Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces

[Jens Reyer]

Control: found -1 3.21.91-1

Hi Andreas

I updated my system as requested (had to uninstall the gnome metapackage
and some extensions).

I can still reproduce this for my regular user with mutter/gnome-shell
3.21.91-1, see attachment. All extensions were disabled.

However it now works for a fresh user. Note that in the past I could
reproduce this on two machines, even for fresh users, see buglog.

At least GNOME now (at least since 3.20) doesn't disable all extensions
automatically anymore after a crash :)

Greets
jre
. xenv.sh
jens@hope:~$ gdb --args /usr/bin/gnome-shell --replace
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gnome-shell...Reading symbols from 
/usr/lib/debug/.build-id/78/afdb18f04b732ec496f2beb1489f0c899b0a41.debug...done.
done.
(gdb) run
Starting program: /usr/bin/gnome-shell --replace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdfaf1700 (LWP 4728)]
[New Thread 0x7fffdd0fe700 (LWP 4743)]
[New Thread 0x7fffdc8fd700 (LWP 4744)]
[New Thread 0x7fffcfdf2700 (LWP 4745)]
[New Thread 0x7fffcf3e9700 (LWP 4748)]
[New Thread 0x7fffcebe8700 (LWP 4749)]
[New Thread 0x7fffce3e7700 (LWP 4750)]
Gjs-Message: JS LOG: Failed to launch ibus-daemon: Failed to execute 
child process "ibus-daemon" (No such file or directory)
Gjs-Message: JS LOG: Failed to add search provider 
/usr/share/gnome-shell/search-providers/org.gnome.bijiben-search-provider.ini: 
TypeError: appInfo is null
[New Thread 0x7fffabfff700 (LWP 4760)]
[New Thread 0x7fffaaf33700 (LWP 4766)]
[Thread 0x7fffdc8fd700 (LWP 4744) exited]
[Thread 0x7fffabfff700 (LWP 4760) exited]
[New Thread 0x7fffabfff700 (LWP 4768)]
[New Thread 0x7fffdc8fd700 (LWP 4769)]
[New Thread 0x7fffa8b9c700 (LWP 4770)]
[New Thread 0x7fff9fffe700 (LWP 4771)]
[New Thread 0x7fff9f7fd700 (LWP 4772)]
[New Thread 0x7fff9effc700 (LWP 4773)]
[Thread 0x7fff9effc700 (LWP 4773) exited]
[Thread 0x7fffa8b9c700 (LWP 4770) exited]
[Thread 0x7fffaaf33700 (LWP 4766) exited]
[Thread 0x7fff9fffe700 (LWP 4771) exited]
[New Thread 0x7fff9fffe700 (LWP 4801)]
[New Thread 0x7fffaaf33700 (LWP 4802)]
[New Thread 0x7fffa8b9c700 (LWP 4803)]
[New Thread 0x7fff9effc700 (LWP 4804)]
[New Thread 0x7fff9e7fb700 (LWP 4805)]
[Thread 0x7fff9e7fb700 (LWP 4805) exited]
[Thread 0x7fff9effc700 (LWP 4804) exited]
[Thread 0x7fffa8b9c700 (LWP 4803) exited]
[Thread 0x7fffaaf33700 (LWP 4802) exited]
[Thread 0x7fff9f7fd700 (LWP 4772) exited]
[Thread 0x7fffdc8fd700 (LWP 4769) exited]
[Thread 0x7fff9fffe700 (LWP 4801) exited]
**
mutter:ERROR:core/screen.c:1206:update_num_workspaces: assertion failed: 
(w->windows == NULL)

Thread 1 "gnome-shell" received signal SIGABRT, Aborted.
0x74a03198 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) t a a bt

Thread 11 (Thread 0x7fffabfff700 (LWP 4768)):
#0  0x74ab2d49 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7501df7a in g_cond_wait_until (cond=cond@entry=0x88a248, 
mutex=mutex@entry=0x88a240, end_time=end_time@entry=227780230) at 
././glib/gthread-posix.c:1442
#2  0x74face39 in g_async_queue_pop_intern_unlocked 
(queue=queue@entry=0x88a240, wait=wait@entry=1, 
end_time=end_time@entry=227780230) at ././glib/gasyncqueue.c:422
#3  0x74fad45c in g_async_queue_timeout_pop (queue=0x88a240, 
timeout=timeout@entry=1500) at ././glib/gasyncqueue.c:543
#4  0x750009cd in g_thread_pool_thread_proxy () at 
././glib/gthreadpool.c:167
#5  0x750009cd in g_thread_pool_thread_proxy (data=) at 
././glib/gthreadpool.c:364
#6  0x7405 in g_thread_proxy (data=0x2c16450) at 
././glib/gthread.c:784
#7  0x74d78444 in start_thread (arg=0x7fffabfff700) at 
pthread_create.c:333
#8  0x74ab720d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7fffce3e7700 (LWP 4750)):
#0  0x74d7e07f in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fffe6582d70 in PR_WaitCondVar (cvar=0x9c6eb0, 
timeout=timeout@entry=4294967295) at ptsynch.c:396
#2  0x706d0536 in 

Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces

[Jens Reyer]

Control: tags -1 - moreinfo
Control: found -1 3.20.3-2

Hi

On 31.08.2016 06:09, Andreas Henriksson wrote:
> Are you still able to reproduce this issue? If so could you please
> provide a full backtrace including debugging symbols for it?
> 
> https://wiki.debian.org/HowToGetABacktrace

Yes, still happens every time I decrease the number of workspace
windows by one. If I repeat that step the whole GNOME session
crashes.

See attached screenlog.0

I followed https://wiki.gnome.org/Projects/GnomeShell/Debugging
(and added that link to the Debian wiki).


Exact steps I did:
[INSTALL] libmozjs-24-0-dbg:amd64 24.2.0-3.1
[INSTALL] libmutter0h-dbgsym:amd64 3.20.3-2
[INSTALL] libpulse0-dbgsym:amd64 9.0-2
[INSTALL] gnome-shell-dbgsym:amd64 3.20.3-1+b1
$ cat ~/xenv.sh
gnome_session=$(pgrep -u $USER gnome-session)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep DISPLAY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep 
XAUTHORITY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep 
DBUS_SESSION_BUS_ADDRESS)
--> Reboot
--> Login GNOME
--> CTRL-ALT-F3
--> Login tty3
$ screen
CTRL + A
SHIFT + H
$ . ~/xenv.sh
$ gdb --args /usr/bin/gnome-shell --replace
(gdb) run
--> CTRL-ALT-F2
--> Start Tweak Tool
Number of Workspaces was set to 2, but the same happens for 3 or 4.
--> Decrease Number of Workspaces by one
--> CRASH
--> CTRL-ALT-F3
(gdb) t a a bt
...
(gdb) call gjs_dumpstack ()


Greets
jre
jens@hope:~$ . xenv.sh
jens@hope:~$ gdb --args /usr/bin/gnome-shell --replace
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gnome-shell...Reading symbols from 
/usr/lib/debug/.build-id/8c/1e32f199e1391f19f8887cefa889baa7a5a774.debug...done.
done.
(gdb) run
Starting program: /usr/bin/gnome-shell --replace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdff9c700 (LWP 5010)]
[New Thread 0x7fffdd5a9700 (LWP 5042)]
[New Thread 0x7fffdcda8700 (LWP 5043)]
[New Thread 0x7fffc700 (LWP 5044)]
[New Thread 0x7fffcf7fe700 (LWP 5045)]
[New Thread 0x7fffceffd700 (LWP 5046)]
[New Thread 0x7fffce7fc700 (LWP 5047)]
Gjs-Message: JS LOG: Failed to launch ibus-daemon: Failed to execute child 
process "ibus-daemon" (No such file or directory)
Gjs-Message: JS LOG: Failed to add search provider 
/usr/share/gnome-shell/search-providers/org.gnome.bijiben-search-provider.ini: 
TypeError: appInfo is null
[New Thread 0x7fffabfff700 (LWP 5066)]
[New Thread 0x7fffaa668700 (LWP 5073)]
[Thread 0x7fffdcda8700 (LWP 5043) exited]
[Thread 0x7fffabfff700 (LWP 5066) exited]
[New Thread 0x7fffabfff700 (LWP 5077)]
[New Thread 0x7fffdcda8700 (LWP 5078)]
[New Thread 0x7fffa9e67700 (LWP 5079)]
[New Thread 0x7fffa8b9c700 (LWP 5080)]
[New Thread 0x7fff9fffe700 (LWP 5081)]
[New Thread 0x7fff9f7fd700 (LWP 5082)]
[Thread 0x7fffa9e67700 (LWP 5079) exited]
[Thread 0x7fffaa668700 (LWP 5073) exited]
[Thread 0x7fff9f7fd700 (LWP 5082) exited]
[Thread 0x7fffa8b9c700 (LWP 5080) exited]
[New Thread 0x7fffa8b9c700 (LWP 5103)]
[New Thread 0x7fff9f7fd700 (LWP 5104)]
[New Thread 0x7fffaa668700 (LWP 5107)]
[New Thread 0x7fffa9e67700 (LWP 5108)]
[New Thread 0x7fff9effc700 (LWP 5109)]
[New Thread 0x7fff9e7fb700 (LWP 5110)]
[New Thread 0x7fff9dffa700 (LWP 5112)]
[Thread 0x7fff9e7fb700 (LWP 5110) exited]
[Thread 0x7fffa8b9c700 (LWP 5103) exited]
[Thread 0x7fff9f7fd700 (LWP 5104) exited]
[Thread 0x7fffdcda8700 (LWP 5078) exited]
[Thread 0x7fffa9e67700 (LWP 5108) exited]
[Thread 0x7fff9fffe700 (LWP 5081) exited]
[Thread 0x7fffabfff700 (LWP 5077) exited]
[Thread 0x7fff9effc700 (LWP 5109) exited]
[Thread 0x7fff9dffa700 (LWP 5112) exited]
[New Thread 0x7fff9dffa700 (LWP 5162)]
[Thread 0x7fffaa668700 (LWP 5107) exited]
**
mutter:ERROR:core/screen.c:1206:update_num_workspaces: assertion failed: 
(w->windows == NULL)

Thread 1 "gnome-shell" received signal SIGABRT, Aborted.
0x74a30198 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) t a a bt

Thread 24 (Thread 0x7fff9dffa700 (LWP 5162)):
#0  0x74adfd49 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x750494ea in g_cond_wait_until (cond=cond@entry=0x889668, 

Bug#835976: gnupg2: autopkgtest requires nonexistent command wine32

[Jens Reyer]

Source: gnupg2
Version: 2.1.14-5
Severity: normal

Hi

I (wine comaintainer) noticed that you use the command wine32 in the
autopkgtest. This command doesn't exist anymore, since we moved closer
to upstream and provide a shared WoW64 setup (this enables users to run
32-bit and 64-bit applications at the same time in the same wineprefix
with the same wineserver).

So today you always use the command wine (in package wine),
independently if you want to run a 32-bit or a 64-bit application.

If you need support for 32-bit applications the package wine32 has to be
installed additionally. If available it's automatically pulled in by wine.

wine32 is available only on some 32-bit architectures:
 any-i386 any-powerpc armel armhf

You may add one of these as foreign architecture on a compatible 64-bit
architecture:
 amd64 arm64
This step has to be done manually.

Greets
jre

Bug#819255: wine-binfmt: doesn't register the binfmt on install/remove

[Jens Reyer]

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=39884

This has also been brought up upstream in #39884 for their packages, and
is now being discussed in wine-devel, beginning here:
  https://www.winehq.org/pipermail/wine-devel/2016-July/114021.html
and continuing here:
  https://www.winehq.org/pipermail/wine-devel/2016-August/114441.html

Setting this bug as forwarded of course doesn't mean that Debian and
Winehq have to go for the same solution. But if someone is able to
either provide a real life example, or to prove that this is not a
security risk, this would help.

Bug#834909: apt-cacher-ng: Fix typos in README

[Jens Reyer]

Package: apt-cacher-ng
Version: 0.9.3.2-1
Severity: minor
Tags: patch

Hi,

please see attached patch to fix 2 minor issues in the README (section
8.1 Package import).

1.)
The README talks about apt-cacher instead of apt-cacher-ng, while the
following example correctly uses apt-cacher-ng.

2.)
In the same section the example chmod command only changes the owner,
but not the group. You might have done this on purpose, than just please
ignore this.

Greets and thanks
jre


-- Package-specific info:

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

Kernel: Linux 4.6.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)

Versions of packages apt-cacher-ng depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.10
ii  init-system-helpers1.42
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.23-4
ii  libgcc11:6.1.1-11
ii  liblzma5   5.1.1alpha+20120614-2.1
ii  libssl1.0.21.0.2h-1
ii  libstdc++6 6.1.1-11
ii  libsystemd0230-7
ii  libwrap0   7.6.q-25
ii  zlib1g 1:1.2.8.dfsg-2+b1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.32-1
ii  doc-base  0.10.7
ii  libfuse2  2.9.7-1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied:
u'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/port: keep
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/bindaddress: keep
diff --git a/doc/README b/doc/README
index 4d4410b..2fe4901 100644
--- a/doc/README
+++ b/doc/README
@@ -858,14 +858,14 @@ Chapter 8: HOWTOs and FAQ
 
 2. Store copies of your .debs, .orig.tar.gz, ... somewhere in the
`_import' subdirectory in the cache, ie. in `/var/cache/apt-
-   cacher/_import/'. The files may be links or symlinks, does not
+   cacher-ng/_import/'. The files may be links or symlinks, does not
matter. When done, apt-cacher will move those files to its own
internal locations. Example:
 
  cd /var/cache
  mkdir apt-cacher-ng/_import
  cp -laf apt-proxy apt-cacher /var/cache/apt-cacher-ng/_import
- chown -R apt-cacher-ng apt-cacher-ng/_import
+ chown -R apt-cacher-ng:apt-cacher-ng apt-cacher-ng/_import
 
 3. Visit the report page and trigger the import action there. Check
the results, look for (red) error messages.

Bug#834168: icedove: Segfaults after start (./mozilla/js/src/jit/JitFrames.cpp: No such file or directory)

[Jens Reyer]

control: fixed -1 1:45.2.0-3


Hi Carsten!

On 12.08.2016 20:31, Carsten Schoenert wrote:

Please note the follwing and all merged reports.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833635


Thanks. I had read some of them, but didn't see them as releavant. 
Annoying I missed the clearly identical ones before reporting.




While writing this email Christoph has uploaded a new version -3 und
hopefully the (most) nullpointers are gone by this due some more
compiler flags.


Confirmed, icedove starts successfully again.



No, not needed right now, this is currently a Debian problem, mhh but in
the end ... it is a upstream source issue. Somethere in the various bug
report traffic I wrote the real issue. Can't find it now. :/


Maybe these:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833635#28
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833698#20

Greets!
jre

Bug#832129: [wine-development]: RegEdit fails to export whole registry

[Jens Reyer]

On 13.08.2016 19:40, Joerg Schiermeier wrote:

Hello,

I sent a patch to WinHQ and it was accepted. See patch here:


Now this is working.
Maybe someone wants to close this ticket?


Thanks for your work.
I already tagged the report fixed-upstream. It will be closed once the 
fixed version is uploaded to the archive.


Greets
jre

Bug#826231: [rt.debian.org #6324] AutoReply: Please add Jens Reyer's key to the DM keyring

[Jens Reyer]

On 05.07.2016 21:08, Aníbal Monsalve Salazar wrote:

Control: package debian-maintainers
Control: tags -1 + pending

Hello Jens Reyer,

Your DM application was accepted and the corresponding RT ticket is
posted at https://rt.debian.org/Ticket/Display.html?id=6324

Currently, rt.debian.org isn't accessible for the general public. It
was sometime ago. Maybe one of your advocates will look at your RT
ticket for you, after it has been taken by a keyring maintainer. See
http://wiki.debian.org/rt.debian.org


Hi!

my key was added in debian-keyring 2016.08.10 (yay!), but not mentioned 
in the changelog. Accordingly this bug here is still open.


The same for Jerome Benoit (#825940).

Greets & thanks!
jre

Bug#834168: icedove: Segfaults after start (./mozilla/js/src/jit/JitFrames.cpp: No such file or directory)

[Jens Reyer]

Package: icedove
Version: 1:45.2.0-2+b1
Severity: normal

Hi!

Since 2 days icedove always segfaults after starting (before icedove is 
ready for user interaction).


The backtrace ends with:
Thread 1 "icedove-bin" received signal SIGSEGV, Segmentation fault.
0x73e007a1 in js::jit::SnapshotIterator::numAllocations 
(this=0x7fffa0b0) at ./mozilla/js/src/jit/JitFrames.cpp:2159

2159./mozilla/js/src/jit/JitFrames.cpp: No such file or directory.

This happens since the update 1:45.2.0-2 -> 1:45.2.0-2+b1. But I already 
had random crashes (probably since version 45) before.


This does not happen with "icedove -safe-mode".

Therefore the backtrace is for a regular "icedove" session, otherwise I 
followed https://wiki.debian.org/Icedove#Debugging. Before I made the 
backtrace I uninstalled all specific (r)dependencies of icedove, and 
permanently disabled all add-ons and reset toolbars and controls with 
safe-mode .


Should I report upstream?

Greets!
jre



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (100, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.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)

Versions of packages icedove depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.5
ii  libasound21.1.2-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.23-4
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.5
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-2
ii  libgtk2.0-0   2.24.30-4
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu57  57.1-2
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.25-1
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.33.6-1
ii  libsqlite3-0  3.13.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-11
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
pn  iceowl-extension  
ii  myspell-de-de [myspell-dictionary]20160407-1

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.2.0-2
ii  libgssapi-krb5-2  1.14.3+dfsg-1

-- no debconf information
MOZILLA_FIVE_HOME=/usr/lib/icedove
  LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
done.
(gdb) handle SIGPIPE nostop
SignalStop	Print	Pass to program	Description
SIGPIPE   No	Yes	Yes		Broken pipe
(gdb) handle SIG38 nostop
SignalStop	Print	Pass to program	Description
SIG38 No	Yes	Yes		Real-time event 38
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin 
[Thread debugging using libthread_db enabled]
Using host 

Bug#833956: wine-development: FTBFS on hurd-i386 and kfreebsd-i386

[Jens Reyer]

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=41117

On 10.08.2016 22:41, Pino Toscano wrote:
[...]
> sysinfo(2) is strictly specific to Linux.
[...]
> Headers in sys/ and bits/ usually are implementations for the platform;
> since sys/sysinfo.h is not standard, you cannot assume that it exists
> only on a platform, nor what it provides.  In this case, the upstream
> check is wrong: it should not check for sys/sysinfo.h and assume it's
> a Linux-ish implementation, but either:
> a) just limit the implementation to Linux unconditionally (as in the
>busybox code
> b) check for sys/sysinfo.h *and* sysinfo() in it
> Considering sysinfo() is not portable anyway, (b) might fail one day
> if a platform provide a different implementation with the same name
> (it's not standard after all).
> 
> Hope it helps -- feel free to ask more.

Thanks a lot, it helped indeed.

I forwarded the issue to upstream for now.

Greets
jre

Bug#833956: wine-development: FTBFS on hurd-i386 and kfreebsd-i386

[Jens Reyer]

Package: wine-development
Version: 1.9.15-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: kfreebsd
User: debian-h...@lists.debian.org
Usertags: hurd


[ I hope I got the CC and tags right, first time I look into a
  portability issue. ]


Hi,

src:wine-development since 1.9.15-1 fails to build on hurd-i386
and kfreebsd-i386. It built successfully before.

The later uploaded src:wine 1.8.3-3 still builds successfully.

Build log for hurd-i386:
https://buildd.debian.org/status/fetch.php?pkg=wine-development=hurd-i386=1.9.15-1=1469253468

Build log kfreebsd-i386:
https://buildd.debian.org/status/fetch.php?pkg=wine-development=kfreebsd-i386=1.9.15-1=1469253097
~
gcc -c -o virtual.o virtual.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ 
-D_REENTRANT -fPIC -Wall \
  -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
-Wignored-qualifiers \
  -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla 
-Wwrite-strings -Wpointer-arith \
  -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror 
-Wdate-time -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-error
virtual.c: In function 'virtual_get_system_info':
virtual.c:1363:20: error: storage size of 'sinfo' isn't known
 struct sysinfo sinfo;
^
virtual.c:1372:10: warning: implicit declaration of function 'sysinfo' 
[-Wimplicit-function-declaration]
 if (!sysinfo())
  ^
virtual.c:1363:20: warning: unused variable 'sinfo' [-Wunused-variable]
 struct sysinfo sinfo;
^
Makefile:711: recipe for target 'virtual.o' failed
~



I assume (not tested) this is because of:

commit d0832cdf428696e2c08b1aa27382baad4d1e376f
Author: Michael Müller 
Date:   Fri Jul 8 05:40:22 2016 +0200

ntdll: Use sysinfo to report correct number of physical pages.

Signed-off-by: Michael Müller 
Signed-off-by: Sebastian Lackner 
Signed-off-by: Alexandre Julliard 

http://source.winehq.org/git/wine.git/commitdiff/d0832cdf428696e2c08b1aa27382baad4d1e376f



The code is only called conditionally (ifdef HAVE_SYS_SYSINFO_H).

It has "include ", which is provided in:
/usr/include/i386-gnu/sys/sysinfo.h   libc0.3-dev [hurd-i386] 
/usr/include/i386-kfreebsd-gnu/sys/sysinfo.h  libc0.1-dev [kfreebsd-i386] 

However "totalram" and "mem_unit" are only in:
/usr/include/linux/sysinfo.h  linux-libc-dev

So sysinfo.h exists on hurd/kfreebsd, but doesn't provide everything
necessary!? Is there a fix for this, or should we disable this code
on hurd/kfreebsd explicitly? Or am I on a completely wrong track here?
Patches welcome, otherwise I'll ask upstream.

I found a similar (not identical) issue in busybox:
https://bugs.debian.org/677254.
Fix:
https://git.busybox.net/busybox/commit/?id=ac42e3de90ebf4b921035893e3670da63cad882c

Greets
jre

Bug#790339: [wine-development] Last two upgrades: Kindle No Longer Working

[Jens Reyer]

control: tags -1 + moreinfo


On 28.06.2015 10:21, David Baron wrote:
> Some downloaded books simply highlight but do not go to reader.
> Others crash out. Backtrace attacher

>From https://bugs.winehq.org/show_bug.cgi?id=38383:

Did you install the required MS core fonts?


There were some changes in our fonts packages, please make sure that you
have at least fonts-wine 1.8.2-1 installed and check again.

If it still fails you might try ttf-mscorefonts-installer (from the
contrib section).

Please report back.


> --- Package information. ---
> Package's Depends field is empty.

This seems very wrong. Either your Wine installation is broken, or
something went wrong while you reported the bug.


Greets
jre

Bug#816020: /usr/bin/wineserver disables persistence delay

[Jens Reyer]

control: severity -1 wishlist

On 18.06.2016 00:44, Jens Reyer wrote:
> On 26.02.2016 19:08, Jakub Wilk wrote:
>> /usr/bin/wineserver passes -p0 to wineserver32. This seems to be an
>> undocumented deviation from upstream behavior. The manpage says: "the
>> default value is 3 seconds".
> 
> I'll patch the manpage.

Done in wine 1.8.3-3.

Downgrading the severity to wishlist for the request to revert to the
upstream behavior.

Bug#819255: wine-binfmt: doesn't register the binfmt on install/remove

[Jens Reyer]

control: severity -1 wishlist

On 28.07.2016 17:08, Jens Reyer wrote:
> This is documented in the README.debian, which also gives an explanation
> why this doesn't happen automatically (I just added the last paragraph
> with removal instructions in git master):

Released in wine 1.8.3-3.

Downgrading the severity to wishlist.

Bug#833795: wine-development breaks wine < 1.8.3-3

[Jens Reyer]

Package: wine-development
Version: 1.9.16-1
Severity: serious
Justification: Maintainer decision, prevent too early testing migration

wine-development 1.9.16-1 breaks wine < 1.8.3-3 to avoid file name
conflicts resulting from the Debian alternatives system, which was
introduced in these versions.

I just uploaded wine 1.8.3-3 and will close this bug as soon as wine has
migrated to testing.



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

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

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

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox   0.74-4.2+b1
pn  playonlinux  
ii  wine-binfmt  1.8.3-3
pn  winetricks   

Versions of packages wine-development is related to:
ii  fonts-wine  1.8.3-3
ii  wine-development1.9.16-1
ii  wine32-development  1.9.16-1
ii  wine64-development  1.9.16-1

-- no debconf information

Bug#832919: unicode-data: Obsolete typo fix xpecially/especially in d/rules and patch update.

[Jens Reyer]

gnn, I forgot: you might want to fix the typo 827098/827908 in the last
changelog entry (bts is already fixed).

Updated patch with this change included attached.
diff --git a/debian/changelog b/debian/changelog
index f6c7345..7179054 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,6 @@
 unicode-data (9.0-1) unstable; urgency=medium
 
-  * New upstream release. Closes: #827098.
+  * New upstream release. Closes: #827908.
   * Move to Standards-Version: 3.9.6. No changes required.
  
  -- Alastair McKinstry   Wed, 22 Jun 2016 14:49:26 +0100
diff --git a/debian/namealias.patch b/debian/namealias.patch
index 90618dd..7d9cc6c 100644
--- a/debian/namealias.patch
+++ b/debian/namealias.patch
@@ -1,6 +1,6 @@
 /usr/share/unicode/NameAliases.txt	2015-10-12 16:39:44.0 +0200
-+++ NameAliases.txt	2015-12-20 12:16:42.298438420 +0100
-@@ -287,7 +287,6 @@
+--- /usr/share/unicode/NameAliases.txt	2016-01-22 14:27:00.0 +0100
 NameAliases.txt	2016-07-29 17:22:20.815820721 +0200
+@@ -289,7 +289,6 @@
  2B7A;LEFTWARDS TRIANGLE-HEADED ARROW WITH DOUBLE VERTICAL STROKE;correction
  2B7C;RIGHTWARDS TRIANGLE-HEADED ARROW WITH DOUBLE VERTICAL STROKE;correction
  A015;YI SYLLABLE ITERATION MARK;correction
@@ -8,7 +8,7 @@
  FE00;VS1;abbreviation
  FE01;VS2;abbreviation
  FE02;VS3;abbreviation
-@@ -304,6 +303,7 @@
+@@ -306,6 +305,7 @@
  FE0D;VS14;abbreviation
  FE0E;VS15;abbreviation
  FE0F;VS16;abbreviation
diff --git a/debian/rules b/debian/rules
index 0f54a44..901fa2a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,6 @@ $(STAMP_DIR)/build-stamp:
 		tr -d \\r < $$f > tmpf  ; \
 		mv tmpf $$f ;			\
 		done )
-	sed -i s/expecially/especially/ $(SOURCE_DIR)/Unihan_Readings.txt
 	( cd $(SOURCE_DIR) && patch  < ../debian/namealias.patch )
 	bzip2 $(SOURCE_DIR)/NormalizationTest.txt
 	( cd $(SOURCE_DIR); for d in Unihan*.txt ; do \


signature.asc
Description: OpenPGP digital signature

Bug#832924: unicode-data: Please provide VerticalOrientation-NN.txt

[Jens Reyer]

Package: unicode-data
Version: 9.0-1
Severity: wishlist
Tags: patch

Hi,

can you add VerticalOrientation-NN.txt to the unicode-data package?

Upstream of src:wine and src:wine-development ships with code generated
from this file (currently they use rev. 15).

The latest approved revision is rev. 15 (character repertoire for
Unicode 8.0).

The latest non-approved revision is 16 (for Unicode 9.0).

I propose to ship both for now, and once it's available only 17 (no hard
opinion here). The non-approved rev has a big warning:
"This is a draft document which may be updated, replaced, or superseded
by other documents at any time. Publication does not imply endorsement
by the Unicode Consortium. This is not a stable document; it is
inappropriate to cite this document as other than a work in progress."

Source:
http://www.unicode.org/Public/vertical/
http://www.unicode.org/Public/vertical/revision-15/VerticalOrientation-15.txt
http://www.unicode.org/Public/vertical/revision-16/VerticalOrientation-16.txt

Documentation:
http://www.unicode.org/reports/tr50/
http://www.unicode.org/reports/tr50/tr50-15.html
http://www.unicode.org/reports/tr50/tr50-16.html

Copyright:
They have the same terms of use as the other Unicode files
(http://www.unicode.org/terms_of_use.html which redirects to
http://www.unicode.org/copyright.html)


Attached patch contains rev. 15 and 16, installs them in
/usr/share/unicode and adds download info in d/copyright (applies on top
of my patch in #832921).

Greets
jre
diff --git a/debian/VerticalOrientation-15.txt b/debian/VerticalOrientation-15.txt
new file mode 100644
index 000..972b389
--- /dev/null
+++ b/debian/VerticalOrientation-15.txt
@@ -0,0 +1,1019 @@
+# VerticalOrientation-15.txt
+# Date: 2015-11-16, 20:00:00 GMT [EM, KI, LI]
+#
+# Note: This data file accompanies Revision 15 of Unicode® Technical
+# Report #50, which has approved status.
+#
+# Vertical_Orientation (vo) Property
+#
+# This file defines the Vertical_Orientation property. The file is not
+# formally part of the Unicode Character Database.
+#
+# Copyright © 2011–2015 Unicode, Inc.
+# For terms of use, see http://www.unicode.org/terms_of_use.html
+# For documentation, see Revision 15 of
+# Unicode® Technical Report #50: Unicode Vertical Text Layout,
+# at http://www.unicode.org/reports/tr50/tr50-15.html
+#
+# The character repertoire of this revision is the repertoire of
+# Unicode Version 8.0.
+#
+# The format of the file is two fields separated by a semicolon.
+# Field 0: Unicode code point value or range of code point values in
+#   hexadecimal form
+# Field 1: Vertical_Orientation property value, one of the following:
+#   U - Upright, the same orientation as in the code charts
+#   R - Rotated 90 degrees clockwise compared to the code charts
+#   Tu - Transformed typographically, with fallback to Upright
+#   Tr - Transformed typographically, with fallback to Rotated
+#
+# @missing: ..10; R
+
+..001F ; R
+0020 ; R
+0021 ; R
+0022 ; R
+0023 ; R
+0024 ; R
+0025 ; R
+0026 ; R
+0027 ; R
+0028 ; R
+0029 ; R
+002A ; R
+002B ; R
+002C ; R
+002D ; R
+002E..005A ; R
+005B ; R
+005C ; R
+005D ; R
+005E ; R
+005F ; R
+0060..007A ; R
+007B ; R
+007C ; R
+007D ; R
+007E ; R
+007F ; R
+0080..009F ; R
+00A0 ; R
+00A1 ; R
+00A2 ; R
+00A3 ; R
+00A4 ; R
+00A5 ; R
+00A6 ; R
+00A7 ; U
+00A8 ; R
+00A9 ; U
+00AA ; R
+00AB ; R
+00AC ; R
+00AD ; R
+00AE ; U
+00AF ; R
+00B0 ; R
+00B1 ; U
+00B2 ; R
+00B3 ; R
+00B4 ; R
+00B5 ; R
+00B6 ; R
+00B7 ; R
+00B8 ; R
+00B9 ; R
+00BA ; R
+00BB ; R
+00BC ; U
+00BD ; U
+00BE ; U
+00BF ; R
+00C0..00D6 ; R
+00D7 ; U
+00D8..00F6 ; R
+00F7 ; U
+00F8..00FF ; R
+0100..017F ; R
+0180..024F ; R
+0250..02AF ; R
+02B0..02E4 ; R
+02E5 ; R
+02E6 ; R
+02E7 ; R
+02E8 ; R
+02E9 ; R
+02EA ; U
+02EB ; U
+02EC..02FF ; R
+0300..036F ; R
+0370..03FF ; R
+0400..04FF ; R
+0500..052F ; R
+0530..0589 ; R
+058A ; R
+058B..058C ; R
+058D..058E ; R
+058F ; R
+0590..05BD ; R
+05BE ; R
+05BF..05FF ; R
+0600..06FF ; R
+0700..074F ; R
+0750..077F ; R
+0780..07BF ; R
+07C0..07FF ; R
+0800..083F ; R
+0840..085F ; R
+08A0..08FF ; R
+0900..097F ; R
+0980..09FF ; R
+0A00..0A7F ; R
+0A80..0AFF ; R
+0B00..0B7F ; R
+0B80..0BFF ; R
+0C00..0C7F ; R
+0C80..0CFF ; R
+0D00..0D7F ; R
+0D80..0DFF ; R
+0E00..0E7F ; R
+0E80..0EFF ; R
+0F00..0FFF ; R
+1000..109F ; R
+10A0..10FF ; R
+1100..11FF ; U
+1200..137F ; R
+1380..139F ; R
+13A0..13FF ; R
+1400 ; R
+1401..167F ; U
+1680..169F ; R
+16A0..16FF ; R
+1700..171F ; R
+1720..173F ; R
+1740..175F ; R
+1760..177F ; R
+1780..17FF ; R
+1800..18AF ; R
+18B0..18FF ; U
+1900..194F ; R
+1950..197F ; R
+1980..19DF ; R
+19E0..19FF ; R
+1A00..1A1F ; R
+1A20..1AAF ; R
+1AB0..1AFF ; R
+1B00..1B7F ; R
+1B80..1BBF ; R
+1BC0..1BFF ; R
+1C00..1C4F ; R
+1C50..1C7F ; R
+1CC0..1CCF ; R
+1CD0..1CFF ; R
+1D00..1D7F ; R
+1D80..1DBF ; R
+1DC0..1DFF ; R
+1E00..1EFF ; R
+1F00..1FFF ; R
+2000..200A ; R
+200B..200F ; R
+2010 ; R
+2011 ; R
+2012 ; R
+2013 ; R
+2014 ; R
+2015 ; R
+2016 ; U
+2017 ; R
+2018 ; R

Bug#832919: unicode-data: Obsolete typo fix xpecially/especially in d/rules and patch update.

[Jens Reyer]

Source: unicode-data
Version: 9.0-1
Severity: minor
Tags: patch

Hi,

I noticed that the typo fix xpecially/especially in d/rules isn't needed
anymore (no occurrence in Unihan_Readings.txt). Attached patch drops
this line.

Attached patch also refreshes the namealias.patch.

Greets
jre
diff --git a/debian/namealias.patch b/debian/namealias.patch
index 90618dd..7d9cc6c 100644
--- a/debian/namealias.patch
+++ b/debian/namealias.patch
@@ -1,6 +1,6 @@
 /usr/share/unicode/NameAliases.txt	2015-10-12 16:39:44.0 +0200
-+++ NameAliases.txt	2015-12-20 12:16:42.298438420 +0100
-@@ -287,7 +287,6 @@
+--- /usr/share/unicode/NameAliases.txt	2016-01-22 14:27:00.0 +0100
 NameAliases.txt	2016-07-29 17:22:20.815820721 +0200
+@@ -289,7 +289,6 @@
  2B7A;LEFTWARDS TRIANGLE-HEADED ARROW WITH DOUBLE VERTICAL STROKE;correction
  2B7C;RIGHTWARDS TRIANGLE-HEADED ARROW WITH DOUBLE VERTICAL STROKE;correction
  A015;YI SYLLABLE ITERATION MARK;correction
@@ -8,7 +8,7 @@
  FE00;VS1;abbreviation
  FE01;VS2;abbreviation
  FE02;VS3;abbreviation
-@@ -304,6 +303,7 @@
+@@ -306,6 +305,7 @@
  FE0D;VS14;abbreviation
  FE0E;VS15;abbreviation
  FE0F;VS16;abbreviation
diff --git a/debian/rules b/debian/rules
index 0f54a44..901fa2a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,6 @@ $(STAMP_DIR)/build-stamp:
 		tr -d \\r < $$f > tmpf  ; \
 		mv tmpf $$f ;			\
 		done )
-	sed -i s/expecially/especially/ $(SOURCE_DIR)/Unihan_Readings.txt
 	( cd $(SOURCE_DIR) && patch  < ../debian/namealias.patch )
 	bzip2 $(SOURCE_DIR)/NormalizationTest.txt
 	( cd $(SOURCE_DIR); for d in Unihan*.txt ; do \


signature.asc
Description: OpenPGP digital signature

Bug#832275: wine: FTBFS against gnutls 3.5

[Jens Reyer]

control: severity -1 serious
control: tags -1 + pending

On 23.07.2016 20:14, Andreas Metzler wrote:
> wine FTBFS against libgnutls28-dev 3.5.2-1 (avainable in experimental:
[...]
> This does not apply to wine-development 1.9.14-1, I guess 
> http://source.winehq.org/git/wine.git/commitdiff/bf5ac531a030bce9e798ab66bc53e84a65ca8fdb
>  fixed the issue.

Thanks for your report. You were right about the commit. Fix committed.
Since gnutls 3.5 is in the archive now I raise the severity.

Greets
jre

Bug#758291: Wine alternatives changes committed to git

[Jens Reyer]

control: tags -1 + pending

I just committed the changes to git stretch and master. wine needs to be
released before wine-development.

I'd be happy about any review. If I don't get any feedback and the
packages aren't in the archive, I'd push them there on August 8th or later.

Greets
jre

Bug#819255: wine-binfmt: doesn't register the binfmt on install/remove

[Jens Reyer]

This is documented in the README.debian, which also gives an explanation
why this doesn't happen automatically (I just added the last paragraph
with removal instructions in git master):

~
Automatically Launching Windows Executables
===
You can configure Wine to automatically launch Windows executables from
the command line, for example:
$ notepad.exe

To configure backend support for that, you'll need to install the
wine-binfmt package first and then execute:
$ sudo update-binfmts --import wine

This change increases the risk of inadvertently launching Windows
malware, so please make sure that you understand the security risks
before blindly setting this up.

To remove the support again execute:
$ sudo update-binfmts --package wine --remove wine /usr/bin/wine
~

However I'd like to discuss system integration more, to see if there is
room for improvement. We (I was the only participant from pkg-wine)
already did so a bit at DebConf, see gobby.debian.org / debconf16 / bof
/ wine (there's not much in that file).


Things to consider:

- Avoid inadvertently launching Windows malware.

- Avoid unexpected filetype associations (*.txt opened with wordpad).


Some data points (I need to investigate that more, or someone enlightens
us):

- Files need to be executable for binfmt support to work.

- binfmt support seems to have no effect in file managers, only
  in the terminal (I assume e.g. mail attachments aren't automatically
  opened either because of binfmt).

- The desktop file (currently not packaged) should be the equivalent in
  file managers, and probably e.g. in mail readers.
  We might ship it in doc/examples of the wine package.

- winemenubuilder (currently enabled)
  https://wiki.winehq.org/Winemenubuilder

https://wiki.winehq.org/FAQ#How_can_I_prevent_Wine_from_changing_the_filetype_associations_on_my_system_or_adding_unwanted_menu_entries.2Fdesktop_links.3F


For the security issue it was proposed at DebConf to implement something
like the (in-)famous Windows question "This application is from an
insecure place, do you really want to execute it?" the first time for
every application. However that would probably have to be implemented
upstream. In the Debian packaging something similar once was implemented.

We might also add a low priority debconf question (default false) to
setup the binfmt support.

Imo winemenubuilder has the biggest potential to annoy users with
unexpected things. However I also see its benefits. Not sure if we
should disable it per default.

Greets
jre

Bug#832041: wine32-tools: Missing dependency on g++-multilib

[Jens Reyer]

control: tags -1 + patch

Hi Javier,

thanks again for your report. I added g++(-multilib) to recommends (not
depends) in wine-development for now, see commit below. I will add it to
wine later.

Greets
jre


commit a9bbdc75ff9ebe9c35ad0ff872a8df58cd24abfb
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Thu Jul 28 15:41:16 2016 +0200

Add Recommends g++ or g++-multilib to the -tools.
Closes in wine: #832041
---
 debian/changelog  | 1 +
 debian/control.in | 4 
 2 files changed, 5 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index feb2ae0..536ffb2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 wine-development (1.9.15-2) UNRELEASED; urgency=medium
* Add removal instructions for binfmt support to README.debian.
+  * Add Recommends g++ or g++-multilib to the -tools (see: #832041).
   -- Jens Reyer <jre.wine...@gmail.com>  Thu, 28 Jul 2016 15:14:47 +0200
 diff --git a/debian/control.in b/debian/control.in
index 64522a5..c5db3f2 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -174,6 +174,8 @@ Depends:
  ${misc:Depends},
  ${shlibs:Depends},
  libwineVERSION-dev (= ${binary:Version}),
+Recommends:
+ g++ | g++-multilib:amd64 [i386],
 Conflicts:
  wine64VERSION-tools,
 Description: Windows API implementation - 32-bit developer tools
@@ -197,6 +199,8 @@ Depends:
  libwineVERSION-dev:i386 (= ${binary:Version}) [amd64] |
  libwineVERSION-dev:armel (= ${binary:Version}) [arm64] |
  libwineVERSION-dev:armhf (= ${binary:Version}) [arm64],
+Recommends:
+ g++,
 Conflicts:
  wine32VERSION-tools,
 Description: Windows API implementation - 64-bit developer tools

Bug#758291: Wine alternatives - last design decisions

[Jens Reyer]

Hi all!

Here's a proposal to implement the wine alternatives. (The manpage
update-alternatives(1) imo is the best reference for this.)

The Debian alternatives system uses one master and additional slaves. As
master I'd suggest "wine" (/usr/bin/wine). As slaves all other commands
in /usr/bin/ and their manpages.


The alternatives system would then be handled by the wine(-development)
binary package. Unfortunately some slaves are not in there, but in
wine64(-development) or wine{32,64}(-development)-tools.


If these packages are not installed, the corresponding slave alternative
links will simply not be installed. Per default update-alternatives will
display a warning then, but I'd suggest to use "--quiet" (Don't generate
any comments unless errors occur).

I added file triggers[1] on a file in each of these packages. These are
activated automatically by dpkg when a matching file is installed,
upgraded or removed as part of a package. The wine(-development) package
is then triggered to update the alternatives, so there won't be any
broken or wrong links.

[1] /usr/share/doc/dpkg-dev/triggers.txt.gz


If wine(-development) is not installed, the other packages still work,
but their commands are only available with suffix (-stable or -development).

wine64 already recommends wine. I propose to also let the -tools
recommend wine. I assume that nearly everybody who installs the -tools
also installs wine anyway. The packages wine, wine32 and wine64 together
have a installed size of only about 1 MB. However (once it's available
and recommended by wine) libwine-gecko has about 45MB. This is a
regression for users of the -tools packages, who don't want to install
wine(-development). But I think that's ok.

Alternatively we might add a new package wine-dummy that only ships the
alternatives system with a dummy script as master, and add "Depends:
wine|wine-dummy" to all slaves packages. I didn't try this yet, because
I'd like to avoid the extra package and the dummy script.

Or alternatively we could add a separate alternative system for the
-tools packages, with e.g. "winegcc" as master. But I assume that would
only help a very small minority of users.


In the attached patch there are 2 DEBUG lines and "--quiet" is not
specified, I'd change that before committing. I'd also rename
development/*.patch to debsuffix/*.patch, and drop winegcc.patch (see my
previous mail in this bugreport).

I will commit this to master and (slightly adjusted + the other relevant
changes) to stretch, in a few days for easier review.

Alternatively I might just commit to stretch for now, so that we could
first release wine, to have another round of testing.

Greets
jre
diff --git a/debian/NEWS b/debian/NEWS
index 31dcfde..8761c2d 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,17 @@
+wine-development (1.9.15-2) unstable; urgency=medium
+
+  Debian has two sets of Wine packages: wine and wine-development. They now use
+  the Debian alternatives system to provide /usr/bin/wine and other commands.
+  If both are installed this system defaults to use the commands provided by
+  wine, which also previously provided the command names without suffix.
+
+  But if configured, or if only "wine-development" is installed, you may now
+  use wine-development's commands without the "-development" suffix.
+
+  For more information on this please have a look at README.debian.
+
+ -- Jens Reyer <jre.wine...@gmail.com>  Sun, 24 Jul 2016 23:43:42 +0200
+
 wine-development (1.9.0-2) unstable; urgency=medium
 
   Wine now uses a shared 64-bit wineprefix per default if wine32 and wine64 (or
diff --git a/debian/README.debian b/debian/README.debian
index 044a2fd..b695045 100644
--- a/debian/README.debian
+++ b/debian/README.debian
@@ -26,9 +26,8 @@ Debugging information is limited to only error messages by default.  If you
 want other types of debugging output as well, you can set the WINEDEBUG
 environment variable.
 
-Examples:
+Example:
 $ WINEDEBUG=fixme+all wine
-$ WINEDEBUG=fixme+all wine-development
 
 If you want this to be more permanent, you can include an
 "export WINEDEBUG=fixme+all" line in your ~/.bashrc file.
@@ -50,15 +49,34 @@ debsnap fetches source packages by default, which you will then need to build
 (see debuild).  debsnap also lets you fetch the binary packages with the
 "-a " option and then specifying each of the binary packages.
 
+Alternative current versions
+
+You can choose between two sets of Wine packages: wine and wine-development.
+wine tracks the stable releases from winehq.org (e.g. version 1.8.3), and
+wine-development the development releases (e.g. version 1.7.15).
+
+wine and wine-development use the Debian alternatives system to provide
+/usr/bin/wine and other commands. If both packages are installed it defaults to
+use the commands provided by wine. You may change this by ru

Bug#832129: [wine-development]: RegEdit fails to export whole registry

[Jens Reyer]

On 24.07.2016 13:26, Joerg Schiermeier wrote:
> On Sunday, July 24, 2016 at 03:48:46 CEST Jens Reyer wrote:
>> Did you get the desired result with any Wine version? Which exactly?
> The regression tests bisection was done with wine v1.9.0 as lowest
> version and v1.9.7 as the highest version see report [2].
> 
> The last version when it fails is the version v1.9.15.

Did any version work in the past or in your regression tests (did you
have any "git bisect good" commits, in particular what was the last good
commit)?
Did you try wine (1.8)?
Did you try to compile from winehq source?


> After your findings I still suspect the upstream from WinHQ as faulty.

So https://bugs.winehq.org/show_bug.cgi?id=40411 should be reopened and
set as forwarded here.

Greets
jre

Bug#832129: [wine-development]: RegEdit fails to export whole registry

[Jens Reyer]

Hi

Looks like the same here. However I also get the same with the winehq
wine-devel package.

Did you get the desired result with any Wine version? Which exactly?

Greets
jre

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#827908: unicode-data: New upstream release (9.0.0)

[Jens Reyer]

Source: unicode-data
Version: 8.0-3
Severity: wishlist
Control: affects -1 src:wine-development

Hi,

please update unicode-data to Unicode 9.0.0:

http://www.unicode.org/versions/Unicode9.0.0/

Upcoming versions of Wine (src:wine-development) will use it.

Greets
jre

Bug#827770: wine-development: FTBFS in Ubuntu

[Jens Reyer]

On 20.06.2016 20:48, Graham Inggs wrote:
> Since version 1.9.9-1, wine-development has FTBFS on all architectures
> in Ubuntu.
> I see the following in the build log:
> 
> ./debian/scripts/sonames2elf libfontconfig.so.1 libfreetype.so.6
> libncurses.so.5 > debian/tmp/elf.depends
> ./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3
> libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30
> libgsm.so.1 libjpeg.so.8 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 > debian/tmp/elf.recommends
> /usr/bin/ld: cannot find libGL.so.1
> collect2: error: ld returned 1 exit status
> debian/rules:153: recipe for target 'override_dh_shlibdeps' failed
> 
> Assuming this had something to do with packaging differences between
> Debian and Ubuntu's mesa package, I made the following changes:

Contrary to Debian, in Ubuntu libGL.so.1 is in /usr/lib//mesa/, so
it is not found automatically. See:

http://packages.ubuntu.com/search?searchon=contents=libGL.so.1=exactfilename=yakkety=any

Try adding it to rpath (change existing line in d/rules):
export DEB_LDFLAGS_MAINT_APPEND+=-Wl,-rpath,/$(LIBDIR),/usr/lib/$(shell
dpkg-architecture -qDEB_HOST_MULTIARCH)/mesa

Question at all: If this works, should we add this to the Debian
packaging (conditionally for ubuntu)? Is there a best practice syntax
for that?


> With the above changes in place, the builds succeeded on amd64, arm64
> and i386, but failed on armhf with a new error:
[...]
> dpkg-shlibdeps: error: couldn't find library libXxf86vm.so.1 needed by
> debian/tmp/elf.recommends (ELF format: 'elf32-littlearm-sfabi'; RPATH:
> '')
[...]
> To help dpkg-shlibdeps find private libraries, you might need to use -l.
> make[1]: *** [override_dh_shlibdeps] Error 2

I checked a few of the so files on armhf/yakkety: they are in
/usr/lib/arm-linux-gnueabihf and the build dependencies make sure that
they are installed. Sounds fine.

Anyway, try specifying the path explicitly for dpkg-shlibdeps (add the
last line, since this is arch neutral it shouldn't hurt on the working
arches):

dpkg-shlibdeps --warnings=1 \
-pdlopen \
-dDepends -edebian/tmp/elf.depends \
-dRecommends -edebian/tmp/elf.recommends \
-Tdebian/libwine$(VERSION).substvars \
-l/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

If this works, then I'd ask Ubuntu's dpkg maintainer about it. This
Ubuntu dpkg change sounds related:
- Special-case arm{el,hf} ELF objects in Shlibs/Objdump.pm for multilib.

Greets
jre

Bug#816020: /usr/bin/wineserver disables persistence delay

[Jens Reyer]

control: forwarded -1 http://bugs.winehq.org/show_bug.cgi?id=36040
control: tags -1 + wontfix


Sorry for the late reply.

On 26.02.2016 19:08, Jakub Wilk wrote:
> /usr/bin/wineserver passes -p0 to wineserver32. This seems to be an
> undocumented deviation from upstream behavior. The manpage says: "the
> default value is 3 seconds".

I'll patch the manpage.

> Please revert to the upstream behavior.

This was added on purpose, see #745346 and
http://bugs.winehq.org/show_bug.cgi?id=36040 (Please support an
environment variable to disable the lingering wineserver).

I assume wineserver persistence will stay disabled at least until such
an environment variable is available, therefore tagging as wontfix.

Not sure which default to use than, personally I've no opinion on this.

As workaround to get wineserver persistence you could set
 WINESERVER=/usr/lib/wine/wineserver32

Unfortunately this seems to be broken upstream as long as
/usr/lib/wine/wineserver exists (reported at
https://bugs.winehq.org/show_bug.cgi?id=40811). So currently you have to
edit or remove that file to get persistence.

Greets
jre

Bug#758291: Final preparations for Wine alternatives - design decisions

[Jens Reyer]

Hi Mike and others who are interested

I'm working on the alternatives system (replace /usr/bin/wine, other
files in /usr/bin and the manpages with links pointing to either the
files from src:wine (default if both are installed) or
src:wine-development).

I've prepared the final changes which still can be tested in
wine-development. There are some design decisions to be taken, maybe you
have some other preferences here (technically they all work). For now I
pushed my proposed changes to my github repository:
  https://github.com/jre-wine/wine.git -b jre/debsuffix

The files from src:wine need to be renamed to free the namespace for the
links. I propose a suffix *-stable*. The directories and packagenames
don't need to be changed.

In the packaging we currently have VERSION which is either empty or
"-development". For the proposed suffix I'd suggest an additional
*DEBSUFFIX* (being either "-stable" or "-development").
Alternative name ideas:
DEB_SUFFIX
SUFFIX
While at it, we might also rename my recently introduced VENDOR (e.g.
DEBVENDORVERSION).

Currently the scripts wine, wineapploader and wineserver detect the
correct paths/names (wine or wine-development) during runtime. This
would need to be adapted e.g. with "readlink".
But instead I propose to just set this at build time (with BINDIR,
DEBSUFFIX and VERSION). Then the installed files and their sources are
easily readable.
As drawback you obviously can't use the script from the packaging
directly, and the packaging itself would be a littlebit more
complicated. But imo it's a net gain (we already do so for the winegcc
script). The sources for these scripts should be renamed to
*.in and have the executable bit removed.

The patches in d/p/development/ need to be adapted, too. Instead of
simply replacing "development" with "stable" I'd propose to use the
generic DEBSUFFIX. (Currently there is no name collision in the
upstream source, but we should bear that in mind when choosing a
variable name). I implemented this similarly to
https://github.com/wine-compholio/wine-staging/tree/master/patches/winemenubuilder-Desktop_Icon_Path.
Review of these patches would be welcome (I tested them successfully,
but I'm not a coder so I might have missed something). You'll find it
at:
https://github.com/jre-wine/wine/blob/jre/debsuffix/debian/patches/debsuffix/winemenubuilder.patch

However I suggest to drop winegcc.patch: It applies to a script template
which afaics is only used for a wrapper *.exe to start the compiled
output *.exe.so with Wine. So it is relevant when actually running the
compiled output.
Of course there might be cases where it is necessary to run the exe with
the same Wine that was also used to compile it. But I assume this isn't
the case most times.
Dropping the patch instead would allow for running the exe on other
machines without requiring the specific wine-stable or wine-development
binary names. And it would be one patch less.

Proposed roadmap:
- Release wine 1.8.3-1 (with the changes I've pushed to git today,
  needs a sponsor).
- Release wine-development 1.9.13 (next week) with these or similar
  changes.
- Implement alternatives system in wine (1.8.3-2) once both above
  are in testing. Details later.

Greets
jre

Bug#827207: winetricks: Please add dependency on binutils (/usr/bin/ar)

[Jens Reyer]

Package: winetricks
Version: 0.0+20160425-1
Severity: normal
Tags: patch

Hi Joseph,

[ Not sure if you are following the upstream tracker, therefore
  forwarding. ]

please add a dependency on "binutils". winetricks needs it to unpack deb
packages, see https://github.com/Winetricks/winetricks/issues/652.

btw, I noticed there's still a "Suggests: libwine". Originally this was
added in order to be able to restart the wineserver. But the wineserver
wrapper is in wine(-development), and the wineserver binaries are in
packages depended upon by wine(-development). Besides that, libwine
would be taken from the host arch (e.g. amd64), while often the 32-bit
packages are the relevant ones.

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.5.0-2-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 winetricks depends on:
ii  cabextract1.6-1
ii  p7zip 15.14.1+dfsg-2
ii  unzip 6.0-20
ii  wget  1.17.1-2
ii  wine  1.8.2-1
ii  wine-development  1.9.12-1
ii  zip   3.0-11

Versions of packages winetricks recommends:
ii  gksu   2.0.2-9
ii  sudo   1.8.15-1.1
ii  xdg-utils  1.1.1-1
ii  zenity 3.20.0-1

Versions of packages winetricks suggests:
ii  aria21.21.0-1
ii  libwine  1.8.2-1
ii  tor  0.2.7.6-1

-- no debconf information
diff --git a/debian/control b/debian/control
index c448047..9989b80 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Package: winetricks
 Architecture: all
 Multi-Arch: foreign
 Depends:
+ binutils,
  cabextract,
  p7zip,
  unzip,
@@ -29,7 +30,6 @@ Recommends:
  zenity | kdebase-bin
 Suggests:
  aria2,
- libwine,
  tor
 Description: package manager for WINE to install software easily
  A POSIX shell script 'package manager' for WINE to install some

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Jens Reyer]

control: tags -1 + pending
control: tags 823264 + patch

I committed several changes on git branch master to either install
wine32-tools, or 32-bit libwine-dev with wine64-tools, and document how
to get 32-bit results.

They should be in the next "wine-development" release, and if they work
out well I'll apply them for "wine".


On 05/30/2016 10:21 PM, Javier Serrano Polo wrote:
> El dl 30 de 05 de 2016 a les 01:27 +0200, Jens Reyer va escriure: 
>> ${perl:Depends} | perl:any [i386],
> 
> This might break in the future if ${perl:Depends} is substituted with
> "perl, foobar".

I considered this issue, but according to the manpage it resolves to
only one value (perl or perlapi), see below.

Greets
jre

--
commit 2e52d32383b040ff7118e46b441410d64f184655
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Jun 5 19:13:52 2016 +0200

Document generating 32-bit results with the -tools packages.

See: #824673
Thanks: Andrey Gursky and Javier Serrano Polo

commit 4b5983772f8ecc8bf93c5da27f39e6d138ca4ab5
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Jun 5 16:21:58 2016 +0200

Let libwine-dev prefer wine64-tools to wine32-tools.

Otherwise, if libwine-dev is installed from a 32-bit and a 64-bit
arch, the recommends may be resolved to wine32-tools and
wine64-tools (which conflict with each other).

This also prevents issues on arm64 with 32-bit libwine-dev
installed while wine32-tools is not installable because of its
dependencies there.

commit 5854b7a988c4c4da97a5fec59058027a24544dfd
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Jun 5 16:29:31 2016 +0200

Make wineNN-tools multi-arch installable.

Closes: #824673
Closes: #823264 (stable)
Thanks: Javier Serrano Polo

Add alternative dependencies to wine32-tools (i386 only) and make
it M-A:foreign, so amd64 packages can depend on it.

Note: perl:Depends resolves to only one value (perl or perlapi),
so there's currently no risk of a malformed expression. A general
fix has been requested in #824696 (debhelper: dh_perl should
report perl:any when usage is architecture independent).

Also make wine64-tools M-A:foreign, so 32-bit libwine-dev can
depend on it.

commit 2cce63ce6118bac660d7229ee8d9163d70280bbd
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Jun 5 16:04:26 2016 +0200

Add alternative dependency on 32-bit libwine-dev to wine64-tools.

Note: Depending e.g. on libwineVERSION-dev:any doesn't work
because that resolves for the host arch only.

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Jens Reyer]

I'll change the dependencies once I've verified if pkg:i386
or pkg:amd64 are legit notations.


Package: wine32VERSION-tools
Depends:
 gcc | gcc-multilib:amd64 [i386],
 ${perl:Depends} | perl:any [i386],

Package: wine64VERSION-tools
 Depends:
 libwineVERSION-dev (= ${binary:Version}) | libwineVERSION-dev:i386 (>= 
${source:Version}) [amd64],


I'd add to README.Debian something like:

Tools (winegcc, ...) and 32-/64 bit
===
For 32-bit output from the wine64-tools (or wine64-development-tools) on amd64
install libwine-dev:i386 (or libwine-development-dev:i386).
Than use "-m32" (for winemaker --wine32). For winegcc specify additionally
"-L/usr/lib/i386-linux-gnu/wine".

Any review is welcome!

Greets
jre

Bug#825395: winetricks: Remove wine versioned dependence to prevent conflicts with alternative wine

[Jens Reyer]

Hi,

I had suggested that change to make sure that the installed wine package
works flawlessly in any respect with winetricks. First off, this isn't
fail-proof either, because this is a "or" dpendency (e.g. you might
install a recent wine-development next to an ancient and problematic
wine package).

However imo none of the issues in older Debian wine(-development)
packages were critical, and there are known workarounds for them.
Basically we would need an unversioned "Depends" on wine(-development),
and a versioned "Recommends".

Given this, and  that the version constraints are met anyway in Debian
stretch/sid, it wouldn't do us harm to remove them again. Sorry for the
short-sighted advice, Joseph.

As benefit of removing the constraints again, users might e.g. install
winetricks on jessie (if we'd go for offical jessie-backports we might
restore some of the just dropped documentation in there).

Greets
jre

Bug#824671: missing widl

[Jens Reyer]

control: tags -1 + pending

commit 8958b3d2432ec1d3212125617b9b3e66eb39a85d
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Thu May 19 14:53:42 2016 +0200

Add widl to the -tools packages.

Closes: #824671
Thanks: Andrey Gursky

Bug#824715: wine32-tools: wineg++ does not link with stdc++

[Jens Reyer]

Pushed to master:

commit faae7dac32d2816937ed5e8a24e5a6343320092c
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Thu May 19 15:05:32 2016 +0200

Fix winegcc script to call wineg++/cpp based on its basename.

Closes in stable: #824715
Thanks: Javier Serrano Polo

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Jens Reyer]

On 05/19/2016 01:21 AM, Javier Serrano Polo wrote:
> winegcc from wine64-tools produces a 32-bit object if "-m32" is
> specified, as expected.

So for winegcc there is no reason to install wine32-tools on amd64?
What about the other tools in that package? Obviously it would simplify
matters a lot if we didn't have to care about different -tools packages.


> wine64-tools needs to be installed manually to
> avoid the 64-bit libwine-dev.

So you have wine64-tools with libwine-dev:i386 installed, but no
libwine-dev:amd64?

And you're sure that this is necessary and works? Strange:

libwine-dev's *.h and *.idl files in /usr/include/wine/ are arch
independent, only the *.def files in /usr/lib//wine/ are arch
specific.
So for the former it doesn't matter which package is installed, and for
the latter I don't see how the 64-bit winegcc is able to find the 32-bit
files.

Greets
jre

Bug#824715: wine32-tools: wineg++ does not link with stdc++

[Jens Reyer]

control: tags -1 + patch

Right, a broken /usr/bin/wineg++ is probably not better than no
/usr/bin/wineg++ at all. So let's fix that...
Thanks for testing the tools, since I personally don't use them at all.

The following as /usr/bin/winegcc should work:


#!/bin/sh -e

name=$(basename $0 | cut -d- -f1)

# wineg++ fails to find winebuild in Wine's bindir
# See https://bugs.winehq.org/show_bug.cgi?id=40245
if test -z "$WINEBUILD"; then
export WINEBUILD="/BINDIR/winebuild"
fi

exec /usr/lib/wine/$name $@


I'll commit the fix for wine-development) soon. Given it turns out well
I'll apply it to the wine packaging a bit later.

Greets
jre

Bug#823264: Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Jens Reyer]

control: block 823264 by 824673

Hi,

[ This has already been requested/asked in #823264 (reported against
wine). Added to CC now, but please send answers only to #824673.
Blocking that bug by this one here, because we usually fix stuff in
wine-development first. ]

I wonder if it's really necessary to use wine32-tools at all. Or is
winegcc from wine64-tools, with gcc-multilib installed, producing the
same results if "-m32" is specified?

If we indeed need wine32-tools:

For the dependeny on gcc the following had been suggested:

 gcc | gcc-multilib:amd64 [i386]

I successfully tested this here, but I'm not sure if specifying a
specific package arch this way (":amd64") is allowed. Further
gcc-multilib has no Multi-Arch field, while I'd expect "m-a:foreign" or
at least "allowed" for this to work. I'll ask the multi-arch folks about
that soon.

Is it really necessary to explicitly specify "-m32" for compiling 32-bit
apps on amd64 with wine32(-development)-tools?
If yes, I wonder if this should be mentioned either in the README, or
added with some logic to the winegcc wrapper script.

We also discussed a possible multi-arch dependency on perl in #823264. I
just noticed in dh_perl(1) that ${perl:Depends} gets resolved to perl
*or* perlapi, while no other alternative value is mentioned there. So we
may use:

 ${perl:Depends} | perl:any [i386]

We may even use "perl:any" only, but I'd like to keep the variable in
order to notice if anything changes there. Some way for dh_perl to
handle this would be preferable.
Or we depend on perl:any and recommend ${perl:Depends}.

However I'd like to first know for what exactly perl is needed, and if
perl:any would work for wine, or if native (i386) perl is needed for at
least some things. Anyone?


Greets
jre

Bug#824671: missing widl

[Jens Reyer]

Hi Andrey

On 05/18/2016 05:34 PM, Andrey Gursky wrote:
> I noticed that wine{32,64}-development-tools packages do not contain
> the widl tool anymore [1]. It is still there in Jessie [2] and in
> wine-staging.

Thanks, you're right. I'm not familiar with widl. I take it this should
be available in /usr/bin, or is it only called indirectly (then I'd only
add it in /usr/lib/wine-development/).

Greets
jre

Bug#783875: network-manager-strongswan interface is useless

[Jens Reyer]

On 05/14/2016 02:42 PM, Prometheus wrote:
> Screenshots taken inside Gnome 3.20, Debian unstable,
> 
> Package: network-manager-strongswan
> Version: 1.3.1-1
> 
> Even if i fill in the text boxes i cannot get the option to Add the
> connection.

I guess you sent the message to the wrong bugreport. Maybe #799200, as
seen in your pictures, was intended.

Bug#823991: Fix committed on other branch for Bug#823991: libpng16-16: generates a ton of noisy warnings

[Jens Reyer]

control: tags -1 + patch

I committed the proposed patch in branch master, so it should be in
wine-development 1.9.9-1.
If this works out well, I will backport it for the next wine release.


commit 3afa4648542268844a23eb17940051452dbb9f43
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Fri May 13 16:07:53 2016 +0200

Add missing runtime dependencies to libwine recommends.

Closes in stable: #823991.

Bug#783428: Fix committed (was: Could not load wine-gecko. HTML rendering will be disabled.)

[Jens Reyer]

control: tags -1 + pending

Just pushed to master, so it should be in wine-development 1.9.9-1.

Note that libwine-gecko-2.44 is not packaged yet, see #824193.


commit 16fe62676bdd08879e953f4ffaa2328d8d9621fc
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Thu May 12 19:28:30 2016 +0200

Fix local search for addon (gecko/mono) installers.

Closes: #783428
Closes in wine (stable): #812750

Only disable the download of external addon installers, but
look for them locally again.

Adjust these search paths:
- directory stored in registry (unchanged)
- /usr/share/wine-
- $INSTALL_DATADIR//
- /usr/share/wine//
- $XDG_CACHE_HOME/wine/(unchanged)
- $HOME/.cache/wine(unchanged)

Update documentation.

You may verify the search paths with WINEDEBUG="trace+appwizcpl".

Bug#812750: Fix committed on other branch (was: wine: Gecko integration is broken)

[Jens Reyer]

control: tags -1 + patch

Just pushed a fix to master, so it should be in wine-development
1.9.9-1. If this works out well, I will backport it for the next wine
release.

Note that libwine-gecko-2.40 is not packaged yet, see #824192.


commit 16fe62676bdd08879e953f4ffaa2328d8d9621fc
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Thu May 12 19:28:30 2016 +0200

Fix local search for addon (gecko/mono) installers.

Closes: #783428
Closes in wine (stable): #812750

Only disable the download of external addon installers, but
look for them locally again.

Adjust these search paths:
- directory stored in registry (unchanged)
- /usr/share/wine-
- $INSTALL_DATADIR//
- /usr/share/wine//
- $XDG_CACHE_HOME/wine/(unchanged)
- $HOME/.cache/wine(unchanged)

Update documentation.

You may verify the search paths with WINEDEBUG="trace+appwizcpl".

Bug#824193: WineGecko 2.44 needs packaging for wine-development 1.9.3 and later

[Jens Reyer]

Package: src:wine-gecko-2.24
Version: 2.24+dfsg-1
Severity: wishlist
Control: affects -1 src:wine-development

wine-development 1.9.3 and later needs packaging of Wine Gecko 2.44.

See: https://wiki.winehq.org/Gecko

Bug#824192: WineGecko 2.40 needs packaging for Wine 1.8

[Jens Reyer]

Package: src:wine-gecko-2.24
Version: 2.24+dfsg-1
Severity: wishlist
Affects: -1 wine

The current stable wine 1.8 needs packaging of Wine Gecko 2.40.

See: https://wiki.winehq.org/Gecko

Bug#823991: libpng16-16: generates a ton of noisy warnings

[Jens Reyer]

On 05/11/2016 05:34 PM, Austin English wrote:
> On Wed, May 11, 2016 at 3:47 AM, Tobias Frost  wrote:
>> can you provide more information, like the package version of your installed
>> wine?  Did you mix stable and other suites? What are the libpng pacakges you
>> have installed?
>>
>> (We have binNMUed everything depending on libpng12 so it is strange that your
>> wine thinks it is compiled against libpng12)
>>
>> libpng has this version warning for a reason, as until version 1.4 it was 
>> possible to
>> directly access struct members, therefore if those structs changed this 
>> *could*
>> cause incompatiblities. The newer API forbids that, so this should be safe.
>>
>> However, taking a (very) short glimpse at the wine packages: Maybe I missed 
>> it
>> but it seems from there that they do not declare a Depends on the libpng
>> library package.
>> That could be an explanation why it has not been binNMUed, and this would be
>> actually a bug in wine (policy 3.5)
>>
>> CC'ing wine maintainers, maybe they can tell ...
[...]
> I didn't check Debian package, but upstream definitely uses libpng.
> From configure.ac:
> dnl  Check for libpng 
> if test "x$with_png" != "xno"
> then
> WINE_PACKAGE_FLAGS(PNG,[libpng],,[$X_CFLAGS],[$X_LIBS],
> [AC_CHECK_HEADERS([png.h])
> if test "$ac_cv_header_png_h" = "yes"
> then
> WINE_CHECK_SONAME(png,png_create_read_struct,
> [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include
> ]],[[typeof(png_set_expand_gray_1_2_4_to_8) *p]])],
> 
> [AC_DEFINE(HAVE_PNG_SET_EXPAND_GRAY_1_2_4_TO_8,1,[Define to 1 if
> libpng has the png_set_expand_gray_1_2_4_to_8 function.])])],
> [PNG_CFLAGS=""],[$PNG_LIBS -lm -lz],[[libpng[[0-9]]*]])
> else
> PNG_CFLAGS=""
> fi])
> fi
> WINE_WARNING_WITH(png,[test "x$ac_cv_lib_soname_png" = "x"],
>  [libpng ${notice_platform}development files not
> found, PNG won't be supported.])
> 
> https://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac#l1590

Thanks for the binNMU request, Tobi!

The Debian packages build-depend on libpng-dev, but indeed currently
there's no runtime dependency in the binary packages (it was there in
wine once, but was lost when the wine-development packaging was merged).

I checked all build-dependencies: many already have matching runtime
dependencies, mostly added by ${shlibs:Depends}.

For the rest (including libpng) I'd suggest to add the following runtime
dependencies as Recommends in libwine.

*Feedback, or better solutions, very welcome!*

* I'd prefer to do this automatically, but am not aware of any
  solution.
  E.g. adding ${shlibs:Depends} and ${so:Depends} to every binary
  package doesn't help at all.
  And debian/scripts/dpkg-depgrep, which is already used to create
  ${dlopen:Depends} with the correct package names of ncurses and
  freetype, doesn't work for all packages (the numbers don't always
  match, see below).

* Only "Recommends", because I'm not sure if they are really needed.
  I've only seen this topic for png/jpeg/tiff before. Not sure if just
  nobody noticed any problem before for the other libraries, or if the
  64-bit libraries work for wine32, too. At least there should be many
  use cases that work without them.

* "libwine" is installed always and on every arch, so it is easiest to
  maintain this awful list there.

Missing/Proposed dependencies:
  libxi-dev,  libxi6
  libxt-dev,  libxt6
  libxmu-dev, libxmu6
  libxrandr-dev,  libxrandr2
  libxrender-dev, libxrender1
  libxkbfile-dev, libxkbfile1
  libxxf86vm-dev, libxxf86vm1
  libxxf86dga-dev,libxxf86dga1
  libxinerama-dev,libxinerama1
  libxcomposite-dev,  libxcomposite1
  libpng-dev, libpng16-16
  libssl-dev, libssl1.0.2
  libgsm1-dev,libgsm1
  libjpeg-dev,libjpeg62-turbo
  libtiff-dev,libtiff5
  libxslt1-dev,   libxslt1.1
  unixodbc-dev,   libodbc1
  libcups2-dev,   libcups2
  libdbus-1-dev,  libdbus-1-3
  freeglut3-dev,  freeglut3
  libosmesa6-dev, libosmesa6
  libgnutls28-dev,libgnutls30
  libgettextpo-dev,   libgettextpo0

To check the result I first purged all wine and i386 packages on my
amd64 system and then installed the current wine-development. A upgrade
to my proposed version additionally installs the following packages:
  freeglut3:i386
  libavahi-client3:i386
  libavahi-common-data:i386
  libavahi-common3:i386
  libcomerr2:i386
  libcups2:i386
  libgettextpo0:i386
  libgssapi-krb5-2:i386
  libjbig0:i386
  libjpeg62-turbo:i386
  libk5crypto3:i386
  libkeyutils1:i386
  libkrb5-3:i386
  libkrb5support0:i386
  libltdl7:i386
  libodbc1:i386
  libosmesa6:i386
  libtiff5:i386
  libunistring0:i386
  libxcomposite1:i386
  libxinerama1:i386
  libxkbfile1:i386
  libxmu6:i386
  libxrandr2:i386
  libxslt1.1:i386
  libxt6:i386
  libxxf86dga1:i386
Note: only i386 packages were installed, seems 

Bug#798780: release.debian.org: Please let playonlinux migrate to testing

[Jens Reyer]

On 05/08/2016 06:16 PM, Bertrand Marc wrote:
> Le 10/04/2016 13:52, Andreas Beckmann a écrit :
>> On Sun, 21 Feb 2016 11:00:14 +0100 Bertrand Marc 
>> wrote:
>>> Do you think we could find a solution to restore the dependency and let
>>> playonlinux migrate to testing ?
>>
>> What about
>>
>> * split a playonlinux-data package from playonlinux containing
>>   /usr/share/playonlinux/*
>>   /usr/share/locale/*
>>   mark as Multi-Arch: foreign
>>   document in the description that a foreign architecture may be needed
>>   to install playonlinux on amd64 (dpkg --add-architecture i386)
>>
>> * make playonlinux arch:any
>>   Depends: playonlinux-data (= ${source:Version})
>>
>> * add Build-Depends: wine32 | wine32-development
>>   (instead of enumerating the architectures in the playonlinux package)

I assume both packages are part of src:playonlinux, and playonlinux-data
is arch:all?
But why "Multi-Arch: foreign" for playonlinux-data then?

Otherwise (playonlinux-data arch:any, and src:playonlinux build-depends
on wine32) no playonlinux* package at all would be on e.g. amd64. So
users would see no playonlinux* package, and thus they wouldn't see the
documentation to install the foreign arch.

But even if playonlinux-data is available on amd64, I doubt that the
documentation in the long package description is enough. Remember that
POL is intended to give a quick and easy start. A part of its target
audience might not even know that long package descriptions exist.

So this solution makes sure that POL works *once* it's been installed.
But it doesn't help greatly to install it.


Alternatively you could make something similar to what we have in the
wine packaging.

There wine (arch:all) depends on wine32|wine64 (which are arch specific,
and only available on archs with the correct 32-/64 bitness).
Installations without wine32 are considered broken generally, but there
are some use cases that work without wine32. I think the same is true
for POL: you generally want wine32, but you don't need it in *every* case.

So:

* Keep a dependency from playonlinux on "wine|wine-development".
  Nowadays these packages provide the /usr/bin/wine(-development)
  and /usr/bin/wineserver(-development) wrappers/links, it's not an
  empty package as stated elsewhere.

* Make playonlinux (arch:all) *recommend* wine32|wine32-development.
  This /should/ solve the release migration issue.

* Change /usr/bin/playonlinux to be a wrapper script that checks
  if wine32 is installed (test if the executables /usr/lib/wine/wine
  or /usr/lib/wine-development/wine exist).
  If yes, execute the real playonlinux.
  If no, give the user instructions how to install wine32. If you
  think wine32 is needed in any case, you'd have to abort now.
  Otherwise just continue after displaying the warning.
  Wine shows the warning only in the terminal. I think POL would
  have to use something like zenity (we had that in Wine once, but
  it was removed for reasons unknown to me).

* Additionally you might add the same test/warning to the postinst
  as suggested in https://bugs.debian.org/783875#44.

* Also additionally you might add the instructions to install wine32
  from i386 in the description (as Andreas suggested). I don't know
  why we don't have that in Wine.

You  probably need some versioning for the wine dependencies. I can help
with them (and the other changes) if you want to pick this route.

For reference the /usr/bin/wine(-development) wrapper script:
http://anonscm.debian.org/cgit/pkg-wine/wine.git/tree/debian/scripts/wine

Greets
jre

Bug#823264: wine32-tools: Allow installation on amd64 with 64-bit tools

[Jens Reyer]

control: retitle -1 wine32-tools: Allow installation on amd64

On 05/02/2016 08:56 PM, Javier Serrano Polo wrote:
> Package: wine32-tools
> Version: 1.8.1-2
> Severity: wishlist
> 
> This is somewhat related to https://bugs.debian.org/807926 .
> wine32-tools works with gcc-multilib and perl from amd64. Adding this
> type of dependency should work:
> 
> Depends: gcc | gcc-multilib:amd64 [amd64], perl | perl:amd64
> [amd64]

Thanks for the hint! Unfortunately there are some issues:

1.)
"[amd64]" seems to be related to the build host. Since wine32-tools is
built on i386 the expression simply is omitted.
Solution: simply omit.


2.)
*Theoretically* speaking: gcc-multilib is not multi-arch'ed [1]. For
"gcc-multilib:amd64" it would need to be "allowed", for omitting the
arch and just installing it from the host arch it would need to be
"foreign".

Quoting https://wiki.ubuntu.com/MultiarchSpec:
  Multi-Arch: no
  The package is not co-installable and it must not be used to satisfy
  the dependency of any package of another architecture than its own.

Other packages of the same source package have multi-arch fields, so I
assume there is a reason that this has none. But I have no real
knowledge about gcc in general and gcc-multilib in particular.

*In practice* it seems to work. Not sure if I'm wrong, or the tools
(tested with aptitude) permit things that they shouldn't.

[1]: See
https://tracker.debian.org/media/packages/g/gcc-defaults/control-1.161


3.)
The dependency on perl originates from "${perl:Depends}". If we just
added "| perl:amd64" this would break if the variable gets expanded to
several values. Just using "perl|perl:amd64" might be ok, but omitting
the variable sounds wrong to me.
At least perl is "Multi-Arch: allowed", so your suggestion works otherwise.


4.)
Finally, even if we got this working, co-installability of wine32-tools
and wine64-tools is not possible atm. They need to conflict with each
other, because they use the same binary names in /usr/lib/wine/. We had
wrappers in the past for winegcc32 and winegcc64 for co-installability,
but I'd like to avoid the mess of doing this again, especially since the
packaging changed since then, and we'd have to do this for every
executable in the -tools packages. Therefore retitling this bug to
reflect the part that needs to be solved first (not sure anyway what you
exactly meant with "64-bit tools").

Final sidenote: there's no gcc-multilib for arm64 (the other 64-bit
architecture with Wine).


Below patch applies to the wine32VERSION-tools section of d/control.in.
With this I could install wine32-development-tools on amd64. If we
replaced "${perl:Depends}" with "perl" we might try it (but again, see
point 2 and 3). Opinions?

diff --git a/debian/control.in b/debian/control.in
index c2b8296..03f81fb 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -171,8 +171,8 @@ Architecture: any-i386 any-powerpc armel armhf
 Section: libdevel
 Built-Using: ${built:Using}
 Depends:
- gcc,
- ${perl:Depends},
+ gcc | gcc-multilib:amd64,
+ ${perl:Depends} | perl:amd64,
  ${misc:Depends},
  ${shlibs:Depends},
  libwineVERSION-dev (= ${binary:Version}),


Greets
jre

Bug#818925: Wine's forked version of fontforge

[Jens Reyer]

[CC to Huw Davies because I have a question about one of his changes]

On 04/22/2016 12:54 PM, Alexandre Julliard wrote:
> Jens Reyer <jre.wine...@gmail.com> writes:
> 
>> Wine and Debian are both using the quite old fontforge version
>> 20120731-b, the patches apply cleanly in Debian.
>> But upstream is actively developing and in Debian someone is working on
>> packaging a recent version (not sure with what outcome, e.g. afaik there
>> is at least one upstream regression blocking an update).
>> Are there any plans in Wine to update to a newer version?
> 
> No plans currently, but I can certainly look into it if it helps.

Thanks. First off, I successfully tested the current fontforge 
20160404. I built Wine and the .ttf files with it, and verified in one 
app that relies on them that they are working. So no immediate need to
update, but it might be a good idea generally.

After looking into your patches and explanation my understanding is
that we may regenerate the .ttf files in Debian without having to 
worry about the results. However for contributing to Wine the current 
Debian fontforge is not suitable. So I started trying to get your 
changes applied upstream:

>> 1. Various hacks to avoid putting timestamps in generated files (AJ).

Created issue https://github.com/fontforge/fontforge/issues/2711
The timestamps are also a hindrance for reproducible builds, and need 
to be tackled somehow in fontforge anyway.


>> 2. - Avoid outputting trailing spaces in sfd files (AJ).

Created pull request https://github.com/fontforge/fontforge/pull/2713
for hopefully all remaining changes.


>> 3. Enable the width of individual bitmap strikes to be altered (Huw Davies).
>>
>> Since the import of upstream version 20120731-b this patch only has a
>> third of its original size. Are the remaining Wine changes still
>> necessary, or are they cruft? If still needed, I guess they should be
>> pushed upstream.
>>
>> In 20160404 not much seems to have changed, but the containing file
>> bitmapview.c was moved ("splitting ui code from fontforge/ to
>> fontforgeexe/").
>>
>> Same as above: is this only needed when creating fonts? Looks like a
>> candidate for upstream.
> 
> I believe it's still needed, I'm not sure why that part didn't get
> upstream.

See below for the remaining changes. I didn't bring that to upstream, 
because I don't know how to test this. Instructions, or a review of 
the patch and whether its still needed in 20160404, would be welcome.
Alternatively, if you update to a newer fontforge I'd filter out the
remaining diff and just go with that.


>> 4. Don't save the selected state. (Huw Davies)

Created issue https://github.com/fontforge/fontforge/issues/2715 for
this and other local information saved in sfds.

Greets
jre

---
 fontforgeexe/bitmapview.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/fontforgeexe/bitmapview.c b/fontforgeexe/bitmapview.c
index 7cee735..749123d 100644
--- a/fontforgeexe/bitmapview.c
+++ b/fontforgeexe/bitmapview.c
@@ -1758,8 +1758,6 @@ static void BVMenuSetWidth(GWindow gw,struct gmenuitem 
*mi,GEvent *g) {
 SplineChar *sc;
 int val;
 
-if ( !bv->bdf->sf->onlybitmaps )
-return;
 if ( mi->mid==MID_SetWidth ) {
sprintf( buffer,"%d",bv->bc->width);
ret = gwwv_ask_string(_("Set Width..."),buffer,_("Set Width..."));
@@ -1778,6 +1776,10 @@ return;
 else
bv->bc->vwidth = val;
 BCCharChangedUpdate(bv->bc);
+
+if ( !bv->bdf->sf->onlybitmaps )
+return;
+
 for ( bdf=bv->bdf->sf->bitmaps; bdf!=NULL; bdf=bdf->next )
if ( bdf->pixelsize > mysize )
 return;
@@ -2065,10 +2067,10 @@ static void mtlistcheck(GWindow gw,struct gmenuitem 
*mi,GEvent *e) {
 for ( mi = mi->sub; mi->ti.text!=NULL || mi->ti.line ; ++mi ) {
switch ( mi->mid ) {
  case MID_SetWidth:
-   mi->ti.disabled = !bv->bdf->sf->onlybitmaps;
+   mi->ti.disabled = 0;
  break;
  case MID_SetVWidth:
-   mi->ti.disabled = !bv->bdf->sf->onlybitmaps || 
!bv->bdf->sf->hasvmetrics;
+   mi->ti.disabled = !bv->bdf->sf->hasvmetrics;
  break;
}
 }
-- 
2.8.1

Bug#818925: Packaging the TrueType fonts (was: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close))

[Jens Reyer]

[Also see my previous mail "Wine's forked version of fontforge" to
wine-devel/#818925.]

On 04/09/2016 06:46 AM, Michael Gilbert wrote:
>> We might also mention in debian/README.source that upstream uses a
>> forked fontforge - but per se this doesn't solve the need to rebuild the
>> Truetype fonts with a tool that is present in Debian.
> 
> A bug report tracking the problem would be better.

I will file one once the changes are released (1.8.2-1).

Speaking of ... I have cherrypicked my last 3 output commits from master
and imported the new upstream version. Should I push those changes to
"stretch" now, or should I wait (for you doing the release, and my
changes to be a bit longer exposed in src:wine-development)?

  * New upstream release 1.8.2, released Apr 12, 2016.
- Various bug fixes.
- Small translation updates.
  * Add patch to append '(Debian)' to the version string.
  * If wine32 is missing warn about it unless err output is disabled.
(closes: #818874)

I may also push the maintainer mode/font changes to master. Not sure if
you want to test them in src:wine first.

Greets
jre

Bug#818925: Wine's forked version of fontforge

[Jens Reyer]

Hi,

in Debian we're currently moving to enable the maintainer mode to e.g.
rebuild Wine's TrueType fonts. AJ already warned us that this is risky:

On 04/01/2016 04:54 AM, wine-b...@winehq.org wrote:
> https://bugs.winehq.org/show_bug.cgi?id=40391
> 
> --- Comment #3 from Alexandre Julliard  ---
> There is definitely a risk too, particularly for fonts. They are supposed to 
> be
> built with our forked version of fontforge
> (https://source.winehq.org/git/fontforge.git), that contains a couple of fixes
> compared to the upstream version.

I really appreciate that warning, thanks again! See a "short"
explanation at the end of the mail, why we want to do this anyway.

I'd like to figure out how to improve the resulting situation by getting
the Wine changes to fontforge applied upstream (and/or in Debian). With
"upstream" I mean github.com/fontforge. I will contact them in a later step.

Wine and Debian are both using the quite old fontforge version
20120731-b, the patches apply cleanly in Debian.
But upstream is actively developing and in Debian someone is working on
packaging a recent version (not sure with what outcome, e.g. afaik there
is at least one upstream regression blocking an update).
Are there any plans in Wine to update to a newer version?


Wine's fontforge has 4 changes. I recreated them based on AJ's merge for
20120731-b and by myself for 20160404 to get a *rough* picture of their
current state (not tested and I'm absolutely no expert in this):


1. Various hacks to avoid putting timestamps in generated files (AJ).

No relevant changes upstream, but there is some work going to allow one
to specify the timestamp in order to get the build
deterministic/reproducible. Would this make this patch obsolete?

I don't know why upstream wants timestamps at all, nor what problems
these cause for Wine. Is this Wine specific, or would it make sense to
drop timestamping upstream, too?


2. - Avoid outputting trailing spaces in sfd files (AJ).

About a third seems to be applied in 20160404. I assume the rest would
still be relevant if Wine updated its fontforge version.

Is this patch only relevant for creating fonts/glyphs, but not for
building the TrueType fonts?
Looks like a good candidate for forwarding to upstream.


3. Enable the width of individual bitmap strikes to be altered (Huw Davies).

Since the import of upstream version 20120731-b this patch only has a
third of its original size. Are the remaining Wine changes still
necessary, or are they cruft? If still needed, I guess they should be
pushed upstream.

In 20160404 not much seems to have changed, but the containing file
bitmapview.c was moved ("splitting ui code from fontforge/ to
fontforgeexe/").

Same as above: is this only needed when creating fonts? Looks like a
candidate for upstream.

4. Don't save the selected state. (Huw Davies)

I found no relevant changes upstream.
No idea about this.


Why are we doing this?
--
The Debian Free Software Guidelines [DFSG] (which are the fundamental
basis for the Debian project) mandate that binaries must be accompanied
by their source (which is usually ensured by building from source), and
that you must be able to modify and redistribute the package with only
the software available in Debian.
The reasons for these are e.g. philosophical (empowering the user), QA
(rebuilding if there was an issue in the build tools), reproducibility
(recreate byte-by-byte-identically, e.g. to rule out attacks at a build
machine or do QA) or security (a build from correct source code may be
manipulated by specific compilers).
The TrueType fonts are pre-built with a forked fontforge, which isn't
(and very unlikely will ever be) in Debian. To package the pre-built
fonts imo we would have to remove Wine from official Debian (main), and
move it to the non/semi-official contrib section.
For the same reason (AFAIK, I'm not the author of these changes) we're
also regenerating opengl files, request code and unicode.
This problem was ignored/missed in the past for the Debian Wine
packages, yet this is no argument against fixing them now. We definitely
don't want Wine removed from Debian, instead keep it in and get it there
as good as possible.

btw, we're also adding a patch (based on wine staging) to append
'(Debian)' to the version string now.

btw2, can you recommend some alternative free fonts to install (either
as partial replacement or as extension to the Wine fonts)?

Greets, and thanks in advance
jre


[DFSG] https://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg,
see also the following chapter "The main archive area".

Bug#818874: "Bad EXE format" error message in case of arch mismatch not very informative

[Jens Reyer]

control: tags -1 + patch

I just pushed to master (src:wine-development, but if we keep it, I will
push it to stretch (src:wine), too):

3c733ad57b848262b76486efc6606093db87de21
 Fix wording of the wine32 hint.
9e6573170821325e5212c89612f023205f7a0e0c
 If wine32 is missing warn about it unless err output is disabled.

Now, whenever you use wine but wine32 is missing, you'll get this
warning (unless you've disabled err debug output):

  it looks like wine32-development is missing, you should install it.
  multiarch needs to be enabled first.  as root, please
  execute "dpkg --add-architecture i386 && apt-get update &&
  apt-get install wine32-development"

or

  it looks like wine32-development is missing, you should install it.
  as root, please execute "apt-get install wine32-development"

Previously you would only get this warning if multiarch was not enabled:

  it looks like multiarch needs to be enabled.  as root, please
  execute "dpkg --add-architecture i386 && apt-get update &&
  apt-get install wine32-development"


Now, if you get these messages first, and then "Bad EXE format", it
shouldn't be that cryptic any more.


About the implementation (see git): I slightly prefer my chosen
approach, but instead we may merge the separate wine32_hint function and
the if-construct in something like:

case x$WINEDEBUGx in
x-all*|x*,-all*|x*err-all*)
;;
*)
echo "..." >&2
...
;;
esac

And maybe we can improve the wording.

Greets
jre

Bug#818925: Packaging the TrueType fonts Re: Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Jens Reyer]

 - Add fontdir.patch to take into account the build time configuration
   (closes: #814844).
+- Install wine's TrueType fonts in package fonts-wine-contrib
+  (closes: #818925).
 
  -- Jens Reyer <jre.wine...@gmail.com>  Sun, 13 Mar 2016 02:40:12 +0100
 
diff --git a/debian/control.in b/debian/control.in
index 53cc10a..e9bf708 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -210,13 +210,15 @@ Description: Windows API implementation - 64-bit developer tools
  .
  This package provides wine's 64-bit developer tools.
 
-Package: fonts-wineVERSION
+Package: fonts-wine
 Section: fonts
 Architecture: all
 Multi-Arch: foreign
 Built-Using: ${built:Using}
 Depends:
  ${misc:Depends},
+Suggests:
+ fonts-wine-contrib,
 Replaces:
  libwineVERSION (<< 1.7.41-2~),
 Breaks:
@@ -227,6 +229,24 @@ Description: Windows API implementation - fonts
  .
  This package provides the fonts used by wine.
 
+Package: fonts-wine-contrib
+Section: contrib/fonts
+Architecture: all
+Multi-Arch: foreign
+Built-Using: ${built:Using}
+Depends:
+ ${misc:Depends},
+Replaces:
+ libwineVERSION (<< 1.7.41-2~),
+Breaks:
+ libwineVERSION (<< 1.7.41-2~),
+Description: Windows API implementation - fonts (contrib)
+ Wine is a free MS-Windows API implementation.
+ This is still a work in progress and many applications may still not work.
+ .
+ This package provides the fonts used by wine that require special build
+ tools.
+
 Package: libwineVERSION
 Section: libs
 Architecture: amd64 any-i386 any-powerpc armel armhf arm64
diff --git a/debian/fonts-wine-contrib.docs b/debian/fonts-wine-contrib.docs
new file mode 100644
index 000..3470255
--- /dev/null
+++ b/debian/fonts-wine-contrib.docs
@@ -0,0 +1 @@
+debian/tmp/changelog
diff --git a/debian/fonts-wine-contrib.install b/debian/fonts-wine-contrib.install
new file mode 100644
index 000..8833d78
--- /dev/null
+++ b/debian/fonts-wine-contrib.install
@@ -0,0 +1,5 @@
+fonts/symbol.ttf usr/share/wine/fonts
+fonts/tahoma.ttf usr/share/wine/fonts
+fonts/marlett.ttf usr/share/wine/fonts
+fonts/tahomabd.ttf usr/share/wine/fonts
+fonts/wingding.ttf usr/share/wine/fonts

Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Jens Reyer]

On 03/23/2016 01:33 AM, Jens Reyer wrote:
[...]
> Ok. So we need to package these TrueType fonts again.
> 
> See also #814844 (wine: fonts-wine fonts are not found). I assume
> upstream's fix for that bug now triggers your issue.

See attached InstallAndUseFonts.patch (applies to git branch stretch,
where we currently package the fonts from). It:
- adds the ttf fonts
- backports upstream's patch to take the fontdir specified at build time
into account
- sets fontdir /usr/share/wine/fonts

This should solve all user visible fonts related issues in both wine and
wine-development.


> However I just noted that the TrueType fonts are generated by upstream.
> So we should regenerate before we can package them.

Initially I thought that this requires to manually change the Makefile
to build the TrueType fonts. However I noted that this happens upstream
in "maintainer mode". I implemented that, see attached
RebuildFonts.patch (for branch stretch).

Upstream's maintainer mode sets the CFLAG "-Werror". I reported the
first build failure on a warning at
https://bugs.winehq.org/show_bug.cgi?id=40391. (btw: we also get e.g.
"warning: 'install_wine_gecko' defined but not used [-Wunused-function]"
if we use disable/external-installers.patch). I workarounded this by
specifying "-Wno-error".

However upstream told me in that bug report that it is risky to rebuild
the TrueType fonts, because they use a forked fontforge. So what should
we do?

- Don't ship the TrueType fonts (see the already reported issues, bad idea)?
- Ship pre-built TrueType fonts (only InstallAndUseFonts.patch)?
- Regenerate the TrueType fonts (both patches)

What do you think?

Greets
jre
diff --git a/debian/changelog b/debian/changelog
index 89263dd..f280179 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,10 @@ wine (1.8.1-3) UNRELEASED; urgency=medium
 - Break older wine32|64 which don't have a reverse version requirement.
 - Re-enable "err" level output by default (closes: #816014).
 - Drop version output (closes: #816017).
+- Install wine's TrueType fonts (closes: #818925).
+- Set fontdir /usr/share/wine/fonts.
+- Add fontdir.patch to take into account the build time configuration
+  (closes: #814844).
 
  -- Jens Reyer <jre.wine...@gmail.com>  Sun, 13 Mar 2016 02:40:12 +0100
 
diff --git a/debian/fonts-wine.install b/debian/fonts-wine.install
index 7977454..4b761c9 100644
--- a/debian/fonts-wine.install
+++ b/debian/fonts-wine.install
@@ -1 +1,7 @@
 fonts/*.fon usr/share/wine/fonts
+
+fonts/symbol.ttf usr/share/wine/fonts
+fonts/tahoma.ttf usr/share/wine/fonts
+fonts/marlett.ttf usr/share/wine/fonts
+fonts/tahomabd.ttf usr/share/wine/fonts
+fonts/wingding.ttf usr/share/wine/fonts
diff --git a/debian/patches/fontdir.patch b/debian/patches/fontdir.patch
new file mode 100644
index 000..ecc802b
--- /dev/null
+++ b/debian/patches/fontdir.patch
@@ -0,0 +1,103 @@
+Description: gdi32: Take into account the fontdir directory specified at build time.
+Origin: http://source.winehq.org/git/wine.git/commit/1eac54ef7d6d90fcc973c5ea92a53be73f61ff12
+Bug: https://bugs.winehq.org/show_bug.cgi?id=40312
+Bug-Debian: https://bugs.debian.org/814844
+Applied-Upstream: 1.9.6
+
+--- a/dlls/gdi32/Makefile.in
 b/dlls/gdi32/Makefile.in
+@@ -49,3 +49,5 @@ C_SRCS = \
+ 	vertical.c
+ 
+ RC_SRCS = gdi32.rc
++
++freetype_EXTRADEFS = -DWINE_FONT_DIR=\"`$(MAKEDEP) -R ${datadir}/wine ${fontdir}`\"
+--- a/dlls/gdi32/freetype.c
 b/dlls/gdi32/freetype.c
+@@ -213,6 +213,10 @@ MAKE_FUNCPTR(FcPatternGetString);
+ #define GET_BE_WORD(x) RtlUshortByteSwap(x)
+ #endif
+ 
++#ifndef WINE_FONT_DIR
++#define WINE_FONT_DIR "fonts"
++#endif
++
+ /* This is basically a copy of FT_Bitmap_Size with an extra element added */
+ typedef struct {
+ FT_Short height;
+@@ -2960,22 +2964,44 @@ static void load_mac_fonts(void)
+ 
+ #endif
+ 
++static char *get_font_dir(void)
++{
++const char *build_dir, *data_dir;
++char *name = NULL;
++
++if ((data_dir = wine_get_data_dir()))
++{
++if (!(name = HeapAlloc( GetProcessHeap(), 0, strlen(data_dir) + 1 + sizeof(WINE_FONT_DIR) )))
++return NULL;
++strcpy( name, data_dir );
++strcat( name, "/" );
++strcat( name, WINE_FONT_DIR );
++}
++else if ((build_dir = wine_get_build_dir()))
++{
++if (!(name = HeapAlloc( GetProcessHeap(), 0, strlen(build_dir) + sizeof("/fonts") )))
++return NULL;
++strcpy( name, build_dir );
++strcat( name, "/fonts" );
++}
++return name;
++}
++
+ static char *get_data_dir_path( LPCWSTR file )
+ {
+ char *unix_name = NULL;
+-const char *data_dir = wine_get_data_dir();
+-
+-if (!data_dir) data_dir = wine_get_build_dir();
++char *font_dir = get_font_dir();
+ 
+-if (data_dir)
++if (font_dir)
+ {
+ INT len = Wide

Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Jens Reyer]

control: block 814844 by -1


On 03/22/2016 10:41 PM, Joerg Schiermeier wrote:
> 1.) How to reproduce this error:

I can confirm that in Gnome now.


>> First try some additional fonts from the wine source:
>> $ cd fonts/
>> $ sudo cp marlett.ttf symbol.ttf tahomabd.ttf tahoma.ttf \
>>   wingding.ttf /usr/share/wine/fonts/
> First I copied all fonts like yours description. This was working the
> glitch disappears. To catch the right suspect I copied than the font
> files one by one and discovered that 'marlett.ttf' was the one which
> did the trick.

Ok. So we need to package these TrueType fonts again.

See also #814844 (wine: fonts-wine fonts are not found). I assume
upstream's fix for that bug now triggers your issue.

Next to my tests there, I also found a real world issue: the login
window of Steam [1] has no writing at all, independently if fonts-wine
(1.8.1-2) is installed and the system's fonts are there or not. Found in
1.9.5-3 and 1.9.6-1, so even before the recent upstream change. Only
installing the Wine TrueType fonts solves this.

[1]: https://steamcdn-a.akamaihd.net/client/installer/SteamSetup.exe


However I just noted that the TrueType fonts are generated by upstream.
So we should regenerate before we can package them.

@Mike: Can you implement that? I guess you're fitter in these changes,
it would take me some time to find my way there.


>> Then uninstall fonts-wine (make sure that /usr/share/wine/fonts/ gets
>> removed).
> This wasn't necessary.

I tried but it didn't fix the issue. I had expected otherwise.


> I would like to have the changes in Debians wine code under source
> control for instance of git. I like the bisection mechanism to find the
> patch with is to blame ().

wine-development is on the master branch at
https://anonscm.debian.org/git/pkg-wine/wine.git

Greets
jre

Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Jens Reyer]

Hi,

so 1.9.5-1 was not affected?
Do you get this in every window/app? I can't reproduce this, yet.
Do you have fonts-liberation installed?

Please try the following two things separately (maybe each time with a
new wineprefix):

First try some additional fonts from the wine source:
$ cd fonts/
$ sudo cp marlett.ttf symbol.ttf tahomabd.ttf tahoma.ttf \
  wingding.ttf /usr/share/wine/fonts/

Then uninstall fonts-wine (make sure that /usr/share/wine/fonts/ gets
removed).

Greets
jre

Bug#814844: [pkg-wine-party] Bug#814844: wine: fonts-wine fonts are not found.

[Jens Reyer]

Upstream (1.9.6) now honors fontdir (see below). Cherry-picking this
commit to 1.8.1 works.


However I noted that you always need some of the .ttf fonts next to the
.fon fonts. Otherwise the line height is much too big. So I think we
should install some of Wine's .ttf fonts. Vanilla wine installs the
following fonts:
  marlett.ttf
  symbol.ttf
  tahomabd.ttf
  tahoma.ttf
  wingding.ttf
I asked upstream if not even all .ttf fonts should be installed
(https://www.winehq.org/pipermail/wine-devel/2016-March/112271.html).

Optimally we'd use the upstream logic to install the fonts (fon+ttf) in
arch-indep. I don't know though if this possible.

Otherwise I'd suggest (and commit that to "stretch") to package those 5
fonts and the upstream fix.

Greets
jre


commit 1eac54ef7d6d90fcc973c5ea92a53be73f61ff12
Author: Alexandre Julliard 
Date:   Thu Mar 17 17:23:24 2016 +0900

gdi32: Take into account the fontdir directory specified at build time.

Signed-off-by: Alexandre Julliard 

Bug#814844: wine: fonts-wine fonts are not found.

[Jens Reyer]

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=40312


Forwarded, the upstream report got some feedback by AJ to keep in
mind.


I pushed a patch (see below) to the git master branch
(wine-development) to at least workaround the problem. However I'm
not sure if this catches every issue. Further my solution is quite
crude, generally it would be much better to actually use fontdir
instead of datadir. If someone can make a better patch that would be
very welcome.


And finally, in the stretch branch we currently have:
-fontdir = ${datadir}/wine/fonts
+fontdir = ${datadir}/wine
  
Typo? Imo, that should be either ${datadir}/fonts, or as in master
/usr/share/wine/fonts (for stable wine both  are the same). Of
course currently this doesn't seem to matter because fontdir is
ignored.





commit b4e5b140010b0825a1b7f658e9bc2be56caba60a
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Tue Mar 15 19:58:49 2016 +0100

Add freetype.patch to fix font search path.

Closes in wine stable: #814844

For fontdir=/usr/share/wine/fonts and
datadir=/usr/share/wine-development.
Upstream uses fontdir=${datadir}/wine/fonts.
===
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
@@ -2980,9 +2980,9 @@ static char *get_data_dir_path( LPCWSTR
 {
 INT len = WideCharToMultiByte(CP_UNIXCP, 0, file, -1, NULL, 0, NULL, 
NULL);
 
-unix_name = HeapAlloc(GetProcessHeap(), 0, strlen(data_dir) + len + 
sizeof("/fonts/"));
+unix_name = HeapAlloc(GetProcessHeap(), 0, strlen(data_dir) + len + 
sizeof("/../../wine/fonts/"));
 strcpy(unix_name, data_dir);
-strcat(unix_name, "/fonts/");
+strcat(unix_name, "/../../wine/fonts/");
 
 WideCharToMultiByte(CP_UNIXCP, 0, file, -1, unix_name + 
strlen(unix_name), len, NULL, NULL);
 }

Bug#816017: /usr/bin/wineserver: unnecessary noise on stderr

[Jens Reyer]

control: tags -1 + pending

Hi,

I just pushed a commit to fix this, see below.

Greets
jre


commit a18275ca64d5f8674e978eb2ad4c4e7249800cd4
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Mar 13 02:37:18 2016 +0100

Drop version output.

Closes: #816017

Sources:
commit 8fcdc3022a88f150970fc5176a6fe7a7bd572ba4
Author: Michael Gilbert <mgilb...@debian.org>
Date:   Sat Mar 5 01:25:40 2016 +

release 1.9.5-1

commit 16b7fefa9f7bb5b9ffb0794d5a238d6cf92707e3
Author: Michael Gilbert <mgilb...@debian.org>
Date:   Sun Feb 28 19:28:57 2016 +

release 1.9.4-2

Bug#816014: /usr/bin/wine hides errors by default

[Jens Reyer]

control: tags -1 + pending

Hi,

I just pushed a commit to fix this, see below. This doesn't remove the
Debian specific WINEDEBUG code as requested, but re-enables "err" level
output (but not fixme which is also part of the upstream default) and
documents this.
Please note that this topic has been discussed several times in the
bugtracker and the mailing list, e.g.
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2016-January/005091.html.

Greets
jre


commit d30c8351819c2534cd1bc77bffcc2a11d85fb51b
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Sun Mar 13 02:30:08 2016 +0100

Re-enable "err" level output by default.

Closes: #816014

Source:
commit 16b7fefa9f7bb5b9ffb0794d5a238d6cf92707e3
Author: Michael Gilbert <mgilb...@debian.org>
Date:   Sun Feb 28 19:28:57 2016 +

release 1.9.4-2

Bug#816034: wine32: insecure use of /tmp

[Jens Reyer]

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=39013

Upstream bug was merged with #39013 "Cannot change the location of the
folder put in /tmp/.wine-uid"

Debian bug has been cloned as:
https://bugs.gentoo.org/show_bug.cgi?id=576134
https://bugzilla.redhat.com/show_bug.cgi?id=1312958

Bug#816167: wine: sporadic sound failure output BTW wine versions from debian stretch release to now

[Jens Reyer]

Hi Fulano,

sorry I don't get what you want to say with "BTW wine versions from
debian stretch release to now".

I see similar "warn+all" output with everything working, also if I use
the official winehq wine-devel packages instead. Of course I might miss
something,  but I'd suggest to first try "fixme+all,err+all" instead,
and then to follow https://wiki.winehq.org/Sound.

Did sound work with previous wine versions:
- wine 1.6 or wine-development up to 1.7.54?
- wine 1.8 (which uses the new pulseaudio)?

Please also test with:
- wine-development (instead of wine).
- a new clean wineprefix.

Greets
jre

Bug#815031: wine: packaging depends fault

[Jens Reyer]

control: tags -1 + moreinfo

Hi Richard

On 02/18/2016 03:59 AM, Austin English wrote:
> On Wed, Feb 17, 2016 at 8:46 PM, Richard Jasmin  
> wrote:
>> we have a SERIOUS depends issue going on with Jessie and multiarch(and any
>> spins based of Jessie).
>>
>> I thought it was just skype being a dick. Its not.
>> Try and install wine and you have the same scenario.
>>
>> What it boils down to is this:
>>
>> The installable package demands libav.
>> Libav demands every other libav package.
>> ASoundlibs are demanded.
>>
>> This demands (generic) openCL be installed, breaking any proprietary video
>> setup you may have(or at least in part).These packages have no need for 
>> either
>> libav, nor openCL.
> 
> Wine doesn't use or depend on libav, I'm not sure how you came to the
> conclusion that this is a Wine bug.

You can at least uninstall the following packages (+ a bunch of other
packages depended on by them).
libasound2-plugins
libavcodec-ffmpeg56
libavresample-ffmpeg2
libavutil-ffmpeg54
libswscale-ffmpeg3
libvdpau-va-gl1
vdpau-driver-all

However, libasound2 has to be installed. And I fail to see a reason to
change that.


>> This demands (generic) openCL be installed [...]
>> Only in rare cases is OpenCL needed. The wine apps that may need it, cannot 
>> run
>> it due to other requirements.Skype doesnt need it.
>>
>> This was reported prior to DECEMBER 2014.
>> (http://ubuntuforums.org/showthread.php?t=2257502)
> Ubuntu isn't Debian, and reports made on ubuntu forums aren't tracked
> in Debian's bug system.

Indeed, and in this case except for wine-development they don't even
have the same packages.

But you know that you can alternatively install
[amd|nvidia|ocl-icd]-libopencl1?

Does this solve the problems for you?

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#814844: wine: fonts-wine fonts are not found.

[Jens Reyer]

Package: wine
Version: 1.8.1-2
Severity: normal

Hi,

the fonts-wine fonts are still not found. I removed /usr/share/fonts and
tested in winefile.

It works as soon as I copy or link the fonts folder to
/usr/share/wine/wine/fonts.

Same for wine-development. It works if I link the fonts folder to
/usr/share/wine-development/wine/fonts.

So it seems that independently of what is specified for fontdir in the
Makefile, Wine expects fonts to be in ${datadir}/wine/fonts.
DATDIR=usr/share/wine$(VERSION) is set in debian/rules.

btw: Between Wine 1.6 and 1.8 there were at least 9 commits related to
fonts. So they are not totally static. That's just another data point
for the fonts-wine(-development) deduplication - not sure if this
warrants the duplication that we had before and which route we should
take to solve these 2 issues.

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)

Versions of packages wine depends on:
ii  wine32  1.8.1-2
ii  wine64  1.8.1-2

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-4.2
pn  wine-binfmt  

Versions of packages wine is related to:
ii  fonts-wine  1.8.1-2
ii  wine1.8.1-2
ii  wine32  1.8.1-2
ii  wine64  1.8.1-2

-- no debconf information

Bug#814572: Please print information output to stderr

[Jens Reyer]

control: tags -1 + pending

Hi,

thanks, this is already fixed in git:

commit d630ec8869c3a62cbabad1b6b4284ab931e222ae
Author: Jens Reyer <jre.wine...@gmail.com>
Date:   Fri Feb 12 01:08:11 2016 +0100

Send script messages to STDERR.

Thanks Joerg Schiermeier.

Greets
jre

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#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Jens Reyer]

I tested it further: I completly emptied /usr/share/fonts. Then, only
the font family "Latin Modern (LM)" (installed in
/usr/share/texmf/fonts) is available and used. I checked this in the
font selection dialogs of libreoffice (Linux native) and winefile.

Then I installed wine 1.8-6 with fonts-wine 1.8-6:
this correctly adds several fonts in winefile.

However with wine 1.8.1-1 and fonts-wine 1.8.1-1 installed, even with
- libfontconfig1 (amd64 and i386) installed and
- enabled bitmapped fonts in "dpkg-reconfigure fontconfig-config",
there are no additional fonts available, neither in winefile, nor
in libreoffice.

For Wine to work either the system fonts or wine-fonts *must* work. The
system fonts imo provide a much superior result. I therefore committed
the change for libwine to always depend on libfontconfig1 (so you end up
with e.g. both the i386 and the amd64 version).
The 32-bit version inadvertently missing happens too easily and has too
severe drawbacks, compared to the benefits of not installing this
package and using only fonts-wine - imo this justifies the promotion
from recommends to depends.

However, to close this bug we should also fix fonts-wine. Even in an
afaics correctly set up system these fonts never show up, neither in
wine nor in the system. I have absolutely no clue how to make them in
the new position in /usr/share/fonts/wine work.
But I found this changelog entry from 2006:
---
 * Wine now install its fonts under /usr/share/wine/fonts, not
/usr/share/fonts/wine. (I've updated the packaging accordingly.)
This should stop them from being picked up by fontconfig et al.
Closes: #353495.
---
The fonts were removed from the new position previously on purpose,
because they weren't correctly rendered in some native apps.

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]

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#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#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Jens Reyer]

control: tags -1 - moreinfo

On 02/08/2016 10:42 PM, Johannes Stezenbach wrote:
> I just ran into the same issue, and after some
> experiments found it is caused by a missing libfontconfig1.
> libfontconfig1:i386 is only in Recommends of libwine:i386,
> but it should be in Depends.
> Same for libwine-development (1.9.0-2).

Hi,

thanks a lot Johannes. I can confirm this now, if I install only the
32-bit packages and uninstall libfontconfig1:i386.

In 1.8-6 if libfontconfig1:i386 is not installed, but fonts-wine is
installed, this doesn't happen. However another font is used then.

tl;dr: There are two issues that should be fixed. I suggest to depend on
libfontconfig1 to make the system fonts available, and to revert the
fonts related changes to make the Wine fonts available. Better
solutions/analysis welcome.

1.)
libfontconfig1 is needed to use the Linux system fonts. Although you can
use 64-bit prefixes just fine even if only libfontconfig1:amd64 is
installed, I think we should make sure that the system fonts *always*
work in Wine (the Wine font used as fallback in winefile is really
ugly). Or is there any use case for wanting to disable them? Otherwise
I'd suggest to depend on libfontconfig1.
I assume this just wasn't reported before, because:

2a)
Without libfontconfig1 in 1.8-6 the Wine fonts were still found, but
aren't now. Looks as if something is broken (the fontdir seems to be
correctly set in the Makefile, so I wonder if Wine has some other
internals that require/exclude a specific fontdir).

2b)
Even if we decided to ignore that problem, and chose to use the Wine
fonts via fontconfig (if that really works the same way for Wine without
drawbacks), we would probably have a new problem: per default fontconfig
doesn't include bitmapped fonts anymore (see
/usr/share/doc/fontconfig/README.Debian). But afaics the Wine fonts are
bitmap fonts. Currently I can only assume this to be a problem, any idea
how to explicitly test the Wine fonts?

If 2a is fixed, 2b won't be a problem. For now my only idea is to revert
that change, although I generally like the idea of the common
fonts-wine, with fonts in /usr/share/fonts (I assume this is not a
strict requirement, didn't check, though).

Greets
jre

Bug#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Jens Reyer]

On 02/01/2016 03:21 PM, Bjørn Mork wrote:
> Package: fonts-wine
> Version: 1.8-7
> Severity: important
> 
> Upgrading fonts-wine from 1.8-6 to 1.8-7 breaks wine. 
> 
> Running e.g. winefile with  WINEDEBUG=warn+all results in lots of
> warnings like this:
> 
>  fixme:font:freetype_SelectFont can't find a single appropriate font - bailing
> 
> and a mostly empty application window.  Downgrading fonts-wine to 1.8-6
> fixes the problem.  So does 
> 
>  /usr/share/wine/wine
>  ln -s ../../fonts/wine fonts
> 
> Looks like the move to /usr/share/fonts wasn't complete?

winecfg or winefile look ok here, even if I start with 1.8-6, create a
prefix and update to 1.8-7 or 1.8.1-1. I also don't get the fixme
warnings (although enabled in WINEDEBUG).

But other Windows applications indeed also miss the text in their
windows. Creating the link doesn't help though for that.

I have fonts-liberation installed (but not ttf-mscorefonts-installer).
Unfortunately I can't easily test if this is the reason that I don't see
exactly the same problem. Do you have fonts-liberation installed?

btw 1, packages.d.o [1] strangely still shows the old filepaths (up to
1.8-6), e.g. /usr/share/wine/wine/fonts/vgasyst.fon. But I don't see how
this could be related.

btw 2, wine-development has fontdir = /usr/share/wine/wine/fonts.

Greets
jre

[1]: https://packages.debian.org/sid/all/fonts-wine/filelist

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#810948: dh_strip: Use dbgsym notation instead of ddeb

[Jens Reyer]

Package: debhelper
Version: 9.20151225
Severity: wishlist

Hi,

dh_strip implements the new automatic debug packages using the word
"ddeb" (e.g. --ddeb-migration, --ddebs, --no-ddebs). However ddeb was
only used in earlier implementations, at least the packages are now
called foo-dbgsym*.deb, not foo*.ddeb.

I'd suggest to use "dbgsym" instead, to avoid any confusion in the long
run. I think now is still the right time to change this. Maybe keep the
option-names available for compatibility and print a deprecation
warning, but simply do a replace in the documentation.

Greets and thanks
jre



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'unstable'), (100, 'experimental'), (1, 'experimental-debug')
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)

Versions of packages debhelper depends on:
ii  binutils 2.25.90.20160101-1
ii  dh-strip-nondeterminism  0.014-1
ii  dpkg 1.18.4
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-3
ii  po-debconf   1.0.18

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  1.20150601

-- no debconf information

Bug#809125: [pkg-wine-party] Bug#809125: Bug#809125: wine-development: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Jens Reyer]

On 01/11/2016 07:47 AM, Tobias Frost wrote:
> On Sun, 10 Jan 2016 17:09:31 +0100 Jens Reyer <jre.wine...@gmail.com>
> wrote:
>> control: tags -1 + pending
>>  
>> On 12/27/2015 01:33 PM, Santiago Vila wrote:
>>> Package: src:wine-development
>>> Version: 1.7.55-4
>>> User: sanv...@debian.org
>>> Usertags: binary-indep
>>> Severity: important
>>>  
>>> Dear maintainer:
>>>  
>>> I tried to build this package with "dpkg-buildpackage -A"
>>> (i.e. only architecture-independent packages), and it failed:
>>  
>> This has been fixed in wine 1.8-2 and should be part of the next
>> wine-development release.
>>  
>> Greets
>> jre
>>  
>>  
> Hi,
> 
> you reference wine 1.8-2 here (different source package)
> Maybe set pending to the wrong bug, us wine 1.8-2 was indeed uploaded?

Hi,

no, the pending was set on purpose: wine and wine-development share the
same  packaging. The changes made now in wine will be part of the next
wine-development release (unless we have to revert them or change the
way the packaging works).

Greets
jre

Bug#809904: ug#809904: wine-development: FTBFS with libpng16

[Jens Reyer]

On 01/11/2016 07:48 AM, Tobias Frost wrote:
> Control: Block -1 by 809125
> 
> I guess this bug is actually #809125, not induced by libpng; it also
> fails in sid.

Indeed. You may simply test building only the arch specific packages
(-B), this is what would happen for a binNMU, wouldn't it?

Since wine passes the test now, I'm quite sure that there is no libpng16
problem in wine-development. There is only one month upstream
development between them, and I'm not aware of any relevant changes in
Debian. Of course we still need to verify that by testing.

Bug#810658: winetricks: Please adjust to new wine packaging (WoW64/wineserver)

[Jens Reyer]

Package: winetricks
Version: 0.0+20151116-1
Severity: normal
Tags: patch


Hi Joseph,

there were some changes in wine 1.8-2 that are also relevant for winetricks:

- Wine now supports and uses shared WoW64/64-bit wineprefixes if wine,
wine32 and wine64 are installed. We discussed winetricks 64-bit for a
bit on pkg-wine-party, that might be of interest for you/users [1].

- Wine now always defaults to $HOME/.wine (no $HOME/.wine64).

- The wineserver is now /usr/bin/wineserver or
/usr/bin/wineserver-development (when it's implemented there). The old
filepaths of wineserver don't exist anymore.

- /usr/bin/wine and /usr/bin/wineserver are in the package wine.

winetricks upstream already accepted my pull request [2]. This patch
will be needed as soon as wine-development with the recent changes is
uploaded.


For the Debian packaging I suggest to (see also attached patch):

- Remove the README entry of 11 Dec 2015 (wine64-only): It's not needed
anymore, and may even cause errors.

- Update the README entry of 23 Sept 2014 for the new
wineserver-development path.

- Change the dependencies in d/control to only depend on
wine|wineserver. Installations without wine (only wine32 and/or wine64)
do not work anymore.


btw, can you please update
git.debian.org/git/collab-maint/winetricks.git. Alternatively, if you
push to another repository can you update debian/control?

Greets
jre


[1]:
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2015-December/005071.html

http://lists.alioth.debian.org/pipermail/pkg-wine-party/2016-January/005121.html

[2]
commit 3cf3d9a3c0e0920792d481b0c7eb286278e7d51a
Author: Jens Reyer <jre.wine...@gmail.com>
Date: Mon Jan 11 01:31:20 2016 +0100
Adapt to new Debian /usr/bin/wineserver[-development].


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

Versions of packages winetricks depends on:
ii  cabextract  1.6-1
ii  p7zip   9.20.1~dfsg.1-4.2
ii  unzip   6.0-20
ii  wget1.17.1-1
ii  wine1.8-2
ii  wine32  1.8-2
ii  wine64  1.8-2
ii  zip 3.0-11

Versions of packages winetricks recommends:
ii  gksu   2.0.2-9
ii  sudo   1.8.15-1.1
ii  xdg-utils  1.1.1-1
ii  zenity 3.18.1.1-1

Versions of packages winetricks suggests:
ii  libwine  1.8-2

-- no debconf information
diff --git a/debian/README.Debian b/debian/README.Debian
index 0bd20f4..f682b2c 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -1,25 +1,15 @@
-If you only have wine64 installed, run the following commands before
-you run winetricks to use wine64:
-.
-  export WINESERVER=/usr/lib/x86_64-linux-gnu/wine/wineserver
-  export WINEPREFIX="$HOME/.wine64"
-
- -- Joseph Bisch <joseph.bi...@gmail.com>, Fri, 11 Dec 2015 22:06:45 -0500
-
-If wine is installed, it's wine binary and wineserver are used, even
+If wine is installed, its wine binary and wineserver are used, even
 if wine-development is installed. The wine-development wine binary and
 wineserver are only used if just wine-development is installed.
 .
 If you have both wine and wine-development installed and you want to
 use the wine-development wine binary and wineserver, you should execute
-the following commands before running winetricks. Make sure to replace
-the * in the WINESERVER line with the appropriate directory based on
-your system's architecture.
+the following commands before running winetricks.
 .
   export WINE=/usr/bin/wine-development
-  export WINESERVER=/usr/lib/*/wine-development/wineserver
+  export WINESERVER=/usr/bin/wineserver-development
 
- -- Joseph Bisch <joseph.bi...@gmail.com>, Tues, 23 Sept 2014 18:24:42 -0400
+ -- Joseph Bisch <joseph.bi...@gmail.com>, Mon, 11 Jan 2016 02:14:27 +0100
 
 About packages in Recommends header: to use GUI progress bar, install
 package "zenity". To read manuals, install package "xdg-utils". If
diff --git a/debian/control b/debian/control
index c342709..52cd76e 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Depends:
  p7zip,
  unzip,
  wget,
- wine32 | wine32-development | wine64 | wine64-development | wine | wine-development,
+ wine | wine-development,
  zip,
  ${misc:Depends}
 Recommends:

Bug#806206: wine: risen game installers fail

[Jens Reyer]

On 01/10/2016 02:45 AM, Jens Reyer wrote:
> just an idea, but do you have winbind installed?

Heiko told me in a PM that installing winbind didn't help.

Bug#809125: [pkg-wine-party] Bug#809125: wine-development: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Jens Reyer]

control: tags -1 + pending

On 12/27/2015 01:33 PM, Santiago Vila wrote:
> Package: src:wine-development
> Version: 1.7.55-4
> User: sanv...@debian.org
> Usertags: binary-indep
> Severity: important
> 
> Dear maintainer:
> 
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:

This has been fixed in wine 1.8-2 and should be part of the next
wine-development release.

Greets
jre

Bug#807026: wine FTBFS on amd64

[Jens Reyer]

On 01/08/2016 07:07 PM, Jens Reyer wrote:
> On 01/08/2016 09:40 AM, Graham Inggs wrote:
>> On 08/01/2016 06:58, Jens Reyer wrote:
>>> Upstream recently changed the buildsystem, since then the wine manpage
>>> isn't available any more on 64-bit.

This is fixed in Debian 1.8-2 now, and indep builds on 64-bit arch again.

Greets
jre

Bug#762058: WoW64 in wine-development

[Jens Reyer]

WoW64 is now implemented in wine 1.8-2, and should soon be in
wine-development, too.

Wine now supports and uses shared WoW64/64-bit wineprefixes if wine,
wine32 and wine64 are installed. So this should work now for all newly
created default (=64-bit) prefixes and existing 64-bit prefixes.

WoW64 works in Wine by
- adapting the /usr/bin/wine script,
- adding a /usr/bin/wineserver script that defaults to the 64-bit
wineserver, and
- not installing wineserver in wine's configured bindir (= libdir)
(/usr/lib/*/wine/wineserver).

However I assume that we have to patch the wine source to look for
wine-development, wine64-development and wineserver-development in PATH.

At least wineserver was found in @bindir@/wineserver up to now, which
doesn't exist anymore (and would break the WoW64 setup, if both the
32-bit and 64-bit wineserver existed there). Next Wine looks in PATH for
wineserver, where /usr/bin/wineserver belongs to wine (stable).
See the wine and wineserver manpages.

Similarily the 64-bit wineloader needs to be found
(/usr/bin/wine64-development). I don't have any documentation pointers
about that, but found it to be relevant.

Bug#806206: #806206: wine: risen game installers fail

[Jens Reyer]

control: retitle -1 wine: risen game installers fail from CD/DVD.

Hi,

just an idea, but do you have winbind installed?

In the Wine 1.6 -> 1.8-1 update the dependency on winbind was dropped.
Since I uninstalled winbind and all the samba stuff, wine tells me about
that. I didn't experience any issues because of that, but I don't have a
CDROM.

Greets
jre

Bug#807026: FTBFS on amd64

[Jens Reyer]

On 01/08/2016 09:40 AM, Graham Inggs wrote:
> On 08/01/2016 06:58, Jens Reyer wrote:
>> Upstream recently changed the buildsystem, since then the wine manpage
>> isn't available any more on 64-bit.
> 
> Has this been reported with upstream?  I don't think arch-dependent
> manpages are a good idea.

It was done on purpose and knowingly. I read about it on the upstream
mailing list, before seeing the consequences here. Since the manpages
contain arch specific paths I see this as the right solution generally.

The problem is that we can't really make use of the "correct" upstream
buildsystem in Debian, because we ship wrapper scripts in path, without
really knowing if the 32- or the 64-bit version gets installed, or if
they even get co-installed (then the wrapper scripts now default to
32-bit wine and 64-bit wineserver).

However I tend to ignore that as a real problem in the documentation,
see previous mails. I even decided for now to build the
wine64-binary-loader manpage from the unchanged wine-binary-loader
manpage-source.

Greets
jre

Bug#807026: FTBFS on amd64

[Jens Reyer]

[I accidentally replied to the mailing list only, see 2 previous mail
below.]
I committed changes that allow to build arch:all everywhere again.
Despite the below described problems with arch specific paths in the
manpage, I still think this is the best solution.

Greets
jre


 Forwarded Message 
Subject: Re: Bug#807026: FTBFS on amd64
Date: Thu, 7 Jan 2016 17:29:57 +0100
From: Jens Reyer <jre.wine...@gmail.com>
To: pkg-wine-pa...@lists.alioth.debian.org

On 01/07/2016 04:10 PM, Santiago Vila wrote:
> On Sat, 12 Dec 2015, Michael Gilbert wrote:
> So I should ask: Which one of those files is so special that they may
> not be built on amd64, and why not?

Upstream recently changed the buildsystem, since then the wine manpage
isn't available any more on 64-bit.

Yesterday I checked in a build based in my local git: surprisingly
loader/wine.man
still gets build (I didn't check if this also happened before my last
change). Yet arch:all still fails on amd64 because
debian/tmp/usr/share/man/man1/wineVERSION.1
doesn't exist. This would be created by d/rules from
debian/tmp/usr/share/man/man1/wine.1,
which in turn is created by the upstream buildsystem - but only on
32-bit, not on 64-bit arch.

I don't know how to patch the buildsystem. But me might fallback to
loader/wine.man on 64-bit.

However, there's something else to consider: the wine manpage yields
arch specific paths (bindir), which depend on whether wine32 and/or
wine64 is installed. I see no way to install the "correct" wine manpage
for all cases since the wine script /usr/bin/wine executes different
wine binaries depending on what is installed. Installing a 64-bit wine
manpage would only be correct if only wine64 is installed (currently it
is the "wrong" information in that case).
On the other side, the mentioned filepaths don't exist in Debian
(neither the loader, nor the wineserver if we keep my recent changes).

Greets
jre



 Forwarded Message 
Subject: Re: Bug#807026: FTBFS on amd64
Date: Thu, 7 Jan 2016 17:46:59 +0100
From: Jens Reyer <jre.wine...@gmail.com>
To: pkg-wine-pa...@lists.alioth.debian.org

On 01/07/2016 05:29 PM, Jens Reyer wrote:
> However, there's something else to consider: the wine manpage yields
> arch specific paths (bindir), which depend on whether wine32 and/or
> wine64 is installed. I see no way to install the "correct" wine manpage
> for all cases since the wine script /usr/bin/wine executes different
> wine binaries depending on what is installed. Installing a 64-bit wine
> manpage would only be correct if only wine64 is installed (currently it
> is the "wrong" information in that case).
> On the other side, the mentioned filepaths don't exist in Debian
> (neither the loader, nor the wineserver if we keep my recent changes).

Regarding that, I'm currently working on moving the wineserver script
from the package "wineserver" to "wine", and then to drop the latter
again (more on that soon).

With that setup most people would need for everything being "correct" a
wine manpage from 32-bit and a wineserver manpage from 64-bit, while
both would be shipped in the arch:all "wine" package, where the scripts
reside.

The arch specific paths mentioned in the man do exist, but as already
mentioned, the exact binaries do not. So what to do? Try to build on
64-bit, and ship the 64-bit manpages (as arch:all buildservers normally
are 64-bit)?

Greets
jre

Bug#762058: WoW64 setup (update)

[Jens Reyer]

control: tags -1 - patch

Removing the tag patch for the pseudo-WoW64-wine-script patch.

However see my previous mail to pkg-wine-party
(56858b58.2040...@gmail.com,
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2015-December/005072.html)
- it seems it is easier to solve then I thought.

tl;dr:
WoW64 seems to work if wineserver (from the native arch) is in /usr/bin
and the 32-bit wineserver is deleted (thanks Mike for the idea).
No need for other build process --with-wine64=...
Should we drop the /usr/bin/wine script and link wine, wine64 and
wineserver to /usr/bin/?

Bug#769234: Removing patch tag for "automatically detect and launch wine32 or wine64"

[Jens Reyer]

control: tags -1 - patch

Mike and I agree [1] that using "file" is a dead end for multiple
reasons (e.g. security issues and 64-bit apps with 32-bit installers).
So removing the patch tag.

If at all, I would change the wine script to honor the winearch of an
existing wineprefix (by grep'ing system.reg or checking for
drive_c/windows/syswow64/ as winetricks does). However this does only
solve the problem for already installed apps.

Instead the complete WoW64 setup seems to be possible and imo is a
better solution, see #762058.

[1]
http://lists.alioth.debian.org/pipermail/pkg-wine-party/2015-December/005042.html

Bug#802779: Bug#803349 closed by Bart Martens <ba...@debian.org> (pepperflashplugin-nonfree: Fails without giving an error message)

[Jens Reyer]

On 10/29/2015 12:43 AM, Jens Reyer wrote:
> Version: 1.8.1+b1
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

On 12/17/2015 01:57 PM, Bart Martens wrote:
> http://backports.debian.org/Instructions/#index6h2
> "and NOT to the Debian BTS!"

... so I have no idea why you closed #803349 and #802779 with
this message. No backports here.


About #803349 (improved error message/handling):
I take it that you are not interested in adding my patches. Ok,
your call.

About #802779 (Change URL to https):
I still support that request, however it is not necessary to fix
the current issues.



Currently pepperflashplugin-nonfree is completly broken in
testing/unstable. As of now the issues can be workarounded with
pada's patch
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=47;bug=763874;att=1;filename=pepperflashplugin-nonfree-with-apt-1.1.diff

#763874 is currently set to wishlist+wontfix. However with apt
1.1 in unstable and testing it is grave (makes the package in
question unusable).

Bug#808075: khronos-api: New upstream version recommended for Wine.

[Jens Reyer]

Package: khronos-api
Version: 0~svn29577-2
Severity: normal

Hi Mike,

according to https://bugs.winehq.org/show_bug.cgi?id=39744#c19 there was
a commit to update Wine's OpenGL tables.

Can you update khronos-api accordingly?

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

Bug#769234: Automatically detect wine32 and wine64.

[Jens Reyer]

On 12/13/2015 04:41 AM, Austin English wrote:
> On Sat, Dec 12, 2015 at 4:05 PM, Jens Reyer <jre.wine...@gmail.com> wrote:
>> 1.)
>> Checking with "file" (but honoring the WINE* variables first) allows to
>> continue to default to Wine32, while you still can install 64-bit apps
>> without manual intervention. However at least 64-bit apps with PE32
>> installers make this as a sole solution "problematic" and obfuscating
>> problems (-> consider tagging #769234 as "wontfix").
> 
> Wine will choose the appropriate loader without intervention. Choosing
> the architecture of the prefix should be up to the user.

Just to make sure I understood correctly: With a WoW64 (built with
--with-wine64=...") Wine:

If I *create* a new prefix then I decide about its arch (with the
default being win64) by using WINEARCH=...

But when I use an existing wineprefix, either with /usr/bin/wine
(vanilla upstream) or with a Desktop launcher, then Wine automatically
sets WINELOADER?


The latter indeed does not work with our current wine64. It could be
done with a system.reg test in our wine-script though.

I'm no programmer, but in server/registry.c I found:

- snip -
/* load a global option from the input file */
static int load_global_option( const char *buffer, struct file_load_info
*info )
{
const char *p;

if (!strncmp( buffer, "#arch=", 6 ))
{
enum prefix_type type;
p = buffer + 6;
if (!strcmp( p, "win32" )) type = PREFIX_32BIT;
else if (!strcmp( p, "win64" )) type = PREFIX_64BIT;
- snap -

I have a feeling that Wine is doing the same like grep'ing system.reg
for #arch=win32 or #arch=win64. In that case I'd feel comfortable with
doing this in the wine script (unless^Wuntil we have a real WoW64
build). Better than having launchers that don't work and which don't
give the user any hint what's wrong.
Alternatively we could write the arch information in the launcher.


Mike, for a "back to back" WoW64 build you thought about cross-compiling
on amd64, or about copying results from one arch to the other/having the
amd64 packages as build-dependency for the WoW64 build on i386?


> I should clarify that. Upstream generally recommends packagers to ship
> WOW64 and enable that by default, yes. I was speaking with my
> bugzilla/user support hat on, where the first thing recommended if
> you're having issues is to use a 32-bit prefix (since a large portion
> of 64-bit installers don't work, and there's generally little gain for
> more problems, unless it's a memory intensive application).

ack

Greets
jre

Bug#769234: Automatically detect wine32 and wine64.

[Jens Reyer]

On 12/11/2015 11:08 PM, Austin English wrote:
> On Fri, Dec 11, 2015 at 3:52 PM, Jens Reyer <jre.wine...@gmail.com> wrote:
>> Hi,
>>
>> please see below for another patch. IMO it is clean, simple and
>> matches the logic of the wine-script perfectly.
>>
>> It tries to detect the correct wine version using the following
>> precedence:
>>
>> 1. WINEARCH - can't be misinterpreted and was also used
>>previously.
>> 2. WINEPREFIX - if it is set and system.reg exists, we have a
>>clean indicator if it is a 32-bit or 64-bit installation,
>>and therefore which wine to use.
>> 3. WINELOADER - if it is set to a known loader, use this for
>>deciding which wine to use.
>>The 32-bit loaders seem to work with both wine32 and wine64,
>>but I see no point in doing this here. Instead it is easier
>>to choose the correct 32-bit or 64-bit wineprefix later if
>>wine loader and binary match.
>>Note that I'm not really familiar with the preloader.
>> 4. Test with "file" if $1 is a 64-bit application. Note that some
>>64-bit applications have PE32 installers, or install single
>>PE32 executables. But those also seem to work with wine64 as
>>long as wine32 is installed. Therefore only testing for PE32+.
[...]
> Only speaking as an upstream observer, I haven't followed the issues
> with the debian wine packaging too closely..

Thanks a lot for your constructive and informational feedback Austin. I
appreciate this very much. I'll definitely not insist on using my
patches (this and the WoW64 patch), but I think they help to discuss
this matter.

The current status in Debian is to prefer Wine32, even if Wine64 is
installed. This is a constant source for bugreports of users thinking
that Wine64 doesn't work - generally, and specifically in combination
with binfmt.

However I now see the benefit of defaulting to wine32 (even despite of
my new knowledge that WoW64 already works), given the maybe typical
installation on amd64:
1.) Install wine, pulling in wine64.
2.) Realize that wine32 is missing.
3.) Add the foreign arch and install wine32.
Because of this, and "wine" depending on "wine64|wine32", the default on
Debian (amd64) is to have wine64 installed.

Further we have to avoid breaking existing installations. With current
default 32-bit wineprefixes (although many have wine64 installed), a
simple change to WoW64 (=prefer Wine64 if installed) would cause a lot
of breakage. However if we do it, now (close to a new stable upstream
release, and a year before Debian freeeze) would be the best time.


> That said, I think going out of your way to detect what sort of prefix
> to use is the wrong approach. A properly built wow64 install will
> automatically use the correct wine bitness when launching
> applications. Trying to detect what architecture to use is prone to
> breakage, as you've seen.

I see two reasons for it:

1.)
Checking with "file" (but honoring the WINE* variables first) allows to
continue to default to Wine32, while you still can install 64-bit apps
without manual intervention. However at least 64-bit apps with PE32
installers make this as a sole solution "problematic" and obfuscating
problems (-> consider tagging #769234 as "wontfix").

2.)
Testing existing wineprefixes allows to change the default to WoW64 (if
wine64 is installed) without breaking old installations


> In general, upstream recommends running 32-bit Wine if 64-bit
> executables are not needed. For users on 64-bit OSes, the
> recommendation is usually to remove Wine64 packages if you don't want
> them.

Oh, I'd been under the impression that WoW64 is the default and
recommended by upstream. Seeing that it may also cause problems, and
reading you, I'm glad that we have 32-bit as default and I think we
should stay with that, even if wine64 is installed.

However we definitely should add something to the README. Given no other
changes in the packaging I'd propose [2].

Maybe we should consider dropping the automatic setting of WINEPREFIX,
because it is not set session-wide. Like the automatic detection, this
is a feature that may obfuscate problems. Yet, how to handle this for
existing installations? Setting the WINEPREFIX made sense for separate
32-/64-bit installation. But now that I know that WoW64 works, I see
less use in it.

Maybe we should offer a separate "wine-wow64" package similar to the
"wine" package (but conflicting with it), that offers a version of the
wine script that prefers win64 and depends on wine32 _and_ wine64.

The "Depends: wine64|wine32" in the wine package might be reversed to
"wine32|wine64".


> I don't know what issues these wrapper scripts the package is using
> are supposed to solve, t

Bug#806206: wine don't install programs from CD

[Jens Reyer]

On 12/11/2015 02:18 PM, Heiko Ernst wrote:
> Am Donnerstag, 10. Dezember 2015, 22:00:44 schrieb Jens Reyer:
>> On 11/26/2015 08:24 AM, Heiko Ernst wrote:
>>> I have mounted the dvd on kde 5 and start with wine "D:
> \\setup.exe". The
>>> installe start and show an undefined error on kde.
>>
>> And what happens if you try it directly from the CD, e.g. if it was
>> mounted to /mount/user/risen/:
>>   cd /mount/user/risen/
>>   wine setup.exe
> 
> how can i mount this to /mount/useres/risen/ ?

That's not what I suggested, that path was just an example. However I
meant /media/YOURUSERNAME/risen/, sorry for giving a bad example. ;)

What I suggested was:
1. Mount the CD as you usually do in KDE 5.
2. Open a terminal.
3. In the terminal "cd PATH", with PATH being the full pathname of the
folder of setup.exe.
4. In the same terminal issue "wine setup.exe".

Since setup.exe seems to be in the top directory of your CD, PATH is the
same as the path you mounted the CD.
If you don't know which path it is mounted to, you can check it in
/etc/mtab. If you have trouble figuring out the correct path from
/etc/mtab you might send that file to me.
Alternatively you might (not sure about that because I don't use KDE)
right click on the icon of the mounted CD or of setup.exe and check its
properties. If you find e.g. /media/YOURUSERNAME/risen/setup.exe then
PATH is /media/YOURUSERNAME/risen/.

Greets
jre

Bug#779012: Two issues with /usr/bin/wine script

[Jens Reyer]

control: retitle -1 wine: test if multiarch is enabled fails with multiple 
foreign archs
control: tags -1 + pending

On 02/23/2015 09:38 AM, Erik de Castro Lopo wrote:
> a) On amd64 if fails when there more than one foreign-achitecture
> installed.
[...]
> b) The current script does not seamlessly handle both 32 and 64 bit
> binaries.

b) is also reported in e.g. #769234 (automatically detect and launch
wine32 or wine64). Your patch for it imo is to strict, I've come up
with another version in #769234. I'd suggest that we followup there
for b).

Your proposed patch for a) [1] does not work for people with
kfreebsd-i386 or hurd-i386 but no i386 as foreign-arch. I've committed
a fixed version with "-x" added to match whole lines.


On 04/02/2015 09:24 AM, Erik de Castro Lopo wrote:
> Each time the wine package gets upgraded, I have to manually re-apply
> this patch. It I don't, the tests for the 64 bit Windows build will
> fail.

Do the tests fail if you get any output? Because the code of issue a)
is only output, not an error/exit. Or did I miss something?

Greets
jre


[1] Relevant part from your patch:
-if [ "$(dpkg --print-architecture)" = "amd64" -a "$(dpkg 
--print-foreign-architectures)" != "i386" ]; then
+if [ "$(dpkg --print-architecture)" = "amd64" -a "$(dpkg 
--print-foreign-architectures | grep -c "i386")" -ne 1 ]; then

Bug#769234: Automatically detect wine32 and wine64.

[Jens Reyer]

Hi,

please see below for another patch. IMO it is clean, simple and
matches the logic of the wine-script perfectly.

It tries to detect the correct wine version using the following
precedence:

1. WINEARCH - can't be misinterpreted and was also used
   previously.
2. WINEPREFIX - if it is set and system.reg exists, we have a
   clean indicator if it is a 32-bit or 64-bit installation,
   and therefore which wine to use.
3. WINELOADER - if it is set to a known loader, use this for
   deciding which wine to use.
   The 32-bit loaders seem to work with both wine32 and wine64,
   but I see no point in doing this here. Instead it is easier
   to choose the correct 32-bit or 64-bit wineprefix later if
   wine loader and binary match.
   Note that I'm not really familiar with the preloader.
4. Test with "file" if $1 is a 64-bit application. Note that some
   64-bit applications have PE32 installers, or install single
   PE32 executables. But those also seem to work with wine64 as
   long as wine32 is installed. Therefore only testing for PE32+.

Additionally to the posted patch, we'd need to depend on "file".

It seems to work perfectly, except for one case which can't be solved
here:

64-bit applications with PE32 installers still require manual
intervention (e.g. export WINEARCH=win64) to install correctly. Then
they will work automatically afterwards.
Without manual intervention they are installed in a 32-bit prefix.
Desktop launchers are broken then. Starting a 64-bit app directly will
work, but will be running in a 64-bit prefix despite of being installed
in a 32-bit prefix.
Without these changes they will be installed in a 32-bit prefix, but
then fail to work.
So this patch may obfuscate the need for manual intervention.

However one may use WoW64 (#762058) together with this patch.

What do you think?

Greets
jre


===
diff --git a/debian/scripts/wine b/debian/scripts/wine
index eb929a9..a1463c9 100755
--- a/debian/scripts/wine
+++ b/debian/scripts/wine
@@ -6,6 +6,32 @@ bindir=/usr/lib/$name
 wine32=$bindir/wine
 wine64=$bindir/wine64
 
+if test -n "$WINEARCH"; then
+true
+elif [ -n "$WINEPREFIX" ] &&
+ [ -e "${WINEPREFIX}/system.reg" ] &&
+ grep -q "^\#arch=win32" "${WINEPREFIX}/system.reg"; then
+echo "Setting WINEARCH=win32 because $WINEPREFIX is a 32-bit installation."
+WINEARCH=win32
+elif [ -n "$WINEPREFIX" ] &&
+ [ -e "${WINEPREFIX}/system.reg" ] &&
+ grep -q "^\#arch=win64" "${WINEPREFIX}/system.reg"; then
+echo "Setting WINEARCH=win64 because $WINEPREFIX is a 64-bit installation."
+WINEARCH=win64
+elif [ -n "$WINELOADER" ] &&
+ [ "$(echo $WINELOADER|sed "s|-preloader||;s|wine32|wine|")" = 
"/usr/lib/$name/wine" ]; then
+echo "Setting WINEARCH=win32 because of WINELOADER $WINELOADER."
+WINEARCH=win32
+elif [ -n "$WINELOADER" ] &&
+ [ "$(echo $WINELOADER|sed "s|-preloader||")" = 
"/usr/lib/$name/wine64" ]; then
+echo "Setting WINEARCH=win64 because of WINELOADER $WINELOADER."
+WINEARCH=win64
+elif [ -f "$1" ] &&
+ file -bL "$1"|grep -Eq "PE32+ executable.*x86-64"; then
+echo "Setting WINEARCH=win64 because $1 is a PE32+ executable."
+WINEARCH=win64
+fi
+
 if test -x $wine32 -a "$WINEARCH" != "win64"; then
 wine=$wine32
 elif test -x $wine64; then

Bug#762058: WoW64 (mostly) working

[Jens Reyer]

control: tags -1 + patch

Hi,

to my great surprise our wine binaries already seem to support WoW64,
(maybe only mostly, see below). I.e. installing and running 32-bit
applications in 64-bit prefixes works. Or is there more to it?

Previously I thought that wine64 has to be linked into wine32 during
build. Now I realized that it seems to work as long as wine32 and
wine64 are installed. Also I didn't see anything indicating this in the
ubuntu/winehq packaging, which is WoW64 enabled.

A definitely wrong assumption of mine was that WoW64 has a separate
winearch. But it is "win64".

So I tried the wine script with the patch below. Basically I just switch
the order of wine32 and wine64 in there. The patch works best with the
automatic-detect-patch (#769234), but that is not necessary.
This solves the problem for 64-bit apps with PE32-installers.


SUCCESS:

I successfully installed the following apps in the same 64-bit prefix. I
started them (using the Desktop launcher if available) concurrently with
the same wineserver. It all happened in ~/.wine64, no ~/.wine was
created.:
- Daggerfall (16-bit, dosbox is installed)
- SteuerSparErklärung (32-bit)
- Steam (32-bit) [2]
- 7z (64-bit, msi installer)
- ImageMagick (64-bit version with a PE32-installer)

[1] App and Launcher fail to start, but this issue also exists with the
official winehq packages.
[2] Starts, but can't login, same with winehq packages.


CAVEATS:

However installing EA's Origin (32-bit) failed, while this works with
the winehq packages. I don't know if this is WoW64 related.

winetricks, without a WINEPREFIX specified, starts correctly in 64-bit
mode, but creates ~/.wine, instead of ~/.wine64. Note that generally the
64-bit mode of winetricks isn't perfect yet.

Greets
jre


===
diff --git a/debian/scripts/wine b/debian/scripts/wine
index a1463c9..3bf4117 100755
--- a/debian/scripts/wine
+++ b/debian/scripts/wine
@@ -32,15 +32,15 @@ elif [ -f "$1" ] &&
 WINEARCH=win64
 fi
 
-if test -x $wine32 -a "$WINEARCH" != "win64"; then
-wine=$wine32
-elif test -x $wine64; then
+if test -x $wine64 -a "$WINEARCH" != "win32"; then
 wine=$wine64
-if [ "$(dpkg --print-architecture)" = "amd64" -a "$(dpkg 
--print-foreign-architectures | grep -cx "i386")" -ne 1 ]; then
+if [ ! -x "$wine32" -a "$(dpkg --print-architecture)" = "amd64" -a "$(dpkg 
--print-foreign-architectures | grep -cx "i386")" -ne 1 ]; then
 echo "it looks like multiarch needs to be enabled.  as root, please"
 echo "execute \"dpkg --add-architecture i386 && apt-get update &&"
 echo "apt-get install $(echo $name | sed s/wine/wine32/)\""
 fi
+elif test -x $wine32 -a "$WINEARCH" != "win64"; then
+wine=$wine32
 else
 echo "error: unable to find wine executable.  this shouldn't happen."
 exit 1

Bug#806206: [pkg-wine-party] Bug#806206: Bug#806206: wine don't install programs from CD

[Jens Reyer]

On 11/26/2015 08:24 AM, Heiko Ernst wrote:
> Am Mittwoch, 25. November 2015, 10:28:28 schrieb Austin English:
>> Do you have the cd/dvd mounted? Is it in dosdevices? Is there a
>> symlink to the raw device in dosdevices? Are you attempting to start
>> the installer with the full path (e.g., wine "D:\\setup.exe")?
> 
> I have mounted the dvd on kde 5 and start with wine "D:\\setup.exe". The 
> installe start and show an undefined error on kde.

And what happens if you try it directly from the CD, e.g. if it was
mounted to /mount/user/risen/:
  cd /mount/user/risen/
  wine setup.exe

At least in the past this was recommended. I don't know if Austin
suggested "D:\\setup.exe", or if he saw that as possible error reason.

Greets
jre