Re: [gentoo-user] python 3.12 update

[hitachi303]

Am 04.06.24 um 22:09 schrieb Eli Schwartz:

The purpose of the news item was to warn users that the event would
occur. Did it not achieve its purpose? Were you not-warned?

Do we at least agree that the news item was truthful?


Hi,

for me this was exactly what the news item did. It helped me to plan my 
updates.


Most updated have been so smooth in the last years that I think there 
are a lot of devs (or all of them) doing incredible good work. I 
remember an update to python being not that smooth, but this might be a 
decade ago. This time there has been a warning, instructions on how to 
deferring, forcing and running it safe. Since I had little time I opted 
for deferring first. Now I'm going to try the save way on one of my 
boxes. But this is just my way.


In the past years a lot of news items have been incredible helpful. The 
others have not been important for my situation. So I am very thankful 
for the news system.


Regards

Re: [gentoo-user] python 3.12 update

[hitachi303]

Am 04.06.24 um 22:34 schrieb Eli Schwartz:

- you read the news item, but decided to NOT defer the upgrade, and
   instead tried to mix both python 3.11 and python 3.12 together on your
   system



I do have one question because I get the vipe from you that mixing 
python 3.11 and 3.12 would be a bad thing:


the news item lists in the save upgrade section those lines:
*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11

This is mixing python 3.11 and 3.12 on the same system. This should be 
working as well, shouldn't it? Shouldn't portage be able to deal with 
this, at least until python 3.11 gets deprecated? Why else would there 
be the chance to define more than one python target? And both versions 
of python are emerged in different slots. There might not be an 
advantage and the disadvantage to carry around two versions of python 
but shouldn't this work non the less?

Re: [gentoo-user] python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 4:27 AM hitachi303
 wrote:
>
> the news item lists in the save upgrade section those lines:
>  */* PYTHON_TARGETS: -* python3_11 python3_12
>  */* PYTHON_SINGLE_TARGET: -* python3_11
>
> This is mixing python 3.11 and 3.12 on the same system. This should be
> working as well, shouldn't it?

Not only should this work, but it should be less likely to cause
problems than the default upgrade process.  The news item says as
much.  This is the configuration I'm currently running (except I did
the next step and am setting python_single_taret to 3.12).  When I get
back from travelling in a week I will probably see what happens when I
remove my package.use overrides.

> Shouldn't portage be able to deal with
> this, at least until python 3.11 gets deprecated?

This should mostly work fine until 3.11 is removed.  The issue is with
python_single_target packages.  Any particular package can only use
one version of this, and if it has deps that use this setting those
must match.

If you're having issues, I would suggest either just waiting a few
weeks and trying again, or following the gradual migration
instructions.  When switching the single target to 3.12 if you have
some packages that don't work, then just override those packages in
package.use.

For example, I had this line in package.use:
<=sys-devel/distcc-3.4-r3 PYTHON_SINGLE_TARGET: -* python3_11

distcc hadn't been updated when I did the migration a few weeks ago.
So I told that package to use 3.11, but you'll note I put a version in
the atom so that when it got updated it would automatically try the
new version.  A few packages had errors when they updated and in those
cases I just updated the version in the override so that they would
continue to work.  In this case distcc -r4 added 3.12 support, and so
now that package is on 3.12.

This isn't a desktop-oriented system and I don't have a ton of python
packages on it, but I had 5 overrides at one point.  Now I'm down to
zero.  I haven't dropped 3.11 yet - I'm about to travel so that will
wait until I get back.

-- 
Rich

Re: [gentoo-user] python 3.12 update

[Rich Freeman]

On Tue, Jun 4, 2024 at 11:41 PM Marco Minutoli  wrote:
>
> What I believe is in the realm of reasonable is to ask to be notified when 
> important (as in popular) packages that are currently missing support get 
> updated with a stable version supporting python 3.12 so that we can take 
> action on our side.

Well, anything system-critical (as in you won't be able to boot or use
the package manager/etc) would have been updated before the change.
Actually, that stuff would have been checked before it was even
possible to install 3.12 most likely.

Popular is another matter.  Part of the issue is that the people who
maintain python do not necessarily maintain or use the stuff that is
popular.  The stuff that is popular might not even be maintained at
all in some cases.

Probably wouldn't have hurt to file bugs before everything started
breaking, but I get that even automated bug filing takes work, and it
isn't like I was volunteering to do it...

-- 
Rich

Re: [gentoo-user] Re: python 3.12 update

[Dr Rainer Woitok]

Grant,

On Tue, 4 Jun 2024 17:00:29 - (UTC) you wrote:

> ...
> I don't see how (even in theory) steps 2 and 3 can work when you have
> packages installed that won't build with 3.12.

That depends  on your definition  of "work".   It occurs even when doing
normal updates that you run into a USE flag conflict  you have to solve.
If you call this a "failed" upgrade  and stop there,  well, that's up to
you.  Others simply roll up their sleeves, investigate and change or add
a USE flag.  Here the problem was NOT that Python 3.11 had vanished, but
just that Python 3.12 had become the new default.  So a finite number of
USE flag changes solved this problem.

And no,  I don't buy  the point of view  that it's the responsibility of
the developers  when my personal set  of USE flags suddenly  causes con-
flicts.

Sincerely,
  Rainer

Re: [gentoo-user] python 3.12 update

[Eli Schwartz]

On 6/5/24 4:27 AM, hitachi303 wrote:
> Am 04.06.24 um 22:34 schrieb Eli Schwartz:
>> - you read the news item, but decided to NOT defer the upgrade, and
>>    instead tried to mix both python 3.11 and python 3.12 together on your
>>    system
> 
> 
> I do have one question because I get the vipe from you that mixing
> python 3.11 and 3.12 would be a bad thing:

> the news item lists in the save upgrade section those lines:
>     */* PYTHON_TARGETS: -* python3_11 python3_12
>     */* PYTHON_SINGLE_TARGET: -* python3_11
> 
> This is mixing python 3.11 and 3.12 on the same system. This should be
> working as well, shouldn't it? Shouldn't portage be able to deal with
> this, at least until python 3.11 gets deprecated? Why else would there
> be the chance to define more than one python target? And both versions
> of python are emerged in different slots. There might not be an
> advantage and the disadvantage to carry around two versions of python
> but shouldn't this work non the less?


It's not a bad thing, and it should work fine. However the person who I
was replying to, considers Gentoo to be broken if you have to set USE
flags in order to perform a world update, and mixing multiple versions
of python definitely requires you to set USE flags -- and if you only
want to keep python 3.11 around for packages that don't support 3.12,
rather than for all packages, then you would have to override
PYTHON_TARGETS for a carefully selected list of packages rather than for */*

So it is only mixing the two python versions that can ever *lead to
having lots of package.use lines as a result of the update*.

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 6:41 AM Dr Rainer Woitok  wrote:
>
> And no,  I don't buy  the point of view  that it's the responsibility of
> the developers  when my personal set  of USE flags suddenly  causes con-
> flicts.
>

Agree, but keep in mind that having personal sets of USE flags is
basically a necessity in Gentoo, and not a choice, because Gentoo does
not dynamically manage USE dependencies.

On any distro, including Gentoo, if you manually installed the
dependencies of every package you use explicitly, you'd probably end
up with a hopeless mess of dependency conflicts within a few months.
Everybody who has used Linux for any period of time understands that
this is a bad practice, and you should explicitly install the packages
you directly use, and let the package manager dynamically manage their
dependencies.  Then when a dependency becomes obsolete and is
replaced, the updates will happen automatically without the user
needing to worry about them.

Gentoo does this with package/version dependencies, but not with USE
flag dependencies.  If a package requires some other package to be
built with a particular USE flag, then portage will output an error,
and you will need to put an entry in package.use to manually specify
the USE configuration, and that will resolve the conflict. Then 5
years later you'll get some mysterious error due to that USE flag
setting being obsolete, and you have no idea why you even had it in
the first place unless you took meticulous notes, because the setting
doesn't reflect your own preference, but the requirements of some
package, which might be so far down the dependency tree that you don't
even know what it does.

Python version settings are just fancy ways of expressing USE
dependencies.  Unless you develop things in Python, you probably don't
care what versions of Python you have installed, and it is reasonable
to expect that the package manager or distro just takes care of this
for you.  Gentoo does not.

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.

It is this clash of expectations vs reality that causes many
frustration, and this is understandable.  That said, improving the
situation is a lot of work, whether this is in the form of a lot of
coordination to deal with the lack of dynamic USE dependencies, or the
effort to implement this feature in the package manager (which has
been discussed here and there for a decade or so).  You can't fault
volunteers for not working on things that they aren't interested in
working on.  That said, I do appreciate the frustration people have,
personally.  This is just one of those things you need to understand
about Gentoo, and then weigh the pros vs the cons when you choose what
distro to use.  If you want a distro that will just accept daily
updates with zero fuss, that isn't Gentoo.

-- 
Rich

Re: [gentoo-user] python 3.12 update

[Joost Roeleveld]

On Tue, Jun 4, 2024 at 11:41 PM Marco Minutoli  wrote:


What I believe is in the realm of reasonable is to ask to be  
notified when important (as in popular) packages that are currently  
missing support get updated with a stable version supporting python  
3.12 so that we can take action on our side.


Well, anything system-critical (as in you won't be able to boot or use
the package manager/etc) would have been updated before the change.
Actually, that stuff would have been checked before it was even
possible to install 3.12 most likely.


Here is the problem.
Not all "system-critical" packages were stabilised before this change  
was pushed.



Popular is another matter. Part of the issue is that the people who
maintain python do not necessarily maintain or use the stuff that is
popular. The stuff that is popular might not even be maintained at
all in some cases.

Probably wouldn't have hurt to file bugs before everything started
breaking, but I get that even automated bug filing takes work, and it
isn't like I was volunteering to do it...

[gentoo-user] Re: python 3.12 update

[Grant Edwards]

On 2024-06-05, Eli Schwartz  wrote:
> On 6/4/24 11:04 PM, Grant Edwards wrote:
>> On 2024-06-04, Eli Schwartz  wrote:
>>> If a package claimed to support python 3.12 and nonetheless failed to
>>> build with it, that's a bug in the package -- can you provide more details?
>> 
>> IIRC, the first one was pycxx.  The build faild during the config
>> step.  I uninstalled it (which meant I also had to uninstall pysvn,
>> which I think means that meld is going to stop working).
>
> Thanks for the report. This was migrated to python 3.12 in
> https://bugs.gentoo.org/929486 and indeed it builds fine for me.
>
> However, it is very obvious, *to me*, why it failed for you (even
> without build logs). The package doesn't have a build dependency on the
> dev-python/setuptools package, and python 3.12 removed a standard
> library module (distutils) which is henceforth provided by this package.
> And pycxx doesn't use pep517 mode either.
>
> It's a trivial fix. You would have seen a build error that looked
> something like
>
> ModuleNotFoundError: No module named 'distutils'

Ah, thanks for taking care of that.

I would have put more time into figuring out that (and similar upgrade
issues) and filing bug reports, but I'm right in the middle of
migrating 400 projects from SVN to Gerrit/Git. It's going about as
well as could be hoped, but...

[A smarter person would not have allowed a major update like that to
proceed in the middle of a big fire-drill.]

Re: [gentoo-user] MPV not compiling

[Jack]

On 6/5/24 11:58 AM, Matthew Brooks wrote:

Can't work out how to reply to the message from John about this, as I wasn't 
subscribed to the list before, but I'm posting more details on mpv's 
compilation failure. The main error seems to be:
locale.Error: unsupported locale setting

I'm attaching the emerge info and build log.

What is your current locale, and which do you have available?

Re: [gentoo-user] MPV not compiling

[Matthew Brooks]

On Wed, 5 Jun 2024 12:03:52 -0400
Jack  wrote:

> On 6/5/24 11:58 AM, Matthew Brooks wrote:
> > Can't work out how to reply to the message from John about this, as I 
> > wasn't subscribed to the list before, but I'm posting more details on mpv's 
> > compilation failure. The main error seems to be:
> > locale.Error: unsupported locale setting
> >
> > I'm attaching the emerge info and build log.  
> What is your current locale, and which do you have available?
> 
According to "eselect locale list" it's these:
Available targets for the LANG variable:
  [1]   C
  [2]   C.utf8
  [3]   en_US.utf8 *
  [4]   ja_JP.utf8
  [5]   POSIX
  [ ]   (free form)

/etc/locale.gen contains:
en_US.UTF-8 UTF-8
ja_JP.UTF-8 UTF-8

Re: [gentoo-user] python 3.12 update

[byte . size226]

I've been lurking in the background, partly amused and partly frustrated 
at the arguments being thrown, but with the risk of exacerbating this 
further I'm going to throw in my two cents (or pence in this corner of 
the world).


I'll start by saying this wasn't the smoothest Python upgrade relative 
to previous ones, I think many of us can agree on that.


In my case, I had completely forgotten about it until 1 June when 
portage exploded with complaints. The common culprit was obviously 
Python from the change flags. Then I remembered reading the news a few 
weeks back, and went down the 3-step route. Maintaining 3.11 and letting 
other non-related upgrades complete with:



*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11


was the first step which was absolutely fine and did not break anything. 
Then I dealt with Python as per the news item. Unfortunately, some 
packages weren't migrated, for various reasons, and I ha

d two options:

  1) keep my newly introduced flags above to maintain compatibility and 
migrate at a later point when things are more polished, or


  2) remove those packages, if I don't need to use them day to day, and 
install them at a later point when they're ready.


I *personally* chose (2) as neither were mission critical for me, but 
this is a choice I made consciously. (1) would have worked just as well.


Which nicely takes me to this:

On 05/06/2024 14:11, Joost Roeleveld wrote:

Here is the problem.
Not all "system-critical" packages were stabilised before this change
was pushed.


Which packages do you consider to have been 'system critical' in this 
instance and why do you classify them as such? Without establishing a 
definition, anything can be 'ssytem-critical' from a subjective point of 
view.


I tend to agree with Rich's definition:

> anything system-critical (as in you won't be able to boot or use
> the package manager/etc)


I'd
hate to take 'centrist' position but:

1) Could this have been a smoother sail? Yes, I think so, given that on 
1 June about half of the _tracked_ bug items in the overarching 
compatibility tracking bug item were not ready. It probably would have 
merited for the switchover to be deferred. But also:


2) Was anything really 'broken'? Most certainly no, going by the above 
definition and the fact that the news item provided for a very clear 
pathway to maintain compatibility that was essentially a two-line solution.


In fact, none of what happened was completely outside of my 
expectations. With Gentoo being self-described as a 'meta-distribution' 
due to 'no two installs being truly identical', conflicts arising from 
USE flag changes are relatively common, at least in my experience. And 
this is part and parcel of having the flexibility that Gentoo offers us. 
I've learnt to deal with it and more often than not the solution is 
reasonably straightforward. I most cert
ainly do not expect of Gentoo to 
behave the same as 'apt dist-upgrade' on Debian or equivalent in binary 
distros.


If the latter is your expectation, have you considered whether Gentoo 
would be the most appropriate choice for maintaining those 21 or so 
hosts? This isn't to say it's a bad choice...


In my (personal) experience of 15+ years of using Gentoo, I've never had 
a truly irrecoverable situation, despite having quirks. In fact, I was 
expecting a much more difficult changeover to the 23 profiles, and even 
that far exceeded my expectations.


Perhaps it does boil down to having different expectations. And if 
that's the case - is Gentoo the most appropriate for you personally or 
your use case?


- Victor


signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: python 3.12 update

[Grant Edwards]

On 2024-06-05, byte.size...@simplelogin.com  
wrote:


> 2) Was anything really 'broken'? Most certainly no, going by the above 
> definition and the fact that the news item provided for a very clear 
> pathway to maintain compatibility that was essentially a two-line solution.

I think that build failures caused by the 3.11 ⇒ 3.12 count as
breakage. There was some, but not a lot of that.

What I found misleading (and tripped over) was the implication that
the three step migration process outlined in the news item had a
reasonable likelyhood of working for a large percentage of users.

If the new items had warned that anybody using one of 
packages that won't work with 3.12 are going to have to stop after
step 1 until those packages have been brought "up to date" so that
they can build with 3.12.  Had I known that, I wouldn't have tried the
three step migration and would have simply postponed the upgrade.

--
Grant

Re: [gentoo-user] Re: python 3.12 update

[Arve Barsnes]

On Wed, 5 Jun 2024 at 20:05, Grant Edwards  wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
>
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.

Maybe I've been using gentoo too long, but I never assumed these three
steps were a 'single upgrade' recipe, I assumed each step were to be
undertaken as the portage tree allowed.

Reading the news item again, I see that no such thing is implied, but
perhaps it should have been? Otherwise, what is the point of these
steps as opposed to the automatic upgrade portage initially attempts?

The only way it is safer is if you have a complete functioning system
between each step, so I naturally assumed that there could be waiting
between each step to allow the tree to come to an upgradeable state.
Maybe some wording to that effect should be added when the 3.13 update
rolls around.

Either way, I went for the "bunch of 3.11 stuff in package.use" since
I "enjoy" that kind of process, so I wasn't impacted.

Regards,
Arve

Re: [gentoo-user] MPV not compiling

[netfab]

Something must be mis-configured on your system.

From your build.log, at the beginning of the configure phase we find :
> locale: Cannot set LC_ALL to default locale: No such file or directory

For me, « default locale » is the locale defined by the LANG
environment variable.

From your mpv-environment.txt file :
> declare -x LANG="en_US.utf8 ja_JP.utf8"

I think that should be :
> declare -x LANG="en_US.utf8"

You should check your configuration files in /etc/env.d.

[gentoo-user] Re: python 3.12 update

[Grant Edwards]

On 2024-06-05, Arve Barsnes  wrote:
> On Wed, 5 Jun 2024 at 20:05, Grant Edwards  wrote:
>> What I found misleading (and tripped over) was the implication that
>> the three step migration process outlined in the news item had a
>> reasonable likelyhood of working for a large percentage of users.
>>
>> If the new items had warned that anybody using one of 
>> packages that won't work with 3.12 are going to have to stop after
>> step 1 until those packages have been brought "up to date" so that
>> they can build with 3.12.  Had I known that, I wouldn't have tried the
>> three step migration and would have simply postponed the upgrade.
>
> Maybe I've been using gentoo too long, but I never assumed these
> three steps were a 'single upgrade' recipe, I assumed each step were
> to be undertaken as the portage tree allowed.
>
> Reading the news item again, I see that no such thing is implied,
> but perhaps it should have been? Otherwise, what is the point of
> these steps as opposed to the automatic upgrade portage initially
> attempts?

I wondered about that too. But, I decided that whoever wrote the news
item probably knew what they were talking about, and chose the "Safer
upgrade procedure". As you said, there's no mention of waiting between
steps for various packages to catch up:

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

*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11

Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:

*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_12

Finally, switch to the final version and upgrade:

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



--
Grant

Re: [gentoo-user] python 3.12 update

[Eli Schwartz]

On 6/5/24 1:12 PM, byte.size...@simplelogin.com wrote:
> On 05/06/2024 14:11, Joost Roeleveld wrote:
>> Here is the problem.
>> Not all "system-critical" packages were stabilised before this change
>> was pushed.
> 
> Which packages do you consider to have been 'system critical' in this
> instance and why do you classify them as such? Without establishing a
> definition, anything can be 'ssytem-critical' from a subjective point of
> view.
> 
> I tend to agree with Rich's definition:
> 
>> anything system-critical (as in you won't be able to boot or use
>> the package manager/etc)
> 
> 
> I'd
> hate to take 'centrist' position but:
> 
> 1) Could this have been a smoother sail? Yes, I think so, given that on
> 1 June about half of the _tracked_ bug items in the overarching
> compatibility tracking bug item were not ready. It probably would have
> merited for the switchover to be deferred. But also:


I would take a somewhat less than centrist position, but:

Let's take the number of ebuilds in the gentoo repository that declare
they depend on some version of python:

# ebuild files declaring the use of python eclasses
git grep --name-only PYTHON_COMPAT '*.ebuild'|

# filtered by category/pkg and deduplicated
awk -F/ '{print $1"/"$2}'| sort -u |

# ... and count them
wc -l


For a total of 2954 packages that needed to somehow be ported.

Now here's the list, as of right this second, of packages that still
need to be ported to support 3.12. This is the same information used to
create the tracker bug:


curl -Ls https://qa-reports.gentoo.org/output/gpyutils/311-to-312.txt  |
wc -l


278 packages.

The list includes packages that optionally use python, packages that
only use python when building with FEATURES=test, vim which I can
actually confirm I have a patch queued to sync the live ebuild, because
its presence here is a false positive caused by that, etc -- but most of
them probably need python at runtime on people's systems, which is fair
enough.

That's about 1/10 of packages in gentoo. A bit less, really. Some
notable standouts are:

- libreoffice-bin, depends solely on the cpython interpreter
- kicad
- mumble
- firefox ESR, but not the latest version, depends solely on the
  interpreter


freecad works with py3.12 but you have to use qt6. This was updated on
June 3.



A lot of these packages are science software, especially.

Regarding the tracker bug itself, there's a total of 949 bugs linked to
it. 293 of them are open today. Including all open and closed ones
together, it's only a third of the total number of python packages in
gentoo.

The tracker bug existed basically to track the laggard packages.


> 2) Was anything really 'broken'? Most certainly no, going by the above
> definition and the fact that the news item provided for a very clear
> pathway to maintain compatibility that was essentially a two-line solution.
> 
> In fact, none of what happened was completely outside of my
> expectations. With Gentoo being self-described as a 'meta-distribution'
> due to 'no two installs being truly identical', conflicts arising from
> USE flag changes are relatively common, at least in my experience. And
> this is part and parcel of having the flexibility that Gentoo offers us.
> I've learnt to deal with it and more often than not the solution is
> reasonably straightforward. I most cert
> ainly do not expect of Gentoo to behave the same as 'apt dist-upgrade'
> on Debian or equivalent in binary distros.


+1

-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Eli Schwartz]

On 6/5/24 2:05 PM, Grant Edwards wrote:
> What I found misleading (and tripped over) was the implication that
> the three step migration process outlined in the news item had a
> reasonable likelyhood of working for a large percentage of users.
> 
> If the new items had warned that anybody using one of 
> packages that won't work with 3.12 are going to have to stop after
> step 1 until those packages have been brought "up to date" so that
> they can build with 3.12.  Had I known that, I wouldn't have tried the
> three step migration and would have simply postponed the upgrade.


FWIW, I do think that for a large percentage of users, the lagging
packages simply aren't relevant to their use cases so it would indeed work.

Regardless, the purpose of the 3-step process I think is just to ensure
that portage doesn't trip while scheduling the rebuilds. If you are
getting dependency conflicts with the one-step process (emerge -puDU
@world) then steps 2 and 3 are likely not going to be able to be fully
carried out.


-- 
Eli Schwartz


OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 13:28, Rich Freeman wrote:

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.


What I at least try to do is use "autounmask-write", or whatever the 
appropriate option is. This does I believe flag individual versions of 
whatever.


Then I DON'T let etc-update append the changes to J Random File in 
whatever package... directory is appropriate !!!


I rename the ._ file to usually the name of the package I'm interested 
in, or maybe the current date, or whatever. Point is, I don't get some 
humungous file full of assorted unrelated dependencies. And then when 
I'm bored I go through deleting loads of files maybe 6 months old or 
more. Seeing as the packages have usually been replaced by then, it 
rarely affects anything.


Yes it's a minor pain I have to go through this for pretty much every 
package update if I've got a problem package, but I do a --update once a 
week at most, so it's very little hassle.


And occasionally I'll add the flag to make.conf, instead ... :-)

Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?

Re: [gentoo-user] MPV not compiling

[Matthew Brooks]

On Wed, 5 Jun 2024 20:30:29 +0200
netfab  wrote:

> Something must be mis-configured on your system.
> 
> From your build.log, at the beginning of the configure phase we find :
> > locale: Cannot set LC_ALL to default locale: No such file or directory  
> 
> For me, « default locale » is the locale defined by the LANG
> environment variable.
> 
> From your mpv-environment.txt file :
> > declare -x LANG="en_US.utf8 ja_JP.utf8"  
> 
> I think that should be :
> > declare -x LANG="en_US.utf8"  
> 
> You should check your configuration files in /etc/env.d.
> 
> 
> 

Turns out LANG was getting set to that in make.conf for some reason. Removing 
that got it working.

Thanks!

Re: [gentoo-user] python 3.12 update

[Wols Lists]

On 05/06/2024 13:12, Eli Schwartz wrote:

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


Ie people like me who don't give a monkeys about python, and consider it 
a necessary evil.


As far as I'm concerned, python just happens to be a dependency of 
things I *am* interested in, so any grief updating it is "pure grief and 
no benefit".


That said, I probably haven't run "emerge" since all this shit hit, so I 
haven't noticed anything ... :-)


Cheers,
Wol

Re: [gentoo-user] MPV not compiling

[Matthew Brooks]

On Wed, 5 Jun 2024 20:30:29 +0200
netfab  wrote:

> Something must be mis-configured on your system.
> 
> From your build.log, at the beginning of the configure phase we find :
> > locale: Cannot set LC_ALL to default locale: No such file or directory  
> 
> For me, « default locale » is the locale defined by the LANG
> environment variable.
> 
> From your mpv-environment.txt file :
> > declare -x LANG="en_US.utf8 ja_JP.utf8"  
> 
> I think that should be :
> > declare -x LANG="en_US.utf8"  
> 
> You should check your configuration files in /etc/env.d.
> 
> 
> 

Accidentally hit Reply All instead of just reply, my bad.


Turns out that LANG was getting set to both in make.conf for some reason. 
Removing that got things working.

Thanks!

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Wols Lists wrote:
> On 05/06/2024 13:28, Rich Freeman wrote:
>> Implementing dynamic USE management would take somebody a fair bit of
>> effort, and for all I know it would make every emerge you run take an
>> hour to recompute the dependency tree.  The ability to configure USE
>> flags, along with the ability to dynamically decide the version of
>> dynamically linked packages, makes Gentoo have a dependency tree that
>> is MUCH larger than basically any other distro out there.  This is why
>> portage takes so long to decide what to install compared to basically
>> everything else.
>
> What I at least try to do is use "autounmask-write", or whatever the
> appropriate option is. This does I believe flag individual versions of
> whatever.
>
> Then I DON'T let etc-update append the changes to J Random File in
> whatever package... directory is appropriate !!!
>
> I rename the ._ file to usually the name of the package I'm interested
> in, or maybe the current date, or whatever. Point is, I don't get some
> humungous file full of assorted unrelated dependencies. And then when
> I'm bored I go through deleting loads of files maybe 6 months old or
> more. Seeing as the packages have usually been replaced by then, it
> rarely affects anything.
>
> Yes it's a minor pain I have to go through this for pretty much every
> package update if I've got a problem package, but I do a --update once
> a week at most, so it's very little hassle.
>
> And occasionally I'll add the flag to make.conf, instead ... :-)
>
> Cheers,
> Wol
>
>


Don't forget eix-test-obsolete which will find and list entries that are
no longer needed.  Bad thing is, it doesn't seem to say which file it is
in when you use a directory.  It just says the type of file, *.use,
*.mask, *.keyword etc. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 20:15, Meowie Gamer wrote:

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?



Because they're using USE or whatever to force packages to stay on 3.11, 
because they won't build with 3.12.


So it's not necessarily about USE, but about the tactics people use to 
make emerge work the way they want. It might be MASK, or any of the 
other package... directories.


Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Dale]

Meowie Gamer wrote:
> I must've taken too long to join the mailing list because I missed the first 
> part of whatever's happening here. How did this turn from python 3.12 to a 
> conversation about USE?
>
>


Because depending on what path you took to deal with this, you could end
up with entries in package.use for python 3.11. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: python 3.12 update

[Meowie Gamer]

I see, thanks for clearing it up.

Meowie

[gentoo-user] Re: python 3.12 update

[Grant Edwards]

On 2024-06-05, Wols Lists  wrote:
> On 05/06/2024 13:12, Eli Schwartz wrote:
>> Which I think is fine, if people want that, but not everyone does, so
>> delaying the update altogether might be preferable to those people.
>
> Ie people like me who don't give a monkeys about python, and consider it 
> a necessary evil.

I care quite a bit about Python and do a fair amount of developemnt in
Python. Howver, I don't (at this point) give a monkey's about 3.12 vs
3.11, so I'm just going to delay the 3.12 upgrade on all my machines
except for the one where I got stuck after step 1 of the now-famouse
"3 step upgrade process". :)

That one machine seems to be working fine (though it's still missing a
few packages that I removed because the build failed with 3.12). So
I'm going to leave it where it is (possibly reinstalling the missing
packages as I run into the need for them).

At some point, emerge -auvND will complain because some installed
package doesn't support 3.11 any longer — and then I'll upgrade to
3.12.

--
Grant

Re: [gentoo-user] Re: python 3.12 update

[Joost Roeleveld]

--- Original message ---
From: Grant Edwards 
To: gentoo-user@lists.gentoo.org
Date: Wed, 05 Jun 2024 22:07:06 +0200



On 2024-06-05, Wols Lists  wrote:

On 05/06/2024 13:12, Eli Schwartz wrote:

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


Ie people like me who don't give a monkeys about python, and  
consider it a necessary evil.


I care quite a bit about Python and do a fair amount of developemnt in
Python. Howver, I don't (at this point) give a monkey's about 3.12 vs
3.11, so I'm just going to delay the 3.12 upgrade on all my machines
except for the one where I got stuck after step 1 of the now-famouse
"3 step upgrade process". :)

That one machine seems to be working fine (though it's still missing a
few packages that I removed because the build failed with 3.12). So
I'm going to leave it where it is (possibly reinstalling the missing
packages as I run into the need for them).

At some point, emerge -auvND will complain because some installed
package doesn't support 3.11 any longer — and then I'll upgrade to
3.12.


Except, if you use Python for development, it's slotted, so you can  
install any version you need (as long as it's in portage or an overlay).


The issue here is the devs insistence on upgrading to 3.12 before all  
the packages are ready for this.


In all this, I have yet to see a good reason apart from "Oooh... shiny!"

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Mark Knecht]

On Sat, Jun 1, 2024 at 10:38 PM Dale  wrote:
>
> Howdy, again,
>

Hi Dale,
   As part of a little AI project I'm working on I ran across a relatively
inexpensive ideo you might want to look into. The basic idea is to
use a PXIx -> M.2 E Key card and on that card load an M2. E Key
to SATA adapter.

First, an E Key adapter card:

https://www.amazon.com/Ableconn-PEXM2150E-Express-Adapter-Socket/dp/B07D6ZCBHY

And second, a 6 port E Key to SATA adapter:

https://www.amazon.com/SATA3-0-Adapter-Expansion-Interface-Indicator/dp/B0B75JWXXS

I have NO NO NO idea if this would actually work, or how well it would
work, but
for roughly $60 it might give you a path to the silly number of hard drives
you want
to run. ;-)

In my case I'm looking at this same card, but loaded with a neural network
processor
running Tensorflow Lite.

Anyway, I thought you might be interested.

Cheers,
Mark

Re: [gentoo-user] Re: python 3.12 update

[Rich Freeman]

On Wed, Jun 5, 2024 at 3:33 PM Wols Lists  wrote:
>
> On 05/06/2024 20:15, Meowie Gamer wrote:
> > I must've taken too long to join the mailing list because I missed the 
> > first part of whatever's happening here. How did this turn from python 3.12 
> > to a conversation about USE?
> >
>
> Because they're using USE or whatever to force packages to stay on 3.11,
> because they won't build with 3.12.
>
> So it's not necessarily about USE, but about the tactics people use to
> make emerge work the way they want. It might be MASK, or any of the
> other package... directories.

It is a bit more than that.  Even if you never touch
/etc/portage/package.use, you effectively will have USE flags set on
packages that involve python simply due to the profile (and the change
therein).  That is why the news item has you put -* at the start of
the setting if you're overriding it - otherwise you'll just be
appending to the profile setting.

While these do end up setting USE flags, you should still set the USE
expand variables as directed in the news item and documentation, and
not manipulate the USE flags directly.

-- 
Rich

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Jun 1, 2024 at 10:38 PM Dale  > wrote:
> >
> > Howdy, again,
> >
>
> Hi Dale,
>    As part of a little AI project I'm working on I ran across a
> relatively 
> inexpensive ideo you might want to look into. The basic idea is to 
> use a PXIx -> M.2 E Key card and on that card load an M2. E Key
> to SATA adapter. 
>
> First, an E Key adapter card:
>
> https://www.amazon.com/Ableconn-PEXM2150E-Express-Adapter-Socket/dp/B07D6ZCBHY
>
> And second, a 6 port E Key to SATA adapter:
>
> https://www.amazon.com/SATA3-0-Adapter-Expansion-Interface-Indicator/dp/B0B75JWXXS
>
> I have NO NO NO idea if this would actually work, or how well it would
> work, but
> for roughly $60 it might give you a path to the silly number of hard
> drives you want 
> to run. ;-)
>
> In my case I'm looking at this same card, but loaded with a neural
> network processor
> running Tensorflow Lite.
>
> Anyway, I thought you might be interested.
>
> Cheers,
> Mark


I have some PCIe cards that go up to 12 SATA ports.  In a X1 slot, they
not exactly speedy but they do work pretty well.  I try to balance the
number of drives to help with speed as much as I can.  I also put all
drives in one LVM on one card.  That way if one card stops working, the
whole LVM goes instead of just one or two of three drives.  You have a
idea tho with those two. 

I was digging around Ebay.  Ran up on a used combo and then had a crazy
idea.  I found a ASUS B550-plus AC-HES mobo that is AM4.  I took that
idea and started building a combo with new parts.  CPU, Ryzen 7 5800X
and my little 4 port video card if CPU has no video support.  AMD says
it does.  The mobo has three PCIe X1 slots and a X4 slot.  A SAS card
would work just slower than when in X8 slot but the little PCIe 10 or 12
port cards would work fine.  Gives me 30 drives total at least on the
cards plus the four on the mobo, two goes away with using one of the
PCIe slots most likely.  Bifurcation I think they call it when they
share roadways.

My thinking.  Build above now.  In a year, or two, I can build either
the rig I was working on a lot cheaper or a even newer rig that is even
faster if say AM6 socket CPUs have arrived.  Then the rig above with
some hard drive options can become the new NAS box.  I can then move
some drives out of the main rig, newer one a year or so down the road,
and not need so many PCIe slots in the main rig, hopefully anyway.  I
may even warm up to the idea of using USB for hard drives.  I'm
surprised hard drives don't come with USB connections instead of SATA
already.

The only downside, the NAS box will have to run 24/7 as well.  Then I
have two puters running all the time.  To offset that, the combo above
does pull a lot less power than my current rig.  Not a huge difference
but fair amount.  Odds are the build a year or so down the road will
also pull less power than current rig.  I could end up with same amount
of power usage or less, even with two running instead of one.

I said it was a crazy idea.  LOL   This time tho, I'm sort of planning
ahead instead of just coming up with a temporary fix all the time.  This
is also a little cheaper but still faster.  Another big thing, newer as
well.  My current rig is about 10 or 11 years old.  It may run another 5
or so years but could go out anytime.  At least I'll have a newer rig
not likely to let the smoke out.  Plus have a path to a more sane
setup.  I just need to get one of those chia harvester cases that holds
40 or so hard drives.  ROFLMBO

Dale

:-)  :-)