Bug#850993: osmosis: FTBFS: PGHStore.java:36: error: package org.postgresql.util does not exist

[Lucas Nussbaum]

Source: osmosis
Version: 0.45-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_build -- --project-prop osmosisBuildType=RELEASE assemble
>   mkdir -p .gradle/init.d
>   cp /usr/share/gradle-debian-helper/init.gradle .gradle/init.d/
>   gradle --info --console plain --offline --stacktrace --no-daemon 
> --refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
> -Duser.name=debian -Ddebian.package=osmosis --parallel --max-workers=64 
> --project-prop osmosisBuildType=RELEASE assemble
> Initialized native services in: /<>/.gradle/native
> Starting Build
> Compiling initialization script '/<>/.gradle/init.d/init.gradle' 
> using SubsetScriptTransformer.
> Compiling initialization script '/<>/.gradle/init.d/init.gradle' 
> using BuildScriptTransformer.
>   Loading the Maven rules...
> Compiling settings file '/<>/settings.gradle' using 
> SubsetScriptTransformer.
> Compiling settings file '/<>/settings.gradle' using 
> BuildScriptTransformer.
> Settings evaluated using settings file '/<>/settings.gradle'.
>   Settings file found (/<>/settings.gradle), but 
> rootProject.name isn't defined
>   Root project name not defined in settings.gradle, defaulting to 
> 'osmosis' instead of the name of the root directory 'osmosis-0.45'
> Projects loaded. Root project using build file 
> '/<>/build.gradle'.
> Included projects: [root project 'osmosis', project ':build-support', project 
> ':db-server', project ':osmosis-apidb', project ':osmosis-areafilter', 
> project ':osmosis-core', project ':osmosis-dataset', project 
> ':osmosis-extract', project ':osmosis-hstore-jdbc', project 
> ':osmosis-osm-binary', project ':osmosis-pbf', project ':osmosis-pbf2', 
> project ':osmosis-pgsimple', project ':osmosis-pgsnapshot', project 
> ':osmosis-replication', project ':osmosis-replication-http', project 
> ':osmosis-set', project ':osmosis-tagfilter', project 
> ':osmosis-tagtransform', project ':osmosis-testutil', project ':osmosis-xml', 
> project ':package']
>   Keep-alive timer started
>   Adding Debian repository to project 'osmosis'
>   Adding Debian repository to project 'build-support'
>   Adding Debian repository to project 'db-server'
>   Adding Debian repository to project 'osmosis-apidb'
>   Adding Debian repository to project 'osmosis-areafilter'
>   Adding Debian repository to project 'osmosis-core'
>   Adding Debian repository to project 'osmosis-dataset'
>   Adding Debian repository to project 'osmosis-extract'
>   Adding Debian repository to project 'osmosis-hstore-jdbc'
>   Adding Debian repository to project 'osmosis-osm-binary'
>   Adding Debian repository to project 'osmosis-pbf'
>   Adding Debian repository to project 'osmosis-pbf2'
>   Adding Debian repository to project 'osmosis-pgsimple'
>   Adding Debian repository to project 'osmosis-pgsnapshot'
>   Adding Debian repository to project 'osmosis-replication'
>   Adding Debian repository to project 'osmosis-replication-http'
>   Adding Debian repository to project 'osmosis-set'
>   Adding Debian repository to project 'osmosis-tagfilter'
>   Adding Debian repository to project 'osmosis-tagtransform'
>   Adding Debian repository to project 'osmosis-testutil'
>   Adding Debian repository to project 'osmosis-xml'
>   Adding Debian repository to project 'package'
> Parallel execution is an incubating feature.
> Evaluating root project 'osmosis' using build file 
> '/<>/build.gradle'.
> Compiling build file '/<>/build.gradle' using 
> SubsetScriptTransformer.
> Compiling build file '/<>/build.gradle' using 
> BuildScriptTransformer.
> Evaluating project ':build-support' using build file 
> '/<>/build-support/build.gradle'.
> Evaluating project ':db-server' using build file 
> '/<>/db-server/build.gradle'.
> Evaluating project ':osmosis-apidb' using build file 
> '/<>/osmosis-apidb/build.gradle'.
> Compiling build file '/<>/osmosis-apidb/build.gradle' using 
> SubsetScriptTransformer.
> Compiling build file '/<>/osmosis-apidb/build.gradle' using 
> BuildScriptTransformer.
>   Adding task debianMavenPom to project 'osmosis-apidb'
>   Configuring javadoc links
> Evaluating project ':osmosis-areafilter' using build file 
> '/<>/osmosis-areafilter/build.gradle'.
> Compiling build file '/<>/osmosis-areafilter/build.gradle' using 
> Sub

Bug#850994: berkshelf: FTBFS: ERROR: Test "ruby2.3" failed.

[Lucas Nussbaum]

Source: berkshelf
Version: 4.3.5-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> /usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby2.3  
>  │
> └──┘
> 
> fatal: Not a git repository (or any of the parent directories): .git
> GEM_PATH=debian/berkshelf/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
>  ruby2.3 -e gem\ \"berkshelf\"
> 
> ┌──┐
> │ Run tests for ruby2.3 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/berkshelf/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=debian/berkshelf/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
>  ruby2.3 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby2.3 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb --format 
> documentation
> Run options:
>   include {:focus=>true}
>   exclude {:not_supported_on_windows=>false}
> 
> All examples were filtered out; ignoring {:focus=>true}
> 
> Berkshelf::Berksfile
>   ClassMethods
> ::from_file
>   reads the content of the Berksfile and binds them to a new instance
>   returns an instance of Berkshelf::Berksfile
>   when Berksfile does not exist at given path
> raises BerksfileNotFound
>   #cookbook
> sends the add_dependency message with the name, constraint, and options 
> to the instance of the includer
> merges the default options into specified options
> converts a single specified group option into an array of groups
> is a DSL method
> when no constraint specified
>   sends the add_dependency message with a nil value for constraint
> when no options specified
>   sends the add_dependency message with an empty Hash for the value of 
> options
>   #group
> sends the add_dependency message with an array of groups determined by 
> the parameter to the group block
> is a DSL method
>   #metadata
> sends the add_dependency message with an explicit version constraint and 
> the path to the cookbook
> is a DSL method
>   #source
> is a DSL method
> adds a source to the sources
> converts the string to a Source
> adds each source in order they appear
> does not add duplicate entries
> adding an invalid source
>   raises an InvalidSourceURI
>   #sources
> when there are no sources
>   raises an exception
> when there are sources
>   returns an Array
>   contains a collection of Berkshelf::Source
>   #site
> raises a Berkshelf::Deprecated error
> is a DSL method
>   #chef_api
> raises a Berkshelf::Deprecated error
> is a DSL method
>   #extension
> is a DSL method
>   #dependencies
> returns all Berkshelf::Dependencys added to the instance of Berksfile
>   #cookbooks
> raises an exception if a cookbook is not installed
> retrieves the locked (cached) cookbook for each dependency
>   #groups
> returns a hash containing keys for every group a dependency is a member of
> returns an Array of Berkshelf::Dependencys who are members of the group 
> for value
>   #add_dependency
> adds new dependency to the list of dependencies
> is a Berkshelf::Dependency
> has a name matching the given name
> has a version_constraint matching the given constraint
> raises DuplicateDependencyDefined if multiple dependencies of the same 
> name are found
> has a nil location if no location options are provided
> when given the :git option
>   has a GitLocation location
> when given the :github option
>   has a GithubLocation location
> when given the :path option
>   has a PathLocation location
>   #retrieve_locked
> delegates to the lockfile
>   #upload
> validates the lockfile is present
> validates the lockfile is trusted
> validates the dependencies are installed
> creates a new Uploader
>   #vendor
> invo

Bug#850999: seaborn: FTBFS: Test failures

[Lucas Nussbaum]

Source: seaborn
Version: 0.7.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> FAIL: seaborn.tests.test_palettes.TestColorPalettes.test_mpl_reversal
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File 
> "/<>/.pybuild/pythonX.Y_2.7/build/seaborn/tests/test_palettes.py",
>  line 166, in test_mpl_reversal
> nt.assert_equal(pal_forward, pal_reverse[::-1])
> AssertionError: [(0.86168396770472899, 0.91280276816608996, 
> 0.94975778546712808), (0.71146482122260668, 0.80127643214148403, 
> 0.88830449826989621), (0.58998846597462518, 0.67472510572856592, 
> 0.8219915417147251), (0.5490196078431373, 0.49036524413687044, 
> 0.72867358708189156), (0.53788542868127642, 0.30269896193771628, 
> 0.63844675124951944), (0.50943483275663204, 0.084198385236447515, 
> 0.50302191464821222)] != [(0.86168396770472899, 0.91280276816608996, 
> 0.94975778546712808), (0.71146482122260668, 0.80127643214148403, 
> 0.88830449826989621), (0.58998846597462518, 0.67472510572856592, 
> 0.8219915417147251), (0.5490196078431373, 0.49036524413687044, 
> 0.72867358708189156), (0.53788542868127642, 0.30269896193771628, 
> 0.63844675124951944), (0.50943483275663204, 0.084198385236447529, 
> 0.50302191464821222)]
> 
> --
> Ran 419 tests in 101.206s
> 
> FAILED (SKIP=8, failures=2)
> E: pybuild pybuild:276: test: plugin custom failed with: exit code=1: 
> nosetests -s -v /<>/.pybuild/pythonX.Y_2.7/build/
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:28: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/seaborn_0.7.1-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#850998: erlang-ranch: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Lucas Nussbaum]

Source: erlang-ranch
Version: 1.2.1-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>'
>  GENdistclean-asciidoc
> a2x -v -f pdf doc/src/guide/book.asciidoc && mv doc/src/guide/book.pdf 
> doc/guide.pdf
> a2x: ERROR: missing configuration file: 
> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
> a2x: args: ['--dblatex-opts', '-P latex.output.revhistory=0 -P 
> doc.publisher.show=0 -P index.numbered=0', '-d', 'book', '--attribute', 
> 'tabsize=4', '-v', '-f', 'pdf', 'doc/src/guide/book.asciidoc']
> a2x: resource files: []
> a2x: resource directories: ['/etc/asciidoc/images', 
> '/etc/asciidoc/stylesheets']
> a2x: executing: "/usr/bin/asciidoc" --backend docbook -a "a2x-format=pdf"  
> --doctype book --attribute "tabsize=4" --verbose  --out-file 
> "/<>/doc/src/guide/book.xml" 
> "/<>/doc/src/guide/book.asciidoc"
> 
> asciidoc: reading: /etc/asciidoc/asciidoc.conf
> asciidoc: reading: /<>/doc/src/guide/book.asciidoc
> asciidoc: reading: /etc/asciidoc/docbook45.conf
> asciidoc: reading: /etc/asciidoc/filters/source/source-highlight-filter.conf
> asciidoc: reading: /etc/asciidoc/filters/graphviz/graphviz-filter.conf
> asciidoc: reading: /etc/asciidoc/filters/music/music-filter.conf
> asciidoc: reading: /etc/asciidoc/filters/latex/latex-filter.conf
> asciidoc: reading: /etc/asciidoc/filters/code/code-filter.conf
> asciidoc: reading: /etc/asciidoc/lang-en.conf
> asciidoc: writing: /<>/doc/src/guide/book.xml
> asciidoc: include: /<>/doc/src/guide/introduction.asciidoc
> asciidoc: book.asciidoc: line 6: reading: 
> /<>/doc/src/guide/introduction.asciidoc
> asciidoc: include: /<>/doc/src/guide/listeners.asciidoc
> asciidoc: book.asciidoc: line 8: reading: 
> /<>/doc/src/guide/listeners.asciidoc
> asciidoc: include: /<>/doc/src/guide/transports.asciidoc
> asciidoc: book.asciidoc: line 10: reading: 
> /<>/doc/src/guide/transports.asciidoc
> asciidoc: include: /<>/doc/src/guide/protocols.asciidoc
> asciidoc: book.asciidoc: line 12: reading: 
> /<>/doc/src/guide/protocols.asciidoc
> asciidoc: include: /<>/doc/src/guide/embedded.asciidoc
> asciidoc: book.asciidoc: line 14: reading: 
> /<>/doc/src/guide/embedded.asciidoc
> asciidoc: include: /<>/doc/src/guide/parsers.asciidoc
> asciidoc: book.asciidoc: line 16: reading: 
> /<>/doc/src/guide/parsers.asciidoc
> asciidoc: include: /<>/doc/src/guide/ssl_auth.asciidoc
> asciidoc: book.asciidoc: line 18: reading: 
> /<>/doc/src/guide/ssl_auth.asciidoc
> asciidoc: include: /<>/doc/src/guide/internals.asciidoc
> asciidoc: book.asciidoc: line 20: reading: 
> /<>/doc/src/guide/internals.asciidoc
> 
> a2x: executing: "xmllint" --nonet --noout --valid 
> "/<>/doc/src/guide/book.xml"
> 
> 
> erlang.mk:5062: recipe for target 'asciidoc-guide' failed
> make[2]: *** [asciidoc-guide] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/erlang-ranch_1.2.1-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851001: python-restless: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13

[Lucas Nussbaum]

Source: python-restless
Version: 2.0.3-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/it.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/data.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/preparers.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/dj.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/constants.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/pyr.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/utils.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/resources.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/exceptions.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/fl.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/tnd.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> copying restless/serializers.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/restless
> I: pybuild base:184: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/it.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/data.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/preparers.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/dj.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/constants.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/pyr.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/utils.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/resources.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/exceptions.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/fl.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/tnd.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> copying restless/serializers.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/restless
> PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ build/html
> Running Sphinx v1.4.9
> making output directory...
> loading pickled environment... not yet created
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 23 source files that are out of date
> updating environment: 23 added, 0 changed, 0 removed
> reading sources... [  4%] contributing
> reading sources... [  8%] cookbook
> reading sources... [ 13%] extending
> reading sources... [ 17%] index
> reading sources... [ 21%] philosophy
> reading sources... [ 26%] reference/constants
> reading sources... [ 30%] reference/data
> reading sources... [ 34%] reference/exceptions
> reading sources... [ 39%] reference/preparers
> reading sources... [ 43%] reference/resources
> reading sources... [ 47%] reference/serializers
> reading sources... [ 52%] reference/utils
> reading sources... [ 56%] releasenotes/v1.0.0
> reading sources... [ 60%] releasenotes/v1.1.0
> reading sources... [ 65%] releasenotes/v1.2.0
> reading sources... [ 69%] releasenotes/v1.3.0
> reading sources... [ 73%] releasenotes/v1.4.0
> reading sources... [ 78%] releasenotes/v2.0.0
> reading sources... [ 82%] releasenotes/v2.0.1
> reading sources... [ 86%] releasenotes/v2.0.2
> reading sources... [ 91%] releasenotes/v2.0.3
> reading sources... [ 95%] security
> reading sources... [100%] tutorial
> 
> /<>/docs/reference/resources.rst:42: WARNING: autodoc: failed to 
> import module u'restless.it'; the following exception was raised:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 529, in 
> import_object
> __import__(self.modname)
>   File "/<>/restless/it.py", line 3, in 
> import itty
> ImportError: No mod

Bug#850995: graphite2: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Lucas Nussbaum]

Source: graphite2
Version: 1.3.9-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[5]: Entering directory '/<>/build'
> [ 20%] Generating manual.pdf
> cd /<>/build/doc && /usr/bin/a2x -D /<>/build/doc 
> --dblatex-opts="--tmpdir=docbuild" /<>/doc/manual.txt
> a2x: WARNING: --destination-dir option is only applicable to HTML based 
> outputs
> a2x: ERROR: missing configuration file: 
> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
> doc/CMakeFiles/docs.dir/build.make:67: recipe for target 'doc/manual.pdf' 
> failed
> make[5]: *** [doc/manual.pdf] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/graphite2_1.3.9-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851002: ggcov: FTBFS: Test failures

[Lucas Nussbaum]

Source: ggcov
Version: 0.9-13
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> ERROR: (test007) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test008.0) tggcov failed, see log or re-run with -D all,verbose 
> --no-log
> ERROR: (test009) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test010) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test011.1) tggcov failed, see log or re-run with -D all,verbose 
> --no-log
> ERROR: (test013) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test014) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test015.a001) tggcov failed, see log or re-run with -D all,verbose 
> --no-log
> ERROR: (test016.1) tggcov failed, see log or re-run with -D all,verbose 
> --no-log
> PASS: (test021) unit test for libpopt / fakepopt.c
> ERROR: (test029) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test030) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test033) tggcov failed, see log or re-run with -D all,verbose --no-log
> ERROR: (test034) tggcov failed, see log or re-run with -D all,verbose --no-log
> Total: 2/20 tests passed
> debian/rules:34: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/ggcov_0.9-13_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851000: kicad: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Lucas Nussbaum]

Source: kicad
Version: 4.0.4+dfsg2-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[4]: Entering directory '/<>/kicad-4.0.4+dfsg2/debian/build/doc'
> cd /<>/kicad-4.0.4+dfsg2/debian/build/doc/src/cvpcb && 
> /usr/bin/asciidoc -b html5 -a toc2 --section-numbers --theme flask -a\ 
> lang=en -o 
> /<>/kicad-4.0.4+dfsg2/debian/build/doc/src/cvpcb/en/cvpcb.html 
> /<>/kicad-4.0.4+dfsg2/debian/build/doc/src/cvpcb/en/cvpcb.adoc
> a2x: ERROR: missing configuration file: 
> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
> src/gerbview/CMakeFiles/gerbview_pdf_en.dir/build.make:60: recipe for target 
> 'src/gerbview/CMakeFiles/gerbview_pdf_en' failed
> make[4]: *** [src/gerbview/CMakeFiles/gerbview_pdf_en] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/kicad_4.0.4+dfsg2-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851007: ckermit: FTBFS: ld: cannot find -lz

[Lucas Nussbaum]

Source: ckermit
Version: 302-5.2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> gcc -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -o wart ckwart.o 
> -L/usr/kerberos/lib -L/usr/local/ssl/lib -lssl  -lpam -lz -lcrypto 
> -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err  -lncurses -lutil -lresolv -lcrypt  
> -lm
> /usr/bin/ld: cannot find -lz
> collect2: error: ld returned 1 exit status

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/ckermit_302-5.2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851008: qtwebengine-opensource-src: FTBFS: dh_install: missing files, aborting

[Lucas Nussbaum]

Source: qtwebengine-opensource-src
Version: 5.7.1+dfsg-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory 
> '/<>/qtwebengine-opensource-src-5.7.1+dfsg'
> dh_install --fail-missing
> dh_install: usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.la exists in 
> debian/tmp but is not installed to anywhere
> dh_install: usr/lib/x86_64-linux-gnu/libQt5WebEngine.la exists in debian/tmp 
> but is not installed to anywhere
> dh_install: usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.la exists in 
> debian/tmp but is not installed to anywhere
> dh_install: 
> usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_lib_webenginewidgets_private.pri
>  exists in debian/tmp but is not installed to anywhere
> dh_install: 
> usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_lib_webenginecore_private.pri 
> exists in debian/tmp but is not installed to anywhere
> dh_install: 
> usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_lib_webenginecoreheaders_private.pri
>  exists in debian/tmp but is not installed to anywhere
> dh_install: 
> usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_lib_webengine_private.pri 
> exists in debian/tmp but is not installed to anywhere
> dh_install: missing files, aborting
> debian/rules:167: recipe for target 'override_dh_install-arch' failed
> make[1]: *** [override_dh_install-arch] Error 2

The full build log is available from:
   
http://aws-logs.debian.net/2017/01/11/qtwebengine-opensource-src_5.7.1+dfsg-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851005: clementine: FTBFS: chromaprinter.cpp:146:33: error: invalid conversion from 'void*' to 'const int16_t* {aka const short int*}' [-fpermissive]

[Lucas Nussbaum]

Source: clementine
Version: 1.3.1+git240-g1a2f6e2+dfsg-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> cd 
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu/src 
> && /usr/bin/c++   -DBOOST_BIND_NO_PLACEHOLDERS -DQT_CORE_LIB -DQT_DBUS_LIB 
> -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG 
> -DQT_NO_URL_CAST_FROM_STRING -DQT_OPENGL_LIB -DQT_SQL_LIB 
> -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_XML_LIB 
> -I/usr/include/taglib -isystem /usr/include/qt4 -isystem 
> /usr/include/qt4/QtCore -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -isystem 
> /usr/include/qt4/QtOpenGL -isystem /usr/include/qt4/QtGui -isystem 
> /usr/include/qt4/QtDBus -isystem /usr/include/qt4/QtXml -isystem 
> /usr/include/qt4/QtSql -isystem /usr/include/qt4/QtNetwork 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/3rdparty/qsqlite 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu/src
>  -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/../3rdparty/gmock/gtest/include
>  -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/3rdparty/qtsingleapplication
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/3rdparty/qtiocompressor 
> -I/usr/include/qxt/QxtCore -I/usr/include/qxt/QxtGui 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/3rdparty/sha2 
> -I/usr/include/mygpo-qt 
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/ext/libclementine-common
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/ext/libclementine-tagreader
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu/ext/libclementine-tagreader
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/ext/libclementine-remote
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu/ext/libclementine-remote
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/ext/libclementine-spotifyblob
>  
> -I/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/obj-x86_64-linux-gnu/ext/libclementine-spotifyblob
>  -I/usr/include/gpod-1.0 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/libpng16 -I/usr/include/p11-kit-1 -I/usr/include/libusb-1.0  
> -g -O2 
> -fdebug-prefix-map=/<>/clementine-1.3.1+git240-g1a2f6e2+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT -Wdate-time -D_FORTIFY_SOURCE=2 
> -Woverloaded-virtual -Wall -Wno-sign-compare -Wno-deprecated-declarations 
> -Wno-unused-local-typedefs --std=c++0x -U__STRICT_ANSI__ -Werror   -o 
> CMakeFiles/clementine_lib.dir/musicbrainz/chromaprinter.cpp.o -c 
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp:
>  In member function 'QString Chromaprinter::CreateFingerprint()':
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp:146:33:
>  error: invalid conversion from 'void*' to 'const int16_t* {aka const short 
> int*}' [-fpermissive]
>chromaprint_feed(chromaprint, reinterpret_cast<void*>(data.data()),
>  ^~~~
> In file included from 
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp:27:0:
> /usr/include/chromaprint.h:235:21: note:   initializing argument 2 of 'int 
> chromaprint_feed(ChromaprintContext*, const int16_t*, int)'
>  CHROMAPRINT_API int chromaprint_feed(ChromaprintContext *ctx, const int16_t 
> *data, int size);
>  ^~~~
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp:152:58:
>  error: invalid conversion from 'void**' to 'uint32_t** {aka unsigned int**}' 
> [-fpermissive]
>int ret = chromaprint_get_raw_fingerprint(chromaprint, , );
>   ^~~
> In file included from 
> /<>/clementine-1.3.1+git240-g1a2f6e2+dfsg/src/musicbrainz/chromaprinter.cpp:27:0:
> /usr/include/chromaprint.h:273:21: note:   initializing argument 2 of 'int 
> chromaprint_get_raw_fingerprint(ChromaprintContext*, uint32_t**, int*)'
>  CHROMAPRINT_API int chromaprint_get_raw_fingerprint(ChromaprintContext *ctx, 
> uint32_t **fingerprint, int *size);
>  ^~~~

Bug#851009: mixxx: FTBFS: src/musicbrainz/chromaprinter.cpp:62:52: error: invalid conversion from 'void**' to 'uint32_t** {aka unsigned int**}' [-fpermissive]

[Lucas Nussbaum]

Source: mixxx
Version: 2.0.0~dfsg-6
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> g++ -o lin64_build/preferences/dlgpreferencepage.o -c -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -Wextra 
> -g -pthread -O3 -ffast-math -funroll-loops -fomit-frame-pointer 
> -mtune=generic -Damd64 -DMIXXX_BUILD_RELEASE -D'Q_ASSERT(x)=qt_noop()' 
> -D__LINUX__ -D__UNIX__ -DSETTINGS_PATH=\".mixxx/\" 
> -DSETTINGS_FILE=\"mixxx.cfg\" -DUNIX_SHARE_PATH=\"/usr/share/mixxx\" 
> -DUNIX_LIB_PATH=\"/usr/lib/mixxx\" -D__PORTAUDIO__ -DQT_SHARED 
> -DQT_TABLET_SUPPORT -DQT_CORE_LIB -DQT_GUI_LIB -DQT_OPENGL_LIB -DQT_XML_LIB 
> -DQT_SVG_LIB -DQT_SQL_LIB -DQT_SCRIPT_LIB -DQT_NETWORK_LIB -DQT_SHARED 
> -D__SNDFILE__ -D__MAD__ -D__HID__ -D__BULK__ -D__VINYLCONTROL__ 
> -D__SHOUTCAST__ -D__OPUS__ -DDISABLE_BUILDTIME -DHAVE_FFTW3 
> -D__AUTODJCRATES__ -D__SQLITE3__ -Ilin64_build -Isrc 
> -I/usr/include/soundtouch -Ilib/replaygain -I/usr/include/qt4 
> -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
> -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXmlPatterns 
> -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtTest 
> -I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtGui 
> -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtCore 
> -Ilib/gtest-1.7.0/include -Ilib/fidlib-0.9.10 -I/usr/include/taglib 
> -I/usr/include/libusb-1.0 -Ilib/xwax -Ilib/scratchlib -I/usr/include/opus 
> src/preferences/dlgpreferencepage.cpp
> src/musicbrainz/chromaprinter.cpp: In member function 'QString 
> ChromaPrinter::calcFingerPrint(const SoundSourcePointer&)':
> src/musicbrainz/chromaprinter.cpp:62:52: error: invalid conversion from 
> 'void**' to 'uint32_t** {aka unsigned int**}' [-fpermissive]
>  int ret = chromaprint_get_raw_fingerprint(ctx, , );
> ^~~
> In file included from src/musicbrainz/chromaprinter.cpp:1:0:
> /usr/include/chromaprint.h:273:21: note:   initializing argument 2 of 'int 
> chromaprint_get_raw_fingerprint(ChromaprintContext*, uint32_t**, int*)'
>  CHROMAPRINT_API int chromaprint_get_raw_fingerprint(ChromaprintContext *ctx, 
> uint32_t **fingerprint, int *size);
>  ^~~
> src/musicbrainz/chromaprinter.cpp:70:56: error: invalid conversion from 
> 'void*' to 'const uint32_t* {aka const unsigned int*}' [-fpermissive]
> _size, 1);
> ^
> In file included from src/musicbrainz/chromaprinter.cpp:1:0:
> /usr/include/chromaprint.h:331:21: note:   initializing argument 1 of 'int 
> chromaprint_encode_fingerprint(const uint32_t*, int, int, char**, int*, int)'
>  CHROMAPRINT_API int chromaprint_encode_fingerprint(const uint32_t *fp, int 
> size, int algorithm, char **encoded_fp, int *encoded_size, int base64);
>  ^~
> src/musicbrainz/chromaprinter.cpp:69:40: error: invalid conversion from 
> 'void**' to 'char**' [-fpermissive]
> ,
> ^~~~
> In file included from src/musicbrainz/chromaprinter.cpp:1:0:
> /usr/include/chromaprint.h:331:21: note:   initializing argument 4 of 'int 
> chromaprint_encode_fingerprint(const uint32_t*, int, int, char**, int*, int)'
>  CHROMAPRINT_API int chromaprint_encode_fingerprint(const uint32_t *fp, int 
> size, int algorithm, char **encoded_fp, int *encoded_size, int base64);
>  ^~
> /usr/share/qt4/bin/moc -Damd64 -DMIXXX_BUILD_RELEASE 
> -D'Q_ASSERT(x)=qt_noop()' -D__LINUX__ -D__UNIX__ -DSETTINGS_PATH=\".mixxx/\" 
> -DSETTINGS_FILE=\"mixxx.cfg\" -DUNIX_SHARE_PATH=\"/usr/share/mixxx\" 
> -DUNIX_LIB_PATH=\"/usr/lib/mixxx\" -D__PORTAUDIO__ -DQT_SHARED 
> -DQT_TABLET_SUPPORT -DQT_CORE_LIB -DQT_GUI_LIB -DQT_OPENGL_LIB -DQT_XML_LIB 
> -DQT_SVG_LIB -DQT_SQL_LIB -DQT_SCRIPT_LIB -DQT_NETWORK_LIB -DQT_SHARED 
> -D__SNDFILE__ -D__MAD__ -D__HID__ -D__BULK__ -D__VINYLCONTROL__ 
> -D__SHOUTCAST__ -D__OPUS__ -DDISABLE_BUILDTIME -DHAVE_FFTW3 
> -D__AUTODJCRATES__ -D__SQLITE3__ -Ilin64_build -Isrc 
> -I/usr/include/soundtouch -Ilib/replaygain -I/usr/include/qt4 
> -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSvg 
> -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXmlPatterns 
> -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/Qt

Bug#851006: pyregion: FTBFS: Test failures

[Lucas Nussbaum]

Source: pyregion
Version: 1.2-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> pyregion/tests/test_region_numbers.py ...
> pyregion/tests/test_wcs_helper.py .
> 
> == 18 passed in 3.30 seconds 
> ===
> python3 setup.py test
> running test
> Searching for Cython
> Reading https://pypi.python.org/simple/Cython/
> Download error on https://pypi.python.org/simple/Cython/: [SSL: 
> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some 
> packages may not be found!
> Couldn't find index page for 'Cython' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [SSL: 
> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some 
> packages may not be found!
> No local packages or working download links found for Cython
> error: Could not find suitable distribution for Requirement.parse('Cython')
> debian/rules:35: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/pyregion_1.2-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851010: txfixtures: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

[Lucas Nussbaum]

Source: txfixtures
Version: 0.2.5-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build --with python2,python3 --buildsystem=pybuild
>dh_testdir -O--buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py config 
> running config
> I: pybuild base:184: python3.5 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> creating /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted
> copying txfixtures/_twisted/testing.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted
> copying txfixtures/_twisted/threading.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted
> copying txfixtures/_twisted/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted
> creating /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/tests/test_mongodb.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/tests/test_service.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/tests/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/tests/test_phantomjs.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/tests/test_reactor.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/tests
> copying txfixtures/phantomjs.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/tachandler.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/mongodb.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/_testtools.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/osutils.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/service.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> copying txfixtures/reactor.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures
> creating 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted/tests
> copying txfixtures/_twisted/tests/test_threading.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted/tests
> copying txfixtures/_twisted/tests/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/txfixtures/_twisted/tests
> running egg_info
> writing requirements to txfixtures.egg-info/requires.txt
> writing txfixtures.egg-info/PKG-INFO
> writing top-level names to txfixtures.egg-info/top_level.txt
> writing dependency_links to txfixtures.egg-info/dependency_links.txt
> [pbr] Reusing existing SOURCES.txt
> I: pybuild base:184: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> creating /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/tests/test_mongodb.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/tests/test_service.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/tests/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/tests/test_phantomjs.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/tests/test_reactor.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures/tests
> copying txfixtures/phantomjs.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/tachandler.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/mongodb.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/_testtools.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/osutils.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/service.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> copying txfixtures/reactor.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/txfixtures
> creating /<>/

Bug#851011: ocrmypdf: FTBFS: Test failures

[Lucas Nussbaum]

Source: ocrmypdf
Version: 4.3.4-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> Found gs 9.20
> Checking for unpaper >= 6.1...
> Found unpaper 6.1
> Checking for qpdf >= 5.0.0...
> Found qpdf 6.0.0
> running pytest
> Searching for olefile
> Reading https://pypi.python.org/simple/olefile/
> Download error on https://pypi.python.org/simple/olefile/: [SSL: 
> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some 
> packages may not be found!
> Couldn't find index page for 'olefile' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [SSL: 
> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some 
> packages may not be found!
> No local packages or working download links found for olefile
> error: Could not find suitable distribution for Requirement.parse('olefile')
> debian/rules:44: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/ocrmypdf_4.3.4-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851012: asyncpg: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13

[Lucas Nussbaum]

Source: asyncpg
Version: 0.8.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build --with python3 --buildsystem=pybuild
>dh_testdir -O--buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:184: python3.5 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:184: /usr/bin/python3 setup.py build build_ext --cython-always
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/connection.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/_testbase.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/cursor.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/compat.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/introspection.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/prepared_stmt.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/cluster.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/types.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/serverversion.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/transaction.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> copying asyncpg/pool.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg
> running egg_info
> writing asyncpg.egg-info/PKG-INFO
> writing dependency_links to asyncpg.egg-info/dependency_links.txt
> writing top-level names to asyncpg.egg-info/top_level.txt
> asyncpg/protocol/protocol.pyx: cannot find cimported module 'asyncpg.protocol'
> reading manifest file 'asyncpg.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching '*.py' under directory 'examples'
> warning: no files found matching '*.pem' under directory 'tests'
> writing manifest file 'asyncpg.egg-info/SOURCES.txt'
> creating /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/exceptions
> copying asyncpg/exceptions/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/exceptions
> copying asyncpg/exceptions/_base.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/exceptions
> creating /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/__init__.py -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/buffer.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/buffer.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/consts.pxi -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/coreproto.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/coreproto.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/debug.h -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/debug.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/encodings.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/hton.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/pgtypes.pxi -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/prepared_stmt.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/prepared_stmt.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/protocol.c -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/protocol.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/protocol.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/python.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/settings.pxd -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> copying asyncpg/protocol/settings.pyx -> 
> /<>/.pybuild/pythonX.Y_3.5/build/asyncpg/protocol
> creating /&

Bug#851003: python-django-pyscss: FTBFS: Test failures

[Lucas Nussbaum]

Source: python-django-pyscss
Version: 2.0.2-6
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> set -e ; for pyvers in 2.7 3.5; do \
>   echo "===> Testing with python$pyvers" ; \
>   http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9 PYTHON=python$pyvers 
> python$pyvers setup.py test ; \
> done
> ===> Testing with python2.7
> running test
> Searching for olefile
> Reading https://pypi.python.org/simple/olefile/
> Download error on https://pypi.python.org/simple/olefile/: [Errno 111] 
> Connection refused -- Some packages may not be found!
> Couldn't find index page for 'olefile' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [Errno 111] Connection 
> refused -- Some packages may not be found!
> No local packages or working download links found for olefile
> error: Could not find suitable distribution for Requirement.parse('olefile')
> debian/rules:19: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   
http://aws-logs.debian.net/2017/01/11/python-django-pyscss_2.0.2-6_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851021: nikola: FTBFS: pkg_resources.DistributionNotFound: The 'olefile' distribution was not found and is required by Pillow

[Lucas Nussbaum]

Source: nikola
Version: 7.6.4-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> ./debian/nikola.sh init -q debian/dpackaging_site
> Traceback (most recent call last):
>   File "/<>/debian/nikola/usr/bin/nikola", line 6, in 
> from pkg_resources import load_entry_point
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 3019, in 
> @_call_aside
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 3003, in _call_aside
> f(*args, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 3032, in _initialize_master_working_set
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 655, in _build_master
> ws.require(__requires__)
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 963, in require
> needed = self.resolve(parse_requirements(requirements))
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 849, in resolve
> raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'olefile' distribution was not found 
> and is required by Pillow
> debian/rules:25: recipe for target 'override_dh_bash-completion' failed
> make[1]: *** [override_dh_bash-completion] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/nikola_7.6.4-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851022: libpqxx: FTBFS: ./conftest.cpp:43: undefined reference to `PQexec'

[Lucas Nussbaum]

Source: libpqxx
Version: 4.0.1+dfsg2-7
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not 
> for C
> configure:8821: $? = 0
> configure:8834: result: no
> configure:9192: checking for gcc option to produce PIC
> configure:9199: result: -fPIC -DPIC
> configure:9207: checking if gcc PIC flag -fPIC -DPIC works
> configure:9225: gcc -c -g -O2 
> -fdebug-prefix-map=/<>/libpqxx-4.0.1+dfsg2=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC -DPIC -DPIC conftest.c >&5
> configure:9229: $? = 0
> configure:9242: result: yes
> configure:9271: checking if gcc static flag -static works
> configure:9299: result: yes
> configure:9314: checking if gcc supports -c -o file.o
> configure:9335: gcc -c -g -O2 
> -fdebug-prefix-map=/<>/libpqxx-4.0.1+dfsg2=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -o out/conftest2.o conftest.c >&5
> configure:9339: $? = 0
> configure:9361: result: yes
> configure:9369: checking if gcc supports -c -o file.o
> configure:9416: result: yes
> configure:9449: checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) 
> supports shared libraries
> configure:10712: result: yes
> configure:10749: checking whether -lc should be explicitly linked in
> configure:10757: gcc -c -g -O2 
> -fdebug-prefix-map=/<>/libpqxx-4.0.1+dfsg2=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 conftest.c >&5
> configure:10760: $? = 0
> configure:10775: gcc -shared  -fPIC -DPIC conftest.o  -v -Wl,-soname 
> -Wl,conftest -o conftest 2\>\&1 \| /bin/grep  -lc  \>/dev/null 2\>\&1
> configure:10778: $? = 0
> configure:10792: result: no
> configure:10952: checking dynamic linker characteristics
> configure:11533: gcc -o conftest -g -O2 
> -fdebug-prefix-map=/<>/libpqxx-4.0.1+dfsg2=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,-rpath -Wl,/foo conftest.c  
> >&5
> configure:11533: $? = 0
> configure:11782: result: GNU/Linux ld.so
> configure:11904: checking how to hardcode library paths into programs
> configure:11929: result: immediate
> configure:12477: checking whether stripping libraries is possible
> configure:12482: result: yes
> configure:12517: checking if libtool supports shared libraries
> configure:12519: result: yes
> configure:12522: checking whether to build shared libraries
> configure:12547: result: yes
> configure:12550: checking whether to build static libraries
> configure:12554: result: yes
> configure:12577: checking how to run the C++ preprocessor
> configure:12604: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
> configure:12604: $? = 0
> configure:12618: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
> conftest.cpp:23:28: fatal error: ac_nonexistent.h: No such file or directory
>  #include 
> ^
> compilation terminated.
> configure:12618: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "libpqxx"
> | #define PACKAGE_TARNAME "libpqxx"
> | #define PACKAGE_VERSION "4.0.1"
> | #define PACKAGE_STRING "libpqxx 4.0.1"
> | #define PACKAGE_BUGREPORT "Jeroen T. Vermeulen <j...@xs4all.nl>"
> | #define PACKAGE_URL ""
> | #define PACKAGE "libpqxx"
> | #define VERSION "4.0.1"
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_DLFCN_H 1
> | #define LT_OBJDIR ".libs/"
> | /* end confdefs.h.  */
> | #include 
> configure:12643: result: g++ -E
> configure:12663: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
> configure:12663: $? = 0
> configure:12677: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
> conftest.cpp:23:28: fatal error: ac_nonexistent.h: No such file or directory
>  #include 
> ^
> compilation terminated.
> configure:12677: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "libpqxx"
> | #define PACKAGE_TARNAME "libpqxx"
>

Bug#851023: mapbox-vector-tile: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

[Lucas Nussbaum]

Source: mapbox-vector-tile
Version: 0.5.0+ds-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build \
>   --with python2,python3 \
>   --buildsystem=pybuild \
>   --parallel
>dh_testdir -O--buildsystem=pybuild -O--parallel
>dh_update_autotools_config -O--buildsystem=pybuild -O--parallel
>dh_auto_configure -O--buildsystem=pybuild -O--parallel
> I: pybuild base:184: python2.7 setup.py config 
> running config
> I: pybuild base:184: python3.5 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild -O--parallel
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
> running build_py
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/tests
> copying tests/test_encoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/tests
> copying tests/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/tests
> copying tests/test_decoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/tests
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile
> copying mapbox_vector_tile/decoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile
> copying mapbox_vector_tile/encoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile
> copying mapbox_vector_tile/compat.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile
> copying mapbox_vector_tile/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/vector_tile_p3_pb2.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/vector_tile_pb2.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_2.7/build/mapbox_vector_tile/Mapbox
> running egg_info
> creating mapbox_vector_tile.egg-info
> writing requirements to mapbox_vector_tile.egg-info/requires.txt
> writing mapbox_vector_tile.egg-info/PKG-INFO
> writing top-level names to mapbox_vector_tile.egg-info/top_level.txt
> writing dependency_links to mapbox_vector_tile.egg-info/dependency_links.txt
> writing manifest file 'mapbox_vector_tile.egg-info/SOURCES.txt'
> reading manifest file 'mapbox_vector_tile.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'mapbox_vector_tile.egg-info/SOURCES.txt'
> I: pybuild base:184: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/tests
> copying tests/test_encoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/tests
> copying tests/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/tests
> copying tests/test_decoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/tests
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile
> copying mapbox_vector_tile/decoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile
> copying mapbox_vector_tile/encoder.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile
> copying mapbox_vector_tile/compat.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile
> copying mapbox_vector_tile/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile
> creating 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/vector_tile_p3_pb2.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/__init__.py -> 
> /<>/mapbox-vector-tile-0.5.0+ds/.pybuild/pythonX.Y_3.5/build/mapbox_vector_tile/Mapbox
> copying mapbox_vector_tile/Mapbox/vector_tile_pb2.py -> 
> /<>/mapbox-vector-tile-0.5.0

Bug#851024: leap-cli: FTBFS: ERROR: Test "ruby2.3" failed.

[Lucas Nussbaum]

Source: leap-cli
Version: 1.9-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> /usr/bin/ruby2.3 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby2.3  
>  │
> └──┘
> 
> GEM_PATH=debian/leap-cli/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
>  ruby2.3 -e gem\ \"leap_cli\"
> /usr/lib/ruby/2.3.0/rubygems/dependency.rb:319:in `to_specs': Could not find 
> 'faraday' (>= 0.9.1, ~> 0.9) among 22 total gem(s) (Gem::LoadError)
> Checked in 
> 'GEM_PATH=debian/leap-cli/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all',
>  execute `gem env` for more information
>   from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1439:in `block in 
> activate_dependencies'
>   from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1428:in `each'
>   from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1428:in 
> `activate_dependencies'
>   from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1410:in `activate'
>   from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:68:in `block 
> in gem'
>   from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in 
> `synchronize'
>   from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
>   from -e:1:in `'
> base32 (0.3.2)
> bigdecimal (1.2.8)
> capistrano (3.4.0)
> colorize (0.8.1)
> did_you_mean (1.0.0)
> gli (2.14.0)
> i18n (0.7.0)
> io-console (0.4.5)
> json (2.0.1, 1.8.3)
> minitest (5.9.0)
> net-scp (1.2.1)
> net-ssh (3.2.0)
> net-telnet (0.1.1)
> power_assert (0.2.7)
> psych (2.1.0)
> rake (10.5.0)
> rdoc (4.2.1)
> sshkit (1.9.0)
> test-unit (3.1.7)
> ya2yaml (0.31)
> ERROR: Test "ruby2.3" failed.

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/leap-cli_1.9-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851025: eclipse-anyedit: FTBFS: ln: failed to create symbolic link 'swt.jar': File exists

[Lucas Nussbaum]

Source: eclipse-anyedit
Version: 2.4.4-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> jh_compilefeatures --build-opts="-DjavacTarget=1.5 -DjavacSource=1.5 
> -DbuildId=dist -DforceContextQualifier=dist"
> jh_compilefeatures: Compatibility levels before 9 are deprecated (level 8 in 
> use)
> mkdir -p /<>/debian/.eclipse-build/build
> mkdir -p /<>/debian/.eclipse-build/build/home
> mkdir -p /<>/debian/.eclipse-build/build/home/workspace
> Building feature = AnyEditTools.
> Symlinking SDK into /<>/debian/.eclipse-build/build/SDK 
> directory.
> /bin/sh /usr/lib/eclipse/buildscripts/copy-platform 
> /<>/debian/.eclipse-build/build/SDK /usr/lib/eclipse
> ls: cannot access '/usr/lib/eclipse/dropins/jdt/plugins/*': No such file or 
> directory
> ls: cannot access '/usr/lib/eclipse/dropins/jdt/features/*': No such file or 
> directory
> ln: failed to create symbolic link 'icon.xpm': File exists
> ln: failed to create symbolic link 'notice.html': File exists
> ln: failed to create symbolic link 'readme': File exists
> ln: failed to create symbolic link 'swt-gtk-3.8.1.jar': File exists
> ln: failed to create symbolic link 'swt-gtk.jar': File exists
> ln: failed to create symbolic link 'swt.jar': File exists
> Starting build:
> An error has occurred. See the log file
> /<>/debian/.eclipse-build/build/home/workspace/.metadata/.log.
> jh_compilefeatures: cd debian/.eclipse-build && 
> /usr/lib/eclipse/buildscripts/pde-build -a "-DjavacTarget=1.5 
> -DjavacSource=1.5 -DbuildId=dist -DforceContextQualifier=dist"  -f 
> AnyEditTools returned exit code 13
> debian/rules:10: recipe for target 'override_jh_compilefeatures' failed
> make[1]: *** [override_jh_compilefeatures] Error 2

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/eclipse-anyedit_2.4.4-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Lucas Nussbaum]

Source: nut
Version: 2.7.4-4
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[3]: Entering directory '/<>/docs'
> make[3]: Nothing to be done for 'all-am'.
> make[3]: Leaving directory '/<>/docs'
> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts 
> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts 
> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts 
> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images 
> --attribute=badges --attribute=external_title --attribute tree_version=2.7 -a 
> toc -a numbered --destination-dir=. --attribute=chunked_format 
> --format=chunked --xsl-file=./chunked.xsl user-manual.txt
> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts 
> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts 
> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts 
> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images 
> --attribute=badges --attribute=external_title --attribute tree_version=2.7 -a 
> toc -a numbered --destination-dir=. --attribute=chunked_format 
> --format=chunked --xsl-file=./chunked.xsl developer-guide.txt
> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts 
> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts 
> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts 
> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images 
> --attribute=badges --attribute=external_title --attribute tree_version=2.7 -a 
> toc -a numbered --destination-dir=. --attribute=chunked_format 
> --format=chunked --xsl-file=./chunked.xsl packager-guide.txt
> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts 
> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts 
> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts 
> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images 
> --attribute=badges --attribute=external_title --attribute tree_version=2.7 -a 
> toc -a numbered --destination-dir=. --attribute=xhtml11_format --format=xhtml 
> --xsl-file=./xhtml.xsl FAQ.txt
> /usr/bin/a2x  --attribute icons --xsltproc-opts "--nonet" --xsltproc-opts 
> "--stringparam nut.localdate \"`TZ=UTC date +%Y-%m-%d`\"" --xsltproc-opts 
> "--stringparam nut.localtime \"`TZ=UTC date +%H:%M:%S`\"" --xsltproc-opts 
> "--stringparam nut.nutversion \"2.7.4\"" --attribute iconsdir=./images 
> --attribute=badges --attribute=external_title --attribute tree_version=2.7 -a 
> toc -a numbered --destination-dir=. --attribute=pdf_format --format=pdf -a 
> docinfo1 user-manual.txt
> a2x: WARNING: --destination-dir option is only applicable to HTML based 
> outputs
> a2x: ERROR: missing configuration file: 
> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
> Makefile:825: recipe for target 'user-manual.pdf' failed
> make[2]: *** [user-manual.pdf] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/nut_2.7.4-4_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851019: postgis-java: FTBFS: Failed to execute goal on project postgis-jdbc: Could not resolve dependencies for project net.postgis:postgis-jdbc:jar:2.2.1: Cannot access central (https://repo.mave

[Lucas Nussbaum]

Source: postgis-java
Version: 1:2.2.1-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_build --sourcedirectory jdbc
>   /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
>  -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<> 
> -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
> -Dmaven.repo.local=/<>/debian/maven-repo package -DskipTests 
> -Dnotimestamp=true -Dlocale=en_US
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Postgis JDBC Driver 2.2.1
> [INFO] 
> 
> [WARNING] The POM for postgresql:postgresql:jar:9.2.jdbc3 is missing, no 
> dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.131 s
> [INFO] Finished at: 2017-01-10T22:30:13+00:00
> [INFO] Final Memory: 23M/1963M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project postgis-jdbc: Could not resolve 
> dependencies for project net.postgis:postgis-jdbc:jar:2.2.1: Cannot access 
> central (https://repo.maven.apache.org/maven2) in offline mode and the 
> artifact postgresql:postgresql:jar:9.2.jdbc3 has not been downloaded from it 
> before. -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
>  -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<> 
> -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
> -Dmaven.repo.local=/<>/debian/maven-repo package -DskipTests 
> -Dnotimestamp=true -Dlocale=en_US returned exit code 1
> debian/rules:16: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/postgis-java_2.2.1-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851014: python-xmp-toolkit: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

[Lucas Nussbaum]

Source: python-xmp-toolkit
Version: 2.0.1+git20140309.5437b0a-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build  --with python2,python3,sphinxdoc --buildsystem=pybuild
>dh_testdir -O--buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py config 
> running config
> I: pybuild base:184: python3.5 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
> running build_py
> creating 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/utils.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/files.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/exempi.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/core.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/__init__.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/consts.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> copying libxmp/version.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_2.7/build/libxmp
> I: pybuild base:184: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/utils.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/files.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/exempi.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/core.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/__init__.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/consts.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
> copying libxmp/version.py -> 
> /<>/python-xmp-toolkit-2.0.1+git20140309.5437b0a/.pybuild/pythonX.Y_3.5/build/libxmp
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py test 
> running test
> running egg_info
> creating python_xmp_toolkit.egg-info
> writing requirements to python_xmp_toolkit.egg-info/requires.txt
> writing python_xmp_toolkit.egg-info/PKG-INFO
> writing top-level names to python_xmp_toolkit.egg-info/top_level.txt
> writing dependency_links to python_xmp_toolkit.egg-info/dependency_links.txt
> writing manifest file 'python_xmp_toolkit.egg-info/SOURCES.txt'
> reading manifest file 'python_xmp_toolkit.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'python_xmp_toolkit.egg-info/SOURCES.txt'
> running build_ext
> test_jpeg (test.test_roundtrip.TestRoundTrip)
> Create XMP from scratch to store in a jpeg. ... ok
> test_sturm_und_drang (test.test_roundtrip.TestRoundTrip)
> Should be able to write a property which includes umlauts. ... ok
> test_tiff (test.test_roundtrip.TestRoundTrip)
> Write to a TIFF that does not already have the XMP tag. ... ok
> test_3 (test.test_exempi.TestExempi)
> Corresponds to test3.cpp ... ok
> test_bad_formats (test.test_exempi.TestExempi)
> Verify check_file_format on PDF, Adobe Illustrator, XMP. ... skipped 'Issue 
> 26'
> test_bgo (test.test_exempi.TestExempi)
> Corresponds to test-bgo.cpp ... ok
> test_exempi_core (test.test_exempi.TestExempi)
> According to test-exempi-core.cpp ... ok
> test_formats (test.test_exempi.TestExempi)
> Verify that check_file_format function works as expected. ... ok
> test_serialize (test.test_exempi.TestExempi)
> Corresponds to test-serialize.cpp ... ok
> test_tiff_leak (test.test_exempi.TestExempi)
> Corresponds to test-tiff-leak.cpp ... ok
> test_write_new_date_property (test.test_exempi.TestExempi) ... ok
> test_write_new_property (test.test_exempi.TestExempi)
> Corresponds to te

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Lucas Nussbaum]

Source: ffmpeg
Version: 7:3.2.2-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> gcc -Wl,-z,relro -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-z,noexecstack 
> -fPIE -pie -o /tmp/ffconf.9Jhc2enE /tmp/ffconf.c7zBBEYH.o
> /tmp/ffconf.c7zBBEYH.o: In function `main':
> /tmp/ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'
> collect2: error: ld returned 1 exit status

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/ffmpeg_3.2.2-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851016: beets: FTBFS: Test failures

[Lucas Nussbaum]

Source: beets
Version: 1.3.19-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> label: the label
>length: 1.071
>lyrics: the lyrics
>mb_albumid: 9e873859-8aa4-4790-b985-5a953e8ef628
>   mb_artistid: 7cf0ea9d-86b9-4dad-ba9e-2355a64899ea
>mb_trackid: 8b882575-08a5-4452-a7a7-cbb8a1531f9e
> rg_track_gain: 0.0
> rg_track_peak: 0.000244
>samplerate: 44100
> title: full
> track: 2
>tracktotal: 3
>  year: 2001
> 
> error: Test failed:  failures=1>
> debian/rules:12: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/beets_1.3.19-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851018: dpmb: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

[Lucas Nussbaum]

Source: dpmb
Version: 0~2016.06.30
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>'
> echo ":revdate: "$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}"  
> '+%FT%T%:z') > version.adoc
> echo -n ":revnumber: " >> version.adoc; \
> if [ -d .git ] && `which git >/dev/null`; then \
> git describe --tags --always >> version.adoc; \
> elif [ -d debian/changelog ] && `which dpkg-parsechangelog >/dev/null`; then \
> dpkg-parsechangelog | fgrep Version | awk '{print $2}' >> version.adoc; \
> fi
> # There seems to be a bug in the images macro if data-uri is
> a2x  -f pdf -L debian-paketmanagement.adoc
> a2x  -f epub -L debian-paketmanagement.adoc
> # set and images are in subdirectories. Hence we override the
> # original macros with fixed ones.
> asciidoc  -f asciidoc-macros/data-uri-fixup.conf -a data-uri -o 
> debian-paketmanagement.allinone.html debian-paketmanagement.adoc
> asciidoc: WARNING: version.adoc: line 2: 
> {include:/<>/debian-paketmanagement-docinfo.html}: file does not 
> exist
> a2x: ERROR: missing configuration file: 
> /etc/asciidoc/dblatex/asciidoc-dblatex.xsl
> Makefile:32: recipe for target 'debian-paketmanagement.pdf' failed
> make[2]: *** [debian-paketmanagement.pdf] Error 1

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/dpmb_0~2016.06.30_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851020: python-asyncssh: FTBFS: Test failures

[Lucas Nussbaum]

Source: python-asyncssh
Version: 1.8.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> sig = yield from agent_key.sign(b'test')
>   File "/<>/asyncssh/agent.py", line 148, in sign
> data, self._flags))
>   File "/<>/asyncssh/agent.py", line 272, in sign
> raise ValueError('Unable to sign with requested key')
> ValueError: Unable to sign with requested key
> 
> --
> Ran 638 tests in 248.313s
> 
> FAILED (errors=1, skipped=2)
> Test failed: 
> error: Test failed:  failures=0>
> E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1: 
> python3.5 setup.py test 
> dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13
> debian/rules:15: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/python-asyncssh_1.8.1-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851027: python-oslo.middleware: FTBFS: Test failures

[Lucas Nussbaum]

Source: python-oslo.middleware
Version: 3.19.0-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> 
> Traceback (most recent call last):
>   File "oslo_middleware/tests/test_sizelimit.py", line 108, in 
> test_request_too_large_no_content_length
> self.assertEqual(413, response.status_int)
>   File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, in 
> assertEqual
> self.assertThat(observed, matcher, message)
>   File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, in 
> assertThat
> raise mismatch_error
> testtools.matchers._impl.MismatchError: 413 != 200
> 
> 
> --
> Ran 93 tests in 0.771s
> 
> FAILED (failures=1)
> debian/rules:14: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   
http://aws-logs.debian.net/2017/01/11/python-oslo.middleware_3.19.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#851017: sardana: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

[Lucas Nussbaum]

Source: sardana
Version: 2.2.0-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build --with python2,sphinxdoc --buildsystem=pybuild
>dh_testdir -O--buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanameta.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanaevent.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanaexception.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanamanager.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanabase.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanacustomsettings.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanamodulemanager.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanautils.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanaattribute.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanavalue.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/requirements.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanalock.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanadefs.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/release.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanathreadpool.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> copying src/sardana/sardanacontainer.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana
> creating /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolelement.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolpseudomotor.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolonedexpchannel.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/controller.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolbasechannel.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolzerodexpchannel.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolextension.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolobject.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/pooltwodexpchannel.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolmetacontroller.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolmotorgroup.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolioregister.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/pooldefs.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolinstrument.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolgroupelement.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolbaseobject.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolcountertimer.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolacquisition.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolcontrollermanager.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/poolmonitor.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
> copying src/sardana/pool/__init__.py -> 
> /<>/.pybuild/pythonX.Y_2.7/build/sardana/pool
&

Bug#851028: composite: FTBFS: lrdf.h:8:20: fatal error: raptor.h: No such file or directory

[Lucas Nussbaum]

Source: composite
Version: 0.006.2+dfsg0-6
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> cd /<>/composite-0.006.2+dfsg0/obj-x86_64-linux-gnu/src/Tritium && 
> /usr/bin/c++   -DFLAC_SUPPORT -DJACK_SUPPORT -DLADSPA_SUPPORT -DLRDF_SUPPORT 
> -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_XML_LIB -DTritium_EXPORTS 
> -I/<>/composite-0.006.2+dfsg0/obj-x86_64-linux-gnu -isystem 
> /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem 
> /usr/include/qt4/QtXml -isystem /usr/include/qt4/QtCore 
> -I/<>/composite-0.006.2+dfsg0 
> -I/<>/composite-0.006.2+dfsg0/src/Tritium/.  -g -O2 
> -fdebug-prefix-map=/<>/composite-0.006.2+dfsg0=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -fPIC   -o 
> CMakeFiles/Tritium.dir/src/transport/SimpleTransportMaster.o -c 
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/SimpleTransportMaster.cpp
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/JackTransportMaster.cpp:31:2:
>  warning: #warning "JackTransportMaster is **NOT** implemented yet." [-Wcpp]
>  #warning "JackTransportMaster is **NOT** implemented yet."
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/JackTransportMaster.cpp:32:2:
>  warning: #warning "We have not handled the client pointer or set up any 
> callbacks yet." [-Wcpp]
>  #warning "We have not handled the client pointer or set up any callbacks 
> yet."
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/JackTransportMaster.cpp:63:6:
>  warning: #warning "Did we fill out enough stuff?" [-Wcpp]
>  #warning "Did we fill out enough stuff?"
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/JackTransportMaster.cpp:93:6:
>  warning: #warning "Did not check for a jpos.valid & JackPositionBBT" [-Wcpp]
>  #warning "Did not check for a jpos.valid & JackPositionBBT"
>   ^~~
> In file included from 
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/JackTimeMaster.cpp:27:0:
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/../IO/JackClient.hpp:61:6:
>  warning: #warning "TODO: These should be private:" [-Wcpp]
>  #warning "TODO: These should be private:"
>   ^~~
> In file included from 
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackMidiDriver.cpp:26:0:
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackClient.hpp:61:6: 
> warning: #warning "TODO: These should be private:" [-Wcpp]
>  #warning "TODO: These should be private:"
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/SongSequencer.cpp:53:2: 
> warning: #warning "audioEngine_song_sequence_process() does not have any 
> lookahead implemented." [-Wcpp]
>  #warning "audioEngine_song_sequence_process() does not have any lookahead 
> implemented."
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/SongSequencer.cpp:54:2: 
> warning: #warning "audioEngine_song_sequence_process() does not have pattern 
> mode." [-Wcpp]
>  #warning "audioEngine_song_sequence_process() does not have pattern mode."
>   ^~~
> In file included from 
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackClient.cpp:25:0:
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackClient.hpp:61:6: 
> warning: #warning "TODO: These should be private:" [-Wcpp]
>  #warning "TODO: These should be private:"
>   ^~~
> In file included from 
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackOutput.cpp:22:0:
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/IO/JackClient.hpp:61:6: 
> warning: #warning "TODO: These should be private:" [-Wcpp]
>  #warning "TODO: These should be private:"
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/MixerImpl.cpp:141:6: 
> warning: #warning "This is the prosaic approach.  Need an optimized one." 
> [-Wcpp]
>  #warning "This is the prosaic approach.  Need an optimized one."
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport/SimpleTransportMaster.cpp:89:6:
>  warning: #warning "There needs to be input checking here." [-Wcpp]
>  #warning "There needs to be input checking here."
>   ^~~
> /<>/composite-0.006.2+dfsg0/src/Tritium/src/transport

Bug#851032: gnocchi: FTBFS: Test failures

[Lucas Nussbaum]

Source: gnocchi
Version: 3.0.0-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> self.assertThat(observed, matcher, message)
>   File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, in 
> assertThat
> raise mismatch_error
> testtools.matchers._impl.MismatchError: !=:
> reference = [(datetime.datetime(2014, 1, 1, 0, 0, tzinfo=), 
> 86400.0, 55.5),
>  (datetime.datetime(2014, 1, 1, 12, 0, tzinfo=), 3600.0, 55.5),
>  (datetime.datetime(2014, 1, 1, 12, 0, tzinfo=), 300.0, 69),
>  (datetime.datetime(2014, 1, 1, 12, 5, tzinfo=), 300.0, 42.0)]
> actual= []
> 
> 
> --
> Ran 304 tests in 46.735s
> 
> FAILED (failures=44, skipped=24)
> debian/rules:44: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/gnocchi_3.0.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#850855: [rtkit] rtkit daemon fails to start

[Bogdan Vatra]

On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote:
> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote:
> > Hi,
> > 
> > On 10 January 2017 at 16:05, Bogdan Vatra  wrote:
> > > Package: rtkit
> > > Version: 0.11-4
> > > Severity: important
> > > 
> > > --- Please enter the report below this line. ---
> > > 
> > > This bug is pretty annoying because it makes pulseaudio unusable (see
> > > #850806).
> > 
> > > Here are the logs:
> > 
> > 
> > > -- Unit rtkit-daemon.service has begun starting up.
> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system
> > > bus:
> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su
> > 
> > This suggests that dbus is not running. Could that be the case? Do
> > other dbus-interacting apps misbehave?
> 
> I think that's a wrong message ... because :
> 
> $ ls -l /var/run/dbus/system_bus_socket
> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket
> 
> That file exists and dbus works fine (all my KDE/Qt apps works ok).
> 

If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine...
The only problem is when I start it with "systemctl start rtkit-
daemon.service".
I strace it and from the log it seems it succeeds to open dbus socket:
[...]
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 
33) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
fstat(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
getsockname(3, {sa_family=AF_UNIX}, [128->2]) = 0
geteuid()   = 1000
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0AUTH EXTERNAL 
", iov_len=15}, {iov_base="31303030", iov_len=8}, {iov_base="\r
\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", iov_len=28}], msg_iovlen=3, 
msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 51
[...]

BogDan.$ strace systemctl start rtkit-daemon.service
execve("/bin/systemctl", ["systemctl", "start", "rtkit-daemon.service"], [/* 66 vars */]) = 0
brk(NULL)   = 0x55654252d000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fce6f2d
access("/etc/ld.so.preload", R_OK)  = 0
open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)= 0
open("/lib/systemd/tls/x86_64/libsystemd-shared-232.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/systemd/tls/x86_64", 0x7ffe76d74760) = -1 ENOENT (No such file or directory)
open("/lib/systemd/tls/libsystemd-shared-232.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/systemd/tls", 0x7ffe76d74760) = -1 ENOENT (No such file or directory)
open("/lib/systemd/x86_64/libsystemd-shared-232.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/systemd/x86_64", 0x7ffe76d74760) = -1 ENOENT (No such file or directory)
open("/lib/systemd/libsystemd-shared-232.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=2200704, ...}) = 0
mmap(NULL, 2205104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce6ee96000
mmap(0x7fce6f025000, 569344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18e000) = 0x7fce6f025000
mmap(0x7fce6f0b, 1456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce6f0b
close(3)= 0
open("/lib/systemd/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=245391, ...}) = 0
mmap(NULL, 245391, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fce6f294000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340`\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=135448, ...}) = 0
mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fce6ec79000
mprotect(0x7fce6ec91000, 2093056, PROT_NONE) = 0
mmap(0x7fce6ee9, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fce6ee9
mmap(0x7fce6ee92000, 13352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fce6ee92000
close(3)= 0
open("/lib/systemd/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 

Bug#850912: bchunk FTCBFS: uses build arch linker and strip, no -dbgsym package

[Helmut Grohne]

Source: bchunk
Version: 1.2.0-12
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bchunk fails to cross build from source, because it uses the build
architecture linker and strip programs. While debhelper has learned to
pass cross compilers for CC and CXX via the makefile buildsystem used by
dh_auto_build, it doesn't do so for other variables such as LD. Simply
setting 'LD=$(CC)' fixes this part though. Further down the road, bchunk
strips during install and does so using the build architecture strip.
This is bad, because it also breaks the generation of -dbgsym packages.
Thus I propose not stripping during install. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru bchunk-1.2.0/debian/changelog bchunk-1.2.0/debian/changelog
--- bchunk-1.2.0/debian/changelog   2012-03-27 08:44:45.0 +0200
+++ bchunk-1.2.0/debian/changelog   2017-01-10 21:11:16.0 +0100
@@ -1,3 +1,12 @@
+bchunk (1.2.0-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Use triplet-prefixed LD.
++ Do not strip during install.
+
+ -- Helmut Grohne   Tue, 10 Jan 2017 21:11:16 +0100
+
 bchunk (1.2.0-12) unstable; urgency=low
 
   * New maintainer. (Closes: #540585)
diff --minimal -Nru bchunk-1.2.0/debian/rules bchunk-1.2.0/debian/rules
--- bchunk-1.2.0/debian/rules   2012-03-11 07:16:04.0 +0100
+++ bchunk-1.2.0/debian/rules   2017-01-10 21:11:16.0 +0100
@@ -3,5 +3,11 @@
 %:
dh ${@}
 
+override_dh_auto_build:
+   dh_auto_build -- 'LD=$$(CC)'
+
 override_dh_auto_install:
-   $(MAKE) BIN_DIR=$(CURDIR)/debian/bchunk/usr/bin 
MAN_DIR=$(CURDIR)/debian/bchunk/usr/share/man install
+   dh_auto_install -- \
+   INSTALL='install --strip-program=/bin/true' \
+   BIN_DIR=$(CURDIR)/debian/bchunk/usr/bin \
+   MAN_DIR=$(CURDIR)/debian/bchunk/usr/share/man

Bug#850646: [copyright-format] Allow https version of Format URI

[Didier 'OdyX' Raboud]

Le dimanche, 8 janvier 2017, 12.02:38 h CET Russ Allbery a écrit :
> Here's an updated patch that also fixes the other examples.

Seconded.

-- 
Cheers,
OdyX

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

Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,
first best wishes to you all for this new year, health, success ;
especially in you Debian area :) .

I am looking for a sponsor for my package "rear".
This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from 
d/changelog :

rear (2.00+dfsg-1) unstable; urgency=medium

  * New upstream release
  * d/control : move asciidoc to Build-Depends (Closes: #849303)

 -- Frédéric Bonnard   Tue, 10 Jan 2017 15:12:34 
+0100

---

 Package name: rear
 Version : 2.00+dfsg-1
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rear/rear_2.00+dfsg-1.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard



pgpAZPxXp0vRJ.pgp
Description: PGP signature

Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Michael Stapelberg]

Source: piuparts
Severity: wishlist

Thanks for your work on piuparts!

I’m working on manpages.debian.org and recently stumbled across an
interesting problem: many packages use slave alternatives for manpages
(think “vi.1” being linked either to “vim.1” or “nvi.1”).

Unfortunately, alternatives cannot be extracted from a .deb package
easily, as they are maintained by calling update-alternatives(1) from
maintscripts. Hence, a package must be installed in order to know what
alternatives it provides.

Given that piuparts already installs each binary package in Debian, I
was wondering if we could leverage piuparts’s infrastructure so that we
don’t need to re-implement package installation.

Specifically, I’m wondering if you could export the files located in
/var/lib/dpkg/alternatives after each binary package installation.
Naively, I’d suggest something like:

  tar cjf /tmp/export.tar.bz2 -C /var/lib/dpkg/alternatives .

…followed by making /tmp/export.tar.bz2 available as
___alternatives.tar.bz2, e.g.
stretch_vim_2:8.0.0134-1_alternatives.tar.bz2.
The path itself is not important, as long as binary packages are
uniquely identified.

Please consider implementing this feature request. Let me know if this
is something where you’d like some assistance, but it seems to me that
the complexity lies in actually changing piuparts, which is something
where I don’t have any experience.

Thank you very much in advance!

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

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

-- no debconf information

Bug#850921: openjfx version for openjdk 9.0

[shirish शिरीष]

Package: openjfx
Version: 8u111-b14-1
Severity: wishlist

Dear Maintainer,
openjfx stamps out at 8u111-b14-1

> aptitude show openjfx

Package: openjfx
Version: 8u111-b14-1
State: installed
Automatically installed: no
Priority: optional
Section: java
Maintainer: Debian Java Maintainers

Architecture: amd64
Uncompressed Size: 74.8 k
Depends: libopenjfx-java, openjdk-8-jre
Description: JavaFX/OpenJFX 8 - Rich client application platform for Java
 JavaFX/OpenJFX is a set of graphics and media APIs that enables Java
developers to design, create, test, debug, and deploy rich client
applications that operate consistently across diverse platforms.

Homepage: http://openjdk.java.net/projects/openjfx/

whereas openjdk has version 9 as well -

> java -version

openjdk version "9-Debian"
OpenJDK Runtime Environment (build 9-Debian+0-9b151-2)
OpenJDK 64-Bit Server VM (build 9-Debian+0-9b151-2, mixed mode)

> apt-cache policy openjdk-9-jre

openjdk-9-jre:
  Installed: 9~b151-2
  Candidate: 9~b151-2
  Version table:
 *** 9~b151-2 100
100 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

Looking forward to see the package which works with version 9.

While openjdk 9 would be available around the middle of the year from
http://openjdk.java.net/projects/jdk9/

If openjdk 9 is being provided in sid to test out things, it makes
sense to also provide openjfx for that as well.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_IN.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjfx depends on:
ii  libopenjfx-java  8u111-b14-1
ii  openjdk-9-jre9~b151-2

openjfx recommends no packages.

openjfx suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#826148: systemd looses track of service status after it was restarted by monit.

[Sergey B Kirpichev]

tags 826148 -pending +wontfix
thanks

Addition.

On Mon, Jan 09, 2017 at 06:36:46PM +0100, Mario Lipinski wrote:
> >1) monit doesn't support systemd.  If you are ready to support this
> >   package for systemd - please do.
> 
> I just use monit on a Debian system with its default init system. I would
> expect monit to work on such a system. If it does not, this should be noted
> in the documentation and also probably declare appropriate dependencies
> (e.g. to require certain init system or conflict systemd) in the package
> meta information. Not sure whether I missed something in this direction. I
> already proposed a solution that could work on all systems in my initial
> email.

Disclamer: systemd-enabled setups are not tested.  So, if you feel that
there should be direct conflict with systemd - I can add that.  But
in principle, any LSB-compatible init should work.

> >2) "This is not the case when used via monit." - and why it's the monit
> >   problem, but not systemd*?
> 
> I think that this issue could be handled better on the monit side, but feel
> free to forward this to the systemd maintainers.
> 
> I consider the compatibility approach for /etc/init.d (sysvinit) by systemd
> very hackish and thus I would prefer a more general solution to control
> services. According to
> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ calling
> init scripts directly is also discouraged by LSB.

I don't see service command in LSB:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common/rcommands.html
Do I miss something?

> I was talking about using the /usr/sbin/service binary. In #791667 as far as
> I can see only invoke-rc.d was suggested.
> 
> I agree, that maintainer script requirements may not apply to the monit
> configuration, but would strongly encourage you to consider a more general
> solution for controlling services.
> /usr/sbin/service as well as invoke-rc.d (maybe event with --force) seem to
> be alternatives worth considering.

service can run upstart job, for example, instead of init-file.  No, thank you.

The point of code snippets in conf-available - be good starting points
for your local configuration.  If you run upstart job (or run systemd
unit, whatever), but monitor init-file instead - something is deeply wrong.

If you have idea how to provide better examples, that able to work with
different inits - feel free to post a patch.  For now, I believe that
is't better to use LSB-compatible solution (/etc/init.d/foo start|stop -
documented by LSB).

Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Michael Stapelberg]

Thanks for the suggestion. I considered this, but I’m worried this
might blow up the logfiles quite a bit for some packages.

With regards to the suites, I’m interested in oldstable,
oldstable-backports, stable, stable-backports, testing, unstable :).

On Wed, Jan 11, 2017 at 3:33 AM, Andreas Beckmann  wrote:
> Would it be sufficient if that information is just dumped into the
> logfile? In that case a new custom script (maybe only active for a few
> suites) might be sufficient.
>
>
> Andreas
>



-- 
Best regards,
Michael

Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#850657: gnupg: Please 
find gpg-agent on PATH"):
> On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote:
> > gpg executes /usr/bin/gpg-agent, rather than fetching it from the
> > PATH.
> >
> > This is contrary to Debian policy.
> 
> Can you point to the specific part of debian policy that this violates?

I looked for the appropriate part.  debian-policy fails to specify
many aspects of behaviour of programs other than maintainer scripts,
but about maintainer scripts it has this to say:

| Programs called from maintainer scripts should not normally have a
| path prepended to them.
(policy 6.1)

> If you want to pass exciting options to gpg-agent, you can pass them
> directly by launching the agent by hand.  there aren't many contortions
> involved, afaict.  Can you explain what you're trying to do?

I don't think it is fruitful in this bug report to speculate about
other ways of achieving my objective at the time I noticed the bug.
(I disagree that this is a wishlist request.  Absolute paths are a
bug.)

Putting a stunt wrapper of a program on PATH is a well-established
technique for debugging, and for users interfering with and modifying
the behaviour of their systems, and for thingse like test suites.

Of course the system administrator can move the program aside (perhaps
also using dpkg-divert), but that has global effect on the whole
system, while setting PATH has only local impact and requires no
privilege.

> > Please change the package to execute all its programs from PATH.
> 
> this almost certainly won't be done.  for example, if a smarcard is
> present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon ,
> which isn't even in the path.

Sorry, I was unclear.  I meant to limit my request to those programs
which are already on PATH directories, like gpg-agent.

> > Ideally upstream would change too but my experience is that upstreams
> > often don't like this kind of change.
> 
> indeed, they don't like changes that make it more difficult to track
> down problems, [...]

I don't want to have this argument with upstream.  IMO this is just
how we do things in Debian.  In Debian we have reportbug, which is the
right place to address the kind of bug report handling difficulties
you mention.  I have other serious objections to the arguments you
made in that paragraph but I'm hoping we don't have to go there.

I'd like to contrast the reaction to this bug report with that of the
Debian devscripts maintainers in http://bugs.debian.org/850655.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Andreas Beckmann]

On 2017-01-11 12:44, Michael Stapelberg wrote:
> Thanks for the suggestion. I considered this, but I’m worried this
> might blow up the logfiles quite a bit for some packages.

How much "logfile" data would that be? Installing texlive-full in sid
with --install-recommends produces 460 kb, distupgrading it from stable
(without recommends) 700 kb, and there are some packages producing more
output than that.


Andreas

Bug#850922: sosreport displays wrong version when run

[Louis Bouchard]

Package: sosreport
Version: 3.3+git50-g3c0349b-1
Severity: minor

Dear Maintainer,

When running sosreport 3.3, version 3.2 is shown.

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

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

Versions of packages sosreport depends on:
ii  python3-six  1.10.0-3
pn  python3:any  

sosreport recommends no packages.

sosreport suggests no packages.

-- no debconf information

Bug#850037: r-cran-rsqlite: Row value IN queries give syntax errors.

[Kirill Müller]

Thanks. I'm not sure why this was removed, I asked the person who 
changed this. From a maintainer's perspective, using a bundled version 
of SQLite certainly simplifies the replication of problems. I'm in favor 
of keeping things as they are, but I see the benefit of giving the user 
the same SQLite versions for both R and the command line.


Using a system version of SQLite is currently difficult because I'm 
using a patched version of sqlite.h, I might be able to get rid of this 
(https://github.com/rstats-db/RSQLite/issues/198).



-Kirill


On 11.01.2017 09:44, Andreas Tille wrote:

Hi,

I've checked version 1.1-2 but the described problem persists.  I think
Charles solution for the  issue sounds quite promissing.

Kind regards

Andreas.

On Sun, Jan 08, 2017 at 11:45:58PM +0900, Charles Plessy wrote:

After the upgrade from 1.0.0-2 to 1.1-1-1, row value subqueries using IN no 
longer
appear to work.  Here is an example (taken from 
https://www.sqlite.org/rowvalue.html)

Hi Andreas and Kirill,

I was puzzled why version 1.0.0-2 worked, while it was built againt an
even older version of sqlite3, and figured out that until commit 8cdf941
in RSQLite's repository on GitHub, there was a configure script that
accepted the parameter --with-sqlite-dir, which we pass when we build
the r-cran-rsqlite package on Debian to dynamically link the package
against the system's sqlite library.

https://github.com/rstats-db/RSQLite/commit/8cdf941f4e0860be0c0dbafde0a64d1c5e75af72

Would it be possible to have this facility back ?

Have a nice day,

Charles Plessy

PS: Andreas, to make it further complicated, the conversion from CDBS to
dh_r caused the parameter to not be passed...  To correct this, one
needs do delete the dh override and instead add the following line:
export RExtraInstallFlags=--configure-args=--with-sqlite-dir=/usr

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#850904: diffoscope crashes with FileExistsError: [Errno 17] File exists

[Holger Levsen]

On Wed, Jan 11, 2017 at 10:02:33AM +0100, Mattia Rizzolo wrote:
> I already reported it yesterday, and already fixed in git; merging the
> bugs.

cool, thanks!

I seemed to recall something like this, but it was late and so I decided
to just file the bug before going to bed… :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Lefevre]

On 2017-01-11 01:47:53 -0500, Daniel Kahn Gillmor wrote:
> hm, both Vincent and gi1242 are using fvwm.  can you try installing
> openbox or some other comparable minimalist window manager and let me
> know whether you still see the same misbehavior?  it sounds to me like
> y'all might have hit on a combination of tools (fvwm + pinentry-gtk2)
> that don't work well together.

Note that when a Fvwm operation is done (like when the pinentry window
is being opened?), Fvwm may grab the mouse pointer, as documented in
the fvwm(1) man page:

SCRIPTING & COMPLEX FUNCTIONS
   To achieve the more complex effects, fvwm has a number of
   commands that improve its scripting abilities.  Scripts can be
   read from a file with Read, from the output of a command with
   PipeRead or written as a complex function with the AddToFunc
   command.  For the curious, section 7 of the fvwm FAQ shows some
   real life applications of scripting.  Please refer to the
   sections User Functions and Shell Commands and Conditional
   Commands for details.  A word of warning: during execution of
   complex functions, fvwm needs to take all input from the mouse
   pointer (the pointer is "grabbed" in the slang of X).  No other

   programs can receive any input from the pointer while a function
   is run.  This can confuse some programs.  For example, the xwd
   program refuses to make screen shots when run from a complex
   function.  To achieve the same functionality you can use the Read
   or PipeRead command instead.

So, the application may need to wait a little bit instead of failing
immediately (I suppose that the problem is more visible on multicore
machines).

In the /usr/share/doc/pinentry-gtk2/changelog.gz, I can see that they
had problems with keyboard grabbing in general, and for the pointer,
this is newer:

2016-08-02  Justus Winter  

gtk2: Also grab the pointer.
* gtk+-2/pinentry-gtk-2.c (grab_pointer): New function.
(ungrab_keyboard): Rename to 'ungrab_inputs' and also release the
pointer grab.
(create_window): Also grab the pointer.

GnuPG-bug-id: 2430

2016-08-01  Justus Winter  

gtk2: Be more persistent trying to grab the keyboard.
We seem to get the 'visibility-notify' event before X is willing to
let us grab the keyboard, insisting that the target window is not
viewable (sic).

* gtk+-2/pinentry-gtk-2.c (grab_keyboard): Retry grabbing the
keyboard.
[...]

> can you try pinentry-qt as well?  does it have the same problem?

No problems with pinentry-qt, but it does not try to grab the pointer.

> Vincent has been unable to replicate the problem with:
> 
>  * fvwm + pinentry-curses

Same reason: no pointer grab.

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

Bug#850923: criu: backport to jessie fails when linking (ld: -r and -shared may not be used together)

[Alexander Weisse]

Package: criu
Version: 2.9-2
Severity: important

Dear Maintainer,

I was trying to backport criu to jessie following the standard procedure from 
https://wiki.debian.org/SimpleBackportCreation.

Compilation seems to work, but linking fails. Here's part of the output:

...
make[3]: Entering directory '/scratch/debs/criu-2.9'
  GEN  criu/arch/x86/../../include/syscall-codes.h
  GEN  criu/arch/x86/../../include/syscall.h
  GEN  criu/arch/x86/syscalls.S
  DEP  criu/arch/x86/syscalls.d
  GEN  criu/arch/x86/sys-exec-tbl.c
  CC   criu/arch/x86/syscalls.o
  LINK criu/arch/x86/syscalls.built-in.o
ld: -r and -shared may not be used together
/scratch/debs/criu-2.9/scripts/nmk/scripts/build.mk:150: recipe for target 
'criu/arch/x86/syscalls.built-in.o' failed
make[3]: *** [criu/arch/x86/syscalls.built-in.o] Error 1
make[3]: Leaving directory '/scratch/debs/criu-2.9'
criu/Makefile:39: recipe for target 'syscalls_lib' failed
...


Could the problem be related to the applied patch 
0001-build-nmk-Filter-out-Wl-flags-from-linking-builtin-t.patch?
Or to the linking with ld? I can successfully build criu from the github 
sources on the same system.


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

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#850925: coq-highschoolgeometry: FTBFS: Syntax error: [tactic:ltac_use_default] expected after [tactic:tactic] (in [vernac:tactic_command]).

[Chris Lamb]

Source: coq-highschoolgeometry
Version: 8.4+20150620-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

coq-highschoolgeometry fails to build from source in unstable/amd64:

  […]

 dh_auto_configure
 dh_auto_build
make -j1
  make[1]: Entering directory '«BUILDDIR»'
  coqdep -c -glob -slash -R . HighSchoolGeometry "complements_cercle.v" > 
"complements_cercle.v.d" || ( RV=$?; rm -f "complements_cercle.v.d"; exit ${RV} 
)
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "complexes_analytique.v" > 
"complexes_analytique.v.d" || ( RV=$?; rm -f "complexes_analytique.v.d"; exit 
${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "complexes_inversion.v" > 
"complexes_inversion.v.d" || ( RV=$?; rm -f "complexes_inversion.v.d"; exit 
${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "contact.v" > "contact.v.d" || 
( RV=$?; rm -f "contact.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "equations_cercles.v" > 
"equations_cercles.v.d" || ( RV=$?; rm -f "equations_cercles.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "inversion.v" > 
"inversion.v.d" || ( RV=$?; rm -f "inversion.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "puissance_cercle.v" > 
"puissance_cercle.v.d" || ( RV=$?; rm -f "puissance_cercle.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "transformations_contact.v" > 
"transformations_contact.v.d" || ( RV=$?; rm -f "transformations_contact.v.d"; 
exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "vecteur.v" > "vecteur.v.d" || 
( RV=$?; rm -f "vecteur.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "trigo.v" > "trigo.v.d" || ( 
RV=$?; rm -f "trigo.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "similitudes_directes.v" > 
"similitudes_directes.v.d" || ( RV=$?; rm -f "similitudes_directes.v.d"; exit 
${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "Rutile.v" > "Rutile.v.d" || ( 
RV=$?; rm -f "Rutile.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "rotation_plane.v" > 
"rotation_plane.v.d" || ( RV=$?; rm -f "rotation_plane.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "representant_unitaire.v" > 
"representant_unitaire.v.d" || ( RV=$?; rm -f "representant_unitaire.v.d"; exit 
${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "repere_plan.v" > 
"repere_plan.v.d" || ( RV=$?; rm -f "repere_plan.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "repere_ortho_plan.v" > 
"repere_ortho_plan.v.d" || ( RV=$?; rm -f "repere_ortho_plan.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "reflexion_plane.v" > 
"reflexion_plane.v.d" || ( RV=$?; rm -f "reflexion_plane.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "projection_orthogonale.v" > 
"projection_orthogonale.v.d" || ( RV=$?; rm -f "projection_orthogonale.v.d"; 
exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "produit_scalaire.v" > 
"produit_scalaire.v.d" || ( RV=$?; rm -f "produit_scalaire.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "Plans_paralleles.v" > 
"Plans_paralleles.v.d" || ( RV=$?; rm -f "Plans_paralleles.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "Plan_espace.v" > 
"Plan_espace.v.d" || ( RV=$?; rm -f "Plan_espace.v.d"; exit ${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob -slash -R . HighSchoolGeometry "parallelisme_concours.v" > 
"parallelisme_concours.v.d" || ( RV=$?; rm -f "parallelisme_concours.v.d"; exit 
${RV} )
  warning: option -slash has no effect and is deprecated.
  coqdep -c -glob 

Bug#850924: libfltk1.3: not Multi-Arch

[Thorsten Glaser]

Package: libfltk1.3
Version: 1.3.3-8
Severity: normal

libfltk1.3:x32 and libfltk1.3:i386 are not coinstallable
because libfltk1.3 is not Multi-Arch.

This can be a problem because someone™ thought it a good idea
to remove my VNC client and force tigervnc upon people, which
requires libfltk1.3 (and probably has other changes… but that’s
not on topic here), which is annoying when I already use libfltk1.3
for a different architecture.

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libfltk1.3 depends on:
ii  libc6   2.24-8
ii  libfontconfig1  2.11.0-6.7
ii  libgcc1 1:6.3.0-2
ii  libstdc++6  6.3.0-2
ii  libx11-62:1.6.4-2
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1

libfltk1.3 recommends no packages.

libfltk1.3 suggests no packages.

-- no debconf information

Bug#850917: [Piuparts-devel] Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Holger Levsen]

Hi Michael,

thanks for your bug report, this seems like a viable idea to me.

On Wed, Jan 11, 2017 at 09:27:56AM +0100, Michael Stapelberg wrote:
> …followed by making /tmp/export.tar.bz2 available as
> ___alternatives.tar.bz2, e.g.
> stretch_vim_2:8.0.0134-1_alternatives.tar.bz2.

except that the suite should not be part of that filename, but rather be
part of the path, so that next to
https://piuparts.debian.org/stretch/pass/vim_2:8.0.0134-1.log
there would be 
https://piuparts.debian.org/stretch/pass/vim_2:8.0.0134-1.alternatives.tar.bz2

> Please consider implementing this feature request. Let me know if this
> is something where you’d like some assistance, but it seems to me that
> the complexity lies in actually changing piuparts, which is something
> where I don’t have any experience.

yes, we like some assistance as in patches here. First, you'd need to
get piuparts.py to actually produce that tarball and then it needs to be
copied from the slave to the master… (I can probably hint you where the
relevant code lives…)

piuparts maintenance is somewhat understaffed these days… (constant and
onetime) help is much welcome!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#792594: libqt5qml5 requires SSE2 on i386

[Guillem Jover]

Hi!

On Mon, 2017-01-02 at 12:04:50 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> On lunes, 2 de enero de 2017 00:28:22 ART Guillem Jover wrote:
> > > The only thing I would like you to change in order to accept the patch is
> > > to change the generic hasRequiredCpuSupport() for something more precise,
> > > maybe something along cpuHasSse2Support() or alike. Yes, I know it's just
> > > details, but helps while looking at the code.
> > 
> > I think we might have covered this in the past reviews, but in any
> > case I think that would be very confusing, because on non-i386 such
> > cpuHasSse2Support() function would need to return true, which is very
> > much not correct. :) 
> 
> WRT past reviews: I'm pretty sure this must have happened, although maybe I 
> left Dmitry alone with that and so I haven't fully checked. My mistake non 
> the 
> less, I should have checked.

No problem!

> > I've left it as is, but reworked the text message
> > handling so that it's also generic now. Hope that qualms your concerns.
> > 
> > Actually, I didn't like that either, and reworked it even further (v2),
> > but I've not build tested that one yet.
> > 
> > Attached both updated patches, for which I've only built tested the first
> > one for now, but I'd not expect any run-time problems. But I'll try to do
> > that for the second one tomorrow.
> 
> Indeed I also prefer the second one. have you got to check it? I'll start
> preparing the packaging.

I checked it some days ago, but already when the upload had happened,
it obviously built :), so just letting you know it seems to work fine,
thanks!

Regards,
Guillem

Bug#840931: Stale pairing records may be left

[Tino Mettler]

Hi,

is anybody with upload permissions reading this? There are roughly 2
weeks left to upload a fixed package to sid so it can migrate to
testing before the full freeze.  If nobody else does, I'll prepare a
fixed package with the mentioned patches and the removal of stale
pairing entries which can be uploaded by someone with upload
permsissions.  My key (ADA5A11B2B805596C78E9067E806E77FF82155BC) is in
the keyring, so granting upload permissions for me would work, too.

Regards,
Tino


signature.asc
Description: Digital signature

Bug#850926: foremost FTCBFS: important compiler flags cleared during cross builds

[Helmut Grohne]

Source: foremost
Version: 1.5.7-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

foremost fails to cross build from source, because it has a rather
uncommon way to handle the CC variable and its assumptions on CC are
broken by how dh_auto_build uses it. During cross compilation,
dh_auto_build overrides CC with a cross compiler, but foremost stuffs
all sorts of flags into CC. The proper way to cross compile foremost is
overriding RAW_CC and leaving CC alone. The attached patch does just
that. Please consider applying it.

Helmut
diff --minimal -Nru foremost-1.5.7/debian/changelog 
foremost-1.5.7/debian/changelog
--- foremost-1.5.7/debian/changelog 2015-02-23 13:54:58.0 +0100
+++ foremost-1.5.7/debian/changelog 2017-01-11 09:44:00.0 +0100
@@ -1,3 +1,10 @@
+foremost (1.5.7-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Override RAW_CC instead of CC. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 09:44:00 +0100
+
 foremost (1.5.7-6) sid; urgency=low
 
   * Update man page with newly supported format. (Closes: #777260)
diff --minimal -Nru foremost-1.5.7/debian/rules foremost-1.5.7/debian/rules
--- foremost-1.5.7/debian/rules 2014-07-07 15:36:04.0 +0200
+++ foremost-1.5.7/debian/rules 2017-01-11 09:44:00.0 +0100
@@ -4,10 +4,17 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
 
 %:
dh $@
 
+override_dh_auto_build:
+   $(MAKE) RAW_CC='$(CC)'
+
 override_dh_auto_install:
install -D -m 644 foremost.conf 
$(CURDIR)/debian/foremost/etc/foremost.conf
install -D -m 755 foremost $(CURDIR)/debian/foremost/usr/bin/foremost

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Lefevre]

Control: retitle -1 pinentry-gtk-2 frequently fails to grab the pointer under 
fvwm
Control: tags -1 -unreproducible

since it is reproducible with fvwm (now mentioned in the bug title)
and the reason is clearly given in the fvwm(1) man page.

On 2017-01-11 01:47:53 -0500, Daniel Kahn Gillmor wrote:
> Unfortunately, i don't know enough about fvwm and how it might affect
> kbd grabbing to know what the right thing to do here is.

Note that pinentry-gtk-2 and pinentry-qt both grab the keyboard
and are successful in doing it, possibly after several tries,
but this seems to be independent from the window manager:

2016-08-01  Justus Winter  

gtk2: Be more persistent trying to grab the keyboard.
We seem to get the 'visibility-notify' event before X is willing to
let us grab the keyboard, insisting that the target window is not
viewable (sic).

I think that this behavior is expected. Without locking mechanism,
there's a race condition between X and the application. BTW, this
is even mentioned in the Debian changelog (apparently more issues
in the past):

pinentry (0.7.5-2.1) unstable; urgency=low

  * Non-maintainer upload.
  * gtk+-2/pinentry-gtk-2.c: apply patch to avoid keyboard grab race on SMP
systems (closes: #401957).

 -- Pierre Habouzit   Mon, 20 Oct 2008 15:11:18 +0200

What is specific to Fvwm is pointer grabbing, not keyboard grabbing.
And this is where pinentry-gtk-2 fails (CRITICAL instead of WARNING).
I've updated the title of the bug.

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

Bug#850927: pngcrush FTCBFS: uses build architecture linker

[Helmut Grohne]

Source: pngcrush
Version: 1.7.85-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pngcrush fails to cross build from source, because it uses the build
architecture linker. debhelper learned to pass cross compilers for CC
and CXX for the makefile buildsystem recently, but does not override LD
as it cannot know whether to use a C or C++ linker. Thus pngcrush, which
sets LD=gcc, uses the build architecture linker. Setting LD=$(CC) fixes
the cross build. Please consider applying the attached patch.

Helmut
diff --minimal -Nru pngcrush-1.7.85/debian/changelog 
pngcrush-1.7.85/debian/changelog
--- pngcrush-1.7.85/debian/changelog2015-06-04 22:21:43.0 +0200
+++ pngcrush-1.7.85/debian/changelog2017-01-11 11:14:25.0 +0100
@@ -1,3 +1,10 @@
+pngcrush (1.7.85-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Also use triplet-prefixed gcc as LD. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 11:14:25 +0100
+
 pngcrush (1.7.85-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru pngcrush-1.7.85/debian/rules pngcrush-1.7.85/debian/rules
--- pngcrush-1.7.85/debian/rules2015-06-04 22:21:43.0 +0200
+++ pngcrush-1.7.85/debian/rules2017-01-11 11:14:23.0 +0100
@@ -4,7 +4,7 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build
+   dh_auto_build -- 'LD=$$(CC)'
docbook-to-man debian/pngcrush.sgml > pngcrush.1
sed -e '1,/^$$/d' -e '/<\/pre>/,$$d' < ChangeLog.html > changelog
 

Bug#850150: freemat ftbfs with LLVM 3.9

[Graham Inggs]

Control: tags -1 patch

Gianfranco found that in LLVM 3.9, llvm/Target/TargetOptions.h now has:
#include "llvm/MC/MCAsmInfo.h"
which was not present in LLVM 3.8.

I tested the workaround below, which can be used until #850785 is fixed.

--- a/libs/libMatC/CJitFuncClang.hpp
+++ b/libs/libMatC/CJitFuncClang.hpp
@@ -5,6 +5,8 @@
 #include 

 #include "llvm/IR/Function.h"
+/* workaround for Debian bug #850785 */
+#undef X86
 #include "llvm/ExecutionEngine/ExecutionEngine.h"
 #include "llvm/IR/LLVMContext.h"
 #include "clang/Frontend/CompilerInstance.h"

Bug#842198: Fwd: Re: Bug#842198: goobox: Crashes when run in VirtualBox

[Helge Kreutzmann]

reassign 842198 brasero 3.12.1.4
tags 842198 - moreinfo
thanks

Hello Paolo,
hello Brasero maintainers,

Paolo: Thanks for your analysis

Brasero maintainer:
Can you have a look at this bug (#842198) to see why the valid call in
goobox crashes in brasero?

For a cbug reference see below or the complete bug in the BTS.

Greetings & thanks

   helge

On Wed, Jan 11, 2017 at 09:25:15AM +0100, Paolo Bacchilega wrote:
> Il 10/01/2017 19:40, Helge Kreutzmann ha scritto:
> >Hello Paolo,
> >please find the stacktrace below. If you need more/other
> >information, do not hesitate to also contact Jeremy Bicha
> > directly (if you keep 842...@bgus.debian.org in
> >CC, that would be great).
> >
> >Thanks a lot for your help!
> >
> >Greetings
> >
> > Helge
> 
> 
> It seems a problem in brasero, the relevant goobox code just calls
> brasero_drive_unlock on a valid brasero drive, that shouldn't crash.
> 
> - Paolo
> 
> 
> 
> 
> 
> >
> >- Forwarded message from Jeremy Bicha  -
> >
> >>Date: Tue, 10 Jan 2017 13:30:55 -0500
> >>From: Jeremy Bicha 
> >>To: Helge Kreutzmann 
> >>Cc: 842...@bugs.debian.org
> >>Subject: Re: Bug#842198: goobox: Crashes when run in VirtualBox
> >>
> >>On 10 January 2017 at 07:16, Helge Kreutzmann  wrote:
> >>>can you provide a stacktrace?
> >>
> >>See https://launchpad.net/bugs/1636983
> >>
> >>I'm attaching the stacktrace from errors.ubuntu.com . If you need
> >>something different, could you let me know the exact command for me to
> >>enter?
> >>
> >>Thanks,
> >>Jeremy Bicha
> >
> >>https://launchpad.net/bugs/1636983
> >>Stacktrace
> >>
> >>#0  brasero_sense_data_not_ready (err=0x0, sense_data=0x7ffd2c31f2e0 
> >>"\360") at scsi-sense-data.c:118
> >>res = BRASERO_SCSI_FAILURE
> >>#1  brasero_sense_data_process (sense_data=sense_data@entry=0x7ffd2c31f2e0 
> >>"\360", err=err@entry=0x0) at scsi-sense-data.c:210
> >>No locals.
> >>#2  0x7fcb58ac5e7b in brasero_scsi_command_issue_sync 
> >>(command=command@entry=0x555bcefe8950, buffer=buffer@entry=0x0, 
> >>size=size@entry=0, error=error@entry=0x0) at scsi-sg.c:134
> >>sense_buffer = 
> >> "\360\000\002\000\000\000\000\n\000\000\000\000:\000\000\000\000\000"
> >>transport = {interface_id = 83, dxfer_direction = -3, cmd_len = 6 
> >> '\006', mx_sb_len = 19 '\023', iovec_count = 0, dxfer_len = 0, dxferp = 
> >> 0x0, cmdp = 0x555bcefe8950 "\036", sbp = 0x7ffd2c31f2e0 "\360", timeout = 
> >> 0, flags = 0, pack_id = 0, usr_ptr = 0x0, status = 2 '\002', masked_status 
> >> = 1 '\001', msg_status = 0 '\000', sb_len_wr = 18 '\022', host_status = 0, 
> >> driver_status = 8, resid = 0, duration = 12, info = 1}
> >>res = 
> >>cmd = 0x555bcefe8950
> >>__func__ = "brasero_scsi_command_issue_sync"
> >>#3  0x7fcb58ac5cff in brasero_sbc_medium_removal 
> >>(handle=handle@entry=0x555bcef80a20, 
> >>prevent_removal=prevent_removal@entry=0, error=error@entry=0x0) at 
> >>scsi-prevent-allow-medium-removal.c:91
> >>cdb = 0x555bcefe8950
> >>res = 
> >>__func__ = "brasero_sbc_medium_removal"
> >>#4  0x7fcb58ac15eb in brasero_drive_unlock (drive=0x555bcee96de0) at 
> >>brasero-drive.c:565
> >>handle = 0x555bcef80a20
> >>priv = 0x555bcee96d70
> >>device = 
> >>result = 
> >>__func__ = "brasero_drive_unlock"
> >>#5  0x555bce075051 in goo_player_set_state 
> >>(self=self@entry=0x555bcec18c10, state=GOO_PLAYER_STATE_NO_DISC, notify=1) 
> >>at goo-player.c:325
> >>No locals.
> >>#6  0x555bce075b61 in goo_player_update (self=0x555bcec18c10) at 
> >>goo-player.c:569
> >>medium = 
> >>#7  0x555bce078247 in first_time_idle (callback_data=0x555bceebaf90, 
> >>callback_data@entry=) 
> >>at goo-window.c:908
> >>window = 0x555bceebaf90
> >>#8  0x7fcb5692b103 in g_timeout_dispatch (source=0x555bcf0763c0, 
> >>callback=, user_data=) at 
> >>././glib/gmain.c:4672
> >>timeout_source = 0x555bcf0763c0
> >>again = 
> >>#9  0x7fcb5692a68a in g_main_dispatch (context=0x555bceae3ea0) at 
> >>././glib/gmain.c:3201
> >>dispatch = 0x7fcb5692b0f0 
> >>prev_source = 0x0
> >>was_in_call = 0
> >>user_data = 0x555bceebaf90
> >>callback = 0x555bce078220 
> >>cb_funcs = 
> >>cb_data = 0x555bceb00080
> >>need_destroy = 
> >>source = 0x555bcf0763c0
> >>current = 0x555bceb60d20
> >>i = 0
> >>#10 g_main_context_dispatch (context=context@entry=0x555bceae3ea0) at 
> >>././glib/gmain.c:3854
> >>No locals.
> >>#11 0x7fcb5692aa40 in g_main_context_iterate 
> >>(context=context@entry=0x555bceae3ea0, block=block@entry=1, 
> >>dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3927
> >>max_priority = 2147483647
> >>timeout = 1
> >>some_ready = 1
> >>nfds = 3
> >>allocated_nfds = 3
> 

Bug#815259: ITA: libofx -- library to support the Open Financial Exchange format

[Sébastien Villemot]

Le mardi 10 janvier 2017 à 23:08 +0100, Dylan a écrit :

> 2017-01-10 11:23 GMT+01:00 Sébastien Villemot :
> >
> > Yes, your plan sounds good. Please go ahead, and tell me when the upload
> > to unstable is ready.
> >
> 
> I have pushed my commits on the git repository of the team.
> The package seems ready to the upload to unstable.

Thanks, I made the upload.

Just as a reminder, you are left with two tasks:
- asking the ftpmasters to update the override file to reflect your
change in the section of ofx
- forwarding your patch upstream, and updating the DEP-3 fields
accordingly

Best

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#850902: installation-reports: Successful install of 8.6.0 i386 on Toshiba Satellite M115

[Philip Hands]

Daniel Erickson  writes:

> Package: installation-reports
> Severity: wishlist
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>  Converting old Windows XP laptop to Linux. (First time user.)
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Used jigbo to download DVD image.
>* What was the outcome of this action?
>  Couldn't find 32 of the files on the Berkeley, California mirror.
>  Resolved by using the debian us mirror.
>  Successful install from DVD.
>  No way to eject Disk-1 until the install was complete.
>  Installed aditional packages over the internet.

Are you saying that none (or almost none) of the packages came from the
DVD, or just that there were some that were downloaded -- if the latter,
would you happen to know a specific package that was downloaded?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850821: RFS: inkscape-open-symbols/1.0-1

[Adam Borowski]

Control: tag -1 +moreinfo

On Tue, Jan 10, 2017 at 02:38:00PM +0100, Félix Sipma wrote:
> I am looking for a sponsor for my package "inkscape-open-symbols".
>   inkscape-open-symbols - Open source SVG symbol sets that can be used as 
> Inkscape symbols
> 
> Package: inkscape-open-symbols
> Version: 1.0-1
> Upstream Author: Xaviju 
> Homepage: http://github.com/Xaviju/inkscape-open-symbols
> License: GPL-2
> Section: graphics

> dget -x 
> https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.0-1.dsc

While from technical point of view it looks good, I'm afraid there's a
license problem: you're mixing GPL-2 and GPL-3+.  I believe this is not a
problem between symbol sets -- there's mere aggregation without derivation
or linking, but this can't be said for packaging.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#850806: [pulseaudio] pulseaudio hangs in "context_autospawn"

[Bogdan Vatra]

On marți, 10 ianuarie 2017 17:24:59 EET Felipe Sateler wrote:
> Control: retitle -1 pulseaudio: hangs if dbus is malfunctioning
> Control: tags -1 - moreinfo
> 
> On 10 January 2017 at 15:51, Bogdan Vatra  wrote:
> > On marți, 10 ianuarie 2017 20:01:29 EET Bogdan Vatra wrote:
> >> On marți, 10 ianuarie 2017 19:47:44 EET Bogdan Vatra wrote:
> >> > Hi,
> >> > 
> >> > On marți, 10 ianuarie 2017 14:21:02 EET Felipe Sateler wrote:
> >> > > On 10 January 2017 at 12:59, Bogdan Vatra  
wrote:
> >> > > > Hi,
> >> > > > 
> >> > > > Attached, but there is not to much in it ...
> >> > > > 
> >> > > > BTW, immediately aster I'm installing pulseaudio a few (3-4)
> >> > > > instances
> >> > > > are
> >> > > > spawn instantly.
> >> > > 
> >> > > Wow, that hangs pretty fast. I'm guessing it hangs while trying to
> >> > > acquire high-priority scheduling.
> >> > > 
> >> > > The initial bug did not report the architecture, which one it is? Are
> >> > > you using a debian-provided kernel or a custom-built one?
> >> > > 
> >> > > Could you please (after installing pulseaudio-dbgsym), run under gdb
> >> > > and present the trace of where it hangs? Note this is different from
> >> > > the backtrace you already showed, as that is from the client, and we
> >> > > want the one from the server.
> >> > 
> >> > I strace it and judging from the log it doesn't seem to hang.
> >> > Anyway I attached for you the gdb log as you requested.
> >> 
> >> Sorry, I forgot to answer the arch & kernel questions :)
> >> I'm using debian amd64 with debian-provided kernel (I'm way too lazy to
> >> build my own).
> >> 
> >> BogDan.
> > 
> > Ah, I was wrong, it ~hangs (actually it waits 25s for every call) in
> > rtkit_make_high_priority, when it calls
> > dbus_connection_send_with_reply_and_block 
> > and it happens because rtkit fails to start :(
> 
> Right, so it appears the cause is rtkit failing. Still, pulseaudio
> should not hang when rtkit cannot start.
> 
> As a workaround, you might try disabling high-priority and
> realtime-scheduling in /etc/pulse/daemon.conf (although that will
> probably give you suboptimal performance).
> 

I completely removed it, until I figure out whats wrong with rtkit :)

>
> Could you please report this bug upstream at
> https://bugs.freedesktop.org/enter_bug.cgi ?

Done https://bugs.freedesktop.org/show_bug.cgi?id=99356 !

Cheers,
BogDan.

Bug#397507: Debian OpenSSL Bug 397507

[Olaf van der Spek]

2017-01-10 22:09 GMT+01:00 Sebastian Andrzej Siewior :
> On 2017-01-10 21:53:11 [+0100], Olaf van der Spek wrote:
>> >> So why does this file contain "countryName_default = AU"?
>> >> AU doesn't make sense, IMO a better one would be the empty string.
>> >
>> > Why doesn't AU make sense? It is a fictional entry / example which
>> > matches the organization name entry. It ends with "Pty Ltd" which an
>> > Australian business structure.
>>
>> It prevents the user from using an empty string.
>
> Why can't the user hit the backspace twice? Ah because countryName_min
> is set to two. So an empty string in the default config would not help.
>
> What stops you from using a custom config file?

I think that's the wrong question..
It should be as simple as possible.

Why can't the interactive interface allow me to not set country (and
other optional fields)?

-- 
Olaf

Bug#850913: spell FTCBFS: ./configure ignores cmdline CC assignment

[Helmut Grohne]

Source: spell
Version: 1.0-24
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

spell fails to cross build from source, because its ./configure ignores
the CC assignment carefully crafted in the Debian packaging. Passing the
CC variable as an environment variable instead of a command line
variable fixes the cross build. Please consider applying the attached
patch.

Helmut
diff -u spell-1.0/debian/rules spell-1.0/debian/rules
--- spell-1.0/debian/rules
+++ spell-1.0/debian/rules
@@ -23,7 +23,7 @@
 config.status: configure patch-stamp
dh_testdir
 
-   CFLAGS="$(CFLAGS)" ./configure $(CROSS) --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
+   CFLAGS="$(CFLAGS)" $(CROSS) ./configure --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
 
 build: build-stamp
 build-stamp: config.status
diff -u spell-1.0/debian/changelog spell-1.0/debian/changelog
--- spell-1.0/debian/changelog
+++ spell-1.0/debian/changelog
@@ -1,3 +1,10 @@
+spell (1.0-24.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CC via environment (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 09:12:54 +0100
+
 spell (1.0-24) unstable; urgency=low
 
   * Support also aspell (Closes: #381511)

Bug#850916: xzgv FTCBFS: uses build architecture build tools (gcc, pkg-config)

[Helmut Grohne]

Source: xzgv
Version: 0.9.1-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xzgv fails to cross build from source, because it uses build
architecture build tools. Simply adding the host architecture triplet as
a prefix to gcc and pkg-config fixes the cross build. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru xzgv-0.9.1/debian/changelog xzgv-0.9.1/debian/changelog
--- xzgv-0.9.1/debian/changelog 2016-08-15 05:16:31.0 +0200
+++ xzgv-0.9.1/debian/changelog 2017-01-11 09:23:36.0 +0100
@@ -1,3 +1,10 @@
+xzgv (0.9.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use triplet-prefixed build tools (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 09:23:36 +0100
+
 xzgv (0.9.1-4) unstable; urgency=medium
 
   * Make the build be reproducible (Closes: #777274)
diff --minimal -Nru xzgv-0.9.1/debian/rules xzgv-0.9.1/debian/rules
--- xzgv-0.9.1/debian/rules 2016-08-15 05:09:49.0 +0200
+++ xzgv-0.9.1/debian/rules 2017-01-11 09:23:34.0 +0100
@@ -11,13 +11,20 @@
 
 PATH=/bin:/usr/bin:/usr/sbin
 
+include /usr/share/dpkg/architecture.mk
+
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
 LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)
 
-CFLAGS += `pkg-config --cflags gtk+-2.0` `pkg-config --cflags gdk-pixbuf-2.0` \
-   `pkg-config --cflags x11`
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
+PKG_CONFIG := $(DEB_HOST_GNU_TYPE)-pkg-config
+
+CFLAGS += `$(PKG_CONFIG) --cflags gtk+-2.0` `$(PKG_CONFIG) --cflags 
gdk-pixbuf-2.0` \
+   `$(PKG_CONFIG) --cflags x11`
 LDFLAGS += -lgtk-x11-2.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 
-lglib-2.0 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lglib-2.0 -lX11 -lm
 
 configure: debian/configure-stamp
@@ -36,7 +43,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) CFLAGS="$(CPPFLAGS) $(CFLAGS)" LDFLAGS="$(LDFLAGS)" GZIP=-9n 
all info
+   $(MAKE) CC="$(CC)" CFLAGS="$(CPPFLAGS) $(CFLAGS)" LDFLAGS="$(LDFLAGS)" 
GZIP=-9n all info
 
touch $@
 

Bug#850920: cabal-debian fails to detect GHC built-in packages

[Kei Hibino]

Package: cabal-debian
Version: 4.33-4
Severity: important
Tags: patch

Dear Maintainer,

I made example sequence of cabal-debian like following.
Build-depends lines are generated by cabal-debian
like 'libghc-base-dev (<< 5)' and 'libghc-base-prof (<< 5)',
but 'base' is GHC built-in package which provided by
'ghc' debian package. So these version constraints are wrong.
It is not expected that version constraints are produced
with built-in packages.

--
$ cabal unpack time-locale-compat-0.1.1.3
Unpacking to time-locale-compat-0.1.1.3/
$ cd time-locale-compat-0.1.1.3
$ tail -21 time-locale-compat.cabal | head -3

  build-depends: base <5

$ cabal-debian
$ head -12 debian/control
Source: haskell-time-locale-compat
Maintainer: Debian Haskell Group 

Priority: extra
Section: haskell
Build-Depends: debhelper (>= 10),
 haskell-devscripts (>= 0.8),
 cdbs,
 ghc,
 ghc-prof,
 libghc-base-dev (<< 5),
 libghc-base-prof (<< 5),
 libghc-old-locale-dev,
--

I made a small patch to fix this problem like following.

--
--- cabal-debian-4.33.orig/src/Debian/Debianize/Bundled.hs  2016-10-07 
04:13:42.0 +0900
+++ cabal-debian-4.33/src/Debian/Debianize/Bundled.hs   2017-01-09 
21:43:40.231080418 +0900
@@ -105,7 +105,7 @@
 lns = lines $ unsafePerformIO (chroot root (readProcess "dpkg" 
["-L", unBinPkgName hcname] ""))
 parseLib :: String -> Maybe PackageIdentifier
 parseLib s =
-case s =~ ("(.*)-([0-9.]*)-(.*).conf$") :: (String, 
String, String, [String]) of
+case s =~ ("(.*)-([0-9.]*)(-.*)?.conf$") :: (String, 
String, String, [String]) of
   (_, _, _, [cabalName, ver, _sum]) ->
   case parseVersion' ver of
 Just v -> Just (PackageIdentifier (PackageName 
cabalName) v)

--


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/40 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cabal-debian depends on:
ii  debhelper   10.2.3
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.24-8
ii  libffi6 3.2.1-6
ii  libgmp102:6.1.2+dfsg-1
ii  zlib1g  1:1.2.8.dfsg-4

Versions of packages cabal-debian recommends:
ii  apt-file  3.1.3

cabal-debian suggests no packages.

-- no debconf information

Bug#850037: r-cran-rsqlite: Row value IN queries give syntax errors.

[Andreas Tille]

Hi,

I've checked version 1.1-2 but the described problem persists.  I think
Charles solution for the  issue sounds quite promissing.

Kind regards

   Andreas.

On Sun, Jan 08, 2017 at 11:45:58PM +0900, Charles Plessy wrote:
> > > 
> > > After the upgrade from 1.0.0-2 to 1.1-1-1, row value subqueries using IN 
> > > no longer
> > > appear to work.  Here is an example (taken from 
> > > https://www.sqlite.org/rowvalue.html)
> 
> Hi Andreas and Kirill,
> 
> I was puzzled why version 1.0.0-2 worked, while it was built againt an
> even older version of sqlite3, and figured out that until commit 8cdf941
> in RSQLite's repository on GitHub, there was a configure script that
> accepted the parameter --with-sqlite-dir, which we pass when we build
> the r-cran-rsqlite package on Debian to dynamically link the package
> against the system's sqlite library.
> 
> https://github.com/rstats-db/RSQLite/commit/8cdf941f4e0860be0c0dbafde0a64d1c5e75af72
> 
> Would it be possible to have this facility back ?
> 
> Have a nice day,
> 
> Charles Plessy
> 
> PS: Andreas, to make it further complicated, the conversion from CDBS to
> dh_r caused the parameter to not be passed...  To correct this, one
> needs do delete the dh override and instead add the following line:
> export RExtraInstallFlags=--configure-args=--with-sqlite-dir=/usr
> 
> -- 
> Charles Plessy
> Debian Med packaging team,
> http://www.debian.org/devel/debian-med
> Tsurumi, Kanagawa, Japan
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#850904: diffoscope crashes with FileExistsError: [Errno 17] File exists

[Mattia Rizzolo]

Control: forcemerge 850807 -1
Control: retitle 850807 diffoscope: FileExistsError in 
comparators.elf._install_debug_symbols()

On Wed, Jan 11, 2017 at 02:40:01AM +0100, Holger Levsen wrote:
> from
> https://jenkins.debian.net/job/reproducible_builder_armhf_8/15471/console
> (which should be preserved forever…)
> 
>   File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 
> 488, in _install_debug_symbols
> os.mkdir(os.path.dirname(dest_path))
> FileExistsError: [Errno 17] File exists: 
> '/srv/reproducible-results/rbuild-debian-t4VQ69oJ/dbd-tmp-rsSs31f/tmpc7n1jfvr_diffoscope/./usr/bin/.debug'

I already reported it yesterday, and already fixed in git; merging the
bugs.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Ben Finney]

Control: retitle -1 devscripts: reject ‘debian/rules’ actions on unpatched 
source
Control: found -1 devscripts/2.13.4
Control: severity -1 wishlist

On 29-Oct-2013, Ximin Luo wrote:
> On 29/10/13 15:37, Ximin Luo wrote:
> > On 29/10/13 15:18, James McCoy wrote:
> >> This is not a bug in debuild. “debuild $target” should behave
> >> similar to “dpkg-buildpackage -T $target” […]
> 
> […] dpkg-buildpackage is quite a low-level tool used by buildd and
> other infrastructure, so does not need to be nice to users.[…]
> debuild is a user-facing tool, so you do not have that excuse.

Reading this bug report, it seems the package maintainers are
unconvinced by that reasoning.

I am altering this report to a request for new behaviour that you
describe.

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)to learn.” —Richard M. Stallman, 2002 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849122: Fwd: With 2.6-2 i dont have the wifi adapter in the (network-manager) list available.

[Andrew Shadura]

-- Forwarded message --
From: data cruncher 
Date: 11 January 2017 at 03:40
Subject: Re: With 2.6-2 i dont have the wifi adapter in the
(network-manager) list available.
To: Andrew Shadura 


Hi

Unfortunately not really, there are no error messages nor similar in
the log files.
When i update to 2.6.2, it continues working, until the next reboot,
then i cannot "access" the device anymore
(although visible with ifconfig -a i cant ifup nor ifconfig wlx... up,
nor network-manager sees the device).

When downgrading to 2.5-2+v2.4-3+b1 (and reboot), everything works
normally again.

I recompiled the nic driver having wpasuplicant 2.6.2 installed, didnt help.
Restarting network-manager, wpa_supplicant, all didnt help.

I suspect dbus as it happens after the restart, but can't be sure...
Also it seems only to happen when one has compiled the module himself,
other (usb) cards works fine.

If you know what information you would need just let me know.


Regards


On Tue, Jan 10, 2017 at 5:14 PM, Andrew Shadura  wrote:
>
> Control: tag -1 moreinfo
>
> On Thu, 22 Dec 2016 20:41:31 +0100 cruncher  wrote:
> > Me too, i have also that problem.
> >
> > When installing 2.6-2, i cant see even the device anywhere (ifconfig nor
> > network-manager), downgrading to 2.5-2+v2.4-3+b1 works again.
> >
> > I'm building the driver module (8188eu) also myself for this device:
> > Wifi adapter: 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n 
> > Wireless
> > Network Adapter
>
> Have you resolved this issue? Could you please provide more details,
> logs, anything?
>
> --
> Cheers,
>   Andrew




-- 
Cheers,
  Andrew

Bug#850881: zurl: Please B-D on "libssl1.0-dev | libssl-dev (<< 1.1)" for stretch

[Jan Niehusmann]

Hi Niels,

On Tue, Jan 10, 2017 at 10:20:32PM +0100, Jan Niehusmann wrote:
> Am I missing something? Is this a good way to handle the situation?
> Would it be possible to speed up the propagation of zurl/1.7.1-3 to
> testing so I can upload zurl/1.7.1-4?

Even though I didn't get an answer to my mail (I hope there is no bad spam
filter involved...), I noticed this morning that you already helped -3
to migrate into testing. Thanks a lot!

(In case you wonder why I re-added zurl/1.7.1-2 to #850881: I got
mislead by stale output on https://tracker.debian.org/pkg/zurl and
thought the bug was still blocking migration.)

I just uploaded -4 build-depending on libssl1.0-dev and closing #850881.

Thanks for taking care of the openssl mess!

Jan

Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

[Frederic Bonnard]

Hi Tobias, Gianfranco.

Tobias, Thierry agreed and I change the owner, I hope it's better now.

Any of you would have time to review the package?
I added Gianfranco as is my usual sponsor,  but I forgot to Cc him in my
initial request.
Thanks,

F.

On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost  wrote:
> Control: tags -1 wontfix
> Control: block 806720 by -1
> 
> Hi Frederick,
> 
> the ITP is owned by Thierry Fauck, did you check with him if it is ok
> to take this ITP? (Should be done via the BTS and then the ITP's meta
> data should be corrected accordingly.
> 
> Please remove the wontfix when this has been resolved. 
> 
> --
> tobi
> 


pgpdbVfT5HPEu.pgp
Description: PGP signature

Bug#850921: openjfx version for openjdk 9.0

[Emmanuel Bourg]

Le 11/01/2017 à 09:51, shirish शिरीष a écrit :

> Looking forward to see the package which works with version 9.
> 
> While openjdk 9 would be available around the middle of the year from
> http://openjdk.java.net/projects/jdk9/
> 
> If openjdk 9 is being provided in sid to test out things, it makes
> sense to also provide openjfx for that as well.

Hi Shirish,

You are right, I plan to upgrade the openjfx package after the Stretch
release, once the OpenJDK 9 transition starts. I don't know yet if it's
preferable to upgrade the existing package, or create a new openjfx-9
package.

Emmanuel Bourg

Bug#850915: ghc: Please switch to llvm 3.8 or, better, 3.9

[Gianfranco Costamagna]

Hello

>Probably need to backport this upstream commit:

>
>https://git.haskell.org/ghc.git/commitdiff/672314cbeb8ac386a58f17dc4650dbdf4c55d8b5


probably not only that one, but at least 3 commits

Unfortunately when I expressed the idea (and the commits) over irc on 
#debian-haskell or whatever
I got a nack, because diverging from upstream in the default toolchain version 
is a no-go,
and moreover it would require probably a lot of binNMUs in the arm* 
architectures for the whole
haskell stack.

Upstream can fix bugs when llvm 3.7 is used, now when we diverge in such 
important key packages.

(this is a sum of the discussion I recall right now, I can search irc logs if 
needed)

G.

Bug#846616: Subj

[Sylvestre Ledru]

Le 11/01/2017 à 03:02, Askar Safin a écrit :
> reassign 846616 lldb-3.7 1:3.7.1-3
> thanks
> 
> Thanks for fixing. The bug is still present in lldb-3.7 1:3.7.1-3 and in 
> lldb-4.0 1:4.0~svn290810-1 in sid
I am not planning to fix 3.7 because I would like to see remove from the next 
Debian release.
For 4.0, it is in NEW:
https://ftp-master.debian.org/new/llvm-toolchain-snapshot_1:4.0~svn291432-1.html

S

Bug#848999: [pkg-gnupg-maint] Bug#848999: pinentry-gtk2: Fails to work, appears as gpg-agent not working

[Daniel Kahn Gillmor]

On Sat 2017-01-07 21:49:47 -0500, Roland Hieber wrote:
> I can confirm that behaviour, the pinentry-gtk2 window only flashes up shortly
> and then closes, but pinenetry-ncurses and -gnome3 work fine. The last time it
> worked for me was on Jan 1st 2017 with Enigmail. It also doesn't work for me
> after a reboot, and I haven't changed anything related to my setup since then
> (if you want to see, have a look at 
> https://github.com/rohieb/dotfiles/tree/r2d2
> ;-))

What window manager are you using, Roland?  Is it fvwm?

 --dkg


signature.asc
Description: PGP signature

Bug#849845: [pkg-gnupg-maint] Bug#850606: dirmngr: can't resolve ipv6 addresses when use-tor is enabled

[Daniel Kahn Gillmor]

Control: forcemerge 849845 850606

Hi Ximin--

Your recently-filed debian bug 850606 is a duplicate of 849845 so i'm
merging the two.

On Sun 2017-01-08 07:31:11 -0500, Ximin Luo wrote:
> Since dirmngr is very stupid in how it deals with DNS pools, one workaround
> that users can do, is to keep killing dirmngr and retrying the keyserver 
> lookup
> until dirmngr selects an IPv4 address and suceeeds.

dirmngr is actually quite a bit smarter about dealing with DNS pools
than tor is itself.

As a current workaround for myself, i mark all IPv6 addresses as dad:

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye |\
  awk '/\[.*:.*\]/{ print "keyserver --dead " $5 } ' |\
  gpg-connect-agent --dirmngr
  
Upstream is aware of the issue [0] and i hope to get a fix from upstream
in the next few days so that this workaround isn't necessary.

Regards,

--dkg

[0] https://bugs.gnupg.org/gnupg/issue2902


signature.asc
Description: PGP signature

Bug#850914: android-platform-frameworks-native FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: android-platform-frameworks-native
Version: 1:7.0.0+r1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

android-platform-frameworks-native fails to cross build from source,
because it uses the build architecture C++ compiler (as a GNU make
builtin). Indirecting the make invocation through dh_auto_build fixes
the problem, because debhelper knows when to supply cross compilers.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
android-platform-frameworks-native-7.0.0+r1/debian/changelog 
android-platform-frameworks-native-7.0.0+r1/debian/changelog
--- android-platform-frameworks-native-7.0.0+r1/debian/changelog
2016-12-06 10:16:45.0 +0100
+++ android-platform-frameworks-native-7.0.0+r1/debian/changelog
2017-01-11 09:17:29.0 +0100
@@ -1,3 +1,10 @@
+android-platform-frameworks-native (1:7.0.0+r1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 09:17:29 +0100
+
 android-platform-frameworks-native (1:7.0.0+r1-2) unstable; urgency=medium
 
   * Upload to unstable
diff --minimal -Nru android-platform-frameworks-native-7.0.0+r1/debian/rules 
android-platform-frameworks-native-7.0.0+r1/debian/rules
--- android-platform-frameworks-native-7.0.0+r1/debian/rules2016-12-06 
10:16:20.0 +0100
+++ android-platform-frameworks-native-7.0.0+r1/debian/rules2017-01-11 
09:17:29.0 +0100
@@ -8,7 +8,7 @@
 export DEB_LDFLAGS_MAINT_APPEND = -fPIC
 
 ifneq ($(filter amd64 i386 armel armhf arm64 mips mipsel 
mips64el,$(DEB_HOST_ARCH)),)
-  BUILD_COMMANDS = make -f debian/libETC1.mk
+  BUILD_COMMANDS = dh_auto_build --buildsystem=makefile -- -f debian/libETC1.mk
 endif
 
 %:

Bug#850915: ghc: Please switch to llvm 3.8 or, better, 3.9

[Sylvestre Ledru]

Source: ghc
Severity: important

Hello,

The armel build issue on 3.8 and 3.9 has been fixed thanks to a fix in 
libstdc++.
ghc can now change llvm version.

This is the last package using llvm 3.7, blocking its removal.
(note that I stopped caring about 3.7 more than a year ago, it is far behing 
3.8 or 3.9
in term of maintenance/support).

Sylvestre

Bug#685344: devscripts: "bts show --mbox" cannot resume after a Ctrl-Z

[Ben Finney]

Control: tags -1 + moreinfo

On 20-Aug-2012, Vincent Lefevre wrote:

> A "bts show --mbox " cannot resume after a Ctrl-Z.
> To reproduce the bug.
> 
> 1. Type "bts show --mbox 622231".
> 2. Ctrl-Z
> 3. Type "fg".
> 
> This shows another "zsh: suspended (signal)  bts show --mbox 622231",
> as if a second Ctrl-Z were sent.

This does not happen for me when I try (using ‘devscripts/2.16.13’).

The ‘fg’ command simply resumes the MUA (in my case, ‘mutt’) as expected.

Can you try reproducing this:

* With the current ‘devscripts’ version?

* Using each of Zsh and Bash?

* Using a different MUA?

-- 
 \“Good morning, Pooh Bear”, said Eeyore gloomily. “If it is a |
  `\   good morning”, he said. “Which I doubt”, said he. —A. A. Milne, |
_o__)_Winnie-the-Pooh_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#842198: Fwd: Re: Bug#842198: goobox: Crashes when run in VirtualBox

[Paolo Bacchilega]

Il 10/01/2017 19:40, Helge Kreutzmann ha scritto:

Hello Paolo,
please find the stacktrace below. If you need more/other
information, do not hesitate to also contact Jeremy Bicha
 directly (if you keep 842...@bgus.debian.org in
CC, that would be great).

Thanks a lot for your help!

Greetings

 Helge



It seems a problem in brasero, the relevant goobox code just calls 
brasero_drive_unlock on a valid brasero drive, that shouldn't crash.


- Paolo







- Forwarded message from Jeremy Bicha  -


Date: Tue, 10 Jan 2017 13:30:55 -0500
From: Jeremy Bicha 
To: Helge Kreutzmann 
Cc: 842...@bugs.debian.org
Subject: Re: Bug#842198: goobox: Crashes when run in VirtualBox

On 10 January 2017 at 07:16, Helge Kreutzmann  wrote:

can you provide a stacktrace?


See https://launchpad.net/bugs/1636983

I'm attaching the stacktrace from errors.ubuntu.com . If you need
something different, could you let me know the exact command for me to
enter?

Thanks,
Jeremy Bicha



https://launchpad.net/bugs/1636983
Stacktrace

#0  brasero_sense_data_not_ready (err=0x0, sense_data=0x7ffd2c31f2e0 "\360") at 
scsi-sense-data.c:118
res = BRASERO_SCSI_FAILURE
#1  brasero_sense_data_process (sense_data=sense_data@entry=0x7ffd2c31f2e0 
"\360", err=err@entry=0x0) at scsi-sense-data.c:210
No locals.
#2  0x7fcb58ac5e7b in brasero_scsi_command_issue_sync 
(command=command@entry=0x555bcefe8950, buffer=buffer@entry=0x0, 
size=size@entry=0, error=error@entry=0x0) at scsi-sg.c:134
sense_buffer = 
"\360\000\002\000\000\000\000\n\000\000\000\000:\000\000\000\000\000"
transport = {interface_id = 83, dxfer_direction = -3, cmd_len = 6 '\006', mx_sb_len = 19 
'\023', iovec_count = 0, dxfer_len = 0, dxferp = 0x0, cmdp = 0x555bcefe8950 "\036", sbp = 
0x7ffd2c31f2e0 "\360", timeout = 0, flags = 0, pack_id = 0, usr_ptr = 0x0, status = 2 
'\002', masked_status = 1 '\001', msg_status = 0 '\000', sb_len_wr = 18 '\022', host_status = 0, 
driver_status = 8, resid = 0, duration = 12, info = 1}
res = 
cmd = 0x555bcefe8950
__func__ = "brasero_scsi_command_issue_sync"
#3  0x7fcb58ac5cff in brasero_sbc_medium_removal 
(handle=handle@entry=0x555bcef80a20, prevent_removal=prevent_removal@entry=0, 
error=error@entry=0x0) at scsi-prevent-allow-medium-removal.c:91
cdb = 0x555bcefe8950
res = 
__func__ = "brasero_sbc_medium_removal"
#4  0x7fcb58ac15eb in brasero_drive_unlock (drive=0x555bcee96de0) at 
brasero-drive.c:565
handle = 0x555bcef80a20
priv = 0x555bcee96d70
device = 
result = 
__func__ = "brasero_drive_unlock"
#5  0x555bce075051 in goo_player_set_state (self=self@entry=0x555bcec18c10, 
state=GOO_PLAYER_STATE_NO_DISC, notify=1) at goo-player.c:325
No locals.
#6  0x555bce075b61 in goo_player_update (self=0x555bcec18c10) at 
goo-player.c:569
medium = 
#7  0x555bce078247 in first_time_idle (callback_data=0x555bceebaf90, 
callback_data@entry=) at 
goo-window.c:908
window = 0x555bceebaf90
#8  0x7fcb5692b103 in g_timeout_dispatch (source=0x555bcf0763c0, callback=, user_data=) at ././glib/gmain.c:4672
timeout_source = 0x555bcf0763c0
again = 
#9  0x7fcb5692a68a in g_main_dispatch (context=0x555bceae3ea0) at 
././glib/gmain.c:3201
dispatch = 0x7fcb5692b0f0 
prev_source = 0x0
was_in_call = 0
user_data = 0x555bceebaf90
callback = 0x555bce078220 
cb_funcs = 
cb_data = 0x555bceb00080
need_destroy = 
source = 0x555bcf0763c0
current = 0x555bceb60d20
i = 0
#10 g_main_context_dispatch (context=context@entry=0x555bceae3ea0) at 
././glib/gmain.c:3854
No locals.
#11 0x7fcb5692aa40 in g_main_context_iterate 
(context=context@entry=0x555bceae3ea0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3927
max_priority = 2147483647
timeout = 1
some_ready = 1
nfds = 3
allocated_nfds = 3
fds = 
#12 0x7fcb5692aaec in g_main_context_iteration 
(context=context@entry=0x555bceae3ea0, may_block=may_block@entry=1) at 
././glib/gmain.c:3988
retval = 
#13 0x7fcb56ee570d in g_application_run (application=0x555bceae10f0, 
argc=1, argv=0x7ffd2c31f638) at ././gio/gapplication.c:2381
arguments = 0x555bceabf330
status = 0
context = 0x555bceae3ea0
acquired_context = 
__func__ = "g_application_run"
#14 0x555bce0670ae in main (argc=1, argv=0x7ffd2c31f638) at main.c:73
status = 

Thread Stacktrace

.
Thread 4 (LWP 27591):
#0  0x7fcb560ee0bd in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x7fcb5692a9d6 in g_main_context_poll (priority=, n_fds=1, 
fds=0x7fcb440010c0, timeout=, context=0x555bceae8b50) at 
././glib/gmain.c:4226
poll_func = 0x7fcb5693a800 

Bug#850915: ghc: Please switch to llvm 3.8 or, better, 3.9

[Emilio Pozuelo Monfort]

On Wed, 11 Jan 2017 09:21:54 +0100 Sylvestre Ledru  wrote:
> Source: ghc
> Severity: important
> 
> Hello,
> 
> The armel build issue on 3.8 and 3.9 has been fixed thanks to a fix in 
> libstdc++.
> ghc can now change llvm version.
> 
> This is the last package using llvm 3.7, blocking its removal.
> (note that I stopped caring about 3.7 more than a year ago, it is far behing 
> 3.8 or 3.9
> in term of maintenance/support).

Probably need to backport this upstream commit:

https://git.haskell.org/ghc.git/commitdiff/672314cbeb8ac386a58f17dc4650dbdf4c55d8b5

Cheers,
Emilio

Bug#850919: icewm FTCBFS: does not pass cross compilers to cmake

[Helmut Grohne]

Source: icewm
Version: 1.3.8+mod+20161220-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

icewm fails to cross build from source, because it does not pass cross
compilers to cmake and thus uses the build architecture ones.
Thankfully, debhelper's cmake support is well aware of cross building,
so simply indirecting the cmake invocations through dh_auto_configure
makes it cross build successfully. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru icewm-1.3.8+mod+20161220/debian/changelog 
icewm-1.3.8+mod+20161220/debian/changelog
--- icewm-1.3.8+mod+20161220/debian/changelog   2016-12-20 20:28:11.0 
+0100
+++ icewm-1.3.8+mod+20161220/debian/changelog   2017-01-11 09:31:35.0 
+0100
@@ -1,3 +1,10 @@
+icewm (1.3.8+mod+20161220-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross compilers (closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Jan 2017 09:31:35 +0100
+
 icewm (1.3.8+mod+20161220-1) unstable; urgency=low
 
   * New upstream snapshot
diff --minimal -Nru icewm-1.3.8+mod+20161220/debian/rules 
icewm-1.3.8+mod+20161220/debian/rules
--- icewm-1.3.8+mod+20161220/debian/rules   2016-12-20 20:28:11.0 
+0100
+++ icewm-1.3.8+mod+20161220/debian/rules   2017-01-11 09:31:35.0 
+0100
@@ -31,15 +31,15 @@
 DEBVERSION := $(shell dpkg-parsechangelog |grep ^Version | sed -e 
s,Version:.,,)
 ORIGVERSION := $(shell echo $(DEBVERSION) | sed -e 's,-[^-]*$$,,' )
 
-cmakecmd = cmake $(CURDIR) 
-DICEHELPIDX=/usr/share/doc/icewm-common/html/icewm.html 
-DCFGDIR=/etc/X11/icewm -DCMAKE_INSTALL_PREFIX=/usr -DVERSION=$(ORIGVERSION) 
-DDOCDIR=$(DOCDIR) -DEXTRA_LIBS="-lsupc++" -DCMAKE_VERBOSE_MAKEFILE=ON
+cmakeargs = -DICEHELPIDX=/usr/share/doc/icewm-common/html/icewm.html 
-DCFGDIR=/etc/X11/icewm -DVERSION=$(ORIGVERSION) -DDOCDIR=$(DOCDIR) 
-DEXTRA_LIBS="-lsupc++" -DCMAKE_VERBOSE_MAKEFILE=ON
 
 config_lite:
-   mkdir -p $(BDIR)-lite
-   cd $(BDIR)-lite && $(cmakecmd) -DLITE=on -DEXEEXT=-lite 
-DCONFIG_XFREETYPE=off -DCONFIG_COREFONTS=on -DXINERAMA=on -DCONFIG_XRANDR=off 
-DCONFIG_TASKBAR=off -DCONFIG_FDO_MENUS=off -DSKIP_TRANSLATIONS=on
+   dh_auto_configure --builddirectory=$(BDIR)-lite -- \
+   $(cmakeargs) -DLITE=on -DEXEEXT=-lite -DCONFIG_XFREETYPE=off 
-DCONFIG_COREFONTS=on -DXINERAMA=on -DCONFIG_XRANDR=off -DCONFIG_TASKBAR=off 
-DCONFIG_FDO_MENUS=off -DSKIP_TRANSLATIONS=on
 
 config_normal:
-   mkdir -p $(BDIR)-normal
-   cd $(BDIR)-normal && $(cmakecmd) -DCONFIG_XRANDR=on 
-DCONFIG_GUIEVENTS=on
+   dh_auto_configure --builddirectory=$(BDIR)-normal -- \
+   $(cmakeargs) -DCONFIG_XRANDR=on -DCONFIG_GUIEVENTS=on
 
 override_dh_auto_configure:
$(MAKE) -f debian/rules -j2 config_normal config_lite

Bug#850789: Patch upload not showing up in deferred queue

[Mattia Rizzolo]

On Tue, Jan 10, 2017 at 06:51:56PM -0600, Taylor Kline wrote:
> So how do non-DDs help out with providing patches?

By attaching patches in the bugs.

The ability to actually upload the packages is the whole distinction
between DD and external contributors.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#850815: wand: diff for NMU version 0.4.4-1.1

[Mattia Rizzolo]

Control: tags 850815 + patch
Control: tags 850815 + pending

Dear maintainer,

I've prepared an NMU for wand (versioned as 0.4.4-1.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for wand-0.4.4 wand-0.4.4

 changelog |8 
 control   |6 +++---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff -Nru wand-0.4.4/debian/changelog wand-0.4.4/debian/changelog
--- wand-0.4.4/debian/changelog	2016-11-06 10:02:18.0 +0100
+++ wand-0.4.4/debian/changelog	2017-01-11 10:15:07.0 +0100
@@ -1,3 +1,11 @@
+wand (0.4.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update dependencies on libmagickwand from libmagickwand-6.q16-2 to
+libmagickwand-6.q16-3.  Closes: #850815
+
+ -- Mattia Rizzolo   Wed, 11 Jan 2017 10:15:07 +0100
+
 wand (0.4.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru wand-0.4.4/debian/control wand-0.4.4/debian/control
--- wand-0.4.4/debian/control	2016-11-06 10:02:18.0 +0100
+++ wand-0.4.4/debian/control	2017-01-11 10:14:15.0 +0100
@@ -23,7 +23,7 @@
 Package: python-wand
 Architecture: all
 Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends},
- libmagickwand5 | libmagickwand-6.q16-2,
+ libmagickwand5 | libmagickwand-6.q16-3,
 Suggests: wand-doc
 Description: Python interface for ImageMagick library (Python 2 build)
  Wand is a ctypes-based simple ImageMagick binding for Python. It
@@ -39,7 +39,7 @@
 Package: python3-wand
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends},
- libmagickwand5 | libmagickwand-6.q16-2,
+ libmagickwand5 | libmagickwand-6.q16-3,
 Suggests: wand-doc
 Description: Python interface for ImageMagick library (Python 3 build)
  Wand is a ctypes-based simple ImageMagick binding for Python. It
@@ -54,7 +54,7 @@
 Package: pypy-wand
 Architecture: all
 Depends: ${pypy:Depends}, ${misc:Depends},
- libmagickwand5 | libmagickwand-6.q16-2,
+ libmagickwand5 | libmagickwand-6.q16-3,
 Suggests: wand-doc
 Description: Python interface for ImageMagick library (PyPy build)
  Wand is a ctypes-based simple ImageMagick binding for Python. It


signature.asc
Description: PGP signature

Bug#850891: Additional patch, to cover slurmdbd's duplicate code

[Rémi Palancher]

Hi Karl,

Le 10/01/2017 à 22:31, Karl Kornel a écrit :

Hello!

I have a second patch, to make another similar change to my first patch.

I noticed that slurmdbd’s preinst script is doing the same user-creation.  
Although slurmdbd does not directly relate to slurm-client, both slurm-client 
and slurmdbd depend directly on the slurm-wlm-basic-plugins package.  So, my 
second patch does two things:

1) Move the preinst script from the slurm-client package to the 
slurm-wlm-basic-plugins package.
2) Remove the duplicate user-creation code from slurmdbd.


FWIW, we took the same approach in our EDF-specific packages:

https://github.com/edf-hpc/slurm-llnl

It works fine for us so far!

I just don't remember why we didn't propose the patch back into Debian 
official packages though :(


Best,
Rémi

Bug#850940: [xserver-xorg-core] plasmashell freezes with xorg-server 1.19.0

[MAG4 Piemonte]

Package: xserver-xorg-core
Version: 2:1.19.0-3
Severity: normal

--- Please enter the report below this line. ---
Hi, after upgrading to version 1.19.0-(2,3) plasmashell freezes frequently 
with the same symptoms described here
https://bugs.kde.org/show_bug.cgi?id=373131
and also here
https://lists.debian.org/debian-kde/2016/12/msg2.html
Downgrading to version 1.18.4-2 makes the problem disappear.
May be the error is solved by
https://bugs.freedesktop.org/show_bug.cgi?id=99333
Regards!

--- System information. ---
Architecture: 
Kernel:   Linux 4.8.0-2-686-pae

Debian Release: stretch/sid
  500 testing httpredir.debian.org 
  500 stable  download.webmin.com 

--- Package information. ---
Depends  (Version) | Installed
==-+-
xserver-common (>= 2:1.19.0-3) | 2:1.19.0-3
keyboard-configuration | 1.155
udev  (>= 149) | 232-8
libegl1-mesa   | 13.0.2-3
 OR libegl1| 
libaudit1 (>= 1:2.2.1) | 1:2.6.7-1
libc6(>= 2.17) | 2.24-8
libdbus-1-3(>= 1.9.14) | 1.10.14-1
libdrm2 (>= 2.3.1) | 2.4.74-1
libepoxy0 (>= 1.0) | 1.3.1-1
libgbm1(>= 10.2~0) | 13.0.2-3
libgcrypt20 (>= 1.7.0) | 1.7.5-2
libgl1-mesa-glx| 13.0.2-3
 OR libgl1 | 
libpciaccess0(>= 0.12.902) | 0.13.4-1
libpixman-1-0  (>= 0.30.0) | 0.34.0-1
libselinux1(>= 2.0.82) | 2.6-3
libsystemd0| 232-8
libudev1  (>= 183) | 232-8
libxau6| 1:1.0.8-1
libxdmcp6  | 1:1.1.2-1.1
libxfont2 (>= 1:2.0.1) | 1:2.0.1-3
libxshmfence1  | 1.2-1


Recommends  (Version) | Installed
=-+-==
libgl1-mesa-dri (>= 7.10.2-4) | 13.0.2-3
libpam-systemd| 232-8


Suggests (Version) | Installed
==-+-===
xfonts-100dpi  | 1:1.0.4+nmu1
 OR xfonts-75dpi   | 1:1.0.4+nmu1
xfonts-scalable| 1:1.0.3-1.1


--- Output from package bug script ---
X server symlink status:

lrwxrwxrwx 1 root root 13 ago 16  2011 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 dic 16 19:39 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/
ATI] RS780 [Radeon HD 3200] [1002:9610]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.8.0-2-686-pae (debian-ker...@lists.debian.org) (gcc version 
5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 37082 gen  5 10:13 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 32774 gen  5 10:15 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 56465 gen 11 12:15 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[36.227] (--) Log file renamed from "/var/log/Xorg.pid-1009.log" to "/var/
log/Xorg.0.log"
[36.248] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[36.249] X Protocol Version 11, Revision 0
[36.249] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
[36.249] Current Operating System: Linux hipnos 4.8.0-2-686-pae #1 SMP 
Debian 4.8.15-2 (2017-01-04) i686
[36.249] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-686-pae 
root=UUID=3f97e352-0d19-4a21-8aac-5c3c9677ee26 ro quiet splash
[36.249] Build Date: 16 December 2016  07:33:27PM
[36.249] xorg-server 2:1.19.0-3 (https://www.debian.org/support) 
[36.249] Current version of pixman: 0.34.0
[36.249]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[36.249] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[36.249] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 11 10:50:30 
2017
[36.321] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[36.656] (==) No Layout section.  Using the first Screen section.
[36.656] (==) No 

Bug#848809: [Debian-med-packaging] Bug#848809: Please confirm that you understood that cwltool is in danger to be removed from testing

[Olivier Sallou]

On 01/10/2017 05:52 PM, Andreas Tille wrote:
> Hi Michael,
>
> I'd like to ask again whether you received my message that my attempts
> to fix this bug remained unsuccessful and I gave up since I'm lacking
> the needed knowledge about the upstream code.  Please make sure that
> those bugs - which I consider easy to fix for an insider - will be fixed
> right in time.

Having a quick look, I cannot build due to git errors:


root@962f1e6e8665:~/cwltool# gbp buildpackage -rfakeroot
gbp:error: upstream/1.0.20161216212910 is not a valid treeish

By the way, patches fail to apply:

root@962f1e6e8665:~/cwltool# quilt push -a
Applying patch ignore_cwltest.patch
patching file setup.py
Hunk #1 FAILED at 48.
1 out of 1 hunk FAILED -- rejects in file setup.py
Patch ignore_cwltest.patch does not apply (enforce with -f)
>
> See you
>
> Andreas.
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Hi Gianfranco,

Thanks for your comments!



what about calling 2to3 in setup.py?


I somehow overlooked that this was possible. That's much more sensible than what 
I was doing.




and you can patch the code with a retro-compatible code
if you can't find a way that works with both python2 and 3, there is the 
version_info
variable that can help you in understanding what is the current interpreter


Ok, I've added a patch to do it the sys.version_info way since there doesn't 
seem to be a more elegant option.




I'm mostly sure upstream would appreciate a porting/retrocompatible patch :)


I hope so!


I've uploaded a new version which removes the d/rules hacks and implements 
proper patches (to be forwarded upstream at a later date). New diff from the 
same base is below.


Cheers,
Carl


$ git diff 281489c

diff --git a/debian/.git-dpm b/debian/.git-dpm
index b634411..f93cbbb 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-0a5a3e9b44be1ec1a150c027a07754a53f039189
-0a5a3e9b44be1ec1a150c027a07754a53f039189
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
 124074ce42e5d83c71e028a8757afb392cc96548
 124074ce42e5d83c71e028a8757afb392cc96548
 python-pynzb_0.1.0.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index c9a8606..2895253 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,27 +2,33 @@ python-pynzb (0.1.0-3) unstable; urgency=medium

   * Add myself to uploaders.
   * Switch to pybuild and dh-python.
-  * Bump d/compat to 10.
+  * Bump d/compat to 10 and update version of B-D on debhelper.
   * Bump standards-version to 3.9.8 (no changes).
-  * d/copyright: add myself and fix license short names
-- "public domain" -> public-domain
+  * d/copyright: add myself and fix license short names:
+- "public domain" -> public-domain,
 - BSD -> BSD-3-clause.
   * Change Vcs to DPMT git repository and use https.
-  * Change Homepage to GitHub.
-  * Build the Python 3 module and drop the Python 2 module (no rdeps).
-  * Run the test suite with pytest.
-  * Call 2to3 during auto build.
-  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
-This change allows the tests to pass for Python 2.
+  * Change Homepage to Github.
+  * Build the Python 3 module.
+- replace B-D: python{,3}-setuptools and python{,3}-all
+  * Drop the Python 2 module (no rdeps):
+  * Run the test suite with pytest:
+- cleanup the produced .cache/ in d/clean,
+- add B-D on python3-pytest.
+  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code
+typo. This change allows the tests to pass for Python 2.
+  * 0002-enable-use_2to3-in-setup.py.patch: enable 2to3 invocation in setup.py.
   * Move lxml to Suggests rather than Depends since there are fallbacks using
 standard library XML parsers.
   * Build-Depend on lxml in order to run the test for the implementation of the
 NZB parser using lxml (LXMLNZBParser).
-  * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
-change the code to decode strings -> bytes as utf-8 for lxml's benefit.
-  * Fix watch file.
+  * 0003-give-lxml-etree-BytesIO-in-Python-3.patch: make the code Python 3
+compatible by decoding strings -> bytes as UTF-8 and substituting BytesIO
+for StringIO. This only affects the LXMLNZPParser.
+  * Fix watch file and declare version 4 format.
+  * Cleanup .egg-info files in d/clean and d/source/options.

- -- Carl Suster   Tue, 10 Jan 2017 15:49:05 +1100
+ -- Carl Suster   Wed, 11 Jan 2017 23:24:01 +1100

 python-pynzb (0.1.0-2) unstable; urgency=low

diff --git a/debian/patches/0002-enable-use_2to3-in-setup.py.patch 
b/debian/patches/0002-enable-use_2to3-in-setup.py.patch

new file mode 100644
index 000..16f2a85
--- /dev/null
+++ b/debian/patches/0002-enable-use_2to3-in-setup.py.patch
@@ -0,0 +1,21 @@
+From 01027917584eafdf4228bf0590123dfd47fe14a8 Mon Sep 17 00:00:00 2001
+From: Carl Suster 
+Date: Wed, 11 Jan 2017 22:23:32 +1100
+Subject: enable use_2to3 in setup.py
+
+---
+ setup.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 0fd9d51..62f1ff3 100644
+--- a/setup.py
 b/setup.py
+@@ -168,4 +168,5 @@ setup(
+ include_package_data=True,
+ zip_safe=False,
+ install_requires=['setuptools'],
+-)
+\ No newline at end of file
++use_2to3=True,
++)
diff --git a/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch 
b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch

new file mode 100644
index 000..aac136f
--- /dev/null
+++ b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch
@@ -0,0 +1,40 @@
+From 591e67b26a2d694d5aae2d77985eab4d8daf2d9e Mon Sep 17 00:00:00 2001
+From: Carl Suster 
+Date: Wed, 11 Jan 2017 22:34:34 +1100
+Subject: give lxml etree BytesIO in Python 3
+
+The 

Bug#850941: wanna-build: Please support the Build-Depends-Arch and Build-Conflicts-Arch fields

[Johannes Schauer]

Package: buildd.debian.org
Severity: normal

Hi,

since #823910 will be fixed with the next Debian policy version, I'm
filing this bug to ask for support for the Build-Depends-Arch and
Build-Conflicts-Arch fields in wanna-build.

Without support for this, packages that use the Build-Depends-Arch field
and have their dependencies not satisfied will be scheduled for a
rebuild nevertheless, which will fail and not only result in wasted
buildd time but also spam the maintainer with regular build failure
emails.

Unfortunately I was not successful in understand the wanna-build code
enough to be able to come up with a patch.

Thanks!

cheers, josch

Bug#850942: RFS: pydbus/0.6.0-1

[Alberto Caso]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: pydbus
  Version : 0.6.0-1
  Upstream Author : Linus Lewandowski 
* URL : https://github.com/LEW21/pydbus
* License : LGPL-2.1+
  Section : python

It builds these binary packages:

 python-pydbus - Pythonic D-Bus library (Python 2)
 python-pydbus-doc - Pythonic D-Bus library (common documentation)
 python3-pydbus - Pythonic D-Bus library (Python 3)

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

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

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

 dget -x https://mentors.debian.net/debian/pool/main/p/pydbus/pydbus_0.6.0-1.dsc

It is also in Alioth:

https://anonscm.debian.org/cgit/python-modules/packages/pydbus.git/

Changes since the last upload:

pydbus (0.6.0-1) unstable; urgency=low

  * New upstream release.
  * Update copyright info to reflect upstream author's new name and email
address.
  * Remove no longer necessary .pyremove files.
  * Add autopkgtest tests.
  * Lower rst2html's report level when generating README.html to avoid 
warnings on minor typo.
  * Add Multi-Arch tags.

Regards,

-- 
Alberto Caso 

Servicio de Implantación de Sistemas.
Dir. Gral. de Administración Electrónica y Tecnologías de la
Información.
Consejería de Hacienda y Administración Pública.
Junta de Extremadura.

Bug#779893: gx is not needed to package go-ipfs

[Holger Levsen]

Hi,

archlinux has a go-ipfs package without gx, see
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/go-ipfs

also from #ipfs on freenode:

 <@whyrusleeping> its worth pointing out that gx does not require ipfs
 <@whyrusleeping> it can function just fine on its own using https from the 
gateways 


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#850943: dose-builddebcheck: please add an option to check non-full builds

[Johannes Schauer]

Package: dose-builddebcheck
Version: 5.0.1-6
Severity: wishlist

Hi,

currently, dose-builddebcheck can only check build dependency
satisfiability for full package builds. It would be great if
dose-builddebcheck could easily be used to also check arch-all-only,
arch-any-only, source-only build or any combination of those.
Specifically this would be interesting for wanna-build because that
still has to mangle build dependencies in the right way before passing
them to dose-builddebcheck because of this missing feature.

My idea would be to add a new option to dose-builddebcheck like:

 --deb-build=type

Where type is a comma separated value equal to syntax and semantics as
for the --build option in dpkg-buildpackage.

Does this sound like a plan?

Thanks!

cheers, josch

Bug#821114: [Pkg-nginx-maintainers] Bug#821114: nginx: Please use KillSignal=SIGQUIT in systemd service

[Christos Trochalakis]

Michael, Laurent,

I believe we can close the issue, unless you have an objection.

Bug#850889: suricata: Inconsistent behaviour between .init and .service

[Arturo Borrero Gonzalez]

On Tue, 10 Jan 2017 22:11:57 +0100 Christoph Biedl
 wrote:
> In #839146 you mentioned the default file is used in the init script
> only. While that's certainly a position to take, the result is
> on sysv systems the Suricata IDS/IDP daemon does not get started by
> default, on systemd however it does. That inconsistency is
> a bad idea, please fix this. In my opinino the daemon should not start
> by default since it probably needs some configuration, and there
> might be use cases for suricata where the daemon is not needed.
>

I like the idea of the suricata daemon being started by just
installing the package.
It means that the package includes a minimal configuration to use it
and implementing user's own
configuration should be easy. It's a symbol of readiness.
Most users find this satisfying, and I, as a user, expect most of
debian daemon packages to
be up and running just by installing them.

Regarding the discrepancy between the sysvinit and the systemd default
behaviour,

* the default sysvinit behaviour has been like this for years.
Probably sysvinit users expect it.
Do you think it worth changing it at this point?

* I have no sysvinit system to test. All my debian systems use systemd
which is the default init system in debian.
So my testing capabilities of sysvinit-related stuff are very limited.
This is something I could improve on my side of course.

* People don't usually run suricata with both sysvinit and systemd at
the same time, don't they?

* My recommendation is to run suricata with systemd. It will be better
integrated with the rest of the system.

> Also, after a quick glance into the init script:
>
> | else
> | echo "/etc/default/suricata is missing... bailing out!"
> | fi
>

Ok, I added 'exit 1' and redirected the echo output to stderr.
Thanks for the report :-)

Bug#771975: ITP: gnome-keysign -- tool to sign OpenPGP keys

[Sascha Steinbiss]

Hi Raphael,

after seeing your ITP I was wondering if you are still working on
packaging GNOME Keysign?

I'm asking because I was recently nudged in this regard by the main
GNOME Keysign upstream author, who is a friend of mine. I have prepared
a package for the latest upstream version 0.7 here:

  https://anonscm.debian.org/cgit/users/satta/geysigning.git/

It is Lintian clean (with the exception of a questionable and overridden
warning) and IMHO ready to be uploaded. I would be happy to get some
comments -- maybe we can join forces here and co-maintain, maybe as part
of a team? :)

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#792594: libqt5qml5 requires SSE2 on i386

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 11 de enero de 2017 11:08:36 ART Guillem Jover wrote:
[snip] 
> > Indeed I also prefer the second one. have you got to check it? I'll start
> > preparing the packaging.
> 
> I checked it some days ago, but already when the upload had happened,
> it obviously built :), so just letting you know it seems to work fine,
> thanks!

Thanks a lot for the feedback! I had in mind writing you to ask you this but 
it slipped trough my fingers :-/

-- 
Why should I care about my chatter from yesterday?
Nothing prevents me from becoming wiser.
  Konrad Adenauer, former German chancellor.
  http://lwn.net/SubscriberLink/397422/60a270d48f933c67/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#850887: Decide proper solution for binutils' mips* bug

[Lisandro Damián Nicanor Pérez Meyer]

I would like to mention that in my previous mail I forgot another possible fix 
for this bug: going back to binutils 2.27. The current uploads are snapshots 
of the next version, 2.28, and whereas the bug in question seems to habe been 
there all the time it started to affect us since a commit in the to-be 2.28 
version.

I've asked Matthias in [msg217] if there are any technical reasons to really 
go for 2.28 instead of 2.27. So far I did not get a reply to that.

[msg217] 

I've taken a look at binutil's [changelog] and there seems to be Debian-
related bugs closed there, but it's not up to me to say wether the mips* bug 
has more precedence or not over the others.

[changelog] 

Thanks, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#850806: [pulseaudio] pulseaudio hangs in "context_autospawn"

[Felipe Sateler]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=99356
Control: tags -1 upstream

On 11 January 2017 at 05:09, Bogdan Vatra  wrote:
> On marți, 10 ianuarie 2017 17:24:59 EET Felipe Sateler wrote:
>>
>> Could you please report this bug upstream at
>> https://bugs.freedesktop.org/enter_bug.cgi ?
>
> Done https://bugs.freedesktop.org/show_bug.cgi?id=99356 !

Thanks, marking the bug as forwarded.

-- 

Saludos,
Felipe Sateler

Bug#847221: fixed in open-vm-tools 2:10.1.0-4449150-2

[Andreas Beckmann]

On Tue, 06 Dec 2016 23:03:46 + Bernd Zeimetz  wrote:
> Source: open-vm-tools
> Source-Version: 2:10.1.0-4449150-2

>* [1e2eb34] Make dpkg --verify happy now. (Closes: #847221)

With debhelper fixed, you should be able to bump the debhelper version
and remove the workaround.


Andreas