Bug#816227: ping: socket: Address family not supported by protocol (raw socket required by specified options).

[Florent Rougon]

Hello,

On Sun, 28 Feb 2016 22:38:05 + Jamie Heilman  
wrote:

> Noah Meyerhans wrote:
> > I cannot reproduce this on a host with no ipv6 connectivity. Does 
> > 'ping -4 127.0.0.1' work any differently?
> 
> Yeah, that works.

Same here. 'ping -4 ' works fine but 'ping '
doesn't (I tried with 127.0.0.1, with the address of a local Ethernet
interface, with the address of a host I can ssh to on the local
network...).

> > By "no ipv6 support", do you mean you're running a custom kernel with a
> > different configuration than provided by Debian?

For me, the kernel is that from linux-image-4.4.0-1-amd64 version
4.4.2-3 (recently updated from unstable), rebuilt with one tiny patch
that is not network-related in any way, and which I have been using
since June 2015 without any problem: it is just reverting upstream Linux
kernel commit 79346d620e9de87912de73337f6df8b7f9a46888 ("HID: input:
force generic axis to be mapped to their user space axis"; I
unfortunately have to apply this patch to every kernel release since
then, because nobody bothered to even answer bug #785606 despite my
'git bisect'ing it).

Apart from that, I use:

  GRUB_CMDLINE_LINUX="init=/bin/systemd ipv6.disable=1"

in /etc/default/grub, which effectively disables IPv6, AFAICT.

My aptitude.log shows:

  [UPGRADE] iputils-ping:amd64 3:20121221-5+b2 -> 3:20150815-1

on Fri, Feb 26 2016 20:48:43 +0100, and I only noticed the problem
today.

Thanks for considering!

-- 
Florent

Bug#815974: Segmentation fault in libresolv triggered by php5-fpm

[Fabian Niepelt]

Am Samstag, den 27.02.2016, 23:59 +0100 schrieb Aurelien Jarno:
> On 2016-02-26 22:03, Fabian Niepelt wrote:
> > 
> > > 
> > > IMHO making sure that programs are restarted after applying the
> > > security
> > > update should be enough, but I am not fully sure about my
> > > analysis, so a
> > > confirmation would be nice to have.
> > The machines in question have been rebooted a few times after
> > upgrading.
> Ok then my scenario might be wrong.
> 
> > 
> > I will try to get a full backtrace next week. Sadly, I won't have
> > access to the systems over the weekend.
> Ok, no problem.
> 
> > 
> > > 
> > > It wonder if it could be that the process is started with the
> > > old libc and is later dlopening the new nss libraries.
> > Going to investigate if there are old libs lying around somewhere
> > in the system on monday.
> I am able to trigger similar (but slightly different) segmentation
> fault
> by doing name resolving with the new libc (ie 2.13-38+deb7u10) but
> with
> the old /lib/x86_64-linux-gnu/libnss_dns.so.2 (ie from 2.13-
> 38+deb7u9).
> Do you have any nss modules which do not come from the libc6 package
> installed (either from another package or manually installed)?
> 

Yep, this was it. Searching for the lib yielded an old version of it
that is not managed by package management...
Thank you for giving me the hint.

> Thanks for your help in debugging.

Thank you all for your time and sorry for the noise!

Greetings

Bug#816253: ruby-fast-gettext: FTBFS: pecified 'sqlite3' for database adapter, but the gem is not loaded

[Chris Lamb]

Source: ruby-fast-gettext
Version: 0.9.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,

ruby-fast-gettext fails to build from source in unstable/amd64:

  [..]
  
10) FastGettext::TranslationRepository::Db expires the cache when updated
Failure/Error: ActiveRecord::Base.establish_connection(
Gem::LoadError:
  Specified 'sqlite3' for database adapter, but the gem is not loaded. 
Add `gem 'sqlite3'` to your Gemfile (and ensure its version is at the minimum 
required by ActiveRecord).
# ./spec/fast_gettext/translation_repository/db_spec.rb:10:in `block (2 
levels) in '
  
  Finished in 1.16 seconds (files took 0.45078 seconds to load)
  208 examples, 10 failures
  
  Failed examples:
  
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:1]' # 
FastGettext::TranslationRepository::Db reads locales from the db
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:2]' # 
FastGettext::TranslationRepository::Db has no pluralisation_rule by default
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:3]' # 
FastGettext::TranslationRepository::Db cannot translate when no models are 
present
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:4]' # 
FastGettext::TranslationRepository::Db can translate
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:5]' # 
FastGettext::TranslationRepository::Db cannot pluralize when no model is present
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:6]' # 
FastGettext::TranslationRepository::Db can pluralize
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:7]' # 
FastGettext::TranslationRepository::Db can ignore newline format
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:8]' # 
FastGettext::TranslationRepository::Db removes texts when key is removed
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:9]' # 
FastGettext::TranslationRepository::Db model attributes should be accessible
  rspec './spec/fast_gettext/translation_repository/db_spec.rb[1:10]' # 
FastGettext::TranslationRepository::Db expires the cache when updated
  
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080718.2dFvoRQW3t/ruby-fast-gettext-0.9.2/debian/ruby-fast-gettext
 returned exit code 1
  debian/rules:15: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

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


ruby-fast-gettext.0.9.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816258: trocla: FTBFS: Self-signed certificate /CN=test creation failed: wrong argument

[Chris Lamb]

Source: trocla
Version: 0.1.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,

trocla fails to build from source in unstable/amd64:

  [..]

  Failures:
  
1) Trocla password x509 password format should return a password hashed in 
the x509 format
   Failure/Error: 
@trocla.password('some_test',format,format_options[format]).should_not be_empty
   RuntimeError:
 Self-signed certificate /CN=test creation failed: wrong argument 
(OpenSSL::X509::Certificate)! (Expected kind of OpenSSL::X509::Name)
   # ./lib/trocla/formats/x509.rb:66:in `rescue in format'
   # ./lib/trocla/formats/x509.rb:61:in `format'
   # ./lib/trocla.rb:31:in `password'
   # ./spec/trocla_spec.rb:22:in `block (5 levels) in '
  
2) Trocla password x509 password format should return the same hashed for 
the x509 format on multiple invocations
   Failure/Error: 
(round1=@trocla.password('some_test',format,format_options[format])).should_not 
be_empty
   RuntimeError:
 Self-signed certificate /CN=test creation failed: wrong argument 
(OpenSSL::X509::Certificate)! (Expected kind of OpenSSL::X509::Name)
   # ./lib/trocla/formats/x509.rb:66:in `rescue in format'
   # ./lib/trocla/formats/x509.rb:61:in `format'
   # ./lib/trocla.rb:31:in `password'
   # ./spec/trocla_spec.rb:26:in `block (5 levels) in '
  
  Deprecation Warnings:
  
  Using `should` from rspec-expectations' old `:should` syntax without 
explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or 
explicitly enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = 
:should }` instead. Called from 
/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2/spec/trocla/encryptions/ssl_spec.rb:24:in
 `block (3 levels) in '.
  
  
  If you need more of the backtrace for any of these deprecations to
  identify where to make the necessary changes, you can configure
  `config.raise_errors_for_deprecations!`, and it will turn the
  deprecation warnings into errors, giving you the full backtrace.
  
  1 deprecation warning total
  
  Finished in 1.24 seconds (files took 0.12851 seconds to load)
  63 examples, 2 failures
  
  Failed examples:
  
  rspec './spec/trocla_spec.rb[1:1:10:1]' # Trocla password x509 password 
format should return a password hashed in the x509 format
  rspec './spec/trocla_spec.rb[1:1:10:2]' # Trocla password x509 password 
format should return the same hashed for the x509 format on multiple invocations
  
  /usr/bin/ruby2.3 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb failed
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2/debian/trocla 
returned exit code 1
  debian/rules:21: recipe for target 'override_dh_auto_install' failed
  make[1]: *** [override_dh_auto_install] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2'
  debian/rules:18: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

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

Bug#816256: ruby-versionomy: FTBFS: `require': cannot load such file -- blockenspiel/unmixer_mri (LoadError)

[Chris Lamb]

Source: ruby-versionomy
Version: 0.4.4-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,

ruby-versionomy fails to build from source in unstable/amd64:

  [..]
  
  
RUBYLIB=/home/lamby/temp/cdt.20160229080839.yx3VvECwEf/ruby-versionomy-0.4.4/debian/ruby-versionomy/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-versionomy/usr/share/rubygems-integration/all:/home/lamby/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ \{\ 
\|f\|\ require\ f\ \}
  /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': 
cannot load such file -- blockenspiel/unmixer_mri (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/vendor_ruby/blockenspiel.rb:48:in `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160229080839.yx3VvECwEf/ruby-versionomy-0.4.4/debian/ruby-versionomy/usr/lib/ruby/vendor_ruby/versionomy.rb:37:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160229080839.yx3VvECwEf/ruby-versionomy-0.4.4/test/tc_custom_format.rb:39:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from -e:1:in `block in '
from -e:1:in `each'
from -e:1:in `'
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080839.yx3VvECwEf/ruby-versionomy-0.4.4/debian/ruby-versionomy
 returned exit code 1
  debian/rules:19: recipe for target 'override_dh_auto_install' failed
  make[1]: *** [override_dh_auto_install] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160229080839.yx3VvECwEf/ruby-versionomy-0.4.4'
  debian/rules:15: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

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


ruby-versionomy.0.4.4-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816257: trocla: FTBFS: Self-signed certificate /CN=test creation failed: wrong argument

[Chris Lamb]

Source: trocla
Version: 0.1.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,

trocla fails to build from source in unstable/amd64:

  [..]

  Failures:
  
1) Trocla password x509 password format should return a password hashed in 
the x509 format
   Failure/Error: 
@trocla.password('some_test',format,format_options[format]).should_not be_empty
   RuntimeError:
 Self-signed certificate /CN=test creation failed: wrong argument 
(OpenSSL::X509::Certificate)! (Expected kind of OpenSSL::X509::Name)
   # ./lib/trocla/formats/x509.rb:66:in `rescue in format'
   # ./lib/trocla/formats/x509.rb:61:in `format'
   # ./lib/trocla.rb:31:in `password'
   # ./spec/trocla_spec.rb:22:in `block (5 levels) in '
  
2) Trocla password x509 password format should return the same hashed for 
the x509 format on multiple invocations
   Failure/Error: 
(round1=@trocla.password('some_test',format,format_options[format])).should_not 
be_empty
   RuntimeError:
 Self-signed certificate /CN=test creation failed: wrong argument 
(OpenSSL::X509::Certificate)! (Expected kind of OpenSSL::X509::Name)
   # ./lib/trocla/formats/x509.rb:66:in `rescue in format'
   # ./lib/trocla/formats/x509.rb:61:in `format'
   # ./lib/trocla.rb:31:in `password'
   # ./spec/trocla_spec.rb:26:in `block (5 levels) in '
  
  Deprecation Warnings:
  
  Using `should` from rspec-expectations' old `:should` syntax without 
explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or 
explicitly enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = 
:should }` instead. Called from 
/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2/spec/trocla/encryptions/ssl_spec.rb:24:in
 `block (3 levels) in '.
  
  
  If you need more of the backtrace for any of these deprecations to
  identify where to make the necessary changes, you can configure
  `config.raise_errors_for_deprecations!`, and it will turn the
  deprecation warnings into errors, giving you the full backtrace.
  
  1 deprecation warning total
  
  Finished in 1.24 seconds (files took 0.12851 seconds to load)
  63 examples, 2 failures
  
  Failed examples:
  
  rspec './spec/trocla_spec.rb[1:1:10:1]' # Trocla password x509 password 
format should return a password hashed in the x509 format
  rspec './spec/trocla_spec.rb[1:1:10:2]' # Trocla password x509 password 
format should return the same hashed for the x509 format on multiple invocations
  
  /usr/bin/ruby2.3 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb failed
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2/debian/trocla 
returned exit code 1
  debian/rules:21: recipe for target 'override_dh_auto_install' failed
  make[1]: *** [override_dh_auto_install] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160229080919.Psq5c9dxod/trocla-0.1.2'
  debian/rules:18: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

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


trocla.0.1.2-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816254: ruby-packetfu: FTBFS: expected NameError with "uninitialized constant PacketFu::FakePacket", got #

[Chris Lamb]

Source: ruby-packetfu
Version: 1.1.11-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,

ruby-packetfu fails to build from source in unstable/amd64:

  [..]
  
  
RUBYLIB=/home/lamby/temp/cdt.20160229080748.jorFXxpWp0/ruby-packetfu-1.1.11/debian/ruby-packetfu/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-packetfu/usr/share/rubygems-integration/all:/home/lamby/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 debian/ruby-tests.rb
  /usr/bin/ruby2.3 -rrspec/its /usr/bin/rspec --pattern 
spec/\*\*\{,/\*/\*\*\}/\*_spec.rb
  rspec 3.3.2
  
...F
  
  Failures:
  
1) PacketFu protocol requires should have some protocols defined
   Failure/Error: expect { PacketFu::FakePacket }.to raise_error(NameError, 
"uninitialized constant PacketFu::FakePacket")
 expected NameError with "uninitialized constant PacketFu::FakePacket", 
got # with backtrace:
   # ./spec/packetfu_spec.rb:52:in `block (3 levels) in '
   # ./spec/packetfu_spec.rb:52:in `block (2 levels) in '
   # ./spec/packetfu_spec.rb:52:in `block (2 levels) in '
  
  Finished in 0.27801 seconds (files took 0.19639 seconds to load)
  248 examples, 1 failure
  
  Failed examples:
  
  rspec ./spec/packetfu_spec.rb:48 # PacketFu protocol requires should have 
some protocols defined
  
  /usr/bin/ruby2.3 -rrspec/its /usr/bin/rspec --pattern 
spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080748.jorFXxpWp0/ruby-packetfu-1.1.11/debian/ruby-packetfu
 returned exit code 1
  debian/rules:4: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

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


ruby-packetfu.1.1.11-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816255: ruby-tinder: FTBFS: `to_specs': Could not find 'http_parser.rb' (~> 0.6.0) among 29 total gem(s) (Gem::LoadError)

[Chris Lamb]

Source: ruby-tinder
Version: 1.10.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,

ruby-tinder fails to build from source in unstable/amd64:

  [..]
  
  
GEM_PATH=debian/ruby-tinder/usr/share/rubygems-integration/all:/home/lamby/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 -e gem\ \"tinder\"
  /usr/lib/ruby/2.3.0/rubygems/dependency.rb:319:in `to_specs': Could not find 
'http_parser.rb' (~> 0.6.0) among 29 total gem(s) (Gem::LoadError)
  Checked in 
'GEM_PATH=debian/ruby-tinder/usr/share/rubygems-integration/all:/home/lamby/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all',
 execute `gem env` for more information
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1438:in `block in 
activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in `each'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in 
`activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1409:in `activate'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1441:in `block in 
activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in `each'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in 
`activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1409:in `activate'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in 
`synchronize'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'
  bigdecimal (1.2.6)
  did_you_mean (1.0.0)
  diff-lcs (1.2.5)
  eventmachine (1.0.7)
  fakeweb (1.3.0)
  faraday (0.9.2)
  faraday_middleware (0.10.0)
  hashie (3.4.2)
  http_parser.rb (0.6.0)
  io-console (0.4.3)
  json (1.8.3, 1.8.1)
  mime-types (2.6.1)
  minitest (5.8.4)
  multi_json (1.11.2)
  multipart-post (1.2.0)
  net-telnet (0.1.1)
  power_assert (0.2.6)
  psych (2.0.8)
  rake (10.4.2)
  rdoc (4.2.0)
  rspec (3.3.0)
  rspec-core (3.3.2)
  rspec-expectations (3.3.0)
  rspec-mocks (3.3.0)
  rspec-support (3.3.0)
  simple_oauth (0.3.1)
  test-unit (3.1.7)
  thread_order (1.1.0)
  twitter-stream (0.1.16)
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160229080812.AyOcHkvQaR/ruby-tinder-1.10.1/debian/ruby-tinder
 returned exit code 1
  debian/rules:18: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

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


ruby-tinder.1.10.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816259: RM: sonic-pi [ppc64el] -- ROM; broken binary package built by mistake

[Petter Reinholdtsen]

Package: ftp.debian.org
Severity: normal
 
The new sonic-pi package require supercollider to work, but this was not
reflected in the initial build dependencies, causing a broken binary to
be build on ppc64el.  Please remove the broken binary package for
sonic-pi on ppc64el from unstable, to allow the package to enter
testing.

Once supercollider is built on ppc64el, the missing architecture support
should solve itself.  But it should not block sonic-pi from becoming
part of the next release.

-- 
Happy hacking
Petter Reinholdtsen

Bug#816262: RFS: python-hdf5storage/0.1.13-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "python-hdf5storage"

* Package name: python-hdf5storage
  Version : 0.1.13-1
  Upstream Author : Freja Nordsiek 
* URL : https://github.com/frejanordsiek/hdf5storage
* License : BSD
  Section : python

It builds those binary packages:

  python-hdf5storage - high-level utilities to read from and write to 
HDF5 (Python 2)

  python-hdf5storage-doc - documentation for hdf5storage
  python3-hdf5storage - high-level utilities to read from and write to 
HDF5 (Python 3)


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


  http://mentors.debian.net/package/python-hdf5storage

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

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-hdf5storage/python-hdf5storage_0.1.13-1.dsc


Successful build logs on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/python-hdf5storage/0.1.13-1/buildlog

http://debomatic-i386.debian.net/distribution#unstable/python-hdf5storage/0.1.13-1/buildlog

http://debomatic-armhf.debian.net/distribution#unstable/python-hdf5storage/0.1.13-1/buildlog

Changes since the last upload:

  * New upstream release.

Additional information:

  * This new release includes a fix for the runtime error encountered 
in the testsuite during reproducibility testing on armhf.


Regards,
Ghislain Vaillant

Bug#813287: avro-java: FTBFS: Plugin com.thoughtworks.paranamer:paranamer-maven-plugin:2.8 or one of its dependencies could not be resolved

[Emmanuel Bourg]

Le 31/01/2016 09:06, Chris Lamb a écrit :

> [ERROR] [...] the artifact org.codehaus.plexus:plexus-utils:jar:1.1 has not 
> been downloaded from it before.

This isn't the first time we see this error since the switch to Maven 3
and I've just figured out why it happens: Maven 3 injects a dependency
on plexus-utils 1.1 to any plugin (here paranamer-maven-plugin) that
doesn't declare a dependency on it already. And since we don't have the
version 1.1 in Debian the resolution fails.

The class responsible for this injection is PlexusUtilsInjector [1] in
the Maven project, we just have to redefine it to use plexus-utils 2.x
instead of 1.1 to fix this class of issues. I'll do that in the next
update of maven-debian-helper.

Emmanuel Bourg

[1]
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusUtilsInjector.java

Bug#814912: libaio1 0.3.110-1 libaio.so.1: undefined reference to `__stack_chk_fail@GLIBC_2.4'

[Guillem Jover]

Control: tags -1 moreinfo unreproducible

Hi!

On Tue, 2016-02-16 at 15:22:57 +0100, Stanislav Davydov wrote:
> Package: libaio1
> Version: 0.3.110-1
> Severity: important
> Tags: upstream

> During installation of Oracle Webtier 11.1.1.9.0 I got error:
> 
> gcc -o /home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/wrc 
> -L/home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/ 
> -L/home/ezwimadm/Middleware/Oracle_WT1/lib/ 
> -L/home/ezwimadm/Middleware/Oracle_WT
> 1/lib/stubs/   /home/ezwimadm/Middleware/Oracle_WT1/lib/s0main.o 
> /home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/sskeced.o 
> /home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/skecpt.o -lwrc11 -lc
> lntsh  `cat /home/ezwimadm/Middleware/Oracle_WT1/lib/ldflags`-lncrypt11 
> -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat 
> /home/ezwimadm/Middleware/Oracle_WT1/lib/ldflags`-lncrypt11 -lnsg
> r11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lztkg11 -lclient11 
> -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lmm -lsnls11 -lnls11  -lcore11 
> -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -l
> xml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat 
> /home/ezwimadm/Middleware/Oracle_WT1/lib/ldflags`-lncrypt11 -lnsgr11 
> -lnzjs11 -ln11 -lnl11 -lnro11 `cat /home/ezwimadm/Mid
> dleware/Oracle_WT1/lib/ldflags`-lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 
> -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11   -lsnls11 -lnls11  
> -lcore11 -lsnls11 -lnls11 -lcore11 -lsn
> ls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 
> -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11  
> -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -
> lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11   `cat 
> /home/ezwimadm/Middleware/Oracle_WT1/lib/sysliblist` 
> -Wl,-rpath,/home/ezwimadm/Middleware/Oracle_WT1/lib -lm`ca
> t /home/ezwimadm/Middleware/Oracle_WT1/lib/sysliblist` -ldl -lm   
> -L/home/ezwimadm/Middleware/Oracle_WT1/lib -lpthread
> //lib/x86_64-linux-gnu/libaio.so.1: undefined reference to 
> `__stack_chk_fail@GLIBC_2.4'
> collect2: error: ld returned 1 exit status
> /home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/ins_rdbms.mk:1012: recipe for 
> target '/home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/wrc' failed
> make: *** [/home/ezwimadm/Middleware/Oracle_WT1/rdbms/lib/wrc] Error 1
> /usr/bin/make -f ins_rdbms.mk client_sharedlib svr_tool 
> ORACLE_HOME=/home/ezwimadm/Middleware/Oracle_WT1//home/ezwimadm/Middleware/Oracle_WT1/bin/genclntsh
> /usr/bin/ld: cannot find crti.o: No such file or directory
> /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
> collect2: error: ld returned 1 exit status
> genclntsh: Failed to link libclntsh.so.11.1

I'm assuming this stuff includes its own libc? In which case it would
be a problem in the Oracle environment. Otherwise you'll need to give
more information.

> After I have downgrade libaio1 and libaio-dev from 0.3.110-1 to
> 0.3.109-3 (taked from Wheezy) it installs and works correctly.

Thanks,
Guillem

Bug#749833: scilab: Scilab include non-free codes

[Maximiliano Curia]

Control: block 816260 by 749833

Hi,

As a request from the release team I have removed the dependency of scilab 
from cantor, I'm adding this block to the corresponding bug in cantor as way 
to remember to reenable the backend once the problem is fixed.

Also, since there is a patch available upstream that's being stale for review 
for sometime now, wouldn't it be feasible to upload a patched scilab to 
experimental as a way to gather some testers/reviewers?

Happy hacking,
-- 
"Politicians and diapers have one thing in common. They should both be changed
regularly, and for the same reason." ― José Maria de Eça de Queiroz
Saludos /\/\ /\ >< `/

Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

[Sergey B Kirpichev]

Package: php-geoip
Version: 1.1.0-3
Severity: serious
Justification: fails to build from source
Tags: sid stretch
Usertags: ftbfs

Tail of build log:
  dh_auto_build --builddirectory=/«PKGBUILDDIR»/build-$v 
--sourcedirectory=geoip-1.1.0; \
done
make -j1
make[2]: Entering directory '/«PKGBUILDDIR»/build-7.0'
/bin/bash /«PKGBUILDDIR»/build-7.0/libtool --mode=compile cc  -I. 
-I/«PKGBUILDDIR»/geoip-1.1.0 -DPHP_ATOM_INC -I/«PKGBUILDDIR»/build-7.0/include 
-I/«PKGBUILDDIR»/build-7.0/main -I/«PKGBUILDDIR»/geoip-1.1.0 
-I/usr/include/php/20151012 -I/usr/include/php/20151012/main 
-I/usr/include/php/20151012/TSRM -I/usr/include/php/20151012/Zend 
-I/usr/include/php/20151012/ext -I/usr/include/php/20151012/ext/date/lib  
-Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security   -c 
/«PKGBUILDDIR»/geoip-1.1.0/geoip.c -o geoip.lo 
/bin/bash: /«PKGBUILDDIR»/build-7.0/libtool: No such file or directory
Makefile:194: recipe for target 'geoip.lo' failed
make[2]: *** [geoip.lo] Error 127
make[2]: Leaving directory '/«PKGBUILDDIR»/build-7.0'
dh_auto_build: make -j1 returned exit code 2
debian/rules:26: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:12: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2

Bug#816260: cantor: Please re-enable the scilab backend

[Maximiliano Curia]

Package: cantor
Version: 4:15.12.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The latest version of cantor uploaded to unstable disables the scilab backend 
due to #749833 and the request from the release team to avoid blocking serious 
bugs with the meta-kde packages (meta-kde depends on cantor, so the removal 
from testing of scilab would, at least, leave some uninstallable pacakges that 
meta-kde depends upon).

I'm adding this bug a as reminder to re-enable the backend once the bug in 
scilab is fixed.

Happy hacking,

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

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

Versions of packages cantor depends on:
ii  kde-runtime 4:15.08.3-1+b1
ii  libc6   2.21-9
ii  libkdecore5 4:4.14.14-1+b1
ii  libkdeui5   4:4.14.14-1+b1
ii  libkio5 4:4.14.14-1+b1
ii  libknewstuff3-4 4:4.14.14-1+b1
ii  libkparts4  4:4.14.14-1+b1
ii  libktexteditor4 4:4.14.14-1+b1
ii  libqt4-xml  4:4.8.7+dfsg-6
ii  libqt4-xmlpatterns  4:4.8.7+dfsg-6
ii  libqtcore4  4:4.8.7+dfsg-6
ii  libqtgui4   4:4.8.7+dfsg-6
ii  libspectre1 0.2.7-3
ii  libstdc++6  5.3.1-8

Versions of packages cantor recommends:
pn  cantor-backend-kalgebra  
ii  texlive-binaries 2015.20150524.37493-7+b1
ii  texlive-latex-base   2015.20160215-1

Versions of packages cantor suggests:
pn  cantor-backend-maxima 
pn  cantor-backend-octave 
pn  cantor-backend-python2
pn  cantor-backend-qalculate  
pn  cantor-backend-r  
pn  cantor-backend-sage   
pn  cantor-backend-scilab 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW0/8uAAoJEMcZdpmymyMq12AP/2hHbh4mvQcNg+1G3EdVWq/o
gFUs94zMhx7nyiZFM7vznHLWwkn22+CDBmscLpTBM4wCsu/eHahno5yysWqouuTM
SpEJR9x2jqU6/iATAj0zsYi/A/0wSvCUjjtXFFCxZGedptM2uvyelgKEu7BpsWRl
EaRQ8Ig5zgbfCFvAD2WQKkCm+40MTUrSw5yfSAxz2fmOJKZYIZf8ic1AT4feskyS
E/xtpSDPoP/jksF3Wcq+CXBujdHmniI8NYje/gkjceIUaiY6VvvbWVf9b0QduPQK
I5rZCUtS8IFPnk5fBkYoe5WIsDTQMZxe1Mx3BxzO9/Hl0/YS3O6oR2YRO6dxCXiI
nPRLP0oLAayx95CrHlQMLavF1gz0glUR5aud9L3zjLlnbHqR8ck34pqAACjgYv9h
yk+yUxWlIEVmZmBxKVAaM8sT0BHdvpy3aeg8SwHLy+evaZvTCX1kCaW7Q3pAak+M
BfBKk0InkgOZ9TaT/oXIwyrSS5AgyYpvyp7/nmI1vjRSwx0NV53oZAKp5A6TrxVh
CLU07gNlNuGABdia1tx9dZf3eVMOj8KaA7RadqFgugZcyhzalZrOdyOp7XQNB4fS
uJ5fOsTzmKMEEuDbBrQr7emIOsNiC0StPNvBjBZDK/WfVBodX773kQ4uP+FTudOm
PaEmjo9fzKn6r0Nqz42/
=G+7L
-END PGP SIGNATURE-

Bug#803320: Pending fixes for bugs in the golang-github-jacobsa-ogletest package

[pkg-go-maintainers]

tag 803320 + pending
thanks

Some bugs in the golang-github-jacobsa-ogletest package are closed in
revision 6b4d5dbe20352c9a65b621d9b63f1d4ee401678f in branch 'master'
by Dmitry Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-ogletest.git/commit/?id=6b4d5db

Commit message:

patchworks (Closes: #803320).

Bug#816261: RFS: django-prometheus/1.0.6-1

[Christopher Baines]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for "django-prometheus"

 * Package name: django-prometheus
   Version : 1.0.6-1
   Upstream Author : Uriel Corfa 
 * URL : https://github.com/korfuri/django-prometheus
 * License : Apache
   Section : python

It builds those binary packages:

  python-django-prometheus - Django middlewares to enable monitoring
with Prometheus (Python 2)
  python3-django-prometheus - Django middlewares to enable monitoring
with Prometheus (Python 3)

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

  http://mentors.debian.net/package/django-prometheus

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

  dget -x
http://mentors.debian.net/debian/pool/main/d/django-prometheus/django-prometheus_1.0.6-1.dsc

It is also available on git.debian.org:


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

Thanks,

Chris



signature.asc
Description: OpenPGP digital signature

Bug#784328: FVWM: fvwm hotkey problem inside vnc

[Claude Krantz]

Dear Thomas,

As far as I understand Hendriks analysis, there is indeed nothing upstream FVWM 
can do about this. He included the fvwm mailing list before his analysis showed 
that the bug is introduced in Debian.


Hendriks analysis indeed suggests to me that, until all X servers shipped with 
Debian support XKEYBOARD, the packaged fvwm should not silently assume that this 
extension is present. Optimally, it should dynamically detect at startup which 
functions are offered by X and then use them accordingly. More simply - indeed - 
it could just stick to the deprecated functions for now, which seem to be 
(still) supported by all X servers.


Thanks for pointing out that one can effectively disable the patch also by an 
undefine. While this may be technically interesting for the package maintainers, 
suggesting that Debian useres should routinely recompile their software on need 
is really beyond the scope of a binary distribution.


@Hendrik: Many thanks for your detailed analysis.

Yours,

Claude




--
---
Dr. Claude Krantz

Für das
Max-Planck-Institut fuer Kernphysik
Saupfercheckweg 1
D-69117 Heidelberg

Email: claude.kra...@mpi-hd.mpg.de

Bug#816263: python-positional: FTBFS: /bin/sh: 7: subunit2pyunit: not found

[Chris Lamb]

Source: python-positional
Version: 1.0.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-positional fails to build from source in unstable/amd64:

  [..]

  ===> Running tests
  set -e ; set -x ; for i in 2.7 3.5 ; do \
PYMAJOR=`echo $i | cut -d'.' -f1` ; \
echo "===> Testing with python$i (python$PYMAJOR)" ; \
rm -rf .testrepository ; \
testr-python$PYMAJOR init ; \
TEMP_REZ=`mktemp -t` ; \

PYTHONPATH=/home/lamby/temp/cdt.20160229085450.DFkIoWaaqj/python-positional-1.0.1
 PYTHON=python$i testr-python$PYMAJOR run --subunit | tee $TEMP_REZ | 
subunit2pyunit ; \
cat $TEMP_REZ | subunit-filter -s --no-passthrough | subunit-stats ; \
rm -f $TEMP_REZ ; \
testr-python$PYMAJOR slowest ; \
  done
  + echo 2.7
  + cut -d. -f1
  + PYMAJOR=2
  + echo ===> Testing with python2.7 (python2)
  ===> Testing with python2.7 (python2)
  + rm -rf .testrepository
  + testr-python2 init
  + mktemp -t
  + TEMP_REZ=/tmp/tmp.wenG0QYkcj
  + 
PYTHONPATH=/home/lamby/temp/cdt.20160229085450.DFkIoWaaqj/python-positional-1.0.1
 PYTHON=python2.7 testr-python2 run --subunit
  + tee /tmp/tmp.wenG0QYkcj
  + subunit2pyunit
  /bin/sh: 7: subunit2pyunit: not found
  [Errno 32] Broken pipe
  debian/rules:27: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 127
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160229085450.DFkIoWaaqj/python-positional-1.0.1'
  debian/rules:12: 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
   `-


python-positional.1.0.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816264: sbsigntool: FTBFS: /bin/bash: openssl: command not found

[Chris Lamb]

Source: sbsigntool
Version: 0.6-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,

sbsigntool fails to build from source in unstable/amd64:

  [..]

  Making check in tests
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160229085535.6P2KGfhuJu/sbsigntool-0.6/tests'
  make  test-x86_64.pecoff test-i386.pecoff test-wrapper.sh \
private-key.rsa public-cert.pem
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160229085535.6P2KGfhuJu/sbsigntool-0.6/tests'
  gcc -m64 -Wdate-time -D_FORTIFY_SOURCE=2  -c -o test-x86_64.o test.S
  gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  
-nostdlib -T ./test-x86_64.lds -o test-x86_64.elf test-x86_64.o
  objcopy -j .text -j .sdata -j .data \
-j .dynamic -j .dynsym  -j .rel \
-j .rela -j .reloc \
--target=efi-app-x86-64 test-x86_64.elf test-x86_64.pecoff
  strip test-x86_64.pecoff
  gcc -m32 -Wdate-time -D_FORTIFY_SOURCE=2  -c -o test-i386.o test.S
  gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  
-nostdlib -T ./test-i386.lds -o test-i386.elf test-i386.o
  objcopy -j .text -j .sdata -j .data \
-j .dynamic -j .dynsym  -j .rel \
-j .rela -j .reloc \
--target=efi-app-i386 test-i386.elf test-i386.pecoff
  strip test-i386.pecoff
  make[3]: Nothing to be done for 'test-wrapper.sh'.
  openssl genrsa -out private-key.rsa 2048
  /bin/bash: openssl: command not found
  Makefile:948: recipe for target 'private-key.rsa' failed
  make[3]: *** [private-key.rsa] Error 127
  rm test-x86_64.elf test-i386.o test-i386.elf test-x86_64.o
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160229085535.6P2KGfhuJu/sbsigntool-0.6/tests'
  Makefile:797: recipe for target 'check-am' failed
  make[2]: *** [check-am] Error 2
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160229085535.6P2KGfhuJu/sbsigntool-0.6/tests'
  Makefile:366: recipe for target 'check-recursive' failed
  make[1]: *** [check-recursive] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160229085535.6P2KGfhuJu/sbsigntool-0.6'
  dh_auto_test: make -j1 check returned exit code 2
  debian/rules:8: 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
   `-


sbsigntool.0.6-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#815793: IPv6 code ignores unsolicited router advertisements

[Marc Haber]

Hi Martin,

On Sun, Feb 28, 2016 at 10:20:22PM +0100, Martin Pitt wrote:
> Marc Haber [2016-02-24 15:01 +0100]:
> > systemd 229 seems to ignore unsolicited router advertisements. This
> > breaks, for example, prefix changes. And it prevents the self-healing
> > characteristics of lost router solicitations.
> 
> Can you please report this and also #815884 upstream? I don't know
> much about IPv6 routing I'm afraid, so I think you are in a better
> position to explain/discuss this with Tom. Some regressions are
> already covered by https://github.com/systemd/systemd/issues/2572
> but not these  two.

I think that it would not be productive if I tried communicating with
systemd upstream. We both consider each other toxic, and I'd rather
not mess with my sanity trying to be nice to a .

I lost my temper on systemd-devel in december and cannot write there
any more due to policy decision of the list owner. I doubt that a bug
report filed by me would get any helpful upstream attention.

So, I regret that in this case my answer is thanks, but no thanks.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#816266: RFS: python-qtawesome/0.3.0-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-qtawesome"

* Package name: python-qtawesome
  Version : 0.3.0-1
  Upstream Author : The Spyder Development Team
* URL : https://github.com/spyder-ide/qtawesome
* License : Expat
  Section : python

It builds those binary packages:

  python-qtawesome - iconic fonts in PyQt and PySide applications 
(Python 2)

  python-qtawesome-common - common files for QtAwesome
  python-qtawesome-doc - documentation and examples for QtAwesome
  python3-qtawesome - iconic fonts in PyQt and PySide applications 
(Python 3)


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


  http://mentors.debian.net/package/python-qtawesome

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-qtawesome/python-qtawesome_0.3.0-1.dsc


Changes since the last upload:

  * Initial release. (Closes: #814718)

Additional information:

  * The -common package contains 2 fonts, one of which is not available 
for Debian (elusive-iconfont, SIL OFL 1.1). The other one (fontawesome)

is symlinked from its corresponding package.
  * The package can be tested by installing one of the Python binary
packages, the -doc package and running the example.py script under the
following location: /usr/share/python-qtawesome-doc/examples.

Regards,
Ghislain Vaillant

Bug#738704: [Debian-ha-maintainers] Bug#738704: Bug#738704: closed by wf...@niif.hu (Ferenc Wágner) (Re: pacemaker: Segfault in libhbclient.so.1.0.0)

[Christoph Berg]

Re: Ferenc Wágner 2016-02-29 <87twkrydx9@lant.ki.iif.hu>
> Philipp Marek  writes:
> 
> > I'd just like to know why Heartbeat support isn't included anymore... yes, 
> > it won't do OCFS2 or GFS2, but in exchange it has been rock-solid for me.
> 
> Ah, I see.  No principal reason, just lack of manpower.  I'll be happy
> if we can properly maintain a single stack; we're not there yet.  What's
> the upstream status of Heartbeat, anyway?  Internet suggest it's
> deprecated and no longer developed, but maintained by Linbit.  Can you
> provide an update on that?  Also, if you can bring Heartbeat expertise
> into the Debian HA team, I've got nothing against compiling support into
> Pacemaker.

3.0.5 was released at least half a decade ago, but 3.0.6 is from last
autumn. I uploaded that a few weeks ago in the upload I did to get all
the references to the no-longer-built packages dropped.

I have no idea though if that was just a one-shot get-pending-changes-out
release, or if they are really maintaining it for the future.

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

Bug#816265: [Pkg-php-pecl] Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

[Ondřej Surý]

What versions of php-all-dev and php7.0-dev are installed at your
machine? Since the libtool 2.4.6-0.1 compatibility was fixed couple
releases back.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Mon, Feb 29, 2016, at 10:07, Sergey B Kirpichev wrote:
> Package: php-geoip
> Version: 1.1.0-3
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> Usertags: ftbfs
> 
> Tail of build log:
>   dh_auto_build --builddirectory=/«PKGBUILDDIR»/build-$v
>   --sourcedirectory=geoip-1.1.0; \
> done
> make -j1
> make[2]: Entering directory '/«PKGBUILDDIR»/build-7.0'
> /bin/bash /«PKGBUILDDIR»/build-7.0/libtool --mode=compile cc  -I.
> -I/«PKGBUILDDIR»/geoip-1.1.0 -DPHP_ATOM_INC
> -I/«PKGBUILDDIR»/build-7.0/include -I/«PKGBUILDDIR»/build-7.0/main
> -I/«PKGBUILDDIR»/geoip-1.1.0 -I/usr/include/php/20151012
> -I/usr/include/php/20151012/main -I/usr/include/php/20151012/TSRM
> -I/usr/include/php/20151012/Zend -I/usr/include/php/20151012/ext
> -I/usr/include/php/20151012/ext/date/lib  -Wdate-time -D_FORTIFY_SOURCE=2
> -DHAVE_CONFIG_H  -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security   -c /«PKGBUILDDIR»/geoip-1.1.0/geoip.c -o
> geoip.lo 
> /bin/bash: /«PKGBUILDDIR»/build-7.0/libtool: No such file or directory
> Makefile:194: recipe for target 'geoip.lo' failed
> make[2]: *** [geoip.lo] Error 127
> make[2]: Leaving directory '/«PKGBUILDDIR»/build-7.0'
> dh_auto_build: make -j1 returned exit code 2
> debian/rules:26: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory '/«PKGBUILDDIR»'
> debian/rules:12: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> 
> ___
> Pkg-php-pecl mailing list
> pkg-php-p...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pecl

___
Pkg-php-pecl mailing list
pkg-php-p...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pecl

Bug#816216: Reassigning to a more suitable package.

[Lisandro Damián Nicanor Pérez Meyer]

reassign 816216 plasma-desktop
thanks

Reassigning to a more suitable package.

-- 
Quote me as saying I was mis-quoted.
 -- Groucho Marx

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


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

Bug#816280: Binary incompatibility between debugperl and perl

[Dominic Hargreaves]

Control: forwarded -1 https://rt.perl.org/Public/Bug/Display.html?id=127212
Control: tags -1 + fixed-upstream confirmed

On Mon, Feb 29, 2016 at 12:53:33PM +0100, Nick Wellnhofer wrote:
> Package: perl-debug
> Version: 5.20.2-2
> 
> The layout of interpreter variables is different in the debug and normal
> version of the perl binary. This means that XS extensions might read from or
> write to the wrong area of the interpreter variable struct, causing crashes
> and other strange behavior.
> 
> Here's an example, originally reported by me at
> https://rt.cpan.org/Public/Bug/Display.html?id=111211
> 
> $ PERL_DESTRUCT_LEVEL=2 debugperl -MList::Util=shuffle -e shuffle
> Segmentation fault
> 
> This segfaults because `shuffle` calls `seedDrand01` which writes to the
> `random_state` interpreter variable. If you have a look at `intrpvar.h` in
> the Perl source, you'll see that `random_state` is at the very end with some
> variables before that are only enabled in debug builds. This causes
> `random_state` to be at a different offset in the debug build. The XS module
> `List::Util` uses the non-debug offset, so any writes to `random_state`
> cause memory corruption.
> 
> I'd propose that all interpreter variables that are only used in the debug
> build should be moved to very end in `intrpvar.h`.

This was discovered as part of the investigation into 
 (which is
not quite the same bug) and was fixed upstream. This fix should be in
5.24 which should be in stretch. However, the fix by its nature breaks
binary compatibility, so it will unfortunately not be possible to apply
it to a stable release.

Cheers,
Dominic.

Bug#816271: gawk: It should not be possible to segfault gawk

[Steve Kemp]

Package: gawk
Version: 1:4.1.1+dfsg-1
Severity: important

Dear Maintainer,

While I appreciate that passing untrusted code to gawk is not a common thing to 
do, I do not believe that it should be possible to trigger a segfault though.

The following "program" will crash gawk though:

 $ echo | gawk  '{ print( @olower( "steve" ) ) }'
 gawk: cmd. line:1: (FILENAME=- FNR=1) fatal error: internal error: segfault
 Aborted

The specific problem here is the error-handling in `interpret.h`, which 
contains the following code:

if (f == NULL || f->type != Node_func) {
if (f->type == Node_ext_func || f->type == Node_old_ext_func)
fatal(_("cannot (yet) call extension functions 
indirectly"));
else
fatal(_("function called indirectly through `%s' does not 
exist"),
pc->func_name); 
}
pc->func_body = f; /* save for next call */

The first condition says:

* If f is NULL
* OR f->type != ..

Assume f is NULL, then the very next line reads:

if ( f->type ==  )

Which is an immediate segfault!  One possible patch would be to change this:

   if (f->type == Node_ext_func || f->type == Node_old_ext_func)

To the following, to explicitly look for a non-NULL f:

   if ( f && (f->type == Node_ext_func || f->type == 
Node_old_ext_func) )



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

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

Versions of packages gawk depends on:
ii  libc6 2.19-18+deb8u3
ii  libgmp10  2:6.0.0+dfsg-6
ii  libmpfr4  3.1.2-2
ii  libreadline6  6.3-8+b3
ii  libsigsegv2   2.10-4+b1

gawk recommends no packages.

Versions of packages gawk suggests:
pn  gawk-doc  

-- no debconf information

Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

[Christian Pernegger]

Package: clamav-freshclam
Version: 0.98.7+dfsg-0+deb8u1
Severity: normal

Hello,

since I've installed clamav-freshclam I get a weekly error message by
e-mail:

> From: Cron Daemon 
> To: r...@buddha.southpark.chp
> Subject: Cron  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
>
> /etc/cron.daily/logrotate:
> error: error running non-shared postrotate script for 
> /var/log/clamav/freshclam.log of '/var/log/clamav/freshclam.log '
> gzip: stdin: file size changed while zipping
> run-parts: /etc/cron.daily/logrotate exited with return code 1

No configuration of clamav or freshclam has been done (yet), apart
from the debconf settings at the bottom of this mail.

Regards,
Christian Pernegger


-- Package-specific info:
--- configuration ---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
AllowSupplementaryGroups false
ConnectTimeout 30
ReceiveTimeout 30
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
SafeBrowsing false
Bytecode true
DatabaseMirror db.at.clamav.net
DatabaseMirror database.clamav.net

--- data dir ---
total 179504
-rw-r--r-- 1 clamav clamav 75879 Feb 10 18:20 bytecode.cvd
drwxr-xr-x 2 clamav clamav  4096 Feb 22 12:52 
clamav-4d66ff37073e2760f1f527f86d9f6696.tmp
-rw-r--r-- 1 clamav clamav 119002112 Feb 28 12:46 daily.cld
-rw-r--r-- 1 clamav clamav  64720632 Feb 10 18:20 main.cvd
-rw--- 1 clamav clamav   104 Feb 29 00:46 mirrors.dat

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

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

Versions of packages clamav-freshclam depends on:
ii  clamav-base0.98.7+dfsg-0+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.26
ii  init-system-helpers1.22
ii  libc6  2.19-18+deb8u3
ii  libclamav6 0.98.7+dfsg-0+deb8u1
ii  libssl1.0.01.0.1k-3+deb8u2
ii  logrotate  3.8.7-1+b1
ii  lsb-base   4.1+Debian13+nmu1
ii  procps 2:3.3.9-9
ii  ucf3.0030
ii  zlib1g 1:1.2.8.dfsg-2+b1

clamav-freshclam recommends no packages.

Versions of packages clamav-freshclam suggests:
pn  apparmor 
pn  clamav-docs  

-- debconf information:
* clamav-freshclam/PrivateMirror:
* clamav-freshclam/LogRotate: true
* clamav-freshclam/Bytecode: true
* clamav-freshclam/NotifyClamd: false
* clamav-freshclam/SafeBrowsing: false
* clamav-freshclam/http_proxy:
  clamav-freshclam/internet_interface:
* clamav-freshclam/local_mirror: db.at.clamav.net (Austria)
  clamav-freshclam/proxy_user:
* clamav-freshclam/update_interval: 2
* clamav-freshclam/autoupdate_freshclam: cron

Bug#816250: qt4-x11: Build Qt4 Multimedia module (QtMobility not in Debian anymore)

[Hendrik Sattler]

Hi, 

you obviously misunderstood the intention of the bug report. It's not about 
reintroducing QtMobility but compiling Qt4 with the modules it provides instead 
of crippling it on purpose.


Am 29. Februar 2016 12:59:11 MEZ, schrieb "Lisandro Damián Nicanor Pérez Meyer" 
:
>severity 816250 wishlist
>tag 816250 wontfix
>thanks
>
>On Monday 29 February 2016 07:51:35 Hendrik Sattler wrote:
>[snip] 
>> Although not very welcome in the past, it was at least possibly to
>use
>> classes from Qt4 Multimedia module in Debian when using QtMobility
>> MultmediaKit. The latter was removed from Debian and the former was
>not
>> built because the latter was in Debian. This obviously changed, so
>the
>> reasoning for not building Qt4 Multimedia module is not valid
>anymore.
>
>
>The mobility stack was removed because it was buggy and had a handful
>of 
>rdeps, which we've got to remove. If it had just a few rdeps then it's
>not 
>that needed, and the same could be said for the multimedia stack.

Etra dependencies are libasound. Wow. Unresolvable. Either you did not even try 
or you must be joking.

>Qt4 is dead upstream in all senses. So a non upstream-supported stack
>is 
>indeed a very good reason to avoid reintroducing it to the archive.

Qt4.8 is still maintained until 5.6 is really released although only minimal. 
And it does not get immediately obsolete even then.

>> And no, not everyone ported to Qt5, yet. :-)
>
>This sounds like a good reason to start with the porting :)

Haha. Is that really the policy of Debian to cripple libraries to enforce extra 
work?

>Sorry, but if you really need the multimedia bits you should really
>consider 
>using Qt5.

Please uncripple Qt4 in Debian! And please read the Qt4 Debian changlog on the 
initial nonsense that lead to this bug report.

HS

Bug#816281: popularity-contest: should allow to collect parts of package configuration

[Dominique Dumont]

Package: popularity-contest
Version: 1.64
Severity: wishlist

Dear Maintainer,

I'm the maintainer of lcdproc package. This package provides drivers
for quite a lot of different HW.

We (lcdproc team and I) don't really know which drivers are used and
which are obsolete.

Looks like we need a popularity-contest for the Driver configured in
/etc/LCDd.conf, so that we'd have data to decide whether to maintain
or drop a driver.

One possibility would be to setup popcon to run a script provided by
package maintainer to gather config data. ( '/etc/popcon.d/lcdproc' ?)
In lcdproc case, the script would be 'grep Driver /etc/LCDd.conf'

The next question are:
- how to formalize the output of the script so popcon can parse it ?
- how to provide package maintainer the statistics of the data
  gathered by the script ?

Thoughts ?

All the best

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 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 popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-128
ii  exim4  4.86-7
ii  exim4-daemon-light [mail-transport-agent]  4.86-7+b2
ii  gnupg  1.4.20-4

Versions of packages popularity-contest suggests:
ii  anacron  2.3-23

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site

[Paul Wise]

On Mon, Feb 29, 2016 at 8:26 PM, The Wanderer wrote:

> So unless wget has a similar feature (which would rather surprise me,
> particularly since I don't see one documented in the man page), I think
> this is an unlikely explanation.

Recent versions of wget support HSTS:

pabs@chianamo ~ $ grep www.debian.org .wget-hsts
pabs@chianamo ~ $ wget -qO /dev/null https://www.debian.org/
pabs@chianamo ~ $ grep www.debian.org .wget-hsts
www.debian.org00145674935715552000

However, get.d.o is redirecting to https now. I think this changed
after the bug was filed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#816284: mpi4py: FTBFS in s390x with openMPI

[Yaroslav Halchenko]

On Mon, 29 Feb 2016, Mattia Rizzolo wrote:

> Source: mpi4py
> Version: 1.3.1+hg20131106-2
> Severity: serious
> Tags: stretch sid
> Control: block 814936 by -1


> Dear maintainer,

> mpi4py has test failures on s390x (only) when rebuilt with mpi-defaults
> using openMPI.
> You can see the full build log on
> https://buildd.debian.org/status/fetch.php?pkg=mpi4py=s390x=1.3.1%2Bhg20131106-2%2Bb4=1455830603

> In ubuntu doko applied a patch to just ignore the tests results in s390x
> only, really unsure if this is correct, but just a data point:
> https://launchpadlibrarian.net/238584899/mpi4py_1.3.1+hg20131106-2ubuntu4_1.3.1+hg20131106-2ubuntu5.diff.gz

Thanks for the buzz -- I will see if I could just upload fresh upstream
release 2.0.0 and may be that one makes it up for s390x ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#710970: Please include extended dh_ucf script

[Hannes von Haugwitz]

Dear Debhelper Maintainers,

On Sun, Jul 14, 2013 at 10:43:48AM +0200, Hannes von Haugwitz wrote:
> Both points make sense. I'll update the script to enable '--three-way'
> by default and change the synopsis to 'dh_ucf [debhelper options] [-n]
> [-- params]'.

Apart from the above two points what else do I have to do to get the
patch accepted?

Best regards

Hannes

Bug#816274: Correct file of pt_BR translation attached

[Marcelo Santana]

Dear maintainer,

Excuse me because I sent you a wrong file before.

Attached you will find the correct file.

King regards,  

-- 
Marcelo Santana (aka msantana) 
4096R/5B76053D: 8E9B 1014 4019 3526 C1C6  B0AC A3C0 DA1E 5B76 053D


pt_BR.po.gz
Description: application/gzip


pgpx_ow_YsdaE.pgp
Description: OpenPGP digital signature

Bug#816269: FTBFS: autogen says "-S" is an illegal option

[Alexandre Detiste]

Package: heroes
Version: 0.21-13
Severity: important



Making all in doc
make[3] : on entre dans le répertoire « /home/tchet/git/heroes/doc »
SOURCE_TEXI=heroes.texi /bin/bash /home/tchet/git/heroes/tools/missing autogen
-L ../src -S ./doc.scm -o 'texi=tmp1.texi' ../src/debugchn.def
/usr/bin/autogen: illegal option -- S
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.18.7
Usage:  autogen [ - [] | --[{=| }] ]... [  ]


current autogen 5.18.7 doesn't know anymore about this option;
It well existed in the ancient vers 5.5.4 I located here:

ftp://ftp.gnu.org/old-gnu/Manuals/autogen-5.5.4/html_chapter/autogen_5.html



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

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

Versions of packages heroes depends on:
ii  heroes-data  1.5-3
ii  libc62.21-9
ii  libsdl-mixer1.2  1.2.12-11+b1
ii  libsdl1.2debian  1.2.15+dfsg1-2

Versions of packages heroes recommends:
ii  heroes-sound-effects  1.0-5
ii  heroes-sound-tracks   1.0-5

heroes suggests no packages.

-- no debconf information

Bug#738704: [Debian-ha-maintainers] Bug#738704: closed by wf...@niif.hu (Ferenc Wágner) (Re: pacemaker: Segfault in libhbclient.so.1.0.0)

[Ferenc Wágner]

Philipp Marek  writes:

> I'd just like to know why Heartbeat support isn't included anymore... yes, 
> it won't do OCFS2 or GFS2, but in exchange it has been rock-solid for me.

Ah, I see.  No principal reason, just lack of manpower.  I'll be happy
if we can properly maintain a single stack; we're not there yet.  What's
the upstream status of Heartbeat, anyway?  Internet suggest it's
deprecated and no longer developed, but maintained by Linbit.  Can you
provide an update on that?  Also, if you can bring Heartbeat expertise
into the Debian HA team, I've got nothing against compiling support into
Pacemaker.
-- 
Thanks,
Feri.

Bug#816273: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings

[Víctor Cuadrado Juan]

Package: wnpp
Severity: wishlist
Owner: "Víctor Cuadrado Juan" 


* Package name: python-jellyfish
  Version : 0.5.2
  Upstream Author : James Turk 
* URL : https://github.com/jamesturk/jellyfish
* License : BSD-2-clause
  Programming Lang: C, Python
  Description : Python library for doing approximate and phonetic matching
of strings

 It uses the following string comparison Algorithms
 (it provides C and Python implementation):
  * Levenshtein Distance
  * Damerau-Levenshtein Distance
  * Jaro Distance
  * Jaro-Winkler Distance
  * Match Rating Approach Comparison
  * Hamming Distance
 .
 Supports the following phonetic encoding:
  * American Soundex
  * Metaphone
  * NYSIIS (New York State Identification and Intelligence System)
  * Match Rating Codex

It is a little library, but does its job.

I intend to maintain this package under the DPMT (which I am part of).

This package is a dependency for beets, #775719, which is lagging some
versions [1].


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775719


-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature

Bug#816274: postfix: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Marcelo Santana]

Package: postfix
Tags: l10n patch
Severity: wishlist

Dear maintainer,

Please, could you update the Brazilian Portuguese translation?

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

*PS: Please I realized again that you forgot to type the question mark
in the new sentence "Update main.cf for daemon_directory change". So now
you have this question and the "Update dynamicmaps.cf for 3.0" with
that typo error. If I'm wrong please let me know so I correct the
translation.

Kind regards,

-- 
Marcelo Santana (aka msantana) 
4096R/5B76053D: 8E9B 1014 4019 3526 C1C6  B0AC A3C0 DA1E 5B76 053D


pt_BR.po.gz
Description: application/gzip


pgpvRI5uGZevw.pgp
Description: OpenPGP digital signature

Bug#816265: [Pkg-php-pecl] Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

[Sergey B Kirpichev]

On Mon, Feb 29, 2016 at 12:44:54PM +0100, Ondřej Surý wrote:
> What versions of php-all-dev and php7.0-dev are installed at your
> machine? Since the libtool 2.4.6-0.1 compatibility was fixed couple
> releases back.

https://buildd.debian.org/status/package.php?p=php-geoip

Bug#816277: gawk: Invalid program crashes the parser

[Steve Kemp]

Package: gawk
Version: 1:4.1.1+dfsg-1
Severity: important

Dear Maintainer,

The following wonderful program causes an immediate segfault in the 
parse-process of gawk:

for (i = ) in foo bar baz

For example:

shelob ~ $ cat t.gawk 
for (i = ) in foo bar baz
shelob ~ $ gawk -f t.gawk
gawk: t.gawk:1: for (i = ) in foo bar baz
gawk: t.gawk:1: ^ syntax error
gawk: t.gawk:1: for (i = ) in foo bar baz
gawk: t.gawk:1:  ^ syntax error
gawk: t.gawk:1: fatal error: internal error: segfault
Aborted

This error comes from a NULL-pointer dereference in awkgram.yy, around line 
1350:

if ($1->lasti->opcode == Op_concat) {
/* multiple (> 2) adjacent strings optimization */


The following patch turns this into an immediate exit, rather than dereference
of $1->lasti (which is NULL):


--- /home/skx/gawk-4.1.1+dfsg/awkgram.y 2014-03-05 06:00:36.0 +0200
+++ awkgram.y   2016-02-29 13:50:43.239771376 +0200
@@ -1343,6 +1343,10 @@
int count = 2;
bool is_simple_var = false;
 
+if ( ( $1 == NULL ) || ($1->lasti == NULL ) ) {
+yyerror("Fatal error");
+YYABORT;
+}
if ($1->lasti->opcode == Op_concat) {
/* multiple (> 2) adjacent strings optimization */
is_simple_var = ($1->lasti->concat_flag & CSVAR);




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

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

Versions of packages gawk depends on:
ii  libc6 2.19-18+deb8u3
ii  libgmp10  2:6.0.0+dfsg-6
ii  libmpfr4  3.1.2-2
ii  libreadline6  6.3-8+b3
ii  libsigsegv2   2.10-4+b1

gawk recommends no packages.

Versions of packages gawk suggests:
pn  gawk-doc  

-- no debconf information

Bug#816250: qt4-x11: Build Qt4 Multimedia module (QtMobility not in Debian anymore)

[Lisandro Damián Nicanor Pérez Meyer]

severity 816250 wishlist
tag 816250 wontfix
thanks

On Monday 29 February 2016 07:51:35 Hendrik Sattler wrote:
[snip] 
> Although not very welcome in the past, it was at least possibly to use
> classes from Qt4 Multimedia module in Debian when using QtMobility
> MultmediaKit. The latter was removed from Debian and the former was not
> built because the latter was in Debian. This obviously changed, so the
> reasoning for not building Qt4 Multimedia module is not valid anymore.


The mobility stack was removed because it was buggy and had a handful of 
rdeps, which we've got to remove. If it had just a few rdeps then it's not 
that needed, and the same could be said for the multimedia stack.

Qt4 is dead upstream in all senses. So a non upstream-supported stack is 
indeed a very good reason to avoid reintroducing it to the archive.

> And no, not everyone ported to Qt5, yet. :-)

This sounds like a good reason to start with the porting :)

Sorry, but if you really need the multimedia bits you should really consider 
using Qt5.

Kinds regards, Lisandro.

-- 
16: De quien es Internet
* De DIOS dado que todas las cosas del mundo le pertenecen
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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


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

Bug#816280: Binary incompatibility between debugperl and perl

[Nick Wellnhofer]

Package: perl-debug
Version: 5.20.2-2

The layout of interpreter variables is different in the debug and normal 
version of the perl binary. This means that XS extensions might read from or 
write to the wrong area of the interpreter variable struct, causing crashes 
and other strange behavior.


Here's an example, originally reported by me at 
https://rt.cpan.org/Public/Bug/Display.html?id=111211


$ PERL_DESTRUCT_LEVEL=2 debugperl -MList::Util=shuffle -e shuffle
Segmentation fault

This segfaults because `shuffle` calls `seedDrand01` which writes to the 
`random_state` interpreter variable. If you have a look at `intrpvar.h` in the 
Perl source, you'll see that `random_state` is at the very end with some 
variables before that are only enabled in debug builds. This causes 
`random_state` to be at a different offset in the debug build. The XS module 
`List::Util` uses the non-debug offset, so any writes to `random_state` cause 
memory corruption.


I'd propose that all interpreter variables that are only used in the debug 
build should be moved to very end in `intrpvar.h`.

Bug#805609: Acknowledgement (grilo-plugins: Split grilo-plugins into base and extra)

[Alberto Garcia]

On Sat, Nov 21, 2015 at 03:54:12PM +1100, Tim wrote:

> Here is the patch to split grilo-plugins into -base and -extra.

Hey, thanks for the patch.

I'm finally able to build Grilo again, so I'll upload 0.2.17 now.
However since this is the last release from the 0.2.x branch, I think
I'll wait until we package 0.3.x to split the plugins.

Berto

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Roger Shimizu]

On Mon, Feb 29, 2016 at 9:25 PM, Matt Fleming  wrote:
> On Mon, 29 Feb, at 10:49:54AM, Raphael Hertzog wrote:
>> Hello Matt and Borislav,
>>
>> in Debian we got a report (see below and https://bugs.debian.org/815125) that
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
>> was breaking early boot on some machines.
>>
>> Can you have a look at those failures?
>>
>
> Can someone provide me with the list of EFI patches that were applied
> for linux-image-4.4.0-1-amd64 that are not part of the stable kernel
> tree for linux-4.4.y?

Debian's kernel patch is located in:
  https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/?h=sid

and EFI related, I guess, is in:
  
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/x86?h=sid

the final "?h=sid" implies it's for sid which is currently 4.4
the master branch is for preparing 4.5-rc now.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#816216: Reassigning to a more suitable package.

[Maximiliano Curia]

Control: tag -1 + moreinfo

Hi Jeanne,

Please use reportbug to report the Debian bugs, as a way to make sure that the 
bug is correctly assigned a package and a version. This bug needed to be 
manually processed by the maintainers that handle the unknown-package@ 
reports, and we prefer not to increase their workload.

Saying that, this bug seems to be an upstream issue, as such it might be 
better to submit it to upstream directly through the upstream bug tracker: 
https://bugs.kde.org/
If you do so, please after submitting the upstream report send a mail to this 
bug so we can tag it as forwarded and get notified when the bug is processed. 

In any case, it would be useful to have a simple enough theme that reproduces 
the issue you are describing.

The problem in the report is not completely clear, but it seems to me that you 
are reporting that themes that are incomplete aren't applied even if the parts 
contained could. (That's my reading of the bug till the proposition part at 
least). Is this correct?

Happy hacking,
-- 
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
Saludos /\/\ /\ >< `/


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

Bug#816281: [Popcon-developers] Bug#816281: popularity-contest: should allow to collect parts of package configuration

[Paul Wise]

On Mon, Feb 29, 2016 at 8:29 PM, Dominique Dumont wrote:

> Thoughts ?

I am not a popcon maintainer but I would consider such a feature
dangerous for user privacy. I guess it could be acceptable if it were
opt-in.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#781110: e2fsprogs: e2fsck does not detect corruption

[Antti Salmela]

This seems to have been fixed at some point, I have kept the broken filesystem 
stored
and can't no longer reproduce this with 1.43~WIP-2015-05-18-1 from experimental.

-- 
Antti Salmela

Bug#813423: Make this release-critical

[Alex Henry]

Hello, I have just contributed to the bug report linked on the last
comment. I'd also like to ask the maintainer to change the severity of this
bug into something that is release-critical to prevent this version from
reaching stable. Please understand that in the current version the entire
audio system is broken at the moment you plug headphones in or out - which
is something many of us do everyday, many times per day. This means the
audio system is possibly requiring a normal user to reboot the system just
to have sound working on his computer if he doesn't know how to manage the
service, hence it's not at all suitable for Debian stable.

Also a quick fix for those experiencing the issue, from my recent comment
on the link above. The following terminal command will restore audio to
your system after you jack your headphones in or out:

pulseaudio --kill;pulseaudio --start

Bug#816285: python3-coverage: HTML report has incorrect hotkey handling

[Hugo Mills]

Package: python3-coverage
Version: 3.7.1+dfsg.1-1+b2
Severity: normal

Dear Maintainer,

   When viewing the HTML results from a coverage run, pressing *any*
key on the keyboard (including modifiers such as shift or ctrl) causes
things to happen. It makes no difference whether the key is a hotkey
or not.

   Specifically, in the summary table, it always sorts/reverses by
coverage percentage. In the file view, it toggles between "run"
highlighting and "missing/excluded" highlighting. The effect in the
file view is particularly annoying, because it keeps jumping to the
top of the file on any keystroke (including the Ctrl-< I use to switch
desktops).

   The browser is Iceweasel 44.0. I can reproduce this with all
extensions turned off. Uninstalling "libjs-jquery-hotkeys" makes the
problem go away, but then the "python3-coverage html" command fails
with an error, and I'm missing the possibly useful hotkeys features.

   Hugo.

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

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

Versions of packages python3-coverage depends on:
ii  libc6  2.21-7
ii  python33.5.1-1
ii  python3-pkg-resources  18.8-1
ii  python3.4  3.4.4-2
ii  python3.5  3.5.1-5

Versions of packages python3-coverage recommends:
ii  libjs-jquery  1.11.3+dfsg-4
pn  libjs-jquery-hotkeys  
ii  libjs-jquery-isonscreen   1.2.0-1
ii  libjs-jquery-tablesorter  10-2

python3-coverage suggests no packages.

-- no debconf information

-- 
Hugo Mills | But people have always eaten people,
hugo@... carfax.org.uk | what else is there to eat?
http://carfax.org.uk/  | If the Juju had meant us not to eat people
PGP: E2AB1DE4  | he wouldn't have made us of meat.


signature.asc
Description: Digital signature

Bug#816265: [Pkg-php-pecl] Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

[Sergey B Kirpichev]

> So a FTBFS on non-release arch with outdated PHP version.

I did some work to keep my packages in installable status for all arch's,
no matter how important they seems to you. Why you break this so easily?
(btw, how such archs could get release status if you refuse to assist them?).

> And with serious severity.

Whatever it is by severity - this a bug and it's not fixed yet.  And
there is no FTBFS bug
for php7.0-dev on kfreebsd (as far, as I can see).

Bug#816275: ipython-notebook can't find mathjax.js if base_url is set in your config

[Will Manley]

Package: ipython-notebook
Version: 2.4.1-1
Severity: normal

Dear Maintainer,

I use IPython notebook on a system serving more than just iPython
notebook.  To do this I set the base_url config option[1].  On with
the debian package this fails when opening a notebook with:

> Failed to retrieve MathJax from 
> '/calibration/static/javascript/mathjax/MathJax.js'

(my base-url is set to '/calibration')

I believe this is due to the patch
[use-system-mathjax-if-available.patch] which doesn't take `base_url`
into account when calling`new_handlers.append`.  I believe the two
places in that patch that refer to mathjax urls should be prepended
should be prepended by the `base_url`.

[1]: https://ipython.org/ipython-doc/3/config/options/notebook.html
[use-system-mathjax-if-available.patch]:
https://sources.debian.net/patches/ipython/2.4.1-1/use-system-mathjax-if-available.patch/

Thanks

Will

Bug#816276: systemd: shutdown fails if swap can't be deactivated

[Christian Pernegger]

Package: systemd
Version: 215-17+deb8u3
Severity: normal

Hello,

I'm running jessie inside a low-memory (k)vm, 384M of RAM plus
swap. This has been tuned so that as much as possible is swapped out
during normal operation but there's no thrashing, i.e. the working set
easily fits into RAM.

Shutting down this vm will fail more often than not because systemd
tries to disable swap very early in the process, before the main
daemon (logitechmediaserver) has shut down. The shutdown process will
then hang until the vm is force-killed by libvirt after about 5 mins
or so.

1) Why is swap deactivated first thing? IMHO it should stick around
until after all "normal" processes have exited / been killed. After
all, if swap can be deactivated in the running system it wasn't really
needed in the first place.

2) Why does a failure to deactivate swap result in the shutdown
process hanging indefinitely? Shouldn't systemd either retry or fail
gracefully (i.e., ignore the problem)?

(For this specific use case I'll also look into giving the vm more RAM
and having the host swap out more, but I do not know yet if parts of
vm memory can be efficiently swapped out host-side.)

Regards,
Christian Pernegger



# fstab entry for swap
/dev/vdb none swap sw 0 0


# log of failed shutdown

Feb 26 20:29:00 slimserver systemd-logind[410]: Power key pressed.
Feb 26 20:29:00 slimserver systemd-logind[410]: Powering Off...
Feb 26 20:29:00 slimserver systemd-logind[410]: System is powering down.
Feb 26 20:29:01 slimserver nullmailer[839]: Stopping mail-transfer-agent: 
nullmailer.
Feb 26 20:29:01 slimserver swapoff[838]: swapoff: /dev/vdb: swapoff failed: 
Nicht genügend Hauptspeicher verfügbar # that's "not enough memory [available]"
Feb 26 20:29:01 slimserver systemd[1]: dev-vdb.swap swap process exited, 
code=exited status=255
Feb 26 20:29:01 slimserver systemd[1]: Unit dev-vdb.swap entered failed state.
Feb 26 20:29:01 slimserver sshd[405]: Received signal 15; terminating.
Feb 26 20:29:01 slimserver kernel:  vdb: unknown partition table
Feb 26 20:29:02 slimserver logitechmediaserver[840]: Stopping Logitech Media 
Server.
Feb 26 20:29:02 slimserver hwclock[837]: hwclock from util-linux 2.25.2
Feb 26 20:29:02 slimserver hwclock[837]: Using the /dev interface to the clock.
Feb 26 20:29:02 slimserver hwclock[837]: Last drift adjustment done at 
1456410669 seconds after 1969
Feb 26 20:29:02 slimserver hwclock[837]: Last calibration done at 1456410669 
seconds after 1969
Feb 26 20:29:02 slimserver hwclock[837]: Hardware clock is on UTC time
Feb 26 20:29:02 slimserver hwclock[837]: Assuming hardware clock is kept in UTC 
time.
Feb 26 20:29:02 slimserver hwclock[837]: Waiting for clock tick...
Feb 26 20:29:02 slimserver hwclock[837]: ...got clock tick
Feb 26 20:29:02 slimserver hwclock[837]: Time read from Hardware Clock: 
2016/02/26 19:29:01
Feb 26 20:29:02 slimserver hwclock[837]: Hw clock time : 2016/02/26 19:29:01 = 
1456514941 seconds since 1969
Feb 26 20:29:02 slimserver hwclock[837]: 1456514942.50 is close enough to 
1456514942.50 (0.00 < 0.001000)
Feb 26 20:29:02 slimserver hwclock[837]: Set RTC to 1456514942 (1456514942 + 0; 
refsystime = 1456514942.00)
Feb 26 20:29:02 slimserver hwclock[837]: Setting Hardware Clock to 19:29:02 = 
1456514942 seconds since 1969
Feb 26 20:29:02 slimserver hwclock[837]: ioctl(RTC_SET_TIME) was successful.
Feb 26 20:29:02 slimserver hwclock[837]: Clock drifted 0.4 seconds in the past 
104273 seconds in spite of a drift factor of 0.520768 seconds/day.
Feb 26 20:29:02 slimserver hwclock[837]: Adjusting drift factor by 0.319724 
seconds/day
Feb 26 20:29:02 slimserver dhclient[895]: Killed old client process
Feb 26 20:29:03 slimserver networking[876]: Deconfiguring network 
interfaces...Killed old client process
Feb 26 20:29:04 slimserver dhclient[895]: Internet Systems Consortium DHCP 
Client 4.3.1
Feb 26 20:29:04 slimserver dhclient[895]: Copyright 2004-2014 Internet Systems 
Consortium.
Feb 26 20:29:04 slimserver dhclient[895]: All rights reserved.
Feb 26 20:29:04 slimserver dhclient[895]: For info, please visit 
https://www.isc.org/software/dhcp/
Feb 26 20:29:04 slimserver dhclient[895]:
Feb 26 20:29:04 slimserver dhclient[895]: Listening on 
LPF/eth0/52:54:00:21:14:bf
Feb 26 20:29:04 slimserver dhclient[895]: Sending on   
LPF/eth0/52:54:00:21:14:bf
Feb 26 20:29:04 slimserver dhclient[895]: Sending on   Socket/fallback
Feb 26 20:29:04 slimserver networking[876]: Internet Systems Consortium DHCP 
Client 4.3.1
Feb 26 20:29:04 slimserver networking[876]: Copyright 2004-2014 Internet 
Systems Consortium.
Feb 26 20:29:04 slimserver networking[876]: All rights reserved.
Feb 26 20:29:04 slimserver networking[876]: For info, please visit 
https://www.isc.org/software/dhcp/
Feb 26 20:29:04 slimserver networking[876]: Listening on 
LPF/eth0/52:54:00:21:14:bf
Feb 26 20:29:04 slimserver networking[876]: Sending on   
LPF/eth0/52:54:00:21:14:bf
Feb 26 20:29:04 slimserver networking[876]: Sending on   

Bug#816279: sogo: please either update Vcs-* fields or the git repo

[Jonas Smedegaard]

Source: sogo
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The git repository advertised in Vcs-* fields of this package does not
contain latest release 2.2.17a-1 currently in sid.

Please either update Vcs-* fields to reference where recent development
may have moved to, or simply push latest changes to the public git.

...or remove the Vcs-* fields if packaging no longer uses a VCS.

- - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW1DJ9AAoJECx8MUbBoAEhmDwP/2zcshE4MwV0D4kOvxwJ6vQk
NEhba7EoDe1SeErpKKX893M1H0ot/pH4KZUKevYsZK6nUMZD50tA1wRj1aDItYjC
6UEnV/5t80SLIA4zejX7WS4i2r2amKJbq2evTNiPJcMM0p7OjuM3N/G0lQL/xjGX
b6wQlqm65fAleT9KYVnQY2cWvuK13tT1IIaXDgQ/3LTnqj93unRA6AoYaOGLSkmO
BNIZYCCrR88r5BkgtnCMQIN0eH5MgSCkw89Z5KpFp8mEoCL5J2QYLzPpuq8fluZ9
Osn4/l/XViS5Ey2MioEVOVRon6ajPNxYOCJ16CEMyJnQza+mQHh4279hNVylOZ4h
C2EnfsN/xbTaDG3ldrwJmo0s5WTzPefyeTzep+cKhNA2nxmA5HPjLN5p0T2mhx77
jlDOvpsNSR9jW6UdnANYtiYtSK1naZijo/9cDlaKi1OLKoe9YE0CbA/kxS+4kW3E
bnYR++ojHFaPpnDfzP6AwDJYIamCTWp3yuqK5y0MV6Gkq33AThkcUJodZKdCKMxx
vZ2SHeg8dA328Q8F28Fcv2MKNTkevOnFgzOXB0iMKQyv/DuzM26xdq4h2ifVKP4v
3SFa9ZFQ+IkI3kN1AwCfYBccP0Nkx/PT16GDjy3vEHExtgsB31CLzuygAbYbKE00
KF8Pew17VuJvEHUmRhSU
=fGaS
-END PGP SIGNATURE-

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Matt Fleming]

On Mon, 29 Feb, at 10:49:54AM, Raphael Hertzog wrote:
> Hello Matt and Borislav,
> 
> in Debian we got a report (see below and https://bugs.debian.org/815125) that
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
> was breaking early boot on some machines.
> 
> Can you have a look at those failures?
> 

Can someone provide me with the list of EFI patches that were applied
for linux-image-4.4.0-1-amd64 that are not part of the stable kernel
tree for linux-4.4.y?

The patch you referenced above isn't in Linus' tree yet and there are
a bunch of prerequisite patches required to make it work.

Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site

[The Wanderer]

On 2016-02-18 at 04:27, Niklas Edmundsson wrote:

 * The Wanderer  [2015-09-04 12:17]:

> When I connect to http://get.debian.org/ in a Web browser, I
> am redirected to https://www.debian.org/CD/, which is a HTTPS
> site.
> 
> FYI, get.debian.org redirects to http://www.debian.org/CD/
> 
> I think the https stuff comes from the 
> https-was-previously-used-for-this-site-so-lets-enforce-it 
> site/browser feature, I forget what it's called...
> 
> So at least the confusion is not intentional on our part ;-)

The same redirection happens with wget:

$ wget http://get.debian.org/
--2016-02-29 07:19:52--  http://get.debian.org/
Resolving get.debian.org (get.debian.org)... 130.239.18.173,
130.239.18.165, 2001:6b0:e:2018::165, ...
Connecting to get.debian.org (get.debian.org)|130.239.18.173|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.debian.org/CD/ [following]
--2016-02-29 07:19:52--  https://www.debian.org/CD/

So unless wget has a similar feature (which would rather surprise me,
particularly since I don't see one documented in the man page), I think
this is an unlikely explanation.

(For that matter, it also happens with lynx, for which I'd be even more
surprised if such a feature were present.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

Hi Jakub,

On 29/02/2016 00:27, Jakub Wilk wrote:
> * Giulio Paci , 2016-02-28, 23:19:
>> I packaged 
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=1;
>>  and noticed the behaviour when upstream was at
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=3;.
>> Right now they are at 
>> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=8;.
>> I still did not check the last revision.
>> I have not found any reasonable way to detect when the package changes. 
>> Essentially the algorythm should be: check for latest version of the 
>> package, if the same package
>> exist with rev=, then the package is at the "same version" + 
>> revision +1.
>>
>> Given the current situation, do you think I should upgrade the upstream 
>> files in pristine-tar?
>> Should I have different versioning with respect to upstream or should I 
>> maintain the same version scheme even if several versions collapse into the 
>> same version?
> 
> Hmm. With pagemangle (available in devscripts >= 2.15.10) we could probably 
> teach uscan about different revisions of the same file. But that'd be 
> probably very brittle...
> 
> So how about asking uscan to always download revision 1? This should be 
> straight-forward:
> 
> opts="downloadurlmangle=s!.*/FstDownload/(.+)!http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=$1=1!;
> 
> (I had to use "&" instead of ";", because you can't use semicolons in mangle 
> rules. I hate uscan.)

Today I checked the differences between rev 8 and current packaged version... 
And they are not just minor changes as it happened before, they also changed 
ABI, without
changing SONAME (again :-().

I think:
1) I need to package latest version, as the differences are not trivial anymore;
2) I have to convince upstream stop these bad practices (however it seems very 
hard, as they stop for one release and then start again a immediately after);
3) *mangle mechanism seems not enough in this case as we need some math (we 
have to compute "+1") and the math has to be applied to a value that 
is not the
current one (we have to check that 
/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=
 exist, in order to compute +1 on
http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.5.1.tar.gz).

I am going to write to upstream again.

In the meanwhile, do you think I can package openfst-1.5.1.tar.gz rev 8 under 
openfst-1.5.1.tar.gz name?

Bests,
Giulio

Bug#815808: /usr/bin/xdg-open: xdg-open on local HTML file provides wrong arguments to browser

[Nils Dagsson Moskopp]

I edited the file to remove the readlink invocation; it works now.

Thank you for your help.

Per Olofsson  writes:

> Den 2016-02-25 kl. 20:41, skrev Nils Dagsson Moskopp:
 >> xdg-open invokes /usr/bin/conkeror with the following command line:
 >> “/usr/bin/conkeror $(readlink -m %f) /usr/share/doc/dc/dc.html”.
 >>
 >> On a cursory glance, I have been unable to find a reason for that.
>>> >
>>> > Could you please run
>>> >
>>> >sh -x /usr/bin/xdg-open /usr/share/doc/dc/dc.html
>>> >
>>> > and send me the output?
>> Yes, see the attached file.
>> 
>
> Thanks.
>
> It seems that the desktop file
> /home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop
> contains a line "Exec=conkeror $(readlink -m %f)". I don't think that's
> supported by the desktop file spec.
>
> -- 
> Pelle

-- 
Nils Dagsson Moskopp // erlehmann



pgplPzbTmdYzv.pgp
Description: PGP signature

Bug#816265: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

[Ondřej Surý]

On Mon, Feb 29, 2016, at 14:11, Sergey B Kirpichev wrote:
> > So a FTBFS on non-release arch with outdated PHP version.
> 
> I did some work to keep my packages in installable status for all arch's,
> no matter how important they seems to you.

It's not how important they seem to *me*, but to the release team. The
FTBFS on non-release archs are not "serious", just "normal" at most and
mostly it's "wishlist".

> Why you break this so easily?
> (btw, how such archs could get release status if you refuse to assist them?).

This is a breakage that was caused by libtool 2.4.6-0.1 upload. If you
want to blame somebody blame libtool maintainers for moving ltmain.sh to
different directory _again_.

And as you can see in #814271, I fixed this bug within one week when it
was reported. So please consider your words.

> > And with serious severity.
> 
> Whatever it is by severity - this a bug and it's not fixed yet.  And there is 
> no FTBFS bug
> for php7.0-dev on kfreebsd (as far, as I can see).

This bug is already fixed in 7.0.3-4:

php7.0 (7.0.3-4) unstable; urgency=medium

  * Resolve ltmain.sh link based on libtool version (Closes: #814271)

 -- Ondřej Surý   Mon, 15 Feb 2016 12:41:07 +0100

When libperl and libsnmp get's resolved on kfreebsd-*, this situation
will fix itself after newer php7.0 is built.

Somehow I cannot fix packages that are not up-to-date. Sergey, please
take your bitterness elsewhere. This is neither place nor time to hinder
the PHP 7.0 transition.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#816278: php-xdebug: PHP 5.6 support

[Michal Klichowicz]

Package: php-xdebug
Version: 2.4.0~rc4-1
Severity: important

Dear Maintainer,

Recent package changelog messages (such as "Implement a dual PHP 5.6 and 7.0
build for PHP xdebug extension") suggest support for PHP 5.6 in xdebug package.

However, php-xdebug only provides extension for the 20151012 API, provided
by php7.0 packages (and depends on these), despite configuring it for 5.6
configuration directories as well.

Since php5-xdebug (working with libapache2-mod-php5) has been removed for most
architectures and php-xdebug depends on the 7.0 API (e.g. 
libapache2-mod-php7.0),
currently there's no way to use it under 5.x modules (libapache2-mod-php5*,
php5*-cli etc.).

root@tulia:~# aptitude search php-xdebug
i   php-xdebug   - Xdebug Module for PHP
root@tulia:~# dpkg -s php-xdebug | grep Version
Version: 2.4.0~rc4-1
root@tulia:~# phpenmod xdebug
root@tulia:/etc/php# php -r 'print_r(get_loaded_extensions());' | grep xdebug
Failed loading /usr/lib/php/20131226/xdebug.so:  
/usr/lib/php/20131226/xdebug.so:
cannot open shared object file: No such file or directory
root@tulia:/etc/php# php -i | grep xdebug
Failed loading /usr/lib/php/20131226/xdebug.so:  
/usr/lib/php/20131226/xdebug.so:
cannot open shared object file: No such file or directory
/etc/php/5.6/cli/conf.d/20-xdebug.ini,

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

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
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 php-xdebug depends on:
ii  libc62.21-9
ii  php7.0-phpdbg [phpapi-20151012]  7.0.3-10
ii  ucf  3.0035

php-xdebug recommends no packages.

php-xdebug suggests no packages.

-- no debconf information

Bug#783449: linux-image-3.16.0-0.bpo.4-amd64: Xorg fails to start with Radeon HD 7600M on Vostro 3560 after upgrade to 3.16

[Vincas Dargis]

2016-02-22 15:43 GMT+02:00 Andreas Beckmann :
> Does that conbination even build the kernel module?

Well, actually, I just figured it out that it was not successfully
built. linux-headers-3.16.0-0.bpo.4-amd64 packages was missing.

Now after installing headers and reinstalling fglrx-modules-dkms I
have X working, BUT with strange flickering artifacts when enabling
multiple monitor support on KDE:

https://www.youtube.com/watch?v=uLdLvdl3r0Q

I did aticonfig --initial=dual-head to generate new xorg.conf

Works OK with 3.2 kernel, or with 3.16 but only without external monitor.

Bug#801992: Iceweasel 44.0.2-1 has broken icons again

[Gregor Riepl]

> There has not been any activity on the upstream bug[2] in the last three
> months, so I wonder whether a "proper upstream fix" actually exists yet.

It seems there's still no fix, but Michael reverted the change in the latest
package version (2.40.13-3): [1]

  * Restore 01_Revert-bgo-520654-Support-export-id-in-rsvg-convert-.patch.
The upstream patch 30_Don-t-crash-when-filters-don-t-exist.patch addresses
a different issue, so the revert is still necessary.


Building Firefox with that should restore proper icons.

[1]
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/librsvg/debian/changelog?revision=47359=markup

Bug#816280: Binary incompatibility between debugperl and perl

[Nick Wellnhofer]

On 29/02/2016 13:17, Dominic Hargreaves wrote:

This was discovered as part of the investigation into
 (which is
not quite the same bug) and was fixed upstream. This fix should be in
5.24 which should be in stretch. However, the fix by its nature breaks
binary compatibility, so it will unfortunately not be possible to apply
it to a stable release.


Yes, my issue is a bit different and it doesn't seem to be fixed. I'll bring 
it up upstream.


Nick

Bug#816270: Files in /usr/share/fence aren't compiled by Python

[Thomas Goirand]

Package: fence-agents
Version: 4.0.22-2
Severity: important

Hi,

The files in /usr/share/fence aren't compiled by Python at install time.
In fact, fence-agents doesn't even have a postinst to do so. Plus the files
in /usr/share/fence really are python modules, which should be exposed, so
that other packages could use it without having to fix the syspath. Indeed,
each and every /usr/sbin/fence_* programs have the following bits:

sys.path.append("/usr/share/fence")

I'm about to package fuel-library which also will import such module.

So I would suggest either:
1/ Move /usr/share/fence to /usr/lib/python2.7/dist-packages/fence
2/ Make sure dh_python2 is called correctly. If you don't want to move stuff
into /usr/lib/python2.7/dist-packages, then you should do, in debian/rules:
override_dh_python2:
dh_python2
dh_python2 /usr/share/fence

(yes, there's really 2 dh_python calls, that's the way it should be...)

Cheers,

Thomas Goirand (zigo)

Bug#813943: openjdk-8-jre recommends transitional dummy packages libgnome2-0 and libgconf2-4

[Vincent Lefevre]

Control: reopen -1
Control: found -1 8u72-b15-4

On 2016-02-07 00:30:53 +0100, Vincent Lefevre wrote:
> openjdk-8-jre recommends transitional dummy packages libgnome2-0 and
> libgconf2-4. These recommendations should be dropped or replaced.

The problem is still present:

$ apt-cache show openjdk-8-jre
Package: openjdk-8-jre
Source: openjdk-8
Version: 8u72-b15-4
Installed-Size: 254
Maintainer: OpenJDK Team 
Architecture: amd64
Replaces: openjdk-8-jre-headless (<< 8u20~b20-3)
Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, 
java7-runtime, java8-runtime
Depends: openjdk-8-jre-headless (= 8u72-b15-4), libgtk2.0-0, libxrandr2, 
libxinerama1, libgl1-mesa-glx | libgl1, libatk-wrapper-java-jni (>= 
0.30.4-0ubuntu2), libasound2 (>= 1.0.16), libc6 (>= 2.14), libgif7 (>= 5.1), 
libjpeg62-turbo (>= 1.3.1), libpng12-0 (>= 1.2.13-4), libpulse0 (>= 0.99.1), 
libx11-6, libxext6, zlib1g (>= 1:1.1.4)
Recommends: libgnome2-0, libgnomevfs2-0, libgconf2-4, fonts-dejavu-extra
[...]

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

Bug#816282: mate-panel[7513]: segfault at 2a5a980e ip 00007fb1fabb7505 sp 00007fffabe76958 error 4 in libgobject-2.0.so.0.4200.1[7fb1fab84000+51000]

[jpp]

Package: mate-desktop
Version: 1.8.1+dfsg1-3+deb8u1
Severity: minor

Dear Maintainer,

I get the following messages in the logs :

mate-panel[7513]: segfault at 2a5a980e ip 7fb1fabb7505 sp 7fffabe76958 
error 4 in libgobject-2.0.so.0.4200.1[7fb1fab84000+51000]

But I didn't notice any default in desktop usage ...

Regards

JP P

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

Kernel: Linux 4.5.0-rc3 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mate-desktop depends on:
ii  hicolor-icon-theme0.13-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u3
ii  libcairo2 1.14.0-2.1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3
ii  libmate-desktop-2-17  1.8.1+dfsg1-3+deb8u1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libunique-1.0-0   1.1.6-5
ii  mate-desktop-common   1.8.1+dfsg1-3+deb8u1

mate-desktop recommends no packages.

mate-desktop suggests no packages.

-- no debconf information

Bug#816159: www.debian.org: new introduction for blends page

[Iain R. Learmonth]

Hi,

Could someone take a look at the wording for this to ensure it's
understandable
by non-technical users and to ensure that it's easily translatable.

Please keep the bug in CC, I'm not subscribed to debian-l10n-english.

Thanks,
Iain.

Bug#813452: [Pkg-pascal-devel] Bug#813452: Bug#813452: [Core] Bug#813452: Bug#813452: fpc-3.0 regression in armhf and armel architectures

[Abou Al Montacir]

Hi Sven, Hi Dear Core team,
It seems I forgot to copy the core list for this mail.
Can you please help finding the revision ranges that we can backport in order to
fix 3.0.0 and allow debian users to enjoy using then new FPC release on ARM?
Thanks for your support
-- 
Cheers,
Abou Al Montacir

On Thu, 2016-02-25 at 12:15 +0100, Abou Al Montacir wrote:
> Hi Sven,
> 
> On Mon, 2016-02-22 at 17:44 +0100, Abou Al Montacir wrote:
> > Hi Sven
> > 
> > On Mon, 2016-02-22 at 07:58 +0100, Sven Barth wrote:
> > > >  Looks like PIC code was broken in 3.0. Is there anyone aware of that?
> > > How can we fix that?
> > > >
> > > Would you please try the current development version of FPC (3.1.1) to
> > > check whether the issue persists there?
> > Yes, sure I'll do and let you know.
> I've tested the FPC trunk and it works well. Here is the log of both wersions:
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ fpc -fPIC test2 && ./test2
> Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test2.pas
> Assembling test
> Linking test2
> /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget
> -T?
> 4 lines compiled, 0.3 sec
> Runtime error 103 at $000101D8
>   $000101D8
>   $00010124
> 
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ /home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-
> 3.1.1/fpcsrc/compiler/ppcarm -Fu/home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-
> 3.1.1/fpcsrc/ -Fu/home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-
> 3.1.1/fpcsrc/rtl/units/arm-linux -fPIC test2 && ./test2
> Free Pascal Compiler version 3.1.1-0 [2016/02/24] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test2.pas
> Linking test2
> 4 lines compiled, 0.2 sec
> Hello
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ 
> 
> This shows that the issue was fixed in trunk. Can you please help finding the
> revision that may fixed that so we can extract a patch and fix 3.0.0?
> 
> As long as this bug is open, fpc transition to testing is blocked and this is
> quite unpleasing for many of our users.
> -- 
> Cheers,
> Abou Al Montacir
> ___
> Pkg-pascal-devel mailing list
> pkg-pascal-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel

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

Bug#814829: [RFR] templates://eviacam/{templates}

[Cesar Mauri]

Hi,

Thanks you both Christian and Justin for your review. Your improvements look 
great to me!

I've just changed webcam for camera and removed the trailing "software" after 
Facial Mouse.

I created the path using "git diff". I hope that is fine.


Cheers,

C.
Template: eviacamloader/eviacamloader_setuid
Type: boolean
Default: false
_Description: Should eviacamloader be installed "setuid root"?
 Installing eviacamloader with the set-user-ID bit set enables all
 users who have been added to the group "eviacam" to launch eviacam
 with a modified scheduling priority for better responsiveness.
 .
 Since this setting allows eviacamloader to be run with superuser
 privileges, it may have security implications in the case of
 vulnerabilities in eviacamloader's code.
Source: eviacam
Section: x11
Priority: optional
Maintainer: Cesar Mauri 
Build-Depends: debhelper (>= 9),
   dh-autoreconf,
   libgtk2.0-dev,
   libopencv-dev (>= 2.0),
   libpng12-dev,
   libv4l-dev,
   libwxgtk3.0-dev,
   libxext-dev,
   libxtst-dev,
   po-debconf
Standards-Version: 3.9.6
Homepage: http://viacam.org

Package: eviacam
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}, opencv-data
Recommends: wx3.0-i18n
Description: camera based mouse emulator
 Enable Viacam (aka eViacam) is a mouse replacement program that moves
 the pointer tracking the user's head movements. It works on a standard
 computer equipped with a camera. No additional hardware is required.
 Based on the award winning Facial Mouse.
diff --git a/debian/control b/debian/control
index 6051f47..5e10e04 100644
--- a/debian/control
+++ b/debian/control
@@ -19,8 +19,8 @@ Package: eviacam
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, opencv-data
 Recommends: wx3.0-i18n
-Description: webcam based mouse emulator
+Description: camera based mouse emulator
  Enable Viacam (aka eViacam) is a mouse replacement program that moves
- the pointer as you move your head. It works on a standard computer
- equipped with a web camera. No additional hardware is required. Based
- on the award winning Facial Mouse software.
+ the pointer tracking the user's head movements. It works on a standard
+ computer equipped with a camera. No additional hardware is required.
+ Based on the award winning Facial Mouse.
diff --git a/debian/templates b/debian/templates
index fb0a2c4..38676e7 100755
--- a/debian/templates
+++ b/debian/templates
@@ -1,12 +1,11 @@
 Template: eviacamloader/eviacamloader_setuid
 Type: boolean
 Default: false
-_Description: Should eviacamloader be installed 'setuid root'?
- In order to enable users of the group 'eviacam' to run eviacam in 
- high priority (which improves responsiveness), the eviacamloader 
- program can be installed with the set-user-ID bit set, so that it 
- will run with the permissions of the superuser.
+_Description: Should eviacamloader be installed "setuid root"?
+ Installing eviacamloader with the set-user-ID bit set enables all
+ users who have been added to the group "eviacam" to launch eviacam
+ with a modified scheduling priority for better responsiveness.
  .
- Such a setting requires that the sysadmin adds authorized users to the 
- 'eviacam' group and may have security implications in the case of 
+ Since this setting allows eviacamloader to be run with superuser
+ privileges, it may have security implications in the case of
  vulnerabilities in eviacamloader's code.

Bug#816273: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings

[Víctor Cuadrado Juan]

close 816273
thanks

Closing this ITP, since there is already another one open, #806716.

Sorry for the noise.



-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

Bug#816283: nvidia-cuda-toolkit: cuda broken after upgrade (x86_64, Jessie, GTX980)

[Alois Schloegl]

Package: nvidia-cuda-toolkit
Version: 7.0.28-4
Severity: important

Dear Maintainer,



I tried to upgrade the nvidia-drivers from 352.41-1
to  the current version "352.79-3" and nvidia-cuda-toolkit to a matching
version, cuda became unusable. Rebooting the machine did not help.

I used the following two tests.

First, nvidia-smi reports this error:

  # nvidia-smi
  Failed to initialize NVML: GPU access blocked by the operating system

Second, I do have a short cuda program from here
https://github.com/leschzinerlab/Motion-correction.git
and can be installed with the following commands

git clone https://github.com/leschzinerlab/Motion-correction.git
cd Motion-correction/motioncorr_v2.1/src/
make -B
../bin/gpuinfo

The compilation works without problems, but running the command
 ../bin/gpuinfo
results in this message:

Simple GPU info query.

You have 32720 nVidia GPGPU.

DeviceID NameVersion Memory(Mb)
Failed to get GPU info of Device #0
Failed to get GPU info of Device #1
Failed to get GPU info of Device #2
Failed to get GPU info of Device #3
...
Failed to get GPU info of Device #32568
Failed to get GPU info of Device #32569
Failed to get GPU info of Device #32570
Failed to get GPU info of Device #32571


I tried a number of additional things, like using the packages in
jessie-backports, and  nvidia-cuda 7.0 from debian/unstable. None of
these attempts solved the issue.


Best,
   Alois



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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 nvidia-cuda-toolkit depends on:
ii  g++-4.8  4.8.4-1
ii  g++-4.9  4.9.2-10
ii  gcc-4.8  4.8.4-1
ii  gcc-4.9  4.9.2-10
ii  libc62.19-18+deb8u3
ii  libgcc1  1:5.3.1-8
ii  libnvvm3 7.0.28-4
ii  libstdc++6   5.3.1-8
ii  nvidia-cuda-dev  7.0.28-4
ii  nvidia-profiler  7.0.28-4
ii  ocl-icd-opencl-dev [opencl-dev]  2.2.3-1+deb8u1

Versions of packages nvidia-cuda-toolkit recommends:
ii  nvidia-cuda-doc 7.0.28-4
ii  nvidia-cuda-gdb 7.0.28-4
pn  nvidia-visual-profiler  

Versions of packages nvidia-cuda-toolkit suggests:
pn  libcupti-dev   
ii  nvidia-driver  352.79-4

-- no debconf information

Bug#738704: [Debian-ha-maintainers] Bug#738704: closed by wf...@niif.hu (Ferenc Wágner) (Re: pacemaker: Segfault in libhbclient.so.1.0.0)

[Philipp Marek]

> > I'd just like to know why Heartbeat support isn't included anymore... yes, 
> > it won't do OCFS2 or GFS2, but in exchange it has been rock-solid for me.
> 
> Ah, I see.  No principal reason, just lack of manpower.  I'll be happy
> if we can properly maintain a single stack; we're not there yet.  What's
> the upstream status of Heartbeat, anyway?  Internet suggest it's
> deprecated and no longer developed, but maintained by Linbit.  Can you
> provide an update on that? 
Well, we won't provide any new features - but yes, we're still using it, 
and provide our customers with a Pacemaker/Heartbeat stack (and 
a Pacemaker/Corosync one, too).

We also fix Pacemaker if support for Heartbeat is broken in there.


> Also, if you can bring Heartbeat expertise
> into the Debian HA team, I've got nothing against compiling support into
> Pacemaker.
Well, we hope to generate some money from our support...
so I can't just say "we'll fix everything for free".

But if redirecting people to (possibly paid-for) support is okay, I guess 
we'd be the right destination for such questions...


Regards,

Phil

Bug#815808: /usr/bin/xdg-open: xdg-open on local HTML file provides wrong arguments to browser

[Nils Dagsson Moskopp]

Per Olofsson  writes:

> Hi Nils,
>
> Den 2016-02-24 kl. 17:02, skrev Nils Dagsson Moskopp:
>> Dear Maintainer,
>>
>> I tried opening a local HTML file with xdg-open.
>>
>> I passed the absolute path with “xdg-open /usr/share/doc/dc/dc.html”
>>
>> Afterwards, xdg-open started /usr/bin/conkeror and opened the file.
>>
>> However, it also opened a buffer with.
>> It also opened another buffer with.
>> Both are non-existing URLs I did not want to open.
>>
>> xdg-open invokes /usr/bin/conkeror with the following command line:
>> “/usr/bin/conkeror $(readlink -m %f) /usr/share/doc/dc/dc.html”.
>>
>> On a cursory glance, I have been unable to find a reason for that.
>
> Could you please run
>
>sh -x /usr/bin/xdg-open /usr/share/doc/dc/dc.html
>
> and send me the output?

Yes, see the attached file.

> -- 
> Pelle

-- 
Nils Dagsson Moskopp // erlehmann



pgpsRg4iOhokx.pgp
Description: PGP signature
+ check_common_commands /usr/share/doc/dc/dc.html
+ [ 1 -gt 0 ]
+ parm=/usr/share/doc/dc/dc.html
+ shift
+ [ 0 -gt 0 ]
+ [ -z  ]
+ unset XDG_UTILS_DEBUG_LEVEL
+ [ 0 -lt 1 ]
+ xdg_redirect_output= > /dev/null 2> /dev/null
+ [ x/usr/share/doc/dc/dc.html != x ]
+ url=
+ [ 1 -gt 0 ]
+ parm=/usr/share/doc/dc/dc.html
+ shift
+ [ -n  ]
+ url=/usr/share/doc/dc/dc.html
+ [ 0 -gt 0 ]
+ [ -z /usr/share/doc/dc/dc.html ]
+ detectDE
+ unset GREP_OPTIONS
+ [ -n i3 ]
+ [ x = x ]
+ [ x != x ]
+ [ x != x ]
+ [ x != x ]
+ dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus 
org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager
+ 
+ grep  = \"xfce4\"$
+ xprop -root _DT_SAVE_MODE
+ grep -i ^xfce_desktop_window
+ xprop -root
+ grep -q ^Enlightenment
+ echo
+ [ x = x ]
+ [ x = x ]
+ uname
+ [ x = xgnome ]
+ [ x = x ]
+ DE=generic
+ DEBUG 2 Selected DE generic
+ [ -z  ]
+ return 0
+ open_generic /usr/share/doc/dc/dc.html
+ is_file_url_or_path /usr/share/doc/dc/dc.html
+ grep -q ^file://
+ echo /usr/share/doc/dc/dc.html
+ egrep -q ^[[:alpha:]+\.\-]+:
+ echo /usr/share/doc/dc/dc.html
+ return 0
+ file_url_to_path /usr/share/doc/dc/dc.html
+ local file=/usr/share/doc/dc/dc.html
+ grep -q ^file:///
+ echo /usr/share/doc/dc/dc.html
+ echo /usr/share/doc/dc/dc.html
+ local file=/usr/share/doc/dc/dc.html
+ check_input_file /usr/share/doc/dc/dc.html
+ [ ! -e /usr/share/doc/dc/dc.html ]
+ [ ! -r /usr/share/doc/dc/dc.html ]
+ [ -n :0 ]
+ sed s/;.*//
+ xdg-mime query filetype /usr/share/doc/dc/dc.html
+ filetype=text/html
+ open_generic_xdg_mime /usr/share/doc/dc/dc.html text/html
+ filetype=text/html
+ xdg-mime query default text/html
+ default=userapp-conkeror-B4SJ9W.desktop
+ [ -n userapp-conkeror-B4SJ9W.desktop ]
+ xdg_user_dir=
+ [ -n  ]
+ xdg_user_dir=/home/erlehmann/.local/share
+ xdg_system_dirs=
+ [ -n  ]
+ xdg_system_dirs=/usr/local/share/:/usr/share/
+ DEBUG 3 /home/erlehmann/.local/share:/usr/local/share/:/usr/share/
+ [ -z  ]
+ return 0
+ sed s/:/ /g
+ echo /home/erlehmann/.local/share:/usr/local/share/:/usr/share/
+ search_desktop_file userapp-conkeror-B4SJ9W.desktop 
/home/erlehmann/.local/share/applications/ /usr/share/doc/dc/dc.html
+ local default=userapp-conkeror-B4SJ9W.desktop
+ local dir=/home/erlehmann/.local/share/applications/
+ local target=/usr/share/doc/dc/dc.html
+ local file=
+ [ -r 
/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop ]
+ 
file=/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop
+ [ -r 
/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop ]
+ first_word
+ read first rest
+ get_key 
/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop Exec
+ local 
file=/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop
+ local key=Exec
+ local desktop_entry=
+ IFS_= 

+ IFS=
+ read line
+ desktop_entry=y
+ read line
+ read line
+ read line
+ read line
+ read line
+ [ -n y ]
+ cut -d= -f 2-
+ echo Exec=conkeror $(readlink -m %f)
+ echo conkeror
+ read line
+ read line
+ read line
+ IFS=  

+ command=conkeror
+ which conkeror
+ command_exec=/usr/bin/conkeror
+ get_key 
/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop Icon
+ local 
file=/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop
+ local key=Icon
+ local desktop_entry=
+ IFS_= 

+ IFS=
+ read line
+ desktop_entry=y
+ read line
+ read line
+ read line
+ read line
+ read line
+ read line
+ read line
+ read line
+ IFS=  

+ icon=
+ get_key 
/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop Name
+ local 
file=/home/erlehmann/.local/share/applications//userapp-conkeror-B4SJ9W.desktop
+ local key=Name
+ local desktop_entry=
+ IFS_= 

+ IFS=
+ read line
+ desktop_entry=y
+ read line
+ read line
+ read line
+ read line
+ read line
+ read line
+ [ -n y ]
+ cut -d= -f 2-
+ echo Name=conkeror
+ read line
+ read line
+ IFS=  

+ 

Bug#728446: apcupsd: diff for NMU version 3.14.12-1.2

[Carsten Leonhardt]

Control: tags 728446 + pending
Control: tags 810396 + patch
Control: tags 810396 + pending

Dear Giuseppe,

as discussed earlier I've prepared an NMU for apcupsd (versioned as
3.14.12-1.2) and will upload it.

Regards.

diff -u apcupsd-3.14.12/debian/changelog apcupsd-3.14.12/debian/changelog
--- apcupsd-3.14.12/debian/changelog
+++ apcupsd-3.14.12/debian/changelog
@@ -1,3 +1,12 @@
+apcupsd (3.14.12-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on libusb-1.0-0-dev instead of libusb-dev, this also
+fixes USB communication on kfreebsd. (Closes: #728446, #810396)
+  * Build-Depend on libgd-dev instead of the deprecated libgd2-noxpm-dev.
+
+ -- Carsten Leonhardt   Mon, 29 Feb 2016 16:13:41 +0100
+
 apcupsd (3.14.12-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u apcupsd-3.14.12/debian/control apcupsd-3.14.12/debian/control
--- apcupsd-3.14.12/debian/control
+++ apcupsd-3.14.12/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Giuseppe Iuculano 
 Uploaders: Stefan Ritter 
-Build-Depends: debhelper (>= 7), autotools-dev, quilt, mawk | awk, 
libgd2-noxpm-dev, libncurses5-dev | libncurses-dev, libsnmp-dev, libssl-dev, 
libwrap0-dev, po-debconf, texinfo, tcpd, rst2pdf, python-docutils, pkg-config, 
libusb-dev
+Build-Depends: debhelper (>= 7), autotools-dev, quilt, mawk | awk, libgd-dev, 
libncurses5-dev | libncurses-dev, libsnmp-dev, libssl-dev, libwrap0-dev, 
po-debconf, texinfo, tcpd, rst2pdf, python-docutils, pkg-config, 
libusb-1.0-0-dev
 Standards-Version: 3.8.4
 Homepage: http://www.apcupsd.com/
 

Bug#816297: subversion-tools: post-commit email errors with default exim4

[David CHALON]

Package: subversion-tools
Version: 1.6.17dfsg-4+deb7u10
Severity: important



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages subversion-tools depends on:
ii  subversion  1.6.17dfsg-4+deb7u10

Versions of packages subversion-tools recommends:
ii  exim4  4.80-7+deb7u1
ii  exim4-daemon-light [mail-transport-agent]  4.80-7+deb7u1
ii  libconfig-inifiles-perl2.75-1
ii  libsvn-perl1.6.17dfsg-4+deb7u10
ii  liburi-perl1.60-1
ii  python-subversion  1.6.17dfsg-4+deb7u10
ii  rsync  3.0.9-4
ii  xsltproc   1.1.26-14.1

Versions of packages subversion-tools suggests:
pn  libsvn-ruby1.8  

-- no debconf information

We migrate a SVN server to a Debian 7 wheezy old-stable.

After add subervsion-tools to get the post-commit scripts we got 2 problems :

1°) error at mail submit : option -f in mailer.py not supported by exim :

* Error in command line:

mail: Cannot give -f and people to send to
Traceback (most recent call last):
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 1353, in 
sys.argv[3:3+expected_args])
  File "/usr/lib/pymodules/python2.7/svn/core.py", line 281, in run_app
return func(application_pool, *args, **kw)
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 105, in main
messenger.generate()
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 388, in generate
group, params, paths, subpool)
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 658, in generate_content
renderer.render(data)
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 968, in render
self._render_diffs(data.diffs, '')
  File "/srv/subversion/Viry/DMS/hooks/mailer.py", line 1020, in _render_diffs
w('\nAdded: %s\n' % diff.path)
IOError: [Errno 32] Broken pipe


* Manual correction in mailer.py:

  def start(self, group, params):
MailedOutput.start(self, group, params)

### gotta fix this. this is pretty specific to sendmail and qmail's
### mailwrapper program. should be able to use option param substitution

#cmd = self.cmd + [ '-f', self.from_addr ] + self.to_addrs
cmd = self.cmd + [ self.from_addr ] + self.to_addrs




2°) after this patch, mail is sent, but format not good for Exim :  the 
metadata like from, type,... are in the body of the mail :

 Final result:

* Missing subject line
* All meta info shown in body

_ MAIL BODY ___
From: durea
To: admin-sysli...@xxx.com
Subject: r4 - trunk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Author: durea
Date: Mon Feb 29 15:18:03 2016
New Revision: 4

Log:
add toto.txt

Added:
   trunk/toto.txt

Added: trunk/toto.txt
=
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/toto.txt  Mon Feb 29 15:18:03 2016(r4)
@@ -0,0 +1 @@
+toto
\ Pas de fin de ligne à la fin du fichier
_

-- 
Ce courriel (incluant ses éventuelles pièces jointes) contient des informations 
confidentielles et/ou protégées ou dont la diffusion est restreinte. Si vous 
avez reçu ce courriel par erreur, vous ne devez ni le copier, ni l’utiliser, ni 
en divulguer le contenu à quiconque. Merci d’en avertir immédiatement 
l’expéditeur et d'effacer ce courriel de votre système. Renault Sport Racing 
décline toute responsabilité en cas de corruption par virus, d’altération ou de 
falsification de ce courriel lors de sa transmission par voie 
électronique.Renault Sport Racing s.a.s – Registre du Commerce et des 
Sociétés d'Evry (Numéro 306.140.807) – Siège social: 1-15 Avenue du Président 
Kennedy, 91170 Viry Chatillon, FranceThis email (including any 
attachments) contains confidential and/or privileged information or information 
otherwise protected from disclosure. If you are not the intended recipient, 
please notify the sender immediately, do not copy this messa
 ge or any attachments and do not use it for any purpose or disclose its 
content to any person, but delete this message and any attachments from your 
system. Renault Sport Racing disclaims any and all liability if this email 
transmission was virus corrupted, altered or falsified. Renault Sport 
Racing s.a.s – Commercial and Companies Registry of Evry (Number 306.140.807) – 
Registered office : 1-15 Avenue du Président Kennedy, 91170 Viry Chatillon, 
France

Bug#816276: systemd: shutdown fails if swap can't be deactivated

[Michael Biebl]

Hi Christian

Am 29.02.2016 um 12:43 schrieb Christian Pernegger:
> Package: systemd
> Version: 215-17+deb8u3
> Severity: normal
> 
> Hello,
> 
> I'm running jessie inside a low-memory (k)vm, 384M of RAM plus
> swap. This has been tuned so that as much as possible is swapped out
> during normal operation but there's no thrashing, i.e. the working set
> easily fits into RAM.
> 
> Shutting down this vm will fail more often than not because systemd
> tries to disable swap very early in the process, before the main
> daemon (logitechmediaserver) has shut down. The shutdown process will
> then hang until the vm is force-killed by libvirt after about 5 mins
> or so.

This looks like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805133

I've pulled the fix into our jessie branch, so it is very likely part of
the next stable point release.
If you want to test the fix, the code is at
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/log/?h=jessie
specifically
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=jessie=c4793975137d5d522fee104b7dab94a79547effd


Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#816276: systemd: shutdown fails if swap can't be deactivated

[Michael Biebl]

Am 29.02.2016 um 17:35 schrieb Christian Pernegger:
> 2016-02-29 17:20 GMT+01:00 Michael Biebl :
>> This looks like a duplicate of
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805133
> 
> Indeed it does, I do apologise. In my defence, I did filter for "swap"
> in reportbug and it didn't show up (still doesn't, actually).

The reason is, that it's already archived.
I've merged the two bug reports.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

(Copying to the bug address now, but no reply in this message.  Will
reply shortly).


2016-02-29 13:17 Zack Weinberg:

On Tue, Feb 23, 2016 at 8:44 AM, Manuel A. Fernandez Montecelo
 wrote:


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?


Attached.  I was having trouble finding the right bit of the logs, but
conveniently the problem happened again this morning.  The logs start
immediately after upgrading aptitude to 0.7.6-1, which I did
separately from everything else.


Also, please attach the result of:

apt-config dump


Ok.

zw



APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.4\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S 
/var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit 
--object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged 
cache-update > /dev/null; /bin/echo > /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e 
/usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Víctor Cuadrado Juan]

About gbp.conf, we at #debian-mentors have realized that if you want to
comply with DPMT's Policy, then you will need to set up the `upstream`
branch by importing only the tar.gzs, without upstream's commit history
on it.

That makes gbp.conf superfluous and also there's no need to think about
upstream submodules.


-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#115767: I see this too on x86 user-mode-linux on etch

[Bernhard M. Wiedemann]

On 2016-02-29 15:12, Sebastian Andrzej Siewior wrote:
> the year 2016 arrived and with it new kernel, openssl among other packages.
> Can anyone of the reporters here reproduce the bug on current unstable or
> atleast stable distro?

I have switched from UML to KVM and have not seen this bug anymore since
years.

Ciao
Bernhard M.

Bug#816159: www.debian.org: new introduction for blends page

[Justin B Rye]

Paul Wise wrote:
>> # 
>> # Debian Pure Blends are a solution for groups of people with specific needs.
>> # Not only do they provide handy collections (meta-packages) of specific 
>> packages,
>> # but they also ease installation and configuration for the intended purpose.
>> # They cover the interests of different groups of people, who might be 
>> children,
>> # scientists, gamers, lawyers, medical staff, visually impaired people, etc.
>> # Their common goal is to make installation and administration of computers
>> # for their target audience as easy as possible and to connect their audience
>> # with the people who write or package software for that audience.
>> # 
>>
>> It's all okay, but there is room for improvement in that last
>> sentence.  How about:
>>
>>   Their common goal is to make computer installation and administration
>>   as easy as possible for their target audience, and to connect that audience
>>   with the people who write or package software.
> 
> The changes there are:
> 
> Ordering in the easy/target part of the first part of the sentence. Looks good
> 
> their audience -> that audience. Looks good.
> 
> Dropping "for that audience" from the end of the sentence. This is a
> fairly crucial part of the sentence and much of the point of the
> previous equivalent of this sentence.
> 
> For reference, the original read like this:
> 
> The common goal of those is to make 12 installation and administration
> of computers for their target users as easy as 13 possible, and to
> serve in the role as the missing link between software 14 developers
> and users well.
> 
> https://anonscm.debian.org/viewvc/webwml/webwml/english/blends/index.wml?revision=1.2=markup
> 
> So, I would propose to modify your version to this:
> 
> Their common goal is to make computer installation and administration
> as easy as possible for their target audience, and to connect that audience
> with the people who write or package software for it.
> 
> I'm not sure "for it" conveys exactly the right emphasis but I'm not
> sure how else to word it.

The trouble is, we can't just keep repeating "audience", but "it" is
the group people we're writing for, so (at least in en_GB) it would be
more natural to say "them", and either way it's a rather weak ending.
My first draft had "the people who write or package that software",
but then I decided there wasn't no clear antecedent for that to refer
back to.  Wracking my brain...

   Their common goal is to make installation and administration of computers
   for that interest group as easy as possible and to connect the people
   writing or packaging the software with their target audience.

or

   Their common goal is to make installation and administration of computers
   for that target audience as easy as possible and to provide a
   connection between that group and the people writing or packaging
   the software they use.

or (maybe better, maybe my critical faculties are just going numb):

   Their common goal is to simplify installation and administration of
   computers for their target audience, and to connect that audience
   with the people writing or packaging the software they use.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#816302: wapiti: Code is GPL2+, copyright file states GPL2-only

[Nicolás Alvarez]

Package: wapiti
Version: 2.3.0+dfsg-1
Severity: minor

The DEP-5 copyright file of the wapiti package unambiguously states the
package is under the GPLv2-only without allowing later versions:

License: GPL-2
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; version 2 of the License.

However, it seems all the source files in the project say "either
version 2 of the License, or (at your option) any later version", so the
copyright file is incorrect, it should say "GPL-2+".

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

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

Bug#816281: [Popcon-developers] Bug#816281: Bug#816281: popularity-contest: should allow to collect parts of package configuration

[Petter Reinholdtsen]

I doubt popcon is a good fit for your need, both for practical and
privacy reasons.  If you restructured the package to provide one package
per driver, popcon would be able to help you.  Otherwise not.

But you could consider adding a bug reporting script in /usr/share/bug/
and let it report the drivers enabled (use apt-file search
/usr/share/bug to find examples).  It would allow you to get the info
you want in reported bugs, at least.

--
Happy hacking
Petter Reinholdtsen

Bug#816284: mpi4py: FTBFS in s390x with openMPI

[Mattia Rizzolo]

Source: mpi4py
Version: 1.3.1+hg20131106-2
Severity: serious
Tags: stretch sid
Control: block 814936 by -1


Dear maintainer,

mpi4py has test failures on s390x (only) when rebuilt with mpi-defaults
using openMPI.
You can see the full build log on
https://buildd.debian.org/status/fetch.php?pkg=mpi4py=s390x=1.3.1%2Bhg20131106-2%2Bb4=1455830603

In ubuntu doko applied a patch to just ignore the tests results in s390x
only, really unsure if this is correct, but just a data point:
https://launchpadlibrarian.net/238584899/mpi4py_1.3.1+hg20131106-2ubuntu4_1.3.1+hg20131106-2ubuntu5.diff.gz

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

[Felipe Sateler]

Hi Anton,

On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev  wrote:
> tags 796603 + help patch

I see you tagged this bug help. What can I do to help move this forward?


-- 
Saludos,
Felipe Sateler

Bug#816281: popularity-contest: should allow to collect parts of package configuration

[Petter Reinholdtsen]

I doubt popcon is a good fit for your need, both for practical and
privacy reasons.  If you restructured the package to provide one package
per driver, popcon would be able to help you.  Otherwise not.

But you could consider adding a bug reporting script in /usr/share/bug/
and let it report the drivers enabled (use apt-file search
/usr/share/bug to find examples).  It would allow you to get the info
you want in reported bugs, at least.

--
Happy hacking
Petter Reinholdtsen

Bug#816159: www.debian.org: new introduction for blends page

[Paul Wise]

[Someone dropped -blends, re-added]

On Mon, Feb 29, 2016 at 11:34 PM, Justin B Rye wrote:
> Iain R. Learmonth wrote:
>> Could someone take a look at the wording for this to ensure it's 
>> understandable
>> by non-technical users and to ensure that it's easily translatable.
>>
>> Please keep the bug in CC, I'm not subscribed to debian-l10n-english.
>
> Quoting that proposed text:
> # 
> # A general purpose operating system like Debian can be the perfect solution 
> for
> # many different areas of life.
> # Whether you want Debian to work for you in the classroom, as a games 
> machine,
> # or in the office, each area has its own unique needs and requires a
> # different subset of packages tailored in a different way.
> # 
> #
> # 
> # Debian Pure Blends are a solution for groups of people with specific needs.
> # Not only do they provide handy collections (meta-packages) of specific 
> packages,
> # but they also ease installation and configuration for the intended purpose.
> # They cover the interests of different groups of people, who might be 
> children,
> # scientists, gamers, lawyers, medical staff, visually impaired people, etc.
> # Their common goal is to make installation and administration of computers
> # for their target audience as easy as possible and to connect their audience
> # with the people who write or package software for that audience.
> # 
>
> It's all okay, but there is room for improvement in that last
> sentence.  How about:
>
>   Their common goal is to make computer installation and administration
>   as easy as possible for their target audience, and to connect that audience
>   with the people who write or package software.

The changes there are:

Ordering in the easy/target part of the first part of the sentence. Looks good

their audience -> that audience. Looks good.

Dropping "for that audience" from the end of the sentence. This is a
fairly crucial part of the sentence and much of the point of the
previous equivalent of this sentence.

For reference, the original read like this:

The common goal of those is to make 12 installation and administration
of computers for their target users as easy as 13 possible, and to
serve in the role as the missing link between software 14 developers
and users well.

https://anonscm.debian.org/viewvc/webwml/webwml/english/blends/index.wml?revision=1.2=markup

So, I would propose to modify your version to this:

Their common goal is to make computer installation and administration
as easy as possible for their target audience, and to connect that audience
with the people who write or package software for it.

I'm not sure "for it" conveys exactly the right emphasis but I'm not
sure how else to word it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#816294: [Pkg-openldap-devel] Bug#816294: slapd segfault on update dbconfig

[Ryan Tandy]

Control: tag -1 moreinfo

On Mon, Feb 29, 2016 at 03:57:30PM +0100, Thomas Otto wrote:

ldapmodify -Z -h ldaptest1
...
dn: olcDatabase={3}hdb,cn=config
changetype: modify
replace: olcDbConfig
olcDbConfig: # Note: most DB_CONFIG settings will take effect only upon 
rebuilding
olcDbConfig: # the DB environment.
olcDbConfig: #
olcDbConfig: # one 0.25 GB cache
olcDbConfig: #set_cachesize 0 268435456 1
olcDbConfig: set_cachesize 1 0 1
olcDbConfig: # Data Directory
olcDbConfig: #set_data_dir db
olcDbConfig: # Transaction Log settings
olcDbConfig: set_lg_regionmax 262144
olcDbConfig: set_lg_bsize 2097152
olcDbConfig: #set_lg_dir logs
olcDbConfig: # delete Transaction Logs:
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbConfig: # Note that if the log files are removed automatically, recovery 
after
olcDbConfig: # a catastrophic failure is likely to be impossible.
olcDbConfig: # http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_5.0
olcDbConfig: # db5.1_stat -c -h /var/lib/ldap/logs
olcDbConfig: set_lk_max_locks   6
olcDbConfig: set_lk_max_objects 25000
olcDbConfig: set_lk_max_lockers 1500

modifying entry "olcDatabase={3}hdb,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: failed to reopen database, rc=22


I performed the same modification on a new install of slapd 
2.4.40+dfsg-1+deb8u2, and did not observe a crash.


What was the olcDbConfig value prior to this change?

What sort of load was slapd under at the time? From the name, I guess 
this might be an accesslog database?


I don't know for sure whether it's relevant, but for completeness: do 
you have other hdb databases, and what do their configs look like?


If you can think of any other information that might help reproduce the 
crash, please mention it.


thanks,
Ryan

Bug#816287: geeqie: please do NOT Recommends lpr

[Michal Čihař]

Hi

Dne 29.2.2016 v 15:30 Martin-Éric Racine napsal(a):
> Package: geeqie
> Version: 1:1.2-3+b1
> Severity: normal
> 
> Please remove the Recommends on 'lpr'. People usually have some printer 
> daemon already installed (usually CUPS) and pulling an extra one is not 
> desirable. Thanks!

There is no reason why lpr should pull in another server, it should
install cups-bsd if you're using cups already...

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750070 why
it's there.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com



signature.asc
Description: OpenPGP digital signature

Bug#813312: xserver-xorg-video-nvidia: GDM crashes on start

[Luca Boccassi]

Control: tag -1 moreinfo
Control: severity -1 normal

On Sun, 2016-01-31 at 15:49 +0200, Victor Porton wrote:
> Package: xserver-xorg-video-nvidia
> Version: 340.96-4
> Severity: important
> 
> Dear Maintainer,
> 
> With Nouveau Gnome works well.
> 
> After installing xserver-xorg-video-nvidia it is impossible to start GDM.
> At start of GDM I see "Something went wrong" error message and the system
> is frozen.
> 
> My video card:
> GeForce 8400 GS Rev. 3
> 
> My motherboard:
> Gigabyte Technology Co., Ltd. H67A-UD3H
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
> (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.1.0-2-686-pae (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages xserver-xorg-video-nvidia depends on:
> ii  debconf [debconf-2.0]  1.5.58
> ii  libc6  2.21-7
> pn  libgl1-nvidia-glx  
> ii  nvidia-alternative 340.96-4
> ii  nvidia-installer-cleanup   20151021+1
> pn  nvidia-support 
> ii  xserver-xorg-core [xorg-video-abi-19]  2:1.17.3-2
> 
> Versions of packages xserver-xorg-video-nvidia recommends:
> pn  nvidia-driver
> ii  nvidia-kernel-dkms   340.96-4
> pn  nvidia-settings  
> ii  nvidia-vdpau-driver  340.96-4
> 
> Versions of packages xserver-xorg-video-nvidia suggests:
> ii  nvidia-kernel-dkms  340.96-4

Hi,

The system report says you do not have nvidia-driver installed. Also you
said you just installed that single package. Is that intentional? You
need to install nvidia-driver for the stack to work.

The nvidia-driver meta-package will pull in everything you need,
including the GL libraries.
Please install it and report back.

Kind regards,
Luca Boccassi



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

Bug#816287: [/master] Add cups-bsd as alternative dependency to lpr (Closes: #816287).

[Michal Čihař]

tag 816287 pending
thanks

Date: Mon Feb 29 17:20:06 2016 +0100
Author: Michal Čihař 
Commit ID: 2b281524d4a71950bfa85d04a9c4616d9dcd7f7d
Commit URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/geeqie.git;a=commitdiff;h=2b281524d4a71950bfa85d04a9c4616d9dcd7f7d
Patch URL: 
http://anonscm.debian.org/gitweb/?p=collab-maint/geeqie.git;a=commitdiff_plain;h=2b281524d4a71950bfa85d04a9c4616d9dcd7f7d

Add cups-bsd as alternative dependency to lpr (Closes: #816287).

  

Bug#816287: geeqie: please do NOT Recommends lpr

[Martin-Éric Racine]

2016-02-29 18:17 GMT+02:00 Michal Čihař :
> Hi
>
> Dne 29.2.2016 v 15:30 Martin-Éric Racine napsal(a):
>> Package: geeqie
>> Version: 1:1.2-3+b1
>> Severity: normal
>>
>> Please remove the Recommends on 'lpr'. People usually have some printer 
>> daemon already installed (usually CUPS) and pulling an extra one is not 
>> desirable. Thanks!
>
> There is no reason why lpr should pull in another server, it should
> install cups-bsd if you're using cups already...

It did not install cups-bsd, it installed lpr.

> See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750070 why
> it's there.

Noted.

Martin-Éric

Bug#816276: systemd: shutdown fails if swap can't be deactivated

[Christian Pernegger]

2016-02-29 17:20 GMT+01:00 Michael Biebl :
> This looks like a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805133

Indeed it does, I do apologise. In my defence, I did filter for "swap"
in reportbug and it didn't show up (still doesn't, actually).

Thanks,
Christian

Bug#816300: imagemagick: Desktop file does not open the Imagemagick application

[Ross Gammon]

Package: imagemagick
Version: 8:6.8.9.9-5ubuntu2
Severity: important
Tags: patch

Dear Maintainer,

Imagemagick provides a desktop file for the display command that is supposed to
show the menu of commands you can see in the screenshot on the package tracker.

Unfortunately, from the menu in XFCE nothing happens. The attached patch to set
Terminal=true instead of false fixes it.

Regards,

Ross



-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
compare:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
convert:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
composite:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
display:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
identify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
import:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
montage:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org
stream:  ImageMagick 6.8.9-9 Q16 x86_64 2015-08-06 http://www.imagemagick.org

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-30-generic (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 imagemagick depends on:
ii  imagemagick-6.q16  8:6.8.9.9-5ubuntu2

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information
--- debian/display.desktop.in	2016-01-17 21:45:14.0 +0100
+++ debian/display.desktop.in_new	2016-02-29 17:36:50.696800036 +0100
@@ -5,10 +5,10 @@
 Comment[fr]=Affiche et édite des fichiers images
 Comment[pt]=Exiba e edite arquivos de imagem
 Exec=/usr/lib/$(DEB_HOST_MULTIARCH)/ImageMagick-$(DEB_UPSTREAM_VERSION_DROPREVISION)/bin-$(QUANTUMDEPTH)/display %f
-Terminal=false
+Terminal=true
 Icon=display-im$(IMVERSION).$(LCQUANTUMDEPTH)
 Type=Application
 Categories=Graphics;
 Keywords=Image;Slideshow;View;Transform;Enhance;F/X;Special Effects
 Keywords[fr]=Image;Diaporama;Visualiser;Transformer;Améliorer;Effets spéciaux
-MimeType=image/avs;image/bie;image/x-ms-bmp;image/cmyk;image/dcx;image/eps;image/fax;image/fits;image/gif;image/gray;image/jpeg;image/pjpeg;image/miff;image/mono;image/mtv;image/x-portable-bitmap;image/pcd;image/pcx;image/pdf;image/x-portable-graymap;image/pict;image/png;image/x-portable-anymap;image/x-portable-pixmap;image/ps;image/rad;image/x-rgb;image/rgba;image/rla;image/rle;image/sgi;image/sun-raster;image/targa;image/tiff;image/uyvy;image/vid;image/viff;image/x-xbitmap;image/x-xpixmap;image/x-xwindowdump;image/x-icon;image/yuv;
\ No newline at end of file
+MimeType=image/avs;image/bie;image/x-ms-bmp;image/cmyk;image/dcx;image/eps;image/fax;image/fits;image/gif;image/gray;image/jpeg;image/pjpeg;image/miff;image/mono;image/mtv;image/x-portable-bitmap;image/pcd;image/pcx;image/pdf;image/x-portable-graymap;image/pict;image/png;image/x-portable-anymap;image/x-portable-pixmap;image/ps;image/rad;image/x-rgb;image/rgba;image/rla;image/rle;image/sgi;image/sun-raster;image/targa;image/tiff;image/uyvy;image/vid;image/viff;image/x-xbitmap;image/x-xpixmap;image/x-xwindowdump;image/x-icon;image/yuv;

Bug#816303: [powerpc] mca_osc_pt2pt.so: undefined symbol: OPAL_THREAD_ADD64

[Yaroslav Halchenko]

Package: libopenmpi1.6
Version: 1.6.5-11
Severity: important
Tags: upstream

While building fresh mpi4py 2.0.0 tests failed on powerpc with

testFenceAll (test_rma.TestRMASelf) ... ok
testFlushSync (test_rma.TestRMASelf) ... /usr/bin/python2.7: symbol lookup 
error: /usr/lib/openmpi/lib/openmpi/mca_osc_pt2pt.so: undefined symbol: 
OPAL_THREAD_ADD64
debian/rules:89: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 127
make[1]: Leaving directory '/«PKGBUILDDIR»'

full log:
https://buildd.debian.org/status/fetch.php?pkg=mpi4py=powerpc=2.0.0-1=1456765171

might be related to
https://github.com/open-mpi/ompi/issues/1162
although that one concerns with arm

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

Kernel: Linux 4.4.0-rc1+ (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 libopenmpi1.6 depends on:
ii  libc6 2.21-6
ii  libcr00.8.5-2.2
ii  libgcc1   1:5.3.1-5
ii  libgfortran3  5.3.1-5
ii  libhwloc5 1.11.2-2
ii  libibverbs1   1.1.8-1.1
ii  libltdl7  2.4.2-1.11
ii  libquadmath0  5.3.1-5
ii  libstdc++65.3.1-5

libopenmpi1.6 recommends no packages.

libopenmpi1.6 suggests no packages.

-- no debconf information

Bug#814240: systemd triggers break upgrades within unstable

[Manuel A. Fernandez Montecelo]

Hi again,

2016-02-29 13:17 Zack Weinberg:

On Tue, Feb 23, 2016 at 8:44 AM, Manuel A. Fernandez Montecelo
 wrote:


Thanks for the report.  Do you have the logs around for those
installations attempts, of aptitude (the relevant section in
/var/log/aptitude*), apt (same for /var/log/apt/*) and dpkg
(/var/log/dpkg.log)?


Attached.  I was having trouble finding the right bit of the logs, but
conveniently the problem happened again this morning.  The logs start
immediately after upgrading aptitude to 0.7.6-1, which I did
separately from everything else.


Also, please attach the result of:

apt-config dump


Ok.


Thanks for providing the information.



DPkg::NoTriggers "true";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";


After talking about this bug a few days ago with APT Deities (David
Kalnischkies, in this case), he told me that apt doesn't use "dpkg
--triggers-only" by default.

He believes that apt /could/ issue that command when
"DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
possibly other similar ones (he didn't mention the specifics).

Such options as marked as experimental and dangerous (man apt.conf) so
maybe they are better left disabled unless there's a specific need to
use them.

If you disable and things keep working normally, please report back to
this bug.


Other than that, I am running this reply through deity@ so APT folks can
take a look, give further insight/recommendations, reassign/clone the
bug to src:apt if they want to follow-up, etc.

In principle, there is nothing that aptitude can do about this (other
than disabling the options behind the user's back), so if there's no
input after some time I will close the bug.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#816298: firmware-realtek: Realtek firmware RTL8821AE leads to kernel panic

[Vittorio Malaguti]

Package: firmware-realtek
Version: 20160110-1~bpo8+1
Severity: important

Dear Maintainer,

my wireless card is a RTL8821AE Realtek device. 
The first main problem is that when I turn off the wireless 
(for powersavings purposes) and then I turn it on, the computer hangs.
An hardware turn-off is then required.


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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.120

-- no debconf information

Bug#816280: Binary incompatibility between debugperl and perl

[Nick Wellnhofer]

On 29/02/2016 16:52, Dominic Hargreaves wrote:

Just to be clear, do you mean you don't think that your issue
will be fixed by these patches in blead?

http://perl5.git.perl.org/perl.git/commit/5ca5a62834a7fccb204c7fd4b35a11873d1bdd3b
http://perl5.git.perl.org/perl.git/commit/0419d9784dfda8adf6980bd60e782b144126dd72

(from https://rt.perl.org/Ticket/Display.html?id=127212)


This fix should work unless there are other interpreter variables that are 
only enabled with -DDEBUGGING. But I think that my proposal to move debugging 
variables to the end of the struct is better. At least `random_state` which 
can be accessed directly from XS code should be moved forward.


Nick

Bug#816301: samba 2:4.3.3 refuses to start

[Francesco Potortì]

Package: samba
Version: 2:4.3.3+dfsg-2+b1
Severity: important

Today, when upgrading from 2:4.1.17+dfsg-4 to 2:4.3.3+dfsg-2+b1, I found
that samba, winbind and libpam-winbind were not configured.  It looked
like a circular dependency, so I tried to force configuration:

|tucano:~# dpkg --force-depends --configure --pending
|Setting up samba (2:4.3.3+dfsg-2+b1) ...
|Job for smbd.service failed because the control process exited with error 
code. See "systemctl status smbd.service" and "journalctl -xe" for details.
|invoke-rc.d: initscript smbd, action "start" failed.
|dpkg: error processing package samba (--configure):
| subprocess installed post-installation script returned error exit status 1
|dpkg: winbind: dependency problems, but configuring anyway as you requested:
| winbind depends on samba (= 2:4.3.3+dfsg-2+b1); however:
|  Package samba is not configured yet.
|
|Setting up winbind (2:4.3.3+dfsg-2+b1) ...
|Job for winbind.service failed because the control process exited with error 
code. See "systemctl status winbind.service" and "journalctl -xe" for details.
|invoke-rc.d: initscript winbind, action "start" failed.
|dpkg: error processing package winbind (--configure):
| subprocess installed post-installation script returned error exit status 1
|dpkg: libpam-winbind:amd64: dependency problems, but configuring anyway as you 
requested:
| libpam-winbind:amd64 depends on winbind (= 2:4.3.3+dfsg-2+b1); however:
|  Package winbind is not configured yet.
|
|Setting up libpam-winbind:amd64 (2:4.3.3+dfsg-2+b1) ...
|debconf: unable to initialize frontend: Dialog
|debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
|debconf: falling back to frontend: Readline
|Processing triggers for libc-bin (2.21-9) ...
|Errors were encountered while processing:
| samba
| winbind

As you sse, it worked for libpam-winbind, but not for winbind and samba.  Here 
is some more info:

|tucano:~# systemctl status winbind.service
|● winbind.service - LSB: start Winbind daemon
|   Loaded: loaded (/etc/init.d/winbind; bad; vendor preset: enabled)
|   Active: failed (Result: exit-code) since Mon 2016-02-29 13:52:22 CET; 19min 
ago
| Docs: man:systemd-sysv-generator(8)
|
|Feb 29 13:52:22 tucano.isti.cnr.it systemd[1]: Starting LSB: start Winbind 
daemon...
|Feb 29 13:52:22 tucano.isti.cnr.it winbind[13309]: Starting the Winbind 
daemon: winbind failed!
|Feb 29 13:52:22 tucano.isti.cnr.it systemd[1]: winbind.service: Control 
process exited, code=exited status=1
|Feb 29 13:52:22 tucano.isti.cnr.it systemd[1]: Failed to start LSB: start 
Winbind daemon.
|Feb 29 13:52:22 tucano.isti.cnr.it systemd[1]: winbind.service: Unit entered 
failed state.
|Feb 29 13:52:22 tucano.isti.cnr.it systemd[1]: winbind.service: Failed with 
result 'exit-code'.

|tucano:~# journalctl -xe
|-- The start-up result is done.
|Feb 29 14:12:06 tucano.isti.cnr.it systemd[1]: Starting LSB: start Samba 
SMB/CIFS daemon (smbd)...
|-- Subject: Unit smbd.service has begun start-up
|-- Defined-By: systemd
|-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
|--
|-- Unit smbd.service has begun starting up.
|Feb 29 14:12:06 tucano.isti.cnr.it smbd[20294]: Starting SMB/CIFS daemon: smbd 
failed!
|Feb 29 14:12:06 tucano.isti.cnr.it systemd[1]: smbd.service: Control process 
exited, code=exited status=1
|Feb 29 14:12:06 tucano.isti.cnr.it systemd[1]: Failed to start LSB: start 
Samba SMB/CIFS daemon (smbd).
|-- Subject: Unit smbd.service has failed
|-- Defined-By: systemd
|-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
|--
|-- Unit smbd.service has failed.
|--
|-- The result is failed.
|Feb 29 14:12:06 tucano.isti.cnr.it systemd[1]: smbd.service: Unit entered 
failed state.
|Feb 29 14:12:06 tucano.isti.cnr.it systemd[1]: smbd.service: Failed with 
result 'exit-code'.
|Feb 29 14:12:06 tucano.isti.cnr.it polkitd(authority=local)[2419]: 
Unregistered Authentication Agent for unix-process:20288:1lines 1799-1821/1821 
(END)q

Now I am stuck...


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (101, 
'unstable')
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=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.18.4
ii  libbsd0   0.8.2-1
ii  libc6 2.21-9
ii  libcap2   1:2.24-12
ii  libldb1   2:1.1.26-1
ii  libpam-modules1.1.8-3.2
ii  libpam-runtime1.1.8-3.2
ii  libpopt0  1.16-10
ii  libpython2.7  2.7.11-4
ii  libtalloc22.1.5-1
ii  libtdb1   1.3.8-1
ii  libtevent00.9.26-3
ii  libwbclient0  2:4.3.3+dfsg-2+b1
ii  lsb-base  9.20160110
ii  procps  

Bug#718243: aptitude: always happens when some time has passed since the last update run

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo
Control: close -1


2016-02-29 16:09 Dr. Axel Stammler:

On Sat 2015-12-12 15.35.43, Manuel A. Fernandez Montecelo wrote:

Does it still continue to happen in your system?

If yes, can you test if it still happens with apt 1.1 recently uploaded
to unstable?


Hi, Daniel,

the problem seems to have disappeared − I have been watching for it but, 
luckily, without
result.


OK, thanks for the confirmation.

Closing the bug then.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#809228: It would be nice to have 1.60 in sid

[Mario Lang]

"Steve M. Robbins"  writes:

> On Fri, 26 Feb 2016 22:03:37 +0100 Mario Lang  wrote:
>> Hi.
>> 
>>  Is there anything in particular I could help you with to get it
>> done?
>
> Yes.  I have the new package in the svn and it is building.  But there are a 
> zillion lintian complaints about missing sources:
>
> E: boost1.60 source: source-is-missing 
> libs/sort/doc/doxygen/html/search/all_0.js line length is 258 characters 
> (>256)
>
> If you have some time to send patches for this, would be appreciated.  I 

Unfortunately, I am about to leave on a trip to Italy.
Saturday at the earliest.

> myself have no patience for this and will end up removing the doc package 
> entirely to fix it.

While I try to understand the motivation behind these efforts, I
also totally understand your frustration.  These are tasks that totally
waste our time, likely for absolutely no benefit at all.

-- 
CYa,
  ⡍⠁⠗⠊⠕