Bug#850964: arduino: GNOME Software catalog entry missing

[asciiwolf]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: normal

The Arduino package cannot be found and/or installed using GNOME Software 
because the arduino.desktop file contained in the package is missing a 
"Comment" section that is required by AppStream to generate correct 
metadata.

https://appstream.debian.org/sid/main/issues/arduino.html

[Test Case]
1. Open the GNOME Software application.
2. Type "Arduino" into the search bar.

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Am 11.01.2017 um 18:25 schrieb Vincent Lefevre:
> On 2017-01-11 18:09:51 +0100, Michael Biebl wrote:
>> Am 11.01.2017 um 18:05 schrieb Michael Biebl:
>>> Why is this no normal shutdown?
> 
> Services are not stopped as usual.

How do you conclude that?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

[Lucas Nussbaum]

Source: molds
Version: 0.3.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):
> make[2]: Entering directory '/<>/src'
> mpicxx -MM base/Enums.cpp   base/PrintController.cpp 
> base/MolDSException.cpp 
> base/MallocerFreer.cpp  mpi/MpiProcess.cpp 
> mpi/AsyncCommunicator.cpp wrappers/Blas.cpp wrappers/Lapack.cpp 
> base/Utilities.cpp base/MathUtilities.cpp base/EularAngle.cpp 
> base/Parameters.cpp base/atoms/Atom.cpp base/atoms/Hatom.cpp 
> base/atoms/Liatom.cpp base/atoms/Catom.cpp base/atoms/Natom.cpp 
> base/atoms/Oatom.cpp base/atoms/Satom.cpp 
> base/atoms/mm/EnvironmentalPointCharge.cpp base/factories/AtomFactory.cpp 
> base/Molecule.cpp base/InputParser.cpp base/GTOExpansionSTO.cpp 
> base/RealSphericalHarmonicsIndex.cpp base/loggers/MOLogger.cpp 
> base/loggers/DensityLogger.cpp base/loggers/HoleDensityLogger.cpp 
> base/loggers/ParticleDensityLogger.cpp
> cndo/Cndo2.cppindo/Indo.cpp 
> zindo/ZindoS.cpp mndo/Mndo.cpp am1/Am1.cpp am1/Am1D.cpp pm3/Pm3.cpp 
> pm3/Pm3D.cpp pm3/Pm3Pddg.cpp base/factories/ElectronicStructureFactory.cpp 
> md/MD.cpp mc/MC.cpp rpmd/RPMD.cpp nasco/NASCO.cpp optimization/Optimizer.cpp 
> optimization/ConjugateGradient.cpp optimization/SteepestDescent.cpp 
> optimization/BFGS.cpp optimization/GEDIIS.cpp 
> base/factories/OptimizerFactory.cpp  base/MolDS.cpp Main.cpp 
> -I/usr/include/mpi -I/usr/lib/openblas-base//include/ | sed 's/^\([^ 
> ]\)/obj\/\1/g' | sed 's/\($*\)\.o[ :]*/\1.o : /g'  > obj/objfile.dep
> mpicxx -I/usr/include/mpi -I/usr/lib/openblas-base//include/ -o obj/Enums.o 
> base/Enums.cpp -g -Wall -fopenmp -O2 -fopenmp -c
> mpicxx -I/usr/include/mpi -I/usr/lib/openblas-base//include/ -o 
> obj/PrintController.o base/PrintController.cpp -g -Wall -fopenmp -O2 -fopenmp 
> -c
> mpicxx -I/usr/include/mpi -I/usr/lib/openblas-base//include/ -o 
> obj/MolDSException.o base/MolDSException.cpp -g -Wall -fopenmp -O2 -fopenmp -c
> base/MolDSException.cpp: In member function 'void 
> MolDS_base::MolDSException::GetBacktrace(int)':
> base/MolDSException.cpp:61:26: warning: comparison between signed and 
> unsigned integer expressions [-Wsign-compare]
> if(this->backtraceSize==bufsize){
>~~~^
> base/MolDSException.cpp: In member function 'virtual const char* 
> MolDS_base::MolDSException::what() const':
> base/MolDSException.cpp:113:24: warning: comparison between signed and 
> unsigned integer expressions [-Wsign-compare]
>for(int i = 0; i < this->backtraceSize; i++){
>   ~~^
> base/MolDSException.cpp: In instantiation of 'void 
> MolDS_base::MolDSException::serialize(Archive&, unsigned int) [with Archive = 
> boost::archive::text_oarchive]':
> /usr/include/boost/serialization/access.hpp:116:9:   required from 'static 
> void boost::serialization::access::serialize(Archive&, T&, unsigned int) 
> [with Archive = boost::archive::text_oarchive; T = 
> MolDS_base::MolDSException]'
> /usr/include/boost/serialization/serialization.hpp:68:22:   required from 
> 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with 
> Archive = boost::archive::text_oarchive; T = MolDS_base::MolDSException]'
> /usr/include/boost/serialization/serialization.hpp:126:14:   required from 
> 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with 
> Archive = boost::archive::text_oarchive; T = MolDS_base::MolDSException]'
> /usr/include/boost/archive/detail/oserializer.hpp:149:40:   required from 
> 'void boost::archive::detail::oserializer<Archive, 
> T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) 
> const [with Archive = boost::archive::text_oarchive; T = 
> MolDS_base::MolDSException]'
> /usr/include/boost/archive/detail/oserializer.hpp:102:1:   [ skipping 2 
> instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
> /usr/include/boost/archive/detail/oserializer.hpp:309:22:   required from 
> 'static void 
> boost::archive::detail::save_non_pointer_type::invoke(Archive&, 
> const T&) [with T = MolDS_base::MolDSException; Archive = 
> boost::archive::text_oarchive]'
> /usr/include/boost/archive/detail/oserializer.hpp:526:18:   required from 
> 'void boost::archive::save(Archive&, T&) [with Archive = 
> boost::archive::text_oarchive; T = const MolDS_base::MolDSException]'
> /usr/include/boost/archive/detail/common_oarchive.

Bug#850986: keyboard focus stays in main window when opening compose window

[Carsten Schoenert]

severity 850986 important
thanks

Lowering down to important. Please see 
https://www.debian.org/Bugs/Developer#severities

Regards
Carsten

On Wed, Jan 11, 2017 at 08:08:47PM +0100, Thibaut Paumard wrote:
> Package: icedove
> Version: 1:45.4.0-1
> Severity: grave
> 
> Dear maintainers,
> 
> I have that spurious proble that very often, when I open a new compose
> window (with ^N or by clicking on one of the reply-to buttons), the
> keyboard focus stays in the main window. I start typing, which can
> have nasty effects since the main indow recieves the events, such as,
> for instance:
>   - deleting emails;
>   - ignoring conversations.
> 
> It is not immediate to get the focus to the compose winodw I am
> interested in. Clicling in this window does not help, even after
> having clicked in the main icedove window or in another window from an
> unrelated application.
> 
> I have found two things that each help recover focus (no need to do
> both, each one is sufficient on its own):
> 
>  1- closing the main window;
> 
>  2- opening yet another compose window: this new window then has focus
> and I can from that point on get the focus in the window I like, 
> including the compose window that initially did not get focus.
> 
> This is not only anoying but also can cause data loss as I can end up
> deleting messages inadvertently. Forunately I have never actually
> purged a directory when that happened, but I consider myself lucky.
> 
> I am running GNOME 3 from testing, this bug has been there for a while
> including when I was running cinnamon on jessie. It feels like it's
> happening more often (almost, but not quite, always).
> 
> Kind regads, Thibaut.

Bug#851041: f-el: FTBFS: test failures

[Lucas Nussbaum]

Source: f-el
Version: 0.19.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):
>  fakeroot debian/rules binary
> dh binary --parallel --with elpa
>dh_elpa_test
>   emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list 
> \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
> 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
> package-initialize -L /usr/share/emacs/site-lisp/s-el -L 
> /usr/share/emacs/site-lisp/dash-el -L . -L test --eval "(progn (load-file 
> \"test/f-init.el\") (load-file \"test/test-helper.el\"))" -l 
> test/f-predicates-test.el -l test/f-destructive-test.el -l test/f-io-test.el 
> -l test/f-misc-test.el -l test/f-stats-test.el -l test/f-paths-test.el -l 
> test/f-sandbox-test.el --eval \(ert-run-tests-batch-and-exit\)
> Loading /<>/test/f-init.el (source)...
> Loading /<>/test/test-helper.el (source)...
> Running 229 tests (2017-01-10 22:30:55+)
>passed1/229  f--files-test/with-files-and-files
>passed2/229  f--traverse-upwards-test
>passed3/229  f-absolute\?-test/is-absolute
>passed4/229  f-absolute\?-test/is-relative
>passed5/229  f-ancestor-of\?-test/is-ancestor
>passed6/229  f-ancestor-of\?-test/is-not-ancestor
>passed7/229  f-ancestor-of\?-test/is-same
>passed8/229  f-append-bytes-test/does-not-exist
>passed9/229  f-append-bytes-test/exists
>passed   10/229  f-append-text/does-not-exist
>passed   11/229  f-append-text/exists
>passed   12/229  f-append/alias
>passed   13/229  f-base-test/multiple-extensions
>passed   14/229  f-base-test/no-extension
>passed   15/229  f-base-test/single-extension
>passed   16/229  f-canonical-test/path
>passed   17/229  f-canonical-test/symlink
>passed   18/229  f-child-of\?-test/is-child
>passed   19/229  f-child-of\?-test/is-not-child
>passed   20/229  f-child-of\?-test/is-same
>passed   21/229  f-common-parent/directory-absolute
>passed   22/229  f-common-parent/directory-relative
>passed   23/229  f-common-parent/empty-list
>passed   24/229  f-common-parent/no-common-parent
>passed   25/229  f-common-parent/root-common-parent
>passed   26/229  f-common-parent/same-path
>passed   27/229  f-common-parent/single-file
>passed   28/229  f-copy-contents-test/copy-directory
>passed   29/229  f-copy-contents-test/directory-does-not-exist
>passed   30/229  f-copy-contents-test/not-a-directory
>passed   31/229  f-copy-test/copy-absolute-dir-does-not-exist
>passed   32/229  f-copy-test/copy-absolute-dir-exists
>passed   33/229  f-copy-test/copy-absolute-file
>passed   34/229  f-copy-test/copy-relative-dir-does-not-exist
>passed   35/229  f-copy-test/copy-relative-dir-exists
>passed   36/229  f-copy-test/copy-relative-file
>passed   37/229  f-delete-test/directory
>passed   38/229  f-delete-test/directory-with-content
>passed   39/229  f-delete-test/file-in-directory
>passed   40/229  f-delete-test/symlink-to-directory
>passed   41/229  f-delete-test/symlink-to-file
>passed   42/229  f-depth/return-number-of-components-minus-one
>passed   43/229  f-depth/return-zero-for-root
>passed   44/229  f-descendant-of\?-test/is-descendant
>passed   45/229  f-descendant-of\?-test/is-not-descendant
>passed   46/229  f-descendant-of\?-test/is-same
>passed   47/229  f-dir\?-test/alias
>passed   48/229  f-directories-test/anaphoric
>passed   49/229  f-directories-test/no-directories-or-files
>passed   50/229  f-directories-test/recursive
>passed   51/229  f-directories-test/with-callback-function
>passed   52/229  f-directories-test/with-files-and-directories
>passed   53/229  f-directory\?-test/is-directory
>passed   54/229  f-directory\?-test/is-file
>passed   55/229  f-dirname-test/directory-absolute
>passed   56/229  f-dirname-test/directory-relative
>passed   57/229  f-dirname-test/file-absolute
>passed   58/229  f-dirname-test/file-relative
>passed   59/229  f-dirname-test/file-with-ending-slash
>passed   60/229  f-dirname-test/parent-alias
>passed   61/229  f-dirname-test/root
>passed   62/229  f-entries-test/anaphoric
>passed   63/229  f-entries-test/no-directories-or-files
>passed   64/229  f-entries-test/recursive
>passed   65/229  f-entries-test/with-callback-function
>passed   66/229  f-entri

Bug#851039: python-apt: FTBFS: Test failures

[Lucas Nussbaum]

Source: python-apt
Version: 1.4.0~beta1
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):
> WARNING: Failed to read mirror file
> WARNING: Failed to read mirror file
> ==
> FAIL: test_os_release_distribution (test_aptsources.TestAptSources)
> os-release file can be read and is_like is populated accordingly
> --
> Traceback (most recent call last):
>   File "/<>/tests/test_aptsources.py", line 265, in 
> test_os_release_distribution
> self.assertEqual('Ubuntu', distro.id)
> AssertionError: 'Ubuntu' != 'Debian'
> 
> --
> Ran 94 tests in 17.786s
> 
> FAILED (failures=1, skipped=2)
> debian/rules:50: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/python-apt_1.4.0~beta1_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#850979: crafty: Does not run on Pentium 4 (Illegal instruction)

[Santiago Vila]

On Wed, Jan 11, 2017 at 07:36:56PM +0100, Sven Joachim wrote:

> The toplevel Makefile in the crafty source adds -march=k8 to CFLAGS,

Hi. I checked that a rebuild fixed the issue, but I've also removed
the -march thing to be safe.

Thanks a lot.

Bug#851038: gcc-6-cross: FTBFS: 1 out of 1 hunk FAILED -- rejects in file src/libphobos/configure.ac

[Lucas Nussbaum]

Source: gcc-6-cross
Version: 14
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 '/<>/gcc'
> : # unpack gcc tarball
> mkdir -p stamps
> if [ -d /<>/gcc/src ]; then \
>   echo >&2 "Source directory /<>/gcc/src exists. Delete by 
> hand"; \
>   false; \
> fi
> rm -rf gcc-6.3.0
> tar -x -f /usr/src/gcc-6/gcc-6.3.0-dfsg.tar.xz
> mv gcc-6.3.0 /<>/gcc/src
> ln -sf libsanitizer /<>/gcc/src/libasan
> rm -f /<>/gcc/src/gcc/doc/*.1
> rm -f /<>/gcc/src/gcc/doc/fsf-funding.7
> rm -f /<>/gcc/src/gcc/doc/*.info
> rm -f /<>/gcc/src/gcc/fortran/*.info
> rm -f /<>/gcc/src/libgomp/*.info
> rm -f /<>/gcc/src/gcc/java/*.1
> rm -f /<>/gcc/src/gcc/java/*.info
> for i in gcc/doc/avr-mmcu.texi gcc/doc/bugreport.texi gcc/doc/cfg.texi 
> gcc/doc/collect2.texi gcc/doc/compat.texi gcc/doc/configfiles.texi 
> gcc/doc/configterms.texi gcc/doc/contrib.texi gcc/doc/contribute.texi 
> gcc/doc/cpp.texi gcc/doc/cppenv.texi gcc/doc/cppinternals.texi 
> gcc/doc/cppopts.texi gcc/doc/extend.texi gcc/doc/fragments.texi 
> gcc/doc/frontends.texi gcc/doc/gccint.texi gcc/doc/gcov.texi 
> gcc/doc/gcov-tool.texi gcc/doc/generic.texi gcc/doc/gimple.texi 
> gcc/doc/gnu.texi gcc/doc/gty.texi gcc/doc/headerdirs.texi 
> gcc/doc/hostconfig.texi gcc/doc/implement-c.texi gcc/doc/implement-cxx.texi 
> gcc/doc/install-old.texi gcc/doc/install.texi gcc/doc/interface.texi 
> gcc/doc/invoke.texi gcc/doc/languages.texi gcc/doc/libgcc.texi 
> gcc/doc/loop.texi gcc/doc/lto.texi gcc/doc/makefile.texi 
> gcc/doc/match-and-simplify.texi gcc/doc/md.texi gcc/doc/objc.texi 
> gcc/doc/optinfo.texi gcc/doc/options.texi gcc/doc/passes.texi 
> gcc/doc/plugins.texi gcc/doc/portability.texi gcc/doc/rtl.texi 
> gcc/doc/service.texi gcc/doc/sourcebuild.texi gcc/doc/standards.texi 
> gcc/doc/tm.texi.in gcc/doc/tm.texi gcc/doc/tree-ssa.texi gcc/doc/trouble.texi 
> gcc/doc/include/gcc-common.texi gcc/doc/include/funding.texi 
> gcc/fortran/gfc-internals.texi gcc/fortran/invoke.texi 
> gcc/fortran/intrinsic.texi ; do \
>   if [ -f /<>/gcc/src/$i ]; then \
> cp debian/dummy.texi /<>/gcc/src/$i; \
>   else \
> cp debian/dummy.texi /<>/gcc/src/$i; \
> echo >&2 "$i does not exist, fix debian/rules.unpack"; \
>   fi; \
> done
> for i in gcc/doc/gcc.texi gcc/java/gcj.texi gcc/ada/gnat-style.texi 
> gcc/ada/gnat_rm.texi gcc/ada/gnat_ugn.texi gcc/fortran/gfortran.texi 
> gcc/go/gccgo.texi libgomp/libgomp.texi libquadmath/libquadmath.texi ; do \
>   n=$(basename $i .texi); \
>   if [ -f /<>/gcc/src/$i ]; then \
> sed "s/@name@/$n/g" debian/gcc-dummy.texi \
>   > /<>/gcc/src/$i; \
>   else \
> sed "s/@name@/$n/g" debian/gcc-dummy.texi \
>   > /<>/gcc/src/$i; \
> echo >&2 "$i does not exist, fix debian/rules.unpack"; \
>   fi; \
> done
> for i in gcc/doc/cpp.1 gcc/doc/g++.1 gcc/doc/gc-analyze.1 gcc/doc/gcc.1 
> gcc/doc/gccgo.1 gcc/doc/gcj.1 gcc/doc/gcj-dbtool.1 gcc/doc/gcjh.1 
> gcc/doc/gcov.1 gcc/doc/gcov-tool.1 gcc/doc/gfortran.1 gcc/doc/gij.1 
> gcc/doc/grmic.1 gcc/doc/grmiregistry.1 gcc/doc/jcf-dump.1 
> gcc/doc/jv-convert.1 gcc/doc/fsf-funding.7 ; do \
>   touch /<>/gcc/src/$i; \
> done
> rm -f /<>/gcc/src/INSTALL/*.html
> echo "gcc-6.3.0-dfsg.tar.xz unpacked." > 
> stamps/01-unpack-stamp-gcc-6.3.0-dfsg.tar.xz
> : # unpack gdc tarball
> mkdir -p stamps
> if [ -d /<>/gcc/src/gcc/d ]; then \
>   echo >&2 "Source directory /<>/gcc/src/gcc/d exists. Delete by 
> hand";\
>   false; \
> fi
> #rm -rf gdc-20161222
> rm -rf /<>/gcc/src/gcc/d
> rm -rf /<>/gcc/src/gcc/testsuite/gdc.test
> rm -f /<>/gcc/src/gcc/testsuite/lib/gdc*.exp
> rm -rf /<>/gcc/src/libphobos
> tar -x -C /<>/gcc/src --strip-components=1 -f 
> /usr/src/gcc-6/gdc-20161222.tar.xz
> echo "gdc-20161222.tar.xz unpacked." > 
> stamps/01-unpack-stamp-gdc-20161222.tar.xz
> echo -e "\nBuilt from Debian source package gcc-6-6.3.0-2" \
>   > pxxx
> echo -e "Integrated upstream packages in this version:\n" >> pxxx
> for i in gcc-6.3.0-dfsg.tar.xz  gdc-20161222.tar.xz; do echo "  $i" >> pxxx; 
> done
> mv -f pxxx stamps/01-unpack-stamp
> echo svn-updates.diff libiberty-updates.diff gcc-gfdl-build.diff 
> gcc-textdomain.diff gcc-driver-extra-langs.diff gcc-hash-style-gnu.diff 
> l

Bug#851047: gcc-6-cross-ports: FTBFS: 1 out of 1 hunk FAILED -- rejects in file src/libphobos/configure.ac

[Lucas Nussbaum]

Source: gcc-6-cross-ports
Version: 11
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 '/<>/gcc'
> : # unpack gcc tarball
> mkdir -p stamps
> if [ -d /<>/gcc/src ]; then \
>   echo >&2 "Source directory /<>/gcc/src exists. Delete by 
> hand"; \
>   false; \
> fi
> rm -rf gcc-6.3.0
> tar -x -f /usr/src/gcc-6/gcc-6.3.0-dfsg.tar.xz
> mv gcc-6.3.0 /<>/gcc/src
> ln -sf libsanitizer /<>/gcc/src/libasan
> rm -f /<>/gcc/src/gcc/doc/*.1
> rm -f /<>/gcc/src/gcc/doc/fsf-funding.7
> rm -f /<>/gcc/src/gcc/doc/*.info
> rm -f /<>/gcc/src/gcc/fortran/*.info
> rm -f /<>/gcc/src/libgomp/*.info
> rm -f /<>/gcc/src/gcc/java/*.1
> rm -f /<>/gcc/src/gcc/java/*.info
> for i in gcc/doc/avr-mmcu.texi gcc/doc/bugreport.texi gcc/doc/cfg.texi 
> gcc/doc/collect2.texi gcc/doc/compat.texi gcc/doc/configfiles.texi 
> gcc/doc/configterms.texi gcc/doc/contrib.texi gcc/doc/contribute.texi 
> gcc/doc/cpp.texi gcc/doc/cppenv.texi gcc/doc/cppinternals.texi 
> gcc/doc/cppopts.texi gcc/doc/extend.texi gcc/doc/fragments.texi 
> gcc/doc/frontends.texi gcc/doc/gccint.texi gcc/doc/gcov.texi 
> gcc/doc/gcov-tool.texi gcc/doc/generic.texi gcc/doc/gimple.texi 
> gcc/doc/gnu.texi gcc/doc/gty.texi gcc/doc/headerdirs.texi 
> gcc/doc/hostconfig.texi gcc/doc/implement-c.texi gcc/doc/implement-cxx.texi 
> gcc/doc/install-old.texi gcc/doc/install.texi gcc/doc/interface.texi 
> gcc/doc/invoke.texi gcc/doc/languages.texi gcc/doc/libgcc.texi 
> gcc/doc/loop.texi gcc/doc/lto.texi gcc/doc/makefile.texi 
> gcc/doc/match-and-simplify.texi gcc/doc/md.texi gcc/doc/objc.texi 
> gcc/doc/optinfo.texi gcc/doc/options.texi gcc/doc/passes.texi 
> gcc/doc/plugins.texi gcc/doc/portability.texi gcc/doc/rtl.texi 
> gcc/doc/service.texi gcc/doc/sourcebuild.texi gcc/doc/standards.texi 
> gcc/doc/tm.texi.in gcc/doc/tm.texi gcc/doc/tree-ssa.texi gcc/doc/trouble.texi 
> gcc/doc/include/gcc-common.texi gcc/doc/include/funding.texi 
> gcc/fortran/gfc-internals.texi gcc/fortran/invoke.texi 
> gcc/fortran/intrinsic.texi ; do \
>   if [ -f /<>/gcc/src/$i ]; then \
> cp debian/dummy.texi /<>/gcc/src/$i; \
>   else \
> cp debian/dummy.texi /<>/gcc/src/$i; \
> echo >&2 "$i does not exist, fix debian/rules.unpack"; \
>   fi; \
> done
> for i in gcc/doc/gcc.texi gcc/java/gcj.texi gcc/ada/gnat-style.texi 
> gcc/ada/gnat_rm.texi gcc/ada/gnat_ugn.texi gcc/fortran/gfortran.texi 
> gcc/go/gccgo.texi libgomp/libgomp.texi libquadmath/libquadmath.texi ; do \
>   n=$(basename $i .texi); \
>   if [ -f /<>/gcc/src/$i ]; then \
> sed "s/@name@/$n/g" debian/gcc-dummy.texi \
>   > /<>/gcc/src/$i; \
>   else \
> sed "s/@name@/$n/g" debian/gcc-dummy.texi \
>   > /<>/gcc/src/$i; \
> echo >&2 "$i does not exist, fix debian/rules.unpack"; \
>   fi; \
> done
> for i in gcc/doc/cpp.1 gcc/doc/g++.1 gcc/doc/gc-analyze.1 gcc/doc/gcc.1 
> gcc/doc/gccgo.1 gcc/doc/gcj.1 gcc/doc/gcj-dbtool.1 gcc/doc/gcjh.1 
> gcc/doc/gcov.1 gcc/doc/gcov-tool.1 gcc/doc/gfortran.1 gcc/doc/gij.1 
> gcc/doc/grmic.1 gcc/doc/grmiregistry.1 gcc/doc/jcf-dump.1 
> gcc/doc/jv-convert.1 gcc/doc/fsf-funding.7 ; do \
>   touch /<>/gcc/src/$i; \
> done
> rm -f /<>/gcc/src/INSTALL/*.html
> echo "gcc-6.3.0-dfsg.tar.xz unpacked." > 
> stamps/01-unpack-stamp-gcc-6.3.0-dfsg.tar.xz
> : # unpack gdc tarball
> mkdir -p stamps
> if [ -d /<>/gcc/src/gcc/d ]; then \
>   echo >&2 "Source directory /<>/gcc/src/gcc/d exists. Delete by 
> hand";\
>   false; \
> fi
> #rm -rf gdc-20161222
> rm -rf /<>/gcc/src/gcc/d
> rm -rf /<>/gcc/src/gcc/testsuite/gdc.test
> rm -f /<>/gcc/src/gcc/testsuite/lib/gdc*.exp
> rm -rf /<>/gcc/src/libphobos
> tar -x -C /<>/gcc/src --strip-components=1 -f 
> /usr/src/gcc-6/gdc-20161222.tar.xz
> echo "gdc-20161222.tar.xz unpacked." > 
> stamps/01-unpack-stamp-gdc-20161222.tar.xz
> echo -e "\nBuilt from Debian source package gcc-6-6.3.0-2" \
>   > pxxx
> echo -e "Integrated upstream packages in this version:\n" >> pxxx
> for i in gcc-6.3.0-dfsg.tar.xz  gdc-20161222.tar.xz; do echo "  $i" >> pxxx; 
> done
> mv -f pxxx stamps/01-unpack-stamp
> echo svn-updates.diff libiberty-updates.diff gcc-gfdl-build.diff 
> gcc-textdomain.diff gcc-driver-extra-langs.diff gcc-hash-style-gnu.

Bug#851045: keystone: FTBFS: Test failures

[Lucas Nussbaum]

Source: keystone
Version: 2:10.0.0-5
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 "keystone/tests/unit/test_wsgi.py", line 179, in 
> test_render_response_no_body
> self.assertEqual('0', resp.headers.get('Content-Length'))
>   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: '0' != None
> 
> 
> --
> Ran 6957 tests in 70.646s
> 
> FAILED (failures=5, skipped=1724)
> debian/rules:20: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/keystone_10.0.0-5_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#850244: reconserver: FTBFS on ppc64el: reConServer.cxx:941:164: error: no matching function for call to 'resip::HEPSipMessageLoggingHandler::HEPSipMessageLoggingHandler(resip::Data&, int&, int&)'

[Lucas Nussbaum]

Control: retitle -1 reconserver: FTBFS: reConServer.cxx:941:164: error: no 
matching function for call to 
'resip::HEPSipMessageLoggingHandler::HEPSipMessageLoggingHandler(resip::Data&, 
int&, int&)'

I ran into this on amd64 as well.

Lucas

Bug#850947: apache2: mod_http2 issue with option "Indexes" and directive "HeaderName"

[Markus Martinet]

Package: apache2
Version: 2.4.25-1
Severity: normal

Dear Maintainer,

please read the issue from https://github.com/icing/mod_h2/issues/126
which also affects the version below.

Thanks.

-- Package-specific info:

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

Kernel: Linux 3.16.0-042stab120.5 (SMP w/4 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) (ignored: 
LC_ALL set to de_DE@euro)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.25-1
ii  apache2-data 2.4.25-1
ii  apache2-utils2.4.25-1
ii  dpkg 1.18.18
ii  init-system-helpers  1.46
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  perl 5.24.1~rc4-1
pn  perl:any 
ii  procps   2:3.3.12-3

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.38

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.25-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.8.9dev11-1

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.2-5
ii  libaprutil1  1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap 1.5.4-3
ii  libc62.24-8
ii  libldap-2.4-22.4.44+dfsg-2
ii  liblua5.2-0  5.2.4-1.1+b1
ii  libnghttp2-141.17.0-1
ii  libpcre3 2:8.39-2
ii  libssl1.0.2  1.0.2j-4
ii  libxml2  2.9.4+dfsg1-2.1
pn  perl:any 
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.25-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.8.9dev11-1

Versions of packages apache2 is related to:
ii  apache2  2.4.25-1
ii  apache2-bin  2.4.25-1

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
/etc/apache2/conf-available/other-vhosts-access-log.conf changed [not included]
/etc/apache2/conf-available/security.conf changed [not included]
/etc/apache2/magic changed [not included]
/etc/apache2/mods-available/alias.conf changed [not included]
/etc/apache2/mods-available/autoindex.conf changed [not included]
/etc/apache2/mods-available/deflate.conf changed [not included]
/etc/apache2/mods-available/dir.conf changed [not included]
/etc/apache2/mods-available/info.conf changed [not included]
/etc/apache2/mods-available/ldap.conf changed [not included]
/etc/apache2/mods-available/mime.conf changed [not included]
/etc/apache2/mods-available/negotiation.conf changed [not included]
/etc/apache2/mods-available/proxy.conf changed [not included]
/etc/apache2/mods-available/setenvif.conf changed [not included]
/etc/apache2/mods-available/ssl.conf changed [not included]
/etc/apache2/mods-available/status.conf changed [not included]
/etc/apache2/mods-available/userdir.conf changed [not included]
/etc/apache2/ports.conf changed [not included]
/etc/apache2/sites-available/000-default.conf changed [not included]
/etc/apache2/sites-available/default-ssl.conf changed [not included]
/etc/cron.daily/apache2 changed [not included]
/etc/logrotate.d/apache2 changed [not included]

-- no debconf information

Bug#850869: [git-buildpackage/master] Quote arguments passed to builder

[Guido Günther]

tag 850869 pending
thanks

Date:   Wed Jan 11 11:57:37 2017 +0100
Author: Guido Günther 
Commit ID: 80a1c39abf60d09bb6b8e033350b06ac789726cf
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=80a1c39abf60d09bb6b8e033350b06ac789726cf
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=80a1c39abf60d09bb6b8e033350b06ac789726cf

Quote arguments passed to builder

Closes: #850869
Thanks: Simon McVittie

A snapshot build including this change will be available at
http://honk.sigxcpu.org:8001/job/git-buildpackage/
  

Bug#850887: TC Involvement: MIPS and binutils

[Sam Hartman]

Hi.

As you are probably aware, the question of what to do about linking on
mips and stretch has been referred to the TC.
There's a reasonable probability that we're going to want to move very
quickly on this issue, and I wanted to reach out to you and see how we
could best work with you to collect your input.

I'd be happy to set up an IRC discussion, to set up a phone call, etc.
I think that might work better than an email discussion, because the
email discussion might involve a number of round trips.
I'd be happy to work one-on-one and summarize results/provide logs back
to the entire TC, or to set up something open to as many people as we
can.
Also if there's a TC member you'd rather work with than me, I'm sure
we'd be happy to facilitate this.

I'm hoping that you will be able to quickly work with us to understand
this issue and your position.

Thanks for your consideration,

--Sam

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Vincent Lefevre]

Control: severity -1 grave

because it can corrupt files.

When this occurred on December 23, the log file of monit got
corrupted:

[CET Dec 22 07:35:07] info : 'zira' Monit reloaded
[CET Dec 22 07:35:07] error: Queued event file: unable to read event size 
-- end of file
[CET Dec 23 10:51:01] error: 'eth0' link down
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[CET
 Dec 23 10:52:10] info : Starting Monit 5.20.0 daemon
[CET Dec 23 10:52:10] info : 'zira' Monit 5.20.0 started
[...]

And from journalctl:

[...]
Dec 23 10:51:01 zira kernel: PM: Finishing wakeup.
Dec 23 10:51:01 zira kernel: Restarting tasks ... 
Dec 23 10:51:01 zira kernel: acpi PNP0501:00: Still not present
Dec 23 10:51:01 zira kernel: done.
Dec 23 10:51:01 zira kernel: pci_bus :02: Allocating resources
Dec 23 10:51:01 zira kernel: pci_bus :3b: Allocating resources
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: bridge window [io  
0x1000-0x0fff] to [bus 5f] add_size 1000
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: res[13]=[io  0x1000-0x0fff] 
res_to_dev_res add_size 1000 min_align 1000
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: res[13]=[io  0x1000-0x1fff] 
res_to_dev_res add_size 1000 min_align 1000
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: BAR 13: no space for [io  
size 0x1000]
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: BAR 13: failed to assign 
[io  size 0x1000]
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: BAR 13: no space for [io  
size 0x1000]
Dec 23 10:51:01 zira kernel: pcieport :3c:03.0: BAR 13: failed to assign 
[io  size 0x1000]
Dec 23 10:51:01 zira kernel: Bluetooth: hci0: read Intel version: 
370710018002030d00
Dec 23 10:51:01 zira kernel: Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
Dec 23 10:51:01 zira systemd[1]: Time has been changed
Dec 23 10:51:01 zira rtkit-daemon[2080]: The canary thread is apparently 
starving. Taking action.
Dec 23 10:51:01 zira systemd[1394]: Time has been changed
Dec 23 10:51:01 zira rtkit-daemon[2080]: Demoting known real-time threads.
Dec 23 10:51:01 zira systemd-logind[803]: Lid opened.
Dec 23 10:51:01 zira rtkit-daemon[2080]: Successfully demoted thread 2097 of 
process 2079 (n/a).
Dec 23 10:51:01 zira systemd[1]: apt-daily.timer: Adding 4h 42min 58.832894s 
random time.
Dec 23 10:51:01 zira rtkit-daemon[2080]: Successfully demoted thread 2096 of 
process 2079 (n/a).
Dec 23 10:51:01 zira systemd[1606]: Time has been changed
Dec 23 10:51:01 zira kernel: video LNXVIDEO:00: Restoring backlight state
Dec 23 10:51:01 zira kernel: ACPI Warning: \_SB.PCI0.PEGP.DGFX._DSM: Argument 
#4 type mismatch - Found [Buffer], ACPI requires [Package] 
(20160422/nsarguments-95)
Dec 23 10:51:01 zira kernel: ACPI Warning: \_SB.PCI0.PEGP.DGFX._DSM: Argument 
#4 type mismatch - Found [Buffer], ACPI requires [Package] 
(20160422/nsarguments-95)
Dec 23 10:51:01 zira kernel: ACPI Warning: \_SB.PCI0.PEGP.DGFX._DSM: Argument 
#4 type mismatch - Found [Buffer], ACPI requires [Package] 
(20160422/nsarguments-95)
Dec 23 10:51:01 zira kernel: ACPI Warning: \_SB.PCI0.PEGP.DGFX._DSM: Argument 
#4 type mismatch - Found [Buffer], ACPI requires [Package] 
(20160422/nsarguments-95)
Dec 23 10:51:01 zira rtkit-daemon[2080]: Successfully demoted thread 2095 of 
process 2079 (n/a).
Dec 23 10:51:01 zira systemd[1]: apt-daily.timer: Adding 1h 5min 28.127060s 
random time.
Dec 23 10:51:01 zira rtkit-daemon[2080]: Successfully demoted thread 2079 of 
process 2079 (n/a).
Dec 23 10:51:01 zira systemd[1]: Starting Load/Save RF Kill Switch Status...
Dec 23 10:51:01 zira rtkit-daemon[2080]: Demoted 4 threads.
Dec 23 10:51:01 zira systemd[1]: bluetooth.target: Unit not needed anymore. 
Stopping.
Dec 23 10:51:01 zira acpid[751]: client 984[0:0] has disconnected
Dec 23 10:51:01 zira systemd[1]: Stopped target Bluetooth.
Dec 23 10:51:01 zira postfix/smtpd[11811]: connect from 

Bug#808459: pywavelets: please make the build reproducible

[Chris Lamb]

Hi Daniele,

> Looking at
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pywavelets.html
> 
> it's not clear to me if the package is now reproducible or not,
> icon seem to say the package is reproducible.

The icon is correct!  Closing bug (in bcc).


Regards,

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

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

[Aaron M. Ucko]

retitle 850924 libfltk1.3: binNMU levels vary by architecture
thanks

Thorsten Glaser  writes:

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

It's been Multi-Arch: same all along, apart from three experimental-only
uploads back in 2010.  However, coinstallability requires exactly
matching *binary* package versions.  That isn't presently the case here
because fltk1.3 underwent a binNMU for the libpng1.6 transition on i386
(and most other architectures) but not x32, on which it had been waiting
for cmake and libasound-dev2 to be installable:

  https://buildd.debian.org/status/package.php?p=fltk1.3=sid

The sourceful upload I'm planning to issue to fix #828081 should bring
all architectures back in sync.  (I've been busy with other matters, but
plan to find time to address it in time for the freeze, or at least the
final release.)  Alternatively, I could ask for no-changes binNMUs to
bump binary versions as necessary, but there's the problem that some
experimental architectures (ppc64, sh4, and sparc64) wound up at +b2
because their +b1 runs accidentally still picked up an older libpng.

Thanks for the report, at any rate!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#850952: CVE-2016-9962

[Moritz Muehlenhoff]

Package: docker.io
Severity: grave
Tags: security

Please see:
https://bugzilla.suse.com/show_bug.cgi?id=1012568
https://github.com/docker/docker/compare/v1.12.5...v1.12.6
https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5

Cheers,
Moritz

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

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

Bug#850965: freecad: GNOME Software catalog entry missing

[asciiwolf]

Package: freecad
Version: 0.16+dfsg2-2
Severity: normal

The FreeCAD package cannot be found and/or installed using GNOME Software 
because the icon file (that is required by AppStream to generate correct 
metadata) contained in the package is in a bad format (xpm instead of png or
svg).

https://appstream.debian.org/sid/main/issues/freecad.html

[Test Case]
1. Open the GNOME Software application.
2. Type "FreeCAD" into the search bar.

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

[Roland Hieber]

On 11.01.2017 08:56, Daniel Kahn Gillmor wrote:
> 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?

I'm using awesome, but that didn't seem to make a difference in the past :)

 - Roland

Bug#850948: [Piuparts-devel] Bug#850948: needrestart, piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Jonas Smedegaard]

Quoting Holger Levsen (2017-01-11 17:16:08)
> control: reassign -1 needrestart
> control: merge -1 826044
> thanks
> 
> On Wed, Jan 11, 2017 at 03:25:10PM +0100, Jonas Smedegaard wrote:
>> Package: needrestart,piuparts
>> Severity: serious
> 
> no. this is definitly not a serious bug in piuparts.

then the bug is somewhere else - merging ruins ability to track where.


>> This bugreport is tracking debian-design not entering testing.
>
> then this bug report would be more appropriate against release.d.o but
> Andreas already filed this bug :)

I believe I stated quite clearly the scope of this bug.

I fail to understand how merging with another (related) bug of different 
severity helps track the issue I reported?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Félix Sipma]

On 2017-01-11 11:27+0100, Adam Borowski wrote:
> 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.

There's a discussion about the licensing there:
https://github.com/Xaviju/inkscape-open-symbols/issues/61

I'm not sure about how inkscape-open-symbols could be licensed (for now it's
GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then,
what would be the difference with the Debian package?


signature.asc
Description: PGP signature

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Am 11.01.2017 um 18:28 schrieb Michael Biebl:
> Am 11.01.2017 um 18:25 schrieb Vincent Lefevre:
>> On 2017-01-11 18:09:51 +0100, Michael Biebl wrote:
>>> Am 11.01.2017 um 18:05 schrieb Michael Biebl:
 Why is this no normal shutdown?
>>
>> Services are not stopped as usual.
> 
> How do you conclude that?

And if something is killing the power midway through the shutdown
process, it's hardly something systemd can do about.

That said, so far this bug report is lacking crucial information why
this is supposed to be a systemd bug, even more a grave one.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850948: needrestart, piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Jonas Smedegaard]

Quoting Andreas Beckmann (2017-01-11 16:30:50)
> On 2017-01-11 15:25, Jonas Smedegaard wrote:
>
>> This bugreport is tracking debian-design not entering testing.
>
> I filed an unblock request for you, since that seems to be fallout 
> from britney evaluationg piuparts results, #850950
>
> I now managed to get the piuparts test to finish after removing 
> timeout from the command line ... strange ...
>
> after installing all the dependencies, we are finally installing 
> design-desktop:

That is great news.  All of it.  Thanks a lot for your help here!


> I'm not sure whether needrestart does the right thing here ...
> * it should adhere to policy-rc.d
> * it should not run missing binaries
> * it should be aware of being run in a chroot
>   (right now it enumerates all shells running in the host system ...)

Sounds suspect indeed.  I didn't dig deep - only reasoned from your 
earlier list of hanging process that it smells like policy-rc.d issue.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#850960: bzr: doesn't support SNI (breaks alioth.d.o)

[Asbjørn Sloth Tønnesen]

Package: bzr
Severity: normal

Hi,

Let's try to fetch the source for a Debian package:

> $ apt source sqsh
> Reading package lists... Done
> Selected version '2.1.7-4' (jessie) for sqsh
> NOTICE: 'sqsh' packaging is maintained in the 'Bzr' version control system at:
> nosmart+http://bzr.debian.org/bzr/users/vorlon/sqsh/trunk/
> Please use:
> bzr branch nosmart+http://bzr.debian.org/bzr/users/vorlon/sqsh/trunk/
> to retrieve the latest (possibly unreleased) updates to the package.
> Need to get 866 kB of source archives.
> Get:3 http://mirror.easyspeedy.com/debian jessie/main sqsh 2.1.7-4 (diff) 
> [70.5 kB]
> 13% [Working]^C

Non-git? Really? Well let's try to fetch it anyway:

> $ bzr branch nosmart+http://bzr.debian.org/bzr/users/vorlon/sqsh/trunk/
> nosmart+http://bzr.debian.org/bzr/users/vorlon/sqsh/trunk/ is redirected to 
> nosmart+https+urllib://bzr.debian.org/bzr/users/vorlon/sqsh/trunk/
> bzr: ERROR: ssl.CertificateError: hostname 'bzr.debian.org' doesn't match 
> either of '*.alioth.debian.org', 'alioth.debian.org'

Hmm. https://bzr.debian.org/ redirects to https://anonscm.debian.org/bzr/, 
let's try with that directly:

> $ bzr branch nosmart+https://anonscm.debian.org/bzr/users/vorlon/sqsh/trunk/
> bzr: ERROR: ssl.CertificateError: hostname 'anonscm.debian.org' doesn't match 
> either of '*.alioth.debian.org', 'alioth.debian.org'

I have verified with wireshark, that the root cause is that bzr doesn't set SNI 
in the TLS handshake.


Notes for fixing bzr access on alioth
=

A serverside fix for alioth, could be to have the Let's Encrypt cert without the
wildchar be the default, and then require SNI for getting the wildchar cert,
unless other stuff needs the wildchar to be the default non-SNI cert.

Workaround: fetching the repo through loggerhead works:
bzr branch https://alioth.debian.org/scm/loggerhead/users/vorlon/sqsh/trunk

So maybe just updating the text of https://anonscm.debian.org/bzr/?

-- 
Best regards
Asbjørn Sloth Tønnesen

Bug#850963: autopostgresqlbackup: fails with "cannot stat" message

[Lee Cremeans]

Package: autopostgresqlbackup
Version: 1.0-7
Severity: important
Tags: patch

Dear Maintainer,

I have autopostgresql set up on a server at my workplace to back up a small
PostgreSQL database to our mail server using the "files" option. However, I
noticed that backups were not running automatically. When I tried to run a
backup manually, I got this message:

Can't stat supp...@gtgi.com: No such file or directory
supp...@gtgi.com: unable to attach file.

Looking at automysqlbackup (which works properly in files mode on the same
machine), I was able to figure out that there was a parameter missing from
the
command line given to mutt. Adding the parameter makes autopostgresqlbackup
work again.

--- autopostgresqlbackup.orig   2015-05-17 07:48:38.0 -0400
+++ autopostgresqlbackup2017-01-11 11:33:39.390144526 -0500
@@ -642,7 +642,7 @@
elif which mutt >/dev/null 2>&1
then
BACKUPFILES=$(echo $BACKUPFILES | sed -e 's# # -a
#g')
-   mutt -s "PostgreSQL Backup Log and SQL Files for
$HOST
- $DATE" $BACKUPFILES $MAILADDR < $LOGFILE
+   mutt -s "PostgreSQL Backup Log and SQL Files for
$HOST
- $DATE" $BACKUPFILES -- $MAILADDR < $LOGFILE
else
cat "$LOGFILE" | mail -s "WARNING! - Enable to send
PostgreSQL Backup dumps, no suitable mail client found on $HOST - $DATE"
$MAILADDR
fi





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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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)

Versions of packages autopostgresqlbackup depends on:
ii  bsd-mailx [mailx] 8.1.2-0.20141216cvs-2
ii  postgresql-client-common  165+deb8u1

Versions of packages autopostgresqlbackup recommends:
ii  mutt 1.5.23-3
ii  openssl  1.0.1t-1+deb8u5

autopostgresqlbackup suggests no packages.

-- Configuration Files:
/etc/default/autopostgresqlbackup changed:
SU_USERNAME=postgres
USERNAME=postgres
DBHOST=localhost
DBNAMES="all"
GLOBALS_OBJECTS="postgres_globals"
BACKUPDIR="/var/lib/autopostgresqlbackup"
MAILCONTENT="files"
MAXATTSIZE="4000"
MAILADDR="supp...@gtgi.com"
MDBNAMES="template1 $DBNAMES"
DBEXCLUDE=""
CREATE_DATABASE=yes
SEPDIR=yes
DOWEEKLY=6
COMP=gzip
COMMCOMP=0
LATEST=no
OPT=""
EXT="sql"
PERM=600
ENCRYPTION=no
ENCRYPTION_PUBLIC_KEY="/etc/ssl/certs/autopostgresqlbackup.crt"
ENCRYPTION_CIPHER="aes256"
ENCRYPTION_SUFFIX=".enc"


-- no debconf information

Bug#829386: xorg: Xorg crashes

[Shérab]

Hi,

Samuel Thibault (2017/01/08 13:05 +0100):
> Control: tags -1 + patch fixed-upstream
> 
> Hello,
> 
> I have attached the upstream fix for this issue, to be applied to the
> xserver-xorg-input-libinput package. Could Jean-Philippe, Sebastien and
> Sebastian test it so that we can apply it to Debian before Stretch?

It works for me, thanks a lot for the hard work!

Shérab.

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

[Bogdan Vatra]

On miercuri, 11 ianuarie 2017 13:11:07 EET Felipe Sateler wrote:
> On 11 January 2017 at 13:05, Bogdan Vatra  wrote:
> > On miercuri, 11 ianuarie 2017 12:40:23 EET Felipe Sateler wrote:
> >> On 11 January 2017 at 12:37, Bogdan Vatra  wrote:
> >> > On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote:
> >> >> Control: tags -1 moreinfo unreproducible
> >> >> 
> >> >> On 11 January 2017 at 04:59, Bogdan Vatra  
wrote:
> >> >> > 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".
> >> >> 
> >> >> Weird. Could you repeat the same with the daemon as started by
> >> >> systemd?
> >> >> 
> >> >> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line.
> >> > 
> >> > It is the same thing ... :
> >> > [...]
> >> > ExecStart=/usr/lib/rtkit/rtkit-daemon
> >> > [...]
> >> > Actually I was inspired from that file to exec
> >> > "/usr/lib/rtkit/rtkit-daemon" manually :).
> >> 
> >> Sorry, I was not clear. I meant stracing the daemon.
> > 
> > Attached the log.
> 
> Hmm. I guess it's not my day, I can't explain myself :(
> 
> Please run the rtkit-daemon under strace, with systemd: edit the
> systemd service like so:
> 
> ExecStart=/usr/bin/strace -o /tmp/strace.log -ff /usr/lib/rtkit/rtkit-daemon
> 
> then do a `systemctl daemon-reload` and a restart of the rtkit-daemon.
> Then please attach the /tmp/strace.log.$PID file.

Ah, sorry probably is me not you.
I edit as you requested but there is not /tmp/strace.log file, this is the 
commands I used:

bogdan@zmeu:~$ sudo systemctl daemon-reload 
bogdan@zmeu:~$ sudo systemctl start rtkit-daemon
Job for rtkit-daemon.service failed because the control process exited with 
error code.
See "systemctl status rtkit-daemon.service" and "journalctl -xe" for details.
bogdan@zmeu:~$ systemctl status rtkit-daemon.service
● rtkit-daemon.service - RealtimeKit Scheduling Policy Service
   Loaded: loaded (/etc/systemd/system/rtkit-daemon.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-01-11 18:42:42 EET; 6s 
ago
  Process: 26573 ExecStart=/usr/bin/strace -o /tmp/strace.log -ff /usr/lib/
rtkit/rtkit-daemon (code=exited, status=1/FAILURE)
 Main PID: 26573 (code=exited, status=1/FAILURE)



What "Loaded: loaded (/etc/systemd/system/rtkit-daemon.service; disabled; 
vendor preset: enabled)" *disabled means in the log?

BogDan.

Bug#850969: mydumper: FTBFS everywhere: dh: unable to load addon sphinxdoc: Can't locate Debian/Debhelper/Sequence/sphinxdoc.pm in @INC

[Emilio Pozuelo Monfort]

Source: mydumper
Version: 0.9.1-2
Severity: serious

Hi,

Your package failed to build everywhere:

 fakeroot debian/rules clean
dh clean --with sphinxdoc
dh: unable to load addon sphinxdoc: Can't locate 
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: /etc/perl 
/usr/local/lib/aarch64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
/usr/lib/aarch64-linux-gnu/perl5/5.24 /usr/share/perl5 
/usr/lib/aarch64-linux-gnu/perl/5.24 /usr/share/perl/5.24 
/usr/local/lib/site_perl /usr/lib/aarch64-linux-gnu/perl-base) at (eval 12) 
line 2.
BEGIN failed--compilation aborted at (eval 12) line 2.

Sounds like a missing build-dep?

Logs at: https://buildd.debian.org/status/package.php?p=mydumper

Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Ben Hutchings]

On Wed, 2017-01-11 at 16:20 +0100, Vincent Lefevre wrote:
> On 2017-01-11 15:09:49 +, Ben Hutchings wrote:
> > Unless you can show that some data had been written *and flushed* to
> > disk by the application, but was not readable afterward - this does not
> > count.  Writes are buffered, and user space has to deal with that.
> 
> If I understand the journalctl log correctly, the system does
> a power off without a clean shutdown:

Sorry, I didn't understand what you were trying to point out in the
system log.  I had thought that pressing the power button was causing
an immediate power-off, but you're showing me that it results in a
resume immediately followed by a software-controlled shutdown.  Right?

It seems like there are two separate bugs:

1. Power button resumes and also generates a power-off input event
(kernel bug)
2. Some writes not flushed to disk during shutdown (probably a kernel
bug, but systemd could potentially break this)

> [...]
> Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
> Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
> Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color 
> Pro
> 
> then nothing after that!!! This is were the problem is, not in the
> application, which cannot know when the machine will power off.

That is why applications should flush writes before considering them
complete.  But in case of a software-controlled shutdown, all writes
sent to the kernel should get flushed even if applications don't
explicitly do so.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert
Coveyou



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

Bug#762734: gbp-pull support for git fetch --prune

[Guido Günther]

Hi Alex,
On Wed, Sep 24, 2014 at 09:44:20PM +0200, Alex Muntada wrote:
> Package: git-buildpackage
> Version: 0.6.19
> 
> After renaming the default debian branch from debian to master
> and the upstream branch from master to upstream on a pkg-perl
> team repository, we realized that the old debian remote branch
> would still be there in the working copies after gbp-pull.
> It would be nice to be able to ask for a "git fetch --prune"
> somehow.
> 
> Maybe it's safer to not enable this by default but having that
> option would help cleanup the working copies of several pkg-perl
> fellows.

Makes sense. We could add --prune command line option. Would be great if
someone could come up with a patch.
Cheers,
 -- Guido

> 
> Thanks!
> Alex

Bug#850961: RM: nvidia-settings/unstable-debug -- ROM; source in both main and contrib

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

For whatever reason, nvidia-settings has its source package
listed in both main and contrib, breaking the archive tools
(see #824169 for the similar problem in chocolate-doom) and
is therefore blocked from migrating to testing.

nvidia-settings | 375.26-1 | unstable | source
nvidia-settings | 375.26-1 | unstable-debug/contrib   | source
nvidia-settings | 375.26-2 | buildd-unstable  | source
nvidia-settings | 375.26-2 | unstable | source
nvidia-settings | 375.26-2 | unstable-debug/contrib   | source

I will upload a new version that does no longer build
the nvidia-settings-dbgsym/contrib binary package, which
should hopefully fix this issue. (Something similar seems
to work for boinc, which builds binary packages in both
main and contrib, but -dbgsym packages only in main.)

Since switching the archive area of packages usually is a bit
complictated, I'll wait for the "conflicting" source package
to be removed first.


Thanks

Andreas

Bug#832560: xserver-xorg-core: performance is very bad since using built-in modesetting 4th gen GMA on ivy bridge

[Andreas Boll]

On Sun, Aug 07, 2016 at 01:50:40PM +0200, Martin Dosch wrote:
> Am 02.08.2016 um 20:53 schrieb Julien Cristau:
> > Please show the output of dpkg -l '*mesa*', you seem to have some bits
> > from experimental, but possibly not all that's needed.  And please
> > attach your X log (after removing xorg.conf again), which should be in
> > ~/.local/share/xorg.
> 
> 
> Ok, it seems like libgbm1 was not yet installed from experimental which
> i did now.
> 
> Now it looks like this:
> 
> > dpkg -l '*mesa*'
> > Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
> > | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
> >  Halb installiert/Trigger erWartet/Trigger anhängig
> > |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: 
> > GROSS=schlecht)
> > ||/ NameVersion  Architektur  Beschreibung
> > +++-===---===
> > ii  libegl1-mesa:amd64  12.0.1-3 amd64free 
> > implementation of the EGL API -- runtime
> > un  libegl1-mesa-drivers(keine 
> > Beschreibung vorhanden)
> > ii  libgl1-mesa-dri:amd64   12.0.1-3 amd64free 
> > implementation of the OpenGL API -- DRI module
> > ii  libgl1-mesa-dri:i38612.0.1-3 i386 free 
> > implementation of the OpenGL API -- DRI module
> > un  libgl1-mesa-dri-experim (keine 
> > Beschreibung vorhanden)
> > ii  libgl1-mesa-glx:amd64   12.0.1-3 amd64free 
> > implementation of the OpenGL API -- GLX runtim
> > ii  libgl1-mesa-glx:i38612.0.1-3 i386 free 
> > implementation of the OpenGL API -- GLX runtim
> > ii  libglapi-mesa:amd64 12.0.1-3 amd64free 
> > implementation of the GL API -- shared library
> > ii  libglapi-mesa:i386  12.0.1-3 i386 free 
> > implementation of the GL API -- shared library
> > ii  libgles1-mesa:amd64 12.0.1-3 amd64free 
> > implementation of the OpenGL|ES 1.x API -- run
> > ii  libgles2-mesa:amd64 12.0.1-3 amd64free 
> > implementation of the OpenGL|ES 2.x API -- run
> > ii  libglu1-mesa:amd64  9.0.0-2.1amd64Mesa OpenGL 
> > utility library (GLU)
> > ii  libwayland-egl1-mesa:am 12.0.1-3 amd64
> > implementation of the Wayland EGL platform -- runti
> > ii  mesa-utils  8.3.0-1  amd64Miscellaneous 
> > Mesa GL utilities
> > ii  mesa-utils-extra8.3.0-1  amd64Miscellaneous 
> > Mesa utilies (opengles, egl)
> > ii  mesa-va-drivers:amd64   12.0.1-3 amd64Mesa VA-API 
> > video acceleration drivers
> > ii  mesa-vdpau-drivers:amd6 12.0.1-3 amd64Mesa VDPAU 
> > video acceleration drivers
> > ii  mesa-vulkan-drivers 12.0.1-3 amd64Mesa Vulkan 
> > graphics drivers
> > un  mesag3  (keine 
> > Beschreibung vorhanden)
> > un  xlibmesa3   (keine 
> > Beschreibung vorhanden)
> 
> Right now I can't afford restarting X but I'll do later and have a look
> if it will work now.
> 
> Best regards,
> Martin
> 

Hi,

did you have a chance to restart your X session?
Is this still an issue?

Thanks,
Andreas


signature.asc
Description: Digital signature

Bug#850966: Please support ftp search with version number only in the directory name

[Ole Streicher]

Package: devscripts
Severity: wishlist
User: devscri...@packages.debian.org
Usertags: uscan


I have the following sample download URL

ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v3.0-9/stilts_src.zip

Corresponding Debian version number should be 3.0.9.

There is currently no way to get this downloaded via uscan. I tried

version=3
options="uversionmangle=s/\-/./,filenamemangle=s/\/$/.zip/" \
ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v([\d\.\-]+)/ stilts_src.zip

but it doesn't work; basically it adjusts upstream version to be 1:

uscan info: Newest upstream tarball version selected for download 
(uversionmangled): 1

Bug#725747: xserver-xorg-core: Using PRIME providers when discreet card is set to be primary leads to xserver crash

[Andreas Boll]

Control: tag -1 moreinfo

On Tue, Oct 08, 2013 at 02:16:10AM +0300, Pauli wrote:
> Package: xserver-xorg-core
> Version: 2:1.14.3-3
> Severity: normal
> Tags: upstream patch
> 
> Dear Maintainer,
> 
> With hydrid graphics laptop I had started X with discreet radein set as
> primary card using vgaswitcheroo. During that run I ended up trying to
> enable PRIME offloading to radeon:
> 
> xrandr --setprovideroutputsource radeon Intel
> 
> That led to following crash:
> #0  0x7ff44fd431e5 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x7ff44fd46398 in __GI_abort () at abort.c:90
> #2  0x7ff44fd3c272 in __assert_fail_base (fmt=0x7ff44fe799c0 "%s%s%s:%u: 
> %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ff452186ce7 
> "slave->isGPU", 
> file=file@entry=0x7ff452186cb2 "../../dix/dispatch.c", 
> line=line@entry=3937, function=function@entry=0x7ff452186d80 
> <__PRETTY_FUNCTION__.17904> "DetachUnboundGPU")
> at assert.c:92
> #3  0x7ff44fd3c322 in __GI___assert_fail 
> (assertion=assertion@entry=0x7ff452186ce7 "slave->isGPU", 
> file=file@entry=0x7ff452186cb2 "../../dix/dispatch.c", 
> line=line@entry=3937, function=function@entry=0x7ff452186d80 
> <__PRETTY_FUNCTION__.17904> "DetachUnboundGPU") at assert.c:101
> #4  0x7ff45202b2f0 in DetachUnboundGPU (slave=slave@entry=0x7ff45429c0d0) 
> at ../../dix/dispatch.c:3937
> #5  0x7ff4520a77fd in xf86RandR14ProviderSetOffloadSink 
> (pScreen=0x7ff45429c0d0, provider=0x7ff4526ece20, 
> sink_provider=0x7ff45428f970)
> at ../../../../hw/xfree86/modes/xf86RandR12.c:1821
> #6  0x7ff4520ec911 in ProcRRSetProviderOffloadSink (client= out>) at ../../randr/rrprovider.c:338
> #7  0x7ff45202ad6e in Dispatch () at ../../dix/dispatch.c:432
> #8  0x7ff45201a2ca in main (argc=10, argv=0x7fff78e24868, envp= out>) at ../../dix/main.c:298
> 
> Problem is missing check that provider is actually configured as offscreen
> card in protocol request validation.
> 
> Attached patch adds the missing check to the protocol layer to avoid
> server from asserting.
> 

Hi,

is this still an issue with a newer xserver-xorg-core version (e.g.
the version from jessie or stretch/sid)?

Thanks,
Andreas

> diff --git a/randr/rrprovider.c b/randr/rrprovider.c
> index b321e62..53a610a 100644
> --- a/randr/rrprovider.c
> +++ b/randr/rrprovider.c
> @@ -291,6 +291,8 @@ ProcRRSetProviderOutputSource(ClientPtr client)
>  
>  if (!(provider->capabilities & RR_Capability_SinkOutput))
>  return BadValue;
> +if (!provider->pScreen->isGPU)
> +return BadValue;
>  
>  if (stuff->source_provider) {
>  VERIFY_RR_PROVIDER(stuff->source_provider, source_provider, 
> DixReadAccess);
> @@ -322,6 +324,8 @@ ProcRRSetProviderOffloadSink(ClientPtr client)
>  VERIFY_RR_PROVIDER(stuff->provider, provider, DixReadAccess);
>  if (!(provider->capabilities & RR_Capability_SourceOffload))
>  return BadValue;
> +if (!provider->pScreen->isGPU)
> +return BadValue;
>  
>  if (stuff->sink_provider) {
>  VERIFY_RR_PROVIDER(stuff->sink_provider, sink_provider, 
> DixReadAccess);



signature.asc
Description: Digital signature

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Am 11.01.2017 um 17:05 schrieb Vincent Lefevre:
> Control: clone -1 -2
> Control: reassign -2 systemd 232-8
> Control: retitle -2 systemd: power off without always a normal shutdown when 
> resuming after suspend with the power button
> Control: severity -2 grave
> 
> as the lack of shutdown yields visible file corruption and potentially
> data loss.
> 
> On 2017-01-11 16:20:35 +0100, Vincent Lefevre wrote:
>> On 2017-01-11 15:09:49 +, Ben Hutchings wrote:
>>> Unless you can show that some data had been written *and flushed* to
>>> disk by the application, but was not readable afterward - this does not
>>> count.  Writes are buffered, and user space has to deal with that.
>>
>> If I understand the journalctl log correctly, the system does
>> a power off without a clean shutdown:
>>
>> [...]
>> Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
>> Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
>> Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color 
>> Pro
>>
>> then nothing after that!!! This is where the problem is, not in the
>> application, which cannot know when the machine will power off.
> 
> Well, there are two problems:
> 
> 1. The fact that the system powers down instead of just resuming.
>systemd-logind reports "Power key pressed." but the power key
>was used to resume, so that I suppose that systemd-logind
>should have never seen this.
> 
> 2. The fact that the system is powered off immediately without a
>clean shutdown. When I use the power button to power off the
>laptop, I get:
> 
> Sep 17 19:36:13 zira systemd-logind[17281]: Power key pressed.
> Sep 17 19:36:13 zira systemd-logind[17281]: Powering Off...
> Sep 17 19:36:13 zira systemd-logind[17281]: System is powering down.
> Sep 17 19:36:13 zira systemd[1]: Stopped target Bluetooth.
> Sep 17 19:36:13 zira systemd[1]: Stopping Session 2041 of user vinc17.
> Sep 17 19:36:13 zira systemd[1]: Deactivating swap 
> /dev/disk/by-id/dm-uuid-LVM-K
> Sep 17 19:36:13 zira systemd[1]: Stopping Disk Manager...
> [...]
> 
> i.e. a normal shutdown, but when this is used just after a suspend
> in order to resume, I *occasionally* get (well, this occurred only
> twice):
> 
> Jul 25 17:15:17 zira systemd-logind[769]: Power key pressed.
> Jul 25 17:15:17 zira systemd-logind[769]: Powering Off...
> Jul 25 17:15:17 zira systemd-logind[769]: System is powering down.
> -- Reboot --
> 
> Dec 23 10:51:01 zira systemd-logind[803]: Power key pressed.
> Dec 23 10:51:01 zira systemd-logind[803]: Powering Off...
> Dec 23 10:51:01 zira systemd-logind[803]: System is powering down.
> Dec 23 10:51:01 zira systemd[1]: Stopping Manage, Install and Generate Color 
> Pro
> -- Reboot --
> 
> No normal shutdown!
> 

Why is this no normal shutdown?
Did you actually have a file corruption?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850703: systemd: incorrect LSB support with monit's init script

[Michael Biebl]

Am 09.01.2017 um 16:41 schrieb Martin Pitt:
> Hello Vincent,
> 
> Vincent Lefevre [2017-01-09 15:15 +0100]:
>> The monit service (from the monit package) should be started last and
>> stopped first. This is not the case with systemd.
>>
>> # Should-Start:  $all
>> # Should-Stop:   $all
> 
> Please note that the SysV concept of "$all" is notoriously broken (what if
> another package uses $all too?), and cannot be represented sensibly in any
> non-serial init system (systemd, upstart, and even sysv with startpar). If
> monit needs to start/stop after/before other services, these should be
> enumerated explicitly.
> 
> That said, the SysV generator could approximate this a bit better by running
> "After=multi-user.target" instead of "Before=multi-user.target", i. e. similar
> to Type=idle.

So, we discussed this on IRC.
To add support for $all in the sysv-generator, we'd have to special case
it at various places as we already have an After=multi-user.target
ordering. This is quite ugly. And it wouldn't be a real fix anyway.

Given that we only have a handful of packages left which use $all, our
time is better spent if those few packages add native service files.

Please consider filing a bug report against monit for that.

I'll keep this bug report open for a while. Maybe someone has an idea
how to implement this cleanly. In which case we'd be fine with applying it.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850970: pvpgn: switch to build depend on the metapackage default-libmysqlclient-dev

[Emilio Pozuelo Monfort]

Package: pvpgn
Version: 1.8.5-2
Severity: serious
User: pkg-mysql-ma...@lists.alioth.debian.org
Usertags: default-mysql

Hi,

This package build depends on libmysqlclient-dev. It should instead
build-depend on default-libmysqlclient-dev metapackage, and end up
having the run-time dependency of the libmysqlclient implementation
Debian has chosen to use, currently MariaDB instead of Oracle MySQL.

Announcement of new default-mysql-* metapackages:
https://lists.debian.org/debian-devel-announce/2016/09/msg0.html

Wiki: https://wiki.debian.org/Teams/MySQL/default-mysql-server

MBF: https://lists.debian.org/debian-devel/2016/11/msg00832.html

Please update the depencies accordingly. In most cases the required
change is:

* BEFORE: Build-Depends: libmysqlclient-dev

* AFTER: Build-Depends: default-libmysqlclient-dev

Cheers,
Emilio


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Bug#848978: removal of src:courier *now* probably a diservice to our users

[Ondřej Surý]

Hi Holger,

the courier packages are therefore your responsibility and I am going to 
forward you all the hate mail I might.


Just make sure that courier, courier-authlib and courier-unicode migrate, 
so the maintainer is set to Debian QA.


O.


On 11 January 2017 18:09:43 Holger Levsen  wrote:


control: severity -1 important

Hi Ondřej,

first of all, thanks for all your work on courier, despite not even
using it!

Second, I think I disagree with your conclusion (from December 26th
2016!) that courier should be removed from Debian because it currently
doesnt have a maintainer. courier has a large userbase still, which many
old setups, which are sometimes hard to migrate… thus I think removing
it from stretch now would really be painful for many people (it still
has a high popcon, even though ists declining) and as such I'll
downgrade #848978 accordingly, also because it has no other RC bugs.

cc:ing the release team so they are aware of this.


--
cheers,
Holger, also a courier user but not captable of taking this
package…

Bug#850971: openstack-trove: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: openstack-trove
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#850181: plymouth theme(s) should provide fsck progress support

[Aurélien COUDERC]

Le 10 janvier 2017 17:28:46 GMT+05:30, Michael Biebl  a écrit 
:

>I've tested all three themes, they worked fine with one or multiple
>fscks running at the same time. I've attached a screenshot for each of
>them. A few suggestions:
>a/ Joy looks ok
>b/ Lines:
>  - The text is not horizontally aligned (centered)
> - The text should probably be moved lower so it doesn't intersect with
>the lines graphic
>c/ softwaves:
>- The text should be moved lower so it doesn't intersect with the
>circle

Which resolution would that be ?


Thanks,
--Aurélien

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

[Werner Koch]

On Wed, 11 Jan 2017 12:22, vinc...@vinc17.net said:

> This wasn't the problem. The problem was the incorrect error code:
> GDK_GRAB_NOT_VIEWABLE instead of GDK_GRAB_ALREADY_GRABBED

I do not think this is tan incorrect error code but we should look at
GDK_GRAB_ALREADY_GRABBED too:

  /* Change the cursor for the duration of the grab to indicate that
   * something is going on.  The fvwm window manager grabs the pointer
   * for a short time and thus we may end up with the already grabbed
   * error code.  Actually this error code should be used to detect a
   * malicious grabbing application but with fvwm this renders
   * Pinentry only unusable.  Thus we try again several times also for
   * that error code.  See Debian bug 850708 for details.  */



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
From f7ceec0fea9f7f2043b835bbe70fc8b1a91d8770 Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Wed, 11 Jan 2017 18:40:17 +0100
Subject: [PATCH] gtk2: Fix a problem with fvwm

* gtk+-2/pinentry-gtk-2.c (grab_pointer): Take care of
GDK_GRAB_ALREADY_GRABBED.
--

Debian-bug-id: 850708
Co-authored-by: Vincent Lefevre 
Signed-off-by: Werner Koch 
---
 gtk+-2/pinentry-gtk-2.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c
index 473c4aa..e37601f 100644
--- a/gtk+-2/pinentry-gtk-2.c
+++ b/gtk+-2/pinentry-gtk-2.c
@@ -203,7 +203,12 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer data)
   (void)data;
 
   /* Change the cursor for the duration of the grab to indicate that
- something is going on.  */
+   * something is going on.  The fvwm window manager grabs the pointer
+   * for a short time and thus we may end up with the already grabbed
+   * error code.  Actually this error code should be used to detect a
+   * malicious grabbing application but with fvwm this renders
+   * Pinentry only unusable.  Thus we try again several times also for
+   * that error code.  See Debian bug 850708 for details.  */
   /* XXX: It would be nice to have a key cursor, unfortunately there
  is none readily available.  */
   cursor = gdk_cursor_new_for_display (gtk_widget_get_display (win),
@@ -215,7 +220,8 @@ grab_pointer (GtkWidget *win, GdkEvent *event, gpointer data)
 NULL /* confine to */,
 cursor,
 gdk_event_get_time (event));
-  while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE);
+  while (tries++ < max_tries && (err == GDK_GRAB_NOT_VIEWABLE
+ || err == GDK_GRAB_ALREADY_GRABBED));
 
   if (err)
 {
-- 
2.8.1



pgpGXGHrNg0OS.pgp
Description: PGP signature

Bug#848978: removal of src:courier *now* probably a diservice to our users

[Holger Levsen]

Hi Ondřej,

On Wed, Jan 11, 2017 at 06:38:52PM +0100, Ondřej Surý wrote:
> the courier packages are therefore your responsibility and I am going to
> forward you all the hate mail I might.
 
ok, please do! :)

> Just make sure that courier, courier-authlib and courier-unicode migrate, so
> the maintainer is set to Debian QA.
 
that already happened.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#846627: Debian RT: systemd v230 in backports writes incorrect transient scope

[Dao Quang Minh]

Hi Michael,

If you have some instructions on how to build the compatible systemd
package for debian-backports, i can probably spend sometime trying to
upgrade it to a newer version.

Regards,
Daniel.

On Mon, Dec 5, 2016 at 10:36 AM, Dao Quang Minh  wrote:

> Hi
>
> > I assume you tested with 232 to verify that this is fixed by a newer
> upstream release.
>
> I tested on 232 and this was fixed as well.
>
> On Fri, Dec 2, 2016 at 10:17 PM, Michael Biebl  wrote:
>
>> Hi,
>>
>> thanks for your interest in systemd.
>>
>> Am 02.12.2016 um 19:57 schrieb Dao Quang Minh:
>> > I suggest that we bump systemd in backports to v231 or somehow backport
>> > relevant patches.
>>
>> I assume you tested with 232 to verify that this is fixed by a newer
>> upstream release.
>>
>> I'd love to see a newer version it backports. Last time this effort was
>> spear-headed by Michael Prokop during debconf. Would be great if we can
>> get some help with this (again).
>>
>> Regards,
>> Michael
>>
>> --
>> Why is it that all of the instruments seeking intelligent life in the
>> universe are pointed away from Earth?
>>
>>
>

Bug#850181: plymouth theme(s) should provide fsck progress support

[Michael Biebl]

Am 11.01.2017 um 18:46 schrieb Aurélien COUDERC:
> 
> 
> Le 10 janvier 2017 17:28:46 GMT+05:30, Michael Biebl  a 
> écrit :
> 
>> I've tested all three themes, they worked fine with one or multiple
>> fscks running at the same time. I've attached a screenshot for each of
>> them. A few suggestions:
>> a/ Joy looks ok
>> b/ Lines:
>>  - The text is not horizontally aligned (centered)
>> - The text should probably be moved lower so it doesn't intersect with
>> the lines graphic
>> c/ softwaves:
>> - The text should be moved lower so it doesn't intersect with the
>> circle
> 
> Which resolution would that be ?

1920x1200


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#848709: xserver-xorg-video-geode-dbg: depends on xserver-xorg-core-dbg, which is no longer built

[Emilio Pozuelo Monfort]

Sorry for the delay, your mail got caught by the spam filter.

On 19/12/16 20:25, Martin-Éric Racine wrote:
> 2016-12-19 20:26 GMT+02:00 Emilio Pozuelo Monfort :
>> Package: xserver-xorg-video-geode-dbg
>> Version: 2.11.18-2
>> Severity: serious
>>
>> Hi,
>>
>> x-x-v-geode-dbg depends on xserver-xorg-core-dbg, but we no longer build
>> that, and rely on debhelper creating dbgsym packages instead. Thus, please
>> drop that dependency. Bonus points if you switch to -dbgsym packages too. :)
> 
> Thanks for the heads up.
> 
> Now, what I'm wondering is how that constitues a sufficient reason for
> Severity:serious?

xserver-xorg-core-dbg no longer exist, so your package was uninstallable. Thanks
for the prompt fix!

Emilio

Bug#820322: X crashes using modesetting driver

[Andreas Boll]

On Mon, May 30, 2016 at 03:26:10PM +0200, Reinhard Karcher wrote:
> reassign src:linux
> fixed-upstream 4.7-rc1
> thanks
> 
> Using a selfcompiled kernel 4.7-rc1, the crash disappeared.
> 
> Reinhard

Is this still an issue with a Debian linux kernel >= 4.7

Thanks,
Andreas


signature.asc
Description: Digital signature

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

[Julien Cristau]

On Tue, Jan 10, 2017 at 16:56:05 -0500, Sam Hartman wrote:

> 
> Hi.
> I'd really appreciate comments from debian-release on this issue.
> Would debian-release like us to take this up?
> If so, I have a proposal for how to fast-track this situation, but I am
> only comfortable doing that if the release team is involved.
> 
Hi Sam,

I was actually about to involve the TC (from a release management
perspective) when Lisandro did.

Here's a timeline I think summarizes events ttbomk:
- on 31 October 2016, the release team finalized the list of release
  architectures for stretch, including mips, mipsel and mips64el
- on 2 November 2016, the binutils maintainer switch from the upstream
  2.27 branch to upstream trunk, which caused a number of regressions
- on 5 November 2016 was the transition freeze for stretch, which is
  intended to reduce the amount of churn affecting many packages at once
- one of the regressions is still unfixed to this day, and blocks a
  number of package migrations to testing, including library transitions
  and RC bug fixes, to the point that if it doesn't get fixed in the
  next few days the options are to either delay the stretch freeze
  (planned for 5 February) or drop three architectures from stretch; I
  feel like a freeze delay might end up being necessary due to this bug
  anyway, even if it does get fixed now
- early this week Lisandro finally NMUed with a patch for this bug, only
  to be promptly reverted by the maintainer

I think it's way past time we fixed this, to avoid any further harm to
the stretch release.  That may mean reverting to the 2.27 branch,
reverting specific changes from our 2.28 branch snapshot, or applying a
proposed fix ahead of upstream, I'm not picky about specifics.  Help
from the TC in getting to a quick resolution would be very much welcome.

Thanks,
Julien


signature.asc
Description: PGP signature

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Vincent Lefevre]

On 2017-01-11 18:36:30 +0100, Michael Biebl wrote:
> Am 11.01.2017 um 18:28 schrieb Michael Biebl:
> > Am 11.01.2017 um 18:25 schrieb Vincent Lefevre:
> >> On 2017-01-11 18:09:51 +0100, Michael Biebl wrote:
> >>> Am 11.01.2017 um 18:05 schrieb Michael Biebl:
>  Why is this no normal shutdown?
> >>
> >> Services are not stopped as usual.
> > 
> > How do you conclude that?

There is no log for stopped services in the journald logs.

> And if something is killing the power midway through the shutdown
> process, it's hardly something systemd can do about.

What would kill the power?

> That said, so far this bug report is lacking crucial information why
> this is supposed to be a systemd bug,

What info do you need?

> even more a grave one.

There is file corruption (not just theoretical, it really happened
in practice).

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

Bug#850972: firefox: FTBFS: configure: error: cannot determine icu version number from uvernum.h header file

[Lucas Nussbaum]

Source: firefox
Version: 50.1.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):
> checking for fontconfig/fcfreetype.h... yes
> checking for fontconfig >= 2.7.0... yes
> checking _FONTCONFIG_CFLAGS... -I/usr/include/freetype2
> checking _FONTCONFIG_LIBS... -lfontconfig -lfreetype
> sed: character class syntax is [[:space:]], not [:space:]
> configure: error: cannot determine icu version number from uvernum.h header 
> file 
> DEBUG: 
> DEBUG: configure:20795: checking GLIB_LIBS
> DEBUG: configure:20902: checking for freetype2 >= 6.1.0
> DEBUG: configure:20909: checking FT2_CFLAGS
> DEBUG: configure:20914: checking FT2_LIBS
> DEBUG: configure:20951: checking for FT_Bitmap_Size.y_ppem
> DEBUG: configure:20966: /usr/bin/gcc -std=gnu99 -c -fstack-protector-strong 
> -Wformat -Werror=format-security -fno-schedule-insns2 
> -fno-delete-null-pointer-checks -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -I/usr/include/freetype2 
> -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> DEBUG: configure:20995: checking for FT_GlyphSlot_Embolden
> DEBUG: configure:21027: /usr/bin/gcc -std=gnu99 -o conftest 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-schedule-insns2 -fno-delete-null-pointer-checks -fno-strict-aliasing 
> -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe 
> -I/usr/include/freetype2 -Wdate-time -D_FORTIFY_SOURCE=2 -lpthread 
> -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory 
> -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id conftest.c -ldl  
> -lfreetype 1>&5
> DEBUG: /usr/bin/ld: total time in link: 0.024000
> DEBUG: /usr/bin/ld: data size 4583424
> DEBUG: configure:20995: checking for FT_Load_Sfnt_Table
> DEBUG: configure:21027: /usr/bin/gcc -std=gnu99 -o conftest 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-schedule-insns2 -fno-delete-null-pointer-checks -fno-strict-aliasing 
> -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe 
> -I/usr/include/freetype2 -Wdate-time -D_FORTIFY_SOURCE=2 -lpthread 
> -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory 
> -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id conftest.c -ldl  
> -lfreetype 1>&5
> DEBUG: /usr/bin/ld: total time in link: 0.024000
> DEBUG: /usr/bin/ld: data size 4583424
> DEBUG: configure:21065: checking for fontconfig/fcfreetype.h
> DEBUG: configure:21078: /usr/bin/gcc -std=gnu99 -c -fstack-protector-strong 
> -Wformat -Werror=format-security -fno-schedule-insns2 
> -fno-delete-null-pointer-checks -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 -I/usr/include/freetype2  conftest.c 1>&5
> DEBUG: configure:21129: checking for fontconfig >= 2.7.0
> DEBUG: configure:21136: checking _FONTCONFIG_CFLAGS
> DEBUG: configure:21141: checking _FONTCONFIG_LIBS
> DEBUG: configure: error: cannot determine icu version number from uvernum.h 
> header file
> ERROR: old-configure failed
> debian/rules:215: recipe for target 'stamps/configure-browser' failed
> make[2]: *** [stamps/configure-browser] Error 1
> make[2]: Leaving directory '/<>'
> debian/rules:388: recipe for target 'build-arch' failed
> make[1]: *** [build-arch] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:388: recipe for target 'build' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/firefox_50.1.0-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#850974: supermin: FTBFS: build-dependency not installable: libc6-dev-bin

[Lucas Nussbaum]

Source: supermin
Version: 5.1.17-5
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):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper (>= 9), dh-autoreconf, libc6-dev-bin, gawk, 
> pkg-config, apt, ocaml-nox, ocaml-findlib, dh-ocaml, perl, comerr-dev, 
> e2fslibs-dev, cpio, musl-tools, augeas-tools, libhivex-bin, linux-image-amd64
> Filtered Build-Depends: debhelper (>= 9), dh-autoreconf, libc6-dev-bin, gawk, 
> pkg-config, apt, ocaml-nox, ocaml-findlib, dh-ocaml, perl, comerr-dev, 
> e2fslibs-dev, cpio, musl-tools, augeas-tools, libhivex-bin, linux-image-amd64
> dpkg-deb: building package 'sbuild-build-depends-supermin-dummy' in 
> '/<>/resolver-K138Q2/apt_archive/sbuild-build-depends-supermin-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> sbuild-build-depends-supermin-dummy
> dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> Ign:1 copy:/<>/resolver-K138Q2/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-K138Q2/apt_archive ./ Release [963 B]
> Ign:3 copy:/<>/resolver-K138Q2/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-K138Q2/apt_archive ./ Sources [777 B]
> Get:5 copy:/<>/resolver-K138Q2/apt_archive ./ Packages [677 B]
> Fetched 2417 B in 0s (233 kB/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
> 
> Install supermin build dependencies (apt-based resolver)
> 
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-supermin-dummy : Depends: libc6-dev-bin but it is not 
> installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/supermin_5.1.17-5_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#850973: python-shogun: FTBFS: build-dependency not installable: libshogun-dev (>= 3.2.0~)

[Lucas Nussbaum]

Source: python-shogun
Version: 3.2.0-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):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: libatlas-base-dev | liblapack-dev, libeigen3-dev, 
> debhelper (>= 9), libreadline-dev | libreadline5-dev, libblas-dev, 
> libglpk-dev, libnlopt-dev, libshogun-dev (>= 3.2.0~), liblzo2-dev, 
> zlib1g-dev, liblzma-dev, libxml2-dev, libjson-c-dev | libjson0-dev, cmake, 
> libarpack2-dev, libsnappy-dev, libhdf5-dev (>= 1.8.8~) | libhdf5-serial-dev, 
> swig3.0 (>= 3.0.2-1~), python-numpy (>= 1:1.7.1-1~), python-all-dev (>= 
> 2.7.0-1~), libprotobuf-dev, protobuf-compiler, libcurl4-gnutls-dev, 
> libbz2-dev, libcolpack-dev
> Filtered Build-Depends: libatlas-base-dev, libeigen3-dev, debhelper (>= 9), 
> libreadline-dev, libblas-dev, libglpk-dev, libnlopt-dev, libshogun-dev (>= 
> 3.2.0~), liblzo2-dev, zlib1g-dev, liblzma-dev, libxml2-dev, libjson-c-dev, 
> cmake, libarpack2-dev, libsnappy-dev, libhdf5-dev (>= 1.8.8~), swig3.0 (>= 
> 3.0.2-1~), python-numpy (>= 1:1.7.1-1~), python-all-dev (>= 2.7.0-1~), 
> libprotobuf-dev, protobuf-compiler, libcurl4-gnutls-dev, libbz2-dev, 
> libcolpack-dev
> dpkg-deb: building package 'sbuild-build-depends-python-shogun-dummy' in 
> '/<>/resolver-usuT83/apt_archive/sbuild-build-depends-python-shogun-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> sbuild-build-depends-python-shogun-dummy
> dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> Ign:1 copy:/<>/resolver-usuT83/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-usuT83/apt_archive ./ Release [963 B]
> Ign:3 copy:/<>/resolver-usuT83/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-usuT83/apt_archive ./ Sources [756 B]
> Get:5 copy:/<>/resolver-usuT83/apt_archive ./ Packages [761 B]
> Fetched 2480 B in 0s (232 kB/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
> 
> Install python-shogun build dependencies (apt-based resolver)
> -
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-python-shogun-dummy : Depends: libshogun-dev (>= 
> 3.2.0~) but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/python-shogun_3.2.0-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#850975: sorl-thumbnail: FTBFS: unsatisfiable build-dependencies: python-wand, python3-wand

[Lucas Nussbaum]

Source: sorl-thumbnail
Version: 12.3+git20160928-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):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper (>= 9), dh-python, graphicsmagick, 
> imagemagick, locales, lsof, python-all, python-django, python-pil, 
> python-pgmagick, python-pytest, python-pytest-django, python-setuptools, 
> python-wand, python3-all, python3-django, python3-pil, python3-pytest, 
> python3-pytest-django, python3-setuptools, python3-wand, python-sphinx (>= 
> 1.0.7+dfsg)
> Merged Build-Conflicts: locales-all (<< 2.21-1)
> Filtered Build-Depends: debhelper (>= 9), dh-python, graphicsmagick, 
> imagemagick, locales, lsof, python-all, python-django, python-pil, 
> python-pgmagick, python-pytest, python-pytest-django, python-setuptools, 
> python-wand, python3-all, python3-django, python3-pil, python3-pytest, 
> python3-pytest-django, python3-setuptools, python3-wand, python-sphinx (>= 
> 1.0.7+dfsg)
> Filtered Build-Conflicts: locales-all (<< 2.21-1)
> dpkg-deb: building package 'sbuild-build-depends-sorl-thumbnail-dummy' in 
> '/<>/resolver-rhhBir/apt_archive/sbuild-build-depends-sorl-thumbnail-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> sbuild-build-depends-sorl-thumbnail-dummy
> dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> Ign:1 copy:/<>/resolver-rhhBir/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-rhhBir/apt_archive ./ Release [963 B]
> Ign:3 copy:/<>/resolver-rhhBir/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-rhhBir/apt_archive ./ Sources [634 B]
> Get:5 copy:/<>/resolver-rhhBir/apt_archive ./ Packages [715 B]
> Fetched 2312 B in 0s (0 B/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
> 
> Install sorl-thumbnail build dependencies (apt-based resolver)
> --
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-sorl-thumbnail-dummy : Depends: python-wand but it is 
> not going to be installed
>  Depends: python3-wand but it is 
> not going to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   
http://aws-logs.debian.net/2017/01/11/sorl-thumbnail_12.3+git20160928-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#850976: firefox-esr: FTBFS: configure: error: cannot determine icu version number from uvernum.h header file

[Lucas Nussbaum]

Source: firefox-esr
Version: 45.6.0esr-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):
> checking for stdint.h... yes
> checking for inttypes.h... yes
> checking for posix_fadvise... yes
> checking for posix_fallocate... yes
> sed: character class syntax is [[:space:]], not [:space:]
> configure: error: cannot determine icu version number from uvernum.h header 
> file 
> -- config.log --
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 4583424
> configure:27972: checking for FT_Load_Sfnt_Table
> configure:28004: gcc -o conftest -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-schedule-insns2 -fno-delete-null-pointer-checks 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -I/usr/include/freetype2 
> -Wdate-time -D_FORTIFY_SOURCE=2 -lpthread  -Wl,--as-needed 
> -Wl,--reduce-memory-overheads -Wl,--no-keep-memory -Wl,--stats 
> -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id conftest.c -ldl  -lfreetype 1>&5
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 4583424
> configure:28042: checking for fontconfig/fcfreetype.h
> configure:28055: gcc -c -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-schedule-insns2 -fno-delete-null-pointer-checks 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 -I/usr/include/freetype2  conftest.c 1>&5
> configure:28145: checking for fontconfig
> configure:28152: checking _FONTCONFIG_CFLAGS
> configure:28157: checking _FONTCONFIG_LIBS
> configure:28346: checking for stdint.h
> configure:28359: gcc -c -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-schedule-insns2 -fno-delete-null-pointer-checks 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:28346: checking for inttypes.h
> configure:28359: gcc -c -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-schedule-insns2 -fno-delete-null-pointer-checks 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:29789: checking for posix_fadvise
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-schedule-insns2 -fno-delete-null-pointer-checks -std=gnu99 
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections 
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 -lpthread  
> -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory 
> -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id conftest.c -ldl  
> 1>&5
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 4329472
> configure:29789: checking for posix_fallocate
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-schedule-insns2 -fno-delete-null-pointer-checks -std=gnu99 
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections 
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 -lpthread  
> -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory 
> -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id conftest.c -ldl  
> 1>&5
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 4333568
> configure:29875: gcc -c -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-schedule-insns2 -fno-delete-null-pointer-checks -std=gnu99 
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections 
> -fno-math-errno -pthread -pipe  -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 
> 1>&5
> configure: error: cannot determine icu version number from uvernum.h header 
> file 
> debian/rules:223: recipe for target 'stamps/configure-browser' failed
> make[1]: *** [stamps/configure-browser] Error 1
> make[1]: Leaving directory '/<>'
> debian/rules:381: recipe for target 'build' failed

The full build log is available from:
   http://aws-logs.deb

Bug#850977: willow: FTBFS: build-dependency not installable: python-wand

[Lucas Nussbaum]

Source: willow
Version: 0.3.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):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: dh-python, python-setuptools (>= 0.6b3), python-all (>= 
> 2.6.6-3), debhelper (>= 9), python-sphinx, python-sphinx-rtd-theme, 
> python-sphinxcontrib.spelling, python-mock, python-pil, python-opencv, 
> python-wand
> Filtered Build-Depends: dh-python, python-setuptools (>= 0.6b3), python-all 
> (>= 2.6.6-3), debhelper (>= 9), python-sphinx, python-sphinx-rtd-theme, 
> python-sphinxcontrib.spelling, python-mock, python-pil, python-opencv, 
> python-wand
> dpkg-deb: building package 'sbuild-build-depends-willow-dummy' in 
> '/<>/resolver-CdsBgb/apt_archive/sbuild-build-depends-willow-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> sbuild-build-depends-willow-dummy
> dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> Ign:1 copy:/<>/resolver-CdsBgb/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-CdsBgb/apt_archive ./ Release [963 B]
> Ign:3 copy:/<>/resolver-CdsBgb/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-CdsBgb/apt_archive ./ Sources [571 B]
> Get:5 copy:/<>/resolver-CdsBgb/apt_archive ./ Packages [649 B]
> Fetched 2183 B in 0s (0 B/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
> 
> Install willow build dependencies (apt-based resolver)
> --
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-willow-dummy : Depends: python-wand but it is not going 
> to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/willow_0.3.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#850821: RFS: inkscape-open-symbols/1.0-1

[Adam Borowski]

On Wed, Jan 11, 2017 at 06:32:59PM +0100, Félix Sipma wrote:
> On 2017-01-11 11:27+0100, Adam Borowski wrote:
> > 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.
> 
> There's a discussion about the licensing there:
> https://github.com/Xaviju/inkscape-open-symbols/issues/61
> 
> I'm not sure about how inkscape-open-symbols could be licensed (for now it's
> GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then,
> what would be the difference with the Debian package?

The Debian packaging consists of nothing but a makefile (debian/rules) and a
few assorted bits of metadata.  Hardly copyrightable, but above the commonly
quoted threshold of copyrightability (~10 lines).

I might be wrong about the ftpmasters' point of view -- might be good to
hear a clarification -- but I for one don't see a difference between
aggregating two unrelated packages with conflicting licenses in one iso
image, vs aggregating two unrelated symbol sets with conflicting licenses in
one package, as long as they're clearly not derived from one another nor
linked/etc.

So the only issue I see is license compatibility between the packaging
and every of included symbol sets separately.  And here, any license
compatible with both GPL-2 and GPL-3+ will do.


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

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Vincent Lefevre]

On 2017-01-11 17:40:09 +, Ben Hutchings wrote:
> On Wed, 2017-01-11 at 16:20 +0100, Vincent Lefevre wrote:
> > On 2017-01-11 15:09:49 +, Ben Hutchings wrote:
> > > Unless you can show that some data had been written *and flushed* to
> > > disk by the application, but was not readable afterward - this does not
> > > count.  Writes are buffered, and user space has to deal with that.
> > 
> > If I understand the journalctl log correctly, the system does
> > a power off without a clean shutdown:
> 
> Sorry, I didn't understand what you were trying to point out in the
> system log.  I had thought that pressing the power button was causing
> an immediate power-off, but you're showing me that it results in a
> resume immediately followed by a software-controlled shutdown.  Right?

Yes, this is what seems to appear from the logs.

> It seems like there are two separate bugs:
> 
> 1. Power button resumes and also generates a power-off input event
> (kernel bug)
> 2. Some writes not flushed to disk during shutdown (probably a kernel
> bug, but systemd could potentially break this)

Bug 850959. Hmm... no shutdown or the journald log is truncated
for the same reason.

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

Bug#850979: crafty: Does not run on Pentium 4 (Illegal instruction)

[Santiago Vila]

Package: crafty
Version: 23.4-6+b1
Severity: grave

Dear maintainer:

Packages which build-depend on crafty FTBFS on every of my old
Dual-Core Pentium 4 running stretch/amd64.

$ crafty
Illegal instruction

The output of /proc/cpuinfo is attached.

Bug in binutils at the time the package was built?

Thanks.processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 3
microcode   : 0x4
cpu MHz : 2992.470
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc pebs bts nopl eagerfpu pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs:
bogomips: 5984.94
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 3
microcode   : 0x4
cpu MHz : 2992.470
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc pebs bts nopl eagerfpu pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs:
bogomips: 5985.35
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

Bug#850978: sysdig: FTBFS: build-dependency not installable: libjq-dev

[Lucas Nussbaum]

Source: sysdig
Version: 0.13.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):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: cmake, debhelper (>= 9.20120417~), jq, libb64-dev, 
> libcurl4-openssl-dev, libjq-dev, libjsoncpp-dev, libluajit-5.1-dev | 
> liblua5.1-0-dev, libncurses5-dev, libssl-dev, pandoc (>= 1.11), zlib1g-dev, 
> dkms
> Filtered Build-Depends: cmake, debhelper (>= 9.20120417~), jq, libb64-dev, 
> libcurl4-openssl-dev, libjq-dev, libjsoncpp-dev, libluajit-5.1-dev, 
> libncurses5-dev, libssl-dev, pandoc (>= 1.11), zlib1g-dev, dkms
> dpkg-deb: building package 'sbuild-build-depends-sysdig-dummy' in 
> '/<>/resolver-rSFdS0/apt_archive/sbuild-build-depends-sysdig-dummy.deb'.
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> sbuild-build-depends-sysdig-dummy
> dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> Ign:1 copy:/<>/resolver-rSFdS0/apt_archive ./ InRelease
> Get:2 copy:/<>/resolver-rSFdS0/apt_archive ./ Release [963 B]
> Ign:3 copy:/<>/resolver-rSFdS0/apt_archive ./ Release.gpg
> Get:4 copy:/<>/resolver-rSFdS0/apt_archive ./ Sources [634 B]
> Get:5 copy:/<>/resolver-rSFdS0/apt_archive ./ Packages [655 B]
> Fetched 2252 B in 0s (0 B/s)
> Reading package lists...
> W: No sandbox user '_apt' on the system, can not drop privileges
> Reading package lists...
> 
> Install sysdig build dependencies (apt-based resolver)
> --
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-sysdig-dummy : Depends: libjq-dev but it is not 
> installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/sysdig_0.13.0-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#558777: [git-buildpackage/master] import-orig: Move orig.tar.gz with filter-pristine-tar

[Guido Günther]

tag 558777 pending
thanks

Date:   Wed Jan 11 19:00:48 2017 +0100
Author: Guido Günther 
Commit ID: 4a41d496a8006fdc05e4eb0faf762d6ad043a96e
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=4a41d496a8006fdc05e4eb0faf762d6ad043a96e
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=4a41d496a8006fdc05e4eb0faf762d6ad043a96e

import-orig: Move orig.tar.gz with filter-pristine-tar

If we filter a tarball and use filter-pristine-tar we want pristine-tar
to see the correct file name. If a file already exists at that location
move it.

If we wouldn't move the existing tarball but rather e.g. create the
symlink in a temp directory we risk gbp buildpackage picking up the
unfiltered tarball later.

Closes: #558777

A snapshot build including this change will be available at
http://honk.sigxcpu.org:8001/job/git-buildpackage/
  

Bug#850980: linux-image-4.8.0-0.bpo.2-amd64: Xserve 1, 1 experiencing kernel panic early in boot

[Martin Weinelt]

Package: src:linux
Version: 4.8.11-1~bpo8+1
Severity: important

Dear Maintainer,

I migrated an Apple Xserve 1,1 from Mac OS to Debian. I tried stretch before, 
which wouldn't
boot at all, but jessie did. So tried the jessie-backports kernel (4.8.11) and 
it turns out
that it experiences a kernel panic early in boot. In maybe 1 out of 10 cases it 
succesfully
boots, but mostly it crashes.
The kernel shipped with jessie (3.16) is booting fine, 4.8.x does not, so this 
is a blocker
for future upgrades on this hardware.

-- Boot log
[0.00] Linux version 4.8.0-0.bpo.2-amd64 
(debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP 
Debian 4.8.11-1~bpo8+1 (2016-12-14)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-0.bpo.2-amd64 
root=/dev/mapper/hexa--vg-root ro nomodeset console=tty0 console=ttyS0,115200n8
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000b] reserved
[0.00] BIOS-e820: [mem 0x000c-0x7eaa5fff] usable
[0.00] BIOS-e820: [mem 0x7eaa6000-0x7eaa9fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eaaa000-0x7eaaafff] usable
[0.00] BIOS-e820: [mem 0x7eaab000-0x7eab1fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eab2000-0x7eab3fff] usable
[0.00] BIOS-e820: [mem 0x7eab4000-0x7eac0fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eac1000-0x7eac1fff] usable
[0.00] BIOS-e820: [mem 0x7eac2000-0x7eac7fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eac8000-0x7eacdfff] usable
[0.00] BIOS-e820: [mem 0x7eace000-0x7ead6fff] ACPI data
[0.00] BIOS-e820: [mem 0x7ead7000-0x7eae1fff] usable
[0.00] BIOS-e820: [mem 0x7eae2000-0x7eae2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7eae3000-0x7eae3fff] usable
[0.00] BIOS-e820: [mem 0x7eae4000-0x7eae4fff] ACPI data
[0.00] BIOS-e820: [mem 0x7eae5000-0x7eaf6fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7eaf7000-0x7eb0] reserved
[0.00] BIOS-e820: [mem 0x7eb1-0x7ebf8fff] usable
[0.00] BIOS-e820: [mem 0x7ebf9000-0x7ec00fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ec01000-0x7ec09fff] usable
[0.00] BIOS-e820: [mem 0x7ec0a000-0x7ec0afff] reserved
[0.00] BIOS-e820: [mem 0x7ec0b000-0x7ec10fff] usable
[0.00] BIOS-e820: [mem 0x7ec11000-0x7ec11fff] type 20
[0.00] BIOS-e820: [mem 0x7ec12000-0x7ec12fff] ACPI data
[0.00] BIOS-e820: [mem 0x7ec13000-0x7ec15fff] type 20
[0.00] BIOS-e820: [mem 0x7ec16000-0x7ec16fff] reserved
[0.00] BIOS-e820: [mem 0x7ec17000-0x7ec17fff] type 20
[0.00] BIOS-e820: [mem 0x7ec18000-0x7ec1afff] usable
[0.00] BIOS-e820: [mem 0x7ec1b000-0x7ec29fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ec2a000-0x7ec33fff] usable
[0.00] BIOS-e820: [mem 0x7ec34000-0x7ec34fff] reserved
[0.00] BIOS-e820: [mem 0x7ec35000-0x7ec36fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ec37000-0x7ec3bfff] usable
[0.00] BIOS-e820: [mem 0x7ec3c000-0x7ec3cfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ec3d000-0x7ec5] usable
[0.00] BIOS-e820: [mem 0x7ec6-0x7ece0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ece1000-0x7ecf] usable
[0.00] BIOS-e820: [mem 0x7ed0-0x7ed01fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ed02000-0x7ed49fff] usable
[0.00] BIOS-e820: [mem 0x7ed4a000-0x7ed4afff] reserved
[0.00] BIOS-e820: [mem 0x7ed4b000-0x7edbefff] usable
[0.00] BIOS-e820: [mem 0x7edbf000-0x7edc0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7edc1000-0x7edd4fff] usable
[0.00] BIOS-e820: [mem 0x7edd5000-0x7edd5fff] reserved
[0.00] BIOS-e820: [mem 0x7edd6000-0x7edd6fff] usable
[0.00] BIOS-e820: [mem 0x7edd7000-0x7ede1fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ede2000-0x7ee69fff] usable
[0.00] BIOS-e820: [mem 0x7ee6a000-0x7ee6afff] 

Bug#850981: diaspora-installer: fails to start as bin/bundle points to /usr/local/bin/bundle

[Julian Gilbey]

Package: diaspora-installer
Version: 0.6.0.0+debian5
Severity: important

Hi Pirate,

Getting there, slowly!

I found that diaspora, installed via diaspora-installer, wouldn't
start, as /usr/share/diaspora/bin/bundle pointed to
/usr/local/bin/bundle, and I ended up with loads of error messages in
the log files.  On changing this link to point to the system-installed
/usr/bin/bundle, it got much further!

But maybe this is wrong for some reason I don't understand...

Best wishes,

   Julian

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

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

Versions of packages diaspora-installer depends on:
ii  build-essential  12.2
ii  diaspora-common  0.6.0.0+debian5
ii  ghostscript  9.20~dfsg-1
ii  imagemagick  8:6.9.6.6+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.6.6+dfsg-1
ii  libcurl4-openssl-dev 7.51.0-1
ii  libmagickwand-dev8:6.9.6.6+dfsg-1
ii  libpq-dev9.6.1-2
ii  libssl-dev   1.1.0c-2
ii  libxml2-dev  2.9.4+dfsg1-2.1
ii  libxslt1-dev [libxslt-dev]   1.1.29-2
ii  ruby 1:2.3.3
ii  ruby-dev 1:2.3.3
ii  ruby2.1 [ruby-interpreter]   2.1.5-4
ii  wget 1.18-4

diaspora-installer recommends no packages.

diaspora-installer suggests no packages.

-- no debconf information

Bug#850753: fresh upstream (and ubuntu) is available (1.12.3)

[Tianon Gravi]

On 9 January 2017 at 14:13, Yaroslav Halchenko  wrote:
> Ubuntu  docker.io1.12.3-0ubuntu4  
> http://packages.ubuntu.com/zesty/docker.io

The reason Ubuntu is able to be more aggressive than Debian is that
they've made an explicit release exception for using Docker's
published "vendor" directory as-is rather than splitting it out into
individual packages (which is what causes so much headache for us in
Debian every new Docker release, and causes a greater number of issues
such as #835686).


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Am 11.01.2017 um 18:55 schrieb Vincent Lefevre:
> On 2017-01-11 18:36:30 +0100, Michael Biebl wrote:
>> Am 11.01.2017 um 18:28 schrieb Michael Biebl:
>>> Am 11.01.2017 um 18:25 schrieb Vincent Lefevre:
 On 2017-01-11 18:09:51 +0100, Michael Biebl wrote:
> Am 11.01.2017 um 18:05 schrieb Michael Biebl:
>> Why is this no normal shutdown?

 Services are not stopped as usual.
>>>
>>> How do you conclude that?
> 
> There is no log for stopped services in the journald logs.

Not sure what that is supposed to show.

>> And if something is killing the power midway through the shutdown
>> process, it's hardly something systemd can do about.
> 
> What would kill the power?

You pressing the power button for too long, a faulty power supply, buggy
bios, ...

>> That said, so far this bug report is lacking crucial information why
>> this is supposed to be a systemd bug,
> 
> What info do you need?

A verbose debug log from shutdown would be helpful.

So far what I see is:
logind receives a power button event and initiates a shutdown request
which is executed by systemd. I can't see the bug in systemd.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#848370: terminology crashes when creating new tab

[Ross Vandegrift]

severity 848370 serious
thanks

terminology shouldn't go into stable with this issue.  Fixing requires
newer EFL, which is still in experimental.

Ross

Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Am 11.01.2017 um 19:12 schrieb Michael Biebl:
> Am 11.01.2017 um 18:55 schrieb Vincent Lefevre:
>> On 2017-01-11 18:36:30 +0100, Michael Biebl wrote:
>>> Am 11.01.2017 um 18:28 schrieb Michael Biebl:
 Am 11.01.2017 um 18:25 schrieb Vincent Lefevre:
> On 2017-01-11 18:09:51 +0100, Michael Biebl wrote:
>> Am 11.01.2017 um 18:05 schrieb Michael Biebl:
>>> Why is this no normal shutdown?
>
> Services are not stopped as usual.

 How do you conclude that?
>>
>> There is no log for stopped services in the journald logs.
> 
> Not sure what that is supposed to show.
> 
>>> And if something is killing the power midway through the shutdown
>>> process, it's hardly something systemd can do about.
>>
>> What would kill the power?
> 
> You pressing the power button for too long, a faulty power supply, buggy
> bios, ...
> 
>>> That said, so far this bug report is lacking crucial information why
>>> this is supposed to be a systemd bug,
>>
>> What info do you need?
> 
> A verbose debug log from shutdown would be helpful.


/usr/share/doc/systemd/README.Debian.gz →
Debugging boot/shutdown problems

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850604: mutt: sidebar doesn't update message stats when using unmailboxes *

[Elimar Riesebieter]

* Mattia Oss  [2017-01-11 12:28 +0100]:

> Please CC me when replying, I didn't receive your last email.
> 
> On Sun, Jan 08, 2017 at 03:22:33PM +0100, Mattia Oss wrote:
> > On Sun, Jan 08, 2017 at 02:57:38PM +0100, Elimar Riesebieter wrote:
> > > Could you please fireup mutt and type at the command prompt:
> > > 
> > > :set ?mail_check_stats
> > > 
> > > and tell me the output?
> > mail_check_stats is set
> > 
> > Sometimes, when I access a mailbox, I get the stats. But it's random and
> > I can't reproduce it.
> > 
> 
> >Why did you "set mail_check=90"? The default is 5.
> 
> I think you found the problem. Now I set these options:
> set mail_check=1
> set timeout=1
> 
> It still lags for 2-3 seconds, but I can live with that. 

So bug closed hereby.

Thanks
Elimar
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)

Bug#792514: foomatic-db: Problems when printing some pdf files in a Brother MFC-9465CDN

[Agustin Martin]

On Wed, Jul 15, 2015 at 05:32:27PM +0200, Agustin Martin wrote:
> Package: foomatic-db
> Version: 20150411-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Hi,
> 
> For some time I am having problems with some pdf files in a multifuncion
> Brother MFC-9465CDN, using BRScript-3 Brother MFC-9450CDN and MFC9840CDW ppd
> files shipped through foomatic. I am having the same problem with a
> MFC-9465CDN ppd file taken from Brother disks. 
> 
> This does not happen with all pdf files, just with some of them containing
> images. I am attaching one of the problematic pdf, in case it helps. It was
> adapted from a previous document and includes a bitmap image. Modificacion
> was done through LibreOffice and exported to pdf from it. When sent to a
> Brother MFC9465CDN using the BR-Script3 ppd files mentioned above, printing
> fails and a sheet is output with this error message printed:
> 
> ERROR NAME;
>typecheck
> COMMAND;
>image
> OPERAND STACK;
> [ None or some of the lines below, depending on the ppd ]
>   --booleantype
>   --booleantype
> 
> The good news are that pre-processing the pdf file with pdfwrite seems to
> work around this problem as well as printing it first to a pdf file with
> cups-pdf, but this latter makes a far bigger file.

Hi,

Seems I am having more info about the offending images. If I try to run
jpeg2ps on one of the problematic jpeg images I get

$ jpeg2ps kk-000.jpg > kk.eps
Warning: JPEG file uses compression method C2 - proceeding anyway.
PostScript output does not work on all PS interpreters!

If I rebuild the pdf file after processing the jpg with imagemagick's
convert

$ convert kk-000.jpg kk-001.jpg

problem seems to go away. So, this is apparently related to jpeg
compression method.
 
> I noticed that for cups 1.3 or higher a pre-processing filter can be used.
> If pstopdf cups filter is available, adding following lines to ppd file
> seems to make things work here,

pstopdf filter is no longer available, so this no longer works. But at
least I know now why it was useful.

Regards,

-- 
Agustin

Bug#850181: plymouth theme(s) should provide fsck progress support

[Michael Biebl]

Am 11.01.2017 um 18:51 schrieb Michael Biebl:
> Am 11.01.2017 um 18:46 schrieb Aurélien COUDERC:
>>
>>
>> Le 10 janvier 2017 17:28:46 GMT+05:30, Michael Biebl  a 
>> écrit :
>>
>>> I've tested all three themes, they worked fine with one or multiple
>>> fscks running at the same time. I've attached a screenshot for each of
>>> them. A few suggestions:
>>> a/ Joy looks ok
>>> b/ Lines:
>>>  - The text is not horizontally aligned (centered)
>>> - The text should probably be moved lower so it doesn't intersect with
>>> the lines graphic
>>> c/ softwaves:
>>> - The text should be moved lower so it doesn't intersect with the
>>> circle
>>
>> Which resolution would that be ?
> 
> 1920x1200


Is this dependent on the aspect ratio?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#849203: libasound2: ALSA_PCM_DEVICE environment variable is ignored

[Elimar Riesebieter]

* Leszek Godlewski  [2016-12-23 18:46 +]:

> Hi Elimar,
> 
> If that is the case, why does ALSA_PCM_CARD work without such preparation?
> /usr/share/alsa/alsa.conf contains a similar block for the card, yet it
> isn't needed in /etc/asound.conf.
> 
> I will try it anyway and let you know if it worked, thanks!

Any news?

[...]

> > As far as i understsnd the sources you must prepare your device to
> > interpret ALSA_PCM_DEVICE. Try /etc/asound.conf as follows:
> >
> > defaults.pcm.card 0
> > defaults.pcm.device 3
> > defaults.pcm.device {
> > @func igetenv
> > vars [ ALSA_PCM_DEVICE ]
> > default 0
> > }
> >
> > Now it should be possible to run
> > $ ALSA_PCM_CARD=1 ALSA_PCM_DEVICE=0 mplayer test.mp3

Elimar

-- 
.~.
/V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^

Bug#818325: xserver-xorg-core: Missing the mouse pointer after locking the screen

[Andreas Boll]

According to the upstream bug report [1] this issue has been resolved.
Thus I'm closing this bug report too.
Feel free to reopen this report if you still have this issue.

Thanks,
Andreas

[1] https://bugs.freedesktop.org/show_bug.cgi?id=94677

On Wed, Mar 16, 2016 at 12:07:59AM +0100, Mikhail Morfikov wrote:
> Package: xserver-xorg-core
> Version: 2:1.18.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading the two following packages:
> 
> 
> [UPGRADE] xserver-common:amd64 2:1.18.1-1 -> 2:1.18.2-1
> [UPGRADE] xserver-xorg-core:amd64 2:1.18.1-1 -> 2:1.18.2-1
> 
> 
> The mouse pointer simply disappears when I want to log into the system after
> locking the screen. After restarting the Xserver, everything backs to normal,
> but when I lock the screen again, I won't see the pointer after login. I'm
> using lightdm as DM.
> 
> I can get the mouse pointer back also when I switch to TTY using ctl-alt-f1 
> and
> then to xsession via ctrl-alt-f7.
> 


signature.asc
Description: Digital signature

Bug#850948: [Piuparts-devel] Bug#850948: needrestart, piuparts: needrestart hangs -> piupart fails -> debian-design blocked

[Jonas Smedegaard]

Quoting Holger Levsen (2017-01-11 18:25:06)
> On Wed, Jan 11, 2017 at 06:14:55PM +0100, Jonas Smedegaard wrote:
> > I believe I stated quite clearly the scope of this bug.
>  
> i dont see the scope.

Here it is, again:

Quoting Jonas Smedegaard (2017-01-11 15:25:10)
> This bugreport is tracking debian-design not entering testing.

...and again:

Quoting Jonas Smedegaard (2017-01-11 15:25:10)
> This bugreport is tracking the combined issue of a) + b) + c).

...and here I request keeping severity tied to debian-design:

> Please therefore reassign and/or merge as appropriate, but only as 
> long as the severity reflects the actual treatment of debian-design.

In other words, basically the whole content of the bugreport apart from 
the few lines you yourself quoted.


> we have one for needsrestart being buggy and one for the release team 
> to ignore this for the testing migration of debian-design. I dont see 
> why another one is needed.

You need not understand all needs of Debian.  Thanks for trying, though.


>> I fail to understand how merging with another (related) bug of 
>> different severity helps track the issue I reported?
>
> you know how to handle the bts yourself, feel free to unmerge and 
> assign somewhere. just not to piuparts (even partly) with RC severity. 
> feel free to make it wishlist and assign to piuparts (party or not).

Yes, I am aware how I can run behind you and clean up after your 
ignorance. Wish I didn't have to.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#850982: Add instructions to disable gpg-agent user service in README.Debian

[Yuri D'Elia]

Package: gnupg-agent
Version: 2.1.17-4
Severity: normal

The gpg-agent and dirmngr services are now auto-enabled for user sessions,
which is actually a nice improvement.

Can we tweak the instructions present in the README.Debian to include the
commands required to disable this for a single user, and also globally?

I do not want to auto-start these services for the root user. I also want to
disable auto-start completely in servers I'm logging into. I think both are
pretty common scenarios and deserve special mention, as systemctl --user
disable won't work some might expect.

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

Kernel: Linux 4.9.0-trunk-amd64 (SMP w/4 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)

Versions of packages gnupg-agent depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-8
ii  libgcrypt20   1.7.5-2
ii  libgpg-error0 1.26-1
ii  libnpth0  1.3-1
ii  libreadline7  7.0-1
ii  pinentry-gtk2 [pinentry]  1.0.0-1

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.17-4

Versions of packages gnupg-agent suggests:
pn  scdaemon  

Bug#850979: crafty: Does not run on Pentium 4 (Illegal instruction)

[Sven Joachim]

On 2017-01-11 18:58 +0100, Santiago Vila wrote:

> Package: crafty
> Version: 23.4-6+b1
> Severity: grave
>
> Dear maintainer:
>
> Packages which build-depend on crafty FTBFS on every of my old
> Dual-Core Pentium 4 running stretch/amd64.
>
> $ crafty
> Illegal instruction
>
> The output of /proc/cpuinfo is attached.
>
> Bug in binutils at the time the package was built?

The toplevel Makefile in the crafty source adds -march=k8 to CFLAGS, I
am not sure if this is compatible with the Pentium 4.  You could try
rebuilding crafty with and without this flag to find out.

Cheers,
   Sven

Bug#850959: Bug#850059: linux-image-4.8.0-2-amd64: After suspend, the power button powers off the laptop instead of resuming

[Michael Biebl]

Control: severity -1 normal
Control: tags -1 moreinfo unreproducible

[moving this over to #850959]
Am 11.01.2017 um 19:13 schrieb Michael Biebl:
> Am 11.01.2017 um 19:12 schrieb Michael Biebl:
>> Am 11.01.2017 um 18:55 schrieb Vincent Lefevre:
>>> What info do you need?
>>
>> A verbose debug log from shutdown would be helpful.
> 
> 
> /usr/share/doc/systemd/README.Debian.gz →
> Debugging boot/shutdown problems
> 

If you had an unclean power off and a file corruption, please provide
the fsck log for this incident.
For / (and /usr) the logs are in /run/initramfs/, for other file systems
the result is in the journal.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850979: crafty: Does not run on Pentium 4 (Illegal instruction)

[Santiago Vila]

On Wed, Jan 11, 2017 at 07:36:56PM +0100, Sven Joachim wrote:
> On 2017-01-11 18:58 +0100, Santiago Vila wrote:
> 
> > Bug in binutils at the time the package was built?
> 
> The toplevel Makefile in the crafty source adds -march=k8 to CFLAGS, I
> am not sure if this is compatible with the Pentium 4.  You could try
> rebuilding crafty with and without this flag to find out.

What I did is to rebuild it under current stretch and then it worked.

I'm preparing a QA upload which does nothing but a little bit of
cleanup.

Thanks.

Bug#850983: gvpe: FTBFS: configure: error: OpenSSL depends on libz.

[Lucas Nussbaum]

Source: gvpe
Version: 2.25-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):
> checking for SSLeay_add_all_algorithms... no
> checking for dlopen... no
> checking for dlopen in -ldl... yes
> checking for inflate... no
> checking for inflate in -lz... no
> configure: error: OpenSSL depends on libz.
>   "tail -v -n +0 config.log"

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/gvpe_2.25-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#850984: icedove: FTBFS: configure: error: cannot determine icu version number from uvernum.h header file

[Lucas Nussbaum]

Source: icedove
Version: 1:45.5.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):
> checking for posix_fallocate... yes
> checking for icu-i18n >= 50.1... yes
> checking MOZ_ICU_CFLAGS... 
> checking MOZ_ICU_LIBS... -licui18n -licuuc -licudata
> sed: character class syntax is [[:space:]], not [:space:]
> configure: error: cannot determine icu version number from uvernum.h header 
> file 
> -- config.log --
> configure:28359: gcc -c -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-delete-null-pointer-checks -fno-schedule-insns2 -std=gnu99 
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections 
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:28346: checking for inttypes.h
> configure:28359: gcc -c -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-delete-null-pointer-checks -fno-schedule-insns2 -std=gnu99 
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections 
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:28610: checking for cairo >= 1.10
> configure:28617: checking CAIRO_CFLAGS
> configure:28622: checking CAIRO_LIBS
> configure:28703: checking for cairo-tee >= 1.10
> configure:28710: checking CAIRO_TEE_CFLAGS
> configure:28715: checking CAIRO_TEE_LIBS
> configure:28795: checking for cairo-xlib-xrender >= 1.10
> configure:28802: checking CAIRO_XRENDER_CFLAGS
> configure:28807: checking CAIRO_XRENDER_LIBS
> configure:29789: checking for posix_fadvise
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 -lpthread -Wl,-z,relro -Wl,--no-keep-memory 
> -Wl,--reduce-memory-overheads -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text 
> -Wl,--build-id conftest.c -ldl  1>&5
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 0
> configure:29789: checking for posix_fallocate
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time 
> -D_FORTIFY_SOURCE=2 -lpthread -Wl,-z,relro -Wl,--no-keep-memory 
> -Wl,--reduce-memory-overheads -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text 
> -Wl,--build-id conftest.c -ldl  1>&5
> /usr/bin/ld: total time in link: 0.02
> /usr/bin/ld: data size 4354048
> configure:29875: gcc -c -Wall -Wempty-body -Wpointer-to-int-cast 
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2 
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections 
> -fdata-sections -fno-math-errno -pthread -pipe  -Wdate-time 
> -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:30104: checking for icu-i18n >= 50.1
> configure:30111: checking MOZ_ICU_CFLAGS
> configure:30116: checking MOZ_ICU_LIBS
> configure: error: cannot determine icu version number from uvernum.h header 
> file 
> *** Fix above errors and then restart with\
>"make -f client.mk build"
> client.mk:361: recipe for target 'configure' failed
> make[2]: *** [configure] Error 1
> make[2]: Leaving directory '/<>'
> debian/rules:68: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:58: recipe for target 'build' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/icedove_45.5.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#850985: webcit: FTBFS: configure: error: zlib.h was not found or is not usable. Please install zlib.

[Lucas Nussbaum]

Source: webcit
Version: 902-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):
> checking xlocale.h presence... yes
> checking for xlocale.h... yes
> checking zlib.h usability... no
> checking zlib.h presence... no
> checking for zlib.h... no
> configure: error: zlib.h was not found or is not usable.  Please install zlib.
> debian/rules:38: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 1
> make[1]: Leaving directory '/<>'
> debian/rules:35: recipe for target 'build' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/webcit_902-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#850821: RFS: inkscape-open-symbols/1.0-1

[Félix Sipma]

On 2017-01-11 18:59+0100, Adam Borowski wrote:
> On Wed, Jan 11, 2017 at 06:32:59PM +0100, Félix Sipma wrote:
>> On 2017-01-11 11:27+0100, Adam Borowski wrote:
>>> 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.
>> 
>> There's a discussion about the licensing there:
>> https://github.com/Xaviju/inkscape-open-symbols/issues/61
>> 
>> I'm not sure about how inkscape-open-symbols could be licensed (for now it's
>> GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then,
>> what would be the difference with the Debian package?
> 
> The Debian packaging consists of nothing but a makefile (debian/rules) and a
> few assorted bits of metadata.  Hardly copyrightable, but above the commonly
> quoted threshold of copyrightability (~10 lines).
> 
> I might be wrong about the ftpmasters' point of view -- might be good to
> hear a clarification -- but I for one don't see a difference between
> aggregating two unrelated packages with conflicting licenses in one iso
> image, vs aggregating two unrelated symbol sets with conflicting licenses in
> one package, as long as they're clearly not derived from one another nor
> linked/etc.
> 
> So the only issue I see is license compatibility between the packaging
> and every of included symbol sets separately.  And here, any license
> compatible with both GPL-2 and GPL-3+ will do.

So, for you, if the inkscape-open-symbols is licensed under MIT (upstream
intends to do that), is there a problem or not?


signature.asc
Description: PGP signature

Bug#812791: xserver-xorg-core: Kills DM controlled session when opening X from another tty

[Agustin Martin]

On Tue, Oct 04, 2016 at 11:43:07AM +0200, Agustin Martin wrote:
> On Wed, Sep 07, 2016 at 12:08:15PM +0200, Agustin Martin wrote:
> > On Wed, Jan 27, 2016 at 03:51:22PM +0100, Agustin Martin wrote:
> > > On Wed, Jan 27, 2016 at 08:29:21AM +0100, Julien Cristau wrote:
> > > > On Tue, Jan 26, 2016 at 16:51:27 +0100, Agustin Martin wrote:
> > > > 
> > > > > Package: xserver-xorg-core
> > > > > Version: 2:1.17.3-2
> > > > > Severity: normal
> > > > > 
> > > > > Dear Maintainers,
> > > > > 
> > > > > I am having a strange problem apparently starting with 2:1.17.2-3.
> > > > > 
> > > > > I often have a display-manager controlled X session for one user and 
> > > > > open
> > > > > another X session in a free tty for a different user with startx.
> > > > > 
> > > > > This has been working for a long time. However, after a recent testing
> > > > > upgrade including xserver-xorg-core 2:1.17.2-3 this started to fail
> > > > > (failure happened before in a sid box, but there were more upgrades to
> > > > > look when trying to locate which change might be responsible).
> > > > > 
> > > > > When I have a display-mamager controlled X session and, without 
> > > > > leaving the
> > > > > session, switch to a free tty, login as another user and start an X 
> > > > > session
> > > > > with startx original X session gets killed and I am sent to DM 
> > > > > greeter.
> > > > > 
> > > > Please provide the log from both X processes.
> > > 
> > > Hi, thanks for quick reply.
> > > 
> > > Please find them attached.
> > 
> > Hi,
> > 
> > Just to add some additional info. This problem is happening not only with
> > the xserver-xorg-video-nouveau driver, but also if I remove it leaving the 
> > fbdev
> > or vesa drivers.

Hi, some funny info about this problem,

I am using a sysvinit box and it is currently suffering from

https://bugs.debian.org/844785 [systemd-shim not fully compatible with systemd 
232]

and similar bugs against lightdm

#770885 lightdm: Restart, Suspend, Hibernate, Shut Down all greyed out and 
nonfunctional
#804165 lightdm: Options reboot,suspend,hibernate are all greyed out

The funny thing is that as soon as this systemd-shim bug reappeared my
original problem reported in this bug #812791 report become no longer present
when using "sysvinit"+"buggy systemd-shim".

I have booted with systemd to see what happens and my original problem
reappeared, cannot switch.

So, this may be related to interaction with policykit or friends, but apart
from that guess I am clueless.

Regards,

-- 
Agustin

Bug#850979: crafty: Does not run on Pentium 4 (Illegal instruction)

[Santiago Vila]

On Wed, Jan 11, 2017 at 07:36:56PM +0100, Sven Joachim wrote:

> The toplevel Makefile in the crafty source adds -march=k8 to CFLAGS, I
> am not sure if this is compatible with the Pentium 4.  You could try
> rebuilding crafty with and without this flag to find out.

To make things more funny, one of the Debian patches add a linux-generic
target (without CPU-specific code), but then debian/rules does not use it.

Thanks.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Daniel Kahn Gillmor]

Hi Ian (and hi tech-ctte!)--

On Wed 2017-01-11 12:13:44 -0500, Ian Jackson  
wrote:
> Package: tech-ctte
> Control: block 850657 by -1

Ian, in the future please x-debbugs-cc me when you take our discussions
to the tech-ctte :)

> Policy 6.1 says
> | Programs called from maintainer scripts should not normally have a
> | path prepended to them.
>
> Ie, programs that are on PATH should be found via the PATH rather than
> by hardcoding /usr/bin/foo or whatever.  In general, I think we
> normally, at least in software written specifically for Debian, apply
> this not just to maintainer scripts but to all program execution.

I agree that it's a common practice for software written specifically
for Debian.  I'm not convinced it's a common practice elsewhere, and i'm
definitely not convinced that we should mandate divergence from upstream
for this purpose.  Please see the examples i've already given in
#850657, or run

  find {/usr,}/{s,}bin -type f -print0 | xargs -0 strings | egrep 
'^(/usr)?/s?bin/[[:alnum:]]+$' | sort | uniq -c | sort -rn

on your own system to see that it's not actually particularly uncommon.

>  * Declare that Debian policy should be clarified to say that programs
>in Debian (not just maintainer scripts) should not hardcode the
>location of the binaries in /{usr/,}{bin,sbin} they execute.
>
>  * Say that this applies even when the program needs to find pieces of
>the same (or closely related) package.
>
>  * Say that where technically feasible, this should usually be done
>for other kinds of search paths (LD_LIBRARY_PATH, PYTHONPATH,
>PERLLIB, etc.), too.
>
>  * Provide an informal opinion that this policy ought to apply to
>gpg-agent as requested in #850657.

Please do not do this to gpg-agent unless upstream is fine with this
change.  I have more important things i want to consider divergence from
upstream about, and i don't think this particular scenario is a healthy
use of debian policy.

I laud Ian's goals of making debugging easier, but the particular
pattern he describes (wrapping stuff and putting the wrappers in $PATH)
is not the only way to ease debugging, and is at least as vulnerable to
the problems he associates with other techniques ("too easy to forget to
put back", etc) as they are.

> Firstly, we are talking about this in the context of Debian.  In
> Debian we have `reportbug', which the majority of people use to file
> bug reports.

the majority of debian users don't file bug reports at all, sadly.  they
complain about brokenness to their friends, they grouse about it on
social media, ask for help on stackoverflow, mention their troubles on
upstream mailing lists, or they just give up and move on.

diverging from upstream for this particular case means that on most of
those complaints, they might *also* hear "oh yeah, debian doesn't know
how to find the files from your specific installation because they
patched that out, so it's using whatever it found in $PATH".  Imagine
hearing this as someone who doesn't know what $PATH is, but just
followed a recipe on stackoverflow for some other problem that stuck
arbitrary crap in your $PATH four weeks ago and then you forgot about
the whole thing.  To such a user, they hear "debian broke this
package", which is not helpful to anyone.

Sophisticated users who do sophisticated debugging already have lots of
other options available to them.

> It would be simple for reportbug to report on these kind of anomalous
> situations and mention them in the bug report.  It could, for example,
> check to see if there is overlap between the package being reported
> (and its dependencies), and /usr/local.  I don't know if it does
> already, but if it doesn't and someone feels the information is
> valuable, then I'm sure the patches to reportbug would be welcome.

Indeed, patches welcome to automate this kind of inspection process as
part of reportbug.  if that infrastructure already existed and was
well-tested, i *might* be willing to consider this divergence from
upstream after talking it over with upstream and making sure they
understand why we aim to do it, and what additional ways we plan to help
them deal with any related bug reports.  As it stands, i don't think
that infrastructure exists, and i don't want to have that negotiation
with upstream.

> Secondly, I think the possibility that users may do things upstream
> consider undesirable, and even cause lossage, is precisely software
> freedom.

of course it is.  I would never tell users they can't build whatever
they want to build.  But i also want to support software in debian.
that means working well with upstream, managing expectations, and
minimizing the bugs that users encounter when they use the defaults.

> The thrust of the upstream argument here is that users must be
> prevented from messing with their software in certain ways because it
> makes those users' bug reports too hard to deal with.
>
> I think this argument is 

Bug#850181: plymouth theme(s) should provide fsck progress support

[Michael Biebl]

Hi

Am 11.01.2017 um 19:56 schrieb Aurélien COUDERC:
> Le mercredi 11 janvier 2017, 19:27:29 IST Michael Biebl a écrit :

>> Is this dependent on the aspect ratio?
> 
> And resolution. The font size is fixed whereas other theme elements are 
> scaled.

Urgh

> But I really don’t understand the softWaves screenshot, all the text elements 
> are supposed to be below the Debian text.
> I’ve tested on a laptop with this exact resolution and it was working as 
> intended, so… I’ll re-read the code and see if I can find something funny in 
> the positioning.
> 
> Do you have a second monitor plugged in ?

It's an external monitor (1920x1200) attached to my laptop (1366x768)
via a docking station. The laptop internal display was turned off during
boot (lid was closed).

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850181: plymouth theme(s) should provide fsck progress support

[Aurélien COUDERC]

Le mercredi 11 janvier 2017, 19:27:29 IST Michael Biebl a écrit :
> Am 11.01.2017 um 18:51 schrieb Michael Biebl:
> > Am 11.01.2017 um 18:46 schrieb Aurélien COUDERC:
> >>
> >>
> >> Le 10 janvier 2017 17:28:46 GMT+05:30, Michael Biebl  a 
> >> écrit :
> >>
> >>> I've tested all three themes, they worked fine with one or multiple
> >>> fscks running at the same time. I've attached a screenshot for each of
> >>> them. A few suggestions:
> >>> a/ Joy looks ok
> >>> b/ Lines:
> >>>  - The text is not horizontally aligned (centered)
> >>> - The text should probably be moved lower so it doesn't intersect with
> >>> the lines graphic
> >>> c/ softwaves:
> >>> - The text should be moved lower so it doesn't intersect with the
> >>> circle
> >>
> >> Which resolution would that be ?
> > 
> > 1920x1200
> 
> 
> Is this dependent on the aspect ratio?

And resolution. The font size is fixed whereas other theme elements are scaled.

But I really don’t understand the softWaves screenshot, all the text elements 
are supposed to be below the Debian text.
I’ve tested on a laptop with this exact resolution and it was working as 
intended, so… I’ll re-read the code and see if I can find something funny in 
the positioning.

Do you have a second monitor plugged in ?


Cheers,
--Aurélien

Bug#850181: plymouth theme(s) should provide fsck progress support

[Michael Biebl]

Am 11.01.2017 um 19:59 schrieb Michael Biebl:

> It's an external monitor (1920x1200) attached to my laptop (1366x768)
> via a docking station. The laptop internal display was turned off during
> boot (lid was closed).

I will retry with the laptop undocked later today. This should provide a
more "standard" 16x9 setup.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be 
hardcoded even in upstream parts"):
> Ian, in the future please x-debbugs-cc me when you take our discussions
> to the tech-ctte :)

Sorry, I should have thought of that.

Thanks for your reply.  There are some things I might want to respond
in it but I don't want to distract the TC any further from #850887.
This issue isn't urgent, even though it is quite wide-ranging.
So, I won't press this now and instead I'll wait for a TC member to
pick it up.

Regards,
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#841208: fixed in monkeysphere 0.41-1

[Daniel Kahn Gillmor]

Control: severity 841208 important

On Mon 2016-12-12 19:16:24 -0500, Daniel Kahn Gillmor wrote:

> thanks for the notes.  the issue is now entropy starvation during
> "monkeysphere gen-subkey" in the test suite.  I'm not sure what the
> right thing to do is here, other than either:
>
>  a) adding debug-quick-random to the gpg.conf file in the test suite, or

I looked into this, and i think this is actually already being done :/

in tests/common, we define get_gpg_prng_arg(), and in tests/basic, we
apply it to all the gpg.conf files that should be relevant.

>  b) adding a build-dependency on haveged

this seems weirdly roundabout.  we don't actually build-depend on
haveged, we build-depend on haveged actually running on the platform in
question and pushing its "entropy" into the kernel's buffers.

Or, we depend on a kernel that seeds itself once for entropy and remains
in a non-blocking state because of a good internal CSPRNG.

Or, we depend on having an entropykey attached.

Or …

Can we just say that the test suite needs entropy somehow?

> It seems to me that there's a general upstream bug with GnuPG consuming
> more entropy than it nees to, but i don't think that's going to be fixed
> by upstream before stretch.

This is sadly still true :/

I'm reducing the severity of this bug report because (a) we understand
the issue, and (b) it's not actually an issue on the debian buildd
infrastructure (the arch-all builder did not hang in the way that
Santiago reported).

Please also see https://bugs.debian.org/850094 for more general
discussion of similar situations.

The issue is still unresolved, but i'm not sure how to fix it, and i
don't think that it should make the package be removed from stretch, so
i don't think this issue is RC.

I hope this severity change is understandable.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#836312: unneccessary build-dependency on libmysqld-dev

[Emilio Pozuelo Monfort]

severity 836312 serious
user pkg-mysql-ma...@lists.alioth.debian.org
usertags 836312 default-mysql
thanks

On Thu, 01 Sep 2016 16:23:33 +0200 "Steinar H. Gunderson"
 wrote:
> Source: net-snmp
> Version: 5.7.3+dfsg-1.4
> Severity: normal
> 
> Hi,
> 
> net-snmp Build-Depends on libmysqld-dev. This is a product known as 
> “Embedded MySQL”,
> which is for if you want to embed all of mysqld in your binary, SQL parser 
> and all.
> (It is in many ways similar to SQLite.) From what I can see, it doesn't 
> actually link
> to libmysqld; if you just want the regular client library to connect to a 
> MySQL server,
> you should probably use libmysqlclient-dev instead. (libmysqld-dev depends on
> libmysqlclient-dev, which is why the package still builds.)

Ack, but you should build-depend on default-libmysqlclient-dev instead as we're
moving to mariadb.

This is RC as you depend on libmysqlclient18 because of this, rather than on
libmariadb18.

Cheers,
Emilio

Bug#850874: ark: CVE-2017-5330: Unintended execution of scripts and executable files

[Salvatore Bonaccorso]

Hi

For jessie: I think the issue was only introduce after the "Open File"
action was introduced, which is post 15.11.80. Would be great if you
can confirm that.

Regards,
Salvatore

Bug#841208: fixed in monkeysphere 0.41-1

[Daniel Kahn Gillmor]

On Fri 2016-12-23 16:18:12 -0500, Petter Reinholdtsen wrote:
> [Daniel Kahn Gillmor]
>> I'm likely to try proposal (a) as 0.41-2 unless i hear other
>> suggestions.
>
> In Debian Edu we ran into a similar problem within debian-installer, when
> setting up Kerberos.  The installation would hang because the Linux kernel
> collect entropy from so few sources and almost none of the sources have
> activity during installation.  We solved it by running a shell script loop
> in the background checking the entropy level, and flushing the disk cache
> and doing find / to generate disk IO when entropy run low.
>
> Perhaps an idea for the test code?

this all sounds like a pretty high-energy set of workarounds.  What we'd
really like is to say declaratively that the test suite needs system
entropy :/  can we solve this problem centrally somehow?

 --dkg


signature.asc
Description: PGP signature

Bug#850986: keyboard focus stays in main window when opening compose window

[Thibaut Paumard]

Package: icedove
Version: 1:45.4.0-1
Severity: grave

Dear maintainers,

I have that spurious proble that very often, when I open a new compose
window (with ^N or by clicking on one of the reply-to buttons), the
keyboard focus stays in the main window. I start typing, which can
have nasty effects since the main indow recieves the events, such as,
for instance:
  - deleting emails;
  - ignoring conversations.

It is not immediate to get the focus to the compose winodw I am
interested in. Clicling in this window does not help, even after
having clicked in the main icedove window or in another window from an
unrelated application.

I have found two things that each help recover focus (no need to do
both, each one is sufficient on its own):

 1- closing the main window;

 2- opening yet another compose window: this new window then has focus
and I can from that point on get the focus in the window I like, including  
   the compose window that initially did not get focus.

This is not only anoying but also can cause data loss as I can end up
deleting messages inadvertently. Forunately I have never actually
purged a directory when that happened, but I consider myself lucky.

I am running GNOME 3 from testing, this bug has been there for a while
including when I was running cinnamon on jessie. It feels like it's
happening more often (almost, but not quite, always).

Kind regads, Thibaut.

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

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

Versions of packages icedove depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.15.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.1-5
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.4-2
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages icedove recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:5.2.3-1
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.4.0-1
ii  myspell-fr-gut [myspell-dictionary]   1:1.0-32

Versions of packages icedove suggests:
pn  apparmor  
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1

-- no debconf information

Bug#741422: git-buildpackage: breaks bash tab completion for filenames in git checkouts

[Guido Günther]

Hi Edward,
On Wed, Mar 12, 2014 at 11:48:22AM +, Edward Betts wrote:
> Package: git-buildpackage
> Version: 0.6.10
> Severity: normal
> 
> Recently bash tab completion stopped working for files in git checkouts.
> I removed git-buildpackage and it started working again. Something in
> /etc/bash_completion.d/git-buildpackage must be responsible. I'm able to
> reproduce this bug.

Sorry for the delay. Can you still reproduce this? I git bash complete
fine with gbp installed.
Cheers,
 -- Guido

Bug#850987: python-keystonemiddleware: FTBFS: Test failures

[Lucas Nussbaum]

Source: python-keystonemiddleware
Version: 4.9.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):
>   File "/<>/keystonemiddleware/auth_token/__init__.py", line 
> 320, in __call__
> response = self.process_request(req)
>   File "/<>/keystonemiddleware/auth_token/__init__.py", line 
> 582, in process_request
> content_type='application/json')
>   File "/usr/lib/python3/dist-packages/webob/exc.py", line 268, in __init__
> **kw)
>   File "/usr/lib/python3/dist-packages/webob/response.py", line 310, in 
> __init__
> "You cannot set the body to a text value without a "
> TypeError: You cannot set the body to a text value without a charset
> 
> 
> --
> Ran 347 tests in 13.902s
> 
> FAILED (failures=74, skipped=3)
> debian/rules:26: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   
http://aws-logs.debian.net/2017/01/11/python-keystonemiddleware_4.9.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#850988: autopkgtest: FTBFS: Test failures

[Lucas Nussbaum]

Source: autopkgtest
Version: 4.2.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):
> autopkgtest: DBG: testbed command exited with code 100
> autopkgtest: DBG: BadPackageError Test dependencies are unsatisfiable. A 
> common reason is that your testbed is out of date with respect to the 
> archive, and you need to use a current testbed, or try "--setup-commands 
> ro-apt-update".
> autopkgtest: DBG: testbed stop
> autopkgtest: DBG: testbed close, scratch=/tmp/autopkgtest.AaVGT6
> autopkgtest: DBG: sending command to testbed: close
> autopkgtest: DBG: got reply from testbed: ok
> autopkgtest: DBG: sending command to testbed: quit
> autopkgtest [22:26:59]: ERROR: erroneous package: Test dependencies are 
> unsatisfiable. A common reason is that your testbed is out of date with 
> respect to the archive, and you need to use a current testbed, or try 
> "--setup-commands ro-apt-update".
> autopkgtest: DBG: testbed stop
> 
> 
> --
> Ran 52 tests in 99.473s
> 
> FAILED (failures=1, skipped=2)
> debian/rules:38: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/autopkgtest_4.2.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#850990: nova: FTBFS: Test failures

[Lucas Nussbaum]

Source: nova
Version: 2:14.0.0-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):
>   File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
> return func(*args, **keywargs)
>   File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
> 291, in _test_microversions_inner_function
> self.assertEqual(200, res.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: 200 != 400
> 
> 
> --
> Ran 14287 tests in 124.274s
> 
> FAILED (failures=4, skipped=56)
> debian/rules:150: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/nova_14.0.0-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#850991: liblicense: FTBFS: ../../../modules/io/exempi.c:48:26: error: 'XMP_OPEN_OPNLYXMP' undeclared (first use in this function)

[Lucas Nussbaum]

Source: liblicense
Version: 0.8.1-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):
> /bin/bash ../../libtool --tag=CC   --mode=compile x86_64-linux-gnu-gcc 
> -DHAVE_CONFIG_H -I. -I../../../modules/io -I../.. -I../../../liblicense 
> -I../../liblicense -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/exempi-2.0 
> -g -Wall -g -O2 -Wall -Wextra -Wchar-subscripts -Wnested-externs 
> -Wpointer-arith -Wsign-compare -Wshadow -std=gnu89 -pedantic -D_SVID_SOURCE 
> -Wdeclaration-after-statement -MT exempi_la-exempi.lo -MD -MP -MF 
> .deps/exempi_la-exempi.Tpo -c -o exempi_la-exempi.lo `test -f 'exempi.c' || 
> echo '../../../modules/io/'`exempi.c
> libtool: compile:  x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
> -I../../../modules/io -I../.. -I../../../liblicense -I../../liblicense 
> -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/exempi-2.0 -g -Wall -g -O2 
> -Wall -Wextra -Wchar-subscripts -Wnested-externs -Wpointer-arith 
> -Wsign-compare -Wshadow -std=gnu89 -pedantic -D_SVID_SOURCE 
> -Wdeclaration-after-statement -MT exempi_la-exempi.lo -MD -MP -MF 
> .deps/exempi_la-exempi.Tpo -c ../../../modules/io/exempi.c  -fPIC -DPIC -o 
> .libs/exempi_la-exempi.o
> ../../../modules/io/exempi.c:1:1: warning: C++ style comments are not allowed 
> in ISO C90
>  // Creative Commons has made the contents of this file
>  ^
> ../../../modules/io/exempi.c:1:1: warning: (this will be reported only once 
> per input file)
> In file included from /usr/include/stdio.h:27:0,
>  from ../../../modules/io/exempi.c:19:
> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and 
> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
>  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
>^~~
> In file included from ../../../modules/io/exempi.c:25:0:
> /usr/include/exempi-2.0/exempi/xmp.h:338:3: warning: C++ style comments are 
> not allowed in ISO C90
>/// Packet offset in the file in bytes, -1 if unknown.
>^
> /usr/include/exempi-2.0/exempi/xmp.h:338:3: warning: (this will be reported 
> only once per input file)
> ../../../modules/io/exempi.c: In function 'exempi_read':
> ../../../modules/io/exempi.c:48:26: error: 'XMP_OPEN_OPNLYXMP' undeclared 
> (first use in this function)
>  #define XMP_OPEN_ONLYXMP XMP_OPEN_OPNLYXMP
>   ^
> ../../../modules/io/exempi.c:63:35: note: in expansion of macro 
> 'XMP_OPEN_ONLYXMP'
>   f = xmp_files_open_new(filename, XMP_OPEN_ONLYXMP);
>^~~~
> ../../../modules/io/exempi.c:48:26: note: each undeclared identifier is 
> reported only once for each function it appears in
>  #define XMP_OPEN_ONLYXMP XMP_OPEN_OPNLYXMP
>   ^
> ../../../modules/io/exempi.c:63:35: note: in expansion of macro 
> 'XMP_OPEN_ONLYXMP'
>   f = xmp_files_open_new(filename, XMP_OPEN_ONLYXMP);
>^~~~
> ../../../modules/io/exempi.c: In function 'exempi_write':
> ../../../modules/io/exempi.c:48:26: error: 'XMP_OPEN_OPNLYXMP' undeclared 
> (first use in this function)
>  #define XMP_OPEN_ONLYXMP XMP_OPEN_OPNLYXMP
>   ^
> ../../../modules/io/exempi.c:109:56: note: in expansion of macro 
> 'XMP_OPEN_ONLYXMP'
>   f = xmp_files_open_new(filename, XMP_OPEN_FORUPDATE | XMP_OPEN_ONLYXMP);
> ^~~~
> In file included from ../../../modules/io/exempi.c:23:0:
> ../../../modules/io/exempi.c: At top level:
> ../../../modules/io/exempi.c:159:16: warning: initialization from 
> incompatible pointer type [-Wincompatible-pointer-types]
> exempi_init,exempi_read,exempi_write,exempi_shutdown);
> ^
> ../../../liblicense/liblicense.h:875:1: note: in definition of macro 
> 'LL_MODULE_DEFINE'
>  read,   \
>  ^~~~
> ../../../modules/io/exempi.c:159:16: note: (near initialization for 
> 'll_module_desc.read')
> exempi_init,exempi_read,exempi_write,exempi_shutdown);
> ^
> ../../../liblicense/liblicense.h:875:1: note: in definition of macro 
> 'LL_MODULE_DEFINE'
>  read,   \
>  ^~~~
> ../../../modules/io/exempi.c:159:57: warning: ISO C does not allow extra ';' 
> outside of a function [-Wpedantic]
> exempi_init,exempi_read,exempi_write,exempi_shutdown);
>  ^
> In file included from ../../../modules/io/exe

Bug#850992: eclipse-mylyn: FTBFS: java.lang.reflect.InvocationTargetException

[Lucas Nussbaum]

Source: eclipse-mylyn
Version: 3.12.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):
> make[1]: Entering directory '/<>'
> # Regenerate org.eclipse.mylyn.builds.core code from model
> /usr/lib/eclipse/eclipse \
> -application org.eclipse.ant.core.antRunner  \
> -configuration debian/.eclipse-build/.platform/configuration \
> -buildfile debian/ecoreToJava.xml\
> -data debian/.eclipse-build  \
> -Dosgi.sharedConfiguration.area=debian/.eclipse-build/build/home \
> -consoleLog -noSplash
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support 
> was removed in 8.0
> !SESSION 2017-01-10 22:14:54.476 
> ---
> eclipse.buildId=debbuild
> java.version=1.8.0_111
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments:  -application org.eclipse.ant.core.antRunner -buildfile 
> debian/ecoreToJava.xml 
> -Dosgi.sharedConfiguration.area=debian/.eclipse-build/build/home
> Command-line arguments:  -os linux -ws gtk -arch x86_64 -application 
> org.eclipse.ant.core.antRunner -buildfile debian/ecoreToJava.xml -data 
> debian/.eclipse-build 
> -Dosgi.sharedConfiguration.area=debian/.eclipse-build/build/home -consoleLog
> 
> !ENTRY org.eclipse.osgi 4 0 2017-01-10 22:14:59.562
> !MESSAGE Application error
> !STACK 1
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.eclipse.ant.core.AntRunner.run(AntRunner.java:513)
>   at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600)
>   at 
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>   at 
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
>   at 
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
>   at 
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
>   at 
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
>   at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
>   at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
>   at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
> Caused by: java.lang.IllegalAccessError
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.setJavaClassPath(InternalAntRunner.java:1426)
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:561)
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:537)
>   ... 19 more
> Root exception:
> java.lang.IllegalAccessError
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.setJavaClassPath(InternalAntRunner.java:1426)
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:561)
>   at 
> org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:537)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.eclipse.ant.core.AntRunner.run(AntRunner.java:513)
>   at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600)
>   at 
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>   at 
> org.eclipse.core.runtime.internal.adaptor.

Bug#850989: caffe: FTBFS: libboost_python.so: undefined reference to `PyUnicodeUCS4_FromEncodedObject'

[Lucas Nussbaum]

Source: caffe
Version: 1.0.0~rc3+20161127-g24d2f67-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):
> /usr/bin/c++   -g -O2 
> -fdebug-prefix-map=/<>/caffe-1.0.0~rc3+20161127-g24d2f67=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall  -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-sign-compare -Wno-uninitialized -O3 
> -DNDEBUG  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed 
> CMakeFiles/test.testbin.dir/test_accuracy_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_argmax_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_batch_norm_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_batch_reindex_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_benchmark.cpp.o 
> CMakeFiles/test.testbin.dir/test_bias_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_blob.cpp.o 
> CMakeFiles/test.testbin.dir/test_caffe_main.cpp.o 
> CMakeFiles/test.testbin.dir/test_common.cpp.o 
> CMakeFiles/test.testbin.dir/test_concat_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_contrastive_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_convolution_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_crop_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_data_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_data_transformer.cpp.o 
> CMakeFiles/test.testbin.dir/test_db.cpp.o 
> CMakeFiles/test.testbin.dir/test_deconvolution_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_dummy_data_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_eltwise_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_embed_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_euclidean_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_filler.cpp.o 
> CMakeFiles/test.testbin.dir/test_filter_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_flatten_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_gradient_based_solver.cpp.o 
> CMakeFiles/test.testbin.dir/test_hdf5_output_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_hdf5data_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_hinge_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_im2col_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_image_data_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_infogain_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_inner_product_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_internal_thread.cpp.o 
> CMakeFiles/test.testbin.dir/test_io.cpp.o 
> CMakeFiles/test.testbin.dir/test_layer_factory.cpp.o 
> CMakeFiles/test.testbin.dir/test_lrn_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_lstm_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_math_functions.cpp.o 
> CMakeFiles/test.testbin.dir/test_maxpool_dropout_layers.cpp.o 
> CMakeFiles/test.testbin.dir/test_memory_data_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_multinomial_logistic_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_mvn_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_net.cpp.o 
> CMakeFiles/test.testbin.dir/test_neuron_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_platform.cpp.o 
> CMakeFiles/test.testbin.dir/test_pooling_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_power_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_protobuf.cpp.o 
> CMakeFiles/test.testbin.dir/test_random_number_generator.cpp.o 
> CMakeFiles/test.testbin.dir/test_reduction_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_reshape_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_rnn_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_scale_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_sigmoid_cross_entropy_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_slice_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_softmax_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_softmax_with_loss_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_solver.cpp.o 
> CMakeFiles/test.testbin.dir/test_solver_factory.cpp.o 
> CMakeFiles/test.testbin.dir/test_split_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_spp_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_stochastic_pooling.cpp.o 
> CMakeFiles/test.testbin.dir/test_syncedmem.cpp.o 
> CMakeFiles/test.testbin.dir/test_tanh_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_threshold_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_tile_layer.cpp.o 
> CMakeFiles/test.testbin.dir/test_upgrade_proto.cpp.o 
> CMakeFiles/test.testbin.dir/test_util_blas.cpp.o  -o 
> ../../../test/test.testbin -rdynamic ../../../lib/libgtest.a 
> ../../../lib/libcaffe.so.1.0.0-rc3 ../../../lib/libproto.a -lboost_system 
> -lboost_thread -lboost_filesystem -lboost_chrono -lboost_date_time 
> -lboost_atomic -lpthread -lpthread -lglog -lgflags -lprotobuf -lhdf5_cpp 
> /usr/lib/x86_64-linux-gnu/hdf5/serial

Bug#850996: ikiwiki: FTBFS: Test failures

[Lucas Nussbaum]

Source: ikiwiki
Version: 3.20161229.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):
> ok 10
> ok 11
> ok
> 
> Test Summary Report
> ---
> t/git-cgi.t  (Wstat: 512 Tests: 21 Failed: 3)
>   Failed tests:  15, 18, 21
>   Non-zero exit status: 2
>   Parse errors: No plan found in TAP output
> t/relativity.t   (Wstat: 0 Tests: 136 Failed: 0)
>   TODO passed:   71
> Files=62, Tests=2948, 28 wallclock secs ( 0.50 usr  0.08 sys + 31.66 cusr  
> 2.48 csys = 34.72 CPU)
> Result: FAIL
> Failed 1/62 test programs. 3/2948 subtests failed.
> Makefile:1225: recipe for target 'test_dynamic' failed

The full build log is available from:
   http://aws-logs.debian.net/2017/01/11/ikiwiki_3.20161229.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.