Bug#819531: Invalid user name 'Debian-snmp' for adduser

[ISHIKAWA Mutsumi]

Package: snmpd
Version: 5.7.3+dfsg-1.1
Severity: grave

Setting up snmpd (5.7.3+dfsg-1.1) ...
adduser: Please enter a username matching the regular expression configured
via the NAME_REGEX configuration variable.  Use the `--force-badname'
option to relax this check or reconfigure NAME_REGEX.
dpkg: error processing package snmpd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 snmpd

"Debian-snmp" is invalid for adduser.

-- 
ISHIKAWA Mutsumi 

Bug#775550: [Pkg-fedora-ds-maintainers] Bug#775550: 389-ds-base: Update fails when /var mounted on different filesystem than /etc

[Timo Aaltonen]

17.01.2015, 10:23, Michal Kaspar kirjoitti:
> Package: 389-ds-base
> Version: 1.3.3.5-3
> Severity: normal
> 
> Dear Maintainer,
> When updating package 389-ds-base, update fails and leaves directory server 
> in uconfigured state if /var is mounted on separate filesystem. There is no 
> apparent error, but changing /var/lib/dpkg/info/389-ds-base.postinst
> setup-ds -l $OUT -u -s General.UpdateMode=offline > $OUT 2>&1
> to
> setup-ds -l $OUT -u -s General.UpdateMode=offline
> reveals the problem in this postinst script. The error is:
> Could not rename config file 
> '/etc/dirsrv/slapd-KASPAR-IN/slapd-collations.conf' to 
> '/var/lib/dirsrv/slapd-KASPAR-IN/bak.bak/slapd-collations.conf'.  Error: 
> Invalid cross-device link
> Creating symlink /etc/dirsrv/bak -> 
> /var/lib/dirsrv/salpd-instance/{bak,bak.bak} resolves the problem but it's 
> not exactly elegant solution.

I dropped the patch to use move instead of rename, because turns out it
works even worse and for everyone.. and also because it was also
unnecessary since this upstream commit that I failed to notice until now:

commit c0d233b60311e2bf65dc13eee6f12abe221be932
Author: Ludwig Krispenz 
Date:   Tue Jan 20 10:34:41 2015 +0100

Ticket 47991 - upgrade script fails if /etc and /var are on
different file systems



-- 
t

Bug#819530: transition: icu

[Laszlo Boszormenyi (GCS)]

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

ICU has a new major upstream release, supporting several new things
that I would like to see in Stretch:
- CLDR[1] 28 [2] and 29 [3] support,
- Unicode 8.0.0 [4] support.

As it affects the system from Boost C++ libraries (several packages
build depends on it) to LibreOffice, it's not uploaded to experimental
even. But my local build tests on amd64 shows that Boost 1.58 could be
built and transiently some packages that build depends on Boost.
The biggest one is LibreOffice which could be built of course. In
short, I compiled ICU 57.1 and installed it -> compiled and installed
Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1.
May I proceed with the upload, targeting experimental first?

Regards,
Laszlo/GCS
[1] http://cldr.unicode.org/index
[2] http://cldr.unicode.org/index/downloads/cldr-28
[3] http://cldr.unicode.org/index/downloads/cldr-29
[4] http://www.unicode.org/versions/Unicode8.0.0/#Summary

Bug#815760:

[C.J. Collier]

 On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt 
wrote:
> Subject: ITP: dpdk -- Data Plane Development Kit
> Package: wnpp
> Owner: Christian Ehrhardt 
> Severity: wishlist
>
> * Package name: dpdk
>   Version : 2.2
>   Upstream Author : Thomas Monjalon 
> * URL : http://dpdk.org/
>  * License : BSD (core libs), GPLv2
(kernel components)
>   Programming Lang: C
>   Description : Data Plane Development Kit
>
...
> But I'm not a Debian developer, so I'd like to have a more Debian centric
> co-maintainer for a proper Debian expertise and opinion in all the work.
> I'm also no DD, so sponsors will be needed.

I'm interested in co-maintaining this package, and I've been a Debian user
for a couple of decades now.  I've even been an uploader, years ago.

I've submitted an ITP for the FD.io group of packages:

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

These depend on DPDK, so I've got an interest in making sure the DPDK
packages are good.

Cheers,

C.J.

Bug#819529: transition: libcrypto++

[Laszlo Boszormenyi (GCS)]

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

I'd like to do the libcrypto++ 5.6.1 to 5.6.3 transition. The latter is
already in experimental. Affected package maintainers are noted,
waiting for feedback. For the time being, I've rebuilt all affected
packages on amd64:
amule
armory
clementine
murasaki
pycryptopp
synergy
tegrarcm (non-free)

All built successfully and as the libcrypto++ libraries are
co-installable, binNMUs can be enough.

Cheers,
Laszlo/GCS

Bug#819528: transition: angular.js

[Laszlo Boszormenyi (GCS)]

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

I don't know if the Release Team follows JavaScript library
transitions or not. But I think it's better to be aware of
angular.js (libjs-angularjs) 1.3 (in Sid) to 1.5 (in experimental)
transition. I have noted the affected package maintainers.
Giving links on the migration issues[1][2]. The packages that may
need update:
glances
grafana-data
node-sprintf-js
nqp
owncloud-music
owncloud-tasks

The owncloud modules may not be relevant as owncloud is going to be
removed from the archive. Reason is that upstream gone hostile[3] and
don't want the software in distributions.

Regards,
Laszlo/GCS
[1] https://docs.angularjs.org/guide/migration#migrating-from-1-3-to-1-
4
[2] https://docs.angularjs.org/guide/migration#migrating-from-1-4-to-1-
5
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816376

Bug#808626: [pkg-boost-devel] Bug#808626: boost1.58: ships empty binary packages on some archs

[Steve M. Robbins]

On March 29, 2016 04:52:17 PM Wookey wrote:

> Do you have a schedule for uploading a version of 1.58 with this patch
> applied, and/or uploading a 1.59 which would make this issue go away,
> at least for arm64. Is there anything we can do to help? (I guess a
> report saying that the patch was tested working on arm64 would be
> helpful).

My apologies for the silence.  I thought I'd sent a follow-up to the bug, but 
now I see that I hadn't.  

The status is that I have uploaded 1.60  with the bug fixed.  It is waiting NEW 
processing.  Unfortunately, my time for debian is too limited to allow an 
upload for 1.58.  But NMUs are certainly welcomed.

-Steve


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

Bug#819527: RM: octave-octcdf -- ROM; deprecated; superseded by octave-netcdf

[Rafael Laboissière]

Package: ftp.debian.org
Severity: normal

Please, remove the octave-octcdf package from unstable and testing. It 
has been superseded by the octave-netcdf package, which is now in 
unstable.


Thanks,

Rafael Laboissière

Bug#408937: libpam-ldap: Wrong configuration with ldapi://

[Lucas Castro]

I was checking this bug,
it mention the #408440 bug, that say it has on writing the config file.
Said must write 'uri ldapi://'  instead of 'host ldapi://'.
But in my tests is already writing 'uri ldapi://'

shouldn't this bug  be closed?

Bug#387891: libpam-ldap: Hyphens ("-") in Base DN are not properly escaped for use in regular expressions

[Lucas Castro]

can someone say anything about this bug,
I've been trying  to reproduce but it seems is everything fine.
I can't get the reported error.

Bug#715615: [Mayhem] Bug report on achilles: achilles crashes with exit status 139

[Michal Zapletal]

Date: Wed, 10 Jul 2013 11:20:17 -0400
>From: Alexandre Rebert 
>-
>Body: ur-type{attachments=[]

Bug#819426: achilles: diff for NMU version 2-8.1

[Michal Zapletal]

Date: Mon, 28 Mar 2016 14:19:44  0200
>From: Tobias Frost 
>-
>Body: ur-type{attachments=[]

Bug#819475: [Pkg-rust-maintainers] Bug#819475: Bug#819475: rustc not run depend on gcc 4.9.2

[Angus Lees]

On Wed, 30 Mar 2016 at 13:27 Lihe Wang 
wrote:

> #~ rustc hello.rs
> error: linking with `cc` failed: exit code: 1
> note: "cc" "-Wl,--as-needed" "-m64" "-L"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "hello.0.o" "-o" "hello"
> "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
> "-Wl,-Bdynamic"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6a154fe0.rlib" "-l"
> "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt"
> "-l" "compiler-rt"
> note: /usr/bin/ld:
> /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib(jemalloc.pic.o):
> unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
>

It looks like this is a change in recent binutils (see discussion in
Bug#808205) - which I _think_ means our static libraries (librust-std-dev)
need to depend on binutils >= 2.25.90.20151209-1.  I note in the glibc-dev
case, however, the decision was "I therefore don't think we need to fix
that at the glibc level. Either we just ignore the problem saying we don't
support partial upgrades or we try to find a global way to fix the
dependencies for all libraries."

Lihe: The short version for you is if you're trying to run a mixed
stable/testing system(*), then you will also need to install binutils from
testing.
(*) rather than rebuild rustc.deb from source for stable.  If we had enough
man-power, it would probably make sense for us to maintain a rustc.deb for
stable-backports.

 - Gus

Bug#819526: ITP: python-feather-format -- Python interface to the Apache Arrow-based Feather File Format

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: python-feather-format
  Version : 0.1.0
  Upstream Author : Wes McKinney 
* URL : https://github.com/wesm/feather
* License : Apache-2
  Programming Lang: Python
  Description : Python interface to the Apache Arrow-based Feather File 
Format

(Include the long description here.)

 Feather is binary columnar serialization for data frames. It is
 designed to read and write data frames very efficiently, and to make it
 easy to share data across multiple data analysis languages.
 .
 This package provides python binding for feather format.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#819475: [Pkg-rust-maintainers] Bug#819475: rustc not run depend on gcc 4.9.2

[Lihe Wang]

#~ rustc hello.rs
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "hello.0.o" "-o" "hello"
"-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
"-Wl,-Bdynamic"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6a154fe0.rlib"
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6a154fe0.rlib" "-l"
"dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt"
"-l" "compiler-rt"
note: /usr/bin/ld:
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib(jemalloc.pic.o):
unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error

and here is the code:

fn main() {
println!("Hello World!");
}



2016-03-29 17:30 GMT+08:00 Sylvestre Ledru :

> Le 29/03/2016 à 11:23, wanglihe a écrit :
> > Package: rustc
> > Version: 1.7.0+dfsg1-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > I added testing repo and just   apt install rustc, so the gcc tool chain
> > remain at 4.9.2, and rustc can not compile any source code with error
> > about cc, after I update gcc, the problem resolved.
> What is the error ?
>
> Thanks
> S
>

Bug#819525: diffoscope must use ruby2.3

[Holger Levsen]

package: diffoscope
version: 51
severity: important

Hi,

On Tue, Mar 29, 2016 at 04:39:05AM +, Debian testing autoremoval watch 
wrote:
> diffoscope 51 is marked for autoremoval from testing on 2016-05-04
> 
> It (build-)depends on packages with these RC bugs:
> 818917: ruby2.2: Replaced by ruby2.3

we need to fix this. No idea what needs to be done here and #818917
ain't helpful.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Holger Levsen]

Hi,

On Tue, Mar 29, 2016 at 09:36:00PM -0400, Daniel Kahn Gillmor wrote:
> This isn't fun-spoiling, it's a useful reality check.  But if we were
> required to get all the way to 100% before we made any progress, then
> reproducible builds wouldn't have gotten off the ground at all.

it's surely progress on the gcc/clang side of things but dropping the
build path from the .buildinfo files would be a huge step *backwards*
for reproducibility…

> The changes proposed in this bug report are a good step that should
> handle a very large proportion of the debian archive.  The fact that
> there will remain corners of the archive that need additional work is
> fine: we can turn our attention to the remaining 20% once we get 80% of
> the buildpaths resolved.

true. 

my point was: I think we still need the build path in the .buildinfo files.

(And btw, this (build path in buildinfo files) is not what *this* bug report 
is about. but it's related.)

Also, c/c++ packages today only make up a small portion of the archive.
Probably this famous someone should do a rebuild of the archive, using
our toolchain (and this patch), using arbitrary build pathes.


-- 
cheers,
Holger




signature.asc
Description: Digital signature

Bug#819524: isc-dhcp-server: /etc/default/isc-dhcp-server not recognized as part of the package

[Oleg Shalaev]

Package: isc-dhcp-server
Version: 4.3.3-8
Severity: minor

The file /etc/default/isc-dhcp-server is created inside postinst
script and is not reported to be a part of the package.
I wonder if that was done for some reason.
I am developing a package able to set up a wireless hootspot, and
I would like to divert /etc/default/isc-dhcp-server using standard debian tools,
but can not do that because the system is not aware of this file.
Do you think it would be better to include this file either in "conffiles" or 
"install"?
I could fix this myself -- just let me know if this indeed can be considered as 
a bug.

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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.59
ii  debianutils4.7
ii  libc6  2.22-4
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 [Errno 2] No such file or directory: 
u'/etc/dhcp/dhcpd.conf'

-- debconf information excluded

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Daniel Kahn Gillmor]

On Tue 2016-03-29 20:58:32 -0400, Holger Levsen wrote:
> not wanting to spoil the fun, but…
>
> On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote:
>> > Ah great! And one less way to leak local information.
>> yep :)
>
> I *believe* it's not enough (for reproducible builds in arbitrary
> pathes) if gcc+clang can now cope. IIRC there are other compilers that
> have the same behaviour, eg ocaml and erlang, but probably others too.
>
> Someone shoulds to check this and confirm or deny though.

This isn't fun-spoiling, it's a useful reality check.  But if we were
required to get all the way to 100% before we made any progress, then
reproducible builds wouldn't have gotten off the ground at all.

The changes proposed in this bug report are a good step that should
handle a very large proportion of the debian archive.  The fact that
there will remain corners of the archive that need additional work is
fine: we can turn our attention to the remaining 20% once we get 80% of
the buildpaths resolved.

-dkg

Bug#819523: squid3 in wheezy-backports has unmet dependencies

[Craig Holyoak]

Package: squid3
Version: 3.4.8-6+deb8u2~bpo70+1
Severity: normal

Dear Maintainer,

I have been running squid3 from wheezy-backports fine for some time, currently 
on version 3.4.8-5~bpo70+1. However, following the recent update to 
3.4.8-6+deb8u2~bpo70+1, it is now uninstallable (and unupgradable):

# aptitude dist-upgrade
The following packages will be upgraded: 
  squid-cgi{b} squid3{b} squid3-common squidclient{b} 
4 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,610 kB of archives. After unpacking 226 kB will be freed.
The following packages have unmet dependencies:
 squid3 : Depends: libc6 (>= 2.15) but 2.13-38+deb7u10 is installed.
  Depends: libdb5.3 which is a virtual package.
  Depends: libstdc++6 (>= 4.9) but 4.7.2-5 is installed.
 squidclient : Depends: libc6 (>= 2.14) but 2.13-38+deb7u10 is installed.
 squid-cgi : Depends: libc6 (>= 2.14) but 2.13-38+deb7u10 is installed.
The following actions will resolve these dependencies:

 Remove the following packages:
1) squid-cgi   
2) squid3  
3) squidclient 



Accept this solution? [Y/n/q/?]

Clearly the versions of the above dependencies are not available in wheezy, or 
wheezy-backports, and have crept in from the packages for jessie somehow.


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages squid3 depends on:
ii  adduser  3.113+nmu3
ii  libc62.13-38+deb7u10
ii  libcap2  1:2.22-1.2
ii  libcomerr2   1.42.5-1.1+deb7u1
ii  libdb5.1 5.1.29-5
ii  libecap2 0.2.0-3~bpo70+1
ii  libexpat12.1.0-1+deb7u2
ii  libgcc1  1:4.7.2-5
ii  libgssapi-krb5-2 1.10.1+dfsg-5+deb7u7
ii  libk5crypto3 1.10.1+dfsg-5+deb7u7
ii  libkrb5-31.10.1+dfsg-5+deb7u7
ii  libldap-2.4-22.4.31-2+deb7u1
ii  libltdl7 2.4.2-1.1
ii  libnetfilter-conntrack3  1.0.1-1
ii  libnettle4   2.7.1-1~bpo70+1
ii  libpam0g 1.1.3-7.1
ii  libsasl2-2   2.1.25.dfsg1-6+deb7u1
ii  libstdc++6   4.7.2-5
ii  libxml2  2.8.0+dfsg1-7+wheezy5
ii  logrotate3.8.1-4
ii  lsb-base 4.1+Debian8+deb7u1
ii  netbase  5.0
ii  squid3-common3.4.8-5~bpo70+1

squid3 recommends no packages.

Versions of packages squid3 suggests:
pn  resolvconf   
pn  smbclient
ii  squid-cgi3.4.8-5~bpo70+1
pn  squid-purge  
ii  squidclient  3.4.8-5~bpo70+1
pn  ufw  
pn  winbindd 

-- Configuration Files:
/etc/logrotate.d/squid3 changed [not included]
/etc/squid3/squid.conf changed [not included]

-- no debconf information

Bug#759886: [patch #8925] Support --clamp-mtime for binary reproducibility]

[Holger Levsen]

Hi Guillem,

FYI, GNU tar's upstream has accepted our patch! :-)


cheers,
Holger

- Forwarded message from Sergey Poznyakoff  -

Date: Thu, 24 Mar 2016 05:33:34 +
From: Sergey Poznyakoff 
To: Sergey Poznyakoff , Ximin Luo , 
816...@bugs.debian.org, g...@gnu.org
Subject: [patch #8925] Support --clamp-mtime for binary reproducibility
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0

Update of patch #8925 (project tar):

  Status:None => Done   
 Assigned to:None => gray   

___

Follow-up Comment #1:

The patch is incorporated into Git repository (commit
13d04fe6ae5a343415299359944382f7a6d37816). It will appear in the next stable
release of GNU tar (v.1.29). Thank you!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



- End forwarded message -




signature.asc
Description: Digital signature

Bug#819522: openjdk: Openjdk version number contains - character.

[Greg Wilkins]

Package: openjdk-8-jre-headless
Version: 8u72-b15-1~bpo8+1
Severity: minor
File: openjdk

Dear Maintainer,

The oracle policy for JVM version numbers is at 
http://www.oracle.com/technetwork/java/javase/versioning-naming-139433.html
It states that:
A GA (FCS) product version or build identifier must not contain a dash (-).

The current reported version from java - version is  '1.8.0_72-internal'
This has caused some minor downstream issues: 
https://github.com/jetty-project/jetty-alpn-agent/pull/3 
which can be worked around.  However it is not desirable to have a version name 
that
contravenes a published policy


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

Kernel: Linux 4.2.0-34-generic (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages openjdk-8-jre-headless:amd64 depends on:
ii  ca-certificates-java  20140324
ii  initscripts   2.88dsf-59
ii  java-common   0.52
ii  libc6 2.19-18+deb8u2
ii  libcups2  1.7.5-11+deb8u1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libjpeg62-turbo   1:1.3.1-12
ii  liblcms2-22.6-3+b3
ii  libnss3   2:3.17.2-1.1+deb8u2
ii  libpcsclite1  1.8.13-1
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.4-1+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxtst6  2:1.2.2-1+b1
ii  multiarch-support 2.19-18+deb8u2
ii  zlib1g1:1.2.8.dfsg-2+b1

openjdk-8-jre-headless:amd64 recommends no packages.

Versions of packages openjdk-8-jre-headless:amd64 suggests:
pn  fonts-dejavu-extra 
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  libnss-mdns
pn  openjdk-8-jre-jamvm
pn  ttf-wqy-microhei | ttf-wqy-zenhei  

-- no debconf information

Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

[Holger Levsen]

Hi,

not wanting to spoil the fun, but…

On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote:
> > Ah great! And one less way to leak local information.
> yep :)

I *believe* it's not enough (for reproducible builds in arbitrary
pathes) if gcc+clang can now cope. IIRC there are other compilers that
have the same behaviour, eg ocaml and erlang, but probably others too.

Someone shoulds to check this and confirm or deny though.


-- 
cheers,
Holger

P.S.: besides that, truely nice work!


signature.asc
Description: Digital signature

Bug#819418: fte: watch file broken

[Axel Beckert]

Hi,

> >   >    * debian/watch: Create.
> > 
> > This is contra-productive. :-(
> > 
> > I'm sorry, what should i have write on the changelog instead? [...]
> 
> I think by "contra-productive" Axel refers to the file creation itself
> (for the reasons he explained later), not the changelog entry :-)

Yes. In retroperspective, it may have been ambiguous with regards to
my other comments. Sorry for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#819521: phpmyadmin: dependency problems with php-gettext and php-mysql

[Chip Rosenthal]

Package: phpmyadmin
Version: 4:4.5.5.1-2
Severity: important

Dear Maintainer,

I encountered two problems installing phpmyadmin on a new system.

After install, web application gave error 500, with logged message:

[Tue Mar 29 19:23:26.595905 2016] [:error] [pid 16189] [client ::1:33050] PHP 
Fatal error:  require_once(): Failed opening required 
'/usr/share/php/php-gettext/gettext.inc' (include_path='.') in 
/usr/share/phpmyadmin/libraries/select_lang.lib.php on line 477

==> Fixed by: sudo apt-get install php-gettext

After that fix, web application ran but displayed error screen:

phpMyAdmin - Error
The mysqli|mysql extension is missing. Please check your PHP configuration. See 
our documentation for more information.

==> Fixed by: sudo apt-get purge php7.0-mysql ; sudo apt-get install php5-mysql

Now my phpmyadmin installation is working.





*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages phpmyadmin depends on:
ii  dbconfig-common  2.0.4
ii  dbconfig-mysql   2.0.4
ii  debconf [debconf-2.0]1.5.59
ii  libapache2-mod-php5  5.6.19+dfsg-2
ii  libjs-sphinxdoc  1.3.6-2
ii  perl 5.22.1-9
ii  php-gettext  1.0.11-2
ii  php-phpseclib2.0.1-2
ii  php5 5.6.19+dfsg-2
ii  php5-cli 5.6.19+dfsg-2
ii  php5-common  5.6.19+dfsg-2
ii  php5-json1.3.7-1
ii  php5-mysql   5.6.19+dfsg-2
ii  php7.0-cli   7.0.4-6
ii  php7.0-common [php-gettext]  7.0.4-6
ii  php7.0-json  7.0.4-6
ii  php7.0-xml   7.0.4-6
ii  ucf  3.0036

Versions of packages phpmyadmin recommends:
ii  apache2 [httpd]  2.4.18-1
ii  mysql-client-5.6 [virtual-mysql-client]  5.6.28-1
ii  php-tcpdf6.2.12+dfsg2-1
ii  php5-common  5.6.19+dfsg-2
ii  php5-gd  5.6.19+dfsg-2
ii  php7.0-common7.0.4-6
ii  php7.0-gd7.0.4-6

Versions of packages phpmyadmin suggests:
ii  firefox-esr [www-browser]45.0.1esr-1
ii  google-chrome-beta [www-browser] 50.0.2661.49-1
ii  konqueror [www-browser]  4:15.08.3-1
ii  mysql-server 5.6.28-1
ii  mysql-server-5.6 [virtual-mysql-server]  5.6.28-1

-- debconf information:
  phpmyadmin/setup-username: admin
  phpmyadmin/remote/host: localhost
  phpmyadmin/install-error: abort
  phpmyadmin/upgrade-error: abort
  phpmyadmin/database-type: mysql
* phpmyadmin/dbconfig-install: true
  phpmyadmin/purge: false
  phpmyadmin/db/dbname: phpmyadmin
  phpmyadmin/internal/skip-preseed: false
  phpmyadmin/mysql/method: Unix socket
  phpmyadmin/remove-error: abort
  phpmyadmin/dbconfig-reinstall: false
  phpmyadmin/remote/port:
* phpmyadmin/reconfigure-webserver: apache2
* phpmyadmin/mysql/admin-user: debian-sys-maint
  phpmyadmin/passwords-do-not-match:
  phpmyadmin/internal/reconfiguring: false
  phpmyadmin/db/app-user: phpmyadmin
  phpmyadmin/remote/newhost:
  phpmyadmin/missing-db-package-error: abort
  phpmyadmin/dbconfig-upgrade: true
  phpmyadmin/dbconfig-remove: true
  phpmyadmin/upgrade-backup: true

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

Steinar H. Gunderson wrote:
> I don't have a kFreeBSD system to test this with. I assume you can do the
> upload yourself if needed, though?

I'm only a DM, so I would need a sponsor for this in any case.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff -Nru net-snmp-5.7.3+dfsg/debian/changelog 
net-snmp-5.7.3+dfsg/debian/changelog
--- net-snmp-5.7.3+dfsg/debian/changelog2016-03-29 09:30:26.0 
+0100
+++ net-snmp-5.7.3+dfsg/debian/changelog2016-03-30 01:27:19.0 
+0100
@@ -1,3 +1,10 @@
+net-snmp (5.7.3+dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Build-Depends: pkg-config on kfreebsd (Closes: #810982)
+
+ -- Steven Chamberlain   Wed, 30 Mar 2016 01:25:48 +0100
+
 net-snmp (5.7.3+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload, done on top of the latest version in pkg-net-snmp
diff -Nru net-snmp-5.7.3+dfsg/debian/control net-snmp-5.7.3+dfsg/debian/control
--- net-snmp-5.7.3+dfsg/debian/control  2016-03-29 00:46:41.0 +0100
+++ net-snmp-5.7.3+dfsg/debian/control  2016-03-30 01:30:17.0 +0100
@@ -8,6 +8,7 @@
  python-all (>= 2.6.6-3~), python-setuptools (>=0.6b3), python2.7-dev,
  autoconf, automake, autotools-dev, debianutils (>=1.13.1), dh-autoreconf,
  bash (>=2.05), findutils (>=4.1.20), procps, 
+ pkg-config [kfreebsd-i386 kfreebsd-amd64], 
  libbsd-dev [kfreebsd-i386 kfreebsd-amd64], 
  libkvm-dev [kfreebsd-i386 kfreebsd-amd64], 
  libsensors4-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],


signature.asc
Description: Digital signature

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Wed, Mar 30, 2016 at 01:08:00AM +0100, Steven Chamberlain wrote:
> Only kfreebsd needs it, to get flags for the libbsd overlay.
> 
> A diff is attached, if someone could please apply it...  I've tested in
> a clean sid chroot that I didn't miss any others.

FWIW, usually pbuilder is the safest way of getting a chroot that truly is
clean and minimal.

I don't have a kFreeBSD system to test this with. I assume you can do the
upload yourself if needed, though?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

found 810982 net-snmp/5.7.3+dfsg-1.1
tags 810982 + patch
thanks

Sorry, I didn't realise that on kfreebsd we now need to add a
Build-Depends: pkg-config.  Surprisingly it wasn't being used already or
brought in as a depedendency of something else - but I had it in all
three chroots I tested in.

Only kfreebsd needs it, to get flags for the libbsd overlay.

A diff is attached, if someone could please apply it...  I've tested in
a clean sid chroot that I didn't miss any others.

Thanks a lot,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/control b/debian/control
index 0aa5574..ded5385 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: debhelper (>= 9), libtool, libwrap0-dev, libssl-dev (>> 0.9.8), p
  python-all (>= 2.6.6-3~), python-setuptools (>=0.6b3), python2.7-dev,
  autoconf, automake, autotools-dev, debianutils (>=1.13.1), dh-autoreconf,
  bash (>=2.05), findutils (>=4.1.20), procps, 
+ pkg-config [kfreebsd-i386 kfreebsd-amd64],
  libbsd-dev [kfreebsd-i386 kfreebsd-amd64], 
  libkvm-dev [kfreebsd-i386 kfreebsd-amd64], 
  libsensors4-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],


signature.asc
Description: Digital signature

Bug#819520: [pkg-go] Bug#819520: ITP: containerd -- A daemon to control runC

[Dmitry Smirnov]

On Tuesday, 29 March 2016 4:49:35 PM AEDT Tianon Gravi wrote:
> Thanks for sharing your notes!  Hopefully we can come up with
> something clever that doesn't involve a snapshot of protobuf-compiler.

Well, there were some progress as I recently did some work on "gogoprotobuf" 
precisely to address FTBFS in docker-containerd... Unfortunately updating 
"gogoprotobuf" was not enough and it looks like we might need beta version of 
"protobuf" which packaging is not very well maintained... :(

-- 
All the best,
 Dmitry Smirnov.

---

Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick


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

Bug#760393: Some feedback...

[Roger Shimizu]

Dear Marco,

On Wed, Mar 30, 2016 at 6:41 AM, Marco Gaiarin  wrote:
>
> I've finally decomissioned the server, so i've get some time (and
> courage ;) to upgrade controller firmware to latest version (2.84) and
> do some test (server was off network, but with service online and with
> clamscan running on a loop continuously).
>
> Machine survive with wheezy kernel for a week, so seems to me that
> firmware upgrade (and/or wheezy kernel upgrades ;) cure the trouble.
>
> Probably the server will be trashed, anyway...

Thanks for your feedback!

It'd be appreciated if you can inform the version of running kernel
and version of upgraded firmware.
This may be helpful to those having the same hardware.

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

Bug#594868: Still applies

[Frank Lichtenheld]

This bug still applies.
A more recent example would be
https://packages.debian.org/jessie-backports/libapache2-mod-security2

It depends on apache2-api-20120211 which is provided in jessie, but
the page in jessie-backports doesn't reflect that.

-- 
Frank Lichtenheld 

Bug#819520: [pkg-go] Bug#819520: ITP: containerd -- A daemon to control runC

[Tianon Gravi]

On 29 March 2016 at 16:44, Dmitry Smirnov  wrote:
> Looks like they already use "proto3" syntax supported in unreleased 
> "protobuf-compiler"... :(

Arg, that's a pile of sadness, although not entirely unexpected. :'(

Thanks for sharing your notes!  Hopefully we can come up with
something clever that doesn't involve a snapshot of protobuf-compiler.
:(


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

Bug#819520: [pkg-go] Bug#819520: ITP: containerd -- A daemon to control runC

[Dmitry Smirnov]

On Tuesday, 29 March 2016 4:30:45 PM AEDT Tianon Gravi wrote:
> Package: wnpp
> * Package name: containerd
>   Version : 0.0.5
>   Upstream Author : Docker, Inc

You've beated me to this one. :) :)

I've been trying to compile it but got the following FTBFS:


# github.com/docker/containerd/api/grpc/types 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:690: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:691: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:692: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:693: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:694: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:695: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:696: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:697: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:698: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:699: undefined: 
proto.RegisterType 
src/github.com/docker/containerd/api/grpc/types/api.pb.go:699: too many errors 


Looks like they already use "proto3" syntax supported in unreleased 
"protobuf-compiler"... :(

-- 
Cheers,
 Dmitry Smirnov.

---

Believing is easier than thinking. Hence so many more believers than
thinkers.
-- Bruce Calvert


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

Bug#804624: please improve support for installing foreign packages to chroots and add DPKG_ROOT

[Guillem Jover]

Hi!

On Tue, 2015-11-10 at 00:01:48 +0100, Helmut Grohne wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: wishlist
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap

> Thank you very much for discussing the idea of DPKG_ROOT and recording
> some results at https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap
> already. By now, I am convinced that this idea is worth exploring and
> have thus prepared a small patch set implementing some of the first
> steps.

Some of the stuff I'll cover below I think I probably covered in our
conversation on IRC at the time, so it might not come as new stuff.

> a) dpkg should export DPKG_ROOT. DPKG_ROOT should be a string that
>should be prepended to "/" to arrive at the current installation
>root (instdir). Notably, when dpkg invokes chroot(), DPKG_ROOT
>becomes empty. At the moment, DPKG_ROOT is always empty, but this
>should not be relied upon. This is
>0001-export-a-variable-DPKG_ROOT.patch.

This part is fine in principle, and that's what I envisioned when
thinking about how to merge the dpkg functional test suite into the
dpkg git repo proper. But there are several reasons I've always
hesitated to add this support even though it would be useful for
dpkg itself.

> b) Packages that do not "set -u" (nounset), can now prepend $DPKG_ROOT
>to any file they operate on. With old versions $DPKG_ROOT will be
>unset and with change a) $DPKG_ROOT will be empty. Thus this change
>is backwards-compatible.

Right, and these can always be set like ": ${DPKG_ROOT:=}". We could
even recommend this as part of some doc/howto/spec for the initial
deployments, before packages can assume a recent enough dpkg.

> c) dpkg should gain a new force flag. I call it --force-remote-configure
>for now. It is supposed to force dpkg into running maintainer scripts
>without chroot even when the package in question did not declare that
>its maintainer scripts support this mode of operation. Note that we
>currently have no way to express whether a package supports running
>maintainer scripts without chroot. The flag is being added by
>0002-add-force-remote-scripts.patch and the behavior is implemented
>by 0003-inhibit-chroot-when-force-remote-scripts.patch. Packages can
>only reasonably support this mode after implementing b).

I don't quite like the name, as remote to me implies on some other
machine. Perhaps foreign, host or extern(al), although some of these
are a bit overloaded terms already.

Also I'm not sure this makes sense as a force option (instead of its own
proper option), as it is a behavior change that we want to always be safe
to use, in contrast to a force option that just forces the behavior.
Having a force option that would not chroot some times is a bit
strange. We might still want to have both though, and there was a
related bug report for that (#614126).

> d) Once a) is accepted and b) starts getting implemented, we need to
>think about a way for packages to tell that they support "remote
>scripts". One way to do so would be to add a header "Remote-Scripts:
>yes" to the binary package stanza. Packages thus marked would be
>required to honour DPKG_ROOT in all maintainer scripts. This flag
>makes no provisions yet on what programs can be assumed to be
>installed outside the chroot that is operated on.

Yes, ideally only packages marked as such would get a chroot-less
environmemt when requested with the new option, because expecting the
user to know when a package supports this mode and on what specific
version is a terrible interface IMO, as it requires the user to
analyze the .debs before unpacking them.

One tiny concern is that if eventually we end up with the whole archive
(haha? :) supporting this, then the field seems a bit of bloat.

The other thing, that ISTR you brought up on IRC are triggers. I'm not
sure how we'd handle those either. :/

> e) Once a) is accepted and b) starts getting implemented, we need to
>think about what programs maintainer scripts can assume to be
>available outside the chroot. Some ways to handle that:
> * Packages may only assume "common unix functionality". Such a set
>   would have to be defined somehow and roughly equates what
>   debootstrap requires.

Defining this in terms of strict POSIX compliance (or a subset of the
utilities defined within) would be the easiest/best I think.

> * Packages may only assume essential packages to be available.

That would resitrict the external system to be a Debian system. Which
might be fine I guess but is more limited than what debootstrap requires.
It has the problem that even then you need to specify essential of what
Debian version?

> * A new set of headers Maint-{Depends,Conflicts,...} is added to
>   request tools to be installed. These new relations would be
>   checked outside the chroot (if any).
> 
>   A full Debian release or two needs to pass 

Bug#819519: mirror submission for mirror.usertrust.info

[Matthew Weeks]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.usertrust.info
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-http: /debian/
CDImage-http: /debian-cd/
IPv6: no
Archive-upstream: mirrors.kernel.org
CDImage-upstream: mirrors.kernel.org
Updates: four
Maintainer: Matthew Weeks 
Country: US United States
Comment: We (Matthew Weeks and Jonathan Ketchum) are long time users of Debian 
and would like to help the project out by hosting a mirror.
 Our maximum bandwidth is 100Mbps.

Bug#819520: ITP: containerd -- A daemon to control runC

[Tianon Gravi]

Package: wnpp
Severity: wishlist
Owner: Tianon Gravi 

* Package name: containerd
  Version : 0.0.5
  Upstream Author : Docker, Inc
* URL : https://containerd.tools
* License : Apache-2.0, CC-BY-SA-4.0
  Programming Lang: Go
  Description : A daemon to control runC

Containerd is a daemon to control runC, built for performance and
density. Containerd leverages runC's advanced features such as seccomp
and user namespace support as well as checkpoint and restore for cloning
and live migration of containers.

It will be the "guts" behind Docker 1.11+, but should also be useful as
a standalone container monitor/manager for users who do not want the
additional complexity and features Docker provides.

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

Bug#819518: hexedit: Improve the short description

[Joao Eriberto Mota Filho]

Package: hexedit
Version: 1.2.13-3
Severity: minor

This is to remember me to improve the short description, to make hexedit
easier to search for more users.

Description: viewer and editor in hexadecimal or ASCII for files or devices

Regards,

Eriberto

Bug#819517: electrum: Please add a dependency against python-zbar

[Laurent Bigonville]

Package: electrum
Version: 2.5.4-2
Severity: minor

Hi,

Electrum uses python-zbar in the "Send" tab to scan the barcodes, if the
package is not installed it display a message suggesting to install it
using pip.

I would say that this is not a good advise in debian. The package should
probably Recommends against python-zbar and the message should be
changed to suggest to install the zbar using apt.

Cheers,

Laurent Bigonville

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

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

Versions of packages electrum depends on:
ii  python-electrum  2.5.4-2
pn  python:any   

Versions of packages electrum recommends:
ii  python-qt4  4.11.4+dfsg-1+b3

Versions of packages electrum suggests:
pn  python-btchip  
pn  python-trezor  

-- no debconf information

Bug#819516: ITP: fdio-vpp -- Open Source Vector Packet Processing Platform

[C.J. Collier]

Package: wnpp
Severity: wishlist
Owner: "C.J. Collier" 

* Package name: fdio-vpp
  Version : 1.0.0
  Upstream Author : FD.io VPP-dev list 
* URL : https://wiki.fd.io/view/VPP
* License : Apache-2.0
  Programming Lang: C
  Description : Open Source Vector Packet Processing Platform

The VPP platform is an extensible framework that provides out-of-the-box
production quality switch/router functionality. It is the open source
version
of Cisco's Vector Packet Processing (VPP) technology: a high performance,
packet-processing stack that can run on commodity CPUs.

The benefits of this implementation of VPP are its high performance, proven
technology, its modularity and flexibility, and rich feature set.

It is a modular design. The framework allows anyone to "plug in" new graph
nodes without the need to change core/kernel code.

Bug#819515: python-sympy: please package new upstream version

[Francesco Poli (wintermute)]

Package: python-sympy
Version: 0.7.6.1-2
Severity: wishlist

Hello and thanks (again) for maintaining the sympy Debian package!

There's a new upstream version (1.0) available with new interesting
features: could you please package it?

Thanks for your time.

P.S.: As an aside, I noticed that the tracker [1] claims that src:sympy is
  marked for autoremoval from testing on 23 April due to bug #817789 [2];
  frankly speaking, I do not understand the relation between the bug
  and sympy, since python-blockdiag does not seem to be a (direct or
  indirect) dependency of any of src:sympy binary packages, nor 
  a (direct) build-dependency... maybe it's an indirect build-dependency?
  Anyway, please investigate and, possibly, help to fix bug #817789 !
  Once more, thanks for your time and dedication.

[1] https://tracker.debian.org/pkg/sympy
[2] https://bugs.debian.org/817789

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Santiago Vila]

> Thanks!  In the built tree in this setup, could you please
> 
> $ ls -l src/binary-gcl/maxima
> 
> $ ./maxima-local
> (%i1) to_lisp();
> MAXIMA> (length si::*code-block-reserve*)
> MAXIMA> (si::contiguous-report nil)
> MAXIMA> (setq *load-verbose* t)
> MAXIMA> (compile nil '(lambda nil nil))

I'll try.

> > Could you please try on a machine with 5GB of RAM + 2 GB of swap?
> > (If you are not used to virtual machines, try virt-manager, it works great).
> 
> I have a laptop and access to the debian build machines via ssh.  I've
> installed virt-manager and looked at it briefly, but it appears to
> require root and or console access.  I've got 4Gb on my laptop.

Yes, you have to be root to setup the thing initially, certainly
not to be done on a Debian official machine.

I'm afraid that 4 GB of RAM will not be enough to reproduce this.
Let me think what we can do about this.

> > In the meantime, I would suggest setting GCL_MEM_MULTIPLE=0.5
> > somewhere in debian/rules. I have the feeling that the upstream
> > default of 1.0 is not a good one.
> 
> This should be harmless enough, but I suspect that the cure is
> accidental, i.e. the failure lies not in running out of memory but in
> placing code above the 2Gb limit.

To be frank, I don't think that using GCL_MEM_MULTIPLE is a good
solution either.

When testing for "dpkg-buildpackage -A", I found that I always need
more and more memory, so I setup a "memory monitor" to see how much
memory does a package uses exactly.

If a given package uses all available memory, no matter what, my
memory monitoring system will tell me that it needs 4GB on a 4GB
machine, 8GB on a 8GB machine, and so on.

I would much prefer that packages use the memory they really need,
regardless of the memory of the system on which the package is built.

Thanks.

Bug#819514: RFS: emacs-buttercup/1.5-1 [ITP] -- behaviour-driven testing for Emacs Lisp packages

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of emacs-buttercup.

Buttercup is an alternative framework for writing test suites for Emacs
Lisp addons that various addons are adopting in preference or in
addition to the ERT testing framework that comes with Emacs.

* Package name: emacs-buttercup
  Version : 1.5-1
  Upstream Author : Jorgen Schaefer 
* URL : https://github.com/jorgenschaefer/emacs-buttercup/
* License : GPL-3+
  Section : lisp

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.5-1.dsc

Or build it with gbp:

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

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Tue, Mar 29, 2016 at 11:14:40PM +0200, Steinar H. Gunderson wrote:
> Thanks! I've squashed your changes into my NMU diff and done a re-upload.
> New diff attached.

Urm, eventually that skipped the DELAYED queue; sorry about that. I don't
actually understand how it happened, because even though I did a dput without
at first, I hit Ctrl-C before it could upload any files, and then re-uploaded
with -e 7. So, strange.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#819467: gap 4r8

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Bill,

On 29/03/16 11:04, Bill Allombert wrote:
> However, I might need to change sysinfo.gap again to address your issue
> with with i686 being replaced by i586 in some build, and that might
> require other packages to be rebuild.

I thought that this part has been solved a long time ago.

Second, is the number of packages to rebuild that large ?


Thanks,
Jerome
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW+vpMAAoJEIC/w4IMSybjvM8H+wf0A1T8Jaf4hyyjiVp+y90J
sMLO7o0vQB1YuM8oBMjmlg/9kUD63pQJ6DmH2G5n8ccPi/MWIz1Xel2yVM3GWxyf
Dihmec1DUWicr/7C48kw12+AGREuQCL5qq+0vtvk1Dl2MSS4U6JU7eZkK0LMU7Hw
p3YtHMlqJRmj0uJ2gSZHLixnD3lUeQeSA+VrFpuP48BNLACaDoHmFlw1M6C2xSy4
W1ZsdhSJRWbCyqSWo4VHlx5qC6sPwripu4tiEOUwzh/PM4U+N3RWuteXoj8nOoRc
lK3NzijbSCvd+uTlC35s7LWCu4U9RgCYLsYqPagOjPQ7gc0RneK06FOSb+vHtmw=
=PVQv
-END PGP SIGNATURE-

Bug#819463: RFS: python-arrayfire/3.3.20160328-1 [ITP]

[Mattia Rizzolo]

On Tue, Mar 29, 2016 at 05:58:28PM +0100, Ghislain Vaillant wrote:
> Just realized I should have probably named the source package
> "arrayfire-python" to reflect the name of the project on GitHub

no, for the very simple reason that there is Python Debian Policy that
asserts python modules have to be named python-${module_name}

> but it
> is probably too late now, isn't it?

technically it isn't: it's easy enough to ask to the ftp master to
reject the package, change the name and re-upload it, but it's a bad
idea, as i said above.

-- 
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#760393: Some feedback...

[Marco Gaiarin]

I've finally decomissioned the server, so i've get some time (and
courage ;) to upgrade controller firmware to latest version (2.84) and
do some test (server was off network, but with service online and with
clamscan running on a loop continuously).

Machine survive with wheezy kernel for a week, so seems to me that
firmware upgrade (and/or wheezy kernel upgrades ;) cure the trouble.

Probably the server will be trashed, anyway...

Bug#819450: This affects Debian packaging of ublock-origin

[Sean Whitton]

control: severity -1 important
control: affects -1 +xul-ext-ublock-origin
control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1249324

This bug affects binary package xul-ext-ublock-origin, Debian's
packaging of the uBlock Origin ad-blocking extension.  The package uses
glyphs from fonts-font-awesome which Firefox fails to load.  Firefox
version 38 in Jessie (under the package name iceweasel, of course) does
not have this problem.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#818843: debian-security-support: new earlyend type, consider future end of support

[Santiago Ruano Rincón]

El 21/03/16 a las 18:00, Markus Koschany escribió:
> Am 21.03.2016 um 00:38 schrieb Santiago Ruano Rincón:
...
> > Also, would it be better to have a separate list file for earlyend?
> 
> Hi,
> 
> I think one file (security-support-ended.deb7) where we store all the
> information should be sufficient. I applied your patch and tested it on
> Wheezy and it seems to work as intended.
> 

Hi,

Thanks for testing! I have uploaded pushed some changes into
collab-maint. There is also a test package available at:

deb https://people.debian.org/~santiago/debian wheezy/
deb-src https://people.debian.org/~santiago/debian wheezy/

Cheers,

Santiago


signature.asc
Description: PGP signature

Bug#817553: Pending fixes for bugs in the libsnowball-swedish-perl package

[pkg-perl-maintainers]

tag 817553 + pending
thanks

Some bugs in the libsnowball-swedish-perl package are closed in
revision cdbd3418e32ee4b1e8f148d34c8eb417564479c8 in branch 'master'
by Dominic Hargreaves

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libsnowball-swedish-perl.git/commit/?id=cdbd341

Commit message:

Switch to minimal dh style rules, and modernize deps and Standards-Version 
(Closes: #817553)

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Tue, Mar 29, 2016 at 09:38:05PM +0100, Steven Chamberlain wrote:
> Commit deed97cc in pkg-net-snmp Git, changed debian/snmpd.postinst
> SNMP_USER from "snmp" to "Debian-snmp".  I think a corresponding change
> is missing from debian/snmpd.default as it fails to start snmpd with:
> 
> Starting SNMP services::Bad user id: snmp

Ah. I didn't test snmpd, only the client tools.

> Also, `dpkg-buildpackage -S` fails in an already-built tree, because the
> files below are generated during the build, and debian/rules clean does
> not remove them:

Yes, I knew about this one -- however, I wasn't going to try to fix all
issues in the existing package at once. :-)

> I've attached a diff against your NMU to fix both of these things.
> After that, the client and server both work nicely for me, IPv6 too.

Thanks! I've squashed your changes into my NMU diff and done a re-upload.
New diff attached.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
>From d87d05256001f852dd8f66116b5d11a16b713b45 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" 
Date: Tue, 29 Mar 2016 02:03:37 +0200
Subject: [PATCH] Diff for 5.7.3+dfsg-1.1 NMU, adding various patches for
 bugfixes (and one small new feature).

---
 debian/changelog   |  21 +++-
 debian/patches/callback_print.diff |  13 +++
 .../do_not_callback_for_failed_reports.diff| 129 +
 debian/patches/fix_engineid_reprobe.diff   |  16 +++
 debian/patches/fix_perl_bulk_gets.diff |  88 ++
 debian/patches/let_perl_access_engineid.diff   |  94 +++
 debian/patches/series  |   5 +
 debian/rules   |   6 +-
 debian/snmpd.default   |   2 +-
 9 files changed, 370 insertions(+), 4 deletions(-)
 create mode 100644 debian/patches/callback_print.diff
 create mode 100644 debian/patches/do_not_callback_for_failed_reports.diff
 create mode 100644 debian/patches/fix_engineid_reprobe.diff
 create mode 100644 debian/patches/fix_perl_bulk_gets.diff
 create mode 100644 debian/patches/let_perl_access_engineid.diff

diff --git a/debian/changelog b/debian/changelog
index 94bf7e1..e4622d2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,8 @@
-net-snmp (5.7.3+dfsg-2) UNRELEASED; urgency=medium
+net-snmp (5.7.3+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload, done on top of the latest version in pkg-net-snmp
+git, as well as adding Steven Chamberlain's kFreeBSD patches from
+bug #810892.
 
   [ Hideki Yamane ]
   * debian/patches
@@ -24,7 +28,20 @@ net-snmp (5.7.3+dfsg-2) UNRELEASED; urgency=medium
   * Re-enable IPv6 on kfreebsd (Closes: #765846)
   * Build with the libbsd overlay on kfreebsd, for nlist
 
- -- Hideki Yamane   Thu, 18 Jun 2015 06:43:28 +0900
+  [ Steinar H. Gunderson ]
+  * New patches, mostly for various bug fixes (some of them for crash bugs):
+* fix_engineid_reprobe.diff: Do not probe engineID for USM
+  if it is already given. (Closes: #765873)
+* callback_print.diff: Fix enum formatting when doing asynchronous queries
+  from Perl. (Closes: #765289)
+* do_not_callback_for_failed_reports.diff: Fix access of freed data due to
+  callbacks for reports occasionally coming twice.
+* fix_perl_bulk_gets.diff: Fix handling of truncated bulk get responses
+  in the Perl module. (Patch 1278 in upstream patch tracker.)
+* let_perl_access_engineid.diff: Add a new functions to let Perl code
+  access the security engine ID.
+
+ -- Steinar H. Gunderson   Tue, 29 Mar 2016 10:30:24 +0200
 
 net-snmp (5.7.3+dfsg-1) unstable; urgency=medium
 
diff --git a/debian/patches/callback_print.diff b/debian/patches/callback_print.diff
new file mode 100644
index 000..f4b6df6
--- /dev/null
+++ b/debian/patches/callback_print.diff
@@ -0,0 +1,13 @@
+--- net-snmp-5.7.2.1~dfsg.orig/perl/SNMP/SNMP.xs
 net-snmp-5.7.2.1~dfsg/perl/SNMP/SNMP.xs
+@@ -1300,6 +1300,10 @@ void *cb_data;
+  netsnmp_ds_set_boolean(NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_PRINT_NUMERIC_OIDS, 1);
+  netsnmp_ds_set_int(NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_OID_OUTPUT_FORMAT, NETSNMP_OID_OUTPUT_NUMERIC);
+   }
++  if (SvIV(*hv_fetch((HV*)SvRV(sess_ref),"UseEnums", 8, 1)))
++ sprintval_flag = USE_ENUMS;
++  if (SvIV(*hv_fetch((HV*)SvRV(sess_ref),"UseSprintValue", 14, 1)))
++ sprintval_flag = USE_SPRINT_VALUE;
+ 
+   sv_bless(varlist_ref, gv_stashpv("SNMP::VarList",0));
+   for(vars = (pdu?pdu->variables:NULL); vars; vars = vars->next_variable) {
diff --git a/debian/patches/do_not_callback_for_failed_reports.diff b/debian/patches/do_not_callback_for_failed_reports.diff
new file mode 100644
index 000..96db193
--- /dev/null
+++ b/debian/patches/do_not_callback_for_failed_reports.diff
@@ -0,0 +1,129 @@
+Index: 

Bug#819513: ocl-icd-opencl-dev: Wrong deprecated tags

[Patrick Matters]

Source: ocl-icd-opencl-dev
Version: 2.2.3-1+deb8u1
Severity: normal

Dear Maintainer,

the actual CL/cl.h header contains wrong defines 
CL_EXT_PREFIX__VERSION_2_0_DEPRECATED for some function signatures. An 
example is clCreateCommandQueue. Newer versions of this package (i 
looked into 2.2.9) and the headers from khronos.org changed these 
function defines to CL_EXT_PREFIX__VERSION_1_2_DEPRECATED.


Wrong:
/* Deprecated OpenCL 2.0 APIs */
extern CL_API_ENTRY CL_EXT_PREFIX__VERSION_2_0_DEPRECATED 
cl_command_queue CL_API_CALL

clCreateCommandQueue(cl_context /* context */,
 cl_device_id   /* device */,
 cl_command_queue_properties/* properties */,
 cl_int *   /* errcode_ret */) 
CL_EXT_SUFFIX__VERSION_2_0_DEPRECATED;



Correct:
/* Deprecated OpenCL 2.0 APIs */
extern CL_API_ENTRY CL_EXT_PREFIX__VERSION_1_2_DEPRECATED 
cl_command_queue CL_API_CALL

clCreateCommandQueue(cl_context /* context */,
 cl_device_id   /* device */,
 cl_command_queue_properties/* properties */,
 cl_int *   /* errcode_ret */) 
CL_EXT_SUFFIX__VERSION_1_2_DEPRECATED;



It would be nice if you could update debian stable with a newer version, 
because otherwise compiling opencl sources with the correct define 
CL_EXT_PREFIX__VERSION_1_2_DEPRECATED fails. Otherwise the workaround is 
in using the wrong define CL_EXT_PREFIX__VERSION_2_0_DEPRECATED.


-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-83-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#819512: breeze: please make the build reproducible

[Dhole]

Source: breeze 
Version: 4:5.4.3-1 
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that breeze could not be built reproducibly.

When processing translation files and using a non-UTF8 locale, grep
misdetects them as binary files and embeds the line: "Binary file
(standard input) matches"

The attached patch fixes this by telling grep to treat the input as
text. Once applied, breeze can be built reproducibly in our current
experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds

Regards,
-- 
Dhole
diff -Nru breeze-5.4.3/debian/changelog breeze-5.4.3/debian/changelog
--- breeze-5.4.3/debian/changelog   2015-12-01 11:46:09.0 +0100
+++ breeze-5.4.3/debian/changelog   2016-03-28 18:31:13.0 +0200
@@ -1,3 +1,10 @@
+breeze (4:5.4.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix misdetection as binary input in grep when LC_ALL=C
+
+ -- Eduard Sanou   Mon, 28 Mar 2016 18:30:54 +0200
+
 breeze (4:5.4.3-1) unstable; urgency=medium
 
   * New upstream release (5.4.3).
diff -Nru breeze-5.4.3/debian/wrapperthemes.sh 
breeze-5.4.3/debian/wrapperthemes.sh
--- breeze-5.4.3/debian/wrapperthemes.sh2015-12-01 11:46:09.0 
+0100
+++ breeze-5.4.3/debian/wrapperthemes.sh2016-03-29 19:51:30.0 
+0200
@@ -13,7 +13,7 @@
 
 mkdir -p ${CURDIR}/debian/tmp${WRAPPERDIR}
 cd ${CURDIR}/debian/tmp${ICONDIR}
-grep -v Inherits ${CURDIR}/debian/tmp${ICONDIR}/${theme}/index.theme > 
"$tmp"
+grep -a -v Inherits ${CURDIR}/debian/tmp${ICONDIR}/${theme}/index.theme > 
"$tmp"
 echo "Inherits=${theme}" >> "$tmp"
 install -m 644 "$tmp" ${CURDIR}/debian/tmp${WRAPPERDIR}/${theme}.theme
 rm "$tmp"


signature.asc
Description: PGP signature

Bug#819511: libreoffice-writer: Writer freezes after scrolling down ODT document

[Stanislav Fyodorov]

Package: libreoffice-writer
Version: 1:5.1.2~rc1-1
Severity: important

Dear Maintainer,

Writer and the whole system freezes after opening and scrolling down
Test.odt.

This file and GDB trace are attached.


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

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

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.0-2
ii  libc6  2.19-18+deb8u3
ii  libe-book-0.1-10.1.1-2
ii  libetonyek-0.1-1   0.1.1-2
ii  libgcc11:5.3.1-12
ii  libicu55   55.1-7
ii  libmwaw-0.3-3  0.3.1-2
ii  libodfgen-0.1-10.1.1-2
ii  libreoffice-base-core  1:5.1.2~rc1-1
ii  libreoffice-core   1:5.1.2~rc1-1
ii  librevenge-0.0-0   0.0.1-3
ii  libstdc++6 5.3.1-12
ii  libwpd-0.10-10 0.10.0-2+b1
ii  libwpg-0.3-3   0.3.0-3
ii  libwps-0.4-4   0.4.3-1
ii  libxml22.9.1+dfsg1-5+deb8u1
ii  uno-libs3  5.1.2~rc1-1
ii  ure5.1.2~rc1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.1.2~rc1-1

Versions of packages libreoffice-writer suggests:
pn  default-jre | openjdk-8-jre | openjdk-7-jre | openjdk-6-jre   
ii  fonts-crosextra-caladea   20130214-1
ii  fonts-crosextra-carlito   20130920-1
ii  libreoffice-base  1:5.1.2~rc1-1
pn  libreoffice-gcj   
ii  libreoffice-java-common   1:5.1.2~rc1-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3
ii  fonts-opensymbol  2:102.6+LibO4.3.3-2+deb8u3
ii  libboost-date-time1.58.0  1.58.0+dfsg-5+b1
ii  libc6 2.19-18+deb8u3
ii  libcairo2 1.14.0-2.1
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.1-2
ii  libcups2  1.7.5-11+deb8u1
ii  libcurl3-gnutls   7.38.0-4+deb8u3
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.102-1
ii  libdconf1 0.22.0-1
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-6+deb8u1
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:5.3.1-12
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.48.0-1
ii  libgltf-0.0-0v5   0.0.2-4+b1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgraphite2-31.3.6-1~deb8u1
ii  libharfbuzz-icu0  0.9.35-2
ii  libharfbuzz0b 0.9.35-2
ii  libhunspell-1.3-0 1.3.3-3
ii  libhyphen02.8.8-1
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libjpeg62-turbo   1:1.3.1-12
ii  liblangtag1   0.5.1-3
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-1
ii  libnspr4  2:4.12-1
ii  libnss3   2:3.23-1
ii  libodfgen-0.1-1   0.1.1-2
ii  libpcre3  2:8.35-3.3+deb8u2
ii  libpng12-01.2.50-2+deb8u2
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.1.2~rc1-1
ii  librevenge-0.0-0  0.0.1-3
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.2   1.0.2g-1
ii  libstdc++65.3.1-12
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.1+dfsg1-5+deb8u1
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.8-1+b1
ii  libxslt1.11.1.28-2+b2
ii  uno-libs3 5.1.2~rc1-1
ii  ure   5.1.2~rc1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information


logs.tar.gz
Description: application/gzip

Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

Hi Steinar,

Steinar H. Gunderson wrote:
> I intend to NMU for this bug and a few other bugs that I'd really like to see
> fixed before stretch. I've uploaded to DELAYED/7-day; let me know if you'd
> like anything changed. I've attached my own git diff on top of Steven's diff
> (which is on top of latest pkg-net-snmp git).

Many thanks for this.  But I found some issues when testing:

Commit deed97cc in pkg-net-snmp Git, changed debian/snmpd.postinst
SNMP_USER from "snmp" to "Debian-snmp".  I think a corresponding change
is missing from debian/snmpd.default as it fails to start snmpd with:

Starting SNMP services::Bad user id: snmp

Also, `dpkg-buildpackage -S` fails in an already-built tree, because the
files below are generated during the build, and debian/rules clean does
not remove them:

  * pkg-net-snmp/dist/generation-scripts/gen-variables
  * pkg-net-snmp/perl/SNMP/t/snmptest.cmd
  * pkg-net-snmp/perl/TrapReceiver/const-c.inc
  * pkg-net-snmp/perl/TrapReceiver/const-xs.inc

I've attached a diff against your NMU to fix both of these things.
After that, the client and server both work nicely for me, IPv6 too.

Thanks again,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/rules b/debian/rules
index d1da11e..d2e7ece 100755
--- a/debian/rules
+++ b/debian/rules
@@ -62,7 +64,11 @@ override_dh_clean:
 	dh_clean
 	rm -rf `find . -name .libs` \
 	   python/build \
-	   python/netsnmp_python.egg-info
+	   python/netsnmp_python.egg-info \
+	   dist/generation-scripts/gen-variables \
+	   perl/SNMP/t/snmptest.cmd \
+	   perl/TrapReceiver/const-c.inc \
+	   perl/TrapReceiver/const-xs.inc
 
 override_dh_strip:
 	dh_strip -plibsnmp$(LIB_VERSION) --dbg-package=libsnmp$(LIB_VERSION)-dbg
diff --git a/debian/snmpd.default b/debian/snmpd.default
index e47dec8..f4ee7a7 100644
--- a/debian/snmpd.default
+++ b/debian/snmpd.default
@@ -8,4 +8,4 @@
 SNMPDRUN=yes
 
 # snmpd options (use syslog, close stdin/out/err).
-SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'
+SNMPDOPTS='-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'


signature.asc
Description: Digital signature

Bug#819485: routino: At airports routino often can not find the route.

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 a...@gedanken.org.uk

Hi Andrew,

Roman reported another issue in the Debian Bug Tracking System for
Routino 3.1.1 similar to the issue with the parks, but a different
error. This report concerns airports.

The report is included below and available online:
https://bugs.debian.org/819485

Can you also confirm this issue, and possibly suggest a fix?

On 03/29/2016 02:29 PM, Roman V. Nikolaev wrote:
> Package: routino
> Version: 3.1.1-2
> Severity: normal
> 
> At airports routino often can not find the route. Reproduce:
> 
> 1. Open http://www.routino.org/uk-leaflet/router.html
> 2. Set point "1": -0.44628 E / 51.45842 N
> 3. Set point "2": any. For example: -0.43684 E / 51.45502 N
> 4. Click "Shortest Route"
> 5. Get:
> 
> router --shortest --speed-unclassified=64 --speed-tertiary=80
> --highway-tertiary=70 --highway-track=0 --lon1=-0.44628
> --speed-motorway=112 --speed-primary=96 --speed-track=16 --turns=1
> --highway-ferry=20 --highway-cycleway=0 --property-footroute=45
> --transport=motorcar --highway-primary=90 --highway-unclassified=60
> --speed-cycleway=0 --highway-trunk=100 --property-tunnel=50
> --property-multilane=60 --speed-ferry=10 --highway-service=40
> --speed-service=32 --property-bridge=50 --loop= --length=0
> --lat2=51.45572 --highway-path=0 --speed-residential=48 --lon2=-0.43636
> --highway-motorway=100 --highway-steps=0 --speed-path=0 --width=0
> --oneway=1 --weight=0 --speed-steps=0 --speed-secondary=88 --reverse=
> --highway-residential=50 --property-paved=100 --speed-trunk=96
> --highway-secondary=80 --property-bicycleroute=45 --lat1=51.45842
> --height=0 --dir=routino-data
> 
> Loaded Files: nodes, segments, ways & relations
> Found Closest Point: Waypoint 1
> Waypoint 1 is node 10966453: -0.446248 51.458374 = 0.003 km
> Found Closest Point: Waypoint 2
> Waypoint 2 is segment 13674333 (node 10967217 -> 10967267): -0.436377
> 51.455728 = 0.000 km
> Routing from waypoint 1 to waypoint 2
> Found Start Route: Nodes checked = 4 - Fail
> Error: Cannot find initial section of route compatible with profile.
> 
> Time: 0.000 CPU / 0.016 elapsed
> 
> 
> I see this bug in many airports. I think this may be due to:
> 1. One way. Disable "Obey oneway streets" checkbox. Then the route will
> be found.
> 2. This roads has tag "highway"="service".
> 
> P.S. I try to send bug to upstream author but not get feedback. I hope 
> mainteiners has connection with upstream.
> 
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages routino depends on:
> ii  libbz2-1.01.0.6-7+b3
> ii  libc6 2.19-18+deb8u3
> ii  libroutino-slim0  3.1.1-2
> ii  libroutino0   3.1.1-2
> ii  routino-common3.1.1-2
> ii  zlib1g1:1.2.8.dfsg-2+b1

Kind Regards,

Bas

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

Bug#819505: gtk3-nocsd: dont works in apps launched from mate menu

[Christian Seiler]

Control: tags -1 + moreinfo

On 03/29/2016 09:38 PM, martintxo wrote:
> I installed the gtk3-nocsd and libgtk3-nocsd0 packages from sid in this 
> testing
> box without problems. I read all the docs in the packages, and the upstream 
> web
> page at github. I see that in Debian the packages are intended to work
> automagically.

Yes, that's how it's supposed to work.

> I'm in a little portatil (emachines) with Mate as default DE, and also with
> Xfce and Lxde.
> 
> If I start gnome-disk (as example) from the Mate default aplications menu, it
> starts without modification. But if I start it from any "X terminal" (in my
> case mate-terminal) the gtk3-noscd packages works and the gnome-disk start 
> with
> a nice window bar from the Mate default window manager...

So I've just tried this in a virtual machine (I don't use MATE
myself) and I can't reproduce it.

I have an up to date Stretch VM with MATE here. Selecting
Applications -> Accessories -> Disks
from the menu results in a window with server side decorations (i.e.
the MATE titlebar). Running gnome-disks from the command line (e.g.
via mate-terminal) results in the same window.

What happens if you try to start gedit via the menu?

Could you give me the following output?

dpkg -l gnome-disk-utility gtk3-nocsd libgtk3-nocsd0 mate-desktop-environment

Also, did you attempt to configure gtk3-nocsd yourself to any
extent? If so, how? Or did you _just_ install the package? Did you
re-login after installing gtk3-nocsd?

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#819486: routino: At parks routino often can not find the route.

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 a...@gedanken.org.uk

Hi Andrew,

Roman reported an issue in the Debian Bug Tracking System for Routino
3.1.1 that it often cannot find routes when one of the locations is in a
park.

The report is included below and available online:
https://bugs.debian.org/819486

Can you confirm this issue, and possibly suggest a fix?

On 03/29/2016 02:32 PM, Roman V. Nikolaev wrote:
> Package: routino
> Version: 3.1.1-2
> Severity: normal
>
> Reproduce:
> 
> 1. Open http://www.routino.org/uk-leaflet/router.html
> 2. Set point "1": -0.73458 E / 51.37529 N
> 3. Set point "2": any. For example: -0.06579 E / 51.47898 N
> 4. Click "Shortest Route"
> 5. Get:
> 
> router --shortest --lon2=-0.06579 --speed-steps=0 --highway-ferry=20 
> --highway-primary=90 --highway-service=40 --speed-residential=48 
> --transport=motorcar --property-multilane=60 --speed-secondary=88 
> --speed-service=32 --highway-unclassified=60 --speed-motorway=112 --height=0 
> --highway-steps=0 --property-footroute=45 --speed-ferry=10 
> --highway-cycleway=0 --highway-residential=50 --highway-motorway=100 
> --highway-secondary=80 --speed-path=0 --width=0 --speed-primary=96 
> --lat1=51.37529 --oneway=1 --speed-cycleway=0 --length=0 --turns=1 --weight=0 
> --speed-unclassified=64 --lon1=-0.73458 --property-paved=100 --speed-track=16 
> --lat2=51.47898 --highway-track=0 --property-bridge=50 
> --property-bicycleroute=45 --highway-tertiary=70 --property-tunnel=50 
> --speed-trunk=96 --highway-trunk=100 --speed-tertiary=80 --highway-path=0 
> --reverse= --loop= --dir=routino-data
> 
> Loaded Files: nodes, segments, ways & relations
> Found Closest Point: Waypoint 1
> Error: Cannot find node close to specified point 1.
> 
> Time: 0.000 CPU / 0.011 elapsed
> 
> I see this bug in many parks. I think this may be due to many footways around.
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages routino depends on:
> ii  libbz2-1.01.0.6-7+b3
> ii  libc6 2.19-18+deb8u3
> ii  libroutino-slim0  3.1.1-2
> ii  libroutino0   3.1.1-2
> ii  routino-common3.1.1-2
> ii  zlib1g1:1.2.8.dfsg-2+b1

Kind Regards,

Bas

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

Bug#819510: gnome-terminal: gnome terminal does not open , there is no error message when i try to open gnome-terminal

[Abhishek Suvarna]

Package: gnome-terminal
Version: 3.14.1-1+deb8u1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-terminal depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  gconf-service3.2.6-3
ii  gnome-terminal-data  3.14.1-1+deb8u1
ii  gsettings-desktop-schemas3.14.1-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u3
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libdconf10.22.0-1
ii  libgconf-2-4 3.2.6-3
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
ii  libglib2.0-0 2.42.1-1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libnautilus-extension1a  3.14.1-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libuuid1 2.25.2-6
ii  libvte-2.91-00.38.1-2
ii  libx11-6 2:1.6.2-3

Versions of packages gnome-terminal recommends:
ii  dbus-x11  1.8.20-0+deb8u1
ii  gvfs  1.22.2-1
ii  yelp  3.14.1-1

gnome-terminal suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#819504: mercurial: CVE-2016-3068 CVE-2016-3069 CVE-2016-3630

[Julien Cristau]

Control: found -1 0.6-1

On Tue, Mar 29, 2016 at 21:34:20 +0200, Salvatore Bonaccorso wrote:

> Source: mercurial
> Version: 3.7.2-2
> Severity: grave
> Tags: security upstream fixed-upstream
> 
> Hi,
> 
> the following vulnerabilities were published for mercurial.
> 
> CVE-2016-3068[0]:
> arbitrary code execution with Git subrepos
> 
> CVE-2016-3069[1]:
> arbitrary code execution when converting Git repos
> 
> CVE-2016-3630[2]:
> remote code execution in binary delta decoding
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-3068
> [1] https://security-tracker.debian.org/tracker/CVE-2016-3069
> [2] https://security-tracker.debian.org/tracker/CVE-2016-3630
> [3] 
> https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_3.7.3_.282016-3-29.29
> 
> Please adjust the affected versions in the BTS as needed.
> 
19:25:27 < SpComb> is there a lower bound on old versions affected by 
CVE-2016-3630?
19:25:50 <@mpm> Roughly... 0.6

Javi: I already told Salvatore on IRC, but I should be able to make some
time tomorrow to prepare updates for sid/jessie/wheezy if that would
help; just let me know.

Cheers,
Julien

Bug#819509: lintian: Relax restriction-formula-without-versioned-dpkg-dev-dependency version check

[Felix Geyer]

Package: lintian
Version: 2.5.42.1

Hi,

Please relax the restriction-formula-without-versioned-dpkg-dev-dependency
version check to allow backports.

For example cmake 3.5.0-1 build-depends on dpkg-dev (>= 1.17.14~) but lintian
emits that tag.

Cheers,
Felix

Bug#819329: [Pkg-xfce-devel] Bug#819329: light-locker: Computer locked by frozen screen after sleep

[Yves-Alexis Perez]

control: tag -1 -d-i moreinfo unreproducible

On sam., 2016-03-26 at 20:04 +, Gert N wrote:
> I use light-locker with openbox. The computer becomes unreachable after sleep
> or hibernate; the screen is frozen and the computer locked. Only a hard reboot
> makes the computer available again.
> Remove of light-locker solves the issue. Without light-locker is the computer
> waking up well.

light-locker only shows a locked message on the current vt, and switches to a
login vt. It's quite unlikely to freeze anything, unless you have a problem
with the graphic stack for example.

There's not much we can do here without more information, so please try to
gain remote access to the system, get logs or anything.

Regards,
-- 
Yves-Alexis



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

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Santiago Vila]

On Tue, Mar 29, 2016 at 05:13:51PM +0200, Santiago Ruano Rincón wrote:
>  #!/usr/bin/make -f
>  
> -DEBIAN_VERSION ?= $(shell LANG=C dpkg -l base-files | awk '($$1=="ii"){print 
> $$3}' | cut -d. -f1)
> +DEBIAN_VERSION ?= $(shell LANG=C dpkg -l base-files | awk '($$1=="ii"){print 
> $$3}' | cut -d. -f1 | cut -d+ -f1)

Hello tocayo.

This is not ok (neither the original or the patched version). The fact
that base-files numbering happens to match Debian stable releases
until now is not enough to use its version number to guess Debian
version number.

Please do it right and use /etc/debian_version or /etc/os-release
instead.

Thanks.

Bug#819508: xul-ext-gnome-keyring: Transition from iceweasel to firefox not covered by dependencies

[Hendrik Langer]

Package: xul-ext-gnome-keyring
Version: 0.10-1
Severity: normal

Dear Maintainer,

I just installed the firefox package, purging the old iceweasel package.

xul-ext-gnome-keyring depends on either iceweasel or icedove but not on firefox.
I'm sure this can also be used with firefox so i think this should be added to 
the 'or'-dependency.


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

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

Bug#819507: cloud-init: French debconf templates translation

[Julien Patriarca]

Package: cloud-init
Version: N/A
Severity: wishlist
Tags: patch l10n


Please find attached the french debconf templates translation, proofread by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.



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

Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 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)
# Translation of cloud-init debconf templates to French. 
# Copyright (C) 2013, French l10n team 
# This file is distributed under the same license as the cloud-init package.
# Julien Patriarca , 2013.
# Julien Patriarca , 2016.
msgid ""
msgstr ""
"Project-Id-Version: cloud-init\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-02-25 14:30+\n"
"PO-Revision-Date: 2016-03-03 15:04+0100\n"
"Last-Translator: Julien Patriarca \n"
"Language-Team: FRENCH \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.6.10\n"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "NoCloud: Use /var/lib/cloud/seed"
msgstr "NoCloud : utilisation de /var/lib/cloud/seed"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "ConfigDrive: OpenStack config drive"
msgstr "ConfigDrive : lecteur de configuration d'OpenStack"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "OpenNebula: OpenNebula context disk"
msgstr "OpenNebula : disque de contexte OpenNebula"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "Azure: Microsoft Azure. Requires waagent package!"
msgstr "Azure : Microsoft Azure. Requiert le paquet waagent."

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "AltCloud: RHEVm and vSphere config disks"
msgstr "AltCloud : disques de configuration de RHEVm et vSphere"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "OVF: OVF transports"
msgstr "OVF : transports pour les images OVF"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "MAAS: Ubuntu MAAS"
msgstr "MAAS : Ubuntu MAAS"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "GCE: Google Compute metadata service"
msgstr "GCE : service de métadonnées pour Google Compute"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "OpenStack: Native OpenStack metadata service"
msgstr "OpenStack : service de métadonnées natif pour OpenStack"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "CloudSigma: Metadata over serial for cloudsigma.com"
msgstr "CloudSigma : métadonnées par le port série pour cloudsigma.com"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "SmartOS: SmartOS metadata service"
msgstr "SmartOS : service de métadonnées pour SmartOS"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "Ec2: EC2 Metadata service"
msgstr "Ec2 : service de métadonnées pour EC2"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "CloudStack: CloudStack metadata service"
msgstr "CloudStack : service de métadonnées pour CloudStack"

#. Type: multiselect
#. Choices
#: ../cloud-init.templates:1001
msgid "None: Fallback"
msgstr "Aucun : repli"

#. Type: multiselect
#. Description
#: ../cloud-init.templates:1002
msgid "Data sources to read from:"
msgstr "Sources des données à lire :"

#. Type: multiselect
#. Description
#: ../cloud-init.templates:1002
msgid ""
"Cloud-init supports searching different \"Data Sources\" for information "
"that it uses to configure a cloud instance."
msgstr ""
"Cloud-init gère la recherche de différentes « sources de données » pour "
"configurer une instance dans le nuage."

#. Type: multiselect
#. Description
#: ../cloud-init.templates:1002
msgid ""
"Please note that \"EC2 Metadata service\" should be used only if the EC2 "
"metadata service is present. Otherwise, it will trigger a very noticeable "
"timeout on boot."
msgstr ""
"Veuillez noter que l'option « Service de métadonnées pour EC2 » ne devrait "
"être choisie que si ce service est présent. Dans le cas contraire, une "
"longue pause se manifestera lors du démarrage."

#~ msgid "AltCloud Config Drive"
#~ msgstr "Lecteur de configuration pour AltCloud"

#~ msgid "Google Cloud Engine"
#~ msgstr "Moteur de Cloud Google"

#~ msgid "Failsafe datasource"
#~ msgstr "Source de données de secours"

Bug#819506: Keep TEXTREL objdump info

[Dan Nicholson]

Package: lintian
Version: 2.5.42.1

The shared-libs-non-pic-i386 test fails on i386 because the objdump
helper no longer keeps the TEXTREL info from the dynamic section.
Attached patch fixes it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless
The i386 non-pic test needs to see if TEXTREL is in the dynamic section,
so keep that.

diff -Nru lintian-2.5.42.1/helpers/coll/objdump-info-helper lintian-2.5.42.1endless1/helpers/coll/objdump-info-helper
--- lintian-2.5.42.1/helpers/coll/objdump-info-helper	2016-02-08 12:50:20.0 -0800
+++ lintian-2.5.42.1endless1/helpers/coll/objdump-info-helper	2016-03-29 12:11:22.0 -0700
@@ -168,6 +168,8 @@
 $value =~ s/.*\[//;
 $value =~ s/\]\s*$//;
 $keep = 1;
+} elsif ($type eq 'TEXTREL') {
+$keep = 1;
 }
 $keep = 1
   if $value =~ s/^(?:Shared library|Library soname): \[(.*)\]/$1/;

Bug#819505: gtk3-nocsd: dont works in apps launched from mate menu

[martintxo]

Package: gtk3-nocsd
Version: 2-1
Severity: normal

Dear Maintainer,

I installed the gtk3-nocsd and libgtk3-nocsd0 packages from sid in this testing
box without problems. I read all the docs in the packages, and the upstream web
page at github. I see that in Debian the packages are intended to work
automagically.

I'm in a little portatil (emachines) with Mate as default DE, and also with
Xfce and Lxde.

If I start gnome-disk (as example) from the Mate default aplications menu, it
starts without modification. But if I start it from any "X terminal" (in my
case mate-terminal) the gtk3-noscd packages works and the gnome-disk start with
a nice window bar from the Mate default window manager...

In the other DE (current in testing xfce4 and lxde) the packages works as
expected from the menus and from any xterminal...

This is the output from my env command:

$ env
XDG_VTNR=2
MATE_DESKTOP_SESSION_ID=this-is-deprecated
SSH_AGENT_PID=1608
XDG_SESSION_ID=1
TERM=xterm
SHELL=/bin/bash
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
LD_PRELOAD=libgtk3-nocsd.so.0
WINDOWID=35651614
LC_ALL=eu_ES.UTF-8
USER=martintxo
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.
 
qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
QT_ACCESSIBILITY=1
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
SESSION_MANAGER=local/debian:@/tmp/.ICE-unix/1563,unix/debian:/tmp/.ICE-
unix/1563
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAIL=/var/mail/martintxo
PWD=/home/martintxo
LANG=eu_ES.UTF-8
XDG_SEAT=seat0
HOME=/home/martintxo
SHLVL=1
LANGUAGE=eu_ES:eu:es_ES:es:en_US:en
GTK_OVERLAY_SCROLLING=0
LOGNAME=martintxo
XDG_DATA_DIRS=/usr/share/mate:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-
hqPKjcflEt,guid=b3e6577106a3f58a7f6f511656fad1b1
GTK_CSD=0
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=:0.0
XDG_CURRENT_DESKTOP=MATE
COLORTERM=mate-terminal
XAUTHORITY=/home/martintxo/.Xauthority
_=/usr/bin/env

As you can see, there are some references to gtk3-nocsd. I can get the same
output from xfce and lxde (well, it's seems to be similar).

That's all. Many thanks for you work. Greetings. Martintxo.



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

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

Versions of packages gtk3-nocsd depends on:
ii  libgtk3-nocsd0  2-1

gtk3-nocsd recommends no packages.

gtk3-nocsd suggests no packages.

-- no debconf information

Bug#440673: nikwi - FTBFS: error: #error makeit

[James Cowgill]

On Tue, 2016-03-29 at 18:36 +0200, Markus Koschany wrote:
> Am 29.03.2016 um 11:49 schrieb James Cowgill:
> > Control: tags -1 patch
> > 
> > Hi,
> > 
> > I had a go at fixing all the big endian issues. Things seem to work OK.
> > I couldn't test the sound since the machine I was using has no sound
> > card, but it doesn't crash!
> > 
> Cool. I can't test your patch but if it works for you just go ahead and
> upload a new revision.

Ok. I've uploaded it!

James

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

Bug#819504: mercurial: CVE-2016-3068 CVE-2016-3069 CVE-2016-3630

[Salvatore Bonaccorso]

Source: mercurial
Version: 3.7.2-2
Severity: grave
Tags: security upstream fixed-upstream

Hi,

the following vulnerabilities were published for mercurial.

CVE-2016-3068[0]:
arbitrary code execution with Git subrepos

CVE-2016-3069[1]:
arbitrary code execution when converting Git repos

CVE-2016-3630[2]:
remote code execution in binary delta decoding

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-3068
[1] https://security-tracker.debian.org/tracker/CVE-2016-3069
[2] https://security-tracker.debian.org/tracker/CVE-2016-3630
[3] https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_3.7.3_.282016-3-29.29

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#819291: pitivi: 0.95-1+b1 segfaults against gtk+3.0 3.20

[Marc J. Driftmeyer]

Downloaded the latest executable from Pitivi, 
pitivi-0.95-x86_64-2016-03-26_0816, and it loads just fine.


- Marc

On 03/27/2016 01:40 AM, Sebastian Dröge wrote:

On Sa, 2016-03-26 at 17:42 -0700, Marc J. Driftmeyer wrote:

I unfortunately had not tested Pitivi of late. I'll see if I can run
a debug set up and get back to you.

Thanks! For me pitivi still runs fine with the latest versions of
everything.


--

Marc J. Driftmeyer

main: m...@reanimality.com 
book: m...@holoworlds.net 
main:www.reanimastudios.com 
book:www.holoworlds.net 

Bug#819250: minidlna: Poor handling of inotify limits

[Mark Brown]

On Sun, Mar 27, 2016 at 08:09:33PM +0300, Alexander Gerasiov wrote:

> 1. I don't think the reason of crash is someway linked to inotify. But
> this doesn't matter because of 2.

I am seeing other crashes due to Linn Kazoo which I need to report
properly (and would expect to be fixed in stable) but this is happening
separately to that with no client software on the network.

> 2. I believe the problem is fixed in current testing version. Please
> try 1.1.5 from testing or backports and report if crash persists.

Are you sure this isn't serious enough to be fixed in stable?  The
number of directories it's failing on is relatively low...


signature.asc
Description: PGP signature

Bug#819499: wheezy-pu: package optipng/0.6.4-1

[Markus Koschany]

Am 29.03.2016 um 20:52 schrieb Adam D. Barratt:
> Control; tags -1 + confirmed
> 
> On Tue, 2016-03-29 at 19:16 +0200, Markus Koschany wrote:
>> I have prepared a security update for optipng in wheezy to address
>> CVE-2015-7801. I have contacted the security team but they don't think
>> this issue warrants a DSA. Please find attached the debdiff.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Thank you. I have uploaded the package a few minutes ago.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#616654: p.d.o: untranslatable top menu

[Frank Lichtenheld]

On Wed, 08 Apr 2015 01:28:12 +0200 Laura Arjona Reina
 wrote:
> Dear all
> I'm not sure about the status of this bug...
>
> https://packages.debian.org/en/wheezy/ for example, shows that the page
> is available in several other languages, but when I click on them (for
> example https://packages.debian.org/fr/wheezy/ ), I still see the page
> in English.
>
> I've reviewed
> https://anonscm.debian.org/cgit/webwml/packages.git/tree/templates/html/head.tmpl
> and I cannot see the lines corresponding to the titles, nor translatable
> nor untranslatable.
>
> OTOH, I'm Spanish translator and the Spanish language is not shown in
> the list of available languages. I would like to provide translations to
> fix that, but I'm not sure how to proceed, where are the current
> templates, in which branch should I commit...

FTR, the correct solution was to merge all the translation relevant
changes to master which I did now.

debian-master was really only intended for debian deployment related
changes that are not relevant for people hosting their own instance.

Will apply the patch to master.

Regards,
-- 
Frank Lichtenheld 

Bug#819503: --buffer-size does not affect read buffer size

[Antoine Beaupré]

Package: pv
Version: 1.5.7-2
Severity: normal

It looks like --buffer-size does not do what I would have expected:

$ strace -e read pv -B 4096 /etc/motd > /dev/null
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 
832) = 832
read(3, "# Locale name alias data base.\n#"..., 4096) = 2492
read(3, "", 4096)   = 0
read(3, "\nThe programs included with the "..., 131072) = 286
read(3, "", 130786) = 0
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\5\0\0\0\0\0\0"..., 
832) = 832
 286 O 0:00:00 [59,5KiB/s] 
[===>]
 100%
+++ exited with 0 +++

I would have expected --buffer-size to change the size of the read()
system call as well as the internal buffer size. In fact, I am not
sure I understand what --buffer-size does at all. :)

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

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

Versions of packages pv depends on:
ii  libc6  2.19-18+deb8u4

pv recommends no packages.

Versions of packages pv suggests:
ii  doc-base  0.10.6

-- no debconf information

Bug#818502: backport?

[Chad William Seys]

It would make things easier if this patch were backported to Jessie, rather 
than having to use a backported kernel.

Nice sleuthing Zito!

C.

Bug#507682: Adjustable averaging window for rate display

[anarcat]

Control: fixed -1 1.2.0-1

Hi,

You may like to know this is now a feature in pv 1.2.0.

Sorry for the (very) delayed response - I actually had a confirmation of
this from upstream in 2014 but forgot to document it here.

A.

On Wed, Dec 03, 2008 at 10:40:33AM -0500, Anthony DeRobertis wrote:
> Package: pv
> Version: 1.1.4-1
> Severity: wishlist
> File: /usr/bin/pv
> 
> It appears that pv always averages the transfer rate over the display
> interval. It'd be nice if that could be controlled seperately. Right
> now, if you have very bursty data (for example, lzcat receiving
> compressed data from the network, writing uncompressed to disk), you
> have to use a very long update interval, on the order of a minute, to
> get a reasonable rate estimate. It'd be nice to keep the 1s update
> interval, but take the average over a longer period.
> 
> It'd be awesome if pv recognized bursty data and adjusted the averaging
> itself, but that's way more than I expect.
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (100, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages pv depends on:
> ii  libc6 2.7-16 GNU C Library: Shared libraries
> 
> pv recommends no packages.
> 
> Versions of packages pv suggests:
> ii  doc-base  0.8.16 utilities to manage online 
> documen
> 
> -- no debconf information
> 
> 

-- 
Education is the most powerful weapon which we can use to change the
world.
   - Nelson Mandela


signature.asc
Description: Digital signature

Bug#819502: ITP: impressive-display -- Impressive based PDF display

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: impressive-display
  Version : 0.2.1
  Upstream Author : Mike Gabriel 
* URL : https://code.it-zukunft-schule.de/cgit/impressive-display/
* License : GPL
  Programming Lang: Bash
  Description : Impressive based PDF display

 Provide an X11 session manager script that launches a minimal window
 manager and then launches the impressive PDF viewer in fullscreen
 mode.
 .
 In combination with the nodm display manager you can provide an
 easy-to-setup display screen based on regulary updated PDF files.
 .
 The viewed PDF file can be obtained from a given URL in regular
 intervals. Alternatively (or for testing purposes) you can also
 display a local static PDF file.

Bug#819499: wheezy-pu: package optipng/0.6.4-1

[Adam D. Barratt]

Control; tags -1 + confirmed

On Tue, 2016-03-29 at 19:16 +0200, Markus Koschany wrote:
> I have prepared a security update for optipng in wheezy to address
> CVE-2015-7801. I have contacted the security team but they don't think
> this issue warrants a DSA. Please find attached the debdiff.

Please go ahead.

Regards,

Adam

Bug#819501: apparmor abstraction nameservice should include /run/NetworkManager/resolv.conf

[Julian Andres Klode]

Package: apparmor-profiles
Version: 2.10-3
Severity: normal

On systems where NetworkManager automatically starts dnsmasq, it also controls
resolv.conf itself, and the resolv.conf file is linked to 
/run/NetworkManager/resolv.conf

ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 35 Mar 29 20:36 /etc/resolv.conf -> 
/var/run/NetworkManager/resolv.conf

So:
/{,var/}run/NetworkManager/resolv.conf r,

should be added to the nameservices abstraction.

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

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.10-3+b1

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:
/etc/apparmor.d/bin.ping changed [not included]
/etc/apparmor.d/usr.sbin.avahi-daemon changed [not included]
/etc/apparmor.d/usr.sbin.dnsmasq changed [not included]
/etc/apparmor.d/usr.sbin.smbd changed [not included]

-- no debconf information

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Moritz Mühlenhoff]

On Tue, Mar 29, 2016 at 05:13:51PM +0200, Santiago Ruano Rincón wrote:
> Source: debian-security-support
> Version: 2015.04.04
> Severity: serious
> Tags: -1 + patch
> Justification: Fails to build from source
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> A jessie pbuilder fails to build debian-security-support. debian/rules
> wrongly defines the debian version number, e.g. 8+deb8u3 instead of 8,
> so the install rule attempts to copy a nonexistent file.

Feel free to make code changes in collab-maint along with an upload
to unstable.

We'll fix that in jessie with the next upload deprecating a package
(at least the EOL for mediawiki 1.19 is forthcoming).

Cheers,
Moritz

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Camm Maguire]

Greetings!

Santiago Vila  writes:

> Ok, tried today with the old configuration (5GB RAM + 2GB swap) using
> a swap file.
>
> The above change does not fix the build.
>

Thanks!  In the built tree in this setup, could you please

$ ls -l src/binary-gcl/maxima

$ ./maxima-local
(%i1) to_lisp();
MAXIMA> (length si::*code-block-reserve*)
MAXIMA> (si::contiguous-report nil)
MAXIMA> (setq *load-verbose* t)
MAXIMA> (compile nil '(lambda nil nil))

> Could you please try on a machine with 5GB of RAM + 2 GB of swap?
> (If you are not used to virtual machines, try virt-manager, it works great).

I have a laptop and access to the debian build machines via ssh.  I've
installed virt-manager and looked at it briefly, but it appears to
require root and or console access.  I've got 4Gb on my laptop.

>
> In the meantime, I would suggest setting GCL_MEM_MULTIPLE=0.5
> somewhere in debian/rules. I have the feeling that the upstream
> default of 1.0 is not a good one.
>

This should be harmless enough, but I suspect that the cure is
accidental, i.e. the failure lies not in running out of memory but in
placing code above the 2Gb limit.

Thanks for your help in debugging this.

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.

[beagleburt]

Package: general
Severity: normal

Dear Maintainer,

* CLI command "shutdown -r now" USUALLY does not work, since systemd replaced
sysvinit in Debian 8 "jessie".
Posted problem on http://www.linuxquestions.org/questions/debian-26/used-to-
shutdown-reboot-from-cli-but-since-systemd-replaced-init-shutdown-cmnd-
broke-4175575779/ got advice to try commmand "init 6". When I try it, I USUALLY
arrive - eventually - at a console login that reports errors - but amongst the
confusing information are the username & password IN PLAIN TEXT! I also had a
single occurrence of my root password split over two lines also in plain text!
Basically the reboot & shutdown commands from the CLI are REALLY buggy!

Another respondent to my query on LQ.org suggested using: "systemctl reboot"
this resulted eventually in poweroff/shutdown.

The MOST annoying part of this bug is its variability: OCCASSIONALLY the
commands work ok! But USUALLY not! Also SOMETIMES on booting-up again after an
unwanted forced-shutdown, the machine powers off without warning USUALLY before
the graphical Login appears & ONCE after an apparently successful login?



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

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

Bug#819499: wheezy-pu: package optipng/0.6.4-1

[Markus Koschany]

More information:

The initial report for CVE-2015-7801 on seclists.org can be found at

http://seclists.org/oss-sec/2015/q3/556

The reproducer can be downloaded from RedHat's bug tracker:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-7801

Markus



signature.asc
Description: OpenPGP digital signature

Bug#819499: wheezy-pu: package optipng/0.6.4-1

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hello,

I have prepared a security update for optipng in wheezy to address
CVE-2015-7801. I have contacted the security team but they don't think
this issue warrants a DSA. Please find attached the debdiff.

Regards,

Markus
diff -Nru optipng-0.6.4/debian/changelog optipng-0.6.4/debian/changelog
--- optipng-0.6.4/debian/changelog	2010-03-17 16:26:21.0 +0100
+++ optipng-0.6.4/debian/changelog	2016-03-28 23:41:09.0 +0200
@@ -1,3 +1,12 @@
+optipng (0.6.4-1+deb7u1) wheezy; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2015-7801:
+Use-after-free vulnerability in optipng 0.6.4 is causing an invalid/double
+free.
+
+ -- Markus Koschany   Mon, 28 Mar 2016 23:15:19 +0200
+
 optipng (0.6.4-1) unstable; urgency=low
 
   * New upstream release;
diff -Nru optipng-0.6.4/debian/patches/CVE-2015-7801.patch optipng-0.6.4/debian/patches/CVE-2015-7801.patch
--- optipng-0.6.4/debian/patches/CVE-2015-7801.patch	1970-01-01 01:00:00.0 +0100
+++ optipng-0.6.4/debian/patches/CVE-2015-7801.patch	2016-03-28 23:41:09.0 +0200
@@ -0,0 +1,34 @@
+From: Markus Koschany 
+Date: Mon, 28 Mar 2016 23:13:51 +0200
+Subject: CVE-2015-7801
+
+Fix Use-after-free vulnerability in optipng 0.6.4 is causing an invalid/double
+free.
+---
+ src/opngoptim.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/opngoptim.c b/src/opngoptim.c
+index aab5580..cf55ed6 100644
+--- a/src/opngoptim.c
 b/src/opngoptim.c
+@@ -1877,7 +1877,7 @@ opng_initialize(const struct opng_options *init_options,
+ int
+ opng_optimize(const char *infile_name)
+ {
+-   const char *err_msg;
++   const char *err_msg = "";
+volatile int result;  /* needs not be volatile, but keeps compilers happy */
+ 
+OPNG_ENSURE(engine.started, "The OptiPNG engine is not running");
+@@ -1906,7 +1906,9 @@ opng_optimize(const char *infile_name)
+   opng_print_error(err_msg);
+   result = -1;
+}
+-   opng_destroy_image_info();
++   // Don't attempt to free if libpng is confused
++   if (strcmp(err_msg, "Inconsistent data in libpng"))
++   opng_destroy_image_info();
+usr_printf("\n");
+return result;
+ }
diff -Nru optipng-0.6.4/debian/patches/series optipng-0.6.4/debian/patches/series
--- optipng-0.6.4/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ optipng-0.6.4/debian/patches/series	2016-03-28 23:41:09.0 +0200
@@ -0,0 +1 @@
+CVE-2015-7801.patch

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[GCS]

Hi Julian,

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
 wrote:
> On 20.03.2016 11:11, László Böszörményi (GCS) wrote:
>>  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
>> new upstream version of pyzmq (15.2) for two months. It seems to be
>> security related according to the release log[1]:
>> - FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
>> - workaround overflow bug in libzmq preventing receiving messages
>> larger than MAX_INT
[...]
> The latest version does unfortunately not fix the problem. It is also
> not security related, it just could not send large data due to bugs in zmq.
> I guess a good approach would be to bisect zmq to see what they changed
> to cause it.
 Just a friendly ping; could you test the latest Git master if that
fixes the hang and/or could you ask upstream for advice? Should I do
it? It seems it constantly get fixes that may be relevant.

Cheers,
Laszlo/GCS

Bug#819498: /etc/resolvconf/update.d/resolvconf-update-bind called without CAP_CHOWN from n-m

[Marc Haber]

Package: resolvconf
Version: 1.78
Severity: normal

Hi,

on a system with network-manager and systemd as PID 1,
/etc/resolvconf/update.d/resolvconf-update-bind gets called without
CAP_CHOWN due to CapabilityBoundingSet in
/lib/systemd/system/network-managaer.service. This causes the script
to fail when it tries to chown root:bind named.options_new.$PID,
resulting in a non-updated named.options.

This can either be fixed by asking n-m to ad CAP_CHOWN to the
CapabilityBoundingSet of Network-Manager, to drop a supplement in
/etc/systemd/system/network-manager.service.d/resolconf-cap
(unfriendly), to ask bind to make /var/run/bind sgid bind, or to fix
the script to not chown the file in the first place.

I have fixed the issue locally by removing the chown file from the
script with no noticed negative effect, but I don't know which corner
cases might be here. So I'd like to ask the package maintainer to
choose whatever is appropriate.

Since using a locally installed bind on a system that has its network
managed with Network-Manager is a rather uncommon setup, I have filed
this bug as "normal" only, but would like to suggest this to be
addressed anyway.

Greetings
Marc


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

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

Versions of packages resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  ifupdown   0.8.10
ii  init-system-helpers1.29
ii  initscripts2.88dsf-59.3
ii  lsb-base   9.20160110

resolvconf recommends no packages.

resolvconf suggests no packages.

-- debconf information excluded

Bug#819482: exim4-config: spelling mistakes

[Andreas Metzler]

Control: tags -1 pending

On 2016-03-29 Vincent Lefevre  wrote:
> Package: exim4-config
> Version: 4.87~RC6-3
> Severity: minor

> There are various spelling mistakes in the exim4 source, in particular
> affecting the config files (exim4.conf.template), but some of these
> mistakes also appear in the .c source files. Here are the changes to
> do (several times):

>   messsage -> message
>   seldomly -> seldom
>   targetted -> targeted
>   receved -> received
>   particularily -> particularly

Thank you, I have fixed the Debian specific issues in GIT and have
forwarded the rest upstream.

https://lists.exim.org/lurker/message/20160329.170230.977561a9.en.html

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

Bug#780628: parcimonie: support gpg2

[intrigeri]

Hi,

Daniel Kahn Gillmor wrote (25 Sep 2015 04:40:22 GMT) :
> the usual way to deal with this is just to update the dirmngr config
> file to have the parameters you want.

> You can even do that programmatically with gpgconf, for example:
> [...]
> see gpgconf(1) for more details.  you may also be interested in the
> --runtime flag.

Thanks, I didn't know about gpgconf. Indeed we can do:

  echo 'use-tor:0:1' | gpgconf --change-options dirmngr

However, it seems that --runtime won't work here: even if I pass that
option to "gpgconf --change-options", dirmngr won't start using Tor
immediately. dirmngr will start using Tor if I kill it (and then I get
a fresh new dirmngr on next request), or if I run "gpgconf --reload
dirmngr".

So we need to do something like:

  echo 'use-tor:0:1' | gpgconf --change-options dirmngr && \
  gpgconf --reload dirmngr

... on parcimonie startup, if we detect that we're using gpg2, and
dirmngr has not been configured correctly yet.

Cheers,
--
intrigeri

Bug#440673: nikwi - FTBFS: error: #error makeit

[Markus Koschany]

Am 29.03.2016 um 11:49 schrieb James Cowgill:
> Control: tags -1 patch
> 
> Hi,
> 
> I had a go at fixing all the big endian issues. Things seem to work OK.
> I couldn't test the sound since the machine I was using has no sound
> card, but it doesn't crash!
> 

Cool. I can't test your patch but if it works for you just go ahead and
upload a new revision.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#800894: [pkg-gnupg-maint] Bug#800894: please add support for reaching out to keyservers through Tor

[intrigeri]

Hi,

intrigeri wrote (29 Dec 2015 09:50:02 GMT) :
> [...] Given your clarification above, I would remove the warning sentence
> about DNS leaks.

I think the confusing (to me) manpage problem can be handled
separately, and then this bug report can be closed as we have
"use-tor". I'll let the Debian maintainers make the call.

Cheers!
--
intrigeri

Bug#819497: network-manager: networkmanager cannot find arping even when its, installed

[Alexander Schier]

Package: network-manager
Version: 0.9.10.0-7
Severity: normal

Dear Maintainer,

network-manager cannot find arping:
Mar 29 17:49:01 neptune NetworkManager[873]:  Could not send ARP
for local address x.x.x.x: Child process »/usr/bin/arping« could not run
(File or Directory not found)

The problem is, that the arping binary lies in /usr/sbin and not in
/usr/bin (maybe difference between arping and iputils-arping package?).

with kind regards,
Alexander Schier

Bug#808626: boost1.58: ships empty binary packages on some archs

[Wookey]

"Steve M. Robbins" 
> On December 28, 2015 11:38:38 AM Graham Inggs wrote:
> > On 28 December 2015 at 08:19, Steve M. Robbins  wrote:
> > > I understand that the lack of Boost.Context support for certain
> > > architectures will cause software using Boost.Context to fail to build on
> > > those architectures.
> > >
> > > I don't follow how the empty binary package is involved in the FTBFS.
> >
> > If the package build-depends on libboost-context-dev, it makes the
> > difference between 'Build-Attempted' and 'BD-Uninstallable'.

> Yes, true.  For me, the distinction isn't important.  But I appreciate that 
> others might find it useful.

This is quite important and is giving people real grief on
arm64. ("Build-dep is not available" is a great deal more obvious than
a mysterious message about a missing header, which a diligent
maintainer will eventually be able to track back to this bug after
maybe an hour of poking and prodding and searching the interwebs).

Do you have a schedule for uploading a version of 1.58 with this patch
applied, and/or uploading a 1.59 which would make this issue go away,
at least for arm64. Is there anything we can do to help? (I guess a
report saying that the patch was tested working on arm64 would be
helpful).

I see that the last upload migrated to testing only at the weekend, so
I guess you were waiting for that to happen before uploading anew.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#819496: clipit clipboard history is *world* readable

[Imran Hussain]

Package: clipit
Version: 1.4.2-1

Description of problem:
This clipboard manager stores history in a file in the users homedir, 
~/.local/share/clipit/history however the permission on this file are 
defaulted to 644 (-rw-r--r--), which means anyone on the machine can 
read a users clipboard history.


If people are using password managers where it involves you copying a 
password temporarily then this causes a huge security risk.



How reproducible:
Steps to Reproduce:
1. apt-get install clipit
2. Enable it and use it
3. Copy a password
4. Log in as another user
5. # strings ~foo/.local/share/clipit/history

Actual results:
Their clipboard history.

Expected results:
strings: /home/foo/.local/share/clipit/history: Permission denied


Additional info:
This is horrific in environments where there are multiple users.

Tested on: Debian Jessie (8.3)

--
Imran Hussain
https://sucs.org

Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash

[Daniel Beyer]

Hi Mattia,

Am Montag, den 28.03.2016, 21:44 + schrieb Mattia Rizzolo:
> Hi Daniel :)
> 
> On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote:
> (...)
> 
> I think your apache snippet is cool, actually.
> I improved it a bit the thing, by moving it to be a config snippet,
> instead of being treated as a virtualhost, and by using dh_apache2
> instead of manually try (and fail, e.g. you forgot to remove the thing
> when removing the package) to get it right :)
> 

The infrastructure I needed letsencrypt.sh for enables the proxy module
in a virtualhost, rather doing it the debian-"mods-enabled"-way. That's
why it was a virtualhost (it had to be loaded at the very end to work).
But this is a rather uncommon setup and providing a config snippet is
definitely the way to go here. Thanks for changing it and switching to
dh_apache2.


>> (...)
> > Let me know if you think we can base our work on what I've done so far,
> > or if we instead should make a fresh start.
> 
> See this:
> https://anonscm.debian.org/git/letsencrypt/letsencrypt.sh.git/
> I updatd it to the released version.  I kind of changed a bit the git
> repository layout (using debian/master instead of debian/experimental,
> and using master (following the upstream one) instead of
> upstream/experimental.  README.source is not really the thing I followed
> to import the new source, but as I did a lot of stuff while updating the
> thing I think we'll need the next release to see what we actually need
> to do to import a new upstream (also, I'm not really a gbp master, I
> committed the pristine-tar info manually with `pristine-tar commit...`)
> 

Great this is will be maintained within Debian's letsencrypt-devel. I
just closed the old packaging repository on GitHub in favor of the new
one at anonscm.d.o.

I'm fine with the changed repository layout, meaning the primary
packaging work will be done in debian/master. I updated d/gbp.conf
accordingly, as well as README.source. As already mentioned in private
to you, I implemented 'When upstream uses Git/No upstream tarballs' [1]
here.
>From my understanding we do not need to track upstream changes in a
branch at all, since gbp defaults to '--git-upstream-tree=TAG'. Thus we
most likely can drop the branch 'upstream/master' from the Debian
packaging repo - hence I'm not 100% sure about that.

[1] 
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL


> I did a buch of other changes, that you may agree or not, please have a
> look and comment on them; I'm quite open, if you don't like some commits
> I can happily accept to see them reverted (some/most of them, some other
> I definitely want to see them keep)
> 

I'm fine with them ;)


> You should have commit access on it, so feel free to just push stuff and
> at most we can discuss it later.
> 

I've pushed some commits to debian/master, you might want to have a look
at them.


> I've already installed the resulting .deb on one of my servers, but I
> have to admit that I already have some infrastructure around LE, so I
> won't use the packaged configuration, nor the apache snippet by myself
> (at least not yet).
> 

I have quite some infrastructure that I would like to use it for. I
check if I can migrate one candidate to fully make use of the packaging
later this week.


> Something I need help/suggestion for: I quite dislike the name
> letsencrypt.sh-challenge-response-apache2, I find it way too long :\
> Can we think of something more nice? :)
> 

Yeah, you're right - pretty unhandy. I renamed it to simply
letsencrypt.sh-apache2 in debian/master - but feel free to propose an
other name.


I would like to see the following features added to the packaging:
- Ship some automatism, so the renews do not need to be done manually
- Add ngnix support (similar to the apache2 one)

Besides that, it would be wise to deny execution by user root per
default, but this should better be implemented upstream. I'll try to
work on this later this week - or more likely on the weekend.


Greetings
Daniel

Bug#819495: [src:linux] linux-image-4.4.0-1-amd64: snd-ice1712.ko is missing, causes no sound with some M-AUDIO boards

[Roger Shimizu]

Control: forcemerge 814855 -1

Bug#800036: ledgersmb: failing to install

[Robert James Clay]

Control: severity -1 serious

On Friday, September 25, 2015 02:19:29 PM Henning Follmann wrote:
> Package: ledgersmb
> Severity: normal

   I'd thought I'd already updated that, as it affects the installation the 
package...

   Currently testing a new package (for v1.3.47-1) intended to resolve this.

> > There are also a few other mistakes.
> > The initial apache2 install does not enable "RewriteEngine", so the
> > configuration of ledgersmb.conf will cause apache2 to not restart
> > properly.
> >  
>   Those also have been resolved in later package versions.

   Or so I thought but that same issue regarding the  "RewriteEngine" has 
still been found in v1.3.46-1 [1] so it wasn't entirely resolved yet.






RJ Clay
j...@rocasa.us
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819481

Bug#819495: [src:linux] linux-image-4.4.0-1-amd64: snd-ice1712.ko is missing, causes no sound with some M-AUDIO boards

[Suso Baco]

Package: src:linux
Severity: grave

Confirmed, I have the same error in the kernel as 4.4.0-1-rt-amd64.


--- System information. ---
Architecture: amd64
Kernel: Linux 4.4.0-1-rt-amd64

Debian Release: stretch/sid
990 testing supertux.lethargik.org
990 testing security.debian.org
990 testing ftp.es.debian.org
500 vivid ppa.launchpad.net
500 trusty ppa.launchpad.net
500 testing-updates ftp.debian.org
500 precise ppa.launchpad.net
500 nightly pkg.tox.chat
500 karmic ppa.launchpad.net
50 unstable download.jitsi.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

--
Suso Comesaña.
Peatón crispado en busca de la libertad.
SIP: susocomesa...@iptel.org
Jabber: susocomesa...@dukgo.com
Tox ID:
Sígueme, si quieres, en https://friendika.me4.it/profile/susocomesanha

Bug#819494: virt-manager: Missing dependency to python-requests

[Esteban Monge]

Package: virt-manager
Version: 1:1.3.2-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
When updated virt-manager from 1.2 to 1.3.2 I start to receive this message:
$ virt-manager
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager", line 34, in 
from virtinst import util as util
  File "/usr/share/virt-manager/virtinst/__init__.py", line 87, in 
from virtinst.distroinstaller import DistroInstaller
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 26, in 
from . import urlfetcher
  File "/usr/share/virt-manager/virtinst/urlfetcher.py", line 27, in 
import requests
ImportError: No module named requests

I installed python-requests packages and resolved the problem.


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


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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.18.9-1
ii  gir1.2-gtk-vnc-2.0   0.5.3-1.3+b1
ii  gir1.2-libosinfo-1.0 0.2.12-2
ii  gir1.2-libvirt-glib-1.0  0.2.3-2
ii  gir1.2-vte-2.91  0.44.0-1
ii  librsvg2-common  2.40.13-3
ii  python-dbus  1.2.4-1
ii  python-gi3.18.2-2+b1
ii  python-gi-cairo  3.18.2-2+b1
ii  python-libvirt   1.3.1-1+b1
ii  python-urlgrabber3.9.1-4.2
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.3.2-2

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.30-1
ii  gnome-icon-theme 3.12.0-1
ii  libvirt-daemon-system1.3.1-2

Versions of packages virt-manager suggests:
ii  gnome-keyring3.18.3-1
pn  python-gnomekeyring  
pn  python-guestfs   
pn  ssh-askpass  
ii  virt-viewer  1.0-1

-- no debconf information

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Santiago Ruano Rincón]

Source: debian-security-support
Version: 2015.04.04
Severity: serious
Tags: -1 + patch
Justification: Fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

A jessie pbuilder fails to build debian-security-support. debian/rules
wrongly defines the debian version number, e.g. 8+deb8u3 instead of 8,
so the install rule attempts to copy a nonexistent file.

...
make[1]: Leaving directory '/build/debian-security-support-2015.04.04'
   debian/rules override_dh_install
make[1]: Entering directory '/build/debian-security-support-2015.04.04'
mkdir -p debian/debian-security-support/usr/share/debian-security-support/
cp security-support-ended.deb8+deb8u3 
debian/debian-security-support/usr/share/debian-security-support/security-support-ended
cp: cannot stat 'security-support-ended.deb8+deb8u3': No such file or directory
debian/rules:26: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 1
...

The attached simple patch fixes this.

Cheers,

Santiago

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW+pupAAoJEN5v/bjI1ki9DhQP/0qliFz2gR46N339dCVigOtb
4+Q5OXpCgKcuGnN9swyK/vDSQI6Thd6U3ot2og1e3TC+MyJRjWb7nJVv+4G7UZO9
7VT0MhLzKrRkF6nAbh5AMAmCJZ2X3CtEte/kWtwp4bKNm5NnXdZML0jgIcdLwWUq
2m0N3hI74RtiDhwa71jFq8g6aibLBlfy3DbtKu8pHb60NFLhOffMDBxDeMZVoixv
/bYxpjjP20UmhRSBQTDxd9eY6EXB1Z6ENcbypknNhhA92P5t6Kl4hig0SrclBORd
u+aPxIOaTy+PgK5yV/BMK+8JC7DqbYUynh5Nh2KjQYGGsOo9vzJfaSQ8a7KUwBMt
8XO/XGlJC8ts7ytTVWJy2L/bW5VdNtpWrUuTt8j63iBSveEiGVz+knoIcR7kalxN
Bm0PqH/Orp2dg3+4y5UzatVgG2yBn0Bg9OJozQJ5DYUfm4Zs4S++2to8JPc1qy4p
buKlCv7r6jwHgw7XvsXuNE3z9lHAcWdv8NQWXCubcxRJj4O3aNZBIho/heIvUjFx
JSfKQd7y93WuIC8sTMucjl+9lBDfRWEcAf2bdSILwDRsGel5PvBrYwqFbX9Rd8iL
LmQOF1C3XpvHXWeMeMPbK98S8786DtquBpYKI7QDkCXiN2li/LUAfPSio0OYkLwx
c7KnFo64HipvreOS9OE8
=8StA
-END PGP SIGNATURE-
>From e128231a940017c0ac71cb05c290beb91231deda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= 
Date: Tue, 29 Mar 2016 15:50:15 +0200
Subject: [PATCH] cuts +debXuY suffix debian version

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 12ebd38..10e034a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-DEBIAN_VERSION ?= $(shell LANG=C dpkg -l base-files | awk '($$1=="ii"){print $$3}' | cut -d. -f1)
+DEBIAN_VERSION ?= $(shell LANG=C dpkg -l base-files | awk '($$1=="ii"){print $$3}' | cut -d. -f1 | cut -d+ -f1)
 
 %:
 	dh $@
-- 
2.8.0.rc3

Bug#244286: chrony: offline mode should be selectable by debconf

[Vincent Blut]

tags 244286 wontfix
thanks

On Sat, 17 Apr 2004 22:05:01 +0300 Sami Haahtinen  
wrote:

> Package: chrony
> Version: 1.20-5
> Severity: wishlist
>
> it would be REALLY convinient if chrony asked on install wether the 
ntp

> servers should be offline or not. This would make it easier for
> beginners to install the package, it is easy enough to disable the
> offline mode if you know your internals, otherwise it's just unneeded
> work for beginners.

Hello,

I really don’t want to bother the admin to make that choice at 
install time.
I’m fairly sure she knows what kind of connection her system is 
connected
to. Consequently, she will update chrony’s configuration file if 
necessary.


> Regards, Sami

Cheers,
Vincent

Bug#817959: bsdmainutils: [cal] The -M and -S options do not work

[Michael Meskes]

> I think that the cause may be the fact that a same man page for two
> different user commands is very unusual. Having two different man
> pages (possibly generated from the same source) would be better,
> IMHO.

You're free to submit a patch.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL