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

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

[n952162]

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.

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On Sat, 3 Apr 2021 22:03:46 +0200, 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.

Have you tried "emaint --check binhost" followed by "emaint --fix
binhost"?


-- 
Neil Bothwick

An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[n952162]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

On 4/4/21 12:31 AM, Neil Bothwick wrote:
> On Sat, 3 Apr 2021 22:03:46 +0200, 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.
> Have you tried "emaint --check binhost" followed by "emaint --fix
> binhost"?
>

Thank you, that was exactly the kind of tip I was hoping for.
Unfortunately, in this case, it didn't help:


$ sudo emaint --check binhost
Password:
Emaint: check binhost           [
<=>                                         ]

$sudo emaint --fix binhost
Emaint: fix binhost        100%
[============================================>]


It is likely a dependency issue, but one package that I checked had:

  * neither server or client USE flags
  * the CPU_FLAGS match
  * the required package exists on the server

E.g.:

[ebuild   R    ]    dev-libs/libuv-1.40.0:0/1::gentoo USE="-static-libs"
0 KiB

I'm not sure where the static-libs USE flag comes from, it's not in
/etc/portage/package.use.

I don't follow the "0 KiB"

Okay, here's the status of the server, I'm a little confused by it now
... like what is rustc?  And why do I have different versions in binpkgs
and distfiles?

[ebuild     U  ] virtual/rust-1.47.0::gentoo [1.46.0::gentoo] 0 KiB
[ebuild     U  ]    dev-lang/rust-1.47.0-r2:stable/1.47::gentoo
[1.46.0:stable/1.46::gentoo]

$ cd /var/cache

$ ls -l  */rust*
-rw-r--r-- 1 root root 117764080 Apr  3 14:30
distfiles/rust-1.45.1-x86_64-unknown-linux-gnu.tar.xz
-rw-r--r-- 1 root root 127200200 Apr  3 14:29
distfiles/rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
-rw-r--r-- 1 root root 101868452 Apr  3 14:30
distfiles/rustc-1.46.0-src.tar.xz
-rw-r--r-- 1 root root 104143736 Apr  3 14:29
distfiles/rustc-1.47.0-src.tar.xz

$ ls -l binpkgs/*/rust*
-rw-r----- 1 root root 95131159 Apr  3 22:30
binpkgs/dev-lang/rust-1.47.0-r2.tbz2
-rw-r----- 1 root root    17542 Apr  3 22:30
binpkgs/virtual/rust-1.47.0.tbz2

$ cd /var/db

$ ls -ld pkg/dev-lang/rust-1.47.0-r2/
drwxr-xr-x 2 root root 4096 Feb  2 14:07 pkg/dev-lang/rust-1.47.0-r2/

# (I can't imagine that I ever intentionally emerged rust-bin)

$ ls -ld repos/gentoo/dev-lang/rust
rust/     rust-bin/

$ ls -l repos/gentoo/dev-lang/rust/
total 140
-rw-r--r-- 1 root root 29908 Feb 25 00:39 Manifest
drwxr-xr-x 2 root root  4096 Mar  1 17:00 files
-rw-r--r-- 1 root root  1083 Mar 31  2020 metadata.xml
-rw-r--r-- 1 root root 17326 Jan 31 01:43 rust-1.46.0.ebuild
-rw-r--r-- 1 root root 18735 Feb 25 00:39 rust-1.47.0-r2.ebuild
-rw-r--r-- 1 root root 18059 Jan 31 01:43 rust-1.48.0.ebuild
-rw-r--r-- 1 root root 18104 Feb  5 20:39 rust-1.49.0.ebuild
-rw-r--r-- 1 root root 18277 Feb 12 01:09 rust-1.50.0.ebuild

I'll run quickpkg again and report ...



[-- Attachment #2: Type: text/html, Size: 4986 bytes --]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Sun, 4 Apr 2021 10:33:15 +0200, n952162 wrote:

> [ebuild   R    ]    dev-libs/libuv-1.40.0:0/1::gentoo USE="-static-libs"
> 0 KiB
> 
> I'm not sure where the static-libs USE flag comes from, it's not in
> /etc/portage/package.use.

The flag is defined in the ebuild and defaults to off.

> I don't follow the "0 KiB"

It's the size of the files portage needs to download to install this. As
you have already installed it, the source files are in your $DISTDIR so
there's nothing to download.


-- 
Neil Bothwick

Feminism: the radical notion that women are people.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[n952162]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On 4/4/21 10:56 AM, Neil Bothwick wrote:
> On Sun, 4 Apr 2021 10:33:15 +0200, n952162 wrote:
>
>> [ebuild   R    ]    dev-libs/libuv-1.40.0:0/1::gentoo USE="-static-libs"
>> 0 KiB
>>
>> I'm not sure where the static-libs USE flag comes from, it's not in
>> /etc/portage/package.use.
> The flag is defined in the ebuild and defaults to off.
>
>> I don't follow the "0 KiB"
> It's the size of the files portage needs to download to install this. As
> you have already installed it, the source files are in your $DISTDIR so
> there's nothing to download.
>
>

Thank you.

After re-running quickpkg, I still get no "binary"s in the emerge output
dependency tree.

I now have this:

02/var/cache/distfiles>ll *rust*
-rw-r--r-- 1 root root     50278 Apr  3 14:30 eselect-rust-20200419.tar.bz2
-rw-r--r-- 1 root root 117764080 Apr  3 14:30
rust-1.45.1-x86_64-unknown-linux-gnu.tar.xz
-rw-r--r-- 1 root root 127200200 Apr  3 14:29
rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
-rw-r--r-- 1 root root 101868452 Apr  3 14:30 rustc-1.46.0-src.tar.xz
-rw-r--r-- 1 root root 104143736 Apr  3 14:29 rustc-1.47.0-src.tar.xz

02/var/cache/distfiles>cd ../binpkgs


22/var/cache/binpkgs>ll */*rust*
-rw-r----- 1 root root    15249 Apr  4 11:36
app-eselect/eselect-rust-20200419.tbz2
-rw-r----- 1 root root 95134383 Apr  4 11:29 dev-lang/rust-1.47.0-r2.tbz2
-rw-r----- 1 root root    17542 Apr  4 11:46 virtual/rust-1.47.0.tbz2

and:

[ebuild     U  ] virtual/rust-1.47.0::gentoo [1.46.0::gentoo] 0 KiB
[ebuild     U  ]    dev-lang/rust-1.47.0-r2:stable/1.47::gentoo
[1.46.0:stable/1.46::gentoo] USE="-clippy -debug (-doc) (-libressl)
(-miri) (-nightly) (-parallel-compiler) -rls -rustfmt
(-system-bootstrap) (-system-llvm) -test% -wasm" CPU_FLAGS_X86="sse2"
LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -AVR% -BPF -Hexagon -Lanai
-MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly
-XCore" 0 KiB

No USE flags associated with "rust" on server or client.

I would expect that it would have "binary" instead of "ebuild" if it
were to come from the server.

I reran the emaint commands.

Here's the command:

+ emerge -p --getbinpkg y -v --tree --deep --update --noreplace
--changed-use --newuse --changed-deps --verbose-conflicts --keep-going
--with-bdeps=y --backtrack=100 @world

Relevant lines from /etc/portage/make.conf:

PORTAGE_BINHOST="http:///xxx//packages"
FEATURES="getbinpkg"

(I guess the FEATURES definition is redundant).

Yesterday, I successfully binary-updated a vm from a different server,
and another vm on that same (other) server is updating now, successfully
pulling in binary packages.




[-- Attachment #2: Type: text/html, Size: 4073 bytes --]

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

[n952162]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On 4/4/21 12:37 PM, n952162 wrote:
> After re-running quickpkg, I still get no "binary"s in the emerge
> output dependency tree.


At some point, I started getting 304 errors here again.

    |304 Not Modified|
    <https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304>
        This is used for caching purposes. It tells the client that the
        response has not been modified, so the client can continue to
        use the same cached version of the response.

I suspect the problem is related to this. The Packages file is the
package index file.

# ls -l /var/cache/binpkgs/Packages
-rw-r--r-- 1 root root 1024590 Apr  4 13:00 /var/cache/binpkgs/Packages


[-- Attachment #2: Type: text/html, Size: 1364 bytes --]

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

[Daniel Frey]

On 4/4/21 6:41 AM, n952162 wrote:
> On 4/4/21 12:37 PM, n952162 wrote:
>> After re-running quickpkg, I still get no "binary"s in the emerge 
>> output dependency tree.
> 
> 
> At some point, I started getting 304 errors here again.
> 
>     |304 Not Modified|
>     <https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304>
>         This is used for caching purposes. It tells the client that the
>         response has not been modified, so the client can continue to
>         use the same cached version of the response.
> 
> I suspect the problem is related to this. The Packages file is the 
> package index file.
> 
> # ls -l /var/cache/binpkgs/Packages
> -rw-r--r-- 1 root root 1024590 Apr  4 13:00 /var/cache/binpkgs/Packages
> 

I wonder if your permissions are messed up? Here's mine:

$ ls -ldh /var/cache/distfiles/ /var/cache/binpkgs
drwxrwxr-x 2 root portage 4.0K Dec  4  2019 /var/cache/binpkgs
drwxrwxr-x 2 root portage 140K Apr  2 08:16 /var/cache/distfiles

Dan

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?

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

[n952162]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

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

[n952162]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

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.



[-- Attachment #2: Type: text/html, Size: 3997 bytes --]