Bug#993570: libvkd3d-doc is not installable besides libvkd3d-dev - still

2022-02-05 Thread Sveinar Søpler
I guess this package has low priority, as this is used - afaik - only 
for Wine. Since Debian are not able to build more recent Wine than 5.0 
either, it may not get too much attention perhaps?


Sveinar

On 04.02.2022 21:29, Andreas Beckmann wrote:

Followup-For: Bug #993570
Control: found -1 1.2-7

Hi,

the file conflict is still there, these 4 files are shipped in both
packages:

usr/share/doc/libvkd3d-dev/ANNOUNCE.gz
usr/share/doc/libvkd3d-dev/AUTHORS
usr/share/doc/libvkd3d-dev/README
usr/share/doc/libvkd3d-dev/README.debian

This is probably fallout from dh_installdocs in debhelper compat level 11+
where documentation is installed into the doc path of the "main package".

(README.debian is an unusual name, it's usually README.Debian)


Andreas





Bug#993570: libvkd3d-doc is not installable besides libvkd3d-dev - still

2021-09-03 Thread Sveinar Søpler
Package: libvkd3d-doc 
Version: 1.2-6 

Previous bug: #992069 

This is not fixed. The package libvkd3d-doc still is not installable alongside 
libvkd3d-dev, as it tries to overwrite files in /usr/share/doc/libvkd3d-dev 
folder. 

This placement of files in /usr/share/doc/libvkd3d-dev folder seems counter 
intuitive to me, as libvkd3d-doc package is installable alone - Why "split" 
documents in these two folders. I am not sure if this is intended or just 
something strange that happens in the "rules" script, because aborting the 
build before override_dh_gencontrol: seems to NOT have the files in the wrong 
folder. 

I added this below override_dh_gencontrol: 

# Need to move html and .pdf to libvkd3d-doc 
ifneq (,$(filter $(DEB_HOST_ARCH),amd64)) 
mv debian/libvkd3d-doc/usr/share/doc/libvkd3d-dev/* 
debian/libvkd3d-doc/usr/share/doc/libvkd3d-doc 
rm -rf debian/libvkd3d-doc/usr/share/doc/libvkd3d-dev 
endif 

Since this is a "all" package, i guess i386 will kinda drop the package 
(override_dh_gencontrol maybe not run? dunno), so i did this just for amd64, or 
it would fail building on launchpad PPA for Ubuntu on the i386 package (file 
not found) 

The result of this is that ALL the files are placed in 
/usr/share/doc/libvkd3d-doc folder instead instead of split between 
/usr/share/doc/libvkd3d-dev and /usr/share/doc/libvkd3d-doc. I do not claim to 
say this is "correct" or even wanted... maybe it is your intent to have the 
html docs in /usr/share/doc/libvkd3d-dev folder anyway.. it just seems somewhat 
strange to me, unless you actually do a "depends libvkd3d-dev" on the package 
(After all.. most likely scenario is to install documentation alongside -dev 
package). This is not up to me... but the fact are that (as the original bug 
#992069 also said) the files ANNOUNCE.gz AUTHORS and README files being put in 
/usr/share/doc/libvkd3d-dev is causing a overwrite conflict when installing 
both the packages. 

By all means - solve this more correct - just make sure that someone TEST 
install the package so that you can install BOTH libvkd3d-dev and libvkd3d-doc 
at the same time. 

Sveinar 


Bug#990753: libvkd3d-dev: Depends: libvkd3d-headers (= ${binary:Version}) breaks multilib

2021-07-06 Thread Sveinar Søpler
Package: libvkd3d-dev
Version: 1.2-4 (Debian experimental)
Source: vkd3d

In the 1.2-4 version of libvkd3d-dev package, the control field indicates
Depends: libvkd3d-headers (= ${binary:Version})

This causes libvkd3d-dev:i386 to depend on libvkd3d-headers:i386, but 
libvkd3d-headers is built with Architecture: all and thus cannot satisfy
dependency. (There is no libvkd3d-headers:i386 on amd64 systems)

Tested suggestion:
Build libvkd3d-dev with Depends: libvkd3d-headers (= ${source:Version})
and build libvkd3d-headers with: Multi-Arch: allowed

Next issue then is that libvkd3d-dev generate html docs in the package,
and this causes libvkd3d-dev:amd64 and libvkd3d-dev:i386 to have conflict
when installing docs. (Trying to overwrite)

Tested suggestion:
Build html docs with the libvkd3d-headers package since it is built as
Architecture: all.

Symlink libvkd3d-dev.docs -> docs
and change
libvkd3d-headers.docs:

README
AUTHORS
ANNOUNCE

doc/html
doc/vkd3d.pdf

I know this is not the most logical solution, since you would expect a -dev
package to contain docs, but building wine requires multilib version of
libvkd3d-dev, and i do not know another way of doing this since the html
docs are being generated when the package is being built (and thus probably
not binary the same?).

Best Regards
Sveinar Søpler



Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

2021-03-16 Thread Sveinar Søpler

On 16.03.2021 13:32, Henri Verbeet wrote:

On 2021-03-03 15:38, Francois Gouget wrote:

Just asking. I don't actually know if the 32- and 64-bit vkd3d-compiler
produce identical files or if one produces 32-bit files and the other
64-bit ones.

The output produced by i386 and amd64 (or any other, for that matter) 
builds of vkd3d-compiler should be identical; if it isn't, that would 
be considered a bug. For the record, I would be inclined to agree that 
the -dev package is not the appropriate place for vkd3d-compiler.


How would vkd3d-compiler be identical regardless of arch? I might 
misunderstand what you are saying tho.. I dont really know how dpkg 
compares binary files when they are installed, but if they are not 
binary equal, they are not "the same" from dpkg's pov. How would 
vkd3d-compiler compiled for amd64 be binary the same as i386? (The 
physical file that is).


I mean, a "hello world" example compiled as i386 or amd64 "are the 
same", but they are not checksum-comparable the same file.




On the subject of Wine builds requiring both vkd3d-dev:amd64 and 
vkd3d-dev:i386, although somewhat tangential, note that Wine doesn't 
only use libvkd3d for its implementation of Direct3D 12, but also 
libvkd3d-shader for producing SPIR-V shaders for the Vulkan backend of 
its implementation of Direct3D 11 and earlier, where i386 applications 
are much more common.


Does that mean wine requires libvkd3d-shader for d3d11 with vulkan 
backend now?


Wine-dev compiled without vkd3d (as the case is for Debian10 ref. 
https://build.opensuse.org/build/Emulators:Wine:Debian/Debian_10/x86_64/wine-devel/_log 
) does not say anything about d3d11 vulkan backend not being supported? 
Should there be a note of that incase configure is missing/too old libvkd3d?


Sveinar



Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

2021-03-03 Thread Sveinar Søpler
I actually ended up generating a "vkd3d-tools" package for my Ubuntu PPA 
packages with this binary set
to Multi-Arch: no

This way ppl can optionally choose to install this as either x86_64 or i386 
depending on needs. However
i am very unsure if it is wise to be able to install a i386 binary directly in 
/usr/bin altogether?
Renaming this in the sceme like gcc does - eg. 
x86_64-linux-gnu-vkd3d-compiler/i686-linux-gnu-vkd3d-compiler
maybe? Not sure if that is reasonable either...

Libraries are installed in their respective /usr/lib/x86_64-linux-gnu or 
/usr/lib/i386-linux-gnu folders
depending on arch, so that is multi-arch.

Wine requires both the vkd3d-dev and vkd3d-dev:i386 packages with libraries 
installed when compiling to
support 64-bit and 32-bit d3d12 games. Not that i really know of many d3d12 
games that are 32-bit tho, but
for correctness sake, i think this should be the case. Many games still uses 
32-bit loaders even if the
game itself is 64-bit... what would happen if the loader does not find any 
d3d12 capabilities?

Sveinar Søpler


- On Mar 1, 2021, at 6:23 PM, Francois Gouget fgou...@free.fr wrote:

> Package: libvkd3d-dev
> Version: 1.2-3
> Severity: normal
> 
> 
> libvkd3d-dev 1.2-3 ships the architecture-dependent
> /usr/bin/vkd3d-compiler file which is incompatible with "Multi-Arch:
> same".
> 
> So as is the package is invalid.
> 
> Multiarch support in vkd3d is really needed though because Wine
> depends on it as Windows applications come in both 32-bit and 64-bit
> flavors. So lack of multiarch support in vkd3d prevents Wine from
> having D3D12 support in either its 32- or 64-bit versions thus making
> development much harder.
> 
> -- System Information:
> Debian Release: 10.8
>  APT prefers stable
>  APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr:en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libvkd3d-dev depends on:
> ii  libc6 2.28-10
> ii  libvkd3d-shader1  1.2-3
> ii  libvkd3d-utils1   1.2-3
> ii  libvkd3d1 1.2-3
> 
> libvkd3d-dev recommends no packages.
> 
> libvkd3d-dev suggests no packages.
> 
> -- no debconf information



Bug#952814: ITP libfaudio0 for buster-backports

2020-11-02 Thread Sveinar Søpler
As per wine-5.0 (and devel/staging) this is indeed a build requirement:
https://forum.winehq.org/viewtopic.php?f=8=32192

The wineHQ buildbot: 
https://build.opensuse.org/package/show/Emulators:Wine:Debian/FAudio

Be adwised that newer libfaudio requires libSDL2 >=2.0.9 to build, but 
Buster should have this already.

Sveinar

- On Nov 1, 2020, at 8:58 PM, Phil Morrell deb...@emorrp1.name wrote:

> Control: owner -1
> thanks
> 
> Hi,
> 
> I intend to build and maintain libfaudio0 for buster-backports unless
> there are any objections. It is needed for some third-party games like
> owlboy and terraria and I think it's now a prerequisite for a wine 5.0
> backport too.
> 
> It builds locally for me without issue or modification. I'm only a DM,
> so I believe I'll need to request both a sponsor and a backports ACL
> once its ready.
> --
> Phil Morrell (emorrp1)