Bug#804436: mlmmj: installs incorrectly formatted job to /etc/crontab when creating a list

[Chris Knadle]

severity 804436 important
retitle 804436 mlmmj: tells user to add malformed entry to /etc/crontab
thanks

> I recently moved all of my email setup to a new machine. I installed mlmmj,
> and when I created a list, it added the following /line to /etc/crontab:
> 
> 0 */2 * * * "/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/tvcadmin/"
> 
> This led to another job failing to run - its crontab entry is:
> 
> 1 0   * * *   root/usr/local/bin/simplebackup
> 
> The mlmmj-maintd job ran, but the simplebackup job was never started. As for
> the other jobs listed, I am unsure whether they ran or not.
> 
> When I amended the mlmmj-maintd job thus, the problem was resolved:
> 
> 0 */2 * * *   root/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/tvcadmin/
> 
> The problem appears to be that mlmmj creates the crontab entry without
> specifying the user name. It should either specify the user name or put the
> entry in the user's crontab.

I just found this bug the other day when I installed mlmmj on Sid to do some
testing and found the bug report by way of how-can-i-help... and I think
I've figured out what's going on.

mlmmj does not install anything to /etc/crontab -- instead it installs a
cronjob at /etc/cron.d/mlmmj that contains this (which works fine):

   0 */2 * * * root /usr/bin/test -x /usr/bin/mlmmj-maintd &&
/usr/bin/mlmmj-maintd -F -d /var/spool/mlmmj

This runs mlmmj-maintd every half hour for all mlmmj mailing lists that
reside under /var/spool/mlmmj -- meaning that adding separate mlmmj-maintd
entries to /etc/crontab is not necessary.



However after running '/usr/bin/mlmmj-make-ml -L testlist2 -s
/var/spool/mlmmj -a -c mlmmj' to create a mailing list it outputs the
following text:

   If you're not starting mlmmj-maintd in daemon mode,
   don't forget to add this to your crontab:
   0 */2 * * * "/usr/bin/mlmmj-maintd -F -L /var/spool/mlmmj/testlist2/"

and this is the bug: it tells the admin running the mailing list to modify
/etc/crontab when it's not necessary to do so, and in a way that will break
things.  It's not obvious that the cron job added in /etc/cron.d/mlmmj
exists and runs mlmmj-maintd on all mailing lists as this isn't mentioned in
the README.Debian.gz.  Furthermore because it's done as a cron job this
would not be considered "daemon mode" and thus even if the user found this
out they still may be misled into thinking that adding the malformed entry
into /etc/crontab is needed.



It seems like this package needs a patch to either modify the text output
concerning the crontab entry or remove it, and I'm not sure which is better.
 I'm considering making a patch an uploading it via a sponsored NMU.


Because of the RC bug severity and lack of response, mlmmj has been missing
from Testing for the last 3-1/2 months.  This seems to be an indication that
the maintainer is too busy for the package, so I'm considering filing an ITA
to adopt the package.  Thomas: this okay with you?

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

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

[Sergey Poznyakoff]

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/

Bug#818225: wheezy-pu: package exim4/4.80-7+deb7u3

[Salvatore Bonaccorso]

Hi Adam,

On Wed, Mar 23, 2016 at 09:30:21PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2016-03-14 at 21:28 +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Mon, Mar 14, 2016 at 09:12:13PM +0100, Salvatore Bonaccorso wrote:
> [...]
> > > The recent DSA had a defective backported patch applied for the
> > > wheezy-security upload. Apologies it slept trough on the review, so I
> > > propose the attached debdiff to fix this in wheezy via the last point
> > > release (the issue is not severe enought to do a follow up DSA).
> > > 
> > > Fine with that upload?
> > 
> > For reference, these are the upstream commits:
> > 
> > https://github.com/Exim/exim/commit/8527598de8b3d09642371e09f1c24d8178f445db
> > https://github.com/Exim/exim/commit/b33c6383718d5978cb87a18878e652e675adc88e
> 
> Assuming that the issue doesn't also apply to the package in unstable,
> please go ahead.

No it is specific to the wheezy backport. Thanks for acknowledging. I
have uploaded the changes.

Regards,
Salvatore

Bug#819146: PHP 7 transition and moving to pkg-php-pecl team

[Mathieu Parent]

Source: php-mongo
Version: 1.6.10-1
Severity: important

Hello,

There is an ongoing transition from php5 to php7.0.

This is basically replacing all references to php5 in debian/* by either php or
php7.0.

Additionnaly moving this package to pkg-php-pecl team and to alioth's git will
allow team maintenance.

Laszlo, can you take care of this? If not, I'll do it in April.

Regards

Mathieu Parent

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

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

Bug#700870: [pkg-wpa-devel] Bug#700870: building eapol_test

[Stefan Lippers-Hollmann]

Hi

On 2016-03-24, Christopher Hoskin wrote:
> Hello, I've been doing some work on the upstream FreeRADIUS 3 Debian
> package, with a view to eventually getting it accepted into Debian (Bug
> #797181).
> 
> https://github.com/FreeRADIUS/freeradius-server/pulls?q=is%3Apr+author%3Amans0954
> 
> I'm currently looking at enabling build and autopkgtest tests. Upstream
> have some tests which make use of eapol_test.
> 
> If eapol_test isn't available on the system, the upstream script clones the
> upstream hostap repository and builds it. This isn't appropriate for a
> Debian package. Including enough of the hostap source within the FreeRADIUS
> Debian package to build eapol_test would not be ideal.
> 
> Therefore, I'd also like to request that Matthew Newton's patch is applied,
> so that the proposed eapoltest package can be specified as a build
> dependency of FreeRADIUS. The patch appears to apply and build against the
> latest wpa source package trunk (on amd64 at least).
> 
> Please, would this be possible?

Just a very quick/ short preliminary response, in general I'm not 
exactly thrilled about adding this -considering my build issues with 
eapol_test in previous src:wpa versions- but I haven't actually 
revisited this particular question recently.

*If* eapol_test builds with v2.3, v2.4, v2.5 and hostapd HEAD without 
having to fix bugs in the upstream code (I haven't tested this yet), I 
could be convinced to add this functionality (well, v2.5 and HEAD would
be more important than the previous versions) to src:wpa, but if this
would still be a 'constant' source for build issues (demonstrating that 
this isn't actually tested by upstream - last time I looked into it, 
the build issues were trivial, but quite numerous), I'd tend towards
declining this (however, if there'd be an src:wpa co-maintainer who'd 
take care of this aspect...). Have you checked buildability recently?

Regards
Stefan Lippers-Hollmann


pgpa50bOT3paK.pgp
Description: Digitale Signatur von OpenPGP

Bug#811057: FTBFS: config.guess: Hunk #1 FAILED at 3

[Logan Rosen]

Package: tkgate
Version: 2.0~b10-4
Followup-For: Bug #811057
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove debian/patches/03_config.diff from series, as debhelper now
updates config.{sub,guess} automatically, causing the patch to not apply
cleanly.
  * Remove autotools-dev from debian/{control,rules}, as it is no longer
necessary due to debhelper's aforementioned new automatic behavior.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-7-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u tkgate-2.0~b10/debian/control tkgate-2.0~b10/debian/control
--- tkgate-2.0~b10/debian/control
+++ tkgate-2.0~b10/debian/control
@@ -1,13 +1,12 @@
 Source: tkgate
 Section: electronics
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Science Maintainers 
+Maintainer: Debian Science Maintainers 
 Uploaders: أحمد المحمودي (Ahmed El-Mahmoudy) ,
 	   Georges Khaznadar 
 Standards-Version: 3.9.5
 Build-Depends: debhelper (>=7.0.50~), tcl8.5-dev, tk8.5-dev, bison|byacc, flex,
- xutils-dev, libx11-dev, quilt (>= 0.46-7~), autotools-dev,
+ xutils-dev, libx11-dev, quilt (>= 0.46-7~),
  hardening-wrapper
 Homepage: http://www.tkgate.org/
 Vcs-Git: git://git.debian.org/git/debian-science/packages/tkgate.git
diff -u tkgate-2.0~b10/debian/patches/series tkgate-2.0~b10/debian/patches/series
--- tkgate-2.0~b10/debian/patches/series
+++ tkgate-2.0~b10/debian/patches/series
@@ -1,5 +1,4 @@
 01_paths.diff
-03_config.diff
 04_typos.diff
 hardening.patch
 remove-shebang-line.patch
diff -u tkgate-2.0~b10/debian/rules tkgate-2.0~b10/debian/rules
--- tkgate-2.0~b10/debian/rules
+++ tkgate-2.0~b10/debian/rules
@@ -5,7 +5,7 @@
 export DEB_BUILD_HARDENING=1
 
 %:
-	dh $@ --with quilt,autotools_dev
+	dh $@ --with quilt
 
 override_dh_auto_configure:
 	dh_auto_configure -- LDFLAGS="$(LDFLAGS) -Wl,--as-needed -lm"

Bug#800220: tzc: Please migrate a supported debhelper compat level

[Logan Rosen]

Package: tzc
Version: 2.6.15-5.3
Followup-For: Bug #800220
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules:
- Remove legacy DH_COMPAT export.
- Add recommended build-arch and build-indep targets.
- Use dh_prep instead of dh_clean -k.
- Don't allow $(MAKE) clean to ignore errors.
  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-7-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u tzc-2.6.15/debian/control tzc-2.6.15/debian/control
--- tzc-2.6.15/debian/control
+++ tzc-2.6.15/debian/control
@@ -2,12 +2,12 @@
 Section: net
 Priority: optional
 Maintainer: Theodore Y. Ts'o 
-Build-Depends: debhelper (>> 3.0.0), libzephyr-dev (>= 3.0~beta), comerr-dev
+Build-Depends: debhelper (>= 9), libzephyr-dev (>= 3.0~beta), comerr-dev
 Standards-Version: 3.6.2.1
 
 Package: tzc
 Architecture: any
-Depends: ${shlibs:Depends}, zephyr-clients
+Depends: ${misc:Depends}, ${shlibs:Depends}, zephyr-clients
 Description: Trivial Zephyr Client
  tzc is a trivial zephyr client program which talks to the zephyr servers 
  (via the "zephyr host manager").   It is primarily used by the gnu-emacs
diff -u tzc-2.6.15/debian/rules tzc-2.6.15/debian/rules
--- tzc-2.6.15/debian/rules
+++ tzc-2.6.15/debian/rules
@@ -5,11 +5,6 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-# This is the debhelper compatibility version to use.
-export DH_COMPAT=3
-
-
-
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 	CFLAGS += -g
 endif
@@ -23,7 +18,9 @@
 	dh_testdir
 
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp: 
 	dh_testdir
@@ -36,13 +33,13 @@
 	dh_testroot
 	rm -f build-stamp configure-stamp
 	# Add here commands to clean up after the build process.
-	-$(MAKE) clean
+	$(MAKE) clean
 	dh_clean
 
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	# Add here commands to install the package into debian/tzc.
only in patch2:
unchanged:
--- tzc-2.6.15.orig/debian/compat
+++ tzc-2.6.15/debian/compat
@@ -0,0 +1 @@
+9

Bug#819145: freebsd-buildutils: prototype setmode to fix implicit pointer conversion

[Logan Rosen]

Package: freebsd-buildutils
Version: 10.0-8
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

As is evident from the build logs [1], there is an implicit declaration and 
pointer conversion of the
setmode function in freebsd-utils. This can lead to unintended consequences, 
especially on 64-bit
architectures.

In Ubuntu, the attached patch was applied to achieve the following:

  * Merge from Debian unstable. Remaining changes:
- Prototype setmode since freebsd-glue and libbsd don't do the right thing.

Thanks for considering the patch.

Logan Rosen

[1] https://qa.debian.org/bls/packages/f/freebsd-buildutils.html

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

Kernel: Linux 4.4.0-7-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru freebsd-buildutils-10.0/debian/patches/prototype-setmode.diff freebsd-buildutils-10.0/debian/patches/prototype-setmode.diff
--- freebsd-buildutils-10.0/debian/patches/prototype-setmode.diff	1969-12-31 18:00:00.0 -0600
+++ freebsd-buildutils-10.0/debian/patches/prototype-setmode.diff	2015-07-11 02:19:06.0 -0500
@@ -0,0 +1,15 @@
+Description: Prototype setmode
+
+Index: b/src/usr.sbin/mtree/spec.c
+===
+--- a/src/usr.sbin/mtree/spec.c
 b/src/usr.sbin/mtree/spec.c
+@@ -49,6 +49,8 @@
+ #include "mtree.h"
+ #include "extern.h"
+ 
++extern void *setmode(const char *mode_str);
++
+ int lineno;/* Current spec line number. */
+ 
+ static void	 set(char *, NODE *);
diff -Nru freebsd-buildutils-10.0/debian/patches/series freebsd-buildutils-10.0/debian/patches/series
--- freebsd-buildutils-10.0/debian/patches/series	2015-07-09 06:37:17.0 -0500
+++ freebsd-buildutils-10.0/debian/patches/series	2016-03-23 01:17:38.0 -0500
@@ -25,6 +25,7 @@
 disable_wsystem_headers.diff
 nostrip.diff
 config_ldflags.diff
+prototype-setmode.diff
 
 # Patches that are likely to be Debian-specific
 avoid_defsyspath_collision.diff

Bug#819144: ITP: golang-github-appc-docker2aci -- library and CLI tool to convert Docker images to ACIs

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block -1 by 819143

   Package name: golang-github-appc-docker2aci
Version: 0.9.2
License: Apache-2.0
URL: https://github.com/appc/docker2aci
Description: library and CLI tool to convert Docker images to ACIs
 docker2aci is a small library and CLI binary that converts Docker images to
 ACI (https://github.com/appc/spec/blob/master/SPEC.md#app-container-image).
 It takes as input either a file generated by "docker save" or a Docker
 registry URL. It gets all the layers of a Docker image and squashes them
 into an ACI image. Optionally, it can generate one ACI for each layer,
 setting the correct dependencies.


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

Bug#819143: ITP: golang-github-coreos-ioprogress -- progress bars around io.Reader/Writers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-coreos-ioprogress
Version: 0.0~git20151023
Upstream Author: Mitchell Hashimoto
License: Expat
URL: https://github.com/coreos/ioprogress
Description: progress bars around io.Reader/Writers
 Ioprogress is a Goolang library with implementations of io.Reader and
 io.Writer that draws progress bars. The primary use case for these are for
 CLI applications.


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

Bug#760813: firmware-b43-installer: Package device detection fails without PCI hardware

[Elliott Mitchell]

tags 760813 + patch
quit

For the heck of it, I'm attaching a patch that takes the suboptimal, but
functional approach.  This looks for 47[01][0-9a-f] chips.  This should
include some of the earlier 47xx chips which share the same firmware.
This is a pretty broad brush, but I know there are quite a few other
types of devices out there.

I also looked through https://wireless.wiki.kernel.org/en/users/Drivers/b43
and added everything that was there.  Some of those need kernel 3.18,
but I imagine the next version of firmware-b43-installer will be out near
the next Debian release when I imagine that will be standard.  I actually
prefer the script's new default of simply always installing the firmware
and not bothering to check for presence of the hardware.

While I was at it, the attached patches also do some cleanup on the
script.  The big case statement is using ranges to match multiple chips,
since that blob is getting too big otherwise.  Also moved the detection
of the BCM4306/3 chips inside the case statement (should be faster).


One major remaining concern with the postinst script.  What about systems
with multiple Broadcom 802.11 chips installed?  If I have a very recent
system, I might plug in an old legacy chip card for initial installation
when the firmware/driver for a newer chip isn't readily available.  In
this case, the script will fail since it has a legacy chip, when it
should succeed because it also has a newer chip...

Got to revisions of the patch, the difference is rev1 is more aggressive
about combining chip id ranges together.  I don't know which you prefer.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


--- firmware-b43-installer.postinst.orig2015-04-05 19:21:07.0 
-0700
+++ firmware-b43-installer.postinst 2016-03-23 20:52:14.0 -0700
@@ -67,48 +67,46 @@
 exit 0
 fi
 
-# Fix for BCM4306/3 [14e4:4320] (rev 03)
-chip=`lspci -n | grep -o "14e4:4320 (rev 03)"` || true
-if [ "$chip" ] ; then
-   echo "Your card is BCM4306/3 [14e4:4320] (rev 03), firwmare 5.100.138 will 
be used"
-   latest_firmware
-   exit 0
-fi 
-
-# Fix for BCM4306/3 [14e4:4324] (rev 03)
-chip=`lspci -n | grep -o "14e4:4324 (rev 03)"` || true
-if [ "$chip" ] ; then
-   echo "Your card is BCM4306/3 [14e4:4324] (rev 03), firwmare 5.100.138 will 
be used"
-   latest_firmware
-   exit 0
-fi
-   
 # check chip
-pci=`lspci -n | grep -o "14e4:[1234567890abcdef]\+"` || true
+pci=`lspci -n -d 14e4: | grep -o "14e4:[1234567890abcdef]\+"` || true
 
-if [ -n "$pci" ]; then
-   for device in $pci; do
-   device_id=`echo $device | cut -d: -f2`
-   case $device_id in
-   4301 | 4306 | 4320 |4324 | 4325)
-   legacy=1
-   ;;
-   4307 | 4311 | 4312 | 4315 | 4318 | 4319 | 4321 | 4328 | 4329 | 
432b | 432c | 4331 | 4353 | 4357 | 5354)
-   latest=1
-;;
-   4322 | 4358 | 4365 | 4727 | a8d8)
-   # b43 upstream says 3.6+ for a8d8
-   unsupported="$unsupported $device_id"
-   ;;
-   0576 | 4313 | 432a | 432d | 4358 | 4359 | 435a | a99d)
-nottested=1
-;;
-   *)
-   ;;
-   esac
-   done
+if [ -z "$pci" ]; then
+   echo "No Broadcom 802.11 chips found, aborting firmware installation."
+   exit 1
 fi
 
+for device in $pci; do
+   device_id=${device#14e4:}
+   case $device_id in
+   4301 | 4306 | 4325)
+   legacy=1
+   ;;
+   4320 | 4324)
+   chip=`lspci -n -d ${device}`
+   if [ "${chip}" != "${chip%${device} (rev 03)}" ] ; then
+  latest=1
+   else
+  legacy=1
+   fi
+   ;;
+   4307 | 4311 | 4312 | 4315 | 4318 | 4319 | 4321 | 4322 | 4328 | 4329 | 
432b | 432c | 4331 | 4350 | 4353 | 4357 | 4358 | 4359 | 43a9 | 43aa | 
47[01][0-9a-f] | a8d8 | a8db | 5354)
+   latest=1
+   ;;
+   4322 | 4358 | 4360 | 4365 | 43a0 | 43b1 | 4727)
+   unsupported="$unsupported $device_id"
+   ;;
+   4313)
+   # need to distinguish BCM4311 (untested) from BCM4313 (not 
supported)
+   nottested=1
+   ;;
+   0576 | 432a | 432d | 4358 | 4359 | 435a | a8d6 | a99d)
+   nottested=1
+   ;;
+   *)
+   ;;
+   esac
+done
+
 if [ "$legacy" ]; then
echo "An unsupported BCM4301, BCM4306 or BCM4306/2 device was found."
echo "Use b43legacy firmware (firmware-b43legacy-installer package) 
instead."
--- firmware-b43-installer.postinst.orig2015-04-05 19:21:07.0 
-0700
+++ 

Bug#817929: mosh fails to connect, giving a UDP error

[john hood]

On 3/22/16 9:48 PM, Matthew Gabeler-Lee wrote:
> On Tue, 22 Mar 2016 23:21:31 +0100 Goffredo Baroncelli
>  wrote:
>> Please give a look to
>>
>> https://sourceware.org/ml/libc-help/2016-03/msg00010.html
>>
>> to me it seems that the real problem is in glibc.
> 
> From reading that thread and looking at the referenced git commit, I'm
> not convinced it's a glibc bug.  While I'm definitely not an expert in
> this area, it looks to me like glibc removed some legacy cruft that
> should no longer have been needed by any app that used the correct
> compile/link flags for pthreads.  They also added a workaround for a
> common case of incorrect flags.

I haven't been able to chase these glibc details down.  Do you have
pointers to specifics for this?

> But what we have here is an uncommon case driven by mosh's linker
> options, which means that the glibc workaround for protobuf's incorrect
> linker options doesn't (can't?) work.

I agree that this issue seems to be provoked by a *change* in glibc, but
not a *bug*-- I believe the bug is protobuf's bad linker options.  All
this stuff is ill-documented though.

> If protobuf didn't recommend incorrect linker options, we wouldn't have
> this problem.  Seems thus this bug should be moved to the protobuf
> package and the upstream patch applied?

That seems reasonable to me.

> Having mosh conflict with the broken protobuf versions would be handy
> too, but may not be necessary?

I think it's not necessary; I think we'll have to fix this in packaging
for mosh-1.2.5 on unstable, and in the upstream for mosh master.  We're
working on #1 now.  I just pushed the fix for #2.

regards,

  --jh

Bug#700870: building eapol_test

[Christopher Hoskin]

Hello, I've been doing some work on the upstream FreeRADIUS 3 Debian
package, with a view to eventually getting it accepted into Debian (Bug
#797181).

https://github.com/FreeRADIUS/freeradius-server/pulls?q=is%3Apr+author%3Amans0954

I'm currently looking at enabling build and autopkgtest tests. Upstream
have some tests which make use of eapol_test.

If eapol_test isn't available on the system, the upstream script clones the
upstream hostap repository and builds it. This isn't appropriate for a
Debian package. Including enough of the hostap source within the FreeRADIUS
Debian package to build eapol_test would not be ideal.

Therefore, I'd also like to request that Matthew Newton's patch is applied,
so that the proposed eapoltest package can be specified as a build
dependency of FreeRADIUS. The patch appears to apply and build against the
latest wpa source package trunk (on amd64 at least).

Please, would this be possible?

Thanks.

Christopher Hoskin

Bug#818996: Please enable -Wabi-tag warning for C++ programs

[Jeffrey Walton]

> On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote:
>> If you want to change that, that change should be made in dpkg-buildflags.
>
> From the original report:
>
>> >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:
>> >>It appears Debian built the library with GCC, and GCC used
>> >>_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a
>> >>link error. The tools did not warn him about the problems, so the
>> >>report trickled downhill to us.
>
> it isn't clear to me whether that would have helped: dpkg-buildflags
> only affects the warnings emitted when Debian packages are built, whereas
> a change in gcc would also affect the warnings emitted when upstream
> software is built on Debian.

When Debian builds its packages, I don't believe it {was|is} an issue.

The problem is a confluence, and there's no single point of failure
per se. It appears when a user builds their userland programs using
Debian libraries *and* the user's compiler and/or options are
different than when Debian built the library.

> Jeffrey: who is "us",

"We" is the Crypto++ project (https://www.cryptopp.com/). Crypto++ is
a C++ class library of cryptographic schemes and algorithms created by
a fellow named Wei Dai.

> and does the problematic link step involve libraries
> from Debian packages, libraries you have previously compiled yourself, or
> both?

Yes (but its not a hard yes).

We (Crypto++) do not maintain Debian's Crypto++ library. We are
fortunate that László Böszörményi maintains it for us since it
relieves us from the task. We are also fortunate that László is a
friend of the project, and he works closely with us to ensure the
library is trouble free when integrating with the Debian ecosystem. A
number of bug fixes are credited to him. He also mentors us in Debian
ways to ensure a trouble free experience for both maintainers and
user. (Sorry about the shameless plug for László).

We believe the issue would surface regardless of who is building the
library under Debian when different compilers and or options are used
by the user. László could build it, we could build it, or the user
could build it from sources.

The problem should not be limited to Crypto++. I believe PCRE has a
C++ component, and it should experience the problem too *if* the user
selects a different compiler and/or options. You should be able to
 and duplicate the issue the user selects
a different compiler and/or options.

> During which compilation/linking step would you have expected to see
> this warning?

Here are the cases I would expect to see the warning. Below, "library"
means the Crypto++ library; and "program" means the program build by
the user linking to the library. "By Debian" implies the GCC compiler
with _GLIBCXX_USE_CXX11_ABI because that's the "out of the box"
configuration.

 (1) library supplied by Debian, program built by user using different
options (say -std=c++03)
 (2) library supplied by Debian, program built by user using different
compiler (say Clang)
 (3) library built by user using GCC with Debian settings, program
built by user using different options (say -std=c++03)
 (4) library built by user using GCC with Debian settings, program
built by user using different compiler (say Clang)
 (5) library built by user using Clang, program built by user using
Debian's GCC with _GLIBCXX_USE_CXX11_ABI

For completeness, here's what works as excepted. It avoids the
"different compiler and/or options" that's causing the pain point at
link time:

 (6) library supplied by Debian, program built by user using GCC with
Debian settings

> - compile and link a program that uses libfoo and libbar with uvw compiler

Let me follow up with some real result from a minimal test case.

> (but I'm probably getting the sequence of events totally wrong so please
> specify what is actually going on)

Not at all. Its a confluence of events, and that's what is making it
tricky to nail down.

-Wabi-tag is somewhat of a mystery at the moment. Though introduced in
GCC 5.1, its still not documented at 5.3 (cf.,
http://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Warning-Options.html#Warning-Options).
According to 
http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/,
its intended to catch the mixing and matching that's causing the pain.

Jeff

Bug#818540: pepperflashplugin-nonfree: broken by new apt

[Barry Grumbine]

Hello,

/usr/sbin/update-pepperflashplugin-nonfree treats all "apt-get update"
output to stderr as an ERROR.

When "apt-get update" gives the (weak digest) Warning
update-pepperflashplugin-nonfree fails.

Here's a diff to v1.8.2. I tested it by setting stdouterr to different
values and it seems to fix the problem. It also adds checks for SHA256
hashes. Tabs got mangled in copy-paste but should be OK in the attached
file.

# diff -u update-pepperflashplugin-nonfree.1.8.2
update-pepperflashplugin-nonfree
--- update-pepperflashplugin-nonfree.1.8.2  2015-12-17
10:28:04.0 -0700
+++ update-pepperflashplugin-nonfree2016-03-23 20:34:50.803926398 -0700
@@ -174,6 +174,11 @@

[ "$verbose" != "yes" ] || echo "doing apt-get update on google
repository"
stdouterr=`APT_CONFIG=apt.conf apt-get --quiet --quiet update 2>&1
|| true`
+   warning_ck=`echo ${stdouterr} |grep "^W\:"` || [ "$verbose" !=
"yes" ] || echo "no 'apt-get update' warning"
+   if [ "${warning_ck}" != "" ]; then
+   echo "WARNING: $stdouterr"
+   stdouterr=""
+   fi
[ "$stdouterr" = "" ] || die_hard_with_a_cleanup "failed to
retrieve status information from google : $stdouterr"

newchromeversion=`APT_CONFIG=apt.conf apt-cache show
google-chrome-$variant | grep "^Version: " | sed -e "s,^Version: ,,"`
@@ -181,6 +186,7 @@
deburl="http://dl.google.com/linux/chrome/deb/$poolfile;
debfile=`echo $poolfile|sed -e "s,.*/,,"`
debsize=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant
| grep "^Size: " | sed -e "s,^Size: ,,"`
+   debsha256=`APT_CONFIG=apt.conf apt-cache show
google-chrome-$variant | grep "^SHA256: " | sed -e "s,^SHA256: ,,"`
debsha1=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant
| grep "^SHA1: " | sed -e "s,^SHA1: ,,"`
debmd5=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant |
grep "^MD5sum: " | sed -e "s,^MD5sum: ,,"`

@@ -235,6 +241,7 @@
HOME=/root wget $wgetoptions $deburl ||
die_hard_with_a_cleanup "wget failed to download $deburl"

[ `stat --format=%s $debfile` = "$debsize"
] || die_hard_with_a_cleanup "rejecting $debfile : wrong size"
+   [ `sha256sum $debfile|sed -e "s, .*,,"` =
"$debsha256" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong
sha256sum"
[ `sha1sum $debfile|sed -e "s, .*,,"` =
"$debsha1" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong sha1sum"
[ `md5sum $debfile|sed -e "s, .*,,"` =
"$debmd5" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong md5sum"
fi


Hope this helps someone...

-Barry
--- update-pepperflashplugin-nonfree.1.8.2	2015-12-17 10:28:04.0 -0700
+++ update-pepperflashplugin-nonfree	2016-03-23 20:34:50.803926398 -0700
@@ -174,6 +174,11 @@
 
 	[ "$verbose" != "yes" ] || echo "doing apt-get update on google repository"
 	stdouterr=`APT_CONFIG=apt.conf apt-get --quiet --quiet update 2>&1 || true`
+	warning_ck=`echo ${stdouterr} |grep "^W\:"` || [ "$verbose" != "yes" ] || echo "no 'apt-get update' warning"
+	if [ "${warning_ck}" != "" ]; then
+		echo "WARNING: $stdouterr"
+		stdouterr=""
+	fi
 	[ "$stdouterr" = "" ] || die_hard_with_a_cleanup "failed to retrieve status information from google : $stdouterr"
 
 	newchromeversion=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant | grep "^Version: " | sed -e "s,^Version: ,,"`
@@ -181,6 +186,7 @@
 	deburl="http://dl.google.com/linux/chrome/deb/$poolfile;
 	debfile=`echo $poolfile|sed -e "s,.*/,,"`
 	debsize=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant | grep "^Size: " | sed -e "s,^Size: ,,"`
+	debsha256=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant | grep "^SHA256: " | sed -e "s,^SHA256: ,,"`
 	debsha1=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant | grep "^SHA1: " | sed -e "s,^SHA1: ,,"`
 	debmd5=`APT_CONFIG=apt.conf apt-cache show google-chrome-$variant | grep "^MD5sum: " | sed -e "s,^MD5sum: ,,"`
 
@@ -235,6 +241,7 @@
 HOME=/root wget $wgetoptions $deburl || die_hard_with_a_cleanup "wget failed to download $deburl"
 	
 [ `stat --format=%s $debfile` = "$debsize" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong size"
+[ `sha256sum $debfile|sed -e "s, .*,,"` = "$debsha256" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong sha256sum"
 [ `sha1sum $debfile|sed -e "s, .*,,"` = "$debsha1" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong sha1sum"
 [ `md5sum $debfile|sed -e "s, .*,,"` = "$debmd5" ] || die_hard_with_a_cleanup "rejecting $debfile : wrong md5sum"
 			fi

Bug#819142: fuzzylite: make symbols file compatible with -O3

[Steve Langasek]

Package: fuzzylite
Version: 5.1+dfsg-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Hi Johannes,

The Ubuntu ppc64el port uses -O3 optimization for package builds by default. 
Under -O3, there are a number of template symbols that are not exported in
libfuzzylite because they wind up inlined instead.  As a result, fuzzylite
fails to build with a mismatched symbols file error.

The attached patch has been applied in Ubuntu to mark these additional
symbols optional, since they are not part of the ABI, and allows the package
to build wherever -O3 is used.

Thanks for considering the patch.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru fuzzylite-5.1+dfsg/debian/libfuzzylite5.1v5.symbols fuzzylite-5.1+dfsg/debian/libfuzzylite5.1v5.symbols
--- fuzzylite-5.1+dfsg/debian/libfuzzylite5.1v5.symbols	2015-11-01 01:29:51.0 -0800
+++ fuzzylite-5.1+dfsg/debian/libfuzzylite5.1v5.symbols	2016-03-23 20:31:54.0 -0700
@@ -1396,23 +1396,23 @@
  (c++)"std::vector::~vector()@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::Proposition* const&)@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::InputVariable* const&)@Base" 5.1
- (c++)"std::vector >::_M_erase(__gnu_cxx::__normal_iterator > >)@Base" 5.1
- (c++)"std::vector >::operator=(std::vector > const&)@Base" 5.1
+ (c++|optional)"std::vector >::_M_erase(__gnu_cxx::__normal_iterator > >)@Base" 5.1
+ (c++|optional)"std::vector >::operator=(std::vector > const&)@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::OutputVariable* const&)@Base" 5.1
- (c++)"std::vector >::_M_erase(__gnu_cxx::__normal_iterator > >)@Base" 5.1
- (c++)"std::vector >::operator=(std::vector > const&)@Base" 5.1
+ (c++|optional)"std::vector >::_M_erase(__gnu_cxx::__normal_iterator > >)@Base" 5.1
+ (c++|optional)"std::vector >::operator=(std::vector > const&)@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::Rule* const&)@Base" 5.1
- (c++)"std::vector >::operator=(std::vector > const&)@Base" 5.1
+ (c++|optional)"std::vector >::operator=(std::vector > const&)@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::Term* const&)@Base" 5.1
- (c++)"std::vector >::operator=(std::vector > const&)@Base" 5.1
+ (c++|optional)"std::vector >::operator=(std::vector > const&)@Base" 5.1
  (c++)"std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, fl::Hedge* const&)@Base" 5.1
  (c++)"std::vector 

Bug#819141: command failed: No such device (-19)

[積丹尼 Dan Jacobson]

Package: iw
Version: 3.17-1

# iw dev wlan0 info
command failed: No such device (-19)
# iwconfig wlan0
wlan0 IEEE 802.11bgn  ESSID:"430"  Nickname:"rtl_wifi"
  Mode:Managed  Frequency:2.412 GHz  Access Point: 90:F6:52:BF:0D:82
  Bit Rate:150 Mb/s   Sensitivity:0/0
  Retry:off   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off
  Link Quality=98/100  Signal level=46/100  Noise level=0/100
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0

So there is such a device.
So the message is wrong.

Bug#819140: command failed: No such device (-19)

[積丹尼 Dan Jacobson]

Package: iw
Version: 3.17-1

# iw dev wlan0 info
command failed: No such device (-19)
# iwconfig wlan0
wlan0 IEEE 802.11bgn  ESSID:"430"  Nickname:"rtl_wifi"
  Mode:Managed  Frequency:2.412 GHz  Access Point: 90:F6:52:BF:0D:82   
  Bit Rate:150 Mb/s   Sensitivity:0/0  
  Retry:off   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off
  Link Quality=98/100  Signal level=46/100  Noise level=0/100
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Bug#819139: php5-dev: php-config5 --php-binary gives unversioned result

[Olly Betts]

Package: php5-dev
Version: 5.6.19+dfsg-2
Severity: normal

"php-config5 --php-binary" gives "/usr/bin/php" which is a managed by
alternatives.  Currently /usr/bin/php7.0 has the highest priority:

$ update-alternatives --config php
There are 2 choices for the alternative php (providing /usr/bin/php).

  SelectionPath Priority   Status

* 0/usr/bin/php7.0   70auto mode
  1/usr/bin/php5 50manual mode
  2/usr/bin/php7.0   70manual mode

On a system with both php5-cli and php7.0-cli installed (which users who have
installed php-cli will have, since this dependency package has now switched to
pulling in php7.0-cli), the upshot is that you get the wrong PHP interpreter
version:

$ php-config5 --php-binary
/usr/bin/php
$ /usr/bin/php --version
PHP 7.0.4-6 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Really "php-config5 --php-binary" should give "/usr/bin/php5":

$ /usr/bin/php5 --version
PHP 5.6.19-2 (cli) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

It appears that php-config7.0 gets this right:

$ php-config7.0 --php-binary
/usr/bin/php7.0

Cheers,
Olly

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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)

Versions of packages php5-dev depends on:
ii  autoconf  2.69-9
ii  automake  1:1.15-4
ii  libpcre3-dev  2:8.38-3.1
ii  libssl-dev1.0.2g-1
ii  libtool   2.4.6-0.1
ii  php5-common   5.6.19+dfsg-2
ii  shtool2.0.8-8

Versions of packages php5-dev recommends:
ii  dh-php50.2
ii  pkg-php-tools  1.32

php5-dev suggests no packages.

-- no debconf information

Bug#818997: [pkg-gnupg-maint] Bug#818997: gpgv.exe linked dynamically against zlib1, doesn't allow proper signature verification

[Daniel Kahn Gillmor]

On Tue 2016-03-22 12:49:10 -0400, Didier 'OdyX' Raboud wrote:

> I've noticed that gpgv.exe fails its CI test (debian/tests/gpgv-win32) in
> version 1.4.20-4 (-3 and previous work fine):

interesting, there was no change between -3 and -4 other than re-adding
the gpgv-udeb for constrained armel devices at tbm's request (see
#814027).

I suspect this means that the toolchain changed in some significant way
between these releases.

> (This is after adding WINEDEBUG=err+all as prefix to the latest line):
>
> err:menubuilder:init_xdg error looking up the desktop directory
> err:module:import_dll Library zlib1.dll (which is needed by 
> L"Z:\\usr\\share\\win32\\gpgv.exe") not found
> err:module:LdrInitializeThunk Main exe initialization for 
> L"Z:\\usr\\share\\win32\\gpgv.exe" failed, status c135
>
> It seems gpgv-win32 is dynamically linked against zlib1.dll, where it should
> probably be statically linked. This appears to be a problem in the dependency
> chain.

hm, right.  I'm actually working on moving gpgv.exe over to the gnupg2
packaging, so that we can get support for elliptic curve signatures as
well.  I'll definitely test to ensure that it's properly statically
linked when i produce it from that source.

> (By the way, the CI seems to have never run successfully in the last months:
> https://ci.debian.net/packages/g/gnupg/unstable/amd64/ …)

this appears to be because of uninstallable dependencies; the tests can
really only run on i386 systems or multiarch systems, right?  is wine32
available in amd64?

I don't see any other architectures available at
https://ci.debian.net/packages/g/gnupg/unstable/, and i'm assuming that
the amd64 ci tester isn't multiarch.  or am i misinterpreting something?

--dkg


signature.asc
Description: PGP signature

Bug#819138: ITP: r-bioc-rgraphviz -- GNU R interface with the Graphviz library

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-bioc-rgraphviz
  Version : 2.14.0
  Upstream Author : Kasper Daniel Hansen 
* URL : 
http://bioconductor.org/packages/release/bioc/html/Rgraphviz.html
* License : Eclipse Public License
  Programming Lang: C, R
  Description : GNU R interface with the Graphviz library

This package provides an interface for plotting objects from the
Bioconductor 'graph' package via the Graphviz graphics library.

It is a dependency of MCMCpack (r-cran-mcmcpack) 1.3-5.

Bug#819137: ITP: r-cran-mcmc -- Markov Chain Monte Carlo simulations for GNU R

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-cran-mcmc
  Version : 0.9-4
  Upstream Author : Charles J. Geyer 
* URL : http://www.stat.umn.edu/geyer/mcmc/
* License : MIT
  Programming Lang: C, R
  Description : Markov Chain Monte Carlo simulations for GNU R

Simulates continuous distributions of random vectors using Markov
chain Monte Carlo (MCMC). Users specify the distribution by an R
function that evaluates the log unnormalized density. Algorithms are
random walk Metropolis algorithm (function metrop), simulated
tempering (function temper), and morphometric random walk Metropolis
(Johnson and Geyer, Annals of Statistics, 2012, function
morph.metrop), which achieves geometric ergodicity by change of
variable.

This package is a dependency for r-cran-mcmcpack version 1.3-5.

Bug#819134: mistral: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: mistral
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#819135: gnocchi: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: gnocchi
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#819133: manila: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: manila
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#819132: aodh: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: aodh
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#760813: firmware-b43-installer: Package device detection fails without PCI hardware

[Elliott Mitchell]

found 760813 1:019-2
quit

I should add onto this report.  While not the identifier of the 802.11
core, `lspci -n -d 14e4:` gives:
00:00.0 0600: 14e4:4716 (rev 01)
00:00.1 0600: 14e4: (rev 01)

So looking for PCI device id 4716 should nominally work.

Better tests is to do something like `ls /sys/class/net/wlan?/phy80211`
which will provide an indication if the driver has managed to detect a
802.11 core and loaded (gah! didn't make good observations of the
situation with driver loaded, but firmware absent).

A few more observations:

$ cat /sys/devices/bcma0\:1/manuf
0x4BF
$ cat /sys/devices/bcma0\:1/id
0x812
$ ls /sys/devices/bcma0\:1/net
wlan0

I'll admit checking for 47[0-9][0-9] may well be the simplest solution.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#819131: /usr/share/man/man8/ss.8.gz: ss man page gice wrong location for html

[=]

Package: iproute2
Version: 3.16.0-2
Severity: normal
File: /usr/share/man/man8/ss.8.gz

Dear Maintainer,

man 8 ss gives the wrong info in see also.
it says:

SEE ALSO
   ip(8), /usr/share/doc/iproute-doc/ss.html (package iproutedoc)

but the file name is actually

  /usr/share/doc/iproute2-doc/ss.html

also the package name is "iproute2-doc" (installing iproute-doc also works as
iproute2-doc is a dependancy)



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

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

Versions of packages iproute2 depends on:
ii  libc62.19-19
ii  libdb5.3 5.3.28-9
ii  libselinux1  2.3-2+b1

Versions of packages iproute2 recommends:
pn  libatm1   
ii  libxtables10  1.4.21-2+b1

Versions of packages iproute2 suggests:
ii  iproute2-doc  3.16.0-2

-- no debconf information

Bug#819130: mate-applets: Weather report: bad radar maps

[Kevin Williams]

Package: mate-applets
Version: 1.12.1-1
Severity: normal

Dear Maintainer,

The default radar maps in Weather Report applet are sometimes
inappropriate.  For example, the Springfield, MO radar map shows Springfield at
top-center instead of the center of the map.  While it's possible to specify a
custom radar map instead, finding a suitable one online is difficult because
the easily-found ones tend to require Javascript.

I propose that a good fix might be to add a configuration option to use
a different city's radar map.  In my Springfield, MO example I think the Kansas
City map is more appropriate, so it'd be nice if I could choose to display that
map instead.

Alternatively, perhaps the applet could explain how to pull the desired
map from the source (which appears to be weather.com) so we could find the URL
ourselves, or perhaps the custom field could be auto-populated with the URL for
the current location's default radar map.



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

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

Versions of packages mate-applets depends on:
ii  gir1.2-mate-panel  1.12.2-1
ii  gsettings-desktop-schemas  3.18.1-1
ii  gvfs   1.26.2-1+b1
ii  libatk1.0-02.18.0-1
ii  libc6  2.22-3
ii  libcairo2  1.14.6-1
ii  libcpufreq0008-1
ii  libdbus-1-31.10.8-1
ii  libdbus-glib-1-2   0.106-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.3-3
ii  libgdk-pixbuf2.0-0 2.32.3-1.2
ii  libglib2.0-0   2.46.2-3
ii  libgtk2.0-02.24.30-1
ii  libgtksourceview2.0-0  2.10.5-2
ii  libgtop-2.0-10 2.32.0-1
ii  libice62:1.0.9-1+b1
ii  libmate-desktop-2-17   1.12.1-1
ii  libmate-panel-applet-4-1   1.12.2-1
ii  libmateweather11.12.1-1
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.38.1-1
ii  libpangocairo-1.0-01.38.1-1
ii  libpangoft2-1.0-0  1.38.1-1
ii  libpolkit-gobject-1-0  0.105-14.1
ii  libsm6 2:1.2.2-1+b1
ii  libstartup-notification0   0.12-4
ii  libupower-glib30.99.4-2
ii  libwnck22  2.30.7-5
ii  libx11-6   2:1.6.3-1
ii  libxml22.9.3+dfsg1-1
ii  mate-applets-common1.12.1-1
ii  mate-panel 1.12.2-1
ii  python 2.7.11-1
ii  python-gi  3.18.2-2+b1

Versions of packages mate-applets recommends:
ii  cpufrequtils 008-1
ii  mate-media   1.12.1-1
ii  mate-polkit  1.12.0-3
ii  mate-system-monitor  1.12.1-1

mate-applets suggests no packages.

-- no debconf information

Bug#756664: firmware-b43-installer: Lack of error checking can cause unflagged installation failure

[Elliott Mitchell]

Package: firmware-b43-installer
Version: 1:019-2
Severity: minor

The obvious fix for #756664 should actually fix this issue, but I believe
the proper procedure is to report this as a separate bug.

The error checking during firmware download/installation is incorrect and
missing a few steps.  Notably if `wget` fails (perhaps for running out of
space on /tmp) the postinst script exits with a return code of 0, which
indicates to dpkg that installation was successful, which it isn't.  The
other two steps very likely to fail are `tar` (again space in /tmp) and
b43-fwcutter (misc reasons).

Suggested patch:

--- ./var/lib/dpkg/info/firmware-b43-installer.postinst.orig  2015-04-05 
19:21:07.0 -0700
+++ ./var/lib/dpkg/info/firmware-b43-installer.postinst  2016-03-23 
19:12:46.0 -0700
@@ -24,16 +24,22 @@
 
 if ! wget --timeout=60 
http://www.lwfinger.com/b43-firmware/broadcom-wl-5.100.138.tar.bz2 ; then
echo "Some problem occurred during the firmware download. Please check 
your internet connection."
-   exit 0
+   exit 1
 else
if [ -d /lib/firmware/b43 ]; then
   echo "Deleting old extracted firmware..."
   rm -rf /lib/firmware/b43
fi
 fi
-tar xvjf broadcom-wl-5.100.138.tar.bz2
+if ! tar xvjf broadcom-wl-5.100.138.tar.bz2 ; then
+   echo "Unpacking firmware file failed, unable to continue (is /tmp 
full?)."
  
+   exit 1
+fi
 cd broadcom-wl-5.100.138/linux
-b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o
+if ! b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o ; then
+   echo "Extraction of firmware from wl_apsta.o failed, unable to 
continue."
+   exit 1
+fi
 rm -rf $tmp
 }

Note, small adjustments will be needed if #810161 and/or #819129 are
adopted.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#794451: systemd openafs-client.service causes ordering cycles

[Benjamin Kaduk]

On Wed, 23 Mar 2016, Sergio Gelato wrote:

> This problem actually has an easy and natural solution: add
>
> [Unit]
> DefaultDependencies=no
>
> to openafs-client.service. My testing hasn't revealed any adverse side effects

Thanks for the suggestion.

(bugs.debian.org does not show any reply from me on this bug, which is
surprising since I thought I had replied when it came in ... my apologies
if this is not so.)

I will have a look at the documentation on basic.target to see whether it
pulls in anything that is needed by openafs.

-Ben

Bug#819100: linux-image-4.4.0-1-amd64: Mute and Mic-Mute LEDs no longer work on Thinkpad T410

[Alex Goebel]

In 3.19, the way the kernel handles that button was changed from 
hardware to software. You'll need


options thinkpad_acpi software_mute=0

in modprobe.d/ to get the old behaviour back.

-Alex

Bug#819129: firmware-b43-installer pigs out on /tmp

[Elliott Mitchell]

Package: firmware-b43-installer
Version: 1:019-2
Severity: minor

SSIA.  The installation process first downloads a 13MB tarball into /tmp
and then uncompresses the entirety into /tmp.  50MB may not be that much
space on a desktop or server, but for smaller embedded devices that could
completely exhaust their memory.

The following patch takes care of the worst of the issue:

--- ./var/lib/dpkg/info/firmware-b43-installer.postinst.orig  2015-04-05 
19:21:07.0 -0700
+++ ./var/lib/dpkg/info/firmware-b43-installer.postinst  2016-03-23 
18:44:53.0 -0700
@@ -31,7 +31,7 @@
   rm -rf /lib/firmware/b43
fi
 fi
-tar xvjf broadcom-wl-5.100.138.tar.bz2
+tar xvjf broadcom-wl-5.100.138.tar.bz2 broadcom-wl-5.100.138/linux/wl_apsta.o
 cd broadcom-wl-5.100.138/linux
 b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o
 rm -rf $tmp

Note this will need a bit of adjustment if #810161 is applied.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#800284: ciphersaber: Please migrate a supported debhelper compat level

[SamuelOPH]

Control: tags 800284 patch
Control: tags 800284 pending

Hi,

I uploaded a NMU to 10-day/delay queue yesterday. Feel free to cancel this
upload if needed.

The debian/changelog is:

ciphersaber (0.61-4.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Update DH level to 9 (closes: #800284, #817315).
  * debian/control:
- Depends: Add ${misc:Depends}.
- Standards-Version: Update to 3.9.7.
  * debian/watch:
- Update to version 4 (closes: #529102).
- Use new URL (closes: #449849).

I attached a debdiff.


Samuel Henrique O. P. [samueloph]
Técnico em Informática - UTFPR [2012].
Estudante de Engenharia de Computação - UTFPR.


ciphersaber.debdiff
Description: Binary data

Bug#696811: b43 wlan0 disappears when on battery

[Elliott Mitchell]

Merely a bystander here trying to figure out certain situations from bug
reports.

Why the heck was this filed against firmware-b43-installer?!  This bug
report doesn't appear to have anything to do with the firmware installer.
`powertop` has been suggested, perhaps this might be a kernel bug.  Yet
neither of these is related to the firmware-b43-installer.  Unless you
had reason to believe this was due to the firmware installer installing
corrupt firmware, this should never have been filed against
firmware-b43-installer.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#819128: ant package dependency on jre is not enough

[Daniel Chao]

Package: ant
Version: 1.9.4-3
Severity: normal


The default default dependency of default-jre-headless will result error message
"Unable to locate tools.jar. Expected to find it in 
/usr/lib/jvm/java-7-openjdk/lib/tools.jar"

After I installed openjdk-7-jdk, the message is gone.



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

Kernel: Linux 4.4.0-x86_64-linode63 (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 ant depends on:
ii  default-jre-headless [java7-runtime-headless]2:1.7-52
ii  openjdk-7-jre-headless [java7-runtime-headless]  7u95-2.6.4-1~deb8u1

Versions of packages ant recommends:
ii  ant-optional  1.9.4-3

Versions of packages ant suggests:
pn  ant-doc   
pn  ant-gcj   
ii  openjdk-7-jdk [java-sdk]  7u95-2.6.4-1~deb8u1

-- no debconf information

Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Thanks for your anwser. I understand.

Thanks.

> And I intend to become a contributor (currently working on it).

Thanks, and good luck.

There are of course many ways to be a contributor to Debian that don't
involve formally joining the project and gaining some kind of approved
status.  We have a lot of bugs that could do with investigation and
perhaps need patches writing and testing, for example :-).

Regards,
Ian.

Bug#816042: Don't include in stretch

[Gedalya]

On Mon, 14 Mar 2016 01:56:06 +0100 Jonas Smedegaard wrote:

>
> If noone else cares, I will consider step up and take over maintaining
> this package (but I really would prefer not to do so: I have plenty of
> other packages to look after already).
>
> - Jonas

I see you're preparing a release in git, thank you so much!! Much appreciated.

Bug#819127: Option to follow symlinks to mboxes in rc file

[Sean Whitton]

Package: mairix
Severity: wishlist

Dear maintainer,

The attached patch adds a .mairixrc option "follow_mbox_symlinks" which
causes mairix to follow symlinks to mboxes when indexing.  This
behaviour was disabled by default, with no option to re-enable, in
mairix version 0.22.  This patch does not change the default behaviour
of mairix for users who do not explicitly include "follow_mbox_symlinks"
in their .mairixrc.

I have submitted this patch to upstream's bug tracker, but since
upstream releases infrequently, I propose that this patch be included in
Debian's packaging of mairix.  That's because it's particularly useful
for users of git-annex, of which there are many in Debian's userbase.
It is possible to work around mairix's symlink-skipping behaviour [1],
but a simple configuration file option to restore the old behaviour is
much more practical.

[1] 
https://joeyh.name/blog/entry/moving_my_email_archives_and_packages_to_git-annex/

-- 
Sean Whitton
From: Sean Whitton 
Date: Wed, 23 Mar 2016 17:18:47 -0700
Subject: Option to follow symlinks to mboxes in rc file
Forwarded: https://github.com/rc0/mairix/pull/20

Add .mairixrc option "follow_mbox_symlinks" which allows the user to
restore the behaviour disabled by commit 74ebca5.

This is particularly useful for users of git-annex.  It is possible to
work around mairix's symlink-skipping behaviour [1], but a simple
configuration file option to restore the old behaviour is much more
practical.

This patch does not change the default behaviour of mairix for users who
do not explicitly include "follow_mbox_symlinks" in their .mairixrc.

[1] https://joeyh.name/blog/entry/moving_my_email_archives_and_packages_to_git-annex/
---
 mairix.c | 9 -
 mairix.h | 3 ++-
 mbox.c   | 7 ---
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/mairix.c b/mairix.c
index 09f255b..2ef6a62 100644
--- a/mairix.c
+++ b/mairix.c
@@ -51,6 +51,7 @@ static char *omit = NULL;
 static char *database_path = NULL;
 static enum folder_type output_folder_type = FT_MAILDIR;
 static int skip_integrity_checks = 0;
+static int follow_mbox_symlinks = 0;
 
 enum filetype {
   M_NONE, M_FILE, M_DIR, M_OTHER
@@ -249,6 +250,7 @@ static void parse_rc_file(char *name)/*{{{*/
 }
 else if (!strncasecmp(p, "mh=", 3)) add_folders(_folders, copy_value(p));
 else if (!strncasecmp(p, "mbox=", 5)) add_folders(, copy_value(p));
+else if (!strncasecmp(p, "follow_mbox_symlinks", 20)) follow_mbox_symlinks = 1;
 else if (!strncasecmp(p, "omit=", 5)) add_folders(, copy_value(p));
 
 else if (!strncasecmp(p, "mformat=", 8)) {
@@ -490,6 +492,7 @@ int main (int argc, char **argv)/*{{{*/
   int do_integrity_checks = 1;
   int do_forced_unlock = 0;
   int do_fast_index = 0;
+  int do_mbox_symlinks = 0;
 
   unsigned int forced_hash_key = CREATE_RANDOM_DATABASE_HASH;
 
@@ -617,6 +620,10 @@ int main (int argc, char **argv)/*{{{*/
 do_integrity_checks = 0;
   }
 
+  if (follow_mbox_symlinks) {
+do_mbox_symlinks = 1;
+  }
+
   if (!folder_base) {
 fprintf(stderr, "No folder_base/MAIRIX_FOLDER_BASE set\n");
 exit(2);
@@ -746,7 +753,7 @@ int main (int argc, char **argv)/*{{{*/
   unlock_and_exit(2);
 }
 
-build_mbox_lists(db, folder_base, mboxen, omit_globs);
+build_mbox_lists(db, folder_base, mboxen, omit_globs, do_mbox_symlinks);
 
 any_updates = update_database(db, msgs->paths, msgs->n, do_fast_index);
 if (do_purge) {
diff --git a/mairix.h b/mairix.h
index 2480492..b05c1c6 100644
--- a/mairix.h
+++ b/mairix.h
@@ -357,7 +357,8 @@ int cull_dead_messages(struct database *db, int do_integrity_checks);
 
 /* In mbox.c */
 void build_mbox_lists(struct database *db, const char *folder_base,
-const char *mboxen_paths, struct globber_array *omit_globs);
+const char *mboxen_paths, struct globber_array *omit_globs,
+int do_mbox_symlinks);
 int add_mbox_messages(struct database *db);
 void compute_checksum(const char *data, size_t len, checksum_t *csum);
 void cull_dead_mboxen(struct database *db);
diff --git a/mbox.c b/mbox.c
index ebbfa78..f8bed26 100644
--- a/mbox.c
+++ b/mbox.c
@@ -743,7 +743,8 @@ void glob_and_expand_paths(const char *folder_base,
 /*}}}*/
 
 void build_mbox_lists(struct database *db, const char *folder_base, /*{{{*/
-const char *mboxen_paths, struct globber_array *omit_globs)
+const char *mboxen_paths, struct globber_array *omit_globs,
+int do_mbox_symlinks)
 {
   char **raw_paths, **paths;
   int n_raw_paths, i;
@@ -776,8 +777,8 @@ void build_mbox_lists(struct database *db, const char *folder_base, /*{{{*/
 if (lstat(path, ) < 0) {
   /* can't stat */
 } else {
-  if (S_ISLNK(sb.st_mode)) {
-/* Skip mbox if symlink */
+  if (S_ISLNK(sb.st_mode) && !do_mbox_symlinks) {
+/* Skip mbox if symlink and no follow_mbox_symlinks in mairixrc */
 if (verbose) {
   printf("%s is a link - skipping\n", path);
 }

Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone

[Brian May]

Brian May  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Brian May 
>
> * Package name: tzlocal

Meant to clarify. The source package is tzlocal, the binary
python-tzlocal and python3-tzlocal.

>   Version : 2.1
>   Upstream Author : Lennart Regebro 
> * URL : https://github.com/regebro/tzlocal
> * License : CC0
>   Programming Lang: Python2 and Python3
>   Description : tzinfo object for the local timezone
>
>  This module attempts to fix a glaring hole in pytz, that there is no way to
>  get the local timezone information, unless you know the zoneinfo name, and
>  under several Linux distros that’s hard or impossible to figure out.
>  .
>  With tzlocal you only need to call get_localzone() and you will get a tzinfo
>  object with the local time zone info. On some Unices you will still not get 
> to
>  know what the timezone name is, but you don’t need that when you have the
>  tzinfo file. However, if the timezone name is readily available it will be
>  used.
>  .
>  This package contains the Python 2 module.
>
> This is required for the latest version of apscheduler. I plan to
> maintain it as part of the Debian Python Modules Team.
-- 
Brian May 

Bug#819111: uscan: option for disabling repacking

[James McCoy]

On Wed, Mar 23, 2016 at 09:46:18PM +0100, Jakub Wilk wrote:
> uscan repacks zip and xpi archives automatically, but AFAICS there's no
> option to turn off this feature.

$ uscan --help | grep no-symlink
--no-symlink   Don't call mk-origtargz

The name is a relic from when the only option was setting up a properly
named symlink.  Over the years, as other mechanisms appeared,
--no-symlink remained the magic “off” switch.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#819049: [Pkg-dns-devel] Bug#819049: unbound stopped suddenly.

[Shogo Mori]

Hi, Robert Edmonds

> Does unbound regularly crash for you with this error message, or is this
> the first occurrence?

this is first occurrence.

> My suggestion would be to upgrade the version of unbound that you are
> running. Based on the version number, you are probably running wheezy
> (oldstable). You can install unbound 1.4.22 from wheezy-backports, or by
> upgrading to jessie (stable). If you upgrade to jessie, you can also try
> the very latest upstream version (1.5.8) from jessie-backports.

I use wheezy. If possible, backports doesn't want to use.
It is because of stability concerns. 

You cannot modify the 1.4.17 ?



On Wed, 23 Mar 2016 14:00:08 -0400
Robert Edmonds  wrote:

> Shogo Mori wrote:
> > Hello. Unbound stopped suddenly. condition of occur is unknown.
> > can you fix this problem ?
> > 
> > *log messages
> > Mar  5 07:09:50 dns-cache6 unbound: [3881:b] error: validator: bad event 
> > module_event_reply
> > Mar  5 07:09:50 dns-cache6 unbound: [3881:b] fatal error: 
> > services/outside_network.c:1508: serviced_callbacks: pointer whitelist 
> > fptr_whitelist_serviced_query(p->cb) failed
> 
> Hi, Shogo Mori:
> 
> Does unbound regularly crash for you with this error message, or is this
> the first occurrence?
> 
> This log message is almost identical to the one reported on the
> unbound-users mailing list here:
> 
> https://unbound.net/pipermail/unbound-users/2012-July/002501.html
> 
> The upstream author suggests upgrading to a newer version in that
> thread.
> 
> My suggestion would be to upgrade the version of unbound that you are
> running. Based on the version number, you are probably running wheezy
> (oldstable). You can install unbound 1.4.22 from wheezy-backports, or by
> upgrading to jessie (stable). If you upgrade to jessie, you can also try
> the very latest upstream version (1.5.8) from jessie-backports.
> 
> -- 
> Robert Edmonds
> edmo...@debian.org

Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 00:23:40+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > > You do not even have a right to a reply from a human.
> > 
> > I'm not sure to agree with that.
> 
> There are too many bugs and too few humans to deal with them.  We are
> not able to reply to every bug.  At least, if we prioritised writing a
> reply (even if only a vacuous one) to every bug, there would be other
> more important work that would go undone.
> 
> If you'd like to make a human connection with the project, it is best
> if you do that as a contributor.  Debian has many millions of users,
> and we can't make a personal connection with each one.

Thanks for your anwser. I understand.

And I intend to become a contributor (currently working on it).

Cheers,

-- 
PEB

Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone

[Brian May]

Package: wnpp
Severity: wishlist
Owner: Brian May 

* Package name: tzlocal
  Version : 2.1
  Upstream Author : Lennart Regebro 
* URL : https://github.com/regebro/tzlocal
* License : CC0
  Programming Lang: Python2 and Python3
  Description : tzinfo object for the local timezone

 This module attempts to fix a glaring hole in pytz, that there is no way to
 get the local timezone information, unless you know the zoneinfo name, and
 under several Linux distros that’s hard or impossible to figure out.
 .
 With tzlocal you only need to call get_localzone() and you will get a tzinfo
 object with the local time zone info. On some Unices you will still not get to
 know what the timezone name is, but you don’t need that when you have the
 tzinfo file. However, if the timezone name is readily available it will be
 used.
 .
 This package contains the Python 2 module.

This is required for the latest version of apscheduler. I plan to
maintain it as part of the Debian Python Modules Team.

Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > You do not even have a right to a reply from a human.
> 
> I'm not sure to agree with that.

There are too many bugs and too few humans to deal with them.  We are
not able to reply to every bug.  At least, if we prioritised writing a
reply (even if only a vacuous one) to every bug, there would be other
more important work that would go undone.

If you'd like to make a human connection with the project, it is best
if you do that as a contributor.  Debian has many millions of users,
and we can't make a personal connection with each one.

Thanks,
Ian.

Bug#819125: mini-httpd: password handling functions will segfault on 64-bit archs

[Steve Langasek]

Package: mini-httpd
Version: 1.21-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Hi José,

The Ubuntu autobuilders have detected a problem with your package on 64-bit
architectures.  The code is using the crypt() function, without including
, which means there's an implicit declaration.  Implicit
declarations are treated as returning an int, but crypt returns a pointer. 
This means that on 64-bit architectures the return value will be truncated,
typically resulting in a segfault.

I have only marked this bug as 'important' because I don't know how
important the password handling is to mini-httpd.  Maybe the bug should be
treated as 'serious' or 'grave'.  Regardless, such segfault bugs are treated
as build failures in Ubuntu, so I've applied the attached patch in Ubuntu to
fix the failure.

Thanks for considering the patch.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mini-httpd-1.21/debian/patches/missing-prototypes mini-httpd-1.21/debian/patches/missing-prototypes
--- mini-httpd-1.21/debian/patches/missing-prototypes	1969-12-31 16:00:00.0 -0800
+++ mini-httpd-1.21/debian/patches/missing-prototypes	2016-03-23 17:00:49.0 -0700
@@ -0,0 +1,33 @@
+Description: include missing headers to ensure proper declarations
+ mini_httpd uses several standard C functions without including the proper
+ headers needed to pick up their declarations.  One of these functions,
+ crypt(), returns a pointer.  Failure to include the header means the return
+ type is assumed to be an int, which means the pointer is implicitly cast to
+ an int, which loses data on 64-bit architectures.
+Author: Steve Langasek 
+
+Index: mini-httpd-1.21/mini_httpd.c
+===
+--- mini-httpd-1.21.orig/mini_httpd.c
 mini-httpd-1.21/mini_httpd.c
+@@ -52,6 +52,8 @@
+ #include 
+ #include 
+ #include 
++#include 
++#include 
+ 
+ #include "port.h"
+ #include "match.h"
+Index: mini-httpd-1.21/htpasswd.c
+===
+--- mini-httpd-1.21.orig/htpasswd.c
 mini-httpd-1.21/htpasswd.c
+@@ -15,6 +15,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #define LF 10
+ #define CR 13
diff -Nru mini-httpd-1.21/debian/patches/series mini-httpd-1.21/debian/patches/series
--- mini-httpd-1.21/debian/patches/series	2015-09-14 07:43:55.0 -0700
+++ mini-httpd-1.21/debian/patches/series	2016-03-23 16:58:39.0 -0700
@@ -4,3 +4,4 @@
 03-cgi-php
 fix-makefile
 05-manpage-hyphen
+missing-prototypes

Bug#805089: ITP: s2n -- lightweight implementation of the TLS/SSL protocols

[Daniel Stender]

I want to recheck the project, but basically alive! (= alive ping)

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#808940: ITP: terraform -- tool for managing cloud infrastructure

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#783015: ITP: easea -- EAsy specification of evolutionary algorithms

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#760315: ITP: mesos -- Cluster manager for sharing distributed application frameworks

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#802194: ITP: apache-spark -- lightning-fast cluster computing

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#802805: ITP: otto -- easy development and deployment for cloud platforms

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#783843: ITP: geneva -- high performance parallel optimization library

[Daniel Stender]

Alive!

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#818501: Found a solution to the bug

[Diane Trout]

Attached is a patch that fixes the issue and allows all unit tests to pass.

I committed the quilt patch to a clone of the debian packaging 

It's a pretty simple fix that just changes the inheritance for index.Index. I 
also submitted the fix upstream.

Diane>From d411dd6fe6fb36ccf47bd34b9c680ff8768b2685 Mon Sep 17 00:00:00 2001
From: Diane Trout 
Date: Wed, 23 Mar 2016 16:12:33 -0700
Subject: [PATCH] Add fix-issue532.patch to fix segfaults creating index.Index
 objects

---
 debian/patches/fix-issue532.patch | 18 ++
 debian/patches/series |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 debian/patches/fix-issue532.patch

diff --git a/debian/patches/fix-issue532.patch b/debian/patches/fix-issue532.patch
new file mode 100644
index 000..b64086f
--- /dev/null
+++ b/debian/patches/fix-issue532.patch
@@ -0,0 +1,18 @@
+Author: Diane Trout 
+Bug: https://github.com/PyTables/PyTables/issues/532
+Forwarded: https://github.com/PyTables/PyTables/pull/533
+Description: Fixes segfault when creating Index objects
+ A number of unit tests failed with segfaults due to
+ tables.index.Index not being initialized correctly.
+===
+--- pytables-3.2.2.orig/tables/index.py
 pytables-3.2.2/tables/index.py
+@@ -105,7 +105,7 @@ def _table_column_pathname_of_index(inde
+ _tableColumnPathnameOfIndex = previous_api(_table_column_pathname_of_index)
+ 
+ 
+-class Index(NotLoggedMixin, indexesextension.Index, Group):
++class Index(NotLoggedMixin, Group, indexesextension.Index):
+ """Represents the index of a column in a table.
+ 
+ This class is used to keep the indexing information for columns in a Table
diff --git a/debian/patches/series b/debian/patches/series
index 5900800..f3dfbe6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 0002-Use-system-compression-libs.patch
 0003-Never-use-the-msse2-flag-explicitly.patch
 0004-Do-not-fetch-icons-for-external-web-sites.patch
+fix-issue532.patch
-- 
2.8.0.rc3

Bug#818711: Aria2 bug - Jessie

[Artyom Aleksyuk]

Thank you for the fix, Kartik!
Debian 8 Jessie is still affected with this bug.

Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

[Roger Shimizu]

Dear Ben,

Thanks for your comments!

On Wed, Mar 23, 2016 at 8:47 PM, Ben Hutchings  wrote:
> On Wed, 2016-03-23 at 18:29 +0900, Roger Shimizu wrote:
>> > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
>> >  wrote:
>> > > Roger Shimizu  writes:
>> > > >
>> > > > May I know your comment regarding to this armel/orion5x related bug?
>> > > > I don't know whether qnap also uses MTD to store u-boot related stuff
>> > > > or not. Just guessing it may have the same issue.
>> > > From a quick look at your logs, your mtd device is needing support for
>> > > cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
>> > > it's not available when the mtd chip is probed ?
>> > > Eg missing in the initrd or should be built-in or something like that ?
>> Yes. After appending "cfi_cmdset_0002" to /etc/initramfs-tools/modules,
>> do an "update-initramfs -u", then the MTD becomes probing OK.
>
> I wonder if there's any way we can discover which of these cfi_cmdset
> modules is needed...

I agree.
If initramfs-tools can help to do this, we can safely make those all
to modules without issue.

>
>> And -kirkwood flavour usually takes CONFIG_MTD_CFI_AMDSTD=m
>> while -orion5x flavour usually takes CONFIG_MTD_CFI_AMDSTD=y
>>
>> After merging to -marvell, it should take the superset [0],
>> and set CONFIG_MTD_CFI_AMDSTD=y
>>
>> I'll make this change if nobody is against with it.
> [...]
>
> Please go ahead.  In the longer term I think we ought to make
> initramfs-tools include these, but I don't want the kernel to be tied
> to newer initramfs-tools as that will make backporting very difficult..

Thanks for your understanding!
I know this is just a quick fix. Your initramfs-tools way is final
solution, which just need some time to sort out.

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

Bug#818712: frontend: "pager" doesn't wait/scroll anymore

[Adam Borowski]

On Thu, Mar 24, 2016 at 12:03:31AM +0100, Robert Luberda wrote:
> Adam Borowski writes:
> >> If not, what tool and with what options do you run to perform upgrades?
> > 
> > apt-get -y dist-upgrade
> > 
> According to the apt-get man page the `-y' option causes it to run
> non-interactively, and apt-listchanges has recently started honouring
> this setting, as requested in bug #687443. That's why it forces the
> "text" frontend and disables confirmation.

This sounds wrong to me: the option -y is "assume-yes" rather than
"noninteractive".  Thus, I believe that if someone wants apt-listchanges to
somehow ignore explicitely set frontend, it should be a distinct option
from commonly used -y.

> Is this explanation OK to you, may I close the bug report?

What about having a setting for apt-listchanges instead of piggybacking on a
mostly unrelated apt-get option?

As of 2.86, there's no way to assume-yes on apt while having apt-listchanges
obey the frontend.

-- 
A tit a day keeps the vet away.

Bug#819124: radcli: new upstream release 1.2.5

[Aron Xu]

Package: src:radcli
Severity: wishlist

radcli upstream released 1.2.5 on Nov 28, 2015, major updates:

1. Added TCP support (Aravind Prasad S)
2. Corrected buffer overflow in rc_ipaddr_local()
3. Added nas-ip config file option. That option allows to override the
IP reported by NAS to the radius server.
4. The NAS identifier set in the configuration file will override any
identifier set by the application.

This version is needed for updating ocserv, I can make an NMU if
there's no objection.

Regards,
Aron

Bug#807797: apscheduler: Please package python3 package

[Brian May]

On Sun, Dec 13, 2015 at 04:11:35PM +1100, Brian May wrote:
> Can you please package the Python 3 package? It looks like upstream
> supports Python 3.
> 
> In addition I notice the Debian version is very old, version 3.0.5 is
> current upstream.
> 
> If you want me to: I can change fix the package up and upload as part of
> the Debian Python Modules Team, so you don't have to worry.

No response since December.

I am going to assume that you are not interested in maintaining this
package anymore.

As discussed I will update the package, put it into git, and change the
maintainer to the Debian Python Module Team.

After I upload the new version it will get stuck in the NEW queue for a
while, so there is still time to disagree if you want.

Regards
-- 
Brian May 

Bug#818712: frontend: "pager" doesn't wait/scroll anymore

[Robert Luberda]

Adam Borowski writes:
>> If not, what tool and with what options do you run to perform upgrades?
> 
> apt-get -y dist-upgrade
> 
According to the apt-get man page the `-y' option causes it to run
non-interactively, and apt-listchanges has recently started honouring
this setting, as requested in bug #687443. That's why it forces the
"text" frontend and disables confirmation.

Is this explanation OK to you, may I close the bug report?

Regards,
robert

Bug#818730: [Python-modules-team] Bug#818730: FTBFS in unstable

[Brian May]

Discussion was moved here:
https://lists.debian.org/debian-python/2016/03/msg00070.html

Am about to upload what should be a fix to this problem.
-- 
Brian May 

Bug#819016: jellyfish: Rename python bindings module name

[Diego M. Rodriguez]

An update on the python tests running, not as exhaustive as I'd like due
to having less time available than initially expected: upon closer
inspection, I believe that indeed the python tests at 
swig/python/test*.py are not being currently run during the build, as
hinted on the previous message.

I have tried passing the location of the test folder to unittest using:
export PYBUILD_TEST_ARGS=${CURDIR}/swig/python/
and the tests are picked up during pybuild, although they are erroring
probably due to the library not being still available at that point:

ImportError: libjellyfish-2.0.so.2: cannot open shared object file: No such 
file or directory

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#819119: jessie-pu: package libsndfile/1.0.25-9.1+deb8u1

[Moritz Mühlenhoff]

On Wed, Mar 23, 2016 at 10:11:32PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2016-03-23 at 22:56 +0100, Moritz Muehlenhoff wrote:
> > Another update for no-dsa security issues, this time in libsndfile.
> > The patches have been used in unstable for over four months, the
> > extensive test suite passes and I made additional functionality tests
> > with the resulting build.
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
Moritz

Bug#819122: elixir-lang: fails to auto-build: epmd process left running

[Steve Langasek]

Source: elixir-lang
Version: 1.1.0-1
Severity: serious

The elixir-lang package, when autobuilt, will successfully spit out a binary
package.  However, on many (most?) autobuild setups, the build will never
complete.  The reason for this is that the build launches an 'epmd' process
in the background, which it never cleans up, and this process keeps its
stdout open.  So any autobuild harness that waits for the end of data will
wait indefinitely.

A good fix for this would be to launch epmd from a script that keeps track
of its pid and kills it at the end of the test.  A lesser fix would be to
just redirect epmd's stdout/stderr to /dev/null so that it isn't holding
pipes open.

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


signature.asc
Description: Digital signature

Bug#819123: Please integrate vCard access restriction patch

[PF4Public]

Package: ejabberd
Version: 16.02-2

Please integrate vCard access restriction patch as Debian patch until it is integrated 
into mainline ejabberd.
As far as I can tell, the patch is maintained at 
https://support.process-one.net/browse/EJAB-797 as well as it was updated to latest 
ejabberd source recently.

Bug#784578: xbmc: Can't play DVDs from nfs or samba shares

[Bálint Réczey]

Hi Jonathan,

2016-03-15 0:01 GMT+01:00 Jonathan McCrohan :
...
> Hi,
>
> It appears that this bug (or similar) is now affecting all DVD playback
> in Kodi 16.
>
> The following fails:
> 1) playback from physical DVD disc
> 2) playback from ISO file on local filesystem
> 3) playback from SMB share via add video source within Kodi
> 4) playback from SMB share mounted via /etc/fstab
>
> Upon attempting to play DVDs via any of the methods above, the GUI
> simply appears as "Working...", and the DVDPlayer thread uses 100% CPU
> on one core. The GUI becomes unresponsive, and must be killed by sending
> SIGKILL.
I have just uploaded 16.0+dfsg1-2 which restored ability to play DVDs for most
use cases. 2) is still broken.

Cheers,
Balint

Bug#819121: ufraw: new version available 0.22

[Antoine Pardigon]

Package: ufraw
Version: 0.20-3+b1
Severity: wishlist

Dear Maintainer,

a newer version has been out since middle of last year. It supports Raw
files from additional cameras (and corrects security bug CVE-2015-3885)

Please consider packaging the new version ?

Best regards,

-- 
Antoine


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

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

Versions of packages ufraw depends on:
ii  desktop-file-utils   0.22-1
ii  libatk1.0-0  2.18.0-1
ii  libbz2-1.0   1.0.6-8
ii  libc62.22-3
ii  libcairo21.14.6-1
ii  libexiv2-14  0.25-2.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.3-3
ii  libgcc1  1:5.3.1-12
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.46.2-3
ii  libgomp1 5.3.1-12
ii  libgtk2.0-0  2.24.30-1
ii  libgtkimageview0 1.6.4+dfsg-1
ii  libjpeg62-turbo  1:1.4.2-2
ii  liblcms2-2   2.6-3+b3
ii  liblensfun0  0.2.8-3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libpng12-0   1.2.54-4
ii  libstdc++6   5.3.1-12
ii  libtiff5 4.0.6-1
ii  ufraw-batch  0.20-3+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

ufraw recommends no packages.

Versions of packages ufraw suggests:
ii  gimp-ufraw  0.20-3+b1

-- no debconf information

Bug#819120: google-glog: FTBS on x32

[Guillaume Morin]

Package: google-glog
Tags: ftbfs-x32, patch

google-glog fails to build form source on x32, see
https://buildd.debian.org/status/package.php?p=google-glog=sid

The error is:
src/symbolize_unittest.cc: Assembler messages:
src/symbolize_unittest.cc:301: Error: operand type mismatch for `pop'
make[1]: *** [src/symbolize_unittest-symbolize_unittest.o] Error 1

This patch fixes the build failure:

--- a/src/symbolize_unittest.cc
+++ b/src/symbolize_unittest.cc
@@ -290,16 +290,24 @@
 inline void* always_inline inline_func() {
   register void *pc = NULL;
 #ifdef TEST_X86_32_AND_64
+#if __x86_64__ || (__x86_64__ && __ILP32__)
+  __asm__ __volatile__("call 1f; 1: popq %q0" : "=r"(pc));
+#else
   __asm__ __volatile__("call 1f; 1: pop %0" : "=r"(pc));
 #endif
+#endif
   return pc;
 }
 
 void* ATTRIBUTE_NOINLINE non_inline_func() {
   register void *pc = NULL;
 #ifdef TEST_X86_32_AND_64
+#if __x86_64__ || (__x86_64__ && __ILP32__)
+  __asm__ __volatile__("call 1f; 1: popq %q0" : "=r"(pc));
+#else
   __asm__ __volatile__("call 1f; 1: pop %0" : "=r"(pc));
 #endif
+#endif
   return pc;
 }
 
Thanks

-- 
Guillaume Morin 

Bug#818688: Processed: severity of 818688 is important

[Eduard Bloch]

reopen 818688
tags 818688 +moreinfo +unreproducible
thanks

As said, someone, please send logs and cache information! Cannot help
otherwise.

Bug#813027: libpng1.6: diff for NMU version 1.6.20-3

[Gianfranco Costamagna]

control: tags -1 patch pending

Hi, I'm uploading this debdiff to deferred/7.

I might cancel/reupload if I find some issues, but the changes since the 
previous version are:

move libpng16-dev to libpng-dev, so providing a real package.

cheers,

G.

On Wed, 16 Mar 2016 16:30:26 + (UTC) Gianfranco Costamagna 
 wrote:
> Hi, since the transition is almost ready, I would like to upload this debdiff 
> ASAP,
> with your ack or your changes.
> 
> the situation is:
> - transition mostly ready (2 deferred/5 uploads, so this upload can wait 
> something like a week or so)
>   FTBFS are blocked by others RC bugs, or with patches, that we can upload 
> later.
> 
> - I changed the previous debdiff to provide the library in /lib (for the udeb 
> package)
>   and dropped some Conflicts: keywords
> - release team is waiting for an ack for [1].
> do you want a real package, or the provides is fine?
> 
> AFAIK you was going for the Provides, so we should uncomment that line and 
> upload on experimental.
> And then wait again for an ack.
> 
> Does it sounds ok to you?
> 
> I really would like to do an upload in a week if possible, so we can ask for 
> an ack before the end of next week.
> 
> 
> (in that case we would have a lot of time before Stretch freeze, I would like 
> to avoid doing things when the freeze
> is approaching)
> 
> 
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#823
> 
> cheers,
> 
> Gianfranco
diff -Nru libpng1.6-1.6.20/debian/changelog libpng1.6-1.6.20/debian/changelog
--- libpng1.6-1.6.20/debian/changelog   2016-01-28 11:34:00.0 +0100
+++ libpng1.6-1.6.20/debian/changelog   2016-03-23 22:29:21.0 +0100
@@ -1,3 +1,26 @@
+libpng1.6 (1.6.20-3) experimental; urgency=medium
+
+  * Team upload
+  * Move libpng16-dev to libpng-dev, to ease next transitions.
+  * Drop conflicts against mzscheme, pngcrush, pngmeta,
+povray-3.5, qemacs, some of them disappeared, some of
+them have later versions already in old-oldstable.
+  * Simplify even more the packaging, probably fixing #813288
+  * Fix symlinks, and two lintian errors:
+- library-in-root-and-usr
+- old-style-config-script-multiarch-path
+  (multiarch: no for libpng16-devtools)
+  * Update standard-version to 3.9.7, no changes required.
+  * Switch to dh-autoreconf (Closes: #813027)
+  * Remove libpng16-devtools circular dependency, recommend it instead.
+  * Fix duplicate description lintian warning
+  * Fix copyright lintian warnings
+  * Remove copyright.in file
+  * Use new plain dh calls in rules file
+  * Remove some old lintian overrides.
+
+ -- Gianfranco Costamagna   Wed, 16 Mar 2016 
17:05:08 +0100
+
 libpng1.6 (1.6.20-2) experimental; urgency=medium
 
   [ Tobias Frost ]
diff -Nru libpng1.6-1.6.20/debian/clean libpng1.6-1.6.20/debian/clean
--- libpng1.6-1.6.20/debian/clean   1970-01-01 01:00:00.0 +0100
+++ libpng1.6-1.6.20/debian/clean   2016-03-23 22:06:57.0 +0100
@@ -0,0 +1 @@
+pngtest-static
diff -Nru libpng1.6-1.6.20/debian/control libpng1.6-1.6.20/debian/control
--- libpng1.6-1.6.20/debian/control 2016-01-28 11:32:25.0 +0100
+++ libpng1.6-1.6.20/debian/control 2016-03-23 22:30:57.0 +0100
@@ -3,15 +3,13 @@
 Priority: optional
 Maintainer: Anibal Monsalve Salazar 
 Uploaders: Nobuhiro Iwamatsu 
-Build-Depends: debhelper (>= 9), zlib1g-dev, mawk, autotools-dev
-Standards-Version: 3.9.6
+Build-Depends: debhelper (>= 9), zlib1g-dev, mawk, dh-autoreconf
+Standards-Version: 3.9.7
 Homepage: http://libpng.org/pub/png/libpng.html
 
 Package: libpng16-16
-Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: mzscheme (<= 1:209-5), pngcrush (<= 1.5.10-2), pngmeta (<= 1.11-3), 
qemacs (<= 0.3.1-5), povray-3.5 (<= 3.5.0c-10)
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
 Description: PNG library - runtime (version 1.6)
@@ -21,14 +19,14 @@
  This package contains the runtime library files needed to run software
  using libpng.
 
-Package: libpng16-dev
+Package: libpng-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, libpng16-16 (= ${binary:Version}), zlib1g-dev, 
libpng16-devtools (= ${binary:Version})
+Depends: ${misc:Depends}, libpng16-16 (= ${binary:Version}), zlib1g-dev
+Breaks: libpng16-dev (<< 1.6.20-3)
 Conflicts: libpng12-dev, libpng12-0-dev, libpng3-dev, libpng2-dev
-Replaces: libpng12-dev, libpng12-0-dev, libpng3-dev, libpng2-dev
-#Provides: libpng-dev
-Recommends: libpng16-tools
+Replaces: libpng16-dev (<<1.6.20-3), libpng12-dev, libpng12-0-dev, 
libpng3-dev, libpng2-dev
+Recommends: libpng16-tools, libpng16-devtools
 Multi-Arch: same
 Description: PNG library - development (version 1.6)
  libpng is a library implementing an interface for reading and writing
@@ -40,12 +38,12 @@
 Package: libpng16-devtools
 Section: libdevel
 Architecture: any
-Multi-Arch: same
-Depends: 

Bug#818615: jessie-pu: package gtk+2.0

[Moritz Mühlenhoff]

tags 818615 -moreinfo
thanks

On Tue, Mar 22, 2016 at 07:56:40PM +, Adam D. Barratt wrote:
> On Fri, 2016-03-18 at 20:58 +0100, Salvatore Bonaccorso wrote:
> > HI Adam,
> > 
> > Not Moritz here but can answer the question as well:
> > 
> > On Fri, Mar 18, 2016 at 07:22:34PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Fri, 2016-03-18 at 19:33 +0100, Moritz Muehlenhoff wrote:
> > > > I'd like to fix a security issue in GTK, which doesn't really warrant
> > > > a DSA. Debdiff below, I've been running this on my jessie
> > > > workstation for a day now.
> > > > 
> > > > Cheers,
> > > > Moritz
> > > > 
> > > > diff -Nru gtk+2.0-2.24.25/debian/changelog 
> > > > gtk+2.0-2.24.25/debian/changelog
> > > > --- gtk+2.0-2.24.25/debian/changelog2015-03-03 19:39:59.0 
> > > > +0100
> > > > +++ gtk+2.0-2.24.25/debian/changelog2016-03-17 23:20:16.0 
> > > > +0100
> > > > @@ -1,3 +1,9 @@
> > > > +gtk+2.0 (2.24.25-3+deb8u1) jessie; urgency=medium
> > > > +
> > > > +  * CVE-2013-7447 (Closes: #799275)
> > > 
> > > The Security Tracker suggests that this isn't fixed in the version of
> > > gtk+2.0 in unstable; is that correct?
> > 
> > Yes it is as well unfixed there. I just have proposed a NMU in
> > https://bugs.debian.org/799275#39
> 
> Thanks for that.
> 
> If we don't notice, please feel free to remove the "moreinfo" tag once
> the NMU reaches unstable.

This is now in unstable:
https://packages.qa.debian.org/g/gtk+2.0/news/20160323T215045Z.html

Cheers,
Moritz

Bug#819119: jessie-pu: package libsndfile/1.0.25-9.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2016-03-23 at 22:56 +0100, Moritz Muehlenhoff wrote:
> Another update for no-dsa security issues, this time in libsndfile.
> The patches have been used in unstable for over four months, the
> extensive test suite passes and I made additional functionality tests
> with the resulting build.

Please go ahead.

Regards,

Adam

Bug#819116: [Pkg-xfce-devel] Bug#819116: light-locker: Mouse Pointer goes invisible after login with xfce4

[Yves-Alexis Perez]

On mer., 2016-03-23 at 16:31 +0100, Don Jajo wrote:
> 
> Dear Maintainer,
> 
> After system being idle and screen goes blank, resuming the screen and
> unlocking, the mouse pointer goes invisible but works. i.e. you can click,
> scroll and double click but with invisible mouse pointer.
> 
> Had to logout and login again make it appear again.

It's unlikely to be an issue in light-locker. Assuming you have an Intel
graphics card, it looks like #819083.

Regards,
-- 
Yves-Alexis



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

Bug#819100: linux-image-4.4.0-1-amd64: Mute and Mic-Mute LEDs no longer work on Thinkpad T410

[Ben Hutchings]

On Wed, 2016-03-23 at 21:32 +, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Wed, 2016-03-23 at 18:53 +, Tim Wootton wrote:
> > 
> > Package: src:linux
> > Version: 4.4.6-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >    * What led up to the situation?
> > Upgrade from jessie to stretch
> >    * What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > Pressing Thnkpad T410's hardware speaker mute button
> >    * What was the outcome of this action?
> > Speaker mutes, but the button's LED does not illuminate
> >    * What outcome did you expect instead?
> > Expected the LED to illuminate
> > 
> > The mic mute button also exhibits the same behavior, but I had not
> > tried this under jessie so don't know if it worked before.
> It hasn't worked for me on the quite similar T420.
> 
> > 
> >  The speaker mute certainly did.
> [...]
> 
> As far as the kernel is concerned, the mute button is just an ordinary
> key on the keyboard (you can see this with the evtest program).  You
> need a userland daemon to act on it (such as pulseaudio).

Actually I'm not sure that's entirely true - I think that initially the
firmware (BIOS) handles the mute button itself, but software can take
responsibility for it.

There are some hints here for debugging and working around this:
https://wiki.archlinux.org/index.php/ThinkPad:_Mute_button

Let us know if any of that helps.

Ben.

> What desktop environment are you using?


-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

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

Bug#650601: libpng is going to be NMUed soon.

[Emilio Pozuelo Monfort]

On 23/03/16 22:42, Gianfranco Costamagna wrote:
> Hi,
> 
>> So what is it that you're talking about? Adding a real libpng-dev package?
> 
> 
> 
> exactly.
> This was one of the open points, and my opinion is to have a real libpng-dev
> package.
> 
> I can of course revert if you don't like it, but as explained before, we might
> have less troubles with it, if I understand correctly.

OK. I don't have a strong preference, so feel free to go that way. Just wanted
to make sure I understood what you were doing.

Cheers,
Emilio

Bug#819119: jessie-pu: package libsndfile/1.0.25-9.1+deb8u1

[Moritz Muehlenhoff]

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

Another update for no-dsa security issues, this time in libsndfile.
The patches have been used in unstable for over four months, the
extensive test suite passes and I made additional functionality tests
with the resulting build.

Debdiff below.

Cheers,
Moritz

diff -Nru libsndfile-1.0.25/debian/changelog libsndfile-1.0.25/debian/changelog
--- libsndfile-1.0.25/debian/changelog  2015-01-26 02:32:12.0 +0100
+++ libsndfile-1.0.25/debian/changelog  2016-03-23 22:40:07.0 +0100
@@ -1,3 +1,12 @@
+libsndfile (1.0.25-9.1+deb8u1) jessie; urgency=medium
+
+  * Fix denial of service through division by zero (CVE-2014-9756)
+-> 03_file_io_divide_by_zero.diff (Closes: #804447)
+  * Fix heap overflow in AIFF parser (CVE-2015-7805)
+-> 04_fix_aiff_heap_overflow.diff (Closes: #804445)
+
+ -- Moritz Mühlenhoff   Wed, 23 Mar 2016 00:34:11 +0100
+
 libsndfile (1.0.25-9.1) unstable; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru libsndfile-1.0.25/debian/patches/03_file_io_divide_by_zero.diff 
libsndfile-1.0.25/debian/patches/03_file_io_divide_by_zero.diff
--- libsndfile-1.0.25/debian/patches/03_file_io_divide_by_zero.diff 
1970-01-01 01:00:00.0 +0100
+++ libsndfile-1.0.25/debian/patches/03_file_io_divide_by_zero.diff 
2016-03-23 22:29:46.0 +0100
@@ -0,0 +1,22 @@
+commit 725c7dbb95bfaf8b4bb7b04820e3a00cceea9ce6
+Author: Erik de Castro Lopo 
+Date:   Wed Dec 24 21:02:35 2014 +1100
+
+src/file_io.c : Prevent potential divide-by-zero.
+
+Closes: https://github.com/erikd/libsndfile/issues/92
+
+Index: libsndfile-1.0.25/src/file_io.c
+===
+--- libsndfile-1.0.25.orig/src/file_io.c
 libsndfile-1.0.25/src/file_io.c
+@@ -358,6 +358,9 @@
+ { sf_count_t total = 0 ;
+   ssize_t count ;
+ 
++  if (bytes == 0 || items == 0)
++  return 0 ;
++
+   if (psf->virtual_io)
+   return psf->vio.write (ptr, bytes*items, psf->vio_user_data) / 
bytes ;
+ 
diff -Nru libsndfile-1.0.25/debian/patches/04_fix_aiff_heap_overflow.diff 
libsndfile-1.0.25/debian/patches/04_fix_aiff_heap_overflow.diff
--- libsndfile-1.0.25/debian/patches/04_fix_aiff_heap_overflow.diff 
1970-01-01 01:00:00.0 +0100
+++ libsndfile-1.0.25/debian/patches/04_fix_aiff_heap_overflow.diff 
2016-03-23 22:29:53.0 +0100
@@ -0,0 +1,18 @@
+commit e4a75172f83894a4e821807b6d94770095ddaeff
+Author: Erik de Castro Lopo 
+Date:   Mon Nov 9 22:10:35 2015 +1100
+
+diff --git a/src/common.c b/src/common.c
+index 8aadbab..543c2c8 100644
+--- a/src/common.c
 b/src/common.c
+@@ -805,7 +805,8 @@ header_read (SF_PRIVATE *psf, void *ptr, int bytes)
+   if (psf->headindex + bytes > SIGNED_SIZEOF (psf->header))
+   {   int most ;
+ 
+-  most = SIGNED_SIZEOF (psf->header) - psf->headindex ;
++  most = SIGNED_SIZEOF (psf->header) - psf->headend ;
++
+   psf_fread (psf->header + psf->headend, 1, most, psf) ;
+   memset ((char *) ptr + most, 0, bytes - most) ;
+ 
diff -Nru libsndfile-1.0.25/debian/patches/series 
libsndfile-1.0.25/debian/patches/series
--- libsndfile-1.0.25/debian/patches/series 2015-01-26 02:31:39.0 
+0100
+++ libsndfile-1.0.25/debian/patches/series 2016-03-23 22:30:30.0 
+0100
@@ -1,3 +1,5 @@
 00lossy_comp_test-overflow.diff
 01_sd2_rsrc_segfault.diff
 CVE-2014-9496.patch
+03_file_io_divide_by_zero.diff
+04_fix_aiff_heap_overflow.diff

Bug#819118: lua5.2: incorrect version number in lua.pc.in

[Heinrich Schuchardt]

Package: lua5.2
Version: 5.2.4-1
Severity: normal

http://http.debian.net/debian/pool/main/l/lua5.2/lua5.2_5.2.4-1.debian.tar.xz
has files lua.pc.in, lua-c++.pc.in which still refer to version 5.1 of lua.

Please, update the version number to match the package.

Best regards

Heinrich Schuchardt

Bug#819028: menu: Menu doesn't update automagically

[Bill Allombert]

On Wed, Mar 23, 2016 at 03:21:16AM +0100, Suppositoire wrote:
> Package: menu
> Version: 2.1.47
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> Trying to install darktable package (and some others packages few days ago, 
> same problem), the problem seems to also affect Ubuntu 15.10 (according to a 
> friend using it)
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 1°/ Synaptic -> install darktable -> no menu entry for darktable
> 2°/ Terminal -> update-menus -> menu entry for darktable created
> 3°/ Synaptic -> uninstall darktable -> menu entry updated, darktable removed
> 
> 4°/ Synaptic -> install darktable -> no menu entry for darktable
> 5°/ Terminal -> update-menus -> menu entry for darktable created

Hello, could you check in /var/log/dpkg.log which version of 
darktable was installed each time ?
Are you sure it was the same ?

Since you use xfce, are you sure the Debian menu system and not
the XDG menu system ?

Thanks for using Debian!
-- 
Bill. 

Imagine a large red swirl here. 

Bug#819050: Please leave the severity at serious, this bug is a security issue.

[Hilko Bengen]

control: tag -1 security
control: severity -1 serious

Hi Matthew,

the original report may not have been 100% clear on this, but the bug is
the main cause of a vulnerability in Suricata (a network IDS/IPS) that
allows for remote denial of service, possibly remote code execution by
simply passing crafted packets by a Suricata installation.

Cheers,
-Hilko

Bug#759972: php-xml-serializer: FTBFS: tests failed

[Antonio Ospite]

Package: php-xml-serializer
Version: 0.20.2-3
Followup-For: Bug #759972

Dear Maintainer,

about the original failure reporded by Lucas (sometimes entities in
attributes get escaped twice), I am trying to get in touch with the
upstream author, see the last comment on
http://pear.php.net/bugs/bug.php?id=15602

About the 6 failures observed by Prach, they may be caused by a change
in how PHPUnit passes the include path, as the errors are basically:

  Fatal error: require_once(): Failed opening required
  'XML/Unserializer.php'
  (include_path='.:/usr/share/php:/usr/share/pear') in - on line 2'


By changing the way the test are run, i.e.:

  diff --git a/debian/tests_run b/debian/tests_run
  index 5c04a0d..ef007fa 100755
  --- a/debian/tests_run
  +++ b/debian/tests_run
  @@ -1,11 +1,9 @@
   #!/bin/sh

   set -e

   pear_pkg=`ls | grep XML_Serializer`

   cd ${pear_pkg}
  -PKG_ROOT=`pwd`
  -cd tests
  -
  -phpunit -d include_path=".:/usr/share/php:${PKG_ROOT}" AllTests.php
  +phpunit tests/AllTests.php


the tests _run_ correctly, however they would still fail because
deprecated syntax warnings pollute the output.

I have fixes for the deprecation warnings but I am waiting for the
upstream to comment on the double escape issue.

I'll report back whan I have more info.

Ciao ciao,
   Antonio


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

Kernel: Linux 4.5.0-rc7-ao2 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages php-xml-serializer depends on:
ii  php-pear1:1.10.1+submodules+notgz-6
ii  php-xml-parser  1.3.6-1

php-xml-serializer recommends no packages.

Versions of packages php-xml-serializer suggests:
ii  php5-cli  5.6.19+dfsg-2

-- no debconf information
-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

[Pierre-Elliott Bécue]

Control: owner -1 !
Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID 
Protocol (Mozilla Persona)

Hey,

I intend to package. VCS is up, the package builds correctly.

VCS: https://github.com/P-EB/python-browserid
Build results: https://peb.pimeys.fr/packages/python-browserid/

Comments welcome, and if everything seems okay, please, I'd like to request
for sponsorship on this package.

-- 
PEB

Bug#650601: libpng is going to be NMUed soon.

[Gianfranco Costamagna]

Hi,

>So what is it that you're talking about? Adding a real libpng-dev package?



exactly.
This was one of the open points, and my opinion is to have a real libpng-dev
package.

I can of course revert if you don't like it, but as explained before, we might
have less troubles with it, if I understand correctly.



sorry for not being clear,

Gianfranco

Bug#697062: s390x porting attempt

[dann frazier]

I made an attempt at fixing the s390x port by cargo culting what has
been done for other architectures. With this patch, I can connect to
the server and start an icewm desktop. However, the screen is still
pretty corrupted - text is offset, etc. See the attached screenshot.
Index: tightvnc-1.3.10/Xvnc/include/Xmd.h
===
--- tightvnc-1.3.10.orig/Xvnc/include/Xmd.h
+++ tightvnc-1.3.10/Xvnc/include/Xmd.h
@@ -59,7 +59,7 @@ SOFTWARE.
 #ifdef CRAY
 #define WORD64/* 64-bit architecture */
 #endif
-#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__) || defined(__aarch64__)
+#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__) || defined(__aarch64__) || defined(__s390x__)
 #define LONG64/* 32/64-bit architecture */
 #endif
 #ifdef __sgi
Index: tightvnc-1.3.10/Xvnc/programs/Xserver/include/servermd.h
===
--- tightvnc-1.3.10.orig/Xvnc/programs/Xserver/include/servermd.h
+++ tightvnc-1.3.10/Xvnc/programs/Xserver/include/servermd.h
@@ -464,6 +464,26 @@ SOFTWARE.
 
 #endif /* Linux/PPC */
 
+#if defined (linux) && defined(__s390x__)
+#  define BITMAP_SCANLINE_UNIT			64
+# define BITMAP_SCANLINE_PAD 			64
+# define LOG2_BITMAP_PAD			6
+# define LOG2_BYTES_PER_SCANLINE_PAD		3
+
+/* Add for handling protocol XPutImage and XGetImage; see comment in
+ * Alpha section.
+ */
+#define INTERNAL_VS_EXTERNAL_PADDING
+#define BITMAP_SCANLINE_UNIT_PROTO		32
+
+#define BITMAP_SCANLINE_PAD_PROTO 	 	32
+#define LOG2_BITMAP_PAD_PROTO			5
+#define LOG2_BYTES_PER_SCANLINE_PAD_PROTO	2
+/*#define GLYPHPADBYTES  4
+  #define GETLEFTBITS_ALIGNMENT  1*/
+
+#endif /* linux/s390x */
+
 #if defined (linux) && defined(__sparc__)
 
 #define IMAGE_BYTE_ORDER   MSBFirst
Index: tightvnc-1.3.10/Xvnc/config/cf/Imake.cf
===
--- tightvnc-1.3.10.orig/Xvnc/config/cf/Imake.cf
+++ tightvnc-1.3.10/Xvnc/config/cf/Imake.cf
@@ -700,6 +700,10 @@ XCOMM Keep cpp from replacing path eleme
 #   define s390Architecture
 #  undef __s390__
 # endif /* s390 */
+# ifdef __s390x__
+#   define s390xArchitecture
+#  undef __s390x__
+# endif /* s390x */
 # ifdef __aarch64__
 #  define AArch64Architecture
 #  undef __aarch64__
Index: tightvnc-1.3.10/Xvnc/config/cf/linux.cf
===
--- tightvnc-1.3.10.orig/Xvnc/config/cf/linux.cf
+++ tightvnc-1.3.10/Xvnc/config/cf/linux.cf
@@ -291,10 +291,10 @@ XCOMM binutils:	(LinuxBinUtilsMajorVersi
 #endif /* s390Architecture */
 
 #ifdef s390xArchitecture
-#define OptimzedCDebugFlags	-O2
+#define OptimizedCDebugFlags	-O2
 #define LinuxMachineDefines	-D__s390x__
 #define ServerOSDefines		XFree86ServerOSDefines -DDDXTIME -DPART_NET
-#define ServerExtraDefines	-DGCCUSESGAS XFree86ServerDefines
+#define ServerExtraDefines	-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64
 #endif /* s390xArchitecture */
 
 #ifdef Ppc64Architecture

Bug#815788: jessie-pu: package exactimage/0.8.9-7+deb8u2

[Sven Eckelmann]

On Wednesday 23 March 2016 21:27:02 Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2016-02-24 at 14:10 +0100, Sven Eckelmann wrote:
> > I'd like to upload a new version of exactimage to stable/jessie.
> > 
> > The exactimage package version in jessie is 0.8.9-7+deb8u1 at the moment.
> > It was noticed that it is also affected by the security issue described
> > in CVE-2015-8366 [1] (no-DSA [2]). This issue was resolved in
> > libraw/jessie by an upload via jessie-pu [3].
> 
> Please go ahead.

Uploaded.

Thanks,
Sven

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

Bug#807274: wheezy-pu: package ca-certificates/20130119+deb7u2

[Adam D. Barratt]

On Mon, 2016-02-22 at 16:03 -0600, Michael Shuler wrote:
> This Wheezy package is going to suffer from the same regression as in
> Jessie, currently. Please, leave this bug report in "moreinfo", if
> that's OK, or just close this and I'll open a new report. I will need to
> create an updated diff that includes the removed 1024-bit CA
> certificates, once I'm sure that's working correctly in Jessie.

Where are we with that, both for wheezy and jessie?

Regards,

Adam

Bug#819100: linux-image-4.4.0-1-amd64: Mute and Mic-Mute LEDs no longer work on Thinkpad T410

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 2016-03-23 at 18:53 +, Tim Wootton wrote:
> Package: src:linux
> Version: 4.4.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> Upgrade from jessie to stretch
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Pressing Thnkpad T410's hardware speaker mute button
>    * What was the outcome of this action?
> Speaker mutes, but the button's LED does not illuminate
>    * What outcome did you expect instead?
> Expected the LED to illuminate
> 
> The mic mute button also exhibits the same behavior, but I had not
> tried this under jessie so don't know if it worked before.

It hasn't worked for me on the quite similar T420.

>  The speaker mute certainly did.
[...]

As far as the kernel is concerned, the mute button is just an ordinary
key on the keyboard (you can see this with the evtest program).  You
need a userland daemon to act on it (such as pulseaudio).  What desktop
environment are you using?

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.


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

Bug#819040: insserv: Symlinked init script in /etc/init.d/ fails to be recognised on reboot.

[Felipe Sateler]

On 23 March 2016 at 18:18, Brett Ryan  wrote:
>
>
>> On 24 Mar 2016, at 08:04, Felipe Sateler  wrote:
>>
>> (please don't top-post)
>>
>>> On 23 March 2016 at 18:02, Brett Ryan  wrote:
>>> Interesting. Does that mean if /usr is mounted separately that it would 
>>> also cause init to fail?
>>
>> Only if you do not use an initramfs. If you use a stock debian kernel
>> and initramfs, then you are alright.
>
> So how is /opt different if in the same order?

Christian Seiler did some nice writeup of why some filesystems are
feasibly mounted in the initramfs and others don't:
https://lists.freedesktop.org/archives/systemd-devel/2016-February/035812.html

-- 

Saludos,
Felipe Sateler

Bug#650601: libpng is going to be NMUed soon.

[Emilio Pozuelo Monfort]

On 23/03/16 22:23, Gianfranco Costamagna wrote:
> Hi,
> 
>> WDYM with versioned depends?
> 
> 
> as said above:
> "a/ virtual provides can't safisfy versioned dependencies"
> 
> maintainers might be able to do something like "Depends: libpng-dev (>=1.6)".
> This might help future transitions (not from 12 to 16 probably).
> 
> Always if I understand correctly what maintainers might want to do.
> And makes easier to pull the trigger, avoding two uploads at the same time 
> and some rebuilds
> possibly.

So what is it that you're talking about? Adding a real libpng-dev package?

Cheers,
Emilio

Bug#819117: ITP: berkshelf-api -- A server which indexes cookbooks from various sources and hosts it over a REST API

[Hleb Valoshka]

Package: wnpp
Severity: wishlist
Owner: Hleb Valoshka <375...@gmail.com>

* Package name: berkshelf-api
  Version : 2.1.3
  Upstream Author : Jamie Winsor , Andrew Garson 

* URL : https://github.com/berkshelf/berkshelf-api
* License : Apache 2.0
  Programming Lang: ruby
  Description : A server which indexes cookbooks from various sources and 
hosts it over a REST API

We need it mostly as build-dependency for ruby-berkshelf-api, which is a 
dependency for berkshelf.

Bug#818225: wheezy-pu: package exim4/4.80-7+deb7u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-03-14 at 21:28 +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Mar 14, 2016 at 09:12:13PM +0100, Salvatore Bonaccorso wrote:
[...]
> > The recent DSA had a defective backported patch applied for the
> > wheezy-security upload. Apologies it slept trough on the review, so I
> > propose the attached debdiff to fix this in wheezy via the last point
> > release (the issue is not severe enought to do a follow up DSA).
> > 
> > Fine with that upload?
> 
> For reference, these are the upstream commits:
> 
> https://github.com/Exim/exim/commit/8527598de8b3d09642371e09f1c24d8178f445db
> https://github.com/Exim/exim/commit/b33c6383718d5978cb87a18878e652e675adc88e

Assuming that the issue doesn't also apply to the package in unstable,
please go ahead.

Regards,

Adam

Bug#815788: jessie-pu: package exactimage/0.8.9-7+deb8u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2016-02-24 at 14:10 +0100, Sven Eckelmann wrote:
> I'd like to upload a new version of exactimage to stable/jessie.
> 
> The exactimage package version in jessie is 0.8.9-7+deb8u1 at the moment. It
> was noticed that it is also affected by the security issue described in
> CVE-2015-8366 [1] (no-DSA [2]). This issue was resolved in libraw/jessie by an
> upload via jessie-pu [3].

Please go ahead.

Regards,

Adam

Bug#650601: libpng is going to be NMUed soon.

[Gianfranco Costamagna]

Hi,

>WDYM with versioned depends?


as said above:
"a/ virtual provides can't safisfy versioned dependencies"

maintainers might be able to do something like "Depends: libpng-dev (>=1.6)".
This might help future transitions (not from 12 to 16 probably).

Always if I understand correctly what maintainers might want to do.
And makes easier to pull the trigger, avoding two uploads at the same time and 
some rebuilds
possibly.

cheers,
G.

Bug#819116: light-locker: Mouse Pointer goes invisible after login with xfce4

[Don Jajo]

Package: light-locker
Version: 1.7.0-3
Severity: important

Dear Maintainer,

After system being idle and screen goes blank, resuming the screen and
unlocking, the mouse pointer goes invisible but works. i.e. you can click,
scroll and double click but with invisible mouse pointer.

Had to logout and login again make it appear again.



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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libc62.22-3
ii  libcairo21.14.6-1
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.9-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libsystemd0  229-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxss1  1:1.2.2-1
ii  lightdm  1.16.7-1

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#819077: linux-image-4.4.0-1-amd64: virtual consoles become unavailable and cause display problems

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 2016-03-23 at 15:30 +0100, Fedor Uvarov wrote:
> Package: src:linux
> Version: 4.4.6-1
> Severity: important
> 
> Dear Maintainer,
> 
> Since the update to 4.4.0-1 i've been regularly encountering a problem where
> virtual consoles (available by pressing Ctrl + Alt + F1..6) "freeze up" after
> working in the X session for some time. Namely, one of two things happen:
> 
> * Sometimes every virtual console shows no login prompt, but only an unmoving,
> unblinking cursor. This seems to only happen if I am not logged into any text
> console.
> * Sometimes the same image will show up for all consoles (no matter which one 
> I
> switch to), which is a frozen image from one of them. This can happen whether
> I'm logged in on one of the ttys or not.
[...]
> ** Loaded modules:
> cmac
> rfcomm
> ecb
> ctr
> ccm
> bbswitch(O)
[...]

Please test whether this still happens without bbswitch loaded.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

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

Bug#819040: insserv: Symlinked init script in /etc/init.d/ fails to be recognised on reboot.

[Brett Ryan]

> On 24 Mar 2016, at 08:04, Felipe Sateler  wrote:
> 
> (please don't top-post)
> 
>> On 23 March 2016 at 18:02, Brett Ryan  wrote:
>> Interesting. Does that mean if /usr is mounted separately that it would also 
>> cause init to fail?
> 
> Only if you do not use an initramfs. If you use a stock debian kernel
> and initramfs, then you are alright.

So how is /opt different if in the same order?

> -- 
> 
> Saludos,
> Felipe Sateler

Bug#650601: libpng is going to be NMUed soon.

[Emilio Pozuelo Monfort]

Just one comment.

On 23/03/16 21:58, Gianfranco Costamagna wrote:
> I did some little rework of the package, in bug #813027
> (fixing lintian errors, and some rules refactoring).
> I would like to NMU it for experimental, with providing a *real* libpng-dev
> package.
> 
> this will ensure next transition will be handled better, and should make this 
> transition even faster.
> (and versioned depends are a good thing for libpng).

WDYM with versioned depends?

Cheers,
Emilio

Bug#819113: openarena: unpure pak6-patch088.pk3 is downloaded from server

[Markus Koschany]

Am 23.03.2016 um 21:53 schrieb Jérémy Lal:
[...]
> /usr/lib/openarena/baseoa/pak6-patch088.pk3 (711 files)
> not on the pure list
> 
> --
> 5803 files in pk3 files
> Need paks: @baseoa/pak6-patch088.pk3@baseoa/pak6-patch088.pk3
> URL: ftp://46.182.19.245/oa/baseoa/pak6-patch088.pk3

Funny, apparently you visited my OpenArena server and downloaded
pak6-patch088.pk3 from my ftp server. Both servers run stable and all
OpenArena files are from this release. I guess Simon can shed more light
on this issue.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#819115: cowsay: missing dependency on libtext-charwidth-perl

[Niko Tyni]

Package: cowsay
Version: 3.03+dfsg1-14
Severity: serious

This package is missing a dependency on libtext-charwidth-perl.

 % /usr/games/cowsay 
 Can't locate Text/CharWidth.pm in @INC (you may need to install the 
Text::CharWidth module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 
/usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/usr/games/cowsay line 14.
 BEGIN failed--compilation aborted at /usr/games/cowsay line 14.

-- 
Niko Tyni   nt...@debian.org

Bug#819040: insserv: Symlinked init script in /etc/init.d/ fails to be recognised on reboot.

[Felipe Sateler]

(please don't top-post)

On 23 March 2016 at 18:02, Brett Ryan  wrote:
> Interesting. Does that mean if /usr is mounted separately that it would also 
> cause init to fail?

Only if you do not use an initramfs. If you use a stock debian kernel
and initramfs, then you are alright.

-- 

Saludos,
Felipe Sateler

Bug#819114: Job reported as failed, but wasn't

[Yuri D'Elia]

Package: systemd-cron
Version: 1.5.4-1
Severity: normal

I've added a cronjob that runs as my user every minute (fetchmail).
Occasionally, the job is reported as failed with the following email:

Subject: [laptop] job cron-wavexx-wavexx-0 failed

● cron-wavexx-wavexx-0.service - [Cron] "* * * * * fetchmail"
  Loaded: loaded (/var/spool/cron/crontabs/wavexx; bad; vendor preset: enabled)
  Active: inactive (dead) since Wed 2016-03-23 18:40:14 CET; 36ms ago
Docs: man:systemd-crontab-generator(8)
 Process: 30246 ExecStart=/usr/bin/zsh -c fetchmail (code=exited, 
status=0/SUCCESS)
Main PID: 30246 (code=exited, status=0/SUCCESS)

Mar 23 18:40:14 eab16011nb systemd[1]: Starting [Cron] "* * * * * fetchmail"...
Mar 23 18:40:14 eab16011nb systemd[1]: Started [Cron] "* * * * * fetchmail".

So it exited with code 0. What exactly has failed here?

-- Package-specific info:
-- output of systemd-delta

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

Kernel: Linux 4.5.0-trunk-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 systemd-cron depends on:
ii  init-system-helpers  1.29
ii  libc62.22-4
pn  python3:any  
ii  systemd-sysv 229-3

Versions of packages systemd-cron recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.86.2-2

systemd-cron suggests no packages.