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

Re: Google use clause conflicting with Apache 2.0

[Jens Reyer]

Hi Hugh

On 23.08.19 16:30, Hugh McMaster wrote:
> In the ITP thread, Jonas pointed out that Google requests users of the
> font to not sell the icons – a request that is seemingly incompatible
> with the Apache 2.0 licence.
> 
> Unfortunately, there is no official clarification on this conflict,
> although non-official interpretations say Google just don’t want people
> reselling the icons by themselves.
> 
> How should I manage this conflict with the Apache 2.0 licence?

I guess you refer to
https://github.com/google/material-design-icons/blob/master/README.md
~
We have made these icons available for you to incorporate into your
products under the Apache License Version 2.0. Feel free to remix and
re-share these icons and documentation in your products. We'd love
attribution in your app's about screen, but it's not required. The only
thing we ask is that you not re-sell these icons.
~

Given
 "We'd love attribution [...], but it's not required."
the next sentence
 "The only thing [...]"
seems to be a real requirement (practically being a part of the license).

But a clarification from upstream would indeed be helpful.  Both the
language ("ask") and the split over separate files is at least confusing.


> Alternatively, there is an active fork [2], which contains Google’s font
> files with fixes for missing icons etc., but no icon files or images.
> Thefork is licensed with Apache 2.0 as well, but with no extra clauses.
> 
> Is it more sensible (and feasible) to package the fork instead of the
> official package?

For license reasons: no, a fork can't change the license without
upstream's consent.  But looking at the fork's README.md I see the same
paragraph there anyway.

For content reasons it might be a good idea.

Greets
jre

Re: Sharing a script between two "Multi-Arch: foreign" packages

[Jens Reyer]

Hi Wookey and Sven,

thanks for your answers!  They helped to stop looking for a non-existing
solution, but find a (nearly) clean one:

(ab)use libwine (M-A:same) for the wineserver wrapper script.


On 06.08.19 17:03, Wookey wrote:
> On 2019-08-06 16:45 +0200, Jens Reyer wrote:
>> Hi all,
>>
>> is there a way for two different, arch-specific packages (from the same
>> source package) to share an identical file (script)?
> 
> Only if those two arch-specific packages have the same name -
> i.e. they are the 'same' package from dpkg's point of view, just
> arch-specific variants of it.
> 
>> This works for "Multi-Arch: same" packages:
>> $ dpkg -S /usr/share/doc/libwine/changelog.Debian.gz
>> libwine:i386, libwine:amd64: /usr/share/doc/libwine/changelog.Debian.gz
>>
>>
>> $ dpkg -S /usr/lib/wine/wineserver
>> wine32:i386, wine64:amd64: /usr/lib/wine/wineserver
> 
> If I understand correctly you want 'wine32' and 'wine64' (different
> packages) to share a file.

Yes.


> dpkg has special magic to notice that files in multiarch:same packages
> which are in fact identical may be installed over each other without
> complaining about clashes, and mark tham as being owned by all the
> install arch variants, and not remove them until the last version of
> the package is removed.
> 
> Otherwise a file is always owned by exactly one package.
> 
> So if you could arrange to just have a 'wine' binary that was 32 or 64
> as required then you could make this work as you want. Otherwise you
> need both those packages to depend on another wine-startup or whatever
> that contains the shared file.

Instead of adding this new package "wineserver", I'm (ab)using libwine
now (which is "M-A: same" and depended on by wine32 and wine64 which
have the binary).

The only drawback is that libwine now ships a wrapper script for
binaries, which are in packages that libwine doesn't depend on.  I don't
expect this to be an issue in practice, but still added a clear error
message for that case.


> (I think - I admit I haven't fully groked the wine package layout)

Yeah, we're special ;)
I'd be happy to explain this in more depth, just tell me.

Greets and thanks again
jre

Sharing a script between two "Multi-Arch: foreign" packages

[Jens Reyer]

Hi all,

is there a way for two different, arch-specific packages (from the same
source package) to share an identical file (script)?


This works for "Multi-Arch: same" packages:

$ dpkg -S /usr/share/doc/libwine/changelog.Debian.gz
libwine:i386, libwine:amd64: /usr/share/doc/libwine/changelog.Debian.gz


But if I try [1] the same for two different packages I end up with only
one package being the owner:

$ dpkg -S /usr/lib/wine/wineserver
wine32:i386: /usr/lib/wine/wineserver


Instead of [fictious output following]:

$ dpkg -S /usr/lib/wine/wineserver
wine32:i386, wine64:amd64: /usr/lib/wine/wineserver



Background:

See #932201.

In src:wine we have two M-A: foreign packages:
 pkg:wine64 (built on some 64-bit architectures)
 pkg:wine32 (built on some 32-bit architectures)

Both build and install a "wineserver" binary, which we install as
/usr/lib/wine/wineserver32 or wineserver64.  We call that binary from a
script [2] /usr/lib/wine/wineserver which currently is in pkg:wine
(arch:all), which is only "recommended" [3] by pkg:wine32 or pkg:wine64.

Since the wineserver{32|64} file is not found by the Wine code, these
filenames are broken without our wineserver script.  So I'd like to move
that script to pkg:wine32 and pkg:wine64.


Thanks and greets
jre


[1] I get both wine32 and wine64 to install with these breaks/replaces:

Package: wine32
Architecture: any-i386 any-powerpc armel armhf
Multi-Arch: foreign
Breaks:
 wine64VERSION (<< ${binary:Version})
Replaces:
 wine64VERSION

Package: wine64
Architecture: amd64 arm64
Multi-Arch: foreign
Breaks:
 wine32VERSION (<< ${binary:Version})
Replaces:
 wine32VERSION

... but then the "shared" wineserver script is only owned by one
package.  Without this unversioned "replaces" dpkg refuses to overwrite
the (identical) script

[2] There are also unrelated reasons for having this script.  Otherwise
I'd dpkg-divert the 32-bit wineserver in favor of the 64-bit one, which
would perfectly match the way Wine works (Wine uses the 32-bit
wineserver only for pure 32-bit installations, but the 64-bit server for
mixed and 64-bit installations).
I could dpkg-divert the script, but that looks like a workaround, not a
solution, to me.


[3] pkg:wine already "depends" on pkg:wine32|wine64, so to avoid a
circular dependency I can't also "depend" the other way round.
The only solution here would be to make a separate arch:all
pkg:wineserver which only has the wineserver script, and let pkg:wine32
and pkg:wine64 "depend" on that.  While this would be a clean solution,
it seems to be excessive to ship only one small wrapper script in a
separate package.

Thanks and 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#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

Re: Dependencies across architectures

[Jens Reyer]

I forgot: the arch specific package needs a Depends on the arch:all
package, which has the wrappers.

Re: Dependencies across architectures

[Jens Reyer]

On 01/07/2018 05:39 PM, Wookey wrote:
> On 2018-01-07 19:23 +0800, Paul Wise wrote:
>> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>>
>>> If we take Multi-Arch serious, this shouldn't be the case, right?
>>
>> I guess the release team might accept patches to britney for this but
>> I've also a vague memory that they prefer arches to be self-contained.
> 
> This issue affects so few packages that no-one has put in the effort
> to make this (automatic migration with cross-arch dependencies) work.
> I talked about it with respect to doing this for cross-compilers and
> they were OK with doing this properly this so long as there was a good
> reason (but in the end cross-compilers were done a different way so
> there was no need). In the meantime there is a rather hacky whitelist
> for the few packages that do need this (basically wine IIRC).

As *workaround* for this problem you might use some wrapper:

Indeed Wine is closely related to this issue, but we solved the problem
in another way: Wine needs some architecture specific packages which are
only available on either 32-bit or 64-bit.  So our common case on amd64
is that we need to depend on a i386 package.

However we don't use any hard cross-architecture dependencies (any
more?), only "soft" cross-architecture dependencies:  either Depends
with an alternate package from the same architecture, or Recommends.  In
our case:

 wine (arch:all)
 depends:
 wine32 (only 32-bit archs) | wine64 (only 64-bit archs)

We additionally have a wrapper script /usr/bin/wine (in wine) for the
main Wine binary (in wine32).  It gives a warning on console with
instructions how to install the foreign package wine32.  Using
wine64-only is possible, but in most cases wine32 is also wanted.  So
just warning on console, but still trying to run Wine, fits our needs
quite good.


Another affected package is playonlinux.  Its users rely on wine32 even
more then Wine users, so its maintainer would like to depend on wine32
(see: #798780).  For now he chose to just depend on wine, but afaik
plans to add some wrapper with a warning if wine32 is missing.  This
would need to be a graphical one, maybe using zenity.)


I don't know if lowering the dependency to recommends and using a
wrapper script would be a good solution for pyraf.  Assuming "iraf" is
absolutely required to make use of the application, that would mean in
the wrapper you'd need an error message which aborts (and not only warns
as in Wine's case).  Thus one could argue that python3-pyraf is buggy
because it lacks the Depends on iraf.  Counterargument would be that the
wrapper exits cleanly and at least gives _instructions_ how to add a
foreign arch and what to install then.

Greets
jre

Re: What option should I now use to do source only builds

[Jens Reyer]

Hi Andreas

On 03/17/2017 11:32 PM, Andreas Tille wrote:
> Hi,
> 
> I have understood from NEWS.debian of pbuilder 0.228 that the '-S'
> option does not work any more.  Unfortunately I did not understood what
> I need to do now to do a source only build (nor what the problem of this
> simple way was).

James Clarke wrote in https://bugs.debian.org/853886#10:

"For source-only builds, I don't understand why you would want to
perform the build in a chroot. You already have to be able to build the
source package outside the chroot, which then gets copied into the
chroot, unpacked and a new source package is built; why not use the
first source package? If your aim is to check the package builds, you're
not actually building any binary packages; you should instead use the
new --source-only-changes option, which will build binary packages but
also generate a source-only changes."

Personally I now use with gbp:
--git-pbuilder-options="--binary-indep --source-only-changes"

Alternatively Mattia suggested something like:
--git-pbuilder debuild -S

Greets
jre

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Jens Reyer]

Hi Alec [answering on debian-mentors]

On 08.11.2016 13:39, Alec Leamas wrote:
> In particular:
>   - How can I handle that kfreebsd should install a different set of
files?

Never done that, but I guess use dh-exec filtering in the
debian/*.install files.

>   - Is it possible to conditionalize the rules file w r t platform?
>   - If so, how?

debian/rules:
ifeq ($(DEB_BUILD_ARCH_OS), kfreebsd)
...
endif


debian/control (don't depend on package foo on kfreebsd-i386 and
kfreebsd-amd64):
foo [!kfreebsd-any]

Greets
jre

Re: .desktop file handling

[Jens Reyer]

On 15.09.2016 09:21, Shawn Sörbom wrote:
> Hi
> I have run into a few projects lately that don't include .desktop files but 
> should. my usual approach to handle this is to write a patch with quilt that 
> writes a .desktop file to the project's root directory, then add a 
> corresponding line to the debian/[package].install file. I know this approach 
> works, but is it the "right" way? Does it matter?

There's also the command desktop-file-install (in the optional package
desktop-file-utils) which validates and installs the desktop file. I'd
use that command at least once for the validation.

For installation in Debian it is unnecessary (Debian policy 9.6 tells us
that for installing it is not necessary because of dpkg triggers.
Further I found that at least in Gnome manually copying (no dpkg) to
/usr/share/applications has an immediate effect).

Still upstream might be interested in that (not sure).


A quick look to sources.debian.net shows a clear preference for simply
installing desktop files:

.desktop in debian/*install:  95 pages of results [1]
desktop-file-install in debain/rules:  2 results [2]

[1]
https://codesearch.debian.net/search?q=path%3A%2Fdebian%2F.*install+.*desktop+

[2]
https://codesearch.debian.net/search?q=path%3A%2Fdebian%2Frules+desktop-file-install+

Greets
jre

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

On 28.05.2016 12:30, Jakub Wilk wrote:
> * Jens Reyer <jre.wine...@gmail.com>, 2016-05-27, 20:17:
>> I think I have it working now in wine to automatically generate a list
>> of runtime dependencies. I based it on Jakub's suggestions, however I
>> didn't go for creating a "dependency binary".
>>
>> For one I did get results this way, but unfortunately I neither really
>> know python nor perl which is usually used in wine packaging, in order
>> to cleanly implement it there.
> 
> I've attached shell implementation of SONAMEs-to-ELF converter.

First off, many thanks again for that script. Unfortunately it fails in
Ubuntu (see #827770):

./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3
libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30
libgsm.so.1 libjpeg.so.8 libncurses.so.5 libodbc.so.2 libopenal.so.1
libOSMesa.so.8 libpng16.so.16 libtiff.so.5 libX11.so.6
libXcomposite.so.1 libXcursor.so.1 libXext.so.6 libXi.so.6
libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libxslt.so.1
libXxf86vm.so.1 > debian/tmp/elf.recommends
/usr/bin/ld: cannot find libGL.so.1
collect2: error: ld returned 1 exit status
debian/rules:153: recipe for target 'override_dh_shlibdeps' failed

In Ubuntu libGL.so.1 is in /usr/lib//mesa/. However this does not
cause issues for other Debian packages for finding it (probably by
looking at /etc/ld.so.conf). I assume one could explicitly specify the
rpath in sonames2elf, but do you have any idea how to solve this
generically/why this doesn't work?

Greets
jre

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

On 05/28/2016 07:17 AM, Paul Wise wrote:
> On Sat, May 28, 2016 at 2:17 AM, Jens Reyer wrote:
> 
>> Then (instead of creating a binary linking to the required
>> libraries and running dpkg-shlibdeps on this) I replicate things
>> from dpkg-shlibdeps(1) to identify the library package names for
>> these sonames:
> 
> I wonder if the best solution would be to allow dpkg-shlibdeps to
> accept a list of SONAMEs instead of getting that from an ELF file.
> Then you could do something like this:
> 
> dpkg-shlibdeps -pdlopen -dRecommends -alibc.so.6
> 
> Until that is available it seems to me that Jakub Wilk's method of
> generating an ELF binary with NEEDED entries for the relevant SONAMEs
> is much simpler and less error prone than essentially reimplementing
> dpkg-shlibdeps. A modification to the upstream build system could
> probably auto-generate the ELF binary and once you have the ELF
> binary, you can just do this:
> 
> override_dh_shlibdeps:
> dpkg-shlibdeps -pdlopen -dRecommends -etheelfbinary
> dh_shlibdeps

Thanks! Turns out your suggestion for dpkg-shlibdeps has already been
requested:

#596715 (dpkg-shlibdeps: Please allow to manually add library
dependencies via shlibdeps)

#548463 (dpkg-shlibdeps: Please provide a method to compute dependencies
for non-elf)

Greets
jre

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

On 05/28/2016 12:30 PM, Jakub Wilk wrote:
> * Jens Reyer <jre.wine...@gmail.com>, 2016-05-27, 20:17:
>> I think I have it working now in wine to automatically generate a list
>> of runtime dependencies. I based it on Jakub's suggestions, however I
>> didn't go for creating a "dependency binary".
>>
>> For one I did get results this way, but unfortunately I neither really
>> know python nor perl which is usually used in wine packaging, in order
>> to cleanly implement it there.
> 
> I've attached shell implementation of SONAMEs-to-ELF converter.
> 
>> sonames=$(shell grep  "^\#define SONAME_" include/config.h | cut -d\"
>> -f2)
>> paths=/usr /usr/lib /lib/$(shell dpkg-architecture
>> -qDEB_HOST_MULTIARCH) /usr/lib/$(shell dpkg-architecture
>> -qDEB_HOST_MULTIARCH)
>> dlopenRecommends=$(shell \
>>for soname in $(sonames); do \
>>for path in $(paths); do \
>>file=$$(echo $$path/$$soname | sed "s|//|/|g"); \
>>[ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\)
>> */\\1,/" && break || true; \
>>done; \
>>done)

Massive thanks again, Jakub, that helped a lot to understand and
implement. As additional benefit I now also get alternative dependencies
(libgl1-mesa-glx|libgl1). I implemented it similar to what Paul suggested.

Should I put your coyright and the MIT/X11 (BSD like) license in the
script, as seen in dctypes2elf? Wine itself is LGPL-2.1+ licensed.

Greets
jre

Re: Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

On 05/19/2016 05:53 PM, Jakub Wilk wrote:
> * Jens Reyer <jre.wine...@gmail.com>, 2016-05-19, 16:57:
>> First off, I'm not sure about every single dependency if it is needed
>> at all.
> 
> Quick grep over the *.dll.so indeed shows that they use a bunch of
> libraries you mentioned:
[...]
> I guess a better method of obtaining the list of used shared libraries
> is to grep for "SONAME_" in include/config.h (after it was created by
> the configure script).
> 
> Once you have the list of needed shlibs, the simplest way to compute
> package dependency is to create an ELF that depends on all of them, and
> then use dpkg-shlibdeps against it.
> 
> You can steal the idea of how to create such ELF here:
> https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf

Thanks a lot Jakub and Gianfranco!

I think I have it working now in wine to automatically generate a
list of runtime dependencies. I based it on Jakub's suggestions,
however I didn't go for creating a "dependency binary".

For one I did get results this way, but unfortunately I neither
really know python nor perl which is usually used in wine
packaging, in order to cleanly implement it there. Generally more
relevant however, since I probably found a Makefile/shell
solution, I'd like to keep it as simple as possible.

I chose to (as suggested) first check for all sonames in
include/config.h after configure. This gives similar results as
grep'ing  for *.so (and a lot more than for *.dll.so). The
differences are only for shlibs, which are not relevant here.

Then (instead of creating a binary linking to the required
libraries and running dpkg-shlibdeps on this) I replicate things
from dpkg-shlibdeps(1) to identify the library package names for
these sonames:

- first find the library file on the system (looking in some
  hardcoded directories),

- then use "dpkg -S library-file" to lookup the package providing
  the library.

I put these library names in a custom substvar
${dlopen:Recommends}, and pass it on with dh_gencontrol. Done.


I'd like to hear your opinion on this, for now my own thoughts:

- As long as there are no specific symbols to work with, we don't
  know if we'd need a version constraint (I think this was
  Gianfranco's point). But since I'm only looking for the sonames,
  we can't profit from using a sophisticated tool as
  dpkg-shlibdeps.
  Anyway, this is superior to not having these dependencies at all,
  or to hardcoding them (we still can manually add e.g. a version
  constraint if necessary).

- I look for the soname files in a hardcoded list of dirs (/lib,
  /usr/lib, /lib/DEB_HOST_MULTIARCH and
  /usr/lib/DEB_HOST_MULTIARCH).
  dpkg-shlibdeps would be more flexible here, but we just need it
  to work for us. Are there any problems with that, e.g. for other
  ports (kfreebsd, hurd) or anything else?


For reference, this is my implementation:

d/rules:
# additional dlopen runtime dependencies
sonames=$(shell grep  "^\#define SONAME_" include/config.h | cut -d\" -f2)
paths=/usr /usr/lib /lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) 
/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
dlopenRecommends=$(shell \
for soname in $(sonames); do \
for path in $(paths); do \
file=$$(echo $$path/$$soname | sed "s|//|/|g"); \
[ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\) 
*/\\1,/" && break || true; \
done; \
done)

override_dh_gencontrol:
dh_gencontrol -- \
-Vdlopen:Recommends="$(dlopenRecommends)"

d/control:
libwine Recommends: ${dlopen:Recommends},


Thanks again for the valuable input!
Greets
jre

Adding runtime dependencies that aren't caught by shlibs:Depends

[Jens Reyer]

Hi,

I'm working on adding more runtime dependencies to wine (see #823991).
Wine uses the dh sequencer and all relevant binary packages have a
"Depends: ${shlibs:Depends}". This adds some runtime dependencies, but
by far not for every build-dependency -dev package.

If I try to do that manually I come up with the following list of
builddeps and assumed runtime dependencies:

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


First off, I'm not sure about every single dependency if it is needed at
all. Is it reasonable to depend on (or recommend) all these packages,
given that the builddeps were added for a good reason? Or am I on the
completely wrong track here?

So far we only added dependencies manually for:
  libncurses5-dev,libncurses5
  libfreetype6-dev,   libfreetype6
  libfontconfig1-dev, libfontconfig1
But I'd assume we just didn't get bugreports for most of the others,
because Wine is such a big beast and many dependencies are just used
seldom and/or installed anyway.

Now, assuming that we really need all of them, but that there is no way
to automatically add them: is there any way to compute the needed
runtime dependency for a given builddep, in order to avoid hardcoding
this list and update it with every soname change of a depended upon
package?

We do so for libncurses5-dev and libfreetype6-dev by stripping the
"-dev" from the builddep line that contains "ncurses" or "freetype". But
this approach unfortunately doesn't work for all packages' naming schemes.

Greets
jre

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Jens Reyer]

On 09/30/2015 12:13 PM, Jakub Wilk wrote:
> * Jens Reyer <jre.wine...@gmail.com>, 2015-09-30, 03:20:
>>  Depends:
>>ma_foreign (>= ${source:Version})
>>ma_foreign (<< ${source:Version}.1~)
> 
> This is what Lintian recommends when you can't use the "=" dependency,
> but it might be too loose.
> 
> The intention was to include all binNMUs, but exclude newer sourceful
> uploads. But a sourceful stable upload would have a "+debX.Y" suffix,
> which is smaller than ".1~".

Right. So should we change the general advice (lintian, wiki) for these
cases to:
 (>= ${source:Version})
 (<< ${source:Version}+c~)
?

I can think of the following versions, sorted from lowest to highest:
version~bpoX (backports)
version
version+bX   (binNMU)
version+c~   (the next possible version after +bX, probably
  never used in practice)
version+debX (stable/security updates)
version+nmu  (obsolete nmu variant, shouldn't be used today)
version.1(NMU)

Greets
jre

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Jens Reyer]

On 09/30/2015 05:39 PM, Christoph Biedl wrote:
> Johannes Schauer wrote...
> 
>> Quoting Christoph Biedl (2015-09-30 08:25:50)
>>> Personally, I'm not happy about adding extra magic to version numbers
>>> to identify binNMUs and would rather introduce a way to define a range
>>> of version numbers a package satifies, like in
>>>
>>> | Version: 5.25-3+b1# upper bound
>>> | Also-Satifies: 5.25-3 # lower bound
>>>
>>> or by allowing two version numbers in the Version: header. But that's
>>> certainly not my cup of tea, and might bring in a huge amount of new
>>> problems I cannot even imagine yet.
>>
>> in fact, this can already be done:
>>
>> Package: foo
>> Architecture: any
>> Version: 5.25-3+b1
>> Provides: foo (= 5.25-3)
> 
> Oy! So what's the reason those who trigger binNMUs do not utlize this
> feature? Then packagers can abandon this ugly and fragile 
> foo (>= ${binary:Version}), foo (<< ${binary:Version}.1~),
> dependency construct.

That was my first thought, too, when I read it - why not just add a
"Provides: foo (= ${source:Version}).
One reason against: in case of a binNMU we still need the strict
dependency on binary:Version from other Arch: any packages of the same arch.

Greets
jre

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Jens Reyer]

On 09/29/2015 10:13 PM, Christoph Biedl wrote:
> Jakub Wilk wrote...
> 
>> * Christoph Biedl , 2015-09-29, 
>> 20:09:
>>> A Source package builds two "Architecture: any" packages, one "Multi-Arch:
>>> same", the other "Multi-Arch: foreign". The first has a strict versioned
>>> relationship on the second:
>>>
>>> | Package: ma_same
>>> | Architecture: any
>>> | Multi-Arch: same
>>> | Depends: ma_foreign (= ${Source-Version})
>>
>> Don't use ${Source-Version}. This variable is deprecated, because the name
>> is misleading. It is actually equivalent to ${binary:Version}.
> 
> *ouch* Of course. I always use ${binary:Version}. Sorry for the mess,
> must have picked this string from some weird place when preparing the
> message.
> 
>>> Now I remember lintian's "not-binnmuable-all-depends-any" warning where
>>> it's recommended to relax a strict dependency all->any in order to allow
>>> binNMUs ... and I think this is basically the same scenario: ma_foreign
>>> might be installed in a different architecture than ma_same, and then any
>>> binNMU will cause havoc.
>>
>> Well, MA:same packages have to be binNMUed in sync preserve their cross-arch
>> co-installability, so the dependency is not an issue in this case.
> 
> I don't follow. Assuming the following installation:
> 
> Name VersionArchitecture
> +++--==-
> ii  ma_same:amd645.25-3 amd64
> ii  ma_foreign   5.25-3 i386
> 
> Now if the package gets binNMU'd in i386, ma_foreign:i386 is available
> in version 5.25-3+b1 only. The resolver could kick ma_foreign:i386 and
> install ma_foreign:amd64 instead then, so no havoc. Appearently apt
> does this when using "apt-get dist-upgrade" - but is this desirable?

Is the ma_foreign package available on every arch (it should be if it is
a real Architecture: any package) and is amd64 your native arch? Then,
in your example, ma_foreign:amd64 should have been installed in the
first place. See the spec[1]. In this case you could use:
  Package: ma_same
  Depends: ma_foreign (= ${binary:Version})

What Jakub said (MA:same packages have to be binNMUed in sync preserve
their cross-arch co-installability) relates to bug #758616 (dpkg:
support installing M-A:same packages with different binNMU version).
This means that if ma_same is binNMUed in one arch, it should be
binNMUed in all other archs too. Otherwise they can't be co-installed
currently. So you should end up with the same (binary) version on all
archs anyway.

But first, AFAIK this binNMU-in-sync isn't done always. Further, as I
understand the bug log, there's a chance for this to be fixed for
stretch. On the other side, we might end up with something completely
else which makes special binNMU handling obsolete, see "binNMU or
reproducible builds (choose only one)"-thread at debian-devel this month.

So if you assume that different binary versions might exist for the
ma_same package and
a) if ma_foreign is not built on the same archs like ma_same, or
b) if there is a valid use case with ma_same from a non-native
architecture installed, or
c) (basically the same, but currently not possible, see above) if
multiple versions of ma-same might be installed ("same" also means
co-installable, and 2 co-installed versions imply different architectures),
then you should indeed go with:
  Depends:
ma_foreign (>= ${source:Version})
ma_foreign (<< ${source:Version}.1~)

About b) the spec only has a "should" prefer-native-arch, so this
"should" not be a hard reason. But I doubt that any automatic conflict
resolution would find the solution to install the non-native ma_foreign.

Greets
jre


[1] https://wiki.ubuntu.com/MultiarchSpec:

Multi-Arch: same
This package is co-installable and it must not be used to satisfy the
dependency of any package of another architecture than its own.
Often used for library packages.

Multi-Arch: foreign
The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.
*If a package is declared Multi-Arch: foreign, preference should be
given to a package for the native architecture if available;* if it is
not available, the package manager may automatically install any
available package, regardless of architecture, or it may choose to make
this an option controlled by user configuration.

Re: apt-get upgrade and package consolidation

[Jens Reyer]

On 09/21/2015 01:36 AM, Frank de Lange wrote:
> Conflicts: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud-
> app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long)
> Breaks: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud-
> app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long)

Not related to your question, but you should add a "~" to every version
so that your setup also works with the versions on backports in case the
packages land there.

Greets
jre

Re: apt-get upgrade and package consolidation

[Jens Reyer]

On 09/21/2015 02:07 AM, Frank de Lange wrote:
> Russ Allbery wrote:
>> Frank de Lange  writes:
>>
>>> In packaging owncloud (https://owncloud.org) for Debian we've hit on a
>>> bit of a snag. In previous versions of the Debian packages, many
>>> disparate components were delivered in their own package
>>> (owncloud-app-encryption, owncloud-app-kichensink, owncloud-app-.,
>>> etc). These functions have now been consolidated into the main package,
>>> named owncloud-server. The main question now is how to get this upgrade
>>> to go ahead using a normal apt-get upgrade (or the equivalent in other
>>> upgrade mechanisms) without needing to resort to dist-upgrade or a
>>> targeted upgrade (apt-get upgrade/install owncloud-server).
>>
>>> Currently the following happens:
>>
>>>  - user has the whole bunch of owncloud-app-... packages installed
>>>as well as owncloud-server, all at v 8.1.1-1.
>>
>>>  - the next version of owncloud-server (v 8.1.3-6.1) includes all these
>>>owncloud-app-... packages. In the control file this is stated:
>>
>>> Conflicts: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud-
>>> app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long)
>>> Breaks: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud-
>>> app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long)
>>
>> You basically never want both Conflicts and Breaks.  Breaks is a weaker
>> version of Conflicts.  In this case, I think you want Conflicts, not
>> Breaks, plus Provides and Replaces.
>>
>>>  - user tries a normal upgrade but this fails - owncloud-server
>>>is held back
>>
>>>  - attempting to solve this by adding a 'Provides:' section with the
>>>consolidated packages does not solve it either - now both the
>>>owncloud-server package as well as all those 'Provided' packages
>>>are held back.
>>
>> I think you need Replaces.  See:
>>
>> https://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
>>
> 
> Uh, jut got this reply. The new owncloud-server already contains a
> 'Replaces:' section, mentioning all the consolidated packages.
> 
> We can try to remove the Breaks: section, but it is doubtful as to
> whether that would solve this issue. Since they more or less state the
> same but in different terms it is probably a good idea anyway.
> 
> Gr//Fr
> 

If the Provides doesn't work, I'd go with empty transitional packages
for each owncloud-app-* *instead*.
Add them in owncloud-server/debian/control, each with Depends:
owncloud-server (>= ${source:Version}).

Then add to "Package: owncloud-server" Breaks and Replaces for each
owncloud-app-... (<< 8.1.3-6.1~).

I don't think Conflicts is necessary if you use transitional packages.
You have to keep thetransitional packages until Stretch is out.


Greets
jre

Re: apt-get upgrade and package consolidation

[Jens Reyer]

On 09/21/2015 03:25 AM, Jens Reyer wrote:
> I don't think Conflicts is necessary if you use transitional packages.

Sorry, I revoke that part. (Although not absolutely sure.)

Re: Bug#797898: RFS: caffe/0.9999~rc2+git20150902+e8e660d3-1 [ITP]

[Jens Reyer]

On 09/06/2015 08:30 AM, Gianfranco Costamagna wrote:
> dpkg -s nvidia-cuda-toolkit | grep -o installed

"installed" is also part of the output of a non-installed package.

Still not 100% failproof alternative:
 19 ifeq (installed, $(shell dpkg -s nvidia-cuda-toolkit | grep Status | grep 
-o installed))

or (untested and I don't know if there are valid alternatives):

 19 if ($(shell dpkg -s nvidia-cuda-toolkit | grep -o "Status: install ok 
installed")

Greets
jre