On Mon, Dec 2, 2019 at 3:22 AM Adrian Schröter wrote:

On Sonntag, 1. Dezember 2019, 04:22:47 CET Neal Gompa wrote:

...

On Sat, Nov 30, 2019 at 10:18 PM Rosanne DiMesio wrote:

...

I'm still trying to build 32 bit Wine packages for Fedora 31 on the OBS.

The Fedora 31 repository at http://ftp.fau.de/fedora/linux/releases/31/Everything/x86_64/os/Packages/ has all the i686 packages needed to build 32 bit Wine, but I have not been able to get the OBS to use them. I even tried manually downloading the packages and building locally, but the build fails with

[ 10s] checking whether gcc -m32 works... no [ 10s] configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries.

The 32 bit libraries were definitely in /var/tmp/osbuild-packagecache/Fedora:31/standard/x86_64.

Is there a way to force the OBS to use the i686 packages available in Fedora 31 x86_64, or should I just give up?

not in the x86_64 scheduler build atm.

...

Not sure. Maybe OBS is filtering out the i686 packages from the x86_64 repo?

yes, they would conflict otherwise.

our mechanic to build 32bit compat packages is different, we extract them from normal i586 builds.

So you don't support name.arch package requests in OBS? Nor using the name%{?_isa} requests to pull multiarch deps? Why not? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Mon, Dec 2, 2019 at 7:56 AM Marcus Meissner wrote:

On Mon, Dec 02, 2019 at 07:52:54AM -0500, Neal Gompa wrote:

...

On Mon, Dec 2, 2019 at 3:22 AM Adrian Schröter wrote:

...

On Sonntag, 1. Dezember 2019, 04:22:47 CET Neal Gompa wrote:

...

On Sat, Nov 30, 2019 at 10:18 PM Rosanne DiMesio wrote:

...

I'm still trying to build 32 bit Wine packages for Fedora 31 on the OBS.

The Fedora 31 repository at http://ftp.fau.de/fedora/linux/releases/31/Everything/x86_64/os/Packages/ has all the i686 packages needed to build 32 bit Wine, but I have not been able to get the OBS to use them. I even tried manually downloading the packages and building locally, but the build fails with

[ 10s] checking whether gcc -m32 works... no [ 10s] configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries.

The 32 bit libraries were definitely in /var/tmp/osbuild-packagecache/Fedora:31/standard/x86_64.

Is there a way to force the OBS to use the i686 packages available in Fedora 31 x86_64, or should I just give up?

not in the x86_64 scheduler build atm.

...

Not sure. Maybe OBS is filtering out the i686 packages from the x86_64 repo?

yes, they would conflict otherwise.

our mechanic to build 32bit compat packages is different, we extract them from normal i586 builds.

So you don't support name.arch package requests in OBS? Nor using the name%{?_isa} requests to pull multiarch deps? Why not?

Why cant the RPMs for building not in the i686 tree like in previous Fedoras?

Can we bootstrap them perhaps if Fedora no longer wants to support Wine?

Fedora supports Wine just fine, and the project still maintains an i686 tree within Koji. It's just no longer being published and synced to mirrors beyond the multiarch package publishing done in the x86_64 repo. You could pull the i686 tree from Koji (the URL is in the mock config shipped in mock-core-configs v31 and newer) and use that, but that means OBS will be pulling unsigned packages directly from Koji. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Mon, Dec 2, 2019 at 10:44 AM Jan Engelhardt wrote:

On Monday 2019-12-02 13:52, Neal Gompa wrote:

...

So you don't support name.arch package requests in OBS?

Two reasons:

1. There is one bs_sched instance for each %_isa (design decision done many moons ago, possibly to have at least some little multiprocessing). In this "enclave" so to speak, there are generally only packages for said %_isa.

mkbaselibs is used inside the i586 space to repackage (part of) i586 rpms with i586 code into a x86_64 rpm, which are then copied to the x86_64 space with an explicit ExportFilter.

That is a horrible way to handle this, because it means that: 1. These packages must be manually defined 2. These packages are lies (they pretend to be x86_64 when they are really x86_32 packages)

Attention is paid towards there being no conflicting files whatsoever, which is otherwise not the case when you install both libfoo1.i586 and libfoo1.x86_64 (e.g. a LICENSE file).

In that particular example, rpm handles it just fine, since the file is identical across arches. Fedora multiarch packages generally do have these things handled.

2. I suppose many parts of bs_sched and obs-build evaluate just %{NAME} (without %{ARCH}), and there simply is no rpm file that has NAME="libfoo1.i586".

...

Nor using the name%{?_isa} requests to pull multiarch deps? Why not?

There are never any "non-home" ISAs available as install candidates, so our specfiles never needed to bother with that case. Certainly saves clutter in that particular place (might generate it elsewhere, tho).

That is not true. Even openSUSE package repos are multiarched. There's one set of repodata for x86_64 and "i586" packages. I can see and install them as multiarch candidates just fine. And runtime dependencies for Wine on Fedora and openSUSE rely on this property. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org