Bug#1031649: wine: /usr/bin/wine64 still required

[Jens Reyer]

Hi Paul

On 09.03.23 15:50, Paul Gevers wrote:

Hi,

On Sun, 19 Feb 2023 18:17:39 -0600 Austin English 
 wrote:



Yes, it's arguably a bug in winetricks. Film what I gather upstream,
it's also not yet fully supported.
On Sat, 25 Feb 2023 17:10:47 +0100 Jens Reyer  
wrote:
ftr: I just uploaded a new winetricks 20230212-1 to unstable which 
should migrate to bookworm before the hard freeze. It workarounds a 
missing /usr/bin/wine64. The fix is quite late in Winetricks logic to 
figure out wine64, so it should work just fine with both setups.  
Tested against wine 8.0~repack-2, 8.0~repack-4 and winehq-staging 
8.2~bookworm-1.


If I understand correctly, this bug can now be downgraded in severity 
because winetricks migrated to bookworm. Maybe even better, reassign to 
winetricks and close it with the version in bookworm? Or am I missing 
the point?


Well, yes, from my winetricks perspective this bug could be closed as 
described.



But I suspect (without any evidence) that a missing /usr/bin/wine64 also 
affects others, at least in non-packaged software, but maybe also in 
Debian. Changing this now shortly before the release imo calls for 
trouble. In general I think /usr/bin/wine64 should be kept as long as 
Wine is built as it is now, since just too many people got used to it. 
Only once Wine is built the new way (upstream is still working on this) 
this setup should be changed.


This change was intended to fix #1029536, where I unfortunately 
mentioned that removing /usr/bin/wine64 might solve the issue. That 
issue may be either ignored or preferably fixed another way, e.g. by 
doing a "ln -s /usr/lib/wine/wine64 /usr/lib/wine/wine64-stable".


Finally this issue here blocked the fix for #1031102 from migrating to 
testing.  As far as I see that could be ignored, since it's a build 
issue with vulkan 1.3.239, which is also only in unstable. I do not know 
if the current wine 8.0~repack-4 would even build with the vulkan 
currently in testing. If it doesn't there would be a new rc bug.


So we have three options (ordered best to least from my perspective, and 
assuming wine builds with both vulkan versions from testing and unstable 
(requirement for 1 and 3). Please note that I stepped down from 
maintaining wine, and might miss something).


1.
Revert the /usr/bin/wine64 removal, add the /usr/lib/wine/wine64-stable 
link instead, and then let wine migrate to bullseye.


2.
Keep everything as it is now, make sure vulkan 1.3.239 doesn't make it 
to bullseye, and bullseye-ignore this and the 2 other bugs.


3.
Reassign this bug as you suggested to winetricks and close it with the 
version in bookworm.


Greets
jre

Bug#1031649: wine: /usr/bin/wine64 still required

[Jens Reyer]

On 20.02.23 01:17, Austin English wrote:
On Sun, Feb 19, 2023, 17:33 Jens Reyer <mailto:jre.wine...@gmail.com>> wrote:
Yes, it's arguably a bug in winetricks. Film what I gather upstream, 
it's also not yet fully supported.


I would advise reverting for now. At least until upstream fully supports it.


ftr: I just uploaded a new winetricks 20230212-1 to unstable which 
should migrate to bookworm before the hard freeze. It workarounds a 
missing /usr/bin/wine64. The fix is quite late in Winetricks logic to 
figure out wine64, so it should work just fine with both setups.  Tested 
against wine 8.0~repack-2, 8.0~repack-4 and winehq-staging 8.2~bookworm-1.

Bug#1031649: wine: /usr/bin/wine64 still required

[Jens Reyer]

On 19.02.23 21:45, Floris Renaud wrote:
Isn't this a bug in winetricks? When Wine is compiled the new way 
(--enable-archs=i386,x86_64), there isn't, as far as I know, a wine64 file.


 From 
https://github.com/Winetricks/winetricks/blob/master/src/winetricks#L3113

---

# Wrapper around winetricks_early_wine()
# Same idea, but use $WINE_ARCH, i.e., always use wine64 for 64-bit 
prefixes

# Currently only used by w_expand_env()
winetricks_early_wine_arch()
{
     WINE="${WINE_ARCH}" winetricks_early_wine "$@"
}
---


I see, thanks.  Well, then it should probably be changed in winetricks 
for this new Wine build.


But still, this change (prompted by a similar issue in a non-default 
Wine installation) breaks previously working setups in default 
installations.  I didn't think of that when originally mentioning this 
as a solution, but now I think changing this now shortly before a Debian 
release is not good.


Greets
jre

Bug#1031649: wine: /usr/bin/wine64 still required

[Jens Reyer]

Source: wine
Version: 8.0~repack-4
Severity: serious

Hi Mike,

I wasn't aware of this, but it seems indeed that /usr/bin/wine64 is 
required somehow: winetricks fails to start with 8.0~repack-4, but works 
with 8.0~repack-2.


I don't understand yet what's exactly going wrong (winetricks complains 
about some empty output, but if I execute said command manually I get 
the output), but I think the recent change should be reverted.


Greets anyway!
jre



Winetricks fails with 8.0~repack-4:

jens@thing:~$ wine --version
wine-8.0 (Debian 8.0~repack-4)
jens@thing:~$ winetricks
Executing mkdir -p /home/jens
--
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only 
install 32-bit versions of packages. If you encounter problems, please 
retest in a clean 32-bit WINEPREFIX before reporting a bug.

--
--
WINEPREFIX INFO:
Drive C: total 28
drwxr-xr-x  7 jens jens 4096 Feb 13 21:28 .
drwxr-xr-x  4 jens jens 4096 Feb 19 19:50 ..
drwxr-xr-x  3 jens jens 4096 Feb 13 21:28 ProgramData
drwxr-xr-x  6 jens jens 4096 Feb 13 21:28 Program Files
drwxr-xr-x  6 jens jens 4096 Feb 19 19:28 Program Files (x86)
drwxr-xr-x  4 jens jens 4096 Feb 13 21:28 users
drwxr-xr-x 21 jens jens 4096 Feb 19 19:28 windows

Registry info:
/home/jens/.wine/system.reg:#arch=win64
/home/jens/.wine/user.reg:#arch=win64
/home/jens/.wine/userdef.reg:#arch=win64
--
--
warning: wine cmd.exe /c echo '%AppData%' returned empty string, error 
message ""

--
jens@thing:~$ echo $?
1
jens@thing:~$ wine cmd.exe /c echo '%AppData%'
0098:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling 
back to RandR 1.0. Please consider using the Nouveau driver instead.
0034:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling 
back to RandR 1.0. Please consider using the Nouveau driver instead.

C:\users\jens\AppData\Roaming




Winetricks works with 8.0~repack-2:

jens@thing:~$ winetricks
Executing mkdir -p /home/jens
--
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only 
install 32-bit versions of packages. If you encounter problems, please 
retest in a clean 32-bit WINEPREFIX before reporting a bug.

--
Using winetricks 20220411 - sha256sum: 
a4952b40c48d104eb4bcb5319743c95ae68b404661957a134974ae4e1dc79b34 with 
wine-8.0 (Debian 8.0~repack-2) and WINEARCH=win64

winetricks GUI enabled, using zenity 3.44.0






-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wine depends on:
ii  wine32  8.0~repack-4
ii  wine64  8.0~repack-4

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks20220411-1

Versions of packages libwine depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-8
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libglib2.0-0 2.74.5-1
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgstreamer-plugins-base1.0-0   1.22.0-3
ii  libgstreamer1.0-01.22.0-2
ii  libpcap0.8   1.10.3-1
ii  libpulse016.1+dfsg1-2+b1
ii  libudev1 252.5-2
ii  libunwind8   1.6.2-3
ii  libusb-1.0-0 2:1.0.26-1
ii  libx11-6 2:1.8.3-3
ii  libxext6 2:1.3.4-1+b1
ii  libz-mingw-w64   1.2.13+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

Versions of packages libwine recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 8.0~repack-4
ii  gstreamer1.0-plugins-good  1.22.0-4
ii  libasound2-plugins 1.2.7.1-1
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-3 

Bug#987554: wine-development should be replaced with wine in experimental+backports

[Jens Reyer]

Hi

On 25.04.21 16:27, Adrian Bunk wrote:
> bullseye users would also benefit more from wine 6.0 in
> bullseye-backports

[not commenting on the whole issue]

I maintained the wine backports in the past, but stepped down
(https://lists.debian.org/debian-wine/2020/09/msg7.html).

But I agree that having them is very valuable.  So this is a call for
new wine backporters!

Greets
jre

Bug#985059: libwine-development: missing Breaks+Replaces: wine-development (<< 4.8)

[Jens Reyer]

On 12.03.21 11:40, Andreas Beckmann wrote:
>   Unpacking libwine-development:amd64 (5.6-1) over (4.2-4+b1) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-mfCwgB/93-libwine-development_5.6-1_amd64.deb 
> (--unpack):
>trying to overwrite '/usr/lib/wine-development/wineserver', which is also 
> in package wine-development 4.2-4
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
[...]
> According to snapshot.d.o 4.8-1 was the first version no longer shipping
> ./usr/lib/wine-development/wineserver in wine-development


See my commit 0ba2f523fdae3ec4787afafea18b28a98fe3f9b4 from back then, I
(probably) had the correct entries there, so you just have to re-apply
these:

Package: libwineVERSION
[...]
+Breaks:
+ wine32VERSION (<< 4.7-2~),
+ wine64VERSION (<< 4.7-2~),
+Replaces:
+ wine32VERSION (<< 4.7-2~),
+ wine64VERSION (<< 4.7-2~),

In 5.5-7 (latest git, please push your changes) they were still there.


Given that bullseye won't have wine-development I guess the packages
should keep such things for updates from buster until bullseye + 1.

Greets
jre

Bug#914794: Please upload fix for #914794 (libmspack fails tests on big endian architectures (s390x, mips))

[Jens Reyer]

Hi,

libmspack in unstable fixes a bug in cabextract (#914263
cabextract: -F option doesn't work correctly.) which affects winetricks.
 But cabextract and libmspack don't migrate because of this bug here.

This issue is already fixed upstream, but afaics not released yet.  Do
you know if this will happen soon, or may you consider uploading a fixed
version with the commits from upstream cherrypicked?

Debian buster is already in soft-freeze, so it would be best to have
this resolved in February.

Thanks in advance, also to upstream who seems to be reading this here!

Greets
jre

Bug#910944: [wine-development] FTBFS on arm64

[Jens Reyer]

Package: wine-development
Version: 3.17-1
Severity: serious
Tags: upstream, fixed-upstream


wine-development 3.17-1 ftbfs on arm64:

https://buildd.debian.org/status/fetch.php?pkg=wine-development=arm64=3.17-1=1539395513=0


It looks like upstream already fixed this in 3.18 with commits
6cfda8bf..d9998f77.

The build-failures on powerpc also seem to be fixed there, but I didn't
look to hard into that.

jre

Bug#903129: unicode-data: unicode-data 11 causes FTBFS in unstable

[Jens Reyer]

On 7/6/18 5:11 PM, Graham Inggs wrote:
> Source: unicode-data
> Version: 11.0.0-1
> Severity: serious
> Tags: ftbfs
> Control: affects -1 gucharmap libxmlada utf8proc wine wine-development
> 
> Hi Maintainer
> 
> The recent upload of unicode-data 11 causes several packages to FTBFS in
> unstable.  This bug is to prevent the migration of unicode-data to
> testing until its reverse build-dependencies have had a chance to adapt.

Thanks Graham!

"wine-development" 3.12 (coming within the next days) will support and
require this.

I will backport the change to "wine" for the next release (probably in
~2 months, or earlier if needed).

I'll remove the affects then.

Greets
jre

Bug#885548: winetricks: Don't recommend gksu

[Jens Reyer]

control: forwarded -1 https://github.com/Winetricks/winetricks/issues/912

> I won't be able to fix upstream for a few weeks, but I've filled a bug in
> the meantime:
> 
> https://github.com/Winetricks/winetricks/issues/912

There have been a few patches upstream, so I guess we'll have a solution
soon.

Greets
jre

Bug#887558: wine-development FTBFS on armel: selected processor does not support `strd r4,[sp]' in ARM mode

[Jens Reyer]

Source: wine-development
Version: 3.0~rc3-2
Severity: serious
Forwarded: https://bugs.winehq.org/show_bug.cgi?id=44365
Tags: upstream


gcc -c -o relay.o relay.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_
-D_REENTRANT -fPIC -Wall \
  -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
-Wignored-qualifiers \
  -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes
-Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith
-Wlogical-op -gdwarf-2 \
  -gstrict-dwarf -Werror -Wdate-time -g -O2
-fdebug-prefix-map=/<>=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong
-Wformat -Werror=format-security -march=armv5t -Wno-error -marm
-mfloat-abi=soft
[...]
{standard input}: Assembler messages:
{standard input}:51: Error: selected processor does not support `strd
r4,[sp]' in ARM mode
Makefile:521: recipe for target 'relay.o' failed
make[2]: *** [relay.o] Error 1
make[2]: Leaving directory '/<>/dlls/ntdll'
Makefile:13147: recipe for target 'dlls/ntdll' failed
make[1]: *** [dlls/ntdll] Error 2


I hope upstream fixes this soon.  Otherwise we'd have to remove armel
from the architecture list and file an RM bug against ftp.debian.org for
removal of the stale old armel packages (advice copied from #881446).

Previously I had mistaken a change in 3.0-rc3 to fix this, therefore the
wrong changelog entry in that version.

Greets
jre

Bug#868175: [pkg-wine-party] Bug#868175: wine: FTBFS: unknown matra Bottom_And_Left at ./tools/make_unicode

[Jens Reyer]

control: tags -1 patch

Hi

On 07/12/2017 09:03 PM, Niko Tyni wrote:
> Package: wine
> Version: 1.8.7-2
> 
> This package fails to build on current sid.
> 
> From the timing I'm guessing it regressed with unicode-data_10.0.0-1.
>   ./tools/make_unicode
>   unknown matra Bottom_And_Left at ./tools/make_unicode line 1226,  
> line 684.

Yes, indeed.  We already fixed that in wine-development 2.11-2 (the
changes in debian/patches/generate/unicode.patch), but I forgot about
src:wine in the archive.

Upstream is currently preparing wine 2.0.2 (eta ~ 1 week).  I'll add the
fix with that release (or whoever does it should do so).

Greets and thanks!
jre

Bug#867106: wine-development: build-depends unicode-data (< 10.0) but 10.0.0-1 is to be installed

[Jens Reyer]

I'm just catching up, and am not working on Wine yet.  So  just fyi
recently there was a patchset at WineHQ for Unicode 10:

https://www.winehq.org/pipermail/wine-patches/2017-July/163321.html
https://www.winehq.org/pipermail/wine-patches/2017-July/163322.html

That one got rejected, but I assume it at least made Wine build again.


Alternatively, I wonder if it is acceptable to temporarily embed the
Unicode 9 files in our source packages.  (I'm quite sure that WineHQ
will update to 10 soon, definitely in time for buster.)

Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

[Jens Reyer]

On 02/02/2017 02:30 PM, Steve McIntyre wrote:
> Dropping the -nostdlib argument to the gcc call inside sonames2elf
> makes a difference - it'll add libc6 to the mix and force the output
> to match the system you're building for. You may then need to filter
> out the libc6 entry afterwards, but that's easily done.

I'll do that for wine and wine-development, keeping options open for
dpkg to handle this correctly.

Filtering out isn't necessary: dpkg-shlibdeps already takes care of
removing redundant entries. And we do want to depend on libc6.

Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

[Jens Reyer]

On 02/01/2017 04:34 PM, Steve McIntyre wrote:
> Hey folks,
> 
> On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote:
>> On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
>>>
>>> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
>>> generate a library which does not link against libc (this is used by
>>> sonames2elf in some packages) causes both flags to be set (maybe
>>> because it's compatible with both?).
>>
>> Even worse, I've found at least one instance of a package containing
>> binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have
>> to remove the flags matching on EM_ARM ELF binaries for now. At least
>> this will get us back to the previous behavior with objdump, no
>> regression in that sense.
>>
>> To be able to distinguish armel from armhf I'd probably need to check
>> the arm attributes section for Tag_ABI_VFP_args, which annoyingly
>> seems to be set even when the HARD flag is not set. :/ But this will
>> be for dpkg 1.19.x.
> 
> Please don't go down that route, the ABI flags are intended to save
> people from that. I'm curious what's going wrong with libgsm1 here
> such that we're not seeing consistent ABI flags.

It's not just libgsm1, on armhf the build fails because of more than 20
libraries:

https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0

Greets
jre


If it helps, this is the short form of the code that triggers this (we
compute a list of dependencies for libs that are dlopen'ed by Wine):

$ sonamesDepends="libfontconfig.so.1 libfreetype.so.6 libncurses.so.5"
$ sonamesRecommends="libcups.so.2 libdbus-1.so.3 libfontconfig.so.1
libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.62
libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8
libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1
libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2
libXrender.so.1 libxslt.so.1 libXxf86vm.so.1"

$ printf 'INPUT(%s)\n' "$sonamesDepends" > libeverything.so
$ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf.depends

$ printf 'INPUT(%s)\n' "$sonamesRecommends" > libeverything.so
$ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o
elf.recommends

$ dpkg-shlibdeps --warnings=1 \
-pdlopen \
-dDepends -edebian/tmp/elf.depends \
-dRecommends -edebian/tmp/elf.recommends \
-Tdebian/libwine.substvars

Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

[Jens Reyer]

On 02/01/2017 05:08 AM, Guillem Jover wrote:
> On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
>> The new ABI mismatch detector seems to be a bit too strict on armel and
>> armhf.

Thanks to both of you for quickly handling this!


>> This was first seen with wine:
>> https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0
>> https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0
>>
>> But there seem to be some other recent build failures relating to this
>> as well.
> 
> Oh, wow, I'm not sure this is very kosher, but if it is causing build
> failures, then it does not matter much.

This sonames2elf stuff is only used to calculate dependencies on
dlopen'ed libraries.  For this we grep the sonames from config.h, create
an ELF that depends on all of them, and then use dpkg-shlibdeps against it.

It's an workaround until this feature is implemented directly in
dpkg-shlibdeps (#596715, dpkg-shlibdeps: Please allow to manually add
library dependencies via shlibdeps).

Greets
jre

Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

control: severity -1 important

Hi Vincent,

this only affects users that actually use Wine (if at all, see below).
Only then the .desktop file gets created (e.g. on running "winecfg" the
first time). Downgrading to important for now.

Funnily I can't reproduce this here. Despite having the problematic wine
entry in /home my system still uses firefox to open html files. Even
after removing and recreating the wine .desktop entries.

Therefore I also can't reproduce the specific crash.


I'm still working on understanding mime et al.:

AFAIK the .desktop files are somehow generated by winemenubuilder.

>From the .desktop files the system (not Wine itself) generates a
mimeinfo.cache file, which basically is a reverse index of them.

It seems the systemwide /usr/share/applications/mimeinfo.cache has
precendence over ~/.local/share/applications/mimeinfo.cache (here?):

$ grep htm ~/.local/share/applications/mimeinfo.cache
application/vnd.ms-htmlhelp=wine-extension-chm.desktop;
application/x-extension-htm=wine-extension-htm.desktop;
application/x-extension-html=wine-extension-html.desktop;
$ grep htm /usr/share/applications/mimeinfo.cache
application/xhtml+xml=firefox-esr.desktop;
application/xhtml_xml=chromium.desktop;
text/html=firefox-esr.desktop;chromium.desktop;
$ xdg-mime query default text/html
userapp-Firefox-1M35PY.desktop

No idea (yet) where/what this userapp-Firefox-1M35PY.desktop exactly is.


Outlook:

I think we want to keep winemenubuilder generally because that should be
used during the installation of Windows applications for creating
specific wanted file type associations.

But we want to patch out the generation of these general purpose file
type associations for e.g. *.html or (imo even more annoying) *.txt.
That might even be proposed to upstream.

Greets
jre

Bug#845452: Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Jens Reyer]

On 23.11.2016 18:06, Matthias Klose wrote:
> ta, and the fix will be in the next binutils upload too.

Great, given your recent binutils upload rate I expect that to happen
soon. So I'll probably stay lazy and avoid changing wine-development.

Bug#845452: Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Jens Reyer]

Control: reassign 845171 winbind/2.27.51.20161118-2
Control: affects 845171 wine-development
Control: tags 845171 - help moreinfo
Control: tags 845452 = patch


[ Referencing the other related bug here. ]

Matthias Klose wrote in https://bugs.debian.org/844847#35
> This looks like another regression with handling $ORIGIN in the
> linker (-rpath=\$ORIGIN/<...>).  The work around for the packages
> is to remove that option, you don't need to relocate the binaries
> when shipped as a debian package.

Thanks a lot! I can confirm that wine-development builds again with
attached patch, which removes the rpath $ORIGIN in configure.ac.

I'll test that a bit more and then commit for wine-development.


Matthias Klose wrote in https://bugs.debian.org/844847#35
> Cloning the bugs for the original packages ...

#845171 was still assigned to wine-development. Fixing metadata to what
I think you wanted.

Greets!
jre


--- a/configure.ac
+++ b/configure.ac
@@ -887,12 +887,12 @@ case $host_os in
   WINE_TRY_CFLAGS([-fPIC -Wl,--export-dynamic],
   [LDEXECFLAGS="-Wl,--export-dynamic"])
 
-  WINE_TRY_CFLAGS([-fPIC -Wl,--rpath,\$ORIGIN/../lib],
-  [LDRPATH_INSTALL="-Wl,--rpath,\\\$\$ORIGIN/\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
-   LDRPATH_LOCAL="-Wl,--rpath,\\\$\$ORIGIN/\$(top_builddir)/libs/wine"],
-  [WINE_TRY_CFLAGS([-fPIC -Wl,-R,\$ORIGIN/../lib],
-   [LDRPATH_INSTALL="-Wl,-R,\\\$\$ORIGIN/\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
-LDRPATH_LOCAL="-Wl,-R,\\\$\$ORIGIN/\$(top_builddir)/libs/wine"])])
+  WINE_TRY_CFLAGS([-fPIC -Wl,--rpath,./lib],
+  [LDRPATH_INSTALL="-Wl,--rpath,\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
+   LDRPATH_LOCAL="-Wl,--rpath,\$(top_builddir)/libs/wine"],
+  [WINE_TRY_CFLAGS([-fPIC -Wl,-R,./lib],
+   [LDRPATH_INSTALL="-Wl,-R,\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
+LDRPATH_LOCAL="-Wl,-R,\$(top_builddir)/libs/wine"])])
 
   WINE_TRY_CFLAGS([-Wl,--enable-new-dtags],
   [LDRPATH_INSTALL="$LDRPATH_INSTALL -Wl,--enable-new-dtags"])

Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Jens Reyer]

On 21.11.2016 22:07, Michael Gilbert wrote:
> On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote:
>> wine-development 1.9.22-1 (in stretch) built successfully on all
>> architectures when it was uploaded to unstable, but fails to
>> build in a stretch environment on i386 now (amd64 is still fine).
>> Exactly the same for 1.9.23-1 on i386 in a sid environment:
> 
> Hi Jens,
> 
> 1.9.23-1 built for me ok in a sid i386 chroot.  Can you clarify the
> setup where it fails?  Did you mean kfreebsd-i386?

Hi Mike

first off, it just built fine on debomatic-i386:
http://debomatic-i386.debian.net/distribution#unstable/wine-development/1.9.23-1/buildlog

And if I understood you correctly it also built fine for you *today*?

So it seems i386 is a local problem, for whatever reasons. If the
upcoming 1.9.24 will still build on the official buildd and noone else
can reproduce this, I'd say the i386 issue may be ignored (especially
for the stretch release). I'll update the bug metadata then.

But of course I need to figure this out here anyway.


I built with git-buildpackage for i386 (not kfreebsd-i386), on my usual
amd64 stretch/sid machine.

The failures began while using my old chroot (minimal base-sid-i386.cow
with only wine build-deps installed). But I now created a new one and
deleted the ccache. It still fails with the same error message when I do
this:

$ DIST=sid ARCH=i386 git pbuilder create
$ DIST=sid ARCH=amd64 git pbuilder update --override-config
$ gbp buildpackage -B \
--git-pbuilder \
--git-arch=i386 \
--git-dist=sid \
--git-upstream-tag="wine-%(version)s"


Similarly 1.9.22-1 failed with a fresh minimal base-stretch-i386.cow,
and ccache deleted.

Both 1.9.22-1 and 1.9.23-1 built fine here with gbp in the past, but
fail now (with an updated chroot).



> A recent change to binutils adds -Wl,--enable-new-dtags by default.
> That may be the cause of the problem on arm.

Unfortunately no, see the buildlogs at
https://buildd.debian.org/status/package.php?p=wine-development:

1.9.23-1 failed to build on Nov 13 (armel), and Nov 14 (armhf).
The binutils change "ld: enable new dtags by default for linux/gnu
targets.  Closes: #835859." was only uploaded on Nov 17.

1.9.23-1 failed with binutils_2.27.51.20161108-1 (armel and armhf)
1.9.22-1 built  with binutils_2.27-9+b1 (armel and armhf)


> The i386 and arm failures are probably different issues.

Ok, I'll try to look into the arm problem separately then. If I don't
find a solution soon, I'll file a separate bug for that.

btw, debomatic-...debian.net works like a charm for testing this.

Greets
jre

Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Jens Reyer]

Source: wine-development
Version: 1.9.22-1
Justification: FTBFS on i386, armel and armhf
Severity: serious
Tags: help


wine-development 1.9.22-1 (in stretch) built successfully on all
architectures when it was uploaded to unstable, but fails to
build in a stretch environment on i386 now (amd64 is still fine).
Exactly the same for 1.9.23-1 on i386 in a sid environment:

gcc -m32 -o wineserver async.o atom.o change.o class.o clipboard.o completion.o 
console.o debugger.o device.o \
  directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o 
mapping.o mutex.o \
  named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o 
request.o \
  semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o 
token.o trace.o \
  unicode.o user.o window.o winstation.o -Wl,--rpath,\$ORIGIN/../libs/wine \
  ../libs/port/libwine_port.a -lwine -L../libs/wine 
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now 
-Wl,-rpath,/usr/lib/i386-linux-gnu/wine-development
collect2: fatal error: ld terminated with signal 6 [Aborted]
compilation terminated.
ld: malloc.c:2403: sysmalloc: Assertion `(old_top == initial_top (av) && 
old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse 
(old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Makefile:732: recipe for target 'wineserver' failed
make[2]: *** [wineserver] Error 1
make[2]: Leaving directory '/build/wine-development-1.9.22/server'
Makefile:19180: recipe for target 'server' failed
make[1]: *** [server] Error 2
make[1]: *** Waiting for unfinished jobs
[...]
dh_auto_build: make -j4 returned exit code 2
debian/rules:100: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2



Further a local rebui1d of .9.22-1 failed on i386 on
2016-11-05[1], but succeeded again on 2016-11-07.

1.9.23-1 didn't build on armel[2], armhf[3] and kfreebsd-i386[4]
when it was uploaded to unstable, and failed on debomatic today
(the error message changed though).

These other failures are not exactly identical, but also happen
in ld. I assume they are all related.

I'm at a loss here what the reason for the failures is. I assume
it's somehow related to build-dependencies being rebuilt with pie
and bindnow and/or something in binutils (I found a similar recent
bugreport (#844847, xorp: FTBFS: collect2: fatal error: ld
terminated with signal 6 [Aborted]) which was reassigned to
binutils.)

However wine 1.8.5-1 still builds fine (wine and wine-development
are nearly identical, only the upstream version differs). If my
assumption was true, I'd expect wine to fail, too. Maybe it will
do so soon.

So what to do now?

I hope someone can help here.

If wine(-development) gets removed from the archive we need a fix
uploaded by December 25th to get it in Stretch (or find a solution
with the release team).

Greets
jre




[1] 1.9.22-1:i386, local rebuild on 2016-11-05
gcc -m32 -o wine-installed main.o \
  -Wl,--rpath,\$ORIGIN/`../tools/makedep -R /usr/lib/wine-development 
/usr/lib/i386-linux-gnu/wine-development` -Wl,--enable-new-dtags \
  -Wl,--export-dynamic -Wl,-Ttext-segment=0x7c00 
-Wl,-z,max-page-size=0x1000 -lwine -lpthread \
  ../libs/port/libwine_port.a -L../libs/wine -Wl,-z,relro -Wl,-z,now 
-Wl,-rpath,/usr/lib/i386-linux-gnu/wine-development
*** Error in `/usr/bin/ld': free(): invalid next size (fast): 0x57050ae0 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6733a)[0xf74ec33a]
/lib/i386-linux-gnu/libc.so.6(+0x6df77)[0xf74f2f77]
/lib/i386-linux-gnu/libc.so.6(+0x6e736)[0xf74f3736]
/usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(objalloc_free+0x3d)[0xf774011d]
/usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_hash_table_free+0x1c)[0xf76858ec]
/usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(+0x30568)[0xf768c568]
/usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_fopen+0x1c3)[0xf768ce13]
/usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_openr+0x25)[0xf768ce65]
/usr/bin/ld(+0x29d69)[0x5659cd69]
/usr/bin/ld(+0x2a385)[0x5659d385]
/usr/bin/ld(+0x2b1bf)[0x5659e1bf]
/usr/bin/ld(+0x1a2e6)[0x5658d2e6]
/usr/bin/ld(main+0x61f)[0x5657a3df]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xf749d276]
/usr/bin/ld(+0x7aeb)[0x5657aaeb]
=== Memory map: 
56573000-566ad000 r-xp  08:06 10898403   
/usr/bin/i686-linux-gnu-ld.bfd
566ad000-566b1000 r--p 00139000 08:06 10898403   
/usr/bin/i686-linux-gnu-ld.bfd
566b1000-566b3000 rw-p 0013d000 08:06 10898403   
/usr/bin/i686-linux-gnu-ld.bfd
566b3000-566b4000 rw-p  00:00 0 
56e65000-57088000 rw-p  00:00 0  [heap]
f730-f7321000 rw-p  00:00 0 
f7321000-f740 ---p  00:00 0 
f745-f746c000 r-xp  08:06 11026496   

Bug#830370: Merging and closing #830370: khronos-api: FTBFS: ImportError: No module named dateutil.parser

[Jens Reyer]

reassign 814914 src:khronos-api 0~svn29735-1
forcemerge 814914 830370
thanks

#830370 is a duplicate of #814914 reported by me. My nmu to fix this has
just been ACCEPTED into unstable.

Greets
jre
--- Begin Message ---
Source: khronos-api
Source-Version: 0~svn29735-1.1

We believe that the bug you reported is fixed in the latest version of
khronos-api, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 814...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jens Reyer <jre.wine...@gmail.com> (supplier of updated khronos-api package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 01 Jul 2016 16:46:18 +0200
Source: khronos-api
Binary: khronos-api
Architecture: source
Version: 0~svn29735-1.1
Distribution: unstable
Urgency: medium
Maintainer: Michael Gilbert <mgilb...@debian.org>
Changed-By: Jens Reyer <jre.wine...@gmail.com>
Description:
 khronos-api - Khronos XML API Registry
Closes: 814914
Changes:
 khronos-api (0~svn29735-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload. "DebConf upload."
   * Fix FTBFS. Add build-depends python-debian and python-dateutil
 (closes: #814914).
Checksums-Sha1:
 0355bfe5214f802e8ad313fabe35b414ba9e7722 1548 khronos-api_0~svn29735-1.1.dsc
 f34c0232200d53581b5a892d501db389f9252823 3408 
khronos-api_0~svn29735-1.1.debian.tar.xz
Checksums-Sha256:
 8ffe0e4ce9c0582c8675261b3e4b2aeca54336ba043eac469dd7619b611472e1 1548 
khronos-api_0~svn29735-1.1.dsc
 2fcbdf5d023d9ab08deb1383c1a13daead62e4a968df7925fb04ad92cc0cf4de 3408 
khronos-api_0~svn29735-1.1.debian.tar.xz
Files:
 181d77c0a9181cabab970f19774bf49b 1548 x11 optional 
khronos-api_0~svn29735-1.1.dsc
 78522a70e543ba6fde6e5f133927764a 3408 x11 optional 
khronos-api_0~svn29735-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJXdp5XAAoJEJxcmesFvXUKPUYIAI6Z+xpodgEQznyIGiQ9YqjV
biioTKS3TI6/RXtY3aaynM9dRHaax4hpT3bKlgAWYw05ICrD7rX0G/AE+TVU7T0y
VcM0d5gyJMhdhublCuVyKXtjtfRghIK0SA30AopV+AlpHw1Qf42m43xMQS6j/N2Q
MrNE94uu5e0mNjyiOqO99F/89oJRU4EtqkK5BntfIN+ciKpOdro8BJ9Lv63HtAtD
7wM8UitHfTvqjxOvtEdVyiexM+kkKdMjmKaqwHCb5JTQ4zeyMdnoIAmh9sHdidw2
1VXA2kmwiYvqYUAzagyCE2ik80p0d3cNIghZFKfZO8r4eVNFseYKy6bkk5MLZS8=
=LEHZ
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Package: khronos-api
Version: 0~svn29735-1
Severity: serious
Tags: patch

Hi,

khronos-api FTBFS in a clean chroot. It requires python-debian and
python-dateutil.

Otherwise the build fails due to:
  ImportError: No module named dateutil.parser
or:
  ImportError: No module named debian.changelog

Greets
jre


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information
diff --git a/debian/control b/debian/control
index 0d8ea6c..c7f2887 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Build-Depends:
  debhelper (>= 9),
  doc-base,
  python-lxml,
+ python-debian,
+ python-dateutil,
  texlive-latex-extra,
  texlive-fonts-recommended,
  texlive-generic-recommended,
--- End Message ---

Bug#829080: wine-development: FTBFS in testing (unknown breaktype EB)

[Jens Reyer]

control: tags -1 + pending

On 30.06.2016 12:04, Santiago Vila wrote:
> Package: src:wine-development
> Version: 1.9.12-1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> Severity: serious
> 
> Dear maintainer:
> 
> This package currently fails to build in stretch:

This will be fixed by the next upstream release 1.9.13 which builds with
Unicode 9.0 (just pushed to git; built, installed and tested locally).

Greets
jre

Bug#814914: NMU khronos-api: FTBFS due to missing build-dependencies

[Jens Reyer]

Hi Mike,

I'm currently at DebConf and got some sponsors around for fixing this
bug. Please find attached the debdiff. It will be uploaded in short time
nmu "delayed/10". Please let us know if we should delay it further.

Greets
jre
diff -Nru khronos-api-0~svn29735/debian/changelog 
khronos-api-0~svn29735/debian/changelog
--- khronos-api-0~svn29735/debian/changelog 2016-01-31 01:59:02.0 
+0100
+++ khronos-api-0~svn29735/debian/changelog 2016-07-01 18:05:56.0 
+0200
@@ -1,3 +1,11 @@
+khronos-api (0~svn29735-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload. "DebConf upload."
+  * Fix FTBFS. Add build-depends python-debian and python-dateutil
+(closes: #814914).
+
+ -- Jens Reyer <jre.wine...@gmail.com>  Fri, 01 Jul 2016 16:46:18 +0200
+
 khronos-api (0~svn29735-1) unstable; urgency=medium
 
   * Fix a lintian warning.
diff -Nru khronos-api-0~svn29735/debian/control 
khronos-api-0~svn29735/debian/control
--- khronos-api-0~svn29735/debian/control   2016-01-31 00:57:41.0 
+0100
+++ khronos-api-0~svn29735/debian/control   2016-07-01 18:20:09.0 
+0200
@@ -6,6 +6,8 @@
  debhelper (>= 9),
  doc-base,
  python-lxml,
+ python-debian,
+ python-dateutil,
  texlive-latex-extra,
  texlive-fonts-recommended,
  texlive-generic-recommended,

Bug#829003: wine: FTBFS since unicode 9 update

[Jens Reyer]

control: tags -1 + pending

Fix committed, based on the previously mentioned 2 commits. Some
files/contents were moved between Wine 1.8 and 1.9.13 (which carries the
Unicode 9.0 changes), which made spotting changes to autogenerated files
a bit harder.
In the resulting patch there are still some data tables and listings -
but these aren't generated automatically, so are indeed needed.

Greets
jre

Bug#829003: wine: FTBFS since unicode 9 update

[Jens Reyer]

Package: wine
Version: 1.8.3-1
Severity: serious
Justification: FTBFS/BD-Uninstallable


wine build-depends on missing unicode-data (< 9.0-1), but that isn't
available anymore.

I started working on a patch to backport the Unicode 9 changes to Wine
1.8, but haven't it ready yet. Basically it should all be in the
following 2 commits:

commit 58e0972c5ca8c82f65860733aaf3aeb41a7725bb
Author: Nikolay Sivov 
Date:   Wed Jun 22 15:00:22 2016 +0300

Update data tables to Unicode 9.0.0.

Signed-off-by: Nikolay Sivov 
Signed-off-by: Alexandre Julliard 

commit bbb9bbdbdb330aca21c363503274e21d558db1bc
Author: Nikolay Sivov 
Date:   Thu Jun 23 00:02:31 2016 +0300

dwrite: Update line breaking algorithm according to Unicode 9.0.0
specification.

Signed-off-by: Nikolay Sivov 
Signed-off-by: Alexandre Julliard 


Large parts of these 2 commits apply to files that we regenerate and
have added to d/clean. So they can and must be ignored.

I'll try to get something ready as time permits.

Greets
jre

Bug#814914: khronos-api: FTBFS due to missing build-dependencies

[Jens Reyer]

Package: khronos-api
Version: 0~svn29735-1
Severity: serious
Tags: patch

Hi,

khronos-api FTBFS in a clean chroot. It requires python-debian and
python-dateutil.

Otherwise the build fails due to:
  ImportError: No module named dateutil.parser
or:
  ImportError: No module named debian.changelog

Greets
jre


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information
diff --git a/debian/control b/debian/control
index 0d8ea6c..c7f2887 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Build-Depends:
  debhelper (>= 9),
  doc-base,
  python-lxml,
+ python-debian,
+ python-dateutil,
  texlive-latex-extra,
  texlive-fonts-recommended,
  texlive-generic-recommended,

Bug#814350: wine: recommended package libwine-gecko-2.40 is not in main

[Jens Reyer]

control: tags -1 + pending

On 02/10/2016 06:12 PM, Jens Reyer wrote:
> Imo the dependency on libwine-gecko-xxx should stay a recommends, a
> suggests imo doesn't meet the importance of Gecko in Wine.
> 
> So I'll commit a change to remove (comment) that from wine and
> wine-development.

Committed for both wine and wine-development. On a second thought I
decided to use suggests as you suggested. We should revert that as soon
as the correct version of libwine-gecko is available.

Greets
jre

Bug#812750: wine: Gecko integration is broken

[Jens Reyer]

On 02/09/2016 08:10 PM, Austin English wrote:
> On Feb 9, 2016 11:08 PM, "Rhonda D'Vine"  wrote:
>>
>>Hi,
>>
>> * Austin English  [2016-02-09 17:45:02 CET]:
>>> On Feb 9, 2016 8:39 PM, austinengl...@gmail.com wrote:
 On Feb 9, 2016 8:25 PM, "Rhonda D'Vine"  wrote:
>>>   Hi!
>>>
>>> * Ralf Jung  [2016-01-26 10:57:49 CET]:
 From all I can tell, the Gecko integration is entirely
> broken. There
 is no wine-gecko packaged in Debian
 (the recommendation of libwine-gecko-2.40 is unsatisfiable),
>^
>>
>> mingw64 is in main, what package are you referring to?
>
>  No clue why you mention mingw64, I am to the package I did quote
> in my
> mail and this bugreport is about, libwine-gecko-2.40.

 I'm asking what recommended package is the problem. It's not on
 packages.d.o and not specified in the mail as far as I can tell.
>>
>>  Erm, it is both on packages.debian.org/wine32 and also in this
>> bugreport mentioned multiple times.  So let me write it a third and
>> three time in this very email:
>> libwine-gecko-2.40 libwine-gecko-2.40 libwine-gecko-2.40
>>
>>> Or is it that libwine-gecko-2.40 isn't in main that is the problem? I
>>> thought the problem was a gecko recommend.
>>
>>  Maybe you should read what is written instead of guessing.
>> libwine-gecko-2.40 is not only not in main but not even nowhere in the
>> archive.
>>
>>  So long,
>> Rhonda
>> --
>> Fühlst du dich mutlos, fass endlich Mut, los  |
>> Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
>> Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf
> Anfang
>> Fühlst du dich haltlos, such Halt und lass los|
> 
> Yes, I got it now. Being condescending was neither necessary nor helpful.

I agree. I see how you got on the wrong track with your much broader
upstream background and our misleading use of gecko as a synonym for
libwine-gecko-2.40.


> Guess I'll go back to contributing upsream/elsewhere instead of trying to
> help Debian get a more functional Wine.

Of course only my opinion, but I am extremely happy that you are here.
Better relations do indeed help. Imo you correctly tell us about other
view points or problems, without being a pita when there are
non-resolvable conflicts. Personally I'd prefer more input from the
upsream side (as long as it stays productive).

Greets
jre

Bug#814350: wine: recommended package libwine-gecko-2.40 is not in main was: Bug#812750: wine: Gecko integration is broken

[Jens Reyer]

On 02/09/2016 08:14 PM, Rhonda D'Vine wrote:
>  Unfortunately unsatisfyable recommends are a policy violation though,
> and even while I understand the sentiments of not wanting to have to
> reupload wine to add it, I don't see a way around this.
[...]
>> Rhonda, do you see any flexibility in interpreting the policy for this
>> case? If not, I'll do something like
> 
>  Unfortunately I don't see it, it's a clear must requirement and there
> for very specific reasons, to keep main untainted from non-free
> packages.
> 
>  So yes, seperating the issue of that it might help to where to find
> gecko to install it personally, and lowering the recommends to suggests
> could definitely be tackled seperately.

Thanks Rhonda.

Imo the dependency on libwine-gecko-xxx should stay a recommends, a
suggests imo doesn't meet the importance of Gecko in Wine.

So I'll commit a change to remove (comment) that from wine and
wine-development.

Greets
jre

Bug#812750: wine: Gecko integration is broken

[Jens Reyer]

Hi

In Wine we depend on libwine-gecko-xxx before it's added to the archive,
knowing/hoping/assuming that it will be added to the archive, which has
always been true for Debian stable releases, but not for all
intermittent Gecko versions that were needed in between (maintainer is
in both cases the Wine packaging team, unfortunately afaik every new
Gecko upstream release takes a lot of work, especially for reevaluating
the copyrights).

Stephen, can you shed some light on the main problem(s) blocking
frequent Gecko releases? Let's say, there's some chance that I help.

This has the benefit of having the dependency already ready, once Gecko
is added to the archive, without the need to reupload Wine.

It may also show people more easily where work needs to be done
(increasing the people who help from 0 to 0).


Rhonda, do you see any flexibility in interpreting the policy for this
case? If not, I'll do something like

clone -1 -2
retitle -1 wine: doesn't find Gecko in documented place
severity -1 important
retitle -2 wine: recommends package not in main

and commit a fix for -2. Of course this doesn't solve the main problem
that the current libwine-gecko (2.40 for current wine, and 2.44 for
current wine-development package) is not available in the archive.

Greets
jre

Bug#813475: [pkg-wine-party] Bug#813475: Broken to run since upgrade

[Jens Reyer]

control: tags -1 + pending

Hi,

I just committed a patch that should fix that:

commit e3a8b8a90d62493f0097e4ff0d560743ca312c03
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Fri Feb 5 05:47:38 2016 +0100

Move Wine binaries to common directory.

This fixes the WoW64 setup for wine-development (closes: #813475).

Wine first looks in its bindir for the loaders and the server.
This bindir seems to be the dirname of the calling executable. So
if wine, wine64 and wineserver are in the same directory, they
are automatically found.

This bindir needs to be in the same file hierarchy level as the
bindir specified on package build, to prevent broken wine
internal links like /usr/lib/wine-development/../../../share/
wine-development/wine/wine.inf.

Therefore:
Move everything in /usr/lib/wineVERSION to new subdir wine.
Move adjusted wine and wineserver scripts to this dir, and create
links in /usr/bin.
Don't specify WINELOADER and WINESERVER explicitly.


The real working of bindir was a surprise once again. I noticed it while
I was trying to patch the upstream source to look for "-development" as
I suggested in #762058. So instead I chose this easier road now.

Note: /usr/bin/wine[32|64|server]-development aren't needed for this to
work. However I really strongly prefer to keep at least wineserver in
the PATH. I left all three of them there.

I successfully tested my changes and verified that a co-installed wine
doesn't break it.

btw @Klaus: you don't need the "export WINEARCH=win64" anymore, this is
the default now if wine64(-development) is installed.

Greets
jre

Bug#804046: No wine-development package and so not binary available anymore

[Jens Reyer]

On 11/05/2015 11:26 AM, Klaus Ethgen wrote:
>> I see that you only have wine64, but not wine32 installed. Is this a
>> result of the current issue, or did you really use Wine without the
>> 32-bit packages installed previously? I was under the impression that a
>> 64-bit only setup has no *real* use case and may fail.
> 
> Well, it is the result of the issue. But I don't use wine32 that much. I
> only use wine64 playing WoW (The only usecase for me :-D). That works
> well. Unfortunatelly for updates that doesn't as it battlenet is 32bit
> only.

But you had it installed, so you would have the manpages installed with
my proposed fix.

Re 64-bit-only installs: I digged that up and they are indeed not
supported by upstream. *Not* installing the recommended wine32-package
(with the manpages) is considered advanced and done on purpose (=don't
complain if something doesn't work, or if the manpages are missing).

>> All in all I'd still go with my committed fix (move manpages to wine32),
>> but I'd be less happy with it.
> 
> If the man pages do the trouble, why not splitting out them to a -doc
> package? That would be the cleanest way.

Unfortunately no, they are only built on 32-bit arches now. So unless we
change the buildsystem they are just not available from 64-bit builds.
So a -doc package doesn't help here.

Greets!
jre

Bug#804046: No wine-development package and so not binary available anymore

[Jens Reyer]

control: forcemerge 803778 -1

Hi,

thanks for reporting this. I already filed bug #803778 and committed a
fix. As a workaround you may build wine-development locally for the i386
architecture.

I see that you only have wine64, but not wine32 installed. Is this a
result of the current issue, or did you really use Wine without the
32-bit packages installed previously? I was under the impression that a
64-bit only setup has no *real* use case and may fail.

If I was wrong about that we might take another approach:

E.g. build the "arch all" package only on 32-bit architectures (not sure
if something like "Architecture: all [any-i386 any-powerpc armhf]" is
already supported).
Pro: manpages exist also for wine64 installation.
Con: local 64-bit-only builds lack the wine-development package.
IMO a clean handling of the manpages is not worth this disadvantage.

Or patch the buildystem.
Pro: Manpages always available and installed.
Con: Potential of sideeffects, maintenance burden.
I definitely don't want that.

All in all I'd still go with my committed fix (move manpages to wine32),
but I'd be less happy with it.

Greets
jre

Bug#803778: wine-development: arch all FTBFS on 64-bit architectures

[Jens Reyer]

Package: wine-development
Version: 1.7.54-1
Severity: serious
Justification: arch indep FTBFS on 64-bit architectures

Hi

The manpages are now built by upstream together with the binaries [1,
2]. The wine manpage is built together with wine32 (there is no separate
manpage for  wine64). So manpages are only built in arch specific
builds, but not in arch independent.
Since atm the manpages are part of the package wine-development (arch
all), there is a FTBFS on arch "all" if the buildd for "all" is 64-bit.

The amd64 and arm64 builds only succeeded because the buildds only build
arch specific packages there.

I'm filing this bug to prevent the incomplete builds to migrate to
testing (don't know if this would be possible).

Currently I'm testing a fix by simply installing the manpages in the
wine32-development package. I will commit that soon.

This fix implies that the wine script and the links in /usr/bin don't
have a manpage if only wine64 is installed, but not wine32. Since this
setup isn't supported upstream, I don't see this as a real issue. (Note
todo: lintian-overrides).


[1]
commit da340169d6518cf42f1cbe169fbf120383202bdc
Author: Alexandre Julliard 
Date:   Thu Oct 29 14:32:45 2015 +0900
makefiles: Generate rules for installing programs.

[2] Follow-up discussion:
https://www.winehq.org/pipermail/wine-devel/2015-November/110097.html


Greets
jre

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wine-development depends on:
ii  wine32-development  1.7.54-1
ii  wine64-development  1.7.54-1

wine-development recommends no packages.

wine-development suggests no packages.

Versions of packages wine-development is related to:
ii  fonts-wine-development1.7.54-1
ii  libwine-development   1.7.54-1
pn  libwine-development-dbg   
ii  libwine-development-dev   1.7.54-1
ii  wine-development  1.7.54-1 (local build on i386)
ii  wine32-development1.7.54-1
pn  wine32-development-preloader  
pn  wine32-development-tools  
ii  wine64-development1.7.54-1
pn  wine64-development-preloader  
ii  wine64-development-tools  1.7.54-1

-- no debconf information

Bug#784855: pytrainer disappeared from repositories (jessie and up)

[Jens Reyer]

control: severity -1 normal

Hi

> pytrainer disappeared from repositories (jessie and up)
> Severity: grave
> Justification: renders package unusable

Somewhat ironic, but I guess this bug report prevents pytrainer to
reenter testing due to its RC severity. Therefore I downgrade it to normal.
I hope it is ok that I tamper with this bug's severity. After looking at
the buglog I do this in the best faith.

Looking at the release-migration site [1] a missing "python:any" is
mentioned, but I guess this is a bug in the site, not relevant to pytrainer.

Let's see what's next in the story of pytrainer-not-in-stable.

Greets
jre


[1]:
https://release.debian.org/migration/testing.pl?package=pytrainer

Why is package X not in testing yet?

Checking pytrainer

pytrainer has no old version in testing (trying to add, not update)

pytrainer (source, amd64, i386, arm64, armel, armhf, mips, mipsel,
powerpc, ppc64el, s390x) has new bugs!

Dependency analysis (including build-depends; i386 only):

pytrainer depends on python:any << 2.8 which is not available in testing
  python:any is not available in Debian

pytrainer depends on python:any >= 2.7.5-5~, which is not available in
testing
  python:any is explained above