Bug#891095: ibid: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: ibid
Version: 0.1.1+dfsg-4
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891093: guake-indicator: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: guake-indicator
Version: 1.1-2
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891100: gourmet: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: gourmet
Version: 0.17.4-5
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891108: mpd ignores port change in mpd.conf

[Sylvain Mandon]

Package: mpdVersion: 0.19.21-1
Hi,
If I change the port in mpd.conf and restart mpd it still listens on the 
default 6600 port.I even uncommented the MPDCONF line in /etc/default/mpd, but 
it still doesn't work.
With changed port in mpd.conf to 6601 and restarting mpd (same result if 
started via init.d and systemctl):
$ netstat -a | grep 660
tcp6   0  0 [::]:6600    [::]:*  LISTEN

The only solution that worked was:$ systemctl disable mpd$ update-rc.d mpd 
enable$ /etc/init.d/mpd restart[ ok ] Restarting mpd (via systemctl): 
mpd.service.$ netstat -a | grep 660tcp    0  0 localhost:6601  
0.0.0.0:*   LISTEN

The strange thing is that it still says that it is starting it via systemctl.
Some info:$ cat /etc/debian_version9.3$ uname -aLinux debian 4.9.0-4-amd64 #1 
SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux

Bug#891063: emacs25: dconf-CRITICAL errors

[Vincent Lefevre]

Control: tags -1 security

On 2018-02-21 22:41:53 -0800, Rob Browning wrote:
> I'm not sure I understand yet how this makes Emacs unusable -- does it
> warn or crash?

I've looked at it more closely, and the problem seems to come from
that when Emacs is run as root after "su" (without using -m or -p),
it still tries to use the user's config and modify things there!
In particular, it can be tricked by the user to create a file
anywhere, like this:

-rw--- 1 root root 2 2018-02-22 12:26:14 /created-by-emacs

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#891096: planet-venus: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: planet-venus
Version: 0~git9de2109-4
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#815234: lintian: Detect Rdata files with embedded code

[Dylan Aïssi]

Hi Chris,

On Tue, 30 Jan 2018 13:33:28 +0530 Chris Lamb  wrote:
>
> > determine if any code is embedded in the file
>
> So, how does one do this? :)
>

Not sure but maybe this [1] could be useful here.


Best,
Dylan


[1] http://search.cpan.org/dist/Statistics-R-IO/

Bug#891099: python-pattern: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: python-pattern
Version: 2.6+git20150109-2
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891097: python-freevo: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: python-freevo
Version: 1.9.2b2-4.3
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891098: python-gumbo: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: python-gumbo
Version: 0.10.1+dfsg-2.1
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891101: python-pyth: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: python-pyth
Version: 0.6.0-1
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891092: apt-dater-host misdetects kernels that need to be upgraded on Ubuntu -> please update to current upstream apt-dater-host

[Tomas Pospisek]

Package: apt-dater-host
Version: 1.0.1-1
Severity: normal
Tags: patch

$ ssh ubuntu_xenial_machine
# apt-dater-host kernel
ADPROTO: 0.7
KERNELINFO: 1 4.13.0-36-generic

# zgrep KERNELINFO -m 1 -A 4 -B 2 /usr/share/doc/apt-dater-host/ADP-0.7.gz 
The result line has the following format:

KERNELINFO: ${Code} ${Release}

The following codes are supported:
0 - The running kernel is the latest distri kernel. No reboot required.
1 - The running kernel is an distri kernel but it's older then the 
latest

So apt-dater-host is telling us, that a new kernel is available on this
machine. Let's see:

# uname -r
4.13.0-36-generic

# dpkg-query -W -f='\${Package} \${Version} \${Status;20} \${Maintainer} 
\${Provides}\n' 'linux-image*'
$linux-image $ $unknown ok not-insta $ $
$linux-image-4.13.0-31-generic $4.13.0-31.34~16.04.1 $deinstall ok config- 
$Ubuntu Kernel Team  $aufs-dkms, fuse-module, 
ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, 
spl-modules, virtualbox-guest-modules, zfs-dkms, zfs-modules
$linux-image-4.13.0-32-generic $4.13.0-32.35~16.04.1 $install ok installed 
$Ubuntu Kernel Team  $aufs-dkms, fuse-module, 
ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, 
spl-modules, virtualbox-guest-modules, zfs-dkms, zfs-modules
$linux-image-4.13.0-36-generic $4.13.0-36.40~16.04.1 $install ok installed 
$Ubuntu Kernel Team  $aufs-dkms, fuse-module, 
ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, 
spl-modules, virtualbox-guest-modules, zfs-dkms, zfs-modules
$linux-image-extra-4.13.0-31-generic $4.13.0-31.34~16.04.1 $deinstall ok 
config- $Ubuntu Kernel Team  $
$linux-image-extra-4.13.0-32-generic $4.13.0-32.35~16.04.1 $install ok 
installed $Ubuntu Kernel Team  $
$linux-image-extra-4.13.0-36-generic $4.13.0-36.40~16.04.1 $install ok 
installed $Ubuntu Kernel Team  $
$linux-image-generic-hwe-16.04 $4.13.0.36.55 $install ok installed $Ubuntu 
Kernel Team  $

So, no, in fact, there is no newer kernel image available. We do have
the latest kernel installed.

Now if we go and debug apt-dater-host, we find out, that the above
command (modulo the '\${Package}' name) is exactly what apt-dater-host
is, to retrieve the list of available kernel images.

Now why does apt-dater-host go wrong in determining whether there's a
new kernel?

It is because it iterates over that list [1] and compares the version
from `uname -r` with the version from the list. The problem here is,
that comparing the current installed kernel version with the version
from the the last line, i.e. :

# dpkg --compare-versions 4.13.0-36 lt 4.13.0.36.55

will yield

# echo $?
0

meaning, yes there indeed *is* a newer kernel available. The problem is
only, that linux-image-generic-hwe-16.04 is *not* a kernel package, but
instead is a kernel *meta* package, that depends on the latest kernel...

Current apt-dater-host versions from upsteam improve the query [2] with a:

| grep linux-image

Remember, the upstream query does not include the '\${Package}' field,
so what the grep does is to effectively filter out by the '\${Provides}'
field, which in the case of the meta package is empty. Only the "real"
kernel packages do provide a 'linux-image'.

Thus upstream's apt-dater-host works on Ubuntu, while Debian's
apt-dater-host doesn't.

If you update Debian's apt-dater-host then I think it will be pulled
into Ubuntu, and things should be fixed there. So I ask you to please
update the Debian apt-dater-host from upstream.

Thanks.
*t

[1] 
https://github.com/DE-IBH/apt-dater-host/blob/master/dpkg/apt-dater-host#L383
[2] 
https://github.com/DE-IBH/apt-dater-host/blob/master/dpkg/apt-dater-host#L379


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-dater-host depends on:
ii  libapt-pkg-perl  0.1.32
ii  libimvirt-perl   0.9.6-3
ii  lsb-release  9.20161125
ii  openssh-server   1:7.4p1-10+deb9u2
ii  perl 5.24.1-3+deb9u2

Versions of packages apt-dater-host recommends:
pn  imvirt   
pn  needrestart  
ii  sudo 1.8.19p1-2.1

apt-dater-host suggests no packages.

-- Configuration Files:
/etc/sudoers.d/apt-dater-host [Errno 13] Keine Berechtigung: 
'/etc/sudoers.d/apt-dater-host'

-- no debconf information

Bug#891091: git-buildpackage: pristine-tar uses unreachable tree for main tarball when components exist

[Guido Günther]

On Thu, Feb 22, 2018 at 10:48:25AM +, James Cowgill wrote:
> Package: git-buildpackage
> Version: 0.9.7
> Severity: normal
> 
> Hi,
> 
> I am attempting to use git-buildpackage and pristine-tar with a package
> which uses multiple components. Unfortunately if I clone the repository,
> pristine-tar fails to generate the main tarball:
> 
> > $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> > pristine-tar: successfully generated ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> > $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig.tar.gz
> > fatal: ambiguous argument 
> > '81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53^{tree}': unknown revision or path 
> > not in the working tree.
> > Use '--' to separate paths from revisions, like this:
> > 'git  [...] -- [...]'
> > fatal: Not a valid object name
> > tar: This does not look like a tar archive
> > tar: Exiting with failure status due to previous errors
> > pristine-tar: command failed: git archive --format=tar 
> > 81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53\^\{tree\} | (cd 
> > '/tmp/pristine-tar.KmsGn7eSaa' && tar x)

That is perfectly fine and it's why /usr/share/bug/git-buildpackage/presubj is
asking for the _full_ comand outpout:

> 
> The mentioned tree (81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53) does not
> exist in the cloned repository but does in the original repository.
> 
> I found this which looks to me exactly the same situation I am in, but I
> could not find a Debian bug so I am filing one now:
> 
> https://lists.sigxcpu.org/pipermail/git-buildpackage/2017-June/000223.html

If you read that thread you see 

https://lists.sigxcpu.org/pipermail/git-buildpackage/2017-July/000240.html

> 
> The gist is that pristine-tar is given a tree object for the main
> tarball without the extra component tarballs, but this tree object is
> never present in the upstream branch and is unreachable from any tags. I
> guess the easiest solution is to pass the final upstream tree (with all
> the components) to pristine-tar when generating the main tarball. This
> might give bigger deltas, but when I tested it with ffdiaporama the
> delta was only a few hundred bytes larger so maybe it's not a big
> problem.

You're very likely missing the --git-component option (see above) which
will be used to create the tree you lack.

O.k. to close this bug?
Cheers
 -- Guido

Bug#891094: calibre: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: calibre
Version: 3.17.0+dfsg-1
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Ian Jackson]

Margarita Manterola :
> I'm sorry this took so long to be actioned by us. This is on me.
> 
> In previous bugs that have been raised to the technical committee
> it has already been discussed and agreed that the technical
> committee does not have the power to overrule official Debian
> delegates.  This covers the decisions taken for example by the
> FTP Masters or the Release Team.
> 
> Thus, we are closing this bug now, as it's not actionable.
> 
> We suggest that you work together with the FTP Masters in
> figuring out a solution to this problem.

I'm not sure I agree with this.  Firstly, it's not clear that the
acceptance or not of packages is a decision "for whom noone else has
responsibility" in the words of the Constitution ?  (That's funny
wording because it should say "for which" since decisions are not
people...)

Secondly, the request could be actioned by a non-binding statement by
the TC.

Thirdly, when you decline a complaint, I think the TC should give real
information about escalation routes.  "Work together with the FTP
Masters" is not the correct escalation route.

You should have advised Pirate that:
 * Pirate should first escalate the matter with leader@d.o,
   because although the DPL does not have the power directly to
   overrule the ftpmasters, the DPL _does_ have ultimate
   responsibility for the ftpmaster team and therefore does have a
   supervisory role.
 * If that does not yield an appropriate outcome, Pirate has the
   option of a General Resolution.
 * Alternatively, this could be seen as a question of policy.  It
   seems unlikely that ftpmster would act cotnrary to a clear
   statement in Debian Policy about when circular build-deps are
   acceptable.

I wouldn't be saying all of this if I agreed that Pirate's complaint
is without merit.  I think our general approach to circular
build-dependencies needs to be clarified.

Personally for example I think it's quite ridiculous that the only way
to get from the Haskell binaries in jessie to the Haskell binaries in
stretch is an undocumented chain of recompilations of packages from
snapshot.d.o.  If we let Haskell do that, why are we being so hard on
JavaScript ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Wed, 22 Nov 2017 05:08:47 -0600 Dan Nicholson  wrote:
> On Fri, Aug 25, 2017 at 4:07 PM, Dan Nicholson 
> wrote:
> 
> > On Tue, Aug 22, 2017 at 10:23 AM, Dan Nicholson 
> > wrote:
> > >
> > > That certainly helps, but it doesn't cover everything since the
> > > mkdir's and ln's could fail. Those are easier to handle by adding
-p
> > > and -f, respectively, but that's a subtle change in behavior for
ln
> > > relative to the mknod change. In the mknod case, an existing
device is
> > > left as is. In the ln case, it would be forcefully overwritten.
> >
> > Attached is a patch to handle all the potentially failing cases. I
> > tested this by running debootstrap once, wiping everything the
target
> > except /dev, and running debootstrap again. It succeeded. As
mentioned
> > above, an existing device is skipped while the symlinks are
forcefully
> > overwritten. That seems inconsistent, but I'm not sure it matters. I
> > could easily change the mknod function to forcefully remove, too.
> >
> 
> Ping? Patch is pretty straightforward, but I'd be happy to adjust any
> direction people like.

Ping? It seemed like people were interested in having this change. Happy
to change the patch in whatever way anyone wants or just step aside and
let one of the maintainers fix it the way they want.

Bug#728535: new URL

[Geert Stappers]

 
https://unix.stackexchange.com/questions/67936/attaching-usb-serial-device-with-custom-pid-to-ttyusb0-on-embedded
because previous URL is broken.

Bug#891112: f2c: New version available

[Andreas Tille]

Package: f2c
Severity: wishlist

Hi,

I took the freedom to move f2c to salsa[1] and do a team upload since
I'm in the process of caring for rdepends of those packages I'm
maintaining that are hanging around in collab-maint.  I hope you like
this.

When doing so I noticed that the version.c file that is refered to in
d/watch now has version 20160102.  I hesitated to upgrade to this new
version to keep changes basically moving to salsa and some general
packaging updates.  The changelog for the new version looks as if it
might make sense to take over but I was not even clear about the
procedure how to create the upstream tarball.  Some
debian/get-orig-script would be helpful here.

Thanks for maintaining f2c

   Andreas.


[1] https://salsa.debian.org/debian/f2c.git


-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages f2c depends on:
ii  libc62.24-11+deb9u1
pn  libf2c2-dev  

Versions of packages f2c recommends:
ii  gcc  4:6.3.0-4

Versions of packages f2c suggests:
pn  fort77  

Bug#866652: runit: Should depend on runit-(systemd|sysv) to be present

[chrysn]

Package: runit
Version: 2.1.2-9.2
Followup-For: Bug #866652

Hello Dmitry,

If this is implemented (which I think is a good idea), please implement
it in a way that users of runit as PID 1 can also satisfy the
dependency, eg. by making the dependency "runit-systemd | runit-any"
where runit-any is virtual and provided by runit-systemd, runit-sysv,
and users of runit-init can make it "Provides: runit-any" even if a
runit-init does not come back to Debian.

Thanks
chrysn


signature.asc
Description: PGP signature

Bug#877635: linux-image-4.14.0-rc3-amd64: Kernel 4.14-rc3 fails to initialize kfd: kgd2kfd_probe failed

[felipe]

Since kernel 4.15.4-1 hit stable I no longer get this error on the same machine.

If there are no more reports, you can close this bug.

Thanks.


> Package: src:linux
> Version: 4.14~rc3-1~exp1
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading to experimental kernel 4.14-rc3, I get the following
> new errors during boot:
> 
> [   10.436142] kfd kfd: DID 6810 is missing in supported_devices
> [   10.436147] kfd kfd: kgd2kfd_probe failed
> 
> Before, on older kernels I would get:
> 
> [7.434988] kfd kfd: Initialized module
> 
> I expected some errors with the amdkfd-next pull.
> I believe this error message was introduced by this patch:
> 
> https://patchwork.freedesktop.org/patch/171967/

Bug#889311: O: radioclk -- simple ntp refclock daemon for MSF/WWVB/DCF77 time signals

[Paride Legovini]

I'm interested in adopting this, but I can't play with the right
hardware right now. It could be in weeks or months, so I won't change
this to an ITA for now.

Paride

Bug#891111: ctdconverter: missing build dependency on 2to3

[Adrian Bunk]

Source: ctdconverter
Version: 2.0-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=ctdconverter=all=2.0-2=1519291849=0

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
2to3 --write --nobackups convert.py galaxy/ cwl/ common/
make[1]: 2to3: Command not found
make[1]: *** [debian/rules:23: override_dh_auto_build] Error 127

Bug#891091: git-buildpackage: pristine-tar uses unreachable tree for main tarball when components exist

[James Cowgill]

Package: git-buildpackage
Version: 0.9.7
Severity: normal

Hi,

I am attempting to use git-buildpackage and pristine-tar with a package
which uses multiple components. Unfortunately if I clone the repository,
pristine-tar fails to generate the main tarball:

> $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> pristine-tar: successfully generated ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig.tar.gz
> fatal: ambiguous argument '81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53^{tree}': 
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
> fatal: Not a valid object name
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> pristine-tar: command failed: git archive --format=tar 
> 81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53\^\{tree\} | (cd 
> '/tmp/pristine-tar.KmsGn7eSaa' && tar x)

The mentioned tree (81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53) does not
exist in the cloned repository but does in the original repository.

I found this which looks to me exactly the same situation I am in, but I
could not find a Debian bug so I am filing one now:

https://lists.sigxcpu.org/pipermail/git-buildpackage/2017-June/000223.html

The gist is that pristine-tar is given a tree object for the main
tarball without the extra component tarballs, but this tree object is
never present in the upstream branch and is unreachable from any tags. I
guess the easiest solution is to pass the final upstream tree (with all
the components) to pristine-tar when generating the main tarball. This
might give bigger deltas, but when I tested it with ffdiaporama the
delta was only a few hundred bytes larger so maybe it's not a big
problem.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#891035: bpfcc-tools: Must depend on linux-headers

[Ritesh Raj Sarraf]

On Wed, 2018-02-21 at 19:55 +0200, Mykola Nikishov wrote:
> For the user who wants to just use bpfcc and not knowing all
> technicalities it would be great to avoid it by adding an explicit
> dependency on linux-headers-$(uname -r).

No. We can't do that. The reasons for the same are explained in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925

I documented this fact, that about manually installing the linux-
headers package, into the README.Debian file. Looks like it only got
included into libbpfcc.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

signature.asc
Description: This is a digitally signed message part

Bug#891090: archmage: python-beautifulsoup is replaced with python-bs4

[Stefano Rivera]

Package: archmage
Version: 1:0.3.1-3
Severity: important
Control: block 891087 by -1

beautifulsoup version 4 was replaced as a new package, bs4, which has
been in Debian for over 5 years now. beautfiulsoup (3.x) hasn't seen any
maintenance since then. It's high time to remove it from the archive.

Most code written against Beautiful Soup 3 will work against Beautiful
Soup 4 with one simple change. All you should have to do is change the
package name from BeautifulSoup to bs4, and depend on python-bs4 instead
of python-beautifulsoup.

There is some documentation on the migration here:
https://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4

Thanks,

SR

Bug#891089: nmu: aolserver4_4.5.1-18.1

[Aurelien Jarno]

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

tcl8.6 stopped linking with libieee.a in preparation for glibc 2.27 (see
bug#890243). aolserver4 encodes this in /usr/share/aolserver4/ns.mak and
thus needs a binNMU following this change.

nmu aolserver4_4.5.1-18.1 . ANY . unstable . -m "Rebuild against tcl8.6 (>= 
8.6.8+dfsg-2)"

Bug#891086: grep: Previous versios took -a as default if files where binary or part binary.

[rodrifra]

Package: grep
Version: 2.27-2
Severity: normal

Dear Maintainer,


   * What led up to the situation?

   Scripts working with grep stopped working after the update. No patterns 
where detected ant the message informing of coincidences in the binary file was 
displayed. The file is a downloaded html and "file" command returns:
   
   selecc.html: HTML document, ISO-8859 text, with CRLF, LF line terminators

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   Explicitly indicating grep to treat the file as text solved the problem: 
"grep -a "

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages grep depends on:
ii  dpkg  1.18.24
ii  install-info  6.3.0.dfsg.1-1+b2
ii  libc6 2.24-11+deb9u1
ii  libpcre3  2:8.39-3

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.39-3

-- no debconf information

Bug#891067: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Yves-Alexis Perez]

control: tag -1 -patch
On Thu, 2018-02-22 at 09:20 +0100, Geert Stappers wrote:
> Bugreport tagged with 'patch',  hope this helps.

Hi,

There is no patch in that bug report. While copying the whole directory might
be doable, it's not the first solution we would consider, and it would
definitely need a lot more testing.

Regards,
-- 
Yves-Alexis

signature.asc
Description: This is a digitally signed message part

Bug#891087: beautifulsoup has been replaced by bs4

[Stefano Rivera]

Source: beautifulsoup
Severity: important

We really should remove beautifulsoup, it has been replaced by bs4, many
years ago. I've just been lazy, and haven't hassled consumers to
migrate...

This bug is for tracking the transition to bs4.

SR

Bug#891088: miniupnpd: modifies conffiles (policy 10.7.3): /etc/default/miniupnpd

[Andreas Beckmann]

Package: miniupnpd
Version: 2.0.20171212-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/#configuration-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/default/miniupnpd


cheers,

Andreas


miniupnpd_2.0.20171212-2.log.gz
Description: application/gzip

Bug#891083: remmina: Fails to save connection details

[Antenore Gatta]

Hello,

upstream dev here.

I think it can related to the XDG folders that are set to something
outside of the user ownership (like /usr/share for example)

Can you check that Remmina is not trying to save where your user doesn't
have permissions to write?

From our point of view, having Remmina using profiles inside folder
without writing permissions, could be normal and we ignore the
exception, this is to allow admins to distribute profiles to the users
and avoid that they could modify those profiles.

That said, start remmina from the command line and look for any
interesting messages if any, than start again but set the XDG folders
in advance (export XDG_xxx=$HOME/whatever).

I'm mobile at the moment so I cannot check easily the XDG folder names.

Please plet me know what happens than.

Bug#891085: aseba-plugin-blockly: missing build-dependency for python2

[Andreas Beckmann]

Source: aseba-plugin-blockly
Version: 20180211+git-1
Severity: serious
Justification: fails to build from source

Hi,

aseba-plugin-blockly FTBFS since it uses python2 without depending on
it:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/aseba-plugin-blockly-20180211+git'
mkdir build
bash build.sh build/blocky.zip
+++ dirname build.sh
++ cd .
++ pwd
+ SRC_DIR=/build/aseba-plugin-blockly-20180211+git
+ BUILD_DIR=/build/aseba-plugin-blockly-20180211+git
++ mktemp -d
+ TEMP_DIR=/tmp/tmp.QJhv5lK8jV
+ trap atexit EXIT
+ cp -r /build/aseba-plugin-blockly-20180211+git/blockly 
/build/aseba-plugin-blockly-20180211+git/closure-library 
/build/aseba-plugin-blockly-20180211+git/thymio_blockly 
/build/aseba-plugin-blockly-20180211+git/index.html 
/build/aseba-plugin-blockly-20180211+git/media /tmp/tmp.QJhv5lK8jV
+ ARCHIVE=/build/aseba-plugin-blockly-20180211+git/blockly.zip
+ '[' '!' -z build/blocky.zip ']'
++ realpath build/blocky.zip
+ ARCHIVE=/build/aseba-plugin-blockly-20180211+git/build/blocky.zip
+ '[' -f /build/aseba-plugin-blockly-20180211+git/build/blocky.zip ']'
+ pushd /tmp/tmp.QJhv5lK8jV
/tmp/tmp.QJhv5lK8jV /build/aseba-plugin-blockly-20180211+git
+ pushd blockly
/tmp/tmp.QJhv5lK8jV/blockly /tmp/tmp.QJhv5lK8jV 
/build/aseba-plugin-blockly-20180211+git
+ echo 'Compiling blockly'
Compiling blockly
+ python2 ./build.py
build.sh: line 33: python2: command not found
+ atexit
+ rm -rf /tmp/tmp.QJhv5lK8jV
make[1]: *** [debian/rules:24: override_dh_auto_build] Error 127
make[1]: Leaving directory '/build/aseba-plugin-blockly-20180211+git'


Andreas


aseba-plugin-blockly_20180211+git-1.log.gz
Description: application/gzip

Bug#886329: [Filesystems-devel] Bug#886329: Bug#886329: Bug#886329: aufs-dkms: Cannot use aufs union mount with Linux 4.14.7-1: kernel BUG at /var/lib/dkms/aufs/4.14+20171218/build/fs/aufs/finfo.c:113

[intrigeri]

intrigeri:
> sf...@users.sourceforge.net:
>> I am interested in why you set '1' to the aufs module parameter "debug".

> IIRC I added it after having noticed the bug, in the hope it would
> yield more useful information for developers to fix it.

>> If you had not set, this bug would not appear I guess. Did you see
>> something wrong without setting "debug"? And you tried debugging? If so,
>> I want to know the original problem too.

> OK, I'll retry without debug=1.

Same problem without debug=1:

 aufs 4.15-20180219
 [ cut here ]
 kernel BUG at /root/aufs4-standalone/fs/aufs/finfo.c:113!
 invalid opcode:  [#1] SMP PTI
 Modules linked in: aufs(O) iscsi_target_mod target_core_mod uinput 
ebtable_filter ebtables ip6table_filter ip6_tables devlink iptable_filter 
configfs snd_hda_codec_generic kvm_intel snd_hda_intel kvm snd_hda_codec 
snd_hda_core irqbypass snd_hwdep snd_pcm joydev snd_timer sg serio_raw pcspkr 
virtio_console snd virtio_input evdev virtio_balloon soundcore parport_pc ppdev 
lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom ata_generic 
virtio_gpu ttm drm_kms_helper drm virtio_blk 8139too crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel ata_piix ahci 
aes_x86_64 crypto_simd glue_helper libahci cryptd libata uhci_hcd psmouse 
i2c_piix4 ehci_hcd 8139cp mii virtio_pci usbcore
  virtio_ring virtio scsi_mod usb_common floppy button
 CPU: 0 PID: 1632 Comm: ls Tainted: G   O 4.15.0-1-amd64 #1 Debian 
4.15.4-1
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
 RIP: 0010:au_finfo_fin+0x55/0x60 [aufs]
 RSP: 0018:ba4fc07bfe68 EFLAGS: 00010202
 RAX: 0001 RBX: 968df5568600 RCX: 0020
 RDX: ffe0 RSI: 968e00664300 RDI: 968e3628c070
 RBP: 968e393294b0 R08: 00024b40 R09: c0adc5a0
 R10: ea6701e4ca40 R11:  R12: 968e00664300
 R13: 968e39329480 R14: 968df5568600 R15: 0001
 FS:  7f1c8e13f040() GS:968e3fc0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 5569e08d08c8 CR3: 7661 CR4: 001606f0
 Call Trace:
  aufs_release_dir+0x101/0x130 [aufs]
  __fput+0xd8/0x210
  task_work_run+0x8a/0xb0
  exit_to_usermode_loop+0xb9/0xc0
  do_syscall_64+0x127/0x130
  entry_SYSCALL_64_after_hwframe+0x21/0x86
 RIP: 0033:0x7f1c8da27747
 RSP: 002b:7ffe97932f10 EFLAGS: 0206 ORIG_RAX: 0003
 RAX:  RBX: 0003 RCX: 7f1c8da27747
 RDX: 00012740 RSI:  RDI: 0003
 RBP:  R08:  R09: 5569e08c8905
 R10: 016c R11: 0206 R12: 7f1c8e13eed8
 R13: 5569e08c8890 R14: 5569e08c8870 R15: 
 Code: b2 53 6c f3 48 8b b3 c8 00 00 00 48 83 7e 50 00 75 17 8b 05 ee 30 3d f4 
85 c0 75 0f 5b 48 8b 3d 02 6e 03 00 e9 dd 0b 53 f3 0f 0b <0f> 0b 66 0f 1f 84 00 
00 00 00 00 0f 1f 44 00 00 48 83 c7 08 48 
 RIP: au_finfo_fin+0x55/0x60 [aufs] RSP: ba4fc07bfe68
 ---[ end trace 22dbca8ab81b58bd ]---

# cat /sys/module/aufs/parameters/debug 
0

Cheers,
-- 
intrigeri

Bug#886827: RFS: youtube-dl-gui/0.4-1 [ITP]

[Félix Sipma]

On 2018-02-22 03:27+, Lumin wrote:
> I built the package locally, but I did not get it working correctly
> With a YouTube URL. It downloads nothing.
> Could you please provide a url for test so I can make sure
> it is working?
> 
> I will look into this problem later.

It definitely works here... Are you sure entered your urls, selected the output
format and directory, clicked "add", and then clicked "start"?


signature.asc
Description: PGP signature

Bug#891084: /usr/bin/slabtop: USE column reports either 100 or 0 percent only

[Frank Chung]

Package: procps
Version: 2:3.3.12-4
Severity: normal
File: /usr/bin/slabtop

Dear Maintainer,

It appears that slaptop is reporting USE values of 0% for any usage lower than 
100%. Sample output from "slabtop -o" follows:

*** sample output of slabtop -o ***
 Active / Total Objects (% used): 187373 / 197086 (95.1%)
 Active / Total Slabs (% used)  : 8404 / 8404 (100.0%)
 Active / Total Caches (% used) : 70 / 98 (71.4%)
 Active / Total Size (% used)   : 42760.51K / 48008.28K (89.1%)
 Minimum / Average / Maximum Object : 0.01K / 0.24K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME   
 60762  60462   0%0.10K   1558   39  6232K buffer_head
 30660  29695   0%0.19K   1460   21  5840K dentry 
 13856  10180   0%0.94K   17328 13856K xfs_inode  
 12064  12013   0%0.59K928   13  7424K inode_cache
 12032  12032 100%0.02K 47  256   188K kmalloc-16 
 10980  10980 100%0.13K366   30  1464K kernfs_node_cache  
  6480   3680   0%0.16K270   24  1080K xfs_ili
  5016   5016 100%0.20K264   19  1056K vm_area_struct 
  4992   4992 100%0.03K 39  128   156K kmalloc-32 
  4480   4480 100%0.06K 70   64   280K pid
  4228   4177   0%0.57K302   14  2416K radix_tree_node
  3584   3584 100%0.01K  7  51228K kmalloc-8  
  3060   3060 100%0.05K 36   85   144K ftrace_event_field 
  2816   2709   0%0.06K 44   64   176K kmalloc-64 
  2576   2576 100%0.09K 56   46   224K anon_vma   
  1792   1512   0%0.12K 56   32   224K kmalloc-128
*** end of sample output ***

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-1-cloud-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.51
ii  libc62.26-6
ii  libncurses5  6.1-1
ii  libncursesw5 6.1-1
ii  libprocps6   2:3.3.12-4
ii  libtinfo56.1-1
ii  lsb-base 9.20170808

Versions of packages procps recommends:
ii  psmisc  23.1-1

procps suggests no packages.

-- no debconf information

Regards,
Frank Chung

Bug#891083: remmina: Fails to save connection details

[Stephen Quinney]

Package: remmina
Version: 1.2.0-rcgit.27+dfsg-3
Severity: important

I just installed the latest version for the first time on this device
so there are no previous configuration files. I click on the '+' to
add a new RDP connection and fill in all the details. I click on any
of the 'Save', 'Save as Default' or 'Save and Connect' buttons (I've
tried all of them) and nothing gets saved. After the attempt to save
there are still no config files or directories in my home directory
and nothing appears in the main list of connections. I've had this
working with previous versions on other devices so I'm pretty sure I'm
not doing anything unusual here...

Regards,

Stephen Quinney

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.4-1
ii  dbus-x11 [dbus-session-bus]   1.12.4-1
ii  libatk1.0-0   2.26.1-3
ii  libavahi-client3  0.7-3.1
ii  libavahi-common3  0.7-3.1
ii  libavahi-ui-gtk3-00.7-3.1
ii  libayatana-appindicator3-10.5.2-1
ii  libc6 2.26-6
ii  libcairo2 1.15.10-1
ii  libgcrypt20   1.8.1-4
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.54.3-2
ii  libgtk-3-03.22.28-1
ii  libice6   2:1.0.9-2
ii  libjson-glib-1.0-01.4.2-3
ii  libpango-1.0-01.40.14-1
ii  libsm62:1.2.2-1+b3
ii  libsoup2.4-1  2.60.3-1
ii  libssh-4  0.8.0~20170825.94fa1e38-1
ii  libssl1.1 1.1.0g-2
ii  libvte-2.91-0 0.50.2-4
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  remmina-common1.2.0-rcgit.27+dfsg-3

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.2.0-rcgit.27+dfsg-3
ii  remmina-plugin-secret  1.2.0-rcgit.27+dfsg-3
ii  remmina-plugin-vnc 1.2.0-rcgit.27+dfsg-3

Versions of packages remmina suggests:
pn  remmina-plugin-exec   
ii  remmina-plugin-nx 1.2.0-rcgit.27+dfsg-3
pn  remmina-plugin-spice  
pn  remmina-plugin-telepathy  
pn  remmina-plugin-xdmcp  

-- no debconf information

Bug#891082: xvkbd: Regression in using some definition for mouse "back" and "forward" buttons

[Jean-Luc Coulon (f5ibh)]

Package: xvkbd
Version: 3.3-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've a Logitech M560 Mouse.
It has 2 extra buttons on the side.

I used to use them for back and forward in the browser.

To affect these keys, I've the follwing in my .xbindkeysrc confiuration file:

"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Left]""
  m:0x0 + b:11
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Right]""
  m:0x0 + b:10

this works as expected with version 3.2 for years.

After the recent upgrade to 3.8, this stops working.

Regards

Jean-Luc

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-rc2-i7-0.1 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 xvkbd depends on:
ii  libc6 2.26-6
ii  libice6   2:1.0.9-2
ii  libsm62:1.2.2-1+b3
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1
ii  libxtst6  2:1.2.3-1
ii  xaw3dg1.5+E-18.3

Versions of packages xvkbd recommends:
ii  wamerican [wordlist]  2017.08.24-1
ii  wfrench [wordlist]1.2.3-11

xvkbd suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT5el3FKLtmYO4UlQtR0YZfPMac0AUCWo6LiQAKCRBR0YZfPMac
0OnZAKCqyR4y8LSXi70JZokZIL7FInZMUgCfW+QCwxIciZwQi33cHZD4GezzVxw=
=h+dK
-END PGP SIGNATURE-

Bug#890846: XFree after glXChooseVisual forgotten

[Christian Kuhn]

Hello,

 

I must correct my bug report: memory leaks after calling glXChooseVisual are
caused by a missing XFree. Calling XFree after glXChooseVisual fix this
problem. But glClear still causes memory leaks.

 

Best regards,

Christian Kuhn

 

Bug#891049: pgmodeler: version in stretch incompatible with db version in stretch

[Christoph Berg]

Control: severity -1 serious
Version: 0.9.1~beta-1

Re: Toni Mueller 2018-02-21 
<151925212500.8837.9009431344134188619.report...@spruce.office.oeko.net>
> I would like to use pgmodeler in Stretch, but the program can't work
> with PostgreSQL 9.6, also in Stretch. I get an error message that only
> versions up to 9.5 are supported, and that's the end of the story.

Oops.

We've only recently imported pgmodeler into the PostgreSQL team, so
obviously this incompatibility fell through the cracks. Sorry.

I don't see that we can realistically upgrade pgmodeler in stretch, so
there's two workarounds available: using pgmodeler from buster, or use
the stretch-pgdg distribution from apt.postgresql.org.

Christoph

Bug#891067: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Geert Stappers]

On Thu, Feb 22, 2018 at 10:28:09AM +0200, Doru Iorgulescu wrote:
> Hello,
> My error:
> I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid/ to
> /usr/src/linux-4.9.82/drivers/scsi/megaraid/
> I compile the kernel 4.9.82, and the result is OK!

Bugreport #891067 now updated with that information ( /ser/ versus /src/ )

Bug#891081: 5.6.2 regression: dns attributes are lost (patch)

[Harald Dunkel]

Package: strongswan-nm
Version: 5.6.2-1
Tags: patch

Using the new strongswan 5.6.2 (on Stretch) together with the
old network-manager-strongswan 1.4.2 the nameserver entries
in the generated /etc/resolv.conf are broken. They contain
some fantasy IP addresses, but not the addresses defined on
the peer. DNS lookup is broken.

Tobias Brunner provided a patch for charon-nm, see attachment.

https://lists.strongswan.org/pipermail/dev/2018-February/001870.html


Regards
Harri
diff --git a/src/charon-nm/nm/nm_service.c b/src/charon-nm/nm/nm_service.c
index 9beac392a..c42733181 100644
--- a/src/charon-nm/nm/nm_service.c
+++ b/src/charon-nm/nm/nm_service.c
@@ -65,8 +65,7 @@ static GVariant* handler_to_variant(nm_handler_t *handler,
 	enumerator = handler->create_enumerator(handler, type);
 	while (enumerator->enumerate(enumerator, ))
 	{
-		g_variant_builder_add (, "u",
-			   g_variant_new_uint32 (*(uint32_t*)chunk.ptr));
+		g_variant_builder_add (, "u", *(uint32_t*)chunk.ptr);
 	}
 	enumerator->destroy(enumerator);
 

Bug#891080: Generate a skeleton of debian/upstream/metadata using upstream inst/CITATION

[Dylan Aïssi]

Package: dh-r
Severity: wishlist


Hi,

dh-make-R (and dh-update-R) could generate (and update) a
d/upstream/metadata file or at least a skeleton with relevant
information from the upstream inst/CITATION file. Lintian will now
emit an (experimental) tag when the metadata file is missing [1].

Best,
Dylan

[1] https://lintian.debian.org/tags/upstream-metadata-file-is-missing.html

Bug#891079: newer kernel supports new hardware

[Geert Stappers]

Package: debian-kernel-handbook

On Thu, Feb 22, 2018 at 09:20:22AM +0100, Geert Stappers wrote:
> On Thu, Feb 22, 2018 at 06:21:00AM +0200, Doru Iorgulescu wrote:
> > I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid/ to
> > /usr/ser/linux-4.9.82/drivers/scsi/megaraid/
> > I compile the kernel 4.9.82, and the result is OK!
> > 
> > It is possible a kernel patch for that ?
> 
>:-)
> 
> I think that question is some what crippled by a language problem 
> or another source for misunderstanding.
> 

The question was raised
as https://lists.debian.org/debian-boot/2018/02/msg00339.html
and https://lists.debian.org/debian-kernel/2018/02/msg00194.html
and became https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891067

This bugreport against Debian kernel handbook is for asking 
to document what to do when new kernel supports new hardware.

That `make deb` builds a .deb which can be installed
with `dpkg -i ../linux-image-*.deb`

What the policy is about backporting and releasing new kernels in stable.
(See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890393 )


The idea, the wish, is that upon future simular questions
posted at d-kernel@l.d.o  and/or  d-boot@l.d.o. can be answered with:

  Please visit  URL=at=kernel=handbook for information what you can do


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#891072: [PATCH] Add golang-missing-built-using and golang-built-using-on-arch-all

[Chris Lamb]

Hi Michael,

> >
> > +Tag: golang-missing-built-using
> > +Tag: golang-built-using-on-arch-all
> >
> > These seem quite "clumsy" wordings and difficult to understand when
> > out of context - can you try expanding them a little?
>
> Can you make a suggestion as to how they would be clearer please?

Hm. The difficult part of parsing it is the "built using" proper noun.
I don't have any thing I love but have you tried adding more nouns,
etc.? For example, golang-package-missing-built-using-{header,field}?
Or missing-built-using-X-for-golang-package. Or golang-built-using-
field-on-arch-all-package? Or arch-all-golang-package-{with,but}-built-
using-{field,header}. Or something.  :)

> > +if ($arch eq 'all
> >  […]
> > +if ($arch ne 'all'
[…]
> What would you consider cleaner? It seems fine to me.

I don't have a concrete example but my gut tells me there is a cleaner
structure that uses the fact that if $arch is "all", we don't need to
check 2 lines down that it is not "all". Again, nothing concrete but
some kind of "else" statement? :p 

> > Are we missing a Test-Depends in the "desc" file too? :)
> >
> Not sure what you mean?

Tests have a "/desc" file with Test-For, Test-Against etc. I am
querying whether this file should also have something along the
lines of:

  t/tests/elpa/desc:
  5:Test-Depends: dh-elpa

(Just a question, I don't have the answer to hand..!)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#890190: [compiz-plugins-default] Plugin "wall" doesn't honor edge-delay

[Alex ARNAUD]

Le 21/02/2018 à 21:31, Johann Glaser a écrit :

However, please consider distibuting a patched version of
/usr/share/compiz/wall.xml with false before
upstream is fixing it.


Could you open an upstream bug about that particular point to propose 
the change and explain why? I prefer to see the answer of the upstream 
developers to be sure the decision has no side effect for other users as 
I'm not an expert of the Wall module.


FYI, a new Compiz release has been published on Debian, could you tell 
us if the issue of this bug still appear?


Best regards and thank you very much for your contribution.
Alex ARNAUD.

Bug#891078: EDAC MC0: Giving out device to module skx_edac.c controller Skylake Socket#0 IMC#0: DEV 0000:3a:0a.0 (INTERRUPT)

[Doru Iorgulescu]

Package: linux-image-4.14.0-3-amd64
Version: 4.14.13-1

Dear kernel mainainers,

Scope:
Debian buster on DMI: Intel Corporation S2600WFT/S2600WFT, BIOS
SE5C620.86B.00.01.0009.101920170742 10/19/2017

The problem not apear in Debian Stretch

I send dmesg for Debian buster.

Thank you,
Doru Iorgulescu


dmesg
Description: Binary data

Bug#891077: kpartx -d doesn't cleanup

[Xavier Bestel]

Package: kpartx
Version: 0.7.4-3
Severity: important

Hi,

If I execute the following testcase:
#!/bin/bash -xe
IMAGE_PATH=bug.img
truncate -s 3608M "${IMAGE_PATH}"
/sbin/sfdisk "${IMAGE_PATH}" <<-__EOF__
4M,512M,L,*
516M,512M,,
1028M,512M,,
1540M,,E,
,64M,,
,64M,,
,,,
__EOF__
sudo kpartx -l "${IMAGE_PATH}"
sudo kpartx -a "${IMAGE_PATH}"
sudo kpartx -d "${IMAGE_PATH}"
then kpartx won't cleanup its loop devices:
$ ls -l /dev/loop* /dev/mapper/
brw-rw 1 root disk  7,   0 févr. 22 09:30 /dev/loop0
brw-rw 1 root disk  7,   1 févr. 22 09:30 /dev/loop1
brw-rw 1 root disk  7,   2 févr. 20 11:38 /dev/loop2
brw-rw 1 root disk  7,   3 févr. 20 11:38 /dev/loop3
brw-rw 1 root disk  7,   4 févr. 20 11:39 /dev/loop4
brw-rw 1 root disk  7,   5 févr. 14 11:35 /dev/loop5
brw-rw 1 root disk  7,   6 févr. 14 11:35 /dev/loop6
brw-rw 1 root disk  7,   7 févr. 14 11:35 /dev/loop7
crw-rw 1 root disk 10, 237 févr. 22 09:12 /dev/loop-control

/dev/mapper/:
total 0
crw--- 1 root root 10, 236 févr.  9 13:54 control
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p1 -> ../dm-0
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p2 -> ../dm-1
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p3 -> ../dm-2
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p4 -> ../dm-3
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p5 -> ../dm-4
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p6 -> ../dm-5
lrwxrwxrwx 1 root root   7 févr. 22 09:30 loop1p7 -> ../dm-6
$ sudo losetup -l
NAME   SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
DIO LOG-SEC
/dev/loop1 0  0 0  0 /home/xav/bug_kaprtx/bug.img   
0 512
/dev/loop0 0  0 0  0 /home/xav/bug_kaprtx/bug.img   
0 512
this is really problematic, because you can't invoke kpartx twice - in
some scripts, the loop devices indices become wrong.

Cheers
Xav

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (500, 'stable-updates'), (90, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kpartx depends on:
ii  dmsetup 2:1.02.145-4.1
ii  libc6   2.26-6
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  udev237-3

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

Bug#891050: gap-autpgrp: please make the build reproducible

[Chris Lamb]

Dear Bill,

> Upstream will never take it. This is not the right way to fix this bug
> and you know it.

I'm afraid I was a little disappointed to read your response. 

It is entirely feasible that upstream would agree with the sentiment
that such timestamps are not useful (or even misleading) and thus
should be removed. I have convinced countless developers in the past
using this or similar arguments.

Furthermore, I did not enjoy being told "I know you know how to do
better" or being informed the patch is "a waste of time". Whatever
the merits of those statements, I could not help but interpret your
tone as needlessly hectoring and, at best, unproductive. As a project,
we should — and can — do better.

> I really mean gap-gapdoc, not this package.
[…] 
> The whole reproducible builds is anxiogen because there are no reliable
> tool to check a package is reproducible

(These are topics/questions outside the scope of this bug report; I fear
we would be doing them a disservice by attempting to cover them here.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#884956: Debian testing

[wm4]

It seems the broken Qt build has reached testing. So much for testing
being better for stability. I wants to upgrade from 5.9.2+dfsg-10 to
5.9.2+dfsg-12.

Bug#890934: [pkg-go] Bug#890934: golang-github-masterzen-winrm: FTBFS and Debci failure with golang-1.10-go

[Michael Stapelberg]

This issue is tracked upstream at
https://github.com/masterzen/winrm/issues/77

On Tue, Feb 20, 2018 at 8:09 PM, Adrian Bunk  wrote:

> Source: golang-github-masterzen-winrm
> Version: 0.0~git20170601.0.1ca0ba6-2
> Severity: serious
>
> https://ci.debian.net/packages/g/golang-github-masterzen-winrm/unstable/
> amd64/
> https://tests.reproducible-builds.org/debian/rb-pkg/
> unstable/amd64/golang-github-masterzen-winrm.html
>
> ...
>dh_auto_test -O--buildsystem=golang
> cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16
> github.com/masterzen/winrm github.com/masterzen/winrm/soap
> === RUN   Test
>
> --
> FAIL: golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/
> obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go:89:
> WinRMSuite.TestRunWithString
>
> golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/
> obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go:100:
> ...open golang-github-masterzen-winrm_0.0~git20170601.0.1ca0ba6-2/
> obj-x86_64-linux-gnu/src/github.com/masterzen/winrm/client_test.go: no
> such file or directory
> ... obtained string = "That's all folks!!!\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
>  \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
>  x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
> ... expected string = "That's all folks!!!"
>
> OOPS: 36 passed, 1 FAILED
> --- FAIL: Test (5.25s)
> FAIL
> FAILgithub.com/masterzen/winrm  5.282s
> === RUN   Test
> OK: 6 passed
> --- PASS: Test (0.01s)
> === RUN   TestAddUsualNamespaces
> --- PASS: TestAddUsualNamespaces (0.00s)
> === RUN   TestSetTo
> --- PASS: TestSetTo (0.00s)
> PASS
> ok  github.com/masterzen/winrm/soap 0.027s
> dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16
> github.com/masterzen/winrm github.com/masterzen/winrm/soap returned exit
> code 1
> make: *** [debian/rules:6: build] Error 1
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#890939: [pkg-go] Bug#890939: etcd FTBFS

[Michael Stapelberg]

Half of this issue can be fixed by re-generating the codec files by setting
“export DH_GOLANG_GO_GENERATE := 1” in debian/rules and adding a
Build-Depends: golang-github-ugorji-go-codec to debian/control.

I haven’t figured out how to re-generate the remaining (failing) files yet.

On Tue, Feb 20, 2018 at 8:57 PM, Adrian Bunk  wrote:

> Source: etcd
> Version: 3.2.9+dfsg-3
> Severity: serious
> Control: affects -1 src:docker-libkv src:golang-github-spf13-viper
> src:golang-github-xordataexchange-crypt src:skydns
>
> Some recent change in unstable makes etcd FTBFS:
>
> https://tests.reproducible-builds.org/debian/history/etcd.html
> https://tests.reproducible-builds.org/debian/rb-pkg/
> unstable/amd64/etcd.html
>
> ...
> github.com/coreos/etcd/mvcc
> # github.com/coreos/etcd/etcdserver/api/v3election/v3electionpb/gw
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:147:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:149:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:154:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:158:30: not enough arguments in call
> to forward_Election_Campaign_0
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, proto.Message, []func("
> golang.org/x/net/context".Context, http.ResponseWriter, proto.Message)
> error...)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, proto.Message,
> ...func("golang.org/x/net/context".Context, http.ResponseWriter,
> proto.Message) error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:175:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:177:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:182:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:186:30: not enough arguments in call
> to forward_Election_Proclaim_0
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, proto.Message, []func("
> golang.org/x/net/context".Context, http.ResponseWriter, proto.Message)
> error...)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> runtime.Marshaler, http.ResponseWriter, *http.Request, proto.Message,
> ...func("golang.org/x/net/context".Context, http.ResponseWriter,
> proto.Message) error)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:203:39: not enough arguments in call
> to runtime.AnnotateContext
> have ("golang.org/x/net/context".Context, *http.Request)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> *http.Request)
> src/github.com/coreos/etcd/etcdserver/api/v3election/
> v3electionpb/gw/v3election.pb.gw.go:205:21: not enough arguments in call
> to runtime.HTTPError
> have ("golang.org/x/net/context".Context, runtime.Marshaler,
> http.ResponseWriter, *http.Request, error)
> want ("golang.org/x/net/context".Context, *runtime.ServeMux,
> 

Bug#891075: clfft: please make the build (partly) reproducible

[Chris Lamb]

Source: clfft
Version: 2.12.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that clfft could not be built reproducibly.

Patch attached that fixes the documentation (at least), but this
does not resolve all the issues in the package — an "unrelated"
binary is also not reproducible.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/docs/clFFT.doxy b/docs/clFFT.doxy
index 131a454..c2241f2 100644
--- a/docs/clFFT.doxy
+++ b/docs/clFFT.doxy
@@ -140,7 +140,7 @@ INLINE_INHERITED_MEMB  = NO
 # shortest path that makes the file name unique will be used
 # The default value is: YES.
 
-FULL_PATH_NAMES= YES
+FULL_PATH_NAMES= NO
 
 # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
 # Stripping is only done if one of the specified strings matches the left-hand

Bug#891076: docker.io: docker version (1.13.1) in sid reached EOL

[Jan Christoph Uhde]

Package: docker.io
Version: 1.13.1~ds2-3+b1
Severity: wishlist

Dear Maintainer,

we had a look at https://success.docker.com/article/Maintenance_Lifecycle and
noticed that the docker version in sid reached EOL. Our docker / kubernetes guy
requires a newer version. I am reluctant to use 3rd party packages (the debian
installation guide on docker.io does not even work for sid), that is why I
would be really glad if there would be an upgrade soon. Please let me know if I
can help building or testing a new version. I am happy to invest a few hours or
a day into this.

~ Jan

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
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 /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser 3.117
ii  docker-containerd   0.2.3+git+docker1.13.1~ds1-1
ii  docker-runc 1.0.0~rc2+git+docker1.13.1~ds1-3
ii  golang-libnetwork   0.8.0-dev.2+git20170202.599.45b4086-3
ii  iptables1.6.2-1
ii  libapparmor12.12-2
ii  libc6   2.26-6
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libsqlite3-03.22.0-1
ii  libsystemd0 237-3
ii  lsb-base9.20170808

Versions of packages docker.io recommends:
ii  ca-certificates  20170717
ii  cgroupfs-mount   1.4
ii  git  1:2.16.1-1
ii  xz-utils 5.2.2-1.3

Versions of packages docker.io suggests:
ii  aufs-tools   1:4.9+20170918-1
ii  btrfs-progs  4.15.1-1
ii  debootstrap  1.0.93
ii  docker-doc   1.13.1~ds2-3
ii  rinse3.2
ii  zfs-fuse 0.7.0-18

-- no debconf information

Bug#891072: [PATCH] Add golang-missing-built-using and golang-built-using-on-arch-all

[Michael Stapelberg]

Thanks for the quick review! Comments inline:

On Thu, Feb 22, 2018 at 9:31 AM, Chris Lamb  wrote:

> tags 891072 - patch
> thanks
>
> Dear Michael,
>
> > Please review and merge the attached patch. Thanks!
>
> Thank you so much for your patch. Can you fix up the following small
> things?  Naturally, please re-add the "patch" tag when ready :)
>
>
> +Tag: golang-missing-built-using
> +Tag: golang-built-using-on-arch-all
>
> These seem quite "clumsy" wordings and difficult to understand when
> out of context - can you try expanding them a little?
>

Can you make a suggestion as to how they would be clearer please?
I can’t come up with anything. Probably I’m stuck too deep in the subject
matter :).


>
> In addition, please make it very explicit about what them maintainer
> should do if they see this message. For example, something phrased
> along the lines of "please add..."
>

Done.


>
>
> +Info: This package builds a binary package which is not including
>  ^
>   does not include
>
> + ${misc:Built-Using} in its Built-Using control field.
>   ^^^^^^
> …… 
>
>
>
Done.


> +if ($arch eq 'all
>  […]
> +if ($arch ne 'all'
>
> Is there a cleaner way of structuring these?
>

What would you consider cleaner? It seems fine to me.


>
> +++ a/t/tests/binaries-golang-built-using/desc
>   ^
> This probably should be prefixed with "control-file-" as that's the
> name of checks/foo.pm.
>

Done.


>
> Are we missing a Test-Depends in the "desc" file too? :)
>

Not sure what you mean?


>
> Thanks again!
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>



-- 
Best regards,
Michael
From c04498f4c71d62cac9e3760c395ae847bf5f5040 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Thu, 22 Feb 2018 09:11:20 +0100
Subject: [PATCH] Add golang-missing-built-using and
 golang-built-using-on-arch-all

---
 checks/control-file.desc   | 23 +
 checks/control-file.pm | 15 
 t/tests/binaries-golang/desc   |  1 +
 t/tests/binaries-golang/tags   |  1 +
 .../debian/Makefile| 16 +
 .../control-file-golang-built-using/debian/basic.c | 12 +++
 .../debian/debian/control.in   | 40 ++
 t/tests/control-file-golang-built-using/desc   |  6 
 t/tests/control-file-golang-built-using/tags   |  1 +
 9 files changed, 115 insertions(+)
 create mode 100644 t/tests/control-file-golang-built-using/debian/Makefile
 create mode 100644 t/tests/control-file-golang-built-using/debian/basic.c
 create mode 100644 t/tests/control-file-golang-built-using/debian/debian/control.in
 create mode 100644 t/tests/control-file-golang-built-using/desc
 create mode 100644 t/tests/control-file-golang-built-using/tags

diff --git a/checks/control-file.desc b/checks/control-file.desc
index 2b2516bfc..a1399ec9a 100644
--- a/checks/control-file.desc
+++ b/checks/control-file.desc
@@ -350,3 +350,26 @@ Info: This package builds a binary package containing at least one path
  Please specify (eg.) Rules-Requires-Root: binary-targets in
  the debian/control source stanza.
 Ref: /usr/share/doc/dpkg-dev/rootless-builds.txt.gz
+
+Tag: golang-missing-built-using
+Severity: wishlist
+Certainty: certain
+Info: This package builds a binary package which does not include
+ ${misc:Built-Using} in its Built-Using control field.
+ .
+ The ${misc:Built-Using} substvar is populated by dh-golang(1)
+ and used for scheduling binNMUs.
+ .
+ Please add the following line to your package definition:
+ .
+ Built-Using: ${misc:Built-Using}
+
+Tag: golang-built-using-on-arch-all
+Severity: wishlist
+Certainty: certain
+Info: This package builds a binary arch:all package which incorrectly
+ specifies a Built-Using control field.
+ .
+ Built-Using only applies to architecture-specific packages.
+ .
+ Please remove the Built-Using line from your package definition.
\ No newline at end of file
diff --git a/checks/control-file.pm b/checks/control-file.pm
index f2a97b24d..8d8a1caac 100644
--- a/checks/control-file.pm
+++ b/checks/control-file.pm
@@ -427,6 +427,21 @@ sub run {
   unless $relation->implies('${gir:Depends}');
 }
 
+# Verify that golang binary packages set Built-Using (except for arch:all
+# library packages).
+if ($info->relation('build-depends')->implies('golang-go | golang-any')) {
+foreach my $bin (@package_names) {
+my $bu = $info->binary_field($bin, 'built-using');
+my $arch = $info->binary_field($bin, 'architecture');
+if ($arch eq 'all' && defined($bu)) {
+tag 

Bug#890243: [Pkg-tcltk-devel] Bug#890243: tcl8.6: Please stop linking with libieee.a, removed in glibc 2.27

[Sergei Golovan]

Hi Aurelien,

On Mon, Feb 12, 2018 at 2:55 PM, Aurelien Jarno  wrote:
>
> Starting with glibc 2.27, support for the "ieee" library (part of SVID
> specification) has been removed. The libieee.a library is therefore not
> shipped anymore.
>
> tcl8.6 already works without this library however the configure script
> detects it and enable support for it if available. The side effects are
> that the "-lieee" link option is then shipped in tclConfig.sh, and that
> the library ends up with the _LIB_VERSION symbol.
>
> To avoid ease the glibc 2.27, I believe it's better to separate the two.
> I have therefore attached a patch to always disable libieee support in
> tcl8.6. The patch can be removed once glibc 2.27 is in testing (but can
> also be kept safely). It will require tk8.6 to be rebuilt against the
> new tcl8.6 as it also exports the "-lieee" link option through
> tkConfig.sh and also removes the _LIB_VERSION symbol. A patch is also
> attached for that.
>
> Do you feel it is an acceptable way to proceed. Another alternative
> would be to just declare the _LIB_VERSION symbol as optional in both
> tcl8.6 and tk8.6, and handle the change through binNMUs as part of the
> glibc 2.27 transition. Please feel free to suggest other options.

It's okay to me to apply this patch and dropped linking to libieee preemptively.
Tcl tests seem to be okay without libieee, so I'll upload the patched package
shortly along with tcl/tk 8.5 and 8.7 (in experimental).

Cheers!
-- 
Sergei Golovan

Bug#891072: [PATCH] Add golang-missing-built-using and golang-built-using-on-arch-all

[Chris Lamb]

tags 891072 - patch
thanks

Dear Michael,

> Please review and merge the attached patch. Thanks!

Thank you so much for your patch. Can you fix up the following small
things?  Naturally, please re-add the "patch" tag when ready :)


+Tag: golang-missing-built-using
+Tag: golang-built-using-on-arch-all

These seem quite "clumsy" wordings and difficult to understand when
out of context - can you try expanding them a little?

In addition, please make it very explicit about what them maintainer
should do if they see this message. For example, something phrased
along the lines of "please add..."


+Info: This package builds a binary package which is not including
 ^
  does not include

+ ${misc:Built-Using} in its Built-Using control field.
  ^^^^^^
……  


+if ($arch eq 'all
 […]
+if ($arch ne 'all'

Is there a cleaner way of structuring these?

+++ a/t/tests/binaries-golang-built-using/desc
  ^
This probably should be prefixed with "control-file-" as that's the
name of checks/foo.pm.

Are we missing a Test-Depends in the "desc" file too? :)

Thanks again!


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#891074: ITP: you-get/0.4.1025 -- command-line utility to download media contents (videos, audios, images) from the Web

[Lumin]

Package:wnpp
Severity: wishlist
Owner: lumin 

* Package name: you-get
  Version : 0.4.1025
  Upstream Author : https://github.com/soimort
* URL : https://github.com/soimort/you-get
* License : MIT
  Programming Lang: awk
  Description : command-line utility to download media
contents (videos, audios, images) from the Web


-- 
Best,

Bug#891063: emacs25: dconf-CRITICAL errors

[Vincent Lefevre]

On 2018-02-21 22:41:53 -0800, Rob Browning wrote:
> Vincent Lefevre  writes:
> 
> > Package: emacs25
> > Version: 25.2+1-6+b1
> > Severity: grave
> > Justification: renders package unusable
> 
> I'm not sure I understand yet how this makes Emacs unusable -- does it
> warn or crash?

Well, there are critical errors. So this must be really important.
I'm wondering whether this may cause data corruption.

Moreover, each time I start emacs, it takes 24 lines of the terminal
due to these errors, hiding important information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#891073: clblas: please make the build reproducible

[Chris Lamb]

Source: clblas
Version: 2.12-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that clblas could not be built reproducibly.

Patch attached. You probably want to merge it with the existing
patch against the Doxygen config file. :)

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build-2.patch 1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build-2.patch 2018-02-22 08:11:35.109200418 
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-02-22
+
+--- clblas-2.12.orig/doc/clBLAS.doxy
 clblas-2.12/doc/clBLAS.doxy
+@@ -119,7 +119,7 @@ INLINE_INHERITED_MEMB  = NO
+ # path before files name in the file list and in the header files. If set 
+ # to NO the shortest path that makes the file name unique will be used.
+ 
+-FULL_PATH_NAMES= YES
++FULL_PATH_NAMES= NO
+ 
+ # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag 
+ # can be used to strip a user-defined part of the path. Stripping is 
--- a/debian/patches/series 2018-02-22 08:03:54.400483178 +
--- b/debian/patches/series 2018-02-22 08:11:34.165191547 +
@@ -5,3 +5,4 @@
 reproducible-build.patch
 use-boost-dynamic-libs.patch
 Detect-CBLAS-when-building-the-client.patch
+reproducible-build-2.patch

Bug#889539: pandas FTBFS: test failures

[Lumin]

Yaroslav has just uploaded pandas 0.22.0, let's see if this problem
still exists.

On 7 February 2018 at 14:57, Andreas Tille  wrote:
> On Tue, Feb 06, 2018 at 03:51:27PM +, Lumin wrote:
>> Apart from that, the pandas packaging needs a patch [2] to reduce
>> autopkgtest failures.
>
> As always:  Please push your patches. :-)
> You and I are in the same position: We are team members of the maintainer
> team.  I even have the strong impression, that you are the more competent
> team member than me in terms of pandas.  So please do not be shy. ;-)
>
> Thanks a lot and feel to keep on pushing promising patches
>
> Andreas.
>
>> [2]
>> diff --git a/debian/tests/control b/debian/tests/control
>> index 38521c8..ab54101 100644
>> --- a/debian/tests/control
>> +++ b/debian/tests/control
>> @@ -15,6 +15,7 @@ Depends: python-all,
>>   python-xlwt,
>>   python-bs4,
>>   python-html5lib,
>> + python-pytest,
>>   xauth,
>>   xvfb
>>
>> @@ -29,5 +30,6 @@ Depends: python3-all,
>>   python3-tk,
>>   python3-tz,
>>   python3-bs4,
>> + python3-pytest,
>>   xauth,
>>   xvfb
>
> --
> http://fam-tille.de



-- 
Best,

Bug#891067: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Geert Stappers]

Control: tag -1 +patch

On Thu, Feb 22, 2018 at 06:21:00AM +0200, Doru Iorgulescu wrote:
> I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid/ to
> /usr/ser/linux-4.9.82/drivers/scsi/megaraid/
> I compile the kernel 4.9.82, and the result is OK!

Bugreport tagged with 'patch',  hope this helps.


> It is possible a kernel patch for that ?

   :-)

I think that question is some what crippled by a language problem 
or another source for misunderstanding.



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#891072: [PATCH] Add golang-missing-built-using and golang-built-using-on-arch-all

[Michael Stapelberg]

Package: lintian
Version: 2.5.72
Severity: wishlist
Tags: patch

Please review and merge the attached patch. Thanks!

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

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-6
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.38-2+b2
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-5
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-1
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information
>From 7318d47e2caff903267d0235d7ef3069d74041a5 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Thu, 22 Feb 2018 09:11:20 +0100
Subject: [PATCH] Add golang-missing-built-using and
 golang-built-using-on-arch-all

---
 checks/control-file.desc   | 17 +
 checks/control-file.pm | 15 
 .../binaries-golang-built-using/debian/Makefile| 16 +
 t/tests/binaries-golang-built-using/debian/basic.c | 12 +++
 .../debian/debian/control.in   | 40 ++
 t/tests/binaries-golang-built-using/desc   |  6 
 t/tests/binaries-golang-built-using/tags   |  1 +
 t/tests/binaries-golang/desc   |  1 +
 t/tests/binaries-golang/tags   |  1 +
 9 files changed, 109 insertions(+)
 create mode 100644 t/tests/binaries-golang-built-using/debian/Makefile
 create mode 100644 t/tests/binaries-golang-built-using/debian/basic.c
 create mode 100644 t/tests/binaries-golang-built-using/debian/debian/control.in
 create mode 100644 t/tests/binaries-golang-built-using/desc
 create mode 100644 t/tests/binaries-golang-built-using/tags

diff --git a/checks/control-file.desc b/checks/control-file.desc
index 2b2516bfc..9743aad81 100644
--- a/checks/control-file.desc
+++ b/checks/control-file.desc
@@ -350,3 +350,20 @@ Info: This package builds a binary package containing at 
least one path
  Please specify (eg.) Rules-Requires-Root: binary-targets in
  the debian/control source stanza.
 Ref: /usr/share/doc/dpkg-dev/rootless-builds.txt.gz
+
+Tag: golang-missing-built-using
+Severity: wishlist
+Certainty: certain
+Info: This package builds a binary package which is not including
+ ${misc:Built-Using} in its Built-Using control field.
+ .
+ The ${misc:Built-Using} substvar is populated by dh-golang(1)
+ and used for scheduling binNMUs.
+
+Tag: golang-built-using-on-arch-all
+Severity: wishlist
+Certainty: certain
+Info: This package builds a binary arch:all package which incorrectly
+ specifies a Built-Using control field.
+ .
+ Built-Using only applies to architecture-specific packages.
diff --git a/checks/control-file.pm b/checks/control-file.pm
index f2a97b24d..8d8a1caac 100644
--- a/checks/control-file.pm
+++ b/checks/control-file.pm
@@ -427,6 +427,21 @@ sub run {
   unless $relation->implies('${gir:Depends}');
 }
 
+# Verify that golang binary packages set Built-Using (except for arch:all
+# library packages).
+if ($info->relation('build-depends')->implies('golang-go | golang-any')) {
+foreach my $bin (@package_names) {
+my $bu = $info->binary_field($bin, 'built-using');
+  

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Teus Benschop]

Hello Berto,

The updated webkit2gtk from the experimental branch fixes the segmentation
fault.

Thank you for making it available.

There's just one thing that is different from before: After installing from
experimental, when running bibledit, it now says this:

*teus@debian-sid-gui*:*~*$ bibledit

WaylandCompositor requires eglBindWaylandDisplayWL,
eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.

Nested Wayland compositor could not initialize EGL


However, Bibledit itself runs perfectly normal, there's no segmentation
fault anymore.

Bug#888955: Better fix suggestion

[Christian Ehrhardt]

Hi,
I just reported a bug but now realized this is the same one.
Please dup/close the new bug appearing any minute as you want.
(copy my update here)

Default Dependencies will cause dependency loop.
Here a full analysis and suggestion ...

I've also got reported issues which looked like a failed to start service
on boot with:
   Active: failed (Result: resources)

A restart on the system after boot worked.

The actual issue was eventually to be found as: "Read-only file system".
After a while I realized we essentially hit [1].

Since [2] the service sets DefaultDependencies=no
But OTOH we use "PrivateTmp=yes" which needs writable /var/tmp.

The combination of the above without precaution is the issue as it may
be started before all file systems are up.

I propose a change to the dependencies that in all my tests worked fine with:
1. still being before cloud-init
2. the file system being ready and no more hitting the issue

--- a/debian/open-vm-tools.service
+++ b/debian/open-vm-tools.service
@@ -4,6 +4,7 @@ Documentation=http://open-vm-tools.sourceforge.net/about.php
ConditionVirtualization=vmware
DefaultDependencies=no
Before=cloud-init-local.service
+After=local-fs.target

[Service]
ExecStart=/usr/bin/vmtoolsd



[1]: 
https://github.com/systemd/systemd/blob/2e6dbc0fcd45c152f15aed77cde4fd07957c150c/src/core/service.c#L1832
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#891071: Race on startup can let the service completely fail

[Christian Ehrhardt]

Package: open-vm-tools
Version: 2:10.2.0-3

Hi,
I've got reported issues which looked like a failed to start service
on boot with:
   Active: failed (Result: resources)

A restart on the system after boot worked.

The actual issue was eventually to be found as: "Read-only file system".
After a while I realized we essentially hit [1].

Since [2] the service sets DefaultDependencies=no
But OTOH we use "PrivateTmp=yes" which needs writable /var/tmp.

The combination of the above without precaution is the issue as it may
be started before all file systems are up.

I propose a change to the dependencies that in all my tests worked fine with:
1. still being before cloud-init
2. the file system being ready and no more hitting the issue

--- a/debian/open-vm-tools.service
+++ b/debian/open-vm-tools.service
@@ -4,6 +4,7 @@ Documentation=http://open-vm-tools.sourceforge.net/about.php
ConditionVirtualization=vmware
DefaultDependencies=no
Before=cloud-init-local.service
+After=local-fs.target

[Service]
ExecStart=/usr/bin/vmtoolsd



[1]: 
https://github.com/systemd/systemd/blob/2e6dbc0fcd45c152f15aed77cde4fd07957c150c/src/core/service.c#L1832
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd