Re: [gentoo-user] network do not come up after booting, only manual reloading (systemd-networkd)

[Canek Peláez Valdés]

On Mon, Sep 6, 2021 at 4:01 PM antlists  wrote:
[...]

> > /etc/systemd/network/20-wirded.network:
>   ^
>
> Typo? Unimportant? Significant?
>

The filename is only used to lexicographically sort the .network files; it
doesn't make a difference.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] network do not come up after booting, only manual reloading (systemd-networkd)

[Canek Peláez Valdés]

On Mon, Sep 6, 2021 at 2:46 PM Tamer Higazi  wrote:
[...]

> /etc/systemd/network/20-wirded.network:

[...]

That looks fine to me.

for enp7s0 there is no other network file.
>

That is as it should be.

I think with THIS systemd version, the whole problem is, that the
> configuration will be done before the devices are made and renamed to
> enp6s0 and enp7s0.
>

I don't think so; the renaming of ethernet devices happens really early,
and systemd-networkd detects it automatically (journal -b -g enp6s0 should
show "enp6s0: renamed from eth0" as first log line, and then
systemd-networkd detecting it).

The problem is, how to solve it 
>

Try adding this to /etc/systemd/network/20-wirded.network, at the end:

[Link]
RequiredForOnline=false

but this is a workaround; everything should work automagically.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] haven't been able to build android-tools for months

[cal]

On 9/6/21 12:23 PM, n952162 wrote:

>>
>> Given the error message implies a compiler error, perhaps try upgrading
>> sys-devel/gcc first?
>>
> 
> Aggh!
> 
> 00~/adm/gentoo/emerged>eselect gcc list
>  [1] x86_64-pc-linux-gnu-9.3.0 *
>  [2] x86_64-pc-linux-gnu-10.3.0
> 
> 
> $ eselect news list | grep gcc
> 
> doesn't turn up anything.  When should/may one upgrade?
> 
> Thank you for the tip!   That's surely what's going on.

https://wiki.gentoo.org/wiki/Upgrading_GCC (note: most of the content
here appears to be related to upgrading to GCC 5.x).

Like the kernel, new versions of GCC are automatically pulled in, but
you have to eselect the new one manually (I don't know the reason; I
assume it is to avoid leaving the user with a broken compiler).
Personally, I just check the emerge output to see if a new version of
GCC was merged, and if so, I eselect it and rebuild libtool as described
on the wiki.

cal

Re: [gentoo-user] network do not come up after booting, only manual reloading (systemd-networkd)

[antlists]

On 06/09/2021 20:45, Tamer Higazi wrote:

Dear Dr. Valdés,

/etc/systemd/network/20-wirded.network:

 ^

Typo? Unimportant? Significant?

Cheers,
Wol

Re: [gentoo-user] haven't been able to build android-tools for months

[antlists]

On 06/09/2021 20:23, n952162 wrote:

Aggh!

00~/adm/gentoo/emerged>eselect gcc list
  [1] x86_64-pc-linux-gnu-9.3.0 *
  [2] x86_64-pc-linux-gnu-10.3.0


$ eselect news list | grep gcc

doesn't turn up anything.  When should/may one upgrade?

Thank you for the tip!   That's surely what's going on.


Others may chime in and say I'm wrong, but my immediate reaction would 
be an "eselect gcc set 2" to upgrade the active gcc. An "emerge 
--depclean" without that could easily leave you with a broken system - 
probably easy enough to fix but still a nightmare until you realise 
what's happened ...


If there's no news, then the change *should* not be a problem.

And if you're at all worried, follow that with an "emerge -e @system". 
Provide it runs successfully ... you will have a working system, even if 
bits of it break. Only downside, it will probably take quite a while to 
run ...


Cheers,
Wol

Re: [gentoo-user] network do not come up after booting, only manual reloading (systemd-networkd)

[Tamer Higazi]

Dear Dr. Valdés,

/etc/systemd/network/20-wirded.network:

[Match]
Name=enp6s0

[Network]
Address=192.168.0.50/24
Gateway=192.168.0.1

DNS=192.168.0.1

for enp7s0 there is no other network file.

/etc/systemd/networkd.conf:

[Network]
#SpeedMeter=no
#SpeedMeterIntervalSec=10sec
#ManageForeignRoutingPolicyRules=yes
#ManageForeignRoutes=yes
#RouteTable=

[DHCPv4]
#DUIDType=vendor
#DUIDRawData=

[DHCPv6]
#DUIDType=vendor
#DUIDRawData=

remained untouched.


I think with THIS systemd version, the whole problem is, that the 
configuration will be done before the devices are made and renamed to 
enp6s0 and enp7s0.


The problem is, how to solve it 

Because when I don't do anything by hand, nothing occurs.
I believe that the configuration is done before everything is full 
available.

(devices created and renamed )

I think I found the solution to my problem, but don't know how to 
implement it.

systemd-udev-settle.service

systemctl list-dependencies --after systemd-networkd:

systemd-networkd.service
● ├─-.mount
● ├─system.slice
● ├─systemd-journald.socket
● ├─systemd-networkd.socket
● ├─systemd-sysctl.service
○ ├─systemd-sysusers.service
○ ├─systemd-udev-settle.service
● ├─systemd-udevd.service
○ └─network-pre.target

Any further ideas I am thankful.


best, Tamer Higazi

references: https://github.com/systemd/systemd/issues/7293

Am 9/5/21 um 9:51 PM schrieb Canek Peláez Valdés:
On Sun, Sep 5, 2021 at 1:36 PM Tamer Higazi > wrote:

[...]

× systemd-networkd-wait-online.service - Wait for Network to be
Configured
  Loaded: loaded
(/lib/systemd/system/systemd-networkd-wait-online.service; enabled;
vendor preset: disabled)
  Active: failed (Result: exit-code) since Sun 2021-09-05
20:22:19
CEST; 11min ago
    Docs: man:systemd-networkd-wait-online.service(8)
    Main PID: 984 (code=exited, status=1/FAILURE) 



Sep 05 20:20:18 tux systemd[1]: Starting Wait for Network to be
Configured...
Sep 05 20:22:19 tux systemd-networkd-wait-online[984]: Timeout
occurred
while waiting for network connectivity.
Sep 05 20:22:19 tux systemd[1]: systemd-networkd-wait-online.service:
Main process exited, code=exited, status=1/FAILURE
Sep 05 20:22:19 tux systemd[1]: systemd-networkd-wait-online.service:
Failed with result 'exit-code'.
Sep 05 20:22:19 tux systemd[1]: Failed to start Wait for Network
to be
Configured.


There's your problem: systemd-networkd-wait-online.service is timing out:

Sep 05 20:22:19 tux systemd-networkd-wait-online[984]: Timeout 
occurred while waiting for network connectivity.


The systemd-networkd-wait-online service runs relatively early and 
waits for *ALL* interfaces it is aware of to be fully configured or 
failed[1], so it probably one of your interfaces is taking too long to 
be ready. Between timing out and you restarting 
systemd-networkd.service, the interface reaches the ready state (or 
fails), and systemd-networkd-wait-online.service doesn't time out anymore.


By your logs, you have two ethernet interfaces: enp6s0 and enp7s0, the 
latter not in use. Do you .network files in /etc/systemd/network/ or 
/run/systemd/network/? Any changes (uncommented lines) in 
/etc/systemd/networkd.conf?


Regards.

[1] 
https://man7.org/linux/man-pages/man8/systemd-networkd-wait-online.8.html 


--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] haven't been able to build android-tools for months

[n952162]

On 9/6/21 8:19 PM, cal wrote:

On 9/6/21 11:14 AM, n952162 wrote:

On any of my 7 gentoo machines:

FAILED: ^[[0mvendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include

-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp

during RTL pass: expand
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:

In member function â~@~Xvoid
android::base::LogdLogger::operator()(android::base::LogId,
android::base::LogSeverity, const char*, const char*, unsigned int,
const char*)â~@~Y:
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:330:6:

internal compiler error: in expand_expr_real_1, at expr.c:10012
   330 | void LogdLogger::operator()(LogId id, LogSeverity severity,
const char* tag, const char* file,
   |  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[107/659] /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include

-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/mapped_file.cpp

ninja: build stopped: subcommand failed.
  * ERROR: dev-util/android-tools-31.0.0_p1::gentoo failed (compile phase):
  *   ninja -v -j2 -l0 failed
  *
  * Call stack:
  * ebuild.sh, line  127:  Called src_compile
  *   environment, line 3186:  Called cmake_src_compile
  *   environment, line 1231:  Called cmake_build
  *   environment, line 1200:  Called eninja
  *   environment, line 1707:  Called die
  * The specific snippet of code:
  *   "$@" || die "${nonfatal_args[@]}" "${*} failed"

I find no mention of this problem here, in the mailing list. There was
one hit in an internet search, but the conclusion was a bug in go, which
I don't have as described.

Anybody seen this?


I have not experienced this issue; android-tools has emerged
successfully (most recently in August) for me.

Per your build.log, you're still using GCC 9.3.0, which isn't even
listed on https://packages.gentoo.org/packages/sys-devel/gcc anymore
(9.4.0 and 10.3.0 are stable on amd64; I'm on 10.3.0 myself).

Given the error message implies a compiler error, perhaps try upgrading
sys-devel/gcc first?



Aggh!

00~/adm/gentoo/emerged>eselect gcc list
 [1] x86_64-pc-linux-gnu-9.3.0 *
 [2] x86_64-pc-linux-gnu-10.3.0


$ eselect news list | grep gcc

doesn't turn up anything.  When should/may one upgrade?

Thank you for the tip!   That's surely what's going on.

Re: [gentoo-user] haven't been able to build android-tools for months

[cal]

On 9/6/21 11:14 AM, n952162 wrote:
> On any of my 7 gentoo machines:
> 
> FAILED: ^[[0mvendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o
> /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
> 
> -O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -MF
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o.d -o
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -c
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp
> 
> during RTL pass: expand
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:
> 
> In member function â~@~Xvoid
> android::base::LogdLogger::operator()(android::base::LogId,
> android::base::LogSeverity, const char*, const char*, unsigned int,
> const char*)â~@~Y:
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:330:6:
> 
> internal compiler error: in expand_expr_real_1, at expr.c:10012
>   330 | void LogdLogger::operator()(LogId id, LogSeverity severity,
> const char* tag, const char* file,
>   |  ^~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> [107/659] /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
> 
> -O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -MF
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o.d -o
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -c
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/mapped_file.cpp
> 
> ninja: build stopped: subcommand failed.
>  * ERROR: dev-util/android-tools-31.0.0_p1::gentoo failed (compile phase):
>  *   ninja -v -j2 -l0 failed
>  *
>  * Call stack:
>  * ebuild.sh, line  127:  Called src_compile
>  *   environment, line 3186:  Called cmake_src_compile
>  *   environment, line 1231:  Called cmake_build
>  *   environment, line 1200:  Called eninja
>  *   environment, line 1707:  Called die
>  * The specific snippet of code:
>  *   "$@" || die "${nonfatal_args[@]}" "${*} failed"
> 
> I find no mention of this problem here, in the mailing list. There was
> one hit in an internet search, but the conclusion was a bug in go, which
> I don't have as described.
> 
> Anybody seen this?
> 
I have not experienced this issue; android-tools has emerged
successfully (most recently in August) for me.

Per your build.log, you're still using GCC 9.3.0, which isn't even
listed on https://packages.gentoo.org/packages/sys-devel/gcc anymore
(9.4.0 and 10.3.0 are stable on amd64; I'm on 10.3.0 myself).

Given the error message implies a compiler error, perhaps try upgrading
sys-devel/gcc first?

[gentoo-user] haven't been able to build android-tools for months

[n952162]

On any of my 7 gentoo machines:

FAILED: ^[[0mvendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp
during RTL pass: expand
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:
In member function â~@~Xvoid
android::base::LogdLogger::operator()(android::base::LogId,
android::base::LogSeverity, const char*, const char*, unsigned int,
const char*)â~@~Y:
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:330:6:
internal compiler error: in expand_expr_real_1, at expr.c:10012
  330 | void LogdLogger::operator()(LogId id, LogSeverity severity,
const char* tag, const char* file,
  |  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[107/659] /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/mapped_file.cpp
ninja: build stopped: subcommand failed.
 * ERROR: dev-util/android-tools-31.0.0_p1::gentoo failed (compile phase):
 *   ninja -v -j2 -l0 failed
 *
 * Call stack:
 * ebuild.sh, line  127:  Called src_compile
 *   environment, line 3186:  Called cmake_src_compile
 *   environment, line 1231:  Called cmake_build
 *   environment, line 1200:  Called eninja
 *   environment, line 1707:  Called die
 * The specific snippet of code:
 *   "$@" || die "${nonfatal_args[@]}" "${*} failed"

I find no mention of this problem here, in the mailing list. There was
one hit in an internet search, but the conclusion was a bug in go, which
I don't have as described.

Anybody seen this?

Portage 3.0.20 (python 3.9.6-final-0, default/linux/amd64/17.1, gcc-9.3.0, 
glibc-2.33-r1, 5.4.92-gentoo-x86_64 x86_64)
=
 System Settings
=
System uname: Linux-5.4.92-gentoo-x86_64-x86_64-with-glibc2.33
KiB Mem: 7602652 total,303252 free
KiB Swap:8388604 total,   8387824 free
Timestamp of repository gentoo: Sun, 05 Sep 2021 08:30:01 +
Head commit of repository gentoo: 63c88537385d5a874c4b0acf2b1b8c3bac423af6
sh bash 5.1_p8
ld GNU ld (Gentoo 2.34 p6) 2.34.0
app-shells/bash:  5.1_p8::gentoo
dev-lang/perl:5.34.0::gentoo
dev-lang/python:  2.7.18-r4::gentoo, 3.6.14::gentoo, 3.7.11::gentoo, 
3.8.11::gentoo, 3.9.6_p1::gentoo
dev-lang/rust:1.53.0::gentoo
dev-util/cmake:   3.20.5::gentoo
sys-apps/baselayout:  2.7::gentoo
sys-apps/openrc:  0.43.5::gentoo
sys-apps/sandbox: 2.24::gentoo
sys-devel/autoconf:   2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:   1.16.3-r1::gentoo
sys-devel/binutils:   2.34-r2::gentoo, 2.35.2::gentoo, 2.36.1-r2::gentoo
sys-devel/gcc:9.3.0-r2::gentoo, 10.3.0-r2::gentoo
sys-devel/gcc-config: 2.4::gentoo
sys-devel/libtool:2.4.6-r6::gentoo
sys-devel/make:   4.3::gentoo
sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers)
sys-libs/glibc:   2.33-r1::gentoo
Repositories:

gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-jobs: 1
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts: 
sync-rsync-verify-max-age: 24

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/boot/cmdline.txt /boot/config.txt /etc 
/usr/share/gnupg/qualified.txt /var/spool/munin-async/.ssh"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf 

Re: [gentoo-user] portage has 0 debugging support for binary emerges

[n952162]

On 9/6/21 6:26 PM, n952162 wrote:

On 9/6/21 3:48 PM, n952162 wrote:

On 4/3/21 10:03 PM, n952162 wrote:

I find no clue why the binary packages on my server aren't being picked
up.  The --debug option  (and --verbose, naturally) has no additional
information.  Running the --getbinpkgonly stops immediately, saying 0
packages are selected.

I found one problem: on my server, my apache log file had a 302 fetch
error for /var/cache/binpkgs/Packages.  I touched it a few hours into
the future and started getting a 200 for it.  But still no emerge would
fetch a binary (even though there ARE good candidates).  On a guess, I
touched all the files in binpkgs an hour into the future, but that
didn't help.

Binary updates are VERY useful for virtual machines.




Unfortunately, there hasn't really been a resolution on this issue.

I think it's reasonable that if portage accesses a package on a binary
server and decides it's not eligible, it should report the reason for
rejecting it.

Is it possible to make requests for improvements in gentoo?




In the current case, llvm-common came across as binary, thunderbird
and firefox are also listed as a *binary* update, but llvm is an
*ebuild*.  Neither host (binary server) nor the client (updating
system) have any USE flags defined for llvm.  I know of no way to
figure out what went wrong.



Okay, maybe I've found what I was looking for:

   !!! The following binary packages have been ignored due to changed
   dependencies:

 net-misc/iputils-20210202::gentoo
 sys-devel/llvm-12.0.1::gentoo
 sys-devel/llvm-10.0.1::gentoo
 sys-devel/llvm-10.0.1::gentoo
 sys-devel/clang-12.0.1::gentoo
 sys-devel/lld-12.0.1::gentoo
 sys-libs/compiler-rt-12.0.1::gentoo
   sys-libs/compiler-rt-sanitizers-12.0.1::gentoo
 sys-libs/libomp-12.0.1::gentoo

   NOTE: The --binpkg-changed-deps=n option will prevent emerge
  from ignoring these binary packages if possible.
  Using --binpkg-changed-deps=y will silence this warning.

Re: [gentoo-user] Emerge -u -k package install order - broken system

[Jack]

On 2021.09.06 10:33, Alexander Puchmayr wrote:

Hi there,

I just tried to upgrade a older installation via binary packages and  
this
broke my system. After around 25 packages of almost 300 it stopped  
with error

and failing packages.

$ emerge
Failed to validate a sane '/dev'.
bash process substitution doesn't work; this may be an indication of  
a broken

'/dev/fd'.
$ ls -l /dev/fd/
insgesamt 0
lrwx-- 1 root root 64  6. Sep 14:18 0 -> /dev/pts/0
lrwx-- 1 root root 64  6. Sep 14:18 1 -> /dev/pts/0
lrwx-- 1 root root 64  6. Sep 14:18 2 -> /dev/pts/0
lr-x-- 1 root root 64  6. Sep 14:18 3 -> /proc/27261/fd

--> looks allright, but:

$ bash
bash: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by  
/lib64/

libreadline.so.8)

--> system broken(!), cannot start any shell anymore, cannot install  
anything
anymore and it's obvious that the system is bricked after reboot or  
even when

the ssh session I'm logged in is closed.

It seems like as if sys-libs/readline-8.1_p1-r1-1:0/8::gentoo is  
installed
*before* installing a suitable glibc, breaking any binary that has  
the useflag

readline (including bash).

Two questions:
How do I get out of this mess?
Why does portage not work in correct package order? Portage bug?
It might help if you stated which version of packages you currently  
have installed - specifically glibc.


As for recovery, you most likely need to boot to a live image (CD or  
USB) then chroot into the existing system.  I'm only guessing as to  
what is the minimal list of files you will need to replace, but I'd see  
if you can find or create a binary package of the latest glibc and then  
install or unpack that to your system.


As to whether this might be a bug in portage, I'd say you need to  
provide more details about exactly what you did.  What emerge line,  
what you mean by installation via binary packages, and where you got  
those binary packages.


If you do still have a running shell, does emerge still run at all?

Re: [gentoo-user] portage has 0 debugging support for binary emerges

[n952162]

On 9/6/21 3:48 PM, n952162 wrote:

On 4/3/21 10:03 PM, n952162 wrote:

I find no clue why the binary packages on my server aren't being picked
up.  The --debug option  (and --verbose, naturally) has no additional
information.  Running the --getbinpkgonly stops immediately, saying 0
packages are selected.

I found one problem: on my server, my apache log file had a 302 fetch
error for /var/cache/binpkgs/Packages.  I touched it a few hours into
the future and started getting a 200 for it.  But still no emerge would
fetch a binary (even though there ARE good candidates).  On a guess, I
touched all the files in binpkgs an hour into the future, but that
didn't help.

Binary updates are VERY useful for virtual machines.




Unfortunately, there hasn't really been a resolution on this issue.

I think it's reasonable that if portage accesses a package on a binary
server and decides it's not eligible, it should report the reason for
rejecting it.

Is it possible to make requests for improvements in gentoo?




In the current case, llvm-common came across as binary, thunderbird and
firefox are also listed as a *binary* update, but llvm is an *ebuild*. 
Neither host (binary server) nor the client (updating system) have any
USE flags defined for llvm.  I know of no way to figure out what went wrong.

[gentoo-user] Emerge -u -k package install order - broken system

[Alexander Puchmayr]

Hi there,

I just tried to upgrade a older installation via binary packages and this 
broke my system. After around 25 packages of almost 300 it stopped with error 
and failing packages.

$ emerge
Failed to validate a sane '/dev'.
bash process substitution doesn't work; this may be an indication of a broken 
'/dev/fd'.
$ ls -l /dev/fd/
insgesamt 0
lrwx-- 1 root root 64  6. Sep 14:18 0 -> /dev/pts/0
lrwx-- 1 root root 64  6. Sep 14:18 1 -> /dev/pts/0
lrwx-- 1 root root 64  6. Sep 14:18 2 -> /dev/pts/0
lr-x-- 1 root root 64  6. Sep 14:18 3 -> /proc/27261/fd

--> looks allright, but:

$ bash
bash: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /lib64/
libreadline.so.8)

--> system broken(!), cannot start any shell anymore, cannot install anything 
anymore and it's obvious that the system is bricked after reboot or even when 
the ssh session I'm logged in is closed.

It seems like as if sys-libs/readline-8.1_p1-r1-1:0/8::gentoo is installed 
*before* installing a suitable glibc, breaking any binary that has the useflag 
readline (including bash).

Two questions:
How do I get out of this mess? 
Why does portage not work in correct package order? Portage bug?

Re: [gentoo-user] emerge --sync keeps failing

[n952162]

On 8/2/21 2:01 PM, Michael wrote:

On Monday, 2 August 2021 12:10:12 BST n952162 wrote:

On 8/1/21 8:32 PM, Michael Orlitzky wrote:

On Sun, 2021-08-01 at 17:32 +0200, n952162 wrote:

* Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine

...!!! Manifest verification failed:
Manifest mismatch for metadata/news/Manifest

I've raised this question before and the only useful answer I got was to
keep trying

On the off chance that something is screwy on the remote end, you can
always use "emerge-webrsync" and delay the problem until next time.

Otherwise, I would say check "dmesg" for disk errors, but if it's
happening on two machines that's a lot less likely.

I have this problem every month.  Why does it fail?  Is it just a
timeout because my network is slow?  Can that be tweaked?

I get this problem over here, but on rare occasions.  Leaving it for half a
day usually fixes it.  Have you tried a different rsync mirror?  You can use
'mirrorselect -i -r' for this task.



Unfortunately, mirrorselect doesn't seem to work anymore:

configparser.MissingSectionHeaderError: File contains no section headers.

It seems to have lost track of whether it's editing make.conf or repos.conf.

I ran it with the -o option, to a tempfile and tried to put that into
/etc/portage/repos.conf, I think, but that didn't work either.

Next, I manually editted /usr/share/portage/config/repos.conf and put
that line in where the old sync-uri was defined.  But that didn't work
either.

Now, I've created a new directory /etc/portage/repos.conf/ and moved the
file generate by the -o of mirrorselect into that as gentoo.conf and
added a "[gentoo]" section head.  It MIGHT be working now.

Re: [gentoo-user] portage has 0 debugging support for binary emerges

[n952162]

On 4/3/21 10:03 PM, n952162 wrote:

I find no clue why the binary packages on my server aren't being picked
up.  The --debug option  (and --verbose, naturally) has no additional
information.  Running the --getbinpkgonly stops immediately, saying 0
packages are selected.

I found one problem: on my server, my apache log file had a 302 fetch
error for /var/cache/binpkgs/Packages.  I touched it a few hours into
the future and started getting a 200 for it.  But still no emerge would
fetch a binary (even though there ARE good candidates).  On a guess, I
touched all the files in binpkgs an hour into the future, but that
didn't help.

Binary updates are VERY useful for virtual machines.




Unfortunately, there hasn't really been a resolution on this issue.

I think it's reasonable that if portage accesses a package on a binary
server and decides it's not eligible, it should report the reason for
rejecting it.

Is it possible to make requests for improvements in gentoo?