Re: 2012 MacBook Pro Debian Bookworm Install

[Timothy M Butterworth]

On Fri, Jun 9, 2023 at 2:47 AM Teemu Likonen  wrote:

> * 2023-06-08 19:32:13-0400, Timothy M. Butterworth wrote:
>
> > I have a 2012 MacBook Pro that I am going to install Debian Bookworm on.
> I
> > will not be keeping OSX on the Mac as it is no longer supported for
> > updates. Does anyone have any tips or tricks for installing Debian on a
> > MacBook Pro?
>
> I don't have that same machine but I believe you won't need any or much
> tricks: it should install and work nicely. I have Apple Macbook Air 2012
> and I have had Debian in it since 2016 or 2017. I reinstalled Debian 11
> last year and all went smoothly again with firmware installer image.
>
>
> https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
>
> Debian 12's (Bookworm) official installer will include non-free firmware
> files.
>
> A couple of tricks I have made. I created /etc/modprobe.d/apple-fn.conf
> file to modify function keys (F1-F12). Normally those keys have various
> special functionality and to access real F1-F12 keys user needs "fn"
> modifier key. I don't like that so I reversed the behavior with the
> following settings:
>
> # /etc/modprobe.d/apple-fn.conf
> # fnmode=1  F1-F12 keys need "fn"
> # fnmode=2  F1-F12 keys work without "fn"
>
> options hid_apple fnmode=2
>
> Apple computers have annoying startup sound ("chime") which can't be
> modified easily from Linux side. I wanted to silence it and the trick
> that works in my Macbook Air is described in Arch Linux wiki (the
> "chattr" and Bash "printf" trick):
>
> https://wiki.archlinux.org/title/mac#Mute_startup_chime
>
> I turned that information into a Bash script:
>
> #!/bin/bash
>
> f=/sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82
> chattr -i "$f"
> # Must be Bash "printf"!
> printf "\x07\x00\x00\x00\x00" > "$f"
> chattr +i "$f"
>
> The settings are persistent so probably that script is needed only once.
> If you set the startup sound silent from Mac OS side before installing
> Linux, that setting persists over to the Linux installation.
>
> --
> /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
> // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
>

Teemu

Thanks for the info. I successfully installed Debian 12 on the MacBook
Pro.  I received a nice surprise as I discovered that Apple restricted the
CPU to 2 cores at 2.5 GHz. With Linux I know have 4 cores at 3.1 GHz!
Almost like buying a new machine. Even with the improved CPU capabilities
it still feels a bit sluggish. At first I thought the problem was that I
needed a RAM upgrade but I have been monitoring the RAM and I have not used
all of it.

The only thing I do not like is the bright white screen that shows up with
the chime. It stays on for a long time with no status display before it
eventually starts Grub. I have been looking for a  way to enter EFI
settings but I have not found anything successful so far. I tried holding
down option but that just took me to a screen to choose which OS to boot. I
tried holding down S, Control+S, Command+S, Command+Control+S,
Command+Control+O+F. None of them worked. Do you know how to get into the
EFI to change the POST settings?

Thanks

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

Re: Do I need X session?

[Michel Verdier]

On 2023-06-12, pa...@quillandmouse.com wrote:

> Typically, when Debian installs a GUI environment (GNOME, XFCE4, etc.),
> it also installs lightdm or some other X session manager. This takes up
> memory, and isn't something I really need (as far as I know). Instead,
> I'm perfectly happy to have Debian give me a console login prompt, and
> then I issue startx.
>
> Is there any liability to removing lightdm or similar?

GNOME, KDE, Xfce are "desktop environments"
lightdm is a "display manager" allowing loging and starting a "window
manager"
with startx you directly start a "window manager" on top of a "X session" and
so you don't need "desktop environment" or "display manager"
I do the same here

Re: exim - bad file descriptor

[steve]

Le 12-06-2023, à 21:25:40 +0200, Michel Verdier a écrit :


On 2023-06-11, steve wrote:


After a few days with this configuration, same errors are still present.

I guess I'll have either to reinstall or go the postfix way.


Just to be sure before you reinstall can you provide
exim -bP | grep syslog


syslog_duplication


Docs indicate it "controls duplicate log lines on syslog".
So adding syslog don't resolve the problem.

Sorry I don't have exim installed here and I can't help you more.
Try a purge+install. Perhaps after upgrading to bookworm :)


I've been a happy bookworm user for months already :)

Will give postfix a try one of these days.

Have a nice day

Re: Debian Trixie

[Leandro Cunha]

Hello,

Recebi mais de 100 updates hoje no testing. Agora eles removeram o bloqueio.

Leandro

Re: Debian home page -> Download link broken:

[songbird]

David Wright wrote:
...
> That's just plain wrong. What was added to bookworm,
> the current stable release, on Release Day was a an
> official number (12 in this instance). Please stop
> trying to sow confusion about codenames.

  ok.


  songbird

Re: Debian home page -> Download link broken:

[songbird]

David Wright wrote:
> songbird wrote:
...
> I can't understand that paragraph. Too many "this", "that"
> and "it"s to know what refers to what.

  haha, that's ok, just let it go.


>>   release notes may not be written and some cases may
>> even be forgotten about.
>
> Which release doesn't have any Notes? Forgotten about
> by whom?

  it isn't the release which happens in testing, when
a package is updated in testing there are no release
notes for that event.  if you are wondering what
is going on you look at the changelogs and/or read up
on the package itself via whatever means you can.  it's
sometimes been the case that the only way i've found
out about some changes is by doing full downloads of
all the source code and doing line-by-line comparisons
between versions - not everything that changes is 
always documented.


>>   with testing, stuff can happen, like sid, stuff can
>> break.  that is just how it goes and i'm quite ok with
>> that because i also do keep a stable partition (which
>> is currently not upgraded yet and won't be until a 
>> point release or two down the line).  my stable is even
>> more stable than the released stable.  there's nobody
>> to force me to upgrade or mysterious software controlled
>> by someone else running to mess with my machine (as i do 
>> not run auto updates).
>
> That's very conservative, and most people don't have twin
> installations as you and I do. You also have years of Debian
> experience, and a degree in computing, I believe. Probably
> a good candidate for running testing.

  i've always been willing to take the chance, with only
a few significant headaches over the years because of a
maintainer making a mistake with a package or me doing 
something boneheaded.

  it also helps that what i'm doing with my computer is
not very extensive in terms of running some sort of 
production system.

  yes, my background is computer science and i spent a
fair number of years running mainframes, minis, pcs, etc.
i retired at a young age to avoid further years of 
sitting at deskjobs being essentially an electronic
janitor and babysitter.  right about when the internet
was becoming popular was when i got away from some things
so my viewpoint is skewed and some web technologies i
pretty much skipped.  like currently the cloud is not
something i know too much about.


...
>>   i consider the release process as a whole which 
>> includes at some point making copies of symlinks to 
>> the package pool and renaming various pathways or
>> copying things as the whole point of making a 
>> release and then building images and such which do
>> include the codename and not using things such as
>> "testing", "sid", "experimental" or "rc-buggy" or
>> ...
>
> More nonsense. They don't add/include a codename.
> What they do add upon release is the release number.
> The codename is the primary collection that is being
> built be Debian. The way in which it is built and
> maintained depends on its current status, and that
> status is reflected, not defined, by the symlinks
> pointing to it. So, a few days ago, bookworm became
> a Release, obtained the number 12, had the stable
> symlink moved to point at it, and now has a policy
> for its modification that differs from what it was
> before.

  yes, it could be another way.  i realize this.
so i could be wrong in other statements.  :)


>>   i don't really think my viewpoint is far from
>> the reality of what does happen, but if anyone
>> from the release team cares to pipe up i'd listen.
>
> They shouldn't need to. It's all been documented in
> the Debian reference/policy manuals, should you care
> to read them.

  i have at various times, since the terminology is not
always consistent you can chase definitions down all 
sorts of rabbit holes.

  to me and in the end the release team's interpretation
of those documents and their specific tools as written
and used are more defining and useful than many policy 
documents (policy documents are at times out of date 
and not updated until there is consensus established 
through practice).  my own experiences in doing support
systems work was to read the code and see what it was 
doing and then going back and seeing if the comments or 
the rest of the framework built around that code were 
accurate.  i'd find a lot of mistakes (which isn't 
something i ever wanted to run into during something 
critical).


> Cheers,
> David.


  songbird

Re: Do I need X session?

[tomas]

On Mon, Jun 12, 2023 at 03:59:40PM -0400, pa...@quillandmouse.com wrote:
> Folks:
> 
> Typically, when Debian installs a GUI environment (GNOME, XFCE4, etc.),
> it also installs lightdm or some other X session manager.

Nitpick: xdm is the X display manager. The X session is something completely
different. You usually want the latter.

>  This takes up
> memory, and isn't something I really need (as far as I know). Instead,
> I'm perfectly happy to have Debian give me a console login prompt, and
> then I issue startx.
> 
> Is there any liability to removing lightdm or similar?

Doing startx is a perfectly valid way of living.

Memory usage is a weak argument, though. While "my" xdm takes 2.2 M
resident memory, Xorg itself is already at 47,6. Firefox (just one of
its eight kraken arms!) goes to a whopping 263 M, that's like one
hundred times xdm! And it still has other seven arms left. And I
start it in a very restricted mode, no javascript for you today.

Gnome? No idea.

But there are other reasons to do startx.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: for the adventurous: apt in readonly rootfs

[tomas]

On Mon, Jun 12, 2023 at 09:53:03PM +0200, Smits Katze wrote:
> >What would be the difference to simply saying
> >
> >  sudo -i
> 
> The effect should be the same (and the command is more concise).
> 
> Thanks for pointing it out.

Thank you for confirmation & sorry for the nitpick :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian home page -> Download link broken:

[Stefan Monnier]

> Using "stable" in your sources.list is idiotic, and you should not do
> it.  Ever.

I guess I'm an idiot, then.

I find it quite convenient because it says exactly what I want: I want
those machines to run Debian stable, whichever version that "stable"
happens to be at any particular time.

AFAIK it used to mean that they got upgraded automatically when a new
release was made, which worked fine for me.  Nowadays it's a bit
different because I get a message like:

N: Repository 'http://deb.debian.org/debian stable InRelease' changed its 
'Version' value from '11.7' to '12.0'
E: Repository 'http://deb.debian.org/debian stable InRelease' changed its 
'Codename' value from 'bullseye' to 'bookworm'
N: This must be accepted explicitly before updates for this repository can 
be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N]

so I don't need to guess that there's a new release from the size of the
`apt full-upgrade`, it says it upfront, but other than that, it works
just as well.

This year, I actually knew that a new release was coming because I saw
announcements on the Fediverse and here, but many times in the past
I didn't, because it's not super important for me.  Using `stable` lets
me know there's a new release without having to read this section of
the news.


Stefan

Re: Debian home page -> Download link broken:

[The Wanderer]

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.

Regardless of what you can or cannot take seriously, the fact is that in
*none* of the cases thus far when I have encountered this message did
the term "release" occur to me as something that I might search for,
except in hindsight after having already encountered the
'--allow-releaseinfo-change" argument name.

>>> AIUI, it contains the string InRelease, according to 
>>> https://lists.debian.org/debian-user/2023/06/msg00392.html in
>>> this thread.
>> 
>> I consider that to be part not of the error message, but of the 
>> repository identifier being referenced *by* the error message. (The
>> same would be true for the labels 'bookworm' and 'trixie'.) It did
>> not occur to me to use that as an indicator of what to search for,
>> and if it had, it would have led me to search not for 'release' but
>> for 'InRelease' - since I consider that latter to be a discrete
>> term of its own.
>> 
>>> Debian's use of camelCase makes it easy to decompose the word.
>>> As pointed out above, the man page that the Note directs you 
>>> (apt-secure) to uses Release rather than InRelease in all but
>>> two places.
>> 
>> I don't think of "InRelease" as being a word, but as being a
>> filename that's presumably used on the repository servers and
>> checked for by the update tooling - i.e., as an implementation
>> detail, which is irrelevant to anyone not attempting to investigate
>> the innards of that tooling or those servers.
> 
> AFAICT the file InRelease is always accompanied by Release and 
> Release.gpg files.

That seems plausible, though again it's an implementation detail which
the end user doesn't need to know about, and was not referenced in the
presented messages.

In case it helps make my perspective more comprehensible: I've been
seeing the term "InRelease" for all these years, in the output of
'apt-get update' as an apparent file file which is being downloaded and
presumably parsed. There's never been any information provided as to
what it is, and there's been no apparent benefit to trying to find out.
(There are other terms used in that output, such as 'rred', which it
seems entirely fruitless to even attempt to find any documentation for;
I've actually found an explanation for that such-as example once, but
don't remember the explanation, and have never been able to find it again.)

Based on that experience, I no longer think of 'InRelease' as being
anything but an unexplained internal detail of the 'apt-get update'
process - one which it shows during its progress messages because that
makes a helpful landmark for keeping track of where in the update
process you are, in case there's a need to troubleshoot an issue. It has
connotations in my mind of an opaque, discrete object, which there is no
point in investigating or thinking about except in terms of that "here's
where the failure occurred" type of troubleshooting.

I certainly don't think of it as being a reference to a codenamed
"release", except perhaps by some historical origin of the filename; I
don't particularly think of it as *not* being that either, however,
because I simply *do not think about it at all*. I'd have been as likely
to think that its name referred to the releases of individual packages
which are indexed within the file (i.e., "packages which are in a
released state"), or something like that, as to think that it referred
to a codenamed Debian release - if, again, I bothered to think about it
at all.

...I've forgotten why I was writing the above paragraphs, or if there
was a concluding point I was trying to reach, although if there was I
think I'd have covered all the necessary ground before the point itself.

>>> I don't know whether or which of your extra repositories use
>>> stable/ testing as suites/codenames, so I can't opine on that.
>> 
>> I wasn't thinking of it as applying only in cases where the
>> symbolic names 'stable' and 'testing' are used; I'm pretty sure it
>> would apply to any repository that uses a symbolic name rather than
>> a release-specific codename, and there's nothing restricting
>> symbolic names to those two.
>> 
>> That said, as far as I recall I don't currently have any 
>> non-Debian-official repositories configured, which is one reason
>> why I'm still considering taking this approach. I have had in the
>> past, however, and I wouldn't want to have to remember to adjust
>> this if I once again add one.
>> 
>> The reason for both of the two reasons I gave is, I think, that I
>> have the 

Re: Debian home page -> Download link broken:

[David Wright]

On Sun 11 Jun 2023 at 19:23:02 (-0400), songbird wrote:
> David Wright wrote:
> > songbird wrote:
> ...
> >>   except that is a misconception for those who are running
> >> testing.  we're not upgrading to a new release.
> >
> > I don't understand. Suite testing was codenamed bookworm until today,
> > and now testing is codenamed trixie. Why is that not a new release?
> 
>   testing is still testing is it not?

No, it was bookworm, it's now trixie. Different repository
operating under different rules.

> they didn't delete it and then create it again.

Trixie? no. Testing? Yes. AIUI, they delete the symlink that
pointed to bookworm, and recreate it, pointing to trixie.
When we used to connect to the Debian site by ftp, you could
see the symlinks themselves in directory listings. I presume
that it's the use of http access that disguises that fact by
displaying testing and trixie as if they were directories of
equal standing.

>   they just created a new directory structure with
> the codename and put links to the packages that were
> the same as testing.  it is like taking a snapshot
> but you don't destroy the original directory.

There's no evidence that anything like that happens,
but only symlink shuffling. It would be a great way
of wasting time and resource, and make the repository
pass through inconsistent states, rather than making
the atomic changes of moving syslinks.

>   after that point testing and stable diverge as
> changes are made (under the rules and procedures of
> the release team and the various software gatekeepers,
> security team, etc.).

The rules change at the instant the symlinks move,
on Release Day. So stable doesn't diverge, it's
Testing that evolves.

>   you could say that as soon as the first change 
> happens that trixie is underway and i wouldn't
> argue too much about that at all, but i don't 
> consider it anything other than testing and a 
> release candidate for trixie.  it's not officially
> a stable release for another 24-?? months and as
> such it isn't really named by me, but others can
> consider it what they want.  it's only the view
> of the release team that really counts (and their
> established procedures and tools).

Think of it however you want, but the facts are that
the codename is the one point of stability in the
whole Debian edifice. If you track a codename, you
know you are using the same repository for the whole
of its life cycle.

>   it's like the chicken and egg problem applied to
> making a cake.  at some point you start with an
> empty bowl and then put in ingredients and then at
> some future point (when the baking is done) you
> have a cake (when it is released from the pan or
> even taken from the oven - as some people do eat
> the cake directly from the pan).  flour alone 
> isn't the cake.  so let's just say that testing is 
> the bowl which holds the ingredients of the next 
> potential stable release, you can call it what you 
> want but it isn't an official release until the 
> release team kicks it out the door with the 
> codename (or not as perhaps some year we run out 
> of codenames or Debian stops producing official 
> images of any kind or ...).

That's just plain wrong. What was added to bookworm,
the current stable release, on Release Day was a an
official number (12 in this instance). Please stop
trying to sow confusion about codenames.

Cheers,
David.

Re: Debian home page -> Download link broken:

[David Wright]

On Sun 11 Jun 2023 at 09:46:49 (-0400), The Wanderer wrote:
> On 2023-06-11 at 09:34, Greg Wooledge wrote:
> > On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
> >> On 2023-06-11 at 09:02, Greg Wooledge wrote:
> 
> >>> Using "stable" in your sources.list is idiotic, and you should
> >>> not do it.  Ever.
> >>> 
> >>> This is not a "use at your own risk" scenario, like using
> >>> "testing". That's OK for people who choose to accept the
> >>> responsibility.
> >>> 
> >>> Using "stable" is just a mistake.

Maybe, but I don't think Debian would proscribe its use, as some
sysadmins might be happy to deal with the consequences as and when
the error and warning messages arise, for whatever reason. That
freedom is part of the open philosophy.

> >> I do not understand why or how. If you want to transition from one
> >> stable release to the next when that "next" release is made, I
> >> don't see any better option for doing so, and I don't see how
> >> there's any downside to using the symbolic name 'stable' for that
> >> purpose.
> > 
> > The issue is that an upgrade to a new stable release CANNOT BE
> > AUTOMATED by the tools.  There are manual steps required, and these
> > are specific to each release, and to each user's unique system.
> 
> While I recognize that automation is in some cases a hard problem, I
> also take the position that if you have a task that has to be carried
> out on a computer over and over the exact same way every time, and you
> are not automating it, you are doing it wrong.
> 
> Thus, I push back - not absolutely, but fairly hard - against "cannot be
> automated".
> 
> > One example of this -- among many! -- is the changing of sources.list
> > line syntax across releases.  This time around, we got a new section
> > ("non-free-firmware") that had to be added to each line. Before that,
> > there was a change to the syntax of the security.debian.org line,
> > from "buster/updates" to "bullseye-security".
> 
> And rather than putting in the design, etc., work to make these things
> happen automatically when they should (and not when they shouldn't), the
> developers gave up and punted it to the release notes. That could be
> acceptable if done rarely, but from what I remember seeing, it seems to
> happen *multiple times per release*.

So in this case they have to mindread the attitude of each sysadmin to
the different categories of non-free software. The same goes for
backports, which I suspect some people (like me) frequently remove as
unnecessary, after an upgrade to a new release.

> As I already mentioned, it's an insufficient solution - both because
> people will not read the release notes before upgrading, as I mentioned,
> and also because people who are tracking testing will encounter these
> changes before the release notes are written. For the most part, release
> notes should be for "important changes you might want to be aware of"
> and/or for getting more information on the details of changes, not for
> some kind of mandatory upgrade checklist.
> 
> I might even argue that for changes like the two you cite, there should
> at minimum have been a tool provided (whether on a Website, or in a
> Debian package, if not something run automatically) which would make the
> necessary adjustments.

Complexity comes at a cost. Making transitional packages for easing
the upgrade of complicated substantive packages themselves seems
reasonable to expend effort on, and leverages the maintainer's
expertise. But I don't think that applies to two-yearly upgrades
that are trivial to implement in themselves, and where the precise
adjustments made depend mainly on the individual sysadmin's policy,
attitude to risk, and so on.

For example, when the message under consideration is received, some
admins tracking "testing" might continue to stick with that, others
might decide that all their hardware is now working well, and switch
to "bookworm" (the most stability), or they might follow the trailing
edge of future Debian development with "stable". And the same applies
across the range of distributions, except sid (and experimental,
not a distribution anyway). How would your automated system decide
which changes to make and when? How would it cope with the sort of
major upgrade changes made during the lenny/squeeze transition
(the paired kernel/udev conundrum).

Cheers,
David.

Re: Debian home page -> Download link broken:

[David Wright]

On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote:
> On 2023-06-11 at 17:36, David Wright wrote:
> > On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote:
> >> On 2023-06-11 at 09:05, David Wright wrote:
> 
> >>> It would seem very simple, the first time this happens, to
> >>> configure this in APT. I typed   man apt-get   (my preferred
> >>> method), /release
> >> 
> >> Where did you come up with the 'release' search term?
> > 
> > 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". Your reasons strike me
as rather like a car driver saying that they didn't know that
"No vehicles" or "No automobiles" applied to them.
The list has been buzzing with the term in anticipation
of release day.

> >> The error message also does not include the string 'release', in
> >> any capitalization variant, so that doesn't provide a hint for what
> >> to search for either.
> > 
> > AIUI, it contains the string InRelease, according to 
> > https://lists.debian.org/debian-user/2023/06/msg00392.html in this
> > thread.
> 
> I consider that to be part not of the error message, but of the
> repository identifier being referenced *by* the error message. (The same
> would be true for the labels 'bookworm' and 'trixie'.) It did not occur
> to me to use that as an indicator of what to search for, and if it had,
> it would have led me to search not for 'release' but for 'InRelease' -
> since I consider that latter to be a discrete term of its own.
> 
> > Debian's use of camelCase makes it easy to decompose the word. As
> > pointed out above, the man page that the Note directs you
> > (apt-secure) to uses Release rather than InRelease in all but two
> > places.
> 
> I don't think of "InRelease" as being a word, but as being a filename
> that's presumably used on the repository servers and checked for by the
> update tooling - i.e., as an implementation detail, which is irrelevant
> to anyone not attempting to investigate the innards of that tooling or
> those servers.

AFAICT the file InRelease is always accompanied by Release and
Release.gpg files.

> > I don't know whether or which of your extra repositories use stable/
> > testing as suites/codenames, so I can't opine on that.
> 
> I wasn't thinking of it as applying only in cases where the symbolic
> names 'stable' and 'testing' are used; I'm pretty sure it would apply to
> any repository that uses a symbolic name rather than a release-specific
> codename, and there's nothing restricting symbolic names to those two.
> 
> That said, as far as I recall I don't currently have any
> non-Debian-official repositories configured, which is one reason why I'm
> still considering taking this approach. I have had in the past, however,
> and I wouldn't want to have to remember to adjust this if I once again
> add one.
> 
> The reason for both of the two reasons I gave is, I think, that I have
> the impression that this "prohibit updating against a changed codename
> unless explicitly approved" behavior is intended in part to protect
> against cases where the name was *not* intended to be a symbolic name,
> but the upstream repository has been taken over and changed (possibly
> legitimately, possibly maliciously). That scenario is one of the things
> I'd prefer to continue to protect against, for any repositories other
> than ones where I know the name in use is a symbolic name.

Seem like tilting at windmills to me.

> All I can say on that front is that when I first ran across mention of
> these configuration settings (many years ago, certainly well before the
> behavior the specific setting we're discussing was introduced), that
> file did not occur to me, and I had no idea where to start looking. I
> think I eventually found a man page somewhere which mentioned the
> filename, rather than just presenting the configuration strings with no
> indication of where to put them, but I don't recall for certain.

Well back then, as best I recall, most packages were configured with
files called, basically, /etc/package.conf(ig) or under /etc/package/
when the package was more complex. The main exceptions were the
traditional well-known unix configuration files.

> Years after that, when I did decide that I wanted to set one of these
> configuration settings, I did manage to dig up the correct file - but I
> don't remember where I found the information, or how I came across it there.

As time goes by, there are examples where information is less focussed
on packages per se, particularly where DEs are involved and
configuration applies more to the whole environment than to individual
packages. But admin utilities, and Debian's own configuration, tends
not to be so monolithic, but more discretely focussed.

> Can you articulate what it is that makes that configuration file name
> seem obvious to you as something to look for, when encountering a string
> such as 'Foo::BarBaz' in an APT 

Re: Debian home page -> Download link broken:

[David Wright]

On Sun 11 Jun 2023 at 19:06:02 (-0400), songbird wrote:
> Greg Wooledge wrote:
> ...
> > The overwhelming majority of people who track testing think that it's
> > a rolling release.  It's not.  It's actually a series of evolving
> > release candidates, with periods of great disruption interspersed with
> > periods of relative calm.
> >
> > You're clearing replying to someone who thinks it's a single rolling
> > release, so set your expectations accordingly.
> 
>   yes, we experience it as it happens, which can sometimes
> be months or even years before the official stable release
> happens and new images are built.  the comment about 
> release candidates is appropriate because that is why
> such things as RC bugs are filed and attempted to be
> fixed before a release actually happens, but that 
> release is a stable and official one and not as far as
> i've ever seen it is not a "release" so calling it a
> rolling release is a contradiction in terminology.  it
> is not a release, but it is a collection of packages 
> in a certain state of being which can change as new 
> packages migrate from unstable (or via testing-pu or
> via other means that perhaps i'm not aware of).  i just
> know that for sure it is not "magic".  :)  someone has
> to do it and make the upload and other things may come
> along and make changes (janitor programs are now doing
> some things, etc.)

I can't understand that paragraph. Too many "this", "that"
and "it"s to know what refers to what.

>   release notes may not be written and some cases may
> even be forgotten about.

Which release doesn't have any Notes? Forgotten about
by whom?

>   with testing, stuff can happen, like sid, stuff can
> break.  that is just how it goes and i'm quite ok with
> that because i also do keep a stable partition (which
> is currently not upgraded yet and won't be until a 
> point release or two down the line).  my stable is even
> more stable than the released stable.  there's nobody
> to force me to upgrade or mysterious software controlled
> by someone else running to mess with my machine (as i do 
> not run auto updates).

That's very conservative, and most people don't have twin
installations as you and I do. You also have years of Debian
experience, and a degree in computing, I believe. Probably
a good candidate for running testing.

>   can you point me to any official statement from the
> project as a whole which says that testing is released 
> and there are official images for people to download?  
> i know of daily and weekly builds of the installer and
> some images but i have never seen any statement from 
> the project as a whole that "testing" is a release 
> candidate and treated as such.  yes, it is the basis
> of the next stable release, but it is not anything
> more than a pool of packages in a directory structure
> which can be copied and updated like any other 
> directory.

Well, it depends when you look at it. The day before a
Release Day, the codename that testing points at looks
very like a release. The next day, that codename becomes
a Release, but of course testing has moved on to point
at the next codename, currently trixie.

Trixie could become a mess, but then again, it probably won't.
If it were, then it wouldn't look like a release, would it.

>   it is, in other words, the collection of packages
> which are used which are the stable release and not 
> anything else which is the main product of making such 
> a stable release and it is the release team which 
> builds that and puts it all together.  as far as i'm 
> concerned it is the release team which has that 
> delegated authority but i guess if they wanted to 
> build "official testing" images or any other 
> collection they surely could, but i'd be a happy
> little potato doing as i have been and running from 
> the testing viewpoint (which can change from moment
> to moment).

Clearly it would be a waste of time and resource to
put testing/trixie onto a DVD and start selling it.

>   i consider the release process as a whole which 
> includes at some point making copies of symlinks to 
> the package pool and renaming various pathways or
> copying things as the whole point of making a 
> release and then building images and such which do
> include the codename and not using things such as
> "testing", "sid", "experimental" or "rc-buggy" or
> ...

More nonsense. They don't add/include a codename.
What they do add upon release is the release number.
The codename is the primary collection that is being
built be Debian. The way in which it is built and
maintained depends on its current status, and that
status is reflected, not defined, by the symlinks
pointing to it. So, a few days ago, bookworm became
a Release, obtained the number 12, had the stable
symlink moved to point at it, and now has a policy
for its modification that differs from what it was
before.

>   i don't really think my viewpoint is far from
> the reality of what does happen, but if anyone
> 

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 09:35:13PM +, bw wrote:
> Right now I'm studying and trying to come up with a way to identify duplicate
> filenames and/or symlinks between /bin /sbin /lib, and /usr/bin /usr/sbin
> /usr/lib.  I bet someone on the list could do it in a one line command.

Well, it's not *that* simple.  Bear in mind that the files in question
are not directly inside /lib and /usr/lib, but instead are inside
subdirectories (e.g. /lib/x86_64-linux-gnu).  So there has to be a
recursive discovery component.

Something like this might work as a starting point.  Note that it
assumes duplicate filename entries will be encountered in pairs, not
in larger groups.  I can't vouch for how well it'll handle finding 3 or
more of the same name.

I'm also not sure if the list of starting directories in the findem
function is complete.

#!/bin/bash

findem() {
find /bin /lib /lib32 /lib64 /sbin /usr/bin /usr/lib /usr/lib32 \
/usr/lib64 /usr/sbin \( -type f -o -type l \) -print0
}
declare -A found

while IFS= read -rd '' f; do
name=${f##*/}
if [[ ${found[x$name]} ]]; then
printf '%s\n' "$f" "${found[x$name]}"
fi
found[x$name]=$f
done < <(findem)

Re: RAM

[The Wanderer]

On 2023-06-12 at 17:47, Bret Busby wrote:

> On 13/6/23 04:52, The Wanderer wrote:

>> I have to apologize; I completely misremembered the name of the program
>> that I was referencing, probably because of the filenames I store its
>> output under. hwinfo is absolutely not it. I would not consider output
>> such as you presented to be appropriately readable for human
>> consumption.
>> 
>> Rather, I got the records I'm looking at from the program 'lshw'.
>> 
> Okay - so the equivalent output that describes the memory, from lshw, is
> 
> "
>   *-memory
>description: System Memory
>physical id: 2f
>slot: System board or motherboard
>size: 128GiB
>capabilities: ecc
>configuration: errordetection=multi-bit-ecc
>  *-bank:0
>   description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
>   product: M393A2G40DB0-CPB
>   vendor: Samsung
>   physical id: 0
>   serial: 400F4723
>   slot: DIMM1
>   size: 16GiB
>   width: 64 bits
>   clock: 2133MHz (0.5ns)



> which may appear to be more "human" understandable, for expressing
> the capacity of each DIMM card in GiB, rather than in bytes,

Actually, that isn't what I found more readable about this. It's more
the separate indented blocks for each distinct item being described, and
the use of lowercase rather than ALL_CAPS field labels, that makes the
difference.

> but, I had no problem in finding and understanding the applicable
> output for describing the RAM component of the hardware.
> 
> If being able to adequately interpret the output from hwinfo, makes
> me other than human, well, such is life.

Oh, certainly not. I can read the other myself, it's just that I
understand myself as doing so through the lens of "thinking like a
computer", similarly to the mindset I find myself in when reading source
code.

> Both utilities work, and, work sufficiently.
> 
> hwinfo is simply less pretty than lshw.
> 
> But, it nevertheless, works.

It certainly does.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RAM

[Bret Busby]

On 13/6/23 04:52, The Wanderer wrote:

On 2023-06-12 at 16:45, Bret Busby wrote:


On 13/6/23 04:30, The Wanderer wrote:


On 2023-06-12 at 16:06, Mick Ab wrote:


I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?


There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.


  From the above, whilst this computer is running Linux Mint Mate 21.1,
which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I
expect that the same will apply for Debian;



Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo



and, in the output (lots of it - it outputs alot of details), is

"
P: /devices/virtual/dmi/id
L: 0
E: DEVPATH=/devices/virtual/dmi/id
E: SUBSYSTEM=dmi
E:
MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:
E: USEC_INITIALIZED=2533353
E: ID_VENDOR=Dell Inc.
E: ID_MODEL=Precision Tower 5810
E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
E: MEMORY_ARRAY_MAX_CAPACITY=137438953472




I have to apologize; I completely misremembered the name of the program
that I was referencing, probably because of the filenames I store its
output under. hwinfo is absolutely not it. I would not consider output
such as you presented to be appropriately readable for human
consumption.

Rather, I got the records I'm looking at from the program 'lshw'.


Okay - so the equivalent output that describes the memory, from lshw, is

"
 *-memory
  description: System Memory
  physical id: 2f
  slot: System board or motherboard
  size: 128GiB
  capabilities: ecc
  configuration: errordetection=multi-bit-ecc
*-bank:0
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 0
 serial: 400F4723
 slot: DIMM1
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:1
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 1
 serial: 39FDE464
 slot: DIMM5
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:2
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 2
 serial: 400F473D
 slot: DIMM3
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:3
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 3
 serial: 39FDD7B6
 slot: DIMM7
 size: 16GiB
 width: 64 bits
 clock: 2133MHz (0.5ns)
*-bank:4
 description: RIMM DDR4 Synchronous 2133 MHz (0.5 ns)
 product: M393A2G40DB0-CPB
 vendor: Samsung
 physical id: 4
 serial: 400F4830
 slot: DIMM2
  

Re:

[German Cardozo]

On Mon, Jun 12, 2023 at 1:33 PM Leo Marín  wrote:
>
>
>
> El lun, 12 jun 2023 a las 13:33, Camaleón () escribió:
>>
>> El 2023-06-12 a las 11:37 -0400, Leo Marín escribió:
>>
>> > Saludos lista,
>> >
>> > pregunta random para no abrir otro hilo,
>> > cambiaron el sourcelist? porque actualizo y veo esto; E: Repository '
>> > http://security.debian.org/debian-security testing-security InRelease'
>> > changed its 'Codename' value from 'bookworm-security' to 'trixie-security'
>> >
>> > tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio colocar
>> > el nombre (trixie) para testing,
>> >
>> > saldos y buen inicio de semana.
>>
>> Me da la impresión de que el mensaje te está avisando que ahora
>> testing-security te va a tomar los paquetes de trixie (nueva testing),
>> no de bookworm (nueva estable), para que cambies o ajustes tu
>> sources.list si ese es tu interés.
>>
>> Resumen: si no haces nada, sigues con testing (trixie).
>
> si eso pensaba también, pero da error y no sé si es temporal o será 
> obligatorio cambiarlo por el nombre.
> me arroja error en todos
>
> E: Repository 'http://security.debian.org/debian-security testing-security 
> InRelease' changed its 'Codename' value from 'bookworm-security' to 
> 'trixie-security'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
> E: Repository 'http://ftp.de.debian.org/debian testing InRelease' changed its 
> 'Codename' value from 'bookworm' to 'trixie'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
> E: Repository 'http://ftp.de.debian.org/debian testing-updates InRelease' 
> changed its 'Codename' value from 'bookworm-updates' to 'trixie-updates'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
>
> lo cambié a "trixie" y todo bien, quizás para los próximos días vuelva a 
> funcionar.
>
>>
>>
>> 
>> https://wiki.debian.org/DebianTesting
>>
>> If you are tracking testing or the next-stable code name, you should
>> always have a corresponding deb http://security.debian.org <"testing"
>> or codename>-security main entry in your apt sources. See this
>> FAQ-Item.
>> 
>>
>> Saludos,
>>
>> --
>> Camaleón
>>
>
>
> --
> L.J.Marín
> Usando: Debian Testing


Hola a Todos!

Si estás en _testing_ (mi caso) el cambio no modifica nada en el
/etc/apt/sources.list.

### /etc/apt/sources.list (antes)
deb http://ftp.us.debian.org/debian/ testing main non-free
non-free-firmware contrib
deb-src http://ftp.us.debian.org/debian/ testing main non-free
non-free-firmware contrib

deb http://security.debian.org/debian-security testing-security main
contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security testing-security
main contrib non-free non-free-firmware

# testing-updates, to get updates before a point release is made;
# see 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://ftp.us.debian.org/debian/ testing-updates main contrib
non-free non-free-firmware
deb-src http://ftp.us.debian.org/debian/ testing-updates main contrib
non-free non-free-firmware

# apt update
Hit:1 http://packages.microsoft.com/repos/code stable InRelease
Get:2 http://ftp.us.debian.org/debian testing InRelease [108 kB]
Get:3 http://security.debian.org/debian-security testing-security
InRelease [48.0 kB]
E: Repository 'http://security.debian.org/debian-security
testing-security InRelease' changed its 'Codename' value from
'bookworm-security' to 'trixie-security'
N: This must be accepted explicitly before updates for this repository
can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this
repository? [y/N] y
Get:4 http://ftp.us.debian.org/debian testing-updates InRelease [49.6
kB]
Hit:5 https://dl.google.com/linux/chrome/deb stable InRelease
E: Repository 'http://ftp.us.debian.org/debian testing InRelease'
changed its 'Codename' value from 'bookworm' to 'trixie'
N: This must be accepted explicitly before updates for this repository
can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this
repository? [y/N] y
E: Repository 'http://ftp.us.debian.org/debian testing-updates
InRelease' changed its 'Codename' value from 'bookworm-updates' to
'trixie-updates'
N: This must be accepted explicitly before updates for this repository
can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this
repository? [y/N] y
Get:6 http://ftp.us.debian.org/debian testing/main Sources.diff/Index
[740 B]
Get:7 http://ftp.us.debian.org/debian testing/main Sources
2023-06-11-0934.16.pdiff [49 B]
Get:7 http://ftp.us.debian.org/debian testing/main Sources
2023-06-11-0934.16.pdiff [49 B]
Fetched 207 kB in 

Re: give us a clue

[mick.crane]

for "mouse" read "trackpad" except when referring to external mouse

Re: Bookworm upgrade, usrmerge failure

[bw]

in-reply-to=

>> On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
...
>>Well, that's somewhat terrifying.  I looked at bugs.debian.org/usrmerge
>>and didn't see any bugs like this already reported.

Sorry for the out of thread posting, but I've been studying the usrmerge issue 
for awhile because I use systems that have been cloned and redeployed on a few 
home machines since 2017.  I understand that some pkgs thru the yrs propagated 
symlinks somewhat randomly (haphazardly?) between lib,bin,sbin and their 
counterparts in usr, or vice-versa.

My current understanding is that if there are duplicate binaries or symlinks, 
this can be an issue when installing usrmerge pkg, and I'd like to minimize the 
annoyance.

Even though there a very few bugs active in debian bugtracker against usrmerge, 
a websearch for 'usrmerge problem' might show that there are possible issues 
that some users need to be proactive in solving IMHO.

Right now I'm studying and trying to come up with a way to identify duplicate 
filenames and/or symlinks between /bin /sbin /lib, and /usr/bin /usr/sbin 
/usr/lib.  I bet someone on the list could do it in a one line command.

I found what looks like a nice oneliner, but it takes some work.  You have to 
create a dir, then symlinks, then run:

awk -F'/' '{
  f = $NF
  a[f] = f in a? a[f] RS $0 : $0
  b[f]++ }
  END{for(x in b)
if(b[x]>1)
  printf "Duplicate Filename: %s\n%s\n",x,a[x] }' <(find -L . -type f)
# 
# and -maxdepth 3 or so to remove the /lib/modules/ clutter

TIA for pursuing the issue, and the attention to issues like this.
L8r,
bw

Re: give us a clue

[mick.crane]

On 2023-06-11 18:43, Peter Ehlert wrote:

On 6/11/23 10:23, mick.crane wrote:

On 2023-06-11 17:53, Peter Ehlert wrote:
On June 11, 2023 9:05:13 AM "mick.crane"  
wrote:


Somebody gave me a Toshiba satellite laptop with the identifying 
number

C50-A-19T
I think this is what is called a Dynabook.
Installed bookworm on it twice the last time with the iso with the
freeware.


Unless this was in the last 24 hours I'm pretty sure you were not
using Bookworm.

Which exact ISO did you use?


This did not automagically cause the trackpad and keyboard to work.
I could only proceed through the installation with a USB mouse and
keyboard.
A laptop might be handy if anybody got the keyboard and trackpad to
work.
and could indicate what to do.
mick


I used firmware-bookworm-DI-alpha1-amd64-DVD-1.iso on a USB stick


I suggest you try again with the new Debian 12 ISO.

there have been significant improvements since the Alpha stage.

best of luck

and previously bookworm alpha "something or other" which is on a CD 
and I've not got the iso to report the exact name..

The keyboard and mouse respond in the BIOS menu.
mick



Well I've tried to install several times to this laptop over the day.
The new Bookworm 12 iso install offers the "select options for the 
install" menu and the keyboard works there but selecting any option the 
laptop keyboard stops responding.
FreeBSD install proceeds using laptop keyboard but on boot half way 
through screen messages are interspersed with screens full of "[OP^" 
text.
Although after failing to logon as "PPP".I seem to have a 
FreeBSD install and the keyboard works but I didn't go as far to install 
X to see if the mouse worked.
It had windows installed on it previously and that seemed to work with 
mouse and keyboard up to the logon before I installed over it.

There is a BIOS type boot message " C drive is "something or other"
So I dunno, maybe wonky keyboard, windows guff in the BIOS.
Toshiba don't seemed too keen to reveal details of this particular 
laptop although there is a BIOS update for
Toshiba Satellite pro for series C50-A models so I may take a chance I 
don't brick it.
Or I may install Bookworm using the external keyboard and mouse and try 
to sort it later or I may bin it and get on with what I'm supposed to be 
doing.

mick

Re: bastante OFFTOPIC - celulares libres

[JavierDebian]

El 12/6/23 a las 15:37, Gonzalo Rivero escribió:


El 10/6/23 a las 07:20, riveravaldez escribió:

On Friday, June 2, 2023, Juan carlos Rebate  wrote:
> (...), en cuanto al SO si eres algo avispado bajas el aosp bajas el 
kernel para el teléfono que tengas y lo compilas así te libras de 
google, y la app del banco la bajas de algún repositorio como 
apkmirror, o bien te bajas androidx86 y lo instalas en el pc y usas la 
app desde ahi


Estas opciones me parece que ameritan investigarse/probarse.

Otra variante más sencilla puede ser buscar en el sitio de LineageOS 
(creo que es la distro abierta más popular basada en AOSP, con la cual 
te ahorras de tener que compilar el sistema) celulares compatibles que 
además puedas adquirir (en mi caso un Moto E LTE 2015), y combinar el 
repositorio de F-Droid para apps libres con la app de Aurora Store 
(que está en F-Droid) para apps del Google Play Store.


Con todos los recaudos del caso, es otra alternativa posible.


hay algunos bancos, al menos el banco macro de argentina, que  no te 
dejan usar otra rom. Incluso me pasó con otro teléfono posterior que lo 
"rootee" para sacarle todas las apps inútiles y hacer algo de espacio 
que tampoco le gustó.


Parece que los programadores del macro piensan que somos idiotas y 
necesitan cuidarnos de nosotros mismos





El de Banco Nación Argentina, si tenés el teléfono "rooteado", no 
funciona, te dice que posiblemente tienes un virus.


JAP

Re: ADD?REMOVE SOFTWARE

[Dan Ritter]

Brad McDonald wrote: 
> IS there any way to make multiple selections of a file,it's dependencies
> and dependant packages rather than one by one as that is very slow.For
> example 3 nights ago I installed all the "electrical" by first the named
> folder then the dependencies then the dependant packages.The following 2
> nights I had as much to put in again.I would like to select everything at
> once with their dependencies


Assuming you're using Debian and haven't done anything odd, 

sudo apt install PACKAGE

will install PACKAGE and all the dependencies.

If you put a list of PACKAGE-A PACKAGE-B PACKAGE-C on the same
command line, all of those packages and all dependencies will be
installed.

-dsr-

Re: ADD?REMOVE SOFTWARE

[err404]

On 6/12/23 20:44, Brad McDonald wrote:

IS there any way to make multiple selections of a file,it's dependencies and dependant 
packages rather than one by one as that is very slow.For example 3 nights ago I installed 
all the "electrical" by first the named folder then the dependencies then the 
dependant packages.The following 2 nights I had as much to put in again.I would like to 
select everything at once with their dependencies


Hello Brad
you can use aptitude (ncurse interface) or synaptic (graphical interface)

if aptitude is not already installed on your computer, you can install it by 
`apt install aptitude`
if synaptic is not already installed on your computer, you can install it by 
`apt install synaptic`

Re: RAM

[Dan Ritter]

Mick Ab wrote: 
> I have seen the dmidecode command being used, but the reliability of the
> information returned is not reliable.

You keep saying that, but have you got any evidence of it? And
if so, it is the unreliability of omission or making things up,
or being random in the returned data?

-dsr-

ADD?REMOVE SOFTWARE

[Brad McDonald]

IS there any way to make multiple selections of a file,it's dependencies
and dependant packages rather than one by one as that is very slow.For
example 3 nights ago I installed all the "electrical" by first the named
folder then the dependencies then the dependant packages.The following 2
nights I had as much to put in again.I would like to select everything at
once with their dependencies

Re: RAM

[The Wanderer]

On 2023-06-12 at 16:45, Bret Busby wrote:

> On 13/6/23 04:30, The Wanderer wrote:
>
>> On 2023-06-12 at 16:06, Mick Ab wrote:
>> 
>>> I wish to obtain information about the RAM installed on my PC using the
>>> command line. The information needed is :-
>>>
>>> Total RAM stored
>>> Number of sticks used and amount of RAM on each stick
>>> Type of RAM e.g. DDR4
>>> Speed of RAM e.g. 3200 MHz
>>> Manufacturer and model number of RAM
>>>
>>> I have seen the dmidecode command being used, but the reliability of the
>>> information returned is not reliable.
>>>
>>> Is there any command that will reliably give the required RAM information ?
>> 
>> There are probably multiple ways to get it, but the first one that comes
>> to my mind involves the 'hwinfo' command, from the package of the same
>> name.
>> 
>> I don't remember exactly how I invoked it, but I have a historical trail
>> of files listing the hardware specifications of my last few machines as
>> they've changed over time, each generated from the output of that
>> command.
>> 
>> 
>> If I search the latest such file for "DIMM", I see two entries, each for
>> a different DIMM (i.e., "RAM stick"), each with multiple data items. The
>> fact that there are two of them gives you the "number of sticks used"
>> you asked for.
>> 
>> Those entries are sub-entries of a larger entry called "memory", which
>> has a data item called "size", which is the "total RAM" you asked for.
>> 
>> One of the data items in each sub-entry is "product", which appears as
>> if it might be the "model number" you asked for. (It certainly looks
>> like a model number, anyway.)
>> 
>> Another is "vendor", which appears to be the "manufacturer" you asked
>> for.
>> 
>> Another is "size", which gives you the "amount of RAM on each stick" you
>> asked for.
>> 
>> Another is "clock", which is the "speed of RAM" you asked for.
>> 
>> Another is "description", which at least in my case specifies (as part
>> of what appears to be a freeform string) that the DIMMs I'm looking at
>> are DDR4. I don't see that information specified anywhere else in the
>> listing.
> 
>  From the above, whilst this computer is running Linux Mint Mate 21.1, 
> which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I 
> expect that the same will apply for Debian;

> Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo

> and, in the output (lots of it - it outputs alot of details), is
> 
> "
> P: /devices/virtual/dmi/id
>L: 0
>E: DEVPATH=/devices/virtual/dmi/id
>E: SUBSYSTEM=dmi
>E: 
> MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:
>E: USEC_INITIALIZED=2533353
>E: ID_VENDOR=Dell Inc.
>E: ID_MODEL=Precision Tower 5810
>E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
>E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
>E: MEMORY_ARRAY_MAX_CAPACITY=137438953472



I have to apologize; I completely misremembered the name of the program
that I was referencing, probably because of the filenames I store its
output under. hwinfo is absolutely not it. I would not consider output
such as you presented to be appropriately readable for human
consumption.

Rather, I got the records I'm looking at from the program 'lshw'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

Re: RAM

[Bret Busby]

On 13/6/23 04:30, The Wanderer wrote:

On 2023-06-12 at 16:06, Mick Ab wrote:


I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?


There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.



From the above, whilst this computer is running Linux Mint Mate 21.1, 
which is based (?) on Ubuntu 22.04 ("jammy"), rather than Debian, I 
expect that the same will apply for Debian;


"
Tue Jun 13 04:32:24 bret@bret-Precision-Tower-5810:~$hwinfo
Command 'hwinfo' not found, but can be installed with:
sudo apt install hwinfo
Tue Jun 13 04:32:40 bret@bret-Precision-Tower-5810:~$sudo apt install hwinfo
[sudo] password for bret:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libhd21 libx86emu3
The following NEW packages will be installed
  hwinfo libhd21 libx86emu3
0 to upgrade, 3 to newly install, 0 to remove and 5 not to upgrade.
Need to get 808 kB of archives.
After this operation, 3,581 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libx86emu3 
amd64 3.1-2 [47.8 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libhd21 
amd64 21.72-1 [742 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy/universe amd64 hwinfo amd64 
21.72-1 [18.0 kB]

Fetched 808 kB in 3s (266 kB/s)
Selecting previously unselected package libx86emu3:amd64.
(Reading database ... 540233 files and directories currently installed.)
Preparing to unpack .../libx86emu3_3.1-2_amd64.deb ...
Unpacking libx86emu3:amd64 (3.1-2) ...
Selecting previously unselected package libhd21:amd64.
Preparing to unpack .../libhd21_21.72-1_amd64.deb ...
Unpacking libhd21:amd64 (21.72-1) ...
Selecting previously unselected package hwinfo.
Preparing to unpack .../hwinfo_21.72-1_amd64.deb ...
Unpacking hwinfo (21.72-1) ...
Setting up libx86emu3:amd64 (3.1-2) ...
Setting up libhd21:amd64 (21.72-1) ...
Setting up hwinfo (21.72-1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
Tue Jun 13 04:33:23 bret@bret-Precision-Tower-5810:~$hwinfo
"

and, in the output (lots of it - it outputs alot of details), is

"
P: /devices/virtual/dmi/id
  L: 0
  E: DEVPATH=/devices/virtual/dmi/id
  E: SUBSYSTEM=dmi
  E: 
MODALIAS=dmi:bvnDellInc.:bvrA34:bd10/19/2020:br65.34:svnDellInc.:pnPrecisionTower5810:pvr:rvnDellInc.:rn0K240Y:rvrA02:cvnDellInc.:ct7:cvr:sku0617:

  E: USEC_INITIALIZED=2533353
  E: ID_VENDOR=Dell Inc.
  E: ID_MODEL=Precision Tower 5810
  E: MEMORY_ARRAY_LOCATION=System Board Or Motherboard
  E: MEMORY_ARRAY_EC_TYPE=Multi-bit ECC
  E: MEMORY_ARRAY_MAX_CAPACITY=137438953472
  E: MEMORY_DEVICE_0_TOTAL_WIDTH=72
  E: MEMORY_DEVICE_0_DATA_WIDTH=64
  E: MEMORY_DEVICE_0_SIZE=17179869184
  E: MEMORY_DEVICE_0_FORM_FACTOR=RIMM
  E: MEMORY_DEVICE_0_LOCATOR=DIMM1
  E: MEMORY_DEVICE_0_BANK_LOCATOR=Not Specified
  E: MEMORY_DEVICE_0_TYPE=DDR4
  E: MEMORY_DEVICE_0_TYPE_DETAIL=Synchronous
  E: MEMORY_DEVICE_0_SPEED_MTS=2133
  E: MEMORY_DEVICE_0_MANUFACTURER=Samsung
  E: MEMORY_DEVICE_0_SERIAL_NUMBER=400F4723
  E: MEMORY_DEVICE_0_ASSET_TAG=02081530
  E: MEMORY_DEVICE_0_PART_NUMBER=M393A2G40DB0-CPB
  E: MEMORY_DEVICE_0_RANK=2
  E: 

Re: RAM in inxi

[Felix Miata]

Roger Price composed on 2023-06-12 22:25 (UTC+0200):

> According to man inxi the command "inxi -mxx" tries to improve on dmidecode.

h2 on irc://irc.oftc.net/smxi (IRC) is inxi's creator. 3.3.27-00 is the current
version, released on 2023-05-07. The devel version is named pinxi, currently at
3.3.27-12, released yesterday. https://smxi.org/ is author's home page, which
links to his own forum.

3.3.27-12 contains a WIP of memory reporting improvements. If you wish to be 
heard
on the subject, or have questions about or problems with pinxi, h2 is all ears.

Maximum RAM reporting in inxi comes from -ma:

# inxi -mxx --vs
inxi 3.3.27-00 (2023-05-07)
Memory:
  System RAM: available: 30.29 GiB used: 14.99 GiB (49.5%)
  Array-1: capacity: 32 GiB slots: 4 EC: None max-module-size: 8 GiB
note: est.
  Device-1: ChannelA-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Corsair part-no: CML16GX3M2A1600C9
  Device-2: ChannelA-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Mushkin part-no: 992069 (997069)
  Device-3: ChannelB-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Corsair part-no: CML16GX3M2A1600C9
  Device-4: ChannelB-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
volts: 1.5 manufacturer: Mushkin part-no: 992069 (997069)
# pinxi -ma --vs
pinxi 3.3.27-12 (2023-06-12)
Memory:
  System RAM: total: 32 GiB available: 30.29 GiB used: 15.02 GiB (49.6%)
igpu: 544 MiB
  Array-1: capacity: 32 GiB slots: 4 modules: 4 EC: None
max-module-size: 8 GiB note: est.
  Device-1: ChannelA-DIMM0 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Corsair part-no: CML16GX3M2A1600C9 serial: N/A
  Device-2: ChannelA-DIMM1 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Mushkin part-no: 992069 (997069) serial: N/A
  Device-3: ChannelB-DIMM0 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
total: 64 manufacturer: Corsair part-no: CML16GX3M2A1600C9 serial: N/A
  Device-4: ChannelB-DIMM1 type: DDR3 detail: synchronous size: 8 GiB
speed: 1600 MT/s volts: curr: 1.5 min: 1.5 max: 1.5 width (bits): data: 64
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: RAM

[The Wanderer]

On 2023-06-12 at 16:06, Mick Ab wrote:

> I wish to obtain information about the RAM installed on my PC using the
> command line. The information needed is :-
> 
> Total RAM stored
> Number of sticks used and amount of RAM on each stick
> Type of RAM e.g. DDR4
> Speed of RAM e.g. 3200 MHz
> Manufacturer and model number of RAM
> 
> I have seen the dmidecode command being used, but the reliability of the
> information returned is not reliable.
> 
> Is there any command that will reliably give the required RAM information ?

There are probably multiple ways to get it, but the first one that comes
to my mind involves the 'hwinfo' command, from the package of the same
name.

I don't remember exactly how I invoked it, but I have a historical trail
of files listing the hardware specifications of my last few machines as
they've changed over time, each generated from the output of that
command.


If I search the latest such file for "DIMM", I see two entries, each for
a different DIMM (i.e., "RAM stick"), each with multiple data items. The
fact that there are two of them gives you the "number of sticks used"
you asked for.

Those entries are sub-entries of a larger entry called "memory", which
has a data item called "size", which is the "total RAM" you asked for.

One of the data items in each sub-entry is "product", which appears as
if it might be the "model number" you asked for. (It certainly looks
like a model number, anyway.)

Another is "vendor", which appears to be the "manufacturer" you asked
for.

Another is "size", which gives you the "amount of RAM on each stick" you
asked for.

Another is "clock", which is the "speed of RAM" you asked for.

Another is "description", which at least in my case specifies (as part
of what appears to be a freeform string) that the DIMMs I'm looking at
are DDR4. I don't see that information specified anywhere else in the
listing.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: RAM

[Roger Price]

On Mon, 12 Jun 2023, Mick Ab wrote:


I have seen the dmidecode command being used, but the reliability of the 
information returned is not reliable.
Is there any command that will reliably give the required RAM information ?


According to man inxi the command "inxi -mxx" tries to improve on dmidecode.

Quoting from man inxi :  Because dmidecode data is extremely unreliable, inxi 
will try to make best guesses.  If you see (check) after the capacity number, 
you should check it with the specifications. (est) is slightly more reliable, 
but you should still check the real specifications before buying RAM. 
Unfortunately there is nothing inxi can do to get truly reliable data about the 
system RAM;  maybe one day the kernel devs will put this data into /sys, and 
make it real data, taken from the actual system, not dmi data. For most people, 
the data will be right, but a significant percentage of users will have either a 
wrong max module size, if present, or max capacity.


Roger

Re: RAM

[Charles Curley]

On Mon, 12 Jun 2023 21:06:06 +0100
Mick Ab  wrote:

> I have seen the dmidecode command being used, but the reliability of
> the information returned is not reliable.
> 
> Is there any command that will reliably give the required RAM
> information ?

Any tool, dmidecode included, is no better than the date it operates
on. If dmidecode is returning bogus data, so will any other tool.

Dmidecode relies on information in ROM. Your alternatives are:

* A physical inventory, i.e. shut the machine down, take a screwdriver
  to it, and look at what's in there.

* A program that shuts off virtual memory and does an inventory by
  testing the RAM. And that has its own problems.

-- 
Does anybody read signatures any more?

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

Re: Do I need X session?

[Greg Wooledge]

On Mon, Jun 12, 2023 at 03:59:40PM -0400, pa...@quillandmouse.com wrote:
> I'm perfectly happy to have Debian give me a console login prompt, and
> then I issue startx.

That's what I use too.  As well as several other people who post regularly
on this mailing list.

Do I need X session?

[paulf]

Folks:

Typically, when Debian installs a GUI environment (GNOME, XFCE4, etc.),
it also installs lightdm or some other X session manager. This takes up
memory, and isn't something I really need (as far as I know). Instead,
I'm perfectly happy to have Debian give me a console login prompt, and
then I issue startx.

Is there any liability to removing lightdm or similar?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: for the adventurous: apt in readonly rootfs

[Smits Katze]

>What would be the difference to simply saying
>
>  sudo -i

The effect should be the same (and the command is more concise).

Thanks for pointing it out.

-- 
PGP: FF815935D964B268656B43DCB8037830D522909E

RAM

[Mick Ab]

I wish to obtain information about the RAM installed on my PC using the
command line. The information needed is :-

Total RAM stored
Number of sticks used and amount of RAM on each stick
Type of RAM e.g. DDR4
Speed of RAM e.g. 3200 MHz
Manufacturer and model number of RAM

I have seen the dmidecode command being used, but the reliability of the
information returned is not reliable.

Is there any command that will reliably give the required RAM information ?

Re: Ligne de commande

[Marc Chantreux]

Le Mon, Jun 12, 2023 at 08:54:45PM +0200, Erwan David a écrit :
> Le 12/06/2023 à 19:59, Marc Chantreux a écrit :
> Avec 30 machines (voire quelques centaines)

> 1) tu passes par de l'automatisation

oui …

> (salt, ansible, puppet, etc.) qui va
> pousser un sources.list (et pas le modifier)

mais non!

apres en avoir utilisé un certain nombre, je ne vois tjrs
pas la valeur ajoutée par rapport à ssh+(les trucs dont
j'ai besoin) et trouve ça contre-productif: tout le temps
perdu à assimiler une nouvelle techno ne sera pas investi
dans l'apprentissage d'outils bien plus génériques
(ssh, les fifos, make, apt et dpkg-buildpackage …).

> 2) tu upgrades pas en block,

là encore: ça dépend vraiment du contexte (les risques de
divergence de comportement entre les machines, le temps à
consacrer, …)

cordialement,
marc

Re:

[Leo Marín]

El lun, 12 jun 2023 a las 13:33, Camaleón () escribió:

> El 2023-06-12 a las 11:37 -0400, Leo Marín escribió:
>
> > Saludos lista,
> >
> > pregunta random para no abrir otro hilo,
> > cambiaron el sourcelist? porque actualizo y veo esto; E: Repository '
> > http://security.debian.org/debian-security testing-security InRelease'
> > changed its 'Codename' value from 'bookworm-security' to
> 'trixie-security'
> >
> > tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio colocar
> > el nombre (trixie) para testing,
> >
> > saldos y buen inicio de semana.
>
> Me da la impresión de que el mensaje te está avisando que ahora
> testing-security te va a tomar los paquetes de trixie (nueva testing),
> no de bookworm (nueva estable), para que cambies o ajustes tu
> sources.list si ese es tu interés.
>
> Resumen: si no haces nada, sigues con testing (trixie).
>
si eso pensaba también, pero da error y no sé si es temporal o será
obligatorio cambiarlo por el nombre.
me arroja error en todos

E: Repository 'http://security.debian.org/debian-security testing-security
InRelease' changed its 'Codename' value from 'bookworm-security' to
'trixie-security'
N: This must be accepted explicitly before updates for this repository can
be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian testing InRelease' changed
its 'Codename' value from 'bookworm' to 'trixie'
N: This must be accepted explicitly before updates for this repository can
be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian testing-updates InRelease'
changed its 'Codename' value from 'bookworm-updates' to 'trixie-updates'
N: This must be accepted explicitly before updates for this repository can
be applied. See apt-secure(8) manpage for details.

lo cambié a "trixie" y todo bien, quizás para los próximos días vuelva a
funcionar.


>
> 
> https://wiki.debian.org/DebianTesting
>
> If you are tracking testing or the next-stable code name, you should
> always have a corresponding deb http://security.debian.org <"testing"
> or codename>-security main entry in your apt sources. See this
> FAQ-Item.
> 
>
> Saludos,
>
> --
> Camaleón
>
>

-- 
L.J.Marín
Usando: Debian Testing

Re: exim - bad file descriptor

[Michel Verdier]

On 2023-06-11, steve wrote:

>>> After a few days with this configuration, same errors are still present.
>>>
>>> I guess I'll have either to reinstall or go the postfix way.
>>
>>Just to be sure before you reinstall can you provide
>>exim -bP | grep syslog
>
> syslog_duplication

Docs indicate it "controls duplicate log lines on syslog".
So adding syslog don't resolve the problem.

Sorry I don't have exim installed here and I can't help you more.
Try a purge+install. Perhaps after upgrading to bookworm :)

Re:

[Leo Marín]

El lun, 12 jun 2023 a las 13:20, Gerardo Braica ()
escribió:

> Como va? El mio esta funcionando asi:
>
> deb http://security.debian.org/debian-security bookworm-security main
> contrib non-free-firmware
>
si así es como me funcionó, cambiando testing por trixie, en mi caso


>
>
>
> El 12/6/23 a las 12:37, Leo Marín escribió:
>
> Saludos lista,
>
> pregunta random para no abrir otro hilo,
> cambiaron el sourcelist? porque actualizo y veo esto; E: Repository '
> http://security.debian.org/debian-security testing-security InRelease'
> changed its 'Codename' value from 'bookworm-security' to 'trixie-security'
>
> tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio colocar
> el nombre (trixie) para testing,
>
> saldos y buen inicio de semana.
>
> El jue, 8 jun 2023 a las 12:23, hubble () escribió:
>
>> On Tue, 6 Jun 2023 09:29:57 +0200
>> Camaleón  wrote:
>>
>> > El 2023-06-05 a las 21:30 +0100, José Manuel (Abogado) escribió:
>> >
>> > > El 5/6/23 a las 16:24, Camaleón escribió:
>> > > > El 2023-06-05 a las 09:00 -0500, Eliecer Rangel escribió:
>> > > >
>> > > > > Esperando con ansías el lanzamiento de Debian 12 Bookworm, este
>> sábado 10
>> > > > > de Junio del 2023.
>> > > > >
>> > > > > Fuente oficial de la noticia:
>> > > > > https://wiki.debian.org/ReleasePartyBookworm
>> > > > Pues sale con 100 BUGS conocidos :-/
>> > > >
>> > > > https://www.phoronix.com/news/Debian-12-Next-Week
>> > > >
>> > > > Sugerencias a quien vaya a instalarlo:
>> > > >
>> > > > 1. Que espere a que salga la primera «point release» (un mes más
>> tarde)
>> > > > 2. Que LEA BIEN las notas de la versión para evitar sustos y
>> desastres
>> > > >
>> > > Hola
>> > > Que nos recomiendas para los que tenemos en los repositorios puesto la
>> > > palabra stable en vez de bullseye
>> > > Gracias
>> >
>> > Si quieres mnatener la versión que tienes (Debian 11), cambia YA los
>> > repos para que apunten a Bullseye.
>> >
>> > Si quieres actualizar a la nueva versión Bookworm (Debian 12), hacer
>> > una copia de los datos que sean importantes y no quieras perder y
>> > seguir las indicaciones de las Notas de la versión:
>> >
>> > Chapter 4. Upgrades from Debian 11 (bullseye)
>> >
>> https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html
>> >
>> > Capítulo 4. Actualizaciones desde Debian 11 (bullseye)
>> >
>> https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.es.html
>> >
>> > Yo estoy con Debian 11, pero no voy a actualizar porque tengo varios
>> > equipos y servidores y prefiero actualizar cada 4/5 años.
>> >
>> > Cuando tenga que «actualizar¹», lo que hago es lo siguiente:
>> >
>> > 1. Descargo una LiveCD de la versión de Debian que quiero instalar,
>> > y la cargo para descartar problemas con el hardware (mis equipos son
>> > viejitos y el kernel puede ponerse farruco).
>> >
>> > 2. Si todo va bien, descargo la miniISO (para los servidores) y el CD de
>> > instalación de XFCE (para estaciones de trabajo) e instalo la nueva
>> > versión de Debian desde cero, en una partición aparte.
>> >
>> > 3. Tras instalar todas las aplicaciones de nuevo, copio los datos al
>> nuevo
>> > sistema y listo.
>> >
>> > Ventajas: mínimos problemas de compatibilidad, tengo redundancia de
>> > datos y sistemas operativos.
>> >
>> > Inconvenientes: pierto el 50% de espacio en disco duro, ya que siempre
>> > tengo dos sistemas operativos funcionales e independientes, pero con el
>> > tamaño de los discos actuales casi que es mejor así, no me gustan las
>> > particiones gordas en exceso. También en un sistema labrioso y costoso
>> > en tiempo pero desde que uso Debian me ha funcionado sin problemas.
>> >
>> > ¹Yo nunca actualizo, instalo desde cero los sistemas operativos.
>> >
>> > Saludos,
>> >
>> > --
>> > Camaleón
>> >
>>
>> Sólo informar que tengo un portatil ASUS br1100FKA (uno de esos
>> portàtiles educativos cautivo de M$).
>> En dicho portatil sólo pude ejectutar e instalar UBUNTU porque el kernel
>> de debian en sus imágenes de instalación no se llevaba bien con la bios y
>> algún componente y no llegaba ni tan solo al menu de grub.
>> Ahora he probado la live de debian y he de decir que ha arrancado.
>> Puede que haya sido sólo la live y que cuando quiera hacer una
>> instalación resulte que no funciona, ya en su momento lo comentaré
>> (esperaré a que quiten esos 100 bugs que comentaba camaleon).
>> Pero ni la live debian-live-11.2.0-amd64-kde.iso ni el CD standard de
>> instalación llegaba a arrancar el grub y
>> debian-live-bkworm-DI-rc4-amd64-kde.iso sí que lo hace.
>>
>> saludos
>> --
>>
>>
>
> --
> L.J.Marín
> Usando: Debian Testing
>
>
> --
>
>
> *Gerardo Braica gbra...@gmail.com.ar  *
>


-- 
L.J.Marín
Usando: Debian Testing

Re: Ligne de commande

[Erwan David]

Le 12/06/2023 à 19:59, Marc Chantreux a écrit :

Le Mon, Jun 12, 2023 at 07:37:45PM +0200, Erwan David a écrit :

J'aurais plutôt fait

sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list

tu pars du principe que c'est bullseye tout le temps et pas stable de
temps en temps.


Mais ça reste un peu tordu d ene pas vouloir utiliser d'éditeur de texte.

pour une station de travail oui. si tu as 30 machines c'est
effectivement mieux de scripter.


Avec 30 machines (voire quelques centaines)

1) tu passes par de l'automatisation (salt, ansible, puppet, etc.) qui 
va pousser un sources.list (et pas le modifier)


2) tu upgrades pas en block, tu vérifies dans chaque cas si les services 
qui tournent ont besoin de vérifier les configurations. Et dans certains 
cas tu réinstalles plutôt que d'upgrader

Re: Debian Trixie

[Leandro Cunha]

Oi,

On Mon, Jun 12, 2023 at 9:30 AM Rafael de Almeida  wrote:
>
> Entendo quando a um lançamento o untable se torna testing... Então estava 
> pensando que seria da mesma forma quando o Debian stable foi lançando, 
> automaticamente o Debian unstable se tornaria testing. (Sempre gosto de usar 
> a versão testing)

Não gosto muito de falar que unstable vira testing, tem alguns pacotes
que ficam longe de migrar para testing (devido a critério do time que
cuida dos lançamentos) e estes pacotes não irão para unstable a não
ser que isso mude (como virtualbox, mysql e firefox (sem ser o ESR)).
O unstable é uma distribuição do Debian e testing seria outra (que
conta com algumas automatizações que acompanha uma série de critérios
para que os pacotes cheguem até o testing). Pode ser que neste momento
testing ainda esteja bloqueado pelos gerentes de lançamento até que
eles resolvem remover o bloqueio.

-- 
Cheers,
Leandro Cunha

Re: bastante OFFTOPIC - celulares libres

[Gonzalo Rivero]

El 10/6/23 a las 07:20, riveravaldez escribió:

On Friday, June 2, 2023, Juan carlos Rebate  wrote:
> (...), en cuanto al SO si eres algo avispado bajas el aosp bajas el 
kernel para el teléfono que tengas y lo compilas así te libras de 
google, y la app del banco la bajas de algún repositorio como 
apkmirror, o bien te bajas androidx86 y lo instalas en el pc y usas la 
app desde ahi


Estas opciones me parece que ameritan investigarse/probarse.

Otra variante más sencilla puede ser buscar en el sitio de LineageOS 
(creo que es la distro abierta más popular basada en AOSP, con la cual 
te ahorras de tener que compilar el sistema) celulares compatibles que 
además puedas adquirir (en mi caso un Moto E LTE 2015), y combinar el 
repositorio de F-Droid para apps libres con la app de Aurora Store 
(que está en F-Droid) para apps del Google Play Store.


Con todos los recaudos del caso, es otra alternativa posible.


hay algunos bancos, al menos el banco macro de argentina, que  no te 
dejan usar otra rom. Incluso me pasó con otro teléfono posterior que lo 
"rootee" para sacarle todas las apps inútiles y hacer algo de espacio 
que tampoco le gustó.


Parece que los programadores del macro piensan que somos idiotas y 
necesitan cuidarnos de nosotros mismos

Re: for the adventurous: apt in readonly rootfs

[tomas]

On Mon, Jun 12, 2023 at 06:54:40PM +0200, Smits Katze wrote:
> Debian wiki describes how to configure a read-only rootfs and how to
> run apt and unattended-upgrades in such a filesystem:
> https://wiki.debian.org/ReadonlyRoot
> 
> I would like to report that I am having considerable success with the
> following simple command sequence:
> 
> sudo su -l

What would be the difference to simply saying

  sudo -i

?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Ligne de commande

[Marc Chantreux]

Le Mon, Jun 12, 2023 at 07:44:55PM +0200, Lamourec Alain a écrit :
> > J'aurais plutôt fait
> > 
> > sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list
> 
> Oui mais il faut rajouter non-free-firmware comme dans le modèle de marc ou
> alors s'en passer

ah oui! exact :) merci.

marc

Re: Bookworm upgrade, usrmerge failure

[Jeffrey Walton]

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

Re: Ligne de commande

[Marc Chantreux]

Le Mon, Jun 12, 2023 at 07:43:51PM +0200, Frederic Zulian a écrit :
> Euh,  je ne comprends pas.  Pourquoi mettre les sources d'unstable ?

* quand je m'intéresse à des sources, c'est en général les plus récents
* dans les cas simples, ca permet de faire un backport vite fait avec
  apt source + dpkg-buildpackage

cordialement,
marc

Re: Ligne de commande

[Marc Chantreux]

Le Mon, Jun 12, 2023 at 07:37:45PM +0200, Erwan David a écrit :
> J'aurais plutôt fait
> 
> sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list

tu pars du principe que c'est bullseye tout le temps et pas stable de
temps en temps.

> Mais ça reste un peu tordu d ene pas vouloir utiliser d'éditeur de texte.

pour une station de travail oui. si tu as 30 machines c'est
effectivement mieux de scripter.

a+
marc

Re: bookworm upgrade report: boring

[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.

-- 
Celejar

Re: Ligne de commande

[Lamourec Alain]

Erwan David  writes:


Le 12/06/2023 à 19:33, Marc Chantreux a écrit :
Le Mon, Jun 12, 2023 at 05:17:41PM +, Simeone Dominique a 
écrit :

Chers amis,
comment ajouter à sources.list la nouvelle deb de Bookworm 
sans vim et en ligne de commande direct!

Tout dépend de ce que tu avais précédement et de ce que tu veux
conserver. Il faut aussi surveiller ce que tu avais 
éventuellement dans

/etc/apt/sources.list.d.

Si il est vide et que tu n'avais pas ajouté de sources à la 
main,

je dirais:

<<\% cat > /etc/apt/sources.list
deb http://security.debian.org/debian-security 
bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm main non-free 
non-free-firmware contrib
deb http://deb.debian.org/debian/ bookworm-updates main contrib 
non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main 
contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ unstable main contrib 
non-free non-free-firmware

%

marc



J'aurais plutôt fait

sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list

ce qui met une sauvegarde de l'ancien fichier dans 
/etc/apt/sources.list.bak


Mais ça reste un peu tordu d ene pas vouloir utiliser d'éditeur 
de texte.


Oui mais il faut rajouter non-free-firmware comme dans le modèle 
de marc ou alors s'en passer


--
Lamourec Alain

Re: Ligne de commande

[Frederic Zulian]

Euh,  je ne comprends pas.  Pourquoi mettre les sources d'unstable ?

> deb-src http://deb.debian.org/debian/ unstable main contrib non-free
non-free-firmware

Frédéric ZULIAN



Le lun. 12 juin 2023 à 19:38, Erwan David  a écrit :

> Le 12/06/2023 à 19:33, Marc Chantreux a écrit :
> > Le Mon, Jun 12, 2023 at 05:17:41PM +, Simeone Dominique a écrit :
> >> Chers amis,
> >> comment ajouter à sources.list la nouvelle deb de Bookworm sans vim et
> en ligne de commande direct!
> > Tout dépend de ce que tu avais précédement et de ce que tu veux
> > conserver. Il faut aussi surveiller ce que tu avais éventuellement dans
> > /etc/apt/sources.list.d.
> >
> > Si il est vide et que tu n'avais pas ajouté de sources à la main,
> > je dirais:
> >
> > <<\% cat > /etc/apt/sources.list
> > deb http://security.debian.org/debian-security bookworm-security main
> contrib non-free non-free-firmware
> > deb http://deb.debian.org/debian/ bookworm main non-free
> non-free-firmware contrib
> > deb http://deb.debian.org/debian/ bookworm-updates main contrib
> non-free non-free-firmware
> > deb http://deb.debian.org/debian/ bookworm-backports main contrib
> non-free non-free-firmware
> > deb-src http://deb.debian.org/debian/ unstable main contrib non-free
> non-free-firmware
> > %
> >
> > marc
> >
> >
> J'aurais plutôt fait
>
> sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list
>
> ce qui met une sauvegarde de l'ancien fichier dans
> /etc/apt/sources.list.bak
>
> Mais ça reste un peu tordu d ene pas vouloir utiliser d'éditeur de texte.
>
>

Re: Ligne de commande

[Erwan David]

Le 12/06/2023 à 19:33, Marc Chantreux a écrit :

Le Mon, Jun 12, 2023 at 05:17:41PM +, Simeone Dominique a écrit :

Chers amis,
comment ajouter à sources.list la nouvelle deb de Bookworm sans vim et en ligne 
de commande direct!

Tout dépend de ce que tu avais précédement et de ce que tu veux
conserver. Il faut aussi surveiller ce que tu avais éventuellement dans
/etc/apt/sources.list.d.

Si il est vide et que tu n'avais pas ajouté de sources à la main,
je dirais:

<<\% cat > /etc/apt/sources.list
deb http://security.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ unstable main contrib non-free 
non-free-firmware
%

marc



J'aurais plutôt fait

sudo sed -i.bak 's/bullseye/bookworm/' /etc/apt/sources.list

ce qui met une sauvegarde de l'ancien fichier dans /etc/apt/sources.list.bak

Mais ça reste un peu tordu d ene pas vouloir utiliser d'éditeur de texte.

Re: Ligne de commande

[Marc Chantreux]

Le Mon, Jun 12, 2023 at 05:17:41PM +, Simeone Dominique a écrit :
> Chers amis,
> comment ajouter à sources.list la nouvelle deb de Bookworm sans vim et en 
> ligne de commande direct!

Tout dépend de ce que tu avais précédement et de ce que tu veux
conserver. Il faut aussi surveiller ce que tu avais éventuellement dans
/etc/apt/sources.list.d.

Si il est vide et que tu n'avais pas ajouté de sources à la main,
je dirais:

<<\% cat > /etc/apt/sources.list
deb http://security.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ unstable main contrib non-free 
non-free-firmware
%

marc

Re: bookworm upgrade report: boring

[Celejar]

On Mon, 12 Jun 2023 18:02:13 +0100
Brian  wrote:

> On Mon 12 Jun 2023 at 08:50:54 -0400, Celejar wrote:
> 
> > On Sun, 11 Jun 2023 12:31:31 -0400
> > Dan Ritter  wrote:
> > 
> > > 
> > > The machine I am typing on has been upgraded from bullseye to
> > > bookworm. TL;DR: boring, which is good.
> > 
> > ...
> > 
> > > I read the release notes.
> > > 
> > > Changed sources.list entries.
> > > 
> > > Ran apt update.
> > > 
> > > I ran apt upgrade --without-new-pkgs before apt full-upgrade.
> > > Then I rebooted.
> > > 
> > > 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 have taken to assuming that detected changes are due to my efforts

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
**

Is this important? 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.

-- 
Celejar

Re:

[Camaleón]

El 2023-06-12 a las 11:37 -0400, Leo Marín escribió:

> Saludos lista,
> 
> pregunta random para no abrir otro hilo,
> cambiaron el sourcelist? porque actualizo y veo esto; E: Repository '
> http://security.debian.org/debian-security testing-security InRelease'
> changed its 'Codename' value from 'bookworm-security' to 'trixie-security'
> 
> tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio colocar
> el nombre (trixie) para testing,
> 
> saldos y buen inicio de semana.

Me da la impresión de que el mensaje te está avisando que ahora 
testing-security te va a tomar los paquetes de trixie (nueva testing), 
no de bookworm (nueva estable), para que cambies o ajustes tu 
sources.list si ese es tu interés.

Resumen: si no haces nada, sigues con testing (trixie).


https://wiki.debian.org/DebianTesting

If you are tracking testing or the next-stable code name, you should 
always have a corresponding deb http://security.debian.org <"testing" 
or codename>-security main entry in your apt sources. See this 
FAQ-Item. 


Saludos,

-- 
Camaleón 

Re: Ligne de commande

[Basile Starynkevitch]

On 6/12/23 19:17, Simeone Dominique wrote:

Chers amis,

comment ajouter à sources.list la nouvelle deb de Bookworm sans vim et 
en ligne de commande direct!


Bien à vous.

Mr.Dominique Simeone



On n'ajoute pas. On remplace. Si la commande à considérer est sed ou ed, 
sur le fichier /etc/apt/sources.list


(ensuite aptitude update et aptitude upgrade, et croiser les doigts pour 
que tout se passe bien)



Mon conseil est bien évidemment de sauvegarder /etc et /home sur un 
support ou machine externe (peut-être avec rsync) avant la mise à jour 
de la Debian (elle pourrait mal se passer, et il faut dans le pire cas 
réinstaller ex-nihilo)



Librement.


NB je cherche (comme d'habitude) des partenaires intéressés par 
http://refpersys.org/


Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re:

[Gerardo Braica]

Como va? El mio esta funcionando asi:

deb http://security.debian.org/debian-security bookworm-security main 
contrib non-free-firmware




El 12/6/23 a las 12:37, Leo Marín escribió:

Saludos lista,

pregunta random para no abrir otro hilo,
cambiaron el sourcelist? porque actualizo y veo esto; E: Repository 
'http://security.debian.org/debian-security testing-security 
InRelease' changed its 'Codename' value from 'bookworm-security' to 
'trixie-security'


tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio 
colocar el nombre (trixie) para testing,


saldos y buen inicio de semana.

El jue, 8 jun 2023 a las 12:23, hubble () escribió:

On Tue, 6 Jun 2023 09:29:57 +0200
Camaleón  wrote:

> El 2023-06-05 a las 21:30 +0100, José Manuel (Abogado) escribió:
>
> > El 5/6/23 a las 16:24, Camaleón escribió:
> > > El 2023-06-05 a las 09:00 -0500, Eliecer Rangel escribió:
> > >
> > > > Esperando con ansías el lanzamiento de Debian 12 Bookworm,
este sábado 10
> > > > de Junio del 2023.
> > > >
> > > > Fuente oficial de la noticia:
> > > > https://wiki.debian.org/ReleasePartyBookworm
> > > Pues sale con 100 BUGS conocidos :-/
> > >
> > > https://www.phoronix.com/news/Debian-12-Next-Week
> > >
> > > Sugerencias a quien vaya a instalarlo:
> > >
> > > 1. Que espere a que salga la primera «point release» (un mes
más tarde)
> > > 2. Que LEA BIEN las notas de la versión para evitar sustos y
desastres
> > >
> > Hola
> > Que nos recomiendas para los que tenemos en los repositorios
puesto la
> > palabra stable en vez de bullseye
> > Gracias
>
> Si quieres mnatener la versión que tienes (Debian 11), cambia YA
los
> repos para que apunten a Bullseye.
>
> Si quieres actualizar a la nueva versión Bookworm (Debian 12),
hacer
> una copia de los datos que sean importantes y no quieras perder y
> seguir las indicaciones de las Notas de la versión:
>
> Chapter 4. Upgrades from Debian 11 (bullseye)
>

https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html
>
> Capítulo 4. Actualizaciones desde Debian 11 (bullseye)
>

https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.es.html
>
> Yo estoy con Debian 11, pero no voy a actualizar porque tengo
varios
> equipos y servidores y prefiero actualizar cada 4/5 años.
>
> Cuando tenga que «actualizar¹», lo que hago es lo siguiente:
>
> 1. Descargo una LiveCD de la versión de Debian que quiero instalar,
> y la cargo para descartar problemas con el hardware (mis equipos
son
> viejitos y el kernel puede ponerse farruco).
>
> 2. Si todo va bien, descargo la miniISO (para los servidores) y
el CD de
> instalación de XFCE (para estaciones de trabajo) e instalo la nueva
> versión de Debian desde cero, en una partición aparte.
>
> 3. Tras instalar todas las aplicaciones de nuevo, copio los
datos al nuevo
> sistema y listo.
>
> Ventajas: mínimos problemas de compatibilidad, tengo redundancia de
> datos y sistemas operativos.
>
> Inconvenientes: pierto el 50% de espacio en disco duro, ya que
siempre
> tengo dos sistemas operativos funcionales e independientes, pero
con el
> tamaño de los discos actuales casi que es mejor así, no me
gustan las
> particiones gordas en exceso. También en un sistema labrioso y
costoso
> en tiempo pero desde que uso Debian me ha funcionado sin problemas.
>
> ¹Yo nunca actualizo, instalo desde cero los sistemas operativos.
>
> Saludos,
>
> --
> Camaleón
>

Sólo informar que tengo un portatil ASUS br1100FKA (uno de esos
portàtiles educativos cautivo de M$).
En dicho portatil sólo pude ejectutar e instalar UBUNTU porque el
kernel de debian en sus imágenes de instalación no se llevaba bien
con la bios y algún componente y no llegaba ni tan solo al menu de
grub.
Ahora he probado la live de debian y he de decir que ha arrancado.
Puede que haya sido sólo la live y que cuando quiera hacer una
instalación resulte que no funciona, ya en su momento lo comentaré
(esperaré a que quiten esos 100 bugs que comentaba camaleon).
Pero ni la live debian-live-11.2.0-amd64-kde.iso ni el CD standard
de instalación llegaba a arrancar el grub y
debian-live-bkworm-DI-rc4-amd64-kde.iso sí que lo hace.

saludos
-- 




--
L.J.Marín
Usando: Debian Testing


--
*/Gerardo Braica
*/gbra...@gmail.com.ar
/*/*

Ligne de commande

[Simeone Dominique]

Chers amis,
comment ajouter à sources.list la nouvelle deb de Bookworm sans vim et en ligne 
de commande direct!
Bien à vous.

Mr.Dominique Simeone

Re: Pourquoi libreoffice-java-common et default-jre ne sont-ils pas des dépendances libreoffice ?

[benoit]

Le lundi 12 juin 2023 à 2:30 PM, Francois Mescam  a écrit :

> Je constate que le paquet libreoffice recommande le paquet 
> libreoffice-java-common donc si lors de l'installation de libreoffice il n'a 
> pas été choisi d'installer libreoffice-java-common c'est normal qu'il ne soit 
> pas installé.
>
> De plus libreoffice-calc ne dépend pas de libreoffice-java-common donc j'en 
> déduis que libreoffice-calc n'a pas besoin du java pour fonctionner 
> correctement. En revanche libreoffice-writer le suggère.
>
> Il me semble donc normal que libreoffice mette libreoffice-java-common en 
> recommande.
>
> C'est à celui qui installe un paquet de savoir quels paquets non obligatoires 
> il doit installer selon l'usage qui en sera fait.

Merci pour l'info
--
Benoit

for the adventurous: apt in readonly rootfs

[Smits Katze]

Debian wiki describes how to configure a read-only rootfs and how to
run apt and unattended-upgrades in such a filesystem:
https://wiki.debian.org/ReadonlyRoot

I would like to report that I am having considerable success with the
following simple command sequence:

sudo su -l
unshare -m
# in the new namespace, remount all
# filesystems writable that apt upgrade
# would want to write to
mount --bind /boot /boot
mount -o remount,rw /boot
mount --bind /usr /usr
mount -o remount,rw /usr
apt upgrade
exit

In particular, this avoids all problems with remounting back to
read-only afterwards, because processes in the original mount
namespace never get to see a writable filesystem.

The whole story is rather trivial, but anyways I wrote a small script
to make this more comfortable: https://github.com/smitsohu/rofairy

The script also verifies that remounting in the new mount namespace
does not inadvertently create writable locations in the original mount
namespace.

Maybe it helps someone. Also let me know if you hate it.
Thanks!

-- 
PGP: FF815935D964B268656B43DCB8037830D522909E

Re: Removing i386 architecture

[Sven Joachim]

On 2023-06-12 06:32 +0200, to...@tuxteam.de wrote:

> On Sun, Jun 11, 2023 at 09:27:11PM -0400, pa...@quillandmouse.com wrote:
>
> [...]
>
>> Nice try. However, this isn't allowed, as it would apparently remove
>> libcrypt1:i386, which is apparently a "system-critical" package. I'm
>> not sure how this could be system critical, since my original
>> installation was 64 bit. This begins to look like a reinstall, in order
>> to get my system "clean". Unless anyone has other ideas.
>
> This has even made it into a bug report [1]. It seems that just adding
> the --allow-remove-essential option is what you need.

The real bug is that removing libcrypt1 requires this option in the
first place[1].  I have just sent a reminder to fix that, but do not
assume it will make it into a Bookworm point release.

Cheers,
   Sven


1. https://bugs.debian.org/1024616

Re: bookworm upgrade report: boring

[Brian]

On Mon 12 Jun 2023 at 08:50:54 -0400, Celejar wrote:

> On Sun, 11 Jun 2023 12:31:31 -0400
> Dan Ritter  wrote:
> 
> > 
> > The machine I am typing on has been upgraded from bullseye to
> > bookworm. TL;DR: boring, which is good.
> 
> ...
> 
> > I read the release notes.
> > 
> > Changed sources.list entries.
> > 
> > Ran apt update.
> > 
> > I ran apt upgrade --without-new-pkgs before apt full-upgrade.
> > Then I rebooted.
> > 
> > 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 have taken to assuming that detected changes are due to my efforts
and reject the package version offered. Less stressful and speeds up
the installation. If necessary, I investigate afterwards.

-- 
Brian.

Re: bookworm upgrade report: boring

[Joe]

On Mon, 12 Jun 2023 08:50:54 -0400
Celejar  wrote:

> On Sun, 11 Jun 2023 12:31:31 -0400
> Dan Ritter  wrote:
> 
> > 
> > The machine I am typing on has been upgraded from bullseye to
> > bookworm. TL;DR: boring, which is good.  
> 
> ...
> 
> > I read the release notes.
> > 
> > Changed sources.list entries.
> > 
> > Ran apt update.
> > 
> > I ran apt upgrade --without-new-pkgs before apt full-upgrade.
> > Then I rebooted.
> > 
> > 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 :)
> 
>
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.

I've had more and more trouble with each version, so this time I'll be
fresh installing. I suppose it's less trouble with a workstation.

-- 
Joe

Re: Bookworm upgrade, usrmerge failure

[Sven Joachim]

On 2023-06-12 10:24 -0400, Greg Wooledge wrote:

> On Mon, Jun 12, 2023 at 09:45:15AM -0400, Greg Wooledge wrote:
>> I think I might try grabbing an older-than-buster version of debootstrap
>> out of snapshot.debian.org and see if I can manage to reproduce something.
>> But don't count on my success.
>
> I've succeeded in *partially* reproducing this error, but not fully.
> My resulting state simply has usrmerge failing with the OP's error
> message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
> giving the same error again.  I do not get the GLIBC errors, nor do I
> get an unusable system.
>
> Here's what I did:
>
> 1) Start from my bookworm amd64 system.
> 2) Install bullseye using debootstrap into /stuff/bullseye-base.
> 3) Copy that directory to /stuff/bullseye-with-old-debootstrap.
> 4) Chroot into bullseye-with-old-debootstrap and apt-get install debootstrap.
> 5) Download 
> http://snapshot.debian.org/archive/debian/20180603T165432Z/pool/main/d/debootstrap/debootstrap_1.0.101_all.deb
>  from outside the chroot.
> 6) Chroot into bullseye-with-old-debootstrap and dpkg -i 
> debootstrap_1.0.101_all.deb
> 7) Chroot into bullseye-with-old-debootstrap and debootstrap bullseye into 
> /bullseye2.
> 8) Move bullseye-with-old-debootstrap/bullseye2 to /stuff/bullseye-unmerged.
> 9) Verify that bullseye-unmerged has separate /bin and /lib directories.
> 10) Copy /stuff/bullseye-unmerged to /stuff/bullseye-upgrade-test.
> 11) Chroot into bullseye-upgrade-test and copy 
> /lib/x86_64-linux-gnu/libz.so.1.2.11 to /usr/lib/x86_64-linux-gnu/ and make 
> /usr/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11
> 12) Chroot into bullseye-upgrade-test and edit sources.list and apt-get 
> update and apt-get install usrmerge.
>
> And the resulting output:
>
> ===
> [...]
> Setting up usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
> /usr/lib/x86_64-linux-gnu/libz.so.1.2.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.

I guess the error message here could be improved, since to the many
users it is probably not obvious *how* to fix the problem.  Assume
convert-usrmerge reports something like this:

,
| Both /lib/x86_64-linux-gnu/foo and /usr/lib/x86_64-linux-gnu/foo exist.
`

Then run

$ dpkg -S /lib/x86_64-linux-gnu/foo /usr/lib/x86_64-linux-gnu/foo

Very likely the output will be something like this:

,
| bar: /lib/x86_64-linux-gnu/foo
| dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/foo
`

In other words, one of the duplicate files belongs to package bar, and
the other one is unknown to dpkg.  That one should be deleted or moved
out of the way, the other one left alone.

> root@unicorn:/# perl -e 'print "hello world\n"'
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> hello world
> root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").

FWIW, these messages are harmless.  The current locale is missing in the
chroot, and perl complains about that.  You will not see this during
package upgrades because Debian carries a patch to suppress it when
running perl from a maintainer script[1].

> The minimal debootstrap system has libidn2 (which is in /usr/lib/x*)
> but not libidn, so I wasn't able to reproduce the OP's setup faithfully.
> I figured using a copy of libz (which is in /lib/x*) might suffice.
>
> Has anyone else ever run into this before,

Not personally, but I suspect it might happen on a few old installations
that had been upgraded over the years.  Packages have moved libraries
from /usr/lib to /lib or vice versa, and for instance in the case of a
dpkg database corruption where the *.list file that belongs to a package
becomes empty dpkg will not remove the old files which now come to bite
you.  Such incidents might have happened 10 years ago without being
noticed.

So this problem falls into the "should not happen, but could happen"
category.

> or have any insight into how
> the OP's system became unusable as a result?

No, I do not see this.  In my book that falls into the "cannot happen"
category which is notoriously hard to reproduce or debug.

Cheers,
   Sven


1. 

Re: New open source project

[Gregory Seidman]

On Mon, Jun 12, 2023 at 12:26:35PM +0200, the2nd wrote:
> i am developing an open source OTP authentication server and currently
> searching for someone to test it. I hope its okay to ask for this on this
> list.
> 
> There is no documentation yet but i can write a step by step guide if
> someone is interested in testing my project.
[...]

No documentation is one thing, but no justification for why this is useful
or better than existing OTP options like otpw-bin and libpam-otpw means
that you aren't likely to find a lot of interest.

You did a thing, and you've announced it, but why should anyone care
(beyond the intellectual exercise) that you did it? This isn't to say it's
a waste or not worth doing, just that you haven't explained why it isn't.

> Regards
> the2nd
--Gregory

Re:

[Leo Marín]

Saludos lista,

pregunta random para no abrir otro hilo,
cambiaron el sourcelist? porque actualizo y veo esto; E: Repository '
http://security.debian.org/debian-security testing-security InRelease'
changed its 'Codename' value from 'bookworm-security' to 'trixie-security'

tiene 2 o 3 dias asi, no se si es temporal o ahora es obligatorio colocar
el nombre (trixie) para testing,

saldos y buen inicio de semana.

El jue, 8 jun 2023 a las 12:23, hubble () escribió:

> On Tue, 6 Jun 2023 09:29:57 +0200
> Camaleón  wrote:
>
> > El 2023-06-05 a las 21:30 +0100, José Manuel (Abogado) escribió:
> >
> > > El 5/6/23 a las 16:24, Camaleón escribió:
> > > > El 2023-06-05 a las 09:00 -0500, Eliecer Rangel escribió:
> > > >
> > > > > Esperando con ansías el lanzamiento de Debian 12 Bookworm, este
> sábado 10
> > > > > de Junio del 2023.
> > > > >
> > > > > Fuente oficial de la noticia:
> > > > > https://wiki.debian.org/ReleasePartyBookworm
> > > > Pues sale con 100 BUGS conocidos :-/
> > > >
> > > > https://www.phoronix.com/news/Debian-12-Next-Week
> > > >
> > > > Sugerencias a quien vaya a instalarlo:
> > > >
> > > > 1. Que espere a que salga la primera «point release» (un mes más
> tarde)
> > > > 2. Que LEA BIEN las notas de la versión para evitar sustos y
> desastres
> > > >
> > > Hola
> > > Que nos recomiendas para los que tenemos en los repositorios puesto la
> > > palabra stable en vez de bullseye
> > > Gracias
> >
> > Si quieres mnatener la versión que tienes (Debian 11), cambia YA los
> > repos para que apunten a Bullseye.
> >
> > Si quieres actualizar a la nueva versión Bookworm (Debian 12), hacer
> > una copia de los datos que sean importantes y no quieras perder y
> > seguir las indicaciones de las Notas de la versión:
> >
> > Chapter 4. Upgrades from Debian 11 (bullseye)
> >
> https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.en.html
> >
> > Capítulo 4. Actualizaciones desde Debian 11 (bullseye)
> >
> https://www.debian.org/releases/testing/amd64/release-notes/ch-upgrading.es.html
> >
> > Yo estoy con Debian 11, pero no voy a actualizar porque tengo varios
> > equipos y servidores y prefiero actualizar cada 4/5 años.
> >
> > Cuando tenga que «actualizar¹», lo que hago es lo siguiente:
> >
> > 1. Descargo una LiveCD de la versión de Debian que quiero instalar,
> > y la cargo para descartar problemas con el hardware (mis equipos son
> > viejitos y el kernel puede ponerse farruco).
> >
> > 2. Si todo va bien, descargo la miniISO (para los servidores) y el CD de
> > instalación de XFCE (para estaciones de trabajo) e instalo la nueva
> > versión de Debian desde cero, en una partición aparte.
> >
> > 3. Tras instalar todas las aplicaciones de nuevo, copio los datos al
> nuevo
> > sistema y listo.
> >
> > Ventajas: mínimos problemas de compatibilidad, tengo redundancia de
> > datos y sistemas operativos.
> >
> > Inconvenientes: pierto el 50% de espacio en disco duro, ya que siempre
> > tengo dos sistemas operativos funcionales e independientes, pero con el
> > tamaño de los discos actuales casi que es mejor así, no me gustan las
> > particiones gordas en exceso. También en un sistema labrioso y costoso
> > en tiempo pero desde que uso Debian me ha funcionado sin problemas.
> >
> > ¹Yo nunca actualizo, instalo desde cero los sistemas operativos.
> >
> > Saludos,
> >
> > --
> > Camaleón
> >
>
> Sólo informar que tengo un portatil ASUS br1100FKA (uno de esos portàtiles
> educativos cautivo de M$).
> En dicho portatil sólo pude ejectutar e instalar UBUNTU porque el kernel
> de debian en sus imágenes de instalación no se llevaba bien con la bios y
> algún componente y no llegaba ni tan solo al menu de grub.
> Ahora he probado la live de debian y he de decir que ha arrancado.
> Puede que haya sido sólo la live y que cuando quiera hacer una instalación
> resulte que no funciona, ya en su momento lo comentaré (esperaré a que
> quiten esos 100 bugs que comentaba camaleon).
> Pero ni la live debian-live-11.2.0-amd64-kde.iso ni el CD standard de
> instalación llegaba a arrancar el grub y
> debian-live-bkworm-DI-rc4-amd64-kde.iso sí que lo hace.
>
> saludos
> --
>
>

-- 
L.J.Marín
Usando: Debian Testing

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 09:45:15AM -0400, Greg Wooledge wrote:
> I think I might try grabbing an older-than-buster version of debootstrap
> out of snapshot.debian.org and see if I can manage to reproduce something.
> But don't count on my success.

I've succeeded in *partially* reproducing this error, but not fully.
My resulting state simply has usrmerge failing with the OP's error
message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
giving the same error again.  I do not get the GLIBC errors, nor do I
get an unusable system.

Here's what I did:

1) Start from my bookworm amd64 system.
2) Install bullseye using debootstrap into /stuff/bullseye-base.
3) Copy that directory to /stuff/bullseye-with-old-debootstrap.
4) Chroot into bullseye-with-old-debootstrap and apt-get install debootstrap.
5) Download 
http://snapshot.debian.org/archive/debian/20180603T165432Z/pool/main/d/debootstrap/debootstrap_1.0.101_all.deb
 from outside the chroot.
6) Chroot into bullseye-with-old-debootstrap and dpkg -i 
debootstrap_1.0.101_all.deb
7) Chroot into bullseye-with-old-debootstrap and debootstrap bullseye into 
/bullseye2.
8) Move bullseye-with-old-debootstrap/bullseye2 to /stuff/bullseye-unmerged.
9) Verify that bullseye-unmerged has separate /bin and /lib directories.
10) Copy /stuff/bullseye-unmerged to /stuff/bullseye-upgrade-test.
11) Chroot into bullseye-upgrade-test and copy 
/lib/x86_64-linux-gnu/libz.so.1.2.11 to /usr/lib/x86_64-linux-gnu/ and make 
/usr/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11
12) Chroot into bullseye-upgrade-test and edit sources.list and apt-get update 
and apt-get install usrmerge.

And the resulting output:

===
[...]
Setting up usrmerge (35) ...

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.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.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1
Processing triggers for libc-bin (2.36-9) ...
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@unicorn:/# perl -e 'print "hello world\n"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
hello world
root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.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.

root@unicorn:/# perl -e 'print "hello world\n"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
hello world
root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.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.

root@unicorn:/# 
===

The minimal debootstrap system has libidn2 (which is in /usr/lib/x*)
but not libidn, so I wasn't able to reproduce the OP's setup faithfully.
I figured using a copy of libz (which is in /lib/x*) might suffice.

Has anyone else ever run into this before, or have any insight into how
the OP's system became unusable as a result?

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
> 
> 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.

Well, that's somewhat terrifying.  I looked at bugs.debian.org/usrmerge
and didn't see any bugs like this already reported.

Next, I wondered about reproducing this with a minimal system.  So I
looked at debootstrap.  But as it turns out, debootstrap gives you a
system with an already-merged /usr, so it's not helpful in setting up
a minimal chroot-able system where we can try to reproduce the failure.

According to  one would need a version
of debootstrap between 1.0.87 and 1.0.101, and according to
 even buster has version 1.0.114.

I think I might try grabbing an older-than-buster version of debootstrap
out of snapshot.debian.org and see if I can manage to reproduce something.
But don't count on my success.

Re: bookworm upgrade report: boring

[Charles Curley]

On Mon, 12 Jun 2023 08:50:54 -0400
Celejar  wrote:

> 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 :)

Right.

I usually do upgrades with at least two terminals open on the subject
machine. One I use for the actual upgrade process. Another has Emacs
open and ready to use, and a third has a shell for general use.

During the upgrade, I select which configuration file to use, my edited
version or the maintainer's. I then use Emacs' ediff mode to compare
the two and update the config file. I have Emacs configured to preserve
the original file as a backup (foo~ for file foo). I do this as the
upgrade proceeds, which lets me concentrate on one file at a time.

It is usually fairly straightforward. Usually.

-- 
Does anybody read signatures any more?

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

Re: bookworm upgrade report: boring

[Celejar]

On Sun, 11 Jun 2023 12:31:31 -0400
Dan Ritter  wrote:

> 
> The machine I am typing on has been upgraded from bullseye to
> bookworm. TL;DR: boring, which is good.

...

> I read the release notes.
> 
> Changed sources.list entries.
> 
> Ran apt update.
> 
> I ran apt upgrade --without-new-pkgs before apt full-upgrade.
> Then I rebooted.
> 
> 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 :)

So far I've upgraded two Stable systems:

* A bare metal install, with a somewhat robust set of packages and
configuration. I mostly kept the the current configs like Dan did.

* A more minimal cloud VM, which pretty much just runs Nextloud through
Docker. I accepted the new sshd_config, but I manually switched
PermitRootLogin back on. (Pretty much everything I do on this machine
is done is root, so I don't bother logging in as a user and switching
to root.)

Both upgrades went quite smoothly.

-- 
Celejar

Debían 12

[Deiby Herrera]

Bienvenido a debían 12 me dijo luego de probar instalar la imagen ISO
oficial de debian dvd pero todas las demás me dieron error a la hora de
instalar el sistema base.hasta ahorita todo bien

Re: Pourquoi libreoffice-java-common et default-jre ne sont-ils pas des dépendances libreoffice ?

[Francois Mescam]

Je constate que le paquet libreoffice recommande le paquet 
libreoffice-java-common donc si lors de l'installation de libreoffice il 
n'a pas été choisi d'installer libreoffice-java-common c'est normal 
qu'il ne soit pas installé.


De plus libreoffice-calc ne dépend pas de libreoffice-java-common donc 
j'en déduis que libreoffice-calc n'a pas besoin du java pour fonctionner 
correctement. En revanche libreoffice-writer le suggère.


Il me semble donc normal que libreoffice mette libreoffice-java-common 
en recommande.


C'est à celui qui installe un paquet de savoir quels paquets non 
obligatoires il doit installer selon l'usage qui en sera fait.



Francois Mescam

Le 12/06/2023 à 12:58, benoit a écrit :

Bonjour à toutes et tous,

Je constate cette alerte quand je lance libreoffice

Warning: failed to launch javaldx - java may not function correctly

Il manque juste libreoffice-java-common et default-jre…

Quel intérêt de ne pas l’installer automatiquement en dépendance ?

Il faut lancer libreoffice dans un terminal pour voir cet avertissement…

--
Benoit

Re: Debian Trixie

[Rafael de Almeida]

Entendo quando a um lançamento o untable se torna testing... Então estava
pensando que seria da mesma forma quando o Debian stable foi lançando,
automaticamente o Debian unstable se tornaria testing. (Sempre gosto de
usar a versão testing)

Em seg., 12 de jun. de 2023 04:25, Leandro Cunha 
escreveu:

> Oi,
>
> On Sun, Jun 11, 2023 at 3:02 PM Lucas Castro 
> wrote:
> >
> >
> > Em 11/06/2023 13:36, Lucas Castro escreveu:
> >
> >
> > Em 11/06/2023 11:38, Rafael de Almeida escreveu:
> >
> > Bom dia!
> > O repositório do Debian Trixie ainda não foi atualizado? (testing)
> >
> > https://wiki.debian.org/DebianTrixie
> >
> > Acredito que você quis fazer referencia ao sid, que aponta a versão
> testing atual.
> >
> > Talvez seja necessário aguardar uma janela de tempo, pois o testing é
> atualizado a cada 5 dias.
> >
> > Não tenho certeza, mas acredito que pode acontecer das atualizações nas
> versões não ocorra no mesmo,
> >
> > por tanto, caso isso seja verdade, deve aguardar até a próxima
> atualização do testing.
> >
> > O debian bookworm foi lançado como stable no dia 10, ontem, por tanto,
> em no máxima (5-1) dias,
> >
> > é provável que a transição ocorra, levando em contato que 5 dias é a
> janela de atualização da  versão testing.
> >
> >
> >
> > --
> > Rafael de Almeida Matias
> > Especialista em Segurança da Informação
> > Tecnólogo em Redes de Computadores
> > Técnico em Informática
> > Currículo Lattes: https://goo.gl/RqclG4
> >
>
> Vamos com calma, tem pacotes que ainda estão no período de 5 dias
> (começa a contar após o upload) e alguns bloqueados por conta de bugs
> e creio que em alguns dias vamos ter uma porteira aberta.
> Por exemplo, do Firefox ESR em
> https://qa.debian.org/excuses.php?package=firefox-esr.
> Do git em https://qa.debian.org/excuses.php?package=git.
>
> Vocês podem acompanhar o status de testing (trixie) em dois meios:
> 1 - https://release.debian.org/britney/update_excuses.html
> 2 - https://lists.debian.org/debian-testing-changes
>
> --
> Cheers,
> Leandro Cunha
>

Pourquoi libreoffice-java-common et default-jre ne sont-ils pas des dépendances libreoffice ?

[benoit]

Bonjour à toutes et tous,

Je constate cette alerte quand je lance libreoffice

Warning: failed to launch javaldx - java may not function correctly

Il manque juste libreoffice-java-common et default-jre…

Quel intérêt de ne pas l’installer automatiquement en dépendance ?

Il faut lancer libreoffice dans un terminal pour voir cet avertissement…

--
Benoit

New open source project

[the2nd]

Hi,

i am developing an open source OTP authentication server and currently 
searching for someone to test it. I hope its okay to ask for this on 
this list.


There is no documentation yet but i can write a step by step guide if 
someone is interested in testing my project.


Installation instructions for debian bullseye can be found here: 
https://github.com/the2nd/otpme/blob/main/pip-install.sh



If someone knows a better place to ask for testers just let me know and 
ill give it a try.


Regards
the2nd

Bookworm upgrade, usrmerge failure

[Bastien Durel]

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 ;)

Regards,

-- 
Bastien

Bookwork upgrade fail with encrypted root

[Tixy]

Anyone with an encrypted root partition should probably follow the
advice in the NEWS for cryptsetup from the last release (buster) which
at the time said.

On systems which do rely on the initramfs integration, one can mark
'cryptsetup-initramfs' as being manually installed (so APT never
selects it for auto-removal) with the following command:

apt-mark manual cryptsetup-initramfs

My failure to do this caused cryptsetup-initramfs to become an
'obsolete' package in Aptitude which I didn't spot when cleaning the
these up after what I thought was a successful upgrade. This resulted
in an unbootable system.

I guess this shouldn't affect most people, it was the result of:

A) The cryptsetup package in Bookworm changing from depending on
cryptsetup-initramfs to just recommending it.

B) Me having APT configured to not install recommends.

Though thinking about this again as I write this, it seems that once a
recommended package is installed it shouldn't show up as 'obsolete'.
Note, I do have the config:

  APT::AutoRemove::SuggestsImportant "false";

But RecommendsImportant is left as the default (true).

Hmmm, perhaps I did something else to cause cryptsetup-initramfs to be
removed?

Either way, it seems safe advice to other people with an encrypted root
partition to mark the package as manually installed to help prevent
issues.

-- 
Tixy

Invitación a chat IRC APK #Revolution

[Eliecer Rangel]

Encontré un canal para hablar de manera más amigable que por correo, es un
chat IRC con la aplicación para dispositivos Android Revolution, soy de
Colombia y también está ubicado en Colombia; es oficial de Debian.

Este es el link para descargar la aplicación Revolution desde F-Droid:

https://f-droid.org/packages/io.mrarm.irc/


Este es el link para ingresar, sólo crean su nickname y listo.

Debian-CO

ircs://irc.oftc.net/debian-co

Re: Debian Trixie

[Leandro Cunha]

Oi,

On Sun, Jun 11, 2023 at 3:02 PM Lucas Castro  wrote:
>
>
> Em 11/06/2023 13:36, Lucas Castro escreveu:
>
>
> Em 11/06/2023 11:38, Rafael de Almeida escreveu:
>
> Bom dia!
> O repositório do Debian Trixie ainda não foi atualizado? (testing)
>
> https://wiki.debian.org/DebianTrixie
>
> Acredito que você quis fazer referencia ao sid, que aponta a versão testing 
> atual.
>
> Talvez seja necessário aguardar uma janela de tempo, pois o testing é 
> atualizado a cada 5 dias.
>
> Não tenho certeza, mas acredito que pode acontecer das atualizações nas 
> versões não ocorra no mesmo,
>
> por tanto, caso isso seja verdade, deve aguardar até a próxima atualização do 
> testing.
>
> O debian bookworm foi lançado como stable no dia 10, ontem, por tanto, em no 
> máxima (5-1) dias,
>
> é provável que a transição ocorra, levando em contato que 5 dias é a janela 
> de atualização da  versão testing.
>
>
>
> --
> Rafael de Almeida Matias
> Especialista em Segurança da Informação
> Tecnólogo em Redes de Computadores
> Técnico em Informática
> Currículo Lattes: https://goo.gl/RqclG4
>

Vamos com calma, tem pacotes que ainda estão no período de 5 dias
(começa a contar após o upload) e alguns bloqueados por conta de bugs
e creio que em alguns dias vamos ter uma porteira aberta.
Por exemplo, do Firefox ESR em
https://qa.debian.org/excuses.php?package=firefox-esr.
Do git em https://qa.debian.org/excuses.php?package=git.

Vocês podem acompanhar o status de testing (trixie) em dois meios:
1 - https://release.debian.org/britney/update_excuses.html
2 - https://lists.debian.org/debian-testing-changes

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Re: Debian home page -> Download link broken:

[Tixy]

On Sun, 2023-06-11 at 15:24 -0400, Jeffrey Walton wrote:
> On Sun, Jun 11, 2023 at 2:12 AM Tixy  wrote:
> > 
> > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote:
> > > Debian's wiki says to use apt-get:
> > > https://wiki.debian.org/DebianUpgrade. Also see
> > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html .
> > > 
> > > Maybe it's time for a complete refresh of those documents.
> > 
> > Or maybe the wiki page should be deleted, or just say go RTFM, i.e.
> > read the release notes for the release you want to upgrade to.
> 
> Tixy, I checked the manual at
> https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html
> . I cannot find the requirement to run 'apt upgrade'.
> 
> Can you provide a reference, please?

Sorry, I was referring to the release notes [1] not the Debian
Handbook.

I must admit that I didn't read the Wiki before now and to be fair it
does say at the beginning to go read the release notes before going on
to summarise the commands that you may need just using 'apt-get'.
Note that release notes for the past two releases say to use the 'apt'
command for everything, e.g.:

apt update
apt upgrade --without-new-pkgs
apt full-upgrade

And for making space and cleaning up:

apt autoremove
apt clean

I also see that the Debian Handbook says that before starting APT
related work to use 'apt update' and the release notes points out the
issue [2] that users of apt-get may need --allow-releaseinfo-change.

[1] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade
[2] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#updating-lists

-- 
Tixy

Re: Removing i386 architecture

[paulf]

On Mon, 12 Jun 2023 06:32:27 +0200
 wrote:

> On Sun, Jun 11, 2023 at 09:27:11PM -0400, pa...@quillandmouse.com
> wrote:
> 
> [...]
> 
> > Nice try. However, this isn't allowed, as it would apparently remove
> > libcrypt1:i386, which is apparently a "system-critical" package. I'm
> > not sure how this could be system critical, since my original
> > installation was 64 bit. This begins to look like a reinstall, in
> > order to get my system "clean". Unless anyone has other ideas.
> 
> This has even made it into a bug report [1]. It seems that just adding
> the --allow-remove-essential option is what you need.
> 
> Cheers
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001015;msg=7

Amazing, the bug reporter had virtually the same problem as I did.
Unfortunately, I decided to reinstall anyway. I accumulate cruft
(packages I install just to test and forget to uninstall), so I figured
a fresh install of Bookworm with just the packages I wanted would be
best.

In any case, thanks for your advice.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster