Chromium has been a heaping pile of crash these days so I've been
running update every few days to try to get a working version.


Ok, apparently gcj is not a thing anymore and has broken libidn (iirc), 

I got around that with a useflag...

As always, Gentoo finds new and more bizare ways to FAIL.

I noticed that udev wasn't building which is instantly a 3-alarm fire,
if not worse...

Library dl found: YES

../systemd-249/meson.build:910:0: ERROR: C shared or static library
'crypt' not found

A full log can be found at /var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86/meson-logs/meson-log.txt
 * ERROR: sys-fs/udev-249-r2::gentoo failed (configure phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line  127:  Called src_configure
 *   environment, line 4090:  Called multilib-minimal_src_configure
 *   environment, line 2862:  Called multilib_foreach_abi 'multilib-minimal_abi_src_configure'
 *   environment, line 3115:  Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2792:  Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2790:  Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
 *   environment, line  710:  Called multilib-minimal_abi_src_configure  *   environment, line 2856:  Called multilib_src_configure
 *   environment, line 3341:  Called meson_src_configure
 *   environment, line 2726:  Called die
 * The specific snippet of code:
 *       "${mesonargs[@]}" ) || die
 *
 * If you need support, post the output of `emerge --info '=sys-fs/udev-249-r2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-fs/udev-249-r2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-fs/udev-249-r2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-fs/udev-249-r2/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249' sys-fs/udev-249-r2/temp/build.log lines 156-206/206 (END)


Libxcrypt, I guess???


Ok, so what's wrong with libxcrypt...

make[2]: Leaving directory '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
make[1]: Leaving directory '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'

Completed installing sys-libs/libxcrypt-4.4.25 into /var/tmp/portage/sys-libs/libxcrypt-4.4.25/image

 * Final size of build directory: 11572 KiB (11.3 MiB)
 * Final size of installed tree:   1808 KiB ( 1.7 MiB)

 * checking 38 files for package collisions
 * This package will overwrite one or more files that may belong to other
 * packages (see list below). You can use a command such as `portageq
 * owners / <filename>` to identify the installed package that owns a
 * file. If portageq reports that only one package owns a file then do
 * NOT file a bug report. A bug report is only useful if it identifies at
 * least two or more packages that are known to install the same file(s).
 * If a collision occurs and you can not explain where the file came from
 * then you should simply ignore the collision since there is not enough
 * information to determine if a real problem exists. Please do NOT file
 * a bug report at https://bugs.gentoo.org/ unless you report exactly
 * which two packages install the same file(s). See
 * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how
 * to solve the problem. And once again, please do NOT file a bug report
 * unless you have completely understood the above message.
 *
 * Detected file collision(s):
 *
 *      /usr/include/crypt.h
 *      /lib64/libcrypt.so.1
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * sys-libs/glibc-2.33-r7:2.2::gentoo
 *      /lib64/libcrypt.so.1
 *
 * Package 'sys-libs/libxcrypt-4.4.25' NOT merged due to file collisions.
 * If necessary, refer to your elog messages for the whole content of the
 * above message.


Obviously, anything associated with glibc is protected by the DO NOT
TOUCH ANYTHING ASSOCIATED WITH GLIBC FOR ANY REASON, EVER. rule...

So I'm roadblocked. =(

--
Beware of Zombies. =O
#EggCrisis #BlackWinter
White is the new Kulak.
Powers are not rights.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2 Sep 2021 10:35:49 -0400, Alan Grimes wrote:

Chromium has been a heaping pile of crash these days so I've been
running update every few days to try to get a working version.

Ok, apparently gcj is not a thing anymore and has broken libidn (iirc), 

I got around that with a useflag...

As always, Gentoo finds new and more bizare ways to FAIL.

I noticed that udev wasn't building which is instantly a 3-alarm fire,
if not worse...

Library dl found: YES

../systemd-249/meson.build:910:0: ERROR: C shared or static library
'crypt' not found

A full log can be found at /var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86/meson-logs/meson-log.txt
 * ERROR: sys-fs/udev-249-r2::gentoo failed (configure phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line  127:  Called src_configure
 *   environment, line 4090:  Called multilib-minimal_src_configure  *   environment, line 2862:  Called multilib_foreach_abi 'multilib-minimal_abi_src_configure'
 *   environment, line 3115:  Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2792:  Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
 *   environment, line 2790:  Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
 *   environment, line  710:  Called multilib-minimal_abi_src_configure  *   environment, line 2856:  Called multilib_src_configure
 *   environment, line 3341:  Called meson_src_configure
 *   environment, line 2726:  Called die
 * The specific snippet of code:
 *       "${mesonargs[@]}" ) || die
 *
 * If you need support, post the output of `emerge --info '=sys-fs/udev-249-r2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-fs/udev-249-r2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-fs/udev-249-r2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-fs/udev-249-r2/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-fs/udev-249-r2/work/systemd-249' sys-fs/udev-249-r2/temp/build.log lines 156-206/206 (END)

Libxcrypt, I guess???

Ok, so what's wrong with libxcrypt...

make[2]: Leaving directory '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'
make[1]: Leaving directory '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_nocompat-abi_x86_64.amd64'

Completed installing sys-libs/libxcrypt-4.4.25 into /var/tmp/portage/sys-libs/libxcrypt-4.4.25/image

 * Final size of build directory: 11572 KiB (11.3 MiB)
 * Final size of installed tree:   1808 KiB ( 1.7 MiB)

 * checking 38 files for package collisions
 * This package will overwrite one or more files that may belong to
other
 * packages (see list below). You can use a command such as `portageq
 * owners / <filename>` to identify the installed package that owns a
 * file. If portageq reports that only one package owns a file then do
 * NOT file a bug report. A bug report is only useful if it identifies
at
 * least two or more packages that are known to install the same
file(s).
 * If a collision occurs and you can not explain where the file came
from
 * then you should simply ignore the collision since there is not enough
 * information to determine if a real problem exists. Please do NOT file
 * a bug report at https://bugs.gentoo.org/ unless you report exactly
 * which two packages install the same file(s). See
 * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how
 * to solve the problem. And once again, please do NOT file a bug report
 * unless you have completely understood the above message.
 *
 * Detected file collision(s):
 *
 *      /usr/include/crypt.h
 *      /lib64/libcrypt.so.1
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * sys-libs/glibc-2.33-r7:2.2::gentoo
 *      /lib64/libcrypt.so.1
 *
 * Package 'sys-libs/libxcrypt-4.4.25' NOT merged due to file
collisions.
 * If necessary, refer to your elog messages for the whole content of
the
 * above message.

Obviously, anything associated with glibc is protected by the DO NOT
TOUCH ANYTHING ASSOCIATED WITH GLIBC FOR ANY REASON, EVER. rule...

So I'm roadblocked. =(

Did you read the news item from 23/7/21? It will have popped up when you synced.

https://www.gentoo.org/support/news-items/2021-07-23-libxcrypt-migration.html


--
Neil Bothwick

You couldn't get a job as a firing squad target.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmEw8BEACgkQ92eFu0QS MJje1g/9HjMTVsCzl7rpoSvr3P7dizRuI4vCkuYddNzFD6hgxrj6ThtxBGcy+Bxi J4VVTIEu9fmqtDkqDDF12eQlaGzMNzxCdAXhpU6Kp7RVQZ6/gRHBQeIJJvNy2zjm nkikVbCyhit5C88xOD9hSi3KLAqQefQup3qToDeiUPv3nomm9+ds0rUYhep3Lla2 /JQVPszccKRiJg0bWis6bsfeP/IkKk+FdO807jpY+37jzOSurmmxrPpgB9q+oxTQ SOjoHfn5bze7O5ry8lYlmW1V7DI0cAPSEs24ysZGZn9jjbcpVRxDgQgqgsQWqCxL 7iPZAdk6kQYf55FLsrCN4LjMitElIgNijQ9u3bYLpqT/CCCqneBURK4p45PavPd1 2LZB1sRFLb2OSAnwChqc1KX1FRwAg+57uIMq7z5OSYDnwPskFwoes3b9w0KIxSY7 eSBK46Hgz9DHR24vIhGa+0hf9qssWsYeZifBOpHmeI5cy3QeAxe/u1tfG0u34JKE uG07R2BHD4G6mRtueKhVK/yt6L3YAAjpZrYQ8tF+kyGPzaGDx3K4C20MN7xbNDtg D6ezxZmYC2z+H7ho8+5SQyEgMaYt6lwFWtB36tcSQRJY8S/qRLCYcVie/WE9vCSV Q3QbjH9rR1X+6bbv5Q8nFBSAgUTZ69bJaIonhkHtkNg2zgBYNsQ=
=SIqo
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Replied to the list.

On Thu, 2 Sep 2021 15:50:37 -0400, Alan Grimes wrote:

Neil Bothwick wrote:

If you wish to manually migrate now, there are a series
of steps described on the wiki (see below), but the outline is:
* unforce the crypt USE flag of sys-libs/glibc and disable it
* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt and enable it
* unmask ~virtual/libcrypt-2

###

Glibc simply DOES NOT HAVE a "crypt" useflag... so FALSE!!!!

Yes it does, but only on the testing version. If you are running stable,
you won't have it. But if you are running stable, why are you trying to
emerge libxcrypt-4.4.25?

It appears that your problem may be caused by trying to mix stable and
testing packages with inter-dependencies.


--
Neil Bothwick

All generalizations are false, including this one.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmExMEMACgkQ92eFu0QS MJhu8xAAsmQQH141aUrti90vp5+/qD9QYnc6Atuur2Tbt+fCjYQSZgMbn8VySCVg S5OXiG58Xz/cXN+XqgTKYJsVakqMxE01Mbh7/+2OXDJuiQvVfI0LUOKvmEAr3HuH RRikJLmsKUWZETAGEjLwboOawEFKnGKsVp3F71vkrp1kbPAeBNAfOacrgqBA3CJR Uddj5eOp1rA4Yq6j6fSpt5U2yp7E2FoUhCNs8xv5sIy+Npqy3svSQQq3lkHZgUCR tTLyoZpryr1Gb/RABvpyvwAJxb3oBUb2+Rq45CA+Jk2QYmh5KhDjgCp/DWXNZdiS mOHWIqDtidtcVWC2uQpa9CrotewG5q4x9tmI7WjsVvqny6OJ1KmEY5jUNlJzjw3F 5uY0pgfUIyp4BiFPylXzF/Jap9+yTtYAkygRrOvfTL3MkEVUmbZglqeHj87syHAp SWjiMtn0HejNg9T+5R2VtftosBtVRI1Cg9ShmjEwdjy4xvBHFyUu2a/m/e9W27bz I4QYaBBhx2KBY31wj92wrbAmEJL19/jFZknpfnLqHBwcmkccwsH4L94el3RvYtDf B/Zh+/zSpxT4zsmL13tg0JNOsVcaFrkXfuA8zA0oQ1YESrQuI2n7gFuZ/AAzI5er rGe+4LpVJmYGsitzMJmN1Cb9iiprLvIMyVQb+kRhjtPyqBYp/CM=
=wbt2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Thu, 02 Sep 2021, Neil Bothwick wrote:

Yes it does, but only on the testing version. If you are running stable,
you won't have it.

I beg to differ on that point:

$ cd $(portageq get_repo_path / gentoo)
$ for f in sys-libs/glibc/glibc-*.ebuild; do \
if grep -q 'KEYW.* amd64' "$f"; then \
printf "${f##*\/}:"; \
sed -n -e 's/IUSE.*\( +\?crypt \).*/\1/p' "$f"; \
fi; \
done
glibc-2.25-r11.ebuild:glibc-2.30-r9.ebuild: +crypt
glibc-2.31-r7.ebuild: +crypt
glibc-2.32-r8.ebuild: +crypt
glibc-2.33-r1.ebuild: +crypt
glibc-2.33.ebuild: +crypt

$ [same as above but with 'KEYW.* ~amd64']:
glibc-2.33-r6.ebuild: +crypt
glibc-2.33-r7.ebuild: +crypt
glibc-2.34.ebuild: +crypt
glibc-9999.ebuild: +crypt

Repo synced earlier today.

HTH,
-dnh

--
printk(KERN_ERR "happy meal: Eieee, rx config register gets greasy fries.\n");
linux-2.6.19/drivers/net/sunhme.c

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Thu, 02 Sep 2021, David Haller wrote:

On Thu, 02 Sep 2021, Neil Bothwick wrote:

Yes it does, but only on the testing version. If you are running stable, >>you won't have it.

I beg to differ on that point:

$ cd $(portageq get_repo_path / gentoo)
$ for f in sys-libs/glibc/glibc-*.ebuild; do \
if grep -q 'KEYW.* amd64' "$f"; then \
printf "${f##*\/}:"; \
sed -n -e 's/IUSE.*\( +\?crypt \).*/\1/p' "$f"; \
fi; \
done
glibc-2.25-r11.ebuild:glibc-2.30-r9.ebuild: +crypt
glibc-2.31-r7.ebuild: +crypt
glibc-2.32-r8.ebuild: +crypt
glibc-2.33-r1.ebuild: +crypt
glibc-2.33.ebuild: +crypt

$ [same as above but with 'KEYW.* ~amd64']:
glibc-2.33-r6.ebuild: +crypt
glibc-2.33-r7.ebuild: +crypt
glibc-2.34.ebuild: +crypt
glibc-9999.ebuild: +crypt

Repo synced earlier today.

Ah yes, of course there is this:

$ grep -r sys-libs/glibc.*crypt profiles/ profiles/base/package.use.force:<sys-libs/glibc-2.33-r2 crypt profiles/base/package.use.mask:>=sys-libs/glibc-2.33-r2 crypt

-dnh

--
panic("huh?\n");
linux-2.2.16/arch/i386/kernel/smp.c

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2 Sep 2021 23:49:40 +0200, David Haller wrote:

Yes it does, but only on the testing version. If you are running
stable, you won't have it.

I beg to differ on that point:

My bad, I was looking in the wrong part of the eix output.

It seems a trip to Barnard Castle is in order...


--
Neil Bothwick

Modulation in all things.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmExS/oACgkQ92eFu0QS MJha8g//dWVQotmGWrO57HWSKjNzLWLSSS+HOKO0KqaNGq2OJGzgMUY3WpyuyrCf AE25Rci5x5kd566+8ezO5YxppuC+lgi730/PjZBaPLjgNXYStJxd8lqusLNPkFX7 AFuTJDgx8+pANVp56vL80gERsL3RaTnwLvG+lD5OEkQ4vrXMMIXvNFLi+bQCS3NA HbsIUi/62xFNhaLyEtEe1Ftlmhsw+L4LYxl0bwtqVnwzC8UuPIuHFvqdCEKmjhii iHLbWfVTwd53LOk3W+gr/GgfETD2I5iPEf7sA0B+XYFVxuWBvWE1w/5DO7n3/k/X zZSd3EdjtqS7/5k7NDAaekGrWC2zFud+Qd6T51irQxt2tecTi6lTxwfu5JewFgum KcGEFy5IHglDLn89pOgZeZJetPgq6+GQPZISscXVolcZ6dD6InKE7J85h9pChnL/ pSIRlmUjFginDEsvAdEC7QLQYbSnmtRRNLfyzm5wGwleCIvfOfnW76m9Lqn4L5Dg euBf0DLmTbUQLaaLQSmeDEX+rVun+PUL68+dsJ7NNULDg99J8N0HO2FY0HDfENnh btPQiukV19b/Wx1PzUFqjKhFDNq5TXDl/QmSFPzSRWIyZR19Q89dW8iPimY/Aa5j unqOE8V0HJLnBUgm2eIEkkKFjg2QDcwaA+e8R9P5UMnOHq61Ftw=
=lyLW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/09/2021 23:11, Neil Bothwick wrote:

On Thu, 2 Sep 2021 23:49:40 +0200, David Haller wrote:

Yes it does, but only on the testing version. If you are running
stable, you won't have it.

I beg to differ on that point:

My bad, I was looking in the wrong part of the eix output.

It seems a trip to Barnard Castle is in order...

You might just need a case of BrewDog ...

Cheers,
Wol

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)