Bug#816363: RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty

[Dmitry Bogatov]

Package: sponsorship-request
Severity: normal

Dear mentors,

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

* Package name: fgetty
  Version : 0.7-0.1
  Upstream Author : Felix von Leitner 
* Url : https://www.fefe.de/fgetty
* Licenses: GPL-2+
  Section : admin

It builds those binary packages:

fgetty -- very small, efficient, console-only getty and login

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

http://mentors.debian.net/package/fgetty

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

http://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-0.1.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://anonscm.debian.org/users/kaction-guest/fgetty.git

More information about fgetty can be obtained from https://www.fefe.de/fgetty

Changes since last upload:

  * Non-maintainer upload.
  * New upstream release
  * Add watch file with GPG key verification
  * Add source/format to follow v3.0 source package format
  * Use debhelper instead of custom debian/rules
  * Drop checkpassword-pam. Upstream does not support it, and once written,
but is not maintained anymore. Averaged desktop setup should not
need anyway.
  * Remove outdated README.Debian
  * Reformat debian/copyright to follow DEP-5
  * Link checkpassword with gnu libc (Closes: #563335) with hardening
  * Add lintian overrides about static build and lack of dependencies
  * Write manpage for login1 and login2
  * New standards version -- 3.9.7 (No changes needed)

Regards,
  Dmitry Bogatov

Bug#816336: forcing reinstallation of alternative /bin/mt-gnu because link group mt is broken

[積丹尼 Dan Jacobson]

MR> typo here ↑  :)
Oops!

Bug#816362: typo in pdns-backend-mysql.postinst script

[Mike Gabriel]

Package: pdns-backend-mysql
Severity: normal
Version: debian/4.0.0_alpha2-2
Tags: patch


There is a typo in the postinst script of pdns-backend-mysql where the  
package name is defined...


´´´
PKGNAME="pdns-backend-gmysql"
´´´

This looks like, the "g" should be removed from the package name, right?

(Consider this information as if it was a patch, thus tagging this bug  
with tag "patch").


light+love
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpwWjD4qq2Or.pgp
Description: Digitale PGP-Signatur

Bug#815786: d-i does not ask for hostname

[Nagel, Peter (IFP)]

On 01.03.2016 00:32, Roger Shimizu wrote:
>
> From implementation side, as you explained before, network-console
> requires network set-up in early stage, so it may be hard to set up
> hostname a second time.

If your ssh connection is bind to the hostname (ssh
user@hostname.domain) the connection will (most probably) hang up if you
change the hostname of your target. However, changing the hostname
should not be ab problem if your ssh connection is bind to the IP adress
(ssh u...@xxx.xxx.xxx.xxx).

An other possibility would be to change the hostname (e.g within
/etc/hostname and via command hostname) but not changing the hostname
for the network (e.g. do not change /etc/hosts/ ...)
In this case the ssh connection should not hang up but the new RAID
device would get the name from the new hostname.
This is, what I also tried to descriped in my bug report (see quick fix).

Cheers,
Peter

Bug#816361: warn upon posting bugs to an unknown package

[積丹尼 Dan Jacobson]

Package: bugs.debian.org

Maybe in the case of e.g.,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816336
send a special message to the user that he posted the bug to an unknown
package, instead or in addition to the usual acknowledgment.

Bug#816336: forcing reinstallation of alternative /bin/mt-gnu because link group mt is broken

[Mattia Rizzolo]

control: reassign -1 cpio 2.11+dfsg-5

On Tue, Mar 01, 2016 at 07:41:47AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: cpip

typo here ↑  :)

> Version: 2.11+dfsg-5
> 
> Setting up cpio (2.11+dfsg-5) ...
> update-alternatives: warning: forcing reinstallation of alternative 
> /bin/mt-gnu because link group mt is broken
> update-alternatives: warning: not replacing /usr/share/man/man1/mt.1.gz with 
> a link

-- 
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#816359: ruby-solve: FTBFS: got #> with backtrace:

[Chris Lamb]

Source: ruby-solve
Version: 2.0.1-2
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-solve fails to build from source in unstable/amd64:

  [..]

  Pending: (Failures listed here are expected and do not affect your suite's 
status)
  
1) Solve::GecodeSolver finding unsatisfiable demands partitions demands 
into satisfiable and not satisfiable
   # Not yet implemented
   # ./spec/unit/solve/gecode_solver_spec.rb:183
  
2) Solve ClassMethods #it returns nil if a solution does not exist
   # No reason given
   # ./spec/unit/solve_spec.rb:8
  
3) Solve ClassMethods #it! raises NoSolutionError if a solution does not 
exist
   # No reason given
   # ./spec/unit/solve_spec.rb:14
  
  Failures:
  
1) Solutions when using the ruby solver raises NoSolutionError when a 
solution cannot be found
   Failure/Error: lambda {
 expected Solve::Errors::NoSolutionError, got #> 
with backtrace:
   # ./lib/solve/ruby_solver.rb:177:in `resolve_with_error_wrapping'
   # ./lib/solve/ruby_solver.rb:72:in `resolve'
   # ./lib/solve.rb:64:in `it!'
   # ./spec/acceptance/ruby_solver_solutions_spec.rb:36:in `block (3 
levels) in '
   # ./spec/acceptance/ruby_solver_solutions_spec.rb:35:in `block (2 
levels) in '
   # ./spec/acceptance/ruby_solver_solutions_spec.rb:35:in `block (2 
levels) in '
  
2) Solutions when using the ruby solver tries all combinations until it 
finds a solution
   Failure/Error: result = Solve.it!(graph, demands)
   NoMethodError:
 undefined method `allow_missing?' for 
#
   # ./lib/solve/ruby_solver.rb:177:in `resolve_with_error_wrapping'
   # ./lib/solve/ruby_solver.rb:72:in `resolve'
   # ./lib/solve.rb:64:in `it!'
   # ./spec/acceptance/ruby_solver_solutions_spec.rb:201:in `block (2 
levels) in '
  
3) Solve::RubySolver when the constraints are not solvable and molinillo 
identifies constraints that exclude all known versions raises an error 
detailing the missing artifacts
   Failure/Error: expect(error).to 
be_a_kind_of(Solve::Errors::NoSolutionError)
 expected #> to be a kind of 
Solve::Errors::NoSolutionError
   # ./spec/unit/solve/ruby_solver_spec.rb:110:in `block (4 levels) in '
  
4) Solve::RubySolver when the constraints are not solvable and molinillo 
identifies missing artifacts raises an error detailing the missing artifacts
   Failure/Error: expect(error).to 
be_a_kind_of(Solve::Errors::NoSolutionError)
 expected #> to be a kind of 
Solve::Errors::NoSolutionError
   # ./spec/unit/solve/ruby_solver_spec.rb:90:in `block (4 levels) in '
  
  Deprecation Warnings:
  
  RSpec::Core::Configuration#treat_symbols_as_metadata_keys_with_true_values= 
is deprecated, it is now set to true as default and setting it to false has no 
effect.
  
  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.20160301070242.8rIosWHgd4/ruby-solve-2.0.1/spec/unit/solve/gecode_solver_spec.rb:68:in
 `block (2 levels) in '.
  
  Using `stub` from rspec-mocks' old `:should` syntax without explicitly 
enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly 
enable `:should` instead. Called from 
/home/lamby/temp/cdt.20160301070242.8rIosWHgd4/ruby-solve-2.0.1/spec/unit/solve/gecode_solver_spec.rb:153:in
 `block (4 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.
  
  3 deprecation warnings total
  
  Finished in 0.12653 seconds (files took 0.12439 seconds to load)
  105 examples, 4 failures, 3 pending
  
  Failed examples:
  
  rspec ./spec/acceptance/ruby_solver_solutions_spec.rb:31 # Solutions when 
using the ruby solver raises NoSolutionError when a solution cannot be found
  rspec ./spec/acceptance/ruby_solver_solutions_spec.rb:167 # Solutions when 
using the ruby solver tries all combinations until it finds a solution
  rspec ./spec/unit/solve/ruby_solver_spec.rb:109 # Solve::RubySolver when the 
constraints are not solvable and molinillo identifies constraints that exclude 
all known versions raises an error detailing the missing artifacts
  rspec ./spec/unit/solve/ruby_solver_spec.rb:89 # Solve::RubySolver when the 
constraints are not solvable and molinillo identifies missing artifacts raises 
an error detailing the missing artifacts
  
  Randomized with seed 54553
  
  /usr/bin/ruby2.2 /usr/bin/rspec --pattern 

Bug#816357: jedit: FTBFS: XThis.java:128: error: cannot find symbol [..] NotSerializableException

[Chris Lamb]

Source: jedit
Version: 5.3.0+dfsg-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,

jedit fails to build from source in unstable/amd64:

  [..]

  [javac] 
/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/org/gjt/sp/jedit/bsh/Primitive.java:75:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
Hashtable
  [javac]   wrapperMap.put( Boolean.TYPE, Boolean.class );
  [javac] ^
  [javac]   where K,V are type-variables:
  [javac] K extends Object declared in class Hashtable
  [javac] V extends Object declared in class Hashtable
  [javac] 
/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/org/gjt/sp/jedit/bsh/Primitive.java:76:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
Hashtable
  [javac]   wrapperMap.put( Byte.TYPE, Byte.class );
  [javac] ^
  [javac]   where K,V are type-variables:
  [javac] K extends Object declared in class Hashtable
  [javac] V extends Object declared in class Hashtable
  [javac] 
/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/org/gjt/sp/jedit/bsh/Primitive.java:77:
 warning: [unchecked] unchecked call to put(K,V) as a member of the raw type 
Hashtable
  [javac]   wrapperMap.put( Short.TYPE, Short.class );
  [javac] ^
  [javac]   where K,V are type-variables:
  [javac] K extends Object declared in class Hashtable
  [javac] V extends Object declared in class Hashtable
  [javac] 
/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/org/gjt/sp/jedit/bsh/XThis.java:128:
 error: cannot find symbol
  [javac]   throw new NotSerializableException();
  [javac] ^
  [javac]   symbol:   class NotSerializableException
  [javac]   location: class XThis.Handler
  [javac] Note: Some input files additionally use or override a deprecated 
API.
  [javac] Note: Some input files additionally use unchecked or unsafe 
operations.
  [javac] 2 errors
  [javac] 100 warnings
  
  BUILD FAILED
  
/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg/build.xml:231: 
Compile failed; see the compiler error output for details.
  
  Total time: 5 seconds
  debian/rules:26: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 1
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160301065925.cu0iTWjXkj/jedit-5.3.0+dfsg'
  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
   `-


jedit.5.3.0+dfsg-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#816360: ruby-typhoeus: FTBFS: "Typhoeus::Hydra::Runnable#run when request queued in callback when real request when max_concurrency default calls on_complete callback once for every response"

[Chris Lamb]

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

Dear Maintainer,

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

  [..]
  
  Failures:
  
1) Typhoeus::Hydra::Runnable#run when request queued in callback when real 
request when max_concurrency default calls on_complete callback once for every 
response
   Failure/Error: expect(String).to receive(:new).exactly(2).times
     (String (class)).new(*(any args))
     expected: 2 times with any arguments
     received: 4 times with any arguments
   # ./spec/typhoeus/hydra/runnable_spec.rb:118:in `block (6 levels) 
in '
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/error_generator.rb:303:in 
`__raise'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/error_generator.rb:87:in 
`raise_expectation_error'
   # 
/usr/lib/ruby/vendor_ruby/rspec/mocks/message_expectation.rb:477:in 
`generate_error'
   # 
/usr/lib/ruby/vendor_ruby/rspec/mocks/message_expectation.rb:435:in 
`verify_messages_received'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/method_double.rb:113:in 
`block in verify'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/method_double.rb:113:in 
`each'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/method_double.rb:113:in 
`verify'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/proxy.rb:138:in `block in 
verify'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/proxy.rb:138:in 
`each_value'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/proxy.rb:138:in `verify'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/space.rb:74:in `block in 
verify_all'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/space.rb:74:in `each'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks/space.rb:74:in 
`verify_all'
   # /usr/lib/ruby/vendor_ruby/rspec/mocks.rb:45:in `verify'
   # 
/usr/lib/ruby/vendor_ruby/rspec/core/mocking_adapters/rspec.rb:23:in 
`verify_mocks_for_rspec'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:444:in 
`verify_mocks'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:438:in 
`run_after_example'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:221:in `block in 
run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:430:in `block in 
with_around_and_singleton_context_hooks'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:388:in `block in 
with_around_example_hooks'
   # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:478:in `block in 
run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:616:in 
`run_around_example_hooks_for'
   # /usr/lib/ruby/vendor_ruby/rspec/core/hooks.rb:478:in `run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:388:in 
`with_around_example_hooks'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:430:in 
`with_around_and_singleton_context_hooks'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example.rb:203:in `run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:559:in 
`block in run_examples'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:555:in 
`map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:555:in 
`run_examples'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:521:in 
`run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`block in run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`block in run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`block in run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`block in run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/example_group.rb:522:in 
`run'
   # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in `block (3 
levels) in run_specs'
   # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in `map'
   # /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:116:in 

Bug#816358: ruby-safe-yaml: FTBFS: undefined method `key?' for nil:NilClass

[Chris Lamb]

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

[..]

  F
  
  Failures:
  
1) Psych unsafe_load with special whitelisted tags defined effectively 
ignores the whitelist (since everything is whitelisted)
   Failure/Error: result = YAML.unsafe_load <<-YAML.unindent
   NoMethodError:
 undefined method `key?' for nil:NilClass
   # ./spec/safe_yaml_spec.rb:51:in `block (4 levels) in '
  
2) Psych safe_load with special whitelisted tags defined will allow objects 
to be deserialized for whitelisted tags
   Failure/Error: result = YAML.safe_load("--- 
!ruby/object:OpenStruct\ntable:\n  foo: bar\n")
   NoMethodError:
 undefined method `key?' for nil:NilClass
   # ./lib/safe_yaml/safe_to_ruby_visitor.rb:23:in `accept'
   # ./lib/safe_yaml/psych_resolver.rb:26:in `native_resolve'
   # ./lib/safe_yaml/resolver.rb:12:in `resolve_node'
   # ./lib/safe_yaml/resolver.rb:55:in `block in resolve_seq'
   # ./lib/safe_yaml/resolver.rb:55:in `each'
   # ./lib/safe_yaml/resolver.rb:55:in `inject'
   # ./lib/safe_yaml/resolver.rb:55:in `resolve_seq'
   # ./lib/safe_yaml/psych_resolver.rb:17:in `resolve_root'
   # ./lib/safe_yaml/resolver.rb:16:in `resolve_node'
   # ./lib/safe_yaml/load.rb:151:in `load'
   # ./lib/safe_yaml.rb:29:in `safe_load'
   # ./spec/safe_yaml_spec.rb:319:in `block (4 levels) in '
  
3) Psych safe_load with special whitelisted tags defined will not allow 
non-whitelisted objects to be embedded within objects with whitelisted tags
   Failure/Error: result = YAML.safe_load <<-YAML.unindent
   NoMethodError:
 undefined method `key?' for nil:NilClass
   # ./lib/safe_yaml/safe_to_ruby_visitor.rb:23:in `accept'
   # ./lib/safe_yaml/psych_resolver.rb:26:in `native_resolve'
   # ./lib/safe_yaml/resolver.rb:12:in `resolve_node'
   # ./lib/safe_yaml/resolver.rb:55:in `block in resolve_seq'
   # ./lib/safe_yaml/resolver.rb:55:in `each'
   # ./lib/safe_yaml/resolver.rb:55:in `inject'
   # ./lib/safe_yaml/resolver.rb:55:in `resolve_seq'
   # ./lib/safe_yaml/psych_resolver.rb:17:in `resolve_root'
   # ./lib/safe_yaml/resolver.rb:16:in `resolve_node'
   # ./lib/safe_yaml/load.rb:151:in `load'
   # ./lib/safe_yaml.rb:29:in `safe_load'
   # ./spec/safe_yaml_spec.rb:331:in `block (4 levels) in '
  
4) Psych safe_load with special whitelisted tags defined with the 
:raise_on_unknown_tag option enabled does not raise an exception as long as all 
tags are whitelisted
   Failure/Error: result = YAML.safe_load <<-YAML.unindent
   NoMethodError:
 undefined method `key?' for nil:NilClass
   # ./lib/safe_yaml/safe_to_ruby_visitor.rb:23:in `accept'
   # ./lib/safe_yaml/psych_resolver.rb:26:in `native_resolve'
   # ./lib/safe_yaml/resolver.rb:12:in `resolve_node'
   # ./lib/safe_yaml/resolver.rb:55:in `block in resolve_seq'
   # ./lib/safe_yaml/resolver.rb:55:in `each'
   # ./lib/safe_yaml/resolver.rb:55:in `inject'
   # ./lib/safe_yaml/resolver.rb:55:in `resolve_seq'
   # ./lib/safe_yaml/psych_resolver.rb:17:in `resolve_root'
   # ./lib/safe_yaml/resolver.rb:16:in `resolve_node'
   # ./lib/safe_yaml/load.rb:151:in `load'
   # ./lib/safe_yaml.rb:29:in `safe_load'
   # ./spec/safe_yaml_spec.rb:373:in `block (5 levels) in '
  
5) Psych safe_load when options are passed direclty to #load which differ 
from the defaults (or, for example, when certain tags are whitelisted) goes 
with the default option when it is not overridden
   Failure/Error: YAML.safe_load(yaml, nil, options)
   NoMethodError:
 undefined method `key?' for nil:NilClass
   # ./lib/safe_yaml/safe_to_ruby_visitor.rb:23:in `accept'
   # ./lib/safe_yaml/psych_resolver.rb:26:in `native_resolve'
   # ./lib/safe_yaml/resolver.rb:12:in `resolve_node'
   # ./lib/safe_yaml/resolver.rb:55:in `block in resolve_seq'
   # ./lib/safe_yaml/resolver.rb:55:in `each'
   # ./lib/safe_yaml/resolver.rb:55:in `inject'
   # ./lib/safe_yaml/resolver.rb:55:in `resolve_seq'
   # ./lib/safe_yaml/psych_resolver.rb:17:in `resolve_root'
   # ./lib/safe_yaml/resolver.rb:16:in `resolve_node'
   # ./lib/safe_yaml/load.rb:151:in `load'
   # ./lib/safe_yaml.rb:29:in `safe_load'
   # ./spec/safe_yaml_spec.rb:7:in `safe_load_round_trip'
   # ./spec/safe_yaml_spec.rb:459:in `block (5 levels) in '
  
6) Psych whitelist! with a Class as its argument successfully deserializes 
the specified class
   Failure/Error: YAML.safe_load(yaml, nil, options)
   NoMethodError:
 undefined method `key?' for nil:NilClass

Bug#813952: RFS: helm/1.9.2-1 -- Emacs incremental completion and selection narrowing framework

[Mattia Rizzolo]

control: block -1 by 813953

On Mon, Feb 29, 2016 at 06:00:05PM -0700, Sean Whitton wrote:
> The Emacs Addons packaging team recently started using PET [1], which
> works best if packages are tagged only after they are uploaded, so I
> removed the tag.

ok, cool.

> I didn't expect anyone outside of the Emacs team to look at the RFS --
> thanks again!

happens when you file a RFS ;)
I know there is bremer doing those RFSes, but hopefully he doesn't get
mad if I steal something :D

> By the way, please be sure to check out the pristine-tar branch so that
> you use the same orig.tar as I'm working with :)

of course.
I have a helm_1.9.2.orig.tar.xz with sha256
b84e0f59889bf51a5743f85e7e557158b86241fdf42d57bee4aa2ee5152b9544

I was about to upload when I realized this is not installable due to
that elpa-popup new dependency that is only in the binary.
I see you have #813953 open for that, I will look at that later.
Given that hopefully you want your packages to always be installable,
it's nice to mark the RFS as blocking one another in cases like this, so
I could have looked at popup before, instead of stalling this now :)

-- 
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#816356: RFS: progress/0.13-2

[lumin]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: progress
   Version : 0.13-2
   Upstream Author : xfennec
 * URL : https://github.com/Xfennec/progress
 * License : gpl-3
   Section : utils

  It builds those binary packages:

progress   - Coreutils Progress Viewer (formerly known as 'cv')

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

  http://mentors.debian.net/package/progress


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/progress/progress_0.13-2.dsc

  Debomatic-amd64 build OK:
  
http://debomatic-amd64.debian.net/distribution#unstable/progress/0.13-2/buildlog

  Changes since the last upload:

progress (0.13-2) unstable; urgency=medium

  * Bump standards from 3.9.6 to 3.9.7 (requires no change)
  * Update Vcs-Browser to an https link.

-- 
 .''`.
: :' :
`. `' 
  `-  


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

Bug#816080: [wajig] Segfault on wajig show command for some packages.

[Paweł Różański]

On 29.02.2016 21:49, Manuel A. Fernandez Montecelo wrote:

Control: tags -1 - moreinfo
Control: forcemerge -1 815581


2016-02-28 10:41 To Paweł Różański:

Control: tags -1 + moreinfo


Hi Paweł,

2016-02-27 09:53 Paweł Różański:

Package: wajig
Version: 2.17
Severity: normal

--- Please enter the report below this line. ---
I noticed, that wajig show command segfaults on some packages. On
some packages it works fine:
#LANG=C wajig show fglrx-driver
Segmentation fault (core dumped)

# LANG=C wajig show ssh
Segmentation fault (core dumped)

# LANG=C wajig show apt
Package: apt
Version: 1.2.3
[...]

Notice: apt-cache show works fine for all mentioned packages. Wajig
update was executed, system after fresh reboot. If additional
information is needed, please provide commands run.


Does the crash happen only for the "not installed" packages and it's
fine for the "installed" ones?  If so, it's #815581, fix to be released
tomorrow or so.


So I'm going to assume that this is the case and will merge the reports
now.


Didn't test throughly, as I waited for new version, but quick check 
confirms, that bug indeed appears only for not installed packages.


Regards,
Paweł Różański
--
http://rozie.blox.pl/

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

[Paul Wise]

On Tue, Mar 1, 2016 at 12:39 AM, Justin B Rye wrote:

> or (maybe better, maybe my critical faculties are just going numb):
>
>Their common goal is to simplify installation and administration of
>computers for their target audience, and to connect that audience
>with the people writing or packaging the software they use.

I think I like this one best.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#807579: CUDA 7.5 planning

[lumin]

Hi anbe,

Is there something that I can help?

Besides please ping me if the svn repo is ready,
I can conduct some test and check :-)

Thanks.
-- 
 .''`.
: :' :
`. `' 
  `-  

Bug#814645: not in stable yet

[Balasankar C]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 25 Feb 2016 13:07:39 +0100 Andreas Beckmann 
wrote:
> On 2016-02-25 08:36, Pirate Praveen wrote:
>> ruby-mousetrap-rails is not part of any stable release. So should
>> I really handle this upgrade case?
> 
> Yes. Especially since the fix should be trivial.

Hi,

This may be a silly doubt, but I didn't quite understand the issue
here. Version 1.4.6-4 is in testing, 1.4.6-4 is in unstable. How will
there be an upgrade from testing to sid when both have the same
version? It is not in stable yet, so there is no upgrade path from
stable to testing.


- -- 
Regards
Balasankar C
http://balasankarc.in
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJW1STxAAoJEJbtq5sua3FxqR4IAKfgpxCyOnmzX9k8FRlIUPr1
tddFp0CTYVsP3m7I/EH/vfMXXQTzOlAgsUH0EUmhv63AfEbYbCXhEjQz/Jc6JRVg
WA3pqtnUbEQj42iFTtjuqdDGCdbo6Cu0QTdbB8bIG0+zv8uZsQi0jO6QmdFOolhc
BT+Gdv1A3UMYNg0r3HMNwUe75F1q/ovZs8ez5PRhWaXxcBFClBA76NB3XHmvB9rw
nvL7Ymn25kmgk7BB6BhE5FlV5KQpSCcGuVuYHEMVWx+/Vo4d2ps9mU0WGUvAXsRh
teAatybt/N/x+3DFnWnCQSB7NsZqSPnaSGJp6NPivDlQMQHwxYaGtSId5igUHEY=
=od21
-END PGP SIGNATURE-


0x2E6B7171.asc
Description: application/pgp-keys

Bug#816124: pnmixer: Icons displaying much too large with certian icon packs installed

[elboulangero]

Hi,

thanks for reporting the issue. Indeed Gtk3 doesn't resize the images
enclosed in a GtkMenuItem. It picks up the right size if different size
are available though.

So, for an immediate workaround, I recommend you to tweak the Buuf
theme. The problem here is that the Buff icon theme only provides
128x128 icons. If you manually the icons PNMixer use to the size you
want (might be 16x16 or 24x24 depending on your font size), then put it
in the right place and edit the theme file, I guess Gtk3 will then
pickup these icons and it will work.

For you to know, the icons PNMixer use are: system-run,
preferences-desktop, gtk-refresh, help-about, gtk-quit

Otherwise, you can just wait for the next PNMixer version, should be
around two or three months. I found a way to workaround the problem,
it's fixed in the upstream version now.

Best Regards,
Arnaud

Bug#807725: freedombox-setup: Installing freedombox-setup locks out users from machines

[Sunil Mohan Adapa]

On 01/15/2016 01:12 PM, Sunil Mohan Adapa wrote:
> On Thursday 14 January 2016 05:44 PM, James Valleroy wrote:
> [...]
>>
>> Adding the sudo group would fix most cases, but there will still be an
>> issue for display managers like gdm (it can't start with the current
>> restriction).
>>
>> I'm wondering about the security benefit of restricting logins (both
>> console and SSH) from non-privileged users. There could be a use case
>> for non-admin users to access files in their home folders, although we
>> may need to implement storage quotas.
> 
> Here is a more concerte plan that should fix all current issues: we will
> allow all local (non-LDAP) users to login, in addition to allowing
> 'admin' group users.  Further to that, we will consider allowing all
> users of a special group say 'console' to login via SSH and console.
> 
> Allowing all users may be good in some situations like what we are doing
> here; have a FreedomBox serve an entire community with each of them
> having logins.
> 

Recently, we have come across situations where apps hosted behind Apache
using its authentication become vulnerable when any user can login to
the system.  Until we have a thorough approach to solving that problem,
let us take a cautious approach and allow only 'sudo' users.

For allowing GDM logins, let us ask users to edit access.conf for now.
Attached a two patches one for allowing 'sudo' users and one for adding
a post setup warning message.  The patches are only unit untested.

-- 
Sunil
From d5c0277982542db7d9b913a5fcac01d39ca0ff8e Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Tue, 1 Mar 2016 10:26:06 +0530
Subject: [PATCH 2/2] Print important notes after finishing setup

- Warn users about locking out users.

- Tell them that next setup is to reboot.
---
 setup.d/99_zmessage | 20 
 1 file changed, 20 insertions(+)
 create mode 100755 setup.d/99_zmessage

diff --git a/setup.d/99_zmessage b/setup.d/99_zmessage
new file mode 100755
index 000..f63bfe2
--- /dev/null
+++ b/setup.d/99_zmessage
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+cat 
Date: Tue, 1 Mar 2016 10:25:02 +0530
Subject: [PATCH 1/2] Allow console access to 'sudo' group users

- This is so that users don't get locked out after running FreedomBox
  setup.
---
 setup.d/30_ldap-server | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/setup.d/30_ldap-server b/setup.d/30_ldap-server
index 73b88ee..1350b80 100755
--- a/setup.d/30_ldap-server
+++ b/setup.d/30_ldap-server
@@ -38,9 +38,9 @@ DEBIAN_FRONTEND=noninteractive apt-get install -y nslcd libpam-ldapd libnss-ldap
 
 pam-auth-update --package
 
-if ! grep -q -- "^-:ALL EXCEPT root fbx (admin):ALL$" \
+if ! grep -q -- "^-:ALL EXCEPT root fbx (admin) (sudo):ALL$" \
  /etc/security/access.conf ; then
-printf "%s\n" "-:ALL EXCEPT root fbx (admin):ALL" \
+printf "%s\n" "-:ALL EXCEPT root fbx (admin) (sudo):ALL" \
 	 >> /etc/security/access.conf
 fi
 
-- 
2.7.0



signature.asc
Description: OpenPGP digital signature

Bug#576540: ITP: theano -- Python library to define, optimize, and evaluate mathematical expressions involving multi-dimensional arrays

[lumin]

Hi Daniel,

We are planning to upload CUDA 7.5 recently, and this
would fix the compatibility of nvcc and gcc-5 [1].

The hot-spot deeplearning frameworks:
 caffe, torch, mxnet, tensorflow, theano

caffe is blocked by CUDA and the nvidia team is working on CUDA curretly,
https://bugs.debian.org/788539
torch is blocked by luarocks issue and we are discussing the solution,
https://bugs.debian.org/794634
tensorflow is blocked by protobuf and bazel,
https://bugs.debian.org/804612
mxnet is likely not blocked.
https://bugs.debian.org/808235

theano is maintained by you, thanks!

[1] http://bugs.debian.org/807579
-- 
 .''`.
: :' :
`. `' 
  `-  

Bug#789703: unattended-upgrades: Equals symbol not escaped for Quoted Printable in Mail

[Michael Deegan]

Package: unattended-upgrades
Version: 0.79.5+wheezy2
Followup-For: Bug #789703

Hello,

Please consider the attached patch as a fix for this bug.

(Note that email.charset (unavoidably) uses Base64 rather than
Quoted-Printable
for UTF-8 content.  Everyone's MUA supports Content-Transfer-Encoding these
days, so it shouldn't be a problem, right? :P)

Thanks,

-MD

-- System Information:
Debian Release: 7.9
  APT prefers squeeze-lts
  APT policy: (500, 'squeeze-lts'), (500, 'oldstable-updates'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'oldstable'), (488, 
'stable-updates'), (488, 'stable')
Architecture: i386 (i686)

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

Versions of packages unattended-upgrades depends on:
ii  apt0.9.7.9+deb7u7
ii  apt-utils  0.9.7.9+deb7u7
ii  debconf [debconf-2.0]  1.5.49
ii  lsb-base   4.1+Debian8+deb7u1
ii  lsb-release4.1+Debian8+deb7u1
ii  python 2.7.3-4+deb7u1
ii  python-apt 0.8.8.2
ii  ucf3.0025+nmu3
ii  xz-utils   5.1.1alpha+20120614-2

unattended-upgrades recommends no packages.

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.2006cvs-1+deb7u1
ii  exim4-daemon-light [mail-transport-agent]  4.80-7+deb7u1

-- debconf-show failed

-MD

-- 
---
Michael DeeganHugaholichttp://www.deegan.id.au/
-  Jung, zr jbeel?  ---
--- /usr/bin/unattended-upgrade	2015-06-29 14:57:18.0 +0800
+++ /usr/bin/unattended-upgrade.new	2016-02-29 11:35:21.908988898 +0800
@@ -570,10 +570,7 @@
 def _send_mail_using_sendmail(to_address, subject, body):
 # format as a proper mail
 msg = Message()
-charset = email.Charset.Charset("utf-8")
-charset.body_encoding = email.Charset.QP
-msg.set_charset(charset)
-msg.set_payload(body)
+msg.set_payload(body,'utf-8')
 msg['Subject'] = subject
 msg['To'] = to_address
 sendmail = subprocess.Popen(

Bug#816355: Please hide menu icon

[Michael Biebl]

Package: ksshaskpass
Version: 4:5.4.3-1
Severity: normal
File: /usr/share/applications/org.kde.ksshaskpass.desktop

Please consider dropping org.kde.ksshaskpass.desktop or not showing it
in the menu by default.
The desktop file has no proper icon and tries (unsuccessfully) to run a
command line program.


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

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

Versions of packages ksshaskpass depends on:
ii  libc6 2.21-9
ii  libkf5coreaddons5 5.16.0-1
ii  libkf5i18n5   5.16.0-1
ii  libkf5wallet-bin  5.16.0-1
ii  libkf5wallet5 5.16.0-1
ii  libkf5widgetsaddons5  5.16.0-1
ii  libqt5core5a  5.5.1+dfsg-14
ii  libqt5widgets55.5.1+dfsg-14
ii  libstdc++65.3.1-10
ii  openssh-client1:7.1p2-2

Versions of packages ksshaskpass recommends:
ii  kwalletmanager  4:15.08.3-1

ksshaskpass suggests no packages.

-- no debconf information

Bug#816354: okular: No file association for pdf files and no menu entry

[Sten Heinze]

Package: okular
Version: 4:15.08.3-1
Severity: minor

Dear Maintainer,

* What led up to the situation?

  I installed okular on an uptodate Debian/testing to view a pdf file.

* What exactly did you do (or not do) that was effective (or ineffective)?
* What was the outcome of this action?

  Trying to open a pdf file from dolphin only leads to an 'open with..' dialog
  where I can select the application to do so. But no entry for okular can be
  found is the list of known application nor in the applications list in the 
  Plasma launcher. However, okular can be run from the command line and can 
  open the pdf file, so just the file associations and menu entry is missing.

* What outcome did you expect instead?

  Open okular displaying the selected pdf file from dolpin; or when starting
  from the launcher, okular to open without any files to display.


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

Kernel: Linux 4.3.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 okular depends on:
ii  kde-runtime 4:15.08.3-1+b1
ii  libc6   2.21-9
ii  libfreetype62.6.1-0.1
ii  libjpeg62-turbo 1:1.4.2-2
ii  libkactivities6 4:4.13.3-1
ii  libkdecore5 4:4.14.14-1+b1
ii  libkdeui5   4:4.14.14-1+b1
ii  libkexiv2-114:15.04.3-1
ii  libkio5 4:4.14.14-1+b1
ii  libkparts4  4:4.14.14-1+b1
ii  libkprintutils4 4:4.14.14-1+b1
ii  libkpty44:4.14.14-1+b1
ii  libokularcore6  4:15.08.3-1
ii  libphonon4  4:4.8.3-2
ii  libpoppler-qt4-40.38.0-2
ii  libqca2 2.1.1-2
ii  libqimageblitz4 1:0.0.6-4
ii  libqmobipocket1 4:14.12.2-2
ii  libqt4-dbus 4:4.8.7+dfsg-6
ii  libqt4-declarative  4:4.8.7+dfsg-6
ii  libqt4-svg  4:4.8.7+dfsg-6
ii  libqt4-xml  4:4.8.7+dfsg-6
ii  libqtcore4  4:4.8.7+dfsg-6
ii  libqtgui4   4:4.8.7+dfsg-6
ii  libsolid4   4:4.14.14-1+b1
ii  libspectre1 0.2.7-3
ii  libstdc++6  5.3.1-8
ii  phonon  4:4.8.3-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages okular recommends:
ii  cups-bsd  2.1.3-1

Versions of packages okular suggests:
pn  ghostscript
pn  jovie  
ii  okular-extra-backends  4:15.08.3-1
ii  poppler-data   0.4.7-7
pn  texlive-binaries   
pn  unrar  

-- no debconf information

Bug#813031: please multiarchify the library packages

[Michael Biebl]

Control: tags -1 - patch

Am 28.01.2016 um 17:35 schrieb Matthias Klose:
> Package: src:gnome-menus
> Version: 3.13.3-6
> Tags: patch
> User: d...@debian.org
> Usertags: multiarch
> 
> patch at
> http://launchpadlibrarian.net/226784022/gnome-menus_3.13.3-6ubuntu1_3.13.3-6ubuntu2.diff.gz

This patch doesn't contain anything useful, therefor removing the patch tag.


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



signature.asc
Description: OpenPGP digital signature

Bug#816352: qjackctl: FTBFS[!linux]: gethostname undeclared

[Steven Chamberlain]

Package: qjackctl
Version: 0.4.1-1
Severity: important
Tags: patch

Hi,

qjackctl stopped building on kfreebsd and hurd with upstream version
0.4.1.  I've attached a patch which also explains the regression:

Upstream commit 5e9eb4e32a1233ca92ec3684c357cec33a38d18b
removed #include , but this source file uses
gethostname() if CONFIG_X11 and CONFIG_XUNIQUE are defined.

On Linux the ALSA headers include unistd.h anyway, but this
broke the build on Debian GNU/kFreeBSD and Hurd.

So, add this back in, guarded by those macros just in case
some platforms don't have or need it.

Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
>From 3a14ba3f60579d87ebf5ff3d1e8d6954baa1df05 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain 
Date: Tue, 1 Mar 2016 03:46:44 +
Subject: [PATCH] include  again

Upstream commit 5e9eb4e32a1233ca92ec3684c357cec33a38d18b
removed #include , but this source file uses
gethostname() if CONFIG_X11 and CONFIG_XUNIQUE are defined.

On Linux the ALSA headers include unistd.h anyway, but this
broke the build on Debian GNU/kFreeBSD and Hurd.

So, add this back in, guarded by those macros just in case
some platforms don't have or need it.
---
 src/qjackctl.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/qjackctl.cpp b/src/qjackctl.cpp
index db37ed6..342d7e3 100644
--- a/src/qjackctl.cpp
+++ b/src/qjackctl.cpp
@@ -65,6 +65,8 @@ const WindowFlags WindowCloseButtonHint = WindowFlags(0x0800);
 #ifdef CONFIG_X11
 #ifdef CONFIG_XUNIQUE
 
+#include  /* for gethostname() */
+
 #include 
 
 #include 
-- 
1.8.4.rc3

Bug#816351: RFS: perspective-el/1.12+git20160216.add7942-1 -- tagged workspaces in Emacs

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an update to perspective-el.

* Package name: perspective-el
  Version : 1.12+git20160216.add7942-1
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/nex3/perspective-el
* License : GPL-3+ or MIT
  Section : lisp

Changes since the last upload:

  * Package upstream git repository snapshot in order to include in Debian
upstream's recent licensing clarification.
Update debian/copyright accordingly.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/perspective-el/perspective-el_1.12+git20160216.add7942-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-emacsen/pkg/perspective-el.git
cd perspective-el
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#816350: firmware-ti-connectivity: please include wl18xx-fw-4

[Ricardo Salveti]

Package: firmware-ti-connectivity
Version: 20160110-1

Please include wl18xx-fw-4, which is already part of the orig.tar.xz.
This firmware is used by wl18xx, and enables wifi support on the
96boards HiKey platform.

Debdiff can be found at
http://people.linaro.org/~ricardo.salveti/firmware-ti-connectivity-wl18xx-fw-4.patch

Thanks!

Bug#816349: aptitude: cannot seem to disable automatic download of updates

[Fulano Diego Perez]

Package: aptitude
Version: 0.7.5-3
Severity: normal



$ cat /etc/apt/apt.conf.d/02periodic
APT
{
Periodic
{
Download-Upgradeable-Packages "0";
Update-Package-Lists "0";
Unattended-Upgrade "0";
AutocleanInterval "0";
}
}


there is no /etc/apt/apt.conf by default as far as im aware in debian
stretch


what else needs to be done in order to disable this ?


is there a gnome package manager possibly interfering ?


its very frustrating on a limited bandwidth connection each time a usb
modem, for example, is connected ...



-- Package-specific info:
$TERM not set.
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.5
Compiler: g++ 5.3.1 20151207
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20151024
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffe0cb5d000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f011c7db000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f011c5ab000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f011c38)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f011c17a000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f011be7d000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f011bba6000)
libboost_iostreams.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f011b98c000)
libboost_filesystem.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7f011b773000)
libboost_system.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7f011b56e000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22
(0x7f011b16a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f011af4d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f011abd1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f011a8cc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f011a6b6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f011a311000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f011a10e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0119f0a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f0119cf2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0119ad7000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f01198c7000)
liblzma.so.5 => /usr/local/lib/liblzma.so.5 (0x7f01196a)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f011948e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0119285000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f011908)
/lib64/ld-linux-x86-64.so.2 (0x5629150be000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.7.5-3
ii  libapt-pkg5.0  1.2.3
ii  libboost-filesystem1.58.0  1.58.0+dfsg-4.1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-4.1
ii  libboost-system1.58.0  1.58.0+dfsg-4.1
ii  libc6  2.21-9
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:5.3.1-8
ii  libncursesw5   6.0+20151024-2
ii  libsigc++-2.0-0v5  2.6.2-1
ii  libsqlite3-0   3.10.2-1
ii  libstdc++6 5.3.1-8
ii  libtinfo5  6.0+20151024-2
ii  libxapian22v5  1.2.22-1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.7.5-3
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
ii  tasksel   3.34

-- no debconf information

Bug#815956: courier-imap fails to update

[Andrew Madison]

Due to lack of response this bug may be closed. I changed to dovecot from 
courier-imap. Thank you.
--
Andrew Madison
uskra...@gmail.com





signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#787663: aptitude forgets/clears manually set auto-installed-flags in several situations

[Manuel A. Fernandez Montecelo]

2016-02-29 22:28 GMT+00:00 Christoph Anton Mitterer :
> On Mon, 2016-02-29 at 18:52 +, Manuel A. Fernandez Montecelo wrote:
>> Because marking a package auto means to tell aptitude "remove it from
>> my system as soon as it's not needed".
>>
>>   http://aptitude.alioth.debian.org/doc/en/ch02s02s06.html
>>
>>   It works like this: when you install a package, aptitude will
>>   automatically install any other packages on which it depends.
>
> I know how it works, but that system alone is a bit limited, as it
> works only for those situations where there is actually a dependency
> expressed between the packages in question,... which in turn is however
> by far not every case where I install a package because of another
> package.
>
> E.g. I install m4-doc, because of m4, yet there is no dependency
> relation between them.

That looks like a thing better solved in the package dependencies, m4
could Suggest m4-doc, and then Auto-installed plus Suggests-Important
would keep would keep it installed.


> So all I can do is either not have m4-doc auto-marked, and I'll
> probably forget it once m4 is deleted (in which case I don't need m4-
> doc anymore)... or I use the current system a bit less narrow-minded
> and set my own manual auto-flag.

The system less narrow-minded is not truthful to the documentation and
what many people expect, and they expressed that repeatedly reporting
many bugs during the years.  Trust me, it was not fun wading through
many dozens of bug reports /related specifically with these issues/
and fixing them.

So I am not for screwing your workflow [1] gratuitously, but if I have
to choose between what most people expect and the way in which you use
it that doesn't match the documentation... well, you know the reply.

  [1] https://xkcd.com/1172/


> It may even go farther to say,... I install gimp and because I export
> my images as jpeg, I also install jpegoptim... these have nothing
> directly to do with each other and there will never be a dependency
> relationship between them.
> Still one may want to mark e.g. jpegoptim auto, in order not to forget
> about it.

I find it hard to sympathise with the idea that keeping m4-doc or
jpegoptim installed in the system for longer than strictly needed,
e.g. if you forget about it for a couple of months, is something Very
Bad.

Other people felt terribly that some packages that were not needed
were removed ASAP, I also find the idea a bit silly, but there were
many many many of them, so they won.

If it is so important for you, well, I already gave you hints about
how to be more proactive about it -- user tags.  Perhaps even creating
a simple script and e-mailing to you the tagged packages every few
weeks, to see if something has slipped through the cracks.

You might even do another proactive thing, try to read the
documentation and see if Delete-Unused does something for you.  But I
wouldn't have high hopes because these options which are not very
useful tend to bitrot with time, and they possibly clash with options
or features added later on.


> It may not be the primary way auto-installation/removal is intended to
> be used, but I see no reason why not to allow that use case.

"Clashing with other people's expectations" and "not being able to
work both ways at the same time" might be one reason.


> Actually the current system is even more "limited",...
> E.g. I may have a package xyz that recommends some python-gibberish...
> and I say, yes I want to use that functionality that python-gibberish
> gives to xyz.
> So it's marked auto-installed.
>
> Now I install abc further package abc, which e.g. suggest, but here I
> don't have any intentions to use that with python-gibberish.
> However, when I remove xyz, pyhton-gibberish, will of course not be
> auto-removed.

Uh-hum.

So you see, there's no way for aptitude to know the intentions of the
user in all cases.

If s/he wants the package in the system but s/he marks the package as
"auto-installed" instead, so aptitude can remove it because nothing
else depends on it, the user gets pissed off.  If other packages
depend on a given package and aptitude doesn't remove it automatically
when the user might not want it installed anymore for some reason,
then aptitude doesn't remove it, just to spite the user!  And the user
gets pissed off.

This perhaps happens because dependencies don't always match 100% what
it right, or what the user expects; and even if the user wants A today
maybe s/he wants B tomorrow, so there is little hope that aptitude can
fulfill 100% the desires of the users all of the time.  AI is not
there yet, and aptitude --prescient was not implemented yet.

It looks to me that the only way to keep the evil aptitude in check is
to closely monitor it, e.g. with simple inspections of what's
installed from time to time and prune unwanted things, use patterns
and user-tags and other features that aptitude provides, and keep
aptitude in check.


>> If human 

Bug#814070: (no subject)

[gustavo panizzo (gfa)]

I've backported curl 7.47.0 from sid to jessie, that has solved my
problems



-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

Bug#812371: nis: NIS is started before rpcbind since rpcbind was migrated to systemd

[Nye Liu]

On Thu, Feb 18, 2016 at 02:32:43PM +, Mark Brown wrote:
> On Fri, Jan 22, 2016 at 01:47:36PM -0800, Nye Liu wrote:
>
> > > It should eventually figure things out?
>
> > No, but I have a patch for nis script, attached...
>
> I can't tell what this patch is supposed to do, sorry.

It retries starting ypbind until it stays running.

If rpcbind isn't running this script hangs forever... it never detects
that ypbind doesn't stay running, because ypbind exits if rpcbind
isn't running.

>
> > --- dist/nis2016-01-20 16:18:24.171239577 -0800
> > +++ nis 2016-01-22 13:08:19.532968676 -0800
> > @@ -43,24 +43,38 @@
> >
> > if [ "`ypwhich 2>/dev/null`" = "" ]
> > then
> > +   running=""
> > bound=""
> > log_action_begin_msg "binding to YP server"
> > -   for i in 1 2 3 4 5 6 7 8 9 10
> > +   for i in `seq 10`
> > do
> > sleep 1
> > -   log_action_cont_msg "."
> > -   if [ "`ypwhich 2>/dev/null`" != "" ]
> > +   # make sure ypbind started; rpcbind might not be 
> > ready yet
> > +   if [ -n "$( pidofproc ${NET}/ypbind )" ]
> > then
> > -   echo -n " done] "
> > -   bound="yes"
> > -   break
> > +   log_action_cont_msg "."
> > +   running="yes"
> > +   if [ "`ypwhich 2>/dev/null`" != "" ]
> > +   then
> > +   echo -n " done] "
> > +   bound="yes"
> > +   break
> > +   fi
> > +   else
> > +   running=""
> > +   # try to start ypbind again
> > +   log_action_cont_msg "x"
> > +   ypbind_start
> > fi
> > done
> > # This should potentially be an error
> > if [ "$bound" ] ; then
> > log_action_end_msg 0
> > -   else
> > +   elif [ "$running" ] ; then
> > log_action_end_msg 1 "backgrounded"
> > +   else
> > +   log_action_end_msg 1 "failed"
> > +   exit 1
> > fi
> > fi
> >  }



--
Nye Liu
n...@mrv.com
(747) 224-2253
(818) 772-0576 fax

"Who would be stupid enough to quote a fictitious character?"
-- Don Quixote


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#813461: cqrlog: FTBFS: lcommon.pp(515,18) Error: (5038) identifier idents no member "family"

[peter green]

tags 813461 +patch
thanks

cqrlog fails to build from source in unstable/amd64:

Colin asked me to take a look at this.

Fixing the build failure is trivial enough, just a matter of avoiding 
some field aliases that iirc were considered deprecated for some time 
and have been removed in 3.0.0


A patch is attatched, note that I have not tested whether the resulting 
packages work. No intent to NMU.
diff -urN cqrlog-1.9.0/debian/patches/fpc-3.0 cqrlog-1.9.0.new/debian/patches/fpc-3.0
--- cqrlog-1.9.0/debian/patches/fpc-3.0	1970-01-01 00:00:00.0 +
+++ cqrlog-1.9.0.new/debian/patches/fpc-3.0	2016-03-01 01:51:42.0 +
@@ -0,0 +1,31 @@
+Description: Fix build with fpc 3.0
+ Some deprecated field name aliases were removed in fpc 3.0. Update the code
+ to use non-deprecated names.
+Author: Peter Michael Green 
+Bug-Debian: https://bugs.debian.org/813461
+
+Index: cqrlog-1.9.0.new/src/lnet/lib/lcommon.pp
+===
+--- cqrlog-1.9.0.new.orig/src/lnet/lib/lcommon.pp
 cqrlog-1.9.0.new/src/lnet/lib/lcommon.pp
+@@ -512,15 +512,15 @@ end;
+ procedure FillAddressInfo(var aAddrInfo: TLSocketAddress; const aFamily: sa_family_t;
+   const Address: string; const aPort: Word);
+ begin
+-  aAddrInfo.IPv4.family := aFamily;
+-  aAddrInfo.IPv4.Port := htons(aPort);
++  aAddrInfo.IPv4.sin_family := aFamily;
++  aAddrInfo.IPv4.sin_port := htons(aPort);
+ 
+   case aFamily of
+ LAF_INET  :
+   begin
+-aAddrInfo.IPv4.Addr := StrToNetAddr(Address);
+-if (Address <> LADDR_ANY) and (aAddrInfo.IPv4.Addr = 0) then
+-  aAddrInfo.IPv4.Addr := StrToNetAddr(GetHostIP(Address));
++aAddrInfo.IPv4.sin_addr.s_addr := StrToNetAddr(Address);
++if (Address <> LADDR_ANY) and (aAddrInfo.IPv4.sin_addr.s_addr = 0) then
++  aAddrInfo.IPv4.sin_addr.s_addr := StrToNetAddr(GetHostIP(Address));
+   end;
+ LAF_INET6 :
+   begin
diff -urN cqrlog-1.9.0/debian/patches/series cqrlog-1.9.0.new/debian/patches/series
--- cqrlog-1.9.0/debian/patches/series	2015-09-22 17:59:53.0 +
+++ cqrlog-1.9.0.new/debian/patches/series	2016-02-29 23:13:15.0 +
@@ -1,3 +1,4 @@
 makefile-no-homedir-use
 desktop-keywords
 apparmor.patch
+fpc-3.0

Bug#816348: bugs.debian.org: forcemerge is confused by the order of blocked bugs

[Mike Hommey]

Package: bugs.debian.org
Severity: normal

See the following output that control returned to me:

> forcemerge 815269 815578 816329
Bug #815269 [iceweasel] iceweasel: Icon doesn't appear on MATE taskbar, works 
for other apps and worked on 44.0-1
Bug #816329 [iceweasel] iceweasel icon on xfce-whisker or xfce-application menu 
missing
Severity set to 'important' from 'normal'
816329 was not blocked by any bugs.
816329 was not blocking any bugs.
Added blocking bug(s) of 816329: 802555 and 801992
816329 was blocked by: 802555 801992
816329 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #816329 to the same blocks 
previously set
Bug #815578 [iceweasel] iceweasel: Wrong /usr/share/pixmaps/iceweasel.xpm
Severity set to 'important' from 'minor'
815578 was not blocked by any bugs.
815578 was not blocking any bugs.
Added blocking bug(s) of 815578: 802555 and 801992
815578 was blocked by: 801992 802555
815578 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #815578 to the same blocks 
previously set
Bug #815578 [iceweasel] iceweasel: Wrong /usr/share/pixmaps/iceweasel.xpm
Unable to complete merge on previous attempt; trying again (retry: 2)
Bug #815578 [iceweasel] iceweasel: Wrong /usr/share/pixmaps/iceweasel.xpm
Unable to complete merge on previous attempt; trying again (retry: 3)
Bug #815578 [iceweasel] iceweasel: Wrong /usr/share/pixmaps/iceweasel.xpm
After four attempts, the following changes were unable to be made:
blockedby of #815578 is '801992 802555' not '802555 801992'
Failed to forcibly merge 815269: Unable to modify bugs so they could be merged.


I'll try to work around, but it seems it could be smarter.

Bug#816347: blacs-mpi: run testsuite

[Michael Banck]

Package: blacs-mpi
Version: 1.1-33.3
Severity: important
Tags: patch

Hi,

I guess the severity can be bikeshedded at, but I find it important to
exercise the testsuites at build time at least once before a release on
all arches.

Hence, I've written the attached patch that runs the test programs and
checks for failures. It is rather simple, but better than nothing in my
opinion.

If people think this is a good idea, I'look into adapting the patch for
scalapack.

The main question is whether the tests are too big for our smaller
arches, but we won't find out if we don't try it.


Michael
diff -u blacs-mpi-1.1/debian/changelog blacs-mpi-1.1/debian/changelog
--- blacs-mpi-1.1/debian/changelog
+++ blacs-mpi-1.1/debian/changelog
@@ -1,3 +1,10 @@
+blacs-mpi (1.1-33.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Run testsuite 
+
+ -- Michael Banck   Tue, 01 Mar 2016 01:59:46 +0100
+
 blacs-mpi (1.1-33.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u blacs-mpi-1.1/debian/control blacs-mpi-1.1/debian/control
--- blacs-mpi-1.1/debian/control
+++ blacs-mpi-1.1/debian/control
@@ -8,7 +8,7 @@
 Priority: extra
 Maintainer: Muammar El Khatib 
 Standards-Version: 3.9.1
-Build-Depends: debhelper (>= 7), mpi-default-dev (>= 1.0), gfortran, pkg-config
+Build-Depends: debhelper (>= 7), mpi-default-dev (>= 1.0), mpi-default-bin, gfortran, pkg-config
 Homepage: http://www.netlib.org/blacs/
 
 Package: libblacs-openmpi1
diff -u blacs-mpi-1.1/debian/control.in blacs-mpi-1.1/debian/control.in
--- blacs-mpi-1.1/debian/control.in
+++ blacs-mpi-1.1/debian/control.in
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Muammar El Khatib 
 Standards-Version: 3.9.1
-Build-Depends: debhelper (>= 7), mpi-default-dev (>= 1.0), gfortran, pkg-config
+Build-Depends: debhelper (>= 7), mpi-default-dev (>= 1.0), mpi-default-bin, gfortran, pkg-config
 Homepage: http://www.netlib.org/blacs/
 
 Package: libblacs-openmpi1
diff -u blacs-mpi-1.1/debian/rules blacs-mpi-1.1/debian/rules
--- blacs-mpi-1.1/debian/rules
+++ blacs-mpi-1.1/debian/rules
@@ -16,13 +16,13 @@
 
 build: build-$(ARCH_DEFAULT_MPI_IMPL)
 
-build-openmpi: build-stamp-openmpi
+build-openmpi: build-stamp-openmpi check-stamp-openmpi
 
-build-lam: build-stamp-lam
+build-lam: build-stamp-lam check-stamp-lam
 
-build-mpich: build-stamp-mpich
+build-mpich: build-stamp-mpich check-stamp-mpich
 
-build-mpich2: build-stamp-mpich2
+build-mpich2: build-stamp-mpich2 check-stamp-mpich2
 
 patch-stamp:
 	patch -p1 < debian/blacs-mpi-implementations.patch
@@ -193,6 +193,70 @@
 
 	touch build-stamp-mpich2
 
+check-stamp-openmpi:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+	dh_testdir
+	if [ -x /usr/bin/mpiexec.openmpi ]; then \
+	  (cd TESTING/EXE; for i in *-openmpi; do \
+	echo "Running test $$i"; \
+	LD_LIBRARY_PATH=../../ mpiexec.openmpi -np 4 ./$$i > $$i.log 2>&1 ; \
+	grep FAILED $$i.log | sed s/DOUBLE// | \
+	awk '{total += $$4; passed += $$6; skipped += $$8; failed += $$10} END \
+	  {print "total: " total " passed: " passed " skipped: " skipped " failed: " failed ; \
+	  if (failed > 0) {exit 1}}' ; \
+	  done) \
+	fi
+endif
+	touch check-stamp-openmpi
+
+check-stamp-lam:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+	dh_testdir
+	if [ -x /usr/bin/mpiexec.lam ]; then \
+	  (cd TESTING/EXE; for i in *-lam; do \
+	echo "Running test $$i"; \
+	LD_LIBRARY_PATH=../../ mpiexec.lam -np 4 ./$$i > $$i.log 2>&1 ; \
+	grep FAILED $$i.log | sed s/DOUBLE// | \
+	awk '{total += $$4; passed += $$6; skipped += $$8; failed += $$10} END \
+	  {print "total: " total " passed: " passed " skipped: " skipped " failed: " failed ; \
+	  if (failed > 0) {exit 1}}' ; \
+	  done) \
+	fi
+endif
+	touch check-stamp-lam
+
+check-stamp-mpich:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+	dh_testdir
+	if [ -x /usr/bin/mpiexec.mpich ]; then \
+	  (cd TESTING/EXE; for i in *-mpich; do \
+	echo "Running test $$i"; \
+	LD_LIBRARY_PATH=../../ mpiexec.mpich -np 4 ./$$i > $$i.log 2>&1 ; \
+	grep FAILED $$i.log | sed s/DOUBLE// | \
+	awk '{total += $$4; passed += $$6; skipped += $$8; failed += $$10} END \
+	  {print "total: " total " passed: " passed " skipped: " skipped " failed: " failed ; \
+	  if (failed > 0) {exit 1}}' ; \
+	  done) \
+	fi
+endif
+	touch check-stamp-mpich
+
+check-stamp-mpich2:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+	dh_testdir
+	if [ -x /usr/bin/mpiexec.mpich2 ]; then \
+	  (cd TESTING/EXE; for i in *-mpich2; do \
+	echo "Running test $$i"; \
+	LD_LIBRARY_PATH=../../ mpiexec.mpich2 -np 4 ./$$i > $$i.log 2>&1 ; \
+	grep FAILED $$i.log | sed s/DOUBLE// | \
+	awk '{total += $$4; passed += $$6; skipped += $$8; failed += $$10} END \
+	  {print "total: " total " passed: " passed " skipped: " skipped " failed: " failed ; \
+	  if (failed > 0) {exit 1}}' ; \
+	  done) \
+	fi
+endif
+	touch 

Bug#815833: Fake-hwclock: consider mtime of root (/) if no saved file

[Steve McIntyre]

Hi Roddy, and thanks for getting in touch!

On Wed, Feb 24, 2016 at 09:27:26PM +, Roddy Shuler wrote:
>Package: fake-hwclock
>Version: 0.9
>
>Upon first use of fake-hwclock, if the device does not have a
>battery-backed clock (and has not saved fake-hwclock.data yet), the clock
>will typically start at Jan 1, 1970 UTC.  This has the following
>repercussions:
>- Before manually adjusting the time, it will be behind other files on the
>system
>- Manual adjustment of the clock via a UI with a mouse will require several
>clicks to increment the year from 1970 to the current
>- If the user does not adjust the time, website certificates will be
>rejected as not yet valid
>
>While a fake clock is never perfect, we can get closer to reality by keying
>off of the modification time of a file or directory, so that on first boot
>the clock will effectively be set to a time that is no earlier than the
>time at which the file system was built.  Using the root directory (/)
>seems safest as it is a directory that can be assumed to always exist.

OK, I see your logic but I'm not sure it's the way I'd choose to
go. What you *have* identified is that there's a hole in the package
such that it may not get to save a state file before rebooting. I'm
thinking a better fix would be to add a call to "fake-hwclock save" in
the postinst. How does that sound?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#816346: dpkg-dev: dpkg-shlibdeps should recognize both host and target objects

[Samuel Thibault]

Package: dpkg-dev
Version: 1.18.4
Severity: normal

Hello,

In Objdump.pm, we use debarch_to_gnutriplet(get_host_arch()).'-objdump';
to run dpkg-shlibdeps on package objects.

When building a cross-compiler, this is however not working. The
cross-compiler itself is fine (since it's host), but the cross-compiler
package also ships a few *target* objects, and for them one would have
to use something like

debarch_to_gnutriplet(get_target_arch()).'-objdump';

That however doesn't seem to exist in libdpkg-perl yet. Also, dpkg-shlibdeps
will probably need to try both, because it can't know which objects are
for the host or for the target.

Otherwise, we for instance get this while building a cross gcc:

dpkg-shlibdeps -Tdebian/gcc-5-x86-64-linux-gnu.substvars 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-5 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-5 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-tool-5 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ar-5 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ranlib-5 
debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-nm-5 
debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/collect2 
debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto1 
debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper 
debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/plugin/libcc1plugin.so.0.0.0
/usr/bin/objdump: debian/libgcc1/lib/x86_64-linux-gnu/libgcc_s.so.1: File 
format not recognized

That happens when the build and host are a 32bit architecture which
doesn't have multilib support and target is a 64bit architecture, and
thus its native objdump probably does not understand 64bit binaries.

Samuel

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

Kernel: Linux 4.4.0 (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: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  base-files9.5
ii  binutils  2.26-4
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.4
ii  make  4.1-6
ii  patch 2.7.5-1
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.2
ii  clang-3.5 [c-compiler]   1:3.5.2-3
ii  clang-3.6 [c-compiler]   1:3.6.2-3
ii  fakeroot 1.20.2-1
ii  gcc [c-compiler] 4:5.3.1-1
ii  gcc-4.8 [c-compiler] 4.8.5-4
ii  gcc-4.9 [c-compiler] 4.9.3-12
ii  gcc-5 [c-compiler]   5.3.1-8
ii  gcc-6 [c-compiler]   6-20160109-1
ii  gnupg1.4.20-4
ii  gnupg2   2.1.11-5
ii  gpgv 1.4.20-4
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.01.20

-- no debconf information

-- 
Samuel
 I hated the Mighty Mouse in the Apple Store every time I played with it. I 
hated the Mighty Mouse at work whenever I set up a Mac for somebody.
 I decided to give it one last chance when I set up my new Mac
 And golly, I like it at home.
 Maybe mine is defective in a way that makes it good.

Bug#813952: RFS: helm/1.9.2-1 -- Emacs incremental completion and selection narrowing framework

[Sean Whitton]

Hello,

Thank you for your review.

On Mon, Feb 29, 2016 at 11:25:22PM +, Mattia Rizzolo wrote:
> On Sat, Feb 06, 2016 at 06:11:40PM -0700, Sean Whitton wrote:
> > git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/helm
> > git checkout debian/1.9.2-1
> 
> there is no such tag (luckily?)

The Emacs Addons packaging team recently started using PET [1], which
works best if packages are tagged only after they are uploaded, so I
removed the tag.

I didn't expect anyone outside of the Emacs team to look at the RFS --
thanks again! -- so I decided not to spam debian-mentors with a message
saying I'd removed the tag.

By the way, please be sure to check out the pristine-tar branch so that
you use the same orig.tar as I'm working with :)

> anyway, looking at HEAD:
> 
> * please use standards-versions 3.9.7

Done.

> 
> * from the changelog:
>   + "New dependency on elpa-popup."  I don't see such thing in the
> debdiff generated

It's included in the ${elpa:Depends} substvar by dh_elpa, so it wouldn't
show up in debdiff.

>   + "Update emacs-helm.sh patch for new upstream release."  usually this
> is written like "Refresh patch ", I find
> hard to understand your sentence, tbh...

Cool, I've improved the changelog.

[1] https://pet.debian.net/pkg-emacsen/pet.cgi

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#816345: RM: ruby-racc -- ROM; duplicate of racc

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

due to lack of coordination somebody on the pkg-ruby-extras team
uploaded ruby-racc, which is a copy of the existing racc package,
also maintained by pkg-ruby-extras.

Please remove ruby-racc.

Thank you,
Christian
(wearing my pkg-ruby-extras hat)

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#816344: slbackup: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: slbackup
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


-- 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/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


ja.po.gz
Description: application/gzip

Bug#816343: cinder: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: cinder
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


-- 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/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


ja.po.gz
Description: application/gzip

Bug#816342: ceilometer: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: ceilometer
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


-- 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/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


ja.po.gz
Description: application/gzip

Bug#811308: imagemagick: Missing upstream fix for 'PixelColor off by one on i386'

[Nish Aravamudan]

On 25.02.2016 [10:54:51 -0800], Nish Aravamudan wrote:
> On 25.02.2016 [09:29:44 -0800], Nishanth Aravamudan wrote:
> > Package: imagemagick
> > Version: 8:6.8.9.9-7
> > Followup-For: Bug #811308
> > 
> > Dear Maintainer,
> > 
> > While working on Ubuntu 16.04, I noticed that the currently sync'd
> > version of imagemagick, 8:6.8.9.9-7 has backported the fixes for
> > https://github.com/ImageMagick/ImageMagick/issues/54, but missed one
> > change:
> > https://github.com/ImageMagick/ImageMagick/commit/95c8394eaacc8c2f272177269416daf0b2ba004f.
> > 
> > The patches git commit in question is:
> > http://anonscm.debian.org/cgit/collab-maint/imagemagick.git/commit/?h=debian-patches/6.8.9.9-7=f40ae7899afa53437ea99f7be105e549e85b0c47
> > 
> > Note also that since the bugfix in question came from a version greater
> > than 0x689 but the Debian package's version number has not been
> > modified, I think that other packages (e.g., php-imagick) can't use the
> > version number any longer to determine if/when a test has been fixed.
> 
> Ah, actually I was slightly wrong about this, as there is another
> upstream commit that seems to have been missed that is really the reason
> for the testcase failure I'm seeing:
> 
> https://github.com/ImageMagick/ImageMagick/commit/d60548249a3370e481ef43f206b6af95c9dd7364#diff-b48c4feab32724d54e6e77845f23f7cc

Sorry for the noise, but there are (eventually) three upstream commits
that are needed on top of the current backport in Debian:

https://github.com/ImageMagick/ImageMagick/commit/d6054824
https://github.com/ImageMagick/ImageMagick/commit/95c8394e
https://github.com/ImageMagick/ImageMagick/commit/68c6a7d

-Nish

Bug#816341: lintian: Prevent the checking for dh-exec-useless-usage on *.dirs files

[Rafael Laboissiere]

Package: lintian
Version: 2.5.41
Severity: normal

The octave package has a debian/octave.dirs file with the following 
contents:


   #!/usr/bin/dh-exec
   # create directories for Octave packages
   usr/share/octave/packages/
   usr/lib/${DEB_HOST_MULTIARCH}/octave/packages

This is a legitimate way to create the architecture-dependent empty 
directory in /usr/lib/ through dh-exec.  However, this triggers the 
Lintian warning dh-exec-useless-usage.


The problem is that this check is tailored for *.install files.  In 
that case, "${DEB_HOST_MULTIARCH}" could be indeed replaced by "*". 
However, this is nont the case for *.dirs files.


Please, consider preventing the checking for dh-exec-useless-usage on 
*.dirs files.


Rafael Laboissière

-- System Information:

Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (550, 'stable'), (500, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages lintian depends on:

ii  binutils  2.26-4
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.56-2
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdpkg-perl  1.18.4
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-7
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-7
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:

ii  dpkg 1.18.4
ii  libautodie-perl  2.29-2
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.1-7
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-7

Versions of packages lintian suggests:

pn  binutils-multiarch 
ii  dpkg-dev   1.18.4
ii  libhtml-parser-perl3.72-1
pn  libtext-template-perl  

-- no debconf information

Bug#816340: lack of rtaudio blocks Movit support in Kdenlive

[Steinar H. Gunderson]

Source: mlt
Version: 6.0.0-2
Severity: normal

Hi,

rtaudio was removed from the Debian MLT package in #668893
(in 2012) due to concerns over the embedded copy. However,
it seems Kdenlive now requires rtaudio support in MLT before
it's willing to enable GPU filters via Movit. (I don't know
exactly why; the comments indicate Movit and SDL audio together
crashes, but when I developed this support back in the day,
I saw no such issues.)

Could you please consider reenabling it? The bug seems to
indicate that work on building against a non-bundled rtaudio
was in progress at the time.

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

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

Bug#816339: check: Making check/subunit bootstrappable

[Samuel Thibault]

Package: check
Version: 0.10.0-3
Severity: normal
Tags: patch

Hello,

check build-depends on subunit, and subunit build-depends on check. It
happens that check has a disable flag against that build, but subunit
doesn't. The attached patch thus adds a stage1 profile to the check
package, thus allowing to build a version of check that can then be used
to build subunit, which can then be used to build the full unstaged
check.

Samuel

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

Kernel: Linux 4.4.0 (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: systemd (via /run/systemd/system)

Versions of packages check depends on:
ii  dpkg1.18.4
ii  install-info6.1.0.dfsg.1-1
pn  libsubunit-dev  
ii  mawk1.3.3-17

check recommends no packages.

check suggests no packages.

-- no debconf information

-- 
Samuel
 t1 faich
 les programmes ils segfaultent jamais quand on veut
 -+- #ens-mim en plein débogage -+-
--- debian/rules.original   2016-03-01 00:33:42.478666936 +0100
+++ debian/rules2016-03-01 00:34:49.468419406 +0100
@@ -1,5 +1,11 @@
 #!/usr/bin/make -f
 
+ifneq ($(DEB_BUILD_PROFILES),stage1)
+ENABLE_SUBUNIT=--enable-subunit
+else
+ENABLE_SUBUNIT=
+endif
+
 %:
dh $@ --buildsystem=autoconf --with autoreconf
 
@@ -11,12 +17,12 @@
dh_auto_configure --builddirectory build-standard -- --prefix=/usr \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--host=$(DEB_HOST_GNU_TYPE) \
-   --infodir=/usr/share/info --disable-shared --enable-subunit
+   --infodir=/usr/share/info --disable-shared $(ENABLE_SUBUNIT)

CFLAGS="-fPIC $(CFLAGS)" dh_auto_configure --builddirectory build-pic
-- --prefix=/usr --host=$(DEB_HOST_GNU_TYPE) \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
-   --infodir=/usr/share/info --disable-shared --enable-subunit
+   --infodir=/usr/share/info --disable-shared $(ENABLE_SUBUNIT)
 
 override_dh_auto_build:
dh_auto_build --builddirectory build-standard
--- debian/control.original 2016-03-01 00:33:19.828752383 +0100
+++ debian/control  2016-03-01 00:33:26.618726675 +0100
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Robert Lemmen 
-Build-Depends: debhelper (>= 9), mawk, texinfo, dh-autoreconf, pkg-config, 
libsubunit-dev
+Build-Depends: debhelper (>= 9), mawk, texinfo, dh-autoreconf, pkg-config, 
libsubunit-dev 
 Build-Conflicts: gawk
 Standards-Version: 3.9.6
 Homepage: http://check.sourceforge.net/
@@ -13,7 +13,7 @@
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, dpkg (>= 1.15.4) | install-info, mawk, libsubunit-dev
+Depends: ${misc:Depends}, dpkg (>= 1.15.4) | install-info, mawk, 
libsubunit-dev 
 Description: unit test framework for C
  Check features a simple interface for defining unit tests, putting
  little in the way of the developer. Tests are run in a separate

Bug#816338: test -d /etc/php5 before warning

[積丹尼 Dan Jacobson]

Package: php5-json
Version: 1.3.7-1

You should test -d /etc/php5 before warning.

Removing php5-json (1.3.7-1) ...
Purging configuration files for php5-json (1.3.7-1) ...
WARN: php5-common has been removed, you need to cleanup /etc/php5 yourself.

Current status: 0 (+0) broken, 34 (+0) upgradable, 51124 (+0) new.
# ls -l /etc/php5
ls: cannot access '/etc/php5': No such file or directory

Bug#816337: prerm called with unknown argument `upgrade'

[積丹尼 Dan Jacobson]

Package: scim
Version: 1.4.15-5.1

Preparing to unpack .../scim_1.4.15-5.1_i386.deb ...
prerm called with unknown argument `upgrade'
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK
Unpacking scim (1.4.15-5.1) over (1.4.15-5) ...

Bug#816336: forcing reinstallation of alternative /bin/mt-gnu because link group mt is broken

[積丹尼 Dan Jacobson]

Package: cpip
Version: 2.11+dfsg-5

Setting up cpio (2.11+dfsg-5) ...
update-alternatives: warning: forcing reinstallation of alternative /bin/mt-gnu 
because link group mt is broken
update-alternatives: warning: not replacing /usr/share/man/man1/mt.1.gz with a 
link

Bug#816335: unable to delete old directory '/etc/iceweasel/profile': Directory not empty

[積丹尼 Dan Jacobson]

Package: iceweasel
Version: 46.0~a2+20160217064514-1

You need to reverse the order of steps, and also remove empty
directories, and more files, to avoid the user getting these messages.

Unpacking iceweasel (46.0~a2+20160217064514-1) over (45.0~a2+20160107004004-1) 
...
dpkg: warning: unable to delete old directory '/etc/iceweasel/profile/chrome': 
Directory not empty
dpkg: warning: unable to delete old directory '/etc/iceweasel/profile': 
Directory not empty

Soon after I then do

$ find /etc/iceweasel/ -ls
   132855  4 drwxr-xr-x   5 root root 4096  7月 27  2013 
/etc/iceweasel/
   132858  4 drwxr-xr-x   3 root root 4096  3月  1 07:23 
/etc/iceweasel/profile
   132863  4 -rw-r--r--   1 root root  473  7月 26  2013 
/etc/iceweasel/profile/prefs.js.dpkg-remove
   132865  4 -rw-r--r--   1 root root  366  7月 26  2013 
/etc/iceweasel/profile/localstore.rdf.dpkg-remove
   132860  4 drwxr-xr-x   2 root root 4096  3月  1 07:23 
/etc/iceweasel/profile/chrome
   132862  4 -rw-r--r--   1 root root  761  7月 26  2013 
/etc/iceweasel/profile/chrome/userContent-example.css.dpkg-remove
   132861  4 -rw-r--r--   1 root root 1165  7月 26  2013 
/etc/iceweasel/profile/chrome/userChrome-example.css.dpkg-remove
   132859  4 -rw-r--r--   1 root root  569  7月 26  2013 
/etc/iceweasel/profile/mimeTypes.rdf.dpkg-remove
   132856  4 drwxr-xr-x   2 root root 4096  3月  1 07:23 
/etc/iceweasel/pref
   133364  4 -rw-r--r--   1 root root 1219  2月 18 15:30 
/etc/iceweasel/pref/iceweasel.js.dpkg-new
   133140  4 -rw-r--r--   1 root root 1219  9月  7 17:36 
/etc/iceweasel/pref/iceweasel.js
   132866  4 drwxr-xr-x   4 root root 4096  7月 27  2013 
/etc/iceweasel/searchplugins
   132876  4 drwxr-xr-x   2 root root 4096  3月  1 07:23 
/etc/iceweasel/searchplugins/common
   133365  4 -rw-r--r--   1 root root 1245  2月 18 12:07 
/etc/iceweasel/searchplugins/common/debsearch.xml.dpkg-new
   132878  4 -rw-r--r--   1 root root 1245  7月 26  2013 
/etc/iceweasel/searchplugins/common/debsearch.xml
   132867  4 drwxr-xr-x   3 root root 4096  7月 27  2013 
/etc/iceweasel/searchplugins/locale
   132868  4 drwxr-xr-x   2 root root 4096  9月  9 07:00 
/etc/iceweasel/searchplugins/locale/en-US

A little later I do it again

$ find /etc/iceweasel/ -ls
   132855  4 drwxr-xr-x   5 root root 4096  7月 27  2013 
/etc/iceweasel/
   132858  4 drwxr-xr-x   3 root root 4096  3月  1 07:30 
/etc/iceweasel/profile
   132860  4 drwxr-xr-x   2 root root 4096  3月  1 07:30 
/etc/iceweasel/profile/chrome
   132856  4 drwxr-xr-x   2 root root 4096  3月  1 07:30 
/etc/iceweasel/pref
   133140  4 -rw-r--r--   1 root root 1219  9月  7 17:36 
/etc/iceweasel/pref/iceweasel.js
   132866  4 drwxr-xr-x   4 root root 4096  7月 27  2013 
/etc/iceweasel/searchplugins
   132876  4 drwxr-xr-x   2 root root 4096  3月  1 07:30 
/etc/iceweasel/searchplugins/common
   132878  4 -rw-r--r--   1 root root 1245  7月 26  2013 
/etc/iceweasel/searchplugins/common/debsearch.xml
   132867  4 drwxr-xr-x   3 root root 4096  7月 27  2013 
/etc/iceweasel/searchplugins/locale
   132868  4 drwxr-xr-x   2 root root 4096  9月  9 07:00 
/etc/iceweasel/searchplugins/locale/en-US

One also sees

Setting up iceweasel (46.0~a2+20160217064514-1) ...
Removing obsolete conffile /etc/iceweasel/profile/chrome/userChrome-example.css 
...
Removing obsolete conffile 
/etc/iceweasel/profile/chrome/userContent-example.css ...
Removing obsolete conffile /etc/iceweasel/profile/localstore.rdf ...
Removing obsolete conffile /etc/iceweasel/profile/mimeTypes.rdf ...
Removing obsolete conffile /etc/iceweasel/profile/prefs.js ...

Bug#816334: libserialport: FTBFS[!linux]: missing _DEFAULT_SOURCE

[Steven Chamberlain]

Package: libserialport
Version: 0.1.0-1
Severity: important
Tags: patch

Hi,

libserialport FTBFS in up-to-date sid.  Perhaps some recent cleanup of
glibc headers triggered this, but there was a pre-existing issue here
in libserialport_internal.h:

 25 #ifdef __linux__
 26 /* For timeradd, timersub, timercmp. */
 27 #define _BSD_SOURCE 1 /* for glibc < 2.19 */
 28 #define _DEFAULT_SOURCE 1 /* for glibc >= 2.20 */
 29 #endif

What really should be tested for is __GLIBC__, not the kernel.  With
the attached patch, this compiles again on kfreebsd, and probably hurd
as well.  Thank you!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- a/libserialport_internal.h	2016-01-27 14:12:27.0 +
+++ b/libserialport_internal.h	2016-02-29 23:30:51.701109454 +
@@ -22,7 +22,7 @@
 #define LIBSERIALPORT_LIBSERIALPORT_INTERNAL_H
 
 
-#ifdef __linux__
+#ifdef __GLIBC__
 /* For timeradd, timersub, timercmp. */
 #define _BSD_SOURCE 1 /* for glibc < 2.19 */
 #define _DEFAULT_SOURCE 1 /* for glibc >= 2.20 */

Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver

[Jose M Calhariz]

On 29/02/16 23:09, Mattia Rizzolo wrote:
> sorry, this took awfully long.
>
> On Fri, Feb 05, 2016 at 11:09:20PM +, Jose M Calhariz wrote:
>> Amanda have release a new upstream version.  My main sponsor is too
>> busy for helping me.  So I am searching for someone that can help
>> sponsor the new release.
> Ok, I can do it.

Thank you.

> Should I use the git repository?

Yes.  I just have upload one more patch to fix a nasty bug in amanda 3.3.8.

In the next days I will work through your task list.

> Just looking through cgit, I can ask you the following things:
>
> * https in Vcs-Git please
> * standards-version to 3.9.7
> * version restriction on tar can go away, and tar being essential:yes
>   the whole dep can go away
> * are you sure the perl dep is needed?  ${perl:Depends} ought to do it
> * guessing you are using git-buildpackage, why didn't you just
>   `gbp import-dsc` to import the NMU?
> * please push the tag for the upstream part
> * you have a build-dep on debhelper version >= 9, but you use compat 5.
>   please bump the compat, after checking the differences in debhelper(7)
> * the *.dirs files don't need to list directories for files installed by
>   other dh_* things, so I'm confident at least line 3,4,5 of
>   amanda-server.dirs are useless, haven't looked at the others
> * I'm not happy with the old style rules file, but guess I can't ask
>   that much in this case, and I can live well with it anyway :)
>
> ↑ that's the kind of things I want to see changed for me to sponsor it.
> If you confirm I should look at the git repository and you're ok with me
> as a sponsor please confirm so (and fix the already reported problems,
> please ;))
>

Kind regards
Jose M Calhariz




signature.asc
Description: OpenPGP digital signature

Bug#815786: d-i does not ask for hostname

[Roger Shimizu]

On Tue, Mar 1, 2016 at 2:46 AM, Martin Michlmayr  wrote:
> * Roger Shimizu  [2016-03-01 00:25]:
>> So you mean hostname actually is got from DHCP, so it's not broken here?
>> I tried d-i on my Linkstation with 2 different device, in 2 different
>> network (DHCP server), both of the final hostname are "debian", with
>> RAID name also "debian".
>
> Debian installer should take the hostname in that order (later taking
> preference):
>
>  - "default" as default
>
>  - Value from DHCP
>
>  - Value from original firmware (if any)
>
> So if you get "debian", I assume no value comes from DHCP. (And I
> assume you no longer have an original firmware config since you're
> doing new Debian installations to the same disk.)
>
> Peter confirmed the installer got the hostname from DHCP.  Are you
> saying this is broken, or does your DHCP not supply a hostname?
>
> I'm not sure what you're trying to say.

hostname from DHCP may work, but not every DHCP server provides one.

Yes, I did new installation, and got "debian" as hostname.
That's the same problem which Peter requested, ask for the hostname in
d-i/network-console.

>From implementation side, as you explained before, network-console
requires network set-up in early stage, so it may be hard to set up
hostname a second time.

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

Bug#813952: RFS: helm/1.9.2-1 -- Emacs incremental completion and selection narrowing framework

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sat, Feb 06, 2016 at 06:11:40PM -0700, Sean Whitton wrote:
> git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/helm
> git checkout debian/1.9.2-1

there is no such tag (luckily?)

anyway, looking at HEAD:

* please use standards-versions 3.9.7
* from the changelog:
  + "New dependency on elpa-popup."  I don't see such thing in the
debdiff generated
  + "Update emacs-helm.sh patch for new upstream release."  usually this
is written like "Refresh patch ", I find
hard to understand your sentence, tbh...

-- 
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#816333: libindi: FTBFS[kfreebsd]: libusb-1.0/libusb.h: No such file or directory

[Steven Chamberlain]

Package: libindi
Version: 1.1.0-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi,

libindi built before on kfreebsd, but since then a new include was
added in libs/indibase/hid_libusb.c:
#include "libusb-1.0/libusb.h"

We prefer that it is just:
#include 
since cmake already sets the include path appropriately to find libusb.h
wherever it is located (/usr/include/libusb-1.0/ on linux, or just
/usr/include/ on kfreebsd).

While here, a symbols update was needed.  I've attached a debdiff having
both of these changes.  Thanks a lot.

p.s. there are some "warning: implicit declaration" happening on linux
and kfreebsd, which suggest maybe compiling with -D_GNU_SOURCE to get
both strptime and asprintf, or define that macro atop the affected
source files.

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libindi-1.1.0/debian/libindidriver1.symbols libindi-1.1.0/debian/libindidriver1.symbols
--- libindi-1.1.0/debian/libindidriver1.symbols	2016-01-18 15:06:38.0 +
+++ libindi-1.1.0/debian/libindidriver1.symbols	2016-02-29 23:11:48.0 +
@@ -128,14 +128,14 @@
  (arch=!kfreebsd-any)_ZN13V4L2_RecorderD0Ev@Base 1.0.0
  (arch=!kfreebsd-any)_ZN13V4L2_RecorderD1Ev@Base 1.0.0
  (arch=!kfreebsd-any)_ZN13V4L2_RecorderD2Ev@Base 1.0.0
- _ZN20V4L2_Builtin_Decoder10getLinearYEv@Base 1.1.0
- _ZN20V4L2_Builtin_Decoder11makeLinearYEv@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder10getLinearYEv@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder11makeLinearYEv@Base 1.1.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder11usesoftcropEb@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder12allocBuffersEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder12getRGBBufferEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder14getColorBufferEv@Base 1.0.0
- _ZN20V4L2_Builtin_Decoder15setQuantizationEb@Base 1.1.0
- _ZN20V4L2_Builtin_Decoder16setLinearizationEb@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder15setQuantizationEb@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder16setLinearizationEb@Base 1.1.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder17issupportedformatEj@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder19getsupportedformatsEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder22init_supported_formatsEv@Base 1.0.0
@@ -143,12 +143,12 @@
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder4getVEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder4getYEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder4initEv@Base 1.0.0
- _ZN20V4L2_Builtin_Decoder5makeYEv@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder5makeYEv@Base 1.1.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder6decodeEPhP11v4l2_buffer@Base 1.0.0
- _ZN20V4L2_Builtin_Decoder6getBppEv@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder6getBppEv@Base 1.1.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder7setcropE9v4l2_crop@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder9resetcropEv@Base 1.0.0
- _ZN20V4L2_Builtin_Decoder9setformatE11v4l2_formatb@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN20V4L2_Builtin_Decoder9setformatE11v4l2_formatb@Base 1.1.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_DecoderC1Ev@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_DecoderC2Ev@Base 1.0.0
  (arch=!kfreebsd-any)_ZN20V4L2_Builtin_DecoderD0Ev@Base 1.0.0
@@ -335,7 +335,8 @@
  _ZN4INDI16FocuserInterfaceD2Ev@Base 1.0.0
  _ZN4INDI3CCD10GuideNorthEf@Base 1.0.0
  _ZN4INDI3CCD10GuideSouthEf@Base 1.0.0
- (subst)_ZN4INDI3CCD10uploadFileEP7CCDChipPKv{size_t}bb@Base 1.0.0
+ (arch=kfreebsd-any)_ZN4INDI3CCD10uploadFileEP7CCDChipPKvmbb@Base 1.1.0-1
+ (arch=!kfreebsd-any)(subst)_ZN4INDI3CCD10uploadFileEP7CCDChipPKv{size_t}bb@Base 1.0.0
  _ZN4INDI3CCD11ISNewNumberEPKcS2_PdPPci@Base 1.0.0
  _ZN4INDI3CCD11ISNewSwitchEPKcS2_P7ISStatePPci@Base 1.0.0
  _ZN4INDI3CCD12SetCCDParamsEiiiff@Base 1.0.0
@@ -584,7 +585,7 @@
  (arch=!kfreebsd-any)_ZN9V4L2_Base10errno_exitEPKcPc@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base10findMinMaxEv@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base10getControlEjPdPc@Base 1.0.0
- _ZN9V4L2_Base10getLinearYEv@Base 1.1.0
+ (arch=!kfreebsd-any)_ZN9V4L2_Base10getLinearYEv@Base 1.1.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base10init_userpEj@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base10query_ctrlEjRdS0_S0_S0_Pc@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base10read_frameEPc@Base 1.0.0
@@ -621,11 +622,11 @@
  (arch=!kfreebsd-any)_ZN9V4L2_Base16setcaptureformatEjPc@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base17getcaptureformatsEP22_ISwitchVectorProperty@Base 1.0.0
  (arch=!kfreebsd-any)_ZN9V4L2_Base18enumerate_ext_ctrlEv@Base 1.0.0
- _ZN9V4L2_Base18setColorProcessingEbbb@Base 

Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver

[Mattia Rizzolo]

sorry, this took awfully long.

On Fri, Feb 05, 2016 at 11:09:20PM +, Jose M Calhariz wrote:
> Amanda have release a new upstream version.  My main sponsor is too
> busy for helping me.  So I am searching for someone that can help
> sponsor the new release.

Ok, I can do it.
Should I use the git repository?
Just looking through cgit, I can ask you the following things:

* https in Vcs-Git please
* standards-version to 3.9.7
* version restriction on tar can go away, and tar being essential:yes
  the whole dep can go away
* are you sure the perl dep is needed?  ${perl:Depends} ought to do it
* guessing you are using git-buildpackage, why didn't you just
  `gbp import-dsc` to import the NMU?
* please push the tag for the upstream part
* you have a build-dep on debhelper version >= 9, but you use compat 5.
  please bump the compat, after checking the differences in debhelper(7)
* the *.dirs files don't need to list directories for files installed by
  other dh_* things, so I'm confident at least line 3,4,5 of
  amanda-server.dirs are useless, haven't looked at the others
* I'm not happy with the old style rules file, but guess I can't ask
  that much in this case, and I can live well with it anyway :)

↑ that's the kind of things I want to see changed for me to sponsor it.
If you confirm I should look at the git repository and you're ok with me
as a sponsor please confirm so (and fix the already reported problems,
please ;))

-- 
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#814936: transition: mpi-defaults

[Emilio Pozuelo Monfort]

On 29/02/16 20:10, Mattia Rizzolo wrote:
> 
> ok, it looks good.
> Except for mpi4py and nwchem that FTBFS, I find this transition to be
> cool.
> 
> Do you notice something that should be take care of?
> Otherwise I'd call this over.

Those are the remaining ones yes.

Emilio

Bug#816332: debhelper: dh_installdirs should operate on both debian/tmp and debian/$package

[Robert Luberda]

Package: debhelper
Version: 9.20160115
Severity: wishlist

By default dh_installdirs creates directories in debian/$package. However
in multi-binary packages files are usually first installed into
debian/tmp. Creating the directories elsewhere seems to have limited
usability, as such directories won't be used by upstream makefiles anyway.

This is a long standing bug, I've already work-arounded in two of my
packages:
http://sources.debian.net/src/man2html/1.6g-8/debian/rules/?hl=35#L32
http://sources.debian.net/src/afterstep/2.2.12-6/debian/rules/?hl=169#L165a
and now I'm thinking about doing the same for yet another package,
because its upstream checks for existance of some directory before
installing files into it.

Simllar code can be found in another package:
http://sources.debian.net/src/isdnutils/1:3.25%2Bdfsg1-3.7/debian/rules/?hl=43#L43

I can find cases where installing into debian/$package can be intended action 
(e.g. providing empty /var/cache/something in the binary package), and I 
guess some packages might depend on this behaviour, so this bug should
be fixed in some backward-compatible way: 
 - maybe by installing in both debian/$package and debian/tmp, 
 - or by providing a new command line option, 
 - or by making `dh_installdocs -Pdebian/tmp -A' work.

Regards,
robert

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

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debhelper depends on:
ii  autotools-dev20150820.1
ii  binutils 2.26-5
ii  dh-strip-nondeterminism  0.016-1
ii  dpkg 1.18.4
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-7
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201605

-- no debconf information

Bug#813237: transition: ruby2.3

[Emilio Pozuelo Monfort]

On 29/02/16 15:50, Christian Hofstaedtler wrote:
> Emilio,
> 
> * Emilio Pozuelo Monfort  [160224 19:03]:
> 
>>> ruby-zoom
> 
> Could you try a g-b on mipsel for this?

Done.

Emilio

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

[Emilio Pozuelo Monfort]

On 29/02/16 15:07, Antonio Terceiro wrote:
> Hi,
> 
> Please binNMU the following packages:
> 
> unicorn
> ruby-oj
> passenger

Scheduled.

Emilio

Bug#816331: libsmbios issues a warning when compiling with new versions of gcc

[Mario Limonciello]

Package: libsmbios
Version: libsmbios
Severity: normal
Tags: patch

Dear Maintainer,

When running on a current version of GCC, this warning is always issued:
"Unknown compiler version - please run the configure tests 
and report the results"

This of course leads to problems with applications compiled with -Werror.

This has been fixed upstream in commit 23017bdcdbe466df555f63b66d6fcf305ec93260.

It is not available in a new upstream version yet, so I would request that this 
commit be backported.

test@test-Latitude-E5470:~$ cat /media/test/EFI/*diff
diff -Nru libsmbios-2.2.28/debian/patches/0001-support-newer-gcc-versions.patch 
libsmbios-2.2.28/debian/patches/0001-support-newer-gcc-versions.patch
--- libsmbios-2.2.28/debian/patches/0001-support-newer-gcc-versions.patch   
1969-12-31 18:00:00.0 -0600
+++ libsmbios-2.2.28/debian/patches/0001-support-newer-gcc-versions.patch   
2016-02-29 11:06:37.0 -0600
@@ -0,0 +1,43 @@
+From 23017bdcdbe466df555f63b66d6fcf305ec93260 Mon Sep 17 00:00:00 2001
+From: Michael E Brown 
+Date: Thu, 29 Mar 2012 00:16:40 -0500
+Subject: [PATCH] support newer gcc versions
+
+---
+ src/include/smbios/config/compiler/gcc.hpp | 4 ++--
+ src/include/smbios_c/config/compiler/gcc.h | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/include/smbios/config/compiler/gcc.hpp 
b/src/include/smbios/config/compiler/gcc.hpp
+index 0891255..13d97d9 100644
+--- a/src/include/smbios/config/compiler/gcc.hpp
 b/src/include/smbios/config/compiler/gcc.hpp
+@@ -110,10 +110,10 @@
+ // versions check:
+ // we don't know gcc prior to version 2.90:
+ #if (__GNUC__ == 2) && (__GNUC_MINOR__ < 90)
+-#  error "Compiler not configured - please reconfigure"
++#  error "Compiler too old. GCC > 3.0 required"
+ #endif
+ //
+-#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ > 5))
++#if (__GNUC__ > 5)
+ #  if defined(LIBSMBIOS_ASSERT_CONFIG)
+ # error "Unknown compiler version - please run the configure tests and 
report the results"
+ #  else
+diff --git a/src/include/smbios_c/config/compiler/gcc.h 
b/src/include/smbios_c/config/compiler/gcc.h
+index f46b8dc..007cc73 100644
+--- a/src/include/smbios_c/config/compiler/gcc.h
 b/src/include/smbios_c/config/compiler/gcc.h
+@@ -24,7 +24,7 @@
+ #  error "GCC versions < 2.90 not supported"
+ #endif
+ //
+-#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ > 7))
++#if (__GNUC__ > 5)
+ #  if defined(LIBSMBIOS_C_ASSERT_CONFIG)
+ # error "Unknown compiler version - please run the configure tests and 
report the results"
+ #  else
+-- 
+2.7.0
+
diff -Nru libsmbios-2.2.28/debian/patches/series 
libsmbios-2.2.28/debian/patches/series
--- libsmbios-2.2.28/debian/patches/series  2013-05-31 00:17:03.0 
-0500
+++ libsmbios-2.2.28/debian/patches/series  2016-02-29 13:14:53.0 
-0600
@@ -1,2 +1,3 @@
 amlcmessages.patch
 am_disable_lzma.patch
+0001-support-newer-gcc-versions.patch


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

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

Bug#816330: libsmbios-dev: pkg-config files are not installed in libsmbios-dev

[Mario Limonciello]

Package: libsmbios-dev
Version: 2.2.28-2ubuntu2
Severity: important
Tags: patch

Dear Maintainer,

currently libsmbios-dev can't be compiled against using pkg-config because the
.pc files are not included with the development package.

They are generated, just not included.  This can be fixed with the following 
diff:

diff -Nru libsmbios-2.2.28/debian/libsmbios-dev.install 
libsmbios-2.2.28/debian/libsmbios-dev.install
--- libsmbios-2.2.28/debian/libsmbios-dev.install   2013-05-31 
00:17:03.0 -0500
+++ libsmbios-2.2.28/debian/libsmbios-dev.install   2016-02-29 
11:13:18.0 -0600
@@ -3,3 +3,4 @@
 debian/tmp/usr/lib/libsmbios_c.a
 debian/tmp/usr/lib/libsmbios.a
 src/include usr
+debian/tmp/usr/lib/pkgconfig/

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

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

Versions of packages libsmbios-dev depends on:
ii  libsmbios2v5  2.2.28-2ubuntu2

libsmbios-dev recommends no packages.

libsmbios-dev suggests no packages.

-- no debconf information

Bug#812518: libfreetype6: Please package version 2.6.2

[Steve Langasek]

On Tue, Feb 23, 2016 at 09:00:44PM +0100, Fabian Greffrath wrote:
> Hey Steve,

> On Sun, 24 Jan 2016 16:54:59 +0100 Fabian Greffrath 
> wrote:
> > freetype 2.6.2 contains some fixes on top of 2.6.1 regarding the
> > rendering of OTF fonts and I'd like to see them in action especially
> > with the recent releases of GNOME's Cantarell UI font.

> I'd like to offer to NMU freetype in order to bring it up to upstream
> version 2.6.3. Please tell me if you agree or not.

Thank you for asking.  However, considering the last NMUer (who didn't ask,
before NMUing for a wishlist bug) broke the .symbols declarations in the
process, I prefer to take care of this myself.

Look for an upload of 2.6.3 shortly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#816329: iceweasel icon on xfce-whisker or xfce-application menu missing

[Karagkiaouris Diamantis]

Package: iceweasel
Version: 44.0.2-1
Severity: normal

Dear Maintainer,

After install iceweasel the application icon is missing from whisker-menu and 
application-menu on XFCE.

Kind Regards,
Diamantis

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Deutsch (DE) Language Pack locale
Location: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-de
Status: enabled

Name: Firebug
Location: ${PROFILE_EXTENSIONS}/fire...@software.joehewitt.com.xpi
Status: enabled

-- Plugins information
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled

Name: Shockwave Flash (11.2.202.569)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  iceweasel  44.0.2-1 amd64Web browser based on Firefox
ii  iceweasel-l10n 1:44.0.2-1   all  German language package for Icewe
ii  rhythmbox-plug 3.3-1amd64plugins for rhythmbox music playe

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.3
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-9
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-8
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1.1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.10.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-8
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.6.3-1
ii  gstreamer1.0-plugins-good  1.6.3-1

Versions of packages iceweasel suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.13.2+dfsg-5
pn  mozplugger 

-- no debconf information

Bug#787663: aptitude forgets/clears manually set auto-installed-flags in several situations

[Christoph Anton Mitterer]

On Mon, 2016-02-29 at 18:52 +, Manuel A. Fernandez Montecelo wrote:
> Because marking a package auto means to tell aptitude "remove it from
> my
> system as soon as it's not needed".
> 
>   http://aptitude.alioth.debian.org/doc/en/ch02s02s06.html
> 
>   It works like this: when you install a package, aptitude will
>   automatically install any other packages on which it depends.

I know how it works, but that system alone is a bit limited, as it
works only for those situations where there is actually a dependency
expressed between the packages in question,... which in turn is however
by far not every case where I install a package because of another
package.

E.g. I install m4-doc, because of m4, yet there is no dependency
relation between them.
So all I can do is either not have m4-doc auto-marked, and I'll
probably forget it once m4 is deleted (in which case I don't need m4-
doc anymore)... or I use the current system a bit less narrow-minded
and set my own manual auto-flag.

It may even go farther to say,... I install gimp and because I export
my images as jpeg, I also install jpegoptim... these have nothing
directly to do with each other and there will never be a dependency
relationship between them.
Still one may want to mark e.g. jpegoptim auto, in order not to forget
about it.

It may not be the primary way auto-installation/removal is intended to
be used, but I see no reason why not to allow that use case.


Actually the current system is even more "limited",...
E.g. I may have a package xyz that recommends some python-gibberish...
and I say, yes I want to use that functionality that python-gibberish
gives to xyz.
So it's marked auto-installed.

Now I install abc further package abc, which e.g. suggest, but here I
don't have any intentions to use that with python-gibberish.
However, when I remove xyz, pyhton-gibberish, will of course not be
auto-removed.




> You can mark packages for removal and exit aptitude without removing
> immediately, but this will not fly long and other tools of the system
> might decide to remove it.
But then it's in the scheduled list when I do anything else...


> aptitude doesn't remove the flag now, but the package altogether,
> which
> is what the human requested (and what aptitude failed to do until
> recently).
> 
> If human doesn't want the package removed, human should revisit what
> the
> machine is asked to do.
Well AFAIU, the flag means auto-installed, not do-auto-remove... and if
I have auto-removal turned of I see no reason why one should forbid the
other use case...


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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

[Kambiz Darabi]

On 2016-02-29 22:31 CET, Mattia Rizzolo  wrote:

> On Mon, Feb 29, 2016 at 10:26:36PM +0100, Kambiz Darabi wrote:
>> I uploaded a new version.
>
> W: cl-asdf source: timewarp-standards-version (2015-10-17 < 2016-02-01)
>
> Please bump also the date in the changelog (`dch -r` does that). :)

done

> And btw, I'd argue that means you didn't run lintian before uploading,
> which is kinda of worrying.  I'd expect sponsoree to always double check
> their packages…

I did, but I didn't have the correct lintian version installed, received
the following warning:

> W: cl-asdf source: newer-standards-version 3.9.7 (current is 3.9.5)

and thought this would be expected behaviour.

Uploaded a new version.


Thanks for your patience!

Bug#816328: light-locker: FTBFS[!linux]: unconditionally configures --with-systemd

[Steven Chamberlain]

Package: light-locker
Version: 1.7.0-2
Severity: wishlist
Tags: patch

Hi,

light-locker unconditionally configures --with-systemd, although that
only makes sense on linux.  Without that, it builds fine on kfreebsd and
probably hurd.

With that change, the libsystemd-dev build-dependency (which is listed
twice BTW) is not needed any more on those platforms.

Please find a debdiff attached for both these things.  Thank you!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru light-locker-1.7.0/debian/control light-locker-1.7.0/debian/control
--- light-locker-1.7.0/debian/control	2015-11-18 12:44:49.0 +
+++ light-locker-1.7.0/debian/control	2016-02-29 22:09:16.0 +
@@ -7,8 +7,8 @@
  Simon Huggins   
 Build-Depends: debhelper (>= 9), pkg-config, dh-autoreconf,
   liblightdm-gobject-dev (>= 1.3.5), libgtk-3-dev, libdbus-glib-1-dev,
-  libxss-dev, libsystemd-dev, intltool, xfce4-dev-tools, libtool,
-  libsystemd-dev
+  libxss-dev, intltool, xfce4-dev-tools, libtool,
+  libsystemd-dev [linux-any]
 Standards-Version: 3.9.6
 Homepage: https://github.com/the-cavalry/light-locker/
 Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/light-locker
diff -Nru light-locker-1.7.0/debian/rules light-locker-1.7.0/debian/rules
--- light-locker-1.7.0/debian/rules	2015-07-09 16:11:26.0 +0100
+++ light-locker-1.7.0/debian/rules	2016-02-29 22:13:04.0 +
@@ -3,10 +3,16 @@
 export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed -Wl,-O1
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+DEB_HOST_ARCH_OS	?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
+ifeq ($(DEB_HOST_ARCH_OS),linux)
+	ARCH_OPTS := --with-systemd
+endif
+
 override_dh_auto_configure:
 	NOCONFIGURE=1 xdt-autogen
 	dh_auto_configure -- --disable-silent-rules \
-		--with-systemd \
+		$(ARCH_OPTS) \
 		--with-upower \
 		--with-console-kit \
 		--with-mit-ext

Bug#816327: O: wv -- Programs for accessing Microsoft Word documents

[Daniel Walrond]

Package: wnpp
Severity: normal

I am orphaning wv since I have not used this package for some time.


Dan

Bug#816326: schroot: don't fail on 15binfmt with a missing /bin/sh

[Raphael Geissert]

Source: schroot
Version: 1.6.10-2
Tags: patch
Severity: minor

Hi,

Once upon a time I found a chroot that didn't have a /bin/sh and
schroot failed miserably due to a call to binfmt --find on a
non-existing file...
Attached patch makes 15binfmt test for $shell to be readable.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Index: sources-schroot/1.6.10-2/etc/setup.d/15binfmt
===
--- sources-schroot/1.6.10-2/etc/setup.d/15binfmt
+++ sources-schroot/1.6.10-2/etc/setup.d/15binfmt
@@ -34,8 +34,12 @@
 fi
 
 shell="${CHROOT_PATH}/bin/sh"
 
+if ! [ -r "$shell" ]; then
+exit 0
+fi
+
 for emulator in $(update-binfmts --find "$shell"); do
 dst="${CHROOT_PATH}$emulator"
 if [ ! -e "$emulator" ]; then
 info "Missing emulator: $emulator; not enabling binfmt support"

Bug#815551: aptitude: safe-upgrade removes manually installed package if dependency is on hold

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Sven,

2016-02-28 02:21 To Sven Joachim:

2016-02-28 1:47 GMT+00:00 Manuel A. Fernandez Montecelo
:

2016-02-27 20:46 GMT+00:00 Sven Joachim :

That package has a reverse dependency which is also held back, and I can
see that it has been marked as auto-installed as well, which is not
surprising (anymore).


The commit above might be doing the wrong thing, but it doesn't have
much to do with holds but with marking the packages to "keep", for
example when one selects "Keep packages at current version" in the
interactive resolver.

It doesn't mark them unconditionally as automatic either, it tries to
force the Automatic parameter that was decided elsewhere (presumably,
determined to be the previous state before the current set of
decisions / pending actions was taken).


BTW, I think that I've got a fix for this, but only if you got to this
situation by selecting "Keep packages at current version" in the
resolver (interactive or not).


So I am still not sure about the relationship between that commit and
the events as described in the original message.

But I am going to release a new version which addresses problems caused
indirectly by that commit (was marking all packages as "keep" as auto,
because of a wrong variable set elsewhere).  So if this was indeed the
cause of the problem that you experience, this should fix it.

If this doesn't fix it please reopen, and I will look into the issue
with more calm.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#816173: [Pkg-lyx-devel] Bug#816173: Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist

[Georg Baum]

Am 28.02.2016 um 18:22 schrieb Sven Hoexter:

On Sun, Feb 28, 2016 at 11:42:52AM +0100, picca wrote:

Hi,


while preparing my tango package, I need to build the documentation with lyx.

For future reference, here is the d-d thread:
https://lists.debian.org/debian-devel/2016/02/msg00454.html


It seems that it is not allow to write outside the source directory except /tmp 
during the build process.

I see at least two problems.

1) lyx try to create a $HOME/.lyx even if $HOME does not exist
2) it would be great to avoir creating this .lyx directory by default.

While I agree that 1) is a bug 2) is a bit more complicated.
It is documented that LyX needs a user configuration directory. If the 
default location does not fit, you can use the -userdir parameter. Where 
is the problem? Would you like to fail in a different way if $HOME does 
not exist? It would be easy to add a check for that, but I'd like to 
understand the problem before doing anything.



LyX is not really intended to be used this way, it's more or less
centered around the idea of an GUI use in a real user environment.
Most people do indeed use LyX that way, but using it via command line 
without a GUI is an important use case as well (and works fine in general).

It's part of the whole configuration problem, kind of a dublicate of #397464.


Yes. Parts of the configuration in .the user directory are needed (they 
are expensive to calculate), other could be gathered by different 
mechanisms if somebody would take the time to implement that.



Georg

Bug#816103: libwv-dev: Please change dependency from libpng12-dev to libpng-dev

[Daniel Walrond]

Hello

On Sat, Feb 27, 2016 at 02:46:29PM +0100, Tobias Frost wrote:
> Package: libwv-dev
> Severity: important
> User: lib...@packages.debian.org
> Usertags: libpng16-transition
> 
> Dear wv maintainers,
> 
> Currently we are preparing the transition of libpng1.2 to libpng1.6.
> The transition bug is #650601.
> 
> libwv-dev depends an versioned development package
> libpng12-dev. Please update your (build-)depends to libpng-dev to
> help in the transition.
> 
> This bug will become RC as soon as the transition starts, as it is
> planned to remove libpng12. 

I can only do sponsored uploads, so I'm happy for you to do a NMU if
required. Assuming you're happy with that.


Dan

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

[Mattia Rizzolo]

On Mon, Feb 29, 2016 at 10:26:36PM +0100, Kambiz Darabi wrote:
> I uploaded a new version.

W: cl-asdf source: timewarp-standards-version (2015-10-17 < 2016-02-01)

Please bump also the date in the changelog (`dch -r` does that). :)

And btw, I'd argue that means you didn't run lintian before uploading,
which is kinda of worrying.  I'd expect sponsoree to always double check
their packages…

-- 
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#816319: Bugs missing from https://ftp-master.debian.org/removals.html

[Mattia Rizzolo]

On Mon, Feb 29, 2016 at 09:42:49PM +0200, Esa Peuha wrote:
> There are currently two bugs missing from the page of Pending
> Debian Package removals, and have been for some time: 812554
> and 814109. Since there doesn't seem to be any other reason why
> these are still open, I'm assuming it's because they are
> missing from the page.

actually, I think it's because those packages are already removed:

* #812554: googlecl, already removed after #812553 (and btw, I have a
  feeling the title is not compliant, there shouldn't be the version
  there)
* #814109: php-html-table, already removed after #814105 (cloned once
  too many)

Now, I don't know whether removals.html should report wrongly opened
bugs too, that's a thing for the ftp team.

-- 
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#809308: RFS: cl-asdf/3.1.6 [ITA] - Another System Definition Facility

[Kambiz Darabi]

> * in the meantime a new version of policy is out, 3.9.7.  Check whether
>   your package is still compliant [0] and if so bump Standards-Version
> ...
> [0] https://www.debian.org/doc/debian-policy/upgrading-checklist

Checked, and bumped.

> * in d/changelog, there should be a blank line between the first line
>   with the package name and the version, and the changelog text

Added.

> Then, it's good to go :)

I uploaded a new version.

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

[Noah Meyerhans]

Control: tags -1 + upstream pending fixed-upstream

On Mon, Feb 29, 2016 at 09:02:02AM +0100, Florent Rougon wrote:
> Apart from that, I use:
> 
>   GRUB_CMDLINE_LINUX="init=/bin/systemd ipv6.disable=1"

Confirmed that this breaks ping when run without an explicit address
family. This is actually already fixed upstream, but not in a tagged
snapshot. It'll be fixed in the next upload, by cherry-picking that
commit or syncing a new snapshot.

Thanks
noah



signature.asc
Description: Digital signature

Bug#816325: org.freedesktop.PolicyKit1 was not provided by any .service files

[Joerg Frings-Fuerst]

Package: isc-dhcp-server
Version: 4.3.3-9
Severity: serious


Hi,

after installing I get:

$ systemctl start isc-dhcp-server
Failed to start isc-dhcp-server.service: The name org.freedesktop.PolicyKit1 
was not provided by any .service files

CU
Jörg

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

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

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  debianutils4.7
ii  libc6  2.21-9
ii  libdns-export100   1:9.9.5.dfsg-12.1
ii  libirs-export911:9.9.5.dfsg-12.1
ii  libisc-export951:9.9.5.dfsg-12.1
ii  lsb-base   9.20160110

Versions of packages isc-dhcp-server recommends:
ii  isc-dhcp-common  4.3.3-8
ii  policycoreutils  2.4-4

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  

-- Configuration Files:
/etc/dhcp/dhcpd.conf changed:
ddns-update-style none;
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
 
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name "home.loc";
option domain-name-servers 192.168.1.111;
option routers 192.168.1.111;
option ntp-servers 192.168.1.111;
option lpr-servers 192.168.1.111;
option netbios-name-servers 192.168.1.111;
option broadcast-address 192.168.1.255;
option subnet-mask 255.255.255.0;
ddns-update-style none;
default-lease-time 6400;
max-lease-time 6400;
use-host-decl-names on;
range 192.168.1.221 192.168.1.223;
host jff-lap {
hardware ethernet 00:0f:b0:92:81:83;
fixed-address 192.168.1.113;
}
host jff-lap-triton {
hardware ethernet e0:69:95:6b:c3:29;
fixed-address 192.168.1.114;
}   
host jff-lap_wlan {
hardware ethernet 00:12:f0:e4:ab:33;
fixed-address 192.168.1.112;
}
host saturn {
hardware ethernet d4:3d:7e:94:59:bb;
fixed-address 192.168.1.1;
}
host merkur1 {
hardware ethernet 00:1d:7d:08:bd:4b;
fixed-address 192.168.1.2;
}
host merkur2 {
hardware ethernet 00:1d:7d:08:bd:3b;
fixed-address 192.168.1.3;
}
host jff-pda-wlan {
hardware ethernet 00:0b:6c:61:72:0a;
fixed-address 192.168.1.114;
}
host tel1 {
hardware ethernet 00:17:9a:72:d5:98;
fixed-address 192.168.1.210;
}
host tel2 {
hardware ethernet 00:17:9a:72:d5:99;
fixed-address 192.168.1.211;
}
host tel3 {
hardware ethernet 00:01:e3:8e:60:dd;
fixed-address 192.168.1.212;
}
host fonspot {
hardware ethernet 00:18:84:24:2c:44;
fixed-address 192.168.1.26;
}
host centos1 {
hardware ethernet 00:0A:e6:f7:88:bf;
fixed-address 192.168.1.22;
}

host virt1310 {
hardware ethernet 08:00:27:2f:6e:3c;
fixed-address 192.168.1.22;
}
host hpdrucker {
hardware ethernet 9c:b6:54:36:d6:da;
fixed-address 192.168.1.19;
}
host lexmark-t520 {
hardware ethernet 00:04:00:68:21:93;
fixed-address 192.168.1.18;
}
}

/etc/logcheck/ignore.d.server/isc-dhcp-server [Errno 13] Keine Berechtigung: 
u'/etc/logcheck/ignore.d.server/isc-dhcp-server'

-- debconf information:
  isc-dhcp-server/interfaces:

Bug#813614: providing a patch

[Stéphane Blondon]

Le 18/02/2016 01:52, Stéphane Blondon a écrit :
> This is a diff of crontab.c providing a color change for comment lines
> for the `crontab -l` output. You can see a demo with the provided
> screenshot attached to this message too.

With the previous patch, the colorized output creates a problem if:
- a redirection (like `crontab -l > /tmp/crontab`)
- or a pipe (like `crontab -l | cat`)

are used because the escape characters are displayed.


This new patch fixes that by checking what the output is.
The provided patch is a diff against the original source code.


The diff between the two provided diffs is only:

< +++ crontab.c 2016-02-18 01:18:31.655518325 +0100
---
> +++ crontab.c 2016-02-29 20:54:07.801740970 +0100
38c38
< +if(ch == '#'){
---
> +if(ch == '#' && isatty(STDOUT)){


So this diff provides the same feature than the previous one and fixes a
bug included in the previous one.

-- 
Stéphane
--- crontab.c.orig	2016-02-18 01:12:36.253608497 +0100
+++ crontab.c	2016-02-29 20:54:07.801740970 +0100
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #ifdef USE_UTIMES
@@ -48,6 +49,10 @@
 
 #define NHEADER_LINES 3
 
+#define COMMENT_COLOR  "\x1B[34m"
+#define RESET_COLOR "\033[0m"
+
+
 enum opt_t	{ opt_unknown, opt_list, opt_delete, opt_edit, opt_replace };
 
 #if DEBUGGING
@@ -302,6 +307,7 @@
 	char	n[MAX_FNAME];
 	FILE	*f;
 	int	ch;
+int new_line = 1;
 #ifdef DEBIAN
 	int x;
 	char*ctnh;
@@ -345,8 +351,17 @@
 	}
 	  }
 #endif
-	while (EOF != (ch = get_char(f)))
-		putchar(ch);
+while (EOF != (ch = get_char(f))){
+if(new_line){
+if(ch == '#' && isatty(STDOUT)){
+printf(COMMENT_COLOR);
+}else{
+printf(RESET_COLOR);
+}
+}
+putchar(ch);
+new_line = ch == '\n';
+}
 	fclose(f);
 }
 


signature.asc
Description: OpenPGP digital signature

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

[matthias.hinkfoth2]

Hi,

I enjoyed playing around with this bug.
My test setup involves google-mock as package, but I think this is
somewhat arbitrary. I chose google-mock, because no package depends
on it.

Setup:
jessie and wheezy in sources.list, amd64, package google-mock installed

1. start aptitude as a user
2. search google-mock
3. [-] (mark for removal)
4. OK (package cache read-only)
5. [g]
now the preview opens.
google-mock is to be removed,
libgtest-dev is to be removed, because no longer used
6. [g]
7. become root :-)
8. [g]
actual removal.
9. now the package view says: will use 2,187 kB of disk spac ...
10. [g]
packages to be installed: google-mock and libgtest-dev
interestingly libgtest-dev will not be automatically
installed, but manually!


I cannot reproduce this behaviour, when I become root before doing
the removal.

In the end, this looks to me to be 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570492
since it involves becoming root in between the package action.


Regards,
Matthias

Bug#798430: apache2: please add systemd service file

[Stefan Fritsch]

This is not that easy because of all the logic that we have in the 
init script.

One part is about starting/stopping htcacheclean if mod_cache_disk is 
enabled. Maybe instead of doing this check at apache2 startup, this 
could be split into a separate service and a2enmod could active the 
htcacheclean service when mod_cache_disk is enabled.

Another part is that apache2 is not very good at telling its status 
via an exit code. For example, when doing reload/stop/graceful-stop, 
the controlling apache2 process will only send a signal and not wait 
for the result of the operation. I don't know enough about systemd to 
tell if this can be easily done via unit files.

Also, some configuration is done via /etc/apache2/envvars and 
/etc/default/apache2 . This would need to be taken care of, too.

Bug#816322: aptitude: SIGABRT due to assertion failure when quitting from conflict resolver

[Katsuhiko Nishimra]

Package: aptitude
Version: 0.6.11-1+b1

Dear maintainer,
I've confirmed this is also found in jessie.

Regards,
Katsuhiko

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.3
  500 stable-updates  cdn.debian.or.jp 
  500 stable  security.debian.org 
  500 stable  ftp.kaist.ac.kr 
  500 stable  dl.google.com 
  500 stable  cdn.debian.or.jp 

--- Package information. ---
Depends  (Version) | Installed
==-+-==
aptitude-common  (= 0.6.8.2-1) | 0.6.11-1
libapt-pkg4.12(>= 0.9.7.6) | 1.0.9.8.2
libboost-iostreams1.49.0 (>= 1.49.0-1) | 1.49.0-3.2
libc6 (>= 2.4) | 
libcwidget3| 
libept1.4.12(>= 1.0.9) | 
libgcc1   (>= 1:4.1.1) | 
libncursesw5 (>= 5.6+20070908) | 
libsigc++-2.0-0c2a  (>= 2.0.2) | 
libsqlite3-0(>= 3.6.5) | 
libstdc++6(>= 4.6) | 
libtinfo5  | 
libxapian22| 
zlib1g(>= 1:1.1.4) | 


Recommends (Version) | Installed
-+-===
aptitude-doc-en  | 
 OR aptitude-doc | 
sensible-utils   | 0.0.9
apt-xapian-index | 0.47
libparse-debianchangelog-perl| 1.2.0-1.1


Suggests  (Version) | Installed
===-+-===
tasksel | 3.31+deb8u1
debtags | 

Bug#816213: ftp.debian.org: afterstep's binary packages stuck in the uploaded state

[Robert Luberda]

reopen 816213
retitle 816213 Please CC rejection mails to maintainer (or uploader)
severity 816213 wishlist
thanks

Ansgar Burchardt pisze:
> 
> They were rejected:
> 
> libafterimage-dev_2.2.12-7_amd64.deb: Multi-Arch: no support in Debian is 
> broken (#768353)

Thanks, I was not aware of this.

BTW. I've just looked at #768353 and the bug was fixed over year ago -
should the uploads be still rejected?
BTW2. Why the uploads were accepted anyway on few port architectures
(alpha, hppa, m68k, sparc, x32)?


> 
> Rejection mails for buildd uploads only go the the buildd maintainer,

I think it would be a great idea to have such rejection mails CC-ed to
maintainer or uploader of the package (without CC-ing the "accepted"
e-mails however). It might be especially important if the initial upload
was the source only - that's why I am re-opening the report.

Alternatively this kind of information could be displayed via some web
interface like PTS or tracker, or together with logs on build.debian.org.

I've just thought about another option - rejecting the initial source
upload; this should be possible for at least some checks, including the
one with lack of `Multi-Arch: no' support.

> but the message can also be found on
> 
>   mirror.ftp-master.debian.org:/srv/ftp-master.debian.org/queue/reject
> 
> in the *.reason* files.
> 

To be honest my guess yesterday was that the upload might have got
rejected, but I nowhere could find the above information. May I suggest
adding it to https://ftp-master.debian.org/ (and maybe to
https://wiki.debian.org/SourceOnlyUpload)?

Thanks a lot,
robert

Bug#816324: RM: ruby-rspec-expectations -- ROM; superseeded by binary package from ruby-rspec

[Cédric Boutillier]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Could you plear remove ruby-rspec-expectations source package 2.14.2-1 from 
unstable. It
is now replaced by a binary package created from ruby-rspec >= 3~.

Thank you in advance

Cédric

Bug#813900: RFS: ripit/4.0.0~beta20140508-1

[Elimar Riesebieter]

* Sven Hoexter  [2016-02-29 20:30 +0100]:

> On Sat, Feb 20, 2016 at 04:32:06PM +0100, Elimar Riesebieter wrote:
> 
> Hi,
> 
> > I wonder why no sponsor takes care of my package since 3 weeks
> > now...
> 
> We also have day jobs and I do not look at sponsoring that often nowadays.
> Anyway why did you recompress the orig tarball? It's painfull to diff the
> upstream tar against yours just to verify it's pristine.
> 
> I'm not a native speaker but to me this comment sounds like
> -Description: Spellfix in manpage
> +Description: Correct spell errors in manpage

Hmm, do you you mean it vice versa in the man-spellfix.patch:
-Description: Correct spell errors in manpage
+Description: Spellfix in manpage
?

> magic in the manpage. I guess it should be "spelling errors", otherwise
> the translation is "korrigiert Fehler im Zauberspruch in der Anleitung".
> 
> Beside of that something only lintian can find ;)
> 
> W: ripit source: timewarp-standards-version (2016-01-30 < 2016-02-01)
> N: 
> N:The source package refers to a Standards-Version that was released after
> N:the date of the most recent debian/changelog entry. Perhaps you forgot
> N:to update the timestamp in debian/changelog before building the package?
> N:
> N:Severity: normal, Certainty: certain
> N:
> N:Check: standards-version, Type: source
> N:
> 
> Maybe only mention the last bump in the changelog.

Could you please be more precise? It was recommended on
mentors.debian.org to bump Standards to 3.9.7 before its official
release, though.

> 
> I'm not sure what to think about the mta dependency, is it wise to depend on
> it? I just looked very quickly at the bugreport and did not check ripit code
> itself.

You are absolutely right: It should be a Recommend to exim | 
mail-transport-agent
and must therefor be corrected in the changelog as well.

Thanks for the review.

Elimar
-- 
  Experience is something you don't get until
  just after you need it!


signature.asc
Description: PGP signature

Bug#816323: RM: ruby-rspec-core -- ROM; superseeded by binary package in ruby-rspec

[Cédric Boutillier]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Could you plear remove ruby-rspec-core source package 2.14.7-2 from unstable. It
is now replaced by a binary package created from ruby-rspec >= 3~.

Thank you in advance

Cédric

Bug#816322: aptitude: SIGABRT due to assertion failure when quitting from conflict resolver

[Katsuhiko Nishimra]

Package: aptitude
Version: 0.7.6-1
Severity: important

Dear Maintainer,

I've run into a SIGABRT when quitting a conflict resolver in aptitude-
curses.

How to reproduce:
* Invoke conflicts by something like
  $ aptitude -st experimental full-upgrade
* Enter the conflict resolver by hitting `e'
* Terminate the process by hitting `qqy'
* Then it goes:
   aptitude:
/usr/include/boost/flyweight/detail/recursive_lw_mutex.hpp:72:boost::flyweights::detail::recursive_lightweight_mutex::scoped_lock::scoped_lock(boost::flyweights::detail::recursive_lightweight_mutex&):
Assertion `pthread_mutex_lock(_)==0' failed.
   Ouch!  Got SIGABRT, dying..

A report on launchpad below might be related with this.
https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1435175

Regards,
Katsuhiko

-- Package-specific info:
$TERM not set.
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.6
Compiler: g++ 5.3.1 20160220
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160213
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffc12be7000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f7fc031)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f7fc00e)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7f7fbfeb5000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f7fbfcaf000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f7fbf9b2000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f7fbf6db000)
libboost_iostreams.so.1.58.0 => /usr/lib/x86_64-linux-
gnu/libboost_iostreams.so.1.58.0 (0x7f7fbf4c1000)
libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-
gnu/libboost_filesystem.so.1.58.0 (0x7f7fbf2a8000)
libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-
gnu/libboost_system.so.1.58.0 (0x7f7fbf0a3000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22
(0x7f7fbec9f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f7fbea82000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f7fbe706000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7fbe401000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f7fbe1eb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7fbde46000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f7fbdc43000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7fbda3f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x7f7fbd827000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f7fbd60c000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x7f7fbd3fc000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f7fbd1d8000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
(0x7f7fbcfc6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f7fbcdbd000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f7fbcbb8000)
/lib64/ld-linux-x86-64.so.2 (0x559298814000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.7.6-1
ii  libapt-pkg5.0  1.2.3
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.21-9
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:5.3.1-10
ii  libncursesw5   6.0+20160213-1
ii  libsigc++-2.0-0v5  2.6.2-1
ii  libsqlite3-0   3.11.0-2
ii  libstdc++6 5.3.1-10
ii  libtinfo5  6.0+20160213-1
ii  libxapian22v5  1.2.22-3

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.7.6-1
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47+nmu2
ii  debtags   2.0.2
ii  tasksel   3.34

Bug#490547: aptitude: safe-upgrade selectively clears 'automatic' flags

[Manuel A. Fernandez Montecelo]

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


Hi again,

2016-01-30 20:20 To Rune Tendal Kock:

2016-01-23 20:51 GMT+00:00 Rune Tendal Kock :

Hi Manuel

I haven't noticed this behaviour recently, but then again I haven't
been looking out for it.  Also, I've reinstalled my computer from
scratch, so in case it was somehow special back then, it would no
longer be so.

So I'm unable to provide any more information on the bug.


No problem, and thanks for the reply after so long.

I will keep this open for the time being, at least until a subsequent
review.  There are other bugs complaining about problems with
automatic flags when upgrading, either this is a manifestation of the
same bug behind those those cases, or the underlying problems were
fixed somewhere in aptitude or (lib)apt in the intervening years.


I was reviewing this problem with the changes in the last release and in
the one about to happen.  I tried to reproduce this bug, directly and
indirectly when checking other bug reports, and I haven't been able to
reproduce it.

In any case, this is a moving target and what happened in 2007/2008 has
little resemblance with the situation today, even if superficially the
symptoms look similar.  Several major versions of both apt and aptitude
went by, and some of these issues can come from both libapt, aptitude,
or the interaction between the two.

Many reports in aptitude auto-flag mishandled have been addressed in the
last few months.  Probably some (or, with less luck, many) still remain,
and many reports are still open and left to be investigated.

Hopefully it got fixed silently in the last few years, or with the
specific changes in the last releases; but if not, it's better if we try
to catch it when we have a recent and reproducible case.

So closing this report now.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#806946: Acknowledgement (bindgraph doesn't show any graphic)

[mjimenez]

Hello,

In my case http://host/cgi-bin/bindgraph.cgi showed embty graphs, without bars.

It seems to ge an user/permissions problem.

/etc/init.d/bindgraph start didn' start the daemon.

Why? Because it tries to start it under daemon:adm, but daemon is not member of 
adm by default in my system (wheezy).

"nice -20 /usr/sbin/bindgraph.pl --daemon --logfile /var/log/bing9-query.log" 
works launched by root, but it doesn't work launched by daemon (error:  
bindgraph: can't write to /var/lib/bindgraph), because this directory is owned 
by root:adm 775.

Making daemon member of adm in /etc/group manually shows the bars in the graphs.

-- 

Bug#816080: [wajig] Segfault on wajig show command for some packages.

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo
Control: forcemerge -1 815581


2016-02-28 10:41 To Paweł Różański:

Control: tags -1 + moreinfo


Hi Paweł,

2016-02-27 09:53 Paweł Różański:

Package: wajig
Version: 2.17
Severity: normal

--- Please enter the report below this line. ---
I noticed, that wajig show command segfaults on some packages. On 
some packages it works fine:

#LANG=C wajig show fglrx-driver
Segmentation fault (core dumped)

# LANG=C wajig show ssh
Segmentation fault (core dumped)

# LANG=C wajig show apt
Package: apt
Version: 1.2.3
[...]

Notice: apt-cache show works fine for all mentioned packages. Wajig 
update was executed, system after fresh reboot. If additional 
information is needed, please provide commands run.


Does the crash happen only for the "not installed" packages and it's
fine for the "installed" ones?  If so, it's #815581, fix to be released
tomorrow or so.


So I'm going to assume that this is the case and will merge the reports
now.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#789162: aptdaemon: CVE-2015-1323: information disclosure via simulate dbus method

[Guido Günther]

Hi,
On Thu, Jun 18, 2015 at 02:33:43PM +0200, Salvatore Bonaccorso wrote:
> Source: aptdaemon
> Version: 1.1.1-4
> Severity: grave
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for aptdaemon, which AFICS
> as well affects Debian.
> 
> CVE-2015-1323[0]:
> information disclosure via simulate dbus method
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

Please find patches for wheezy-security and jessie-security attached.

The tracker has:

  "For jessie-security compat layer for PackageKit needs to be dropped"

The current version in sid also has "Drop PackageKit compat layer" which
seems to confirm that but there's no explanation why needs to go.

I'm happy about any review or a thumgs up to upload to security-master.

Cheers,
 -- Guido
diff --git a/debian/changelog b/debian/changelog
index eb3eb13..3366b5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+aptdaemon (0.45-2+deb7u1) wheezy-security; urgency=high
+
+  * Non maintainer upload
+  * Add CVE-2015-1323.patch to address CVE-2015-1323 - taken from
+0.43+bzr805-0ubuntu10 (Closes: #789162)
+
+ -- Guido Günther   Mon, 29 Feb 2016 08:33:47 +0100
+
 aptdaemon (0.45-2) unstable; urgency=medium
 
   * Check downloaded key id; merged from Ubuntu (CVE-2012-0962)
diff --git a/debian/patches/CVE-2015-1323.patch b/debian/patches/CVE-2015-1323.patch
new file mode 100644
index 000..09bcfb6
--- /dev/null
+++ b/debian/patches/CVE-2015-1323.patch
@@ -0,0 +1,373 @@
+From: =?utf-8?q?Guido_G=C3=BCnther?= 
+Date: Sun, 28 Feb 2016 19:55:02 +0100
+Subject: CVE-2015-1323
+
+---
+ aptdaemon/core.py | 10 ++
+ aptdaemon/pkcompat.py | 11 +++
+ aptdaemon/policykit1.py   |  9 ++---
+ aptdaemon/worker.py   | 43 ++-
+ tests/test_dbus_type.py   |  6 --
+ tests/test_unicodedecoding.py |  3 ++-
+ tests/test_worker.py  | 31 ---
+ 7 files changed, 79 insertions(+), 34 deletions(-)
+
+diff --git a/aptdaemon/core.py b/aptdaemon/core.py
+index b69923d..6d841e3 100644
+--- a/aptdaemon/core.py
 b/aptdaemon/core.py
+@@ -330,7 +330,7 @@ class Transaction(DBusObject):
+"DebconfSocket", "MetaData", "Locale",
+"RemoveObsoleteDepends")
+ 
+-def __init__(self, tid, role, queue, pid, uid, cmdline, sender,
++def __init__(self, tid, role, queue, pid, uid, gid, cmdline, sender,
+  connect=True, bus=None, packages=None, kwargs=None):
+ """Initialize a new Transaction instance.
+ 
+@@ -365,6 +365,7 @@ class Transaction(DBusObject):
+ kwargs = {}
+ self.queue = queue
+ self.uid = uid
++self.gid = gid
+ self.locale = dbus.String("")
+ self.allow_unauthenticated = dbus.Boolean(False)
+ self.remove_obsoleted_depends = dbus.Boolean(False)
+@@ -1469,11 +1470,12 @@ class AptDaemon(DBusObject):
+ @inline_callbacks
+ def _create_trans(self, role, sender, packages=None, kwargs=None):
+ """Helper method which returns the tid of a new transaction."""
+-pid, uid, cmdline = \
++pid, uid, gid, cmdline = \
+ yield policykit1.get_proc_info_from_dbus_name(sender, self.bus)
+ tid = uuid.uuid4().get_hex()
+-trans = Transaction(tid, role, self.queue, pid, uid, cmdline, sender,
+-packages=packages, kwargs=kwargs, bus=self.bus)
++trans = Transaction(
++tid, role, self.queue, pid, uid, gid, cmdline, sender,
++packages=packages, kwargs=kwargs, bus=self.bus)
+ self.queue.limbo[trans.tid] = trans
+ return_value(trans.tid)
+ 
+diff --git a/aptdaemon/pkcompat.py b/aptdaemon/pkcompat.py
+index 0806201..845c72e 100644
+--- a/aptdaemon/pkcompat.py
 b/aptdaemon/pkcompat.py
+@@ -408,9 +408,10 @@ class PackageKit(aptdaemon.core.DBusObject):
+ 
+ @inline_callbacks
+ def _get_tid(self, sender):
+-pid, uid, cmdline = \
++pid, uid, gid, cmdline = \
+ yield policykit1.get_proc_info_from_dbus_name(sender, self.bus)
+-pktrans = PackageKitTransaction(pid, uid, cmdline, self.queue, sender)
++pktrans = PackageKitTransaction(
++pid, uid, gid, cmdline, self.queue, sender)
+ return_value(pktrans.tid)
+ 
+ # pylint: disable-msg=C0103,C0322
+@@ -531,7 +532,8 @@ class MergedTransaction(aptdaemon.core.Transaction):
+ def __init__(self, pktrans, role, queue, connect=True,
+  bus=None, packages=None, kwargs=None):
+ aptdaemon.core.Transaction.__init__(self, pktrans.tid[1:], role, queue,
+-pktrans.pid, pktrans.uid,
++pktrans.pid,
++   

Bug#664866: refresh, backports in security-tracker

[Geert Stappers]

FWIW updating the ticket

- Forwarded message from Salvatore Bonaccorso  -

Date: Mon, 29 Feb 2016 21:05:02 +0100
From: Salvatore Bonaccorso 
To: Geert Stappers 
Cc: debian-security-trac...@lists.debian.org
Subject: Re: severity-tracker and backports

Hi Geert,

On Mon, Feb 29, 2016 at 08:58:00PM +0100, Geert Stappers wrote:
> Hi,
> 
> https://security-tracker.debian.org/tracker/CVE-2016-1898
> mentions wheezy and stretch, but not jessie, neither jessie-backports.
> 
> CVE-2016-1898 is about a ffmpeg vulnerbility.
> 
> ffmpeg is not in jessie, but it is in jessie-backports.
> 
> The CVE-2016-1898 vulnerbility is is fixed in jessie-backports.
> 
> What needs to be done that the Debian security-tracker
> reports status of packages in backports?

There is some discussion about this in #664866. But we haven't
progress on having that correctly since then.

Regards,
Salvatore

- End forwarded message -

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#809623: RFS: telegram-purple/1.2.5

[Gianfranco Costamagna]

Hi,

>It *is* backward-compatible, but now a freshly-introduced 
>turns-out-to-be-big feature is missing.


let me know if you can do your upstream features in time, and I'll try to 
quickly make the package
uploaded on unstable then :)

cheers,

G.

Bug#809623: RFS: telegram-purple/1.2.5

[Ben Wiederhake]

Hey there,


Well, that didn't work. Also, see below. As it turns out, pushing 1.2.5
into Debian right now would be a bad idea.


again, if the problem is on Windows, I don't really care.


We're not entirely sure about that; and 1.3.0 isn't ready yet.


Due to Telegram cranking out unexpected features that break everything,
we won't push 1.2.5 into Debian anyway, so that's why I don't bother
with another RFS yet.


as you wish, just be aware that we can break the freeze if needed, just
speed up the fixes :)


Wow, thanks!
But I'll decline for this time. Version 1.2.5 doesn't support 
channels/supergroups, and letting all telegram-enthusiasts run against 
the wall called "Yeah we promise it'll be in the next release for sure I 
swear" is a bad idea. So it's even more waiting.



(with telegram changing API/ABI it becomes difficult to make it suitable
for stable...)


It *is* backward-compatible, but now a freshly-introduced 
turns-out-to-be-big feature is missing.


Regards
Ben

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

[Alois Schloegl]

On 2016-02-29 16:08, lumin wrote:
> Hi,
> 
> Thank you for reporting this bug.
> 
> It seems like a GCC ABI issue, rather than that of CUDA
> or nvidia-driver.
> If the nvidia-driver package ships binary then they are
> linked by GCC-5, which requires an different ABI to
> the one of Jessie. Hence installing stuff from unstable
> into Jessie may basically introduce ABI-broken ELFs.
> If the truth lies there, this bug cannot be fixed.
> And my advise is 1. try unstable 2. install nvidia stuff
> 
> Does this bug appear in version 7.0.28-3 or some former version?
> or is this the first time you trying to install these stuff from
> unstable into stable?



Before trying to upgrade, I was on
   nvidia-driver 352.41
   nvidia-cuda-toolkit 6.5.19
from debian/testing. This was working.

Now, I'm on
   nvidia-driver 352.79-4
   nvidia-cuda-toolkit 7.0.28-4
from debian/unstable.

This machine is part of a larger compute cluster, and I'd prefer to
stick with Jessie, if possible.

If your theory about incompatible ABI's is correct, it would not help
installing "nvidia stuff", because the ABI would still be incompatible.

Attached is the list of installed nvidia packages obtained with
dpkg -l|grep -i nvidia

Thanks,
   Alois




> 
> Thanks :-)
> 

ii  glx-alternative-nvidia 0.7.1
amd64allows the selection of NVIDIA as GLX provider
rc  libcublas6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuBLAS Library
ii  libcublas7.0:amd64 7.0.28-4 
amd64NVIDIA cuBLAS Library
ii  libcuda1:amd64 352.79-4 
amd64NVIDIA CUDA Driver Library
rc  libcudart6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA CUDA Runtime Library
ii  libcudart7.0:amd64 7.0.28-4 
amd64NVIDIA CUDA Runtime Library
rc  libcufft6.5:amd64  6.5.19-3~bpo8+1  
amd64NVIDIA cuFFT Library
ii  libcufft7.0:amd64  7.0.28-4 
amd64NVIDIA cuFFT Library
rc  libcufftw6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuFFTW Library
ii  libcufftw7.0:amd64 7.0.28-4 
amd64NVIDIA cuFFTW Library
rc  libcuinj64-6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA CUINJ Library (64-bit)
ii  libcuinj64-7.0:amd64   7.0.28-4 
amd64NVIDIA CUINJ Library (64-bit)
rc  libcurand6.5:amd64 6.5.19-3~bpo8+1  
amd64NVIDIA cuRAND Library
ii  libcurand7.0:amd64 7.0.28-4 
amd64NVIDIA cuRAND Library
ii  libcusolver7.0:amd64   7.0.28-4 
amd64NVIDIA cuSOLVER Library
rc  libcusparse6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA cuSPARSE Library
ii  libcusparse7.0:amd64   7.0.28-4 
amd64NVIDIA cuSPARSE Library
ii  libegl1-nvidia:amd64   352.79-4 
amd64NVIDIA binary EGL libraries
ii  libgl1-nvidia-glx:amd64352.79-4 
amd64NVIDIA binary OpenGL libraries
ii  libgles1-nvidia:amd64  352.79-4 
amd64NVIDIA binary OpenGL|ES 1.x libraries
ii  libgles2-nvidia:amd64  352.79-4 
amd64NVIDIA binary OpenGL|ES 2.x libraries
rc  libnppc6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives core runtime library
ii  libnppc7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives core runtime library
rc  libnppi6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives for image processing runtime library
ii  libnppi7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives for image processing runtime library
rc  libnpps6.5:amd64   6.5.19-3~bpo8+1  
amd64NVIDIA Performance Primitives for signal processing runtime library
ii  libnpps7.0:amd64   7.0.28-4 
amd64NVIDIA Performance Primitives for signal processing runtime library
ii  libnvidia-compiler:amd64   352.79-4 
amd64NVIDIA runtime compiler library
ii  libnvidia-eglcore:amd64352.79-4 
amd64NVIDIA binary EGL core libraries
ii  

Bug#812728: RFS: identity4c/1.0-1 [ITP] -- UFP Identity C library

[Richard Levenberg]

All of your comments have been addressed except for the empty NEWS which
is part of upstream.

All of the previous uploads have been removed and the only one that
should be evaluated is:

http://mentors.debian.net/debian/pool/main/i/identity4c/identity4c_1.0-1.dsc

Thank you.

r

Bug#816320: coreutils: CVE-2016-2781: nonpriv session can escape to the parent session by using the TIOCSTI ioctl

[Salvatore Bonaccorso]

Source: coreutils
Version: 8.13-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for coreutils.

CVE-2016-2781[0]:
|nonpriv session can escape to the parent session by using the TIOCSTI
| ioctl

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2781
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1312863
[2] http://seclists.org/oss-sec/2016/q1/452

Regards,
Salvatore

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

[Felipe Sateler]

On 29 February 2016 at 15:22, Anton Zinoviev  wrote:
> On Mon, Feb 29, 2016 at 09:54:23AM -0300, Felipe Sateler wrote:
>>
>> 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?
>
> Thank you.  In the new version I am preparing now (should be ready in a
> couple of days), this script will move out of runlevel S on Linux and on
> FreeBSD there is no systemd.

Interesting. Why is it no longer required during early boot?

> So it seems there will be no need for a
> systemd service unit.

Well, that depends on the value of "need" ;).  A systemd unit would
still be useful, as it allows better tracking by systemd of the
process. I can submit a systemd unit, after I see the end result of
this rework you are doing now.


-- 

Saludos,
Felipe Sateler

Bug#816319: Bugs missing from https://ftp-master.debian.org/removals.html

[Esa Peuha]

Package: ftp.debian.org

There are currently two bugs missing from the page of Pending
Debian Package removals, and have been for some time: 812554
and 814109. Since there doesn't seem to be any other reason why
these are still open, I'm assuming it's because they are
missing from the page.

Bug#816318: RM: ruby-rspec-core/experimental -- NVIU; never version in unstable

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Please remove ruby-rspec-core from experimental, sid has got 3.x already.

Thanks,
Christian

Bug#816310: Acknowledgement (WebSVN wants do write to non existing folder "/etc/apache2/conf.d")

[Joerg Schiermeier]

On Monday, February 29, 2016 at 19:39:05 the Debian Bug Tracking System wrote:

> If you wish to submit further information on this problem, please
> send it to 816...@bugs.debian.org.

Sorry, my bug report was always reported before four years ago. Please see:
#669785

This was a maintainers fault done by the maintainer of the SolydXK
distribution.

-- 

Kindly regards
Joerg Schiermeier
Bielefeld/Germany

Bug#816317: libffi: please add Homepage field

[Jakub Wilk]

Source: libffi
Version: 3.2.1-4
Severity: wishlist

Please add 


Homepage: https://sourceware.org/libffi/

to debian/control.

--
Jakub Wilk