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#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#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#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#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#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#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#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#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#749833: scilab: Scilab include non-free codes

[Sylvestre Ledru]

Le 29/02/2016 à 09:54, Maximiliano Curia a écrit :
> 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,

Clément, François, could you help here?
Thanks

Sylvestre

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

[PICCA Frederic-Emmanuel]

Hello Ghislain

>* 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.

in that case can you create a real fonts package in order to be consistant with 
all other font packages
Here the font policy[1]

thanks

Fred

Ps; I will be on vacation starting now :)

[1] https://wiki.debian.org/Fonts/PackagingPolicy

Bug#816247: general: hardening distro is an afterthought

[Samuel Thibault]

Richard Jasmin, on Sun 28 Feb 2016 22:42:00 -0600, wrote:
>(With hardened by default config for source builds)

Hardening does break some packages, you can't just go away with forcing
it.

Samuel

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

[Ghislain Vaillant]

The Spyder Development Team is not upstream of this font actually. So I
don't think creating a font package from this source package is the
right solution, is it?

What I thought of doing was to keep the embedded copy of the font for
now and file a RFP for elusive-iconfont. I don't think I'll have time to
work on yet another source package at this time.

Ghis


On 29/02/16 09:29, PICCA Frederic-Emmanuel wrote:

Hello Ghislain


* 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.


in that case can you create a real fonts package in order to be consistant with 
all other font packages
Here the font policy[1]

thanks

Fred

Ps; I will be on vacation starting now :)

[1] https://wiki.debian.org/Fonts/PackagingPolicy

Bug#816267: RM: ganeti [mips64el] -- ROM; mips64el lacks build-dependencies

[Apollon Oikonomopoulos]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Please remove the ganeti-htools-2.15 and ganeti-haskell-2.15 mips64el 
packages from unstable as mips64el lacks some necessary Haskell 
Build-Dependencies. I don't expect ganeti is being run on mips64el 
systems anyway. 

Regards,
Apollon

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Raphael Hertzog]

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?

Cheers,

On Tue, 23 Feb 2016, Alexis Murzeau wrote:
> Hi,
> 
> I have the same traceback as Zdravko in Message #121 (NULL pointer
> dereference at RIP=0x81063682, __change_page_attr_set_clr+0x242).
> 
> If I add "efi=old_map" parameter to kernel cmdline, the kernel boots
> fine.
> 
> Also, this might help Norbert to have a traceback printed: using
> "quiet earlyprintk=efi,keep" kernel cmdline options will print only
> the traceback (so it should be faster to get the kernel to the crash
> traceback, if the cause is really a crash).
> 
> 
> After compiling several kernels, I narrowed down the crash to the
> patch "x86-efi-build-our-own-page-table-structures.patch".
> 
> Without this patch, the kernel boots fine (dmesg output in attachment
> dmesg_linux-4.4.2_[...].txt)
> 
> With this patch, I get the crash in efi_call (photo of
> "earlyprintk=efi,keep" output in attachment
> traceback_linux-4.4.2_with_patch_[...].jpg).
> 
> I also added 4 printk to add information before the crash when
> calling efi_call_phys with efi_phys.set_virtual_address_map (see also
> "additionnal_printk.diff" in attachment). (Not sure if it can help)
> 
> When I added these printk, the traceback stop at efi_call
> (__change_page_attr_set_clr isn't anymore in the traceback) but RIP
> is still the same as without these changes.
> 
> See also the traceback I get in attachment
> traceback_linux-4.4.2-3_unmodified.jpg with the current 4.4 kernel
> (version 4.4.2-3 unmodified)
> 
> Also, let me know if a new bug should be opened for this.
> 
> Thanks,
> Alexis Murzeau

> [0.00] microcode: CPU0 microcode updated early to revision 0x1c, date 
> = 2015-02-26
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.2-amubtdx-custom (root@Debian2) (gcc version 
> 5.3.1 20160220 (Debian 5.3.1-9) ) #4 SMP Tue Feb 23 18:02:39 CET 2016
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.2-amubtdx-custom 
> root=UUID=be5f2ba3-ec9a-4645-8db5-eb9a6ddfd226 ro quiet crashkernel=128M@32M
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
> bytes, using 'standard' format.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x00087fff] usable
> [0.00] BIOS-e820: [mem 0x00088000-0x000b] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
> [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
> [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
> [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
> [0.00] BIOS-e820: [mem 0x40005000-0xa4da] usable
> [0.00] BIOS-e820: [mem 0xa4db-0xa61a] reserved
> [0.00] BIOS-e820: [mem 0xa61b-0xaa7befff] usable
> [0.00] BIOS-e820: [mem 0xaa7bf000-0xaa8adfff] type 20
> [0.00] BIOS-e820: [mem 0xaa8ae000-0xaa8aefff] reserved
> [0.00] BIOS-e820: [mem 0xaa8af000-0xaa8bcfff] type 20
> [0.00] BIOS-e820: [mem 0xaa8bd000-0xaa8bdfff] reserved
> [0.00] BIOS-e820: [mem 0xaa8be000-0xaa8c4fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8c5000-0xaa8c5fff] reserved
> [0.00] BIOS-e820: [mem 0xaa8c6000-0xaa8d5fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8d6000-0xaa8d6fff] reserved
> [0.00] BIOS-e820: [mem 0xaa8d7000-0xaa8f4fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8f5000-0xaa937fff] reserved
> [0.00] BIOS-e820: [mem 0xaa938000-0xaa9befff] type 20
> [0.00] BIOS-e820: [mem 0xaa9bf000-0xaaebefff] reserved
> [0.00] BIOS-e820: [mem 0xaaebf000-0xaafbefff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xaafbf000-0xaaffefff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xaafff000-0xaaff] usable
> [0.00] BIOS-e820: [mem 0xab00-0xaf9f] reserved
> [0.00] BIOS-e82

Bug#814943: mpi-default-dev: provide the list of architectures for each MPI implementation

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Mattia,

Le 27/02/2016 12:29, Mattia Rizzolo a écrit :
>> The feature that I would need for e.g. the yorick package is the
>> list of architectures on which each implementation is available.
>> This is what I currently check and hardcode by hand. I guess this
>> is also what other people do when they provide packages with
>> distinct names for each flavour.

Yes, it is certainly loosing of its usefulness...

> Guess I can do that too. I personally think it's kind of pointless
> as of now, where mpich is available everywhere and openmpi is
> available on all but m68k (not considering powerpcspe that
> yesterday has been resurrected from ashes…)
> 
> Anyway, What about:
> 
> https://anonscm.debian.org/cgit/debian-science/packages/mpi-defaults.g
it/commit/?id=57d37c200258e7512733d7ee36aade8bf806ffea
>
>  ?

Perfect, thanks.

> I do think this is a bigger improvment than hardcoding this in a
> donzen of packages, everyone with its own data source.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW1BQXAAoJEJOUU0jg3ChAR5cQAK8oGwvRameitL5ZMiVAAAki
LzJNYaBUJIupsg5/WsUyd/4arzJOkXPaWOOyWCyo5f79DjEXmYXfC/9oZsZXIKtu
0XJUZQFVS9UaieWhPRLTDcUbEA77wSCl8qOgpRDtPPdVgN69au6RajKe8TPx87GY
BJVrvO+4du3P9hN8PcXCg/dIrxJ+LI88iURPzFPlbsT4THokH1Z4YwkuVPkNXRxp
4t3XOjcPLYa4V5IBJZGCbQ02xXyzsdHGYid3IDlLhGAHO59jK68IHAGlwa48eZrw
eR7e+zOwmA14+ViEqD24DgQU8yOCgZDVU5kGTZ4yDXLWatZdp+9yV4AKr/UNOFoI
yPYFmSI55ooOtydIJwwzIOMMhrzAn4t90m7nfJXCqkw3zRsRiZb8LBnzL5TvUQR8
92rgElndITHA+QXBCkdGqNaeHKGi6wTRHdy030UTOlqUglfUUaQLpQGto7NbPm93
7l6SwKwTiMS+J/BxAyMt9rqAUpj2YyNkpwGVHRdue8EByTAWnQV2X6ksrBpHK81w
RNSHUkn3a4ydKr4YJO2NlyNl+m7fuhu4J3gd+2JMaApuJAL6dSYaZJ7BSvLYm31m
RYQB8s9ux6ikqKIjRA4dKjsbgEqqqNCzrb5rRrxAgoy70mecJBx/EuMR7ibKSu2z
Kvprrazm7EM7zLuhxR73
=OgYk
-END PGP SIGNATURE-

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

[PICCA Frederic-Emmanuel]

> The Spyder Development Team is not upstream of this font actually. So I
> don't think creating a font package from this source package is the
> right solution, is it?

No you are right

I looked at the elusive content

/tmp$ unzip elusive-icons-2.0.0.zip 
Archive:  elusive-icons-2.0.0.zip
   creating: elusive-icons-2.0.0/
   creating: elusive-icons-2.0.0/css/
  inflating: elusive-icons-2.0.0/css/elusive-icons.css  
  inflating: elusive-icons-2.0.0/css/elusive-icons.min.css  
   creating: elusive-icons-2.0.0/fonts/
  inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.eot  
  inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.svg  
  inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.ttf  
  inflating: elusive-icons-2.0.0/fonts/elusiveicons-webfont.woff  
   creating: elusive-icons-2.0.0/less/
  inflating: elusive-icons-2.0.0/less/animated.less  
  inflating: elusive-icons-2.0.0/less/bordered-pulled.less  
  inflating: elusive-icons-2.0.0/less/core.less  
  inflating: elusive-icons-2.0.0/less/elusive-icons.less  
  inflating: elusive-icons-2.0.0/less/fixed-width.less  
  inflating: elusive-icons-2.0.0/less/icons.less  
  inflating: elusive-icons-2.0.0/less/larger.less  
  inflating: elusive-icons-2.0.0/less/list.less  
  inflating: elusive-icons-2.0.0/less/mixins.less  
  inflating: elusive-icons-2.0.0/less/path.less  
  inflating: elusive-icons-2.0.0/less/rotated-flipped.less  
  inflating: elusive-icons-2.0.0/less/stacked.less  
  inflating: elusive-icons-2.0.0/less/variables.less  
   creating: elusive-icons-2.0.0/scss/
  inflating: elusive-icons-2.0.0/scss/_animated.scss  
  inflating: elusive-icons-2.0.0/scss/_bordered-pulled.scss  
  inflating: elusive-icons-2.0.0/scss/_core.scss  
  inflating: elusive-icons-2.0.0/scss/_fixed-width.scss  
  inflating: elusive-icons-2.0.0/scss/_icons.scss  
  inflating: elusive-icons-2.0.0/scss/_larger.scss  
  inflating: elusive-icons-2.0.0/scss/_list.scss  
  inflating: elusive-icons-2.0.0/scss/_mixins.scss  
  inflating: elusive-icons-2.0.0/scss/_path.scss  
  inflating: elusive-icons-2.0.0/scss/_rotated-flipped.scss  
  inflating: elusive-icons-2.0.0/scss/_stacked.scss  
  inflating: elusive-icons-2.0.0/scss/_variables.scss  
  inflating: elusive-icons-2.0.0/scss/elusive-icons.scss  

There is plenty of files I do not know what to do with, but I amnot part of the 
font team.

> What I thought of doing was to keep the embedded copy of the font for
> now and file a RFP for elusive-iconfont. I don't think I'll have time to
> work on yet another source package at this time.

I understand (welcome onboard ;). In that case just fill the RFP.
The license is DFSG free :) . And just ping the font team in order to make them 
aware of our problem :).


Cheers

Fred

Bug#816268: ifupdown: init script /etc/init.d/networking run ifup before devs exist: improper use of "udevadm settle"

[J Mo]

Package: ifupdown
Version: 0.8.8
Severity: important

Hello

I have been having a problem where my network devices are not being configured 
properly on boot. I suspect that my problems are caused in a fundamental 
oversight 
in the /etc/init.d/networking init script, though I'm not sure.

/etc/init.d/networking calls "udevadm settle" to determine when device drivers 
are 
loaded and network devices exist. However, that's not what "udevadm settle" 
does. 
"udevadm settle" returns before drivers have finished loading and before 
devices 
exist. As a result, it is possible for ifup to try and start network interfaces 
on devices which don't exist yet.

I don't know if ifup itself may have some internal checking to make sure that 
devices actually exist. If it does, than this checking is insufficient. If it 
does not, then the situation is even worse than I suspected.

In my particular case, I have a bridge interface with eth0 and wlan0 members. I 
find it common that the wlan0 interface has not finished loading the driver 
when the bridge attempts to start. I have several "pre-up" commands required 
for 
my setup, and they fail because the devices onto which the commands rely don't 
yet exist (iw or ethtool as examples).

The solution to this problem is that the init script must wait for these 
network 
devices to exist. Before they exist, it does not seem appropriate for ifup to 
be 
called.

It is notable that in my particular case, ifquery simply returns the name of my 
bridge interface, br0, and not the member interfaces (eth0 and wlan0, since 
they 
have no normal config stanzas). Thus, ifquery will probably need to know about 
these interfaces for the init script to wait for them.

One possibility is that I should add a config like this, but this might not be 
a great idea for all types of special interface configs (LACP bundles come to 
mind):
auto eth0
iface eth0 inet manual

Alternatively, a new configuration parameter indicating a device dependency, 
such 
as "waitdev wlan0" might be appropriate.

I don't know what the right solution is here. Feedback would be apreciated.



For now, as a workaround, I can do something horrible like this in my bridge 
interface config:
pre-up while ! [ -e /sys/class/net/wlan0 ] ; do echo "dev wlan0 not 
ready!" ; sleep 0.25 ; done



Please advise



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

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

Versions of packages ifupdown depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.25
ii  iproute2 4.3.0-1
ii  libc62.21-6
ii  lsb-base 9.20160110

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.3-5

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- debconf-show failed

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#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#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#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#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#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#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#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#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#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#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#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=  

+ localised_name=conkeror
+ 

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#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#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#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#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#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#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&view=markup

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#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&rev=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#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#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#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#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#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#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#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#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#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#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#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&arch=s390x&ver=1.3.1%2Bhg20131106-2%2Bb4&stamp=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#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#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#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#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#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#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#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#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#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&arch=s390x&ver=1.3.1%2Bhg20131106-2%2Bb4&stamp=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#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

Hi,

Steven Chamberlain wrote:
> Attached are all the kfreebsd fixes in a single debdiff, based on
> current pkg-net-snmp Git master.  I hope this is much easier.

I'm sorry, there was a piece missing from that debdiff.
I attach a corrected version now.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From 003b7f74fc602b92b8d6f6d9e5dcfee551a93c6e Mon Sep 17 00:00:00 2001
From: Steven Chamberlain 
Date: Mon, 29 Feb 2016 13:39:57 +
Subject: [PATCH] kfreebsd support (Closes: #810982)

  * Fix a typo in 26_kfreebsd.patch
  * Add 27_kfreebsd.patch: (Closes: #810982)
- Add missing dependency of mibII/icmp on kfreebsd
- Add kfreebsd definitions not in GNU libc's icmp6.h
  * Remove obsolete Fix-kfreebsd-builds-with-kernel-headers-10.patch
  * Re-enable IPv6 on kfreebsd (Closes: #765846)
  * Build with the libbsd overlay on kfreebsd, for nlist
---
 debian/changelog   | 10 ++
 debian/patches/26_kfreebsd.patch   | 22 
 debian/patches/27_kfreebsd.patch   | 25 +
 ...ix-kfreebsd-builds-with-kernel-headers-10.patch | 41 --
 debian/patches/series  |  2 +-
 debian/rules   |  4 ++-
 6 files changed, 45 insertions(+), 59 deletions(-)
 create mode 100644 debian/patches/27_kfreebsd.patch
 delete mode 100644 debian/patches/Fix-kfreebsd-builds-with-kernel-headers-10.patch

diff --git a/debian/changelog b/debian/changelog
index cd8a1bd..94bf7e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 net-snmp (5.7.3+dfsg-2) UNRELEASED; urgency=medium
 
+  [ Hideki Yamane ]
   * debian/patches
 - add Bug-788964-net-snmp-snmp_pdu_parse-DoS.patch (Closes: #788964)
 - add 0026-fix-Bug-785380-incorrect-date-format.patch (Closes: #785380)
@@ -14,6 +15,15 @@ net-snmp (5.7.3+dfsg-2) UNRELEASED; urgency=medium
   * debian/snmp.preinst
 - revert "killall", it is unnecessary anymore (Closes: #781257)
 
+  [ Steven Chamberlain ]
+  * Fix a typo in 26_kfreebsd.patch
+  * Add 27_kfreebsd.patch: (Closes: #810982)
+- Add missing dependency of mibII/icmp on kfreebsd
+- Add kfreebsd definitions not in GNU libc's icmp6.h
+  * Remove obsolete Fix-kfreebsd-builds-with-kernel-headers-10.patch
+  * Re-enable IPv6 on kfreebsd (Closes: #765846)
+  * Build with the libbsd overlay on kfreebsd, for nlist
+
  -- Hideki Yamane   Thu, 18 Jun 2015 06:43:28 +0900
 
 net-snmp (5.7.3+dfsg-1) unstable; urgency=medium
diff --git a/debian/patches/26_kfreebsd.patch b/debian/patches/26_kfreebsd.patch
index d758e17..60fa7a0 100644
--- a/debian/patches/26_kfreebsd.patch
+++ b/debian/patches/26_kfreebsd.patch
@@ -1,14 +1,4 @@
-From: Net-SNMP Packaging Team 
-Date: Thu, 18 Jun 2015 06:12:05 +0900
-Subject: _kfreebsd
-
 Preliminary support for kfreebsd.

- agent/mibgroup/hardware/cpu/cpu_sysctl.c | 14 +++---
- 1 file changed, 7 insertions(+), 7 deletions(-)
-
-diff --git a/agent/mibgroup/hardware/cpu/cpu_sysctl.c b/agent/mibgroup/hardware/cpu/cpu_sysctl.c
-index 5ecb68e..f0899c2 100644
 --- a/agent/mibgroup/hardware/cpu/cpu_sysctl.c
 +++ b/agent/mibgroup/hardware/cpu/cpu_sysctl.c
 @@ -12,7 +12,7 @@
@@ -20,7 +10,7 @@ index 5ecb68e..f0899c2 100644
  #include 
  #if !defined(CPUSTATES)
  #include 
-@@ -89,7 +89,7 @@ void init_cpu_sysctl( void ) {
+@@ -89,7 +89,7 @@
  #elif defined(KERN_CPTIME)/* OpenBSD */
  #define NETSNMP_KERN_CPU  KERN_CPTIME
  
@@ -29,7 +19,7 @@ index 5ecb68e..f0899c2 100644
  #define NETSNMP_KERN_MCPU 1/* Enable support for multi-cpu stats. Valid for FreeBSD >=6.4, >=7.1, >=8.0 and beyond */
  #define NETSNMP_KERN_MCPU_TYPE NETSNMP_CPU_STATS
  
-@@ -129,7 +129,7 @@ void init_cpu_sysctl( void ) {
+@@ -129,7 +129,7 @@
  #define NETSNMP_VM_STATS_TYPE  struct uvmexp
  #endif  /* VM_UVMEXP2 || VM_UVMEXP */
  
@@ -38,12 +28,12 @@ index 5ecb68e..f0899c2 100644
  #define NETSNMP_VM_STATS   VM_METER
  #define NETSNMP_VM_STATS_TYPE  struct vmmeter
  #define NS_VM_INTR		v_intr
-@@ -169,10 +169,10 @@ int netsnmp_cpu_arch_load( netsnmp_cache *cache, void *magic ) {
+@@ -169,10 +169,10 @@
   */
  NETSNMP_CPU_STATS cpu_stats[CPUSTATES];
  size_t cpu_size  = sizeof(cpu_stats);
 -#if !defined(__FreeBSD__) && !defined(__NetBSD__)
-+#if !defined(__FreeBSD__) || defined(__FreeBSD_kernel__) && !defined(__NetBSD__)
++#if !defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) && !defined(__NetBSD__)
  intcpu_mib[] = { CTL_KERN, NETSNMP_KERN_CPU };
  #endif
 -#ifdef __FreeBSD__
@@ -51,7 +41,7 @@ index 5ecb68e..f0899c2 100644
  static int cp_times = -1;
  #endif
  #ifdef KERN_CPTIME2
-@@ -189,7 +189,7 @@ int netsnmp_cpu_arch_load( netsnmp_cache *cache, void *magic ) {
+@@ -189,7 +189,7 @@
  size_t mem_size  = sizeof(NETSNMP_VM_STATS_TYPE);
  netsnmp_cpu_info *cpu = netsnmp_cpu_get_byIdx( -1, 0 );
  
@@ -60,7 +50,7 @@ index 5ecb68e..f0899c2 100644
  sy

Bug#816286: lsof: Latest stable kernels issue WARN_ON for some uses

[Athanasius]

Package: lsof
Version: 4.86+dfsg-1
Severity: minor

Dear Maintainer,

  I just updated a web server to latest 3.14 stable kernel, 3.14.62,
which includes a patch tightening up ptrace permissions.

  Now the use of "/usr/bin/lsof -w -l +d /var/lib/php5" by
/etc/cron.d/php5 to clean up sessions causes a kernel WARN_ON to be
spammed to the log.

Feb 29 13:36:14 www kernel: [48425.679328] [ cut here ]
Feb 29 13:36:14 www kernel: [48425.679753] WARNING: CPU: 0 PID: 13503 at 
kernel/ptrace.c:233 __ptrace_may_access+0x13a/0x150()
Feb 29 13:36:14 www kernel: [48425.680540] denying ptrace access check without 
PTRACE_MODE_*CREDS
Feb 29 13:36:14 www kernel: [48425.681090] Modules linked in: nfsv3 nfsd 
auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc ipv6 xt_nat iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter 
ip_tables floppy virtio_balloon virtio_net
Feb 29 13:36:14 www kernel: [48425.683176] CPU: 0 PID: 13503 Comm: lsof 
Tainted: GW3.14.62-fysh-kvmguest #6
Feb 29 13:36:14 www kernel: [48425.683891] Hardware name: Bochs Bochs, BIOS 
Bochs 01/01/2007
Feb 29 13:36:14 www kernel: [48425.684415]  0286  
8850ade4 0007
Feb 29 13:36:14 www kernel: [48425.684536]  88051bf1fd88 0009 
8803fe81 0001
Feb 29 13:36:14 www kernel: [48425.684536]  8805fd8b50a0 0001 
 7ffa0012ee50
Feb 29 13:36:14 www kernel: [48425.684536] Call Trace:
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
dump_stack+0x5e/0x7a
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
warn_slowpath_common+0x81/0xb0
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
warn_slowpath_fmt+0x45/0x50
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
__ptrace_may_access+0x13a/0x150
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
ptrace_may_access+0x32/0x60
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
mm_access+0x7d/0xc0
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
m_start+0x78/0x1e0
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
do_filp_open+0x47/0xb0
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
seq_read+0x10f/0x380
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
vfs_read+0xa5/0x180
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
SyS_read+0x4b/0xb0
Feb 29 13:36:14 www kernel: [48425.684536]  [] ? 
system_call_fastpath+0x1a/0x1f
Feb 29 13:36:14 www kernel: [48425.692738] ---[ end trace f8d6c7c51a5bfc2a ]---

  Some 58 times for a single run of that command!

  I'm guessing that the version of lsof in wheezy doesn't do some
credentials setting that would prevent this WARN_ON.  Yes, I'm aware I
should really get around to upgrading this server to Jessie.

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

Kernel: Linux 3.14.62 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lsof depends on:
ii  libc6  2.13-38+deb7u10
ii  perl   5.14.2-21+deb7u2
ii  perl-modules [libperl4-corelibs-perl]  5.14.2-21+deb7u2

lsof recommends no packages.

lsof suggests no packages.

-- debconf-show failed

Bug#816205: [Pkg-php-pecl] Bug#816205: php-igbinary: Incomplete copyright information

[Ondřej Surý]

Luke, thanks for catching this. The work you do (as ftp-masters group)
is really appreciated and admired.

Somehow the "just update package to PHP 7.0" has turned into "fix the
copyrights all over the places". I'll try to do more checks when
updating more packages to PHP 7.0 packaging.

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

On Sun, Feb 28, 2016, at 20:00, Luke Faraone wrote:
> Source: php-igbinary
> Severity: serious
> Justification: §2.3
> 
> Hello,
> 
> While reviewing your package in NEW, I noticed that the license
> information for the package is incomplete. COPYING states:
> 
> Copyright (c) 2008 Sulake Dynamoid Oy, 2008-2014 Oleg Grenrus, Teddy
> Grenman,
> igbinary contributors
> 
> However, debian/copyright only indicates:
> 
> Files: *
> Copyright: 2008 Sulake Dynamoid Oy
> License: BSD-3-clause
> 
> Cheers,
> Luke Faraone
> FTP team
> 
> ___
> 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#816192: RFS: python-proselint/0.3.5-1 [ITP] -- A prose linter

[Víctor Cuadrado Juan]

On Mon, 29 Feb 2016 01:08:02 +0100 Jakub Wilk  wrote:
> Typo in the manpages:
> initiliaze -> initialize

Fixed.

> The license text in the copyright file is not correctly formated; see 
> bug #700970.

Fixed.

Many thanks for the review! :)

I have uploaded the fixes to mentors and also set up the DPMT repo in
case anyone wants to grab it from there, too:

Vcs-Git:
https://anonscm.debian.org/git/python-modules/packages/python-proselint.git
Vcs-Browser:
https://anonscm.debian.org/cgit/python-modules/packages/python-proselint.git


-- 
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#815668: Me too

[Chris Chiappa]

I'm experiencing this same problem.  I use the applet to connect to an
openconnect vpn.  I just rebuilt it to try to get a proper stack trace
(debug symbols don't appear to be available in the Debian archives),
but now it dosn't seem to reproduce.  Maybe a dependant library
changed and didn't bump a sover or something?  I'll keep it running in
the debugger in case it does decide to reproduce...

-- 

[ ch...@chiappa.net | chris.chia...@oracle.com ]
[http://www.chiappa.net/~chris/]

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

[Sergey B Kirpichev]

On Mon, Feb 29, 2016 at 02:28:08PM +0100, Ondřej Surý wrote:
> It's not how important they seem to *me*, but to the release team.
> The FTBFS on non-release archs are not "serious"

I don't see that here:
https://www.debian.org/Bugs/Developer#severities

btw, will kfreebsd release arch or not - up to the release team, I
don't think you can decide about this by yourself.  Of course, you
can "help" them by ignoring some issues.

> > 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.
> ...
> And as you can see in #814271, I fixed this bug within one week when it
> was reported. So please consider your words.

Maybe.  But to check that - package must be in an installable state
on this arch.  Otherwise, we can't be sure.

Ok, you aren't going to reconsider anything, there is no
issue and nothing to do, right?

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Matt Fleming]

On Mon, 29 Feb, at 09:34:55PM, Roger Shimizu wrote:
> 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.

Thanks Roger.

OK, that rules out an error porting the feature because all the
required patches are present.

Looking at 
traceback_linux-4.4.2_with_patch_x86-efi-build-our-own-page-table-structures.jpg
from comment #164, it appears as though the firmware is trying to
access an address that isn't mapped in our new dedicated EFI page
tables while inside of SetVirtualAddressMap().

Curiously the E280 memory map describes the range covering the
faulting IP (0xaa9462ee) as "type 20" which is a bogus E820
type and a bogus EFI memory map type.

Alexis, could you boot a kernel with CONFIG_EFI_PGT_DUMP enabled,
efi=debug on the command line and upload the dmesg output? Booting
with efi=old_map,debug should be fine (so your machine won't crash).

Bug#813237: transition: ruby2.3: another round of binNMUs

[Antonio Terceiro]

Hi,

Please binNMU the following packages:

unicorn
ruby-oj
passenger

I will now test the switch to ruby2.3 as default in experimental, and
test rebuilding all the missing packages, which are supposed to only
link against the default Ruby.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#809308: RFS: cl-asdf/3.1.6 [ITA] - Another System Definition Facility

[Mattia Rizzolo]

Gentle ping.

Are you still interested in adopting this package and getting it
uploaded?

-- 
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#115767: I see this too on x86 user-mode-linux on etch

[Sebastian Andrzej Siewior]

On 2008-03-25 11:02:39 [+0100], Bernhard M. Wiedemann wrote:
> Hi,
Hi,

> I am running several virtual machines (currently using 2.6.24.2) with 
> user-mode-linux (UML) and am seeing the very same problem repeatedly.

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?
If not, we could probably close the bug if nobody complains about it anymore
and the problem might have vanished.

> Ciao
> Bernhard M.

Sebastian

Bug#816246: boinc-manager:task tab in advanced view does not update properly -> last active task does not update automatically, regardless of sort order

[Gianfranco Costamagna]

Hi, can you please try boinc from testing?
a lot of gtk fixes has been added there.

cheers,

G.




Il Lunedì 29 Febbraio 2016 5:33, vic_dev  ha scritto:
Package: boinc-manager
Version: 7.4.23+dfsg-1

The task tab in the advanced view does not update properly, the last 
active task does not update automatically, instead it displays the same 
thing all the time until user interacts with the task list. (Last active 
task = the active task at the bottom of the list, regardless of sort order.)

The last active task only updates when I click on any task in the list, 
or when the sort order is changed, or when switching away from the task 
tab then back again.  Changing the sort order does not change this, it 
just moves the non-updating behavior to whatever task ends up at the 
bottom of the list.

This behavior is the same on two computers in either the Gnome or Xfce 
desktops.  Each computer has an AMD Phenom II X4 processor, with an 
Radeon 5850 graphics card, using both CPU and GPU to crunch Seti@Home 
workunits (using OpenCL).

Noticed this behavior a long time ago, has been an issue for several years.

OS: Debian GNU/Linux 8 (jessie)
Kernel:  3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
x86_64 GNU/Linux
Architecture: x86-64
wxWidgets: 3.0.2-1+b1
AMD OpenCL: 1:15.9-4~deb8u1

Debian Release: 8.3
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')

boinc-client: 7.4.23+dfsg-1
libboinc7: 7.4.23+dfsg-1
libc6: 2.19-18+deb8u3
libgcc1: 1:4.9.2-10
libglib2.0-0: 2.42.1-1
libgtk2.0-0: 2.24.25-3
libnotify4: 0.7.6-2
libsqlite3-0: 3.8.7.1-1+deb8u1
libstdc++6: 4.9.2-10
libwxbase3.0-0: 3.0.2-1+b1
libwxgtk-webview3.0-0: 3.0.2-1+b1
libwxgtk3.0-0: 3.0.2-1+b1
libgl1-mesa-glx: 10.3.2-1+deb8u1
libxt6: 1:1.1.4-1+b1

Bug#816287: geeqie: please do NOT Recommends lpr

[Martin-Éric Racine]

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!

-- System Information:
Debian Release: 8.3
  APT prefers oldoldstable
  APT policy: (1001, 'oldoldstable'), (1001, 'stable'), (1001, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geeqie depends on:
pn  geeqie-common
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u3
ii  libcairo21.14.0-2.1
ii  libexiv2-13  0.24-4.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
ii  libglib2.0-0 2.42.1-1
ii  libgtk2.0-0  2.24.25-3
ii  libjpeg62-turbo  1:1.3.1-12
ii  liblcms2-2   2.6-3+b3
ii  liblircclient0   0.9.0~pre1-1.2
ii  liblua5.1-0  5.1.5-7.1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libstdc++6   4.9.2-10
ii  libtiff5 4.0.3-12.3+deb8u1

Versions of packages geeqie recommends:
ii  exiftran 2.09-1+b1
ii  exiv20.24-4.1
ii  imagemagick  8:6.8.9.9-5
ii  librsvg2-common  2.40.5-1
pn  lpr  
ii  ufraw-batch  0.20-2+deb8u1
ii  zenity   3.14.0-1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.14-1+b1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.3.1-12
pn  ufraw
pn  xpaint   

Bug#816288: Missing Build-Depends and Depends on php-xml

[Prach Pongpanich]

Package: pkg-php-tools
Version: 1.31
Severity: serious
Tags: patch

Hi,

I rebuild php-net-ldap2 against with php-pear/1:1.10.1 (#809771) and get error:

[..]
 dpkg-source --before-build php-net-ldap2-2.2.0
 fakeroot debian/rules clean
dh clean --buildsystem=phppear --with phppear
   dh_testdir -O--buildsystem=phppear
   dh_auto_clean -O--buildsystem=phppear
PHP Fatal error:  Uncaught Error: Call to undefined function
Pkgtools\Phppear\simplexml_load_file() in
/usr/share/php/pkgtools/phppear/source.php:76
[..]


Regard,
Prach
diff --git a/debian/control b/debian/control
index db39ff5..cdceb9c 100644
--- a/debian/control
+++ b/debian/control
@@ -7,14 +7,15 @@ Build-Depends: debhelper (>= 9),
perl,
php-pear,
php-cli,
-   php-json
+   php-json,
+   php-xml
 Vcs-Git: git://anonscm.debian.org/pkg-php/pkg-php-tools.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-php/pkg-php-tools.git;a=summary
 Standards-Version: 3.9.6
 
 Package: pkg-php-tools
 Architecture: all
-Depends: debhelper, php-pear, php-cli, php-json, ${misc:Depends}
+Depends: debhelper, php-pear, php-cli, php-json, php-xml,${misc:Depends}
 Suggests: dh-make
 Description: various packaging tools and scripts for PHP packages
  Provide an easy way to package PHP PEAR, PECL and Composer packages: Run

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

[Lisandro Damián Nicanor Pérez Meyer]

No I didn't. I won't re add/start compiling again a Qt 4 module for the
reasons I wrote in my previous mail.

If you need the functionality you should really consider switching to Qt 5

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

Bug#816289: luit: unable to use advertised conversion charset

[Thorsten Glaser]

Package: x11-utils
Version: 7.7+3
Severity: normal
Tags: upstream

I find myself in the situation of wishing to change the
charset for a remote session, i.e. ssh to a cp1252 system
from an UTF-8 system. I thought to use luit for this, but:

tglase@tglase-nb:~ $ luit -encoding 'CP 1252' echo mäh
Warning: couldn't find charset data for locale CP 1252; using ISO 8859-1.
mäh
tglase@tglase-nb:~ $ luit -encoding microsoft-cp1252 echo mäh
Warning: couldn't find charset data for locale microsoft-cp1252; using ISO 
8859-1.
mäh
tglase@tglase-nb:~ $ luit -list | fgrep 1252
  CP 1252

This is not specific to Debian (Cc’ing the original author from
the manpage), as I can reproduce it also on MirBSD with XFree86®.

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

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

Versions of packages x11-utils depends on:
ii  libc6 2.21-9
ii  libfontconfig12.11.0-6.3
ii  libfontenc1   1:1.1.3-1
ii  libfreetype6  2.6.1-0.1
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxcb-shape0 1.11.1-1
ii  libxcb1   1.11.1-1
ii  libxcomposite11:0.4.4-1
ii  libxext6  2:1.3.3-1
ii  libxft2   2.3.2-1
ii  libxi62:1.7.6-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxmu6   2:1.1.2-2
ii  libxmuu1  2:1.1.2-2
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  libxtst6  2:1.2.2-1+b1
ii  libxv12:1.0.10-1+b1
ii  libxxf86dga1  2:1.1.4-1+b1
ii  libxxf86vm1   1:1.1.4-1

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information