Bug#820412: irssi-scripts: auto_away: timeout trigger/reset also on '\n' (not only '\r')

[Nicolas Schier]

Package: irssi-scripts
Version: 20160301
Severity: normal
Tags: patch

Dear maintainer,

the auto_away script does actually not work on my systems due to the
limited timeout/reset triggering: auto_away currently only sets up the
timeout handler on '\r', not on '\n'.  The attached patch works for me.

Kind regards,
Nicolas
--- a/usr/share/irssi/scripts/auto_away.pl
+++ b/usr/share/irssi/scripts/auto_away.pl
@@ -39,7 +39,7 @@ Irssi::settings_add_str('misc', 'away_se
 
 sub reset_timer{
   my $key=shift;
-  if($key == 10){
+  if (($key == 10) or ($key == 13)) {
 my (@servers) = Irssi::servers();
 foreach my $server (@servers) {
   if($server->{usermode_away} == 1){

Bug#820068: optipng: diff for NMU version 0.7.5-1.1

[Salvatore Bonaccorso]

Control: tags 820068 + patch
Control: tags 820068 + pending

Dear maintainer,

I've prepared an NMU for optipng (versioned as 0.7.5-1.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should delay it
longer. It is exactly the same patch as used by Moritz for the
jessie-security upload. Better would be though to straight go to 0.7.6.

Regards,
Salvatore
diff -Nru optipng-0.7.5/debian/changelog optipng-0.7.5/debian/changelog
--- optipng-0.7.5/debian/changelog	2014-06-11 13:48:44.0 +0200
+++ optipng-0.7.5/debian/changelog	2016-04-08 06:53:53.0 +0200
@@ -1,3 +1,12 @@
+optipng (0.7.5-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2016-2191: Invalid write while processing delta escapes without
+any boundary checking (Patch from Moritz Muehlenhoff from the jessie-
+security upload) (Closes: #820068)
+
+ -- Salvatore Bonaccorso   Fri, 08 Apr 2016 06:26:14 +0200
+
 optipng (0.7.5-1) unstable; urgency=medium
 
   * New upstream release (Closes: #687770)
diff -Nru optipng-0.7.5/debian/patches/CVE-2016-2191.patch optipng-0.7.5/debian/patches/CVE-2016-2191.patch
--- optipng-0.7.5/debian/patches/CVE-2016-2191.patch	1970-01-01 01:00:00.0 +0100
+++ optipng-0.7.5/debian/patches/CVE-2016-2191.patch	2016-04-08 06:53:53.0 +0200
@@ -0,0 +1,140 @@
+Description: CVE-2016-2191: Invalid write while processing delta escapes without any boundary checking
+Origin: upstream
+Bug: https://sourceforge.net/p/optipng/bugs/59/
+Bug-Debian: https://bugs.debian.org/820068
+Forwarded: not-needed
+Author: Moritz Muehlenhoff 
+Last-Update: 2016-04-08
+Applied-Upstream: 0.7.6
+
+--- optipng-0.7.5.orig/src/pngxtern/pngxrbmp.c
 optipng-0.7.5/src/pngxtern/pngxrbmp.c
+@@ -108,17 +108,17 @@ bmp_get_dword(png_bytep ptr)
+ 
+ 
+ /*/
+-/* BMP RLE helpers   */
++/* BMP helpers   */
+ /*/
+ 
+ static void
+-bmp_rle8_memset(png_bytep ptr, size_t offset, int ch, size_t len)
++bmp_memset_bytes(png_bytep ptr, size_t offset, int ch, size_t len)
+ {
+memset(ptr + offset, ch, len);
+ }
+ 
+ static void
+-bmp_rle4_memset(png_bytep ptr, size_t offset, int ch, size_t len)
++bmp_memset_halfbytes(png_bytep ptr, size_t offset, int ch, size_t len)
+ {
+if (len == 0)
+   return;
+@@ -136,7 +136,7 @@ bmp_rle4_memset(png_bytep ptr, size_t of
+ }
+ 
+ static size_t
+-bmp_rle8_fread(png_bytep ptr, size_t offset, size_t len, FILE *stream)
++bmp_fread_bytes(png_bytep ptr, size_t offset, size_t len, FILE *stream)
+ {
+size_t result;
+ 
+@@ -147,15 +147,17 @@ bmp_rle8_fread(png_bytep ptr, size_t off
+ }
+ 
+ static size_t
+-bmp_rle4_fread(png_bytep ptr, size_t offset, size_t len, FILE *stream)
++bmp_fread_halfbytes(png_bytep ptr, size_t offset, size_t len, FILE *stream)
+ {
+size_t result;
+int ch;
+ 
++   if (len == 0)
++  return 0;
+ptr += offset / 2;
+if (offset & 1)  /* use half-byte operations at odd offset */
+{
+-  for (result = 0; result < len; result += 2)
++  for (result = 0; result < len - 1; result += 2)
+   {
+  ch = getc(stream);
+  if (ch == EOF)
+@@ -231,14 +233,14 @@ bmp_read_rows(png_bytepp begin_row, png_
+   endn = row_size * 2;
+   if (endn <= row_size)
+  return 0;  /* overflow */
+-  bmp_memset_fn = bmp_rle4_memset;
+-  bmp_fread_fn = bmp_rle4_fread;
++  bmp_memset_fn = bmp_memset_halfbytes;
++  bmp_fread_fn = bmp_fread_halfbytes;
+}
+else
+{
+   endn = row_size;
+-  bmp_memset_fn = bmp_rle8_memset;
+-  bmp_fread_fn = bmp_rle8_fread;
++  bmp_memset_fn = bmp_memset_bytes;
++  bmp_fread_fn = bmp_fread_bytes;
+}
+ 
+if (compression == BI_RGB || compression == BI_BITFIELDS)
+@@ -258,19 +260,14 @@ bmp_read_rows(png_bytepp begin_row, png_
+   if (compression == BI_RLE8)
+   {
+  endn = row_size;
+- bmp_memset_fn = bmp_rle8_memset;
+- bmp_fread_fn = bmp_rle8_fread;
+   }
+-  else /* BI_RLE4 */
++  else  /* BI_RLE4 */
+   {
+  endn = row_size * 2;
+  if (endn <= row_size)
+ return 0;  /* overflow */
+- bmp_memset_fn = bmp_rle4_memset;
+- bmp_fread_fn = bmp_rle4_fread;
+   }
+-  crt_row = begin_row;
+-  for ( ; ; )
++  for (crt_row = begin_row; crt_row != end_row; )
+   {
+  ch = getc(stream); b1 = (unsigned int)ch;
+  ch = getc(stream); b2 = (unsigned int)ch;
+@@ -300,6 +297,7 @@ bmp_read_rows(png_bytepp begin_row, png_
+ {
+bmp_memset_fn(*crt_row, crtn, 0, endn - crtn);
+crt_row += inc;
++   crtn = 0;
+result = (begin_row <= end_row) ?
+   

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[tcrass]

Rolf,

the fax was transferred successfuly, everything is fine now!

Thanks again for fixing this bug.

Cheers --

Torsten

Bug#819854: reassigning back to letsencrypt

[Pirate Praveen]

On Friday 08 April 2016 04:43 AM, Axel Beckert wrote:

>> where as I would have preferred to use letsencrypt by default
> 
> Short said: That's exactly what you prefer. You already have it.

Sorry for the noise. This was not the result I got when running it in a
cowbuilder --login chroot.

When I ran apt-get install gitlab, it did not install letsencrypt.

But that is just cowbuilder/pbuilder default it seems.



signature.asc
Description: OpenPGP digital signature

Bug#820373: w3m: SEGFAULT on bogus HTML

[Steve Kemp]

> Fixed, thank you.
> 
>   - 
> https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=5a159af05d8556a3f9f8f1a42d8fc153ffbc9694
> 

  I confirm that fixes the problem.  Thanks once more for your
 prompt attention.

> Welcome to add more info, so that I'll confirm the problems are
> really fixed.

  Sure thing. I will do so next time.

  All my current samples are fixed; I'll start searching again.

Steve
-- 

Bug#820378: Ensure users report bugs in BTS and not to upstream directly

[Paul Wise]

On Thu, 7 Apr 2016 21:22:22 +0200 Tormod Volden wrote:

> According to upstream, a lot of Debian stable users send bug reports
> about the xscreensaver package directly to him.

I note that upstream is or was subscribed to Debian bug reports too.
 
> Apparently the xscreensaver user interface encourages e-mailing of bug
> reports directly upstream. We should try to change this, so that the
> normal flow of bug reports go to the Debian bug tracker, and anything
> relevant for upstream gets forwarded from there as usual.

Given his subscription to Debian bug reports I wonder if redirecting
Debian bug reporters from upstream to Debian+upstream will be enough to
prevent upstream from being annoyed by Debian users using old versions?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820403: jessie-pu: package linux/3.16.7-ckt25-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2016-04-07 at 23:18 +0100, Ben Hutchings wrote:
> The recent point release (8.4) introduced several regressions in
> src:linux.  In particular bug #819881 (radeon crasher) is affecting a
> fair number of users.  Bug #820176 (usb crasher) was also reported
> several times and there is a second crash bug in radeon which had many
> reports upstream.
> 
> All three regressions are caused by single commits that have been reverted
> in the next 3.16.7-ckt update; two were also reverted upstream.  I would
> like to apply those reversions through jessie-updates rather than
> waiting for the next point release or security update.
> 
> As I haven't done this before (so far as I can remember, anyway),
> please let me know whether I have to do anything different compared to
> an upload that's destined for the next point release.

Everything's the same from the uploader's perspective, including:

> --- linux-3.16.7-ckt25/debian/changelog   2016-03-06 22:19:35.0 
> +
> +++ linux-3.16.7-ckt25/debian/changelog   2016-04-07 22:34:44.0 
> +0100
> @@ -1,3 +1,14 @@
> +linux (3.16.7-ckt25-2) jessie-updates; urgency=medium

That should simply be "jessie", as usual, please. The upload goes to
p-u, gets built there, and then once ready for release we ask dak to
copy it to -updates.

With that tweak made, please go ahead.

Regards,

Adam

Bug#820313: vim-addon-manager ftbfs (tests are failing)

[James McCoy]

Control: reassign vim-common 2:7.4.1689-2

On Thu, Apr 07, 2016 at 12:45:43PM +0200, Matthias Klose wrote:
> The package currently fails to build (triggered by the recent vim update):
> 
> ┌──┐
> │ Run tests for ruby2.3 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> mv lib .gem2deb.lib
> RUBYLIB=. GEM_PATH= ruby2.3 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby2.3 -S rspec --color spec
> ...
> 
> Finished in 0.05316 seconds (files took 0.12667 seconds to load)
> 23 examples, 0 failures
> 
> /usr/bin/ruby2.3 -S cucumber --format progress
> ...F--..
> 
> (::) failed steps (::)
> 
> expected `[].empty?` to return false, got true
> (RSpec::Expectations::ExpectationNotMetError)
> ./features/step_definitions/steps.rb:78:in `/^the documentation should be 
> indexed$/'
> features/install.feature:17:in `Then the documentation should be indexed'

This is because helpztags isn't generating the tags file.  I'll have it
fixed shortly.

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

Bug#783741: Not fixed in debian-live-8.4.0-amd64-lxde

[Anatoly A]

Still present in  debian-live-8.4.0-amd64-lxde-desktop+nonfree.iso .
I boot from USB flash (created by dd ).

Bug#820411: wily: SIGSEGV on exit

[Nathaniel Morck Beaver]

Package: wily
Version: 0.13.41-7.2
Severity: normal

Dear Maintainer,

I find a segfault on exit in both Jessie and Sid (see attached gdb log).

Unfortunately, I can't reproduce when I build from source, so I can't 
provide a proper backtrace with debugging symbols.


Sincerely,

Nathaniel Beaver

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wily depends on:
ii  libc6 2.19-18+deb8u4
ii  libx11-6  2:1.6.2-3
ii  libxt61:1.1.4-1+b1

wily recommends no packages.

Versions of packages wily suggests:
pn  9fonts  
ii  rc  1.7.2-1

-- no debconf information
Starting program: /usr/bin/wily 

Program received signal SIGSEGV, Segmentation fault.
0x804103a7 in ?? ()
#0  0x804103a7 in ?? ()
No symbol table info available.
#1  0x0006 in ?? ()
No symbol table info available.
#2  0x in ?? ()
No symbol table info available.
#3  0x00670180 in ?? ()
No symbol table info available.
#4  0x6af57ff56ab9ec00 in ?? ()
No symbol table info available.
#5  0x in ?? ()
No symbol table info available.
A debugging session is active.

Inferior 1 [process 21235] will be killed.

Quit anyway? (y or n) 

Bug#820409: r-cran-dplyr: missing dependency on r-cran-assertthat

[Evan Thompson]

Package: r-cran-dplyr
Version: 0.4.3-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

When attempting to load dplyr in R:

> library(dplyr)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘assertthat’
Error: package or namespace load failed for ‘dplyr’

Installing r-cran-assertthat solves the issue.

Regards,
-- Evan Thompson



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

Kernel: Linux 4.4-6.dmz.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-dplyr depends on:
ii  libc6  2.22-5
ii  libgcc11:5.3.1-13
ii  libstdc++6 5.3.1-13
ii  r-base-core [r-api-3]  3.2.4.20160406-1
ii  r-cran-dbi 0.3.1-1
ii  r-cran-magrittr1.5-1

r-cran-dplyr recommends no packages.

r-cran-dplyr suggests no packages.

-- no debconf information

Bug#820410: gnome should not depend on network-manager-gnome

[Nye Liu]

Package: gnome
Version: 1:3.14+4
Severity: important

Network manager is crap and causes all sorts of issues for machines with
static, stable connections.

Unfortunately, gnome *requires* network-manager-gnome instead of
recommends.

$ sudo dpkg --purge network-manager network-manager-gnome
dpkg: dependency problems prevent removal of network-manager-gnome:
 gnome depends on network-manager-gnome (>= 0.9.10).

dpkg: error processing package network-manager-gnome (--purge):
 dependency problems - not removing
dpkg: dependency problems prevent removal of network-manager:
 network-manager-gnome depends on network-manager (>= 1.1).

dpkg: error processing package network-manager (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 network-manager-gnome
 network-manager
$

Please allow the user to remove the blight that is network manager w/o
uninstalling all of gnome.

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

Kernel: Linux 3.16-3-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 gnome depends on:
ii  alacarte   3.11.91-2
ii  avahi-daemon   0.6.32~rc+dfsg-1
ii  bijiben3.18.2-1
ii  brasero3.12.1-1
ii  cheese 3.18.1-2
ii  cups-pk-helper 0.2.5-2+b1
ii  desktop-base   8.0.2
ii  evolution  3.18.5.1-1
ii  evolution-plugins  3.18.5.1-1
ii  file-roller3.20.0-1
ii  gedit  3.18.3-1
ii  gedit-plugins  3.18.0-1+b1
ii  gimp   2.8.16-1
ii  gnome-clocks   3.18.0-1+b1
ii  gnome-color-manager3.18.0-1+b1
ii  gnome-core 1:3.14+4
ii  gnome-documents3.18.2-1
ii  gnome-games1:3.14+4
ii  gnome-getting-started-docs 3.18.2-1
ii  gnome-logs 3.18.1-1
ii  gnome-maps 3.20.0-1
ii  gnome-music3.18.2-1
ii  gnome-nettool  3.8.1-1+b1
ii  gnome-orca 3.18.2-1
ii  gnome-shell-extension-weather  0~20160325.gitb5415ec-1
ii  gnome-sound-recorder   3.18.2-1
ii  gnome-tweak-tool   3.18.1-1
ii  gstreamer1.0-libav 1.8.0-1
ii  gstreamer1.0-plugins-ugly  1.6.3-1
ii  inkscape   0.91-7+b1
ii  libgsf-bin 1.14.36-1
ii  libgtk2-perl   2:1.2498-1
ii  libreoffice-calc   1:5.1.2~rc1-1
ii  libreoffice-evolution  1:5.1.2~rc1-1
ii  libreoffice-gnome  1:5.1.2~rc1-1
ii  libreoffice-impress1:5.1.2~rc1-1
ii  libreoffice-writer 1:5.1.2~rc1-1
ii  nautilus-sendto3.8.2-2
pn  network-manager-gnome  
ii  polari 3.18.1-2
ii  rhythmbox  3.3-1
ii  rhythmbox-plugin-cdrecorder3.3-1
ii  rhythmbox-plugins  3.3-1
ii  rygel-playbin  0.28.3-1
ii  rygel-tracker  0.28.3-1
ii  seahorse   3.18.0-2
ii  shotwell   0.22.0-4
ii  simple-scan3.19.2-1
ii  sound-juicer   3.18.1-1
ii  telepathy-gabble   0.18.3-2+b1
ii  telepathy-rakia0.8.0-3
ii  telepathy-salut0.8.1-5+b1
ii  totem-plugins  3.18.1-2+b1
ii  transmission-gtk   2.84-3
ii  vinagre3.18.2-1
ii  xdg-user-dirs-gtk  0.10-1

Versions of packages gnome recommends:
ii  gnome-software  3.18.3-3

Versions of packages gnome suggests:
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  xul-ext-adblock-plus 
pn  xul-ext-gnome-keyring

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme 3.18.0-2
ii  at-spi2-core   2.18.3-4
ii  baobab 3.18.1-1
ii  caribou0.4.20-1
ii  caribou-antler 0.4.20-1
ii  dconf-cli  0.24.0-2
ii  dconf-gsettings-backend0.24.0-2
ii  empathy3.12.11-2
ii  eog3.18.2-1
ii  evince 3.20.0-1
ii  evolution-data-server  3.18.5-1
ii  firefox-esr45.0.1esr-1
ii  fonts-cantarell0.0.21-1
ii  gdm3   3.18.0-2
ii  gkbd-capplet   3.6.0-1
ii  glib-networking2.48.0-1
ii  gnome-backgrounds  3.18.0-1
ii  gnome-bluetooth3.18.3-1
ii  gnome-calculator   3.20.0-1
ii  gnome-contacts 3.18.1-1
ii  gnome-control-center   1:3.18.2-1
ii  gnome-dictionary   3.18.0-2
ii  

Bug#820260: nvidia-kernel-source: Module does not build with make-kpkg (kernel-package)

[Kevin Locke]

Hi Luca,

On 04/07/2016 04:51 PM, Luca Boccassi wrote:

On Wed, 2016-04-06 at 20:40 -0700, Kevin Locke wrote:

Starting in version 352.79-2 I am unable to build the nvidia kernel
module for custom kernels using make-kpkg (part of the kernel-package
package).


Sorry for the problem you are facing, it's a corner case that I don't
usually test.


That's quite alright.  Thanks for taking a look at it.


I didn't have time to fully reproduce your environment, but could you
please try with the attached patch (for the debian/rules in the 352.79-5
kernel-source)? It should allow one to pass an arbitrary KSRC directory
if the one derived from the version does not exist, which allows the
current behaviour to continue. I'll try and find the time to fully test
it myself as well in the following days.


The patch works for me.  However, it looks like it could cause breakage 
if the kernel being built shared the same version as an installed kernel 
but had source differences (e.g. additional patches), since the sources 
for the installed kernel would be used rather than the kernel being 
built (for which the module is intended to be used).


Perhaps the rationale for removing support for KSRC can shed some light 
on the tradeoffs for this fix vs reverting the commit.


Thanks again,
Kevin

Bug#820408: apt upgrade with autoremove does not upgrade packages that Breaks/Replaces a second, dropped package

[Felipe Sateler]

Package: apt
Version: 1.2.10
Severity: normal

Hi,

I have been experiencing this bug for a while now (since the c++ mass
rebuild), but I now decided to stop upgrading so I can file a
reproducible bug report.

As of today in sid:

% sudo apt upgrade -o APT::Get::AutomaticRemove=true
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  libjavascriptcoregtk-1.0-0 libjavascriptcoregtk-3.0-0 libwebkitgtk-1.0-0 
libwebkitgtk-3.0-0
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.


Turns out that the new (2.4.10-1) versions of libwebkitgtk (both -1 and
-3), dropped the respective -common package, and added Breaks/Replaces
to them. Nothing else depends on these packages:

% axi-cache rdetails libwebkitgtk-1.0-common libwebkitgtk-3.0-common
libwebkitgtk-1.0-common bre libwebkitgtk-1.0-0:i386 libwebkitgtk-1.0-0
libwebkitgtk-3.0-common bre libwebkitgtk-3.0-0:i386 libwebkitgtk-3.0-0

Using full-upgrade can successfully upgrade the packages. However, it
seems to me that automatic removes should enable a simple upgrade to
work as well.

If there is any other info that may be useful, please just ask.

Saludos


-- Package-specific info:

-- apt-config dump --

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

Bug#816325: [pkg-dhcp-devel] Bug#816325: org.freedesktop.PolicyKit1 was not provided by any .service files

[Michael Gilbert]

On Wed, Apr 6, 2016 at 11:52 PM, Jörg Frings-Fürst wrote:
>> > $ systemctl start isc-dhcp-server
>> > Failed to start isc-dhcp-server.service: The name
>> > org.freedesktop.PolicyKit1 was not provided by any .service files
>> The org.freedesktop.PolicyKit1.service file is provided by the
>> policykit-1 package.  Do you have that installed?
>
> No I don't.

Try installing it then?

> It's a stretch system without any manual installs. Packages see
> attachment.

I tested unstable, so you may want to test there too.

Best wishes,
Mike

Bug#820407: RFS: smartmontools/6.4+svn4214-1~bpo8+1

[Nicholas D Steeves]

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

Dear mentors,

I am looking for a sponsor for my backport of "smartmontools"

Package name: smartmontools
Version: 6.4+svn4214-1~bpo8+1
Section: utils

It builds these binary packages:

smartmontools - control and monitor storage systems using S.M.A.R.T.

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

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

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

dget -x 
http://mentors.debian.net/debian/pool/main/s/smartmontools/smartmontools_6.4+svn4214-1~bpo8+1.dsc

More information about hello can be obtained from http://www.example.com.

Changes since the last upload:

  * Rebuild for jessie-backports.


Regards,
Nicholas

Bug#814766: Not reproducible

[Lisandro Damián Nicanor Pérez Meyer]

tag 814766 unreproducible moreinfo
severity 814766 important
thanks

Hi Chris! I have also tried to rebuild it on a clean chroot with sbuild, and I 
also didn't have any problems, it built as it should.

I'm so downgrading the severity to important at least for now. Can you check 
your build environment is sane?

Thanks for your efforts!

-- 
La vida no se mide por la cantidad de veces que respiramos,
sino por la cantidad de momentos que nos quitan la respiración.
  Anónimo

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


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

Bug#787146: ITP: Gambatte - Game Boy and Game Boy Color emulator

[Sérgio Benjamim]

Support the libretro core instead please --> 
https://mentors.debian.net/package/libretro-gambatte



mentors packages that has a related ITP must be mantain event erased
in the time!


Tell that to the debian devs who made the mentors website, I don't know 
why the website deletes your package after 2 months.
If you have only the package there, you lost all the work you had 
packaging...



sergio-br2

Bug#820406: dh-haskell: Fails to build a package that doesn't contain libraries

[Neil Mayhew]

Package: dh-haskell
Version: 0.1
Severity: important
Tags: patch

I'm packaging a utility written in Haskell that doesn't provide any libraries,
just executables. The build fails with:

> debian/haskellbuild.setup register --builddir=dist-ghc --gen-pkg-config
> Package contains no library to register: blah-1.0.0.0...
> dh_auto_install: More than one pkg-config file:

although the problem is actually that there are *no* pkg-config files.

I was able to work around it with:

override_dh_auto_install:
touch foo.conf
dh_auto_install $(DH_INTERNAL_OPTIONS)

This is ugly, of course, and I'd prefer not to have to do it.

I've looked at the code in install_pkg_config(), and it seems that if there
are no .conf files, the rest of the function should be skipped. However, at
the call site in install(), a conf file name has to be provided, but providing
"/dev/null" seems to work OK. I've tested this change and it seems to work OK,
so I've attached a patch.

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

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

Versions of packages dh-haskell depends on:
ii  debhelper  9.20160313
ii  dh-buildinfo   0.11
ii  hscolour   1.23-3
ii  libcarp-assert-perl0.21-1
ii  libfile-chdir-perl 0.1008-1
ii  libhtml-linkextractor-perl 0.130-6
ii  liblist-moreutils-perl 0.413-1+b1
ii  libparse-debcontrol-perl   2.005-4
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libreadonly-perl   2.000-2

dh-haskell recommends no packages.

dh-haskell suggests no packages.

-- no debconf information
>From 28c5f7778a95a25f2151a13501495eed9ec82c79 Mon Sep 17 00:00:00 2001
From: Neil Mayhew 
Date: Thu, 7 Apr 2016 17:35:15 -0600
Subject: [PATCH] Handle packages that don't contain libraries

---
 lib/Debian/Debhelper/Buildsystem/haskell.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/Debian/Debhelper/Buildsystem/haskell.pm b/lib/Debian/Debhelper/Buildsystem/haskell.pm
index aabed89..7fb28af 100644
--- a/lib/Debian/Debhelper/Buildsystem/haskell.pm
+++ b/lib/Debian/Debhelper/Buildsystem/haskell.pm
@@ -578,6 +578,8 @@ sub install_pkg_config {
 run_setup( 'register', '--gen-pkg-config' );
 
 my @candidates = <*.conf>;
+
+return "/dev/null" if ( @candidates == 0 );
 error("More than one pkg-config file: @candidates") if ( @candidates != 1 );
 
 my $pkg_config  = $candidates[0];
-- 
2.8.0.rc3

Bug#541157: RFP: vbam - Gameboy Advance emulator

[Sérgio Benjamim]

Hi,

I uploaded it again. The build is broken. Good luck

https://mentors.debian.net/package/vbam

src/gtk/screenarea.cpp: In constructor ‘VBA::ScreenArea::ScreenArea(int, 
int, int)’:
src/gtk/screenarea.cpp:53:62: error: no matching function for call to 
‘Gdk::Cursor::Cursor(, 
Glib::RefPtr&, int, int)’

   m_poEmptyCursor = new Gdk::Cursor(get_display, pixbuf, 0, 0);


sergio-br2


On 06/04/2016 17:54, PICCORO McKAY Lenz wrote:

the package in mentors are now go..

please reupload to mentors

mentors must mantain the packages that already has a bug number
relationship and only erase those that are onlñy uploaded alone
without a itp or rfp bug related!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#820260: nvidia-kernel-source: Module does not build with make-kpkg (kernel-package)

[Luca Boccassi]

On Wed, 2016-04-06 at 20:40 -0700, Kevin Locke wrote:
> Package: nvidia-kernel-source
> Version: 352.79-5
> Severity: normal
> 
> Dear Maintainer,
> 
> Starting in version 352.79-2 I am unable to build the nvidia kernel
> module for custom kernels using make-kpkg (part of the kernel-package
> package).  I have confirmed that the issue is present in both 352.79-5
> and 355.11-2.  The error which occurs is:
> 
> $ make-kpkg -j4 --rootcmd fakeroot --append_to_version +kevinoid1 --revision 
> 4.5+1 --added_modules nvidia-kernel modules_image
> [...]
> make[2]: Entering directory '/usr/src/modules/nvidia-kernel'
> /usr/bin/make  KBUILD_VERBOSE=1 -C /lib/modules/4.5.0+kevinoid1/build 
> M=/usr/src/modules/nvidia-kernel ARCH=x86_64 
> NV_KERNEL_SOURCES=/lib/modules/4.5.0+kevinoid1/build 
> NV_KERNEL_OUTPUT=/lib/modules/4.5.0+kevinoid1/build NV_KERNEL_MODULES="nvidia 
> nvidia-uvm" INSTALL_MOD_DIR=kernel/drivers/video Q= modules
> make[3]: Entering directory '/usr/src/modules/nvidia-kernel'
> make[3]: *** /lib/modules/4.5.0+kevinoid1/build: No such file or directory.  
> Stop.
> make[3]: Leaving directory '/usr/src/modules/nvidia-kernel'
> Makefile:81: recipe for target 'modules' failed
> make[2]: *** [modules] Error 2
> 
> I have attached both a successful build log (with version 352.79-1) and
> an unsuccessful one (with version 352.79-2) using the same command as
> above.
> 
> I believe this is due to debian/rules not passing KSRC (/usr/src/linux
> in my case) to the nVidia Makefile, which attempts to deduce it from the
> version information.  This fails if the kernel is not yet installed,
> which is always the case when building the module with the kernel using
> make-kpkg.  I think this behavior was introduced in r6121.[1]

Hello Kevin,

Sorry for the problem you are facing, it's a corner case that I don't
usually test.

I didn't have time to fully reproduce your environment, but could you
please try with the attached patch (for the debian/rules in the 352.79-5
kernel-source)? It should allow one to pass an arbitrary KSRC directory
if the one derived from the version does not exist, which allows the
current behaviour to continue. I'll try and find the time to fully test
it myself as well in the following days.

Andreas,

Was there any specific reason to prefer letting the module derive the
kernel source path from the version?

Kind regards,
Luca Boccassi

--- debian/rules
+++ debian/rules
@@ -22,7 +22,14 @@
 ifndef KPKG_DEST_DIR
 KPKG_DEST_DIR = ..
 endif
+ifndef KVERS
 KVERS := $(shell perl debian/kernel-version $(KSRC))
+endif
+ifeq ($(wildcard /lib/modules/$(KVERS)/build),)
+SYSSRC=SYSSRC=$(KSRC)
+else
+SYSSRC=
+endif
 export KVERS
 export KPKG_DEST_DIR
 
@@ -42,8 +49,8 @@
 build-stamp: configure-stamp
dh_prep
dh_quilt_patch
-   unset ARCH; $(MAKE) module KERNEL_UNAME=$(KVERS)
-   unset ARCH; $(MAKE) -C uvm module KERNEL_UNAME=$(KVERS) 
KBUILD_EXTMOD=$(CURDIR)/uvm
+   unset ARCH; $(MAKE) module KERNEL_UNAME=$(KVERS) $(SYSSRC)
+   unset ARCH; $(MAKE) -C uvm module KERNEL_UNAME=$(KVERS) $(SYSSRC) 
KBUILD_EXTMOD=$(CURDIR)/uvm
test "nvidia-current" = "nvidia" || mv nvidia.ko nvidia-current.ko
test "nvidia-current" = "nvidia" || mv uvm/nvidia-uvm.ko 
uvm/nvidia-current-uvm.ko
touch $@
@@ -76,8 +83,8 @@
test -f debian/control || cp debian/control.template debian/control
dh_testdir
dh_testroot
-   $(MAKE) clean KERNEL_UNAME=$(KVERS) $(KPKG_EXTRAV_ARG)
-   $(MAKE) -C uvm clean KERNEL_UNAME=$(KVERS) $(KPKG_EXTRAV_ARG)
+   $(MAKE) clean KERNEL_UNAME=$(KVERS) $(SYSSRC) $(KPKG_EXTRAV_ARG)
+   $(MAKE) -C uvm clean KERNEL_UNAME=$(KVERS) $(SYSSRC) $(KPKG_EXTRAV_ARG)
dh_quilt_unpatch || quilt --quiltrc /dev/null pop -af
dh_clean debian/control debian/install
 



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

Bug#820381: rar crashes.

[Martin Meredith]

Any chance you can run rar with strace or similar to provide a backtrace?

On 7 April 2016 at 20:26, Alexandre Pereira Nunes  wrote:
> Package: rar
> Version: 2:5.3.b2-1
> Severity: serious
>
> Rar crashes in all evocations.
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.6 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
>
> rar depends on no packages.
>
> rar recommends no packages.
>
> Versions of packages rar suggests:
> ii  unrar  1:5.3.2-1
>
> -- no debconf information

Bug#820405: RFP: merlin -- assistant for editing OCaml code

[Christoph Egger]

Package: wnpp
Severity: wishlist

* Package name: merlin
  Version : 2.3.1
  Upstream Author : 
* URL or Web page : https://github.com/the-lambda-church/merlin
* License : MIT
  Description : assistant for editing OCaml code


--

I'm currently working a lot with OCaml source and would really love to
apt-get install merlin ;-) As I'm working with OCaml mainly for
university reasons and have no idea whether I'll still be working with
it in a year I don't think I'm a reasonable maintainer -- but I do
believe it would be a worthwile addition to Debian! Could certainly
contribute a first working package though.

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#788444: please include Belarusian

[Norbert Preining]

On Thu, 07 Apr 2016, Andrew Shadura wrote:
> Actually, since I posted that message, I made an attempt to rebase the
> changes to the latest babel Russian package (as it was based on it
> originally), and I succeeded. I just to do need minor changes, and I
> think I will upload it to CTAN if I manage to figure that out.

Sounds great. Please do it soon as TeX Live 2015 has gone int freeze,
and we are preparing TL 2016. So there will be updates from CTAN
for around 1month from now on, before we go into deep freeze ;-)

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#820388: variety: Section should be “x11”

[James Lu]

package variety
unarchive 814705
reopen 814705
merge 814705 820388
tags 814705 + fixed
thanks

Hi,

I've already fixed this error in the package; I'm just waiting for
FTP-masters to fix up the section on their side. Perhaps I closed the
old bug too early, but I'll reopen it now.

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#797687: Upstream merged pull request resolves this bug

[Antonio Russo]

Unlike my previous, inaccurate claim, a patch resolving this bug
has now indeed been merged upstream:

https://github.com/collectd/collectd/pull/1553

https://github.com/collectd/collectd/commit/10b10a6718dbb87c6890d4bc821a6e21c8b7b527

Bug#813176: closed by Theodore Ts'o <ty...@mit.edu> (Re: Bug#813176: "Checking in progress on 1 disk. (0.0%)" doesn't update)

[積丹尼 Dan Jacobson]

reopen 813176
reassign 813176 initscripts
thanks
Maybe it is initscripts.

Bug#820404: bind9: in6_pktinfo not detected on hurd-i386

[Samuel Thibault]

Package: bind9
Version: 1:9.9.5.dfsg-12.1
Severity: important

Hello,

bind9's configure fails to detect in6_pktinfo on hurd-i386. It indeed
needs the same definition as linux & kfreebsd of _GNU_SOURCE to get it,
since that's a glibc issue actually.

I have attached a patch to extend the fix to hurd-i386, could you apply
it?  We need it to fix isc-dhcp FTBFS (which itself is needed for
building the debian installer...)

Thanks,
Samuel

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

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

Versions of packages bind9 depends on:
ii  adduser 3.114
ii  bind9utils  1:9.9.5.dfsg-12.1
ii  cdebconf [debconf-2.0]  0.207
ii  debconf [debconf-2.0]   1.5.59
ii  init-system-helpers 1.29
ii  libbind9-90 1:9.9.5.dfsg-12.1
ii  libc6   2.22-5
ii  libcap2 1:2.24-12
ii  libcomerr2  1.43~WIP.2016.03.15-2
ii  libdns100   1:9.9.5.dfsg-12.1
ii  libgssapi-krb5-21.13.2+dfsg-5
ii  libisc951:9.9.5.dfsg-12.1
ii  libisccc90  1:9.9.5.dfsg-12.1
ii  libisccfg90 1:9.9.5.dfsg-12.1
ii  libk5crypto31.13.2+dfsg-5
ii  libkrb5-3   1.13.2+dfsg-5
ii  liblwres90  1:9.9.5.dfsg-12.1
ii  libssl1.0.2 1.0.2g-1
ii  libxml2 2.9.3+dfsg1-1
ii  lsb-base9.20160110
ii  net-tools   1.60+git20150829.73cef8a-2
ii  netbase 5.3

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.9.5.dfsg-12.1
ii  resolvconf  1.78
pn  ufw 

-- debconf information excluded

-- 
Samuel
 argh, pi est plus grand que 2. Ca casse tout
 -+- #ens-mim -+-
--- debian/patches/05_non-linux.diff.original   2016-04-07 22:59:46.0 
+
+++ debian/patches/05_non-linux.diff2016-04-07 23:04:19.0 +
@@ -8,6 +8,15 @@
 
 --- a/configure.in
 +++ b/configure.in
+@@ -441,7 +441,7 @@
+   # as it breaks how the two halves (Basic and Advanced) of the IPv6
+   # Socket API were designed to be used but we have to live with it.
+   # Define _GNU_SOURCE to pull in the IPv6 Advanced Socket API.
+-  *-linux* | *-kfreebsd*-gnu*)
++  *-linux* | *-kfreebsd*-gnu* | *-gnu*)
+   STD_CDEFINES="$STD_CDEFINES -D_GNU_SOURCE"
+   CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
+   ;;
 @@ -1202,7 +1202,7 @@
# LinuxThreads requires some changes to the way we
# deal with signals.

Bug#816722: zoom-player: interraction with xscreensaver

[Jamie Zawinski]

> This bug does _NOT_ happen when "xscreensaver-data-extra"
> which provides /usr/lib/xscreensaver/zoom is also installed.

Hey guess what, this is a problem that only exhibits itself because you took 
the code that I had tested and distributed, ripped half of it out, and expected 
the other half to continue working properly.

I am shocked -- shocked -- at this outcome.

Bug#816722: zoom-player: interraction with xscreensaver

[Jamie Zawinski]

If you modify xscreensaver to not obey $PATH, you are making it do this weird, 
confusing, undiscoverable thing.

If you merely launch it with a different $PATH, then it's easy to know what's 
going on. Especially since the $PATH appears in error messages about not being 
able to find things.

> Is it not possible to specify the full path in the app-default file?

You could do that, but just changing $PATH seems a lot simpler, and isn't going 
to result in merge conflicts for the rest of eternity.

Anyway, xscreensaver already prepends HACKDIR to $PATH, so this problem can 
only happen if HACKDIR is wrong or if the "zoom" saver is A) enabled but B) not 
installed.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Stephen Powell]

On Tue, Apr 5, 2016, at 20:37, Ben Hutchings wrote:
> 
> I'm not applying this until the kernel actually supports device numbers
> that large.  Currently it defines (in include/linux/kdev_t.h):
> 
> static inline u32 new_encode_dev(dev_t dev) { ... }
> static inline dev_t new_decode_dev(u32 dev) { ... }
> 
> static inline u64 huge_encode_dev(dev_t dev)
> {
>   return new_encode_dev(dev);
> }
> 
> static inline dev_t huge_decode_dev(u64 dev)
> {
>   return new_decode_dev(dev);
> }
> 
> i.e. anything above bit 31 is zeroed.
> 
> Ben.
> 

Interesting.  I wasn't aware of that.  Thank you for calling my attention
to it.  Under the circumstances, wishlist is fine.

Regards,

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Bug#804582: (no subject)

[Barry Warsaw]

I'm running across this too now.  I think part of the problem is that pybuild
invokes unittest discover by default, but this isn't how paramiko's test suite
is actually run, at least if you go by what's in the tox.ini file.

This gets me closer:

diff --git a/debian/rules b/debian/rules
index 9c04662..8d5d25b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=paramiko
+export PYBUILD_TEST_ARGS={interpreter} $(CURDIR)/test.py
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild
@@ -11,3 +12,5 @@ ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
 endif
dh_installdocs
 
+override_dh_auto_test:
+   PYBUILD_SYSTEM=custom dh_auto_test


But I'm still seeing two failures and two errors:

==
ERROR: test_K_utf8 (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 171, in tearDown
sftp.rmdir(FOLDER)
  File "/<>/paramiko/sftp_client.py", line 390, in rmdir
self._request(CMD_RMDIR, path)
  File "/<>/paramiko/sftp_client.py", line 729, in _request
return self._read_response(num)
  File "/<>/paramiko/sftp_client.py", line 776, in _read_response
self._convert_status(msg)
  File "/<>/paramiko/sftp_client.py", line 806, in _convert_status
raise IOError(text)
IOError: Failure

==
ERROR: test_L_utf8_chdir (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 679, in test_L_utf8_chdir
sftp.mkdir(FOLDER + '/' + unicode_folder)
  File "/<>/paramiko/sftp_client.py", line 380, in mkdir
self._request(CMD_MKDIR, path, attr)
  File "/<>/paramiko/sftp_client.py", line 729, in _request
return self._read_response(num)
  File "/<>/paramiko/sftp_client.py", line 776, in _read_response
self._convert_status(msg)
  File "/<>/paramiko/sftp_client.py", line 806, in _convert_status
raise IOError(text)
IOError: Failure

==
FAIL: test_K_utf8 (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 675, in test_K_utf8
self.fail('exception ' + str(e))
AssertionError: exception Failure

==
FAIL: test_O_getcwd (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 734, in test_O_getcwd
self.assertEqual(None, sftp.getcwd())
AssertionError: None != u'/'

--
Ran 148 tests in 34.596s

FAILED (failures=2, errors=2)

Bug#820403: jessie-pu: package linux/3.16.7-ckt25-2

[Ben Hutchings]

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

The recent point release (8.4) introduced several regressions in
src:linux.  In particular bug #819881 (radeon crasher) is affecting a
fair number of users.  Bug #820176 (usb crasher) was also reported
several times and there is a second crash bug in radeon which had many
reports upstream.

All three regressions are caused by single commits that have been reverted
in the next 3.16.7-ckt update; two were also reverted upstream.  I would
like to apply those reversions through jessie-updates rather than
waiting for the next point release or security update.

As I haven't done this before (so far as I can remember, anyway),
please let me know whether I have to do anything different compared to
an upload that's destined for the next point release.

The debdiff is below, with changes to generated files
debian/config.defines.dump, debian/control.md5sum and debian/rules.gen
omitted.

Ben.

diff -Nru linux-3.16.7-ckt25/debian/changelog 
linux-3.16.7-ckt25/debian/changelog
--- linux-3.16.7-ckt25/debian/changelog 2016-03-06 22:19:35.0 +
+++ linux-3.16.7-ckt25/debian/changelog 2016-04-07 22:34:44.0 +0100
@@ -1,3 +1,14 @@
+linux (3.16.7-ckt25-2) jessie-updates; urgency=medium
+
+  * Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
+(Closes: #819881)
+  * Revert "drm/radeon: call hpd_irq_event on resume", reported to cause
+regressions (crash/hang) on some systems
+  * Revert "usb: hub: do not clear BOS field during reset device"
+(Closes: #820176)
+
+ -- Ben Hutchings   Thu, 07 Apr 2016 22:34:43 +0100
+
 linux (3.16.7-ckt25-1) jessie; urgency=medium
 
   * New upstream stable update:
diff -Nru 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
--- 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
   1970-01-01 01:00:00.0 +0100
+++ 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
   2016-04-07 22:33:40.0 +0100
@@ -0,0 +1,42 @@
+From: Linus Torvalds 
+Date: Mon, 7 Mar 2016 13:15:09 -0800
+Subject: Revert "drm/radeon: call hpd_irq_event on resume"
+Origin: https://git.kernel.org/linus/256faedcfd646161477d47a1a78c32a562d2e845
+
+This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.
+
+It turns out that commit can cause problems for systems with multiple
+GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
+graphics.
+
+This got noticed originally in 4.4.4, where this patch had already
+gotten back-ported, but 4.5-rc7 was verified to have the same problem.
+
+Alexander Deucher says:
+ "It looks like you have a muxed system so I suspect what's happening is
+  that one of the display is being reported as connected for both the
+  IGP and the dGPU and then the desktop environment gets confused or
+  there some sort problem in the detect functions since the mux is not
+  switched to the dGPU.  I don't see an easy fix unless Dave has any
+  ideas.  I'd say just revert for now"
+
+Reported-by: Jörg-Volker Peetz 
+Acked-by: Alexander Deucher 
+Cc: Dave Airlie 
+Signed-off-by: Linus Torvalds 
+---
+ drivers/gpu/drm/radeon/radeon_device.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
+index f7296ca6510c..ca470fb17aa4 100644
+--- a/drivers/gpu/drm/radeon/radeon_device.c
 b/drivers/gpu/drm/radeon/radeon_device.c
+@@ -1649,7 +1649,6 @@ int radeon_resume_kms(struct drm_device *dev, bool 
resume, bool fbcon)
+   }
+ 
+   drm_kms_helper_poll_enable(dev);
+-  drm_helper_hpd_irq_event(dev);
+ 
+   /* set the power state here in case we are a PX system or headless */
+   if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
diff -Nru 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
--- 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
 1970-01-01 01:00:00.0 +0100
+++ 
linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
 2016-04-07 22:33:40.0 +0100
@@ -0,0 +1,39 @@
+From: Luis Henriques 
+Date: Wed, 9 Mar 2016 13:58:27 +
+Subject: Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
+Origin: 
http://kernel.ubuntu.com/git/ubuntu/linux.git/commit?id=f80be5a9b1ccf679415676f761bc9efdc3ad13b5
+
+This 

Bug#763720: Please enable the vst plugin on i386 and amd64

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> Perhaps you want to be a co-maintainer or take over the package?

[Javier Serrano Polo]
> I hope I can help. I have created a new Alioth account, jasp00-guest.

Very good.  To get write access to the git repo, you need to join the
Debian Edu team, https://alioth.debian.org/projects/debian-edu/ >.

Are you on IRC?  Please join us on #debian-edu (irc.debian.org) and we
can coordinate there. :)

PS: Your email address seem to be broken and bounces.

--
Happpy hacking
Petter Reinholdtsen

Bug#820336: composer: remove mercurial from Recommends

[David Prévot]

Hi Thijs,

Thanks for you interest in the composer package.

Le 07/04/2016 09:57, Thijs Kinkhorst a écrit :

> Installing composer by default also pulls in mercurial because it's in
> Recommends. I personally doubt that the amount of mercurial use justifies
> pulling it in by default (and e.g. not svn).

On top of the default Hg driver, there is one specific to Bitbucket, so
I initially assumed it should be useful enough, but I have never seen
any PHP package hosted on Mercurial yet.

> I'd say it could be better
> moved to Suggests.

Agreed, added subversion to suggest too since there is also a Svn driver.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#820298: popularity-contest: Garbage E-Mail: UID must be less than 49999 (from pam)

[Bill Allombert]

On Thu, Apr 07, 2016 at 09:52:23AM +0200, Juergen Pfennig wrote:
> Package: popularity-contest
> Version: 1.61
> Severity: normal
> 
> Dear Maintainer,
> 
> your cron.daily scripts does something like "su  nobody".
> Unfortunately some pam module outputs the UID warning.

Hello,

Do you know the bug number for those bugs ?

> Although being a pam bug this causes a lot of garbage email from
> popularity-contest.
> 
> Could you please modify popularity-contest to avoid this? 

It seems you are using stable and I cannot update stable... 
Fortunately /etc/cron.daily/popularity-contest is a config file, so you
can edit it.

Thanks for using popularity-contest!
Bill.

Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Andreas Beckmann]

On 2016-04-07 15:53, Sébastien Jodogne wrote:
> I am really sorry, but despite hours of work and readings, I am still totally 
> unable to reproduce (and thus fix) this bug by myself.
> 
> Andreas (Tille), would it be possible that there was a problem when you 
> uploaded the package last Monday?
> 
> I definitely need someone else to solve this bug. Otherwise, Orthanc will 
> soon disappear from Debian testing.

Try

  pdebuild [pbuilder options] -- --debbuildopts -A

This will produce the broken package.

Looking at your debian/rules
* the dh_link and dh_install calls are wrong for a package producing
multiple binary packages
* dh_install does not belong into the override_dh_auto_install target


Andreas

Bug#820402: Depend on x11-xserver-utils?

[Stephen Paul Weber]

Package: lxrandr
Version: 0.3.0-1

lxrandr without xrandr available only gives an error box ("Unable to get 
montior information").  Installing x11-xserver-utils to get a working xrandr 
command fixes this.  Perhaps it should be added as a dependency?


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature

Bug#742152: _ssl.c:1415: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

[Sebastian Andrzej Siewior]

Control: found -1 1.0.1k-3+deb8u2

On 2016-04-07 14:40:54 [+0200], Fabrizio Lippolis wrote:
> BUG still exists within openssl: 1.0.1k-3+deb8u2 using: debian jessie

Jessie has 1.0.1k-3+deb8u4 by now.
Anyway. This is probably getting us nowhere. Is there someone using the
SDK successfully? Is there a new version of this SDK?
Without a reduced testcase I don't think this will make any progress
within the next decade.
But looking at google, I found one person with the same bug hacking an
email bomb. My guess here based on the error message and goole is that
multiple threads are using the same SSL socket without proper locking.
And this is not openssl's fault.

Sebastian

Bug#805716: resize2fs: Invalid argument While checking for on-line resizing support

[Theodore Ts'o]

On Sat, Nov 21, 2015 at 12:26:20PM +0200, Fathi Boudra wrote:
> Subject: resize2fs: Invalid argument While checking for on-line resizing 
> support
> Package: e2fsprogs
> Version: 1.43~WIP-2015-05-18-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Using latest resize2fs 1.43-WIP (18-May-2015), but same behavior is
> observed on Jessie package.
> 
> I've run a session (see attachment) on a board with 8G eMMC:
> 1. resizing partition works fine, it expands as expected
> 2. resizing the filesystem fails
> 
> resize2fs: Invalid argument While checking for on-line resizing support
> resize2fs: Invalid argument While trying to add group #25

What architecture and kernel version were you using this on?  I'm not
sure how you got the first error message since the code looks like this:

if ((errno != ENOTTY) && (errno != EINVAL)) {
if (errno == EPERM)
com_err(program_name, 0,
_("Permission denied to resize filesystem"));
else
com_err(program_name, errno,
_("While checking for on-line resizing "
  "support"));
exit(1);
}

So if errno is EINVAL, it shouldn't have gotten here.  The only thing
I can think of is if you are using a 32-bit binary on a 64-bit kernel,
or some such, and there was more than one error code that would result
in "Invalid argument" getting printed.

- Ted

Bug#816722: zoom-player: interraction with xscreensaver

[Tormod Volden]

On Thu, Apr 7, 2016 at 10:54 PM, Jamie Zawinski  wrote:
> Having xscreensaver override and ignore the $PATH that the user passed in is 
> a terrible idea.

Since we are in control of where we install the hacks
(/usr/lib/xscreensaver), it is not that bad. But it would prevent the
user from adding his own hacks somewhere random and have them launched
just by setting the $PATH. Unless he patches and rebuilds xscreensaver
himself :)

Is it not possible to specify the full path in the app-default file?
That would address above user case. Or is there other user cases I am
missing?

We do have the problem that there are name clashes. How can we handle
this if we do not ignore (alt. parts of) the $PATH? We wouldn't like
to add a namespace to all the hack binaries to avoid name clashes. And
I don't think it is realistic that the xscreensaver package takes
monopoly on names like "zoom".

Tormod




>
> But if init scripts are involved, perhaps those scripts should launch 
> xscreensaver without /usr/games/ on $PATH.
>
> --
> Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#814766: signon-ui: FTBFS: xvfb-run -a ./tst_inactivity_timer \n Floating point exception (core dumped)

[Chris Lamb]

> I didn't get any segfaults, though I did get this warning.
> 
> signon-ui_0.17+15.10.20150810-2_amd64.build-libEGL warning: DRI2: failed to 
> open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:
> ${ORIGIN}/dri:/usr/lib/dri)

Curiously, I get a *different* FTBFS now:

  Project ERROR: libnotify development package not found.

Full build-log (with packages) attached.


Regards,

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


signon-ui.0.17+15.10.20150810-2.unstable.amd64.log.txt.gz
Description: application/gzip

Bug#819447: acl2: FTBFS in stretch (looks like the same problem in maxima)

[Camm Maguire]

severity 819447 important
thanks

Greetings!  I have a fix for this in the pipeline, but as the problem
only appears under particular and rare memory configurations, and in
particular is absent from the Debian autobuilder infrastructure, I've
lowered the severity.

Thank you for the machine you've provided.  I will check that my fix
addresses acl2 there as well with your permission.

Take care,

Santiago Vila  writes:

> On Mon, Mar 28, 2016 at 05:37:49PM +0200, Santiago Vila wrote:
>
>> The first build was done on a virtual machine with 4GB RAM and 4GB swap.
>> The second build was done on a virtual machine with 8GB RAM and 4GB swap.
>
> BTW: The first build tried to use up to 7200 MB of memory and the
> second build tried to build up to 13900 MB of memory.
>
> I know this because I had a cron job monitoring /proc/meminfo.
>
> So, assuming this is the same problem which happens in maxima, your
> theory that the reason for this is that garbage collection is not
> working properly seems to be consistent with observed data.
>
> Thanks.
>
>
>
>

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

Bug#820347: juce: diff for NMU version 4.1.0+repack-4.1

[Gianfranco Costamagna]

control: reopen -1




>thanks gianfranco or the patch and tobi for checking doing an NMU.


you are welcome :)
>i have just uploaded the package (including some other changes i was
>preparing while the NMU came in).


*thanks*

(I hope you also tested the png interface a little bit ;) )

>just for the record:
>i would prefer if you did not close the NMU-bug manually right after an
>upload to DELAYED/*.
>instead it would be great if the bug was closed automatically once the
>ixed package entered the archive (so if you are doing an NMU that has a
>bug attached to it, please close the bug via the changelog).
>of course feel free to tag the bug as "pending" in the meantime.


true, unfortunately I didn't have any intention to upload this bug,
I did a little (very) little bit of googling, I found some partial solutions
tried to patch, and at the first try... it was compiling correctly.
(no pointers issues, and similar stuff).

I'm still not confident with the patch, because I didn't have knowledge about
why the API changed, and how.

Seems that Tobias (who has a better knowledge than me) appreciated the quality
of the patch, unfortunately nmudiff didn't know about the bug number, because
it wasn't created yet (actually nmudiff created the bug).

So the bug close wasn't available on the patch I sent.

and since we have a transition of ~500 packages, I prefer to proactively close

bugs, instead of forgetting about open RC bugs :)
>speaking of DELAYED: using DELAYED/5 stresses me a *little* bit, but so
>far i was always able to manage a proper upload in time, so i guess it
>is not a big issue :-)


you are completely right,  I'm not sure about why all the rebuilds that
have been performed never showed issues with this package (probably something
in the toolchain was needing a rebuild before this package, so it always ended
up in some dep-wait status).

Anyway, thanks for checking and the upload, it is *really* appreciated.
And sorry for the quick RC bugs, we are actively working in fixing unstable
and this transition in a little time (98% of packages are rebuilding correctly,
we had to NMU 3-4 packages on top of ~20 already schedules biNMUs)

for this reason, if we can manage to quick fix the issues, the old libpng will 
be
hopefully removed soon from the archive :)

thanks for understanding,

Gianfranco

Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Andreas Tille]

Hi Sébastien,

please double check my commits whether all files end up where they
should be.  The package builds nor also for arch all binary packages.

I also fixed some other minor issues.

Hope this helps and let me know if it should be sponsored as it is
now.

Kind regards

 Andreas.

On Thu, Apr 07, 2016 at 03:53:55PM +0200, Sébastien Jodogne wrote:
> Dear all,
> 
> > Right. I was just wondering why this was actually happening on the buildd,
> > until I realised that it was a source-only upload of orthonc.
> > 
> > Sebastien: you can see a log of the package build for arch=all on the
> > package tracker, or directly on
> > 
> > https://buildd.debian.org/status/logs.php?pkg=orthanc=1.0.0%2Bdfsg-2=all
> > 
> > You might want to split the build process of your package into build-arch 
> > and
> > build-indep.
> 
> 
> I am really sorry, but despite hours of work and readings, I am still totally 
> unable to reproduce (and thus fix) this bug by myself.
> 
> Andreas (Tille), would it be possible that there was a problem when you 
> uploaded the package last Monday?
> 
> I definitely need someone else to solve this bug. Otherwise, Orthanc will 
> soon disappear from Debian testing.
> 
> Sorry again,
> Sébastien-
> 

-- 
http://fam-tille.de

Bug#805389: signon-ui: runaway dbus-daemon during build

[Diane Trout]

Hello,

I wasn't able to replicate this issue with an amd64-unstable sbuild chroot on 
my system. I ran it in several times in case it was a intermittent failure.

for a in $(seq 10) ; do sbuild -c unstable-amd64-sbuild signon-
ui_0.17+15.10.20150810-2.dsc ; done

Do you have any thoughts what might be different about our build environments?

Diane

Bug#820401: ciphersaber: FTBFS on binary-indep-only build

[Andreas Beckmann]

Source: ciphersaber
Version: 0.61-4.2
Severity: serious
Justification: fails to build from source

Hi,

ciphersaber builds fine if a full build of the package is requested, but
fails if only the binary-indep packages are to be built (which should
produce the same packages):

https://buildd.debian.org/status/fetch.php?pkg=ciphersaber=all=0.61-4.2=1459571526

The binary-arch and binary-indep targets in debian/rules need to be
swapped: binary-arch should be the no-op one.


Andreas

Bug#814766: signon-ui: FTBFS: xvfb-run -a ./tst_inactivity_timer \n Floating point exception (core dumped)

[Diane Trout]

Hi,

I tried to replicate the bug, and ran an amd64 unstable schroot build in a 
loop 10 times.

I didn't get any segfaults, though I did get this warning.

signon-ui_0.17+15.10.20150810-2_amd64.build-libEGL warning: DRI2: failed to 
open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:
${ORIGIN}/dri:/usr/lib/dri)

Is it still failing for you? and/or what packages did you have installed

Diane

Bug#820400: burp -- Burp is a client/server backup system that saves space and network usage by using librsync. It uses the Volume Snapshot Service for backing up Windows clients.

[Bas van den Dikkenberg]

Package: wnpp
Severity: O

Bug#820373: w3m: SEGFAULT on bogus HTML

[Tatsuya Kinoshita]

Control: tags -1 + patch pending

On April 7, 2016 at 7:10PM +, steve (at steve.org.uk) wrote:
>cat $file | w3m -dump
> (gdb) bt
> #0  wc_N_to_johab1 (code=4294963072) at johab.c:163

Fixed, thank you.

  - 
https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=5a159af05d8556a3f9f8f1a42d8fc153ffbc9694

> PS. I have more samples that crash in the same area of code, I
> suspect that they will all be fixed at once as per #820162, so
> I'm only sharing a pair of files.

Welcome to add more info, so that I'll confirm the problems are
really fixed.

Thanks,
--
Tatsuya Kinoshita


pgpPHh30AFQ_T.pgp
Description: PGP signature

Bug#820225: [d...@sqlite.org: Re: Sqlite 3.12 breaks the Django test suite]

[Richard Hipp]

On 4/7/16, Chris Lamb  wrote:
>> please find attached a patch from upstream. He also indicated that he
>> will
>> release 3.12.1 shortly with the fix.
>
> (Confirmed that this no longer causes the testsuite to segfault for me.)

Thanks for the confirmation.

A slightly different fix will appear in SQLite 3.12.1:
https://www.sqlite.org/src/vdiff?from=153135bfb3b8f7c4=c4b9c611bdcd85f3=1

The SQLite ticket for this issue can be seen at:
https://www.sqlite.org/src/info/7f7f8026eda38

That ticket will be closed soon (perhaps before you read this) then we
will do a few cherry-pick merges onto a branch to create version
3.12.1.  I expect SQLite version 3.12.1 will be available Saturday or
Monday.

-- 
D. Richard Hipp
d...@sqlite.org

Bug#774715: burp: Please update burp package to 1.4.40

[Bas van den Dikkenberg]

I put the package up for adoption 

I am unable to maintain the package

-Oorspronkelijk bericht-
Van: Will Aoki [mailto:wa...@umnh.utah.edu] 
Verzonden: donderdag 7 april 2016 21:50
Aan: 774...@bugs.debian.org
CC: cont...@bugs.debian.org
Onderwerp: Bug#774715: burp: Please update burp package to 1.4.40

retitle 774715 Please update burp package to 1.4.40 tags 774715 patch thanks

All that's really needed for 1.4.40 is a 'quilt refresh': The attached patches 
(against 1.4.40 from the upstream's git) are what I used to make basic 
burp-1.4.40 packages for local use. I've been compiling it on wheezy and 
installing on wheezy & jessie.

I've also been doing some work (not included here, as it's not ready for public 
consumption, but deployed to my servers) to make the burp server run as user 
'backup' out of the box on Debian & to not leave world-readable files with 
backups & passwords lying around.

Bug#820347: juce: diff for NMU version 4.1.0+repack-4.1

[Debian/GNU]

On 04/07/2016 08:38 PM, Tobias Frost wrote:
> On Thu, 7 Apr 2016 18:40:41 +0200 Gianfranco Costamagna  debian.org> wrote:
[...]
>>  
>> Dear maintainer,
>>  
>> I have prepared a patch for juce, but I don't feel confident with it,
> so I didn't upload as NMU.
[...]
> 
> Hi Gianfranco,
> 
> Patch looks good to me.
> I'll take it and schedula an NMU.
> 

thanks gianfranco or the patch and tobi for checking doing an NMU.

i have just uploaded the package (including some other changes i was
preparing while the NMU came in).

just for the record:
i would prefer if you did not close the NMU-bug manually right after an
upload to DELAYED/*.
instead it would be great if the bug was closed automatically once the
ixed package entered the archive (so if you are doing an NMU that has a
bug attached to it, please close the bug via the changelog).
of course feel free to tag the bug as "pending" in the meantime.

speaking of DELAYED: using DELAYED/5 stresses me a *little* bit, but so
far i was always able to manage a proper upload in time, so i guess it
is not a big issue :-)

gfmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#820282: [php-maint] Bug#820282: Please enable fpm by default on Apache

[Mathieu Parent (Debian)]

2016-04-07 12:57 GMT+02:00 Ondřej Surý :
> Hi Mathieu,
>
> I already tried enabling FPM by default but it ended with a weird errors
> on the user side, see:
>
> https://github.com/oerdnj/deb.sury.org/issues/266
>
> So I have disabled it again. It might need a debconf question that can
> be pre-seeded or something like that before we re-enable it again.

The original problem is not about mod_php vs fcgi, but about the fpm
not working by default.

What is required is enabling mod_proxy_fcgi, and ensure it's activated
with the attached patch.

This is just a proof-of-concept, I'll check that later (read: end of April)

> I've been getting a lot of complaints that `apt-get install php` pulls
> apache2 and FPM SAPI is much safer anyway.

I understand. But we have tried to move to php5-fpm in jessie and some
applications didn't work. I won't go into details, but the behavior is
slightly different, and it seems that mod_php is the most used (we
also had problem with mod_auth_cas not working with mpm_workers which
decrease the advantage of fcgi over mod_php). Anyway I don't care that
much about defaults as we use Puppet.


Cheers
-- 
Mathieu Parent
From 1d5174bfaf4219aa5169e9611395f9783a40a168 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Thu, 7 Apr 2016 22:57:41 +0200
Subject: [PATCH] Only use fpm SetHandler when it works

i.e when mod_proxy_fcgi is loaded
---
 debian/php-fpm.conf | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/debian/php-fpm.conf b/debian/php-fpm.conf
index 32c1119..3172a92 100644
--- a/debian/php-fpm.conf
+++ b/debian/php-fpm.conf
@@ -1,19 +1,21 @@
 # Redirect to local php-fpm if mod_php is not available
 
-# Enable http authorization headers
-SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
+
+# Enable http authorization headers
+SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
 
-
-SetHandler "proxy:unix:/run/php/php@php_vers...@-fpm.sock|fcgi://localhost"
-
-
-# Deny access to raw php sources by default
-# To re-enable it's recommended to enable access to the files
-# only in specific virtual host or directory
-Require all denied
-
-# Deny access to files without filename (e.g. '.php')
-
-Require all denied
-
+
+SetHandler "proxy:unix:/run/php/php@php_vers...@-fpm.sock|fcgi://localhost"
+
+
+# Deny access to raw php sources by default
+# To re-enable it's recommended to enable access to the files
+# only in specific virtual host or directory
+Require all denied
+
+# Deny access to files without filename (e.g. '.php')
+
+Require all denied
+
+
 
-- 
2.8.0.rc3

Bug#816722: zoom-player: interraction with xscreensaver

[Jamie Zawinski]

Having xscreensaver override and ignore the $PATH that the user passed in is a 
terrible idea.

But if init scripts are involved, perhaps those scripts should launch 
xscreensaver without /usr/games/ on $PATH.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#820399: How will Jessie get the important upstream security fix for Samba (smb/cifs) badlock (details embargod until April 12, 2016)?

[Michael Evans]

Package: samba

Version: 2:4.1.17+dfsg-2+deb8u2

Severity: grave

Tags: security,fixed-upstream,wheezy,jessie,sid,experimental

 

(Severity listed as grave as the scope of the security issue is not yet
public; it may be critical, and a lesser vulnerability level was not
enumerated that reflects a potentially serious security issue.)

 

The security vulnerability mentioned on samba.org
(https://www.samba.org/samba/latest_news.html ) (links to
http://badlock.org/ ) will only be released for Samba versions in the 4.2
and higher releases; as Debian Stable (Jessie) presently has a 4.1.x release
it will not receive this patch.

 

The severity and impact of not releasing an updated upstream version is
unknown, and I am quite worried that there isn't a backports version of the
Samba packages to use a version that should (easily) have the security patch
included.

 

 

Bug#820398: Lyx crashes with SIGILL on processors without cmov

[Johann Klammer]

Package: lyx
Version: 2.1.4-2

I got this while trying to build ngspice on my fileserver
(it holds the debian installation here, 
and ngspice dropped from testing)

[...]
dh_testdir
#cd build/manual && lyx --export ps manual.lyx.
cd build/manual && lyx --export pdf2 manual.lyx.
/home/klammerj/projects/dc_dc/ngspice-26/build/manual
/bin/sh: line 1:  1742 Illegal instruction lyx --export pdf2 manual.lyx
debian/rules:78: recipe for target 'build-indep' failed
make: *** [build-indep] Error 132
make: *** Waiting for unfinished jobs
[...]

trying to run the thing in gdb yields:

[...]
(gdb) bt
#0  0xb7f386b9 in 
boost::object_cache::do_get(boost::re_detail::cpp_regex_traits_base const&, unsigned int) ()
   from /usr/lib/i386-linux-gnu/libboost_regex.so.1.58.0
#1  0xb7f43b3b in boost::basic_regex >::do_assign(char const*, char const*, unsigned 
int) ()
   from /usr/lib/i386-linux-gnu/libboost_regex.so.1.58.0
[...]
(gdb) disass 0xb7f386b9,+20
Dump of assembler code from 0xb7f386b9 to 0xb7f386cd:
=> 0xb7f386b9 
<_ZN5boost12object_cacheINS_9re_detail21cpp_regex_traits_baseIcEENS1_31cpp_regex_traits_implementationIcEEE6do_getERKS3_j+1241>:
  cmove  -0x74(%ebp),%eax
   0xb7f386bd 
<_ZN5boost12object_cacheINS_9re_detail21cpp_regex_traits_baseIcEENS1_31cpp_regex_traits_implementationIcEEE6do_getERKS3_j+1245>:
  mov%eax,-0x74(%ebp)
[...]

Bug#819943: really should add an unforbid-version command

[積丹尼 Dan Jacobson]

> "MAFM" == Manuel A Fernandez Montecelo  
> writes:

MAFM> spend more time on re-reading the whole 3 paragraphs of documentation of
MAFM> this feature and see how they make sense.

Yes but most people take a quick look at the part of man pages they need
to check. Anyways as a long time reader of Risks Digest...

Bug#820385: swap-cwm: Section should be “web”

[Jonas Smedegaard]

Quoting Ben Finney (2016-04-07 22:16:07)
> On 07-Apr-2016, Jonas Smedegaard wrote:
> > Quoting Ben Finney (2016-04-07 21:38:04)
> > > By the section descriptions, this package belongs in section “web”.
> > > 
> > > Please set the field “Section” appropriately on this package.
> > 
> > You are so very right. This is a kind of bug I get annoyed by
> > myself, and am embarrassed to have failed with some of "my"
> > packages.
> > 
> > Thanks a lot for reporting! And in you usual elaborate style.
> 
> You're welcome, it's good to have minor bug reports appreciated :-)
> 
> > > Since the package is already in Debian with a different section,
> > > you will also need to submit a request to override the existing
> > > section
> > > .
> > 
> > Oh, I didn't know that detail. Thanks for educating me!
> 
> That is IMO a flaw in the archive system; I don't know the reasons why
> Section values don't automatically propagate, and haven't spent time
> to investigate. In the meantime, we are stuck with requesting that
> manual override.

Turned out I _had_ already fixed this issue a year ago, so only thing 
remaining is that ftpmaster nudging.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#820397: fonts-fantasque-sans: some glyphs unsuitable for programming

[Ben Finney]

Package: fonts-fantasque-sans
Version: 1.7~alpha.2~dfsg-2
Severity: normal
Tags: upstream

The font Fantasque Sans Mono is described as being suitable for
programmers. However, its glyphs fail to sufficiently distinguish
important characters.

In particular:

* The glyphs for accent characters ,  do not match
  correctly. They should be left-right mirror images, but instead the
  “grave” accent incorrectly looks like a single-open-quote glyph.

* The single-quote characters , ,  have
  glyphs that are virtually indistinguishable. The  glyph
  should not be left or right biased.

  By comparison, the double-quote characters , ,
   have conventional and sufficiently distinct glyphs.

There may be other glyphs which in this font are unhelpful to
programmers, but these have caught my attention.


-- 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_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
 \ “I was in the first submarine. Instead of a periscope, they had |
  `\   a kaleidoscope. ‘We're surrounded.’” —Steven Wright |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#816722: zoom-player: interraction with xscreensaver

[Tormod Volden]

On Sat, Mar 5, 2016 at 5:22 PM, Alexandre Detiste
 wrote:
> Le samedi 5 mars 2016, 16:29:41 Stephen Kitt a écrit :
>>
>> Or perhaps xscreensaver-demo should only look in /usr/lib/xscreensaver...
>> (For the xscreensaver maintainers: the context here is that the zoom-player
>> package provides /usr/games/zoom, which xscreensaver attempts to use for its
>> Zoom screensaver if xscreensaver-data-extra isn't installed.)
>
> Awww, I found a duplicate:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794719
>
> xscreensaver-data: runs /usr/bin/barcode rather than 
> /usr/lib/xscreensaver/barcode

Yup, this is a bit hairy, not easy to make a solution that is 100%
without patching much of the original code. However in most cases,
restricting it to /usr/lib/xscreensaver would fix the issue. There
might be some cases where a program from another package can be used,
but that can maybe be fixed by patching these individual cases in the
app-defaults file.

As upstream points out in the other report, the use of one
app-defaults file but multiple hack collection packages complicates
the issue.

>
> I'd like to help on this bug, and the 106 other ones.
>

Alexandre,

That would be fantastic!

Best regards,
Tormod

Bug#817748: Acknowledgement (cups-daemon will not fully install )

[info2014]

Some additional information: 
Many of the writeups on cups assume that a web-browser 
will be used. This is probably not a good idea. Certainly 
in my use I have set the browser permissions to prevent 
pop-up windows from appearing. This also prevents the 
user interaction to authenticate or authorise printing to 
a remote machine. 

I'm not an expert on security, so do not read this as 
advice for your printer setup. 

Bug#813119: ngspice: FTBFS with nonexistant $HOME

[Johann Klammer]

Try this debian/rules file.

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

export CPPFLAGS=$(shell dpkg-buildflags --get CPPFLAGS)
export CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
export CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS)
export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)

# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
else
CROSS= --build $(DEB_BUILD_GNU_TYPE)
endif

CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS)

config.status: config.status-stamp configure
config.status-stamp:
dh_testdir
# Make build dir for ngspice
mkdir -p build/ngspice
cp -Rl `ls . |grep -v build|grep -v debian` build/ngspice
cp -f /usr/share/misc/config.sub build/ngspice/config.sub
cp -f /usr/share/misc/config.guess build/ngspice/config.guess
#cp -f /usr/share/misc/config.sub build/ngspice/doc/config.sub
#cp -f /usr/share/misc/config.guess build/ngspice/doc/config.guess
cp -a manual build/
# Make build dir for tclspice
mkdir -p build/tclspice
cp -Rl `ls . |grep -v build|grep -v debian` build/tclspice
cp -f /usr/share/misc/config.sub build/tclspice/config.sub
cp -f /usr/share/misc/config.guess build/tclspice/config.guess
# Configure ngspice
(cd build/ngspice;\
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
LDFLAGS="$(LDFLAGS)" \
./configure $(CROSS) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--enable-maintainer-mode \
--with-editline=yes \
--enable-xspice \
--enable-cider \
--disable-debug)
# Configure tclspice
(cd build/tclspice;\
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
LDFLAGS="$(LDFLAGS) -lBLT -ltcl8.6" \
./configure $(CROSS) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--libdir=/usr/lib/tcltk \
--enable-shared=yes \
--enable-maintainer-mode \
--with-editline=no \
--enable-xspice \
--enable-cider \
--disable-debug \
--disable-x \
--with-tcl=/usr/lib/tcl8.6)
touch $@

build: build-arch build-indep

build-arch: config.status 
dh_testdir
cd build/ngspice && $(MAKE)
cd build/tclspice && $(MAKE)
touch $@

build-indep: config.status
# Build documentation
dh_testdir
#cd build/manual && lyx --export ps manual.lyx 
cd build/manual ; mkdir "./.lyx" ; lyx -userdir "./.lyx" -batch 
--export pdf2 manual.lyx ; rm -rf "./.lyx"
cd build/manual ; mkdir "./.lyx" ; lyx -userdir "./.lyx" -batch 
--export html manual.lyx ; rm -rf "./.lyx"
touch $@

clean:
dh_testdir
dh_testroot
rm -f build-stamp 
rm -f config.status-stamp
rm -rf build
rm -f src/frontend/parse-bison.c
rm -f src/frontend/parse-bison.h
rm -f config.guess
rm -f config.sub
rm -f *-indep *-arch
dh_clean 

install-arch: build-arch
dh_testdir
dh_testroot
dh_prep
dh_installdirs

# Make ngspice and tclspice
# tclspice must be installed prior to ngspice. Some files will be 
overwritten by ngspice
# but the ngspice are the correct ones.
cd build/tclspice && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install 
cd build/ngspice && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
# The code mode were stripped but change since version 25
#ifneq ("nostrip","$(findstring nostrip,$(DEB_BUILD_OPTIONS))")
#strip $(CURDIR)/debian/tmp/usr/lib/ngspice/*.cm
#strip $(CURDIR)/debian/tmp/usr/lib/tcltk/ngspice/*.cm
#endif

# Remove empty dirs:
find $(CURDIR)/debian/tclspice -type d -empty -delete
touch $@

install-indep: build-indep
# Documentation for ngspice, the same as for tclspice
mkdir -p $(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/html
cp -a $(CURDIR)/build/manual/manual.html.LyXconv/* \
$(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/html
#install -o root -g root -m 644 build/manual/manual.ps \
#   $(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/ngspice.ps
install -o root -g root -m 644 build/manual/manual.pdf \

Bug#807616: [Pkg-xfce-devel] Bug#807616: lightdm: Lightdm (and KDM) does not autologin on desktop computers

[oldtechaa]

I believe this bug may have come about due to operator error. I may have
been uncommenting the lines
# autologin-user = User ..
# autologin-user-timeout = ..

Due to the fact that these lines are not after the [SeatDefaults] line,
they were not being accepted. I'll close this bug.

Bug#820396: override: swap-cwm:web/optional

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Almost a year ago, swap-cwm 1.2.1-6 changed its sectio to web.

Apparently that was not effectuated, as reported in bug#820385.

Please change section of swap-cwm to web.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXBsakAAoJECx8MUbBoAEho6MP/2EQZUdsMPrdw9j7FBTB5mPS
A+OZiMCF236QQHqRWPPb+d6hpQCmTbjwEVYnuPD/Vm2vyYi9bzpXAFNKfuD9uPud
ANGeaxmVorMg7r2EAJmJgL5/oKrQWlYflK0r4b913ekFpXTeeoaWeuHUlkL+jUvw
Lza4aOYNtrtMwEbtw7aV4amHzc8Kb9fEsTiss7PxGEovhwpo7RSeXixFEODmRPT+
kGWRhmSnsNpPAAvnsuMM0U12XF0sCINXmKDImIPejHx23t0hJY1D+3PQeHGHLrw4
+SYuSbbAJNBBufvClMdtQJwQ8ky0pGJAV8x9mMhI/m7l87wgDBjw8HMZ6TSBRpki
orW3pwRDJNLCITbxNmlbh49GjaBD0AuFR2841AkRhRp4kW68rz1GwktyNHLyoAuW
iUz6nnU9h/rXkfXK02A3tW6HbOrC0oiL8XX8glDMBHFdqEpJ8i/GrH417KQ7AqmE
e27rYrOldGXqBXOEb3I61j2O33jT88o7cDGwH4QfZV8s/dX9YDHTNnX8ISfH1zl0
F0uhPiQV2UwzXg/C0d9dOHq+ZIbckkCGaLdCJSDbHKE367UeLz7WKnJGMykPWCiz
g726f8s0Xca5G0pre/qmvttKogfTc8zpmKXqpK0ye4YOrqrpyRdkVJzZY3WK3wzl
6ANKopxMneOOFPKFi9E/
=dEbw
-END PGP SIGNATURE-

Bug#820342: [pkg-gnupg-maint] Bug#820342: gpa send public key to server despite the refusal of the user

[Werner Koch]

On Thu,  7 Apr 2016 17:18, rpn...@free.fr said:

> (x) to close this box, so it is the same as to click on Yes, the key is 
> even though sent to the server. It is not the choice of the user. It is 

This has been fixed in 0.9.8 with
commit 071ed43fac92c68c46a1a8fb19a435eebb8927e6.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Bug#820395: dh-make-perl: Don't use local::lib $HOME/perl5 location for --build of .deb

[Jacob L Anawalt]

Package: dh-make-perl
Version: 0.84-2
Severity: wishlist

Dear Maintainer,

I used dh-build-perl --requiredeps --build --cpan to build some modules
not currently available in Debian 8 (jessie) and was surprised to find
that installing the .deb package put files into $HOME/perl5.

If I instead ran dh-build-perl --requiredeps --cpan  and then
changed into the directory and ran debuild the generated .deb installed
into ./usr and not into ./home/jacob/perl5

After getting some help to sort this out in #debian-perl from gregoa and
mst I saw that it wasn't anything in .cpan, but some local::lib
environment variables added to my .bashrc file that was causing this. It
was suggested by mst that dh-build-perl --build might be picking up
local::lib settings and debuild controls the environment variables more
strictly.

Before getting help on #debian-perl I had tried blowing away .cpan
several times and re-downloaded and re-built the modules without any
change. I then started trying without different options to find that it
was the --build option that put the ~/perl5 path into the package.

After getting help and commenting out the .bashrc Perl environment
variables and attempting again in a new terminal --build created
packages that were rooted in ./usr just like debuild.

Since the point of --build is to create the binary .deb package and it
is expected that a .deb installs to ./usr, please change the --build
code to sanitize the environment or whatever so that it doesn't build a
.deb with local::lib paths. It was confusing and time consuming to
figure out why the .deb packages were putting files into ./home.

These are the lines that appeared in my .bashrc the same day I first
tried building on this system. I suspect I answered a CPAN config
question the wrong way to have these added. I commented them out to fix
the problem.

PATH="/home/jacob/perl5/bin${PATH+:}${PATH}"; export PATH;
PERL5LIB="/home/jacob/perl5/lib/perl5${PERL5LIB+:}${PERL5LIB}"; export
PERL5LIB;
PERL_LOCAL_LIB_ROOT="/home/jacob/perl5${PERL_LOCAL_LIB_ROOT+:}${PERL_LOCAL_LIB_ROOT}";
export PERL_LOCAL_LIB_ROOT;
PERL_MB_OPT="--install_base \"/home/jacob/perl5\""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/home/jacob/perl5"; export PERL_MM_OPT;


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

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

Versions of packages dh-make-perl depends on:
ii  debhelper 9.20150101
ii  dpkg-dev  1.17.26
ii  fakeroot  1.20.2-1
ii  libapt-pkg-perl   0.1.29+b2
ii  libarray-unique-perl  0.08-1
ii  libclass-accessor-perl0.34-1
ii  libcpan-meta-perl 2.142690-1
ii  libdpkg-perl  1.17.26
ii  libemail-address-perl 1.905-2
ii  libemail-date-format-perl 1.005-1
ii  libfile-which-perl1.09-1
ii  liblist-moreutils-perl0.33-2+b1
ii  libmodule-depends-perl0.16-1
ii  libparse-debcontrol-perl  2.005-4
ii  libparse-debianchangelog-perl 1.2.0-1.1
ii  libsoftware-license-perl  0.103010-3
ii  libtie-ixhash-perl1.23-1
ii  libwww-mechanize-perl 1.73-2
ii  libyaml-libyaml-perl  0.41-6
ii  libyaml-perl  1.13-1
ii  make  4.0-8.1
ii  perl  5.20.2-3+deb8u4
ii  perl-modules [libcpan-meta-perl]  5.20.2-3+deb8u4

Versions of packages dh-make-perl recommends:
ii  apt-file  2.5.4
ii  git   1:2.1.4-2.1+deb8u2
ii  pristine-tar  1.33

dh-make-perl suggests no packages.

-- no debconf information

Bug#820394: RM: blender [hurd-i386] -- RoQA; new B-D libjemalloc-dev missing on hurd

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

blender recently added a B-D: libjemalloc-dev which has never been built
successfully on hurd-i386 so far.


Andreas

Bug#820225: [d...@sqlite.org: Re: Sqlite 3.12 breaks the Django test suite]

[Chris Lamb]

> please find attached a patch from upstream. He also indicated that he will
> release 3.12.1 shortly with the fix.

(Confirmed that this no longer causes the testsuite to segfault for me.)


Regards,

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

Bug#819724: Please find a second maintainer

[Tormod Volden]

On Thu, Apr 7, 2016 at 9:25 AM, Goswin von Brederlow  wrote:
> The BTS is not just for the maintainer. It also documents things for
> users. Like what bugs are already known.
>
> When I see a package with lots of patches in the BTS my willingness to
> patch something myself goes right down the drain. Who would want to
> spend their time writing patches if the maintainer will just ignore
> them for years?

There are only 3 patches in there all together. They have all been
reviewed and rejected by upstream. Maybe one, if rewritten, could be a
candidate for a Debian specific patch (tmp files location).

>
> I'm sure you handled all the security stuff as you say but you are the
> only one that knows that. Everyone else looks at the BTS and sees bugs
> tagged security. When I see a package in the BTS with bugs tagged
> security then I start to worry.

You have a point there, appearances may give the wrong impression. I
will take a look at getting rid of these, for example the LDAP bug you
mention below. Also since some very uninformed people may not
understand that we backport all valid security fixes to stable (I've
seen lot a of stupid remarks lately).

> That would be just a drive-by shooting. You won't get more info just
> ebcause someone sets the more-info tag. One also has to track down the
> submitter and at least test the issue itself too. Since I don't use
> LDAP that would be rather a lot of work. And what for? If I write a
> patch it's just going to rot in the BTS form all apearances. See my
> point?

That bug was maybe not a good example, but there are many places where
a drive-by contributor can be useful. Of course someone with a longer
perspective is much preferred. But often large contributions starts
with small steps, scratching their own itch, for then to be pulled in.

>
> Saddly that is also not how it works. Usualy a package rots away for
> years getting worse and worse before it finally blows and someone else
> gets so fed up with it and steps up to take over. You are doing a too
> good job for that to happen. Sometimes you have to get the word out
> that help is needed or simply just wanted to attract someone.

I think we both are just sketching up possible ways this works or not.

Anyway, it is probably good if I make clear that I am welcoming
co-maintainers. This is how we ran it before, just that the previous
co-maintainer had more important issue to attend to and had to step
down. Unlike some other maintainers I am in favour of collective and
shared maintenance.

>
> Front desk is part of the new maintainer process and is staffed by a
> few people:
>
>   https://nm.debian.org/public/managers
>
> I think the alias for it is front-d...@debian.org. And the long line
> of people longing to help out is every person wanting to become Debian
> Maintainer or Debian Developer. So yeah, there is aline. Wether they
> will stay with your package after they completed the NM process or not
> is up in the air. Maybe they will, maybe they won't. It's unlikely
> though. But hey, if you do this once every 3 years the BTS will look a
> lot cleaner and eventually someone will stick. :)

Thanks for the link, I will check it out.

Regards,
Tormod

Bug#817748: Acknowledgement (cups-daemon will not fully install )

[info2014]

An update on my problems installing cups. This just covers 
the hilights of sorting out the problems, and my writeup 
will be specific to the problems on my particular setup. 

I got the various components of the cups daemon to install 
by manually either reinstalling or copying files to where 
they needed to be to let the installation continue. So 
eventually got success with : 

# systemctl start cups.service

I'm running xfce as a windows manager, and to print I 
used samba to print via a networked printer on a Windows7
machine. I tried using the cups daemon to print simple 
text files, and also used smbclient to try to verify that 
the networked part of the system was working properly.
I'd set up the windows smb share using firefox. 
Although samba allowed me to login to my windows shares, 
when I tried to print I got various messages including 
NT_STATUS_BAD_NETWORK_NAME
I'd guess that is progress compared to 
NT_STATUS_LOGON_FAILURE

Fortunately I had a copy of /etc/cups/printer.conf from
a backup made before the system crashed a couple of months 
ago, and I knew it worked. The relevant code is

DeviceURI smb://192.168.1.3/HP%20Deskjet%201510%20series

something different from the tidy writeups on web pages 
explaining how these things work. 
I also noted that the printer ppds offered by 
cups+gutenprint  a) had no close match to my printer, 
and b) were different from the codes identified by the 
printer.conf file. I dumped cups+gutenprint, installed 
the foomatic ppd's and set up a new printer with the 
new drivers. Still no success, but the error messages 
were a little cleaner. I was getting : cups filter 
failed - can't detect file type. 

I figured it was time to try printing a .pdf file, and 
installed cups-pdf. This is a dummy transitional package 
that should have set up a new PDF printer. The .pdf 
files are the basic files that cups uses, so file detection 
was less likely to be a problem. 

This time I loaded up a .pdf file in gimp, and printed 
the file. No success, but the error messages said that 
libqpdf was a problem. I installed libqpdf13. This time 
when the file print instruction was activated in gimp, 
a window popped up asking for a username and password. 
Success!

Well, success for .pdf files. Txt files still would not 
print, but at least the problem was narrowed down to 
getting a username and password off over the network to 
the windows share. 

I'd noted that in the Applications Menu the "print settings" 
used to bring up a printer management program, and months 
ago, when files did not print straightaway, I could select 
the job in the printer queue and authenticate it. 

The application is called 
system-config-printer

I reinstalled this, reinstalled it python dependencies, and 
finally python-pycurl. "print-settings" now opens up the 
printer app. I could see the print queue, and authenticate 
the held files in the drop-down menu. This brings up 
a login window, one per file, but it works. Finally.   

Bug#820385: swap-cwm: Section should be “web”

[Ben Finney]

On 07-Apr-2016, Jonas Smedegaard wrote:
> Quoting Ben Finney (2016-04-07 21:38:04)
> > By the section descriptions, this package belongs in section “web”.
> > 
> > Please set the field “Section” appropriately on this package.
> 
> You are so very right. This is a kind of bug I get annoyed by
> myself, and am embarrassed to have failed with some of "my"
> packages.
> 
> Thanks a lot for reporting! And in you usual elaborate style.

You're welcome, it's good to have minor bug reports appreciated :-)

> > Since the package is already in Debian with a different section,
> > you will also need to submit a request to override the existing
> > section
> > .
> 
> Oh, I didn't know that detail. Thanks for educating me!

That is IMO a flaw in the archive system; I don't know the reasons why
Section values don't automatically propagate, and haven't spent time
to investigate. In the meantime, we are stuck with requesting that
manual override.

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney 


signature.asc
Description: PGP signature

Bug#820393: erlang-p1-stun: FTBFS on hurd-i386: One or more eunit tests failed.

[Andreas Beckmann]

Source: erlang-p1-stun
Version: 1.0.1-1
Severity: important

Hi,

erlang-p1-stun FTBFS on hurd-i386, but the previous releases
successfully built there:

https://buildd.debian.org/status/fetch.php?pkg=erlang-p1-stun=hurd-i386=1.0.1-1=1457060170


If that is not trivially fixable, please request decrufting of the
outdated binary packages (and their rdepends).


Andreas

Bug#820378: Ensure users report bugs in BTS and not to upstream directly

[anarcat]

I think this patch is a great idea!

Unfortunately, there is no obvious way to file a bug from the URL used:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xscreensaver;dist=unstable

(that is the target of the redirection.)

We are doing a poor job at helping people file bugs, generally. I
usually point people to:

https://www.debian.org/Bugs/Reporting

but that's a little horrible as well...

Not sure what the best fix is here, but pointing people to
bugs.d.o/xscreensaver will certainly not help our users. :)

A.

PS: great job on that other bug report btw, Tormod. :)

-- 
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg


signature.asc
Description: Digital signature

Bug#820352: [Pkg-utopia-maintainers] Bug#820352: network-manager: usb ath9k wifi asigned default wired connection at boot

[Michael Biebl]

Hi Jason,

Am 07.04.2016 um 19:30 schrieb Jason Woofenden:
> 
> Every time I boot linux (2-ish times per day) NetworkManager won't
> connect to my wifi, because it thinks my wifi card is an ethernet
> device.

It would be great if you can file this bug upstream at

https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
and report back with the bug number.

It's hard for me to reproduce the issue, since I don't own such a hardware.

What you might include in the upstream bug report is the
udevadm info /sys/class/net/X
output of the device directly after boot and after you unplug/plug it.

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



signature.asc
Description: OpenPGP digital signature

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

Hi Gianfranco, thanks for the RFS :)

First, some info:

Upstream released python-neovim-gui_0.1.2.
That depends on python-neovim >= 0.1.6, which I already have packaged
and not uploaded, since python-neovim depends on neovim >= 0.1.3,
currently unreleased git master branch, which is changing.

We could send the tagged python-neovim-gui_0.1.1 to NEW, as it works
with Debian's neovim_0.1.2 and python-neovim_0.1.2, but this version
has some quirks that I would like to be fixed prior to shipping it. [1]

Therefore, I have imported the new upstream version 0.1.2, which fixes
some of the problems on the review, but we can't ship until we have
neovim_0.1.3.

On 06/04/16 13:22, Gianfranco Costamagna wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi Victor,
> 
> - please meld changelog in a single entry

Fixed, removed Ondrej entry because if not it thinks it's an NMU.

> install_requires = [
> 'neovim>=0.1.3',
> 'click>=3.0',
> 'pygobject'
> ]
> 
> please add them as build-dependencies and check that python3:Depends do its 
> job

Fixed.
 * Added neovim check.
 * python3-click is only present on testing and unstable as 6.2, I have
   added the check but it could be dropped.
 * pygobject is provided by python3-gi-cairo, python3-cairo,
   gir1.2-gtk-3.0 as jpleau and I tracked down [2][3].

> upstreaming the desktop file and the svg file is appreciated :)
> (also installing it inside setup.py, to avoid overrides in debian packaging)

Already upstreamed on 0.1.2.
I haven't added the install inside setup.py since I wasn't sure it of
the best way to make it work on all downstreams.

> I usually prefer instead of a clean override something like
> echo "neovim_gui/screen.c" >> debian/clean

New version now ships a neovim_gui/screen.c. After a conversation at
#debian-mentors and #python, Debian side I concur that we shouldn't
be shipping it and that upstream should include the cythonize on the
build, yet python docs say "distribute both .c and .py, don't build"
[6]. I will leave the .c there for now.

> does -pie breaks the build? why?
> (link error? maybe adding some -l flags is enough?)

Documented it on the commit message, please tell me if it's enough [4].

> check-all-the-things review:
> pyflakes3 .

Reported upstream, where I will tackle it [5].



Also, I now get an experimental lintian:
X: python3-neovim-gui: library-package-name-for-application usr/bin/pynvim

Should we rename the package as `pynvim` and move it to DPAT instead of
DPMT, even if it is provided by PyPi's module `neovim-gui`?



Cheers,


[1]: https://github.com/neovim/python-gui/issues/16
[2]: https://github.com/neovim/python-gui/issues/5
[3]:
https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git/commit/?id=9bee986b0f35806517ae6d3dc7f2e882df95ef72
[4]:
https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git/commit/?id=e4f8f3de0874cc2c8f57a84f7fc182d23a1eed8a
[5]: https://github.com/neovim/python-gui/issues/17
[6]:
http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules



signature.asc
Description: OpenPGP digital signature

Bug#820385: swap-cwm: Section should be “web”

[Jonas Smedegaard]

Quoting Ben Finney (2016-04-07 21:38:04)
> The section “python” is for packages that install the Python 
> programming language or libraries. Its packages are primarily of 
> interest only to Python programmers.
> 
> The package ‘swap-cwm’ installs primarily an application, of interest 
> regardless of the programming language. It should not be in the 
> “python” section.
> 
> By the section descriptions, this package belongs in section “web”.
> 
> Please set the field “Section” appropriately on this package.

You are so very right.  This is a kind of bug I get annoyed by myself, 
and am embarrassed to have failed with some of "my" packages.

Thanks a lot for reporting!  And in you usual elaborate style.


> Since the package is already in Debian with a different section, you
> will also need to submit a request to override the existing section
> .
> 
> Then mark this bug report as blocked by that new one.

Oh, I didn't know that detail. Thanks for educating me!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#820392: xapers: Section should not be “python”

[Ben Finney]

Package: xapers
Version: 0.6-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘xapers’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package may belongs in section “doc”
or “misc”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \“The number of UNIX installations has grown to 10, with more |
  `\ expected.” —Unix Programmer's Manual, 2nd Ed., 1972-06-12 |
_o__)  |
Ben Finney 

Bug#774715: burp: Please update burp package to 1.4.40

[Will Aoki]

retitle 774715 Please update burp package to 1.4.40
tags 774715 patch
thanks

All that's really needed for 1.4.40 is a 'quilt refresh': The attached
patches (against 1.4.40 from the upstream's git) are what I used to make
basic burp-1.4.40 packages for local use. I've been compiling it on
wheezy and installing on wheezy & jessie.

I've also been doing some work (not included here, as it's not ready for
public consumption, but deployed to my servers) to make the burp server
run as user 'backup' out of the box on Debian & to not leave
world-readable files with backups & passwords lying around.

>From 3115f407aecddd15c1b0f0f3a3f1d78bc53417e8 Mon Sep 17 00:00:00 2001
From: Will Aoki 
Date: Wed, 30 Mar 2016 15:29:01 -0600
Subject: [PATCH 1/2] initial update to 1.4.40

---
 debian/changelog   |7 +++
 debian/patches/disable_tests.patch |   12 +++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index ac12f61..0289328 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+burp (1.4.40-1umnh0) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release
+
+ -- Will Aoki   Wed, 30 Mar 2016 15:07:15 -0600
+
 burp (1.3.48-1) unstable; urgency=low
 
   * New upstream release.
diff --git a/debian/patches/disable_tests.patch b/debian/patches/disable_tests.patch
index 37fd495..40e5226 100644
--- a/debian/patches/disable_tests.patch
+++ b/debian/patches/disable_tests.patch
@@ -9,11 +9,13 @@ Bug: 
 Reviewed-By: Bastiaan Franciscus van den Dikkenberg 
 Last-Update: <2014-01-09>
 
 burp-1.3.46.orig/test/test_self
-+++ burp-1.3.46/test/test_self
-@@ -12,6 +12,16 @@ path="$PWD"
- build="$path/build"
- target="$path/target"
+Index: burp/test/test_self
+===
+--- burp.orig/test/test_self	2016-03-30 15:05:57.744780009 -0600
 burp/test/test_self	2016-03-30 15:10:30.467193993 -0600
+@@ -22,6 +22,16 @@
+ 	exit 0
+ fi
  
 +if ! [ -c /dev/random -o -c /dev/urandom ] &&
 +   ! [ -e /var/run/egd-pool -o -e /dev/egd-pool -o -e /etc/egd-pool -o -e /etc/entropy ]
-- 
1.7.10.4

>From 13d2d1df2dcd4881db05368d19906c28164cd64b Mon Sep 17 00:00:00 2001
From: Will Aoki 
Date: Wed, 30 Mar 2016 15:29:35 -0600
Subject: [PATCH 2/2] ignore .pc used by quilt

---
 .gitignore |1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index aa57078..61b43b8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ config.status
 libtool
 src/bedup
 src/burp
+.pc
-- 
1.7.10.4

Bug#820391: wapiti: Section should be “web”

[Ben Finney]

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

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘wapiti’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section “web”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \   “If you write the word ‘monkey’ a million times, do you start |
  `\  to think you're Shakespeare?” —Steven Wright |
_o__)  |
Ben Finney 

Bug#820390: vitables: Section should not be “python”

[Ben Finney]

Package: vitables
Version: 2.1-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘vitables’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package may belong in section
“science” or “utils”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \   “Two possibilities exist: Either we are alone in the Universe |
  `\   or we are not. Both are equally terrifying.” —Arthur C. Clarke, |
_o__) 1999 |
Ben Finney 

Bug#820389: virtaal: Section should not be “python”

[Ben Finney]

Package: virtaal
Version: 0.7.1-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘virtaal’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package may belong in section
“editors” or “devel”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \ “If you can do no good, at least do no harm.” —_Slapstick_, |
  `\ Kurt Vonnegut |
_o__)  |
Ben Finney 

Bug#820388: variety: Section should be “x11”

[Ben Finney]

Package: variety
Version: 0.6.0-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘variety’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section “x11”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \ “Simplicity and elegance are unpopular because they require |
  `\   hard work and discipline to achieve and education to be |
_o__)appreciated.” —Edsger W. Dijkstra |
Ben Finney 

Bug#820387: uucp-lmtp: Section should be “mail”

[Ben Finney]

Package: uucp-lmtp
Version: 0.20130117+nmu1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘uucp-lmtp’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section “mail”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \“Most people don't realize that large pieces of coral, which |
  `\   have been painted brown and attached to the skull by common |
_o__)wood screws, can make a child look like a deer.” —Jack Handey |
Ben Finney 

Bug#820386: typecatcher: Section should not be “python”

[Ben Finney]

Package: typecatcher
Version: 0.2-2
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘typecatcher’ installs primarily an application, of
interest regardless of the programming language. It should not be in
the “python” section.

By the section descriptions, this package may belongs in section “web”
or “fonts”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \ “I was gratified to be able to answer promptly and I did. I |
  `\   said I didn't know.” —Mark Twain, _Life on the Mississippi_ |
_o__)  |
Ben Finney 

Bug#820308: qiime: many unsatisfiable dependencies

[Andreas Tille]

Hi Tim,

it seems I trapped into the pitfall to upload qiime with the
dependencies as available in BioLinux.  The three first missing
Dependencies (for amd64) are a real problem while the other could
probably be fixed by restricting the architectures to amd64 only.

Our last conversation about these depencencies was IMHO here:

   
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2015-October/035295.html

Tim, please help.  I feel totally unable to sort this out.

Kind regards

   Andreas.

On Thu, Apr 07, 2016 at 12:01:10PM +0200, Andreas Beckmann wrote:
> Package: qiime
> Version: 1.9.1+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> qiime/amd64 unsatisfiable Depends: python-burrito-fillings (>= 0.1.1)
> qiime/amd64 unsatisfiable Depends: qiime-default-reference
> qiime/amd64 unsatisfiable Depends: emperor (>= 0.9.51)
> qiime/i386 unsatisfiable Depends: python-burrito-fillings (>= 0.1.1)
> qiime/i386 unsatisfiable Depends: qiime-default-reference
> qiime/i386 unsatisfiable Depends: bwa
> qiime/i386 unsatisfiable Depends: emperor (>= 0.9.51)
> qiime/i386 unsatisfiable Depends: swarm
> qiime/i386 unsatisfiable Depends: vsearch (>= 1.1.1)
> qiime/arm64 unsatisfiable Depends: python-burrito-fillings (>= 0.1.1)
> qiime/arm64 unsatisfiable Depends: qiime-default-reference
> qiime/arm64 unsatisfiable Depends: bwa
> qiime/arm64 unsatisfiable Depends: emperor (>= 0.9.51)
> qiime/arm64 unsatisfiable Depends: infernal
> qiime/arm64 unsatisfiable Depends: raxml
> qiime/arm64 unsatisfiable Depends: sortmerna
> qiime/arm64 unsatisfiable Depends: swarm
> qiime/arm64 unsatisfiable Depends: vsearch (>= 1.1.1)
> ...
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#820385: swap-cwm: Section should be “web”

[Ben Finney]

Package: swap-cwm
Version: 1.2.1-7
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘swap-cwm’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section “web”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \ “I have an answering machine in my car. It says, ‘I'm home now. |
  `\  But leave a message and I'll call when I'm out.’” —Steven Wright |
_o__)  |
Ben Finney 

Bug#820384: thefuck: Section should not be “utils”

[Ben Finney]

Package: thefuck
Version: 3.2-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘thefuck’ installs primarily an application, of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section “utils”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \  “The best way to get information on Usenet is not to ask a |
  `\   question, but to post the wrong information.” —Aahz |
_o__)  |
Ben Finney 

Bug#820383: RFS: photocollage/1.4.0-1 [ITP]

[Adrien Vergé]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 Package name: photocollage
 Version : 1.4.0-1
 Upstream Author : Adrien Vergé
 URL : https://github.com/adrienverge/PhotoCollage
 License : GPL-2+
 Section : graphics

It builds this binary package:

  photocollage - Graphical tool to make photo collage posters

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/photocollage/photocollage_1.4.0-1.dsc

More information about PhotoCollage can be obtained from
https://github.com/adrienverge/PhotoCollage and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820377

Regards,
 Adrien Vergé

Bug#650581: xemacs21: FTBFS: glyphs-eimage.c:949:22: error: dereferencing pointer to incomplete type

[Tobias Frost]

Control: severity -1 serious

As the libpng 1.6 transition is now started, this is RC.

-- 
tobi

Bug#820350: libreoffice: Packaging LibreOfice Still for stable branch of the Debian

[Rene Engelhard]

notfound 820350 1:4.3.3-2+deb8u3
tag 820350 + wontfix
thanks

Hi,

On Thu, Apr 07, 2016 at 08:07:48PM +0300, Stanislav Fyodorov wrote:
> LibreOffice is developing rapidly. Unfortunately, not all fixes are
> ported back.

True.

That's why jessie-backports has 5.1.1 right now (ok, not Still but Fresh.)

 libreoffice | 1:5.1.1-1~bpo8+1   | jessie-backports | 
source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x

> A similar situation exists in other popular packages. Look how it is
> proposed to package Firefox ESR (life cycle of 9 months) for Debian
> stable (life cycle of about two years).
> 
> "Mozilla releases new Firefox releases every 6 to 8 weeks.
> In parallel of these rapid releases, Mozilla proposes a version called
> ESR which is maintained for about 9 months.
> On the contrary, Debian having a longer release cycle (about every two
> years), release cycles don't align.
> Because of the complexity of backporting security fixes, Debian cannot
> maintain a deprecated ESR release.

Yes, and this problem doesn't exist for LO. We *do* get the security patches
in patch form and apply them on stable. While firefox doesn't and thus ESR
is the only way to get them properly.

> To address this packaging issue, once a ESR cycle is over, Debian has
> been accepting uploads of new ESR releases in the stable release." [1]
> 
> Is it possible to offer something like this for LibreOffice Still and
> Debian stable branch?

Theoretically yes. Practicably no.

and I consider the firefox situation suboptimal. Stuff changes, library
dependecies changes, you need newer ones (which change SONAME and become
incompatible to old ones, etc)

No idea how iceweasel handles it. Either that doesn't happen or it uses (I fear
that that is the case mostly) internal copies of the libraries.

I can live with jessie-backports using internal copies of those, but that is
not something for stable.

If you want/need something newer, use backports[1]. That's what it's for.
(Firefox is also provided in the same way, though on mozilla.debian.net)

Regards,

Rene

Bug#662354: gnome-xcf-thumbnailer: Please Build-Depends on libpng-dev, change from libpng12-dev

[Tobias Frost]

Fixed with NMU 1.0-1.1

-- 
tobi

Bug#800202: parchive: Please migrate a supported debhelper compat level

[Eriberto Mota]

Control: tags 800202 patch
Control: tags 800202 pending


Hi,

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

The debian/changelog is:

parchive (1.1-4.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Migrated DH level to 9 to avoid a FTBFS. (Closes: #800202)
  * debian/compat: created.
  * debian/control:
  - Added the Homepage field.
  - Added the ${misc:Depends} field.
  - Bump Standards-Version to 3.9.7.
  * debian/watch: created.

I attached a debdiff.

Regards,

Eriberto


parchive.debdiff
Description: Binary data

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Tormod Volden]

On Wed, Apr 6, 2016 at 1:01 AM, Peter Nowee  wrote:
> Here is a patch I was working on to add links to the Debian BTS in the
> several places where bug reporting is encouraged (man pages, dialog
> boxes). Perhaps it can be of use. Note that I did not have a chance to
> test the change I made to the Motif dialog box (driver/demo-Xm.c) yet.
>
> Good luck, thanks,
> Peter Nowee

Thanks for the patch, Peter! I have opened bug #820378 for this task.

Tormod

Bug#820381: rar crashes.

[Alexandre Pereira Nunes]

Package: rar
Version: 2:5.3.b2-1
Severity: serious

Rar crashes in all evocations.


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

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

rar depends on no packages.

rar recommends no packages.

Versions of packages rar suggests:
ii  unrar  1:5.3.2-1

-- no debconf information

Bug#820382: pysatellites: Section should not be “python”

[Ben Finney]

Package: pysatellites
Version: 2.4-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘pysatellites’ installs primarily an application, of
interest regardless of the programming language. It should not be in
the “python” section.

By the section descriptions, this package may belong in section
“science”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \“I went to the hardware store and bought some used paint. It |
  `\  was in the shape of a house.” —Steven Wright |
_o__)  |
Ben Finney 

Bug#820359: init-system-helpers: Handle \ escape in systemd unit names

[Dan Nicholson]

On Thu, Apr 7, 2016 at 11:56 AM, Felipe Sateler  wrote:
>
> AFAICT, the only difference between quotewords and split is that
> quotewords takes into account quotes to allow "multiple words" to be
> parsed as a single token. I don't think we have use for such a feature
> (there are no such files in the archive).
>
> So, unless I'm missing something, this could be further simplified to
> just use split.

Yeah, that does seem possible. The only fields parsed are WantedBy,
RequiredBy, Also and Alias. Since the values here are unit names,
there shouldn't be any instances where there's valid whitespace in the
words. So, I think you could do split followed by quote stripping and
everything would be fine. I'll try that out.

Of course, if init-system-helpers ever does parse any fields might
contain contain multiple quoted words, then you'd need to go back to
using quotewords or something like that.

--
Dan

Bug#820379: pyhoca-cli: Section should be “admin”

[Ben Finney]

Package: pyhoca-cli
Version: 0.5.0.2-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘pyhoca-cli’ installs primarily an application, of
interest regardless of the programming language. It should not be in
the “python” section.

By the section descriptions, this package belongs in section “admin”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \ “When we pray to God we must be seeking nothing — nothing.” |
  `\—Francis of Assisi |
_o__)  |
Ben Finney 

-- 
 \ “Don't be misled by the enormous flow of money into bad defacto |
  `\standards for unsophisticated buyers using poor adaptations of |
_o__) incomplete ideas.” —Alan Kay |
Ben Finney 

Bug#820378: Ensure users report bugs in BTS and not to upstream directly

[Tormod Volden]

Package: xscreensaver
Version: 5.30-1+deb8u1
X-Debbugs-CC: Peter Nowee 


According to upstream, a lot of Debian stable users send bug reports
about the xscreensaver package directly to him. Since many of the bugs
already have been fixed in later upstream releases (and in Debian
unstable) this causes extra work for upstream which have to explain
that the bugs have already been fixed and that the user should upgrade
to a newer version in order to receive the bug fix.

Apparently the xscreensaver user interface encourages e-mailing of bug
reports directly upstream. We should try to change this, so that the
normal flow of bug reports go to the Debian bug tracker, and anything
relevant for upstream gets forwarded from there as usual.

Below a comment with patch from bug #819703 where this was brought up:

-- Forwarded message --
From: Peter Nowee 
Date: Wed, Apr 6, 2016 at 1:01 AM

On Tue, Apr 05, 2016 at 08:31:46PM +0200, Tormod Volden wrote:
> Debian users should always report bugs to Debian and not directly
> upstream. So the author being spammed by Debian users on old versions
> should in principle not happen. If the current software encourages
> people to send bug reports to the author we will look into and fix
> this.

Thanks for your reply.

Here is a patch I was working on to add links to the Debian BTS in the
several places where bug reporting is encouraged (man pages, dialog
boxes). Perhaps it can be of use. Note that I did not have a chance to
test the change I made to the Motif dialog box (driver/demo-Xm.c) yet.

Good luck, thanks,
Peter Nowee
Index: xscreensaver-5.30/driver/demo-Gtk.c
===
--- xscreensaver-5.30.orig/driver/demo-Gtk.c
+++ xscreensaver-5.30/driver/demo-Gtk.c
@@ -824,7 +824,10 @@ about_menu_cb (GtkMenuItem *menuitem, gp
   sprintf(copy, ("Copyright \251 1991-%s %s"), year, s);
 #endif /* !HAVE_GTK2 */
 
-  sprintf (msg, "%s\n\n%s", copy, desc);
+  sprintf (msg, "%s\n\n%s\n"
+"Please report bugs for this Debian version at\n"
+"https://bugs.debian.org/xscreensaver;,
+copy, desc);
 
   /* I can't make gnome_about_new() work here -- it starts dying in
  gdk_imlib_get_visual() under gnome_about_new().  If this worked,
Index: xscreensaver-5.30/driver/demo-Xm.c
===
--- xscreensaver-5.30.orig/driver/demo-Xm.c
+++ xscreensaver-5.30/driver/demo-Xm.c
@@ -360,7 +360,9 @@ about_menu_cb (Widget button, XtPointer
"version is no longer maintained.  Please use the GTK version\n"
"instead, which has many more features.\n"
"\n"
-   "For xscreensaver updates, check http://www.jwz.org/xscreensaver/;,
+   "For xscreensaver updates, check http://www.jwz.org/xscreensaver/\n;
+   "Please report bugs for this Debian version at\n"
+   "https://bugs.debian.org/xscreensaver;,
s, s2);
   free (s);
 
Index: xscreensaver-5.30/driver/xscreensaver-command.c
===
--- xscreensaver-5.30.orig/driver/xscreensaver-command.c
+++ xscreensaver-5.30/driver/xscreensaver-command.c
@@ -135,6 +135,8 @@ usage: %s -\n\
 \n\
   See the man page for more details.\n\
   For updates, check http://www.jwz.org/xscreensaver/\n\
+  Please report bugs for this Debian version at\n\
+  https://bugs.debian.org/xscreensaver\n\
 \n";
 
 /* Note: The "-throttle" command is deprecated -- it predates the XDPMS
Index: xscreensaver-5.30/driver/xscreensaver-command.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-command.man
+++ xscreensaver-5.30/driver/xscreensaver-command.man
@@ -261,3 +261,5 @@ without express or implied warranty.
 Jamie Zawinski , 13-aug-1992.
 
 Please let me know if you find any bugs or make any improvements.
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
\ No newline at end of file
Index: xscreensaver-5.30/driver/xscreensaver-demo.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-demo.man
+++ xscreensaver-5.30/driver/xscreensaver-demo.man
@@ -396,3 +396,5 @@ without express or implied warranty.
 Jamie Zawinski , 13-aug-92.
 
 Please let me know if you find any bugs or make any improvements.
+.SH BUGS
+Please report bugs for this Debian version at https://bugs.debian.org/xscreensaver
\ No newline at end of file
Index: xscreensaver-5.30/driver/xscreensaver-getimage-desktop.man
===
--- xscreensaver-5.30.orig/driver/xscreensaver-getimage-desktop.man
+++ xscreensaver-5.30/driver/xscreensaver-getimage-desktop.man
@@ -53,3 +53,5 @@ any purpose.  It is provided "as is" wit
 warranty.
 .SH 

Bug#820380: pyhoca-gui: Section should be “admin”

[Ben Finney]

Package: pyhoca-gui
Version: 0.5.0.4-1
Severity: minor

Dear Maintainer,

The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘pyhoca-gui’ installs primarily an application, of
interest regardless of the programming language. It should not be in
the “python” section.

By the section descriptions, this package belongs in section “admin”.

Please set the field “Section” appropriately on this package.


Since the package is already in Debian with a different section, you
will also need to submit a request to override the existing section
.

Then mark this bug report as blocked by that new one.

-- 
 \  “Contentment is a pearl of great price, and whosoever procures |
  `\it at the expense of ten thousand desires makes a wise and |
_o__)  happy purchase.” —J. Balguy |
Ben Finney