Dale
2023-09-16 04:50:01 UTC
Howdy,
A couple of my video players are not playing videos correctly. I've
rebuilt a few things but no change. Some work fine, some give a error
about a bad index or something, some just don't even try at all. The
videos come from various sources and are of different file extensions.
I can't find a rhyme or reason to the failure. So, my plan, do a emerge
-ek world to reinstall all packages instead of just the obvious ones
that isn't fixing the issue. I figure that should catch whatever is out
of sync and fix the problem. If not, then try to figure out why it is
breaking the hard way. This is basically a emerge -e world, just faster
on my main system.
What I did before this. I ran emerge -eak world on my main install.
Any packages that showed ebuild, which means it doesn't have a package
binary, I emerged in my chroot. Once it was done installing, I copied
the binary package over to my main install. However, when I run emerge
-eak world again on my main install, it still shows ebuild for these
packages.
[ebuild R ] dev-cpp/glibmm-2.66.6:2::gentoo USE="-debug -gtk-doc
-test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] dev-cpp/pangomm-2.46.3:1.4::gentoo USE="-gtk-doc"
ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] app-crypt/gcr-3.41.1-r2:0/1::gentoo USE="gtk
introspection vala -gtk-doc -systemd -test" 0 KiB
[ebuild R ] dev-qt/qtdeclarative-5.15.10-r2:5/5.15::gentoo
USE="jit vulkan widgets -debug -gles2-only -localstorage -test" 0 KiB
[ebuild R ] sys-devel/llvm-15.0.7-r3:15::gentoo
USE="binutils-plugin libffi ncurses xml -debug -doc -exegesis -libedit
-test -verify-sig -xar -z3 -zstd" ABI_X86="32 (64) (-x32)"
LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai)
(MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE)
(WebAssembly) (X86) (XCore) (-ARC) (-CSKY) (-DirectX) (-LoongArch)
(-M68k) (-SPIRV)" 0 KiB
[ebuild R ] sys-libs/compiler-rt-15.0.7:15.0.7::gentoo USE="clang
-debug -test -verify-sig" ABI_X86="32 (64)" 0 KiB
[ebuild R ] sys-libs/compiler-rt-sanitizers-15.0.7:15.0.7::gentoo
USE="asan cfi clang dfsan gwp-asan hwasan libfuzzer lsan memprof msan
orc profile safestack scudo tsan ubsan xray -debug (-shadowcallstack)
-test -verify-sig" ABI_X86="32 (64)" 0 KiB
[ebuild R ] sys-devel/clang-15.0.7-r3:15/15g1::gentoo USE="extra
(pie) static-analyzer xml -debug -doc (-ieee-long-double) -test
-verify-sig" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="(AArch64) (AMDGPU)
(ARM) (AVR) (BPF) (Hexagon) (Lanai) (MSP430) (Mips) (NVPTX) (PowerPC)
(RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) (-ARC)
(-CSKY) (-DirectX) (-LoongArch) (-M68k) (-SPIRV)"
PYTHON_SINGLE_TARGET="python3_11 -python3_10" 0 KiB
[ebuild R ] sci-electronics/klayout-0.28.9::gentoo
PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12"
RUBY_TARGETS="ruby31" 0 KiB
Most package are the way they should be, showing a binary. Like this:
[binary R ] x11-libs/libX11-1.8.6::gentoo USE="-doc -test"
ABI_X86="32 (64) (-x32)" 0 KiB
Does anyone know if there is some reason these packages won't use a
binary for some reason? I've recompiled some of these twice now with it
refusing to show it using a binary. I expect memtest and a couple
others to fail but never ran into this before.
I do this so that my main system updates faster. A couple of those
packages has a bit longer compile time. I might add, I've done this
countless times doing updates with no problems, most likely even with
these packages. Today it just refuses to cooperate.
Oh, I posted about handbrake and opencascade blocking some updates in
another thread a while back, I unmerged those and Kicad which I think
used opencascade. It did update some video stuff the other day. I feel
some package is out of sync with some other package and hope a reinstall
will fix it. Otherwise, could be a bug in some package version.
Any ideas?
Dale
:-) :-)
P. S. Fresh backups are still working on the new NAS system. Also, the
speed is about the same as it was on TrueNAS. It seems encryption on
both ends does slow things down. I suspect it is the slower machine.
Still, it works. Even if I switch to another OS, it can still see LVM
drives and I won't have to redo them again. I hope. :-D At 7.6TB of
about 26TBs at the moment.
A couple of my video players are not playing videos correctly. I've
rebuilt a few things but no change. Some work fine, some give a error
about a bad index or something, some just don't even try at all. The
videos come from various sources and are of different file extensions.
I can't find a rhyme or reason to the failure. So, my plan, do a emerge
-ek world to reinstall all packages instead of just the obvious ones
that isn't fixing the issue. I figure that should catch whatever is out
of sync and fix the problem. If not, then try to figure out why it is
breaking the hard way. This is basically a emerge -e world, just faster
on my main system.
What I did before this. I ran emerge -eak world on my main install.
Any packages that showed ebuild, which means it doesn't have a package
binary, I emerged in my chroot. Once it was done installing, I copied
the binary package over to my main install. However, when I run emerge
-eak world again on my main install, it still shows ebuild for these
packages.
[ebuild R ] dev-cpp/glibmm-2.66.6:2::gentoo USE="-debug -gtk-doc
-test" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] dev-cpp/pangomm-2.46.3:1.4::gentoo USE="-gtk-doc"
ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild R ] app-crypt/gcr-3.41.1-r2:0/1::gentoo USE="gtk
introspection vala -gtk-doc -systemd -test" 0 KiB
[ebuild R ] dev-qt/qtdeclarative-5.15.10-r2:5/5.15::gentoo
USE="jit vulkan widgets -debug -gles2-only -localstorage -test" 0 KiB
[ebuild R ] sys-devel/llvm-15.0.7-r3:15::gentoo
USE="binutils-plugin libffi ncurses xml -debug -doc -exegesis -libedit
-test -verify-sig -xar -z3 -zstd" ABI_X86="32 (64) (-x32)"
LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai)
(MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE)
(WebAssembly) (X86) (XCore) (-ARC) (-CSKY) (-DirectX) (-LoongArch)
(-M68k) (-SPIRV)" 0 KiB
[ebuild R ] sys-libs/compiler-rt-15.0.7:15.0.7::gentoo USE="clang
-debug -test -verify-sig" ABI_X86="32 (64)" 0 KiB
[ebuild R ] sys-libs/compiler-rt-sanitizers-15.0.7:15.0.7::gentoo
USE="asan cfi clang dfsan gwp-asan hwasan libfuzzer lsan memprof msan
orc profile safestack scudo tsan ubsan xray -debug (-shadowcallstack)
-test -verify-sig" ABI_X86="32 (64)" 0 KiB
[ebuild R ] sys-devel/clang-15.0.7-r3:15/15g1::gentoo USE="extra
(pie) static-analyzer xml -debug -doc (-ieee-long-double) -test
-verify-sig" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="(AArch64) (AMDGPU)
(ARM) (AVR) (BPF) (Hexagon) (Lanai) (MSP430) (Mips) (NVPTX) (PowerPC)
(RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) (-ARC)
(-CSKY) (-DirectX) (-LoongArch) (-M68k) (-SPIRV)"
PYTHON_SINGLE_TARGET="python3_11 -python3_10" 0 KiB
[ebuild R ] sci-electronics/klayout-0.28.9::gentoo
PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12"
RUBY_TARGETS="ruby31" 0 KiB
Most package are the way they should be, showing a binary. Like this:
[binary R ] x11-libs/libX11-1.8.6::gentoo USE="-doc -test"
ABI_X86="32 (64) (-x32)" 0 KiB
Does anyone know if there is some reason these packages won't use a
binary for some reason? I've recompiled some of these twice now with it
refusing to show it using a binary. I expect memtest and a couple
others to fail but never ran into this before.
I do this so that my main system updates faster. A couple of those
packages has a bit longer compile time. I might add, I've done this
countless times doing updates with no problems, most likely even with
these packages. Today it just refuses to cooperate.
Oh, I posted about handbrake and opencascade blocking some updates in
another thread a while back, I unmerged those and Kicad which I think
used opencascade. It did update some video stuff the other day. I feel
some package is out of sync with some other package and hope a reinstall
will fix it. Otherwise, could be a bug in some package version.
Any ideas?
Dale
:-) :-)
P. S. Fresh backups are still working on the new NAS system. Also, the
speed is about the same as it was on TrueNAS. It seems encryption on
both ends does slow things down. I suspect it is the slower machine.
Still, it works. Even if I switch to another OS, it can still see LVM
drives and I won't have to redo them again. I hope. :-D At 7.6TB of
about 26TBs at the moment.