[ISSUE] Unresolved dependencies, missing libglapi-32bit

[ISSUE] Unresolved dependencies, missing libglapi-32bit

[linkert]

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

New issue by linkert on void-packages repository

https://github.com/void-linux/void-packages/issues/30420

Description:
### System

Rocking wayland, sway on my X230 (thrid gen i5), future meets the past - Followed the instruction on how to setup Intel gpu for my machine on the documentation which led me to install:  `intel-video-accel vulkan-loader vulkan-loader-32bit mesa-dri mesa-dri-32bit mesa-vulkan-intel mesa-vulkan-intel-32bit` - 32bit packages because I sometimes get an itch to play Diablo 2 and such through Wine which then usually complains if 32bit packages are not installed.

Also: `export LIBVA_DRIVER_NAME=i965`

None of the above ^ probably have to do much with the issue below:


* xuname:  

```
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
Void 5.11.15_1 x86_64 GenuineIntel uptodate rrrmFFF
```

* package:  
  *affected package(s) including the version*: ``xbps-query -p pkgver <pkgname>``

`libglapi-32bit-21.0.2_1
`
### Expected behavior
To update my system ```xbps-install -Su```

### Actual behavior

```
[linkert@x230 ~]$ sudo xbps-install -Su
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/nonfree/x86_64-repodata' ...
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
```

### Steps to reproduce the behavior

`sudo xbps-install -Su`



### Other:

`xbps-install --debug -Su`
Did not paste full output, large section of the bottom part. I think it has to do with mesa and such yes? [pastebin, raw](https://pastebin.com/raw/tMpADZM8)

Re: Unresolved dependencies, missing libglapi-32bit

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824553477

Comment:
From https://build.voidlinux.org/builders/i686_builder/builds/32006/steps/shell_3/logs/stdio

```
=> Registering new packages to /host/binpkgs/multilib (x86_64)
index: failed to read props.plist metadata for `/host/binpkgs/multilib/libglapi-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/libgbm-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/libOSMesa-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/mesa-vulkan-radeon-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/mesa-ati-dri-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/mesa-vulkan-intel-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/mesa-intel-dri-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/mesa-nouveau-dri-32bit-21.0.3_1.x86_64.xbps', skipping!
index: failed to read props.plist metadata for `/host/binpkgs/multilib/libxatracker-32bit-21.0.3_1.x86_64.xbps', skipping!
index: added `MesaLib-devel-32bit-21.0.3_1' (x86_64).
index: added `mesa-32bit-21.0.3_1' (x86_64).
index: added `mesa-XvMC-32bit-21.0.3_1' (x86_64).
index: added `mesa-dri-32bit-21.0.3_1' (x86_64).
index: added `mesa-opencl-32bit-21.0.3_1' (x86_64).
index: added `mesa-vaapi-32bit-21.0.3_1' (x86_64).
index: added `mesa-vdpau-32bit-21.0.3_1' (x86_64).
index: added `mesa-vmwgfx-dri-32bit-21.0.3_1' (x86_64).
index: added `mesa-vulkan-overlay-layer-32bit-21.0.3_1' (x86_64).
```

Something went wrong in the builders, trying to figure it out.

Re: Unresolved dependencies, missing libglapi-32bit

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824561836

Comment:
Potentially fixed with 74f709768c6be3dfc57150c42470e187d82d6755

Re: Unresolved dependencies, missing libglapi-32bit

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824563292

Comment:
What went wrong in the builders seems to be a race between the generation of `-32bit` packages and the removal of obsolete packages on the `x86_64` trail.

You can see `libglapi-32bit-21.0.3_1.x86_64.xbps` (the package that you wanted to install and should have been added to the index) being removed in https://build.voidlinux.org/builders/x86_64_builder/builds/32066/steps/shell_4/logs/stdio

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824565062

Comment:
Propose solution to the underlying problem: cleaning up multilib repo should be done by the i686 builder, to avoid the potential for any races.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824565062

Comment:
Proposed solution to the underlying problem: cleaning up multilib repo should be done by the i686 builder, to avoid the potential for any races.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824569791

Comment:
Given that the multilib repo is exclusively x86_64 packages, and your suggestion is to clean it by an unrelated architecture, this feels like an XBPS bug.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824577583

Comment:
The `libxkbcommon-devel-32bit` package also probably needs to be revbumped.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[linkert]

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

New comment by linkert on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824702714

Comment:
> You can see `libglapi-32bit-21.0.3_1.x86_64.xbps` (the package that you wanted to install and should have been added to the index) being removed in https://build.voidlinux.org/builders/x86_64_builder/builds/32066/steps/shell_4/logs/stdio

Re: [ISSUE] [CLOSED] Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[linkert]

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

Closed issue by linkert on void-packages repository

https://github.com/void-linux/void-packages/issues/30420

Description:
### System

Rocking wayland, sway on my X230 (thrid gen i5), future meets the past - Followed the instruction on how to setup Intel gpu for my machine on the documentation which led me to install:  `intel-video-accel vulkan-loader vulkan-loader-32bit mesa-dri mesa-dri-32bit mesa-vulkan-intel mesa-vulkan-intel-32bit` - 32bit packages because I sometimes get an itch to play Diablo 2 and such through Wine which then usually complains if 32bit packages are not installed.

Also: `export LIBVA_DRIVER_NAME=i965`

None of the above ^ probably have to do much with the issue below:


* xuname:  

```
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
Void 5.11.15_1 x86_64 GenuineIntel uptodate rrrmFFF
```

* package:  
  *affected package(s) including the version*: ``xbps-query -p pkgver <pkgname>``

`libglapi-32bit-21.0.2_1
`
### Expected behavior
To update my system ```xbps-install -Su```

### Actual behavior

```
[linkert@x230 ~]$ sudo xbps-install -Su
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/nonfree/x86_64-repodata' ...
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
```

### Steps to reproduce the behavior

`sudo xbps-install -Su`



### Other:

`xbps-install --debug -Su`
Did not paste full output, large section of the bottom part. I think it has to do with mesa and such yes? [pastebin, raw](https://pastebin.com/raw/tMpADZM8)

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[linkert]

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

New comment by linkert on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824702714

Comment:
> You can see `libglapi-32bit-21.0.3_1.x86_64.xbps` (the package that you wanted to install and should have been added to the index) being removed in https://build.voidlinux.org/builders/x86_64_builder/builds/32066/steps/shell_4/logs/stdio

Sorry did not mean to close - gosh darn it.. 

Thank you very kindly everyone - amazed at the response to this! 

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824728696

Comment:
> Given that the multilib repo is exclusively x86_64 packages, and your suggestion is to clean it by an unrelated architecture, this feels like an XBPS bug.

The problem is that i686 writes the repo. This comes down to the same issue with running the cleanup in a cronjob instead of part of the build pipeline, there is a inherent race condition between `xbps-create` creating the package and then `xbps-rindex` adding the packages to the repository index.
While the `.xbps` archives for the specific architecture are not in the `-repodata`, they are considered obsolete. 

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824728696

Comment:
> Given that the multilib repo is exclusively x86_64 packages, and your suggestion is to clean it by an unrelated architecture, this feels like an XBPS bug.

The problem is that i686 writes the repo. This comes down to the same issue with running the cleanup in a cronjob instead of part of the build pipeline, there is a inherent race condition between `xbps-create` creating the package and then `xbps-rindex` adding the packages to the repository index: While the `.xbps` archives for the specific architecture are not in the `-repodata`, they are considered obsolete. 

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824737700

Comment:
The only way to solve this in xbps would be to add another type of lock, which is held before `xbps-src` is doing `xbps-create` in the repository directory, then `xbps-src` calls `xbps-rindex` to add the newly created packages to the repodata, then unlocks the repo again.
`xbps-rindex -c` would then have to check for both types of locks.

Then we would avoid the race, but the obsolete packages would only cleaned up after another build runs on the `x86_64` builder.

The way `-32bit` packages are created is weird and its the only way `xbps-src` is responsible for repositories for multiple architectures.

IMHO the best way is to handle the cleanup correctly is to let the build pipeline that creates those packages clean up obsolete packages for the repository it writes to.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824728696

Comment:
> Given that the multilib repo is exclusively x86_64 packages, and your suggestion is to clean it by an unrelated architecture, this feels like an XBPS bug.

The problem is that i686 writes the repo. This comes down to the same issue with running the cleanup in a cronjob instead of part of the build pipeline, there is a inherent race condition between `xbps-create` creating the package and then `xbps-rindex` adding the packages to the repository index: While the `.xbps` archives for the specific architecture are not in the `-repodata`, they are considered obsolete.

1. The multilib repo is exclusively i686 packages with a x86_64 label.
2. The repository is not unrelated, its created and maintained by the i686 builder.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824728696

Comment:
> Given that the multilib repo is exclusively x86_64 packages, and your suggestion is to clean it by an unrelated architecture, this feels like an XBPS bug.

The problem is that i686 writes the repo. This comes down to the same issue with running the cleanup in a cronjob instead of part of the build pipeline, there is a inherent race condition between `xbps-create` creating the package and then `xbps-rindex` adding the packages to the repository index: While the `.xbps` packages for the specific architecture are not in the `-repodata`, they are considered obsolete.

1. The multilib repo is exclusively i686 packages with a x86_64 label.
2. The repository is not unrelated, its created and maintained by the i686 builder.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824577583

Comment:
The `libxkbcommon-devel-32bit` package also probably needs to be revbumped.
```
$ xuname
libxkbcommon-devel-1.2.1_1 in transaction breaks installed pkg `libxkbcommon-devel-32bit-1.0.3_1'
Transaction aborted due to unresolved dependencies.
Void 5.11.13_1 x86_64 GenuineIntel uptodate rrrmFFFFFFFFFFF
```
(This is depended on by SDL2-devel-32bit)

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-825211329

Comment:
The libxkbcommon-devel-32bit package isn't updated in the repo but the libxkbcommon-32bit package in the repo is. Is this the same issue or should I make a different bug report?

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-825211329

Comment:
The libxkbcommon-devel-32bit package isn't updated in the multilib repo but the libxkbcommon-32bit package in the repo is. Is this the same issue or should I make a different bug report?

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-825211329

Comment:
The libxkbcommon-devel-32bit package isn't updated in the multilib repo but the libxkbcommon-32bit package in the repo is. Is this the same issue or something else?

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-824577583

Comment:
The `libxkbcommon-devel-32bit` package also may need to be revbumped.
```
$ xuname
libxkbcommon-devel-1.2.1_1 in transaction breaks installed pkg `libxkbcommon-devel-32bit-1.0.3_1'
Transaction aborted due to unresolved dependencies.
Void 5.11.13_1 x86_64 GenuineIntel uptodate rrrmFFFFFFFFFFF
```
(This is depended on by SDL2-devel-32bit)

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Duncaen]

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

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-825213403

Comment:
```
index: added `libxkbcommon-devel-32bit-1.2.1_1' (x86_64).
```

should be there now.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[Oreo639]

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

New comment by Oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-825213482

Comment:
Thanks.

Re: Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30420#issuecomment-826354398

Comment:
Fixed with https://github.com/void-linux/void-infrastructure/commit/af6b41f31a4bd1f5113690083020fa15d50c39dd

Re: [ISSUE] [CLOSED] Obsolete package removal on x86_64 builder can race with multilib generation on i686 builder

[ericonr]

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

Closed issue by linkert on void-packages repository

https://github.com/void-linux/void-packages/issues/30420

Description:
### System

Rocking wayland, sway on my X230 (thrid gen i5), future meets the past - Followed the instruction on how to setup Intel gpu for my machine on the documentation which led me to install:  `intel-video-accel vulkan-loader vulkan-loader-32bit mesa-dri mesa-dri-32bit mesa-vulkan-intel mesa-vulkan-intel-32bit` - 32bit packages because I sometimes get an itch to play Diablo 2 and such through Wine which then usually complains if 32bit packages are not installed.

Also: `export LIBVA_DRIVER_NAME=i965`

None of the above ^ probably have to do much with the issue below:


* xuname:  

```
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
Void 5.11.15_1 x86_64 GenuineIntel uptodate rrrmFFF
```

* package:  
  *affected package(s) including the version*: ``xbps-query -p pkgver <pkgname>``

`libglapi-32bit-21.0.2_1
`
### Expected behavior
To update my system ```xbps-install -Su```

### Actual behavior

```
[linkert@x230 ~]$ sudo xbps-install -Su
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/nonfree/x86_64-repodata' ...
MISSING: libglapi-32bit-21.0.3_1
Transaction aborted due to unresolved dependencies.
```

### Steps to reproduce the behavior

`sudo xbps-install -Su`



### Other:

`xbps-install --debug -Su`
Did not paste full output, large section of the bottom part. I think it has to do with mesa and such yes? [pastebin, raw](https://pastebin.com/raw/tMpADZM8)