4 ms·

I'm talking about this: The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by

by _V_ 3y ago

I'm talking about this: The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by net-libs/nodejs-20.5.1::gentoo # required by www-client/firefox-102.15.0::gentoo # required by @selected # required by @world (argument) =dev-libs/openssl-1.1.1v And many many many more packages. I went through like 20 yesterday and created custom ebuilds without mentions to slot :0= in ebuild, but there is plenty more.

terinjokes 3y ago
Something seems unusual about your system. Are you using an unusual profile or heavily customized make.conf? net-libs/nodejs-20.5.1 is satisfied with dev-libs/openssl-3.0.10 out of the box here. I have a fully updated world with a KDE desktop, and don't have OpenSSL 1.1 installed at all.
- _V_ 3y ago
  eselect profile list says I have selected the default one: default/linux/amd64/17.1 (stable) * I would not say it is something unusual... But funny thing is that if I emerge that one specific package with -1, it does not pull this dependency. It seems like something broken inside the portage.
nubinetwork 3y ago
Please report any incompatible packages or any that need updating. I don't happen to see any open/related bugs for nodejs.
- _V_ 3y ago
  I generaly don't bother reporting errors like this, I just fix it locally and push things into my overlay/forks and I'm done with it.
  - simoncion 3y ago
    It might be your local ebuilds that are the cause of your problem. As an example, here are the versions of firefox, nodejs, and openssl installed on my system: $ eix -I --format '<installedversions:EQNAMEVERSION>' nodejs -o firefox -o dev-libs/openssl =dev-libs/openssl-3.1.2 =net-libs/nodejs-20.5.1 =www-client/firefox-102.15.0 I have the same nodejs version and firefox version as you, but neither of them require openssl 1.x.
    - _V_ 3y ago
      It seems like portage did remember that those packages were built against that openssl version - when running as "emerge -DavuUN @world @system --changed-deps" the problem went away :-) Probably some caching issue/race condition in portage...
halz 3y ago
I experienced a similar sounding issue, but was able to decipher the blocked emerge output from portage to find that app-crypt/tpm2-tss-engine was blocking the whole system from getting onto openssl-3. Once I dropped tpm2-tss-engine, things went forward swimmingly. No other unmasking/masking of anything was needed.
- Zambyte 3y ago
  > I experienced a similar sounding issue This is why we need Lojban

by _V_ 3y ago

terinjokes 3y ago

Something seems unusual about your system. Are you using an unusual profile or heavily customized make.conf? net-libs/nodejs-20.5.1 is satisfied with dev-libs/openssl-3.0.10 out of the box here. I have a fully updated world with a KDE desktop, and don't have OpenSSL 1.1 installed at all.

_V_ 3y ago
eselect profile list says I have selected the default one: default/linux/amd64/17.1 (stable) * I would not say it is something unusual... But funny thing is that if I emerge that one specific package with -1, it does not pull this dependency. It seems like something broken inside the portage.

nubinetwork 3y ago

Please report any incompatible packages or any that need updating. I don't happen to see any open/related bugs for nodejs.

_V_ 3y ago
I generaly don't bother reporting errors like this, I just fix it locally and push things into my overlay/forks and I'm done with it.
- simoncion 3y ago
  It might be your local ebuilds that are the cause of your problem. As an example, here are the versions of firefox, nodejs, and openssl installed on my system: $ eix -I --format '<installedversions:EQNAMEVERSION>' nodejs -o firefox -o dev-libs/openssl =dev-libs/openssl-3.1.2 =net-libs/nodejs-20.5.1 =www-client/firefox-102.15.0 I have the same nodejs version and firefox version as you, but neither of them require openssl 1.x.
  - _V_ 3y ago
    It seems like portage did remember that those packages were built against that openssl version - when running as "emerge -DavuUN @world @system --changed-deps" the problem went away :-) Probably some caching issue/race condition in portage...

halz 3y ago

I experienced a similar sounding issue, but was able to decipher the blocked emerge output from portage to find that app-crypt/tpm2-tss-engine was blocking the whole system from getting onto openssl-3. Once I dropped tpm2-tss-engine, things went forward swimmingly. No other unmasking/masking of anything was needed.

Zambyte 3y ago
> I experienced a similar sounding issue This is why we need Lojban