Mailing List Archive

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.

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 ...

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.

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.

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

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

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?

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.

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.