Bug#815308: streamlining license version "or later" version syntax

[Daniel Pocock]

On 21/02/16 05:52, Ben Finney wrote:
> Daniel Pocock  writes:
> 
>> W: libfoobar source: missing-license-paragraph-in-dep5-copyright gpl-2+
>> (paragraph at line X)
>>
>> Should lintian ignore the '+' suffix when determining if a License
>> paragraph exists?
> 
> Your position, if I understand correctly, is that the trailing “+”
> should not be considered part of the license name; it should instead be
> considered part of the license grant.
> 


Yes, that would be a reasonable way to explain it.


> That's a position I agree with. Perhaps we should progress bug#786470
> https://bugs.debian.org/786470> and clarify the distinction between
> the license grant and license conditions.
> 
> Lintian is presently doing the right thing according to the copyright
> format specification 1.0, I believe. The trailing “+” is not
> distinguished in that specification; a plain reading of the
> specification has that just as another character in the license name.
> 
> Part of that revision to the specification should then be to make clear
> that the License-Grant field grants a set of licenses to the recipient;
> the License field specifies the effective license conditions on the
> work; and a trailing “+” is to be interpreted as a special non-name
> character that modifies the set of license conditions granted.
> 
> I think the proposed change to Lintian would not be appropriate until
> after the change to policy's specification of the copyright file, to
> make explicit the effect of “+”. That policy change could be part of
> resolving bug#786470.
> 

OK, if you feel the current wording of the policy does not permit this,
the change can wait

Should the BTS record that 786470 blocks 815308?

In the meantime, people should override the lintian warning or they
should duplicate the license paragraph if they have this situation?

Bug#815344: Processed (with 1 error): Re: Bug#815344: preseeding: empty tasksel not possible

[Geert Stappers]

Control: severity -1 normal
Stop

On Sun, Feb 21, 2016 at 07:51:31AM +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > severity normal
> Unknown command or malformed arguments to command.

Oops

Bug#815392: django-recurrence: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . returned exit code 13

[Chris Lamb]

Source: django-recurrence
Version: 1.2.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

django-recurrence fails to build from source in unstable/amd64:

  [..]


 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: cd 
/home/lamby/temp/cdt.20160221091515.LCVwMzn9Sa/django-recurrence-1.2.0/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  = test session starts 
==
  platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
  rootdir: 
/home/lamby/temp/cdt.20160221091515.LCVwMzn9Sa/django-recurrence-1.2.0, 
inifile: 
  collected 0 items
  
  = no tests ran in 0.01 seconds 
=
  E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/home/lamby/temp/cdt.20160221091515.LCVwMzn9Sa/django-recurrence-1.2.0/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . 
returned exit code 13
  debian/rules:10: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

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


django-recurrence.1.2.0-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815396: python-snuggs: FTBFS: E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5

[Chris Lamb]

Source: python-snuggs
Version: 1.3.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-snuggs fails to build from source in unstable/amd64:

  [..]

 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: cd 
/home/lamby/temp/cdt.20160221091808.ywQnUdn26V/python-snuggs-1.3.1/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  = test session starts 
==
  platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
  rootdir: /home/lamby/temp/cdt.20160221091808.ywQnUdn26V/python-snuggs-1.3.1, 
inifile: 
  collected 0 items
  
  = no tests ran in 0.00 seconds 
=
  E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/home/lamby/temp/cdt.20160221091808.ywQnUdn26V/python-snuggs-1.3.1/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit 
code 13
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

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


python-snuggs.1.3.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815393: pypuppetdb: FTBFS: E: pybuild pybuild:274: test: plugin custom failed with: exit code=5: python2.7 -m pytest -m unit

[Chris Lamb]

Source: pypuppetdb
Version: 0.1.1+git080614-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

pypuppetdb fails to build from source in unstable/amd64:

  [..]

 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160221091633.CnPq7WYdDo/pypuppetdb-0.1.1+git080614'
  PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} -m pytest -m unit" \
dh_auto_test
  I: pybuild base:184: python2.7 -m pytest -m unit
  = test session starts 
==
  platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
  rootdir: 
/home/lamby/temp/cdt.20160221091633.CnPq7WYdDo/pypuppetdb-0.1.1+git080614, 
inifile: setup.cfg
  collected 60 items
  
  == 60 tests deselected by "-m 'unit'" 
==
   60 deselected in 0.13 seconds 
=
  E: pybuild pybuild:274: test: plugin custom failed with: exit code=5: 
python2.7 -m pytest -m unit
  dh_auto_test: pybuild --test --test-tox -i python{version} -p 2.7 --dir . 
returned exit code 13
  debian/rules:12: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160221091633.CnPq7WYdDo/pypuppetdb-0.1.1+git080614'
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


pypuppetdb.0.1.1+git080614-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815394: python-certifi: FTBFS: h_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . returned exit code 13

[Chris Lamb]

Source: python-certifi
Version: 2015.11.20.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-certifi fails to build from source in unstable/amd64:

  [..]

 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: cd 
/home/lamby/temp/cdt.20160221091706.x6lrDRbUP9/python-certifi-2015.11.20.1/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  = test session starts 
==
  platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
  rootdir: 
/home/lamby/temp/cdt.20160221091706.x6lrDRbUP9/python-certifi-2015.11.20.1, 
inifile: 
  collected 0 items
  
  = no tests ran in 0.00 seconds 
=
  E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/home/lamby/temp/cdt.20160221091706.x6lrDRbUP9/python-certifi-2015.11.20.1/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . 
returned exit code 13
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

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


python-certifi.2015.11.20.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815395: python-kdcproxy: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . returned exit code 13

[Chris Lamb]

Source: python-kdcproxy
Version: 0.3.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-kdcproxy fails to build from source in unstable/amd64:

  [..]


 dh_auto_test -O--buildsystem=pybuild
  I: pybuild base:184: cd 
/home/lamby/temp/cdt.20160221091726.e0RWSToYdG/python-kdcproxy-0.3.2/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  = test session starts 
==
  platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1
  rootdir: 
/home/lamby/temp/cdt.20160221091726.e0RWSToYdG/python-kdcproxy-0.3.2, inifile: 
tox.ini
  plugins: cov-2.2.1
  collected 0 items
  
  = no tests ran in 0.00 seconds 
=
  E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/home/lamby/temp/cdt.20160221091726.e0RWSToYdG/python-kdcproxy-0.3.2/.pybuild/pythonX.Y_2.7/build;
 python2.7 -m pytest 
  dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . 
returned exit code 13
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

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


python-kdcproxy.0.3.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#809319: jessie-pu: package sane-backends/1.0.24-8

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/21/2016 07:38 AM, Jörg Frings-Fürst wrote:
> I have no upload rights. So I ask my sponsor to upload it. But he
> has a lot of work in his job.
> 
> It's fine if someone can upload it. The package is on mentors[1].

I'm taking care of it right now. No worries.

Just got up. It's Sunday after all ;).

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyXb6AAoJEHQmOzf1tfkTV9gP/3aECdvRBz3vXvbsLxygbfzG
57NEnrEY0eREiEKWZ1WqUEbyztVZjihqWxrv45S4uooqMdIFqKHIhbTDHaN4rfW8
zBFx/PtYUagc/yhyTEj9VxyLYBz6HLue5BWEfbSqe8AhzQf1xc2bdNv0lfbqbX8X
iJJcAyBxRI1W9hotRDzl8EsYoVhNlsaI4jpNeQSwt92aDyM4kUhRTL5yOdD2khTk
dWXcoS1bR3x9V1cfEhZ1bZMf7WXRFWHzOd29nB9DNhV2Dx5u4fC9ak3binVHThyV
UL+KYi9dQwuB943RXb+6MljsNzTmrZBU64d8980fNsft7T4UZk8UeGriW9vsPCU4
GsYsq/vXDGPl1DLvc5BHUXBnTzhMUs0wnRT/KLgcn28HS1ZsFfcYk0WrcwFWZ636
ya1nT6N9zf3sZ9GEhJG/YImCTuE08fQDtEDjSjmonBUjhwL8b8CdX2n+tIbr+bvn
qpOsiyCk9xbzkMxVoHppa22fQBwuKvhClE7StZjfsxCPeDnK02UvnAnGm7fMws+B
uBF4xTKUp4OX8Ttl6k3xpTeezHMqN6rLT+dRQse5L4fSTzv6FUxCgAtSP1knD6C9
uw10ZogJpBoIcuR2sMYbZkwXxER71uVIp9WU6kJ9Rt6k86VdQMv066hHS1OyGava
9pQyMSrowbQlETt9djFL
=uejZ
-END PGP SIGNATURE-

Bug#815397: r-cran-tm: FTBFS: ERROR: dependencies 'NLP', 'slam' are not available for package 'tm'

[Chris Lamb]

Source: r-cran-tm
Version: 0.6-2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

r-cran-tm fails to build from source in unstable/amd64:

  [..]

  echo "R:Depends=r-base-core (>= 3.2.3-6), r-api-3" >> 
debian/r-cran-tm.substvars
  if test -f /usr/bin/xvfb-run; then\
 xvfb-run -a\
R CMD INSTALL -l 
/home/lamby/temp/cdt.20160221091835.7kRrMoa2Ut/r-cran-tm-0.6-2/debian/r-cran-tm/usr/lib/R/site-library
 --clean \
 .  \
"--built-timestamp=\"Thu, 18 Feb 2016 21:43:55 
+0100\"" \
;   \
else\
 R CMD INSTALL -l 
/home/lamby/temp/cdt.20160221091835.7kRrMoa2Ut/r-cran-tm-0.6-2/debian/r-cran-tm/usr/lib/R/site-library
\
--clean  .  \
"--built-timestamp=\"Thu, 18 Feb 2016 21:43:55 
+0100\"" \
;   \
fi
  ERROR: dependencies 'NLP', 'slam' are not available for package 'tm'
  * removing 
'/home/lamby/temp/cdt.20160221091835.7kRrMoa2Ut/r-cran-tm-0.6-2/debian/r-cran-tm/usr/lib/R/site-library/tm'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

  [..]

The full build log is attached.


Regards,

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


r-cran-tm.0.6-2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815398: ros-ros-comm: FTBFS: dh_install: python-rosbag missing files: usr/lib/*/rosbag

[Chris Lamb]

Source: ros-ros-comm
Version: 1.11.16-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ros-ros-comm fails to build from source in unstable/amd64:

  [..]

  running build
  running build_py
  creating 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/lib.linux-x86_64-2.7
  creating 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/lib.linux-x86_64-2.7/rostopic
  copying src/rostopic/__init__.py -> 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/lib.linux-x86_64-2.7/rostopic
  running build_scripts
  creating 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/scripts-2.7
  copying and adjusting scripts/rostopic -> 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/scripts-2.7
  changing mode of 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/scripts-2.7/rostopic
 from 644 to 755
  running install
  running install_lib
  creating 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/lib/python2.7/dist-packages/rostopic
  copying 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/lib.linux-x86_64-2.7/rostopic/__init__.py
 -> 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/lib/python2.7/dist-packages/rostopic
  byte-compiling 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/lib/python2.7/dist-packages/rostopic/__init__.py
 to __init__.pyc
  running install_scripts
  copying 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build/tools/rostopic/scripts-2.7/rostopic
 -> 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/bin
  changing mode of 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/bin/rostopic
 to 755
  running install_egg_info
  Writing 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/lib/python2.7/dist-packages/rostopic-1.11.16.egg-info
  -- Installing: 
/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/debian/tmp/usr/lib/rostopic/rostopic
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160221091918.5hY6ViggBF/ros-ros-comm-1.11.16/build'
 dh_install -O--parallel -O--buildsystem=cmake -O--builddirectory=build
  dh_install: python-rosbag missing files: usr/lib/*/rosbag
  dh_install: topic-tools missing files: usr/lib/*/topic_tools
  dh_install: missing files, aborting
  debian/rules:7: recipe for target 'binary' failed
  make: *** [binary] Error 255

  [..]

The full build log is attached.


Regards,

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


ros-ros-comm.1.11.16-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#814954: libgcrypt20: add libgcrypt-mingw-w64-dev for cross-building to Windows targets

[Andreas Metzler]

On 2016-02-20 Daniel Kahn Gillmor  wrote:
[...]
> Ugh, it looks like it builds when building from git, but not from a
> tarball.  This is because we're using autoreconf and upstream's
> configure.ac relies on being in a git repo (it selects the revision
> number from the number of git commits in the active history).

> The attached patch works to build it from a tarball.  It is modelled off
> the one we're using for libgpg-error, which derives the revision number
> From the length of debian/changelog instead of from the count of git
> commits.
[...]
> -  m4_esyscmd([git rev-parse --short HEAD | tr -d '\n\r']))
> +  m4_esyscmd([printf %x $(wc -l < debian/changelog)]))
[...]

Why don't we simply hardcode this as 1, 2 or 42 instead? Having changing
builds without source changes (just becuse the lenght of
debian/changelog increased) seems wrong to me.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Alexander Clouter]

On Sun, Feb 21, 2016 at 03:45:24AM +, Ben Hutchings wrote:

Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
was able to get a traceback this way.

It looks like the efi-bgrt driver is crashing, and there is an upstream
fix for it.  I'll upload a test version of the package shortly.


This test version is now available at
https://people.debian.org/~benh/packages/unstable/

Please report back whether this does or doesn't fix the problem for
you.


Works for Me(tm)

Thanks

--
Alexander Clouter
.sigmonster says: Excellent day to have a rotten day.

Bug#815399: spykeutils: FTBFS: AssertionError: array(1.0) * s != array(1.0) * s**2

[Chris Lamb]

Source: spykeutils
Version: 0.4.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

spykeutils fails to build from source in unstable/amd64:

  [..]

  ==
  FAIL: test_respects_k_argument 
(spykeutils.tests.test_scipy_quantities.TestScipyDiag)
  --
  Traceback (most recent call last):
File 
"/home/lamby/temp/cdt.20160221092242.wqfwVnb5ST/spykeutils-0.4.2/spykeutils/tests/test_scipy_quantities.py",
 line 260, in test_respects_k_argument
  self.assertEqual(expected.units, actual.units)
  AssertionError: array(1.0) * s != array(1.0) * s**2
  
  --
  Ran 180 tests in 2.268s
  
  FAILED (errors=25, failures=3)
  debian/rules:29: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160221092242.wqfwVnb5ST/spykeutils-0.4.2'
  debian/rules:9: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


spykeutils.0.4.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Guy Durrieu]

Le 21/02/2016 04:45, Ben Hutchings a écrit :

 Hi Ben !

This test version is now available at
https://people.debian.org/~benh/packages/unstable/

Please report back whether this does or doesn't fix the problem for
you.

Ben.



It works for me.

Thanks !

Regards.

-- GD.

Bug#815344: preseeding: empty tasksel not possible

[Philip Hands]

John Wyzer  writes:

> Package: debian-installer
> Version: 20150422+deb8u3
> Severity: important
> Tags: d-i
>
> I used the current netboot.tar.gz for debian jessie from 
> http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/
>  to create a pxe based preseeded installation.
> Everything works fine except the tasksel configuration.
> I don't want to execute any of the tasksel tasks.
> Whatever I do, the installer starts to install about 1500 packages including 
> Xorg.
>
> I tried
>   tasksel tasksel/first   multiselect

As far as I'm aware, that's all that should be needed.

I presume you're not doing anything complicated (like including other
preseed files that might set the setting back).

It might be worth checking that your setting really was applied by
flipping to the console once the install is underway (Ctrl-Alt-F2) and
running:

  debconf-get tasksel/first

to make sure it's empty.

You might also want to add DEBCONF_DEBUG=5 to your kernel command line,
to make the install much more verbose, which might let you work out
what's going on.

BTW The resulting syslog ends up as /var/log/installer/syslog on the
installed system.

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


signature.asc
Description: PGP signature

Bug#815307: usbutils: FTBFS on hurd-i386: unsatisfiable Build-Depends: libusb-1.0-0-dev

[Andreas Beckmann]

On 2016-02-21 08:53, Aurelien Jarno wrote:
>> usbutils FTBFS on hurd-i386 since the 
>>   Build-Depends: libusb-1.0-0-dev
>> cannot be satisfied on that platform.
> 
> What I can do about that? usbutils makes no sense without USB support,

OK, I'll request usbutils to be decrufted.

Andreas

Bug#785047: vsftpd/3.0.2-17+deb8u1

[John Paul Adrian Glaubitz]

On 02/20/2016 11:09 PM, Julien Cristau wrote:
> Doesn't look like that's happening.  Closing.

Sorry, I completely missed the pu updates Joerg prepared. That was not
done intentionally, but it was rather somewhere lost in communication.

I'd be happy to take carre of vsftpd.

@Joerg: Could you re-upload the package to mentors?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Vincent Bernat]

 ❦ 21 février 2016 03:45 GMT, Ben Hutchings  :

>> Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
>> was able to get a traceback this way.
>> 
>> It looks like the efi-bgrt driver is crashing, and there is an upstream
>> fix for it.  I'll upload a test version of the package shortly.
>
> This test version is now available at
> https://people.debian.org/~benh/packages/unstable/
>
> Please report back whether this does or doesn't fix the problem for
> you.

It works fine for me. Thanks!
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x

[Sebastian Dröge]

On Di, 2015-11-10 at 20:28 +, Olly Betts wrote:
> 
> I'll try to find time to test it.  Also happy for someone else to test
> the amended patch and NMU if it works, but please keep me in the loop to
> avoid duplicating effort.
> 
> (If someone does NMU, you could usefully drop `--enable-sdl` in
> debian/rules to close #802770 - there's no corresponding BD so this
> doesn't affect the built result in a clean chroot).

I'm looking into this now btw, will provide an updated patch some time
later today or so. How can I test the wxwidgets GStreamer integration?

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

Bug#815400: transition: ros-ros-comm

[Jochen Sprickerhof]

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

Hi,

we want to transition librosconsole to link against log4cxx instead of an
internal print version. librosconsole exports these symbols, so other packages
depend on the choice and we can't simply switch it. We went for a Soname bump
because it's Debian internal anyhow, as upstream declined to add one.

The new version of ros-ros-comm is in experimental already.

Ben file:

title = "ros-ros-comm";
is_affected = .depends ~ "librosconsole0d" | .depends ~ "librosconsole1d";
is_good = .depends ~ "librosconsole1d";
is_bad = .depends ~ "librosconsole0d";

We are maintainer of all reverse dependencies and we did test rebuilds already
and have all needed patches prepared. All rdepends are listed here:

https://release.debian.org/transitions/html/auto-ros-ros-comm.html

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

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

Bug#694992: mutt: hangs indefinitely with "No authenticators available" if smtp_authenticators = 'gssapi' and fails

[Antonio Radici]

tag 694992 +moreinfo
thanks

On Mon, Dec 03, 2012 at 03:07:49AM +, Tom Jones wrote:
> Package: mutt
> Version: 1.5.21-6.2
> Severity: important
> 
> Dear Maintainer,
> 
> I have:
> 
> set smtp_authenticators = 'gssapi'

Hi Christian && Tom,
do you have a way to reproduce this for me? Christian in particular confirmed
that this bug is still happening in 1.5.24-1, which is particularly worrying.

Unfortunately I don't use gssapi anywhere so I can't reproduce this problem, can
you suggest me a way to do so?

Cheers
Antonio

Bug#815401: dh_makeshlibs: man page still speaks about postinst and postrm, not triggers

[Eugene V. Lyubimkin]

Package: debhelper
Version: 9.20150507
Severity: minor

Dear Maintainer,

Since recently, dh_makeshlibs does not generated postinst and postrm
files anymore to call ldconfig, but a dpkg trigger instead.

The description in the man page still speaks about the old way. This can
be confusing especially if using older lintian which produces an error
if it doesn't see postrm/postinst, since nothing suggests to a
maintainer that it isn't a bug in dh_makeshlibs.

Please modify the man page accordingly.

Thanks!

-- System Information:
Debian Release: 8.0
Architecture: amd64 (x86_64)

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

Versions of packages debhelper depends on:
ii  binutils  2.25-5
ii  dpkg  1.17.24
ii  dpkg-dev  1.17.24
ii  file  1:5.22+15-1
ii  libdpkg-perl  1.17.24
ii  man-db2.7.0.2-5
ii  perl  5.20.2-6
ii  po-debconf1.0.16+nmu3

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#815253: Seems to fail when gcc is not available

[Guillem Jover]

Control: reassign -1 meson

Hi!

On Sat, 2016-02-20 at 14:52:43 +0200, Jussi Pakkanen wrote:
> Package: libdpkg-perl
> Version: 1.18.4

> The Meson package is running debtests that compile a test project
> separately with gcc and clang. This has started failing with an error
> message from libdpkg-perl. The full log is here:
> 
> https://ci.debian.net/data/packages/unstable/amd64/m/meson/20160218_083321.autopkgtest.log.gz
> 
> The log shows that Meson's test runs successfully but something prints this:
> 
> Can't exec "gcc": No such file or directory at
> /usr/share/perl5/Dpkg/Arch.pm line 126.
> dpkg-architecture: warning: cannot determine CC system type, falling back
> to default (native compilation)
> 
> It seems that libdpkg-perl gets confused by the fact that clang is
> installed on the system but gcc is not and prints a warning to stderr. This
> causes Debian's test runner to flag the test as a failure even though the
> actual test passes. I don't know what calls into libdpkg-perl or why, the
> test itself does not do that.

It seem to me dpkg-architecture is being called in «mesonbuild/mesonlib.py».

> It seems like libdpkg-perl should be able to handle a missing gcc and fall
> back to using clang instead.

Currently the default and expected compiler defining the ABI of a dpkg
arch is gcc. And build flags are based on what the current gcc default
supports. Falling back natively to clang in dpkg would break several
assumptions. My current stance on this is that dpkg should make it
possible to use clang or any other compatible compiler, but then this
should be a user/maintainer initiated action, and any fallout should
be the responsibility of whoever requested that to dpkg-dev

In this case just setting CC=clang before anything that involves a
call to a script in dpkg-dev, should make it work. Thus reassigning.

Thanks,
Guillem

Bug#815346: [Debian-ha-maintainers] Bug#815346: crmsh: add multiarch support in config.py (libdir)

[Christoph Berg]

Control: tags -1 = upstream moreinfo

Re: Daniel Hoffend 2016-02-20 <20160220224920.GA4650@dotCarbon>
> Subject: [PATCH] medium: config: add multiarch support for libdir
> 
> Debian and Ubuntu doesn't use the directory /usr/lib64. They switched to
> a different directory structure for better multiarch support.

Hi Daniel,

the patch is not sufficient. You forgot that there are two dozen other
architectures in Debian, and several more out there. I don't think
including all possible arch-os-vendor triplets in libdir will lead
anywhere; you'll likely need to generate that dynamically.

We've been pondering to move the pacemaker binaries to plain
/usr/lib/pacemaker/ via ./configure --libexecdir which would solve the
issue without any patch for us.

> This also fixes a problem where crmsh can't find crmd on recent
> Debian/Ubuntu 64bit installations (same as in #67) because the
> autodetection doesn't find the correct crm_daemon_dir path
> 
> References:
> * https://wiki.debian.org/Multiarch/
> * https://wiki.ubuntu.com/MultiarchSpec
> ---
>  modules/config.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/modules/config.py b/modules/config.py
> index 25eaea7..82d09f5 100644
> --- a/modules/config.py
> +++ b/modules/config.py
> @@ -19,7 +19,9 @@
>  _PATHLIST = {
>  'datadir': ('/usr/share', '/usr/local/share', '/opt'),
>  'cachedir': ('/var/cache', '/opt/cache'),
> -'libdir': ('/usr/lib64', '/usr/libexec', '/usr/lib',
> +'libdir': ('/usr/lib64', '/usr/lib/x86_64-linux-gnu', 
> '/usr/lib/i386-linux-gnu',
> +   '/usr/libexec', '/usr/lib', '/usr/local/lib64',
> +   '/usr/local/lib/x86_64-linux-gnu', 
> '/usr/local/lib/i386-linux-gnu',
> '/usr/local/lib64', '/usr/local/libexec', '/usr/local/lib'),
>  'varlib': ('/var/lib', '/opt/var/lib'),
>  'wwwdir': ('/srv/www', '/var/www')

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/

Bug#815369: [BUG] command line definitions not expanded

[Gavin Smith]

On 21 February 2016 at 06:19, Norbert Preining  wrote:
> Hi Gavin, hi all
>
> (please keep Cc)
>
> I am sorry for all the bug reports, but here is the next one that
> surfaced when building the documentation for gcc.
>
> In short, it seems that definitions given on the command line
> --command='@set foobar value'
> are not properly expanded in the aux files.
>
> Here a minimal not working example:
>
> The following code works without problems:
> \input texinfo   @c -*-texinfo-*-
> @set cmd1 HELLO
>
> What ever
> @anchor{@value{cmd1} doc}@anchor{0}
> Here we go
> @bye
>
> But when I remove the @set line and instead call
> texi2pdf --command='@set cmd1 HELLO' mwe.texi
> I get the following error:
>
> /home/norbert/Debian/gcc-doc/mwe/mwe.aux:1: TeX capacity exceeded, sorry 
> [input
>  stack size=5000].
> @value ->@begingroup @makevalueexpandable
>   @valuexxx
> .
> l.1 ..., used in @value, is not set.} doc-title}{}
>
>
> The reason is that the mwe.aux file contains:
>
> @xrdef{{[No value for ``cmd1'']}@message {Variable `cmd1', used in @value, is 
> not set.} doc-title}{}

The problem is that @setfilename is missing from the file, and
texi2dvi looks for that line to add the extra line. @setfilename was
required before, so this isn't a regression (I hope).

Here's a patch. Please try it, and if it works fine, I'll commit it
and upload the new texi2dvi.

It might work fine just to always add the extra lines after the first,
depending on how people use this command: for example, --command
"\ngngnngng" would break for older versions of texinfo.tex (similarly
index commands could break, and possibly others as well). I can't
think of a likely use-case which would break, but it's more reliable
to do it this way.

Index: texi2dvi
===
--- texi2dvi(revision 7006)
+++ texi2dvi(working copy)
@@ -1312,7 +1312,14 @@ insert_commands ()
 verbose "Inserting extra commands: $textra"
 case $in_lang in
   latex)   textra_cmd=1i;;
-  texinfo) textra_cmd='/^@setfilename/a';;
+  texinfo)
+# If @setfilename is used in the first few lines of the file,
+# add the extra lines after it, otherwise add after the first line.
+if sed 10q "$in_input" | grep "^@setfilename"; then
+  textra_cmd='/^@setfilename/a'
+else
+  textra_cmd=1a
+fi ;;
   *)   error 1 "internal error, unknown language: $in_lang";;
 esac
 $SED "$textra_cmd\\

Bug#814855: Will it be fixed later ?

[Gael Le Mignot]

Hello,

This sounds like a pretty serious bug to me - making a whole serie of
hardware unusuable in Sid.

I have a SB Live! card too, and don't plan to change it anytime soon.

Will that be fixed in a later (like 4.5) kernel version ? I really hope
Stretch won't be released with such a regression.

And using an older kernel is not really an option, I plan to buy a
graphic card requiring AMDGPU driver soon, so there will no option to
have both my GPU and my soundcard working on Debian ?

I don't really know the details about NVDIMM_PFN and what it implies,
but this current situation seems problematic and I hope a solution can
be found.

Regards,

Bug#815307: usbutils: FTBFS on hurd-i386: unsatisfiable Build-Depends: libusb-1.0-0-dev

[Aurelien Jarno]

On 2016-02-21 09:48, Andreas Beckmann wrote:
> On 2016-02-21 08:53, Aurelien Jarno wrote:
> >> usbutils FTBFS on hurd-i386 since the 
> >>   Build-Depends: libusb-1.0-0-dev
> >> cannot be satisfied on that platform.
> > 
> > What I can do about that? usbutils makes no sense without USB support,
> 
> OK, I'll request usbutils to be decrufted.

What do you want to get decrufted? I really doubt we have an hurd-i386
version of usbutils somewhere in the archive or even on snapshot.d.o.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#815369: [BUG] command line definitions not expanded

[Norbert Preining]

HI Gavin,

> The problem is that @setfilename is missing from the file, and
> texi2dvi looks for that line to add the extra line. @setfilename was
> required before, so this isn't a regression (I hope).

Ahh, I see. The original did have a line like this:
@setfilename @value{cmd1}.info
so it might be necessary to add it *before* this line.

Here is the had of the original file (gnat_rm.texi):
\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename @value{fngnatrm}.info
@documentencoding UTF-8
@ifinfo
@*Generated by Sphinx 1.3b2.@*
@end ifinfo
@settitle GNAT Reference Manual
@defindex ge
@paragraphindent 0
@exampleindent 4
@finalout
@dircategory GNU Ada Tools 
@direntry
* @value{fngnatrmlong}: (@value{fngnatrm}).  Reference Manual for GNU Ada tools.
@end direntry

@definfoenclose strong,`,'
@definfoenclose emph,`,'
@c %**end of header


Maybe better to add it *before* the @setfilename directive?

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#815368: [Pkg-alsa-devel] Bug#815368: libasound2-plugins: Victor Vran game crash with this package installed

[Berillions]

2016-02-21 8:42 GMT+01:00 Elimar Riesebieter :

> * Berillions  [2016-02-21 01:46 +0100]:
>
> > Package: libasound2-plugins
> > Version: 1.1.0-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > I bought and downloaded Victor Vran game on GoG.com (
> > http://www.gog.com/game/victor_vran).
> > You can see that the game requires libasound2{-data,-plugins}:i386
> packages
> > dependencies.
>
> I see that this isn't a official Debian package.
>
> Yes, the game is "officialy" supported by Ubuntu and Linux-Mint which are
debian based...


> > After to downloaded, installed the game and dependencies, i launch the
> game
> > and ... it crashes directly.
> > The output console for the crash is this :
> >
> >  --
> > "berillions@debian64-test:/media/Autres/Jeux/Victor Vran$ ./start.sh
> > Running Victor Vran
> > Language: French
> > Voice Language: English
> > Protocol error: bad 3 (Window); Sequence Number 5
> >  Opcode (20, 0) = GetProperty
> >  Bad resource 587630196 (0x23068674)
> >  at -e line 15.
> > *** Texture headers: 5568 loaded, 0 newer, 3 ms
> >
> > *** graphics info
> > GPU GeForce GTX 970M/PCIe/SSE2
> > APIopengl
> > Platform: {
> > desktop = true,
> > developer = false,
> > editor = true,
> > gog = true,
> > goldmaster = true,
> > linux = true,
> > }
> >
> > support/gog_com.shlib : ligne 94 : 15328 Erreur de segmentation  (core
> > dumped)./"${bin_64}""
>
> There is no reference to a alsa bug
>
> Right, so it's very complicated to find where come from the problem with
this issue.


> >  --
> >
> > For my first test, i uninstalled the libasound2-plugins package and i
> > re-launched the game.
> > Result = The game works but i have no sound in-game so it is unplayable.
> > The output console when i launch the game without libasound2-plugins
> > package is this :
> >[...]
> >
> > ALSA lib conf.c:3357:(snd_config_hooks_call) Cannot open shared library
> > libasound_module_conf_pulse.so
>
> Do you have pulseaudio installed?
>

Yes, Gnome 3 is installed and use PulseAudio.

>
> > ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
> > AL lib: alsa.c:512: Could not open playback device 'default': No such
> file
> > or directory
> > AL lib: oss.c:169: Could not open /dev/dsp: No such file or directory
>
> Install alsa-oss and modprobe snd-pcm-oss.
>
> I installed the package lauch the command and the game works and i have
sound. Install libasound2-plugins still crash the game
But the question is : How i do to play at others games which need the
package if Victor Vran crash with it ?

I found a solution but for me, it's not proper :
1- Install libpulsedsp:i386 package
2- cp "/usr/bin/padsp /usr/bin/padsp_32"
3- nano "/usr/bin/padsp_32" and change LD_PRELOADER=/usr/lib/x86_64... to
LD_PRELOADER=/usr/lib/i386...
4- launch the game with padsp_32 ./VictorVranGoG


> Elimar
> --
>   Learned men are the cisterns of knowledge,
>   not the fountainheads ;-)
>

Maxime

Bug#775961: supervisor: package can not be upgraded

[Orestis Ioannou]

Hello,

Sorry I haven't  checked this error since adopting the package.
I guess you fixed this by now but:


On Wed, 21 Jan 2015 23:34:38 + Toni Mueller  wrote:
> # apt-get upgrade
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue [Y/n]? 
> Setting up supervisor (3.0a8-1.1+deb7u1) ...
> Starting supervisor: Error: Another program is already listening on a port 
> that one of our HTTP servers is configured to use.  Shut this program down 
> first before starting supervisord.
> For help, use /usr/bin/supervisord -h
> invoke-rc.d: initscript supervisor, action "start" failed.
> dpkg: error processing supervisor (--configure):
>  subprocess installed post-installation script returned error exit status 2
> Processing triggers for python-support ...
> Errors were encountered while processing:
>  supervisor
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> # 
> 

You could unlink the supervisor socks:

sudo unlink /tmp/supervisor.sock
sudo unlink /var/run/supervisor.sock

Or check whether other another supervisord instance is running:

ps -ef | grep supervisord

and kill it.


If this helps please close/follow up on the bug.

Cheers

Bug#798780: release.debian.org: Please let playonlinux migrate to testing

[Bertrand Marc]

Le 20/02/2016 22:53, Julien Cristau a écrit :
> Seems to be in testing now, closing.
> 
> Cheers,
> Julien

Hello Julien,

Indeed playonlinux migrated to testing, thanks to Markus Koschany who
"removed dependency on wine32|wine32-development again to ensure the
package can migrate to testing." in 4.2.9-2.

Ideally, this would only be temporary as playonlinux should really
depend on wine32|wine32-development.

Do you think we could find a solution to restore the dependency and let
playonlinux migrate to testing ?

Cheers,
Bertrand



signature.asc
Description: OpenPGP digital signature

Bug#785047: vsftpd/3.0.2-17+deb8u1

[Jörg Frings-Fürst]

Am Sonntag, den 21.02.2016, 09:50 +0100 schrieb John Paul Adrian
Glaubitz:
> On 02/20/2016 11:09 PM, Julien Cristau wrote:
> > Doesn't look like that's happening.  Closing.
> 
> Sorry, I completely missed the pu updates Joerg prepared. That was
> not
> done intentionally, but it was rather somewhere lost in
> communication.
> 
> I'd be happy to take carre of vsftpd.
> 
> @Joerg: Could you re-upload the package to mentors?
> 

done.. [1]


> Thanks,
> Adrian
> 

CU
Jörg

[1] 
http://mentors.debian.net/debian/pool/main/v/vsftpd/vsftpd_3.0.2-17+deb8u1.dsc
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Josef Atmin]

Package: org-mode
Version: 8.3.3-3
Severity: normal

Dear Maintainer,

when a shell command in an unnumbered list includes '::', it is not recognized 
as a shell
command anymore.

To reproduce the bug, paste the following two lines in file 'tmp'

  asdf :: asdf
  asdf :: qwer

and add the following shell commands to an org file

   * [[shell:cat ~/tmp | grep "asdf :"]]
   * [[shell:cat ~/tmp | grep "asdf ::"]]
   * [[shell:cat ~/tmp | grep "asdf :: "]]

If you klick on them you will probably find that the first two work while the 
last one
does not, presumably because it is interpreted as a description list entry.
Interestingly, if you use a numbered list

   1. [[shell:cat ~/tmp | grep "asdf :"]]
   2. [[shell:cat ~/tmp | grep "asdf ::"]]
   3. [[shell:cat ~/tmp | grep "asdf :: "]]

then all three work.

Thanks for this great piece of software, I use it all the time.

Best wishes,

Josef.


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

Kernel: Linux 4.3.0-1-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 org-mode depends on:
ii  emacs24 24.5+1-6+b1
ii  emacsen-common  2.0.8

Versions of packages org-mode recommends:
ii  texlive-generic-recommended  2015.20160215-1
ii  texlive-latex-recommended2015.20160215-1

Versions of packages org-mode suggests:
pn  ditaa  
ii  texlive-fonts-recommended  2015.20160215-1
ii  texlive-latex-extra2015.20160117-1

-- no debconf information

Bug#815322: supervisor doesn't install or start correctly

[Orestis Ioannou]

Hello,

I can't reproduce this on my machine. Just a wild guess, had you
installed before supervisor from pip ??


On Sat, 20 Feb 2016 13:23:49 -0700 Alexander  wrote:
> 
> Also here is the systemd output:
> 
> alex@tapandcork:~$ sudo systemctl start supervisor
> Job for supervisor.service failed. See 'systemctl status 
> supervisor.service' and 'journalctl -xn' for details.
> alex@tapandcork:~$ ^C
> alex@tapandcork:~$ systemctl status supervisor.service
> ● supervisor.service - LSB: Start/stop supervisor
> Loaded: loaded (/etc/init.d/supervisor)
> Active: failed (Result: exit-code) since Sat 2016-02-20 12:49:21 
> MST; 18s ago
>Process: 21786 ExecStart=/etc/init.d/supervisor start (code=exited, 
> status=2)


The status doesn't give much details here. Maybe journalctl will provide
some more info so please provide me with an output.

Cheers,

Orestis

Bug#815344: preseeding: empty tasksel not possible

[John Wyzer]

Thanks for the answers!

On 21/02/16 09:49, Philip Hands wrote:
> I presume you're not doing anything complicated (like including other
> preseed files that might set the setting back).
No, just one preseed.cfg. I pasted it below.
 
> It might be worth checking that your setting really was applied by
> flipping to the console once the install is underway (Ctrl-Alt-F2) and
> running:
> 
>   debconf-get tasksel/first
> 
> to make sure it's empty.

With either
  tasksel tasksel/first   multiselect standard
or
  tasksel tasksel/first multiselect ""
or
  tasksel tasksel/first multiselect 
or
  d-i tasksel/first   multiselect standard
or
  d-i tasksel/first multiselect ""
or
  d-i tasksel/first multiselect 
the output of
  debconf-get tasksel/first
is completely empty during installation and I end up with those 1500 packages 
anyway.

In a run with
  tasksel tasksel/first   multiselect standard
I get this when grepping the logs for tasksel (excluding the matches in 
./cdebconf/templates):

./cdebconf/questions.dat:Value: boot-root :: 200 50 250 ext3 $primary{ } 
$bootable{ } method{ format } format{ } use_filesystem{ } filesystem{ ext3 } 
mountpoint{ /boot } . 64 512 1200 linux-swap method{ swap } format{ } . 500 512 
10 btrfs method{ format } format{ } use_filesystem{ } filesystem{ btrfs 
} mountpoint{ / } . tasksel tasksel/first   multiselect standard
./cdebconf/questions.dat:Name: pkgsel/progress/tasksel
./cdebconf/questions.dat:Template: pkgsel/progress/tasksel
./cdebconf/questions.dat:Name: tasksel/title
./cdebconf/questions.dat:Template: tasksel/title


 
./syslog:Feb 21 08:59:42 frontend: --> SET partman-auto/expert_recipe boot-root 
:: 200 50 250 ext3 $primary{ } $bootable{ } method{ format } format{ } 
use_filesystem{ } filesystem{ ext3 } mountpoint{ /boot } . 64 512 1200 
linux-swap method{ swap } format{ } . 500 512 10 btrfs method{ format } 
format{ } use_filesystem{ } filesystem{ btrfs } mountpoint{ / } . tasksel 
tasksel/first   multiselect standard
./syslog:Feb 21 08:59:42 frontend: --> SET partman-auto/expert_recipe boot-root 
:: 200 50 250 ext3 $primary{ } $bootable{ } method{ format } format{ } 
use_filesystem{ } filesystem{ ext3 } mountpoint{ /boot } . 64 512 1200 
linux-swap method{ swap } format{ } . 500 512 10 btrfs method{ format } 
format{ } use_filesystem{ } filesystem{ btrfs } mountpoint{ / } . tasksel 
tasksel/first   multiselect standard
./syslog:Feb 21 09:00:48 debconf: <-- 0 boot-root :: 200 50 250 ext3 $primary{ 
} $bootable{ } method{ format } format{ } use_filesystem{ } filesystem{ ext3 } 
mountpoint{ /boot } . 64 512 1200 linux-swap method{ swap } format{ } . 500 512 
10 btrfs method{ format } format{ } use_filesystem{ } filesystem{ btrfs 
} mountpoint{ / } . tasksel tasksel/first   multiselect standard
./syslog:Feb 21 09:01:00 debconf: --> SUBST 
base-installer/debootstrap/info/retrieving SUBST0 tasksel
./syslog:Feb 21 09:01:00 debconf: Adding [SUBST0] -> [tasksel]
./syslog:Feb 21 09:01:00 debconf: --> SUBST 
base-installer/debootstrap/info/validating SUBST0 tasksel
./syslog:Feb 21 09:01:00 debconf: Adding [SUBST0] -> [tasksel]  
./syslog:Feb 21 09:01:00 debconf: <-- 0 Retrieving tasksel...  
./syslog:Feb 21 09:01:00 debconf: --> SUBST 
base-installer/debootstrap/info/retrieving SUBST0 tasksel-data  
./syslog:Feb 21 09:01:00 debconf: Adding [SUBST0] -> [tasksel-data]
./syslog:Feb 21 09:01:00 debconf: <-- 0 Validating tasksel...  
./syslog:Feb 21 09:01:00 debconf: --> SUBST 
base-installer/debootstrap/info/validating SUBST0 tasksel-data  
./syslog:Feb 21 09:01:00 debconf: Adding [SUBST0] -> [tasksel-data]  
./syslog:Feb 21 09:01:00 debconf: <-- 0 Retrieving tasksel-data...
./syslog:Feb 21 09:01:00 debconf: <-- 0 Validating tasksel-data...  
./syslog:Feb 21 09:02:08 debootstrap: Preparing to unpack 
.../tasksel_3.31+deb8u1_all.deb ...  
./syslog:Feb 21 09:02:08 debconf: --> SUBST 
base-installer/debootstrap/info/unpacking SUBST0 tasksel  
./syslog:Feb 21 09:02:08 debconf: Adding [SUBST0] -> [tasksel]
./syslog:Feb 21 09:02:08 debootstrap: Unpacking tasksel (3.31+deb8u1) ...
./syslog:Feb 21 09:02:08 debootstrap: Preparing to unpack 
.../tasksel-data_3.31+deb8u1_all.deb ...
./syslog:Feb 21 09:02:08 debconf: <-- 0 Unpacking tasksel...
./syslog:Feb 21 09:02:08 debconf: --> SUBST 
base-installer/debootstrap/info/unpacking SUBST0 tasksel-data
./syslog:Feb 21 09:02:08 debconf: Adding [SUBST0] -> [tasksel-data]
./syslog:Feb 21 09:02:08 debootstrap: Unpacking tasksel-data (3.31+deb8u1) ...
./syslog:Feb 21 09:02:08 debconf: <-- 0 Unpacking tasksel-data...
./syslog:Feb 21 09:02:23 debootstrap: Setting up tasksel (3.31+deb8u1) ...
./syslog:Feb 21 09:02:23 debconf: --> SUBST 
base-installer/debootstrap/info/configuring SUBST0 tasksel
./syslog:Feb 21 09:02:23 debconf: Adding [SUBST0] -> [tasksel]
./syslog:Feb 21 09:02:24 debootstrap: Setting up tasksel-data (3.31+deb8u1) ...
./syslog:Feb 21 09:02:24 debconf: <-- 0 Configuring tasksel...
./syslog:Feb 21 09:02:24 d

Bug#815308: streamlining license version "or later" version syntax

[Tobias Frost]

Am Samstag, den 20.02.2016, 19:41 +0100 schrieb Daniel Pocock:
> Package: lintian
> Version: 2.5.30+deb8u4
> X-Debbugs-cc: debian-de...@lists.debian.org
> 
> 
> Let's say that debian/copyright contains the following:
> 
> 
> 
> Files: foo
> Copyright: 2016, Mr Foo
> License: GPL-2
> 
> Files: bar
> Copyright: 2016, Mr Bar
> License: GPL-2+
> 
> License: GPL-2
>  On Debian systems, the complete text of the GNU General
>  Public License version 2 can be found in
> "/usr/share/common-licenses/GPL-2".
> 
> 
> 
> 
> Lintian will complain with a warning:
> 
> W: libfoobar source: missing-license-paragraph-in-dep5-copyright gpl-
> 2+
> (paragraph at line X)
> 
> 
> Should lintian ignore the '+' suffix when determining if a License
> paragraph exists?
> 

Well, IMHO lintian is right here.

You'll need also the "license grant", your License: paragraph'd be
incomplete without it.
And the license grant is the one that actually grants the "or later
option", not the license text itself in /usr/share/common-licenses

Also, not quoting the license grant would be a violation of the
"verbatim copyright" requirement in the Policy. 


-- 
tobi

Bug#815070: Small solution for this problem

[Michael Ott]

Hi!

I found this as solution:
https://bugs.archlinux.org/task/43823

Set
shlib_directory = no
in main.cf fixes the issue

CU  
 
  Michael
  
-- 
,''`.   
   : :' :   Michael Ott 
   `. `'e-mail: michael at king-coder dot de
 `-

Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der
Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


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

Bug#815403: erlang-proper: FTBFS on kfreebsd: sh: 1: exec: gmake: not found

[Andreas Beckmann]

Source: erlang-proper
Version: 1.1+gitfa58f82bdc+dfsg-1
Severity: important

Hi,

erlang-proper FTBFS on kfreebsd-i386 and kfreebsd-amd64:

https://buildd.debian.org/status/fetch.php?pkg=erlang-proper&arch=kfreebsd-i386&ver=1.1%2Bgitfa58f82bdc%2Bdfsg-1&stamp=1437761653
https://buildd.debian.org/status/fetch.php?pkg=erlang-proper&arch=kfreebsd-amd64&ver=1.1%2Bgitfa58f82bdc%2Bdfsg-1&stamp=1437760697

[...]
./write_compile_flags include/compile_flags.hrl
INFO:  sh info:
cwd: "/«BUILDDIR»/erlang-proper-1.1+gitfa58f82bdc+dfsg"
cmd: gmake include/compile_flags.hrl
DEBUG:  opts: [{env,[{"REBAR_DEPS_DIR",
[...]
   {abort_on_error,"Command [compile] failed!\n"}]
DEBUG: Port Cmd: "gmake include/compile_flags.hrl"
Port Opts: [{env,[{"REBAR_DEPS_DIR",
[...]
  {"REBAR","/usr/bin/rebar"}]},
exit_status,
{line,16384},
use_stdio,stderr_to_stdout,hide]
sh: 1: exec: gmake: not found
ERROR: Command [compile] failed!
make[2]: *** [rebar_compile] Error 1
/usr/share/dh-rebar/make/dh-rebar.Makefile:125: recipe for target 
'rebar_compile' failed
dh_auto_build: make --no-print-directory -f 
/usr/share/dh-rebar/make/dh-rebar.Makefile build returned exit code 2
make[1]: *** [override_dh_auto_build] Error 2


Looks like a hardcoded use of gmake somewhere ...


Andreas

Bug#815352: New mailing list for RISC-V port(s): debian-riscv@l.d.o

[Marco d'Itri]

On Feb 21, "Manuel A. Fernandez Montecelo"  wrote:

> Marco and Paul (in CC) expressed their interest, so I expect that they will
> reply seconding the request.
Seconded.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#815369: [BUG] command line definitions not expanded

[Gavin Smith]

On 21 February 2016 at 09:50, Norbert Preining  wrote:
> HI Gavin,
>
>> The problem is that @setfilename is missing from the file, and
>> texi2dvi looks for that line to add the extra line. @setfilename was
>> required before, so this isn't a regression (I hope).
>
> Ahh, I see. The original did have a line like this:
> @setfilename @value{cmd1}.info
> so it might be necessary to add it *before* this line.
>

Did this ever work, and if so, which version of texinfo.tex and texi2dvi?

Bug#814478: cups: OKI 320 print drivers not working correctly

[Kurt Theis]

Hey Brian -

>There is an okiibm driver, which is the one recommended to use. It is in
>the foomatic-db-compressed-ppds package.

That did it. First time in 21 years My OKI printer worked correctly on
Linux.

Seriously appreciate the work on this. Thanks!

By the way:

> Since this is running on a Raspberry Pi I don't believe I have any
> immediate access to the BIOS. At least I'm not aware of any way to access
> it.

 > https://www.raspberrypi.org/documentation/configuration/config-txt.md

>But the Pi doesn't have a parallel port, does it?

A *.txt file isn't a BIOS no matter what marketing says (having written
BIOS's several times over 20+ years).

Thanks again.

Kurt

(i'll post a followup resolved to the bug list as well).


On Sat, Feb 13, 2016 at 10:37 AM, Brian Potkin 
wrote:

> tags 814478 - moreinfo
> thanks
>
>
>
>
> On Fri 12 Feb 2016 at 16:50:07 -0500, Kurt Theis wrote:
>
> > Thanks for looking at this issue.
>
> Hello, Kurt. Don't forget to mail any replies the bug. The last one has
> been bounced there for you.
>
> > > Do any of the parallel port settings in the BIOS have an effect?
> >
> > Since this is running on a Raspberry Pi I don't believe I have any
> > immediate access to the BIOS. At least I'm not aware of any way to access
> > it.
>
>   https://www.raspberrypi.org/documentation/configuration/config-txt.md
>
> But the Pi doesn't have a parallel port, does it?
>
> > > I believe the printer has an Emulation Mode. What is being used now?
> > > Does changing it have any effect?
> >
> > There are two emulation modes: IBM PPR and Epson FX. Per the manual I
> have
> > IBM Proprinter II/XL and IBM Graphics. The Epson options are FX86/286 and
> > EX800/1000.
> >
> > I tried these emulation modes (after setting the mode in the printer
> front
> > panel menu) using IBM and Epson drivers. I Also tried Oki drivers in each
> > mode.
> >
> > After several tries I got this message from the CUPS localhost webpage:
> > (See image). This came across while using the "Print Test Page" option in
> > printer maintenance dropdown.
> >
> > I set the printer back to OKI mL (microline) mode and changed the driver
> > back to generic 9 pin. a "ls -la | lpr" command on the command line
> prints
> > OK as it should. The Print Test Page drop down still gives me the
> indicated
> > error.
>
> We assume the Oki 9-Pin Series PPD did not work with either emulation.
>
> > > Which particular feature is important to you?
> >
> > There are different font styles (pitch/letter styles,
> > subscript/superscript) that I am trying to use.
>
> I have a dim recollection of doing something similar a long time ago
> with a Panasonic dot matrix printer. Something like using ESC codes,
> isn't it?
>
> > >Please post what you get for
> >
> >   grep NickName /etc/cups/ppd/
> >
> > pi@kurts_office:/media/extstorage/pi/simulators/8080 $ l /etc/cups/ppd
> > total 20
> > drwxr-xr-x 2 root lp 4096 Feb 12 16:28 .
> > drwxr-xr-x 5 root lp 4096 Feb 12 16:28 ..
> > -rw-r- 1 root lp 1401 Feb 12 16:28 OKI_DATA_CORP_ML320_1TURBO.ppd
>
> The Generic text-only PPD
>
> > -rw-r- 1 root lp 5503 Feb 12 16:24 OKI_DATA_CORP_ML320_1TURBO.ppd.O
>
> The Oki 9-Pin Series PPD.
>
> There is an okiibm driver, which is the one recommended to use. It is in
> the foomatic-db-compressed-ppds package.
>
> Regards,
>
> Brian.
>



-- 
theis.k...@gmail.com
http://www.landfall.net

Bug#815070: Small solution for this problem

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 21-02-16 11:14, Michael Ott wrote:
> I found this as solution: https://bugs.archlinux.org/task/43823
> 
> Set shlib_directory = no in main.cf fixes the issue

The ArchLinux issue links to an upstream discussion, in which the
postfix developers recommend using:

 daemon_directory = /usr/libexec/postfix
 shlib_directory = /usr/lib/postfix

To not have both use the same directory.

Distributions that don't have /usr/libexec can use:

 daemon_directory = /usr/lib/postfix
 shlib_directory = /usr/lib/postfix/lib

That seems a better option than disabling shlib_directory.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWyZCNAAoJEGdQ8QrojUrx3g8QAKvfQ+UmBGbYbuedsblSiWgu
gtEqcyypGAUcnbLFEmnBvFyUEupjaRXvcwKkVPv+IxgXwfq9e0lOwgWiqf38cibe
e0H5QLwLTcXDswQoGFlz8fQncuQeoz5Txu5KAWbLbIu8Sv5VB9JtfCclIJf0lgj9
DMpn/7AP4F6T0X6UvHGC5k2fPpAzjnBfb9XgLTLlEzLP3HYfffZ3+tkqGmQ9QOAM
B7dXG1oCOcV58AamTk9zqtc1IFlHf92MeF9LhxGWJ4W72hrJOtFlDAW+I63KZ6v/
Y1oSzUFT91x2kDYtQXGm58FdpRwANZnlt/9B5zUtKJwV2xs3asUxFr2V0+wi/8sW
UinBVGFJRY3Py+VhOxS/sIV7hRBrd9HbqCz0ru+DTb2SUkam1yekVGOvhcObdarJ
CUsSuyJIQXUDcvCX+8+s2RzGhxpCmxC0kGvKGgd32jyrHrThvfRc3a0U1KIlNlY0
D2wX7rWEaPVlH5YI3LbUiW5XKRdTdeVWIR+gaQHaQjbac0MinFjLP+oMnFL1JENh
bQfl8t1BVzo33InhOaWVMULzxaUTMUg59F975DUcl9YDN9oyj3qd5A9qlEXSd4cl
Bfpzjrw8GV+1oLyIEnurmYi9SYEsaFJ8/8GCzqp+4YLZvmU95KriaQXiC8RRYcKP
tSxW7RjRWHZMQU2BuTQZ
=p+IP
-END PGP SIGNATURE-

Bug#690537: Bug#809563: reportbug: how to know if a package needs arch-qualif

[Guillem Jover]

Hi!

I'm not entirely sure what you expect out of this bug report. Is this
a support request? If so a mail to debian-dpkg might have been better.
Also CCing the package address helps seeing the issue more quickly.

On Fri, 2016-01-01 at 14:04:05 +, Sandro Tosi wrote:
> Dear dpkg maintainer, how can reportbug understand if a package needs
> arch-qualification or not? for example
> 
> $ dpkg-query -W gcc-5-base
> gcc-5-base:amd645.2.1-24
> gcc-5-base:i386 5.2.1-24
> 
> but
> 
> $ dpkg-query -W dpkg
> dpkg1.18.3

«dpkg-query -W» will arch-qualify packages when needed. The current
rules for arch-qualifying can be found in dpkg-query(1), in the
description of the binary:Package virtual field.

> we are currently using the 'status' file (we are parsing it matching
> on '^Package:'), where:
> 
> $ dpkg --status gcc-5-base:amd64
> Package: gcc-5-base
> Status: install ok installed
> Priority: required
> Section: libs
> Installed-Size: 197
> Maintainer: Debian GCC Maintainers 
> Architecture: amd64
> [8<]
> 
> so the Package line doesnt have the arch qualification so our
> file-parsing doesnt return it, but from the command line we need to
> specify it else:
> 
> $ dpkg --status gcc-5-base
> dpkg-query: error: --status needs a valid package name but
> 'gcc-5-base' is not: ambiguous package name 'gcc-5-base' with more
> than one installed instance

Any command that requires a specific package instance, needs to be
unambiguous, the commands accepting patterns do not need to, and
something like «dpkg-query -W gcc-5-base» is equivalent to
«dpkg-query -W gcc-5-base:*».

> how can we improve that in reportbug? is there a better way to
> retrieve such information? ideally if someone wants to report a bug
> against 'gcc-5-base' we should be able to return the 2 entries as of:
> 
> $ dpkg-query -W gcc-5-base
> gcc-5-base:amd645.2.1-24
> gcc-5-base:i386 5.2.1-24
> 
> (we also provide the description, that's why we use the status db).

I'm not exactly sure what you are asking for here. You need to either
parse the status file, and match the arch-qualifying rules documented
in dpkg-query. Or you could use something lile:

  «dpkg-query -f '${binary:Package} ${Version}\n ${Description}\n' pkg»

or any other formatting you might want to parse.

Thanks,
Guillem

Bug#815369: [BUG] command line definitions not expanded

[Norbert Preining]

Hi Gavin,


no idea, guess so. I'll try on texinfo 4.8 in stable. I just was informed of 
the report and it seems that it was working before.

I'll investigate, and hope that the maintainer of the package will comment, too.

Thanks

Norbert

On 21 February 2016 19:18:39 GMT+09:00, Gavin Smith  
wrote:
>On 21 February 2016 at 09:50, Norbert Preining 
>wrote:
>> HI Gavin,
>>
>>> The problem is that @setfilename is missing from the file, and
>>> texi2dvi looks for that line to add the extra line. @setfilename was
>>> required before, so this isn't a regression (I hope).
>>
>> Ahh, I see. The original did have a line like this:
>> @setfilename @value{cmd1}.info
>> so it might be necessary to add it *before* this line.
>>
>
>Did this ever work, and if so, which version of texinfo.tex and
>texi2dvi?

---
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#815301: Removed package(s) from unstable

[Sebastian Ramacher]

On 2016-02-21 05:26:44, Debian FTP Masters wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
> 
>vlc |2.1.5-1 | hurd-i386

And what about the other binary packages produced by src:vlc? Just removing vlc
seems pointless. There are at least

libvlc-dev  | 2.1.5-1   | unstable   | hurd-i386
libvlc5 | 2.1.5-1   | unstable   | hurd-i386
libvlccore-dev  | 2.1.5-1   | unstable   | hurd-i386
libvlccore7 | 2.1.5-1   | unstable   | hurd-i386
vlc-nox | 2.1.5-1   | unstable   | hurd-i386
vlc-plugin-jack | 2.1.5-1   | unstable   | hurd-i386

and some other vlc-plugin- packages left.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#815404: linux-image-4.4.0-1-amd64 fails to boot on Lenovo X1 Carbon

[Russel Winder]

Package: src:linux
Version: 4.4.2-1
Severity: important

Dear Maintainer,

This morning saw a kernel upgrade from 4.3.0 to 4.4.0. This worked fine on 
Lenovo T500, Lenovo Z201, and
Dell Precision T5400, the machines now boot to 4.4.0, without problem. However 
on a Lenovo X1 Carbon, the
upgrade seem to go without a problem, but when a reboot is attempted, the 
machine hangs on the message:

loading initial ramdisk…

At this point the machine is "locked up" and an enforced power down is 
required. The machine
boots fine to 4.3.0, hence being able to send this bug report in from the 
machine itself.

I tried reinstalling the packages in case there was simply a problem with the 
upgrade process itself, but
whilst the installation seemed to go fine, the same behaviour occured on boot: 
not able to get past the
ramdisk message.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20BSCTO1WW
product_version: ThinkPad X1 Carbon 3rd
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N14ET25W (1.03 )
board_vendor: LENOVO
board_name: 20BSCTO1WW
board_version: SDK0E50512 STD

** Network interface configuration:

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Lenovo Broadwell-U Host Bridge -OPI [17aa:2227]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Broadwell-U Integrated Graphics [17aa:2227]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller 
[8086:160c] (rev 09)
Subsystem: Lenovo Broadwell-U Audio Controller [17aa:2227]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI 
Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller [17aa:2227]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI 
Controller #1 [8086:9cba] (rev 03)
Subsystem: Lenovo Wildcat Point-LP MEI Controller [17aa:2227]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) 
I218-LM [8086:15a2] (rev 03)
Subsystem: Lenovo Ethernet Connection (3) I218-LM [17aa:2227]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition 
Audio Controller [8086:9ca0] (rev 03)
Subsystem: Lenovo Wildcat Point-LP High Definition Audio Controller 
[17aa:2227]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #2 [8086:9c92] (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.1 PCI bridge [0604]: Intel Corporation Wildcat

Bug#809563: reportbug: how to know if a package needs arch-qualif

[Guillem Jover]

[ Sorry, resending to the correct bug now to have a track record. :/ ]

Hi!

I'm not entirely sure what you expect out of this bug report. Is this
a support request? If so a mail to debian-dpkg might have been better.
Also CCing the package address helps seeing the issue more quickly.

On Fri, 2016-01-01 at 14:04:05 +, Sandro Tosi wrote:
> Dear dpkg maintainer, how can reportbug understand if a package needs
> arch-qualification or not? for example
> 
> $ dpkg-query -W gcc-5-base
> gcc-5-base:amd645.2.1-24
> gcc-5-base:i386 5.2.1-24
> 
> but
> 
> $ dpkg-query -W dpkg
> dpkg1.18.3

«dpkg-query -W» will arch-qualify packages when needed. The current
rules for arch-qualifying can be found in dpkg-query(1), in the
description of the binary:Package virtual field.

> we are currently using the 'status' file (we are parsing it matching
> on '^Package:'), where:
> 
> $ dpkg --status gcc-5-base:amd64
> Package: gcc-5-base
> Status: install ok installed
> Priority: required
> Section: libs
> Installed-Size: 197
> Maintainer: Debian GCC Maintainers 
> Architecture: amd64
> [8<]
> 
> so the Package line doesnt have the arch qualification so our
> file-parsing doesnt return it, but from the command line we need to
> specify it else:
> 
> $ dpkg --status gcc-5-base
> dpkg-query: error: --status needs a valid package name but
> 'gcc-5-base' is not: ambiguous package name 'gcc-5-base' with more
> than one installed instance

Any command that requires a specific package instance, needs to be
unambiguous, the commands accepting patterns do not need to, and
something like «dpkg-query -W gcc-5-base» is equivalent to
«dpkg-query -W gcc-5-base:*».

> how can we improve that in reportbug? is there a better way to
> retrieve such information? ideally if someone wants to report a bug
> against 'gcc-5-base' we should be able to return the 2 entries as of:
> 
> $ dpkg-query -W gcc-5-base
> gcc-5-base:amd645.2.1-24
> gcc-5-base:i386 5.2.1-24
> 
> (we also provide the description, that's why we use the status db).

I'm not exactly sure what you are asking for here. You need to either
parse the status file, and match the arch-qualifying rules documented
in dpkg-query. Or you could use something lile:

  «dpkg-query -f '${binary:Package} ${Version}\n ${Description}\n' pkg»

or any other formatting you might want to parse.

Thanks,
Guillem

Bug#815405: RM: pearpc [kfreebsd-amd64] -- RoQA; FTBFS

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please decruft pearpc on kfreebsd-amd64, it does FTBFS there and may need
some porting work, while there hasn't been much activity over the last
years.


Andreas

Bug#815406: org-mode: "No link found" for after <2016-02-21 Sun>

[Josef Atmin]

Package: org-mode
Version: 8.3.3-3
Severity: normal

Dear Maintainer,

when the curser is at the end of the line directly after <2016-02-21 Sun>, i.e. 
there
comes a newline right after the '>', then typing  results in the 
message "No link
found".  I guess this is a bug.

When I add a space between <2016-02-21 Sun> and the newline, then typing 
 when
the curser sits on the space brings up agenda mode for that date.  I guess this 
is the
intended behavior.

I actually find both behaviors anoying and would much rather prefer if simply a 
newline
is inserted when I type  AFTER <2016-02-21 Sun>.  Typing return on the
<2016-02-21 Sun> should, of course, bring up agenda mode for that date.  The 
same applies
to regular shell commands of the form [[shell...]] or [[file...]].  The problem 
is, that
I quite often run into the situation that I want have a line break right after 
such a
date and command, and each time I accidentally rund the command or date. So 
this is my
wishlist part.

I think this is a new feature you have added in one of the recent versions.  So 
I would
strongly vote for reverting that.

I use the following options, and I would like to keep them:

;; configure link behavior
; don't ask for confirmation when klicking on a shell link
(setq org-confirm-shell-link-function nil)
; follow a link when pressing return on it
(setq org-return-follows-link t)

Best wishes,

Josef.


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

Kernel: Linux 4.3.0-1-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 org-mode depends on:
ii  emacs24 24.5+1-6+b1
ii  emacsen-common  2.0.8

Versions of packages org-mode recommends:
ii  texlive-generic-recommended  2015.20160215-1
ii  texlive-latex-recommended2015.20160215-1

Versions of packages org-mode suggests:
pn  ditaa  
ii  texlive-fonts-recommended  2015.20160215-1
ii  texlive-latex-extra2015.20160117-1

-- no debconf information

Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x

[Sebastian Dröge]

On So, 2016-02-21 at 11:09 +0200, Sebastian Dröge wrote:
> On Di, 2015-11-10 at 20:28 +, Olly Betts wrote:
> >  
> > I'll try to find time to test it.  Also happy for someone else to
> > test
> > the amended patch and NMU if it works, but please keep me in the
> > loop to
> > avoid duplicating effort.
> > 
> > (If someone does NMU, you could usefully drop `--enable-sdl` in
> > debian/rules to close #802770 - there's no corresponding BD so this
> > doesn't affect the built result in a clean chroot).
> 
> I'm looking into this now btw, will provide an updated patch some time
> later today or so. How can I test the wxwidgets GStreamer integration?

Please see attached. This builds but I don't know how to test it.diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/changelog wxwidgets3.0-3.0.2+dfsg/debian/changelog
--- wxwidgets3.0-3.0.2+dfsg/debian/changelog	2015-08-03 13:55:58.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/changelog	2016-02-21 12:26:54.0 +0200
@@ -1,3 +1,16 @@
+wxwidgets3.0 (3.0.2+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control.in,
+debian/rules,
+debian/patches/gst1.0.patch:
++ Port to GStreamer 1.x (Closes: #785924), patch based on the one from
+  http://trac.wxwidgets.org/ticket/14976 with a lot of changes.
+  * debian/control.in:
++ Remove obsolete build-depends on ESD and GConf.
+
+ -- Sebastian Dröge   Sun, 21 Feb 2016 11:21:28 +0200
+
 wxwidgets3.0 (3.0.2+dfsg-1.2) unstable; urgency=medium
 
   * Non maintainer upload.
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/control wxwidgets3.0-3.0.2+dfsg/debian/control
--- wxwidgets3.0-3.0.2+dfsg/debian/control	2015-07-30 14:59:26.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/control	2016-02-21 12:15:52.0 +0200
@@ -5,10 +5,10 @@
 Build-Depends: debhelper (>= 9), gettext, libgtk2.0-dev,
  g++ (>= 4:5.2),
  zlib1g-dev, libjpeg-dev, libpng-dev, libtiff5-dev, libsm-dev,
- libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libesd0-dev,
- autotools-dev, libexpat1-dev, dpkg-dev (>= 1.16.1~),
- libxt-dev, libgstreamer-plugins-base0.10-dev, libgconf2-dev, libwebkitgtk-dev,
- libnotify-dev
+ libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
+ autotools-dev, autoconf, libexpat1-dev, dpkg-dev (>= 1.16.1~), libxt-dev,
+ libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
+ libwebkitgtk-dev, libnotify-dev
 Maintainer: wxWidgets Maintainers 
 Uploaders: Olly Betts 
 Standards-Version: 3.9.6
@@ -129,7 +129,10 @@
 Package: libwxgtk-media3.0-0v5
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+  gstreamer1.0-plugins-base,
+  gstreamer1.0-plugins-good,
+  gstreamer1.0-x
 Multi-Arch: same
 Breaks: libwxgtk-media3.0-0
 Replaces: libwxgtk-media3.0-0
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/control.in wxwidgets3.0-3.0.2+dfsg/debian/control.in
--- wxwidgets3.0-3.0.2+dfsg/debian/control.in	2015-07-30 14:59:22.0 +0300
+++ wxwidgets3.0-3.0.2+dfsg/debian/control.in	2016-02-21 12:15:50.0 +0200
@@ -5,10 +5,10 @@
 Build-Depends: debhelper (>= 9), gettext, libgtk2.0-dev,
  g++ (>= 4:5.2),
  zlib1g-dev, libjpeg-dev, libpng-dev, libtiff5-dev, libsm-dev,
- libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libesd0-dev,
- autotools-dev, libexpat1-dev, dpkg-dev (>= 1.16.1~),
- libxt-dev, libgstreamer-plugins-base0.10-dev, libgconf2-dev, libwebkitgtk-dev,
- libnotify-dev
+ libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
+ autotools-dev, autoconf, libexpat1-dev, dpkg-dev (>= 1.16.1~), libxt-dev,
+ libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
+ libwebkitgtk-dev, libnotify-dev
 Maintainer: wxWidgets Maintainers 
 Uploaders: Olly Betts 
 Standards-Version: 3.9.6
@@ -129,7 +129,10 @@
 Package: libwxgtk-media=SOV
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+  gstreamer1.0-plugins-base,
+  gstreamer1.0-plugins-good,
+  gstreamer1.0-x
 Multi-Arch: same
 Breaks: libwxgtk-media3.0-0
 Replaces: libwxgtk-media3.0-0
diff -Nru wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch
--- wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch	1970-01-01 02:00:00.0 +0200
+++ wxwidgets3.0-3.0.2+dfsg/debian/patches/gst1.0.patch	2016-02-21 11:48:12.0 +0200
@@ -0,0 +1,886 @@
+Index: wxwidgets3.0-3.0.2+dfsg/configure.in
+===
+--- wxwidgets3.0-3.0.2+dfsg.orig/configure.in
 wxwidgets3.0-3.0.2+dfsg/configure.in
+@@ -7543,43 +7543,22 @@ if test "$wxUSE_MEDIACTRL" = "yes" -o "$
+ wxUSE_GSTREAMER="no"
+ 
+ dnl ---
+-dnl Test for at least 0.8 gstreamer module from pkg-config
+-dnl Even totem doesn't accept 0.9 evidently.
+-dnl
+-dnl So, we first 

Bug#815253: Seems to fail when gcc is not available

[Jussi Pakkanen]

On Sun, Feb 21, 2016 at 11:27 AM, Guillem Jover  wrote:

In this case just setting CC=clang before anything that involves a
> call to a script in dpkg-dev, should make it work. Thus reassigning.
>

Here are the relevant bits from the test script:

CC=clang meson build
ninja -C build test

The first line has CC properly set. I did some testing and it seems that
the latter line does not call into the function where dpkg-architecture is
invoked. This implicates that it should work.

Bug#815400: transition: ros-ros-comm

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 21/02/16 10:09, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> we want to transition librosconsole to link against log4cxx instead of an
> internal print version. librosconsole exports these symbols, so other packages
> depend on the choice and we can't simply switch it. We went for a Soname bump
> because it's Debian internal anyhow, as upstream declined to add one.
> 
> The new version of ros-ros-comm is in experimental already.
> 
> Ben file:
> 
> title = "ros-ros-comm";
> is_affected = .depends ~ "librosconsole0d" | .depends ~ "librosconsole1d";
> is_good = .depends ~ "librosconsole1d";
> is_bad = .depends ~ "librosconsole0d";
> 
> We are maintainer of all reverse dependencies and we did test rebuilds already
> and have all needed patches prepared. All rdepends are listed here:
> 
> https://release.debian.org/transitions/html/auto-ros-ros-comm.html

Go ahead.

Cheers,
Emilio

Bug#815344: preseeding: empty tasksel not possible

[Geert Stappers]

On Sun, Feb 21, 2016 at 11:07:15AM +0100, John Wyzer wrote:
> Thanks for the answers!

 :-)

As in "good to see common interrests"


> On 21/02/16 09:49, Philip Hands wrote:
> > I presume you're not doing anything complicated (like including other
> > preseed files that might set the setting back).
> No, just one preseed.cfg. I pasted it below.
  
> ./cdebconf/questions.dat:Value: boot-root :: 200 50 250 ext3 $primary{ } 
> $bootable{ } method{ format } format{ } use_filesystem{ } filesystem{ ext3 } 
> mountpoint{ /boot } . 64 512 1200 linux-swap method{ swap } format{ } . 500 
> 512 10 btrfs method{ format } format{ } use_filesystem{ } filesystem{ 
> btrfs } mountpoint{ / } . tasksel tasksel/first   multiselect standard

Note the tasksel in "partman stuff"

  
> ./syslog:Feb 21 09:04:36 debconf: --> SETTITLE tasksel/title
> ./syslog:Feb 21 09:05:07 frontend: --> GET tasksel/first
> ./syslog:Feb 21 09:05:07 frontend: <-- 10 tasksel/first doesn't exist

Note 'tasksel/first doesnot exist'

  

> This is my preseed.cfg with root password, ntp, proxy and 
> preseed/late_command removed.
> 
  
> d-i partman/choose_partition select finish
> d-i partman/confirm boolean true
> d-i partman/confirm_nooverwrite boolean true
> 
> d-i partman/early_command string [ -b /dev/sda ] && if=/dev/zero of=/dev/sda 
> bs=1024 count=1024 || true

FWIW: I think it misses `dd` ...


> d-i partman-auto/expert_recipe string \
>   boot-root ::\
>   200 50 250 ext3  \
>   $primary{ } $bootable{ }\
>   method{ format } format{ }  \
>   use_filesystem{ } filesystem{ ext3 }\
>   mountpoint{ /boot } \
>   .   \
>   64 512 1200 linux-swap  \
>   method{ swap } format{ }\
>   .   \
>   500 512 10 btrfs\ 
>   method{ format } format{ }  \ 
>   use_filesystem{ } filesystem{ btrfs }\
>   mountpoint{ / } \
>   .   \
> 
> tasksel tasksel/first   multiselect standard

I see  

.   \
tasksel tasksel/first   multiselect standard


So 'tasksel tasksel/first   multiselect standard' is merged to the 
partman-auto/expert_recipe string.


Advice: add some seperator or remove a backslash to avoid "continue on next 
line"



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#690537: reportbug: Package list does not specify arch

[Guillem Jover]

Hi!

On Fri, 2016-01-01 at 00:59:31 +, Sandro Tosi wrote:
> On Sun, Nov 15, 2015 at 1:26 PM, Diederik de Haas  
> wrote:
> > I'm adding my info to this bug report as I would have choosen the same
> > title, even though the steps/behavior aren't the same.
> 
> they are actually different situations.
> 
> > Earlier today I have reported bug #805132
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805132) with title
> > "glx-alternative-nvidia:amd64 installs update-glx:armhf as dependency".
> > As you can see by the title the arch where a package came from is
> > critical, but especially that info was missing from the Package list
> > section. The relevant part of that bug report (for this bug):
> >
> > Versions of packages glx-alternative-nvidia depends on:
> > ii  glx-alternative-mesa  0.7.1
> > ii  glx-diversions0.7.1
> > ii  update-glx0.7.1
> >
> > The maintainer of that package was able to confirm this behavior.
> 
> that list is the package dependencies as defined by
> 
> $ dpkg --status glx-alternative-nvidia | grep Depends
> Depends: update-glx (= 0.7.1), glx-diversions (= 0.7.1), glx-alternative-mesa
> 
> which are the ones reportbug enlist.

Hmm, this might or might not be the correct information. Because the
dependencies of a package depen on its architecture, and any
Multi-Arch markings, so simply dumping anything installed from the
status file that matches the package name of a Depends might give
false information.

A way to solve this could be to check which packages satisfy those
dependencies using one of the Dpkg perl modules.

Thanks,
Guillem

Bug#815406: org-mode: "No link found" for after <2016-02-21 Sun>

[Sébastien Delafond]

Hi Josef,

thanks for your report. As this seems to be a pure upstream problem,
could you please follow up on it using the org-mode mailing list[0] ?
Once that's done, feel free to add a link to your post in the Debian
BTS.

Cheers,

--Seb

Bug#815346: [Debian-ha-maintainers] Bug#815346: crmsh: add multiarch support in config.py (libdir)

[Daniel Hoffend]

Hello Christoph,

after submitting the patch I started thinking about the other architectures
as well, but wasn't sure what would be the right way to get this fixed.
And yes, taking care of all possible exotic architecture shouldn't be
in the responsibility of the upstream software. Especially if other
distributions are following a different folder structures like 'lib64'
and so on.

In this case I would vote for moving the pacemaker binaries to a more
generic directory or even symlink /usr/lib/pacemaker  to
/usr/lib//pacemaker (if that's possible).

I also would suggest to remove the i386 arch from the upstream config
but keep x86_64 to be in line with lib64 naming stuff, but basically
everything folder/location specific stuff should be take care during
packaging like you describe before.

But as long none of the changes (changing libexec dir or adjusting
config.py libdir) the crmsh is basically non-working in the default
configuration. As soon as you either patch the config.py, change
crm_daemon_dir in crm.conf or change the $PATH variable every change
you try to make via crmsh is denied because verify doesn't succeed.

To summarize I see multiple options:

* change libexecdir to /usr/lib/pacemaker instead of the arch-specific
* symlink /usr/lib/pacemaker to /usr/lib//pacemaker
* configure arch specific crm_daemon_dir in /etc/crm/crm.conf


--
Regards
Daniel Hoffend

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

[Sébastien Delafond]

Hi Josef,

thanks for your report. As this seems to be a pure upstream problem,
could you please follow up on it using the org-mode mailing list[0] ?
Once that's done, feel free to add a link to your post in the Debian
BTS.

Cheers,

--Seb

Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x

[Sebastian Dröge]

On So, 2016-02-21 at 12:29 +0200, Sebastian Dröge wrote:
> On So, 2016-02-21 at 11:09 +0200, Sebastian Dröge wrote:
> > On Di, 2015-11-10 at 20:28 +, Olly Betts wrote:
> > >  
> > > I'll try to find time to test it.  Also happy for someone else to
> > > test
> > > the amended patch and NMU if it works, but please keep me in the
> > > loop to
> > > avoid duplicating effort.
> > > 
> > > (If someone does NMU, you could usefully drop `--enable-sdl` in
> > > debian/rules to close #802770 - there's no corresponding BD so
> > > this
> > > doesn't affect the built result in a clean chroot).
> > 
> > I'm looking into this now btw, will provide an updated patch some
> > time later today or so. How can I test the wxwidgets GStreamer
> > integration?
> 
> Please see attached. This builds but I don't know how to test it.

I also provided that patch upstream with some further information, but
their bug tracker requires moderation of comments so it probably takes
a while until it shows up there.

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

Bug#815356: jessie-pu: package ruby-standalone/0.5+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2016-02-20 at 22:05 -0200, Antonio Terceiro wrote:
> I would like to upload a stable update for ruby-standalone, that makes
> it work correctly with bundler, which is a very important use case.

Please go ahead.

Regards,

Adam

Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope

[Andreas Beckmann]

Source: xd
Version: 3.23.04-1
Severity: important

Hi,

xd currently FTBFS on hurd-i386 (but an older version built successfully
on that platform):

https://buildd.debian.org/status/fetch.php?pkg=xd&arch=hurd-i386&ver=3.23.04-1&stamp=1450674516

[...]
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
--std=c++14 -Wall  -c -o tmp/o/2gethome.o alternatives/gethome.cc
alternatives/getcwd.cc: In member function 'void 
Alternatives::getCwd(std::unique_ptr*)':
alternatives/getcwd.cc:5:26: error: 'PATH_MAX' was not declared in this scope
 dest->reset(new char[PATH_MAX]);
  ^
Fatal: system - failure of system call (status 256)
Fatal: system - failure of system call (status 256)
make: *** [build-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


If this isn't trivially fixable, please request the outdated binary
packages to be decrufted.


Andreas

Bug#814266: jessie-pu: package pagekite/0.5.6d-3+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-02-20 at 15:01 +0100, Petter Reinholdtsen wrote:
> [Adam D. Barratt]
> > Please go ahead.
> 
> Thank you.  Uploaded, and a new branch jessie-update contain the
> changes on
> https://anonscm.debian.org/gitweb/?p=collab-maint/pagekite.git >.

Flagged for acceptance.

Regards,

Adam

Bug#815241: xul-ext-mozvoikko: As above

[Tuomas Pylkkö]

Package: xul-ext-mozvoikko
Version: 2.0.1-1
Followup-For: Bug #815241

Dear Maintainer,

I can verify that - just as reported by Antti Järvinen - the presence of voikko 
causes segfaults immediately after starting iceweasel. At times iceweasel 
starts but segfaults after clicking on any button, but at times it does not 
even start. If started in "safe mode", it is then possible to disable voikko, 
after which this behavior is no longer present.


(gdb) bt
#0  0x7fffc13bfe58 in voikkoSetBooleanOption () from 
/usr/lib/x86_64-linux-gnu/libvoikko.so.1
#1  0x71a37060 in ffi_call_unix64 () from 
/usr/lib/x86_64-linux-gnu/libffi.so.6
#2  0x71a36acb in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3  0x7410868d in js::ctypes::FunctionType::Call (cx=0x7fffe65fc000, 
argc=, vp=0x7fff72a8) at 
/tmp/buildd/iceweasel-44.0.2/js/src/ctypes/CTypes.cpp:6632
#4  0x7441117e in js::CallJSNative (args=..., native=, 
cx=0x7fffe65fc000) at /tmp/buildd/iceweasel-44.0.2/js/src/jscntxtinlines.h:235
#5  js::Invoke (cx=cx@entry=0x7fffe65fc000, args=..., 
construct=construct@entry=js::NO_CONSTRUCT) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:489
#6  0x74411e2d in js::Invoke (cx=0x7fffe65fc000, thisv=..., fval=..., 
argc=3, argv=, rval=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:542
#7  0x743955e5 in js::DirectProxyHandler::call (this=, 
cx=, proxy=..., args=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/proxy/DirectProxyHandler.cpp:77
#8  0x743949c9 in js::CrossCompartmentWrapper::call 
(this=0x76734cf0 , 
cx=0x7fffe65fc000, wrapper=..., args=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/proxy/CrossCompartmentWrapper.cpp:289
#9  0x7439d7bf in js::Proxy::call (args=..., proxy=..., 
cx=0x7fffe65fc000) at /tmp/buildd/iceweasel-44.0.2/js/src/proxy/Proxy.cpp:412
#10 js::proxy_Call (cx=0x7fffe65fc000, argc=, vp=) at /tmp/buildd/iceweasel-44.0.2/js/src/proxy/Proxy.cpp:710
#11 0x7441117e in js::CallJSNative (args=..., native=, 
cx=0x7fffe65fc000) at /tmp/buildd/iceweasel-44.0.2/js/src/jscntxtinlines.h:235
#12 js::Invoke (cx=0x7fffe65fc000, args=..., construct=) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:489
#13 0x74405036 in Interpret (cx=0x7fffe65fc000, state=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:2798
#14 0x74410db1 in js::RunScript (cx=cx@entry=0x7fffe65fc000, state=...) 
at /tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:430
#15 0x744110b3 in js::Invoke (cx=cx@entry=0x7fffe65fc000, args=..., 
construct=construct@entry=js::CONSTRUCT) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:507
#16 0x7441184d in InternalConstruct (cx=cx@entry=0x7fffe65fc000, 
args=...) at /tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:569
#17 0x744118c9 in js::Construct (cx=cx@entry=0x7fffe65fc000, fval=..., 
fval@entry=..., args=..., newTarget=..., rval=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:616
#18 0x7439ef4a in js::DirectProxyHandler::construct (this=, cx=0x7fffe65fc000, proxy=..., args=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/proxy/DirectProxyHandler.cpp:95
#19 0x74394b37 in js::CrossCompartmentWrapper::construct 
(this=0x76734cf0 , 
cx=0x7fffe65fc000, wrapper=..., args=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/proxy/CrossCompartmentWrapper.cpp:309
#20 0x7439d952 in js::Proxy::construct (args=..., proxy=..., 
cx=0x7fffe65fc000) at /tmp/buildd/iceweasel-44.0.2/js/src/proxy/Proxy.cpp:431
#21 js::proxy_Construct (cx=cx@entry=0x7fffe65fc000, argc=, 
vp=) at /tmp/buildd/iceweasel-44.0.2/js/src/proxy/Proxy.cpp:719
#22 0x744117b2 in js::CallJSNative (args=..., native=0x7439d880 
, cx=0x7fffe65fc000) 
at /tmp/buildd/iceweasel-44.0.2/js/src/jscntxtinlines.h:235
#23 js::CallJSNativeConstructor (args=..., native=0x7439d880 
, cx=0x7fffe65fc000) 
at /tmp/buildd/iceweasel-44.0.2/js/src/jscntxtinlines.h:268
#24 InternalConstruct (cx=cx@entry=0x7fffe65fc000, args=...) at 
/tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:579
#25 0x744118c9 in js::Construct (cx=cx@entry=0x7fffe65fc000, fval=..., 
fval@entry=..., args=..., newTarget=..., newTarget@entry=..., rval=..., 
rval@entry=...) at /tmp/buildd/iceweasel-44.0.2/js/src/vm/Interpreter.cpp:616
#26 0x745dae31 in js::jit::DoCallFallback (cx=0x7fffe65fc000, 
frame=0x7fff8308, stub_=0x7fffd766aa90, argc=0, vp=0x7fff82b8, res=...) 
at /tmp/buildd/iceweasel-44.0.2/js/src/jit/BaselineIC.cpp:9013
#27 0x77eec720 in ?? ()
#28 0x7fffe65fc018 in ?? ()
#29 0x7fff8270 in ?? ()
#30 0xfff9 in ?? ()
#31 0x7686cb60 in js::jit::DoSpreadCallFallbackInfo () from 
/usr/lib/iceweasel/libxul.so
#32 0x7fffd9a57a60 in ?? ()
#33 0x77e24cc3 in ?? ()
#34 0x0902 in ?? ()
#35 0x7fff8308 in ?? ()
#36 0x7fffd766aa90 in ?? ()



-- System Information:
D

Bug#815408: gscan2pdf: fails to record some settings when saving profile

[gerry butler]

Package: gscan2pdf
Version: 1.3.8-1
Severity: normal
Tags: upstream

Dear Maintainer,

(1) Start gscan2pdf

(2) Set source = Flatbed

(3) Set tl-x, tl-y, br-x, br-y to required values.

(4) Do not set mode or resolution, as they are already the required values.

(5) Save the profile as "business card".

(6) The saved profile in ~/.gscan2pdf does not contain settings 
for mode or resolution. I expect it should.

Workaround: Change all settings, then change them back to the 
required settings before saving the profile.

-- System Information:
Debian Release: 8.3
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Bug#814651: jessie-pu: package sitesummary/0.1.17+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-02-20 at 16:27 +0100, Petter Reinholdtsen wrote:
> [Adam D. Barratt]
> > The comment for the prerm is wrong (twice) - it's disabling, not
> > enabling, the configuration and not checking for cgi.load.
> 
> Right.  It was wrong in the master branch and unstable too.  I've fixed
> the master branch, and will upload the fix later.

Thanks.

> > Other than that, please go ahead.
> 
> The fix for jessie is uploaded, and the changes available in the jessie
> branch in
> http://anonscm.debian.org/cgit/debian-edu/upstream/sitesummary.git >.

Flagged for acceptance.

Regards,

Adam

Bug#815408: gscan2pdf: fails to record some settings when saving profile

[Gerry Butler]

~/.gscan2pdf and gscan2pdf.log are attached.


.gscan2pdf
Description: Binary data
INFO - Starting gscan2pdf 1.3.8
INFO - Log level DEBUG
INFO - Using C locale
INFO - Startup LC_NUMERIC C
INFO - Reading config from /home/gerry/.gscan2pdf
INFO - Config file version 1.3.8
DEBUG - $VAR1 = {
  'frontend' => 'libsane-perl',
  'rotate reverse' => 0,
  'unsharp radius' => 0,
  'downsample' => '',
  'pages to scan' => '1',
  'window_x' => 140,
  'available-tmp-warning' => 10,
  'window_width' => 1011,
  'ocr engine' => 'tesseract',
  'pdf compression' => 'auto',
  'scan_window_width' => 721,
  'OCR on scan' => 1,
  'Paper' => {
   'A4' => {
 'y' => 297,
 'l' => 0,
 'x' => 210,
 't' => 0
   },
   'US Legal' => {
   't' => 0,
   'y' => 356,
   'l' => 0,
   'x' => 216
 },
   'US Letter' => {
'x' => 216,
'l' => 0,
'y' => 279,
't' => 0
  }
 },
  'visible-scan-options' => {
  'y' => 1,
  'button-wait' => 1,
  'calibration-cache' => 1,
  'mode' => 1,
  'pagewidth' => 1,
  'wait-for-button' => 1,
  'page-height' => 1,
  'source' => 1,
  'adf-mode' => 1,
  'Paper size' => 1,
  'x' => 1,
  'contrast' => 1,
  'gain' => 1,
  'page-width' => 1,
  'l' => 1,
  'brightness' => 1,
  'resolution' => 1,
  'threshold' => 1,
  'adf_mode' => 1,
  'speed' => 1,
  'compression' => 1,
  'pageheight' => 1,
  'overscan-bottom' => 1,
  'batch-scan' => 1,
  'overscan-top' => 1,
  't' => 1
},
  'restore window' => 1,
  'window_maximize' => '',
  'user_defined_tools' => [
'gimp %i'
  ],
  'unsharp sigma' => 1,
  'SANE version' => '1.0.24',
  'scan prefix' => '',
  'cache options' => 1,
  'unsharp threshold' => '0.05',
  'Page range' => 'all',
  'scan_window_height' => 664,
  'Dark threshold' => '0.12',
  'rotate facing' => 0,
  'default filename' => '%a %y-%m-%d',
  'layout' => 'single',
  'thumb panel' => 100,
  'device' => 'brother3:net1;dev0',
  'quality' => 75,
  'scan-reload-triggers' => 'mode',
  'OCR output' => 'replace',
  'unpaper on scan' => '',
  'libsane-perl version' => '0.05',
  'auto-open-scan-dialog' => 1,
  'Blank threshold' => '0.005',
  'date offset' => 0,
  'version' => '1.3.8',
  'threshold tool' => 80,
  'unsharp amount' => 1,
  'window_y' => 0,
  'window_height' => 1138,
  'profile' => {},
  'cwd' => '/home/gerry',
  'downsample dpi' => 150
};

INFO - Operating system: linux
INFO - PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/";
SUPPORT_URL="http://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";
INFO - Perl version v5.20.2
INFO - Glib-Perl version 1.305
INFO - Built for Glib 2.40.0
INFO - Running with Glib 2.42.1
INFO - Gtk2-Perl version 1.2492
INFO - Built for GTK 2.24.25
INFO - Running with GTK 2.24.25
INFO - Gscan2pdf::Document version 1.3.8
INFO - Using GtkImageView version 1.6.4
INFO - Using Gtk2::ImageView version 0.05
INFO - Using PDF::API2 version 2.023
INFO - Using Sane version 1.0.24
INFO - Using libsane-pe

Bug#785047: vsftpd/3.0.2-17+deb8u1

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: reopen -1

On 02/21/2016 11:08 AM, Jörg Frings-Fürst wrote:
>> @Joerg: Could you re-upload the package to mentors?
>> 
> 
> done.. [1]

Reopening since I am preparing the upload now.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyZfSAAoJEHQmOzf1tfkTTDAQAIfaINeqRqwFAkHslYKf9BjV
1St7RcUfUBk33JG+RMrSFS8ejZ2peDQAYVcgaLQrs0W4Tr0RuiLOeeD2mhPWTdX0
Uediyojh2zjzJHD6rTPe/I4CZMaaXNmUX3uUzmZZYiNwLcH9epbP9OG7v7K8mDC7
w2JS7EBpk0q8B+sZw+5ZC5gtwGud3n1GiJREm3GjZUOu7SSf1ii46Z+IBV1yeY4p
Ufzp5FiY6nafYLakZbffATxXUvLIqW6+HpCdMjxJS4insrUiKDQ1CRnKVt+cyUf1
zgyPhVuOWmvqzoxau3Le4alFv+O5e8d1UZ1ye19kINxUjg+3LVKh9vJP5lP3fcUw
F0mQdkkVI11nPilxSkQNIlSGZm6+ccCC63AWpD62uZw9DQdMf/FYsMZnxPzdfmlf
8s0TzuOwpUDIC8e+PVzNrSBfe6Rdn4VbZ4zmHYeajD6aM78vZSr+NfNlC1GNhqVu
i6pDJD5X2kTDTrr6b1HuQHfSjyoxM74t57DQduQDkeaMJlJ6gd89mg1kd7wKJ6zT
Q57o5axq0OVRTXiqll2BlsWGkLXcObSjsku9nn2IFxmygxmzp0dQ+1FbkpQDbaTR
HZOIqhBjPIZ5p3Xx2ebnfmWR2aKUZ02b3CqZnYClJOPo7e5CdheBgi7B1xc2bfKy
igrVcPwegKURt93/NM6W
=vbBf
-END PGP SIGNATURE-

Bug#815409: libguestfs: FTBFS on mips: segfault while creating blank-disk-1s.qcow2

[Andreas Beckmann]

Source: libguestfs
Version: 1:1.32.2-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

libguestfs FTBFS on mips:

https://buildd.debian.org/status/fetch.php?pkg=libguestfs&arch=mips&ver=1%3A1.32.2-3&stamp=1455065650

Making all in blank-disks
make[5]: Entering directory 
'/«PKGBUILDDIR»/debian/build-python3.4/test-data/blank-disks'
rm -f blank-disk-1s.raw
qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
truncate -s 512 blank-disk-1s.raw
rm -f blank-disk-1K.raw
truncate -s 1K blank-disk-1K.raw
qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1K.qcow2 1K
Makefile:1691: recipe for target 'blank-disk-1s.qcow2' failed
make[5]: *** [blank-disk-1s.qcow2] Segmentation fault


Andreas

Bug#804209: wheezy-pu: package fuse-exfat/0.9.7-2+deb7u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-01-07 at 10:26 +0100, Sven Hoexter wrote:
> On Fri, Jan 01, 2016 at 06:26:22PM +, Adam D. Barratt wrote:
> 
> Hi Adam,
> 
> > Please go ahead.
> 
> Uploaded.

This was accepted a while ago but I apparently forgot to tag it.

Regards,

Adam

Bug#815192: manpages-de: please make the build reproducible

[Dr. Tobias Quathamer]

Control: tags -1 pending

Am 19.02.2016 um 22:08 schrieb Reiner Herrmann:
> Hi!
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that manpages-de could not be built reproducibly.
> When processing po files with generate-addendum.sh and using a non-UTF8
> locale, grep misdetects them as binary files and embeds the line:
> "Binary file (standard input) matches"
> 
> The attached patch fixes this by telling grep to treat the input as
> text.

Hi,

thanks for the bug report and patch. It's applied upstream in git and
will be part of the next release.

Regards,
Tobias




signature.asc
Description: OpenPGP digital signature

Bug#815410: xmms2: FTBFS on hurd-i386: B-D libsmbclient-dev no longer available

[Andreas Beckmann]

Source: xmms2
Version: 0.8+dfsg-14
Severity: important

Hi,

xmms2 can no longer be built on hurd-i386 (but it built successfully on
that platform in the past), since samba is not built on hurd-i386 any
more and therefore libsmbclient-dev is gone.

If this cannot be trivially fixed (by building on hurd-i386 without
smb support), please request the outdated and uninstallable binary
packages to be decrufted.


Andreas

Bug#815133: gitlab installation fails with LoadError: cannot load such file -- /usr/share/gitlab/config/application

[Pirate Praveen]

On Sat, 20 Feb 2016 22:37:20 +0530 Pirate Praveen  
wrote:
> Hi Josch,
> 
> You'll have to do a fresh install as directory structure has changed 
> significantly.
> 
> 1. apt-get purge gitlab (removes files, so new version can add symlinks)
> 2. rm -rf /usr/share/gitlab (config, tmp, log were not empty).
> 3. userdel -r gitlab (/var/lib/gitlab is new home or .gitconfig can't be 
> created)
> 4. apt-get install gitlab

You have to also remove /usr/share/gitlab-shell/.gitlab_shell_secret

> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#813071: jessie-pu: package amavisd-new/1:2.10.1-2

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-02-21 at 13:24 +1100, Brian May wrote:
> "Adam D. Barratt"  writes:
> 
> > You've dropped the epoch in the new stanza. With that fixed, please feel
> > free to upload.
> 
> Have had confirmation that the change solves the problem. Fixed the
> version and uploaded.

Thanks; flagged for acceptance.

Regards,

Adam

Bug#815411: opensips: drop build-dep on libjson0-dev compat package

[Neil Williams]

Package: opensips
Version: 2.1.1-1
Severity: important
Tags: patch

Dear maintainer,

The json-c upstream has dropped an compatibility layer from libjson0(-dev)
to libjson-c2(-dev) in current upstream release.

Please update your build-depends from libjson0-dev to libjson-c-dev.

This bug severity will be bumped to serious when 0.12 is uploaded to
unstable.

I've included a patch for debian/control but I am unable to
upload due to the other FTBFS bugs in opensips.

Regards.
diff -Nru opensips-2.1.1/debian/changelog opensips-2.1.1/debian/changelog
--- opensips-2.1.1/debian/changelog	2015-08-28 08:18:08.0 +0100
+++ opensips-2.1.1/debian/changelog	2016-02-21 11:14:10.0 +
@@ -1,3 +1,10 @@
+opensips (2.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from libjson compat library
+
+ -- Neil Williams   Sun, 21 Feb 2016 11:14:10 +
+
 opensips (2.1.1-1) unstable; urgency=low
 
   * Initial Release (Closes: #556131)
diff -Nru opensips-2.1.1/debian/control opensips-2.1.1/debian/control
--- opensips-2.1.1/debian/control	2015-08-28 08:18:08.0 +0100
+++ opensips-2.1.1/debian/control	2016-02-21 11:13:14.0 +
@@ -14,7 +14,7 @@
libfreeradius-client-dev | libradiusclient-ng-dev,
libgeoip-dev (>= 1.4.4),
libhiredis-dev,
-   libjson0-dev,
+   libjson-c-dev,
libldap2-dev,
liblua5.1-dev,
libmemcache-dev,


signature.asc
Description: PGP signature

Bug#815368: [Pkg-alsa-devel] Bug#815368: libasound2-plugins: Victor Vran game crash with this package installed

[Elimar Riesebieter]

* Berillions  [2016-02-21 10:55 +0100]:

[...] 
> > AL lib: oss.c:169: Could not open /dev/dsp: No such file or directory
> >
> > Install alsa-oss and modprobe snd-pcm-oss.
> >
> I installed the package lauch the command and the game works and i have
> sound. Install libasound2-plugins still crash the game
> But the question is : How i do to play at others games which need the
> package if Victor Vran crash with it ?

Well, Debian isn't designed to run third party based games. If you
have trouble running such ones please consider to contact the game
autors or community. We at Debian don't have any ressources to
implement third party software (games you want to play)

> I found a solution but for me, it's not proper :
> 1- Install libpulsedsp:i386 package
> 2- cp "/usr/bin/padsp /usr/bin/padsp_32"
> 3- nano "/usr/bin/padsp_32" and change LD_PRELOADER=/usr/lib/x86_64... to
> LD_PRELOADER=/usr/lib/i386...
> 4- launch the game with padsp_32 ./VictorVranGoG

This is a starting point to discuss your intention at a property
game community but is worth to complain any faults as a Debian bug
here. So I close this bug hereby.


Elimar
-- 
  The path to source is always uphill!
-unknown-

Bug#815395: [Pkg-freeipa-devel] Bug#815395: python-kdcproxy: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 --dir . returned exit code 13

[Timo Aaltonen]

21.02.2016, 10:37, Chris Lamb kirjoitti:
> Source: python-kdcproxy
> Version: 0.3.2-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> python-kdcproxy fails to build from source in unstable/amd64:

I'm not sure if pybuild did the right thing, but running tox manually
reveals something that is actually a bug in mock

 FAILURES ===
_KDCProxyWSGITests.test_post_asreq ___
/usr/lib/python2.7/dist-packages/mock/mock.py:1297: in patched
arg = patching.__enter__()
/usr/lib/python2.7/dist-packages/mock/mock.py:1450: in __enter__
_name=self.attribute, **kwargs)
/usr/lib/python2.7/dist-packages/mock/mock.py:2320: in create_autospec
_name='()', _parent=mock)
/usr/lib/python2.7/dist-packages/mock/mock.py:2359: in create_autospec
_check_signature(original, new, skipfirst=skipfirst)
/usr/lib/python2.7/dist-packages/mock/mock.py:228: in _check_signature
_copy_func_details(func, checksig)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

func = 
funcopy = 

def _copy_func_details(func, funcopy):
funcopy.__name__ = func.__name__
funcopy.__doc__ = func.__doc__
try:
funcopy.__text_signature__ = func.__text_signature__
except AttributeError:
pass
# we explicitly don't copy func.__dict__ into this copy as it would
# expose original attributes that should be mocked
try:
funcopy.__module__ = func.__module__
except AttributeError:
pass
try:
funcopy.__defaults__ = func.__defaults__
except AttributeError:
pass
try:
funcopy.__kwdefaults__ = func.__kwdefaults__
except AttributeError:
pass
if not inPy3k:
>   funcopy.func_defaults = func.func_defaults
E   AttributeError: 'functools.partial' object has no attribute
'func_defaults'

https://github.com/nsqio/pynsq/pull/147

though I haven't tested if this would fix the tests here.

-- 
t

Bug#815396: python-snuggs: FTBFS: E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Chris,

Thanks for your work reproducible builds and reporting this issue.

On 21-02-16 09:38, Chris Lamb wrote:
>   E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
> /home/lamby/temp/cdt.20160221091808.ywQnUdn26V/python-snuggs-1.3.1/.pybuild/pythonX.Y_2.7/build;
>  python2.7 -m pytest 

The test command needed the path to the test script appended.

The fixed package is on its way to unstable.

Kind Regards,

Bas

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

Bug#815412: hubicfuse: diff for NMU version 2.0.0-1.1

[Neil Williams]

Package: hubicfuse
Version: 2.0.0-1
Severity: important
Tags: patch pending

Dear maintainer,

The json-c upstream has dropped an compatibility layer from libjson0(-dev)
to libjson-c2(-dev) in current upstream release.

hubicfuse needs to update the build-depends from libjson0-dev to libjson-c-dev
and in order to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792177,
I'm going around each of the reverse dependencies.

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

Regards.
diff -Nru hubicfuse-2.0.0/debian/changelog hubicfuse-2.0.0/debian/changelog
--- hubicfuse-2.0.0/debian/changelog	2015-04-28 08:24:49.0 +0100
+++ hubicfuse-2.0.0/debian/changelog	2016-02-21 11:22:31.0 +
@@ -1,3 +1,10 @@
+hubicfuse (2.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from libjson0-dev to libjson-0-dev
+
+ -- Neil Williams   Sun, 21 Feb 2016 11:22:28 +
+
 hubicfuse (2.0.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru hubicfuse-2.0.0/debian/control hubicfuse-2.0.0/debian/control
--- hubicfuse-2.0.0/debian/control	2015-04-28 08:24:49.0 +0100
+++ hubicfuse-2.0.0/debian/control	2016-02-21 11:20:00.0 +
@@ -3,7 +3,7 @@
 Maintainer: Sylvestre Ledru 
 Build-Depends: debhelper (>= 9.0.0), autotools-dev,
  libcurl4-openssl-dev, libxml2-dev, libssl-dev, libfuse-dev,
- libjson0-dev, pkg-config
+ libjson-c-dev, pkg-config
 Standards-Version: 3.9.6
 Section: utils
 Homepage: https://github.com/TurboGit/hubicfuse


signature.asc
Description: PGP signature

Bug#815216: execjs error

[Pirate Praveen]

Precompiling assets...
fatal: Not a git repository (or any of the parent directories): .git
rake aborted!
ExecJS::ProgramError: Error: Parse error on line 19: Unexpected 'INDENT'
Object.parseError ((execjs):1723:11)
Object.parse ((execjs):1800:22)
exports.compile.compile [as compile] ((execjs):5101:20)
compile ((execjs):5333:31)
eval (eval at  ((execjs):5347:8), :1:10)
(execjs):5347:8
(execjs):5353:14
require../helpers.exports ((execjs):1:102)
Object. ((execjs):1:120)
Module._compile (module.js:410:26)
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)



signature.asc
Description: OpenPGP digital signature

Bug#750245: binfmt-support: does not set up binfmts in a chroot if they are already in the host system

[Colin Watson]

Control: tag -1 fixed-upstream

On Mon, Aug 10, 2015 at 12:09:00AM +0200, Raphael Hertzog wrote:
> I have been bitten by this on official Kali isos. I'm taking the liberty
> to upgrade this to important as it breaks other packages... for instance
> a package depending on jarwrapper expects to have /usr/bin/burpsuite as a
> jar file to be working. And due to this bug, it's not the case in the live
> image.
> 
> https://bugs.kali.org/view.php?id=2466

FYI this appears to be a private bug or something; I don't have an
account on this bug tracker, and logging in anonymously just returns
"Access Denied" here.  It probably doesn't matter.

> IMO update-binfmts should always record the entry in its database and just
> let act_enable() do nothing when it detects that it's already enabled in
> some other way.
> 
> The attached patch should do this, I'm going to try this on the Kali
> side.

Thanks for this patch, and sorry for taking so long to respond.  I think
your analysis is correct here.  The underlying problem we're working
around is that we don't have per-chroot (etc.) state in binfmt_misc; but
the workaround in act_install was significantly older (Dec 2000 in its
original Perl implementation) than the one in act_enable (Jul 2012,
#680349), and I ought to have removed the former when adding the latter.

I've committed your patch upstream, and it will be in 2.1.6.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope

[Frank B. Brokken]

Dear Andreas Beckmann, you wrote:

> If this isn't trivially fixable, please request the outdated binary
> packages to be decrufted.

It should be trivially fixable: should be a matter of including
 in alternatives/alternatives.ih. (*should* because I don't
have access to a hurd machine, so I can't test the presumed fix directly).

I'll try to prepare a new release today. Thanks!

-- 
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA

Bug#812251: fixed in apt 1.2.1

[Francesco Poli]

Control: found -1 apt/1.2.3


On Mon, 25 Jan 2016 17:18:48 + Julian Andres Klode wrote:

> Source: apt
> Source-Version: 1.2.1
> 
> We believe that the bug you reported is fixed in the latest version of
> apt, which is due to be installed in the Debian FTP archive.
[...]
>* Remap StringView instances pointing into the cache (Closes: #812251)
[...]

Hello,
I've just experienced this issue (for the first time) with apt/1.2.3 on
a i386 Debian testing box (a Soekris net5501-60 board, to be precise).

Today, running:

  # aptitude update
  Get: 1 http://security.debian.org testing/updates InRelease [62.8 kB]
  [...]
  Get: 21 http://debian.ethz.ch/debian unstable/main Translation-en 
2016-02-21-0858.48.pdiff [97 B]
  Fetched 868 kB in 1min 19s (11.0 kB/s)
  [100%] Reading package listsSegmentation fault

led to a segfault.
Trying again was useless:

  # aptitude update
  Segmentation fault

Wiping /var/lib/apt/lists completely and starting afresh was useless:

  # aptitude update
  Get: 1 http://security.debian.org testing/updates InRelease [62.8 kB]
  [...]
  Get: 9 http://debian.ethz.ch/debian unstable/main Translation-en [5,319 kB]   
  
  Fetched 26.7 MB in 2min 41s (165 kB/s)
  
  [100%] Reading package listsSegmentation fault

Updating the package lists with apt equally resulted in a segfault:

  # apt update 
  Hit:1 http://security.debian.org testing/updates InRelease
  Hit:2 http://debmirror.amis.net/debian testing InRelease
  Hit:3 http://debmirror.amis.net/debian unstable InRelease
  Segmentation faultsts... 65%

Using the workaround suggested in this bug log (see message #15)
allowed me to update the package lists:

  # aptitude -o APT::Cache-Start=1 update 
  Hit http://security.debian.org testing/updates InRelease
  Hit http://ftp-stud.hs-esslingen.de/debian unstable InRelease
  Hit http://debmirror.amis.net/debian testing InRelease

without any segfaults.
After that, everything worked fine:

  # aptitude --purge-unused safe-upgrade
  The following packages will be upgraded:
  [...]
  Current status: 0 (-3) upgradable.


Please note that I had libapt-pkg5.0/1.2.3 installed on this box, both
before and after today's upgrade.

I am reopening the bug report, since the bug does not seem to be
(completely) fixed.
Please fix this issue.

Thanks for your time!
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgptgprfK4EsQ.pgp
Description: PGP signature

Bug#814276: Non-Free file: src/stdlib/SDL_qsort.c

[Manuel A. Fernandez Montecelo]

Hi Ben,

2016-02-21 03:09 Ben Hutchings:

I happen to know the original author, so I've mailed him requesting he
consider relicencing.


I suppose that you were looking into this as part of the BSP.

I notified upstream a few days ago, and they didn't want to be in
possible breach of the license, so they changed the implementation for
libsdl2:

 
http://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-February/002374.html

libsdl1.2 suffers from the same problem, but we can just repack the
orig.tar and disable the use of this implementation (it's supposed to
not be used by default, so an empty file would do, or otherwise the file
from libsdl2 can be used).

So, in summary, I am going to upload fixes in the next few days.


At this point I suspect that upstream is not going to go back (unless
the implementation that they now use is problematic).  Maybe it's good
if you could get this relicenced just in case, e.g. for the benefit of
other distros.  What do you think?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815216: Jessie repo

[Pirate Praveen]

Install from

http://pod.pxq.in
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#815413: libu2f-host: diff for NMU version 1.0.0-1.1

[Neil Williams]

Package: libu2f-host
Version: 1.0.0-1
Severity: important
Tags: patch pending

Dear maintainer,

The json-c upstream has dropped an compatibility layer from libjson0(-dev)
to libjson-c2(-dev) in current upstream release.

libu2f-host needs to update the build-depends from libjson0-dev to libjson-c-dev
and in order to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792177,
I'm going around each of the reverse dependencies of libjson0-dev.

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

Regards.
diff -Nru libu2f-host-1.0.0/debian/changelog libu2f-host-1.0.0/debian/changelog
--- libu2f-host-1.0.0/debian/changelog	2015-09-22 07:50:15.0 +0100
+++ libu2f-host-1.0.0/debian/changelog	2016-02-21 11:40:17.0 +
@@ -1,3 +1,10 @@
+libu2f-host (1.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from libjson0-dev to libjson-c-dev
+
+ -- Neil Williams   Sun, 21 Feb 2016 11:40:17 +
+
 libu2f-host (1.0.0-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru libu2f-host-1.0.0/debian/control libu2f-host-1.0.0/debian/control
--- libu2f-host-1.0.0/debian/control	2015-04-20 10:19:24.0 +0100
+++ libu2f-host-1.0.0/debian/control	2016-02-21 11:40:33.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 9),
 	   pkg-config,
 	   libhidapi-dev,
-	   libjson0-dev,
+	   libjson-c-dev,
 	   gengetopt,
 	   help2man,
 	   dh-autoreconf,


signature.asc
Description: PGP signature

Bug#813916: transition: gdal

[Sebastiaan Couwenberg]

On 19-02-16 14:08, Sebastiaan Couwenberg wrote:
> On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
>> On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
>>> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
 On 06/02/16 17:43, Bas Couwenberg wrote:
> Package: release.debian.org
> For the Debian GIS team I'd like to transition to the recently released
> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>
> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
> support for GDAL 2.0 in all reverse dependencies. Since the transition
> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
> depedencies except Fiona [0]. Upstream has recently included changes for
> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
> as a patch in #802808. The improved GDAL 2.0 changes are entangled with
> other changes for the upcoming Fiona 1.7 release, which I've not been
> able to successfully backport. This will not be a blocker for the GDAL
> 2.0 transition, as discussed with the maintainer on the debian-gis list
> [1].
>
> Because the transition for GDAL 1.11.4 is ready now, I'd like to do that
> first before preparing the transition to GDAL 2.0. All reverse
> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
> rebuilds is included below.
>

 This would get entangled with the openmpi transition, so it will have to 
 wait.
 After openmpi, I'm thinking about doing libpng, but we'll see.
>>>
>>> Waiting for openmpi is no problem, but if the libpng transition is going
>>> to happen first, I think it's better to use that time the prepare the
>>> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
>>> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
>>> The 2.0 packages will have to pass the NEW queue again, because of the
>>> delay that will cause I've opted to transition to 1.11.4 which is ready now.
>>>
>>> If you can confirm that the libpng transition is going to happen first,
>>> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
>>> to that in unstable after the libpng transition and the new gdal has
>>> passed NEW.
>>
>> Sure, let's do that.
> 
> The GDAL 2.0.2 packages are available in experimental and ready for
> transition.
> 
> libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
> grass need to be rebuilt with GDAL 2.0 before it can be built too,
> because the SOVERSION is included in the binary package it builds the
> package will have to pass the NEW queue after upload first. To get it
> passed the NEW queue, I'll rebuild liblas & grass with gdal
> (2.0.2-1-1~exp2) from experimental and upload all three to experimental too.

libgdal-grass (2.0.2-1~exp1) and its dependencies are in experimental
now too.

Kind Regards,

Bas

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

Bug#815415: libu2f-server: diff for NMU version 1.0.1-1.1

[Neil Williams]

Package: libu2f-server
Version: 1.0.1-1
Severity: important
Tags: patch pending

Dear maintainer,

The json-c upstream has dropped an compatibility layer from libjson0(-dev)
to libjson-c2(-dev) in current upstream release.

libu2f-server needs to update the build-depends from libjson0-dev to 
libjson-c-dev
and in order to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792177,
I'm going around each of the reverse dependencies of libjson0-dev.

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

Regards.
diff -Nru libu2f-server-1.0.1/debian/changelog libu2f-server-1.0.1/debian/changelog
--- libu2f-server-1.0.1/debian/changelog	2015-08-11 13:24:34.0 +0100
+++ libu2f-server-1.0.1/debian/changelog	2016-02-21 11:45:39.0 +
@@ -1,3 +1,10 @@
+libu2f-server (1.0.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from libjson0-dev to libjson-c-dev
+
+ -- Neil Williams   Sun, 21 Feb 2016 11:45:37 +
+
 libu2f-server (1.0.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libu2f-server-1.0.1/debian/control libu2f-server-1.0.1/debian/control
--- libu2f-server-1.0.1/debian/control	2015-08-11 13:14:58.0 +0100
+++ libu2f-server-1.0.1/debian/control	2016-02-21 11:45:53.0 +
@@ -7,7 +7,7 @@
 	   pkg-config,
 	   libssl-dev,
 	   check,
-	   libjson0-dev,
+	   libjson-c-dev,
 	   gengetopt,
 	   help2man,
 	   dh-autoreconf,


signature.asc
Description: PGP signature

Bug#815414: git-buildpackage incorrectly drop "Gbp-Pq: Topic " strings

[Antonio Radici]

Package: git-buildpackage
Version: 0.7.2
Severity: important

This problem compromises our ability to use git-buildpackage to manage quilt
patches.

It seems that "gbp pq export" incorrectly drops the "Gbp-Pq: Topic" strings that
are set in the patches.

Additionally if a new patch is created and it contains
"Gbp-Pq: Topic misc" in the commit message, then the new patch is not placed on
the misc directory.
Let me know if you want me to file another bug for this second problem.

To reproduce:

git clone git://anonscm.debian.org/pkg-mutt/mutt.git
gbp pq import
git checkout master
gbp pq export
git status

Cheers
Antonio

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

Kernel: Linux 4.3.0-1-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 git-buildpackage depends on:
ii  devscripts2.15.10
ii  git   1:2.7.0-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  18.8-1
ii  python-six1.10.0-2
pn  python:any

Versions of packages git-buildpackage recommends:
ii  pbuilder 0.223
ii  pristine-tar 1.33
ii  python-requests  2.9.1-2

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

Bug#785924: [Freewx-maint] Bug#785924: wxwidgets3.0: Please update to GStreamer 1.x

[Olly Betts]

Sebastian Dröge  wrote:
> How can I test the wxwidgets GStreamer integration?

You need to test via an application which uses it - something which depends
on the wx or wxpython media package.  I think I've used whyteboard for this
before.

Thanks for looking at this.

Cheers,
Olly

Bug#815416: does not regenerate format files after installing hyphenation patterns

[Dmitry Eremin-Solenikov]

Package: tex-common
Version: 6.04
Severity: normal

After installing texlive-lang-* packages, the triggers do only update
the language.* files, but do not regenerate the compiled format files,
thus resulting in warnings like the following one. Running fmtutil --sys
--all as root fixes the issue.

[...cut...]
) (/usr/share/texlive/texmf-dist/tex/generic/babel-russian/russianb.ldf
Language: russianb 2015/05/01 1.3g Russian support for the Babel system


Package babel Warning: No hyphenation patterns were preloaded for
(babel)the language `Russian' into the format.
(babel)Please, configure your TeX system to add them and
(babel)rebuild the format. Now I will use the patterns
(babel)preloaded for english instead on input line 26.

\l@russian = a dialect from \language0
[...cut...]

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

Kernel: Linux 4.3.0-1-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/bash
Init: systemd (via /run/systemd/system)

Versions of packages tex-common depends on:
ii  dpkg  1.18.4
ii  ucf   3.0033

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  9.20160115

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  libpaper-utils 1.1.24+nmu4
ii  texlive-binaries   2015.20150524.37493-7+b1
ii  ucf3.0033
ii  xdg-utils  1.1.1-1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   3.18.2-1
ii  ghostscript [postscript-viewer]  9.16~dfsg-2.1
ii  gv [postscript-viewer]   1:3.7.4-1
pn  perl-tk  
pn  xpdf-reader | pdf-viewer 

Versions of packages texlive-binaries depends on:
ii  dpkg  1.18.4
ii  install-info  6.1.0.dfsg.1-1
ii  libc6 2.21-8
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-8
ii  libgmp10  2:6.1.0+dfsg-2
ii  libgraphite2-31.3.5-1
ii  libgs99.16~dfsg-2.1
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libkpathsea6  2015.20150524.37493-7+b1
ii  libmpfr4  3.1.3-2
ii  libpaper1 1.1.24+nmu4
ii  libpixman-1-0 0.33.6-1
ii  libpoppler57  0.38.0-2
ii  libpotrace0   1.13-2
ii  libptexenc1   2015.20150524.37493-7+b1
ii  libsm62:1.2.2-1+b1
ii  libstdc++65.3.1-8
ii  libsynctex1   2015.20150524.37493-7+b1
ii  libtexlua52   2015.20150524.37493-7+b1
ii  libtexluajit2 2015.20150524.37493-7+b1
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.6-1
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.11-1+b1
ii  libxt61:1.1.5-1
ii  libzzip-0-13  0.13.62-3
ii  perl  5.22.1-7
ii  t1utils   1.39-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages texlive-binaries recommends:
ii  python2.7.11-1
ii  ruby  1:2.2.4
ii  texlive-base  2015.20160117-1
ii  tk [wish] 8.6.0+9

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:

Bug#815417: Needs a menu entry

[Eduard Bloch]

Package: dwww
Version: 1.13.1
Severity: minor

Hello,

I have been always wondering about some things... why do I have to run
dwww from command line if it opens a X11 web browser afterwards?

dwww is a good entry point to a generic help portal. It should be
available in Debian menu entries, right in the beginning of the "Help"
section.

Regards,
Eduard.


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi]2.4.18-1
ii  debconf [debconf-2.0]  1.5.58
ii  debianutils4.7
ii  doc-base   0.10.7
ii  file   1:5.25-2
ii  libc6  2.21-7
ii  libfile-ncopy-perl 0.36-1
ii  libmime-types-perl 2.12-1
ii  man-db 2.7.5-1
ii  mime-support   3.59
ii  perl   5.22.1-7
ii  ucf3.0035

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.18-1
ii  apt  1.2.3
ii  dlocate  1.02+nmu3
ii  info2www 1.2.2.9-24
ii  swish++  6.1.5-3

Versions of packages dwww suggests:
ii  chromium [www-browser]   48.0.2564.82-2
ii  doc-debian   6.3
pn  dpkg-www 
ii  dwb [www-browser]20150419git-2+b1
ii  elinks [www-browser] 0.12~pre6-11+b2
ii  iceweasel [www-browser]  45.0~b5-1
ii  konqueror [www-browser]  4:15.08.3-1
ii  links [www-browser]  2.12-1+b1
ii  lynx [www-browser]   2.8.9dev8-4
ii  opera [www-browser]  12.15.1748
ii  qupzilla [www-browser]   1.8.9~dfsg1-3
ii  w3m [www-browser]0.5.3-26

-- debconf information:
* dwww/servername: zombie.inka.de
* dwww/cgiuser: www-data
* dwww/docrootdir: /var/www
* dwww/cgidir: /usr/lib/cgi-bin
  dwww/nosuchuser:
  dwww/badport:
* dwww/serverport: 80
  dwww/index_docs: true
  dwww/nosuchdir:

-- 
Scheich zu Bill Gates: "Ich bin so reich, daß ich die ganze Welt
kaufen kann."
Bill Gates: "Ich verkaufe zur Zeit nicht."

Bug#815407: xd: FTBFS on hurd-i386: error: 'PATH_MAX' was not declared in this scope

[Andreas Beckmann]

On 2016-02-21 12:30, Frank B. Brokken wrote:
> It should be trivially fixable: should be a matter of including
>  in alternatives/alternatives.ih. (*should* because I don't

Does that header exist on hurd-i386?

Probably ask the hurd porters for advice how to fix this recurring problem.


Andreas

Bug#545814: Mutt count strlen in bytes != symbols

[Antonio Radici]

forwarded 545814 http://bugs.mutt.org/3807
severity 545814 wishlist
tag 545814 -pending
thanks

On Wed, Sep 09, 2009 at 02:48:32PM +0400, Dmitry E. Oboukhov wrote:
> Package: mutt
> Version 1.5.20-2
> Tags: l10n
> 
> Now I've attached at LDAP-address-book and added instruction
> set query_command = "lbdbq '%s'"
> 
> It works fine only if address name contains only latin1 symbols.
[...]

Hi Dmitry,
I had another run at this but it seems a bit tricky to patch, snprintf can
handle wide characters but I believe that some other things are done in the
caller of query_format_str.

I've reported it upstream as an enhancement, I'll change the severity of this
bug to wishlist accordingly, I'll have another look at it next week, I might be
able to patch it.

Bug#545814: #3807: query_format should handle unicode string

[Mutt]

#3807: query_format should handle unicode string
-+--
 Reporter:  antonio@…|  Owner:  mutt-dev
 Type:  enhancement  | Status:  new
 Priority:  minor|  Milestone:
Component:  display  |Version:
 Keywords:   |
-+--
 Hi,
 it will be great if query_format could handle unicode string, at the
 moment it is not the case and strings like:

 Дмитрий Эдуардович

 get truncated based on the precision specified in query_format, so if I
 specify %2n, I will only get the first character rather than the first two
 (because there are 2 bytes in Д)

 snprintf already handles this case if %ls is specified rathern than %s,
 I've had a look at query_format_str but I've been unable to patch it
 properly (I think that the caller might also do other things with the
 output).

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Bug#797181: Review status

[Wichert Akkerman]

Hi,

I was wondering if there has been any progress on this ticket?

Regards,
Wichert.

Bug#811591: Fixed FTBFS

[Miriam Ruiz]

tags 811591 patch
thanks

I've reproduced the bug by following tbm's indication, and fixed it
with the attached patch.

Greetings,
Miry
diff -ruN -x rules ifhp-3.5.20.orig/debian/changelog ifhp-3.5.20/debian/changelog
--- ifhp-3.5.20.orig/debian/changelog	2014-05-09 12:44:38.0 +
+++ ifhp-3.5.20/debian/changelog	2016-02-21 12:04:38.0 +
@@ -1,3 +1,9 @@
+ifhp (3.5.20-14) UNRELEASED; urgency=medium
+
+  * Added patch to make it buildable with GCC 6. Closes: #811591
+
+ -- Miriam Ruiz   Sun, 21 Feb 2016 12:03:07 +
+
 ifhp (3.5.20-13) unstable; urgency=medium
 
   [HIGUCHI Daisuke (VDR dai)]
diff -ruN -x rules ifhp-3.5.20.orig/debian/patches/70-fix-ftbfs-gcc6.patch ifhp-3.5.20/debian/patches/70-fix-ftbfs-gcc6.patch
--- ifhp-3.5.20.orig/debian/patches/70-fix-ftbfs-gcc6.patch	1970-01-01 00:00:00.0 +
+++ ifhp-3.5.20/debian/patches/70-fix-ftbfs-gcc6.patch	2016-02-21 11:56:41.0 +
@@ -0,0 +1,128 @@
+Index: ifhp-3.5.20/src/ifhp.c
+===
+--- ifhp-3.5.20.orig/src/ifhp.c
 ifhp-3.5.20/src/ifhp.c
+@@ -1345,7 +1345,8 @@ void Process_job( int do_pagecount, int
+ 			Errorcode = JFAIL;
+ 			LOGERR_DIE(LOGINFO) _("Process_job: outfd dup2(%d,1) failed"), out_fd );
+ 		}
+-		if( tempfd > 0 ) close(tempfd); tempfd = -1;
++		if( tempfd > 0 ) close(tempfd);
++		tempfd = -1;
+ 		close(in_fd);
+ 		close(out_fd);
+ 		End_of_job(&startpagecounter, do_pagecount, pagecount_ps,
+@@ -3379,7 +3380,8 @@ int Pjl_setvar(char *prefix, char*id, ch
+ 	LOGMSG(LOG_INFO)_("Pjl_setvar: WARNING - unknown type for PJL variable '%s' = '%s', %s"),
+ 			id, value, type_name ); 
+ }
+-if( working ) free( working ); working = 0;
++if( working ) free( working );
++working = 0;
+ 			} else {
+ /* we do not have constraint */
+ /* convert to ON/OFF if numerical value */
+@@ -3674,7 +3676,8 @@ void Do_sync( int sync_timeout, int sync
+ 		Errorcode = JFAIL;
+ 		FATAL(LOGINFO)"Do_sync: no sync response from printer" );
+ 	}
+-	if( use_prog ) free( use_prog ); use_prog = 0;
++	if( use_prog ) free( use_prog );
++	use_prog = 0;
+ 	LOGMSG(LOG_INFO)_("Do_sync: sync done"));
+ }
+ 
+@@ -4000,7 +4003,8 @@ void Do_waitend( int waitend_timeout, in
+ 		if( Errorcode == 0 ) Errorcode = JFAIL;
+ 		FATAL(LOGINFO)_("Do_waitend: no end response from printer, timeout %d"), waitend_timeout );
+ 	}
+-	if( use_prog ) free( use_prog ); use_prog = 0;
++	if( use_prog ) free( use_prog );
++	use_prog = 0;
+ 	LOGMSG(LOG_INFO)_("Do_waitend: %s detected %s END"), banner?_("BANNER PAGE"):_("JOB"), waitend );
+ }
+ 
+@@ -4654,7 +4658,8 @@ void Send_job()
+ 			Errorcode = JABORT;
+ 			LOGERR_DIE(LOGINFO) _("Make_stdin_file: dup2 failed") );
+ 		}
+-		if( tempfd != 0 ) close(tempfd); tempfd = -1;
++		if( tempfd != 0 ) close(tempfd);
++		tempfd = -1;
+ 		language = 0;
+ 		/* if you did filtering,  then reopen for the job */
+ 		goto again;
+@@ -5095,7 +5100,8 @@ void Make_stdin_file()
+ 			Errorcode = JABORT;
+ 			LOGERR_DIE(LOGINFO) _("Make_stdin_file: dup2 failed") );
+ 		}
+-		if( fd != 0 ) close(fd); fd = -1;
++		if( fd != 0 ) close(fd);
++		fd = -1;
+ 	}
+ 	if( lseek(0,0,SEEK_SET) == -1 ){
+ 		Errorcode = JABORT;
+@@ -5761,7 +5767,8 @@ void Select_model_info( OBJ *model, OBJ
+ 		SNPRINTF(msg,sizeof(msg)) "Select_model_info: for '%s'", id );
+ 		SHORT_DUMP_OBJ(msg, model );
+ 	}
+-	if( hash ) FREE_OBJ( hash ); hash = 0;
++	if( hash ) FREE_OBJ( hash );
++	hash = 0;
+ }
+ 
+ /*
+Index: ifhp-3.5.20/src/accounting.c
+===
+--- ifhp-3.5.20.orig/src/accounting.c
 ifhp-3.5.20/src/accounting.c
+@@ -116,7 +116,9 @@ void Do_accounting(int start, int elapse
+ 			Errorcode = n;
+ 			FATAL(LOG_INFO)_("Do_accounting: script '%s' failed"), Accounting_script);
+ 		}
+-		if( s ) free(s); s = 0;
++		if( s ) free(s);
++		s = 0;
+ 	}
+-	if( list ) free(list); list = 0;
++	if( list ) free(list);
++	list = 0;
+ }
+Index: ifhp-3.5.20/src/open_device.c
+===
+--- ifhp-3.5.20.orig/src/open_device.c
 ifhp-3.5.20/src/open_device.c
+@@ -158,7 +158,8 @@ int Link_open( char * device )
+ 		}
+ 		if( fd >= 0 ) break;
+ 	}
+-	if( dcopy ) free(dcopy); dcopy = 0;
++	if( dcopy ) free(dcopy);
++	dcopy = 0;
+ 	return(fd);
+ }
+ 
+Index: ifhp-3.5.20/src/perlobj.c
+===
+--- ifhp-3.5.20.orig/src/perlobj.c
 ifhp-3.5.20/src/perlobj.c
+@@ -193,7 +193,8 @@ OBJ *Clear_OBJ( OBJ *p )
+ 		case OBJ_T_LIST:
+ 			list = p->info.array.value;
+ 			for( i = 0; i < p->info.array.len; ++i ){
+-if( list[i] ) safefree(list[i], MEMINFO); list[i] = 0;
++if( list[i] ) safefree(list[i], MEMINFO);
++list[i] = 0;
+ 			}
+ 			safefree( p->info.array.value, MEMINFO );
+ 			break;
+@@ -2989,7 +2990,8 @@ int Parse_obj_obj_str( OBJ **objp )
+ 			c = Get_parse_token(name);
+ 		}
+ 	}
+-	if( name ) FREE_O

Bug#815418: libosinfo-1.0-0: uninstallable on hurd-i386: depends on unavailable usbutils

[Andreas Beckmann]

Package: libosinfo-1.0-0
Version: 0.2.12-2
Severity: important

Hi,

libosinfo-1.0-0 built fine on hurd-i386, but it is not installable
on that platform:

The following packages have unmet dependencies:
 libosinfo-1.0-0 : Depends: usbutils but it is not installable

The usbutils package is not available on hurd-i386 (due to lack of
dependencies).

If the libosinfo-1.0-0 is functional without usbutils, please drop that
dependency on hurd-i386, e.g:
  Depends: usbutils [!hurd-i386]
but if the package is useless without usbutils, please stop building it
for hurd-i386, e.g. by adding
  Build-Depends: usbutils [hurd-i386]
(so it would automatically build the package again once
usbutils:hurd-i386 becomes available).


Andreas

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Ben Hutchings]

On Sun, 2016-02-21 at 08:40 +0100, Mateusz Kaduk wrote:
> Hi Ben,
[...]
> > - If you haven't already reported this, does the Linux 4.5-rc4 package
> >   from experimental have the same problem?
> > 
> 
> I am using 4.5.0-rc4-amd64 from experimental at the moment as that boots
> without issues.
> Only 4.4.0 seems to be affected.
> 
> > This test version is now available at
> > https://people.debian.org/~benh/packages/unstable/
> 
> 
> > Please report back whether this does or doesn't fix the problem for
> > you. 
> 
> I installed 4.4.2-3~a.test and it replaced previous 4.4.x package, but
> system is not booting either.
> 
> Let me know if you need anything.

It sounds like this is a slightly different bug; please open a new bug report.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.

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

Bug#814269: jessie-pu: package nettle/2.7.1-5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2016-02-09 at 20:59 +0100, Magnus Holmgren wrote:
> OK to upload fix for https://bugs.debian.org/813679 (CVE-2015-8803
> CVE-2015-8804 CVE-2015-8805), as suggested by (a member of) the
> security team? (Security-related bugs but unlikely to be exploitable.)

Assuming that the resulting package has been tested on Jessie, please go
ahead.

Regards,

Adam

Bug#784915: jessie-pu: package rsnapshot/1.3.1-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2015-10-26 at 00:26 +0100, Guillaume Delacour wrote:
> Hi,
> 
> Le 21/08/2015 16:34, Adam D. Barratt a écrit :
> 
> > 
> > The package in unstable and testing appears to have been fixed now.
> > 
> >> In either case, when it comes to an update in stable we'll need a source
> >> debdiff of the proposed updated package, built and tested in a Jessie
> >> environment, rather than pointers to online patches.
> > 
> > This is still true, however.
> 
> Please find attached a debdiff that fix the problem in Jessie. I've
> tested the fix by defining ssh_args in /etc/rsnapshot.conf and it's
> works well after the fix (before applying the update rsnapshot fails
> with "rsync: Failed to exec /usr/bin/ssh -p222: No such file or directory").

Apologies for the delay in getting back to you. Please go ahead.

Regards,

Adam

Bug#684499: Fixed upstream

[Emilio Jesús Gallego Arias]

found 684499 1:2.2.13-12~deb8u1
found 684499 1:2.2.18-2+b1
forwarded 684499 http://www.dovecot.org/list/dovecot/2016-February/103205.html
severity 684499 serious
tags 684499 +patch +fixed-upstream +confirmed

thanks

Hi,

I think this bug has been fixed and identified upstream.

Raising to serious as missed expunges are not something clients expect
and indeed can cause mail corruption or really weird behavior.

I've asked Timo if the patch would be suited for Jessie.

Thanks,
Emilio