Bug#1063466: winetricks: architecture detection mechanism (commit #9ca7a68b) breaks winetricks.desktop

[Jens Reyer]

control: retitle -1 winetricks: architecture detection mechanism (commit 
#9ca7a68b) broken


On 08.02.24 16:02, Alex Volkov wrote:

as the architecture detection mechanism (commit #9ca7a68b) checks $1
argument, it views the "--gui" parameter in the .desktop file as a
filename, which leads to appearance of erroneous messages about
"Unknown file arch" when launching from the applications menu. Not a
big deal, but can be confusing to an unsuspecting user.


Thanks for the report. Turns out there are some other issues causing the
symptoms you reported:

The detection fails because it can't handle wrapper scripts like
Debian's wine and wineserver.  But this goes unnoticed if "--gui"
is not specified, but still leads to the correct outcome on a
common installation (wine32+wine64 in Debian).

"winetricks --gui" just exposes this issue because then winetricks is more
verbose at this moment, while "winetricks" also starts the GUI
but the logic is after the broken architecture detection mechanism.

I'll try to find a solution for this with upstream.

Greets
jre

Bug#1034052: winetricks: winetrick searches for 32 bit wine as wine32, not wine

[Jens Reyer]

control: tags -1 moreinfo

Hi,


On 07.04.23 15:49, Thomas Dorner wrote:

While setting up a new Wine environment winetricks aborted with the
following error:


I can't reproduce this issue.  What steps exactly did you issue that failed?

With the same packages installed I successfully did the following tests:

rm -rf .wine
wineboot
winetricks vcrun2019

rm -rf .wine
winetricks vcrun2019

rm -rf .wine
regedit





it looks like wine32 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:i386"


This is an error message from Wine. Winetricks doesn't look for "wine32".

Please remove the hardlink again and report the output of "wine --version".

You may also reinstall wine (apt purge wine wine32 wine64 && apt install 
wine wine32 wine64) and check again.



Thanks and greets
jre

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

[Jens Reyer]

Hi Paul

On 09.03.23 15:50, Paul Gevers wrote:

Hi,

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



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


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


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



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


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


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


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


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


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


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


Greets
jre

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

[Jens Reyer]

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


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


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

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

[Jens Reyer]

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


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

---

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

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


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


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


Greets
jre

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

[Jens Reyer]

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

Hi Mike,

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


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


Greets anyway!
jre



Winetricks fails with 8.0~repack-4:

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

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

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

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

C:\users\jens\AppData\Roaming




Winetricks works with 8.0~repack-2:

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

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

winetricks GUI enabled, using zenity 3.44.0






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

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

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

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

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

wine recommends no packages.

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

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

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

Bug#1029536: wine64-stable ENOENT

[Jens Reyer]

On 12.02.23 10:53, Junichi Uekawa wrote:


The -stable suffix was added for the Debian alternatives system. While
I don't expect an issue with adding an /usr/lib/wine/wine64-stable
link, I wonder if the whole issue is really a bug (still probably a
regression, which I can't comment on since I'm not involved in current
packaging) or wrong usage.


Somehow /usr/bin/wine-stable has correct files in the right place, so
/usr/bin/wine-stable works


Yes, as soon as "wine" is installed it sets up the Debian alternatives 
system. (Which is used so both the stable and the development Wine 
packages may use /usr/bin/wine and may even be coinstalled.)  I'm glad 
to see that this part works as intended.




/usr/bin/wine64-stable fails because of missing files.
Should /usr/bin/wine64-stable be there at all?


I don't know if we really need /usr/bin/wine64, or could just go with 
/usr/bin/wine and the rest in /usr/lib/wine.  But if we want 
/usr/bin/wine64 then we also need /usr/bin/wine64-stable (for the 
alternatives system).


Currently this is a link to /usr/lib/wine/wine64.  Current maintainers 
may replace it with a wrapper script or provide the link suggested 
previously. (Or figure out why the -stable suffix in the link is now 
expected by the binary, while it wasn't in the past.)


For now, I don't think I can help further, back to retirement

GReets
jre

Bug#1031232: RFS: winetricks/20230212-1 [NMU] [RC] -- simple tool to work around common problems in Wine

[Jens Reyer]

Hi Renato,

as pointed out your packages would need more work to match the Debian 
standards, simply uploading upstream's version is not enough. But I'm 
already working on this version, just need to solve some verification 
issues.


Greets
jre

Bug#1029536: wine64-stable ENOENT

[Jens Reyer]

On 07.02.23 14:22, Bernhard Übelacker wrote:

Dear Maintainer,
if one creates this wine64-stable just as a link to wine64,
then `wine64-stable wineboot` would start to work.

# ln -s wine64 /usr/lib/wine/wine64-stable

Kind regards,
Bernhard


(rr)
692 execv( argv[1], argv + 1 );
(rr) print argv[1]
$2 = 0x7e848400 "/usr/lib/wine/wine64-stable"
(rr) shell ls -lisah /usr/lib/wine/wine64-stable
ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
(rr) bt
#0  preloader_exec (argv=argv@entry=0x7e8483d0) at 
dlls/ntdll/unix/loader.c:692
#1  0x7f5e1d159a6b in loader_exec (machine=34404, argv=0x7e8483d0) 
at dlls/ntdll/unix/loader.c:716
#2  __wine_main (argc=, argv=0x7ffd65438648, 
envp=0x7ffd65438660) at dlls/ntdll/unix/loader.c:2416

#3  0x7d001254 in main ()
(rr)


$ ls -lisah /usr/bin/wine64-stable /usr/bin/wine64 
/usr/lib/wine/wine64-stable /usr/lib/wine/wine64

ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
674145   0 lrwxrwxrwx 1 root root  24 Jan 27 02:36 /usr/bin/wine64 -> 
/etc/alternatives/wine64
673301   0 lrwxrwxrwx 1 root root  18 Jan 27 02:36 
/usr/bin/wine64-stable -> ../lib/wine/wine64

673289 16K -rwxr-xr-x 1 root root 15K Jan 27 02:36 /usr/lib/wine/wine64


[Ex-maintainer here]

The -stable suffix was added for the Debian alternatives system. While I 
don't expect an issue with adding an /usr/lib/wine/wine64-stable link, I 
wonder if the whole issue is really a bug (still probably a regression, 
which I can't comment on since I'm not involved in current packaging) or 
wrong usage.


I don't know what you want to do exactly, but generally I (and afaik 
upstream) recommend to just call "wine", not "wine64". This will default 
to 64-bit anyway (supporting also 32-bit if "wine32" is installed).


To force 64 bit you may set "WINEARCH=win64".

To create a new wineprefix just issue "WINEARCH=win64 wineboot" (without 
"wine" or "wine64" in front).


Of course you need the "wine" package to be installed, which basically 
just contains the relevant wrappers and links. I see no reason to not 
install this recommended package. Comments welcome!


Without "wine" installed you may use
$ /usr/lib/wine/wine64 wineboot

If you install "wine64" and "wine", but not "wine32", you'll get a 
non-critical warning on STDERR:

~
it looks like wine32 is missing, you should install it.
as root, please execute "apt-get install wine32:i386"
~
You can disable this (and some Wine output by something like this:
$ WINEDEBUG="-all" wineboot


So I suggest:

docker run -it docker.io/debian:testing-slim
# apt update && apt install wine
# wineboot

Greets
jre

Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB

[Jens Reyer]

control: found -1 thunderbird/1:91.6.2-1
control: found -1 thunderbird/1:91.7.0-2
Control: tags -1 - moreinfo



Hi Simon and all,


On 27.03.22 14:16, Simon McVittie wrote:
> I think this is a description of the same bug as #948691. If that's
> the case, then it should be fixed by thunderbird versions based on
> 1:91.7.0-2, including the 1:91.7.0-2~deb11u1 and 1:91.7.0-2~deb10u1
> versions in bullseye-security and buster-security. Please check
> whether this is still reproducible.

Unfortunately no, I can still reproduce this:

I
- enabled the default-browser check in firefox,
- updated thunderbird,
- removed ~/.local/share/applications/ and ~/.config/mimeapps.list
Then I
- rebooted the system
- started thunderbird/1:91.7.0-2 and
- clicked a link:

firefox-esr/91.7.0esr-1 asked me about becoming the default browser. I
answered yes and got this mimeapps.list:

~
[Default Applications]
x-scheme-handler/http=thunderbird.desktop
x-scheme-handler/https=thunderbird.desktop
x-scheme-handler/chrome=thunderbird.desktop
text/html=thunderbird.desktop
application/x-extension-htm=thunderbird.desktop
application/x-extension-html=thunderbird.desktop
application/x-extension-shtml=thunderbird.desktop
application/xhtml+xml=thunderbird.desktop
application/x-extension-xhtml=thunderbird.desktop
application/x-extension-xht=thunderbird.desktop

[Added Associations]
x-scheme-handler/http=thunderbird.desktop;
x-scheme-handler/https=thunderbird.desktop;
x-scheme-handler/chrome=thunderbird.desktop;
text/html=thunderbird.desktop;
application/x-extension-htm=thunderbird.desktop;
application/x-extension-html=thunderbird.desktop;
application/x-extension-shtml=thunderbird.desktop;
application/xhtml+xml=thunderbird.desktop;
application/x-extension-xhtml=thunderbird.desktop;
application/x-extension-xht=thunderbird.desktop;
~



Is there anything I missed? Because I agree this should be the same as
#948691.



Huge thanks anyway for working on this and keeping bugs.d.o in good
shape, despite my surprising test results!

Greets
jre

Bug#1003491: winetricks: Please allow co-installation with wine-staging

[Jens Reyer]

On 20.03.22 17:16, Jens Reyer wrote:
>   export WINE=/opt/wine-staging/bin/wineserver
>   export WINESERVER=/opt/wine-staging/bin/wineserver

That should have been:

  export WINE=/opt/wine-staging/bin/wine
  export WINESERVER=/opt/wine-staging/bin/wineserver

Bug#986650: winetricks: move from contrib to main

[Jens Reyer]

On 04.07.21 14:51, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Jens Reyer (2021-07-04 14:36:13)
>> On 08.04.21 22:47, Johannes 'josch' Schauer wrote:
>>> a recent threat on debian-devel [1] revealed that winetricks falls into the
>>> same category as other packages that are happily sitting in main.
>>> Specifically, winetricks not only allows to download non-free software but
>>> also DFSG-free software like dxvk or faudio. As such it is in the same
>>> category as many other packages in main that allow to download both free
>>> and non-free binaries from the internet if the user requests it to do so.
>>>
>>> Since other packages that allow to download and run non-free stuff are
>>> allowed in main I think winetricks can be uploaded to main.
>>>
>>> The advantage would be that this would make it easier for our users to
>>> install winetricks.
>>>
>>> Thanks!
>>>
>>> cheers, josch
>>>
>>> [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot
>>
>> thanks, I agree that winetricks can be moved to "main".  Although the thread
>> was not completely in favor of doing so, I think there was a loose consensus
>> that this is ok.
>>
>> I'm a DM, so I can't upload to NEW which (afair) is required for such a
>> change.  I'd appreciate it if you or some other DD directly took care of
>> that after the freeze (without me preparing this trivial change upload).
>>
>> Since I'm in the process of stepping down as Debian maintainer I generally
>> welcome anyone taking over winetricks maintainership.
> 
> I would upload the package to main/experimental today if you have no
> objections?
> 
> Thanks!
> 
> cheers, josch
> 


Thanks, please go ahead.

If you have access to the git repository please upload your changes also
there, otherwise send a "git am"-able commit per mail.  Or I'll import
your changes later on.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986650: winetricks: move from contrib to main

[Jens Reyer]

On 08.04.21 22:47, Johannes 'josch' Schauer wrote:
> Package: winetricks
> Version: 0.0+20210206-1
> Severity: normal
> 
> Hi,
> 
> a recent threat on debian-devel [1] revealed that winetricks falls into
> the same category as other packages that are happily sitting in main.
> Specifically, winetricks not only allows to download non-free software
> but also DFSG-free software like dxvk or faudio. As such it is in the
> same category as many other packages in main that allow to download both
> free and non-free binaries from the internet if the user requests it to
> do so.
> 
> Since other packages that allow to download and run non-free stuff are
> allowed in main I think winetricks can be uploaded to main.
> 
> The advantage would be that this would make it easier for our users to
> install winetricks.
> 
> Thanks!
> 
> cheers, josch
> 
> [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot

Hi josch,

thanks, I agree that winetricks can be moved to "main".  Although the
thread was not completely in favor of doing so, I think there was a
loose consensus that this is ok.

I'm a DM, so I can't upload to NEW which (afair) is required for such a
change.  I'd appreciate it if you or some other DD directly took care of
that after the freeze (without me preparing this trivial change upload).

Since I'm in the process of stepping down as Debian maintainer I
generally welcome anyone taking over winetricks maintainership.

Greets and sorry for the late answer
jre



OpenPGP_signature
Description: OpenPGP digital signature

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

[Jens Reyer]

Hi

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

[not commenting on the whole issue]

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

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

Greets
jre

Bug#987157: unblock: winetricks/0.0+20210206-2

[Jens Reyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock



Please unblock package winetricks


[ Reason ]
One of the main purposes of Winetricks is to download Windows software
and install them in the users Wine prefix (basically a Windows
installation in the user's home directory).  Downloaded files are
verified against a hardcoded sha256sum.  Since some software still
receive frequent updates some of these hashsums get outdated quite fast.

#986376 is about updating the hashsum of vcrun2019, which is required by
quite many Windows applications to run.

I updated the hashsum to fix this for now.

I also followed upstream suggestion to cherrypick a change which extends
the existing option "--force" to ignore hashsums, in order to give an
easy general longterm workaround for this issue.


[ Impact if the unblock isn't granted ]
Adjusting only the hashsums via stable-updates is not an option due too
the number of changes and the delay until a user may use Winetricks as
expected again.

Without the "--force"-workaround the usability of our winetricks package
will degrade during Bullseye's lifetime.  (Which will still happen to
some lesser degree with this fix because download URLs will change.)


[ Tests ]
Upstream runs an automatic test suite which downloads and installs each
known software.

I manually tested
- 0.0+20210206-1 does not install vcrun2019
- 0.0+20210206-2 installs vcrun2019
- 0.0+20210206-2 with force accepts invalid hashsums.


[ Risks ]
The hashsum update is trivial.

The extension of the "--force" option is
- quite simple (in posix shell)
- in a specific function (no unexpected things expected)
- authored by upstream
- trivially cherrypicked.

Winetricks is a leaf package in contrib.

The best alternative for users is to install Winetricks (one shell
script) from upstream and use their autoupdate instead.
For this they may opt-in directly from the debian package
(sudo winetricks --self-update).


[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing


[ Other info ]
Thanks for your work!

Greets
jre


unblock winetricks/0.0+20210206-2


diff -Nru winetricks-0.0+20210206/debian/changelog 
winetricks-0.0+20210206/debian/changelog
--- winetricks-0.0+20210206/debian/changelog2021-02-07 01:18:11.0 
+0100
+++ winetricks-0.0+20210206/debian/changelog2021-04-13 22:05:56.0 
+0200
@@ -1,3 +1,10 @@
+winetricks (0.0+20210206-2) unstable; urgency=medium
+
+  * Add patch to update vcrun2019 hashes. (Closes: #986376)
+  * Add upstream patch allowing using --force to ignore the sha256sum check.
+
+ -- Jens Reyer   Tue, 13 Apr 2021 22:05:56 +0200
+
 winetricks (0.0+20210206-1) unstable; urgency=medium
 
   * New upstream release 20210206. (Closes: #961205, #981660)
diff -Nru 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
--- 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
1970-01-01 01:00:00.0 +0100
+++ 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
2021-04-13 22:03:58.0 +0200
@@ -0,0 +1,27 @@
+From: Austin English 
+Subject: w_verify_sha256sum: allow using --force to ignore the check 
+Origin: upstream, 
https://github.com/Winetricks/winetricks/commit/fb824722d731cd8dfad6610d6449746e763d81ad
+Bug-Debian: https://bugs.debian.org/986376
+
+
+--- a/src/winetricks
 b/src/winetricks
+@@ -1352,13 +1352,17 @@ w_download_to()
+ ;;
+ esac
+ 
+-if test ! "${WINETRICKS_CONTINUE_DOWNLOAD}" ; then
++if test "${WINETRICKS_FORCE}" != 1; then
+ case ${LANG} in
+ pl*) w_warn "Niezgodność sum kontrolnych dla 
${_W_cache}/${_W_file}, pobieram ponownie" ;;
+ ru*) w_warn "Контрольная сумма файла 
${_W_cache}/${_W_file} не совпадает, попытка повторной загрузки" ;;
+ *) w_warn "Checksum for ${_W_cache}/${_W_file} did 
not match, retrying download" ;;
+ esac
+ mv -f "${_W_cache}/${_W_file}" 
"${_W_cache}/${_W_file}".bak
++else
++w_warn "Checksum for ${_W_cache}/${_W_file} did not 
match, but --force was used, so ignoring and trying anyway."
++checksum_ok=1
++break
+ fi
+ else
+ # file exists, no checksum known, declare success and exit 
loop
diff -Nru winetricks-0.0+20210206/debian/patches/series 
winetricks-0.0+20210206/debian/patches/series
--- winetr

Bug#986376: Please Update HASH values for vcrun2019

[Jens Reyer]

Unfortunately the hashes already changed twice since your report. But
upstream already accepted my PR for the latest change (awesome!).

Uploading this now. I hope the hashes stay stable now for a while. I'll
request an unblock for Debian Bullseye then.

Bug#986376: Please Update HASH values for vcrun2019

[Jens Reyer]

control: severity -1 important

Hi,

thanks for your report.  I'll upload a fix soon.

Since vcrun2019 is a quite important verb I'll try to get the fix in
Debian bullseye.

Greets
jre




On 04.04.21 18:34, Bernhard wrote:
> Package: winetricks
> Version: 0.0+20210206-1
> 
> Dear maintainer,
> 
> The Hash-values for vcrun2019 were changed.
> Installation of vcrun2019 is no more possible.
> 
> The Hash-values were fixed upstream.
> Please have a look at Github:
> 
> https://github.com/Winetricks/winetricks/commit/f503916c7df23d128c534248d91abdfbf331b93d
> 
> Please backport this change in Debian package.
> And, if possible, please backport this change also in Debian 11.
> 
> Thank you in advance.
> 
> Best regards
> Bernhard
> 

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

[Jens Reyer]

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


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

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

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


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

Greets
jre

Bug#980307: wine-development: misses dependencies on dlopen'ed libraries

[Jens Reyer]

Package: wine-development
Version: 5.5-3
Severity: normal


Hi,

since 5.5-3 libwine-development misses the dependencies (Recommends) on
dlopen'ed libraries.  That version (git commit
753fa038bd903b7c5c91b6df08d52409b3eb67ae) had some changes in
debian/rules and introduced a new config2sonames script.

I had no deeper look into this, but assume dropping the "Recommends" was
not intended.  In practice users probably experience issues mainly for
the foreign architecture (i386 needed for 32-bit support), while the
native architecture probably has most dependencies installed anyway.  As
a quick workaround users may co-install the not affected libwine:i386
5.0-4 package.

When I implemented the sonames-mechanism, it added a "Recommends" on
every dlopen'ed library.  Additionally I promoted a few of them
(libfontconfig, libfreetype, libncurses) to "Depends", because they are
critical for the most basic functionality.  These three are still there.


List of missing "Recommends" in wine-development 5.5-9 compared to wine
5.0-4:

libcapi20-3
libcups2 (>= 1.4.0)
libdbus-1-3 (>= 1.9.14)
libgl1
libglu1-mesa | libglu1
libgnutls30 (>= 3.6.5)
libgsm1 (>= 1.0.18)
libgssapi-krb5-2 (>= 1.6.dfsg.2)
libjpeg62-turbo (>= 1.3.1)
libkrb5-3 (>= 1.6.dfsg.2)
libodbc1 (>= 2.3.1)
libosmesa6 (>= 10.2~)
libpng16-16 (>= 1.6.2-1)
libsane (>= 1.0.24)
libsdl2-2.0-0 (>= 2.0.10)
libtiff5 (>= 4.0.3)
libv4l-0 (>= 0.5.0)
libvulkan1 (>= 1.2.131.2)
libxcomposite1 (>= 1:0.4.5)
libxcursor1 (> 1.1.2)
libxfixes3
libxi6
libxinerama1
libxrandr2
libxrender1
libxslt1.1 (>= 1.1.25)
libxxf86vm1

(Most of the above dependencies miss because of this change. Only a few,
e.g. sane, were unfortunately removed from Debian's Wine packaging.)

Greets
jre

Bug#946193: Fix available (Re: Refuses to use profiles from stretch after upgrade to buster 68.2.0esr-1~deb9u2 -> 68.2.0esr-1~deb10u1)

[Jens Reyer]

control: tags -1 +patch


Hi firefox maintainer(s),

Thunderbird was also affected by this, and got fixed in #946588.

In the meantime I successfully used the workaround to remove the
date/timestamp from compatibility.ini.  (It got readded with a new value
the next time I started firefox-esr, so I'm sure it's safe to do so.)

Greets
jre

Bug#940192: wine-development: msi regression, not installing dotnet35sp1

[Jens Reyer]

control: tags -1 + fixed-upstream

Hi

Hans Leidekker wrote https://bugs.winehq.org/show_bug.cgi?id=47724#c22
> This might be fixed by cce9a5f124ae6d3fffcc7772cab6523f09a1e3d1,
please test.

I rebuilt wine-development with upstream merged at
cce9a5f124ae6d3fffcc7772cab6523f09a1e3d1:

"winetricks dotnet35sp1" now worked.  So this will be fixed in 4.20-1.

Please report upstream if this also fixes the
Office 2007 SP3 installer.

Greets
jre

Bug#940203: faudio: Update faudio to latest upstream version

[Jens Reyer]

On 02.11.19 00:55, Alistair Leslie-Hughes wrote:
> Is there any chance you could use version 19.11 that was just release?

Definitely, I'll prepare that upload shortly.
But I still lack the permissions to upload the package (working on it).

Greets
jre

Bug#940203: faudio: Update faudio to latest upstream version

[Jens Reyer]

control: tags -1 pending

Hi

On 13.09.19 23:47, Shmerl wrote:
> Please update faudio to latest upstream version. They normally come out once a
> month,
> so it would be good if they could be packaged in Debian as well.

Thanks!  I'm working on this.  I joined as an uploader and prepared
19.10-1.  Now I just need some permissions to upload it.

Greets
jre

Bug#942731: parcimonie: typos and document autostart

[Jens Reyer]

Package: parcimonie
Version: 0.11.0-1
Severity: minor
Tags: patch

Hi

please see attached patch for fixing some minor typos.
I also added a quick documentation of the XDG autostart.

Thanks for parcimonie.

Greets
jre



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages parcimonie depends on:
ii  dirmngr 2.2.17-3
ii  gnupg   2.2.17-3
ii  libclone-perl   0.41-1+b2
ii  libconfig-general-perl  2.63-1
ii  libfile-homedir-perl1.004-1
ii  libfile-which-perl  1.23-1
ii  libgnupg-interface-perl 0.52-11
ii  libipc-system-simple-perl   1.25-4
ii  liblist-moreutils-perl  0.416-1+b5
ii  libmoo-perl 2.003004-2
ii  libmoox-late-perl   0.015-4
ii  libmoox-options-perl4.103-2
ii  libmoox-strictconstructor-perl  0.010-2
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libtime-duration-parse-perl 0.15-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libtypes-path-tiny-perl 0.006-1
ii  perl5.30.0-7
ii  torsocks2.3.0-2+b1

Versions of packages parcimonie recommends:
ii  libglib-perl3:1.329.1-1+b1
ii  libgtk3-perl0.036-1
ii  liblocale-gettext-perl  1.07-3+b5
ii  libnet-dbus-glib-perl   0.33.0-3+b2
ii  libnet-dbus-perl1.1.0-6+b1
ii  libpango-perl   1.227-3+b2
ii  libtime-duration-perl   1.21-1
ii  tor 0.4.1.6-1

parcimonie suggests no packages.

-- no debconf information
diff --git a/debian/control b/debian/control
index 1a4360f..d44fb1f 100644
--- a/debian/control
+++ b/debian/control
@@ -81,7 +81,7 @@ Description: privacy-friendly helper to refresh a GnuPG 
keyring
  parcimonie is a daemon that slowly refreshes a gpg public keyring
  from a keyserver.
  .
- Its refreshes one OpenPGP key at a time; between every key update,
+ It refreshes one OpenPGP key at a time; between every key update
  parcimonie sleeps a random amount of time, long enough for the
  previously used Tor circuit to expire.
  .
@@ -95,3 +95,6 @@ Description: privacy-friendly helper to refresh a GnuPG 
keyring
  to monitor the background daemon's activities with a graphical
  user interface. It may or may not work for you, depending on
  your desktop environment.
+ .
+ The daemnon and the applet are autostarted by your desktop
+ environment (XDG).
diff --git a/design.mdwn b/design.mdwn
index 0376d43..222886a 100644
--- a/design.mdwn
+++ b/design.mdwn
@@ -70,9 +70,9 @@ Refresh rate
 
 parcimonie sleeps a random amount of time between every key fetch;
 
-- the longest the delay is, the longest it takes for a published key
+- the longer the delay is, the longer it takes for a published key
   update (e.g. revocation certificate) to become locally available
-- the shortest the delay is, the cheaper a correlation attack is
+- the shorter the delay is, the cheaper a correlation attack is
 
 this lapse time is computed in function of the number of public keys
 in the keyring:

Bug#942728: parcimonie: documents obsolete use of gnupg-curl

[Jens Reyer]

Package: parcimonie
Version: 0.11.0-1
Severity: minor

Hi,

README.Debian documents the use of gnupg-curl.  However this package has been
removed from Debian since stretch (oldstable).  AFAIR its completely superseded
by dirmngr in gnupg 2, which parcimonie depends on.  So you could just remove
the whole README.Debian.

Greets
jre



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages parcimonie depends on:
ii  dirmngr 2.2.17-3
ii  gnupg   2.2.17-3
ii  libclone-perl   0.41-1+b2
ii  libconfig-general-perl  2.63-1
ii  libfile-homedir-perl1.004-1
ii  libfile-which-perl  1.23-1
ii  libgnupg-interface-perl 0.52-11
ii  libipc-system-simple-perl   1.25-4
ii  liblist-moreutils-perl  0.416-1+b5
ii  libmoo-perl 2.003004-2
ii  libmoox-late-perl   0.015-4
ii  libmoox-options-perl4.103-2
ii  libmoox-strictconstructor-perl  0.010-2
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libtime-duration-parse-perl 0.15-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libtypes-path-tiny-perl 0.006-1
ii  perl5.30.0-7
ii  torsocks2.3.0-2+b1

Versions of packages parcimonie recommends:
ii  libglib-perl3:1.329.1-1+b1
ii  libgtk3-perl0.036-1
ii  liblocale-gettext-perl  1.07-3+b5
ii  libnet-dbus-glib-perl   0.33.0-3+b2
ii  libnet-dbus-perl1.1.0-6+b1
ii  libpango-perl   1.227-3+b2
ii  libtime-duration-perl   1.21-1
ii  tor 0.4.1.6-1

parcimonie suggests no packages.

-- no debconf information

Bug#941110: /usr/share/doc/git-buildpackage/manual-html/gbp.import.convert.html: wrong git command in documentation

[Jens Reyer]

Package: git-buildpackage
Version: 0.9.15
Severity: minor
File: /usr/share/doc/git-buildpackage/manual-html/gbp.import.convert.html
Tags: patch

Hi Guido

The git command in this paragraph:


Upstream sources on a branch

If the upstream sources are already on a separate branch, things are pretty
simple. You can either rename that branch to the default upstream-branch name
upstream with:

  git branch -m upstream theupstream-branch


should be the other way:
  git branch -m theupstream-branch upstream

Greets
Jens



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

Kernel: Linux 5.2.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.19.6
ii  git1:2.23.0-1
ii  man-db 2.8.7-3
ii  python33.7.3-1
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  41.2.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.88
ii  pbuilder  0.230.4
ii  pristine-tar  1.46
ii  python3-requests  2.21.0-1

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.27-1+b1
ii  unzip6.0-25

-- no debconf information

Bug#940192: wine-development: msi regression, not installing dotnet35sp1

[Jens Reyer]

Hi Allan,

In https://bugs.winehq.org/show_bug.cgi?id=47724#c16 you wrote:
> Adding "--without-mingw" to "configure" fixes this issue.

Up to 4.11-1 (the version that you reported the bug against) the Debian
packages had a build-conflicts against gcc-mingw-w64-i686 and
gcc-mingw-w64-x86-64.  I changed that in 4.12-1 to the configure flag
"--without-mingw".  Both should have the same result.

So I'm confused now.  Did you find the issue in our 4.11-1 Debian
package, or some other Wine build?

Do you still find the issue in the current package (4.14-1, built
--without-mingw)?

Either I missed something, or your finding in the winehq bug is wrong,
or this bug does not exist in Debian for now.

Generally, of course, the underlying issue needs to be fixed upstream.

But if this is indeed a mingw-w64-only issue, then it's good to know so
that we don't change this in debian too early.

Greets
jre

Bug#824192: wine: please add new wine-gecko source package

[Jens Reyer]

Hi

> I was wondering if somebody is working on this

AFAIK noone on wine-gecko (but I'd be happy to be wrong).  For wine-mono
there was some work half a year ago, but I haven't seen any results.


> In the
> past the wine in Debian would at least try to download wine gecko from 
> official
> binary files at winehq.org, and now even that is gone
Downloading from a 3rd party (including upstream) is exactly what we
want to prevent.  Did I miss something, or are you confusing something here?


> I know it is know (and documented in README.Debian.gz), but I couldn't find 
> exact
> details what are the current blockers to build it in Debian using debian
> libraries. Is it because it is somehow forked vesion of Gecko? It is fully
> understandable tho, and can be considered a separate project, as it provides
> completly different functionality than gecko. Is it a security support?
> Or some other reasons?

I guess the main reason is just time, or generally a person who is
willing to work on this.  One of the main blockers in the past afaik was
handling the copyright.

The good news is that upstream recently fixed the build with python3 and
current gcc - so if these were blockers now is a good time to start again.

In the mean time, if you can't help on packaging, the best option
probably is to download the installers manually to your user's
.cache/wine.  Then Wine will check the correct version and checksum of
the installer and install it automatically.  For wine 4.0 this is:

cd ~/.cache/wine
wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86.msi
wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86_64.msi
wget http://dl.winehq.org/wine/wine-mono/4.7.5/wine-mono-4.7.5.msi

Greets
jre

Bug#939087: Please support HOOKDIR config option

[Jens Reyer]

Hi Enrico

> I tried adding this to ~/.pbuilderrc, but it gets ignored:
> 
>   OTHERMIRROR="deb http://incoming.debian.org/debian-buildd buildd-unstable"

Typo? I guess "main" is missing.
Do you "apt update" later?


> So I put this in ~/.pbuilder/hooks/D09incoming:
> 
>   #!/bin/sh
>   echo "deb http://incoming.debian.org/debian-buildd buildd-unstable main" > 
> /etc/apt/sources.list.d/incoming.list
>   apt update
> 
> And it works if I do:
> 
>   sudo cowbuilder build --hookdir ~/.pbuilder/hooks file.dsc
> 
> I tried adding this to ~/.pbuilderrc:
> 
>   HOOKDIR="/home/enrico/.pbuilder/hooks/"
> 
> But it gets ignored (as documented in man cowbuilder) and I still need
> to build with --hookdir.
> 
> Would it be possible to have HOOKDIR honored and not ignored?
> 
> Alternatively, would it be possible to have OTHERMIRROR honored and not
> ignored?

[disclaimer: I'm not the cowbuilder maintainer, and I use it via gbp.]

Not sure, what you refer to in man cowbuilder.

Anyway, this works for me:
(note: BINDMOUNTS is needed for the local repository.  All variables are
set up so that you can set them multiple times and their values get
concatenated, no specific syntax needed besides that):



$ cat ~/.pbuilderrc
OTHERMIRROR="${OTHERMIRROR}${OTHERMIRROR:+|}deb [trusted=yes]
file:///home/jens/development/wine/REPO ./"

BINDMOUNTS="$BINDMOUNTS /home/jens/development/wine/REPO"

# execute D05deps with "apt update"
HOOKDIR="/home/jens/development/wine/pbuilder.hooks"

EXTRAPACKAGES="$EXTRAPACKAGES apt-utils"



$ cat /home/jens/development/wine/pbuilder.hooks/D05deps
#!/bin/sh
set -e
apt update



Greets
jre

Bug#934985: libusrsctp: please mark shared libraries and development packages as "Multi-Arch: same"

[Jens Reyer]

Source: libusrsctp
Version: 0.9.3.0+20190127-2
Tags: patch
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch


Hi

Please find attached a patch to mark the library and development
packages in libusrsctp as "Multi-Arch: same".

I rebuilt your package with my proposed patch applied and successfully
co-installed all packages from amd64 and i386.



Background:

Wine requires gstreamer1.0-plugins-bad to play some media.  To support
both 32-bit and 64-bit Windows executables Wine needs to be installed on
two architectures, usually amd64 being the host arch and i386 the
foreign arch.  Both Wine versions need their libraries from the same
arch, so gstreamer1.0-plugins-bad:amd64 and
gstreamer1.0-plugins-bad:i386 need to be co-installed.

gstreamer1.0-plugins-bad itself supports this, but some of its
dependencies not.  From src:libusrsctp this is libusrsctp1.


Generally the multi-arch hinter at https://tracker.debian.org/libusrsctp
currently reports:

There are issues with the multiarch metadata for this package.

libusrsctp-dev could be marked Multi-Arch: same
libusrsctp1 could be marked Multi-Arch: same


Thanks and greets
jre
>From c786b4727f3345e671e9d32d36f1a01c0c9c7a22 Mon Sep 17 00:00:00 2001
From: Jens Reyer 
Date: Sat, 17 Aug 2019 17:27:58 +0200
Subject: Mark shared libraries and development packages as "Multi-Arch: same"

This adds the "Multi-Arch: same" header to the following packages:
  libusrsctp1
  libusrsctp-dev

diff --git a/debian/control b/debian/control
index 12b6943..8f80741 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Rules-Requires-Root: no
 Package: libusrsctp1
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
@@ -35,6 +36,7 @@ Description: portable SCTP userland stack - shared library
 Package: libusrsctp-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends:
  libusrsctp1 (= ${binary:Version}),
  ${misc:Depends},

Bug#934984: mjpegtools: please mark shared libraries and development packages as "Multi-Arch: same"

[Jens Reyer]

Source: mjpegtools
Version: 1:2.1.0+debian-5
Tags: patch
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch


Hi

Please find attached a patch to mark the library and development
packages in mjpegtools as "Multi-Arch: same".

I rebuilt your package with my proposed patch applied and successfully
co-installed all packages from amd64 and i386.



Background:

Wine requires gstreamer1.0-plugins-bad to play some media.  To support
both 32-bit and 64-bit Windows executables Wine needs to be installed on
two architectures, usually amd64 being the host arch and i386 the
foreign arch.  Both Wine versions need their libraries from the same
arch, so gstreamer1.0-plugins-bad:amd64 and
gstreamer1.0-plugins-bad:i386 need to be co-installed.

gstreamer1.0-plugins-bad itself supports this, but some of its
dependencies not.  From src:mjpegtools these are:

  libmjpegutils-2.1-0
  libmpeg2encpp-2.1-0
  libmplex2-2.1-0


Generally the multi-arch hinter at https://tracker.debian.org/mjpegtools
currently reports:

There are issues with the multiarch metadata for this package.

  liblavfile-2.1-0 could be marked Multi-Arch: same
  liblavjpeg-2.1-0 could be marked Multi-Arch: same
  liblavplay-2.1-0 could be marked Multi-Arch: same
  libmjpegtools-dev could be marked Multi-Arch: same
  libmjpegutils-2.1-0 could be marked Multi-Arch: same
  libmpeg2encpp-2.1-0 could be marked Multi-Arch: same
  libmplex2-2.1-0 could be marked Multi-Arch: same

Thanks and greets
jre
>From 09bc71493bff42010f143a009b7d5f147ea04f1c Mon Sep 17 00:00:00 2001
From: Jens Reyer 
Date: Sat, 17 Aug 2019 16:56:07 +0200
Subject: Mark shared libraries and development packages as "Multi-Arch: same"

This adds the "Multi-Arch: same" header to the following packages:

  liblavfile-2.1-0
  liblavjpeg-2.1-0
  liblavplay-2.1-0
  libmjpegtools-dev
  libmjpegutils-2.1-0
  libmpeg2encpp-2.1-0
  libmplex2-2.1-0

diff --git a/debian/control b/debian/control
index a84a973..4953fd8 100644
--- a/debian/control
+++ b/debian/control
@@ -48,6 +48,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (GTK+ fronte
 
 Package: libmjpegtools-dev
 Section: libdevel
+Multi-Arch: same
 Architecture: any
 Depends:
  liblavfile-2.1-0 (= ${binary:Version}),
@@ -67,6 +68,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (development
 Package: liblavfile-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
@@ -80,6 +82,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (library)
 Package: liblavjpeg-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
@@ -93,6 +96,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (library)
 Package: liblavplay-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
@@ -106,6 +110,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (library)
 Package: libmjpegutils-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
@@ -119,6 +124,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (library)
 Package: libmpeg2encpp-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}
@@ -132,6 +138,7 @@ Description: MJPEG capture/editing/replay and MPEG encoding toolset (library)
 Package: libmplex2-2.1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends}

Bug#934909: debmake-doc: "binNMU safe" should use Use source:Version instead of source:Upstream-Version

[Jens Reyer]

Package: debmake-doc
Version: 1.14-1
Severity: normal

Hi

in "5.5.3. binNMU safe" there's:


The dependency defined in the debian/control file among binary packages
from the same source package should be safe for the binNMU. This needs
attention if there are both “Architecture: any” and “Architecture: all”
packages involved in it.
[...]
“Architecture: all” package: depends on “Architecture: any” baz package

  Depends: baz (>= ${source:Version}), baz (<<
${source:Upstream-Version}.0~)


Instead of restricting this by the next upstream version, the next
debian revision version should be used:

Depends: baz (>= ${source:Version}), baz (<< ${source:Version}.1~)



Explanation:

Consider an arch:all package foo 1.0-1 which depends on baz as above.

The restriction "baz (<< ${source:Upstream-Version}.0~)" would resolve
to "baz << 1.0.0~".  This correctly includes versions from binNMUs
(1.0-1+b1).

But it also includes new debian revisions like 1.0-2 or 1.0-1.1 (NMU),
which might have changes which require foo and baz to be both updated at
the same time (foo 1.0-1 does not work with baz 1.0-1.1).  So these
versions should be excluded.

My proposal would set the restriction to "baz << 1.0-1.1~".  I
found that suggested in several places a few years ago, when I had a
deep look into this topic for packaging wine.



Some data:

Roughly looking at codesearch for the pattern in debian/control:

* (<< ${source:Upstream-Version}.0~) : 19 results
https://codesearch.debian.net/search?q=%28%3C%3C+%24%7Bsource%3AUpstream-
Version%7D.0%7E%29+path%3Adebian%2Fcontrol=1

* (<< ${source:Version}.1~): 233 results
https://codesearch.debian.net/search?q=%28%3C%3C+%24%7Bsource%3AVersion%7D.1%7E%29+path%3Adebian%2Fcontrol=1


* AFAICT you might also use the slightly stricter
"${source:Version}.0~", but it seems noone else does because NMUs should
start at ".1": 0 results
https://codesearch.debian.net/search?q=%28%3C%3C+%24%7Bsource%3AVersion%7D.0%7E%29+path%3Adebian%2Fcontrol=1


Greets and thanks
jre




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debmake-doc depends on no packages.

Versions of packages debmake-doc recommends:
ii  debmake  4.3.1-1

Versions of packages debmake-doc suggests:
ii  debian-policy 4.4.0.1
ii  developers-reference  3.4.26

-- no debconf information

Bug#932201: wine64 should also look for /usr/lib/wine/wineserver64 if WINESERVER is not set

[Jens Reyer]

control: tags -1 pending

On 04.08.19 01:04, Jens Reyer wrote:
> Gving it another thought:  just install wine and call /usr/bin/wine64
> (not wine).  This doesn't cause the warning about wine32 afaict.  So
> problem solved for you!?

Turned out this isn't true: on updating the wineprefix you still get the
warning.

Anyway, I finally got it working by moving our wineserver script to libwine:


commit 06f7608ee4b21bc0ac44ad876bbd144bdae039a1
Author: Jens Reyer 
Date:   Fri Aug 2 13:37:55 2019 +0200

Move the wineserver script from wine to libwine.

Closes: #932201

This ensures that Wine always finds its wineserver in its bindir.
Otherwise if wine was not installed it might fail to find it, or
fall back to another wineserver in e.g. PATH.

wine{32,64} would be better suited, but dpkg only accepts multiple
packages as owner of a file for "Multi-Arch: same" packages.

diff --git a/debian/control.in b/debian/control.in
index 6ff2203ade..188163060c 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -247,6 +247,12 @@ Suggests:
  ttf-mscorefonts-installer,
 Pre-Depends:
  ${misc:Pre-Depends},
+Breaks:
+ wine32 (<< 4.0.1-1~),
+ wine64 (<< 4.0.1-1~),
+Replaces:
+ wine32 (<< 4.0.1-1~),
+ wine64 (<< 4.0.1-1~),
 Description: Windows API implementation - library
  Wine is a free MS-Windows API implementation.
  This is still a work in progress and many applications may still not work.
diff --git a/debian/libwineVERSION.install b/debian/libwineVERSION.install
index e1785f603e..2295e336e2 100644
--- a/debian/libwineVERSION.install
+++ b/debian/libwineVERSION.install
@@ -3,3 +3,5 @@ debian/tmp/usr/lib/*/*/fakedlls
 debian/tmp/usr/lib/*/*/libwine.so.*

 debian/tmp/usr/share/*/wine/*.*
+
+debian/tmp/wineserver usr/lib/wineVERSION
diff --git a/debian/rules b/debian/rules
index e1bce028b9..9fb4f78033 100755
--- a/debian/rules
+++ b/debian/rules
@@ -170,8 +170,6 @@ override_dh_auto_install-indep: $(INSTALLS)
mkdir -p debian/tmp
cp ANNOUNCE debian/tmp/NEWS
cp programs/winedbg/README debian/tmp/README.winedbg
-   sed "s|BINDIR|$(BINDIR)|g" debian/scripts/wineserver.in >
debian/tmp/wineserver
-   chmod 755 debian/tmp/wineserver
sed "s|DEBSUFFIX|$(DEBSUFFIX)|g" debian/scripts/wineapploader.in >
debian/tmp/wineapploader
chmod 755 debian/tmp/wineapploader
sed "s|BINDIR|$(BINDIR)|g;s|VERSION|$(VERSION)|g"
debian/scripts/wine.in > debian/tmp/wine$(DEBSUFFIX)
@@ -195,6 +193,8 @@ override_dh_auto_install-arch: $(INSTALLS)
cp tools/winedump/README debian/tmp/README.winedump
cp server/wineserver debian/tmp/wineserver$(DEB_BUILD_ARCH_BITS)
sed "s|BINDIR|$(BINDIR)|g" debian/scripts/winegcc.in >
debian/tmp/winegcc$(DEBSUFFIX)
+   sed "s|BINDIR|$(BINDIR)|g;s|VERSION|$(VERSION)|g"
debian/scripts/wineserver.in > debian/tmp/wineserver
+   chmod 755 debian/tmp/wineserver
dh_auto_install
for file in $$(find . ! -path "./debian/*" -name \*.man); do \
rename=$$(basename $$file | sed
"s/\\./$(DEBSUFFIX)./;s/UTF-8\\.//"); \
diff --git a/debian/scripts/wineserver.in b/debian/scripts/wineserver.in
index f105fcf474..b420ea6569 100644
--- a/debian/scripts/wineserver.in
+++ b/debian/scripts/wineserver.in
@@ -8,7 +8,8 @@ if test -x "$wineserver64"; then
 elif test -x "$wineserver32"; then
 wineserver=$wineserver32
 else
-echo "error: unable to find wineserver executable.  this shouldn't
happen." >&2
+echo "error: unable to find wineserver executable." >&2
+echo "wine32VERSION and/or wine64VERSION must be installed." >&2
 exit 1
 fi

diff --git a/debian/wineVERSION.install b/debian/wineVERSION.install
index 482568c1c6..ca605f8857 100644
--- a/debian/wineVERSION.install
+++ b/debian/wineVERSION.install
@@ -1,5 +1,4 @@
 debian/tmp/wineDEBSUFFIX usr/bin
-debian/tmp/wineserver usr/lib/wineVERSION
 debian/tmp/wineapploader usr/lib/wineVERSION
 debian/tmp/wineDEBSUFFIX.svg usr/share/icons/hicolor/scalable/apps/

Bug#932201: wine64 should also look for /usr/lib/wine/wineserver64 if WINESERVER is not set

[Jens Reyer]

Hi dkg

On 02.08.19 18:00, Jens Reyer wrote:
> On 16.07.19 16:48, Daniel Kahn Gillmor wrote:
>>  So if you see a better way around this, so that i can use
>>   wine in autopkgtest more easily, please don't hesitate to suggest
>>   it)

Gving it another thought:  just install wine and call /usr/bin/wine64
(not wine).  This doesn't cause the warning about wine32 afaict.  So
problem solved for you!?

Greets
jre

Bug#932201: wine64 should also look for /usr/lib/wine/wineserver64 if WINESERVER is not set

[Jens Reyer]

Hi dkg and wine-team,

On 16.07.19 16:48, Daniel Kahn Gillmor wrote:
> wine64(1) says:
> 
> WINESERVER
>   Specifies  the  path  and  name of the wineserver binary. If not
>   set, Wine will try to load /usr/lib/wine/wineserver, and if this
>   doesn't exist it will then look for a file named "wineserver" in
>   the path and in a few other likely locations.
> 
> But wine64 only ships with /usr/lib/wine/wineserver64.

Yes.

I'm working on a solution.  Feel free to stop reading here, following
are my thoughts on how to best solve this.


In Debian we rename the wineserver binary to wineserver32 and
wineserver64 to get the multiarch working. You only need one wineserver.
For multiarch Wine wineserver64 is used for all Wine prefixes (32-bit
and 64-bit). /usr/lib/wine/wineserver is our script to get this working.

I'm now trying to move this script to wine32 and wine64, so that these
two packages "share" this script.  I got an installable version just
now, but that has issues at least on uninstalling...

Maybe I also find a way to merge pkg:wine32 and pkg:wine64 in pkg:wine
(making the latter arch specific instead of arch:all).  But that would
be a major change in our packaging.  While I don't like a major change
here, I see a potential for a slight improvement of our packaging beyond
your report (if it is possible, the current status is really good).


> I'm finding that i need to set WINESERVER=/usr/lib/wine/wineserver64
> in libgpg-error's debian/tests/windows (an autopkgtest where we ensure
> that we can build a static windows executable against libgpg-error on
> debian), otherwise i get "could not exec wineserver".

Correct solution for now.


> It seems like wine64 should be smart enough to try
> /usr/lib/wine/wineserver64.
>
>  (aside about the overall problem space of using wine in autopkgtest:
>   i think if i installed the "wine" package, and then just invoked
>   /usr/bin/wine directly, instead of wine64, it would work correctly
>   for me,

Indeed, usually that would be the correct solution.  That's why I
(usually) tell people to just "apt install wine", which pulls in wine64.


>   but the problem with that is that "wine" sends a warning to
>   stderr about wanting wine32 installed upon every invocation, which
>   isn't possible on a non-multiarch system (and all the continuous
>   integration systems i've used thus far are non-multiarch).  And
>   messages to stderr are indicators to autopkgtest that the test is a
>   failure.  I could suppress the warning by setting WINEDEBUG=-all,
>   but i *don't* want to suppress any other warnings that wine might
>   produce.

This warning is from a Debian script, so you can't suppress it by
WINEDEBUG=-all.  We could invent our own variable to silence
/usr/bin/wine here.  But if you have to set a variable anyway, you can
just set WINESERVER as described above.  So not much to be gained this way.


>  So if you see a better way around this, so that i can use
>   wine in autopkgtest more easily, please don't hesitate to suggest
>   it)

My least favorite solution would be to patch the upstream source.

Greets!
jre

Bug#930650: khronos-api FTBFS

[Jens Reyer]

control: reassign -1 libpython3.5-minimal 3.5.3-1+deb9u1

@doko: reassigning, only affects stretch, but might be rc. See below.


Hi Olivier

thanks for your feedback!

> trying to rebuild khronos-api (version from backport) with pbuilder on a
> Debian Stretch, it fails with:

I just successfully rebuilt khronos-api_4.6+git20180514-1~bpo9+1 with
gbp in a clean stretch (+backports) environment.

But the same fails if I add the letter "Ă" to d/changelog.  I assume you
have some unicode/non-ascii letter entry there!?

Similar to you I get:

[...]
  File "/usr/lib/python3/dist-packages/debian/changelog.py", line 308,
in parse_changelog
for line in file:
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 75:
ordinal not in range(128)
[...]

I get "0xc4" while you got "0xc3" - I probably copy the wrong
character from my websearch.

Anyway, there's some issue with decoding unicode characters - I assume
/usr/lib/python3.5/encodings/ascii.py in package libpython3.5-minimal
needs to be fixed.  Reassigning to this package.

I'm not sure about the severity, might be rc if other packages are affected.

Luckily, the same build succeeds in a clean sid environment with
libpython3.7-minimal 3.7.3-2.

Greets
jre

Bug#926118: Alternative for unblock: libmspack/0.10.1-1

[Jens Reyer]

On 06.06.19 22:24, Jens Reyer wrote:
> The referenced ChangeLog was:
[...]
I missed a second entry:> chmd_read_headers(): a CHM file name beginning
"::" but shorter
> than 33 bytes will lead to reading past the freshly-allocated
> name buffer - checks for specific control filenames didn't take
> length into account. Thanks to ADLab of Venustech for the report
> and proof of concept.

Bug#926118: Alternative for unblock: libmspack/0.10.1-1

[Jens Reyer]

Hi all,

first off, many thanks for your efforts here, Paul!


On 06.06.19 15:54, Paul Gevers wrote:
> On 06-06-2019 04:23, Marc Dequènes (duck) wrote:
>> I'm not committing to this plan for the above stated reasons. I also
>> feels uncomfortable uploading with a know security problem, so unless
>> upstream or our security team says it's low risk, I'm not taking such
>> responsibility.
>
> Sorry, I am mising something here. Can you please point me to it again?


AFAICT duck had this in his original unblock request:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923885#5:
> Please unblock package libmspack. 0.9.1-1 should have made it
> but somehow the build failed on big-endian systems (see #914794),
> maybe gcc changes in the meanwhile; anyway upstream kindly fixed
> it but it took some time.
>
> 0.10.1 is a maintenance release with only few fixes, among which
> fixing chmd_read_headers() closed a security problem (see upstream
> ChangeLog in debdiff). There is also a simple one-liner fix for
> the doc (compared to 0.9.1-1, which had ample time to be tested).
> I would also note that 0.9.1-1 fixed a regression (see #912687).
> Thus I believe 0.10.1-1 is a much better fit for release and hope
> you would conclude the same.


The referenced ChangeLog was:

2019-02-18  Stuart Caie :
> chmd_read_headers(): CHM files can declare their chunks are any
> size up to 4GB, and libmspack will attempt to allocate that to
> read the file.
>
> This is not a security issue; libmspack doesn't promise how
> much memory it'll use to unpack files. You can set your own
> limits by returning NULL in a custom mspack_system.alloc()
> implementation.
>
> However, it would be good to validate chunk size further. With
> no offical specification, only empirical data is available. All
> files created by hhc.exe have a chunk size of 4096 bytes, and
> this is matched by all the files I've found in the wild, except
> for one which has a chunk size of 8192 bytes, which was created
> by someone developing a CHM file creator 15 years ago, and they
> appear to have abandoned it, so it seems 4096 is a de-facto
> standard.
>
> I've changed the "chunk size is not a power of two" warning to
> "chunk size is not 4096", and now only allow chunk sizes between
> 22 and 8192 bytes. If you have CHM files with a larger chunk
> size, please send them to me and I'll increase this upper limit.
>
> Thanks to ADLab of Venustech for the report.



On 06.06.19 15:54, Paul Gevers wrote:
> On 06-06-2019 04:23, Marc Dequènes (duck) wrote:
>> On 2019-06-04 03:53, Paul Gevers wrote:
>> Currently the current version has been sitting in unstable for three
>> months without any single bug reported, this feels like a good progress
>> towards saying this version is safe.
>
> It's a valid argument for sure.

And the previous 0.9.1-1 is even 7 months old now, having been blocked
only by the big endian issue.  Personally I doubt an in-depth code
review is really helpful here.  Anyway, I'm attaching 2 new debdiffs:

Upstream did a "tab to spaces".  A "debdiff --ignore-space" reduces the
diff from 11176 to 4819 lines.  I think this is also a point for
0.10.1-1 in buster, because it will make eventual security updates easier.

I further removed the diff of generated, examples and test files (I
marked those files in the diffstat).  Yay, the diff had 678 lines
improving the tests!

I did this both for each 0.8-1 (in the archive since 2018-10-24) and
0.9.1-1 (2018-11-06) compared to 0.10.1-1 (2019-03-05).

So if at all, I'd suggest to only have a look at the last one of these
diffs:

$ wc -l debdiff_libmspack_0.*
 11176 debdiff_libmspack_0.8-1_0.10.1-1.diff
  4819 debdiff_libmspack_0.8-1_0.10.1-1_ignore-space.diff
  1724 debdiff_libmspack_0.8-1_0.10.1-1_ignore-space_edited.diff
  1067 debdiff_libmspack_0.9.1-1_0.10.1-1_ignore-space.diff
   731 debdiff_libmspack_0.9.1-1_0.10.1-1_ignore-space_edited.diff

Thanks again and greets
jre
diffstat for libmspack-0.8 libmspack-0.10.1

 ChangeLog   |  107 +
 Makefile.am |   66 
-Makefile.in |  737 +++---
 README  |   17 
 acinclude.m4|   12 
 config.h.in |   27 
-configure   |  402 +++--
 configure.ac|   20 
 debian/changelog|   18 
 debian/control  |2 
 debian/copyright|2 
 debian/libmspack-doc.docs   |   12 
 debian/rules

Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

control: affects -1 + winetricks cabextract libmspack

Hi,

please find attached a targeted fix for #912687 (libmspack0: Regression
when extracting cabinets using -F option fixed upstream, needs to be
patched).  In my (winetricks maintainer) opinion that is the most
pressing issue with libmspack/buster.

I'm posting this now because I'm really worried about the lack of
progress with this issue.  However as stated before by me in this bug
here, and by the libmspack maintainer in #923885, we both think that
0.10.1-1 is for various reasons better, and better tested and thus risk
free.

About this alternative version here:

+libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert back to libmspack/0.8-1.
+  * Add build-dependency on quilt.
+  * Add patch from upstream to fix regression when extracting cabinets
+using -F option (Closes: #912687).
+
+ -- Jens Reyer   Sat, 01 Jun 2019 14:32:06 +0200
+


1.) Versioning and targeted suite

This proposal reverts the upstream version back from 0.10 (unstable) to
0.8 (testing), therefore the "new" upstream version 0.10.1+really0.8.
For building I just symlinked the 0.8 orig.tar.

It's based directly on 0.8-1, dropping all debian/ changes (including
the changelog) since then.

So this version should be fine to go via unstable (not sure about the
reverted d/changelog)).

Alternatively we could go via testing-proposed.


2.) Code

I took only the "fix" part from the upstream commit fixing this, but not
the documentation or updated testsuite (which includes changed binaries).

I verified that the issue affecting winetricks is solved.

I assume a fix for #914794 (libmspack fails tests on big endian
architectures (s390x, mips)), reported against 0.9.1-1 is not necessary.
 However if that was caused by a change in the toolchain instead of
changes in the package, I'll also add that fix here.




I'm looking forward to get some feedback from the release team,
preferably by:

unblock libmspack/0.10.1-1

Otherwise please tell us if we should go with this version (targeting
unstable or testing-proposed?), or something else (e.g. filing bugs for
every issue fixed in 0.10.1-1)

Before (if at all) doing any upload I'll of course coordinate it with
the libmspack maintainer.

Greets
jre

diff -Nru libmspack-0.8/debian/changelog libmspack-0.10.1+really0.8/debian/changelog
--- libmspack-0.8/debian/changelog	2018-10-24 03:03:13.0 +0200
+++ libmspack-0.10.1+really0.8/debian/changelog	2019-06-01 14:32:06.0 +0200
@@ -1,3 +1,13 @@
+libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert back to libmspack/0.8-1.
+  * Add build-dependency on quilt.
+  * Add patch from upstream to fix regression when extracting cabinets
+using -F option (Closes: #912687).
+
+ -- Jens Reyer   Sat, 01 Jun 2019 14:32:06 +0200
+
 libmspack (0.8-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru libmspack-0.8/debian/control libmspack-0.10.1+really0.8/debian/control
--- libmspack-0.8/debian/control	2018-04-12 12:20:00.0 +0200
+++ libmspack-0.10.1+really0.8/debian/control	2019-06-01 14:32:06.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Marc Dequènes (Duck) 
 Standards-Version: 4.1.4
 Build-Depends: dpkg-dev (>= 1.16.1.1), debhelper (>= 11)
-Build-Depends-indep: doxygen, graphviz
+Build-Depends-indep: doxygen, graphviz, quilt
 Vcs-Browser: https://salsa.debian.org/debian/libmspack
 Vcs-Git: https://salsa.debian.org/debian/libmspack.git
 Homepage: https://www.cabextract.org.uk/libmspack/
diff -Nru libmspack-0.8/debian/patches/fix-cabd_extract.patch libmspack-0.10.1+really0.8/debian/patches/fix-cabd_extract.patch
--- libmspack-0.8/debian/patches/fix-cabd_extract.patch	1970-01-01 01:00:00.0 +0100
+++ libmspack-0.10.1+really0.8/debian/patches/fix-cabd_extract.patch	2019-06-01 14:32:06.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix regression when extracting cabinets using -F option
+Origin: upstream, https://github.com/kyz/libmspack/commit/2d86d4e70026cd03730ce0b00b12579c2e21620a
+Bug: https://github.com/kyz/libmspack/issues/22
+Bug-Debian: https://bugs.debian.org/912687
+
+--- a/mspack/cabd.c
 b/mspack/cabd.c
+@@ -1125,11 +1125,9 @@ static int cabd_extract(struct mscab_dec
+  *   and pass back MSPACK_ERR_READ
+  */
+ self->d->outfh = NULL;
+-if ((self->d->comp_type & cffoldCOMPTYPE_MASK) != cffoldCOMPTYPE_LZX) {
+-  if ((bytes = file->offset - self->d->offset)) {
+-  error = self->d->decompress(self->d->state, bytes);
+-  self->error = (error == MSPACK_ERR_READ) ? self->read_error : error;
+-  }
++if ((bytes = file->offset - self->d->offset)) {
++error = self->d->decompress(self->d->state, bytes);
++self->error = (error == MSPACK_ERR_READ) ? self->read_error : error;
+ }
+ 
+ /* if getting to the correct offs

Bug#928014: binNMU: rebuild wine-development against unicode-data 12.1.0~pre1-2

[Jens Reyer]

control: retitle -1 binNMU: please rebuild wine-development against 
unicode-data 12.1.0~pre1-2
control: reassign -1 release.debian.org

Hi,

On 11.05.19 20:25, Paul Gevers wrote:
> Hi Jens,
> 
> On 09-05-2019 22:54, Jens Reyer wrote:
> 
> [...]
> 
>> The files built with unicode-data are in arch-specific packages, so a
>> binnmu should work.

FTR fonts-wine (arch all) contains affected build results, but is only
built by src:wine, not src:wine-development.  All other arch all
packages in src:wine-development are definitely not affected.

> [...]
> 
>> So what do you think, binnmu or new source upload?
> 
> Than I have a preference for binNMU (this could be my first binNMU as well).

Thanks Paul.
Reassigning to the release team then, please binNMU and unblock:

nmu wine-development_4.2-4 . ANY . unstable . -m "rebuild against unicode-data 
12.1.0~pre1-2"

Greets
jre

Bug#928014: nmu: wine-development_4.2-4

[Jens Reyer]

Hi Paul, hi wine-team

On 09.05.19 12:26, Paul Gevers wrote:
> retitle 928014 please rebuild against unicode-data 12.1.0~pre1-2
> reassign 928014 wine-development
> usertag 928014 unicode-data-12
> thanks
> 
> On Fri, 26 Apr 2019 10:23:17 +0100 Alastair McKinstry
>  wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> nmu wine-development_4.2-4 . ANY . unstable . -m "rebuild against 
>> unicode-data 12.1.0~pre1-2"
> 
> This package is arch:all. Somebody needs to do a source upload.

The files built with unicode-data are in arch-specific packages, so a
binnmu should work.

However this would be the first binnmu for the current package layout
(Wine's package relationships are a bit tricky with its internal
versioned cross-architecture relationships).  So although back then I
took great care to get it right and successfully tested a binnmu
locally, it was never verified for real.

On the other side binnmu version numbers are ugly ;)

So what do you think, binnmu or new source upload?

Greets
jre

Bug#928013: nmu: wine_4.0-1

[Jens Reyer]

Hi,

that won't work, because wine_4.0-1 has a build-depends on unicode-data
(<< 12) (see my mail in the 'Handling Japanese new era "令和 (Reiwa)"'
thread).  I'll upload wine_4.0-2 shortly, closing this bug here with
that version.

btw, wine-development_4.2-4 already was changed, so the other Wine
related nmu request #928014 (nmu: wine-development_4.2-4) is correct and
locally tested here.

Greets
jre

Bug#927139: [src:wine-development] wineserver doens't work when /run/user/pid is not available

[Jens Reyer]

cotrol: tags -1 + moreinfo


Hi Konstantin,

On 15.04.19 15:11, Konstantin Demin wrote:
> Source: wine-development
> Version: 4.2-2
> 
> wineserver fails to setup it's directory when /run/user/${pid} is not
> available due to buggy patch.
> please fix debian/patches/fixes/temporary-directory.patch:
> 
> line 65:
> -+tmp_dir = xmalloc( sizeof(tmp_env) );
> ++tmp_dir = xmalloc( strlen(tmp_env) + 1 );
> 
> line 110:
> -+n = fputs( root + sizeof(tmp_dir) + 1, stream );
> ++n = fputs( root + strlen(tmp_dir) + 1, stream );
> 
> bug is caused by copy-paste mistake, because tmp_env and tmp_dir are
> type of "char *", not "char []", therefore sizeof() isn't equal to
> strlen() + 1.

Thanks for your report.  I can' reproduce the issue here, but
/run/user/$uid exists here (btw: typo pid/uid in your mail).  So can you
please explain more specifically how to trigger this bug?  I'd like to
know if this needs to be fixed for buster.

Besides that, I rebuilt Wine with your fixes and all seems fine.  Your
explanations sound good, but I have to admit I can't really verify them
due to lack of C skills, and in-depth Wine code knowledge.

Greets
jre

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

On 03.04.19 09:05, Marc Dequènes (duck) wrote:
> I already asked for an unblock, explaining the situation (like why it
> was blocked out of testing, why the recent fixes…), but it was rejected
> without any comment on my rational:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923885

Strange, #923885 doesn't appear on
https://lists.debian.org/debian-release/2019/03/threads.html (or page 2
or 3).  I checked before, and now triple checked again.


> I'm not convinced backporting a bunch of patches on top of 0.8-1
> (important and security fixes), which would end-up creating an untested
> version would be a safe solution. 0.9.1-1 and now 0.10.1-1 have been
> around for some time without problem.

After reading duck's insiders rational I'm even more convinced that this
is the right way to go.

libmspack/0.8-1 really is problematic.  The now broken "cabextract -F"
is used quite often in Winetricks.  Users are frequently reporting
issues upstream.[1]  So if we can't get 0.10.1-1 accepted, I guess I'd
try to submit a patched, freeze-policy compliant version targeted only
at the problem that affects winetricks.  I'd be more then surprised if
that results in a nearly as good and tested version as 0.10.1-1 is.

0.8-1 was superseded after only 8 days by 0.9.1-1 in unstable last
November.  At least winetricks users will have manually updated long
time ago.


> So I hope the release team will change their mind, or suggest a solution.

Yes, please make an exception.  Sorry for the work now, but please help
us to solve this issue in a good way.

Greets
jre


[1]
https://github.com/kyz/libmspack/issues/22
https://github.com/Winetricks/winetricks/issues/1120
https://github.com/Winetricks/winetricks/issues/1154
https://github.com/Winetricks/winetricks/issues/1172
https://github.com/Winetricks/winetricks/issues/1178
https://github.com/Winetricks/winetricks/issues/1193

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

I sent the full debdiff as xz (70kb), but erroneously to #926123.
Not resending, sorry and thanks.

Bug#926123: unblock: cabextract/1.9-2

[Jens Reyer]

Attached the debdiff as xz.

I also explicitly forwarded my mail to the maintainer, because I don't
know if x-debbugs-cc worked.


libmspack_0.8-1_0.10.1-1.diff.xz
Description: application/xz

Bug#926123: unblock: cabextract/1.9-2

[Jens Reyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

block -1 by 926118


Hi

Please unblock package cabextract

I'm not the maintainer of cabextract, but of winetricks which is affected by
#914263 (cabextract: -F option doesn't work correctly.)

#914263 is a duplicate of #912687 (libmspack0: Regression when extracting
cabinets using -F
option fixed upstream, needs to be patched), see my previous unblock request
#926118.  It was fixed by:

cabextract (1.9-2) unstable; urgency=medium

  * Force libmspack0 version >= 0.9.1-1 to avoid bugs in that
package: Closes: #914263

 -- Eric Sharkey   Sun, 09 Dec 2018 08:06:55 -0500

Other changes I found in the debdiff:
- Bump debhelper version from 7 to 11
- Bump Standards-Version from 3.9.6 to 4.2.1
- d/rules target install: build
  drop dh_clean -k, add dh_prep


This unblock of cabextract is not strictly necessary for a pure Debian stable,
but might help e.g. derivatives.  If I'm wasting your time here, please just
NACK and close this report.


unblock cabextract/1.9-2


Thanks and greets
jre



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
diffstat for cabextract-1.9 cabextract-1.9

 changelog |7 +++
 compat|2 +-
 control   |6 +++---
 rules |2 +-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff -Nru cabextract-1.9/debian/changelog cabextract-1.9/debian/changelog
--- cabextract-1.9/debian/changelog 2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/changelog 2018-12-09 14:06:55.0 +0100
@@ -1,3 +1,10 @@
+cabextract (1.9-2) unstable; urgency=medium
+
+  * Force libmspack0 version >= 0.9.1-1 to avoid bugs in that
+package: Closes: #914263
+
+ -- Eric Sharkey   Sun, 09 Dec 2018 08:06:55 -0500
+
 cabextract (1.9-1) unstable; urgency=medium
 
   * New upstream release: Closes: #913007
diff -Nru cabextract-1.9/debian/compat cabextract-1.9/debian/compat
--- cabextract-1.9/debian/compat2018-11-11 17:20:41.0 +0100
+++ cabextract-1.9/debian/compat2018-12-09 14:06:55.0 +0100
@@ -1 +1 @@
-7
+11
diff -Nru cabextract-1.9/debian/control cabextract-1.9/debian/control
--- cabextract-1.9/debian/control   2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/control   2018-12-09 14:06:55.0 +0100
@@ -2,12 +2,12 @@
 Section: utils
 Priority: optional
 Maintainer: Eric Sharkey 
-Build-Depends: debhelper (>= 7), sharutils, libmspack-dev, pkg-config, 
automake-1.15
-Standards-Version: 3.9.6
+Build-Depends: debhelper (>= 11), sharutils, libmspack-dev, pkg-config, 
automake-1.15
+Standards-Version: 4.2.1
 
 Package: cabextract
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libmspack0 (>= 0.9.1-1), ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: foreign
 Enhances: konqueror
 Description: Microsoft Cabinet file unpacker
diff -Nru cabextract-1.9/debian/rules cabextract-1.9/debian/rules
--- cabextract-1.9/debian/rules 2018-11-11 17:46:01.0 +0100
+++ cabextract-1.9/debian/rules 2018-12-09 14:06:55.0 +0100
@@ -44,7 +44,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k
+   dh_prep
dh_installdirs
 
# Add here commands to install the package into debian/cabextract.

Bug#926118: unblock: libmspack/0.10.1-1

[Jens Reyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi

Please unblock package libmspack

I'm not the maintainer of libmspack (in CC), but of winetricks which is
affected by #912687 (libmspack0: Regression when extracting cabinets using -F
option fixed upstream, needs to be patched).

The mentioned upstream fix is
https://github.com/kyz/libmspack/commit/2d86d4e70026cd03730ce0b00b12579c2e21620a
and was released some time ago in:

libmspack (0.9.1-1) unstable; urgency=medium

  * New upstream release:
+ fix regression when extracting cabinets using -F option
  (Closes: #912687)
  * Bump Standards-Version to 4.2.1.
  * Adapt to documentation now generated in 'doc/html'.

 -- Marc Dequènes (Duck)   Tue, 06 Nov 2018 22:38:49 +0900



Unfortunately the version fixing this failed to build on big-endian systems.
The upload fixing that was just a few days short for migration before the hard
freeze:

libmspack (0.10.1-1) unstable; urgency=medium

  * New upstream release:
+ fix build on big-endian systems (Closes: #914794)
  * Add missing JS files for documentation menu and search functions.

 -- Marc Dequènes (Duck)   Tue, 05 Mar 2019 19:03:29 +0900



I propose to accept libmspack/0.10.1-1 for buster, because especially 0.9.1-1
was much more tested since last December, then a 0.8 plus some cherry-picked
fixes would ever be.  However there seem to be a lot of unrelated changes,
mainly for the documentation system.  The debdiff is quite large (full debdiff
is over 400bk), so here's just the diffstat for libmspack-0.8 libmspack-0.10.1:

 ChangeLog  |  107 +
 Makefile.am|  178 +-
 Makefile.in|  787 +++---
 README |   17
 acinclude.m4   |   12
 config.h.in|   27
 configure  |  402 +++--
 configure.ac   |   20
 debian/changelog   |   18
 debian/control |2
 debian/copyright   |2
 debian/libmspack-doc.docs  |   12
 debian/rules   |2
 doc/.gitignore |1
 doc/Doxyfile   |   17
 doc/Doxyfile.in|   22
 doc/Makefile   |   16
 doc/Makefile.in|   14
 examples/cabd_memory.c |   30
 examples/cabrip.c  |   85 +
 examples/chmextract.c  |  121 +
 examples/msexpand.c|   48
 examples/multifh.c |   12
 examples/oabextract.c  |   41
 libmscabd.la   |   41
 libmschmd.la   |   41
 libmspack.la   |   41
 mspack/cab.h   |6
 mspack/cabd.c  |  351 ++--
 mspack/chmd.c  |  578 +++
 mspack/crc32.c |  104 -
 mspack/crc32.h |2
 mspack/kwajd.c |  354 ++--
 mspack/lzss.h  |8
 mspack/lzssd.c |   84 -
 mspack/lzx.h   |   22
 mspack/lzxd.c  |  714 -
 mspack/mspack.h|  173 +-
 mspack/mszip.h |   12
 mspack/mszipd.c|  270 +--
 mspack/oab.h   |1
 mspack/oabd.c  |  117 -
 mspack/qtm.h   |8
 mspack/qtmd.c  |  232 +-
 mspack/readbits.h  |  124 -
 mspack/readhuff.h  |  124 -
 mspack/system.c|9
 mspack/system.h|   56
 mspack/szddd.c |   74
 src/cabrip.c   |   85 -
 src/chmextract.c   |  122 -
 src/error.h|   22
 src/msexpand.c |   48
 src/oabextract.c   |   41
 test-driver|  148 +
 test/cabd_md5.c|  154 -
 test/cabd_test.c   |  643 
 test/chmd_find.c   |  110 -
 test/chmd_md5.c|   34
 test/chmd_order.c  |  190 +-
 test/chmd_test.c   |   70
 test/chminfo.c |  207 +-
 test/kwajd_test.c  |  144 -
 test/md5.c |  163 --
 test/md5.h |   25
 test/md5_fh.h  |   58
 test/test_files/cabd/mszip_lzx_qtm.cab  |binary
 test/test_files/cabd/normal_2files_2folders.cab |binary
 test/test_files/chmd/cve-2015-4467-reset-interval-zero.chm.LZXC-is-lzxc
|binary
 test/test_files/chmd/cve-2015-4467-reset-interval-zero.chm.xor |binary
 test/test_files/chmd/short-system-filenames.chm |binary
 test/test_files/kwajd/make.pl  |   16
 72 files changed, 4294 insertions(+), 3525 deletions(-)



unblock libmspack/0.10.1-1


Sorry for being so late.

Greets
jre


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

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

[Jens Reyer]

Hi,

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

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

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

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

Greets
jre

Bug#921200: vkd3d: misses dependency on libvulkan1

[Jens Reyer]

Source: vkd3d
Version: 1.1-2
Severity: normal


[resend to the bts]

Hi Mike

On 02.02.19 08:56, Michael Gilbert wrote:
> On Fri, Feb 1, 2019 at 10:38 PM Jens Reyer wrote:
>> vkd3d has no runtime dependency on libvulkan1 or any other vulkan
>> related packages.  So with the currently existing package relationships
>> you can build vkd3d with newer vulkan and then install it next to wine
>> with older vulkan.[1]
> 
> This is an error in the packaging.  Vulkan is loaded via dlopen, so an
> explicit dependency is needed but missing.  That could be automated as
> is done in wine with sonames2elf.

Ah, now I understand, thanks! Filing this as a bug for now.

I had a first look into libvulkan1' symbols and (if I get this
correctly) it seems symbols get frequently dropped.  I'll have to talk
vulkan's maintainers about that.

Greets
jre

Bug#920649: wine backports: include stub for SetWindowThemeAttribute

[Jens Reyer]

HI

On 27.01.19 22:39, Axel Huebl wrote:
> I am using wine 3.0.3 from stretch-backports.
> 
> With the latest update (v1.6.0) of the reMarkable desktop GUI, the upgrade
> breaks on an unimplemented function.
> 
>   https://remarkable.com
>   https://remarkable.engineering
> 
> Wine 3.1.0 fixes this via commit
>   https://github.com/wine-
> mirror/wine/commit/28613fcd934bffb3a581830a8fa7568ab35e4140
> 
> Can you please add either wine 3.1.0 or just the little stub patch to
> stretch-
> backports?

Thanks for your report.  I'll soon upload 4.0 to stretch-backports, that
should fix it.

Greets
jre

btw, you may also update your fonts-wine to the backports version.

Bug#919889: vkd3d: Make build-dependency on libvulkan-dev versioned.

[Jens Reyer]

Source: vkd3d
Version: 1.1-2
Severity: normal


Hi Mike,

vkd3d fails to build in stretch with libvulkan-dev 1.0.39.0+dfsg1-1, but
succeeds with 1.1.70+dfsg1-1~bpo9+1 which is in stretch-backports.

I didn't investigate exactly which version is required, but just suggest
something like this in d/control:

- libvulkan-dev,
+ libvulkan-dev (>= 1.1.70),

Greets
jre




Failed build with 1.0.39.0+dfsg1-1:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include -I./include
-I./include/dummy -I./include/private -Wdate-time -D_FORTIFY_SOURCE=2
-Wall -pipe -std=c99 -Wdeclaration-after-statement -Wmissing-prototypes
-Wunused-but-set-parameter -Wvla -Wl,--no-undefined -g -O2
-fdebug-prefix-map=/build/vkd3d-1.1=. -fstack-protector-strong -Wformat
-Werror=format-security -c libs/vkd3d/command.c  -fPIC -DPIC -o
libs/vkd3d/.libs/command.o
In file included from libs/vkd3d/resource.c:19:0:
libs/vkd3d/vkd3d_private.h:62:30: error: unknown type name
'PFN_vkCmdPushDescriptorSetKHR'
 #define DECLARE_VK_PFN(name) PFN_##name name;
  ^
libs/vkd3d/vkd3d_private.h:74:27: note: in expansion of macro
'DECLARE_VK_PFN'
 #define VK_DEVICE_EXT_PFN DECLARE_VK_PFN
   ^~
libs/vkd3d/vulkan_procs.h:175:1: note: in expansion of macro
'VK_DEVICE_EXT_PFN'
 VK_DEVICE_EXT_PFN(vkCmdPushDescriptorSetKHR)
 ^
Makefile:1066: recipe for target 'libs/vkd3d/resource.lo' failed
make[3]: *** [libs/vkd3d/resource.lo] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from libs/vkd3d/state.c:20:0:
libs/vkd3d/vkd3d_private.h:62:30: error: unknown type name
'PFN_vkCmdPushDescriptorSetKHR'
 #define DECLARE_VK_PFN(name) PFN_##name name;
  ^
libs/vkd3d/vkd3d_private.h:74:27: note: in expansion of macro
'DECLARE_VK_PFN'
 #define VK_DEVICE_EXT_PFN DECLARE_VK_PFN
   ^~
libs/vkd3d/vulkan_procs.h:175:1: note: in expansion of macro
'VK_DEVICE_EXT_PFN'
 VK_DEVICE_EXT_PFN(vkCmdPushDescriptorSetKHR)
 ^
In file included from ./include/private/vkd3d_common.h:23:0,
 from libs/vkd3d/vkd3d_private.h:26,
 from libs/vkd3d/state.c:20:
libs/vkd3d/state.c: In function 'd3d12_root_signature_init':
libs/vkd3d/state.c:957:17: error:
'VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR' undeclared
(first use in this function)

VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR,
 ^
./include/vkd3d_windows.h:36:35: note: in definition of macro 'FAILED'
 # define FAILED(hr)((HRESULT)(hr) < 0)
   ^~
libs/vkd3d/state.c:957:17: note: each undeclared identifier is
reported only once for each function it appears in

VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR,
 ^
./include/vkd3d_windows.h:36:35: note: in definition of macro 'FAILED'
 # define FAILED(hr)((HRESULT)(hr) < 0)
   ^~
Makefile:1066: recipe for target 'libs/vkd3d/state.lo' failed
make[3]: *** [libs/vkd3d/state.lo] Error 1
In file included from libs/vkd3d/device.c:19:0:
libs/vkd3d/vkd3d_private.h:62:30: error: unknown type name
'PFN_vkCmdPushDescriptorSetKHR'
 #define DECLARE_VK_PFN(name) PFN_##name name;
  ^
libs/vkd3d/vkd3d_private.h:74:27: note: in expansion of macro
'DECLARE_VK_PFN'
 #define VK_DEVICE_EXT_PFN DECLARE_VK_PFN
   ^~
libs/vkd3d/vulkan_procs.h:175:1: note: in expansion of macro
'VK_DEVICE_EXT_PFN'
 VK_DEVICE_EXT_PFN(vkCmdPushDescriptorSetKHR)
 ^
libs/vkd3d/device.c:66:6: error:
'VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME' undeclared here (not in a function)
 {VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME, offsetof(struct
vkd3d_vulkan_info, KHR_push_descriptor)},
  ^
Makefile:1066: recipe for target 'libs/vkd3d/device.lo' failed
make[3]: *** [libs/vkd3d/device.lo] Error 1
In file included from libs/vkd3d/command.c:20:0:
libs/vkd3d/vkd3d_private.h:62:30: error: unknown type name
'PFN_vkCmdPushDescriptorSetKHR'
 #define DECLARE_VK_PFN(name) PFN_##name name;
  ^
libs/vkd3d/vkd3d_private.h:74:27: note: in expansion of macro
'DECLARE_VK_PFN'
 #define VK_DEVICE_EXT_PFN DECLARE_VK_PFN
   ^~
libs/vkd3d/vulkan_procs.h:175:1: note: in expansion of macro
'VK_DEVICE_EXT_PFN'
 VK_DEVICE_EXT_PFN(vkCmdPushDescriptorSetKHR)
 ^
libs/vkd3d/command.c: In function 'd3d12_command_list_set_root_cbv':
libs/vkd3d/vkd3d_private.h:40:21: error: called object is not a
function or function pointer
 #define VK_CALL(f) (vk_procs->f)
 ^

Bug#707790: Fix is missing (Re: Bug#707790: marked as done ([git] Please add dependency on "meld"))

[Jens Reyer]

control: found -1 git/1:2.20.1-1
control: reopen -1 !


Hi Jonathan,

On 17.12.18 02:24, Debian Bug Tracking System wrote:
>  git (1:2.20.1-1) unstable; urgency=medium
>  [...]
>* package git-gui: Suggests: meld for mergetool support (thx Jens
>  Reyer; closes: #707790).

thanks for working on this.  But unfortunately the fix itself is missing
in the package.  Commit 9e54d98d3481749026d09cf456a845248fa11ae4 only
adds the d/changelog entry.

Reopening this bug.

Greets
jre

Bug#829119: radicale does not commit to git

[Jens Reyer]

Package: radicale
Followup-For: Bug #829119

Hi

committing to git works here (radicale 2.1.11-2 and previous versions
from experimental).
python-dulwich / python3-dulwich is not needed anymore for this.

$ grep hook /etc/radicale/config
hook = ([ -d .git ] || git init) && ([ -e .gitignore ] || printf
'.Radicale.cache\n.Radicale.lock\n.Radicale.tmp-*\n' > .gitignore) &&
git add -A && (git diff --cached --quiet || git commit -m "Changes by
"%(user)s)

Whenever it didn't work here, it was because of messed up permissions
(although this is probably not the case for the submitter, I'd still
suggest a "chown -R radicale:radicale /var/lib/radicale").

Greets
jre

Bug#917005: wine: TreePad Generates Error Upon Stratup in WINE 4.x

[Jens Reyer]

Hi Van

On 21.12.18 12:33, Van wrote:
> TreePad X Enterprise 12GB (single user) generates the following error
> upon startup using WINE version 4.x:
> List index out of bounds (-2147483632)

I can reproduce this, the error happens after clicking "Cancel" in the
"TreePad quick start" window.  Did you experience any specific issues
because of that?

It happens also with the regular installer from
http://www.treepad.com/download/tpxsu1.html, both with the Debian wine
packages and the Winehq wine-devel packages.  Can you report this at
https://bugs.winehq.org/ and report their bugnumber here?

I understood this is a regression from previous good Wine versions?
Then please also report the last known good Wine version.


> The horizontal ruler/scale in the article window (right pane) is
> also skewed:
> No database opened (WINE version 4.x):
> https://i.postimg.cc/qMw2MFgn/2018-12-20-1545291398-1920x1080-scrot.png
> Database opened with article displayed (WINE version 4.x):
> https://i.postimg.cc/8znWLrRz/2018-12-20-1545291515-1920x1080-scrot.png
> No database opened (WINE version 3.x):
> https://i.postimg.cc/DwzLWcbN/2018-12-20-1545293959-1920x1080-scrot.png
> Database opened with article displayed (WINE version 3.x):
> https://i.postimg.cc/k56SsXsF/2018-12-20-1545293999-1920x1080-scrot.png
> Link to TreePad X Enterprie 12GB (single user) download (21-day
> evaluation):http://www.treepad.com/download/tpxsu1.html

I fail to see what's skewed in there.  Maybe mark it in the screenshots
and also forward upstream.

Greets
jre

Bug#916613: [winetricks] Don't remove upstream's manual selfupdate option

[Jens Reyer]

Package: winetricks
Version: 0.0+20181203-2
Severity: wishlist
Tags: pending


Hi all,

Currently we completely patch out Winetricks' selfupdate feature
(remove-self-update.patch).  Now I plan to only disable the *automatic*
winetricks version check and selfupdate, but keep the option
"--self-update" for manual updates:

The default behavior of the Debian package will still be unchanged then.

One has to execute as root "winetricks --self-update" to download and
install the upstream version in /usr/bin/winetricks.  Further my
proposed version is quite verbose about this, and also requires an
explicit confirmation before updating to the upstream version.

The complete change is at https://salsa.debian.org/wine-team/winetricks.
For easier discussion I also attached the patch with the new implementation.

Any thoughts on this, or need for more explanation?
I'd be especially happy about suggestions for better wording.

jre
>From 9413ec1be8ed1ca3c3daf5668c529ec2a1805a86 Mon Sep 17 00:00:00 2001
From: Jens Reyer 
Date: Sun, 9 Dec 2018 22:20:43 +0100
Subject: [PATCH] Add disable-automatic-selfupdate.patch.

Disable automatic version check and selfupdate.
Warn and ask on manual selfupdate.
Document this in README.Debian.
---
 debian/README.Debian  | 14 
 .../disable-automatic-selfupdate.patch| 79 +++
 debian/patches/series |  1 +
 3 files changed, 94 insertions(+)
 create mode 100644 debian/patches/disable-automatic-selfupdate.patch

diff --git a/debian/README.Debian b/debian/README.Debian
index 3d52574..3ba53b6 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -54,3 +54,17 @@ for more information:
 
   https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1006909
 
+
+Winetricks' selfupdate
+==
+
+Winetricks' automatic selfupdate and version check is disabled in
+Debian.  Although you may still run a manual "winetricks --selfupdate",
+be aware that this will install /usr/bin/winetricks directly from its
+developers, without any lookover from Debian.  What happens then, is out
+of Debian's control.
+Assuming the selfupdate only changed /usr/bin/winetricks, but nothing
+else was changed by this subsequently, then a future update of the
+winetricks package will bring back the regular Winetricks by Debian.
+But again: Debian cannot guarantee this.
+
diff --git a/debian/patches/disable-automatic-selfupdate.patch b/debian/patches/disable-automatic-selfupdate.patch
new file mode 100644
index 000..10b3a6c
--- /dev/null
+++ b/debian/patches/disable-automatic-selfupdate.patch
@@ -0,0 +1,79 @@
+Description: Disable automatic version check and selfupdate.
+  Warn and ask on manual selfupdate.
+Author: Jens Reyer 
+Forwarded: not-needed
+Last-Update: 2018-12-16
+
+--- a/src/winetricks
 b/src/winetricks
+@@ -941,6 +941,18 @@ winetricks_check_update_availability()
+ w_warn "You don't have the proper permissions to run this command. Try again with sudo or as root."
+ exit
+ fi
++
++w_warn "This will install Winetricks directly from its original developers.  Debian has no control over that version."
++printf %s "To continue press Y or N, then Enter: "
++read -r debresponse
++if test "$debresponse" = Y || test "$debresponse" = y; then
++true
++elif test "$debresponse" = N || test "$debresponse" = n; then
++exit
++else
++w_warn "Please press Y or N.  Aborting"
++exit
++fi
+ }
+ 
+ winetricks_selfupdate()
+@@ -982,6 +994,8 @@ winetricks_selfupdate()
+ w_try chmod +x "$0"
+ 
+ w_warn "Update finished! The current version is $($0 -V). Use 'winetricks --update-rollback' to return to the previous version."
++w_warn "Winetricks is no more controlled by Debian but by the Winetricks project now."
++w_warn "The next update of the winetricks package may or may not revert this change."
+ 
+ exit
+ }
+@@ -3168,10 +3182,10 @@ winetricks_latest_version_check()
+ if [ ! "$WINETRICKS_VERSION" = "${latest_version}" ] && [ ! "$WINETRICKS_VERSION" = "${latest_version}-next" ]; then
+ if [ -f "${WINETRICKS_CONFIG}/enable-auto-update" ] ; then
+ w_info "You are running winetricks-${WINETRICKS_VERSION}."
+-w_info "New upstream release winetricks-${latest_version} is available."
+-w_info "auto-update enabled: running winetricks_selfupdate"
+-winetricks_selfupdate
+-else
++w_info "The automatic selfupdate is disabled in the Debian packages."
++#winetricks_selfupdate
++fi
++#else
+ case $LANG in
+ pl*)
+ w_warn "Korzystasz z wine

Bug#913593: [apt-cacher-ng] Typo /snipped/snippet/

[Jens Reyer]

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


Hi,

the little text files are snippets, not snippeds.

https://www.merriam-webster.com/dictionary/snippet
https://www.merriam-webster.com/dictionary/snipped

Patch attached.

Thanks
jre
diff --git a/INSTALL b/INSTALL
index da32cbe..c1cc0e6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -68,7 +68,7 @@ Configuration:
  - visit Command-and-Control web interface of apt-cacher-ng, link can be found
among other instructions at http://yourHostName:portNumber/ , which might be
http://localhost:3142/ with the default configuration
- - for apt clients, there is a config snipped in contrib/10-apt-cacher-ng.conf
+ - for apt clients, there is a config snippet in contrib/10-apt-cacher-ng.conf
which might be installed into /etc/apt/apt.conf.d/.
 
 Developer notes:
diff --git a/doc/000apt-cacher-ng-proxy b/doc/000apt-cacher-ng-proxy
index e03fadd..9bb07c2 100644
--- a/doc/000apt-cacher-ng-proxy
+++ b/doc/000apt-cacher-ng-proxy
@@ -1,4 +1,4 @@
-# This configuration snipped is intended to be stored in /etc/apt/apt.conf.d/
+# This configuration snippet is intended to be stored in /etc/apt/apt.conf.d/
 # on the client system in order to change a regular setup to use apt-cacher-ng.
 #
 Acquire::http::Proxy "http://192.168.0.245:3142/;;

Bug#913594: [apt-cacher-ng] Vcs-Git field lacks branch information

[Jens Reyer]

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

Hi,

https://tracker.debian.org/pkg/apt-cacher-ng believes that the git repo
is outdated, because it's looking at branch master instead of debian/sid.

To fix either adapt the salsa project, or debian/control.

Patch for the latter solution is attached.

Thanks for apt-cacher-ng
Greets
jre
diff --git a/debian/control b/debian/control
index 9e6f616..e4834bc 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Eduard Bloch 
 Build-Depends: debhelper (>= 9), cmake (>= 2.6.2), libbz2-dev, zlib1g-dev, liblzma-dev, libfuse-dev [!hurd-i386], pkg-config, libwrap0-dev, lsb-base (>> 3.0-6), debhelper (>= 9.20160709) | dh-systemd (>= 1.5), po-debconf, libssl-dev, libsystemd-dev (>= 210) [linux-any] | libsystemd-daemon-dev [linux-any]
 Standards-Version: 4.1.1
 Homepage: http://www.unix-ag.uni-kl.de/~bloch/acng/
-Vcs-Git: https://salsa.debian.org/blade/apt-cacher-ng.git
+Vcs-Git: https://salsa.debian.org/blade/apt-cacher-ng.git -b debian/sid
 Vcs-Browser: https://salsa.debian.org/blade/apt-cacher-ng/tree/debian/sid
 
 Package: apt-cacher-ng

Bug#912057: getting winehq's wine-mono to work

[Jens Reyer]

On 28.10.18 19:53, Austin English wrote:
> For testing, using a C# hello world is easy:
[...]

For completeness, someone else from winehq just told me (and it seems
they would really be happy to see wine-mono packaged as that would ease
their support burden):

.NET apps that work with wine-mono are mostly older ones (v2.0). The MS
Office 2007 and 2010 installers come to mind. (Note that the Office 2010
installer doesn't work in current Wine for other reasons.)

Bug#912057: getting winehq's wine-mono to work

[Jens Reyer]

On 28.10.18 18:45, Alexandre Viau wrote:
> On 2018-10-28 12:49 p.m., Jens Reyer wrote:
>> great to see you working on wine-mono (although personally I never
>> needed it).
> 
> Is this because you use Microsoft's proprietary implementation?

I don't use Wine very often, and the apps that I use it for, just don't
require it.  Last time I needed it, it was for Adobe Digital Editions -
back then I used the proprietary solution (iirc wine-mono didn't work
for it, not sure).


>> On 28.10.18 01:22, Alexandre Viau wrote:
>>> Also, I notice that C:\\windows\mono exists in prefixes by default, even
>>> when wine-mono is not installed. That is expected?
>>
>> I've seen empty gecko/mono folders before, but didn't worry/investigate.
> 
> Mono's folder is full, however. It contains many .exes and .dlls.
> 
> Can you reproduce this?
> 
>  - rm -rf ~/wine
>  - wine explorer
>  - browse c:\\windows\mono

Tested: No, no mono folder at all.


> It could be that wine picks-up wine-mono from an unknown location on my
> system without me noticing...

Check for ~/.cache/wine/wine-mono-4.7.1.msi.  That will be installed
automatically and result in a full c:\\windows\mono folder.  You might
have downloaded it accidentally if you used another Wine (not from
Debian, where we removed the installer download).

All search paths (see the gecko and mono entries in our Debian.readme):
- /usr/share/wine-mono/
- /usr/share/wine-development/mono/ (only if you are using wine-development)
- /usr/share/wine/mono
- $XDG_CACHE_HOME/wine/
- $HOME/.cache/wine/ (if XDG_CACHE_HOME is not set)



>>> On a side note, Wine has a feature that installs mono automatically when
>>> it is in /usr/share/wine-development/mono. However it checks for shasums
>>> and exact filenames so we will probably have to patch it in Debian.
>>> (dlls/appwiz.cpl/addons.c). That said, it shouldn't prevent us from
>>> installing it manually with ``wine64 msiexec /i winemono.msi``.
>>
>> When I worked on disable/addons-download.patch I figured that the
>> checksums are only checked if the wine-gecko/mono installer is loaded
>> from home, but not when loaded from /usr/share.  That's what I put into
>> README.debian.  Please verify.
> 
> I'll verify when I get to that. I read it quickly and never really
> managed to get it installed from /usr/share, but before I jump to the
> conclusion that it didn't work, I want to find a reliable way to test
> whether or not wine-mono is installed.
> 
> Looking at wine uninstaller isn't enough as it produces results that are
> hard to explain, like mono/gecko showing as present even when they were
> not installed.

Ok, I haven't looked into this more deeply.  Make sure you don't have
mono/gecko installed accidentally, see above.
Which Wine are you using?



>> btw, the command is always "wine" (not wine64 or wine32), e.g. "wine
>> msiexec /i winemono.msi".  Wine will then figure out internally which
>> Wine loader to use.  This is true both upstream and in Debian.
> 
> Sure, I specified wine64 because this is what WineHQ's wiki specifically
> says so, for 64bit prefixes:
>  - https://wiki.winehq.org/Mono
> 
> It also yields totally different results, if we trust wine uninstaller.
> Note that the .msi is supposed to install both 32 and 64bit versions of
> mono. It could be that installing it with just wine will install only
> the 32bit version and skip the 64bit version.

Ok, that's new to me.  I'd need to look into that more deeply (no
promise, tell me if you need more help).

Greets
jre

Bug#912057: getting winehq's wine-mono to work

[Jens Reyer]

[ Dropping debian-wine (=maintainer, gets bugreports anyway), and skitt
  (member of debian-wine) from CC ]

Hi Alexandre

great to see you working on wine-mono (although personally I never
needed it).  I guess you'll put this under the wine-team umbrella?


On 28.10.18 01:22, Alexandre Viau wrote:
> Also, I notice that C:\\windows\mono exists in prefixes by default, even
> when wine-mono is not installed. That is expected?

I've seen empty gecko/mono folders before, but didn't worry/investigate.


> On a side note, Wine has a feature that installs mono automatically when
> it is in /usr/share/wine-development/mono. However it checks for shasums
> and exact filenames so we will probably have to patch it in Debian.
> (dlls/appwiz.cpl/addons.c). That said, it shouldn't prevent us from
> installing it manually with ``wine64 msiexec /i winemono.msi``.

When I worked on disable/addons-download.patch I figured that the
checksums are only checked if the wine-gecko/mono installer is loaded
from home, but not when loaded from /usr/share.  That's what I put into
README.debian.  Please verify.

btw, the command is always "wine" (not wine64 or wine32), e.g. "wine
msiexec /i winemono.msi".  Wine will then figure out internally which
Wine loader to use.  This is true both upstream and in Debian.

Greets
jre

Bug#910942: [wine-development] Please use wrap-and-sort

[Jens Reyer]

Hi Mike

On 10/14/18 2:36 AM, Michael Gilbert wrote:
> Welcome back!

Thanks, much appreciated!  btw, I'm just working on 3.0.3-1.


> Wrap and sort is itself the original source of the extra diff being
> seen and will continue to be in the future.

Wrap and sort has a deterministic result.  We could add it to
debian/scripts/import, so that even misplaced entries get sorted quite
soon, and then stay in their place forever.


> I would prefer to
> maintain the original rough organization of dependencies, which is
> build tools, utilities, and data followed by libraries.  Wrap and sort
> to me is not particularly useful.

It helps to see the logic being named.  However in my packaging work on
Wine I've really seen these reorganization changes so often (in d/rules
and other files like .install) and had to spend a lot of time in
comparing files, that I'd prefer a deterministic sorting to a rough
organization which changes over time.



>> [1] This time I just noticed you replaced the builddep "fontforge-nox |
>> fontforge" with "fontforge-nox".  This reverts something I did on
>> purpose when I implemented the font-rebuilding, so that for local
>> rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge
>> is already installed.
> 
> That change is of course intentional.  It is my opinion that it is
> preferable to try to avoid potential sources of variance in builds.  A
> desire to reduce the number of installed packages for a build I think
> should not override that.

Ok.

Greets
jre

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

[Jens Reyer]

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


wine-development 3.17-1 ftbfs on arm64:

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


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

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

jre

Bug#910942: [wine-development] Please use wrap-and-sort

[Jens Reyer]

Package: wine-development
Version: 3.17-1
Severity: normal

Hi Mike,

in the recent uploads you re-sorted the dependencies in d/control.in
once again.  Each time this happens this takes some of my time when I
sync the src:wine packaging, or dig into issues that exist only in one
of our or other packages (upstream, downstream, other versions, ...).
Further it obfuscates packaging changes[1] and has potential for
copy errors.

To avoid these issues I suggest to use

  wrap-and-sort --wrap-always --short-indent --trailing-comma

which will keep the general layout intact, but sorts the entries
alphabetically.  You objected this change some years ago, but we didn't
discuss it in depth back then.  Hopefully I could change your mind this
time.

Greets
jre

[1] This time I just noticed you replaced the builddep "fontforge-nox |
fontforge" with "fontforge-nox".  This reverts something I did on
purpose when I implemented the font-rebuilding, so that for local
rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge
is already installed.

Greets
jre

Bug#908012: wine-development: gcc-8 build with -O2 causes some apps to crash

[Jens Reyer]

control: found -1 3.16-1


Hi Anton,

I assume this also affects the stable version of wine (3.0.2-3), since
that was also compiled with gcc 8.1.  Can you please confirm?


On 2018-09-17 03:37:11 CDT Anton Vorobyov wrote in
https://bugs.winehq.org/show_bug.cgi?id=45199#c40
> Debian maintainers compiled wine-development with -O1 optimization,
> but it still doesn't help - EVE online launcher crashes on start.

So repopening the bug for wine-development again for now.

The -O1 workaround has been dropped in 3.17-1.

Upstream has probably fixed this with several commits:

wine-3.18:

commit 72c2af3868bd68419a0f43c3ce2d8b606cb228ca
Author: Alex Henrie 
Date:   Tue Oct 2 21:30:45 2018 -0600
oleaut32: Add DECLSPEC_HOTPATCH to SysAllocStringByteLen.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199


wine-3.17:

commit b917cc66f4f7b786e7f19f63ab0c0819a5455222
Author: Alex Henrie 
Date:   Tue Sep 18 00:58:21 2018 -0600
msvcrt: Add DECLSPEC_HOTPATCH to functions patched by libtcmalloc.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199

commit 1e8c62b0209977aeb74e52c874dff53313117a63
Author: Alex Henrie 
Date:   Tue Sep 18 00:58:59 2018 -0600
oleaut32: Add DECLSPEC_HOTPATCH to functions patched by MS Word 2010.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199

commit bca3ec9fd9ff55e191c11dfe2525aa6af160d162
Author: Alex Henrie 
Date:   Tue Sep 18 00:58:32 2018 -0600
ntdll: Add DECLSPEC_HOTPATCH to functions patched by libtcmalloc.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199

commit b8b946dd0f2159b30b9775526c7aa5763bce71bd
Author: Alex Henrie 
Date:   Tue Sep 18 00:57:42 2018 -0600
kernel32: Add DECLSPEC_HOTPATCH to functions patched by libtcmalloc.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199


wine-3.12:

commit 478a3d64ef7630f16e6c618375a76ad665c7cf63
Author: Alex Henrie 
Date:   Thu Jul 5 08:39:25 2018 +0200
gdi32: Add DECLSPEC_HOTPATCH to GetDIBits.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45199
[already in wine-3.0.3 as
 commit 6f8db1d2cd5b4cbf4891cdf6feda7008374da024]

Bug#898573: [thunderbird+enigmail] thread '' panicked at '`before_sheet` stylesheet not found', src/libcore/option.rs:891:5

[Jens Reyer]

Hi Carsten

On 7/16/18 8:39 AM, Carsten Schoenert wrote:
[...]
> the root for these problems seem to be solved by a recent gpg update, at
> least since gnupg 2.2.8 the segfault of TB don't happen anymore. We can
> close this report now I guess.

Yes, you're right.  I still had a few infrequent crashes with
thunderbird 1:60.0~b9-1 and gpg 2.2.8-3, but didn't investigate them.
Probably something unrelated.

With the current versions everything seems to be stable:

enigmail2:2.0.7+ds1-1
gpg 2.2.8-3
thunderbird 1:60.0~b10-1

Greets
jre

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

[Jens Reyer]

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

Thanks Graham!

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

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

I'll remove the affects then.

Greets
jre

Bug#900312: RFS: khronos-api/4.6+git20180514-1~bpo9+1

[Jens Reyer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "khronos-api"

 * Package name: khronos-api
   Version : 4.6+git20180514-1~bpo9+1
   Upstream Author : The Khronos Group Inc.
 * URL : https://www.opengl.org/registry
 * License : Apache-2.0
   Section : x11

It builds those binary packages:

khronos-api - Khronos XML API Registry

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/khronos-api


Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/k/khronos-api/khronos-api_4.6+git20180514-1~bpo9+1.dsc


Changes since the last upload:

I only added myself to uploaders, otherwise this is a no-change upload
of the package from unstable to stretch-backports.

It's a now required build-dependency for the src:wine backports.

I'm a DM with upload-rights for khronos-api and I'm in the backports
acl, so I only need a sponsor for this first NEW upload to
stretch-backports.

I informed the maintainer about the stretch-backport (but he's usually
not available for sponsoring).

Greets
jre

Bug#900135: [lists.debian.org] please provide debian-wine-digest

[Jens Reyer]

On 05/26/2018 06:37 PM, Alexander Wirt wrote:
> On Sat, 26 May 2018, Jens Reyer wrote:
>> thanks again for the quick setup of the new debian-wine mailinglist.
>>
>> Now a user requested to read it as digest.  I've seen that a few other
>> mailing lists are provided also in this form, e.g. debian-devel-digest.
>>
>> Can you do the same for debian-wine?
> Nope, we don't provide (new) digest lists anymore for some time now, they
> mean a lot overhead and tbh your list is not big enough.

Ok, I assumed something like "a lot overhead" that, and so agree with
your explanation. Closing this bug.

Bug#900135: [lists.debian.org] please provide debian-wine-digest

[Jens Reyer]

Package: lists.debian.org
Severity: normal

Hi,

thanks again for the quick setup of the new debian-wine mailinglist.

Now a user requested to read it as digest.  I've seen that a few other
mailing lists are provided also in this form, e.g. debian-devel-digest.

Can you do the same for debian-wine?

(I haven't found any documentation, so I fear this is a no longer
supported/wanted feature.)

Greets, and thanks
jre

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Jens Reyer]

On 20.05.2018 02:20, Javier Serrano Polo wrote:
> El ds 19 de 05 de 2018 a les 23:39 +0200, Jens Reyer va escriure:
>> I definitely want the well-established system command
>> "update-alternatives" to be used.
> 
> What are the requirements?
> "update-alternatives --config wine" must work if wine or wine-
> development are installed. Only this one?

This one definitely yes.  And the state of either solution must be in
sync with the other (so if I have e.g. "wine" installed, but use your
solution, the states must match. And vice versa.)

I can't give you a complete list a priori, that's not possible.  It
depends on the way you choose to implement it.  Please don't see this as
an excuse I give now to weasel out later on, I'm really interested in
getting this issue solved.  Please assume good faith.

We have to keep in mind that libwine would be a public library then, so
symbols need to be handled accordingly then.  It's great to see that
lmms works with it for 10 years now, but this is not sufficient to
"just" put libwine on a public path (again).  Instead we have to look
into correct symbol handling (and I never did that before).

The solution must be maintainable basically forever to keep it in the
packages.  Other team members have to be fine with it, too.

I'd also check with upstream if they are fine with libwine... being on
this path, but I guess they are.

Greets
jre

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Jens Reyer]

Hi,

sorry I thought I had answered to this.

On 17.01.2018 17:56, Javier Serrano Polo wrote:
> X-Debbugs-CC: k...@codeweavers.com
> 
> El dc 17 de 01 de 2018 a les 15:48 +0100, Jens Reyer va escriure:
>> The second line is about the master, we always need it.  And I want the
>> master to be "wine", not "libwine.so.0" (e.g. master's name is used in
>> the user interfacing command "update-alternatives --config wine").
> 
> You want to configure with "update-alternatives --config wine", but I am
> asking to configure with "update-wine-alternatives --config" instead.
> The update-wine-alternatives script does not exist yet.
> 
[...]>> - Imo we should stay with pkg:wine(-development) providing the
>>   master /usr/bin/wine
> 
> Jens, you should first understand what I am proposing. Is it fine to
> configure with "update-wine-alternatives --config" and not have unneeded
> wine packages installed?

I definitely want the well-established system command
"update-alternatives" to be used.  Replacing this with a script
"update-wine-alternatives" is not acceptable.  If you can come up with a
solution which works in your sense additionally to this, we can try it.

Greets
jre

Bug#899125: [debhelper] dh_testroot: requires root despite Rules-Requires-Root: no

[Jens Reyer]

On 19.05.2018 17:46, Niels Thykier wrote:
> Niels Thykier:
>> On Sat, 19 May 2018 16:36:46 +0200 Jens Reyer <jre.wine...@gmail.com> wrote:
>>> Package: debhelper
>>> Version: 11.2.1
>>> Severity: normal
>>>
>>> Hi,
>>>
>>> I've run into this with src:wine:
>>>
>>
>> Hi,
>>
>> Thanks for the report.
>>
>>> [...]
>>>
>>> So Wine indeed builds fine without (fake)root, but dh_testroot returns
>>> false, while according to dh_testroot(1) it should return successfully.
>>>
>>
>> This happens because the documentation in dh_testroot(1) reflects the
>> draft initial implementation of R³.  However, there was a change that
>> altered how dpkg and debhelper interact before the specification was
>> announced as stable.  When I implemented that change, I forgot to update
>> the documentation in dh_testroot.
>>
>> The change has the advantage of decoupling debhelper from dpkg (e.g.
>> debhelper can now implement R³ without requiring a recent enough dpkg,
>> as dpkg will announce its support for R³).
>>
>> Please see #899125 for draft being proposed to debian-policy until I
>> have fixed the documentation in debhelper.  It should be up to date and
>> reflect the current implementation.

s/#899125/#880920/


> I have pushed the following change that I believe will fix this bug:
> https://salsa.debian.org/debian/debhelper/commit/d95a2c9328c9e934d5cf7f6e577c3d36a6a3f228

Yes, that clarifies things, advice tested successfully.
Awesome quick response and thanks a lot!

Greets
jre

Bug#880920: Minor typo Re: Bug#880920: Document Rules-Requires-Root field

[Jens Reyer]

Hi,

just a minor typo I guess, absolutely no review, sorry:

"If the package builder supports the Rules-Requires-Root field and want
to enable the feature"

s/want/wants

Greets
jre

Bug#899125: [debhelper] dh_testroot: requires root despite Rules-Requires-Root: no

[Jens Reyer]

Package: debhelper
Version: 11.2.1
Severity: normal

Hi,

I've run into this with src:wine:

$ grep Rules debian/control*
debian/control:Rules-Requires-Root: no
debian/control.in:Rules-Requires-Root: no
$ quilt push -a
$ ./debian/rules binary
[...]
make[2]: Leaving directory '/home/jens/development/wine/wine/wine/server'
Wine build complete.
make[1]: Leaving directory '/home/jens/development/wine/wine/wine'
   dh_auto_test
   create-stamp debian/debhelper-build-stamp
   dh_testroot
dh_testroot: You must run this as root (or use fakeroot).
debian/rules:107: recipe for target 'binary' failed
make: *** [binary] Error 255

So Wine indeed builds fine without (fake)root, but dh_testroot returns
false, while according to dh_testroot(1) it should return successfully.

debuild and buildd build the package just fine (but I guess they just
still use fakeroot).  Am I doing something wrong here?

Besides that, shouldn't the dh_testroot check be earlier in the dh
sequence to really make sense?


I set R³: debian/control.in here:
https://salsa.debian.org/wine-team/wine/commit/b32a716ee4255270539d4f770aa63404cf2451a2

Greets
jre

--- System information. ---
Architecture: Kernel:   Linux 4.16.0-1-amd64

Debian Release: buster/sid
  990 testing hope   990 testing dl.winehq.org   500
unstable-debug  hope   500 unstablehope   500 testing-debug
hope   100 experimentalhope 1 experimental-debug hope
--- Package information. ---
Depends(Version) | Installed
-+-=
autotools-dev| 20180224.1
dh-autoreconf   (>= 17~) | 17
dh-strip-nondeterminism  (>= 0.028~) | 0.041-1
dpkg(>= 1.18.0~) | 1.19.0.5+b1
dpkg-dev(>= 1.18.2~) | 1.19.0.5
file   (>= 3.23) | 1:5.33-2
libdpkg-perl(>= 1.17.14) | 1.19.0.5
man-db   | 2.8.3-2
po-debconf   | 1.0.20
perl | 5.26.2-3


Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
dh-make | dwz |

Bug#899113: tracker.debian.org: emails sent to '@tracker.d.o' are discarded

[Jens Reyer]

On 19.05.2018 12:34, Niels Thykier wrote:
> Mattia Rizzolo:
>> On Sat, May 19, 2018 at 06:13:39AM -0400, Michael Gilbert wrote:
>>> Similar to #891504, emails sent directly to a package tracker address,
>>> for example chromium-brow...@tracker.debian.org, are discarded instead
>>> of being relayed to those subscribed (to the 'contact' keyword).
>>>
>>> Other than this bug, @tracker.debian.org as the maintainer
>>> field has so far worked well.
>>
>> $pkg@tracker.d.o is not supposed to work, you should be using
>> $p...@packages.debian.org
>>
>> (I'll leave the longer explenation and closing to Raphael)

If the mails are not relayed but discarded then I strongly suggest to
send something like a "Delivery Status Notification (Failure)" mail to
the sender.  I'm used to getting them from "regular" mail servers if I
use an incorrect address.

E.g. I used $pkg@tracker.d.o a year ago as user because I saw it
(incorrectly) mentioned somewhere.  I just realized recently (while
looking into alioth issues) that there was no non-responsive maintainer,
but a mistake on my side.

Greets
jre

Bug#898810: wine: revert_opengl46.patch applied to wine why no upstream bug.

[Jens Reyer]

control: block 898810 by 869233


On 16.05.2018 02:40, oiaohm wrote:
> I was looking over patches that are being added to wine.

Again, thanks for doing that.


> I stumbled on the
> https://sources.debian.org/patches/wine/3.0-1/revert_opengl46.patch/ and when 
> I
> look at it is in the fact of not right.
> 
> Is this caused because you are not using the current khronos files
> https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml
> https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/wgl.xml

Yes, we need a newer version of the package khronos-api in Debian.  I
set the related bug as blocking bug.


> There is a possiblity that the opengl46 patch is wrong to start off with.
> {"GL_EXT_texture_filter_anisotropic",   ARB_TEXTURE_FILTER_ANISOTROPIC}
> This line in the patch makes me smell a possible issue that someone might have
> done a straight find and replace incorrectly.   If that is the case
> EXT_TEXTURE_FILTER_ANISOTROPIC and  ARB_TEXTURE_FILTER_ANISOTROPIC handling
> need to be implemented next to each other.   As in try
> ARB_TEXTURE_FILTER_ANISOTROPIC if that don't exist try
> EXT_TEXTURE_FILTER_ANISOTROPIC and after that fail.  If this is the case there
> need to be a wine bug opened and a patch submitted upstream.
> 
> Please note I do serousally think this is a bug in wine source code.  From the
> gl.xml file from kronous
> extension name="GL_ARB_texture_filter_anisotropic" supported="gl|glcore"
> extension name="GL_EXT_texture_filter_anisotropic" supported="gl|gles1|gles2"
> 
> Note the supported.   Running on android with glex1 or gles2 not seeing
> ARB_TEXTURE_FILTER_ANISOTROPIC and only seeing EXT_TEXTURE_FILTER_ANISOTROPIC
> would be normal.   Please remember wine is adding android support so has to
> support gles1 and gles2 as you even get new android devices today missing
> Opengl ES 3.0
> 
> If what I suspect is the case and not caused somehow by what you have done 
> with
> the khronos files please open upstream bug report in wine.

I created the opengl46 patch simply by reverting the related upstream
commits.  You might be right with your suspicion, but I currently don't
have enough time to really look into it, and argue the case or propose a
fix to upstream.  If you're sure with your theoretical analysis please
submit a bug at http://bugs.winehq.org/ and then tell us here about it.

Personally I'm more interested in getting khronos-api in Debian updated,
and thus getting rid of this patch here.

Greets
jre

Bug#898812: wine: Why is font divbyzero.patch still being applied to stable, testing and sid debian packages of wine.

[Jens Reyer]

Thanks for having a look at our patches!

On 16.05.2018 05:45, oiaohm wrote:
> https://sources.debian.org/patches/wine/3.0-1/font-divbyzero.patch/
> 
> If you read the associated wine bug
> https://bugs.winehq.org/show_bug.cgi?id=38762
> 
> The divide by zero issue was in fact fixed in freetype 2.6.2 .The
> changing of the scale value to 1 end up not copying windows behavior
> where face->size.height == 0 equals font not display.   So its not a
> error to have face->size.height==0.
> 
> So this should be set min version of freetype greater than where the
> patch was added and that is freetype 2.6.2 and this suitable  for
> stable, testing and sid.
> 
> Thing to remember there are third party fonts out there with stupid
> metrics so the correct place to address the font divide by zero
> problem was always freetype.
> 
> I can see that min version of freetype has not been updated as libwine
> is packages are still with libfreetype6 (>= 2.2.1) instead of
> libfreetype6 (>= 2.6.2) as required to address this issue properly
> without the patch.

We discussed that some time before (you'll find the full discussion in
https://lists.debian.org/debian-wine/):

On Wed, Aug 31, 2016 at 2:29 PM, Jens Reyer wrote:
On 13.09.2016 02:47, Michael Gilbert wrote:
>> font-divbyzero.patch
>> description: avoid divide-by-zero condition for certain font files and
>> warn about it
>> bug: https://bugs.winehq.org/show_bug.cgi?id=38762
>> bug-debian: https://bugs.debian.org/788809
>>
>> The problematic font has been fixed, and the situation should have
>> improved with freetype >= 2.6.2.
>> I'd suggest to drop this patch now.
>
> Division by zero shouldn't be tolerated.  It should be upstreamed.

Given that stable has a newer freetype, that the specific font is fixed,
and that upstream hasn't acted on the bugreport (although nobody
submitted the patch officially) I'd personally agree that we can drop
this patch.  To get this fixed upstream the next step is to check what
Windows does (e.g. if Windows crashes, Wine is supposed to also crash).

About increasing the minimum freetype version:  this shouldn't be done
"just" because of a bug.  Reason for this (afaik) is because it has wide
consequences, e.g. for using the package in another Debian version or
another distribution.  Since this is just a minor issue I'd advise
against increasing it.

Greets
jre

Bug#897120: Maintainer address is broken and team mailinglist is needed

[Jens Reyer]

Hi all,

On 4/28/18 5:46 PM, Jens Reyer wrote:

A1) @lists.debian.org

Since the mailing list is also for discussion and coordination (not only 
automatic mails) I think we qualify to use e.g.


  wine-team@lists.d.o


I filed #898066 against lists.debian.org, starting a request for a 
debian-wine list.  Every interested person (maintainer, upstream 
developer, user, ...) should state that by sending a mail to the bug. 
Or if you object this list for whatever reason, please also tell so.





A2) alioth-lists.debian.net

There's also the mailing list continuation service (we missed the 
deadline and did not opt in):


  https://alioth-lists.debian.net/
  https://wiki.debian.org/Alioth/MailingListContinuation

I do not know if we could still use it (I'd prefer wine-team@l.d.o anyway).


According to a mail to debian-devel[1] it is still possible to opt-in:

"Migrate the list the new system. This is still possible, please appoint 
a Debian developer as a list owner first, then contact the alioth lists 
migration team <ad...@alioth-lists.debian.net> and provide all the 
necessary information."


Since I don't know if we get a list at lists.d.o, and how long that 
would take, I guess we should do this.


Note: there's also #alioth-lists on irc.debian.org to contact the admins.

[1] "MBF: Defunct alioth addresses in the Maintainer: field (serious)", 
alioth-mbf-maintai...@msgid.manchmal.in-ulm.de





A3) salsa.d.o

Mike already created the "wine-team" at salsa.d.o.  [Thanks for adding 
me, whoever it was.].  I still need to investigate if this offers some 
good way of team communication, and how this works with the single 
package projects at salsa.  So I don't know if this could replace the 
need for a "real" mailing list.


I found nothing useful for team communication.




A4) tracker.d.o

We may also create a team at tracker.d.o.  Again, I don't know exactly 
what benefits this has, and how mail works with teams there.


Emails sent to team+@tracker.debian.org are discarded (#891504).

Once fixed this could be used for team communication, but team mails are 
not archived yet (https://salsa.debian.org/qa/distro-tracker/issues/14).


Further issues:
- Ownership can't be changed (#889163, Better team management)
- Bounce handler should manage team subscriptions too 
(https://salsa.debian.org/qa/distro-tracker/issues/12)


So a tracker.d.o team is not a replacement for the need of an 
mailinglist (yet), but useful generally in the long run with further 
tracker improvements.


Greets
jre

Bug#898066: [lists.debian.org] New mailing list: debian-wine (move from alioth)

[Jens Reyer]

Package: lists.debian.org
Severity: wishlist


Hi listmasters,

please accept the former mailing list

  Debian Wine Party 

on lists.debian.org.

I'm not formally requesting this yet, since I'd like to first have some 
official endorsement from the old team admins on alioth, and some 
general feedback on the details below.


Further I wasn't the owner of the old list.  I assume the owner of the 
old list was ovek at arcticnet.no, who wasn't active in the team (and 
Debian afaik) since 2011.  Do you have access to the old subscribers 
list, or know a way to get it?


If you're generally ok with the request, please tell me your formal 
requirements for the new owner (DD?).  I'm a member of the Wine team (as 
DM with upload rights for wine, wine-development and winetricks, and as 
developer in wine-team@salsa).


If you need more information I'd be happy to give answers.


The old archive is at
 https://alioth-lists-archive.debian.net/pipermail/pkg-wine-party/

I'll ask the other maintainers and other probably interested persons to 
write to this bug.  From the Wine perspective I discuss this at #897120.



Following are my proposed answers to the questions on
 https://www.debian.org/MailingLists/HOWTO_start_list


Name:
-
debian-wine


Rationale:
--
The list is used to coordinate the maintainers and interested persons in

  wine
  wine-development
  wine-gecko-N.NN (2.21 and 2.24 in the archive)
  winetricks
  exe-thumbnailer

The old list was used mostly, but not exclusively, for automated mails 
(bugs and archive uploads). But it was also used for direct team 
communication, and I assume not having a common address for these 
packages would be a major drawback for the Wine _team_.  E.g. it was my 
personal entry point in maintaining Wine after filing a few bugs.


The list is a single contact point for both Wine source packages (one 
tracking stable, the other development upstream releases, while 
sometimes bugs are reassigned from one to the other).  I get it that a 
tracker.d.o team would help to manage this 
two-source-packages-for-one-upstream setup, but at least for now, e.g. 
without a public archive for tracker, I don't see this as sufficient.


In the case of wine-gecko, which needs a new source package with every 
new version, it would also help to follow the development, or (since 
development is currently stalled) to re-start it.




Short description:
--
Maintenance of the Debian Wine and related packages



Long description:
-
Discussions about the packaging in Debian of Wine and related packages.

This list is not moderated; posting is allowed by anyone.

Posting address: debian-w...@lists.debian.org


Category:
-
Developers


Subscription Policy:

open


Post Policy:

open


Web Archive:

yes


Greets
jre

Bug#897120: Maintainer address is broken and team mailinglist is needed

[Jens Reyer]

Package: src:wine
Version: 3.6-1
Severity: important


Hi,

so pkg-wine-pa...@lists.alioth.debian.org doesn't work anymore since 
about 2 weeks.  The new maintainer address in wine's maintainer field


 w...@tracker.debian.org

also doesn't work.  Although I'm subscribed to the wine package at 
tracker.debian.org I do not receive mails sent there.




A) Possible solutions


A0) Short-term solution per package

 dispatch+$p...@tracker.debian.org

I've used dispatch+w...@tracker.debian.org in the x-debbugs-cc of this 
bug and it hopefully works. Since I do not know if the other maintainers 
are also subscribed to wine at tracker.d.o I also added their personal 
addresses explicitly there.
Documentation is at 
https://qa.pages.debian.net/distro-tracker/about.html#email-interface.


Now, I'd like to find a real team address again, which suits for the 
multiple packages (wine, wine-development, wine-gecko-X, winetricks,

exe-thumbnailer, anything-else?).
It should fit the needs of maintainers, other interested parties (e.g. 
upstream) and users.




A1) @lists.debian.org

Since the mailing list is also for discussion and coordination (not only 
automatic mails) I think we qualify to use e.g.


 wine-team@lists.d.o



A2) alioth-lists.debian.net

There's also the mailing list continuation service (we missed the 
deadline and did not opt in):


 https://alioth-lists.debian.net/
 https://wiki.debian.org/Alioth/MailingListContinuation

I do not know if we could still use it (I'd prefer wine-team@l.d.o anyway).



A3) salsa.d.o

Mike already created the "wine-team" at salsa.d.o.  [Thanks for adding 
me, whoever it was.].  I still need to investigate if this offers some 
good way of team communication, and how this works with the single 
package projects at salsa.  So I don't know if this could replace the 
need for a "real" mailing list.




A4) tracker.d.o

We may also create a team at tracker.d.o.  Again, I don't know exactly 
what benefits this has, and how mail works with teams there.





B) Subscribers

Currently people not too deeply involved in Debian will have no clue at 
all what happened, if they noticed anything at all.  Once we have a new 
team communication setup again, we should transfer all old subscribers 
there, or at least notify them.  Is there a way to get the list of the 
old subscribers (I'm neither the owner of the old mailinglist, nor am I 
a DD)?





C) Team name

Previously we were the "Debian Wine Party".  I don't mind at all to 
discard the "Party" from the name.


Currently we have these:

https://salsa.debian.org/debian/wine
Debian Wine Packages

https://salsa.debian.org/wine-team/wine
Debian Wine Packaging

debian/control.in
Debian Wine Party

Not sure if "Debian Wine Packaging" is the new "official" name, or only 
the description.  I'd be fine with that, although imo it's a bit to 
narrow for all related tasks.  I'd suggest "Debian Wine Team" in case we 
need a name somewhere.



And related: we also need to migrate all "other" team git repositories. 
Any existing plans here?



Greets and hoping for much feedback
jre

Bug#890276: RFS: wine/3.0-1~bpo9+1

[Jens Reyer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "wine"

 * Package name: wine
   Version : 3.0-1~bpo9+1
   Upstream Author : see AUTHORS file
 * URL : winehq.org
 * License : LGPL-2.1+
   Section : otherosfs

It builds those binary packages:

fonts-wine - Windows API implementation - fonts
libwine- Windows API implementation - library
libwine-dev - Windows API implementation - development files
wine  - Windows API implementation - standard suite
wine-binfmt - Windows API implementation - binfmt support
wine32 - Windows API implementation - 32-bit binary loader
wine32-preloader - Windows API implementation - prelinked 32-bit binary
loader
wine32-tools - Windows API implementation - 32-bit developer tools
wine64 - Windows API implementation - 64-bit binary loader
wine64-preloader - Windows API implementation - prelinked 64-bit binary
loader
wine64-tools - Windows API implementation - 64-bit developer tools

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/wine

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/w/wine/wine_3.0-1~bpo9+1.dsc

or from our git repository, branch stretch-backports

 commit dc601b2480c66f577d2d38f1ecf1c2017ad0d175

Changes since the last upload:

  * Rebuild for stretch-backports.
  * Make versioned dependency on debhelper backports safe.



I'm a member of pkg-wine and DM with upload rights for this package.  I
still need a sponsor this time, because this is the first upload to
stretch-backports and therefore has to go through backports-new.

My usual sponsor (in bcc) from pkg-wine intended to upload this
(http://lists.alioth.debian.org/pipermail/pkg-wine-party/2018-January/007014.html),
but has gone mia since.  A private mail from a few days ago is also
still unanswered, yet (I hope you're well!).  Therefore I'm asking here
in the hope to speed up things.

To build this package you need debhelper and unicode-data from
stretch-backports.  AFAIK uploading to backports-new requires at least
an binary-indep build (not only source).

Thanks and greets
jre



signature.asc
Description: OpenPGP digital signature

Bug#889158: [pkg-wine-party] Bug#889158: Package wine-development is less recent than wine

[Jens Reyer]

On 02/10/2018 06:58 PM, Joerg Schiermeier, Bielefeld/Germany wrote:
> Jens Reyer wrote:
>> Still, I'd love to understand what this bug was about.
> Maybe I'm too "German":

Maybe, welcome in the club ;)


> in WinHQ.orgs website both version were set to 3.0 when wine v3.0 was
> published. "wine-development" didn't follow this.
> In my point of view this was an error, which means: a bug. Every time when
> WineHQ.org publish a stable version also "wine-development" should have the
> same version as "wine". This will happen only one time a year.

I agree the current solution is not optimal, but duplicating one release
in two source package is not an option in Debian (tell me if I'm wrong
here).  If there's any other idea how to handle this, I'd be happy to
look into it, especially for the next release, which will probably be
shortly before the next Debian freeze/release (buster).


> At the end (this is to Jens Reyer):
> ¡Thank you for your great work about wine in Debian!

Thanks a lot!  But I can't do the intensity of Wine releated work, as I
did it recently, on a permanent basis.  I'm really just a part of this
team, and I hope to see others (old and new) to contribute here more again.

Greets
jre

Bug#889158: [pkg-wine-party] Bug#889158: Package wine-development is less recent than wine

[Jens Reyer]

[Adding the bugreport back in the address field]


On 02/06/2018 06:56 PM, Joerg Schiermeier, Bielefeld/Germany wrote:
> WineHQ |  Debian Package
> 
> stable version == wine
> devel. version == wine-development
> 
> Is this correct?

Yes, that's correct.  And it's what we are doing:

wine: 1.8.x, 2.0.x, 3.0.x (all stable releases)

wine-development: 2.1, 2.2, ..., 2.22, 3.0-rcx (all development
releases, and release candidates)

Maybe it's about the release candidates and where to put them?  For the
1.8 release they were in wine, for 2.0 and 3.0 in wine-development.


You wrote:
> The version of 'wine-development' has to be minimum the version of
> 'wine' and not below.

This is correct 52 weeks a year, but not when the stable release is the
most recent release.  So if the latest release is 3.0 (stable) and the
previous release 3.0-rc6 (development) then we will (and did) ship a
higher version number in wine:

wine/3.0-1
wine-development/3.0~rc6-1


> If not you may close this bug as solved/won't fix please.

I'll close it with wine-development/3.1-1.  Still, I'd love to
understand what this bug was about.

Greets
jre

Bug#889158: Package wine-development is less recent than wine

[Jens Reyer]

On 02/02/2018 08:10 PM, Joerg Schiermeier, Bielefeld/Germany wrote:
> the package version of 'wine-development' is lower than the version of 
> 'normal' wine:
> 
> wine-development: 3.0~rc6-1
> wine: 3.0-1
> 
> Since January 18th, 2018 until today the WineHQ versions were set to v3.0. 
> This was the version from their stable wine and also from their developer 
> version of wine.
> So this should also be in Debians package 'wine' and 'wine-development'! The 
> version of 'wine-development' has to be minimum the version of 'wine' and not 
> below. This is what the prefix '-development' means. Or not? Maybe I'm wrong.
> And: No, I didn't want to change the packages in my installation from 
> 'wine-development' to 'wine' for this period of same version between WinHQs 
> 'Wine stable release' and WineHQs 'Wine development release'
> 
> So this is a bug.

No.  Latest is not the same as development.  I didn't see 3.0 offered
upstream as -development (at least it's not in
https://dl.winehq.org/wine/source/3.x/), but that wouldn't change my mind.

And because of the duplication I definitely won't package stable 3.0
also as src:wine-development.

An exception to my first point might be if the stable upstream release
is too late in the Debian release cycle, so that src:wine gets the
previous stable, and src:wine-development the current stable release -
but currently we're just in the middle of the release cycle.

I'm just packaging 3.1 which will close this bug anyway.  If you just
wanted to request that version packaged: 36 minutes after its release is
a bit early.  But you're interest in wine-development is appreciated!

Greets
jre

Bug#885548: winetricks: Don't recommend gksu

[Jens Reyer]

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

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

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

Greets
jre

Bug#819255: nothing depends on wine-binfmt

[Jens Reyer]

control: tags -1 pending

Hi all,

On 01/19/2018 08:41 PM, Adam Borowski wrote:
>> This has also been brought up upstream in #39884 for their packages, and
>> is now being discussed in wine-devel
> 
> The discussion ended without a conclussion, be it for yes or for no.
> 
> Upstream's packages are monolithic, though, without a separate binfmt
> package, thus it's a valid dilemma there.  Your packaging is different.
> 
>> We might also add a low priority debconf question (default false) to
>> setup the binfmt support.
> 
> I just realized: as there's nothing that can make wine-binfmt automatically
> installed (the only relationships are Suggests:), this question has already
> been answered by the user: they made the manual step of installing this
> package.  On Debian, it is split out, and has no other contents than the
> binfmt.
> 
> Thus, every user who would want to answer "no" to such a debconf question
> wouldn't install the package.

I reread #733556 (binfmt-support got lost for PE32+) and follow-up bugs,
which already have some discussion of this topic.  They discuss the
security risks, and the risk of running an application already installed
in another prefix in the wrong prefix.  The 64-/32-bit issues mentioned
in these bugs are solved by the current Wine setup.  It seems nobody
explicitly objected activating binfmt-support as long as it is in a
separate package.

So I agree with Adam, and therefore committed the needed postinst and
prerm scripts to git (also attached to this mail).

I will not make an upload with these changes for at least 2 weeks, to
give everyone a chance to raise their voice.

I also updated the package description and the README, and added a NEWS
entry.  Please have a look at them, and tell me what you think.

Greets
jre
diff --git a/debian/NEWS b/debian/NEWS
index d632c989b3..d8b9e371ae 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,19 @@
+wine (3.0-2) unstable; urgency=medium
+
+  The package wine-binfmt (not part of a standard Wine installation) will now
+  automatically register Wine as interpreter for Windows executables.  This
+  causes Wine to be invoked automatically whenever a matching file is executed.
+  (Previously wine-binfmt only installed support for this, but you still needed
+  to activate it manually.)
+
+  Warning: This increases the risk of inadvertently launching Windows malware,
+  so please make sure that you understand the security risks before installing
+  this package.
+
+  For more information please refer to Wine's README.debian.
+
+ -- Jens Reyer <jre.wine...@gmail.com>  Sun, 28 Jan 2018 18:51:42 +0100
+
 wine-development (1.9.16-1) unstable; urgency=medium
 
   Debian has two sets of Wine packages: wine and wine-development. They now use
diff --git a/debian/README.debian b/debian/README.debian
index a4a093cc1f..15f650a15e 100644
--- a/debian/README.debian
+++ b/debian/README.debian
@@ -175,42 +175,55 @@ make sure that you understand the security risks before blindly setting this
 up.
 
 
-You can directly launch Windows executables from the command line if they have
-the executable bit set, and if they are either in PATH or you specify the path
-to them.
-
-To configure backend support for that, you'll need to execute:
-$ sudo apt install wine-binfmt
-$ sudo update-binfmts --import wine
-
-To remove this backend support again execute:
-$ sudo update-binfmts --package wine --remove wine /usr/bin/wine
-
-
-You can also make Wine known to your desktop environment.  Then you may for
-example in a filebrowser double-click on Windows executables to start them, or
-right-click on them to "Open With Wine Windows Programs Loader".
-
-Wine does this automatically for most file types supported by your installed
-Windows applications.  However this is disabled for basic ones in Debian, both
-for security reasons and to avoid unwanted associations with Wine while a
-preferred native application exists.
-
-To enable system-wide support for .exe files execute the following command
-(replace /usr/share/doc/wine with /usr/share/doc/wine-development if you use
-wine-development):
+System integration (binfmt)
+---
+If you install the package wine-binfmt Wine gets registered as interpreter for
+Windows executables.  So instead of executing "wine foo.exe" you may just use
+"./foo.exe".  Windows executables (including malware) might get auto-started
+this way, even as root.  For this to work, the executable has to be on PATH (or
+its path must be specified), and the executable mode bit must be set.
+
+This feature is probably most interesting for automatic software testing.
+Desktop users probably don't need it, so don't install wine-binfmt, unless you
+know that you need it.
+
+
+Desktop integration
+---
+To make Wine known to your desktop environment you can install a wine.desktop
+file.  Then you may 

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

[Jens Reyer]

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


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


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

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

Greets
jre

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Jens Reyer]

On 01/10/2018 09:07 PM, Javier Serrano Polo wrote:
> El dc 10 de 01 de 2018 a les 19:51 +0100, Jens Reyer va escriure:
>> I'm not sure if you suggest to make libwine (instead of wine) the
>> alternatives-master for all Wine packages - I think that wouldn't work,
>> because each arch has its own libwine, so we'd have multiple master.
>> Feel free to prove me wrong.
> 
> Then make libwine depend on a wine-alternatives package that ships the
> update-wine-alternatives script.

No, then we'd have no master at all (or did I miss something?).  The
"update-wine-alternatives script" is in 3 files
(debian/wineVERSION.{postinst,prerm,triggers}).  It's core is:

  update-alternatives --quiet \
--install /usr/bin/wine wine /usr/bin/wineDEBSUFFIX $PRIORITY \
  $slaves

The second line is about the master, we always need it.  And I want the
master to be "wine", not "libwine.so.0" (e.g. master's name is used in
the user interfacing command "update-alternatives --config wine").  So I
still see no alternative to using wine(-development) for the
alternatives scripts, and using /usr/bin/wine as master.



Now, unfortunately there's also another thing I missed here: upstream
does not consider libwine to be a general-purpose library. We discussed
that because they call exit in this shared library:

https://www.winehq.org/pipermail/wine-devel/2016-October/114992.html
"The reason for this is that libwine is not like other libraries where
Debian's check may make sense.  It's not a general-purpose library.
It's only really useful for Wine itself and for a program which wants to
be an alternative Wine loader.  The client of libwine will want it to
call exit() when needed."

I should have thought about this earlier, but imo this shows that making
libwine public is wrong.
If lmms-vst-server handles the use of exit in libwine well, I think it's
ok to use rpath to link to the private lib.


To sum up, these are the issues:
- upstream considers libwine to not be a general-purpose library
- I'm not sure how stable its api is
- Imo we should stay with pkg:wine(-development) providing the
  master /usr/bin/wine


Any other opinion? Close this bug?


Greets
jre

Bug#852494: wine: Add libwine.so and libwine.so.1 alternatives

[Jens Reyer]

Hi Javier and Mike,


On 06/17/2017 11:16 PM, Michael Gilbert wrote:
> control: tag -1 moreinfo
> 
>> Please add a libwine.so.1 alternative to libwine packages, and
>> libwine.so to libwine-dev ones.
> 
> There are no reverse dependencies of libwine, so it is not clear to me
> how this would actually be helpful.  Do you have a specific problem
> where it would be, if so what is it?

AFAIK Javier needs it for lmms.


On 01/24/2017 11:15 PM, Javier Serrano Polo wrote:
> The alternatives should not be slaves in the wine package. I suggest to
> move the slave alternatives from wine package to their respective
> packages (wine32-tools and such), and to depend on an
> update-wine-alternatives script (in libwine) that runs
> update-alternatives for the installed packages.

I'm not sure if you suggest to make libwine (instead of wine) the
alternatives-master for all Wine packages - I think that wouldn't work,
because each arch has its own libwine, so we'd have multiple master.
Feel free to prove me wrong.

Alternatively you might ask for the libwine-alternatives to be separate
from the other Wine-alternatives - I don't feel comfortable about having
main Wine and libwine potentially pointing to different Wine versions.

So why not make libwine a slave of wine and let it recommend wine, like
I did for the other packages?  AFAIK "recommends" are not installed for
build-dependencies, so you'd need to explicitly build-depend on wine in
lmms - but imo that's acceptable.  Of course you would have wine, and
wine32 or wine64 (or both if e.g. i386 is available on the build-daemon)
installed unnecessarily then - but their installed size is very small
compared to libwine (and its dependencies).  The only real drawback I
can think of is having potentially unwanted Wine binaries on PATH.
Still, that's what I'd suggest.

Having said all this, I have no experience with packaging system
libraries.  Can we just stay with soversion .0, or do we have to check
if the Wine API changes (sounds strange since Wine is supposed to
provide a stable (!?) Windows API)?  What do others think?

Greets
jre

Bug#883973: fonts-wine: Please move the ttf/otf fonts to /usr/share/fonts

[Jens Reyer]

On 12/09/2017 11:01 PM, Rogério Brito wrote:
> For the benefit of other programs (thinking here especially of evince/atril
> and other PDF viewers, but also for people that need to collaborate with
> Windows users in an office environment), please put the Tahoma clone and
> other fonts under /usr/share/fonts.

We had the fonts there in the past.  AFAIK we only moved them to the
current position, because back then there was a bug in Wine which
required fonts to be in a specific place.  But this is fixed now, so I
think, we can probably do that.


Did you successfully test this for "the other purpose"?  AFAIK the Wine
fonts are greatly reduced in which glyphs they provide.  On the other
site those are probably very uncommon glyphs.

If we move the fonts, then I guess we have to move all fonts.  Not only
the ttf (marlett.ttf, symbol.ttf, tahomabd.ttf, tahoma.ttf,
wingding.ttf), but also a bunch of *.fon fonts.  Does anyone know if
they work for other applications, and if they are acceptable for a
system-wide position at all?

Greets
jre

Bug#885860: [pkg-wine-party] Bug#885860: wine registers mime handlers with too high priority

[Jens Reyer]

control: tags -1 + moreinfo

Hi Michal


On 12/30/2017 03:07 PM, Michal Suchanek wrote:
> Package: wine
> Version: 1.8.7-2
> Severity: important
> 
> Hello,
> 
> once you install wine text files open in notepad, pictures, PDFs and
> HTML files in winebrowser.
> 
> This breaks the desktop integration.
> 
> It is fine to install these alternatives as very low priority but the
> priority for thes slow-starting nearly useless applications in the
> highest. Higher than gedit, evince, gqview, imagemagick, ..
> 
> This is broken
> 
> Please fix the priority of wine pre-installed applicatins to work with
> the rest of the distribution.

This should be fixed since wine 1.8.6-2 (see #845334), by not
associating some file types at all.

Did you run a previous version of Wine for your user sometimes in the
past?  Or some other version of Wine (not from Debian)?  Then that would
have broken your system.  Unfortunately there's no good way for us to
automatically fix already broken systems.

Or can you still reproduce this for a new user with an previously
unbroken account?  If yes, can you give me more details so that I can
figure out what's going wrong?

Greets
jre

Bug#884016: Again: Could not load wine-gecko. HTML rendering will be disabled.

[Jens Reyer]

control: reassign -1 src:wine-gecko-2.24
control: affects -1 src:wine-development
Control: merge -1 824193


> On Sun, 10 Dec 2017 15:11:46 +0100, "Joerg Schiermeier, Bielefeld/Germany"
>  wrote:
>> So: there is something wrong with wine-gecko I guess. This isn't new in
>> wine-development because this error appears some versions of
>> wine-development before. But I can't remember when it hits the ground
>> first. (Maybe a half year ago?) And it seems to be a Zombie: see issue
>> #783428.
> 
> Yes, I need to get round to finishing the license review of the current
> upstream version of Gecko...

Besides this real and favorable solution, there's already the existing
workaround to manually download wine-gecko (and wine-mono) installers.
See /usr/share/doc/wine-development/README.Debian.gz or
https://anonscm.debian.org/git/pkg-wine/wine.git/tree/debian/README.debian#n135

When you reported #783428 this was broken first, but fixed then.  Since
you didn't have this issue for some time, but it started again, I assume
that you deleted your wineprefix and your manually downloaded and cached
wine-gecko installers.

So this should work (it does so here with 3.0~rc1-1):

$ mkdir -p ~/.cache/wine
$ cd ~/.cache/wine
$ wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86.msi
$ wget http://dl.winehq.org/wine/wine-gecko/2.47/wine_gecko-2.47-x86_64.msi

If not, then there might be a new bug.

Greets
jre

Bug#881617: Bug#882325: marked as done (wine32: Cannot install wine32 on strech. libwine:i386 problem)

[Jens Reyer]

On 11/26/2017 09:19 PM, Michael Gilbert wrote:
> From: Jens Reyer
>> Clearly something wrong here, buster/sid mixed with stable.  I'm closing
>> the bug because mixed systems are not supported.
> 
> This is a common misconception about Debian.  Mixed suites are a
> supported, although not very well advertised, feature.
Of course, everyone is free to run a mixed setup.  I've also done
stable+testing for a long time in the past.  And there are good chances
that it works, as long as you know how to solve package conflicts.  But
the longer you are in a release cycle, with more transitions having
happened, the harder it will get to solve these issues, and you will
have to go more and more to a pure buster setup.

And so far this is only for the package relations with known issues,
which resulted in e.g. versioned dependencies.  I'm not aware of any
infrastructure which tests mixed setups, any maintainers which test
their buster packages in stretch and officially advertise this as
feature, or any user support channel which is generally helping here.

In the wiki we explicitly discourage doing this
(https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian).

Users of this feature need to know that they're on their own when doing
this, and that they cannot expect any support.  Sending them this route
might seem to be a good solution in the beginning, but it might end very
bad for them in the long run.  At least they most probably won't have
stable with just-this-app-from testing, but instead either a mostly
testing system, or a not-updated system.

Greets
jre

Bug#881617: [pkg-wine-party] Bug#881617: wine-development: wine32 creates win64 prefixes: wine prefer win32 on amd64 while wineserver prefer win64

[Jens Reyer]

Oh, and about the inconsistency:  yes, the wine wrapper /usr/bin/wine
defaults to the loader (from wine32) /usr/lib/wine/wine, while the
wineserver wrapper defaults to /usr/lib/wine/wineserver64.  But that's
absolutely correct:

Even if you run a 32-bit prefix wineserver64 is the right choice, you
don't need wineserver32 for that.  If you're building Wine from vanilla
upstream for 32- and 64-bit you end up with just exactly that binary.
And if you want something like vanilla upstream built only for 32-bit
you just have to uninstall wine64, so that /usr/lib/wine/wineserver32 is
used.

The 32-bit wine loader is also the right choice for starting wine, even
if you want to run a 64-bit Windows application.  I'm quite sure that
you're never expected to call wine64 directly.

Greets
jre

Bug#882325: [pkg-wine-party] Bug#882325: wine32: Cannot install wine32 on strech. libwine:i386 problem

[Jens Reyer]

control: tags -1 moreinfo

Hi

this is usually because of version mismatches between amd64 libraries
and their i386 counterpart. Since Wine depends on *many* libraries which
need to come from *both* an 32-bit architecture and an 64-bit
architecture users are often hit by this issue.

To figure out which library exactly causes the problems please go down
the dependency chain until you find the real culprit, e.g.:

sudo apt install update
sudo apt install libncurses5:i386
...

Then report back.

See also these two bugs:

https://bugs.debian.org/879453 (some amd64 libraries were already
installed from backports, but their new-to-be-installed i386
counterparts per default come from pure stable) and

https://bugs.debian.org/865387 (no fully updated system).

Greets
jre

btw: Would be great if someone put this on https://wiki.debian.org/Wine.

Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX

[Jens Reyer]

Hi again Sven

On 10/30/2017 05:56 PM, Sven Joachim wrote:
> On 2017-10-29 21:04 +0100, Jens Reyer wrote:
>> If this solves the issue we definitely should talk to upstream.
> 
> That seems reasonable since the problem is not specific to Debian.

Unfortunately I still can't reproduce this, instead I get other issues.

(They were partly fixed by the recent xdg-utils 1.1.2-1 update.  For the
tests I made sure that gio open/xdg-open default to your .desktop file
from post #1, and tried to open a pdf.  Here this starts wine, but ends
up in an infinite loop of restarting it, but without giving "your" error
message.  This happens both with and without quotation marks here.)

So I'd like to ask you to file a bug at https://bugs.winehq.org/ (note
the info on https://wiki.winehq.org/Bugs).

Please verify if the old .desktop file still causes problems today
(remember that we have a Debian specific patch which prevents the
creation of these general .desktop files today), and if your solution
still works.  (Of course I expect both to do so.)

If you have any uncommon system-settings that might also be noteworthy
information.

Further you might mention the other url from the ARCH user, and this bug
here.

Following that please send a mail to this bugreport starting with the
following lines (X obviously being your new bugnumber):

control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=X
control: tags -1 - moreinfo + upstream

Greets
jre

Bug#879453: wine32: Unmet dependencies in Stretch

[Jens Reyer]

On 11/04/2017 12:07 AM, Omar Jair Purata Funes wrote:
> Apt policy reveals:
> 
> apt policy libsystemd0
> libsystemd0:
>   Installed: 234-3~bpo9+1
>   Candidate:  234-3~bpo9+1
>   Version table:
>  *** 234-3~bpo9+1 100
> 100 http://deb.debian.org/debian stretch-backports/main amd64
> Packages
> 100 /var/lib/dpkg/status
>  232-25+deb9u1 500
> 500 http://deb.debian.org/debian stretch/main amd64 Packages
> 
> And:
> 
> apt policy libsystemd0:i386
> libsystemd0:i386:
>   Installed: (none)
>   Candidate:  232-25+deb9u1
>   Version table:
>  234-3~bpo9+1 100
> 100 http://deb.debian.org/debian stretch-backports/main i386
> Packages
>  232-25+deb9u1 500
> 500 http://deb.debian.org/debian stretch/main i386 Packages
> 
> second triggers a lot of packages removal (system is up to date).
> 

Ah, so for whatever reason you have libsystemd0 installed from
stretch-backports on amd64.

If this was not intended and is not required by some other package you
might try to downgrade it (and eventually other packages) by installing
the regular stretch version again.  (Downgrades are not officially
supported but usually work.  I recommend to keep as many packages as
possible in their pure stretch version.)  Something like:

sudo apt install libsystemd0/stretch


Alternatively you might just start with installing libsystemd0:i386 from
stretch backports:

sudo apt install libsystemd0/stretch-backports


As soon as you have libsystemd0 (and all other problematic packages)
installed on both amd64 and i386 you can try wine again.


Greets
jre

Bug#879453: wine32: Unmet dependencies in Stretch

[Jens Reyer]

[Re-adding the bug in CC]


On 11/03/2017 04:24 PM, Omar Jair Purata Funes wrote:
> Tried to install it until finding a "stop". The first one came with
> "libwine:i386", trying to install this library throws 2 more faulty
> ones, libldap-2.4-2:i386 & libpulse0:i386, trying to install
> libldap-2.4-2:i386 prompts to remove the entire desktop, and libpulse0:i386
> needs libsystemd0:i386 which breaks the whole system if installed.
We probably had the same report in #865387.

Please fully update your system:

sudo apt update && sudo apt upgrade


If this doesn't solve the issue make sure that the system tries to
install the correct version.  They have to be identical for the amd64
and the i386 version.  These commands might help in figuring out what is
wrong:

apt policy libsystemd0
apt policy libsystemd0:i386

Good luck and please tell us the results.

Greets
jre

Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX

[Jens Reyer]

On 10/29/2017 08:43 PM, Sven Joachim wrote:
>> However I'm still absolutely clueless and ask for help to solve this
>> issue at its root:
>>
>> I see the check for the wineprefix starting with a "/" (slash, no
>> quotation marks) in libs/wine/config.c[1], which is indeed the only
>> place in the code which has the mentioned warning.  But I assume (I'm
>> not a C coder) that the quotation marks are not relevant here.
> 
> I am not the greatest C programmer, but they seem very relevant, since
> in the generated .desktop files the first character is a quotation mark
> rather than a slash.

I was just thinking that the quotation mark is not part of the actual
variable.

You might restore the
~/.local/share/applications/wine-extension-pdf.desktop from post #1 and
try to reproduce the issue.  Then edit the file and remove the quotation
marks, and check again.
If this solves the issue we definitely should talk to upstream.

> 2. 
> https://unix.stackexchange.com/questions/231092/firefox-tries-to-open-tex-files-with-wined-notepad

The general topic there is about the unneeded extension associations,
which we have removed in Debian in the meantime.
Our specific issue for "not an absolute path" is observed there by an
Arch Linux user, so it seems the issue is indeed not Debian specific.

Greets
jre