Bug#885353: mirage: Python2 removal in sid/bullseye

2020-01-02 Thread Thomas Ross
I've started to port Mirage to Python 3 + PyGObject here: 
https://gitlab.com/thomasross/mirage/tree/python3


On Fri, 30 Aug 2019 07:26:43 + Matthias Klose  wrote:

Package: src:mirage
Version: 0.9.5.2-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.


- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:mirage

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.






Bug#946241: ffmpeg: please make autopkgtests cross-test-friendly

2020-01-02 Thread Sebastian Ramacher
On 2020-01-03 01:08:14, James Cowgill wrote:
> Hi,
> 
> On 06/12/2019 03:33, Steve Langasek wrote:
> > Package: ffmpeg
> > Version: 7:4.2.1-2
> > Severity: minor
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu focal ubuntu-patch
> > 
> > Dear maintainers,
> > 
> > In Ubuntu, we are in the process of moving the i386 architecture to a
> > compatibility-only layer on amd64, and therefore we are also moving our
> > autopkgtest infrastructure to test i386 binaries in a cross-environment.
> > 
> > This requires changes to some tests so that they are cross-aware and can do
> > the right thing.
> 
> [...]
> > 
> > --- ffmpeg-4.2.1/debian/tests/control   2019-11-01 18:17:31.0 
> > -0700
> > +++ ffmpeg-4.2.1/debian/tests/control   2019-12-05 17:17:44.0 
> > -0800
> > @@ -5,4 +5,4 @@
> >  Depends: ffmpeg
> >  
> >  Tests: encdec-extra
> > -Depends: ffmpeg, libavcodec-extra
> > +Depends: ffmpeg, libavcodec-extra58
> 
> Am I right in thinking this is necessary because libavcodec-extra is an
> "arch all multi-arch foreign" package?
> 
> I'm wondering if marking libavcodec-extra (and libavfilter-extra) like
> that is wrong because the behavior of these packages depends on what the
> native architecture is, but I'm not sure. It currently installs the
> native arch's libavcodec-extra library which doesn't seem right for a
> multi-arch foreign package. I don't know if anyone from the multimedia
> team knows why it's done this way (maybe just historical)?
> 
> Making the package "arch any multi-arch same" seems sensible to me, or
> just removing the packages altogether (we already have a Provides:
> libavcodec-extra on the real library packages so the existing
> dependencies should work still).

The package is intended for users that want the extra codecs. So
converting it to arch any would be fine, dropping it not.

Best

> 
> Thanks,
> James
> 




-- 
Sebastian Ramacher



Bug#885815: fcitx-configtool-gtk2: Depends on libunique

2020-01-02 Thread Changwoo Ryu
Control: tags -1 + pending

On Fri, 29 Dec 2017 21:45:12 -0500 Jeremy Bicha  wrote:
> Package: fcitx-configtool-gtk2
> Version: 0.4.9-1
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs libunique
> Tags: sid buster
>
> As announced [1], we do not intend to release Debian 10 "Buster" with
> the old libgnome (and related) libraries. These libraries have been
> deprecated and unmaintained for several years.
>
> Your package depends and or build-depends on libunique.
>
> Please consider dropping fcitx-configtool-gtk2 to help us achieve this
> goal.
>
> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html
>
> On behalf of the Debian GNOME team,
> Jeremy Bicha

Hello, Jeremy.

Your 0.4.10-3 upload two months ago has been auto-rejected as it refers
"orig.tar.gz" file instead of "orig.tar.xz". Could you upload again with
existing orig tarball?

Thanks,
Changwoo Ryu


Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation

2020-01-02 Thread Paul Gevers
Hi all,

On 02-01-2020 19:29, Graham Inggs wrote:
> As of now, lazarus 2.0.6+dfsg-3 has failed its autopkgtests 2 out of
> 11 times on amd64 [1], and 3 out of 11 times on arm64 [2].
> 
> I am hesitant to re-open this bug as RC, as it potentially removes all
> packages built with lazarus for no good reason.
> 
> 
> [1] https://ci.debian.net/packages/l/lazarus/testing/amd64/
> [2] https://ci.debian.net/packages/l/lazarus/testing/arm64/

I propose we mark the test as flaky until somebody is able to completely
fix it or until the statistics have dramatically improved.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#947976: license problems

2020-01-02 Thread Sebastiaan Couwenberg
On 1/2/20 11:58 PM, Thorsten Alteholz wrote:
>  CODE_OF_CONDUCT.md not accounted for in d/copyright (it's CC-BY-4.0).

You really had to dig for that one.

>  Copyright for docs/auth.html wrong, and the file seems to be generated
>  from auth.md -- can you confirm we can regenerate it with tools in the
>  archive?

What makes you say the copyright is wrong? It falls under the "Files: *"
section, which is BSD-3-Clause after the relicensing from the NetCDF
license.

doxygen is used to generate the HTML docs, which is part of the build
process.

>  What reason is there to think that docs\unidata_logo_cmyk.png is
>  redistributible?

What reason is there to think that it isn't?

Unidata develops NetCDF and chose to include their logo in the source
tree to use it in the (generated) documentation.

>  Can docs/docmap.pdf be rebuilt?

Why do you care?

>  Are the .dmp, .hdf4 and .nc files in dap4_test/, hdf4_test/ and
>  h5_test/ perhaps generated files?  Can they be regenerated?

They are test data, they shouldn't be regenerated.

>  I think that it would be best to explicitly include the Unidata
>  copyright line from COPYRIGHT in addition to the "University
>  Corporation for Atmospheric Research/Unidata" line.

"2018 Unidata"

is already part of

"1988-2019, University Corporation for Atmospheric Research/Unidata"

I don't see why including the former is in any way better.

> Please take care of these issues.

I've added license & copyright for CODE_OF_CONDUCT.md, that is enough to
fix this issue in my opinion. If you also demand that I fix the pedantic
issues, I'll instead start working on removing netcdf and everything
that depends on it from Debian as I don't enjoy working on these
packages. I only do so because it's currently a dependency of gdal, but
that can be changed.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#947365: transition: libvigraimpex

2020-01-02 Thread Paul Gevers
Hi Andreas,

On 31-12-2019 18:26, Andreas Metzler wrote:
> On 2019-12-31 Sebastiaan Couwenberg  wrote:
>> I would commit the change now, and upload it after the testing migration
>> unless there are other blockers that hold up the migration for more than
>> 5 days, then I would upload it now.
> 
> Afaict the involved packages should propagate to testing in 3 days, when
> enblend-enfuse is old enough. I have commited the fix. [1]

Unfortunately libvigraimpex is (hopefully only temporarily) blocked by a
bug we had in piuparts and the (automatically) rescheduling of the
failed tests takes some days [1]. So, maybe it would be even faster to
upload the fix now.

Paul

[1] I don't want to manually test all the piuparts failures as there are
too many, and I don't want to blindly ignore those results.



signature.asc
Description: OpenPGP digital signature


Bug#948004: Locked files disappear, reappear after restart

2020-01-02 Thread DAVID TSOUKALOS
Package: apt
Version: 1.3-16

When I invoke `hello' without arguments from an ordinary shell prompt it prints 
`goodbye', rather than the expected `hello, world'. Here is a transcript:

$ hello
goodbye
$ /usr/bin/hello
goodbye
$

I suggest that the output string, in hello.c, be corrected.

I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 and libc6 2.1.3-10.

Bug#947165: transition: llvm-defaults to 9

2020-01-02 Thread Paul Gevers
Control: tags -1 - moreinfo

Hi,

> They build-depend on llvm/clang, not sure whether they are actually part 
> of the transition.

I worked a bit on the tracker page and I think it has a better view of
what is involved (basically limiting "Affected" to the -dev packages
from llvm-defaults).

We currently have a bit much transitions going on (and some backslash
from a piuparts bug), so I'd like to get a bit of those transitions off
the table before starting this one.

I'll let you know, probably in a week or so.

Paul



Bug#948002: prometheus-process-exporter FTBFS in testing/unstable

2020-01-02 Thread peter green

source: prometheus-process-exporter
version: 0.4.0+ds-1
severity: serious
tags: bullseye, sid, ftbfs

prometheus-process-exporter FTBFS in testing/unstable, I first noticed this on 
a raspbian autobuilder, but it's also happening on the reproducible builds 
tests, so it's not raspbian specific.


github.com/ncabatoff/process-exporter/vendor/github.com/ncabatoff/fakescraper
# github.com/ncabatoff/process-exporter/vendor/github.com/ncabatoff/fakescraper
src/github.com/ncabatoff/process-exporter/vendor/github.com/ncabatoff/fakescraper/fakescraper.go:38:2:
 undefined: prometheus.Handler
dh_auto_build: cd build && go install 
-gcflags=all=\"-trimpath=/build/1st/prometheus-process-exporter-0.4.0\+ds/build/src\" 
-asmflags=all=\"-trimpath=/build/1st/prometheus-process-exporter-0.4.0\+ds/build/src\" -v -p 15 
github.com/ncabatoff/process-exporter github.com/ncabatoff/process-exporter/cmd/process-exporter 
github.com/ncabatoff/process-exporter/config github.com/ncabatoff/process-exporter/proc returned exit code 2
make[1]: *** [debian/rules:14: override_dh_auto_build] Error 255




Bug#948003: prometheus-squid-exporter FTBFS in testing/unstable

2020-01-02 Thread peter green

source: prometheus-squid-exporter
version: 1.4+ds-1
severity: serious
tags: bullseye, sid, ftbfs

prometheus-squid-exporter FTBFS in testing/unstable, I first noticed this on a 
raspbian autobuilder, but it's also happening on the reproducible builds tests, 
so it's not raspbian specific.


github.com/boynux/squid-exporter
# github.com/boynux/squid-exporter
src/github.com/boynux/squid-exporter/main.go:38:33: undefined: 
prometheus.Handler
dh_auto_build: cd build && go install 
-gcflags=all=\"-trimpath=/build/1st/prometheus-squid-exporter-1.4\+ds/build/src\" 
-asmflags=all=\"-trimpath=/build/1st/prometheus-squid-exporter-1.4\+ds/build/src\" -v -p 16 -tags  -ldflags 
" -X github.com/prometheus/common/version.Version=1.4+ds -X 
github.com/prometheus/common/version.Revision=1.4+ds-1 -X github.com/prometheus/common/version.Branch=debian/sid -X 
github.com/prometheus/common/version.BuildUser=pkg-go-maintain...@lists.alioth.debian.org -X 
github.com/prometheus/common/version.BuildDate=20190123-11:01:45 -X 
github.com/prometheus/common/version.GoVersion=go1.13.5" github.com/boynux/squid-exporter 
github.com/boynux/squid-exporter/collector github.com/boynux/squid-exporter/types returned exit code 2
make[1]: *** [debian/rules:28: override_dh_auto_build] Error 255




Bug#947960: gdal: Doesn't build on ports without java

2020-01-02 Thread Sebastiaan Couwenberg
On 1/2/20 9:07 PM, Samuel Thibault wrote:
> Sebastiaan Couwenberg, le jeu. 02 janv. 2020 20:51:43 +0100, a ecrit:
>> Is there a particular reason you want to build gdal on hppa, hurd &
>> kfreebsd? Is it blocking any important packages?
> 
> It is directly blocking various packages (see attached list), and from
> there, by dependency, 81 packages in total on hurd-i386.

Most of those packages are maintained by the GIS team as well, and
unlikely to have actual users on those archs.

opencv is known to have made gdal more popular, once it added gdal to
its dependencies the number of users grew significantly. opencv is not
on your list however.

openscenegraph is another slightly more general purpose package, but
like gdal none of its rdeps are very important.

>> I can't imagine actual users of gdal on those archs, but it may be a
>> lack of imagination on my part.
> 
> direct users, possibly not indeed, but indirectly you quickly get
> packages which can be obstacle to other things, e.g. a positioning
> package that would happen to be used by widgets of desktop environments.

Ubuntu has gdal in universe which seems to confirm that is not in the
dependency chain of DEs.

If gnome-maps ever starts supporting local data that may make gdal
significantly more important for desktop environments, but for now it's
mostly a viewer with no GIS dependencies. The same goes for marble in
the KDE ecosystem.

So I don't think you have to worry about not having gdal on these
architectures just yet.

We had a similar situation with proj and its libproj-java package, the
Java build dependencies prevented hurd & kfreebsd from building the
package. With proj being a core library in the geospatial field it
blocked most other GIS packages on those archs. Still not a big loss due
to the lack of actual users. The Java bindings were dropped when they
also broke on release architectures. The same will happen with the Java
bindings in gdal when they break on release architectures.

If a stronger case for gdal on hppa, hurd & kfreebsd can be made, I'll
consider dropping the Java bindings for the sake of ports as well.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#948001: go-dep FTBFS in testing/unstable

2020-01-02 Thread peter green

source: go-dep
version: 0.5.4-2
severity: serious
tags: bullseye, sid, ftbfs

go-dep FTBFS in testing/unstable, I first noticed this on a raspbian 
autobuilder, but it's also happening on the reproducible builds tests, so it's 
not raspbian specific.


make[1]: Entering directory '/build/1st/go-dep-0.5.4'
go: cannot find GOROOT directory: /usr/lib/go-1.8
*** Cannot use default go. Forcing go-1.8.
GOPATH=/build/1st/go-dep-0.5.4/obj-x86_64-linux-gnu go generate 
github.com/golang/dep
go: cannot find GOROOT directory: /usr/lib/go-1.8
make[1]: *** [debian/rules:23: override_dh_auto_build] Error 2




Bug#948000: packer FTBFS in testing/unstable

2020-01-02 Thread peter green

source: packer
version: 1.3.4+dfsg-4
severity: serious
tags: bullseye, sid, ftbfs

packer FTBFS in testing/unstable, I first noticed this on a raspbian 
autobuilder, but it's also happening on the reproducible builds tests, so it's 
not raspbian specific.

Note: I am aware there is an existing FTBFS bug tagged as unreproducible, but 
this seems to be a different issue from the one reported there.


github.com/hashicorp/packer/builder/parallels/pvm
# github.com/hashicorp/packer/builder/openstack
src/github.com/hashicorp/packer/builder/openstack/step_create_volume.go:128:22: 
not enough arguments in call to volumes.Delete
have (*gophercloud.ServiceClient, string)
want (*gophercloud.ServiceClient, string, volumes.DeleteOptsBuilder)
github.com/aws/aws-sdk-go/service/s3/s3iface
github.com/vmware/govmomi/vim25/mo
github.com/hashicorp/packer/provisioner/ansible
github.com/hashicorp/packer/provisioner/ansible-local
github.com/hashicorp/packer/provisioner/breakpoint
github.com/hashicorp/packer/builder/hyperv/iso
github.com/hashicorp/packer/builder/hyperv/vmcx
github.com/hashicorp/packer/provisioner/chef-client
github.com/hashicorp/packer/provisioner/chef-solo
github.com/hashicorp/packer/builder/virtualbox/iso
github.com/hashicorp/packer/builder/virtualbox/ovf
github.com/hashicorp/packer/provisioner/converge
github.com/hashicorp/packer/provisioner/file
github.com/hashicorp/packer/provisioner/powershell
github.com/hashicorp/packer/provisioner/puppet-masterless
github.com/hashicorp/packer/provisioner/puppet-server
github.com/hashicorp/packer/packer/rpc
github.com/hashicorp/packer/provisioner/salt-masterless
github.com/hashicorp/packer/provisioner/shell
github.com/hashicorp/packer/builder/vmware/iso
github.com/hashicorp/packer/builder/vmware/vmx
github.com/hashicorp/packer/provisioner/shell-local
github.com/hashicorp/packer/provisioner/windows-restart
github.com/hashicorp/packer/provisioner/windows-shell
# github.com/hashicorp/packer/packer/rpc
src/github.com/hashicorp/packer/packer/rpc/client.go:45:3: cannot use promoted 
field BasicHandle.DecodeOptions.RawToString in struct literal of type 
codec.MsgpackHandle
src/github.com/hashicorp/packer/packer/rpc/server.go:135:3: cannot use promoted 
field BasicHandle.DecodeOptions.RawToString in struct literal of type 
codec.MsgpackHandle
google.golang.org/api/internal
github.com/aws/aws-sdk-go/service/s3/s3manager
google.golang.org/api/option
google.golang.org/api/transport/http
github.com/vmware/govmomi/property
google.golang.org/api/storage/v1
google.golang.org/api/compute/v1
github.com/vmware/govmomi/session
github.com/vmware/govmomi/list
github.com/vmware/govmomi/task
github.com/vmware/govmomi
github.com/hashicorp/packer/builder/cloudstack
github.com/vmware/govmomi/object
github.com/aws/aws-sdk-go/service/ec2/ec2iface
github.com/vmware/govmomi/find
github.com/hashicorp/packer/post-processor/vsphere-template
github.com/hashicorp/packer/builder/amazon/common
github.com/hashicorp/packer/builder/amazon/ebs
github.com/hashicorp/packer/builder/amazon/ebsvolume
github.com/hashicorp/packer/builder/amazon/instance
github.com/hashicorp/packer/builder/amazon/ebssurrogate
github.com/hashicorp/packer/post-processor/amazon-import
github.com/hashicorp/packer/builder/amazon/chroot
github.com/hashicorp/packer/builder/docker
github.com/hashicorp/packer/post-processor/docker-import
github.com/hashicorp/packer/post-processor/docker-tag
github.com/hashicorp/packer/post-processor/docker-push
github.com/hashicorp/packer/post-processor/docker-save
github.com/hashicorp/packer/builder/googlecompute
github.com/hashicorp/packer/post-processor/googlecompute-export
github.com/hashicorp/packer/post-processor/googlecompute-import
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/build/1st/packer-1.3.4\+dfsg/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/build/1st/packer-1.3.4\+dfsg/obj-x86_64-linux-gnu/src\" -v -p 15 
github.com/hashicorp/packer github.com/hashicorp/packer/builder/alicloud/ecs 
github.com/hashicorp/packer/builder/amazon/chroot github.com/hashicorp/packer/builder/amazon/common 
github.com/hashicorp/packer/builder/amazon/ebs github.com/hashicorp/packer/builder/amazon/ebssurrogate 
github.com/hashicorp/packer/builder/amazon/ebsvolume github.com/hashicorp/packer/builder/amazon/instance 
github.com/hashicorp/packer/builder/cloudstack github.com/hashicorp/packer/builder/digitalocean 
github.com/hashicorp/packer/builder/docker github.com/hashicorp/packer/builder/file 
github.com/hashicorp/packer/builder/googlecompute github.com/hashicorp/packer/builder/hyperv/common 
github.com/hashicorp/packer/builder/hyperv/iso github.com/hashicorp/packer/builder/hyperv/vmcx 
github.com/hashicorp/packer/builder/lxc github.com/hashicorp/packer/builder/lxd 
github.com/hashicorp/packer/builder/null github.com/hashicorp/packer/builder/openstack 
github.com/hashicorp/packer/builder/parallels/common github.com/hashicorp/packer/builder/parallels/iso 

Bug#947999: prometheus-varnish-exporter FTBFS in testing/unstable

2020-01-02 Thread peter green

source: prometheus-varnish-exporter
version: 1.5-1
severity: serious
tags: bullseye, sid, ftbfs

prometheus-varnish-exporter FTBFS in testing/unstable, I first noticed this on 
a raspbian autobuilder, but it's also happening on the reproducible builds 
tests, so it's not raspbian specific.


github.com/jonnenauha/prometheus_varnish_exporter
dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 15 
github.com/jonnenauha/prometheus_varnish_exporter
flag provided but not defined: -test.testlogfile
Usage of /tmp/go-build260258336/b001/prometheus_varnish_exporter.test:
   -N string
varnishstat -N value.
   -docker-container-name string
Docker container name to exec varnishstat in.
   -exit-on-errors
Exit process on scrape errors.
   -n string
varnishstat -n value.
   -no-exit
Deprecated: see -exit-on-errors
   -raw
Raw stdout logging without timestamps.
   -test
Test varnishstat availability, prints available metrics and exits.
   -varnishstat-path string
Path to varnishstat. (default "varnishstat")
   -verbose
Verbose logging.
   -version
Print version and exit
   -web.health-path string
Path under which to expose healthcheck. Disabled unless configured.
   -web.listen-address string
Address on which to expose metrics and web interface. (default ":9131")
   -web.telemetry-path string
Path under which to expose metrics. (default "/metrics")
   -with-go-metrics
Export go runtime and http handler metrics
FAILgithub.com/jonnenauha/prometheus_varnish_exporter   0.010s
FAIL
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 15 
github.com/jonnenauha/prometheus_varnish_exporter returned exit code 1




Bug#947998: notary FTBFS in testing/unstable

2020-01-02 Thread peter green

source: notary
version: 0.6.1~ds1-4
severity: serious
tags: bullseye, sid, ftbfs

notary FTBFS in testing/unstable, I first noticed this on a raspbian 
autobuilder, but it's also happening on the reproducible builds tests, so it's 
not raspbian specific.


github.com/theupdateframework/notary/utils
# github.com/theupdateframework/notary/utils
src/github.com/theupdateframework/notary/utils/http.go:112:24: not enough 
arguments in call to challenge.SetHeaders
have (http.ResponseWriter)
want (*http.Request, http.ResponseWriter)
github.com/theupdateframework/notary/server/snapshot
github.com/theupdateframework/notary/client
github.com/theupdateframework/notary/server/timestamp
github.com/theupdateframework/notary/tuf/testutils/interfaces
github.com/theupdateframework/notary/tuf/testutils
github.com/prometheus/client_golang/prometheus/promhttp
google.golang.org/grpc/internal/transport
github.com/docker/go-metrics
github.com/docker/distribution/metrics
github.com/docker/distribution/registry/storage/cache
github.com/docker/distribution/registry/storage/cache/memory
github.com/docker/distribution/registry/client
google.golang.org/grpc
github.com/docker/distribution/registry/client/auth
github.com/theupdateframework/notary/trustmanager/remoteks
github.com/theupdateframework/notary/proto
google.golang.org/grpc/health/grpc_health_v1
github.com/theupdateframework/notary/signer
github.com/theupdateframework/notary/signer/client
google.golang.org/grpc/health
github.com/theupdateframework/notary/signer/api
dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/build/1st/notary-0.6.1\~ds1/_build/src\" 
-asmflags=all=\"-trimpath=/build/1st/notary-0.6.1\~ds1/_build/src\" -v -p 15 -tags pkcs11 
github.com/theupdateframework/notary github.com/theupdateframework/notary/client 
github.com/theupdateframework/notary/client/changelist github.com/theupdateframework/notary/cmd/escrow 
github.com/theupdateframework/notary/cmd/notary github.com/theupdateframework/notary/cmd/notary-server 
github.com/theupdateframework/notary/cmd/notary-signer github.com/theupdateframework/notary/cryptoservice 
github.com/theupdateframework/notary/passphrase github.com/theupdateframework/notary/proto 
github.com/theupdateframework/notary/server github.com/theupdateframework/notary/server/errors 
github.com/theupdateframework/notary/server/handlers github.com/theupdateframework/notary/server/snapshot 
github.com/theupdateframework/notary/server/storage github.com/theupdateframework/notary/server/timestamp 
github.com/theupdateframework/notary/signer github.com/theupdateframework/notary/signer/api 
github.com/theupdateframework/notary/signer/client github.com/theupdateframework/notary/signer/keydbstore 
github.com/theupdateframework/notary/storage github.com/theupdateframework/notary/storage/rethinkdb 
github.com/theupdateframework/notary/trustmanager 
github.com/theupdateframework/notary/trustmanager/remoteks 
github.com/theupdateframework/notary/trustmanager/yubikey github.com/theupdateframework/notary/trustpinning 
github.com/theupdateframework/notary/tuf github.com/theupdateframework/notary/tuf/data 
github.com/theupdateframework/notary/tuf/signed github.com/theupdateframework/notary/tuf/testutils 
github.com/theupdateframework/notary/tuf/testutils/interfaces 
github.com/theupdateframework/notary/tuf/testutils/keys github.com/theupdateframework/notary/tuf/utils 
github.com/theupdateframework/notary/tuf/validation github.com/theupdateframework/notary/utils 
github.com/theupdateframework/notary/version returned exit code 2
make[1]: *** [debian/rules:25: override_dh_auto_build] Error 255




Bug#947997: ncbi-entrez-direct FTBFS in testing/unstable

2020-01-02 Thread peter green

source: prometheus-blackbox-exporter
version: 0.13.0+ds-2
severity: serious
tags: bullseye, sid, ftbfs

prometheus-blackbox-exporter FTBFS in testing/unstable, I first noticed this on 
a raspbian autobuilder, but it's also happening on the reproducible builds 
tests, so it's not raspbian specific.


github.com/prometheus/blackbox_exporter/prober
# github.com/prometheus/blackbox_exporter/prober
src/github.com/prometheus/blackbox_exporter/prober/http.go:219:44: not enough arguments 
in call to "github.com/prometheus/common/config".NewClientFromConfig
have ("github.com/prometheus/common/config".HTTPClientConfig, string)
want ("github.com/prometheus/common/config".HTTPClientConfig, string, 
bool)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/build/1st/prometheus-blackbox-exporter-0.13.0\+ds/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/build/1st/prometheus-blackbox-exporter-0.13.0\+ds/obj-x86_64-linux-gnu/src\" -v 
-p 15 -ldflags " -X github.com/prometheus/common/version.Version=0.13.0+ds -X 
github.com/prometheus/common/version.Revision=0.13.0+ds-2 -X github.com/prometheus/common/version.Branch=debian/sid 
-X github.com/prometheus/common/version.BuildUser=pkg-go-maintain...@lists.alioth.debian.org -X 
github.com/prometheus/common/version.BuildDate=20190119-14:59:39 -X 
github.com/prometheus/common/version.GoVersion=go1.13.5" github.com/prometheus/blackbox_exporter 
github.com/prometheus/blackbox_exporter/config github.com/prometheus/blackbox_exporter/prober returned exit code 2
make[1]: *** [debian/rules:26: override_dh_auto_build] Error 255




Bug#947996: golang-github-mailru-easyjson FTBFS in testing/unstable

2020-01-02 Thread peter green

source: golang-github-mailru-easyjson
version: 0.0~git20161103.0.159cdb8-1.1
severity: serious
tags: bullseye, sid, ftbfs

golang-github-mailru-easyjson FTBFS in testing/unstable, I first noticed this 
on a raspbian autobuilder, but it's also happening on the reproducible builds 
tests, so it's not raspbian specific.


easyjson -all 
/build/1st/golang-github-mailru-easyjson-0.0~git20161103.0.159cdb8/obj-x86_64-linux-gnu/src/github.com/mailru/easyjson/tests/data.go
failed to initialize build cache at /nonexistent/first-build/.cache/go-build: 
mkdir /nonexistent: permission denied
Bootstrap failed: exit status 1




Bug#947995: ncbi-entrez-direct FTBFS in testing/unstable

2020-01-02 Thread peter green

source: ncbi-entrez-direct
version: 10.9.20190219+ds-1
severity: serious
tags: bullseye, sid, ftbfs

ncbi-entrez-direct FTBFS in testing/unstable, I first noticed this on a 
raspbian autobuilder, but it's also happening on the reproducible builds tests, 
so it's not raspbian specific.


go build -v -gccgoflags '-g -O2 
-ffile-prefix-map=/build/1st/ncbi-entrez-direct-10.9.20190219+ds=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed' -o bin/xtract \
 xtract.go common.go
go build: when using gc toolchain, please pass compile flags using -gcflags, 
and linker flags using -ldflags
failed to initialize build cache at /nonexistent/first-build/.cache/go-build: 
mkdir /nonexistent: permission denied
make[1]: *** [debian/rules:84: override_dh_auto_build] Error 1




Bug#947248: python-caja: Please build-depend on python-gi in addition to python-gi-dev, or drop Python 2 support

2020-01-02 Thread Mike Gabriel

Hi Simon,

On  Mo 23 Dez 2019 16:02:22 CET, Simon McVittie wrote:


Source: python-caja
Version: 1.22.1-2
Severity: minor
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: python-gi-dev-945022
Control: block 945022 by -1

Please see https://salsa.debian.org/gnome-team/pygobject/merge_requests/2
for the latest information on this transition.

python-gi-dev contains development files (pkg-config metadata and header
file) corresponding to both python-gi and python3-gi.

At the moment, python-gi-dev Depends on both python-gi and python3-gi.
The GNOME team would like to drop the python-gi dependency, to make the
status of Python 2 removal easier to track.

The package receiving this bug is one of a few packages that build-depend
on python-gi-dev and appear to build Python 2 bindings. However, it
appears to build successfully even if python-gi is missing - perhaps
because it doesn't have any build-time tests, so if importing 'gi' doesn't
actually work, that's never detected.

If your package requires a Python 2 version of the gi module at build
time now or in the future, please add python-gi to its Build-Depends.
If it also requires a Python 3 version of the gi module, it is probably a
good idea to add an explicit Build-Depends on python3-gi as well - this
will ensure that it doesn't need changes if python-gi-dev subsequently
also drops its python3-gi dependency, which would make it similar to
python-dbus-dev.

If your package does not require a Python 2 version of the gi module at
build time and you don't think it is likely to do so in future, you can
just close this bug. Similarly, if you drop Python 2 support in unstable
(I see you have a Python-3-only version in experimental already), you
can close this bug in that upload.

Thanks,
smcv


I have just uploaded python-caja 1.23.0-1 to Debian unstable dropping  
Python2 support entirely. Can this considered to be resolved then?


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpUcbz9Z50T_.pgp
Description: Digitale PGP-Signatur


Bug#947994: RFS: pdf2djvu/0.9.15-1 [ITA] -- PDF to DjVu converter

2020-01-02 Thread Hsieh-Tseng Shen
Package: sponsorship-requests
Severity: normal
Tags: upstream

Dear mentors,

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

 * Package name: pdf2djvu
   Version : 0.9.15-1
   Upstream Author : Jakub Wilk 
 * URL : http://jwilk.net/software/pdf2djvu
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/pdf2djvu
   Section : text

It builds those binary packages:

  pdf2djvu - PDF to DjVu converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pdf2djvu/pdf2djvu_0.9.15-1.dsc

Changes since the last upload:

   * New maintainer (Closes: #945185).
   * New upstream release.

Regards,
-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature


Bug#947987: here is a URL with the Packages.xz files

2020-01-02 Thread Russell Coker
https://www.coker.com.au/bug/

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



Bug#941803: debian-policy: dependencies on font packages

2020-01-02 Thread Russ Allbery
Stephen Kitt  writes:

> I’m attaching a revert and an update to the footnote (against the next
> branch):

Thanks!  Applied for the next release.

-- 
Russ Allbery (r...@debian.org)  



Bug#947630: lintian still gives E: statically-linked-binary for golang project's binary

2020-01-02 Thread Felix Lechner
Hi Tong,

On Thu, Jan 2, 2020 at 8:24 PM Tong Sun
 wrote:
>
> $ lintian -EvIL +pedantic ../easygen*_amd64.changes

Will you please upload this *.changes file to mentors.d.n?

Kind regards
Felix Lechner



Bug#941266: netty: CVE-2019-16869

2020-01-02 Thread tony mancill
On Thu, Jan 02, 2020 at 11:38:08PM +0100, Salvatore Bonaccorso wrote:
> On Fri, Sep 27, 2019 at 01:12:04PM +0200, Salvatore Bonaccorso wrote:
> > Source: netty
> > Version: 1:4.1.33-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://github.com/netty/netty/issues/9571
> > 
> > Hi,
> > 
> > The following vulnerability was published for netty.
> > 
> > CVE-2019-16869[0]:
> > | Netty before 4.1.42.Final mishandles whitespace before the colon in
> > | HTTP headers (such as a "Transfer-Encoding : chunked" line), which
> > | leads to HTTP request smuggling.
> 
> Attached is the proposed debdiff. I included the tests as well
> (altough those are not run).

Hi Salvatore,

The debdiff looks good to me; thank you for adapting the patch for the
current version in 4.1.33.  No need for an NMU.  I will apply your patch
and perform a team upload to unstable with only this change to make it
easier for backports/security uploads.

Thanks,
tony


signature.asc
Description: PGP signature


Bug#947630: reopen 947630

2020-01-02 Thread Tong Sun
reopen 947630 =



Bug#947630: lintian still gives E: statically-linked-binary for golang project's binary

2020-01-02 Thread Tong Sun
Hi Felix,

Thanks for trying it out for me.

On Wed, Jan 1, 2020 at 10:36 PM Felix Lechner
 wrote:
>
> > E: easygen: statically-linked-binary usr/bin/easygen
>
> This tag is not reproducible in unstable. Build log attached. Closing this 
> bug.
>
> Please reopen if a mistake was made.

I'm still seeing that error when I'm building it, but honestly I don't
know what happened at my end, and yours, because I have no idea how it
comes to like this.

Here is what I'm getting now:

$ apt-cache policy lintian
lintian:
  Installed: 2.43.0
  Candidate: 2.43.0
  Version table:
 *** 2.43.0 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

$ lintian -EvIL +pedantic ../easygen*_amd64.changes
N: Starting on group easygen/4.1.0-1
N: Unpacking packages in group easygen/4.1.0-1
N: 
N: Processing changes file easygen
N: (version 4.1.0-1, arch amd64 all) ...
N: 
N: Processing buildinfo package easygen
N: (version 4.1.0-1, arch all amd64) ...
N: 
N: Processing binary package easygen
N: (version 4.1.0-1, arch amd64) ...
N: 
N: Processing binary package golang-github-go-easygen-easygen-dev
N: (version 4.1.0-1, arch all) ...
E: easygen: statically-linked-binary usr/bin/easygen
N: Finished processing group easygen/4.1.0-1

$ file obj-x86_64-linux-gnu/bin/easygen
obj-x86_64-linux-gnu/bin/easygen: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), statically linked, Go
BuildID=wq5SReT4_T68YpD7UOR9/LOqZugecRUOfQUOmfqkf/uNwyL1fb4NSfnJdS8jK0/sxnLKoUyMvPv0RCeQxvh,
not stripped

Full log available at
http://paste.debian.net/1124280/
including my build test on ffcvt as well.

@Chris,

if Lintian only has visibility against the binary, then maybe the
"Go BuildID" from `file` output can be used as a strong indicator?



Bug#938313: qpid-proton: diff for NMU version 0.22.0-3.3

2020-01-02 Thread Sandro Tosi
Control: tags 938313 + patch


Dear maintainer,

I've prepared an NMU for qpid-proton (versioned as 0.22.0-3.3). The diff
is attached to this message.

Regards.

diff -Nru qpid-proton-0.22.0/debian/changelog qpid-proton-0.22.0/debian/changelog
--- qpid-proton-0.22.0/debian/changelog	2019-08-07 22:29:46.0 -0400
+++ qpid-proton-0.22.0/debian/changelog	2020-01-02 22:49:44.0 -0500
@@ -1,3 +1,10 @@
+qpid-proton (0.22.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938313
+
+ -- Sandro Tosi   Thu, 02 Jan 2020 22:49:44 -0500
+
 qpid-proton (0.22.0-3.2) unstable; urgency=medium
 
   * Replace previous NMU with a new source-only upload.
diff -Nru qpid-proton-0.22.0/debian/control qpid-proton-0.22.0/debian/control
--- qpid-proton-0.22.0/debian/control	2019-08-07 20:44:02.0 -0400
+++ qpid-proton-0.22.0/debian/control	2020-01-02 22:48:39.0 -0500
@@ -11,8 +11,6 @@
doxygen,
libssl-dev,
pkg-config,
-   python-all,
-   python-all-dev,
python3-all,
python3-all-dev,
swig,
@@ -131,23 +129,6 @@
  .
  This package provides C++ developer documentation for Qpid Proton.
 
-Package: python-qpid-proton
-Architecture: any
-Section: python
-Depends: libqpid-proton11,
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
-Provides: ${python:Provides},
-Description: language bindings for Qpid Proton messaging framework - Python 2.7
- Qpid Proton is a high-performance, lightweight messaging library. It can be
- used in the widest range of messaging applications, including brokers, client
- libraries, routers, bridges, proxies, and more. Proton makes it trivial to
- integrate with the AMQP 1.0 ecosystem from any platform, environment, or
- language.
- .
- This package provides Python 2.7 language bindings for Qpid Proton.
-
 Package: python3-qpid-proton
 Architecture: any
 Section: python
diff -Nru qpid-proton-0.22.0/debian/python-qpid-proton.install qpid-proton-0.22.0/debian/python-qpid-proton.install
--- qpid-proton-0.22.0/debian/python-qpid-proton.install	2019-08-07 20:44:02.0 -0400
+++ qpid-proton-0.22.0/debian/python-qpid-proton.install	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-usr/lib/python2.7/dist-packages/_cproton.so
-usr/lib/python2.7/dist-packages/cproton.py
-usr/lib/python2.7/dist-packages/proton
diff -Nru qpid-proton-0.22.0/debian/rules qpid-proton-0.22.0/debian/rules
--- qpid-proton-0.22.0/debian/rules	2019-08-07 20:44:02.0 -0400
+++ qpid-proton-0.22.0/debian/rules	2020-01-02 22:49:12.0 -0500
@@ -21,11 +21,10 @@
 export DH_OPTIONS
 export DH_ALWAYS_EXCLUDE=LICENSE
 
-PYTHONS:=$(shell pyversions -vr)
 PYTHON3S:=$(shell py3versions -vr)
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 override_dh_auto_configure:
 	dh_auto_configure -- -DPROTON_DISABLE_RPATH=true -DNOBUILD_RUBY=on -DSYSINSTALL_BINDINGS=on
@@ -52,9 +51,6 @@
 	mkdir -p debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
 	mv debian/tmp/usr/lib/lib*.so* debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
 	set -e ; cd obj-$(DEB_BUILD_GNU_TYPE)/proton-c/bindings/python/dist ; \
-		for pyvers in $(PYTHONS); do \
-			python$$pyvers setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp ; \
-		done ; \
 		for pyvers in $(PYTHON3S); do \
 			python$$pyvers setup.py install --install-layout=deb --root $(CURDIR)/debian/tmp ; \
 		done
diff -Nru qpid-proton-0.22.0/debian/tests/control qpid-proton-0.22.0/debian/tests/control
--- qpid-proton-0.22.0/debian/tests/control	2019-08-07 20:44:02.0 -0400
+++ qpid-proton-0.22.0/debian/tests/control	2020-01-02 22:49:35.0 -0500
@@ -1,5 +1,2 @@
-Test-Command: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import proton; print proton" ; done
-Depends: python-all, python-qpid-proton
-
 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import proton; print(proton)" ; done
 Depends: python3-all, python3-qpid-proton


Bug#947993: systemd: mysterious timeout /sys/subsystem/net/device/multi/user

2020-01-02 Thread Joshua
Package: systemd
Version: 241-7~deb10u2
Severity: normal

Mysterious timeout booting on multi/user ficticious device


-- Package-specific info:

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u2
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-7~deb10u2

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=volatile
ForwardToSyslog=1


-- no debconf information



Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

2020-01-02 Thread Joshua Hudson
> Does `journalctl --user-unit pulseaudio.service` have anything to say?

Says "daemon already running" quite a few times.

> You can set the debug flags on daemon.conf to force it to verbose mode.

Spectacular:

E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.

Must clear the log file every time.

$ grep -v '^$' /etc/pulse/daemon.conf | grep -v '^;' | grep -v '^#'
$ cat ~/.pulse/daemon.conf

exit-idle-time=-1
log-target=file:/home/joshua/.pulse/daemon.log
log-level=info
kill=yes

and aplay reports:

ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave
aplay: main:828: audio open error: No such file or directory

but writing directly to /dev/audio1 makes some noise



Bug#938342:

2020-01-02 Thread Eriberto Mota
Em dom., 29 de dez. de 2019 às 12:45, Malcolm Albie
 escreveu:
>
> The python script in this package is python3-compatible, only the 
> dependencies need to be updated.

Thanks Malcolm. I will take care of this now.

Cheers,

Eriberto



Bug#947992: RM: rust-syntex-pos -- ROM; obsolete package, prevents others from migrating to testing

2020-01-02 Thread Ximin Luo
Package: ftp.debian.org
Severity: normal

Hi, please remove this package on all architectures. It is an old rust library
that is preventing newer ones from migrating to testing. Nothing else in the
archive depends on it these days.



Bug#947991: RM: rust-syntex-errors -- ROM; obsolete package, prevents others from migrating to testing

2020-01-02 Thread Ximin Luo
Package: ftp.debian.org
Severity: normal

Hi, please remove this package on all architectures. It is an old rust library
that is preventing newer ones from migrating to testing. Nothing else in the
archive depends on it these days.



Bug#947907: uno-libs-private: Unmet dependencies

2020-01-02 Thread Felicia
On Thu, 02 Jan 2020 08:45:17 +0100 rene.engelh...@mailbox.org wrote:
>
> I know.
>
> Already fixed locally, needs a test build ...

>

Thanks :-)



Bug#947990: gdcm: Doesn't build on ports without java

2020-01-02 Thread Samuel Thibault
Source: gdcm
Version: 3.0.4-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

gdcm currently doesn't build on ports without java support. The attached
patch fix that: it disables the default-jdk and libvtk7-java build-deps
on non-java ports, they enable the lib*-java packages only on java
ports, and pass -DGDCM_WRAP_JAVA:BOOL=ON to configure only on java
ports.

Samuel

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

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
-- Arnold Robbins in the LJ of February '95, describing RCS
--- debian/control.original 2020-01-02 12:40:16.0 +
+++ debian/control  2020-01-03 01:10:28.0 +
@@ -7,7 +7,7 @@
  Gert Wollny  
 Build-Depends: cmake (>= 2.8.9),
debhelper (>= 11),
-  default-jdk,
+  default-jdk [!hppa !hurd-any !kfreebsd-any],
dh-strip-nondeterminism, 
dh-python, 
   python3-dev,
@@ -20,7 +20,7 @@
   libvtk7-dev,
   libcharls-dev (>= 1.1.0),
   libopenjp2-7-dev,
-  libvtk7-java,
+  libvtk7-java [!hppa !hurd-any !kfreebsd-any],
   libxml2-dev,
   libjson-c-dev,
   libpoppler-private-dev,
@@ -194,7 +194,7 @@
 
 Package: libgdcm-java
 Section: java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${java:Depends}
 Suggests: java-virtual-machine
 Description: Grassroots DICOM Java bindings
@@ -207,7 +207,7 @@
 
 Package: libvtkgdcm-java
 Section: java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${java:Depends}, libgdcm3.0 (= 
${binary:Version})
 Suggests: libgdcm-java
 Description: Grassroots DICOM VTK Java bindings
--- debian/rules.original   2020-01-02 12:41:11.0 +
+++ debian/rules2020-01-02 12:43:55.0 +
@@ -28,10 +28,15 @@
 export LD_LIBRARY_PATH
 
 DEFAULT_JAVA_VERSION=1.8
-ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH),hppa hurd-i386))
-  DEFAULT_JAVA_VERSION=1.5
+ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH),hppa hurd-i386 
kfreebsd-i386 kfreebsd-amd64))
+  DEFAULT_JAVA_VERSION=
 endif 
 
+ifneq ($(DEFAULT_JAVA_VERSION),)
+CMAKE_EXTRA_FLAGS += -DGDCM_WRAP_JAVA:BOOL=ON \
+ -DGDCM_DEFAULT_JAVA_VERSION:STRING=$(DEFAULT_JAVA_VERSION)
+endif
+
 # set JAVA path on arm, doesn't seem to find it otherwise
 ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH),armhf armel arm64 powerpc 
ppc64el))
 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-$(DEB_BUILD_ARCH)
@@ -65,8 +70,6 @@
-DGDCM_BUILD_SHARED_LIBS:BOOL=ON \
-DGDCM_WRAP_PYTHON:BOOL=ON \
-DGDCM_WRAP_CSHARP:BOOL=$(DEB_WRAP_CSHARP) \
-   -DGDCM_WRAP_JAVA:BOOL=ON \
-   -DGDCM_DEFAULT_JAVA_VERSION:STRING=$(DEFAULT_JAVA_VERSION) \
-DGDCM_WRAP_PHP:BOOL=OFF \
-DGDCM_USE_PVRG:BOOL=ON \
-DGDCM_USE_SYSTEM_PVRG:BOOL=ON \


Bug#947989: libgtk-3-0: Mouse button presses ignored at edge of screen

2020-01-02 Thread Benjamin Moody
Package: libgtk-3-0
Version: 3.24.5-1
Severity: normal

Dear Maintainer,

If a GTK window is placed adjacent to the top or left edge of the
screen, it sometimes fails to handle mouse clicks.

For example, with the standard MATE panel configuration, the
"Applications" menu is in the top left corner.  Yet, if I move the
mouse to coordinates (0, 10) and try to click the button, then
sometimes, nothing happens.

On the other hand, 'xdotool mousemove 0 10 click 1' works as expected.

The problem seems to be that, if the mouse cursor is "pushed" against
the edge of the screen, the XInput 2 extension sometimes reports a
*negative* sub-pixel position, and even though the event is correctly
delivered to the X client, GTK doesn't recognize the negative position
as belonging to a widget.

A test program is below.  If I run that program, then click several
times while sliding the pointer along the left edge of the screen, I
see output like:

XI_ButtonPress at 0, 71.670608520507812
 -> 1 pressed at 0, 71.670608520507812
XI_ButtonPress at 0, 88.633712768554688
 -> 1 pressed at 0, 88.633712768554688
XI_ButtonPress at -0.9815216064453125, 111.44589233398438
XI_ButtonPress at 0, 130.43672180175781
 -> 1 pressed at 0, 130.43672180175781
XI_ButtonPress at -0.9422607421875, 135.76339721679688
XI_ButtonPress at -0.935089111328125, 149.22447204589844

indicating that Xlib receives the button-press events, but GTK doesn't
transmit them to the widget.

This problem appears to affect the top and left edges of the screen,
but not the right or bottom edges.

Not sure if this should be considered a bug in GTK, a bug in X, a bug
in libinput, or even a bug in MATE, but it's rather annoying.

This is using:
* xserver-xorg-core 2:1.20.4-1
* xserver-xorg-input-libinput 0.28.2-2
* libinput10 1.12.6-2

 Example program 
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 

int XNextEvent(Display *dpy, XEvent *ev)
{
  static int (*real_XNextEvent)(Display *dpy, XEvent *ev);
  static int xi2extension;
  int op, evt, err;
  XIDeviceEvent *devev;

  if (!real_XNextEvent) {
real_XNextEvent = dlsym(RTLD_NEXT, "XNextEvent");
if (XQueryExtension(dpy, "XInputExtension", , , ))
  xi2extension = op;
  }

  (*real_XNextEvent)(dpy, ev);

  if (ev) {
if (ev->type == ButtonPress) {
  printf("ButtonPress at %d, %d\n", ev->xbutton.x, ev->xbutton.y);
}
if (ev->type == GenericEvent
&& ev->xgeneric.extension == xi2extension
&& ev->xgeneric.evtype == XI_ButtonPress) {
  if (XGetEventData(dpy, >xcookie)) {
devev = ev->xcookie.data;
printf("XI_ButtonPress at %.17g, %.17g\n",
   devev->event_x, devev->event_y);
  }
  /* welp, guess if gdk doesn't call XFreeEventData then we leak. */
}
  }

  return 0;
}

static gboolean button_press(GtkWidget *w, GdkEventButton *ev)
{
  printf(" -> %d pressed at %.17g, %.17g\n", ev->button, ev->x, ev->y);
  return FALSE;
}

int main(int argc, char **argv)
{
  void *window, *da;
  gtk_init(, );
  window = gtk_window_new(GTK_WINDOW_POPUP);
  da = gtk_drawing_area_new();
  gtk_widget_add_events(da, GDK_BUTTON_PRESS_MASK);
  g_signal_connect(da, "button-press-event", G_CALLBACK(button_press), NULL);
  gtk_container_add(window, da);
  gtk_widget_show_all(window);
  gtk_window_parse_geometry(window, "300x300+0+0");
  gtk_main();
  return 0;
}


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/40 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.2.10-6+deb10u1
ii  libepoxy01.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-common  3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  librest-0.7-00.8.1-1
ii  libsoup2.4-1 2.64.2-2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   

Bug#938682: Future of Trac in Debian

2020-01-02 Thread Sandro Tosi
Hello Martin,

On Fri, Nov 29, 2019 at 6:55 PM Martin  wrote:
>
> On 2019-11-29 18:13, Nicholas D Steeves wrote:
> > IMHO one of the Debian Trac uploaders should post to the #12130 Trac
> > ticket informing them of our plan.
>
> I linked to the email of 2019-10-14:
> https://trac.edgewall.org/ticket/12130#comment:63

So Jan 1 arrived, what do you think we should do? i didnt see any
progress on the port to python3 upstream; should we start filing RM
for trac extensions/plugins and once they are gone, RM src:trac?

an initial list of packages for the first pass of RM could be:

$ apt-cache search trac-
libnet-trac-perl - Perl client library for Trac
libtext-trac-perl - module for formatting text with Trac Wiki Style
trac-accountmanager - account management plugin for Trac
trac-announcer - enhanced e-mail notification system for Trac
trac-authopenid - OpenID authentication plugin for Trac
trac-customfieldadmin - panel for administrating custom ticket fields in Trac
trac-datefield - Add custom date fields to Trac tickets
trac-diavisview - Renders dia and vdx files in Trac
trac-graphviz - Graphs printing plugin for Trac
trac-httpauth - Force HTTP authentication from within Trac
trac-icalview - Provides iCalendar feeds for ticket queries
trac-includemacro - Include external resources in a Trac wiki page
trac-jsgantt - displays Trac tickets as a Gantt chart in a wiki page
trac-mastertickets - adds inter-ticket dependencies to Trac
trac-mercurial - Mercurial version control backend for Trac
trac-navadd - add custom items to main and meta navigation bar in Trac webapp
trac-odtexport - Export Trac wiki pages as OpenDocument (ODT) files
trac-privatetickets - Allows Trac users to only see tickets they are
associated with
trac-privateticketsplugin - transitional dummy package for trac-privatetickets
trac-privatewiki - add private wiki ability to Trac
trac-roadmap - enhances the Trac roadmap with sorting and filtering
trac-sensitivetickets - Plugin for Trac ticketing system to hide
tickets marked as sensitive
trac-subcomponents - use multiple layers of components in Trac
trac-subtickets - sub-ticket feature for Trac tickets
trac-tags - Tagging plugin for Trac wiki and issue tracking system
trac-translatedpages - Show translated versions of wiki page in the
Trac web application
trac-virtualticketpermissions - Extended permissions plugin for Trac
ticketing system
trac-wikiprint - Make Trac wiki pages printable, exporting to PDF or
printable HTML
trac-wikitablemacro - SQL Table in Wiki Page for Trac
trac-wysiwyg - WYSIWYG style editor for the Trac issue tracking system
trac-xmlrpc - XML-RPC interface to the Trac wiki and issue tracking system

if i dont hear anything back withing a week, i'll most likely opening
those RM bugs, so that we can work on their transitive dependencies.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#947988: ITP: python-msoffcrypto-tool -- Python tool and library for decrypting MS Office files

2020-01-02 Thread Sascha Steinbiss
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: python-msoffcrypto-tool
  Version : 4.10.1
  Upstream Author : nolze
* URL : https://github.com/nolze/msoffcrypto-tool
* License : MIT
  Programming Lang: Python
  Description : Python tool and library for decrypting MS Office files

msoffcrypto-tool (formerly ms-offcrypto-tool) is a Python tool and library
for decrypting encrypted MS Office files with password, intermediate key,
or private key which generated its escrow key.

I will be packaging this as a dependency of a more recent version of the
peframe tool, which will be Python 3 compatible.



Bug#947987: apt-cacher-ng: Inexplicable error in cron job and html file

2020-01-02 Thread Russell Coker
Package: apt-cacher-ng
Version: 3.2-2
Severity: normal

I get the following error repeatedly from the cron job:

/etc/cron.daily/apt-cacher-ng:
Maintenance Task: Expiration
See file /var/log/apt-cacher-ng/maint_1577993104.log.html for more details.
Server control address: http://127.0.0.1:3142/acng-report.html
Problem with 
mirror.internode.on.net/pub/debian/dists/unstable/main/binary-amd64/Packages.xz
Problem with 
mirror.internode.on.net/pub/debian/dists/unstable/main/binary-i386/Packages.xz
Errors found, aborting expiration...

The HTML file has the following messages that are relevant:

Parsing metadata in
   mirror.internode.on.net/pub/debian/dists/unstable/main/binary-amd64/Pa
   ckages.xz
   An error occurred while reading this file, some contents may have been
   ignored.
   Parsing metadata in
   mirror.internode.on.net/pub/debian/dists/unstable/main/binary-i386/Pac
   kages.xz
   An error occurred while reading this file, some contents may have been
   ignored.

Firstly both the cron job and the HTML file should include the full path to
the file.  If the errors were reported in 
/var/cache/apt-cacher-ng/mirror.internode.on.net/pub/debian/dists/unstable/main/binary-i386/Packages.xz
 then it
would take me less time to track the problem down.

Next what is the error when reading the file?  I ran xzless against it and the
contents looked OK.  The HTML file should give some clue as to what the error
is.

After the bug is submitted I'll attach both Packages.xz files.

-- Package-specific info:

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages apt-cacher-ng depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libbz2-1.0 1.0.6-9.2~deb10u1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  liblzma5   5.2.4-1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libstdc++6 8.3.0-6
ii  libsystemd0241-7~deb10u2
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.9-1

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed:
CacheDir: /var/cache/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: /usr/lib/apt-cacher-ng
BindAddress: localhost 10.0.0.1
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian 
Archives
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu 
Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # 
incomplete, please create this file or specify preferred mirrors here
Remap-sfnet:  file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please 
create this file or specify preferred mirrors here
Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch 
Linux
Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel:   file:epel_mirrors # Fedora EPEL
Remap-slrep:  file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo 
Archives
Remap-secdeb: security.debian.org ; security.debian.org 
deb.debian.org/debian-security
ReportPage: acng-report.html
ExThreshold: 4
LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng


-- debconf information:
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/bindaddress: keep



Bug#947986: vtk7: Doesn't build on ports without java

2020-01-02 Thread Samuel Thibault
Source: vtk7
Version: 7.1.1+dfsg2-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

vtk7 currently doesn't build on ports without java support. The attached
patch fix that: it disables the default-jdk and libvtk7-java build-deps
on non-java ports, they enable the libvtk7-jni/java packages only on java
ports, pass -DVTK_WRAP_JAVA=ON to configure only on java ports, and install
java bits only on java ports.

Samuel

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

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
Now, it we had this sort of thing:
  yield -a for yield to all traffic
  yield -t for yield to trucks
  yield -f for yield to people walking (yield foot)
  yield -d t*  for yield on days starting with t
...you'd have a lot of dead people at intersections, and traffic jams you
wouldn't believe...
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)
--- debian/control.original 2020-01-02 12:46:30.0 +
+++ debian/control  2020-01-02 12:47:41.0 +
@@ -7,7 +7,7 @@
 Build-Depends: chrpath,
cmake (>= 3.2.0),
debhelper (>= 9),
-   default-jdk,
+   default-jdk [!hppa !hurd-any !kfreebsd-any],
default-libmysqlclient-dev,
dh-python,
libftgl-dev,
@@ -110,7 +110,7 @@
  libtheora-dev,
  libtiff-dev,
  libvtk7.1p (= ${binary:Version}),
- libvtk7-java (= ${binary:Version}),
+ libvtk7-java (= ${binary:Version}) [!hppa !hurd-any !kfreebsd-any],
  libx11-dev,
  libxft-dev,
  libxml2-dev,
@@ -187,7 +187,7 @@
  that use VTK. Qt files
 
 Package: libvtk7-jni
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Section: java
 Depends: ${java:Depends},
  ${misc:Depends},
@@ -202,7 +202,7 @@
  This package provides the VTK Java language support.
 
 Package: libvtk7-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Section: java
 Depends: libvtk7-jni (= ${binary:Version}),
  ${java:Depends},
--- debian/rules.original   2020-01-02 12:47:46.0 +
+++ debian/rules2020-01-02 12:50:59.0 +
@@ -14,21 +14,25 @@
   export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
 endif 
 
-ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH),hppa hurd-i386))
-JAVA_VERSION=1.5
+extra_flags=
+
+nojava_archs=hppa hurd-i386 kfreebsd-i386 kfreebsd-amd64
+ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), $(nojava_archs)))
+JAVA_VERSION=
 else
 JAVA_VERSION=1.8
+extra_flags += -DVTK_WRAP_JAVA=ON
 endif
 
 noqt_archs="" 
 ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), $(noqt_archs)))
-extra_flags=-DVTK_Group_Qt=OFF \
--DMODULE_vtkParseOGLExt=ON  \
--DModule_vtkWrappingTools=ON \
--DModule_vtkRenderingSceneGraph=ON \
--DModule_vtkIOExportOpenGL2=ON \
--DModule_vtkPython=ON \
--DVTK_BUILD_ALL_MODULES=OFF
+extra_flags += -DVTK_Group_Qt=OFF \
+   -DMODULE_vtkParseOGLExt=ON  \
+   -DModule_vtkWrappingTools=ON \
+   -DModule_vtkRenderingSceneGraph=ON \
+   -DModule_vtkIOExportOpenGL2=ON \
+   -DModule_vtkPython=ON \
+   -DVTK_BUILD_ALL_MODULES=OFF
 else
 extra_flags += -DVTK_QT_VERSION=5 \
-DVTK_Group_Qt=ON \
@@ -53,7 +57,6 @@
 -DVTK_JAVA_SOURCE_VERSION=$(JAVA_VERSION) \
 -DVTK_JAVA_TARGET_VERSION=$(JAVA_VERSION) \
-DVTK_USE_TK=ON \
-   -DVTK_WRAP_JAVA=ON \
-DVTK_WRAP_PYTHON=ON \
 -DVTK_PYTHON_VERSION:STRING=3 \
-DVTK_WRAP_TCL=ON \
@@ -121,11 +124,13 @@
 override_dh_auto_install:
pwd
dh_auto_install -X.pyc -X.pyo
+ifneq ($(JAVA_VERSION),)
# Modify vtkWrapJava.cmake to properly upload JavaDependencies.cmake.in 
from $VTK_DIR
perl -pi -e 

Bug#947985: RM: sagemath [mips64el] -- ROM; remove arch-specific binary to allow testing migration

2020-01-02 Thread Ximin Luo
Package: ftp.debian.org
Severity: normal

Hi, please remove sagemath binaries on mips64el. There are failing tests which
we are unlikely to fix in a timely fashion, and in the meantime this is
blocking migration to testing. Testing already does not have any binaries for
sagemath as it was autoremoved a while back due to RC bugs. The version in
unstable fixes these, so ignoring mips64el is preferable for the time being so
we can have Sagemath in Debian Testing on any architectures at all.



Bug#946241: ffmpeg: please make autopkgtests cross-test-friendly

2020-01-02 Thread James Cowgill
Hi,

On 06/12/2019 03:33, Steve Langasek wrote:
> Package: ffmpeg
> Version: 7:4.2.1-2
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
> 
> Dear maintainers,
> 
> In Ubuntu, we are in the process of moving the i386 architecture to a
> compatibility-only layer on amd64, and therefore we are also moving our
> autopkgtest infrastructure to test i386 binaries in a cross-environment.
> 
> This requires changes to some tests so that they are cross-aware and can do
> the right thing.

[...]
> 
> --- ffmpeg-4.2.1/debian/tests/control 2019-11-01 18:17:31.0 -0700
> +++ ffmpeg-4.2.1/debian/tests/control 2019-12-05 17:17:44.0 -0800
> @@ -5,4 +5,4 @@
>  Depends: ffmpeg
>  
>  Tests: encdec-extra
> -Depends: ffmpeg, libavcodec-extra
> +Depends: ffmpeg, libavcodec-extra58

Am I right in thinking this is necessary because libavcodec-extra is an
"arch all multi-arch foreign" package?

I'm wondering if marking libavcodec-extra (and libavfilter-extra) like
that is wrong because the behavior of these packages depends on what the
native architecture is, but I'm not sure. It currently installs the
native arch's libavcodec-extra library which doesn't seem right for a
multi-arch foreign package. I don't know if anyone from the multimedia
team knows why it's done this way (maybe just historical)?

Making the package "arch any multi-arch same" seems sensible to me, or
just removing the packages altogether (we already have a Provides:
libavcodec-extra on the real library packages so the existing
dependencies should work still).

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#947956: duplicity: mega backend fails to create directory

2020-01-02 Thread Alexander Zangerl
forwarded 947956 https://bugs.launchpad.net/duplicity/+bug/1858153
thanks

On Thu, 02 Jan 2020 20:06:45 +0100, Jean-Michel Vourgère writes:
>This is actually easy to fix, it's just a typo calling _make_dir while
>the class function, just above, is named _makedir.

thanks for the info; i'll make sure your patch makes it into the next
debian release.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
MASER, n.: Mail Amplification by Stimulation of Emitted Rejections
 -- Steve VanDevender, Patrick Wade


signature.asc
Description: Digital Signature


Bug#947984: libvirt-daemon-driver-lxc: internal error: Unable to find 'devices' cgroups controller mount in cgroup2 / unified hierarchy

2020-01-02 Thread Ryutaroh Matsumoto
Package: libvirt-daemon-driver-lxc
Version: 5.6.0-3
Severity: normal
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2
Control: block 943981 by -1

Dear Maintainer,

libvirt-daemon-driver-lxc fails in cgroup2 / unified hierarchy
(host Linux booted with systemd.unified_cgroup_hierarchy)
with the following error message:

root@debian:~# virt-install  --connect lxc:/ --os-variant fedora30 --memory 
2096 --filesystem /var/lib/lxc/chrome1/rootfs,/ --network 
network=default,model=virtio --graphics=vnc,listen=0.0.0.0 --video qxl 
--accelerate --cpuset 2 --cpu host-model --transient --import --name chrommee 
WARNING  Graphics requested but DISPLAY is not set. Not running virt-viewer.
WARNING  No console to launch for the guest, defaulting to --wait -1

Starting install...
ERRORinternal error: Unable to find 'devices' cgroups controller mount
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect lxc:/ start chrommee
otherwise, please restart your installation.
root@debian:~# virsh --connect lxc:/ start chrommee
error: failed to get domain 'chrommee'

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages libvirt-daemon-driver-lxc depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.29-3
ii  libcap-ng0  0.7.9-2.1+b1
ii  libfuse22.9.9-2
ii  libgcc1 1:9.2.1-21
ii  libvirt-daemon  5.6.0-3
ii  libvirt05.6.0-3
ii  libxml2 2.9.4+dfsg1-8

libvirt-daemon-driver-lxc recommends no packages.

libvirt-daemon-driver-lxc suggests no packages.

-- no debconf information



Bug#947983: imagemagick-6.q16: missing ImageMagick-ims6.q16(1) man page or incorrect reference

2020-01-02 Thread Vincent Lefevre
Package: imagemagick-6.q16
Version: 8:6.9.10.23+dfsg-2.1+b2
Severity: minor

The convert(1) man page says

SEE ALSO
   ImageMagick-ims6.q16(1)

but "man ImageMagick-ims6.q16" gives

No manual entry for ImageMagick-ims6.q16

"man ImageMagick" works and starts with

ImageMagick-im6.q16(1)  General Commands Manual ImageMagick-im6.q16(1)

So, either the ImageMagick-ims6.q16(1) man page is missing, or the
reference is incorrect (is the "s" in "ims6.q16" a typo?).

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
compare:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
convert:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
composite:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
conjure:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
display:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
identify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
import:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
mogrify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
montage:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
stream:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.29-7
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2.1+b2
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2.1+b2

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.50~dfsg-5
ii  libmagickcore-6.q16-6-extra  8:6.9.10.23+dfsg-2.1+b2
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.3.1-1
ii  curl 7.67.0-2
pn  enscript 
ii  ffmpeg   7:4.2.1-2+b1
ii  fig2dev [transfig]   1:3.2.7b-2
ii  gimp 2.10.14-2
ii  gnuplot-qt [gnuplot] 5.2.7+dfsg1-6+b1
pn  grads
pn  graphviz 
ii  groff-base   1.22.4-4
pn  hp2xx
pn  html2ps  
ii  imagemagick-6-doc [imagemagick-doc]  8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-17
ii  mplayer  2:1.3.0-8+b5
pn  povray   
pn  radiance 
ii  sane-utils   1.0.27-3.2+b1
ii  texlive-binaries [texlive-base-bin]  2019.20190605.51237-3
pn  ufraw-batch  
ii  xdg-utils1.1.3-1

-- no debconf information

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



Bug#947982: imagemagick-6.q16: convert-im6.q16 man page: +repage needs to be documented, in particular for -crop

2020-01-02 Thread Vincent Lefevre
Package: imagemagick-6.q16
Version: 8:6.9.10.23+dfsg-2.1+b2
Severity: normal

When I execute

  convert black.png -crop 150x100+0+0 black-cropped.png

on a 272x120 image black.png (obtained with a screenshot and a first
crop with "display", for testing), I get the following warning:

convert-im6.q16: geometry does not contain image `black.png' @ 
warning/transform.c/CropImage/667.

After searching for the warning on the web, I found something
suggesting "+repage". This works, but this is not documented at all
in the man page. Its need for -crop should also be documented.

(I also think that this is ugly and -crop should just do what the
user wants.)

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
compare:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
convert:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
composite:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
conjure:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
display:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
identify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
import:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
mogrify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
montage:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
stream:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.29-7
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2.1+b2
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2.1+b2

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.50~dfsg-5
ii  libmagickcore-6.q16-6-extra  8:6.9.10.23+dfsg-2.1+b2
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.3.1-1
ii  curl 7.67.0-2
pn  enscript 
ii  ffmpeg   7:4.2.1-2+b1
ii  fig2dev [transfig]   1:3.2.7b-2
ii  gimp 2.10.14-2
ii  gnuplot-qt [gnuplot] 5.2.7+dfsg1-6+b1
pn  grads
pn  graphviz 
ii  groff-base   1.22.4-4
pn  hp2xx
pn  html2ps  
ii  imagemagick-6-doc [imagemagick-doc]  8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-17
ii  mplayer  2:1.3.0-8+b5
pn  povray   
pn  radiance 
ii  sane-utils   1.0.27-3.2+b1
ii  texlive-binaries [texlive-base-bin]  2019.20190605.51237-3
pn  ufraw-batch  
ii  xdg-utils1.1.3-1

-- no debconf information

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


Bug#936113:

2020-01-02 Thread Samuel Henrique
As said by upstream at:
https://github.com/aircrack-ng/aircrack-ng/pull/2087

The issue is fixed in git and there' s gonna be a new release soon.

Sending this mail to reset the auto-rm clock so we can wait for the new
release without removing the package from testing,

Regards,

--
Samuel Henrique 


Bug#947981: RFS: wcd/6.0.3-2 [QA] -- saves time typing when you want to change directories

2020-01-02 Thread Sudip Mukherjee
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wcd
   Version : 6.0.3-2
   Upstream Author : Erwin Waterlander , 

 * URL : https://waterlan.home.xs4all.nl
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/wcd
   Section : utils

It builds those binary packages:

  wcd - saves time typing when you want to change directories

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/w/wcd/wcd_6.0.3-2.dsc

Changes since the last upload:

   * QA upload.
   * Fix ftcbfs. (Closes: #929759)
   * Update Vcs to debian/wcd repo.
   * Add Rules-Requires-Root for lintian warning.
   * Use https with homepage.

-- 
Regards
Sudip



Bug#895517: libglade2 unmaintained and affected by python2 removal

2020-01-02 Thread Adrian Bunk
On Thu, Jan 02, 2020 at 02:02:27PM +0100, Andreas Henriksson wrote:
> affects 895517 + aeskulap desmume exult-studio foxtrotgps fyre g3dviewer gfm 
> ghemical gpaint guile-gnome2-gtk kconfig-frontends kino libglade2.0-cil 
> libglademm-2.4-1v5 libgnomecanvas2-0 libgtkdatabox0-libglade 
> liblablgtk2-ocaml libswami0 marionnet mdk mialmpick ogmrip ogmrip-plugins 
> planner plotdrop rfdump screentest tiemu wbar-config xscreensaver
> thanks
> 
> Please note that src:libglade2 is affected by the ongoing python2 removal and
> as #895517 states:
> "libglade2-0: deprecated and unmaintained upstream"
> so don't expect anyone to port it.
> 
> See #936867 for the specific python2 bug report.
>...

This is only the libglade-convert script for converting
pre-2001 (sic) glade files.

I can adopt or NMU (whatever you prefer) libglade2 with the trivial fix
of removing this script.

> Regards,
> Andreas Henriksson

cu
Adrian



Bug#947977: Fails to declare API dependencies

2020-01-02 Thread Simon McVittie
On Thu, 02 Jan 2020 at 15:04:54 -0800, Matthew Garrett wrote:
> Package: xdg-desktop-portal-gtk
> Version: 1.6.0-1
> 
> xdg-desktop-portal-gtk depends on version 2 of the
> MUTTER_SCREEN_CAST_API_VERSION being available but doesn't express
> that dependency in any way.

What's the failure mode when this is missing? I'd expect screencasting
to fail to start (hopefully gracefully) when not in (a suitable version
of) GNOME Shell or similar, but the rest of the portals provided by
xdg-desktop-portal-gtk should continue to work.

Screencasting also requires a suitably recent version of Pipewire,
which isn't yet widespread.

xdg-desktop-portal-gtk has a bit of a weird dual role: it's the GNOME
portal implementation, and it's also the fallback when there is no
more specific set of portal backends for a non-GNOME desktop (because
it happens to be the one that is maintained by the xdg-desktop-portal
developers, and because many of the desktop environments that don't have
their own more specific portal backends are GTK-based, so in many cases
the GNOME implementation is close enough).

Suggests: gnome-shell (>= some suitable version) would express the weak
dependency, but seems odd for xdg-desktop-portal-gtk's role as a fallback.

Perhaps xdg-desktop-portal-gtk should split into -gtk and -gnome versions,
where the -gnome version is more featureful? But I don't think that would
necessarily make anything work better than it already does.

smcv



Bug#947980: firmware-atheros: Please package new "upstream" firmware version

2020-01-02 Thread Chris Lamb
Package: firmware-atheros
Version: 20190717-2
Severity: wishlist

Hi

I get the occasional firmware crash on my QCA6174-based Dell XPS13. I
had a look to see whether there was new version available and one
appeared to have been added a few days ago:

  
https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552

(Is this something that could/should be packaged? Thanks in
advance.)


Regards,

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



Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang

2020-01-02 Thread Milan Kupcevic
On 2020-01-02 15:54, Bernd Zeimetz wrote:

> 
> any idea if this affects 14.2.4?
> 


Reports are pointing to 14.2.5, so far.

Also see https://tracker.ceph.com/issues/43317


Milan



Bug#947446: closed by Rene Engelhard (Bug#947446: fixed in libreoffice 1:6.4.0~rc1-3)

2020-01-02 Thread Rene Engelhard
notfound 947446 1:6.4.0~rc1-5
close 947446 1:6.4.0~rc1-3
thanks

On Thu, Jan 02, 2020 at 10:58:11PM +0100, Andreas Beckmann wrote:
> Control: reopen -1
> Control: found -1 1:6.4.0~rc1-5

Erm, no. Breaks:/Replaces: are present.

> it looks like ure is still shipping (some of) the files that were split 
> out to separate packages:

Yes. But this completely different to your bug which was about the
Breaks:/Replaces: being there at all. Your bug is fixed.

That the split was broken per se is an other matter, but there are
already 3 bugs wrt that:

#947907 [S|P|=] [ure] trying to overwrite '/usr/share/java/juh.jar', which is 
also in package libjuh-java
#947909 [S|P|=] [ure] ure is trying to overwrite '/usr/share/java/juh.jar', 
which is also in package libjuh-java 1:6.4.0~rc1-5
#947910 [S|P|=] [ure] ure uninstallable because of file conflict with 
libjuh-java

>   Selecting previously unselected package ure.
>   Preparing to unpack .../08-ure_6.4.0~rc1-5_amd64.deb ...
>   Unpacking ure (6.4.0~rc1-5) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-p2iEE9/08-ure_6.4.0~rc1-5_amd64.deb (--unpack):
>trying to overwrite '/usr/share/java/juh.jar', which is also in package 
> libjuh-java 1:6.4.0~rc1-5
> 
> Similarily for libjurt-java, libridl-java, libunoloader-java in sid.

Yes.

> Don't forget to bump the B+R against ure to a version that is no longer
> shipping them.

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/7994273bbbe8014624b3e9001dfb7243ac18c6fd

Regards,

Rene



Bug#935141: wxmaxima: assertion failure with multiple monitors

2020-01-02 Thread Olly Betts
On Mon, Aug 19, 2019 at 11:08:55PM -0400, John Scott wrote:
> I'm having this issue both with 19.01.2-1 and 19.07.0-1. Backtraces and
> screenshots are from the latter.

Can you reproduce this with wxmaxima 19.07.0-1.1 (the version currently
in unstable and testing)?  That's the version that switched to using the
GTK3 flavour of wxWidgets.

I have multiple monitors and I can't reproduce with this version, though
I use Mate not GNOME 3 so it could be something specific to the desktop
environment.

Cheers,
Olly



Bug#947979: enchant-2: Consider requesting a transition for enchant1->2

2020-01-02 Thread Boyuan Yang
Source: enchant-2
Severity: wishlist
Version: 2.2.7+repack1-1
X-Debbugs-CC: pr...@debian.org

Since enchant 1.x is not really maintained by upstream, it might be
reasonable to request a (manual) transition from enchant1 to enchant2
after enchant-2 enters Testing.

This issue might not be suitable to be submitted as a bug against
enchant-2 package; please feel free to properly reassign it. At least
this will make the maintainers for both enchant and enchant-2 to be
aware of it.

-- 
Best,
Boyuan Yang


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


Bug#947978: license problem

2020-01-02 Thread Thorsten Alteholz

Package: bind9
Version: 1:9.15.5-1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
thanks

Hi,

our hardworking trainees added a note to your package:

 d/copyright mentions that this source is:
  License: MPL-2.0 and ISC and BSD-2-clause and BSD-3-clause
 However, LICENSE only says MPL-2.0. I see no indication that the majority
 of source files are quadruple-licensed. Rather, the majority seem to be
 only MPL-2.0.

 The directories lim/isccc/ and m4/ have a number of copyright holders not
 that are not mentioned in d/copyright.

 lib/irs/getnameinfo.c also has a copyright holder (WIDE Project) that is
 not mentioned in d/copyright.


Please take care of these issues.

Thanks!
  Thorsten



Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

2020-01-02 Thread Karl O. Pinc
On Thu, 2 Jan 2020 16:56:10 -0600
"Karl O. Pinc"  wrote:

> On Thu, 2 Jan 2020 13:27:19 -0600
> "Karl O. Pinc"  wrote:
> 
> > Attached are 2 patches:
> > 
> > cleanup_v2.patch
> >   This should incorporate all changes discussed so far.
> > 
> > section_v1.patch
> >   This applies on top of the cleanup patch.  It re-titles
> >   the 4.2 section and adds sub-sections.  If you want this
> >   in a separate bug report, discussed elsewhere, etc.,
> >   please let me know.  (I had it in my brain and wanted
> >   to get it out.)  
> 
> Attached is section_v2.patch, to be applied on top of
> cleanup_v2.patch.  (Replaces section_v1.patch.)

Attached is a cleanup_v3.patch.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 9cc9f7a4..eb32edc8 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -244,73 +244,105 @@
 
 
 
-  Checking APT configuration status
+  Start from "pure" Debian
   
-The upgrade process described in this chapter has been designed for
-pure Debian stable systems. If your APT configuration
-mentions additional sources besides , or if you have
-installed packages from other releases or from third parties, then to
-ensure a reliable upgrade process you may wish to begin by removing these
-complicating factors.
+The upgrade process described in this chapter has been designed
+for pure Debian stable systems. APT controls what
+is installed on your system. If your APT configuration mentions
+additional sources besides , or if you have
+installed packages from other releases or from third parties, then
+to ensure a reliable upgrade process you may wish to begin by
+removing these complicating factors.
   
   
-The main configuration file that APT uses to decide what sources it should
-download packages from is /etc/apt/sources.list, but
-it can also use files in the /etc/apt/sources.list.d/
+The main configuration file that APT uses to decide what sources
+it should download packages from is
+/etc/apt/sources.list, but it can also use
+files in the /etc/apt/sources.list.d/
 directory - for details see sources.list(5).
-If your system is using multiple source-list files then you will need to
-ensure they stay consistent.
+If your system is using multiple source-list files then you will
+need to ensure they stay consistent.
   
-  
-Below there are two methods for finding installed packages that
-did not come from Debian, using either
-aptitude or apt-forktracer.  Please
-note that neither of them are 100% accurate  (e.g. the aptitude example
-will list packages that were once provided by Debian but no longer are, such as
-old kernel packages).
-$ aptitude search '~i(!~ODebian)'
-$ apt-forktracer | sort
-  
-  
-  
-Direct upgrades from Debian releases older than  ()
-are not supported.
-Please follow the instructions in the https://www.debian.org/releases//releasenotes;>Release
-Notes for   to upgrade to   first.
-  
-  
-This procedure also assumes your system has been updated to the latest point
-release of .  If you have not done this or are unsure, follow the
-instructions in .
-  
-  
-You should also make sure the package database is ready before proceeding
-with the upgrade. If you are a user of another package manager like
-aptitude or synaptic, review any pending actions. A
-package scheduled for installation or removal
-might interfere with the upgrade procedure. Note that correcting this is
-only possible if your APT source-list files still point to
- and not to
-stable or ; see
-.
-  
-  
-It is a good idea to remove obsolete
-packages from your system before upgrading.
-  
-  
-A previous upgrade may have left unused copies of configuration
-files; old versions
-of configuration files, versions supplied by the package
-maintainers, etc.  Removing leftover files from previous upgrades
-can avoid confusion.  Find such leftover files with:
-  
-  
-# find /etc -name '*.dpkg-*' '*.ucf-*' '*.merge-error'
-  
+
+  
+Upgrade to Debian  ()
+
+  Direct upgrades from Debian releases older than 
+  () are not supported.  Display your Debian version
+  with:
+  
+$ cat /etc/debian_version
+  
+  Please follow
+  the instructions in the https://www.debian.org/releases//releasenotes;>Release
+  Notes for   to upgrade to 
+   first.
+
+  
+
+  
+Remove non-Debian packages
+
+  Below there are two methods for finding installed packages that
+  did not come from Debian, using either
+  aptitude or apt-forktracer.  Please
+  note that neither of them are 100% accurate  (e.g. the aptitude example
+  will list packages that were once provided by Debian but no longer are, such as
+  old kernel packages).

Bug#947976: license problems

2020-01-02 Thread Thorsten Alteholz

Package: netcdf
Version: 1:4.6.3-1~exp1
Severity: serious
User: alteh...@debian.org
Usertags: ftp
thanks

Hi,

our hardworking trainees added a note to your package:

 CODE_OF_CONDUCT.md not accounted for in d/copyright (it's CC-BY-4.0).

 Copyright for docs/auth.html wrong, and the file seems to be generated
 from auth.md -- can you confirm we can regenerate it with tools in the
 archive?

 What reason is there to think that docs\unidata_logo_cmyk.png is
 redistributible?

 Can docs/docmap.pdf be rebuilt?

 Are the .dmp, .hdf4 and .nc files in dap4_test/, hdf4_test/ and
 h5_test/ perhaps generated files?  Can they be regenerated?

 I think that it would be best to explicitly include the Unidata
 copyright line from COPYRIGHT in addition to the "University
 Corporation for Atmospheric Research/Unidata" line.

 debian/ copyright stanza out-of-date.


Please take care of these issues.

Thanks!
  Thorsten



Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

2020-01-02 Thread Karl O. Pinc
On Thu, 2 Jan 2020 13:27:19 -0600
"Karl O. Pinc"  wrote:

> Attached are 2 patches:
> 
> cleanup_v2.patch
>   This should incorporate all changes discussed so far.
> 
> section_v1.patch
>   This applies on top of the cleanup patch.  It re-titles
>   the 4.2 section and adds sub-sections.  If you want this
>   in a separate bug report, discussed elsewhere, etc.,
>   please let me know.  (I had it in my brain and wanted
>   to get it out.)

Attached is section_v2.patch, to be applied on top of
cleanup_v2.patch.  (Replaces section_v1.patch.)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 9cc9f7a4..fa6f9c74 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -244,73 +244,105 @@
 
 
 
-  Checking APT configuration status
+  Start from "pure" Debian
   
-The upgrade process described in this chapter has been designed for
-pure Debian stable systems. If your APT configuration
-mentions additional sources besides , or if you have
-installed packages from other releases or from third parties, then to
-ensure a reliable upgrade process you may wish to begin by removing these
-complicating factors.
+The upgrade process described in this chapter has been designed
+for pure Debian stable systems. APT controls what
+is installed on your system. If your APT configuration mentions
+additional sources besides , or if you have
+installed packages from other releases or from third parties, then
+to ensure a reliable upgrade process you may wish to begin by
+removing these complicating factors.
   
   
-The main configuration file that APT uses to decide what sources it should
-download packages from is /etc/apt/sources.list, but
-it can also use files in the /etc/apt/sources.list.d/
+The main configuration file that APT uses to decide what sources
+it should download packages from is
+/etc/apt/sources.list, but it can also use
+files in the /etc/apt/sources.list.d/
 directory - for details see sources.list(5).
-If your system is using multiple source-list files then you will need to
-ensure they stay consistent.
+If your system is using multiple source-list files then you will
+need to ensure they stay consistent.
   
-  
-Below there are two methods for finding installed packages that
-did not come from Debian, using either
-aptitude or apt-forktracer.  Please
-note that neither of them are 100% accurate  (e.g. the aptitude example
-will list packages that were once provided by Debian but no longer are, such as
-old kernel packages).
-$ aptitude search '~i(!~ODebian)'
-$ apt-forktracer | sort
-  
-  
-  
-Direct upgrades from Debian releases older than  ()
-are not supported.
-Please follow the instructions in the https://www.debian.org/releases//releasenotes;>Release
-Notes for   to upgrade to   first.
-  
-  
-This procedure also assumes your system has been updated to the latest point
-release of .  If you have not done this or are unsure, follow the
-instructions in .
-  
-  
-You should also make sure the package database is ready before proceeding
-with the upgrade. If you are a user of another package manager like
-aptitude or synaptic, review any pending actions. A
-package scheduled for installation or removal
-might interfere with the upgrade procedure. Note that correcting this is
-only possible if your APT source-list files still point to
- and not to
-stable or ; see
-.
-  
-  
-It is a good idea to remove obsolete
-packages from your system before upgrading.
-  
-  
-A previous upgrade may have left unused copies of configuration
-files; old versions
-of configuration files, versions supplied by the package
-maintainers, etc.  Removing leftover files from previous upgrades
-can avoid confusion.  Find such leftover files with:
-  
-  
-# find /etc -name '*.dpkg-*' '*.ucf-*' '*.merge-error'
-  
+
+  
+Upgrade to Debian  ()
+
+  Direct upgrades from Debian releases older than 
+  () are not supported.  Display your Debian version
+  with:
+  
+$ cat /etc/debian_version
+  
+  Please follow
+  the instructions in the https://www.debian.org/releases//releasenotes;>Release
+  Notes for   to upgrade to 
+   first.
+
+  
+
+  
+Remove non-Debian packages
+
+  Below there are two methods for finding installed packages that
+  did not come from Debian, using either
+  aptitude or apt-forktracer.  Please
+  note that neither of them are 100% accurate  (e.g. the aptitude example
+  will list packages that were once provided by Debian but no longer are, such as
+  old kernel packages).
+  $ aptitude search '~i(!~ODebian)'
+  $ apt-forktracer | sort
+
+
+  
+
+  
+Upgrade to latest point release
+

Bug#947975: ITP: mariadb-mysql-kbs - A php library that contains the documentation of MariaDB and MySQL server variables and more

2020-01-02 Thread William Desportes
Package: wnpp
Owner: William Desportes 
Severity: wishlist

* Package name: mariadb-mysql-kbs
  Version : x.y.z
  Upstream Author : William Desportes 
* URL : https://github.com/williamdes/mariadb-mysql-kbs
* License : MPL-2.0
  Programming Lang: PHP
  Description : mariadb-mysql-kbs is a php library that allow access to the 
documentation of MariaDB and MySQL server variables and more

This package is a dependency of phpMyAdmin since version 5.0

The packaging is done and ready for review.



Bug#947974: ITP: light - control display backlight controllers and LEDs

2020-01-02 Thread Samuel Henrique
Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org

* Package name: light
* URL : https://github.com/haikarainen/light
* License : GPL-3
  Programming Lang: C
  Description :
 Light is a useful tool to control display brightness in lightweight
 desktops or window managers that do not have bundled applications for
 this purpose.
 .
 Most modern laptops have moved away from hardware controlled brightness
 and require software control.  Light works where other software has
 proven to be unreliable, e.g. xbacklight.  It can even be used from the
 console as it does not rely on X.
 .
 Light has features like setting a minimum brightness value, as well as
 saving and restoring the brightness at reboot and startup.


-- 
Samuel Henrique 


Bug#941266: netty: CVE-2019-16869

2020-01-02 Thread Salvatore Bonaccorso
Control: tags -1 + patch

On Fri, Sep 27, 2019 at 01:12:04PM +0200, Salvatore Bonaccorso wrote:
> Source: netty
> Version: 1:4.1.33-1
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/netty/netty/issues/9571
> 
> Hi,
> 
> The following vulnerability was published for netty.
> 
> CVE-2019-16869[0]:
> | Netty before 4.1.42.Final mishandles whitespace before the colon in
> | HTTP headers (such as a "Transfer-Encoding : chunked" line), which
> | leads to HTTP request smuggling.

Attached is the proposed debdiff. I included the tests as well
(altough those are not run).

Regards,
Salvatore
diff -Nru netty-4.1.33/debian/changelog netty-4.1.33/debian/changelog
--- netty-4.1.33/debian/changelog   2019-01-22 14:06:25.0 +0100
+++ netty-4.1.33/debian/changelog   2020-01-02 20:47:57.0 +0100
@@ -1,3 +1,11 @@
+netty (1:4.1.33-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Correctly handle whitespaces in HTTP header names as defined by
+RFC7230#section-3.2.4 (CVE-2019-16869) (Closes: #941266)
+
+ -- Salvatore Bonaccorso   Thu, 02 Jan 2020 20:47:57 +0100
+
 netty (1:4.1.33-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
netty-4.1.33/debian/patches/14-Correctly-handle-whitespaces-in-HTTP-header-names-as.patch
 
netty-4.1.33/debian/patches/14-Correctly-handle-whitespaces-in-HTTP-header-names-as.patch
--- 
netty-4.1.33/debian/patches/14-Correctly-handle-whitespaces-in-HTTP-header-names-as.patch
   1970-01-01 01:00:00.0 +0100
+++ 
netty-4.1.33/debian/patches/14-Correctly-handle-whitespaces-in-HTTP-header-names-as.patch
   2020-01-02 20:47:57.0 +0100
@@ -0,0 +1,98 @@
+From: Norman Maurer 
+Date: Fri, 20 Sep 2019 21:02:11 +0200
+Subject: Correctly handle whitespaces in HTTP header names as defined by
+ RFC7230#section-3.2.4 (#9585)
+Origin: 
https://github.com/netty/netty/commit/39cafcb05c99f2aa9fce7e6597664c9ed6a63a95
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-16869
+Bug-Debian: https://bugs.debian.org/941266
+Bug: https://github.com/netty/netty/issues/9571
+
+Motivation:
+
+When parsing HTTP headers special care needs to be taken when a whitespace is 
detected in the header name.
+
+Modifications:
+
+- Ignore whitespace when decoding response (just like before)
+- Throw exception when whitespace is detected during parsing
+- Add unit tests
+
+Result:
+
+Fixes https://github.com/netty/netty/issues/9571
+[Salvatore Bonaccorso: Backport to 4.1.33 for context changes in
+HttpObjectDecoder.java]
+---
+ .../handler/codec/http/HttpObjectDecoder.java| 16 +++-
+ .../codec/http/HttpRequestDecoderTest.java   | 14 ++
+ .../codec/http/HttpResponseDecoderTest.java  | 15 +++
+ 3 files changed, 44 insertions(+), 1 deletion(-)
+
+--- 
a/codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java
 
b/codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java
+@@ -736,7 +736,21 @@ public abstract class HttpObjectDecoder
+ nameStart = findNonWhitespace(sb, 0);
+ for (nameEnd = nameStart; nameEnd < length; nameEnd ++) {
+ char ch = sb.charAt(nameEnd);
+-if (ch == ':' || Character.isWhitespace(ch)) {
++// https://tools.ietf.org/html/rfc7230#section-3.2.4
++//
++// No whitespace is allowed between the header field-name and 
colon. In
++// the past, differences in the handling of such whitespace have 
led to
++// security vulnerabilities in request routing and response 
handling. A
++// server MUST reject any received request message that contains
++// whitespace between a header field-name and colon with a 
response code
++// of 400 (Bad Request). A proxy MUST remove any such whitespace 
from a
++// response message before forwarding the message downstream.
++if (ch == ':' ||
++// In case of decoding a request we will just continue 
processing and header validation
++// is done in the DefaultHttpHeaders implementation.
++//
++// In the case of decoding a response we will "skip" the 
whitespace.
++(!isDecodingRequest() && Character.isWhitespace(ch))) {
+ break;
+ }
+ }
+--- 
a/codec-http/src/test/java/io/netty/handler/codec/http/HttpRequestDecoderTest.java
 
b/codec-http/src/test/java/io/netty/handler/codec/http/HttpRequestDecoderTest.java
+@@ -320,4 +320,18 @@ public class HttpRequestDecoderTest {
+ assertTrue(request.decoderResult().cause() instanceof 
TooLongFrameException);
+ assertFalse(channel.finish());
+ }
++
++@Test
++public void testWhitespace() {
++EmbeddedChannel channel = new EmbeddedChannel(new 
HttpRequestDecoder());
++String requestStr = "GET /some/path HTTP/1.1\r\n" +
++   

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

2020-01-02 Thread nurupo
No point in reporting this bug upstream, they will not be able to
reproduce it as it's related to the hardware video acceleration patch
that Debian has recently started applying on top of the upstream
Chromium: 
https://salsa.debian.org/chromium-team/chromium/blob/c88b97a6dc183a6a7f8a05aee9e99957285a9371/debian/patches/fixes/vaapi.patch

As I can see, there are two possibilities here:
1. the patch got broken in Chromium 79, in which case it needs to be
updated and fixed
2. the issue is not with Chromium but the VAAPI library or the
hardware you use, in which case you could make Chromium use different
GPU (integrated graphics) or disable hardware video acceleration
altogether, either by passing some flag to Chromium (removing
--ignore-gpu-blacklist from /etc/chromium.d/default-flags might work
too) or rebuilding Chromium without the patch



Bug#947446: closed by Rene Engelhard (Bug#947446: fixed in libreoffice 1:6.4.0~rc1-3)

2020-01-02 Thread Andreas Beckmann
Control: reopen -1
Control: found -1 1:6.4.0~rc1-5

Hi Rene,

it looks like ure is still shipping (some of) the files that were split 
out to separate packages:

  Selecting previously unselected package ure.
  Preparing to unpack .../08-ure_6.4.0~rc1-5_amd64.deb ...
  Unpacking ure (6.4.0~rc1-5) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-p2iEE9/08-ure_6.4.0~rc1-5_amd64.deb (--unpack):
   trying to overwrite '/usr/share/java/juh.jar', which is also in package 
libjuh-java 1:6.4.0~rc1-5

Similarily for libjurt-java, libridl-java, libunoloader-java in sid.

Don't forget to bump the B+R against ure to a version that is no longer
shipping them.

Andreas



Bug#945392: hyperkitty: diff for NMU version 1.3.0-1.1

2020-01-02 Thread Sandro Tosi



Dear maintainer,

I've prepared an NMU for hyperkitty (versioned as 1.3.0-1.1). The diff
is attached to this message.

Regards.

diff -Nru hyperkitty-1.3.0/debian/changelog hyperkitty-1.3.0/debian/changelog
--- hyperkitty-1.3.0/debian/changelog	2019-10-27 08:21:44.0 -0400
+++ hyperkitty-1.3.0/debian/changelog	2020-01-02 16:17:27.0 -0500
@@ -1,3 +1,11 @@
+hyperkitty (1.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/MR201.patch
+- make hyperkitty compatible with networkx 2.4; Closes: #945392
+
+ -- Sandro Tosi   Thu, 02 Jan 2020 16:17:27 -0500
+
 hyperkitty (1.3.0-1) unstable; urgency=medium
 
   [ Jonas Meurer ]
diff -Nru hyperkitty-1.3.0/debian/patches/MR201.patch hyperkitty-1.3.0/debian/patches/MR201.patch
--- hyperkitty-1.3.0/debian/patches/MR201.patch	1969-12-31 19:00:00.0 -0500
+++ hyperkitty-1.3.0/debian/patches/MR201.patch	2020-01-02 16:16:44.0 -0500
@@ -0,0 +1,47 @@
+From c95c00276000f48f1ac2d211450f54454e74fe9c Mon Sep 17 00:00:00 2001
+From: Abhilash Raj 
+Date: Sun, 17 Nov 2019 19:17:45 -0800
+Subject: [PATCH] Fix for networkx 2.4
+
+---
+ hyperkitty/lib/analysis.py | 4 ++--
+ setup.py   | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/hyperkitty/lib/analysis.py b/hyperkitty/lib/analysis.py
+index 87120fba..cfaba7a3 100644
+--- a/hyperkitty/lib/analysis.py
 b/hyperkitty/lib/analysis.py
+@@ -34,14 +34,14 @@ def compute_thread_order_and_depth(thread):
+ thread_pos = {"d": 0, "o": 0}  # depth, order
+ 
+ def walk_successors(msgid):
+-obj = graph.node[msgid]["obj"]
++obj = graph.nodes[msgid]["obj"]
+ obj.thread_depth = thread_pos["d"]
+ obj.thread_order = thread_pos["o"]
+ obj.save(update_fields=["thread_depth", "thread_order"])
+ thread_pos["d"] += 1
+ thread_pos["o"] += 1
+ for succ in sorted(graph.successors(msgid),
+-   key=lambda m: graph.node[m]["num"]):
++   key=lambda m: graph.nodes[m]["num"]):
+ walk_successors(succ)
+ thread_pos["d"] -= 1
+ for index, email in enumerate(thread.emails.order_by("date")):
+diff --git a/setup.py b/setup.py
+index 1844d7f7..48a30c95 100755
+--- a/setup.py
 b/setup.py
+@@ -46,7 +46,7 @@ REQUIRES = [
+ "django-compressor>=1.3",
+ "mailmanclient>=3.1.1",
+ "python-dateutil >= 2.0",
+-"networkx>=1.9.1",
++"networkx>=2.0",
+ "django-haystack>=2.8.0",
+ "django-extensions>=1.3.7",
+ "flufl.lock",
+-- 
+2.24.1
+
diff -Nru hyperkitty-1.3.0/debian/patches/series hyperkitty-1.3.0/debian/patches/series
--- hyperkitty-1.3.0/debian/patches/series	2019-10-27 07:55:34.0 -0400
+++ hyperkitty-1.3.0/debian/patches/series	2020-01-02 16:16:44.0 -0500
@@ -1,3 +1,4 @@
 0001_README_remove_embedded_images.patch
 0002_Use_python3_by_default.patch
 0003-run-sassc-at-build-time.patch
+MR201.patch


Bug#934949: clips: build-depends on removed package pdf2htmlex

2020-01-02 Thread Paul Gevers
Dear Javier,

On Sat, 17 Aug 2019 09:11:28 +0200 Ralf Treinen  wrote:
> Source: clips
> Version: pdf2htmlex
> Severity: serious
> Version: 6.30-4
> User: trei...@debian.org
> Usertags: edos-uninstallable
> 
> Hi,
> 
> clips build-depends on pdf2htmlex which was removed from unstable on
> 2019-04-01.

I expect that you didn't receive this message due to bug #881009. Can
you please fix your package? It didn't migrate to testing for over two
years.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#947470: [Py3] TypeError: a bytes-like object is required, not 'str' in pkey.write_private_key()

2020-01-02 Thread Emmanuel Arias
Hi!,

I can apply the patch, but the Travis-CI is failing for the patch.

https://travis-ci.org/paramiko/paramiko/builds/630010264?utm_source=github_status_medium=notification

Thanks!


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com


Bug#947973: fspanel FTCBFS: does not pass cross tools to make

2020-01-02 Thread Helmut Grohne
Source: fspanel
Version: 0.7-15
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fspanel fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
makes fspanel cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru fspanel-0.7/debian/changelog fspanel-0.7/debian/changelog
--- fspanel-0.7/debian/changelog2019-12-31 16:10:52.0 +0100
+++ fspanel-0.7/debian/changelog2020-01-02 22:24:12.0 +0100
@@ -1,3 +1,9 @@
+fspanel (0.7-16) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 Jan 2020 22:24:12 +0100
+
 fspanel (0.7-15) unstable; urgency=medium
 
   [ Giovani Augusto Ferreira ]
diff --minimal -Nru fspanel-0.7/debian/rules fspanel-0.7/debian/rules
--- fspanel-0.7/debian/rules2019-12-31 16:10:52.0 +0100
+++ fspanel-0.7/debian/rules2020-01-02 22:24:11.0 +0100
@@ -13,7 +13,7 @@
# Do nothing. See files debian/{install,manpages}
 
 override_dh_auto_build:
-   $(MAKE) EXTRA_CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
+   dh_auto_build -- EXTRA_CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
 
 %:
dh $@


Bug#947972: transcalc: broken, outdated, embedded copy of AM_PATH_GTK_2_0

2020-01-02 Thread Helmut Grohne
Source: transcalc
Version: 0.14-6
Tags: fixed-upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

transcalc fails to cross build from source, because it uses a broken,
outdated, embedded copy of AM_PATH_GTK_2_0 in aclocal.m4. The actual bug
is already fixed, see #895002. transcalc just happens to ship a copy of
the bug. The Debian policy discourages embedded code copies. Please
remove your copy. Failing that, please update your copy and register it
with the security tracker. See
https://wiki.debian.org/EmbeddedCodeCopies for how to do that. This bug
report comes without a patch, because the actual issue is already fixed.

Helmut



Bug#947950: autoconf BD on texlive-generic-recommended which isn't build anymore and isn't in bullseye

2020-01-02 Thread Paul Gevers
Control: tags -1 patch

On 02-01-2020 18:43, Paul Gevers wrote:
> I intent to prepare an NMU and upload it to DELAYED/15 or so, please let
> me know if you will handle this yourself.

I have uploaded the attached changes to DELAYED/15.

Paul
diff --git a/debian/changelog b/debian/changelog
index 9917e79..ece0b6c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+autoconf (2.69-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on texlive-plain-generic instead of
+texlive-generic-recommended Closes: #947950
+
+ -- Paul Gevers   Thu, 02 Jan 2020 21:24:24 +0100
+
 autoconf (2.69-11) unstable; urgency=medium
 
   * debian/patches/mmap-leak-fix.patch: New patch from upstream commit
diff --git a/debian/control b/debian/control
index 2a7cab4..74653c2 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Ben Pfaff 
 Standards-Version: 3.9.3
 Build-Depends-Indep: texinfo (>= 4.6), m4 (>= 1.4.13),
- texlive-base, texlive-generic-recommended, texlive-latex-base,
+ texlive-base, texlive-plain-generic, texlive-latex-base,
  texlive-latex-recommended, texlive-fonts-recommended, help2man, cm-super
 Build-Depends: debhelper (>= 7.0.50~)
 Homepage: http://www.gnu.org/software/autoconf/


signature.asc
Description: OpenPGP digital signature


Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang

2020-01-02 Thread Bernd Zeimetz
Hi,

> ceph-mgr queue on large clusters grows indefinitely pushing cpu utilization
> to 100% and causing command execution to hang. For more info see:
>   
>   https://tracker.ceph.com/issues/43364

any idea if this affects 14.2.4?


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#947971: whois FTCBFS: does not pass cross tools to make

2020-01-02 Thread Helmut Grohne
Source: whois
Version: 5.5.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Since the dh conversion in 5.5.3, the package no longer passes cross
tools to make. Please consider applying the attached patch to fix that.
Also consider making the package nmu-able.

Helmut
diff --minimal -Nru whois-5.5.4/debian/changelog whois-5.5.5/debian/changelog
--- whois-5.5.4/debian/changelog2019-12-31 03:04:15.0 +0100
+++ whois-5.5.5/debian/changelog2020-01-02 21:55:09.0 +0100
@@ -1,3 +1,10 @@
+whois (5.5.5) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 Jan 2020 21:55:09 +0100
+
 whois (5.5.4) unstable; urgency=medium
 
   * Updated the .vu TLD server.
diff --minimal -Nru whois-5.5.4/debian/rules whois-5.5.5/debian/rules
--- whois-5.5.4/debian/rules2019-11-14 04:31:41.0 +0100
+++ whois-5.5.5/debian/rules2020-01-02 21:55:02.0 +0100
@@ -4,5 +4,5 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) CONFIG_FILE="/etc/whois.conf" HAVE_ICONV=1
+   dh_auto_build -- CONFIG_FILE="/etc/whois.conf" HAVE_ICONV=1
 


Bug#947970: please update to the fresh release 1.4.2.1.6

2020-01-02 Thread Yaroslav Halchenko
Package: libghc-filepath-bytestring-dev
Version: 1.4.2.1.0-2
Severity: wishlist

Upstream maintainer, Joey (CCed), uploaded a new version which should
also make package backportable (to buster).

thanks in advance

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages libghc-filepath-bytestring-dev depends on:
ii  ghc [libghc-unix-dev-2.7.2.2-dbe0e]   8.8.1+dfsg1+is+8.6.5+dfsg1-2
ii  libatomic19.2.1-19
ii  libc6 2.29-3
pn  libghc-base-dev-4.12.0.0-a86a1
pn  libghc-bytestring-dev-0.10.8.2-20f27  
ii  libgmp10  2:6.1.2+dfsg-4

libghc-filepath-bytestring-dev recommends no packages.

Versions of packages libghc-filepath-bytestring-dev suggests:
pn  libghc-filepath-bytestring-doc   
pn  libghc-filepath-bytestring-prof  

-- debconf-show failed



Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang

2020-01-02 Thread Milan Kupcevic
Package: ceph-mgr
Version: 14.2.5-1
Severity: serious
Tags: upstream
Forwarded: https://tracker.ceph.com/issues/43364

ceph-mgr queue on large clusters grows indefinitely pushing cpu utilization
to 100% and causing command execution to hang. For more info see:
  
  https://tracker.ceph.com/issues/43364


Milan



Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Dmitry Shachnev
On Thu, Jan 02, 2020 at 11:18:07PM +0300, Dmitry Shachnev wrote:
> Actually I also saw a warning on the github page and it bothered me.
> But I was able to run the tests and they all pass, so I guess it should not
> be *that* broken.

According to https://github.com/bluebird75/winpdb/issues/15 it looks like
the GUI may be not working.

Can one of you please check that?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#947968: openctm FTCBFS: builds for the build architecture

2020-01-02 Thread Helmut Grohne
Source: openctm
Version: 1.0.3+dfsg1-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openctm fails to cross build from source, because it builds for the
build architecture. Using dh_auto_build partially fixes that, but the
upstream build system hard codes build architecture build tools in a few
occasions. Even then, it fails running bin2c, because it needs to be run
during build and thus built using the build architecture compiler.
Please consider applying the attached patch to fix all of the aspects.

Helmut
diff --minimal -Nru openctm-1.0.3+dfsg1/debian/changelog 
openctm-1.0.3+dfsg1/debian/changelog
--- openctm-1.0.3+dfsg1/debian/changelog2019-12-19 00:54:01.0 
+0100
+++ openctm-1.0.3+dfsg1/debian/changelog2020-01-02 20:25:47.0 
+0100
@@ -1,3 +1,13 @@
+openctm (1.0.3+dfsg1-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make build tools substitutable.
++ Let dh_auto_build pass cross tools to make.
++ Build the build tool "bin2c" for the build architecture.
+
+ -- Helmut Grohne   Thu, 02 Jan 2020 20:25:47 +0100
+
 openctm (1.0.3+dfsg1-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru openctm-1.0.3+dfsg1/debian/patches/cross.patch 
openctm-1.0.3+dfsg1/debian/patches/cross.patch
--- openctm-1.0.3+dfsg1/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ openctm-1.0.3+dfsg1/debian/patches/cross.patch  2020-01-02 
20:25:47.0 +0100
@@ -0,0 +1,32 @@
+--- openctm-1.0.3+dfsg1.orig/lib/Makefile.linux
 openctm-1.0.3+dfsg1/lib/Makefile.linux
+@@ -72,7 +72,7 @@
+   $(RM) $(DYNAMICLIB) $(SONAME) $(LIBNAME) $(OBJS) $(LZMA_OBJS)
+ 
+ $(DYNAMICLIB): $(OBJS) $(LZMA_OBJS)
+-  gcc $(LDFLAGS) -shared -s -Wl,-soname,$(SONAME) -o $@ $(OBJS) 
$(LZMA_OBJS) -lm
++  $(CC) $(LDFLAGS) -shared -s -Wl,-soname,$(SONAME) -o $@ $(OBJS) 
$(LZMA_OBJS) -lm
+   ln -s $(DYNAMICLIB) $(SONAME)
+   ln -s $(DYNAMICLIB) $(LIBNAME)
+ 
+--- openctm-1.0.3+dfsg1.orig/tools/Makefile.linux
 openctm-1.0.3+dfsg1/tools/Makefile.linux
+@@ -38,7 +38,8 @@
+ #PNGLITEDIR = pnglite
+ 
+ CXX = g++
+-CXXFLAGS += -W -Wall `pkg-config --cflags gtk+-2.0` -I$(OPENCTMDIR) 
-I$(RPLYDIR) -I$(GLEWDIR)
++PKG_CONFIG ?= pkg-config
++CXXFLAGS += -W -Wall `$(PKG_CONFIG) --cflags gtk+-2.0` -I$(OPENCTMDIR) 
-I$(RPLYDIR) -I$(GLEWDIR)
+ 
+ MESHOBJS = mesh.o meshio.o ctm.o ply.o rply.o stl.o 3ds.o dae.o obj.o lwo.o 
off.o wrl.o
+ CTMCONVOBJS = ctmconv.o common.o systimer.o convoptions.o $(MESHOBJS)
+@@ -109,7 +110,7 @@
+ # gcc -c -Os -W -I$(GLEWDIR) -o $@ $<
+ 
+ rply.o: $(RPLYDIR)/rply.c
+-  gcc $(CPPFLAGS) $(CFLAGS) -c -O2 -W -I$(RPLYDIR) -o $@ $<
++  $(CC) $(CPPFLAGS) $(CFLAGS) -c -O2 -W -I$(RPLYDIR) -o $@ $<
+ 
+ #pnglite.o: $(PNGLITEDIR)/pnglite.c
+ # gcc -c -O2 -W -I$(PNGLITEDIR) -o $@ $<
diff --minimal -Nru openctm-1.0.3+dfsg1/debian/patches/series 
openctm-1.0.3+dfsg1/debian/patches/series
--- openctm-1.0.3+dfsg1/debian/patches/series   2018-03-24 18:01:59.0 
+0100
+++ openctm-1.0.3+dfsg1/debian/patches/series   2020-01-02 20:25:47.0 
+0100
@@ -1,2 +1,3 @@
 makefiles
 escape-hyphens-in-man
+cross.patch
diff --minimal -Nru openctm-1.0.3+dfsg1/debian/rules 
openctm-1.0.3+dfsg1/debian/rules
--- openctm-1.0.3+dfsg1/debian/rules2019-12-19 00:51:25.0 +0100
+++ openctm-1.0.3+dfsg1/debian/rules2020-01-02 20:25:47.0 +0100
@@ -3,7 +3,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
@@ -25,6 +25,10 @@
rm -rf $(TDIR)/tools/zlib
tar -jcf openctm_$(DEBVERSION).orig.tar.bz2 $(TDIR)
 
+override_dh_auto_build:
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build 
--buildsystem=makefile --sourcedirectory=tools -- -f Makefile.linux bin2c
+   dh_auto_build
+
 override_dh_compress:
dh_compress -X.pdf
 


Bug#947966: php-nesbot-carbon: include an autoloader

2020-01-02 Thread Robin Gustafsson
Package: php-nesbot-carbon
Version: 1.27.0-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Please consider including an autoloader (autoload.php) in the package.

Many PHP library packages contain a file (autoload.php) defining an
autoloader for the library's classes and loading its own dependencies.
It's then sufficient for the client to include this one file to use the
library, without care for the its internals, dependencies, etc.

Outside of Debian packaging, this is often similarly handled with Composer's
"vendor/autoload.php" file.

I've attached a patch to implement this, should you be interested.

Regards,
Robin


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

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

Versions of packages php-nesbot-carbon depends on:
ii  php-common   2:69
pn  php-symfony-translation  

php-nesbot-carbon recommends no packages.

php-nesbot-carbon suggests no packages.
>From c68adc94881cf69613c15531b873ff9778f1e901 Mon Sep 17 00:00:00 2001
From: Robin Gustafsson 
Date: Thu, 2 Jan 2020 20:34:10 +0100
Subject: [PATCH] Add an autoloader

---
 debian/autoload.php.tpl | 24 
 debian/clean|  1 +
 debian/control  |  2 +-
 debian/rules|  4 
 4 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 debian/autoload.php.tpl
 create mode 100644 debian/clean

diff --git a/debian/autoload.php.tpl b/debian/autoload.php.tpl
new file mode 100644
index 000..89c4f4f
--- /dev/null
+++ b/debian/autoload.php.tpl
@@ -0,0 +1,24 @@
+
 Uploaders: Thorsten Glaser , Dominik George 

-Build-Depends: debhelper-compat (= 12), pkg-php-tools (>= 1.7~)
+Build-Depends: debhelper-compat (= 12), pkg-php-tools (>= 1.7~), phpab
 Standards-Version: 4.4.1
 Homepage: https://carbon.nesbot.com/
 Rules-Requires-Root: no
diff --git a/debian/rules b/debian/rules
index 3b60be1..4a6c6bd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,3 +2,7 @@
 
 %:
dh $@ --with phpcomposer
+
+override_dh_auto_build:
+   dh_auto_build
+   phpab -o src/Carbon/autoload.php -t debian/autoload.php.tpl src/Carbon
-- 
2.20.1



Bug#947967: xbattbar FTCBFS: uses the build architecture compiler

2020-01-02 Thread Helmut Grohne
Source: xbattbar
Version: 1.4.9-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xbattbar fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler and the debian packaging does
not pass cross tools to make. The attached patch fixes both aspects.
Please consider applying it.

Helmut
diff --minimal -Nru xbattbar-1.4.9/debian/changelog 
xbattbar-1.4.9/debian/changelog
--- xbattbar-1.4.9/debian/changelog 2020-01-01 08:49:59.0 +0100
+++ xbattbar-1.4.9/debian/changelog 2020-01-02 20:30:46.0 +0100
@@ -1,3 +1,12 @@
+xbattbar (1.4.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make gcc substitutable.
++ Let dh_auto_build substitute $(CC).
+
+ -- Helmut Grohne   Thu, 02 Jan 2020 20:30:46 +0100
+
 xbattbar (1.4.9-2) unstable; urgency=medium
 
   * Rebuild package with pbuilder:SOURCE_ONLY_CHANGES=yes.
diff --minimal -Nru xbattbar-1.4.9/debian/patches/cross.patch 
xbattbar-1.4.9/debian/patches/cross.patch
--- xbattbar-1.4.9/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ xbattbar-1.4.9/debian/patches/cross.patch   2020-01-02 20:30:45.0 
+0100
@@ -0,0 +1,23 @@
+--- xbattbar-1.4.9.orig/Makefile
 xbattbar-1.4.9/Makefile
+@@ -11,16 +11,16 @@
+ all: $(TARGET) $(APM_CHECK)
+ 
+ $(TARGET): obj/xbattbar.o
+-  gcc -o $@ $< -lX11 $(LDFLAGS)
++  $(CC) -o $@ $< -lX11 $(LDFLAGS)
+ 
+ obj/xbattbar.o: xbattbar.c obj/stamp
+-  gcc -MMD -o $@ -c $< $(CFLAGS)
++  $(CC) -MMD -o $@ -c $< $(CFLAGS)
+ 
+ $(APM_CHECK): obj/xbattbar-check-apm.o
+-  gcc -o $@ $< $(LDFLAGS)
++  $(CC) -o $@ $< $(LDFLAGS)
+ 
+ obj/xbattbar-check-apm.o: xbattbar-check-apm.c obj/stamp
+-  gcc -MMD -D$(OS_TYPE) -o $@ -c $< $(CFLAGS)
++  $(CC) -MMD -D$(OS_TYPE) -o $@ -c $< $(CFLAGS)
+ 
+ obj/stamp:
+   mkdir obj
diff --minimal -Nru xbattbar-1.4.9/debian/patches/series 
xbattbar-1.4.9/debian/patches/series
--- xbattbar-1.4.9/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ xbattbar-1.4.9/debian/patches/series2020-01-02 20:30:24.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru xbattbar-1.4.9/debian/rules xbattbar-1.4.9/debian/rules
--- xbattbar-1.4.9/debian/rules 2019-12-31 11:01:08.0 +0100
+++ xbattbar-1.4.9/debian/rules 2020-01-02 20:29:16.0 +0100
@@ -5,7 +5,7 @@
 
 build-stamp:
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:


Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Olly Betts
Shouldn't this discussion be in bug #922067 (and not Cc-ed to me -
I have no interest in winpdb beyond it having been a blocker for
a wxpython transition over 5 years ago)?

This bug was providing the debdiff for an NMU I did back then.  There's
been a maintainer upload since (1.4.8-3) which incorporated my changes
but missed closing this bug, which Scott recently spotted and tidied up.

Cheers,
Olly



Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Dmitry Shachnev
Hi all,

On Thu, Jan 02, 2020 at 02:53:17PM -0500, Scott Talbert wrote:
> > > It seems like the other choice would be to remove
> > > winpdb from Debian, as Python 2 is going away.
> >
> > As far as I can tell removing is the only option, or somebody needs to
> > take over upstream development.  Not sure, though.
>
> Why don't you give a try to the updated package that Dmitry and I have
> prepared and see if it works well enough for you?  Otherwise, we can RM it.
>
> https://salsa.debian.org/python-team/applications/winpdb

Actually I also saw a warning on the github page and it bothered me.
But I was able to run the tests and they all pass, so I guess it should not
be *that* broken.

I guess we can upload it as is, and if it turns out to be broken, just
remove it from archive. Bernd, does that plan sound fine to you?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#947965: RFS: antimony/0.9.3-1.1 [NMU, RC] -- Computer-aided design CAD tool

2020-01-02 Thread Håvard Flaget Aasen

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: antimony
   Version : 0.9.3-1.1
   Upstream Author :
 * URL : https://github.com/mkeeter/antimony
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/antimony
   Section : graphics

It builds those binary packages:

  antimony - Computer-aided design CAD tool

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/antimony/antimony_0.9.3-1.1.dsc


Changes since the last upload:

   * Non-maintainer upload.
 .
   [ Tiago Bortoletto Vaz ]
   * Add MPL-2.0 notice to debian/copyright.
   * Add Boost license notice to debian/copyright.
 .
   [ Håvard Flaget Aasen ]
   * Explicit build-dependency on dh-python. closes: #947326
   * Use new CMake discovery for python and boost::python. closes: #947479
 - Patch from Ubuntu.
   * This package embeds python3, and is only built against the default
 version. Change build-dependency to python3-dev.
 - Patch from Ubuntu.


This package fails with piupart, but i believe it can be traced back to 
this bug: #897040 in fontconfig. If it makes any difference.


Regards,
Håvard



Bug#947964: gatb-core: hardcoded libcppunit-1.14-0 (and libhdf5-103) dependency instead of shlibs:Depends

2020-01-02 Thread Rene Engelhard
Source: gatb-core
Version: 1.4.1+git20191209.9398f28+dfsg-1
Severity: important

$ cat debian/control
Maintainer: Debian Med Packaging Team 

Uploaders: Nadiya Sitdykova ,
   Andreas Tille 
Section: science
Priority: optional
Build-Depends: debhelper-compat (= 12),
   d-shlibs,
   cmake,
   libcppunit-dev,
   libhdf5-dev,
   libboost-dev,
   libjsoncpp-dev,
   doxygen,
   graphviz
Standards-Version: 4.4.1
Vcs-Browser: https://salsa.debian.org/med-team/gatb-core
Vcs-Git: https://salsa.debian.org/med-team/gatb-core.git
Homepage: https://github.com/GATB/gatb-core

Package: gatb-core
Architecture: any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 libhdf5-103,
 libcppunit-1.14-0
 ^
Description: Genome Analysis Toolbox with de-Bruijn graph
[...]

Why is libcppunit-1.14-0 (and libhdf5-103 fwiw) harcoded and not applied with
${shlibs:Depends}?

At least for cppunit there is now a transition
libcppunit-1.14-0 -> libcppunit-1.15-0 ongoing and because of this the bin-NMUs
didn't have a real effect.

Regards,

Rene



Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Bernd Zeimetz



On 1/2/20 8:53 PM, Scott Talbert wrote:
 take over upstream development.  Not sure, though.
> 
> Why don't you give a try to the updated package that Dmitry and I have
> prepared and see if it works well enough for you?  Otherwise, we can RM it.
> 
> https://salsa.debian.org/python-team/applications/winpdb

I don't really have anything to try it with anymore, but if you say it
works as expected, I'll trust you, perfectly fine for me. Just want to
avoid to have a broken package in bullseye - and I also want to avoid to
have to become upstream for it :)

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#947963: Mouse-pad no longer working

2020-01-02 Thread Daniel Leidert
Package: src:linux
Version: 5.4.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I observe some errors with the new kernel during startup related to i2c*
modules. After booting up the system, the mousepad is not working. These lines
occur during startup and might be important.


[1.575956] i2c_hid i2c-ELAN0511:01: i2c-ELAN0511:01 supply vdd not found, 
using dummy regulator
[1.575963] i2c_hid i2c-ELAN0511:01: i2c-ELAN0511:01 supply vddl not found, 
using dummy regulator
- --
[6.767793] i2c_hid i2c-ELAN0511:01: failed to reset device.
[   11.311539] irq 14: nobody cared (try booting with the "irqpoll" option)
[   11.311556] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.4.0-1-amd64 #1 
Debian 5.4.6-1
[   11.311556] Hardware name: Acer Aspire A717-71G/Charizard_KLS, BIOS V1.21 
11/02/2018
[   11.311557] Call Trace:
[   11.311558]  
[   11.311562]  dump_stack+0x66/0x90
[   11.311564]  __report_bad_irq+0x38/0xad
[   11.311565]  note_interrupt.cold+0xb/0x6e
[   11.311566]  handle_irq_event_percpu+0x72/0x80
[   11.311568]  handle_irq_event+0x3c/0x5c
[   11.311569]  handle_fasteoi_irq+0xa3/0x160
[   11.311570]  do_IRQ+0x53/0xe0
[   11.311572]  common_interrupt+0xf/0xf
[   11.311572]  
[   11.311574] RIP: 0010:cpuidle_enter_state+0xc4/0x450
[   11.311575] Code: e8 71 6b ad ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 
f6 c4 02 0f 85 61 03 00 00 31 ff e8 73 89 b3 ff fb 66 0f 1f 44 00 00 <45> 85 e4 
0f 88 8c 02 00 00 49 63 cc 4c 2b 6c 24 10 48 8d 04 49 48
[   11.311576] RSP: 0018:9a26800f3e68 EFLAGS: 0246 ORIG_RAX: 
ffde
[   11.311577] RAX: 8abb2eaaa6c0 RBX: b9cb90a0 RCX: 001f
[   11.311577] RDX:  RSI: 2d958954 RDI: 
[   11.311577] RBP: 8abb2eab4600 R08: 0002a237001e R09: 0049b27fc738
[   11.311578] R10: 8abb2eaa95a0 R11: 8abb2eaa9580 R12: 0008
[   11.311578] R13: 0002a237001e R14: 0008 R15: 8abb2c52cd80
[   11.311580]  ? cpuidle_enter_state+0x9f/0x450
[   11.311581]  cpuidle_enter+0x29/0x40
[   11.311582]  do_idle+0x1dc/0x270
[   11.311584]  cpu_startup_entry+0x19/0x20
[   11.311585]  start_secondary+0x15f/0x1b0
[   11.311587]  secondary_startup_64+0xa4/0xb0
[   11.311588] handlers:
[   11.311596] [<35ca105c>] intel_gpio_irq
[   11.311606] Disabling IRQ #14
[   12.912243] i2c_hid i2c-ELAN0511:01: failed to reset device.
[   19.056249] i2c_hid i2c-ELAN0511:01: failed to reset device.
[   25.200250] i2c_hid i2c-ELAN0511:01: failed to reset device.
[   26.224249] i2c_hid i2c-ELAN0511:01: can't add hid device: -61
[   26.224662] i2c_hid: probe of i2c-ELAN0511:01 failed with error -61
- --

Everything works well with linux-image-5.3.0-3-amd64.

This issue might be related to #943370. If so please merge these reports.

If you need the full kernel log please tell me.

Regards, Daniel



- -- Package-specific info:
** Version:
Linux version 5.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191130 (Debian 9.2.1-21)) #1 SMP Debian 5.4.6-1 (2019-12-27)

** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-1-amd64 
root=UUID=98c84654-dbce-45dc-a29d-65d3fb83d767 ro quiet

** Not tainted

** Kernel log
[stripped here]

** Model information
sys_vendor: Acer
product_name: Aspire A717-71G
product_version: V1.21
chassis_vendor: Acer
chassis_version: V1.21
bios_vendor: Insyde Corp.
bios_version: V1.21
board_vendor: KBL
board_name: Charizard_KLS
board_version: V1.21

** Loaded modules:
fuse
ctr
ccm
rfcomm
nf_tables
nfnetlink
cmac
snd_hda_codec_hdmi
bnep
intel_rapl_msr
intel_rapl_common
btusb
btrtl
btbcm
btintel
nls_ascii
x86_pkg_temp_thermal
bluetooth
intel_powerclamp
nls_cp437
ath10k_pci
snd_hda_codec_realtek
vfat
kvm_intel
ath10k_core
snd_hda_codec_generic
efi_pstore
fat
ledtrig_audio
ath
kvm
mac80211
snd_hda_intel
uvcvideo
snd_intel_nhlt
irqbypass
snd_hda_codec
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
drbg
intel_cstate
snd_hda_core
videobuf2_common
intel_uncore
cfg80211
efivars
intel_wmi_thunderbolt
snd_hwdep
serio_raw
pcspkr
videodev
intel_rapl_perf
snd_pcm
ansi_cprng
mei_me
iTCO_wdt
rtsx_pci_ms
iTCO_vendor_support
acer_wmi
joydev
sparse_keymap
snd_timer
mei
ecdh_generic
sg
ecc
mc
snd
libarc4
wmi_bmof
rfkill
memstick
watchdog
intel_pch_thermal
tpm_crb
soundcore
tpm_tis
tpm_tis_core
ac
tpm
rng_core
evdev
acpi_pad
acer_wireless
coretemp
parport_pc
sunrpc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
hid_generic
usbhid
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
i915
nouveau
ghash_clmulni_intel
rtsx_pci_sdmmc
mmc_core
mxm_wmi
i2c_designware_platform
ttm
i2c_designware_core
ahci
i2c_algo_bit
libahci
xhci_pci
drm_kms_helper
nvme
xhci_hcd
r8169
i2c_hid
aesni_intel
libata
realtek
drm
libphy
rtsx_pci
crypto_simd
usbcore
cryptd
scsi_mod
glue_helper
nvme_core
i2c_i801
intel_lpss_pci
intel_lpss
hid
idma64
usb_common
mfd_core
fan
battery
wmi
video
button

** PCI devices:
00:00.0 Host 

Bug#947962: ITP: aerc - aerc is an email client for your terminal.

2020-01-02 Thread rajudev
Package: wnpp
Severity: wishlist
Owner: Raju Devidas 
X-Debbugs-CC: debian-de...@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org,

* Package name    : aerc
  Version : 0.3.0
  Upstream Author : Drew Devault
* URL : https://git.sr.ht/~sircmpwn/aerc/
* License : Expat
  Programming Lang: Go
  Description : aerc is an email client for your terminal.
aerc is an email client that runs in your terminal. It's highly
efficient and
extensible, perfect for the discerning hacker. Some of its features include
editing emails in an embedded terminal tmux-style, render HTML emails
with an
interactive terminal web browser, highlight patches with diffs, and
browse with
an embedded less session, Vim-style keybindings and ex-command system,
allowing
for powerful automation at a single keystroke, First-class support for
working
with git & email, Support for multiple accounts, with support for IMAP,
Maildir,
SMTP, and sendmail transfer protocols and many other features.



signature.asc
Description: OpenPGP digital signature


Bug#910529: wrong permissions on /etc/courier/webadmin/password

2020-01-02 Thread Flavio Stanchina

merge 910527 910529
thanks

This bug is seriously annoying, because the permissions get changed back to 
the wrong ones at every upgrade. Maintainer, do you need help on this?


--
Ciao, Flavio

Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer



Bug#947960: gdal: Doesn't build on ports without java

2020-01-02 Thread Samuel Thibault
Hello,

Sebastiaan Couwenberg, le jeu. 02 janv. 2020 20:51:43 +0100, a ecrit:
> as long as the Architecture field doesn't
> support excludes like Build-Depends I'm not willing to apply it.

I agree that the arch list maintenance burden is problematic. Does
anybody know if some effort has been started to enable excludes there?

> Is there a particular reason you want to build gdal on hppa, hurd &
> kfreebsd? Is it blocking any important packages?

It is directly blocking various packages (see attached list), and from
there, by dependency, 81 packages in total on hurd-i386.

> I can't imagine actual users of gdal on those archs, but it may be a
> lack of imagination on my part.

direct users, possibly not indeed, but indirectly you quickly get
packages which can be obstacle to other things, e.g. a positioning
package that would happen to be used by widgets of desktop environments.

Samuel
"cloudcompare"
"epigrass"
"fiona"
"flightgear"
"gdal"
"gmt"
"grass"
"libcitygml"
"libgdal-grass"
"libopencv-imgcodecs3.2"
"libosmium"
"liggghts"
"mapcache"
"ncl"
"odin"
"openorienteering-mapper"
"openscenegraph"
"osgearth"
"osmcoastline"
"otb"
"pdal"
"pgsql-ogr-fdw"
"pktools"
"postgis"
"pyosmium"
"qgis"
"qmapshack"
"rasterio"
"r-cran-rgdal"
"r-cran-sf"
"saga"
"simgear"
"sumo"


Bug#947960: gdal: Doesn't build on ports without java

2020-01-02 Thread Sebastiaan Couwenberg
Control: tags -1 wontfix moreinfo

Hi Samuel,

Thanks for the patch, but as long as the Architecture field doesn't
support excludes like Build-Depends I'm not willing to apply it.
Experience with mapnik has shown that maintaining the list of
architectures manually is a PITA.

I'd rather not have gdal (and everything that depends on it) on those
architectures than deal with manually maintaining the list of
architectures where it's possible to build it.

libgdal-java only has 3 votes in popcon (and no rdeps), so I'd rather
drop that entirely than not build the Java bits on architectures where
openjdk is not available.

Is there a particular reason you want to build gdal on hppa, hurd &
kfreebsd? Is it blocking any important packages? I can't imagine actual
users of gdal on those archs, but it may be a lack of imagination on my
part.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Scott Talbert

On Thu, 2 Jan 2020, Bernd Zeimetz wrote:


On 1/2/20 3:12 PM, Scott Talbert wrote:

On Thu, 2 Jan 2020, Bernd Zeimetz wrote:


upstream's comment to the current winpdb:

I started porting winpdb-reborn to Python 3 / Phoenix but the amount of
effort exceeds my availability. So: WINPDB ON PYTHON 3 IS BUGGY AND NOT
WORKING.

Did you test winpdb with the patches applied here? Does everything work
as expected?

I did not upload a new version as I wanted to keep it out of testing for
that reason, sorry for not stating that in the bug report.


I'm assuming you're talking about my changes in salsa to port to
winpdb-reborn and move to Python 3 (and not my closing of this bug,
which is pretty much unrelated).


I thought 1.4.8 is already from the -reborn fork. Didn't have the time
to investigate further.


Nope, it seems that 1.4.8 is still from the original upstream.


Yes, it does seem to work as best as I can tell, but I'm not really
familiar with winpdb.  I'm just really trying to help the Python 3
porting effort.


Thanks for that!


It seems like the other choice would be to remove
winpdb from Debian, as Python 2 is going away.


As far as I can tell removing is the only option, or somebody needs to
take over upstream development.  Not sure, though.


Why don't you give a try to the updated package that Dmitry and I have 
prepared and see if it works well enough for you?  Otherwise, we can RM 
it.


https://salsa.debian.org/python-team/applications/winpdb

Regards,
Scott

Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)

2020-01-02 Thread Thorsten Glaser
Karel Zak dixit:

>The problem is that with signalfd it's more reliable than when
>classic signals interrupt any syscall, but I have no problem to
>support any #ifdefs for non-signalfd systems.

Thanks!

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)



Bug#947961: dch: DTRT for team uploads

2020-01-02 Thread Nicholas D Steeves
Package: devscripts
Version: 2.19.7~bpo10+1
Severity: wishlist

Hi,

Team-maintained packages seem to be the norm these days, and it would be 
wonderful if dch handled this workflow better.

Debchange/dch chooses upstream_version-x.y (NMU Debian revision) when
one's email address is in neither the Maintainer nor the Uploaders
fields.  Dch --team will do the right thing for the Debian revision,
but the "* Team upload" line it generates shouldn't be used if one of
the Uploaders (or Maintainer for weak team attributed package) or will
be finalising the changelog and uploading.

I wish "dch -r" would detect this case, and that it would add the "*
Team upload" line only under the required specific condition.
Additionally, I wish "dch -i" would query a configurable list of email
addresses for teams that one is part of and DTRT for the Debian
revision.  The combination of these two things would replace "dch
--team".  The downside is it doesn't force the contributor to learn
about these things, but if they read the documentation and configured
the list_of_email_addrs_teams variable then maybe a new contributor
would still learn this?


No rush, but it would be nice to have!
Thank you for your consideration,
Nicholas

-- Package-specific info:

--- /etc/devscripts.conf ---
DEBCHANGE_MULTIMAINT_MERGE=yes

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.19.87 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE (acpi-call?)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.23-1
ii  file  1:5.35-4+deb10u1
ii  gnupg 2.2.12-1+deb10u1
ii  gnupg22.2.12-1+deb10u1
ii  gpgv  2.2.12-1+deb10u1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  curl7.64.0-4
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
pn  equivs  
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.42.0~bpo10+1
ii  man-db  2.8.5-2
ii  patch   2.7.6-3+deb10u1
ii  python3-apt 1.8.4
ii  python3-debian  0.1.35
pn  python3-magic   
ii  python3-requests2.21.0-1
pn  python3-unidiff 
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-23+deb10u1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.10
pn  bls-standalone   
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.6+dfsg1-1+deb10u1
ii  gnuplot-qt [gnuplot] 5.2.6+dfsg1-1+deb10u1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.31-1+b1
ii  mailutils [mailx]1:3.5-3
pn  mozilla-devscripts   
ii  mutt 1.10.1-2.1
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u1
ii  piuparts 1.0.0+deb10u1
pn  postgresql-client

Bug#947960: gdal: Doesn't build on ports without java

2020-01-02 Thread Samuel Thibault
Source: gdal
Version: 2.4.3+dfsg-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

gdal currently doesn't build on ports without java support. The attached
patch fix that: they disable the defaul-jdk-headless and ant build-deps
on non-java ports, they enable the libgdal-java package only on java
ports, pass --with-java to configure only on java ports, and install
java bits only on java ports.

Samuel

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

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
 make
 oops
 make clean
--- debian/control.original 2020-01-01 19:37:51.0 +
+++ debian/control  2020-01-02 02:40:25.0 +
@@ -8,10 +8,10 @@
dh-autoreconf,
dh-python,
d-shlibs,
-   default-jdk-headless,
+   default-jdk-headless [!hppa !hurd-any !kfreebsd-any],
doxygen,
graphviz,
-   ant,
+   ant [!hppa !hurd-any !kfreebsd-any],
chrpath,
libarmadillo-dev,
libcfitsio-dev,
@@ -317,7 +317,7 @@
  GDAL/OGR library.
 
 Package: libgdal-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Section: java
 Depends: ${shlibs:Depends},
  ${misc:Depends}
--- debian/rules.original   2019-11-04 11:53:34.0 +
+++ debian/rules2020-01-02 02:41:59.0 +
@@ -48,6 +48,14 @@
   WITH_HDF5:=
 endif
 
+ifeq (,$(findstring $(DEB_HOST_ARCH), hppa hurd-i386 kfreebsd-i386 
kfreebsd-amd64))
+  WITH_JAVA:=--with-java=/usr/lib/jvm/default-java
+  BINDINGS:=perl java
+else
+  WITH_JAVA:=
+  BINDINGS:=perl
+endif
+
 NJOBS := -j1
 ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS
 NJOBS := -j$(subst parallel=,,$(filter parallel=%,$(subst $(COMMA), 
,$(DEB_BUILD_OPTIONS
@@ -144,7 +152,7 @@
--with-xerces \
--with-zstd \
--with-dods-root=/usr \
-   --with-java=/usr/lib/jvm/default-java \
+   $(WITH_JAVA) \
--with-perl \
--with-python; \
mv GDALmake.opt GDALmake.opt-$$V; \
@@ -155,7 +163,9 @@
$(MAKE) $(NJOBS) lib-target apps-target
rm -rf $(CURDIR)/swig/perl/*.c  $(CURDIR)/swig/perl/*.cpp
$(MAKE) $(NJOBS) -C $(CURDIR)/swig/perl generate build doc
+ifneq ($(WITH_JAVA),)
$(MAKE) $(NJOBS) -C $(CURDIR)/swig/java clean generate build
+endif
 
# It needs pre-installing just after the building due to intermediate 
cleaning.
for V in $(PYVERS); do \
@@ -172,7 +182,7 @@
 
 override_dh_auto_install:
cp `ls GDALmake.opt-*|tail -1` GDALmake.opt
-   $(MAKE) $(NJOBS) install BINDINGS="perl java" 
DESTDIR=$(CURDIR)/debian/tmp
+   $(MAKE) $(NJOBS) install BINDINGS="$(BINDINGS)" 
DESTDIR=$(CURDIR)/debian/tmp
$(MAKE) $(NJOBS) install-docs DESTDIR=$(CURDIR)/debian/tmp \
"INST_DOCS=\$$(prefix)/share/doc/libgdal-doc"\
"INST_MAN=\$$(prefix)/share/man"
@@ -181,15 +191,18 @@
"INST_MAN=\$$(prefix)/share/man"
 
# install python stuff previuosly built and pre-installed
+   install -o root -g root -d $(CURDIR)/debian/tmp/usr/lib
cp -a $(CURDIR)/debian/python-tmp/usr/lib/* 
$(CURDIR)/debian/tmp/usr/lib/.
install -o root -g root -d $(CURDIR)/debian/tmp/usr/bin
install -o root -g root -m 755 $(CURDIR)/swig/python/scripts/*.py 
$(CURDIR)/debian/tmp/usr/bin/.
 
+ifneq ($(WITH_JAVA),)
# java stuff
mkdir -p $(CURDIR)/debian/tmp/usr/share/java 
$(CURDIR)/debian/tmp/usr/lib/jni
install -o root -g root -m 644 $(CURDIR)/swig/java/gdal.jar 
$(CURDIR)/debian/tmp/usr/share/java/.
install -o root -g root -m 644 $(CURDIR)/debian/tmp/usr/lib/*jni.so* 
$(CURDIR)/debian/tmp/usr/lib/jni
rm -f $(CURDIR)/debian/tmp/usr/lib/*jni.so*
+endif
 
# removing useless autogenerated man pages
rm -f $(CURDIR)/debian/tmp/usr/share/man/man1/_*_apps_.1


Bug#762332: marked as done (winpdb: diff for NMU version 1.4.8-2.1)

2020-01-02 Thread Bernd Zeimetz



On 1/2/20 3:12 PM, Scott Talbert wrote:
> On Thu, 2 Jan 2020, Bernd Zeimetz wrote:
> 
>> upstream's comment to the current winpdb:
>>
>> I started porting winpdb-reborn to Python 3 / Phoenix but the amount of
>> effort exceeds my availability. So: WINPDB ON PYTHON 3 IS BUGGY AND NOT
>> WORKING.
>>
>> Did you test winpdb with the patches applied here? Does everything work
>> as expected?
>>
>> I did not upload a new version as I wanted to keep it out of testing for
>> that reason, sorry for not stating that in the bug report.
> 
> I'm assuming you're talking about my changes in salsa to port to
> winpdb-reborn and move to Python 3 (and not my closing of this bug,
> which is pretty much unrelated).

I thought 1.4.8 is already from the -reborn fork. Didn't have the time
to investigate further.

> Yes, it does seem to work as best as I can tell, but I'm not really
> familiar with winpdb.  I'm just really trying to help the Python 3
> porting effort.

Thanks for that!

> It seems like the other choice would be to remove
> winpdb from Debian, as Python 2 is going away.

As far as I can tell removing is the only option, or somebody needs to
take over upstream development.  Not sure, though.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Bug#947915: release-notes: Suggest cleaning up leftover *.dpkg-old etc. config files

2020-01-02 Thread Karl O. Pinc
Hi,

Attached are 2 patches:

cleanup_v2.patch
  This should incorporate all changes discussed so far.

section_v1.patch
  This applies on top of the cleanup patch.  It re-titles
  the 4.2 section and adds sub-sections.  If you want this
  in a separate bug report, discussed elsewhere, etc.,
  please let me know.  (I had it in my brain and wanted
  to get it out.)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index b04a58e2..9cc9f7a4 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -301,6 +301,16 @@ $ apt-forktracer | sort
 It is a good idea to remove obsolete
 packages from your system before upgrading.
   
+  
+A previous upgrade may have left unused copies of configuration
+files; old versions
+of configuration files, versions supplied by the package
+maintainers, etc.  Removing leftover files from previous upgrades
+can avoid confusion.  Find such leftover files with:
+  
+  
+# find /etc -name '*.dpkg-*' '*.ucf-*' '*.merge-error'
+  
 
   
 The proposed-updates section
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 9cc9f7a4..2bff7d03 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -244,7 +244,20 @@
 
 
 
-  Checking APT configuration status
+  Start from "pure" Debian
+  
+Direct upgrades from Debian releases older than 
+() are not supported.  Display your Debian version
+with:
+
+$ cat /etc/debian_version
+
+Please follow
+the instructions in the https://www.debian.org/releases//releasenotes;>Release
+Notes for   to upgrade to 
+ first.
+  
   
 The upgrade process described in this chapter has been designed for
 pure Debian stable systems. If your APT configuration
@@ -254,63 +267,78 @@
 complicating factors.
   
   
-The main configuration file that APT uses to decide what sources it should
-download packages from is /etc/apt/sources.list, but
-it can also use files in the /etc/apt/sources.list.d/
+APT controls what is installed on your system.  The main
+configuration file that APT uses to decide what sources it should
+download packages from is
+/etc/apt/sources.list, but it can also use
+files in the /etc/apt/sources.list.d/
 directory - for details see sources.list(5).
-If your system is using multiple source-list files then you will need to
-ensure they stay consistent.
-  
-  
-Below there are two methods for finding installed packages that
-did not come from Debian, using either
-aptitude or apt-forktracer.  Please
-note that neither of them are 100% accurate  (e.g. the aptitude example
-will list packages that were once provided by Debian but no longer are, such as
-old kernel packages).
-$ aptitude search '~i(!~ODebian)'
-$ apt-forktracer | sort
-  
-  
-  
-Direct upgrades from Debian releases older than  ()
-are not supported.
-Please follow the instructions in the https://www.debian.org/releases//releasenotes;>Release
-Notes for   to upgrade to   first.
+If your system is using multiple source-list files then you will
+need to ensure they stay consistent.
   
-  
-This procedure also assumes your system has been updated to the latest point
-release of .  If you have not done this or are unsure, follow the
-instructions in .
-  
-  
-You should also make sure the package database is ready before proceeding
-with the upgrade. If you are a user of another package manager like
-aptitude or synaptic, review any pending actions. A
-package scheduled for installation or removal
-might interfere with the upgrade procedure. Note that correcting this is
-only possible if your APT source-list files still point to
- and not to
-stable or ; see
-.
-  
-  
-It is a good idea to remove obsolete
-packages from your system before upgrading.
-  
-  
-A previous upgrade may have left unused copies of configuration
-files; old versions
-of configuration files, versions supplied by the package
-maintainers, etc.  Removing leftover files from previous upgrades
-can avoid confusion.  Find such leftover files with:
-  
-  
-# find /etc -name '*.dpkg-*' '*.ucf-*' '*.merge-error'
-  
+
+  
+Remove non-Debian packages
+
+  Below there are two methods for finding installed packages that
+  did not come from Debian, using either
+  aptitude or apt-forktracer.  Please
+  note that neither of them are 100% accurate  (e.g. the aptitude example
+  will list packages that were once provided by Debian but no longer are, such as
+  old kernel packages).
+  $ aptitude search '~i(!~ODebian)'
+  $ apt-forktracer | sort
+
+
+  
+
+  
+Upgrade to latest point release
+
+  This procedure assumes your system has been updated to the latest point
+  release of .  If you have not done this or are 

Bug#947959: octave: Does not build on ports without java support

2020-01-02 Thread Samuel Thibault
Source: octave
Version: 5.1.0-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

octave is currently not getting built on ports which do not have java
support, because it build-depends on default-jdk which is not available
there. The attach changes fix this.

"patch" drops the default-jdk build-depency on those ports, so the
package can be built there.

The "always-build-octave-jar.patch" patch should be removed: since we do
not have a jdk, calling javac can not work anyway.

"patch2" makes sure that on ports without java support, we do not
build the arch:all java-common package. always-build-octave-jar.patch
was meant to make sure that non-java ports still properly build the
octave-common package, but the thing is: they can not, since they do not
have a javac to be run. But at least patch2 makes sure that they do not.
arch:all packages are built by buildds on an amd64 box that has java
support anyway.

Samuel

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

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
How do I type "for i in *.dvi do xdvi i done" in a GUI?
(Discussion in comp.os.linux.misc on the intuitiveness of interfaces.)
--- debian/control.original 2020-01-01 19:10:58.0 +
+++ debian/control  2020-01-01 19:12:14.0 +
@@ -7,7 +7,7 @@
 Build-Depends: automake,
bison,
debhelper-compat (= 12),
-   default-jdk,
+   default-jdk [!hppa !hurd-any !kfreebsd-any],
desktop-file-utils,
dh-exec,
epstool,
--- debian/rules.original   2019-10-30 11:35:16.0 +
+++ debian/rules2020-01-02 00:50:29.0 +
@@ -76,6 +76,12 @@
env OCTAVE=./run-octave debian/tests/builtin-features
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),$(NO_JDK_ARCHS)))
+override_dh_auto_build-indep:
+   # We can not build java-common on these
+   false
+endif
+
 # override normal dh_compress call to avoid compressing .pdf files
 override_dh_compress:
dh_compress --exclude=.pdf


Bug#947653: csv2latex FTCBFS: strips with the wrong strip

2020-01-02 Thread Helmut Grohne
Hi Benoît,

On Sun, Dec 29, 2019 at 05:57:51PM +0100, Benoît Rouits wrote:
> Unfortunately, i cannot sign the new source package due to your
> changelog entry. What is the best way to integrate your patch then ?
> May i change the debian changelog entry with my own message or is there
> a better way to integrate your patch (maybe you should sign the source
> package) ?

Of course you should change the changelog entry. It is still unreleased.
You can use "dch -r" to update the release. Doing so will also change
the final email address to yours. Alternatively, you can edit the text
yourself or only apply the non-changelog portion of my patch and
manually add your changelog. Whatever fits your workflow.

Helmut



Bug#947958: adns FTCBFS: help2man

2020-01-02 Thread Helmut Grohne
Source: adns
Version: 1.5.1-0.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

adns fails to cross build from source, because it uses help2man. In this
case, we can simply rebuild adns for the build architecture to run
help2man. Please consider applying the attached patch or stop using
help2man.

Helmut



Bug#947247: libcln-dev: move cln.pc to a multiarch location

2020-01-02 Thread Helmut Grohne
Hi richy,

On Wed, Jan 01, 2020 at 09:58:20PM +0100, Richard B. Kreckel wrote:
> Hmmm, I have a question: Wouldn't it be more consistent to set $(libdir)
> to /usr/lib//, so the library files are installed there, too,
> not in /usr/lib/?

Yes. I often opt for moving all components to the multiarch libdir.
However in the case of cln, the comment in debian/rules line 70 made me
not go that route:

# This installs into libdir, but we must not set libdir because it affects the 
.la file:

Maybe I didn't properly understand the comment, but it seemed as if we
shouldn't pass --libdir. If that actually works, it should be preferred.
It might even allow marking some packages Multi-Arch: same.

This bug is only concerned with the location of the .pc file though. It
can be solved by only moving it or by moving all files. Whatever suits
you best. I chose the minimally invasive route, because I feared
introducing a regression, but as you figured it adds complexity on its
own.

Helmut



Bug#947957: O: hexxagon -- Hexagonal Ataxx clone

2020-01-02 Thread Michael Piefel
Package: wnpp
Severity: normal

This GTK game is still fun to play and Popcon suggests it is even in use.

Lintian warnings on it mainly because I did not update it in ages. There
is a new upstream, and my guess is the new upstream fixes exactly the
same bugs as the diff in this Debian package did. Upstream is also
virtually dead, so if anyone picks this up, it will take minimal effort
to maintain.



signature.asc
Description: OpenPGP digital signature


Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

2020-01-02 Thread Samuel Thibault
Hello,

Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> the windows that have been opened before activating sleep mode are
> blurry. Newly opened windows are not affected.
> The issue happens with windows from all programs, not just a specific program.
> Moving or resizing the windows does not change the blurry appearance.

Oh, that's very odd. Are you running X or wayland? Better reassign
to either xorg-server or weston. Perhaps also try different desktop
environments to determine in which cases that happens.

Samuel



Bug#947956: duplicity: mega backend fails to create directory

2020-01-02 Thread Jean-Michel Vourgère
Package: duplicity
Version: 0.7.18.2-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

When using mega backend for the first time, the initial directory
creation fails:

> --- Start running command BKP at 18:08:19.874 ---
> 1577988500 ERROR torsocks[13151]: Unable to resolve. Status reply: 4 (in 
> socks5_recv_resolve_reply() at socks5.c:677)
> mkdir: hostname
> Reading globbing filelist /root/.duply/hostname/exclude
> megals: /Root/hostname
> Local and Remote metadata are synchronized, no sync needed.
> megals: /Root/hostname
> Last full backup date: none
> Last full backup is too old, forcing full backup
> Reuse configured PASSPHRASE as SIGN_PASSPHRASE
> megarm: duplicity-full.20200102T180820Z.vol1.difftar.gpg
> megaput: duplicity-full.20200102T180820Z.vol1.difftar.gpg
> Attempt 1 failed. BackendException: Error running 'megaput -u 
> em...@example.net -p mypassword --no-progress --path 
> /Root/hostname/duplicity-full.20200102T180820Z.vol1.difftar.gpg 
> /tmp/duplicity-yolDd8-tempdir/mktemp-idQtpH-2': returned 1, with output:
> 
> ERROR: Upload failed for '/tmp/duplicity-yolDd8-tempdir/mktemp-idQtpH-2': 
> Parent directory doesn't exist: /Root/hostname
> ^C18:08:27.223 Task 'BKP' failed with exit code '4'.

Running megamkdir manually fixes the issue.

This is actually easy to fix, it's just a typo calling _make_dir while
the class function, just above, is named _makedir.

Attached is a patch.

I did check the problem is still present in the development tree.

Thank you

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

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

Versions of packages duplicity depends on:
ii  gnupg 2.2.12-1+deb10u1
ii  libc6 2.28-10
ii  librsync1 0.9.7-10+b1
ii  python2.7.16-1
ii  python-fasteners  0.12.0-3
ii  python-lockfile   1:0.12.2-2

Versions of packages duplicity recommends:
ii  python-oauthlib  2.1.0-1
ii  python-paramiko  2.4.2-0.1
ii  python-pexpect   4.6.0-1
ii  python-urllib3   1.24.1-1
ii  rsync3.1.3-6

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
pn  python-boto 
pn  python-cloudfiles   
pn  python-gdata
pn  python-pip  
pn  python-swiftclient  
pn  tahoe-lafs  

-- no debconf information
--- duplicity/backends/megabackend.py	2020-01-02 18:33:17.129411886 +0100
+++ duplicity/backends/megabackend.py	2020-01-02 19:12:47.004365142 +0100
@@ -94,7 +94,7 @@
 for folder in path:
 p = p + u'/' + folder
 try:
-self._make_dir(p)
+self._makedir(p)
 except:
 pass
 


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


  1   2   3   >