https://bugs.winehq.org/show_bug.cgi?id=48878
--- Comment #7 from Luca Boccassi luca.boccassi@gmail.com --- (In reply to Rosanne DiMesio from comment #6)
(In reply to Luca Boccassi from comment #0)
The first one adds postints and a dependency on libcap-bin, so that wineserver, wine-loader and wine64-loader can get cap_net_raw added on installation.
I've asked the wine-staging maintainers to weigh in on that.
Thanks - note that this applies to all 3 flavours, not just -staging. I just don't know where the "true source" lives, so I don't have a base to generate patches from. I've picked staging because it's what I use. Is there a repository?
The second patch improves debian/rules so that it does out-of-tree automake builds in debian/build-$ARCH. This is the first step to allow multi-arch builds to work more smoothly.
"More smoothly" is rather vague; exactly what problem with the WineHQ packages does this solve? i586 and x86_64 builds are done separately on the OBS, and I've seen no evidence this causes a problem for users of our packages.
A user/developer can do apt source -b winehq-<foo> and, without having to use any i386-specific host/chroot of any form, can build both sets of packages. I've used this extensively while bisecting issues, for example. By building and installing the packages I can be 100% sure that there's no differences due to prefixes, and that everything that is installed is then tracked and removed by dpkg. No leftovers lying around. Note that it's no longer just more smoothly, but it now fully works with the second patch.
Also it's about quality: using DEB_BUILD_ARCH to do checks for the target architecture is just wrong - this is because of the very confusing GNU nomenclature of course, but it's still good to fix. Using ln without -f is also not great - it makes incremental builds not possible.