[gentoo-user] Fragile python update is wedged.

[gentoo-user] Fragile python update is wedged.

[Alan Mackenzie]

Hello, Gentoo.

I've just been trying the update for python 3.13.  It went well on my
new machine (well, after unmerging app-portage/unsymlink-lib, which was
debris from some 2019 update).

On my old machine, however, there was a seg fault while merging rust.
This is a known problem in certain first generation Ryzen processors.

However, this left the build wedged: emerge says that there's a circular
dependency from rust to itself.  More precisely, the error message looks
like:

#########################################################################

[ebuild  NS    ] dev-lang/rust-1.85.1:1.85.1::gentoo [1.81.0-r100:1.81.0::gentoo, 1.82.0-r101:1.82.0::gentoo, 1.83.0-r2:1.83.0::gentoo, 1.84.1-r1:1.84.1::gentoo] USE="(-big-endian) -clippy -debug -dist -doc (-llvm-libunwind) -lto -rust-analyzer -rust-src -rustfmt (-system-llvm) -test -verify-sig -wasm (-miri%) (-nightly%) (-parallel-compiler%)" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="(19)" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARC -ARM -AVR -BPF -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -SPIRV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa" 0 KiB

Total: 1 package (1 in new slot), Size of downloads: 0 KiB

 * Error: circular dependencies:

(dev-lang/rust-1.85.1:1.85.1/1.85.1::gentoo, ebuild scheduled for merge) depends on
 (dev-lang/rust-1.85.1:1.85.1/1.85.1::gentoo, ebuild scheduled for merge) (buildtime)

 * Note that circular dependencies can often be avoided by temporarily
 * disabling USE flags that trigger optional dependencies.

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-python/gpep517:0

#########################################################################

(and so on).

This would appear to be a bug in the rust ebuild - it has set itself as a
builtime dependency before it had been built - or something like that.

How do I best recover from this?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Fragile python update is wedged.

[Pramod V U]

You need a rust compiler to compile rust's own rust compiler.

You either need dev-lang/rust-bin, a package with binaries... Either just use it or compile the main rust package for use.

If that's a problem. dev-lang/mrustc is another compiler for rust, written in C/C++. It has been written specifically for this purpose of compiling rust's own rust compiler.

Kind regards,
Pramod

Re: [gentoo-user] Fragile rust update is wedged. (Was: Fragile python update is wedged.)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2025 bytes --]

On 5/2/25 1:07 PM, Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> I've just been trying the update for python 3.13.  It went well on my
> new machine (well, after unmerging app-portage/unsymlink-lib, which was
> debris from some 2019 update).
> 
> On my old machine, however, there was a seg fault while merging rust.
> This is a known problem in certain first generation Ryzen processors.
> 
> However, this left the build wedged: emerge says that there's a circular
> dependency from rust to itself.  More precisely, the error message looks
> like:


This is clearly not a python update, then.


> This would appear to be a bug in the rust ebuild - it has set itself as a
> builtime dependency before it had been built - or something like that.
> 
> How do I best recover from this?


It is not a bug in the rust ebuild -- the rust ebuild has always,
always, always depended on itself. In the past, the rust ebuild silently
downloaded a temporary copy of dev-lang/rust-bin to work around this.

This was changed in November 2024.

The rust compiler is written in the rust programming language, using
bleeding-edge features of the most recent version of rust. They are
aware that this is a bootstrap problem and don't consider it a problem,
because rust is officially installed by downloading prebuilt binaries
into $HOME.

Compiling rust officially requires building the pre 1.0 version of rust,
itself written in ocaml, and then building *every* version of rust since
then, one by one, in turn, without skipping a single one. That is over
80 different versions of rust, you need to compile all of them in order
to get to the current one.

On amd64, you can use the unofficial dev-lang/mrustc (third-party
reimplementation of rust written in C++) which allows you to skip all
the way to rust 1.74, and from there it is "only" 13 or so versions to
build.

Or, you may use rust-bin. Alternatively, you may use:

```
emerge --getbinpkg dev-lang/rust
```


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile rust update is wedged.

[Alan Mackenzie]

Hello, Eli.

On Fri, May 02, 2025 at 13:47:02 -0400, Eli Schwartz wrote:
> On 5/2/25 1:07 PM, Alan Mackenzie wrote:
> > Hello, Gentoo.

> > I've just been trying the update for python 3.13.  It went well on my
> > new machine (well, after unmerging app-portage/unsymlink-lib, which was
> > debris from some 2019 update).

> > On my old machine, however, there was a seg fault while merging rust.
> > This is a known problem in certain first generation Ryzen processors.

> > However, this left the build wedged: emerge says that there's a circular
> > dependency from rust to itself.  More precisely, the error message looks
> > like:


> This is clearly not a python update, then.

Well, it was.  ;-)

> > This would appear to be a bug in the rust ebuild - it has set itself as a
> > builtime dependency before it had been built - or something like that.

> > How do I best recover from this?


> It is not a bug in the rust ebuild -- the rust ebuild has always,
> always, always depended on itself. In the past, the rust ebuild silently
> downloaded a temporary copy of dev-lang/rust-bin to work around this.

I disagree.  By attempting this emerging of rust, and failing, some
persistent information indicating this dependency has been created.  This
persistent information, wherever it is, should not have been created, or
it should have been removed on the emerge failure.

> This was changed in November 2024.

Hmmm...  OK.

> The rust compiler is written in the rust programming language, using
> bleeding-edge features of the most recent version of rust. They are
> aware that this is a bootstrap problem and don't consider it a problem,
> because rust is officially installed by downloading prebuilt binaries
> into $HOME.

This sounds bad, but how is it different from C and C++ in GCC?

> Compiling rust officially requires building the pre 1.0 version of rust,
> itself written in ocaml, and then building *every* version of rust since
> then, one by one, in turn, without skipping a single one. That is over
> 80 different versions of rust, you need to compile all of them in order
> to get to the current one.

No thanks!  There's only so much time left before the Sun becomes a red
giant.  But this attitude must limit the portability of rust to different
processors, such as are found in embedded systems.

> On amd64, you can use the unofficial dev-lang/mrustc (third-party
> reimplementation of rust written in C++) which allows you to skip all
> the way to rust 1.74, and from there it is "only" 13 or so versions to
> build.

Doesn't sound much like a solution.

> Or, you may use rust-bin. Alternatively, you may use:

> ```
> emerge --getbinpkg dev-lang/rust
> ```

I think I'll be going for rust-bin.  This is quite new in Gentoo (in the
last few years, at any rate), but I couldn't find the news item about it
I vaguely remember reading.

Hopefully there's nothing tricky about moving from package foo to
foo-bin.

And then I can, hopefully, finish the update of the python stuff.  Though
I would classify it as a design bug that all python programs need to be
rebuilt just because there's a minor version update in python itself.  We
don't need to do this when a new version of GCC comes out.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Fragile rust update is wedged.

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 5234 bytes --]

On 5/2/25 3:07 PM, Alan Mackenzie wrote:
> Hello, Eli.
> 
> On Fri, May 02, 2025 at 13:47:02 -0400, Eli Schwartz wrote:
>> On 5/2/25 1:07 PM, Alan Mackenzie wrote:
>>> Hello, Gentoo.
> 
>>> I've just been trying the update for python 3.13.  It went well on my
>>> new machine (well, after unmerging app-portage/unsymlink-lib, which was
>>> debris from some 2019 update).
> 
>>> On my old machine, however, there was a seg fault while merging rust.
>>> This is a known problem in certain first generation Ryzen processors.
> 
>>> However, this left the build wedged: emerge says that there's a circular
>>> dependency from rust to itself.  More precisely, the error message looks
>>> like:
> 
> 
>> This is clearly not a python update, then.
> 
> Well, it was.  ;-)


Your saying that it was, doesn't make it the case. So you can repeat a
false claim if you want -- or explain why you think it is true.



>>> This would appear to be a bug in the rust ebuild - it has set itself as a
>>> builtime dependency before it had been built - or something like that.
> 
>>> How do I best recover from this?
> 
> 
>> It is not a bug in the rust ebuild -- the rust ebuild has always,
>> always, always depended on itself. In the past, the rust ebuild silently
>> downloaded a temporary copy of dev-lang/rust-bin to work around this.
> 
> I disagree.  By attempting this emerging of rust, and failing, some
> persistent information indicating this dependency has been created.  This
> persistent information, wherever it is, should not have been created, or
> it should have been removed on the emerge failure.


Since you do not know what this "persistent information" is, I assert in
response that it doesn't exist, therefore it hasn't been created.

If you are nonetheless certain that it exists, you are welcome to
explain what "it" is and where I can find it.


>> This was changed in November 2024.
> 
> Hmmm...  OK.
> 
>> The rust compiler is written in the rust programming language, using
>> bleeding-edge features of the most recent version of rust. They are
>> aware that this is a bootstrap problem and don't consider it a problem,
>> because rust is officially installed by downloading prebuilt binaries
>> into $HOME.
> 
> This sounds bad, but how is it different from C and C++ in GCC?


Because:
- GCC 15 can be compiled with GCC 5.4
- GCC 11 - 14 can be compiled with GCC 4.8.3
- GCC 4.8 - 10 can be compiled with a C++98 compiler
- GCC 4.7 can be compiled with a C compiler

The bootstrappable.org project uses TinyCC to build GCC 2.95.0, which
then builds GCC 4.7.4, which gives you a very nearly C++11 compiler.

It takes you 4 hops from TinyCC to GCC 15, which is a quarter of a
decade of technology.

For rust, the best bootstrap we have is unofficial -- mrustc -- and
relies on first bootstrapping GCC with 4 hops, then compiling 13
versions of Rust released between December 2023 and today. And that's
our hack to avoid building 80 versions released over the course of 10
years (rust 1.0 was released on May 15, 2015).


>> Compiling rust officially requires building the pre 1.0 version of rust,
>> itself written in ocaml, and then building *every* version of rust since
>> then, one by one, in turn, without skipping a single one. That is over
>> 80 different versions of rust, you need to compile all of them in order
>> to get to the current one.
> 
> No thanks!  There's only so much time left before the Sun becomes a red
> giant.  But this attitude must limit the portability of rust to different
> processors, such as are found in embedded systems.
> 
>> On amd64, you can use the unofficial dev-lang/mrustc (third-party
>> reimplementation of rust written in C++) which allows you to skip all
>> the way to rust 1.74, and from there it is "only" 13 or so versions to
>> build.
> 
> Doesn't sound much like a solution.


You're entirely correct. The upstream rust developers imposed this
constraint.


>> Or, you may use rust-bin. Alternatively, you may use:
> 
>> ```
>> emerge --getbinpkg dev-lang/rust
>> ```
> 
> I think I'll be going for rust-bin.  This is quite new in Gentoo (in the
> last few years, at any rate), but I couldn't find the news item about it
> I vaguely remember reading.
> 
> Hopefully there's nothing tricky about moving from package foo to
> foo-bin.
> 
> And then I can, hopefully, finish the update of the python stuff.  Though
> I would classify it as a design bug that all python programs need to be
> rebuilt just because there's a minor version update in python itself.  We
> don't need to do this when a new version of GCC comes out.


It's not a minor version update in python itself. Python doesn't really
use semver.

GCC, and in general, C/C++, tend to take this sort of compatibility a
lot more serious than other languages. e.g. rust and golang simply
statically compile, and that's why @rust-rebuild and @golang-rebuild
exist. Ruby has to be rebuilt on version updates just like python. Zig
software only ever supports a single version of the compiler, and has to
be rewritten in tandem with the compiler upgrade.



-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Alan Mackenzie]

Hello, Eli.

On Fri, May 02, 2025 at 16:07:17 -0400, Eli Schwartz wrote:
> On 5/2/25 3:07 PM, Alan Mackenzie wrote:
> > On Fri, May 02, 2025 at 13:47:02 -0400, Eli Schwartz wrote:
> >> On 5/2/25 1:07 PM, Alan Mackenzie wrote:
> >>> I've just been trying the update for python 3.13.  It went well on my
> >>> new machine (well, after unmerging app-portage/unsymlink-lib, which was
> >>> debris from some 2019 update).

> >>> On my old machine, however, there was a seg fault while merging rust.
> >>> This is a known problem in certain first generation Ryzen processors.

> >>> However, this left the build wedged: emerge says that there's a circular
> >>> dependency from rust to itself.  More precisely, the error message looks
> >>> like:


> >> This is clearly not a python update, then.

> > Well, it was.  ;-)

> Your saying that it was, doesn't make it the case. So you can repeat a
> false claim if you want -- or explain why you think it is true.

It was an update.  It was for the purpose of replacing python 3.12 with
python 3.13.  Thus it was a python update.

> >>> This would appear to be a bug in the rust ebuild - it has set itself as a
> >>> builtime dependency before it had been built - or something like that.

> >>> How do I best recover from this?


> >> It is not a bug in the rust ebuild -- the rust ebuild has always,
> >> always, always depended on itself. In the past, the rust ebuild silently
> >> downloaded a temporary copy of dev-lang/rust-bin to work around this.

> > I disagree.  By attempting this emerging of rust, and failing, some
> > persistent information indicating this dependency has been created.  This
> > persistent information, wherever it is, should not have been created, or
> > it should have been removed on the emerge failure.


> Since you do not know what this "persistent information" is, I assert in
> response that it doesn't exist, therefore it hasn't been created.

Well, thanks for being so generous and understanding.

At the start of this python update, I was able to start emerge, which
carried on until the seg fault part way through emerging rust.

On attempting to restart the python update, portage reported a "circular
dependency" in rust and failed to build any packages.

Some persistent information thus clearly differed between these two
attempts.  I don't know what was changed, and I shouldn't have to find
out, being a user of emerge, not a maintainer.

> If you are nonetheless certain that it exists, you are welcome to
> explain what "it" is and where I can find it.

See above.

> >> This was changed in November 2024.

> > Hmmm...  OK.

> >> The rust compiler is written in the rust programming language, using
> >> bleeding-edge features of the most recent version of rust. They are
> >> aware that this is a bootstrap problem and don't consider it a problem,
> >> because rust is officially installed by downloading prebuilt binaries
> >> into $HOME.

> > This sounds bad, but how is it different from C and C++ in GCC?


> Because:
> - GCC 15 can be compiled with GCC 5.4
> - GCC 11 - 14 can be compiled with GCC 4.8.3
> - GCC 4.8 - 10 can be compiled with a C++98 compiler
> - GCC 4.7 can be compiled with a C compiler

> The bootstrappable.org project uses TinyCC to build GCC 2.95.0, which
> then builds GCC 4.7.4, which gives you a very nearly C++11 compiler.

> It takes you 4 hops from TinyCC to GCC 15, which is a quarter of a
> decade of technology.

?Quarter of a century, perhaps?

OK, thanks.  That was more or less what I suspected.  GCC was at the
heart of the GNU project right from the beginning, and having people able
to build it easily was always important.  I'm glad that's still the case.

> For rust, the best bootstrap we have is unofficial -- mrustc -- and
> relies on first bootstrapping GCC with 4 hops, then compiling 13
> versions of Rust released between December 2023 and today. And that's
> our hack to avoid building 80 versions released over the course of 10
> years (rust 1.0 was released on May 15, 2015).

Somehow that feels like it's pushing the definition of free software in a
direction it was never intended to go.

> >> Compiling rust officially requires building the pre 1.0 version of rust,
> >> itself written in ocaml, and then building *every* version of rust since
> >> then, one by one, in turn, without skipping a single one. That is over
> >> 80 different versions of rust, you need to compile all of them in order
> >> to get to the current one.

> > No thanks!  There's only so much time left before the Sun becomes a red
> > giant.  But this attitude must limit the portability of rust to different
> > processors, such as are found in embedded systems.

> >> On amd64, you can use the unofficial dev-lang/mrustc (third-party
> >> reimplementation of rust written in C++) which allows you to skip all
> >> the way to rust 1.74, and from there it is "only" 13 or so versions to
> >> build.

> > Doesn't sound much like a solution.


> You're entirely correct. The upstream rust developers imposed this
> constraint.

If that's the way they see things, it would seem that having a project
dependent on rust should figure high on that project's risk list.

> >> Or, you may use rust-bin. Alternatively, you may use:

> >> ```
> >> emerge --getbinpkg dev-lang/rust
> >> ```

> > I think I'll be going for rust-bin.  This is quite new in Gentoo (in the
> > last few years, at any rate), but I couldn't find the news item about it
> > I vaguely remember reading.

> > Hopefully there's nothing tricky about moving from package foo to
> > foo-bin.

> > And then I can, hopefully, finish the update of the python stuff.  Though
> > I would classify it as a design bug that all python programs need to be
> > rebuilt just because there's a minor version update in python itself.  We
> > don't need to do this when a new version of GCC comes out.


> It's not a minor version update in python itself. Python doesn't really
> use semver.

Use what?

> GCC, and in general, C/C++, tend to take this sort of compatibility a
> lot more serious than other languages. e.g. rust and golang simply
> statically compile, and that's why @rust-rebuild and @golang-rebuild
> exist. Ruby has to be rebuilt on version updates just like python. Zig
> software only ever supports a single version of the compiler, and has to
> be rewritten in tandem with the compiler upgrade.

Thank goodness for C!

Anyhow, my old machine is now in an unusable state.  When I repeat the
emerge incantation from the news item, emerge fails with obscure messages
about conflicting package versions.  These messages take several hours to
parse and understand, being basically dumps of the internal state of
emerge.

One way or another, I'll get that machine back in working order.  But I
can't help thinking it shouldn't be this difficult, even in Gentoo.

I think my first summary of my problem was fair: The python update scheme
is fragile.  In particular if the emerge is interrupted for any reason,
it cannot be restarted, and cannot be reverted to a workable state,
without a great deal of time and expert knowledge.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Wol]

On 02/05/2025 22:15, Alan Mackenzie wrote:
> I think my first summary of my problem was fair: The python update scheme
> is fragile.  In particular if the emerge is interrupted for any reason,
> it cannot be restarted, and cannot be reverted to a workable state,
> without a great deal of time and expert knowledge.

Just don't blame that on gentoo. Python is notorious for being a 
"dangerous" language. Look at the mess with the Python 2 -> 3 upgrade.

You said a project using Rust should assume that is a serious risk 
factor. I suspect any project using Python should assume that is an even 
bigger risk factor ... the fact that emerge is written in Python should 
be seen as very risky!

Cheers,
Wol

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Jay Faulkner]

On 5/2/25 2:15 PM, Alan Mackenzie wrote:
> If that's the way they see things, it would seem that having a project
> dependent on rust should figure high on that project's risk list.

This is ... a non-actionable take, regardless of if I agree with it or not.

Do you expect Gentoo to replace Firefox? pycryptography? a heavily used 
SVG library? kernel drivers for interesting (really, mac) hardware? 
There's only so much that the downstream distribution has control over, 
and I appreciate that Gentoo, generally, has accepted that the state of 
the world is that rust can't easily be avoided.

There are a bunch of volunteers keeping the lights on, navigating some 
of these pitfalls -- even though they themselves might actually agree 
with you -- because they represent the reality of the OSS landscape.

...but complaining about it here is unlikely to actually change 
anything, and only dishearten the folks who are trying to keep it all 
working. It's nicer to focus our mental energy and time on changes that 
are achievable as a project -- or specific, fixable technical issues, 
like the wedged install this started with (and the reply with direct 
information on how to fix it).


My $.02,

JayF

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Alan Mackenzie]

Hello, Jay.

On Fri, May 02, 2025 at 14:44:06 -0700, Jay Faulkner wrote:

> On 5/2/25 2:15 PM, Alan Mackenzie wrote:
> > If that's the way they see things, it would seem that having a project
> > dependent on rust should figure high on that project's risk list.

> This is ... a non-actionable take, regardless of if I agree with it or not.

OK.

> Do you expect Gentoo to replace Firefox? pycryptography? a heavily used 
> SVG library? kernel drivers for interesting (really, mac) hardware? 
> There's only so much that the downstream distribution has control over, 
> and I appreciate that Gentoo, generally, has accepted that the state of 
> the world is that rust can't easily be avoided.

No, I don't expect any of the above.

I was thinking more as a putative project manager at the start of, say, a
project to design and produce a device with embedded software.  The
question would arise as to what language to program it in.  Rust would
likely be a contender.  But if it were up to me, I'd veto it.  The
language isn't stable, doesn't have a standards body (such as ISO)
defining it, there is only one compiler, there aren't that many
competent practitioners, and so on.  Add to that the difficulty of
recreating an up to date compiler if the current infrastructure
collapsed for any reason, then I think it fair to say that current users
of rust are courageous.

None of this has anything to do with Gentoo, really, it's just a
tangent.

> There are a bunch of volunteers keeping the lights on, navigating some 
> of these pitfalls -- even though they themselves might actually agree 
> with you -- because they represent the reality of the OSS landscape.

> ...but complaining about it here is unlikely to actually change 
> anything, and only dishearten the folks who are trying to keep it all 
> working. It's nicer to focus our mental energy and time on changes that 
> are achievable as a project -- or specific, fixable technical issues, 
> like the wedged install this started with (and the reply with direct 
> information on how to fix it).

I wasn't wanting to dishearten anybody.  Apologies for doing so
unintentionally.

> My $.02,

> JayF

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Jay Faulkner]

On 5/2/25 3:17 PM, Alan Mackenzie wrote:
> None of this has anything to do with Gentoo, really, it's just a
> tangent.

:) Yeah, fair enough for sure! I read that "a project" in the original 
email as a backhanded reference to Gentoo itself. I'm friends with a 
handful of folks who have been (unfairly, imo) roasted for introducing 
python libraries so I am a bit trigger happy on trying to jump in front 
of potential flames (so to speak).

-JayF

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4348 bytes --]

On 5/2/25 5:15 PM, Alan Mackenzie wrote:
>>>> This is clearly not a python update, then.
> 
>>> Well, it was.  ;-)
> 
>> Your saying that it was, doesn't make it the case. So you can repeat a
>> false claim if you want -- or explain why you think it is true.
> 
> It was an update.  It was for the purpose of replacing python 3.12 with
> python 3.13.  Thus it was a python update.


I am quite certain that at least once before in your life, while using
Gentoo, you have encountered a system update that had two different
updates for unrelated software, which were both ready at the same time.

https://en.wikipedia.org/wiki/Correlation_does_not_imply_causation


>> The bootstrappable.org project uses TinyCC to build GCC 2.95.0, which
>> then builds GCC 4.7.4, which gives you a very nearly C++11 compiler.
> 
>> It takes you 4 hops from TinyCC to GCC 15, which is a quarter of a
>> decade of technology.
> 
> ?Quarter of a century, perhaps?


Oops, typo. :)


> OK, thanks.  That was more or less what I suspected.  GCC was at the
> heart of the GNU project right from the beginning, and having people able
> to build it easily was always important.  I'm glad that's still the case.
> 
>> For rust, the best bootstrap we have is unofficial -- mrustc -- and
>> relies on first bootstrapping GCC with 4 hops, then compiling 13
>> versions of Rust released between December 2023 and today. And that's
>> our hack to avoid building 80 versions released over the course of 10
>> years (rust 1.0 was released on May 15, 2015).
> 
> Somehow that feels like it's pushing the definition of free software in a
> direction it was never intended to go.


Well, the rust developers do say that rust itself has "no warranty of
any kind, express or implied, including but not limited to the warranty
of fitness for a particular purpose". :)

So perhaps they are leaning into that -- rust is provided without a
guarantee that it is fit for installing on your system.


>> It's not a minor version update in python itself. Python doesn't really
>> use semver.
> 
> Use what?


Semantic Versioning (semver) is the rule that says "version 1.5 and
version 2.0 of software are a major version update. Version 1.5 and
version 1.6 is just a minor update, so not a lot changed probably, and
it should still be compatible".



>> GCC, and in general, C/C++, tend to take this sort of compatibility a
>> lot more serious than other languages. e.g. rust and golang simply
>> statically compile, and that's why @rust-rebuild and @golang-rebuild
>> exist. Ruby has to be rebuilt on version updates just like python. Zig
>> software only ever supports a single version of the compiler, and has to
>> be rewritten in tandem with the compiler upgrade.
> 
> Thank goodness for C!
> 
> Anyhow, my old machine is now in an unusable state.  When I repeat the
> emerge incantation from the news item, emerge fails with obscure messages
> about conflicting package versions.  These messages take several hours to
> parse and understand, being basically dumps of the internal state of
> emerge.
> 
> One way or another, I'll get that machine back in working order.  But I
> can't help thinking it shouldn't be this difficult, even in Gentoo.
> 
> I think my first summary of my problem was fair: The python update scheme
> is fragile.  In particular if the emerge is interrupted for any reason,
> it cannot be restarted, and cannot be reverted to a workable state,
> without a great deal of time and expert knowledge.


Maybe it would help to know the exact command you used, and the full
output? If it's quite long, include it as an email attachment or use a
pastebin.

I hope you did not use

```
emerge --resume
```

at least. Because that option is far too broken to ever be used, in my
experience, besides for having no useful purpose.

Also note:
"emerge fails with obscure messages about conflicting package versions"

The news item did suggest a "safe" upgrade approach that takes longer
but is, well, safer.

It's also possible to greatly simplify large upgrades using emerge
--getbinpkg, or, it would if not for the fact that the Gentoo Binhost
has been working for two days now to finish building the binaries so it
can publish them. :(


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Alan Mackenzie]

Hello, Eli.

[ Added in some hours after writing the main bit below ]

I've managed to solve my problem.  In the error output from emerge there
was a message about having to update some configuration files.  Normally
this message just means "we advise you to get around to this sometime"
but this time it meant "your emerge will be broken until you do this".

So a quick dispatch-conf later, which inserted an atom spec into some
config file (I've forgotten which), and emerge was able to run.  Just
under two hours later it was complete.

So thanks for all the help!

On Fri, May 02, 2025 at 17:56:46 -0400, Eli Schwartz wrote:
> On 5/2/25 5:15 PM, Alan Mackenzie wrote:

[ .... ]

> > Anyhow, my old machine is now in an unusable state.  When I repeat the
> > emerge incantation from the news item, emerge fails with obscure messages
> > about conflicting package versions.  These messages take several hours to
> > parse and understand, being basically dumps of the internal state of
> > emerge.

> > One way or another, I'll get that machine back in working order.  But I
> > can't help thinking it shouldn't be this difficult, even in Gentoo.

> > I think my first summary of my problem was fair: The python update scheme
> > is fragile.  In particular if the emerge is interrupted for any reason,
> > it cannot be restarted, and cannot be reverted to a workable state,
> > without a great deal of time and expert knowledge.

> Maybe it would help to know the exact command you used, and the full
> output? If it's quite long, include it as an email attachment or use a
> pastebin.

The command I used was:

# time emerge -1avUD @world

After a lot of error messages (see below), I got the following obscure
message:

!!! All ebuilds that could satisfy ">=dev-python/installer-0.5.0[python_targets_pypy3_11(-)?,python_targets_python3_13t(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?]" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-python/installer-0.7.0::gentoo (masked by: )

(dependency required by "dev-python/gpep517-17::gentoo" [installed])
(dependency required by "dev-python/setuptools-78.1.0::gentoo" [installed])
(dependency required by "dev-python/setuptools-scm-8.2.1::gentoo[-test]" [installed])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

On the line beginning "!!! All ebuilds ..." I do not understand what has
been written.  What do the square brackets mean?  What does the several
times repeated incantation "(-)?" mean?

I can't parse the "(masked by: )".  Is it saying that installer-0.7.0 is
masked by "(dependency required by ...)".  What would that even mean?
There are too few finite verbs in this message.

Where is this output documented?  It is not documented in the MASKED
PACKAGES section of the emerge man page, or in the Gentoo Handbook, at
least as far as I could find.

It would appear that dev-python/installer-0.7.0 should satisfy the
dependencies.  But it doesn't.  It is currently installed.

> I hope you did not use

> ```
> emerge --resume
> ```

> at least. Because that option is far too broken to ever be used, in my
> experience, besides for having no useful purpose.

Yes I did indeed use emerge --resume.  It usually works for me when an
emerge operation is interrupted by a sporadic seg fault.

> Also note:
> "emerge fails with obscure messages about conflicting package versions"

> The news item did suggest a "safe" upgrade approach that takes longer
> but is, well, safer.

Safer than what?  There was no guidance in the news item as to what the
dangers might be, or when the safer upgrade option is recommended.

> It's also possible to greatly simplify large upgrades using emerge
> --getbinpkg, or, it would if not for the fact that the Gentoo Binhost
> has been working for two days now to finish building the binaries so it
> can publish them. :(

Anyhow, here's the full output of the command

# time emerge -1avUD @world > ~acm/rust-bug.20250504b.txt 2>&1:

#########################################################################
[ Removed, due to me having solved the problem. ]
#########################################################################

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Fragile python update is wedged [Was: Fragile rust update is wedged].

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4448 bytes --]

On 5/4/25 12:41 PM, Alan Mackenzie wrote:
> Hello, Eli.
> 
> [ Added in some hours after writing the main bit below ]
> 
> I've managed to solve my problem.  In the error output from emerge there
> was a message about having to update some configuration files.  Normally
> this message just means "we advise you to get around to this sometime"
> but this time it meant "your emerge will be broken until you do this".
> 
> So a quick dispatch-conf later, which inserted an atom spec into some
> config file (I've forgotten which), and emerge was able to run.  Just
> under two hours later it was complete.
> 
> So thanks for all the help!


:) that does happen, yes.

>> Maybe it would help to know the exact command you used, and the full
>> output? If it's quite long, include it as an email attachment or use a
>> pastebin.
> 
> The command I used was:
> 
> # time emerge -1avUD @world
> 
> After a lot of error messages (see below), I got the following obscure
> message:
> 
> !!! All ebuilds that could satisfy ">=dev-python/installer-0.5.0[python_targets_pypy3_11(-)?,python_targets_python3_13t(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?]" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - dev-python/installer-0.7.0::gentoo (masked by: )
> 
> (dependency required by "dev-python/gpep517-17::gentoo" [installed])
> (dependency required by "dev-python/setuptools-78.1.0::gentoo" [installed])
> (dependency required by "dev-python/setuptools-scm-8.2.1::gentoo[-test]" [installed])
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.
> 
> On the line beginning "!!! All ebuilds ..." I do not understand what has
> been written.  What do the square brackets mean?  What does the several
> times repeated incantation "(-)?" mean?


The square brackets mean that it needs the package to be installed with
specific USE flags. The (-) means that if the package does NOT support
that USE flag at all, whether set or unset, then it is equal to having
the USE flag with the "unset" value.

This is the same format used to describe a dependency inside a *.ebuild
file.

See also "man 5 ebuild" under:

- Atom USE

- Atom USE defaults


> I can't parse the "(masked by: )".  Is it saying that installer-0.7.0 is
> masked by "(dependency required by ...)".  What would that even mean?
> There are too few finite verbs in this message.


I believe this means, masked by the package as required not existing at
all (due to USE flags).


> Where is this output documented?  It is not documented in the MASKED
> PACKAGES section of the emerge man page, or in the Gentoo Handbook, at
> least as far as I could find.


Dunno about that, sorry. :)


>> Also note:
>> "emerge fails with obscure messages about conflicting package versions"
> 
>> The news item did suggest a "safe" upgrade approach that takes longer
>> but is, well, safer.
> 
> Safer than what?  There was no guidance in the news item as to what the
> dangers might be, or when the safer upgrade option is recommended.


The upgrade added a USE flag to a large number of packages, and removed
a different USE flag.

If your system is in a state where some packages depend on the removed
USE flag, you can hit issues. Simply adding a USE flag is "safer".

If some packages depend on the removed USE flag, but will be rebuilt by
portage to stop depending on that USE flag, then it's safer to add a USE
flag to all packages, get your system into a consistent state, then
remove the other USE flag from all those packages, since now you have
the new version of all those packages safely installed and the unneeded
bits aren't used by anything anymore.


From the news:

"""
Please note that the default upgrade method switches packages to the new
Python versions as they are rebuilt.  This means that all interdependent
packages have to support the new version for the upgrade to proceed,
and that some programs may temporarily fail to find their dependencies
throughout the upgrade (although programs that are already started
are unlikely to be affected).
"""

That also includes programs which you aren't running in another window,
but rather, programs which are used to build other packages.




-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[gentoo-user] Re: Fragile python update is wedged [Was: Fragile rust update is wedged].

[Grant Edwards]

On 2025-05-02, Alan Mackenzie <acm@muc.de> wrote:

> It was an update.  It was for the purpose of replacing python 3.12 with
> python 3.13.  Thus it was a python update.

Wow. As Kelly Bundy used to say: "The mind wobbles!"

--
Grant

Re: [gentoo-user] Fragile rust update is wedged.

[Nate Eldredge]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]



> On May 2, 2025, at 13:07, Alan Mackenzie <acm@muc.de> wrote:
> 
> Hello, Eli.
> 
> On Fri, May 02, 2025 at 13:47:02 -0400, Eli Schwartz wrote:
> 
>> Compiling rust officially requires building the pre 1.0 version of rust,
>> itself written in ocaml, and then building *every* version of rust since
>> then, one by one, in turn, without skipping a single one. That is over
>> 80 different versions of rust, you need to compile all of them in order
>> to get to the current one.
> 
> No thanks!  There's only so much time left before the Sun becomes a red
> giant.  But this attitude must limit the portability of rust to different
> processors, such as are found in embedded systems.
> 


For embedded systems, I assume you'd normally be cross-compiling.  So all you'd need to get started is a current rust binary package for your build system (let's say x86-64-linux).  With that, you can build a cross-compiler x86-64-linux->toaster-none, and build your toaster control software with it.  You wouldn't normally want to be running the rust compiler on your toaster at all, but if it somehow has enough memory and storage for that, then you should be able to use your cross-compiler to build a native toaster->toaster rust compiler, and copy it to the toaster.  And if you then have the patience to rebuild rust natively on the toaster, at this point you can.

But by no means should you need to build 80 versions of rust on the toaster.


[-- Attachment #2: Type: text/html, Size: 6695 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Wol]

On 02/05/2025 18:07, Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> I've just been trying the update for python 3.13.  It went well on my
> new machine (well, after unmerging app-portage/unsymlink-lib, which was
> debris from some 2019 update).

I'm now trying to update my system. And it's not even fragile or wedged, 
it just won't.

I followed the instructions at the end - depclean, -1uVD, and it just 
fails completely with "requires just one of 3_11 or 3_12". Including 
important stuff like most of kde, systemd-dbus, and so on.

I thought I'd try increasing backtrack like I usually do - to 100 - but 
that made no difference.

I missed out the stuff at the start of the news item, sorry, but see 
below ...

Giveb that I don't "do" Python, I've got nothing in make.conf that 
mentions python. I guess I have nothing in package.use etc unless the 
system set it for me ...

So I guess I need to do the "safer" upgrade, but it gives me two lines 
that look like comments, and says "use these to blah blah", How do I use 
them? Where do I put them? I don't "do" python - this is double dutch to me.

Cheers,
Wol

Re: [gentoo-user] Fragile python update is wedged.

[Dale]

Wol wrote:
>
>
> On 02/05/2025 18:07, Alan Mackenzie wrote:
>> Hello, Gentoo.
>>
>> I've just been trying the update for python 3.13.  It went well on my
>> new machine (well, after unmerging app-portage/unsymlink-lib, which was
>> debris from some 2019 update).
>
> I'm now trying to update my system. And it's not even fragile or
> wedged, it just won't.
>
> I followed the instructions at the end - depclean, -1uVD, and it just
> fails completely with "requires just one of 3_11 or 3_12". Including
> important stuff like most of kde, systemd-dbus, and so on.
>
> I thought I'd try increasing backtrack like I usually do - to 100 -
> but that made no difference.
>
> I missed out the stuff at the start of the news item, sorry, but see
> below ...
>
> Giveb that I don't "do" Python, I've got nothing in make.conf that
> mentions python. I guess I have nothing in package.use etc unless the
> system set it for me ...
>
> So I guess I need to do the "safer" upgrade, but it gives me two lines
> that look like comments, and says "use these to blah blah", How do I
> use them? Where do I put them? I don't "do" python - this is double
> dutch to me.
>
> Cheers,
> Wol
>
>


I'm going to do this in segments from the news item.  I had to read it a
couple times to get the idea myself.  Keep in mind, I ran into the same
thing as you and ended up stopping at step two.  I have not done a
complete switch yet because several packages still want 3.12. 


NEWS ITEM:
First, enable both Python 3.12 and Python 3.13, and then run the upgrade
commands:

    */* PYTHON_TARGETS: -* python3_12 python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_12
END NEWS ITEM

Put that in package.use, or some other file you may want to use.  I ran
my normal emerge -auDN world.  I have some defaults like --with-bdeps y
--backtrack=500 in make.conf.  You may or may not want to use those as
well. If you get a clean update from that, nothing fails, then move to
the next step.  You only change the second line from 12 to 13 next. 


NEWS ITEM:
Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:

    */* PYTHON_TARGETS: -* python3_12 python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_13
END NEWS ITEM

If you get a clean update with that, then change to the next step.  The
top line changes this time.  Just remove the 3.12 bit.  Keep in mind, I
haven't got that far yet.  I need to try again tho.  I forgot during the
update I did this morning. 


NEWS ITEM:
Finally, switch to the final version and upgrade:

    */* PYTHON_TARGETS: -* python3_13
    */* PYTHON_SINGLE_TARGET: -* python3_13
END NEWS ITEM


If you lucky, that last part works and you get a clean update.  If you
get a long list of packages that won't work, you either have to set it
back to step two and wait until the packages update or make exceptions
for each package in package.use and try to check for updates later so
you can remove all the python stuff in package.use.  I've read that
unless you really know what you doing, setting python versions long term
in package.use isn't a good idea.  If one forgets, which I do a LOT,
packages can start to fail and cause all sorts of issues that makes
emerge spit out encrypted error messages that most of us can't decode. 

I might add, Eli said it is safe to stop at step two if the last step is
just to soon.  I have some packages, Kicad and such, that you likely
don't and that is one set that is causing problems for me.  Unless you
have a lot of packages that have to have 3.12, it should work.  It just
results in compiling the same packages several times. 

If nothing else, maybe the above will give you a idea on how you can
adjust the above to fit your needs.  Basically, it's a three step
process.  I hope you can make it to the end and get a clean update.  Oh,
don't forget --depclean too. 

Dale

:-)  :-) 

Re: [gentoo-user] Fragile python update is wedged.

[Philip Webb]

I noticed others reporting Python update problems & didn't follow it,
but in my regular Sat update today encountered a big mess.
'setuptools-scm' offered  13  screens of conflicts,
which were reduced to  10  by ' --backtrack=60 '.
I tried a 'quickpkg' + 'emerge -k', but was refused as the ebuild was missing.
Finally, I did a few 'emerge -C' brute-forces on some listed pkgs,
which allowed a straightforward 'emerge' of  18  Python pkgs.
The underlying problem seemed to be a jump to Python 3.13 .

That solution is risky, but it has always worked before + today.
I don't understand why Python can't do it automatically,
but am tired of complaining & remain a strong fan of Gentoo.

PS I've never done 'emerge World' without '-pv' since 2003 :
I always pick/choose which pkgs to update a few at a time.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatcadotinterdotnet

Re: [gentoo-user] Fragile python update is wedged.

[Dale]

Philip Webb wrote:
> I noticed others reporting Python update problems & didn't follow it,
> but in my regular Sat update today encountered a big mess.
> 'setuptools-scm' offered  13  screens of conflicts,
> which were reduced to  10  by ' --backtrack=60 '.
> I tried a 'quickpkg' + 'emerge -k', but was refused as the ebuild was missing.
> Finally, I did a few 'emerge -C' brute-forces on some listed pkgs,
> which allowed a straightforward 'emerge' of  18  Python pkgs.
> The underlying problem seemed to be a jump to Python 3.13 .
>
> That solution is risky, but it has always worked before + today.
> I don't understand why Python can't do it automatically,
> but am tired of complaining & remain a strong fan of Gentoo.
>
> PS I've never done 'emerge World' without '-pv' since 2003 :
> I always pick/choose which pkgs to update a few at a time.
>


I think a lot of it depends on what packages we have installed.  For me,
it was Kicad and a couple others, plus all their friends.  It became a
lengthy list tho.  You may have a completely different set of packages
installed but with the same problem as me, doesn't support 3.13 yet. 

I think Eli said that as long as a version of python is installed for
emerge, one can fix most problems if we remove something by mistake.  We
just need to make sure emerge stays happy. 

I started using Gentoo in about 2003 as well.  Over the years, I've put
some options that are always wanted in make.conf and then I put others,
depending on what I'm doing, on the command line.  I have backtrack set
to 500.  It rarely goes higher than 4 or 5 tho.  Still, it has it if it
needs it.  I have build deps turned on as well.  Over the years tho,
I've found settings and methods that result in a very stable system.  I
always sync, do a emerge -auDN world and then look at any USE flag
changes, or any other changes, before letting it go.  Sometimes a new
USE flag pops up that I know I need or don't need.  I adjust and then
rerun emerge -auDN world.  I've found that letting emerge figure it out
is usually the best and most stable.  It may result in a little more
compiling but it's rare that anything crashes on my system.  That's
important to me. 

We all have our own ways tho.  If it works, why do it differently??? 

Oh, tried to do the last step on my main rig, emerge spit out a nice
loud and hard to miss, NO!!!.  There's still a lot of packages not ready
for python 3.13 yet.  Maybe next week.  If I don't forget.  Again. 

Dale

:-)  :-) 

Re: [gentoo-user] Fragile python update is wedged.

[Dale]

Dale wrote:
> <<<< SNIP >>>>
> Oh, tried to do the last step on my main rig, emerge spit out a nice
> loud and hard to miss, NO!!!.  There's still a lot of packages not ready
> for python 3.13 yet.  Maybe next week.  If I don't forget.  Again. 
>
> Dale
>
> :-)  :-) 
>


Little update.  I just went to the third step in the python update news
item, safer method.  The only package I have left at 3.12 is
media-libs/avidemux-plugins.  It is a lonely package for python 3.12. 
Even Kicad is up to 3.13 now. 

So, for those still stuck at step 2, may want to give step three a try
and see how close you are to being able to fully switch. 

Dale

:-)  :-) 

Re: [gentoo-user] Fragile python update is wedged.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On Saturday, 17 May 2025 08:17:34 British Summer Time Dale wrote:
> Dale wrote:
> > <<<< SNIP >>>>
> > Oh, tried to do the last step on my main rig, emerge spit out a nice
> > loud and hard to miss, NO!!!.  There's still a lot of packages not ready
> > for python 3.13 yet.  Maybe next week.  If I don't forget.  Again. 
> > 
> > Dale
> > 
> > :-)  :-) 
> 
> Little update.  I just went to the third step in the python update news
> item, safer method.  The only package I have left at 3.12 is
> media-libs/avidemux-plugins.  It is a lonely package for python 3.12. 
> Even Kicad is up to 3.13 now. 
> 
> So, for those still stuck at step 2, may want to give step three a try
> and see how close you are to being able to fully switch. 
> 
> Dale
> 
> :-)  :-) 

First, a big thank you to devs and maintainers for making this python upgrade 
so seamless and for me at least, painless.  Four PCs were updated without any 
intervention by me whatsoever.

The fifth upgrade involved an old laptop which had not seen an update for more 
than 9 months.  I thought this would present some problems and require my 
manual intervention, if only because portage and its contents have moved on 
some distance over this time.

Emerge added a load of python target related USE flags in zz-autounmask, which 
I accepted.  Then I added '--backtrack=99' before I let it rip.  It took 
overnight, emerged close to 900 packages and arrived at a fully working system 
and desktop.  After a --depclean session I removed the zz-autounmask USE 
flags, whereby a number of python related packages were re-emerged and 
everything is working as expected.

Finally, another laptop with a very similar collection of packages had an 
almost seamless upgrade ... except that I stopped it some way through.  When I 
restarted emerge a day later there were problems.  Packages were asking to be 
emerged in a different order.  Rust had a circular hissy fit as Alan reported 
initially and qt-base and friends were blocking because they didn't like some 
of the recently emerged dependencies - or something like that.  Anyway, I 
emerged rust-bin for now, unmerged qt-base and left the emerge well alone to 
proceeded with further issues.

Given this anecdotal experience, I made a mental note for next time to leave 
systems complete a major upgrade once I commit to it, rather than interrupt 
emerge from doing its thing.  

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]

Michael wrote:
> On Saturday, 17 May 2025 08:17:34 British Summer Time Dale wrote:
>> Dale wrote:
>>> <<<< SNIP >>>>
>>> Oh, tried to do the last step on my main rig, emerge spit out a nice
>>> loud and hard to miss, NO!!!.  There's still a lot of packages not ready
>>> for python 3.13 yet.  Maybe next week.  If I don't forget.  Again. 
>>>
>>> Dale
>>>
>>> :-)  :-) 
>> Little update.  I just went to the third step in the python update news
>> item, safer method.  The only package I have left at 3.12 is
>> media-libs/avidemux-plugins.  It is a lonely package for python 3.12. 
>> Even Kicad is up to 3.13 now. 
>>
>> So, for those still stuck at step 2, may want to give step three a try
>> and see how close you are to being able to fully switch. 
>>
>> Dale
>>
>> :-)  :-) 
> First, a big thank you to devs and maintainers for making this python upgrade 
> so seamless and for me at least, painless.  Four PCs were updated without any 
> intervention by me whatsoever.
>
> The fifth upgrade involved an old laptop which had not seen an update for more 
> than 9 months.  I thought this would present some problems and require my 
> manual intervention, if only because portage and its contents have moved on 
> some distance over this time.
>
> Emerge added a load of python target related USE flags in zz-autounmask, which 
> I accepted.  Then I added '--backtrack=99' before I let it rip.  It took 
> overnight, emerged close to 900 packages and arrived at a fully working system 
> and desktop.  After a --depclean session I removed the zz-autounmask USE 
> flags, whereby a number of python related packages were re-emerged and 
> everything is working as expected.
>
> Finally, another laptop with a very similar collection of packages had an 
> almost seamless upgrade ... except that I stopped it some way through.  When I 
> restarted emerge a day later there were problems.  Packages were asking to be 
> emerged in a different order.  Rust had a circular hissy fit as Alan reported 
> initially and qt-base and friends were blocking because they didn't like some 
> of the recently emerged dependencies - or something like that.  Anyway, I 
> emerged rust-bin for now, unmerged qt-base and left the emerge well alone to 
> proceeded with further issues.
>
> Given this anecdotal experience, I made a mental note for next time to leave 
> systems complete a major upgrade once I commit to it, rather than interrupt 
> emerge from doing its thing.  


I agree.  The devs did a good job with the safer method.  Some of us
just had some packages that were a little behind, for me, Kicad and a
couple other packages that likely not many people use compared to
something like Chrome, Firefox or LOo which was ready.  Still, the devs
can't help that some packages lag behind.  The important part, they gave
use a upgrade method that works even if it requires us to either delay
some packages or just delay the final step.  Once my odd packages caught
up, I was left with one package that still needs the old python.  Thing
is, my system remained stable during the whole thing. 

I have to say, emerge has come a LONG ways since 2003 when I started
using Gentoo.  Someone coming up with the idea of being able to inform
us of changes, with the news items, is also a HUGE help.  We get a
notice that something important is changing and might require certain
steps.  We not hitting these major changes blindly anymore.  I remember
the old days when I would sync and then emerge would puke all over my
keyboard with something most of us couldn't make sense of.  Today, we
sync, get a alert of serious changes that require attention and then
tells us how to navigate the change, usually with more than one way to
do it. 

Yea, Gentoo has come a long ways.  The devs do some awesome work.  Wish
I could win the lottery.  LOL  :-D 

Dale

:-)  :-) 

P. S.  I'm still trying to figure out how to redo my drive setup.  I got
one large LVM that I want to transfer to a encrypted file system.  I'm
trying to figure out how to put the new drives in or move the old drives
to the NAS box for the transfer.  Either way requires a lot of work.  :/ 

[-- Attachment #2: Type: text/html, Size: 5399 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]

On 5/11/25 9:26 AM, Philip Webb wrote:
> I noticed others reporting Python update problems & didn't follow it,
> but in my regular Sat update today encountered a big mess.
> 'setuptools-scm' offered  13  screens of conflicts,
> which were reduced to  10  by ' --backtrack=60 '.
> I tried a 'quickpkg' + 'emerge -k', but was refused as the ebuild was missing.
> Finally, I did a few 'emerge -C' brute-forces on some listed pkgs,
> which allowed a straightforward 'emerge' of  18  Python pkgs.
> The underlying problem seemed to be a jump to Python 3.13 .


I doubt the problem was that package specifically, as it supports all
python versions already. Probably, it was just set by the default
upgrade changes to 3.13, but some other package was stuck on 3.12. This
in turn prevented updating setuptools-scm at all, which meant other
packages which required setuptools-scm, couldn't be rebuilt for 3.13

The "safe" approach solves that, fwiw. (You may not be able to do the
second stage and remove 3.12, ddepending.)

Please consider emerge -c --with-bdeps=n before something as dangerous
as -C. If the former works, then you're guaranteed a correct system
dependency graph and will just have to freshly emerge build
dependencies, which is a valid and supported scenario, whereas emerge -C
is *not*.

As you say, "that solution is risky"... but -c --with-bdeps=n would mean
you aren't doing risky things at all...


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Frank Schletz]

Am Sun, 11 May 2025 12:54:48 +0100
schrieb Wol <antlists@youngman.org.uk>:

> On 02/05/2025 18:07, Alan Mackenzie wrote:
> > Hello, Gentoo.
> > 
> > I've just been trying the update for python 3.13.  It went well on my
> > new machine (well, after unmerging app-portage/unsymlink-lib, which was
> > debris from some 2019 update).
> 
> I'm now trying to update my system. And it's not even fragile or wedged, 
> it just won't.
> 
> I followed the instructions at the end - depclean, -1uVD, and it just 
> fails completely with "requires just one of 3_11 or 3_12". Including 
> important stuff like most of kde, systemd-dbus, and so on.
> 
> I thought I'd try increasing backtrack like I usually do - to 100 - but 
> that made no difference.
> 
> I missed out the stuff at the start of the news item, sorry, but see 
> below ...
> 
> Giveb that I don't "do" Python, I've got nothing in make.conf that 
> mentions python. I guess I have nothing in package.use etc unless the 
> system set it for me ...
> 
> So I guess I need to do the "safer" upgrade, but it gives me two lines 
> that look like comments, and says "use these to blah blah", How do I use 
> them? Where do I put them? I don't "do" python - this is double dutch to me.


Hello.

The "Safer upgrade procedure" in 
https://www.gentoo.org/support/news-items/2025-03-24-python3-13.html
works for me like a charm.

yes, looks funny for some people, if in
/etc/portage/package.use/python
there is something like

 */* PYTHON_TARGETS: -* python3_12 python3_13
 */* PYTHON_SINGLE_TARGET: -* python3_12

But that is right.

My old file consist of:
 */* PYTHON_TARGETS: -* python3_11 python3_12
 */* PYTHON_SINGLE_TARGET: -* python3_12

so I start as mentioned in the news with
  emerge -1vUD @world
  emerge -a --depclean (I always take care and in doubt don't delete)

Then change to
 */* PYTHON_TARGETS: -* python3_12 python3_13
 */* PYTHON_SINGLE_TARGET: -* python3_12
and repeat with emerge.
Finally change to
 */* PYTHON_TARGETS: -* python3_13
 */* PYTHON_SINGLE_TARGET: -* python3_13
and repeat.

It works for me and looks very straight forward.
I got a non-systemd system and not that much packages.

Hope you got a clean emerge @world at the beginning.

Frank

Re: [gentoo-user] Fragile python update is wedged.

[Wol]

On 11/05/2025 13:43, Frank Schletz wrote:
> It works for me and looks very straight forward.
> I got a non-systemd system and not that much packages.
> 
> Hope you got a clean emerge @world at the beginning.

Yup I always make sure everything's depclean'd at the end.

It's now updating stage 1 fine (approx 250 packages), but my usual 
backtrack=100 didn't work - I made it 1000 and it's fine.

Little tip - if you use backtrack I think it comes up with a little 
status report - it said something like "backtrack 100/100". I'm guessing 
what that means is backtrack was set to 100, and it used 100, which is 
why it failed ... useful info if I'm right ... :-)

Cheers,
Wol

Re: [gentoo-user] Fragile python update is wedged.

[Dale]

Wol wrote:
> On 11/05/2025 13:43, Frank Schletz wrote:
>> It works for me and looks very straight forward.
>> I got a non-systemd system and not that much packages.
>>
>> Hope you got a clean emerge @world at the beginning.
>
> Yup I always make sure everything's depclean'd at the end.
>
> It's now updating stage 1 fine (approx 250 packages), but my usual
> backtrack=100 didn't work - I made it 1000 and it's fine.
>
> Little tip - if you use backtrack I think it comes up with a little
> status report - it said something like "backtrack 100/100". I'm
> guessing what that means is backtrack was set to 100, and it used 100,
> which is why it failed ... useful info if I'm right ... :-)
>
> Cheers,
> Wol
>
>


That's what I think as well.  If you set it to a number and it maxes out
and fails, try a higher number.  If it fails and didn't reach the limit,
well, you got other problems.  The thing to keep in mind, regardless of
setting, it only uses what it needs.  Most of the time, mine shows a
status of 1 or 2 and sometimes 3.  Rarely goes above that.  I just set
mine to 500 because I got tired of it running out of room to think and
having to change the setting and start over again.  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] Fragile python update is wedged.

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2168 bytes --]

On 5/11/25 7:54 AM, Wol wrote:
> 
> 
> On 02/05/2025 18:07, Alan Mackenzie wrote:
>> Hello, Gentoo.
>>
>> I've just been trying the update for python 3.13.  It went well on my
>> new machine (well, after unmerging app-portage/unsymlink-lib, which was
>> debris from some 2019 update).
> 
> I'm now trying to update my system. And it's not even fragile or wedged,
> it just won't.
> 
> I followed the instructions at the end - depclean, -1uVD, and it just
> fails completely with "requires just one of 3_11 or 3_12". Including
> important stuff like most of kde, systemd-dbus, and so on.
> 
> I thought I'd try increasing backtrack like I usually do - to 100 - but
> that made no difference.


You must have done something more than just emerge --sync followed by
emerge -uDU @world.

OR you must have had old package.use entries setting duplicate USE flags
already.


> I missed out the stuff at the start of the news item, sorry, but see
> below ...
> 
> Giveb that I don't "do" Python, I've got nothing in make.conf that
> mentions python. I guess I have nothing in package.use etc unless the
> system set it for me ...
> 
> So I guess I need to do the "safer" upgrade, but it gives me two lines
> that look like comments, and says "use these to blah blah", How do I use
> them? Where do I put them? I don't "do" python - this is double dutch to
> me.


I'm confused and baffled that, when a news item describes some blocks of
code as "the package.use samples provided below", you are totally lost
and declare that you don't "do" python as it's double dutch to you.

And why on earth would you assume they are comments?

You don't need to know python and aren't expected to either. The news
item describes the fact that:

- a group of packages using the python programming language, are
 switching their versioned USE flags, here's the correct way to migrate
 the USE

- it involves building many packages for the changed USE. Rebuilding
  many packages at the same time can sometimes result in complex issues,
  these are a USE_EXPAND and can be migrated in stages, which is safer.



-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Wol]

On 11/05/2025 16:04, Eli Schwartz wrote:
> On 5/11/25 7:54 AM, Wol wrote:
>>
>>
>> On 02/05/2025 18:07, Alan Mackenzie wrote:
>>> Hello, Gentoo.
>>>
>>> I've just been trying the update for python 3.13.  It went well on my
>>> new machine (well, after unmerging app-portage/unsymlink-lib, which was
>>> debris from some 2019 update).
>>
>> I'm now trying to update my system. And it's not even fragile or wedged,
>> it just won't.
>>
>> I followed the instructions at the end - depclean, -1uVD, and it just
>> fails completely with "requires just one of 3_11 or 3_12". Including
>> important stuff like most of kde, systemd-dbus, and so on.
>>
>> I thought I'd try increasing backtrack like I usually do - to 100 - but
>> that made no difference.
> 
> 
> You must have done something more than just emerge --sync followed by
> emerge -uDU @world.
> 
What else would I have done? I ran the sync, read the news, and followed 
the instructions at the bottom. The emerge failed with loads of errors.

The only thing else I did was delete avidemux (which I think was broken 
anyway), because that was an obvious problem that wouldn't cause 
problems if I deleted it.

> OR you must have had old package.use entries setting duplicate USE flags
> already.
> 
> 
>> I missed out the stuff at the start of the news item, sorry, but see
>> below ...
>>
>> Giveb that I don't "do" Python, I've got nothing in make.conf that
>> mentions python. I guess I have nothing in package.use etc unless the
>> system set it for me ...
>>
>> So I guess I need to do the "safer" upgrade, but it gives me two lines
>> that look like comments, and says "use these to blah blah", How do I use
>> them? Where do I put them? I don't "do" python - this is double dutch to
>> me.
> 
> 
> I'm confused and baffled that, when a news item describes some blocks of
> code as "the package.use samples provided below", you are totally lost
> and declare that you don't "do" python as it's double dutch to you.
> 
Found it. I will investigate, but to the best of my memory I have no 
"targets" settings whatsoever. I will take a look, but at the moment I'm 
running the emerge. So from what the news item says, it looks like 
everything should have "just worked" - except it didn't.

And I can see what happened now. It doesn't help that I didn't have my 
glasses, but the news item says:

"At this point, you have a few configuration options to choose from:"

I jumped straight to option 4, so I didn't read option 1 - why should I? 
Especially if I'm having difficulty reading.

> And why on earth would you assume they are comments?

Because the news item, as written, led me up the garden path!

"Safer upgrade procedure
=======================
A safer approach is to add Python 3.13 support to your system first,
and only then remove Python 3.12.  However, note that this involves two
rebuilds of all the affected packages, so it will take noticeably
longer.

First, enable both Python 3.12 and Python 3.13, and then run the upgrade
commands:

     */* PYTHON_TARGETS: -* python3_12 python3_13
     */* PYTHON_SINGLE_TARGET: -* python3_12"

It says "run the upgrade commands - COLON". As I understand English, 
that says that what follows is a list of COMMANDS. And "*/*" looks like 
a weird comment marker. Why would I assume it's a declaration snippet?

> 
> You don't need to know python and aren't expected to either. The news
> item describes the fact that:

That's clear now. But the combination of not reading a paragraph that 
clearly appeared to be irrelevant, and the use of non-idiomatic grammar 
that read completely differently than intended, meant I completely 
failed to understand what I was supposed to do.

Oh - and I've just checked - there is no mention of Python in my 
package.use (apart from what I've just created to do the upgrade). So I 
don't appear to have any python targets anywhere .

Cheers,
Wol

Re: [gentoo-user] Fragile python update is wedged.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On Sunday, 11 May 2025 18:40:44 British Summer Time Wol wrote:

> Found it. I will investigate, but to the best of my memory I have no
> "targets" settings whatsoever. I will take a look, but at the moment I'm
> running the emerge. So from what the news item says, it looks like
> everything should have "just worked" - except it didn't.

This won't help you, but I have updated 4 systems so far and a 4th somewhat 
abandoned waiting for my time, with no problems so far whatsoever.  I do 
understand and it was explained, it is a matter of which packages may be 
installed in a system if you may face a failed update.


> And I can see what happened now. It doesn't help that I didn't have my
> glasses, but the news item says:
> 
> "At this point, you have a few configuration options to choose from:"
> 
> I jumped straight to option 4, so I didn't read option 1 - why should I?
> Especially if I'm having difficulty reading.

Perhaps because a numbered list is meant to be followed in the numbered order?

I started with option 1 and had no problems, but others sooner or later run 
aground and had to consider subsequent options depending on their individual 
situation.


> First, enable both Python 3.12 and Python 3.13, and then run the upgrade
> commands:
> 
>      */* PYTHON_TARGETS: -* python3_12 python3_13
>      */* PYTHON_SINGLE_TARGET: -* python3_12"
> 
> It says "run the upgrade commands - COLON". As I understand English,
> that says that what follows is a list of COMMANDS. And "*/*" looks like
> a weird comment marker. Why would I assume it's a declaration snippet?

Because an asterisk "*" is a special character treated as a wildcard when 
parsed by a Unix shell.  It will match any number of unknown characters.

The "*/*" statement at the start of a file under /etc/portage/ can be 
interpreted as a filter matching:

 any category/any package

with the next "-*" statement interpreted as:

disable any python targets and then finally set only the python target(s) that 
follow.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4350 bytes --]

On 5/11/25 1:40 PM, Wol wrote:
> On 11/05/2025 16:04, Eli Schwartz wrote:
>>> I followed the instructions at the end - depclean, -1uVD, and it just
>>> fails completely with "requires just one of 3_11 or 3_12". Including
>>> important stuff like most of kde, systemd-dbus, and so on.
>>>
>>> I thought I'd try increasing backtrack like I usually do - to 100 - but
>>> that made no difference.
>>
>>
>> You must have done something more than just emerge --sync followed by
>> emerge -uDU @world.
>>
> What else would I have done? I ran the sync, read the news, and followed
> the instructions at the bottom. The emerge failed with loads of errors.
> 
> The only thing else I did was delete avidemux (which I think was broken
> anyway), because that was an obvious problem that wouldn't cause
> problems if I deleted it.


You didn't post full output so it's difficult to say for sure. But,
"requires just one of" sounds like this:

$ PYTHON_SINGLE_TARGET='python3_13 python3_12' emerge -1a glib-utils

These are the packages that would be merged, in order:

Calculating dependencies -

!!! Problem resolving dependencies for dev-util/glib-utils
... done!
Dependency resolution took 1.01 s (backtrack: 0/20).


!!! The ebuild selected to satisfy "glib-utils" has unmet requirements.
- dev-util/glib-utils-2.82.5::gentoo USE="" ABI_X86="(64)"
PYTHON_SINGLE_TARGET="python3_12 python3_13 -python3_11"

  The following REQUIRED_USE flag constraints are unsatisfied:
    exactly-one-of ( python_single_target_python3_11
python_single_target_python3_12 python_single_target_python3_13 )



The "exactly-one-of" means you have set two USE flags for the package
and can only choose one at the same time.

The ::gentoo repository of ebuilds does not set both at the same time.
In order to get both, you must have one somewhere outside of the gentoo
repository...


>> OR you must have had old package.use entries setting duplicate USE flags
>> already.


... which is why I suggested this.


> And I can see what happened now. It doesn't help that I didn't have my
> glasses, but the news item says:
> 
> "At this point, you have a few configuration options to choose from:"
> 
> I jumped straight to option 4, so I didn't read option 1 - why should I?
> Especially if I'm having difficulty reading.


Sorry? What? This wasn't part of option 1, this was from the paragraph
before "at this point you have a few configuration options".

You jumped straight over the paragraph before the one telling you to
make a choice.


>> And why on earth would you assume they are comments?
> 
> Because the news item, as written, led me up the garden path!
> 
> "Safer upgrade procedure
> =======================
> A safer approach is to add Python 3.13 support to your system first,
> and only then remove Python 3.12.  However, note that this involves two
> rebuilds of all the affected packages, so it will take noticeably
> longer.
> 
> First, enable both Python 3.12 and Python 3.13, and then run the upgrade
> commands:
> 
>     */* PYTHON_TARGETS: -* python3_12 python3_13
>     */* PYTHON_SINGLE_TARGET: -* python3_12"
> 
> It says "run the upgrade commands - COLON". As I understand English,
> that says that what follows is a list of COMMANDS. And "*/*" looks like
> a weird comment marker. Why would I assume it's a declaration snippet?


First, enable both python 3.12 an python 3.13:

    <package.use stuff>

and then run the upgrade commands.

It is not lacking the quality of being idiomatic, to write the colon
after the full sentence rather than splitting the sentence in two. I see
both quite often. But regardless,

it certainly isn't a weird comment marker given:

- it looks EXACTLY like package.use syntax (because it is)

- there are no COMMANDS. No "emerge" either. Did you try to copy/paste
  it into a bash shell?


>> You don't need to know python and aren't expected to either. The news
>> item describes the fact that:
> 
> That's clear now. But the combination of not reading a paragraph that
> clearly appeared to be irrelevant, 


This is not what happened, so the news item is not responsible for your
failure to read the paragraph *before* the one you felt was irrelevant.

Sorry.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Fragile python update is wedged.

[Wol]

On 11/05/2025 19:08, Eli Schwartz wrote:
>> Because the news item, as written, led me up the garden path!
>>
>> "Safer upgrade procedure
>> =======================
>> A safer approach is to add Python 3.13 support to your system first,
>> and only then remove Python 3.12.  However, note that this involves two
>> rebuilds of all the affected packages, so it will take noticeably
>> longer.
>>
>> First, enable both Python 3.12 and Python 3.13, and then run the upgrade
>> commands:
>>
>>      */* PYTHON_TARGETS: -* python3_12 python3_13
>>      */* PYTHON_SINGLE_TARGET: -* python3_12"
>>
>> It says "run the upgrade commands - COLON". As I understand English,
>> that says that what follows is a list of COMMANDS. And "*/*" looks like
>> a weird comment marker. Why would I assume it's a declaration snippet?
> 
> First, enable both python 3.12 an python 3.13:
> 
>      <package.use stuff>
> 
> and then run the upgrade commands.
> 
> It is not lacking the quality of being idiomatic, to write the colon
> after the full sentence rather than splitting the sentence in two. I see
> both quite often. But regardless,

The problem is, if I see "commands COLON", that means that what follows 
the colon is a list of commands. And it's clearly a list so I assumed it 
was commands ...

 From his name, I assume Michał Górny is not a native English speaker, 
and I have no problem with that. I speak four languages to varying 
amounts of ability and the quality of foreigners' English never ceases 
to amaze me. But the fact remains I did not understand what this news 
item said! It's been explained and it's now clear what was meant, 
whether that's what was actually written or not.

And going back a bit - having carefully read the news item to find what 
it said about package.use, it's magically changed!?!? I now can't find 
any mention of "package.use snippets", which I am sure I found when 
carefully reading the item!

But anyway - a bit more - the actual targets ...

 > You didn't post full output so it's difficult to say for sure. But,
 > "requires just one of" sounds like this:
 >
 > $ PYTHON_SINGLE_TARGET='python3_13 python3_12' emerge -1a glib-utils

That's basically what I got, except it was demanding python 11 or 12. 
Given that I have absolutely no mention that I can find of python, in 
either make.conf or package.use (other than the snippet I've just added 
to force the upgrade), it looks to me like option 1 should have "just 
worked". So why didn't it? Where else would there be stuff that tells my 
system that Python 13 is "persona non grata"?

The only thing that feels like it might be a problem (and if Python 13 
is now the default that's REALLY weird) is I don't have ~amd64 as 
default ... (and my system is systemd/kde, but that also should be 
irrelevant).

Cheers,
Wol

Re: [gentoo-user] Fragile python update is wedged.

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

On 5/11/25 3:10 PM, Wol wrote:
> But anyway - a bit more - the actual targets ...
> 
>> You didn't post full output so it's difficult to say for sure. But,
>> "requires just one of" sounds like this:
>>
>> $ PYTHON_SINGLE_TARGET='python3_13 python3_12' emerge -1a glib-utils
> 
> That's basically what I got, except it was demanding python 11 or 12.


... but you originally said,

"I followed the instructions at the end - depclean, -1uVD, and it just
fails completely with "requires just one of 3_11 or 3_12". Including
important stuff like most of kde, systemd-dbus, and so on."


You should definitely not have only 3.11 and 3.12 as options for "most
of kde, systemd-dbus, and so on".

Here's a list of packages that only have 3.11 and 3.12 support:

https://qa-reports.gentoo.org/output/gpyutils/312-to-313.txt

Courtesy of the dashboard at https://qa-reports.gentoo.org/

A mere 269 packages, out of numerous thousands of packages in gentoo.
And "most of KDE" was certainly ready. A common theme of those that
weren't is that they are usually not well maintained or popular. sci-*/
packages are quite a chunk.

Either way, that goes back to the general discussion about "not all
packages were ready yet", and that is a topic of discussion every single
year. As the news item said, it's possible to take a slower approach and
defer the whole thing.


> Given that I have absolutely no mention that I can find of python, in
> either make.conf or package.use (other than the snippet I've just added
> to force the upgrade), it looks to me like option 1 should have "just
> worked". So why didn't it? Where else would there be stuff that tells my
> system that Python 13 is "persona non grata"?


Full portage output could no doubt shed a light on which package is
missing support for 3.13 entirely.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]