Bug#818555: Bug#820746: did anybody else see how scim no longer shows character choices?

[Tz-Huan Huang]

Hi,

On Mon, Apr 18, 2016 at 11:01 AM, 積丹尼 Dan Jacobson 
wrote:

> found 818555 3.20.3-1
> thanks
>
> > Dear scim maintainers, your package is no longer compatible with
> > libgtk-3-bin. The box becomes white.
> > libgtk-3-*3.18.9-1* was the last compatible version.
>
> < Thank you very much for the report. I'm looking into it now.
>
> Did you see the white box I am talking about?
>
>
Yes. I have set up a VM for gtk3 > 3.18.9 and confirmed the issue last
weekend.
I'll try to solve it as fast as I can.

Thanks,
Tz-Huan

Bug#821366: urxvt: Resizing urxvt cuts off some long lines

[Hong Xu]

Package: urxvt
Version: rxvt-unicode
Severity: normal
Tags: upstream patch

Dear Maintainer,


There is also a description here: https://superuser.com/questions/442589
/xmonad-urxvt-issue-text-disappears-after-resizing/1066695

1. Start up urxvt, produce some long lines (such as run `ls` in a directory
with a lot of files).
2. Resize until the window width is smaller than the line length. Release the
mouse.
3. Resize the window to make it wider.

Now the long lines have been cut off.

A patch is available to fix this issue: http://lists.schmorp.de/pipermail/rxvt-
unicode/2015q4/002197.html

I think it is a good idea to include the patch.



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

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

Bug#821365: debian-policy: Clarify which characters constitute the syntax of control files

[Ben Finney]

Package: debian-policy
Severity: minor
Control: tags -1 + patch

The description of control file syntax in §5.1 references numerous
characters, some by number and some as simple display of the
character, and some as informal names. Some of these mentions are
confusing.

The section also specifies that all control files are encoded as
UTF-8, so knowledge of Unicode is (IMO correctly) assumed of the
reader.

This patch standardises the mention of characters in §5.1 to
explicitly give Unicode code point references and (where appropriate)
the literal character unambiguously quoted.

-- 
 \“Pinky, are you pondering what I'm pondering?” “Wuh, I think |
  `\so, Brain, but will they let the Cranberry Duchess stay in the |
_o__) Lincoln Bedroom?” —_Pinky and The Brain_ |
Ben Finney 
From 04bffa59187df69969d9736dc865514fcd30b840 Mon Sep 17 00:00:00 2001
From: Ben Finney 
Date: Mon, 18 Apr 2016 13:31:14 +1000
Subject: [PATCH 1/2] Clarify which characters constitute syntax of control
 files.

---
 policy.sgml | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 404dc737..236bf743 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2541,13 +2541,16 @@ endif
 	
 
 	
-	  Each paragraph consists of a series of data fields.  Each field
-	  consists of the field name followed by a colon and then the
-	  data/value associated with that field.  The field name is
-	  composed of US-ASCII characters excluding control characters,
-	  space, and colon (i.e., characters in the ranges 33-57 and
-	  59-126, inclusive).  Field names must not begin with the comment
-	  character, #, nor with the hyphen character, -.
+	  Each paragraph consists of a series of data fields. Each
+	  field consists of the field name followed by a colon and
+	  then the data/value associated with that field. The field
+	  name is composed of US-ASCII characters excluding control
+	  characters, space, and colon (i.e., characters in the ranges
+	  U+0021 “!” through U+0039 “9”, and U+003B
+	  “;” through U+007E “~”, inclusive). Field
+	  names must not begin with the comment character (U+0023
+	  “#”), nor with the hyphen character (U+002D
+	  “-”).
 	
 
 	
@@ -2624,17 +2627,20 @@ Package: libc6
 	
 
 	
-	  Paragraph separators (empty lines) and lines consisting only of
-	  spaces and tabs are not allowed within field values or between
-	  fields.  Empty lines in field values are usually escaped by
-	  representing them by a space followed by a dot.
+	  Paragraph separators (empty lines), and lines consisting
+	  only of U+0020 SPACE and U+0009 TAB, are not allowed within
+	  field values or between fields. Empty lines in field values
+	  are usually escaped by representing them by a U+0020 SPACE
+	  followed by a U+002E “.”.
 	
 
 	
-	  Lines starting with # without any preceding whitespace are comments
-	  lines that are only permitted in source package control files
-	  (debian/control).  These comment lines are ignored, even
-	  between two continuation lines.  They do not end logical lines.
+	  Lines starting with U+0023 “#”, without any
+	  preceding whitespace, are comment lines that are only
+	  permitted in source package control files
+	  (debian/control). These comment lines are
+	  ignored, even between two continuation lines. They do not
+	  end logical lines.
 	
 
 	
-- 
2.8.0.rc3



signature.asc
Description: PGP signature

Bug#821364: gnome-shell: .Xmodmap not read on startup

[Stephen Crowley]

Package: gnome-shell
Version: 3.18.1-1
Severity: important

It is a complete and total travesty that this vital functionality has
been missing since at least a year. No, adding it to the startup
programs is not acceptable.. .xinitrc doesnt even work either


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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  evolution-data-server3.18.5-1
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.18.3-4
ii  gir1.2-caribou-1.0   0.4.20-1
ii  gir1.2-clutter-1.0   1.26.0-2
ii  gir1.2-freedesktop   1.46.0-4
ii  gir1.2-gcr-3 3.20.0-2
ii  gir1.2-gdesktopenums-3.0 3.18.1-1
ii  gir1.2-gdm3  3.18.0-2
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.46.0-4
ii  gir1.2-gnomebluetooth-1.03.18.3-1
ii  gir1.2-gnomedesktop-3.0  3.18.2-1
ii  gir1.2-gtk-3.0   3.18.9-1
ii  gir1.2-gweather-3.0  3.20.0-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.18.3-2
ii  gir1.2-networkmanager-1.01.1.93-1
ii  gir1.2-nmgtk-1.0 1.1.93-1
ii  gir1.2-pango-1.0 1.38.1-1
ii  gir1.2-polkit-1.00.105-14.1
ii  gir1.2-soup-2.4  2.52.2-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-2
ii  gjs  1.43.3-2
ii  gnome-backgrounds3.18.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.18.2-1
ii  gnome-shell-common   3.18.1-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk-bridge2.0-0   2.18.1-3
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-6
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.26.0-2
ii  libcogl-pango20  1.22.0-2
ii  libcogl201.22.0-2
ii  libcroco30.6.11-1
ii  libdbus-glib-1-2 0.106-1
ii  libecal-1.2-19   3.18.5-1
ii  libedataserver-1.2-213.18.5-1
ii  libgcr-base-3-1  3.20.0-2
ii  libgdk-pixbuf2.0-0   2.32.3-2
ii  libgirepository-1.0-11.46.0-4
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.43.3-2
ii  libglib2.0-0 2.48.0-1
ii  libgstreamer1.0-01.8.0-2
ii  libgtk-3-0   3.18.9-1
ii  libical1a1.0.1-0.1
ii  libjson-glib-1.0-0   1.2.0-1
ii  libmozjs-24-024.2.0-3
ii  libmutter0g  3.18.3-2
ii  libnm-glib4  1.1.93-1
ii  libnm-util2  1.1.93-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpolkit-agent-1-0  0.105-14.1
ii  libpolkit-gobject-1-00.105-14.1
ii  libpulse-mainloop-glib0  8.0-2
ii  libpulse08.0-2
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  229-4
ii  libtelepathy-glib0   0.24.1-1.1
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  mutter   3.18.3-2
ii  python3  3.5.1-3
ii  telepathy-mission-control-5  1:5.16.3-2

Versions of packages gnome-shell recommends:
ii  gdm33.18.0-2
ii  gkbd-capplet   

Bug#821363: debian-policy: Allow line-end comments in all Debian packaging control files

[Ben Finney]

Package: debian-policy
Severity: normal
Control: tags -1 patch

The specification of Debian control files in Policy §5.1 says:

Lines starting with # without any preceding whitespace are
comments lines that are only permitted in source package control
files (debian/control). These comment lines are ignored, even
between two continuation lines. They do not end logical lines.

What is the rationale for explicitly disallowing line-end comments in
any but that one file?

The ‘debian/copyright’ file is an example of a file of the described
syntax, that benefits from line-end comments (e.g. for editor hints,
or for temporarily disabling some lines, or for explaining an unusual
value for a field).

There are likely other Debian packaging files of the same syntax where
line-end comments are useful.

If there is no good rationale to categorically deny all line end
comments in other files with that syntax, I suggest the attached
patches.

-- 
 \ “What is it that makes a complete stranger dive into an icy |
  `\   river to save a solid gold baby? Maybe we'll never know.” —Jack |
_o__)   Handey |
Ben Finney 
From 04bffa59187df69969d9736dc865514fcd30b840 Mon Sep 17 00:00:00 2001
From: Ben Finney 
Date: Mon, 18 Apr 2016 13:31:14 +1000
Subject: [PATCH 1/2] Clarify which characters constitute syntax of control
 files.

---
 policy.sgml | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 404dc737..236bf743 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2541,13 +2541,16 @@ endif
 	
 
 	
-	  Each paragraph consists of a series of data fields.  Each field
-	  consists of the field name followed by a colon and then the
-	  data/value associated with that field.  The field name is
-	  composed of US-ASCII characters excluding control characters,
-	  space, and colon (i.e., characters in the ranges 33-57 and
-	  59-126, inclusive).  Field names must not begin with the comment
-	  character, #, nor with the hyphen character, -.
+	  Each paragraph consists of a series of data fields. Each
+	  field consists of the field name followed by a colon and
+	  then the data/value associated with that field. The field
+	  name is composed of US-ASCII characters excluding control
+	  characters, space, and colon (i.e., characters in the ranges
+	  U+0021 “!” through U+0039 “9”, and U+003B
+	  “;” through U+007E “~”, inclusive). Field
+	  names must not begin with the comment character (U+0023
+	  “#”), nor with the hyphen character (U+002D
+	  “-”).
 	
 
 	
@@ -2624,17 +2627,20 @@ Package: libc6
 	
 
 	
-	  Paragraph separators (empty lines) and lines consisting only of
-	  spaces and tabs are not allowed within field values or between
-	  fields.  Empty lines in field values are usually escaped by
-	  representing them by a space followed by a dot.
+	  Paragraph separators (empty lines), and lines consisting
+	  only of U+0020 SPACE and U+0009 TAB, are not allowed within
+	  field values or between fields. Empty lines in field values
+	  are usually escaped by representing them by a U+0020 SPACE
+	  followed by a U+002E “.”.
 	
 
 	
-	  Lines starting with # without any preceding whitespace are comments
-	  lines that are only permitted in source package control files
-	  (debian/control).  These comment lines are ignored, even
-	  between two continuation lines.  They do not end logical lines.
+	  Lines starting with U+0023 “#”, without any
+	  preceding whitespace, are comment lines that are only
+	  permitted in source package control files
+	  (debian/control). These comment lines are
+	  ignored, even between two continuation lines. They do not
+	  end logical lines.
 	
 
 	
-- 
2.8.0.rc3

From 3a00ca0e08f19926a6e64e0e47a8d823eda9846f Mon Sep 17 00:00:00 2001
From: Ben Finney 
Date: Mon, 18 Apr 2016 13:46:44 +1000
Subject: [PATCH 2/2] Remove restriction of which control files may contain
 comments.

---
 policy.sgml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 236bf743..9aca360c 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2636,9 +2636,7 @@ Package: libc6
 
 	
 	  Lines starting with U+0023 “#”, without any
-	  preceding whitespace, are comment lines that are only
-	  permitted in source package control files
-	  (debian/control). These comment lines are
+	  preceding whitespace, are comment lines. These comment lines are
 	  ignored, even between two continuation lines. They do not
 	  end logical lines.
 	
-- 
2.8.0.rc3



signature.asc
Description: PGP signature

Bug#821334: approx: 'apt-get update' yields 'Err http://approx wheezy-updates/main amd64 Packages'

[David Christensen]

On 04/17/2016 04:28 PM, Eric Cooper wrote:

Sorry, I should have noticed sooner that you're running the version
from wheezy. Can you try installing the version from wheezy-backports:
 https://packages.debian.org/wheezy-backports/approx
and see if that works better?


Okay -- I upgraded Approx to wheezy-backports.  Console session follows.


I didn't notice until after upgrading that 'apt-get update' and Approx 
appeared to worked correctly prior to upgrading (?).  Any ideas?



David


2016-04-17 20:33:08 root@cd2533 ~/cd2533.holgerdanske.com
# vi /etc/apt/sources.list

2016-04-17 20:34:03 root@cd2533 ~/cd2533.holgerdanske.com
# apt-get update
Hit http://approx wheezy Release.gpg
Hit http://approx wheezy/updates Release.gpg
Hit http://approx wheezy-updates Release.gpg
Get:1 http://approx wheezy-backports Release.gpg [1554 B]
Hit http://approx wheezy Release 

Hit http://approx wheezy/updates Release 

Hit http://approx wheezy-updates Release 

Get:2 http://approx wheezy-backports Release [161 kB] 

Hit http://approx wheezy/main Translation-en 

Hit http://approx wheezy/updates/main Translation-en 

Ign http://approx wheezy-updates/main amd64 Packages/DiffIndex 

Hit http://approx wheezy-updates/main Translation-en/DiffIndex 

Get:3 http://approx wheezy-backports/main Translation-en [376 kB] 

Hit http://approx wheezy/main amd64 Packages 

Hit http://approx wheezy/updates/main amd64 Packages 

Get:4 http://approx wheezy-backports/main amd64 Packages [769 kB] 

Hit http://approx wheezy-updates/main amd64 Packages 

Fetched 1308 kB in 13s (94.7 kB/s) 


Reading package lists... Done

2016-04-17 20:34:42 root@cd2533 ~/cd2533.holgerdanske.com
# grep -v '#' /etc/apt/sources.list
deb http://approx:/debian   wheezy  main
deb http://approx:/security wheezy/updates  main
deb http://approx:/debian   wheezy-updates  main
deb http://approx:/debian   wheezy-backportsmain

2016-04-17 20:35:28 root@cd2533 ~/cd2533.holgerdanske.com
# apt-get -t wheezy-backports install approx
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  libconfig-model-approx-perl
The following packages will be upgraded:
  approx
1 upgraded, 0 newly installed, 0 to remove and 133 not upgraded.
Need to get 1408 kB of archives.
After this operation, 455 kB of additional disk space will be used.
Get:1 http://approx/debian/ wheezy-backports/main approx amd64 
5.5-1~bpo70+1 [1408 kB]

Fetched 1408 kB in 2s (602 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 95715 files and directories currently installed.)
Preparing to replace approx 5.3-1 (using 
.../approx_5.5-1~bpo70+1_amd64.deb) ...

Unpacking replacement approx ...
Processing triggers for man-db ...
Setting up approx (5.5-1~bpo70+1) ...

2016-04-17 20:40:06 root@cd2533 ~/cd2533.holgerdanske.com
# grep -v '#' /etc/approx/approx.conf

debian  http://ftp.debian.org/debian
securityhttp://security.debian.org/debian-security


$debug  true

2016-04-17 20:42:11 root@cd2533 ~/cd2533.holgerdanske.com
# cp /var/log/daemon.log daemon.log-foo

2016-04-17 20:42:49 root@cd2533 ~/cd2533.holgerdanske.com
# apt-get update
Hit http://approx wheezy Release.gpg
Hit http://approx wheezy/updates Release.gpg
Hit http://approx wheezy-updates Release.gpg
Hit http://approx wheezy-backports Release.gpg
Hit http://approx wheezy Release
Hit http://approx wheezy/updates Release
Hit http://approx wheezy-updates Release
Hit http://approx wheezy-backports Release
Hit http://approx wheezy/main amd64 Packages
Hit http://approx wheezy/main Translation-en
Get:1 http://approx wheezy/updates/main amd64 Packages [347 kB]
Hit http://approx wheezy/updates/main Translation-en
Get:2 http://approx wheezy-updates/main amd64 Packages/DiffIndex [1504 B]
Hit http://approx wheezy-updates/main Translation-en/DiffIndex
Get:3 http://approx wheezy-backports/main amd64 Packages/DiffIndex [10.1 kB]
Get:4 http://approx wheezy-backports/main Translation-en/DiffIndex [3964 B]
Fetched 363 kB in 3s (95.3 kB/s)
Reading package lists... Done

2016-04-17 20:43:14 root@cd2533 ~/cd2533.holgerdanske.com
# diff daemon.log-foo /var/log/daemon.log
1070a1071,1270
> Apr 17 20:42:51 cd2533 approx[8572]: Connection from 192.168.1.253 
port 48847
> Apr 17 20:42:51 cd2533 approx[8572]: Request: GET 
/debian/dists/wheezy/Release.gpg

> Apr 17 20:42:51 cd2533 approx[8572]:   Host: approx:
> Apr 17 20:42:51 cd2533 approx[8572]:   Connection: keep-alive
> Apr 17 20:42:51 cd2533 approx[8572]:   Cache-Control: max-age=0
> Apr 17 20:42:51 cd2533 approx[8572]:   If-Modified-Since: Sat, 02 Apr 
2016 12:17:17 GMT
> Apr 17 20:42:51 cd2533 approx[8572]:   User-Agent: Debian 
APT-HTTP/1.3 (0.9.7.9)
> Apr 17 20:42:51 cd2533 approx[8572]:   last modified: Sat, 02 Apr 
2016 12:17:17 GMT
> Apr 17 20:42:51 cd2533 approx[8572]:   last verified: Mon, 18 Apr 
2016 03:34:10 

Bug#782029: dolfin-bin: FEniCS/DOLFIN fails to compile Python dolfin.Expression()

[Drew Parsons]

reassign 782029 libsuitesparse-metis-dev
retitle 782029 build multiarch installation of suitesparse-metis 
severity 782029 serious
thanks

On Mon, 06 Apr 2015 10:57:40 -0700 Jan Medlock  wrote:
> 
> Removing '/x86_64-linux-gnu' from the paths to the libsuitesparse
> libraries in /usr/lib/dolfin/cmake/DOLFINTargets-relwithdebinfo.cmake
> makes the Expression compile.
> 

Thanks for the bug report, Jan.  I'm trying to keep petsc and dolfin
up-to-date.

Reading through your bug report, it looks like the bug you're
experiencing here needs to be resolved in libsuitesparse-metis-dev

The background is that Debian now provides multiarch support.  That
means library binaries for multiple cpu architectures can be hosted on
the one system.  It makes cross-architecture compilation simpler, as
well as running 32bit programs on 64bit systems.

Under the old layout, library files would be placed in /usr/lib,
e.g. /usr/lib/libumfpack.so.  In the new multiarch layout, they should
be placed in /usr/lib//usr/lib/, 
e.g. /usr/lib/x86_64-linux-gnu/libumfpack.so.5.6.2

What's happened here is that libsuitesparse-dev has been updated to the
new multiarch layout, and petsc is build against that multiarch
installation of suitesparse.

libsuitesparse-metis-dev has not been updated for a long time, so it
still places files in the old /usr/lib directory. It needs to be
updated for multiarch, to place the files in /usr/lib/.  It's not
hard to do, but because parmetis is not DFSG-free (it's in the non-free 
section), libraries using it (in the contrib section) don't get as much
attention.

You've found one workaround, hacking the dolfin library list
in /usr/share/dolfin/cmake/DOLFINTargets-relwithdebinfo.cmake

Another clumsy temporary workaround is to create links in the multiarch
directory with something like
   for l in `dpkg -L libsuitesparse-metis-dev | grep -E 
"/usr/lib/lib.*.so|/usr/lib/lib.*.a"`; 
  do echo ln -s $l /usr/lib/`dpkg-architecture 
-qDEB_TARGET_MULTIARCH`/`basename $l`; 
   done
(with libsuitesparse-dev uninstalled)

Drew

Bug#821175: naming conflict to grip the cd ripper

[Tiago Ilieve]

Harald,

On 17 April 2016 at 09:41, Harald Dunkel  wrote:
> This is not about a conflict of the package name, but about
> the config file/directory. Surely I wasn't the only one who
> had used grip the CD ripper a long time ago. Closing the
> report won't make the conflict in the user's $HOME go away.
> At least your grip should show a readable error message, even
> if it is Python.
>
> Please reopen.

I do understood the problem. But see, what is being reported is that a
packaged application has its configuration file names clashing with a
software that is isn't part of Debian anymore. I can't even forward
this bug to the upstream, because how one can argue about fixing a
conflict with a software that was abandoned over 10 years ago?

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#821362: soundconverter: clicking sound

[Ezequiel]

Package: soundconverter
Version: 2.1.3-1
Severity: normal

Dear Maintainer,

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

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

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



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

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

Versions of packages soundconverter depends on:
ii  gstreamer0.10-plugins-base  0.10.36-2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b1
ii  python  2.7.9-1
ii  python-glade2   2.24.0-4
ii  python-gnome2   2.28.1+dfsg-1.1
ii  python-gst0.10  0.10.22-3

soundconverter recommends no packages.

Versions of packages soundconverter suggests:
ii  gstreamer0.10-ffmpeg1:0.10.13-dmo2
ii  gstreamer0.10-plugins-ugly  0.10.19-2.1

-- no debconf information

Bug#821361: Voting for CTTE Chair

[Don Armstrong]

Package: tech-ctte
Severity: normal

With the appointment of Phil to the CTTE, according to our procedures,
we should elect the chair of the CTTE.[1]

Therefore, I am announcing my intention to step down from the CTTE
chairmanship effective Monday, April 25th at 03:00:00 UTC (or as soon as
the outcome of this election is no longer in doubt) to force an election
of the CTTE chair from our membership.

The ballot is the following:

===BEGIN===

The chair of the CTTE will be:

A: Don Armstrong
B: Andreas Barth
C: Phil Hands
D: Sam Hartman
E: Tollef Fog Heen
F: Keith Packard
G: Didier Raboud 
===END===


1: For those following along at home, this is not in the constitution,
but was discussed and agreed upon in #795857 and is documented in
procedures.md in our git repository.
-- 
Don Armstrong  https://www.donarmstrong.com

"Them as can do has to do for them as can't. And someone has to speak
up for them as have no voices."
 -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227


signature.asc
Description: PGP signature

Bug#821360: mon: Please don't include options in the default command line and default mon.cf

[Russell Coker]

Package: mon
Version: 1.2.0-9
Severity: normal

/usr/sbin/mon -B /etc/mon -a /usr/lib/mon/alert.d -s /usr/lib/mon/mon.d -D 
/var/lib/mon -L /var/log/mon -f -c /etc/mon/mon.cf

The default configuration of mon runs the daemon with the above command line.

alertdir= /usr/lib/mon/alert.d
mondir  = /usr/lib/mon/mon.d
logdir  = /var/log/mon

The default mon.cf has the above entries which lead one to expect that changing 
those
entries would change the behavior of the daemon.  However they have no effect 
because
the command-line overrides them.

One way to deal with this without confusing the user would be to have the above 
mon.cf
lines commented out as examples with a comment saying "the default 
configuration sets
these in /etc/default/mon".

But it might be best to just have it configured to only use the config file.

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

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

Versions of packages mon depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u4
ii  libtime-period-perl  1.20-8
ii  mon-client   1.2.0-2

Versions of packages mon recommends:
pn  fping   
pn  libauthen-pam-perl  
pn  libcrypt-ssleay-perl
pn  libfilesys-diskspace-perl   
pn  libnet-dns-perl 
pn  libnet-ldap-perl
pn  libnet-telnet-perl  
pn  libsnmp-perl
pn  libstatistics-descriptive-perl  
pn  libtime-parsedate-perl  
ii  perl-modules [libnet-perl]  5.20.2-3+deb8u4

Versions of packages mon suggests:
ii  mon-contrib  1.0+dfsg-3

-- no debconf information

Bug#805083: polygraph: FTBFS: SSlv3 method

[Alex Rousskov]

On 04/17/2016 01:58 PM, Sebastian Andrzej Siewior wrote:
> On 2015-11-16 08:19:36 [-0700], Alex Rousskov wrote:
>> On 11/14/2015 09:02 AM, Alex Rousskov wrote:
>>
>>> If we can provide a small better fix, we will. If a better fix requires
>>> too many unrelated changes to this Polygraph version, we will provide a
>>> patch that disables SSLv3 (until a recent Polygraph version with a
>>> comprehensive fix is released).
>>
>> The attached patch allows Polygraph to be built with OpenSSL that does
>> not support SSLv3 while preserving legacy functionality for those who
>> need it.

> Current 4.9.0 version still has the problem. 

IIRC, the patch was developed after v4.9.0 was released.


> Any reason why I should not NMU it? 

Not that I know of. If it works, please do!


> Alex in case you need a sponsor then I could help with that.

Yes, but, frankly, we probably need a maintainer. We are happy to do the
legwork upstream, but do not have anybody with enough Debian knowledge
to efficiently navigate the Debian-specific packaging process and
related maintenance steps. AFAICT, sponsorship would be required (thank
you!) but _insufficient_ to get the package fully up to date. For more
details, please see:

  http://lists.web-polygraph.org/pipermail/users/2016-March/000313.html


Thank you,

Alex.

Bug#821359: mon often fails to restart because port is still in use

[Russell Coker]

Package: mon
Version: 1.2.0-9
Severity: normal

Apr 18 13:10:22 myserver systemd[1]: Stopped LSB: monitor 
hosts/services/whatever and alert about problems.
Apr 18 13:10:22 myserver systemd[1]: Starting LSB: monitor 
hosts/services/whatever and alert about problems...
Apr 18 13:10:22 myserver mon[2800]: fatal, could not bind TCP server port 2583: 
Address already in use
Apr 18 13:10:22 myserver mon[2787]: Starting mon daemon : mon failed!
Apr 18 13:10:22 myserver systemd[1]: mon.service: Control process exited, 
code=exited status=1

When running "/etc/init.d/mon restart" I often get the above result, it seems 
that
the restart happens too quickly for the kernel to release the port.

Would a delay in the restart operation be the appropriate solution for this?

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

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

Versions of packages mon depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u4
ii  libtime-period-perl  1.20-8
ii  mon-client   1.2.0-2

Versions of packages mon recommends:
pn  fping   
pn  libauthen-pam-perl  
pn  libcrypt-ssleay-perl
pn  libfilesys-diskspace-perl   
pn  libnet-dns-perl 
pn  libnet-ldap-perl
pn  libnet-telnet-perl  
pn  libsnmp-perl
pn  libstatistics-descriptive-perl  
pn  libtime-parsedate-perl  
ii  perl-modules [libnet-perl]  5.20.2-3+deb8u4

Versions of packages mon suggests:
ii  mon-contrib  1.0+dfsg-3

-- no debconf information

Bug#821048: [Pkg-alsa-devel] Bug#821048: alsa-utils: arecord -d broken, apply upstream patch

[David Fries]

On Fri, Apr 15, 2016 at 08:06:15AM +0200, Elimar Riesebieter wrote:
> Please update to alsa-utils 1.1.0-2 first. In stable there will be
> only security patches accepted. Bug closed herewith. Backports are
> not maintained from us.

1.1.0-2 is fixed as far as this bug report goes for the -d option.

This could be seen as a denial of service, security bug, unless there
is a directory limit, this can create files until it runs the system
out of inodes.  I was more of wanting to say the next version is
fixed, thanks for the quick disposition, I don't need a response to
this e-mail.

-- 
David Fries 

Bug#818555: did anybody else see how scim no longer shows character choices?

[積丹尼 Dan Jacobson]

found 818555 3.20.3-1
thanks

> Dear scim maintainers, your package is no longer compatible with
> libgtk-3-bin. The box becomes white.
> libgtk-3-*3.18.9-1* was the last compatible version.

< Thank you very much for the report. I'm looking into it now.

Did you see the white box I am talking about?

Bug#821358: nss_hesiod segfaults in sock_eq

[Anders Kaseorg]

Package: libc6
Version: 2.22-6
Severity: important
Tags: upstream
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=19573

glibc 2.22 broke nss_hesiod so that it segfaults on almost all uses.  To 
reproduce:

# sed -i 's/^passwd:.*/& hesiod/' /etc/nsswitch.conf
# cat > /etc/hesiod.conf <, a2=0x0) at 
res_send.c:1629
1629res_send.c: No such file or directory.
(gdb) bt
#0  0x76531aa3 in sock_eq (a1=a1@entry=0x77bb7af4 <_res+20>, 
a2=0x0) at res_send.c:1629
#1  0x765333f7 in __libc_res_nsend (statp=0x77bb7ae0 <_res>, 
buf=buf@entry=0x7fffdec0 "\322\325\001", buflen=45, buf2=buf2@entry=0x0, 
buflen2=buflen2@entry=0, ans=ans@entry=0x7fffe2c0 
"`\343\377\377\377\177", anssiz=1024, ansp=0x0, ansp2=0x0, nansp2=0x0, 
resplen2=0x0, 
ansp2_malloced=0x0) at res_send.c:416
#2  0x76533bbd in __GI___res_nsend (statp=, 
buf=buf@entry=0x7fffdec0 "\322\325\001", buflen=, 
ans=ans@entry=0x7fffe2c0 "`\343\377\377\377\177", 
anssiz=anssiz@entry=1024) at res_send.c:638
#3  0x767417d6 in get_txt_records (class=1, name=name@entry=0x610a80 
"39270.uid.ns.athena.mit.edu", ctx=0x60f8c0) at hesiod.c:374
#4  0x76741d95 in hesiod_resolve (context=context@entry=0x60f8c0, 
name=name@entry=0x7fffe780 "39270", type=type@entry=0x767432c6 "uid")
at hesiod.c:240
#5  0x76742aa2 in lookup (name=name@entry=0x7fffe780 "39270", 
type=type@entry=0x767432c6 "uid", 
pwd=pwd@entry=0x77bb5e20 , buffer=buffer@entry=0x60f260 
"saned", buflen=buflen@entry=1024, errnop=errnop@entry=0x77fe56b8)
at nss_hesiod/hesiod-pwd.c:63
#6  0x76742c2b in _nss_hesiod_getpwuid_r (uid=, 
pwd=0x77bb5e20 , buffer=0x60f260 "saned", buflen=1024, 
errnop=0x77fe56b8) at nss_hesiod/hesiod-pwd.c:112
#7  0x778ccc0c in __getpwuid_r (uid=uid@entry=39270, 
resbuf=resbuf@entry=0x77bb5e20 , buffer=0x60f260 "saned", 
buflen=buflen@entry=1024, result=result@entry=0x7fffe848) at 
../nss/getXXbyYY_r.c:266
#8  0x778cc52e in getpwuid (uid=39270) at ../nss/getXXbyYY.c:116
#9  0x004022b9 in ?? ()
#10 0x77835610 in __libc_start_main (main=0x401b20, argc=2, 
argv=0x7fffe9b8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe9a8) at libc-start.c:291
#11 0x004026ac in ?? ()

See also:

https://sourceware.org/bugzilla/show_bug.cgi?id=19573
https://bugzilla.redhat.com/show_bug.cgi?id=1252570
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1571456

Anders

Bug#821357: roxterm: starts at completely useless size

[Norbert Preining]

Package: roxterm
Version: 3.3.2-1
Severity: normal

Hi

since one of the recent updates roxterm starts every new window at incredible 
small
size: 3 lines, 29 chars (maybe this is 80x25 pixel?).

I have checked all settings (there is none for size) and looked into
~/.config/roxterm.sourceforge.net/
nothing specific there.

I also don't have any .Xresources or .Xdefaults.

I am running Cinnamon.

Thanks

Norbert

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

Kernel: Linux 4.6.0-rc3+ (SMP w/4 CPU cores; PREEMPT)
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 roxterm depends on:
ii  libc6   2.22-6
ii  libcairo2   1.14.6-1+b1
ii  libdbus-1-3 1.10.8-1
ii  libdbus-glib-1-20.106-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.0-1
ii  libgtk-3-0  3.20.3-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.40.1-1
ii  librsvg2-common 2.40.15-1
ii  libsm6  2:1.2.2-1+b1
ii  libvte-2.91-0   0.44.1-1
ii  libx11-62:1.6.3-1
ii  roxterm-data3.3.2-1

roxterm recommends no packages.

roxterm suggests no packages.

-- no debconf information

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 09:51 +0800, Paul Wise wrote:
> Hmm, compile-time choice of CPU instructions doesn't sound like a 
> good idea, because if I build on an old crappy build machine or a 
> base-level  qemu virtual machine then I won't be getting SSE4 when I 
> run on my fast powerful desktop machine. Please ask upstream to 
> switch to runtime choice based on the available instructions on the
> user's CPU.

Upstream has been pretty much MIA for a long time. But even if I
managed to track him down, I reckon I know what he would say: Portable
floating point calculations can come at the expense of performance and
in order to mitigate this as much as possible, hardware level
optimizations are necessary and heavily tied to the method of
implementation.

The user can still select the best library during configure time. e.g.
with autoconf like so...

# Select correct library based on host hardware...
case "$host_cpu" in

# For Intel based hardware, use SSE2 hardware accelerated variant...
i?86) ;&
x86_64) 
PKG_CHECK_MODULES(
[streflop], [streflop-sse >= 0.3], [],
[AC_MSG_ERROR([streflop-sse >= 0.3 missing...])])
;;

# Otherwise fallback to software emulated variant...
*)
PKG_CHECK_MODULES(
[streflop], [streflop-soft >= 0.3], [],
[AC_MSG_ERROR([streflop-soft >= 0.3 missing...])])
;;
esac

> Please talk to upstream about the test suite stuff too.

Believe me, I've tried. He's MIA. The test suite I've "rigged up" in
one of my quilt patches might be sufficient, but we'll never know for
certain until he checks.

> The upstream website says that it uses the SoftFloat library for the
> software floating-point implementation. Since this is a modified
> embedded code copy too, please document this in the security team's
> embedded code copies file and talk to the upstreams about it. 
> Likewise for the old libc code and for Random.cpp.

Yup. And ideally the package would depend on SoftFloat, but I'm really
not sure how much of the latter he's modified or dependent on in the
way it was back when he wrote streflop.

> Great work convincing them!

Yeah. I think it will end up saving them time in not having to maintain
their own embedded copy and be responsible for it.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



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

Bug#821356: emoslib: Package is not reproducible changing shell

[boyska]

Package: emoslib
Version: 4.3.9-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org

Hi,
While working on the “reproducible builds” effort [1], we have noticed that
emoslib is not reproducible changing shell: debian/rules assume the behaviour
of dash's echo, which is not compatible with bash.

The attached patch (thanks, deki) fixes this behavior.

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


-- System Information:
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.11-1-lts-apparmor (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
diff -Nur emoslib-4.3.9/debian/changelog emoslib-4.3.9-repr/debian/changelog
--- emoslib-4.3.9/debian/changelog	2016-03-22 19:28:00.0 -0400
+++ emoslib-4.3.9-repr/debian/changelog	2016-04-17 10:42:19.868582724 -0400
@@ -1,3 +1,9 @@
+emoslib (2:4.3.9-1.0~reproducible1) UNRELEASED; urgency=medium
+
+  * Solve reproducibility issues with different shells
+
+ -- boyska   Sun, 17 Apr 2016 10:41:40 -0400
+
 emoslib (2:4.3.9-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nur emoslib-4.3.9/debian/rules emoslib-4.3.9-repr/debian/rules
--- emoslib-4.3.9/debian/rules	2016-03-22 19:28:00.0 -0400
+++ emoslib-4.3.9-repr/debian/rules	2016-04-17 10:41:02.746387904 -0400
@@ -96,4 +96,5 @@
 	# Change default from emos to emos_shared to link against shared libs in metview, etc.
 	grep -v LIBEMOS_SELF_LIBRARIES ${CMAKE_DIR}/libemos-config.cmake > ${CMAKE_DIR}/tmp
 	mv ${CMAKE_DIR}/tmp ${CMAKE_DIR}/libemos-config.cmake  
-	echo "\nset( LIBEMOS_SELF_LIBRARIES"emos_shared" )" >> ${CMAKE_DIR}/libemos-config.cmake 
+	echo >> ${CMAKE_DIR}/libemos-config.cmake 
+	echo "set( LIBEMOS_SELF_LIBRARIES"emos_shared" )" >> ${CMAKE_DIR}/libemos-config.cmake 

Bug#821049: multipath-tools: reloading devmap results in block device being created incorrectly

[Andrew Patterson]

On Fri, 15 Apr 2016 16:07:48 -0600 Andrew Patterson
 wrote:
> On Sat, 16 Apr 2016 00:42:33 +0530 Ritesh Raj Sarraf  wrote: 
> > > On Sat, 2016-04-16 at 00:35 +0530, Ritesh Raj Sarraf wrote: > >
Hello Mike, > > > > All I can say is that I am able to see the >
behavior that you've mentioned (So > > marking the bug as confirmed). >
THis is seen on my LIO iSCSI Setup running on 2 > > Guest VMs. > > > > >
In doing that, I was surprised that those dev/mapper/ entries are now >
> > symlinks. > > My storage knowledge has rusted for some time now, but
> from what I recollect, > > it > > used to by direct block node names,
> not symlinks. > > Maybe this could be of some help to you in debugging
> this further. > > Apr 16 00:34:11 debian-sanboot systemd[1]: Started >
Device-Mapper Multipath > Device Controller. > Apr 16 00:34:11 >
debian-sanboot systemd-udevd[949]: conflicting device node > >
'/dev/mapper/sanroot' found, link to '/dev/dm-0' will not be created > >
> > So I think my understanding was correct about Device Mapper's >
behavior. Now I'm > not sure what 'systemd-udevd[949]' is reflecting >
here as. I doubt if that is the > ID for the rules processing because >
then I'd have seen the respective rule. > > I hope this is of some use >
to you. My Debian time for today is running out :-) > > > Hi Ritesh, > >
I am working with Mike on this problem. > > We have seen this issue
using multiple transports (FCoE, FC, and > iSCSI), although most of our
testing has been using QLogic FC cards > with 3Par FC storage. I don't
think this is a transport problem, but > is instead, some sort of
udev/multipath interaction problem. > > Here is a test I ran with
multipath-tools_0.5.0-7 and > multipath-tools_0.5.0+git0.770e6d0d-1 on
stretch using the same > hardware and configuration that Mike has been
using: > > Here is the storage: > > 1:0:0:1] disk 3PARdata VV 3212
/dev/sdb > [1:0:0:2] disk 3PARdata VV 3212 /dev/sdc > [1:0:0:254]
enclosu 3PARdata SES 3212 - > [1:0:1:1] disk 3PARdata VV 3212 /dev/sdd >
[1:0:1:2] disk 3PARdata VV 3212 /dev/sde > [1:0:1:254] enclosu 3PARdata
SES 3212 - > > And udev monitor output (udevadm monitor -u -k): > >
multipath-tools_0.5.0-7 > > # udevadm monitor -k -u > monitor will print
the received events for: > UDEV - the event which udev sends out after
rule processing > KERNEL - the kernel uevent > > KERNEL[90540.185998]
change /devices/virtual/block/dm-0 (block) > KERNEL[90540.187857] change
/devices/virtual/block/dm-1 (block) > UDEV [90540.265654] change
/devices/virtual/block/dm-1 (block) > UDEV [90540.266138] change
/devices/virtual/block/dm-0 (block) > > # ls -l /dev/mapper > total 0 >
crw--- 1 root root 10, 236 Apr 14 14:31 control > lrwxrwxrwx 1 root
root 7 Apr 15 15:40 mpatha -> ../dm-0 > lrwxrwxrwx 1 root root 7 Apr 15
15:40 mpathb -> ../dm-1 >

My git bisection resulted in this commit causing the change in behavior:

commit 4a2431aa944eb2e5b6f3ccd2d4fe1df67f9e5679
Author: Hannes Reinecke 
Date:   Tue Jul 29 15:44:46 2014 +0200

Fixup device-mapper 'cookie' handling
   
device-mapper has a 'cookie', which is inserted with the ioctl
for modifying device-mapper devices.
It is used as a synchronization point between udev and any other
applications to notify the latter when udev has finished
processing the event.
Originally multipath would only use a single cookie for every
transaction, and wait for that cookie at the end of the program.
Which works well if you only have one transaction, but for several
(like calling 'multipath') it will actually overwrite the cookie
and fail to wait for earlier events.
This causes libdevmapper to create the device nodes on its own,
and the device nodes not being handled by udev.
   
Signed-off-by: Hannes Reinecke 

So it looks like this is the designed behavior.

-- 
Andrew Patterson
Hewlett-Packard Enterprise

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Paul Wise]

On Sun, 2016-04-17 at 17:18 -0700, Kip Warner wrote:

> Nice to hear from you again.

Likewise! I hope Avaneya is going well :)

> https://springrts.com/mantis/view.php?id=5058

Cool. Some thoughts:

Hmm, compile-time choice of CPU instructions doesn't sound like a good
idea, because if I build on an old crappy build machine or a base-level 
qemu virtual machine then I won't be getting SSE4 when I run on my fast
powerful desktop machine. Please ask upstream to switch to runtime
choice based on the available instructions on the user's CPU.

Please talk to upstream about the test suite stuff too.

The upstream website says that it uses the SoftFloat library for the
software floating-point implementation. Since this is a modified
embedded code copy too, please document this in the security team's
embedded code copies file and talk to the upstreams about it. Likewise
for the old libc code and for Random.cpp.

> After some discussion upstream (Spring RTS), they were at first
> reluctant to rely on an external package (or even pkg-config at build
> time for that matter!), but eventually they came around. 

Great work convincing them!

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#818909: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers

[Drew Parsons]

On Sat, 9 Apr 2016 13:25:35 +0200 Aurelien Jarno 
wrote:
> 
> The chrpath issue has been fixed, I have scheduled binNMUs to get a
> fixed openmpi on mipsel and mips64el
> 
> I am keeping this bug open with severity minor to not forget to
remove
> the workaround that has been added (thanks for that). There is no
> urgency for it, it can wait other changes.
> 


petsc now builds on all official architectures except for mipsel.  It
does build on mips and mips64el, but not mipsel.  I'm not certain if
the build failure is related to the final work needed in this bug for
mipsel, or if it's something else.  Further details are in Bug#816101.

Drew

Bug#814921: RFS: sphde/1.1.0-1 [ITP] -- sphde -- Shared Persistent Heap Data Environment library

[Paul Wise]

On Fri, Apr 15, 2016 at 8:59 PM, Gianfranco Costamagna wrote:

> BTW one single symbol file please

I recommend using the C++ support in dpkg-gensymbols to achieve this,
it is better than restricting particular symbols to particular arches
etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#795603: ruby-libvirt: has no rubygems-integration entry

[Antonio Terceiro]

Control: tag -1 + patch
Control: severity -1 important

On Thu, Mar 10, 2016 at 07:55:51PM +0100, Guido Günther wrote:
> On Sat, Aug 15, 2015 at 06:32:25PM +0200, Guido De Rosa wrote:
> [..snip..]
> > [Suggested solution / approach]
> > 
> > I guess the issue can be easily fixed by adding the gemspec file taken
> > from the original gem
> 
> 
> Did you check that this works? If so, could you provide a tested patch?

I have one, attached.

This is actually a requirement for the vagrant-libvirt vagrant plugin to
work correctly, so I am taking the liberty of raising the severity to
important again.

It would be very nice if this could be fixed sooner rather than later. I
can also NMU if you are OK with it.

Thanks
diff -Nru ruby-libvirt-0.6.0/debian/changelog ruby-libvirt-0.6.0/debian/changelog
--- ruby-libvirt-0.6.0/debian/changelog	2016-03-10 16:04:32.0 -0300
+++ ruby-libvirt-0.6.0/debian/changelog	2016-04-17 14:36:34.0 -0300
@@ -1,3 +1,16 @@
+ruby-libvirt (0.6.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: remove manual test run in favor of gem2deb's own mechanism
+for running tests, avoiding building the C extension twice on every Debian
+build.
+* This also gives us autopkgtest support almost for free; so add
+  `Testsuite: autopkgtest` in debian/control
+  * debian/rules: call debian/gemspec.rake to build a gemspec during the build
+(Closes: #795603)
+
+ -- Antonio Terceiro   Sun, 17 Apr 2016 14:04:22 -0300
+
 ruby-libvirt (0.6.0-1) unstable; urgency=medium
 
   * [dc7846f] New upstream version 0.6.0
diff -Nru ruby-libvirt-0.6.0/debian/control ruby-libvirt-0.6.0/debian/control
--- ruby-libvirt-0.6.0/debian/control	2016-03-10 16:03:34.0 -0300
+++ ruby-libvirt-0.6.0/debian/control	2016-04-17 14:38:15.0 -0300
@@ -7,11 +7,12 @@
 # for the tests
  rake,
  libvirt-daemon
-Standards-Version: 3.9.6
-Vcs-Git: git://anonscm.debian.org/git/pkg-libvirt/ruby-libvirt.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-libvirt/ruby-libvirt.git;a=summary
+Standards-Version: 3.9.7
+Vcs-Git: https://anonscm.debian.org/git/pkg-libvirt/ruby-libvirt.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-libvirt/ruby-libvirt.git
 Homepage: http://libvirt.org/ruby/
 XS-Ruby-Versions: all
+Testsuite: autopkgtest
 
 Package: ruby-libvirt
 Architecture: any
diff -Nru ruby-libvirt-0.6.0/debian/gemspec.rake ruby-libvirt-0.6.0/debian/gemspec.rake
--- ruby-libvirt-0.6.0/debian/gemspec.rake	1969-12-31 21:00:00.0 -0300
+++ ruby-libvirt-0.6.0/debian/gemspec.rake	2016-04-17 14:26:33.0 -0300
@@ -0,0 +1,8 @@
+load 'Rakefile'
+
+gemspec = "ruby-libvirt-#{PKG_VERSION}.gemspec"
+
+task :gemspec => gemspec
+file gemspec do |t|
+  File.open(t.name, 'w') { |f| f.write(SPEC.to_ruby) }
+end
diff -Nru ruby-libvirt-0.6.0/debian/ruby-tests.rake ruby-libvirt-0.6.0/debian/ruby-tests.rake
--- ruby-libvirt-0.6.0/debian/ruby-tests.rake	1969-12-31 21:00:00.0 -0300
+++ ruby-libvirt-0.6.0/debian/ruby-tests.rake	2016-04-17 14:34:18.0 -0300
@@ -0,0 +1,12 @@
+topdir = File.dirname(File.dirname(__FILE__))
+ENV['XDG_RUNTIME_DIR'] = topdir
+ENV['XDG_CONFIG_HOME'] = topdir
+ENV['LIBVIRT_DEFAULT_URI'] = 'test:///default'
+ENV['RUBY_LIBVIRT_TEST_URI'] = 'test:///default'
+
+require 'gem2deb/rake/testtask'
+Gem2Deb::Rake::TestTask.new do |t|
+  t.test_files = [ 'tests/test_nodedevice.rb',
+   'tests/test_open.rb',
+   'tests/test_stream.rb' ]
+end
diff -Nru ruby-libvirt-0.6.0/debian/rules ruby-libvirt-0.6.0/debian/rules
--- ruby-libvirt-0.6.0/debian/rules	2016-02-04 14:26:48.0 -0200
+++ ruby-libvirt-0.6.0/debian/rules	2016-04-17 14:05:26.0 -0300
@@ -4,8 +4,10 @@
 %:
 	dh $@ --buildsystem=ruby --with ruby
 
-override_dh_auto_test:
-	XDG_RUNTIME_DIR=$(CURDIR) \
-	XDG_CONFIG_HOME=$(CURDIR) \
-	LIBVIRT_DEFAULT_URI=test:///default \
-	RUBY_LIBVIRT_TEST_URI=test:///default rake test
+override_dh_auto_install:
+	rake -f debian/gemspec.rake gemspec
+	dh_auto_install
+
+override_dh_auto_clean:
+	$(RM) *.gemspec
+	dh_auto_clean
diff -Nru ruby-libvirt-0.6.0/debian/tests/control ruby-libvirt-0.6.0/debian/tests/control
--- ruby-libvirt-0.6.0/debian/tests/control	1969-12-31 21:00:00.0 -0300
+++ ruby-libvirt-0.6.0/debian/tests/control	2016-04-17 14:22:51.0 -0300
@@ -0,0 +1,2 @@
+Test-Command: rake -f debian/gemspec.rake gemspec && gem2deb-test-runner --autopkgtest --check-dependencies 2>&1
+Depends: @, libvirt-dev,pkg-config,rake,libvirt-daemon, gem2deb-test-runner


signature.asc
Description: PGP signature

Bug#821352: Acknowledgement (Edge-scrolling and tap-to-click no longer working)

[Michael Biebl]

On Mon, 18 Apr 2016 02:47:38 +0200 Michael Biebl  wrote:

> > The option to configure edge-scrolling has been removed as well from
> > gnome-control-center, imho this should be readded as well, as this is an
> > import usability regression.
> 
> I'll mark this as forwarded accordingly.

For anyone who wants edge-scrolling back, you can cop the attached
desktop file to ~/.config/autostart/

You might have to adjust the xprop parameters.

Run "xinput list" and look for your touchpad (in my case it's device
number 11), then run "xinput list-props ". There, look for
"Scroll Method Enabled" (in my case 290)
That gives you
/usr/bin/xinput set-prop 11 --type=int --format=8 290 0 1 0


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


edge-scrolling.desktop
Description: application/desktop


signature.asc
Description: OpenPGP digital signature

Bug#821311: linux-image-4.5.0-1-armmp-lpae: ethernet fails to detect carrier on Firefly boards

[Vagrant Cascadian]

Control: notfound 821311 4.6~rc3-1~exp1

On 2016-04-17, Vagrant Cascadian wrote:
> Running the 4.5.x kernel doesn't appear to have working carrier
> detection on ethernet for the Firefly board. Earlier 4.4.x versions of
> the kernel work fine.

Well, at least the 4.6-rc3 kernel from experimental at appears to work
fine...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#821355: mdadm: RAID1 unknown partition table kernel messages for raid disks

[Royce Lithgo]

Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Upgraded Debian "stable" to 8.4.
For testing also built a new Debian "stable" 8.4 server.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Built RAID1 array with 2 disks, /dev/sbd and /dev/sdc
Disks were not partitioned prior to create.

   * What was the outcome of this action?
Every 5 minutes /var/log/kern.log gets spammed with these messages:
Apr 18 09:28:02 OraDev kernel: [  239.699780]  sdb: unknown partition table
Apr 18 09:28:02 OraDev kernel: [  239.820083]  sdc: unknown partition table
Apr 18 09:33:12 OraDev kernel: [  550.186757]  sdb: unknown partition table
Apr 18 09:33:13 OraDev kernel: [  550.332722]  sdc: unknown partition table
Apr 18 09:38:23 OraDev kernel: [  860.690046]  sdb: unknown partition table
Apr 18 09:38:23 OraDev kernel: [  860.912395]  sdc: unknown partition table
Apr 18 09:43:23 OraDev kernel: [ 1161.079827]  sdb: unknown partition table
Apr 18 09:43:23 OraDev kernel: [ 1161.194904]  sdc: unknown partition table

   * What outcome did you expect instead?
No messages.

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


-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root
ARRAY /dev/md/0 metadata=1.2 name=OraDev:0 
UUID=c0e9ccb7:0fa23f89:7c1cc1f0:11176cba

--- /etc/default/mdadm
INITRDSTART='none'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid1] 
md0 : active raid1 sdb[0] sdc[1]
  488255488 blocks super 1.2 [2/2] [UU]
  bitmap: 0/4 pages [0KB], 65536KB chunk

unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80  250059096 sda
   81  239899648 sda1
   82  1 sda2
   85   10157056 sda5
  1101048575 sr0
   8   16  488386584 sdb
   8   32  488386584 sdc
   90  488255488 md0

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1007433,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1615408k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/md0 on /mnt/raid type ext4 (rw,relatime,data=ordered)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/115 type tmpfs 
(rw,nosuid,nodev,relatime,size=807704k,mode=700,uid=115,gid=122)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=807704k,mode=700,uid=1000,gid=1000)

--- initrd.img-3.16.0-4-amd64:
94175 blocks
d3be82c0f275d6c25b04d388baf9e836  ./etc/modprobe.d/mdadm.conf
8e77686a1bbfb047270c4f492a95f4d9  ./etc/mdadm/mdadm.conf
599bbf3fe6093157a26863dcb59cdf5d  ./scripts/local-top/mdadm
131be8e959b59b6dc48c289966125cd4  ./sbin/mdadm
00836adf69901d2eeca7d38e38dcb713  ./conf/mdadm
9a7bb44377b1a47f4deb35d9d8197578  
./lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid1.ko
ae86495b276499238b3878138013d030  
./lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid10.ko
5b9ef223eb3cb1fcaf57b47dee9ed899  

Bug#817091: Acmetool Review

[Harlan Lieberman-Berg]

Hi Peter,

Took a look at the acmetool package, and it looks pretty good.

You might want to suppress the lintian warnings for some of the
hardening flags; it's my understanding (please correct me if I'm wrong
-- I'm far from a Golang expert) that Golang simply doesn't support many
kinds of hardening flags on its output -- PIE just doesn't work, and
since it produces statically linked binaries, some of the other stuff
doesn't work either.

There's also a newer version that's been released since you first
packaged acmetool; it should be updated prior to upload.

Thanks for your help!

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#821352: Acknowledgement (Edge-scrolling and tap-to-click no longer working)

[Michael Biebl]

Control: clone -1 -2
Control: retitle -2 tap-to-click requires xserver-xorg-input-libinput
Control: retitle -1 edge-scrolling can no longer be configured
Control: reassign -1 gnome-control-center
Control: found -1  1:3.19.92-1
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=761461

Am 18.04.2016 um 02:40 schrieb Michael Biebl:
> Apparently tap-to-click requires that xserver-xorg-input-libinput is
> installed, so I guess we need to make some package
> (gnome-settings-daemon?) pull that package in.
> 
> Still, the option to configure tap-to-click has been removed from
> gnome-control-center. I think this is a regression and we should report
> that upstream.

I need to correct that. Tap-to-click can still be configured, it just
needs xserver-xorg-input-libinput

> The option to configure edge-scrolling has been removed as well from
> gnome-control-center, imho this should be readded as well, as this is an
> import usability regression.

I'll mark this as forwarded accordingly.


-- 
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#821352: Acknowledgement (Edge-scrolling and tap-to-click no longer working)

[Michael Biebl]

Apparently tap-to-click requires that xserver-xorg-input-libinput is
installed, so I guess we need to make some package
(gnome-settings-daemon?) pull that package in.

Still, the option to configure tap-to-click has been removed from
gnome-control-center. I think this is a regression and we should report
that upstream.

The option to configure edge-scrolling has been removed as well from
gnome-control-center, imho this should be readded as well, as this is an
import usability regression.

-- 
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#821353: wxmaxima: Alt+Up/Down does not work in Gnome 3

[Anders Andersson]

Package: wxmaxima
Version: 16.04.1-1
Severity: normal

Dear Maintainer,

The keyboard shortcuts Alt+Up/Down does not work when using wxMaxima in
Gnome 3. They are supposed to make it possible to edit previous
commands (like cursor up/down does in bash/readline), but instead they
simply act like plain Up/Down without Alt.

Selecting the menu entry "Cell->Previous Command" works as expected.

No Gnome function is bound to Alt+Up or Alt+Down.



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

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

Versions of packages wxmaxima depends on:
ii  ibus-gtk3 1.5.11-1
ii  imagemagick   8:6.8.9.9-7+b2
ii  libc6 2.22-6
ii  libgcc1   1:5.3.1-14
ii  libstdc++65.3.1-14
ii  libwxbase3.0-0v5  3.0.2+dfsg-1.3+b1
ii  libwxgtk3.0-0v5   3.0.2+dfsg-1.3+b1
ii  maxima5.37.3-1
ii  maxima-doc5.37.3-1

Versions of packages wxmaxima recommends:
ii  fonts-jsmath 0.090709+0-3
ii  texlive-latex-extra  2015.20160320-1

wxmaxima suggests no packages.

-- no debconf information

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Bas Wijnen  writes:

> I didn't look at the package, but just a quick note:

Thanks. In the case of this package it is unusual; see its PyPI entry at
.

The game as I have packaged it is a normal command-line program: run the
command to play the game.

The Python module has additional behaviour though. It is able to play
the game by being imported in Python as a main module. That is, it
modifies the names available so that game commands can be typed as
Python syntax.

I'm not completely decided on whether that is useful in Debian, nor
whether the module name ‘adventure’ is appropriate. But I would like to
leave the option open for some publicly-available import to provide that
feature in Python. That's why I have done the work to build the separate
‘python3-adventure’ binary package.

> Similarly for adventure-common: the usual reason for splitting off
> common files is that you don't want a copy for every arch on the
> mirrors […] Or do you have a different reason for the split?

Another common reason to build a ‘foo-common’ package is that there can
be multiple possible implementations of essentially the same ‘foo’
behaviour, that could each make use of common files. Adventure is one
such variously-implemented program.

> Do you expect any package (or user) to need the data files, but not
> the game?

I am making the ‘adventure-common’ package because it could be used by
other Adventure implementations.

-- 
 \“All opinions are not equal. Some are a very great deal more |
  `\   robust, sophisticated, and well supported in logic and argument |
_o__) than others.” —Douglas Adams |
Ben Finney 

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Ben Finney]

Markus Koschany  writes:

> I had a look at your package and wanted to give you some feedback
> because of the effort you put into packaging this game.

Thank you! Are you a prospective sponsor of this package?

> The vim comments at the bottom are not allowed (syntax-wise)

Those are in end-line comments (“# foo”). My understanding is that
end-line comments with that syntax are permitted in any Debian control
files.

> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
> or CC-BY-4.0

Thanks. The package includes works I have derived from upstream works
licensed under CC By-2.0.

My understanding of the problems with CC licenses version 2.0 is in the
potential for some licensors to set impractical restrictions on
attribution. That is not the case for any of these specific works, so I
think they are DFSG-free currently.

To avoid such problems arising for the derived works, I will set the
license to CC By-4.0 in those derived works as distributed in Debian.

> You have patched the upstream sources (12 patches). In general the
> patches look O.K but I wonder if they are all necessary. Did you
> forward them upstream? Why do you think Debian should diverge from
> upstream?

Those patches turn the work into a useable stand-alone program for
Debian. Each one is submitted upstream, and I'm corresponding with the
upstream maintainer to get these changes incorporated.

> You split the game into three arch:all binary packages. I'm not
> totally convinced that this is really necessary for a game like
> python-adventure. Your current approach is not totally wrong either,
> perhaps a bit too perfectionist though. Are there strong reasons why
> you split the game into three parts?

I would think rather that conforming to Debian policy would be the
default, and a divergence would need a strong reason.

> Why don't you join the Python or Games Team and maintain
> python-adventure within one of these teams?

No particular reason. I am enjoying maintaining the code as it is.

> I found the following things with check-all-the-things:
>
> colossal-cave-adventure.desktop: found with desktop-file-validate
> error: value "adventure;advent;colossal;cave;spelunk" for locale string
> list key "Keywords" in group "Desktop Entry" does not have a semicolon
> (';') as trailing character

Thank you. I formed that field just by copying others. Is there a
specification for that field that I've missed?

> codespell --quiet-level=3
> ./adventure/advent.dat:996: KNIVE  ==> KNIFE
> ./adventure/advent.dat:1462: THRU  ==> THROUGH
>
> Might be intentional since it's the original game dialogue.

Yes, that's right; the purpose of the package is to present the original
game data and dialogue.

> pep8 --ignore W191 . found something that could be improved. Nothing
> critical but it could be forwarded upstream.
>
> pyflakes3 .
> ./adventure/__main__.py:10: 'readline' imported but unused

Thanks, I will work with upstream on code style over time.

-- 
 \  “If you don't fail at least 90 percent of the time, you're not |
  `\aiming high enough.” —Alan Kay |
_o__)  |
Ben Finney

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

On Mon, 2016-04-18 at 08:05 +0800, Paul Wise wrote:
> There are some embedded code copies of this already in Debian, it
> would be great if you could get them to use the package you are
> preparing instead of the code copies in the packages. Please also
> ensure the security team knows about these embedded code copies.
> 
> https://codesearch.debian.net/search?perpkg=1=streflop
> https://wiki.debian.org/EmbeddedCodeCopies

Hey Paul,

Nice to hear from you again. MegaGlest I will liaise with, but Spring
RTS is already aware of my effort to Debianize streflop:

https://springrts.com/mantis/view.php?id=5058

This is partially why I had prepared a PPA, for situations like that
(or at least for those developers using Ubuntu):

https://launchpad.net/~kip/+archive/ubuntu/streflop

After some discussion upstream (Spring RTS), they were at first
reluctant to rely on an external package (or even pkg-config at build
time for that matter!), but eventually they came around. Nevertheless,
I still haven't heard back from them on their efforts to test the
package.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com



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

Bug#821352: Edge-scrolling and tap-to-click no longer working

[Michael Biebl]

Package: gnome-settings-daemon
Version: 3.20.0-1
Severity: important

After the upgrade to 3.20, edge-scrolling and tap-to-click are no longer
my X220. I'm using the standard wacom driver for my touchpad.

Maybe related:
https://bugzilla.gnome.org/show_bug.cgi?id=761461


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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gsettings-desktop-schemas3.20.0-3
ii  libasound2   1.1.0-1
ii  libc62.22-6
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcolord2   1.2.12-1
ii  libcups2 2.1.3-5
ii  libfontconfig1   2.11.0-6.4
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgeoclue-2-0   2.4.1-1
ii  libgeocode-glib0 3.20.1-1
ii  libglib2.0-0 2.48.0-1
ii  libgnome-desktop-3-123.20.1-1
ii  libgtk-3-0   3.20.3-1
ii  libgudev-1.0-0   230-3
ii  libgweather-3-6  3.20.0-1
ii  liblcms2-2   2.6-3+b3
ii  libnm0   1.1.94-1
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.23-2
ii  libpam-systemd   229-4
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpolkit-gobject-1-00.105-15
ii  libpulse-mainloop-glib0  8.0-2
ii  libpulse08.0-2
ii  librsvg2-2   2.40.15-1
ii  libupower-glib3  0.99.4-2
ii  libwacom20.18-1
ii  libwayland-client0   1.10.0-1
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.20.0-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  1.1-1
ii  pulseaudio8.0-2

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Paul Wise]

On Sat, Apr 9, 2016 at 8:44 AM, Kip Warner wrote:

> * Package name: streflop

There are some embedded code copies of this already in Debian, it
would be great if you could get them to use the package you are
preparing instead of the code copies in the packages. Please also
ensure the security team knows about these embedded code copies.

https://codesearch.debian.net/search?perpkg=1=streflop
https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#821351: debian-goodies: checkrestart crashes with error AttributeError: 'list' object has no attribute 'startswith'

[Aaron Hastings]

Package: debian-goodies
Version: 0.63
Severity: normal

checkrestart fails on one (and only one) of my Debian 8 jessie systems. The odd 
thing is that I have two more-or-less "identical" servers used as Nginx API 
hosts. The two are managed using Salt and so should not be deviated from each 
other package or config-wise. However, I only get this issue on one of them.

The error I get is just a Python traceback. Nothing too descriptive:

shell#> checkrestart

Traceback (most recent call last):
  File "/usr/sbin/checkrestart", line 637, in 
main()
  File "/usr/sbin/checkrestart", line 131, in main
toRestart = lsofcheck(blacklist = blacklist)
  File "/usr/sbin/checkrestart", line 284, in lsofcheck
process = processes.setdefault(data,Process(int(data)))
  File "/usr/sbin/checkrestart", line 557, in __init__
data = self.which(data)
  File "/usr/sbin/checkrestart", line 572, in which
if os.path.isabs(program):
  File "/usr/lib/python2.7/posixpath.py", line 61, in isabs
return s.startswith('/')
AttributeError: 'list' object has no attribute 'startswith'


I'm not sure how much more detail I can add here, given the simple nature of 
this program's functioning. Let me know if I can provide any other information.

Thanks,
Aaron


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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 debian-goodies depends on:
ii  curl  7.38.0-4+deb8u3
ii  dctrl-tools [grep-dctrl]  2.23
ii  perl  5.20.2-3+deb8u4
ii  python2.7.9-1
ii  whiptail  0.52.17-1+b1

Versions of packages debian-goodies recommends:
ii  lsof  4.86+dfsg-1

Versions of packages debian-goodies suggests:
pn  popularity-contest  
pn  xdg-utils   
pn  zenity  

-- no debconf information

Bug#821334: approx: 'apt-get update' yields 'Err http://approx wheezy-updates/main amd64 Packages'

[Eric Cooper]

Sorry, I should have noticed sooner that you're running the version
from wheezy. Can you try installing the version from wheezy-backports:
https://packages.debian.org/wheezy-backports/approx
and see if that works better?

--
Eric Cooper e c c @ c m u . e d u

Bug#809112: condor: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 809112 + patch
thanks

>debian/rules override_dh_install
> make[1]: Entering directory '/<>'
> dh_install
> # fix permissions
> chmod -x debian/htcondor/etc/default/condor
> chmod: cannot access 'debian/htcondor/etc/default/condor': No such file or 
> directory
> debian/rules:105: recipe for target 'override_dh_install' failed

This happens because we are creating arch-independent packages only,
so debian/htcondor/[...] does not exist, because htcondor is
arch-dependent.

The trivial fix is to override dh_install only for arch-dependent packages.
While we are at it, the chmod commands fit better in override_dh_fixperms-arch.

Patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -101,11 +101,15 @@ override_dh_auto_install:
chrpath -c -k ./debian/tmp/usr/lib/condor/libexec/* || true
 
 
-override_dh_install:
-   dh_install
+override_dh_fixperms-arch:
+   dh_fixperms
# fix permissions
chmod -x debian/htcondor/etc/default/condor
chmod -x debian/htcondor/usr/lib/condor/libexec/interactive.sub
+
+
+override_dh_install-arch:
+   dh_install
# remove RPATH from public lib
chrpath -d debian/libclassad*/usr/lib/libclassad.so.*.*
# remove duplicate that is also installed as a config file

Bug#821349: Please add Breaks for older gnome-terminal and libvte-2.91-0

[Josh Triplett]

On Mon, Apr 18, 2016 at 12:50:58AM +0200, Michael Biebl wrote:
> Am 18.04.2016 um 00:29 schrieb Josh Triplett:
> > Package: libgtk-3-0
> > Version: 3.20.3-1
> > Severity: normal
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819712 and
> > https://bugzilla.gnome.org/show_bug.cgi?id=760944 for background.  GTK+3
> > 3.20 removed functionality that gnome-terminal and libvte-2.91-0
> > depended on.  While newer versions of those have worked around the
> > problem, this still breaks older versions.  Please consider adding
> > Breaks on the following:
> > 
> > gnome-terminal (<< 3.20.1-1)
> 
> I'm running gnome-terminal 3.20.0-1 but I don't see a problem. Can you
> be more specific what the breakage is?

With gnome-terminal 3.20.0-1, along with the latest libgtk-3-0 and
libvte-2.91-0 from unstable, if I create a gnome-terminal window and hit
Ctrl-+, the font size increases but the window stays the same size,
resulting in decreased $COLUMNS and $LINES instead.  (Downgrading
libgtk-3-0 and libvte-2.91-0 fixes that.)  The changelog entries for
gnome-terminal 3.20.0-2, 3.20.0-3, and 3.20.1-1 mention various fixes
and refinements for bug 819712; I'll test those as soon as 3.20.1-1
becomes available for amd64.

Note that each time I upgraded or downgraded to a different version of
any of these packages, I restarted my session (sudo systemctl restart
gdm3) before testing.

- Josh Triplett

Bug#815667: ERROR: error executing SQL - cannot start a transaction within a transaction

[Christoph Egger]

Hi!

FWIW I changed the kasp.sqlite to WAL mode (found somewhere on the
opendnssec bugtracker) which made things go smooth indeed for a
while. And resulted in bad database corruption.

  Christoph

Bug#821334: approx: 'apt-get update' yields 'Err http://approx wheezy-updates/main amd64 Packages'

[David Christensen]

On 04/17/2016 01:51 PM, Eric Cooper wrote:

Can you please enable debugging for the approx server
(add a "$debug true" line to /etc/approx/approx.conf),
and then send me the relevant part of the log (in /var/log/daemon.log
for example) when this error occurs.  Thanks.


Thanks for the prompt reply.  Please see console session, below.

David



2016-04-17 15:54:11 root@cd2533 ~
# grep -v '#' /etc/approx/approx.conf

debian  http://ftp.debian.org/debian
securityhttp://security.debian.org/debian-security


$debug  true

2016-04-17 15:54:17 root@cd2533 ~
# grep -v '#' /etc/apt/sources.list
deb http://approx:/debian   wheezy  main
deb http://approx:/security wheezy/updates  main
deb http://approx:/debian   wheezy-updates  main

2016-04-17 15:54:25 root@cd2533 ~
# cp /var/log/daemon.log daemon.log-foo
cp: overwrite `daemon.log-foo'? y

2016-04-17 15:54:35 root@cd2533 ~
# apt-get update
Get:1 http://approx wheezy Release.gpg [2373 B]
Get:2 http://approx wheezy/updates Release.gpg [1554 B]
Hit http://approx wheezy-updates Release.gpg
Get:3 http://approx wheezy Release [191 kB]
Get:4 http://approx wheezy/updates Release [102 kB]
Hit http://approx wheezy-updates Release
Get:5 http://approx wheezy/main Translation-en [3846 kB]
Get:6 http://approx wheezy/updates/main Translation-en [202 kB]
Ign http://approx wheezy-updates/main amd64 Packages/DiffIndex
Hit http://approx wheezy-updates/main Translation-en/DiffIndex
Get:7 http://approx wheezy/main amd64 Packages [7635 kB]
Get:8 http://approx wheezy/updates/main amd64 Packages [438 kB] 

Err http://approx wheezy-updates/main amd64 Packages 



Err http://approx wheezy-updates/main amd64 Packages 



Err http://approx wheezy-updates/main amd64 Packages

Hit http://approx wheezy-updates/main amd64 Packages
Fetched 12.4 MB in 8s (1455 kB/s) 


Reading package lists... Done

2016-04-17 15:55:06 root@cd2533 ~
# diff daemon.log-foo /var/log/daemon.log
523a524,723
> Apr 17 15:54:40 cd2533 approx[7972]: Connection from 192.168.1.253 
port 48830
> Apr 17 15:54:40 cd2533 approx[7972]: Request: GET 
/debian/dists/wheezy/Release.gpg

> Apr 17 15:54:40 cd2533 approx[7972]:   Host: approx:
> Apr 17 15:54:40 cd2533 approx[7972]:   Connection: keep-alive
> Apr 17 15:54:40 cd2533 approx[7972]:   Cache-Control: max-age=0
> Apr 17 15:54:40 cd2533 approx[7972]:   User-Agent: Debian 
APT-HTTP/1.3 (0.9.7.9)
> Apr 17 15:54:40 cd2533 approx[7972]:   last modified: Sat, 02 Apr 
2016 12:17:17 GMT
> Apr 17 15:54:40 cd2533 approx[7972]:   last verified: Sun, 17 Apr 
2016 22:49:26 GMT

> Apr 17 15:54:40 cd2533 approx[7972]:   => delivering from cache
> Apr 17 15:54:40 cd2533 approx[7972]: Local response
> Apr 17 15:54:40 cd2533 approx[7972]:   Last-Modified: Sat, 02 Apr 
2016 12:17:17 GMT

> Apr 17 15:54:40 cd2533 approx[7972]:   Content-Type: text/plain
> Apr 17 15:54:40 cd2533 approx[7972]:   Content-Length: 2373
> Apr 17 15:54:40 cd2533 approx[7972]: Connection from 192.168.1.253 
port 48830
> Apr 17 15:54:40 cd2533 approx[7972]: Request: GET 
/security/dists/wheezy/updates/Release.gpg

> Apr 17 15:54:40 cd2533 approx[7972]:   Host: approx:
> Apr 17 15:54:40 cd2533 approx[7972]:   Connection: keep-alive
> Apr 17 15:54:41 cd2533 approx[7972]:   Cache-Control: max-age=0
> Apr 17 15:54:41 cd2533 approx[7972]:   User-Agent: Debian 
APT-HTTP/1.3 (0.9.7.9)
> Apr 17 15:54:41 cd2533 approx[7972]:   last modified: Sun, 17 Apr 
2016 19:00:43 GMT
> Apr 17 15:54:41 cd2533 approx[7972]:   last verified: Sun, 17 Apr 
2016 22:49:26 GMT

> Apr 17 15:54:41 cd2533 approx[7972]:   => delivering from cache
> Apr 17 15:54:41 cd2533 approx[7972]: Local response
> Apr 17 15:54:41 cd2533 approx[7972]:   Last-Modified: Sun, 17 Apr 
2016 19:00:43 GMT

> Apr 17 15:54:41 cd2533 approx[7972]:   Content-Type: text/plain
> Apr 17 15:54:41 cd2533 approx[7972]:   Content-Length: 1554
> Apr 17 15:54:41 cd2533 approx[7972]: Connection from 192.168.1.253 
port 48830
> Apr 17 15:54:41 cd2533 approx[7972]: Request: GET 
/debian/dists/wheezy-updates/Release.gpg

> Apr 17 15:54:41 cd2533 approx[7972]:   Host: approx:
> Apr 17 15:54:41 cd2533 approx[7972]:   Connection: keep-alive
> Apr 17 15:54:41 cd2533 approx[7972]:   Cache-Control: max-age=0
> Apr 17 15:54:41 cd2533 approx[7972]:   If-Modified-Since: Sun, 17 Apr 
2016 21:13:47 GMT
> Apr 17 15:54:41 cd2533 approx[7972]:   User-Agent: Debian 
APT-HTTP/1.3 (0.9.7.9)
> Apr 17 15:54:41 cd2533 approx[7972]:   last modified: Sun, 17 Apr 
2016 21:13:47 GMT
> Apr 17 15:54:41 cd2533 approx[7972]:   last verified: Sun, 17 Apr 
2016 22:49:26 GMT

> Apr 17 15:54:41 cd2533 approx[7972]:   => not modified
> Apr 17 15:54:41 cd2533 approx[7972]: Connection from 192.168.1.253 
port 48830
> Apr 17 15:54:41 cd2533 approx[7972]: Request: GET 
/debian/dists/wheezy/Release

> Apr 17 15:54:41 cd2533 approx[7972]:   Host: approx:
> Apr 17 15:54:41 cd2533 approx[7972]:   Connection: keep-alive
> Apr 

Bug#815202: packages: machines and sponsors information is outdated

[Paul Wise]

On Mon, Apr 18, 2016 at 5:47 AM, Stéphane Blondon wrote:

> https://github.com/Debian/ud is the future for the ldap web interface
> (db.debian.org), not for packages.debian.org, isn't it?

Correct.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#820748: uniconvertor: ImportError: No module named sk1libs.utils.fs

[Georgios Zarkadas]

I encountered the same bug.

The missing python modules are contained at the sk1 release tarball at
sourceforge.net (https://sourceforge.net/projects/sk1/). This project is
not yet part of the distribution, although there is an unofficial deb
package provided at the http://sk1project.org/ download page.

Thus someone has to do the packaging of sk1, or the neccesary modules  must
be copied to python-uniconvertor as a patch, or a request to upstream to
fix this issue has to be made.

regards
George

Bug#819332: tuxguitar: New 1.3.x versions available upstream

[Jérôme]

Le Sat, 9 Apr 2016 17:53:01 -0700,
tony mancill  a écrit :

> Hello Jérôme,

Hi.
 
> Thank you for reporting the updated version.  I have taken a quick
> look and the new upstream tarball needs some license clarification
> before it will be distributable as per the DFSG.
> 
> For example, the soundbank beneath ./TuxGuitar-resources/ merely says
> that it was "contributed," but doesn't clarify the distribution
> license. Furthermore, I think we'll run into problems with it not
> being in a "preferred form of modification."

I don't know about the "preferred form of modification". I don't know
how an sf2 file is built and if we could expect some sort of sources
for it.

Anyway, it makes sense to distribute it independently, making it just a
Suggests (and allowing other softwares to use it as well).

FWIW, here is another package with .sf2 files:
https://sources.debian.net/src/fluid-soundfont/3.1-5/

Regarding the licence, without any notice stating otherwise, I'd say
LGPL like the rest, but it doesn't hurt to ask the author. His email
address is in the AUTHORS file. I was about to email him, but you may
want to do it and address the source files issue in the same message.

> Similarly, parts of the TuxGuitar-android tree is GPLv2 instead of
> LGPL, but I believe it can simply be excluded from a DFSG tarball.

Yes, absolutely.
 
> > Any plans to package it?
> 
> I can try, but I welcome help.  I think the first thing to do is
> determine whether we need/want to try to distribute the soundbank
> (via a contrib package) and have the tuxguitar-jsa package suggest
> that. Looking at the popcon graphs [1], the -jsa package isn't nearly
> as popular as either -alsa or -oss, so maybe it's preferable to get
> 1.3.x packaged without it?

If you mean package everything but Magic Sound Font (at least for now)
and the Android stuff, then I totally agree.

Thanks.

-- 
Jérôme

Bug#821349: Please add Breaks for older gnome-terminal and libvte-2.91-0

[Michael Biebl]

Am 18.04.2016 um 00:29 schrieb Josh Triplett:
> Package: libgtk-3-0
> Version: 3.20.3-1
> Severity: normal
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819712 and
> https://bugzilla.gnome.org/show_bug.cgi?id=760944 for background.  GTK+3
> 3.20 removed functionality that gnome-terminal and libvte-2.91-0
> depended on.  While newer versions of those have worked around the
> problem, this still breaks older versions.  Please consider adding
> Breaks on the following:
> 
> gnome-terminal (<< 3.20.1-1)

I'm running gnome-terminal 3.20.0-1 but I don't see a problem. Can you
be more specific what the breakage is?




-- 
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#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Dmitry Smirnov]

Package: dh-golang
Version: 1.15
Severity: serious

Recent upload of "rkt" was rejected

rkt_1.4.0+dfsg-1_amd64.deb: Built-Using refers to non-existing source 
package apt (= 1.0.9.10)

due to rubbish in Built-Using field:

apt (= 1.0.9.10), apt (= 1.0.10.2), apt (= 1.2.10)

Also invocation of dh-golang logged the following:


   dh_golang -O--buildsystem=golang -O--builddirectory=_build
can't load package: package github.com/coreos/rkt/api/v1alpha: cannot find 
package "github.com/coreos/rkt/api/v1alpha" in any of:
/usr/lib/go/src/github.com/coreos/rkt/api/v1alpha (from $GOROOT)

/build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/coreos/rkt/api/v1alpha
 (from $GOPATH)
can't load package: package github.com/coreos/rkt/rkt: cannot find package 
"github.com/coreos/rkt/rkt" in any of:
/usr/lib/go/src/github.com/coreos/rkt/rkt (from $GOROOT)

/build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/coreos/rkt/rkt (from 
$GOPATH)
can't load package: package .: no buildable Go source files in 
/build/rkt-1.4.0+dfsg
can't load package: package .: no buildable Go source files in 
/build/rkt-1.4.0+dfsg
dpkg-query: error: --search needs at least one file name pattern argument

Use --help for help about querying packages.


This is regression from "dh-golang" v1.12.

Please investigate.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Truth never damages a cause that is just.
-- Mahatma Gandhi


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

Bug#781501: gnote segfaults when it can't find a .note file

[Michael Biebl]

Control: severity -1 grave
Control: tags -1 - moreinfo unreproducible

Hi Vincent

Am 18.04.2016 um 00:35 schrieb Michael Biebl:
> 
> I can reproduce the issue (backtrace attached).
> 
> I do have a ~/.gnote folder. gnote has been installed a long time.
> Moving ~/.gnote away, makes gnote start up.
> 
> I do think this makes it a RC bug, as gnote should be able to deal with
> old data after an upgrade.

Here is a simple way to reproduce the bug:

# remove existing data
rm -rf ~/.local/share/gnote
# create some legacy data
mkdir ~/.gnote
then copy the attached file to ~/.gnote/

If you now start gnote, you'll get the crash. In the light of this
simple reproducer and assuming that there are possibly quite a few users
with old data, I'm raising the severity.



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

http://beatniksoftware.com/tomboy/link; xmlns:size="http://beatniksoftware.com/tomboy/size; xmlns="http://beatniksoftware.com/tomboy;>Hier startenhttp://beatniksoftware.com/tomboy; version="0.1">Hier starten

Willkommen zu Tomboy!

Benutzen Sie diese Seite als Startseite um Ihre Notizen zu verwalten und umherschwirrende Ideen zu sammeln.

2006-08-20T20:46:34Z2006-08-20T20:46:34Z2006-08-20T20:46:34Z14463360564345False



signature.asc
Description: OpenPGP digital signature

Bug#781501: gnote segfaults when it can't find a .note file

[Michael Biebl]

I can reproduce the issue (backtrace attached).

I do have a ~/.gnote folder. gnote has been installed a long time.
Moving ~/.gnote away, makes gnote start up.

I do think this makes it a RC bug, as gnote should be able to deal with
old data after an upgrade.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Starting program: /usr/bin/gnote 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe970b700 (LWP 24115)]
[New Thread 0x7fffe8f0a700 (LWP 24116)]
[New Thread 0x7fffe3395700 (LWP 24117)]

Program received signal SIGABRT, Aborted.
0x73e07478 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x73e07478 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
resultvar = 0
pid = 24110
selftid = 24110
#1  0x73e088fa in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x6c2d34365f363878, 
sa_sigaction = 0x6c2d34365f363878}, sa_mask = {__val = {8461814194867891817, 
7091318279560064047, 
  3346019690373591597, 3471765346408738352, 7148451098534491914, 
7365405400577881139, 3473739188760110694, 233741787981676, 
3472328523861012528, 
  3539889987387928608, 2314910914395190576, 2314885530818453536, 
2314885530818453536, 8660248813382869024, 7596496373740942904, 
3419760881481315694}}, 
  sa_flags = 1734502764, sa_restorer = 0x4f}
sigs = {__val = {32, 0 }}
#2  0x73e45ffa in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x73f3dcb8 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
ap = 
fd = 11
on_2 = 
list = 
nlist = 
cp = 
written = 
#3  0x73e4b946 in malloc_printerr (action=3, str=0x73f3a4d1 
"free(): invalid pointer", ptr=, ar_ptr=) at 
malloc.c:5000
buf = "0078fd00"
cp = 
ar_ptr = 
ptr = 
str = 0x73f3a4d1 "free(): invalid pointer"
action = 3
#4  0x73e4c12e in _int_free (av=0x74172b20 , 
p=, have_lock=0) at malloc.c:3861
size = 
fb = 
nextchunk = 
nextsize = 
nextinuse = 
prevsize = 
bck = 
fwd = 
errstr = 
locked = 
__func__ = "_int_free"
#5  0x77b28213 in gnote::NoteManagerBase::~NoteManagerBase 
(this=0x773350, __in_chrg=) at notemanagerbase.cpp:100
No locals.
#6  0x77b255ea in gnote::NoteManager::NoteManager (this=0x773350, 
directory=...) at notemanager.cpp:41
No locals.
#7  0x0044bda4 in gnote::Gnote::common_init (this=this@entry=0x6f4700) 
at gnote.cpp:142
note_path = "/home/michael/.local/share/gnote"
#8  0x0044dfc8 in gnote::Gnote::on_command_line (this=0x6f4700, 
command_line=...) at gnote.cpp:120
argc = 1
argv = 0x82c510
passed_cmd_line = {m_context = 0x84c440, m_use_panel = false, 
m_background = false, m_shell_search = false, m_note_path = 0x0, m_do_search = 
false, m_search = "", 
  m_show_version = false, m_do_new_note = false, m_new_note_name = "", 
m_open_note = 0x0, m_open_start_here = false, m_highlight_search = 0x0, 
  m_open_note_name = "", m_open_note_uri = "", 
m_open_external_note_path = ""}
cmdline = @0x6f4760: {m_context = 0x893480, m_use_panel = false, 
m_background = false, m_shell_search = false, m_note_path = 0x0, m_do_search = 
false, 
  m_search = "", m_show_version = false, m_do_new_note = false, 
m_new_note_name = "", m_open_note = 0x0, m_open_start_here = false, 
m_highlight_search = 0x0, 
  m_open_note_name = "", m_open_note_uri = "", 
m_open_external_note_path = ""}
#9  0x76b6171d in 
Gio::Application_Class::command_line_callback(_GApplication*, 
_GApplicationCommandLine*) () from /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
No symbol table info available.
#10 0x7fffec341060 in ffi_call_unix64 () from 
/usr/lib/x86_64-linux-gnu/libffi.so.6
No symbol table info available.
#11 0x7fffec340acb in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
No symbol table info available.
#12 0x74c47cf5 in g_cclosure_marshal_generic_va () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#13 0x74c471d4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#14 0x74c614b8 in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#15 0x74c6208f in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
No symbol table info available.
#16 0x74f35a13 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
No symbol 

Bug#821349: Please add Breaks for older gnome-terminal and libvte-2.91-0

[Josh Triplett]

Package: libgtk-3-0
Version: 3.20.3-1
Severity: normal

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819712 and
https://bugzilla.gnome.org/show_bug.cgi?id=760944 for background.  GTK+3
3.20 removed functionality that gnome-terminal and libvte-2.91-0
depended on.  While newer versions of those have worked around the
problem, this still breaks older versions.  Please consider adding
Breaks on the following:

gnome-terminal (<< 3.20.1-1)
libvte-2.91-0 (<< 0.44.0-2)

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

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

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0  2.18.1-3
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-6
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.2.12-1
ii  libcups22.1.3-5
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.0-1
ii  libgtk-3-common 3.20.3-1
ii  libjson-glib-1.0-0  1.2.0-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  librest-0.7-0   0.7.93-1
ii  libsoup2.4-12.54.0.1-1
ii  libwayland-client0  1.10.0-1
ii  libwayland-cursor0  1.10.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  11.1.2-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.5-2

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.18.9-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.28.1-1
ii  librsvg2-common  2.40.15-1

-- no debconf information

Bug#821128: rkt: FTBFS on ppc64el: undefined: SYS_SYNCFS

[Luca BRUNO]

tags 821128 + patch
thanks

On Fri, 15 Apr 2016 15:52:19 -0400 "Aaron M. Ucko"  wrote:
 
> Please either add an appropriate sys_linux_*.go file supplying this
> definition or restrict the Architecture: field to reflect reality.

Patch with the additional constant definition sent upstream:
https://patch-diff.githubusercontent.com/raw/coreos/rkt/pull/2443.patch

Tested on ppc64 and ppc64le.
However, ppc64 (BE) still has some trouble and compilation fails in
another place:
"""
/usr/bin/make -C _build/src/github.com/coreos/rkt 
BUILDDIR="/home/lucab/rkt-1.3.0+dfsg"/_build 
GOPATH="/home/lucab/rkt-1.3.0+dfsg"/_build/src2
make[2]: Entering directory 
'/home/lucab/rkt-1.3.0+dfsg/_build/src/github.com/coreos/rkt'
  GO   github.com/coreos/rkt/rkt
../../../../src2/src/github.com/appc/spec/pkg/tarheader/pop_posix.go:24:2: no 
buildable Go source files in 
/home/lucab/rkt-1.3.0+dfsg/_build/src2/src/github.com/appc/spec/pkg/device
makelib/build_go_bin.mk:47: recipe for target 
'/home/lucab/rkt-1.3.0+dfsg/_build/bin/rkt' failed
"""

(at the moment ppc64 BE is not a release architecture, though)

Ciao, Luca

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

Bug#821177: dpkg: please make dpkg perl libraries available on cpan

[Patrick Schönfeld]

Hi,

I understand that it would be bothersome and therefore I understand your
position, yet I ask to reconsider my request :)

2016-04-16 12:56 GMT+02:00 Guillem Jover :
>
> Which means many if not most major distributions (and their
> derivatives) already provide them:
>


Indeed and I did not notice that it's even available on OSX where I could
have needed it. So thanks for the hint.

Still, I see value in providing Debian-specific libraries via CPAN. The
tools available in the packaging
ecosystem allow installing packages independently from the system package
manager, apart from that they can manage several different versions of a
library for different perl versions, which is quiet handy as a developer.

Consider the following use case:
A developer want's to write a tool to query depends of a perl application
from debian/control files, so that this can be the source of truth for what
dependency the application has, even when developing and therefore running
it on a developers OSX notebook (where he'd use the tools in perl ecosystem
to manage the depends). Since the application itself can run on OSX just
fine, there is no reason why this tool couldn't run on OSX. It would also
help to manage dependencies for various target platforms, keeping them in
sync.

There is a library for this and maybe other use cases and it is most likely
to be in sync with the policy. It would be quiet cool if a random perl
developer could use it and get it via standard means, e.g. cpanm. Currently
there is no library for parsing Debian dependencies on CPAN (at least I
haven't found one that doesn't depend on other Dpkg::* libraries) and even
if there were one, it wouldn't be the reference implementation.

I agree that something like that will always have limitations, e.g. if the
libraries in fact require dpkg binaries, but not all of the dpkg perl
libraries do have those limitations, do they?

Best Regards,
Patrick

Bug#807025: statsmodels: FTBFS when built with dpkg-buildpackage -A ('module' object has no attribute 'parse')

[Santiago Vila]

retitle 807025 statsmodels: FTBFS in stretch ('module' object has no attribute 
'parse')
1;2802;0cseverity 807025 serious
user sanv...@debian.org
usertags 807025 - binary-indep
forcemerge 807025 810864
thanks

This was not a "dpkg-buildpackage -A" bug after all but a normal FTBFS bug.

Hello Mattia. If you ever see a misfiled bug like this, please feel
free to drop my binary-indep usertag, retitle, and upgrade to serious.

Thanks.

Bug#821303: Pending fixes for bugs in the rkt package

[pkg-go-maintainers]

tag 821303 + pending
thanks

Some bugs in the rkt package are closed in revision
787cdc437659f77c08746f8d2fc139256b10b054 in branch 'master' by Dmitry
Smirnov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/commit/?id=787cdc4

Commit message:

Depends += "dbus" (Closes: #821303).

Bug#821056: u-boot-tools: no example /etc/fw_env.config files for openrd devices

[Rick Thomas]

On Apr 17, 2016, at 8:35 AM, Vagrant Cascadian  wrote:

> On 2016-04-16, Rick Thomas wrote:
>> Re-reading this, I realize that I said “0x8” for the environment
>> location of legacy u-boot.  But when I went to test it, the true value
>> turned out to be “0xa”.
>> 
>> Sorry for the confusion.  The latter value (0xa) is correct.
> 
> Ok, what you submitted was:
> 
>>> # MTD device name   Device offset   Env. size   Flash sector size
>>> # Legacy u-boot versions:
>>> #/dev/mtd0   0xa 0x2 0x2
>>> 
>>> # New u-boot versions:
>>> /dev/mtd0   0x6 0x2 0x2
> 
> Are those the values you would like in the example fw_env.config for
> openrd, or are you saying they need to be adjusted? If those values need
> to be changed, please re-submit the example fw_env.config you would like
> included in the package.
> 
> 
> live well,
>  vagrant

The correct values for “Device offset” are:

0xa for “Legacy”  u-boot
   and
0x6 for “New”  u-boot

So my suggested /etc/fw_env.config for u-boot-tools on OpenRD machines is:

/usr/share/doc/u-boot-tools/examples/openrd.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
#
# XXX this configuration might miss a fifth parameter for the "Number of
# sectors"

# MTD device name   Device offset   Env. size   Flash sector size
# Legacy u-boot versions:
#/dev/mtd0   0xa 0x2 0x2

# New u-boot versions:
/dev/mtd0   0x6 0x2 0x2
 cut here ===

Sorry for any confusion I may have caused!

For completeness, my testing procedure was:

1) On an OpenRD Ultimate, running latest u-boot
(specifically, “U-Boot 2016.03+dfsg1-3 (Apr 04 2016 - 18:23:06 +)”)
I used the above file as is.
With it, I was able to read the u-boot environment from Linux with fw_printenv.
I did not try fw_setenv.

2) On an OpenRD Client, running a legacy u-boot
(specifically. “U-Boot 1.1.4 (May 18 2009 - 13:33:10) Marvell version: 3.4.16”)
I reversed the commenting on the two “/dev/mtd0” lines.
With that, I was able to read the u-boot environment from Linux with 
fw_printenv.
I did not try fw_setenv.

For the time being, I plan to leave the Client machine with the legacy u-boot, 
incase
you find that further testing is required.

Thank you for your efforts!

Rick

Bug#821347: FTBFS on mipsel and s390x: test suite failures

[Michael Biebl]

Source: libsecret
Version: 0.18.5-1
Severity: serious

libsecret has test suite failure ons mipsel and s390x [1]

mipsel:
FAIL: test-session 4 /session/ensure-async-aes
FAIL: test-collection 18 /collection/delete-sync

s390x:
FAIL: test-collection 18 /collection/delete-sync
the build gets stuck and is killed after 150min



[1] https://buildd.debian.org/status/package.php?p=libsecret
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#821348: RFS: gap-grape/4.7+ds-2 [REPRODUCIBLE] - GRaph Algorithms using PErmutation groups for GAP

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Sponsors,

I am looking for sponsorship for the Debian package gap-grape which 
brings
to Debian the GAP package GRAPE; GAP is a Computer Algebra System (CAS).
This package attempts to render the Debian package reproducible.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gap-grape.git

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#821346: /etc/initramfs-tools/scripts not included in the image

[Любен Каравелов]

Package: initramfs-tools
Version: 0.124
Severity: critical

A script to workaround a chipset bug that is installed in:

/etc/initramfs-tools/scripts/init-premount

is not included in the generated initrd.img.

here is the whole content of the /etc/initramfs-tools:

$ ls -alR /etc/initramfs-tools

$ ls -alR /etc/initramfs-tools

/etc/initramfs-tools/:
total 40
drwxr-xr-x   5 root root  4096 апр 17 22:00 .
drwxr-xr-x 169 root root 12288 апр 17 21:48 ..
drwxr-xr-x   2 root root  4096 апр 17 22:38 conf.d
drwxr-xr-x   2 root root  4096 яну 19 00:02 hooks
-rw-r--r--   1 root root  1107 яну  5 21:50 initramfs.conf
-rw-r--r--   1 root root   249 дек  5 23:08 modules
drwxr-xr-x  12 root root  4096 яну 19 18:17 scripts
-rw-r--r--   1 root root   378 юни 17  2010 update-initramfs.conf

/etc/initramfs-tools/conf.d:
total 12
drwxr-xr-x 2 root root 4096 апр 17 22:38 .
drwxr-xr-x 5 root root 4096 апр 17 22:00 ..
-rw-r--r-- 1 root root   49 авг 13  2014 resume

/etc/initramfs-tools/hooks:
total 8
drwxr-xr-x 2 root root 4096 яну 19 00:02 .
drwxr-xr-x 5 root root 4096 апр 17 22:00 ..

/etc/initramfs-tools/scripts:
total 48
drwxr-xr-x 12 root root 4096 яну 19 18:17 .
drwxr-xr-x  5 root root 4096 апр 17 22:00 ..
drwxr-xr-x  2 root root 4096 яну 19 00:02 init-bottom
drwxr-xr-x  2 root root 4096 апр 17 22:00 init-premount
drwxr-xr-x  2 root root 4096 яну 19 00:02 init-top
drwxr-xr-x  2 root root 4096 яну 19 00:02 local-bottom
drwxr-xr-x  2 root root 4096 апр 17 22:41 local-premount
drwxr-xr-x  2 root root 4096 яну 19 00:02 local-top
drwxr-xr-x  2 root root 4096 яну 19 00:02 nfs-bottom
drwxr-xr-x  2 root root 4096 яну 19 00:02 nfs-premount
drwxr-xr-x  2 root root 4096 яну 19 00:02 nfs-top
drwxr-xr-x  2 root root 4096 яну 19 00:02 panic

/etc/initramfs-tools/scripts/init-bottom:
total 8
drwxr-xr-x  2 root root 4096 яну 19 00:02 .
drwxr-xr-x 12 root root 4096 яну 19 18:17 ..

/etc/initramfs-tools/scripts/init-premount:
total 12
drwxr-xr-x  2 root root 4096 апр 17 22:00 .
drwxr-xr-x 12 root root 4096 яну 19 18:17 ..
-rwxr-xr-x  1 root root  176 дек  7 03:15 export_vars

... the rest of the dirs are empty ...
-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 18M Feb 24 18:45 /boot/initrd.img-4.3.0-1-amd64
-rw-r--r-- 1 root root 18M Apr  1 13:28 /boot/initrd.img-4.4.0-1-amd64
-rw-r--r-- 1 root root 18M Apr 17 22:13 /boot/initrd.img-4.5.0-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.5.0-1-amd64 
root=UUID=a1908697-6218-4737-a017-abf86f272aa5 ro scsi_mod.use_blk_mq=1

-- resume
RESUME=UUID=3fda2043-31e6-4f5c-8220-6d2c74c5d729
-- /proc/filesystems
ext3
ext2
ext4
vfat
xfs
jfs
msdos
ntfs
minix
hfs
hfsplus
qnx4
ufs
btrfs
fuseblk

-- lsmod
Module  Size  Used by
fuse   98304  1
btrfs 995328  0
xor24576  1 btrfs
raid6_pq  102400  1 btrfs
ufs73728  0
qnx4   16384  0
hfsplus   102400  0
hfs57344  0
minix  36864  0
ntfs   98304  0
msdos  20480  0
jfs   176128  0
xfs   962560  0
libcrc32c  16384  1 xfs
crc32c_generic 16384  0
dm_mod110592  0
sch_fq_codel   20480  1
ctr16384  1
ccm20480  1
rfcomm 69632  2
cpufreq_conservative16384  0
cpufreq_stats  16384  0
cpufreq_powersave  16384  0
cpufreq_userspace  16384  0
bnep   20480  2
snd_hda_codec_hdmi 53248  1
binfmt_misc20480  1
arc4   16384  2
intel_rapl 20480  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
coretemp   16384  0
kvm_intel 184320  0
kvm   552960  1 kvm_intel
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
hid_multitouch 20480  0
hid_generic16384  0
btusb  45056  0
btrtl  16384  1 btusb
btbcm  16384  1 btusb
btintel16384  1 btusb
bluetooth 512000  29 bnep,btbcm,btrtl,btusb,rfcomm,btintel
nls_utf8   16384  1
ghash_clmulni_intel16384  0
nls_cp437  20480  1
vfat   20480  1
fat69632  2 vfat,msdos
jitterentropy_rng  16384  0
uvcvideo   90112  0
videobuf2_vmalloc  16384  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 24576  1 uvcvideo
videobuf2_core 36864  2 uvcvideo,videobuf2_v4l2
videodev  172032  3 uvcvideo,videobuf2_core,videobuf2_v4l2
hmac   16384  1
media  32768  2 uvcvideo,videodev
drbg   24576  1
ansi_cprng 16384  0
iTCO_wdt   16384  

Bug#815202: packages: machines and sponsors information is outdated

[Stéphane Blondon]

Le 05/04/2016 07:06, Paul Wise a écrit :
> On Tue, Apr 5, 2016 at 9:05 AM, Stéphane Blondon wrote:
> 
>> There are no commit since two years, so I'm not sure it's still alive.
> 
> Nevertheless, it is the way forward.


Perhaps I am wrong but
https://github.com/Debian/ud is the future for the ldap web interface
(db.debian.org), not for packages.debian.org, isn't it?



To merge the previous Perl patch to packages.debian.org:
- clone http://anonscm.debian.org/cgit/webwml/packages.git/ repository,
check out to the debian-master branch
- move the template static/about/sponsors.tmpl templates/html/
- create a new module lib/Packages/DoAboutSponsors.pm. The request to
the LDAP would be inserted inside.
- modify (at least) lib/Packages/Dispatcher.pm by:
 - including DoAboutSponsors.pm
 - modify do_dispatch to bind the url to the new module. (I didn't
understand it completely)

(I fail to write the patch so I wrote the previous paragraph in hope  it
could help someone else.)


>> - Or providing a python script which could be reused by the django site
>> in the future?
> 
> I agree that any future machines list in ud (one doesn't exist yet)
> should have some filtering options.

I can do a pull/request to github with a modified version of the
previous code if you want.


-- 
Stéphane



signature.asc
Description: OpenPGP digital signature

Bug#819810: There is now and AR release of 2016.2.22

[Eric Valette]

ntfs-3g_ntfsprogs-2016.2.22AR.1.tgz


--eric

Bug#806655: libzen: FTBFS when built with dpkg-buildpackage -A (dh_installdocs fails)

[Santiago Vila]

tags 806655 + patch
thanks

> dh_installdocs
> fromdos debian/*/usr/share/doc/*/*.txt
> fromdos: Unable to access file "debian/*/usr/share/doc/*/*.txt".
> debian/rules:32: recipe for target 'override_dh_installdocs' failed

Explanation: There is only one file in the pattern above:

debian/libzen0v5/usr/share/doc/libzen0v5/ReadMe.txt

but we are creating arch-independent packages only,
so debian/libzen0v5/[...] does not exist because libzen0v5
is arch-dependent.

The trivial fix is to override dh_installdocs only
when creating arch-dependent packages.

Patch follows.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ override_dh_auto_clean:
 override_dh_auto_install:
dh_auto_install -D$(libpath) -B$(builddir)
 
-override_dh_installdocs:
+override_dh_installdocs-arch:
dh_installdocs
fromdos debian/*/usr/share/doc/*/*.txt
 

Bug#806198: siscone: FTBFS when built with dpkg-buildpackage -A (dh_testroot in build-indep)

[Santiago Vila]

tags 806198 + patch
thanks

As explained in the previous message, this is the patch I would apply
if this were my package. Now "dpkg-buildpackage -A" works again.

This is of course a lot better than not working at all, but be careful
because now "dpkg-buildpackage -A" creates a siscone-doc-html package
slightly different than the one it's created without using -A:

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/siscone-doc-html/html/devel/config_8h_source.html

This would be a reproducibility issue for which I don't have a fix
and should probably be reported separately.

In either case, please feel free to close this report after
"dpkg-buildpackage -A" works again.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -54,14 +54,11 @@ clean:
dh_clean
 
 configure-stamp:
-   dh_testdir
dh_autoreconf
dh_auto_configure -- --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
touch $@
 
 doxygen-stamp:
-   dh_testdir
-   dh_testroot
doxygen
touch doxygen-stamp
 

Bug#821343: RM: zotero-standalone-build/4.0.22-1

[Sébastien Villemot]

Le dimanche 17 avril 2016 à 22:21 +0100, Adam D. Barratt a écrit :
> Control: tags -1 + jessie moreinfo
> 
> On Sun, 2016-04-17 at 23:06 +0200, Sébastien Villemot wrote:
> > 
> > Please remove zotero-standalone-build from jessie. The package is
> > affected by
> > two RC bugs (#795343, #788277) which are not easy to address via a
> > minimal
> > patch.
> > 
> > I'll try to provide a backport. In the meantime, packages directly
> > taken from
> > stretch are working fine.
> There's a reverse dependency, which would need addressing:
> 

> Checking reverse dependencies...
> # Broken Depends:
> lyz: xul-ext-lyz

This is a Zotero plugin for LyX. Given that zotero is currently
unusable in jessie, I don't see how xul-ext-lyz could be functional. So
a removal should also be warranted.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594





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

Bug#821345: Please package latest upstream version 1.3.1

[Michael Biebl]

Source: colord
Version: 1.2.12-1
Severity: wishlist

Hi,

gnome-color-manager 3.20 needs colord 1.3.1 or newer.
Would be great if you can update to latest upstream version.

I'm available for sponsoring an upload, if necessary.

Regards,
Michael


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

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

-- no debconf information

Bug#819111: uscan: option for disabling repacking

[Jakub Wilk]

* James McCoy , 2016-04-17, 13:49:
Right, that's not a very intuitive name... Also, I was grepping for 
"repack", not for "mk-origtargz", as the latter is mostly an 
implementation detail.


I agree. Let's find a better description.  Is this agreeable?

  --no-symlink  Don't rename nor repackage upstream tarball by not
calling mk-origtargz.


I think that would be fine if “by not calling mk-origtargz” was 
removed.


Shouldn't it be s/repackage/repack/?

Other than that, it looks good to me.

--
Jakub Wilk

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

[Guillem Jover]

Hi!

On Wed, 2016-03-30 at 08:48:45 +0200, Helmut Grohne wrote:
> On Wed, Mar 30, 2016 at 01:29:15AM +0200, Guillem Jover wrote:
> > > b) Packages that do not "set -u" (nounset), can now prepend $DPKG_ROOT
> > >to any file they operate on. With old versions $DPKG_ROOT will be
> > >unset and with change a) $DPKG_ROOT will be empty. Thus this change
> > >is backwards-compatible.
> > 
> > Right, and these can always be set like ": ${DPKG_ROOT:=}". We could
> > even recommend this as part of some doc/howto/spec for the initial
> > deployments, before packages can assume a recent enough dpkg.
> 
> I like the recommendation, but I note that only about 30 packages employ
> "set -u" (i.e. about 0.1%).

I've added this for now to the wiki spec.

  

> > > c) dpkg should gain a new force flag. I call it --force-remote-configure
> > >for now. It is supposed to force dpkg into running maintainer scripts
> > >without chroot even when the package in question did not declare that
> > >its maintainer scripts support this mode of operation. Note that we
> > >currently have no way to express whether a package supports running
> > >maintainer scripts without chroot. The flag is being added by
> > >0002-add-force-remote-scripts.patch and the behavior is implemented
> > >by 0003-inhibit-chroot-when-force-remote-scripts.patch. Packages can
> > >only reasonably support this mode after implementing b).
> > 
> > I don't quite like the name, as remote to me implies on some other
> > machine. Perhaps foreign, host or extern(al), although some of these
> > are a bit overloaded terms already.
> 
> Of course, I am not attached to the name. I just needed some string that
> remotely made sense. What about "chrootless-configure" to make it
> crystal clear? It should go hand in hand with d) if possible. What is
> your preference?

Hmm, that's always difficult. :) "configure" probably not, as this
involves several maintainer scripts not all of them being configure
related. "chrootless" while quite clear is a bit long, but if there's
nothing better then that does. Things that come to mind perhaps which
are also pretty long, but other proposals welcome:

  maintscript-chrootless
  maintscript-jailbreak
  maintscript-detached

Another option could be to add:

  maintscript-chroot

and make that the default. The problem I can see with this is that it
feels like it is promoting a bit the chrootless case as perhaps safer
or similar.

> > Also I'm not sure this makes sense as a force option (instead of its own
> > proper option), as it is a behavior change that we want to always be safe
> > to use, in contrast to a force option that just forces the behavior.
> > Having a force option that would not chroot some times is a bit
> > strange. We might still want to have both though, and there was a
> > related bug report for that (#614126).
> 
> For the same reasons that you bring forward against making this a force
> option, I think it should be a force option: No package in the archive
> is currently known to be safe to configure from outside the chroot. So
> doing that is inherently unsafe. We generally use force options to do
> unsafe things. I see this force option as a development tool and not as
> switch being used regularly. I think it is similar to --force-depends:
> Proceed even though the package declared that it doesn't support the
> mode of operation. The declaration is the absence of a support field as
> in d). Does this make sense to you?

Yes, but as I mention not as the primary user-facing interface.

> Possibly another switch is needed to enable this feature at all? I
> thought we could just make it default (for supported packages), but
> maybe that has downsides as well.

I don't think this behavior should be made the default, it'd be very
unexpected and can cause issues if the external environment is not
"compliant".

> > > d) Once a) is accepted and b) starts getting implemented, we need to
> > >think about a way for packages to tell that they support "remote
> > >scripts". One way to do so would be to add a header "Remote-Scripts:
> > >yes" to the binary package stanza. Packages thus marked would be
> > >required to honour DPKG_ROOT in all maintainer scripts. This flag
> > >makes no provisions yet on what programs can be assumed to be
> > >installed outside the chroot that is operated on.
> > 
> > Yes, ideally only packages marked as such would get a chroot-less
> > environmemt when requested with the new option, because expecting the
> > user to know when a package supports this mode and on what specific
> > version is a terrible interface IMO, as it requires the user to
> > analyze the .debs before unpacking them.
> 
> This also seems in support of the force option to override.
> 
> > The other thing, that ISTR you brought up on IRC are triggers. I'm not
> > sure how we'd handle those either. :/
> 
> I 

Bug#821343: RM: zotero-standalone-build/4.0.22-1

[Adam D. Barratt]

Control: tags -1 + jessie moreinfo

On Sun, 2016-04-17 at 23:06 +0200, Sébastien Villemot wrote:
> Please remove zotero-standalone-build from jessie. The package is affected by
> two RC bugs (#795343, #788277) which are not easy to address via a minimal
> patch.
> 
> I'll try to provide a backport. In the meantime, packages directly taken from
> stretch are working fine.

There's a reverse dependency, which would need addressing:

Will remove the following packages from stable:

libreoffice-zotero-integration |   4.0.22-1 | all
xul-ext-zotero |   4.0.22-1 | all
zotero-standalone |   4.0.22-1 | all
zotero-standalone-build |   4.0.22-1 | source

Maintainer: Michele Cane 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
lyz: xul-ext-lyz

Dependency problem found.

Regards,

Adam

Bug#821119: Fw: Change build mechanism for sk [ Re: Debian refcard: call to update translations ]

[Holger Wansing]

forward to the bug



Date: Sat, 16 Apr 2016 22:59:11 +0200
From: helix84 
To: Holger Wansing 
Cc: Peter Mann , Debian Sk 

Subject: Re: Debian refcard: call to update translations


Hi Holger,

I looked at accent signs and they are displayed correctly. I looked at
rendering in Acrobat and in the Google Docs viewer and I don't see anything
wrong, either.

I'll try to do the translation update within a week.

Thank you,

Ivan


On Sat, Apr 16, 2016 at 9:32 PM, Holger Wansing 
wrote:

> Hi,
>
> Holger Wansing  wrote:
> > Hi all,
> >
> > We have recently updated the content of Debian refcard for Stretch.
> >
> > Since you are noted as last translator, I would like to ask if you could
> > take the time to update the translation again.
> > For most languages, there is only very few work to do.
>
> I have another request:
>
> I would like to change the build method for the Slovak pdf file.
> Therefore I need a proofread of the new file, to ensure that everything
> is still fine with the pdf, that the fonts are correctly displayed,
> the text is clearly readable etc.
>
> So I have attached the pdf, and would appreciate you to have a look
> at it for checking.
> Thanks
>
>
> Holger



-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#820250: calibre: rebuild against Qt 5.6

[Martin Pitt]

Hello Marc,

Marc J. Driftmeyer [2016-04-06 15:37 -0700]:
> When you have time I would appreciate being able to move a large
> portion of my Qt installation to 5.6.0, but Calibre/Calibre-bin are
> holding everything up with its build depends. The sooner it gets
> rebuilt against Qt 5.6.0 the better.

I am just about to package a new upstream version and checked this,
but Qt 5.6 is only in experimental [1]. Thus it will continue to build
against 5.5 in unstable, until Qt 5.6 gets uploaded to unstable.

Martin

[1] https://tracker.debian.org/pkg/qtbase-opensource-src
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#802621: samba: FTBFS on kfreebsd-*: UnboundLocalError: local variable 'CTDB_SYSTEM_SRC' referenced before assignment

[Steven Chamberlain]

reopen 802621 =
found 802621 samba/4.2.10+dfsg-0+deb8u2
thanks

Hi,

Unfortunately this patch was not included in what security team
uploaded.  It was also not pulled into the +deb8u2 regression update
either.

In the build log below, of samba/4.2.10+dfsg-0+deb8u2 for
jessie-kfreebsd, there is no ctdb-Fix-detection-of-gnukfreebsd.patch

Please could you maybe:
  * revert 
https://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?h=stable-update=e84aab844661db284b58cf6449f25b6e313f30e5
  * import samba/4.2.10+dfsg-0+deb8u2 into Git
(because it seems to have not been committed into VCS yet)
  * bump version number to +deb8u3, re-apply the kfreebsd patch on top
of that, and hopefully it can be included in some future stable,
security or regression update?

In fact... let me do all that for you.  Just pull the top 7 commits of
http://pyro.eu.org/git/?p=samba.git;a=shortlog from repository URI
http://pyro.eu.org/git/samba.git into your stable-update branch
and that's all done.  Pull with --tags and you'll get tags marking
exactly what was in the +deb8u1 and +deb8u2 security uploads.

HTTP-only URI, but the top commit should be
SHA1:1dd10d5ea847d12d733204ff9fc2550ab885968b

Thanks again!

| dpkg-source: info: unpacking samba_4.2.10+dfsg.orig.tar.gz
| dpkg-source: info: unpacking samba_4.2.10+dfsg-0+deb8u2.debian.tar.xz
| dpkg-source: info: applying 05_share_ldb_module
| dpkg-source: info: applying 07_private_lib
| dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
| dpkg-source: info: applying bug_601406_fix-perl-path-in-example.patch
| dpkg-source: info: applying pam-examples.patch
| dpkg-source: info: applying README_nosmbldap-tools.patch
| dpkg-source: info: applying smbclient-pager.patch
| dpkg-source: info: applying usershare.patch
| dpkg-source: info: applying VERSION.patch
| dpkg-source: info: applying waf_smbpasswd_location
| dpkg-source: info: applying add-so-version-to-private-libraries
| dpkg-source: info: applying xsltproc_dont_build_smb.conf.5.patch
| dpkg-source: info: applying heimdal-rfc3454.txt
| dpkg-source: info: applying no_wrapper
| dpkg-source: info: applying ctdb_sockpath.patch
| dpkg-source: info: applying Fix-privacy-breach-on-google.com.patch
| dpkg-source: info: applying decrease-min-ldb-version.patch
| dpkg-source: warning: diff `samba-4.2.10+dfsg/debian/patches/backupkey.patch' 
patches file samba-4.2.10+dfsg/source4/rpc_server/backupkey/dcesrv_backupkey.c 
twice
| dpkg-source: warning: diff `samba-4.2.10+dfsg/debian/patches/backupkey.patch' 
patches file samba-4.2.10+dfsg/source4/rpc_server/backupkey/dcesrv_backupkey.c 
twice
| dpkg-source: warning: diff `samba-4.2.10+dfsg/debian/patches/backupkey.patch' 
patches file samba-4.2.10+dfsg/source4/rpc_server/backupkey/dcesrv_backupkey.c 
twice
| dpkg-source: warning: diff `samba-4.2.10+dfsg/debian/patches/backupkey.patch' 
patches file samba-4.2.10+dfsg/source4/rpc_server/backupkey/dcesrv_backupkey.c 
twice
| dpkg-source: warning: diff `samba-4.2.10+dfsg/debian/patches/backupkey.patch' 
patches file samba-4.2.10+dfsg/source4/rpc_server/backupkey/dcesrv_backupkey.c 
twice
| dpkg-source: info: applying backupkey.patch
| dpkg-source: info: applying fix_pam_smbpass.patch
| dpkg-source: info: applying 
security-2016-04-12-prerequisite-v4-2-regression-fixes.metze01.txt
| dpkg-source: info: applying disable-socketwrapper.diff
| dpkg-source: warning: diff 
`samba-4.2.10+dfsg/debian/patches/sockets-with-htons.patch' patches file 
samba-4.2.10+dfsg/ctdb/common/system_freebsd.c twice
| dpkg-source: warning: diff 
`samba-4.2.10+dfsg/debian/patches/sockets-with-htons.patch' patches file 
samba-4.2.10+dfsg/ctdb/common/system_gnu.c twice
| dpkg-source: warning: diff 
`samba-4.2.10+dfsg/debian/patches/sockets-with-htons.patch' patches file 
samba-4.2.10+dfsg/ctdb/common/system_kfreebsd.c twice
| dpkg-source: warning: diff 
`samba-4.2.10+dfsg/debian/patches/sockets-with-htons.patch' patches file 
samba-4.2.10+dfsg/ctdb/common/system_linux.c twice
| dpkg-source: info: applying sockets-with-htons.patch
| dpkg-source: info: applying unprivate-samba-debug.patch

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#821344: pan doesn't remember all articles after shutdown

[Gary Dale]

Package: pan
Version: 0.140-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Pan crashes before downloading all headers on at least some newsgroups. When it 
does,
it loses the downloaded headers. When I attempted to circumvent this behaviour 
by
stopping the task before it completed, then shutting down and restarting pan, 
the
task vanished, as did all the headers it had downloaded.

   * What exactly did you do (or not do) that was effective (or ineffective)?
The workaround seems to be download only a specific number of days worth of 
headers
until I hit the number that makes pan crash. However this can be a lot of 
headers
so the process can take days, maybe weeks.

   * What outcome did you expect instead?
1) the download all headers task should be restartable after shutting down pan, 
or
2) the download all headers task should save the headers list periodically, or
3) there should be an option to download a range of headers (by date). e.g. 
   download headers from 365 days ago to 730 days ago.

At the very least, pan should remember the headers that were downloaded when the
download all headers task was stopped. These shouldn't vanish after a restart.

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


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/6 CPU cores)
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 pan depends on:
ii  gnome-keyring3.18.3-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-6
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libgcc1  1:5.3.1-14
ii  libgdk-pixbuf2.0-0   2.32.3-2
ii  libglib2.0-0 2.48.0-1
ii  libgmime-2.6-0   2.6.20-1+b1
ii  libgnome-keyring03.12.0-1+b1
ii  libgnutls30  3.4.10-4
ii  libgtk-3-0   3.18.9-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libstdc++6   5.3.1-14
ii  zlib1g   1:1.2.8.dfsg-2+b1

pan recommends no packages.

pan suggests no packages.

-- no debconf information

Bug#821343: RM: zotero-standalone-build/4.0.22-1

[Sébastien Villemot]

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

Dear Release Team,

Please remove zotero-standalone-build from jessie. The package is affected by
two RC bugs (#795343, #788277) which are not easy to address via a minimal
patch.

I'll try to provide a backport. In the meantime, packages directly taken from
stretch are working fine.

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#821334: approx: 'apt-get update' yields 'Err http://approx wheezy-updates/main amd64 Packages'

[Eric Cooper]

Can you please enable debugging for the approx server
(add a "$debug true" line to /etc/approx/approx.conf),
and then send me the relevant part of the log (in /var/log/daemon.log
for example) when this error occurs.  Thanks.

--
Eric Cooper e c c @ c m u . e d u

Bug#821342: xlog: FTBFS: /usr/bin/ld: gui_gtkprintdialog.o: undefined reference to symbol 'trunc@@GLIBC_2.2.5'

[Chris Lamb]

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

Dear Maintainer,

xlog fails to build from source in unstable/amd64:

  [..]

  rm -f build-stamp debian/substvars config.log
  [ ! -f Makefile ] || /usr/bin/make distclean
  dh_clean
rm -f debian/debhelper-build-stamp
rm -f debian/xlog.substvars
rm -f debian/xlog.*.debhelper
rm -rf debian/xlog/
rm -f debian/xlog-data.substvars
rm -f debian/xlog-data.*.debhelper
rm -rf debian/xlog-data/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
find .  \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path 
.\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
 -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
 -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
 -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) 
\)
rm -f *-stamp
   debian/rules build
  dh_testdir
  cp -f /usr/share/misc/config.sub config.sub
  cp -f /usr/share/misc/config.guess config.guess
  CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu 
--build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... no
  checking for mawk... mawk
  checking whether make sets $(MAKE)... yes
  checking whether make supports nested variables... yes
  checking whether to enable maintainer-specific portions of Makefiles... no
  checking for x86_64-linux-gnu-ranlib... x86_64-linux-gnu-ranlib
  checking for style of include used by make... GNU
  checking for x86_64-linux-gnu-gcc... x86_64-linux-gnu-gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables... 
  checking whether we are cross compiling... no
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether x86_64-linux-gnu-gcc accepts -g... yes
  checking for x86_64-linux-gnu-gcc option to accept ISO C89... none needed
  checking whether x86_64-linux-gnu-gcc understands -c and -o together... yes
  checking dependency style of x86_64-linux-gnu-gcc... gcc3
  checking how to run the C preprocessor... x86_64-linux-gnu-gcc -E
  checking for grep that handles long lines and -e... /bin/grep
  checking for egrep... /bin/grep -E
  checking for ANSI C header files... yes
  checking for sys/types.h... yes
  checking for sys/stat.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for memory.h... yes
  checking for strings.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for unistd.h... yes
  checking sys/ipc.h usability... yes
  checking sys/ipc.h presence... yes
  checking for sys/ipc.h... yes
  checking sys/shm.h usability... yes
  checking sys/shm.h presence... yes
  checking for sys/shm.h... yes
  checking for strptime... yes
  checking for strptime declaration in time.h... no
  checking for strchr... yes
  checking for index... yes
  checking for x86_64-linux-gnu-pkg-config... 
/usr/bin/x86_64-linux-gnu-pkg-config
  checking pkg-config is at least version 0.9.0... yes
  checking for GLIB... yes
  checking for GTK... yes
  checking for HAMLIB... yes
  checking for update-mime-database... /usr/bin/update-mime-database
  checking for update-desktop-database... no
  checking for a sed that does not truncate output... /bin/sed
  checking whether NLS is requested... yes
  checking for msgfmt... /usr/bin/msgfmt
  checking for gmsgfmt... /usr/bin/msgfmt
  checking for xgettext... /usr/bin/xgettext
  checking for msgmerge... /usr/bin/msgmerge
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking for ld used by x86_64-linux-gnu-gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for shared library run path origin... done
  checking for CFPreferencesCopyAppValue... no
  checking for CFLocaleCopyCurrent... no
  checking for GNU gettext in libc... yes
  checking whether to use NLS... yes
  checking where the gettext function comes from... libc
  disabled updating of the mime database
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: creating po/Makefile.in
  config.status: creating m4/Makefile
  config.status: creating Makefile
  

Bug#819282: wheezy-pu: package openldap/2.4.31-2+deb7u2

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sun, 2016-04-17 at 13:22 -0700, Ryan Tandy wrote:
> On Wed, Apr 13, 2016 at 09:30:13PM +0100, Adam D. Barratt wrote:
> >Does a significant portion of the testsuite fail, or only a small part?
> 
> Exactly one third of it: the same suite is run once for each of the backends 
> built, namely bdb, hdb, and mdb. The page size issue renders mdb totally 
> non-functional under the newer kernel.
> 
> >If the latter, is it possible to only disable the affected tests?
> 
> Actually, yes. Improved debdiff below; and sorry for not thinking of this 
> myself.

Thanks; that looks fine to me.

Regards,

Adam

Bug#821341: debian-installer: unbootable, no gpt partition for uefi install

[josh]

Package: debian-installer
Severity: important

After installation system was not bootable.

During the installation it said that it had detected that I had UEFI
booted the installation CD and proposed to make an EFI boot partion
which I accepted. However, after installation, Debian wasn't bootable.

I tracked the problem down to the fact that even though it said it was
installing a UEFI bootable system, the hard drive was still partitioned
with an MBR, which is not UEFI boot compatible. There seemed to be no
option for selecting/forcing gpt partitioning.

Using a rescue cd and converting the MBR to a gpt and then reinstalling
grub-uefi solved the problem without having to reinstall the system.

It would seem to me that if the installer detects an uefi booted system
and is installing an efi boot partition then it should automatically
partition with a gpt and not an mbr.


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

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.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#745094: closed by Andreas Beckmann <a...@debian.org> (Bug#745094: fixed in uqm 0.6.2.dfsg-9.2)

[Stephen Kitt]

Control: reopen -1
Control: notfixed uqm/0.6.2.dfsg-9.2

On Sun, 17 Apr 2016 17:21:08 +, ow...@bugs.debian.org (Debian Bug
Tracking System) wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:uqm package:
> 
> #745094: uqm: Please build-depend on libmikmod-dev instead of libmikmod2-dev
> 
> It has been closed by Andreas Beckmann .

Unfortunately the fix is incomplete; as mentioned in the original bug report,
uqm needs to either build-depend on libmikmod-config in addition to
libmikmod-dev, or switch to using pkg-config. The patch attached to the
original bug report implements the latter.

Regards,

Stephen


pgpEhKGptJLQ4.pgp
Description: OpenPGP digital signature

Bug#819282: wheezy-pu: package openldap/2.4.31-2+deb7u2

[Ryan Tandy]

On Wed, Apr 13, 2016 at 09:30:13PM +0100, Adam D. Barratt wrote:

Does a significant portion of the testsuite fail, or only a small part?


Exactly one third of it: the same suite is run once for each of the backends 
built, namely bdb, hdb, and mdb. The page size issue renders mdb totally 
non-functional under the newer kernel.


If the latter, is it possible to only disable the affected tests?


Actually, yes. Improved debdiff below; and sorry for not thinking of this 
myself.

(The diff doesn't have as much context as I'd like: the debian/rules addition 
is just appended to the end of the file.)

As before:
- built locally on amd64, verified all three test suites were run
- built on the powerpc porterbox (partch), verified bdb and hdb test suites 
were run but not mdb
- tested amd64 binaries in a clean wheezy chroot
- tested powerpc binaries in a qemu VM running wheezy (all backends)

thanks,
Ryan
diff -u openldap-2.4.31/debian/rules openldap-2.4.31/debian/rules
--- openldap-2.4.31/debian/rules
+++ openldap-2.4.31/debian/rules
@@ -174,0 +175,6 @@
+
+# Avoid running back-mdb tests on ppc64 builders
+ifeq ($(DEB_HOST_ARCH),powerpc)
+override_dh_auto_test:
+   dh_auto_test -- BUILD_MDB=no
+endif
diff -u openldap-2.4.31/debian/changelog openldap-2.4.31/debian/changelog
--- openldap-2.4.31/debian/changelog
+++ openldap-2.4.31/debian/changelog
@@ -1,3 +1,11 @@
+openldap (2.4.31-2+deb7u2) wheezy; urgency=medium
+
+  * Disable the back-mdb test suite on powerpc to work around back-mdb tests
+failing on buildds running the jessie ppc64 kernel, which uses 64KB pages.
+(ITS#7713)
+
+ -- Ryan Tandy   Thu, 14 Apr 2016 20:55:33 -0700
+
 openldap (2.4.31-2+deb7u1) wheezy-security; urgency=high
 
   * Non-maintainer upload by the Security Team.

Bug#821340: debian installer bug: doesn't partition with gpt for uefi install

[josh]

Package: installation-reports

Boot method: CD
Image version: 8.3 amd64 netinstall
Date: March 2016

Machine: custom built
Processor: amd A10 7850k
Memory: 8gb
Partitions: 

pax:/home/josh# df -Tl
FilesystemType  1K-blocks  Used Available Use%
Mounted on
/dev/sda7 ext4 1042041924 170045856 861391824  17% /
udev  devtmpfs  10240 0 10240   0% /dev
tmpfs tmpfs   1410916  9480   1401436   1% /run
tmpfs tmpfs   3527288  1516   3525772   1% /dev/shm
tmpfs tmpfs  5120 4  5116   1% /run/lock
tmpfs tmpfs   3527288 0   3527288   0%
/sys/fs/cgroup
/dev/sda1 vfat 191551 22685168867  12% /boot/efi
/dev/mapper/_dev_sda5 ext4  216143892  62152000 153975508  29%
/home/josh
tmpfs tmpfs70546024705436   1%
/run/user/1000
/dev/mapper/_dev_sda6 ext4  168082544  30673920 137392240  19%
/home/heike
tmpfs tmpfs70546012705448   1%
/run/user/1001



Output of lspci -knn (or lspci -nn):
pax:/home/josh# lspci -knn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family
15h (Models 30h-3fh) Processor Root Complex [1022:1422]
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Family 15h
(Models 30h-3fh) I/O Memory Management Unit [1022:1423]
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f]
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: radeon
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
Kaveri HDMI/DP Audio Controller [1002:1308]
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: snd_hda_intel
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1424]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1424]
00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h
(Models 30h-3fh) Processor Root Port [1022:1426]
Kernel driver in use: pcieport
00:03.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h
(Models 30h-3fh) Processor Root Port [1022:1426]
Kernel driver in use: pcieport
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1424]
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB XHCI Controller [1022:7814] (rev 09)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: xhci_hcd
00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB XHCI Controller [1022:7814] (rev 09)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: xhci_hcd
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH
SATA Controller [AHCI mode] [1022:7801] (rev 40)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: ahci
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB OHCI Controller [1022:7807] (rev 11)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: ohci-pci
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB EHCI Controller [1022:7808] (rev 11)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: ehci-pci
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB OHCI Controller [1022:7807] (rev 11)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: ohci-pci
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH
USB EHCI Controller [1022:7808] (rev 11)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: ehci-pci
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:780b] (rev 16)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
Kernel driver in use: piix4_smbus
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH
Azalia Controller [1022:780d] (rev 01)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:d721]
Kernel driver in use: snd_hda_intel
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:780e] (rev 11)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI
Bridge [1022:780f] (rev 40)
00:14.5 USB controller 

Bug#821339: ITP: haproxy-log-analysis -- generate aggregate statistics from HAProxy HTTP logs

[Christopher Baines]

Package: wnpp
Severity: wishlist
Owner: Christopher Baines 

* Package name: haproxy-log-analysis
  Version : 2.0~a0
  Upstream Author : Gil Forcada 
* URL : https://github.com/gforcada/haproxy_log_analysis
* License : GPL-3
  Programming Lang: Python
  Description : generate aggregate statistics from HAProxy HTTP logs

haproxy log analysis can generate aggregate statistics from HAProxy logs
in the HTTP log format. This can be over a specific period, or over a
subset of the entries by specifying a filter.

I intend to maintain this package as part of the Debian Python Modules Team.



signature.asc
Description: OpenPGP digital signature

Bug#821119: [debian-refcard] change build mechanism to improve layout for cs, el and sk

[Holger Wansing]

Hi,

"W. Martin Borgert"  wrote:
> On 2016-04-15 20:10, Holger Wansing wrote:
> > When building the pdfs with
> > make USE_DBLATEX=2 refcard-XX-a4.pdf
> > (this means using dblatex instead of xmlroff) I get a pdf with a correct 
> > copyright notice, coloured URLs and better usage of the available space 
> 
> Note, that when I started the refcard, I tried four different
> toolchains: dblatex, docbook2latex(?), fop, and xmlroff. I don't
> remember now, but neither docbook2latex nor fop did work well
> for this usecase. Depending on the language I had acceptable
> results with dblatex or xmlroff. Unfortunately, both dblatex
> and xmlroff are more or less "one person projects". While
> xmlroff had no further development since many years, dblatex is
> alive and kicking, integrating patches from others and getting
> better with every release.
> 
> Maybe it is time to focus on only one tool, dblatex, and fix
> remaining issues with it?

The intend to change cs, el and sk to use dblatex is a step in exactly
that direction then :-)

That would leave only ar, he, hi, ja, zh_CN and zh_TW for xmlroff.
And for that languages I am unable to build promising results with
dblatex, at least with the actual buildchain.

And more aggressive changes on the buildchain are probably out of my
skills. 
However the Hebrew translator has already volunteered on working to 
improve the build for he, so maybe there is a chance for some 
improvement for he, if not for other languages as well.



Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#821280: refcard: updated french translation

[Baptiste Jammet]

Hi,

Dixit Holger Wansing, le 17/04/2016 :

>I have built the french pdfs, and I see no grave problems.
>PDFs attached.
>
>Could you please have a look?

The pdf looks fine. I think I don't have the exact same buildchain
locally.
There is only the window title that is wrong, I think something with
encoding (there is strange characters istead of "é" and non-breakable
space), but the old one had the same problem.

Thanks.

Baptiste


pgpVj8hKSzAal.pgp
Description: OpenPGP digital signature

Bug#821319: aisleriot: sol Segmentation Fault

[Josh Triplett]

Package: aisleriot
Version: 1:3.18.2-1
Followup-For: Bug #821319
Control: retitle -1 sol segmentation fault after upgrading libgtk-3-0 to 
3.20.3-1

I managed to narrow down the cause of this bug.  I noticed that it
occurred after upgrading several GNOME and GTK+ packages to the latest
versions in sid, including libgtk-3-0.  I downgraded libgtk-3-0 back to
3.18.9-1 from testing (along with various associated packages that
depended on the new version), and sol stopped segfaulting.  I then
upgraded *only* libgtk-3-0 and libgail-3-0 (which has an exact version
dependency) to 3.20.3-1, and sol started segfaulting again.

- Josh Triplett

Bug#811393: Another try at flint-arb sponsoring

[Julien Puydt]

Hi,

quite some time ago, Gianfranco wrote:

> something needs changes:
>
> - std-version is now 3.9.7

Done.

> - unsecure VCS fields

Done.

> - call ldconfig in rules? what?

Uh... removed.

> - changing names usually is just bad, people won't find the package, 
> and you will diverge from upstream.

>
> do you have any good rationale?

The rationale is that there is already a libarb in Debian, which has 
nothing to do with flint's ARB... so I'm trying to make sure there is no 
name conflict.


> - do you pass --parallel twice? (I mean in build)

Uh... fixed.

> - what about dh_auto_configure -- (FLAGS) instead of ./configure?
> (I think the build fails for "unknown parameters, right?"

Bad idea: dh_auto_configure will think it's an autotools configure 
script, which it isn't.


> - they have a Makefile.in, but no configure.ac.
> please ask them to include it, and do autoreconf before building
> (Probably they are not using autotools but they just like similar and 
> confusing names)


Yes, they're using autotools-like names with hand-made stuff. Which is 
why I have to do some flag injection by hand.


> - copyrights missing, e.g. Tommy Hofmann, Arb, FSFa
> licenses looks good to me

I gave another try at getting copyrights right.

> check-all-the-things:
> codespell --quiet-level=3
> flawfinder -Q -c .
> cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find 
> or open any of the paths given.'

> [lots]

Uh... isn't that something more for upstream than for me?

> # You should almost never use -m64 and -m32 when compiling.
> $ grep -rE -- '-m64|-m32' .
> ./configure:   ABI_FLAG="-m32"
> ./configure:   ABI_FLAG="-m64"

See above : upstream has its own build system...

> $ pep8 --ignore W191 .

That's for upstream, isn't it?

> pyflakes{,3}

Again, that's for upstream.

> ./doc/source/_static/arbtext.pdf
> ./doc/source/_static/arbtext.eps
>
> maybe recreate during build?

Hmmm... the source appears to be the .svg ; I don't think I ship it in 
the -doc package, so I don't think I should care. I'm not sure I'm eager 
to put my hand in their doc-building yet...


> Please add some upstream metadata: 
https://wiki.debian.org/UpstreamMetadata


Looks overkill at that point.


> and the other stuf LGTM
(you shouldn't address all the above, something is just nice to have)

I put up a new version both on git :

Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/flint-arb.git
Vcs-Git: 
https://anonscm.debian.org/git/debian-science/packages/flint-arb.git


and on mentors.d.n :
http://mentors.debian.net/package/flint-arb
dget -x 
http://mentors.debian.net/debian/pool/main/f/flint-arb/flint-arb_2.8.1-1.dsc


Cheers,

Snark on #debian-science

Bug#726661: login fails with pam_loginuid(sshd:session): set_loginuid failed

[Evgeni Golov]

Ohai²,

On Sun, Apr 17, 2016 at 09:03:57PM +0200, Evgeni Golov wrote:
> I can reproduce this bug on a Debian Jessie system with LXC 2.0 (from 
> Stretch).
> 
> Host: jessie with systemd as pid1, lxc and lxcfs from stretch
> Guest: jessie with sysvinit as pid1 (systemd gives me headaches in containers 
> yet)

Also with Stretch/systemd as guest.

> There are PAM patches at [1][2][3], maybe they just need backporting to 
> Jessie?
> 
> [1] 
> https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=5825450540e6620ac331c64345b42fdcbb1d6e87
> [2] 
> https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=24f3a88e7de52fbfcb7b8a1ebdae0cdbef420edf
> [3] 
> https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a

[3] is missing from src:pam/debian/patches-applied/pam-loginuid-in-containers
Ubuntu has it backported at [4].

I think the following should be done (but I am unsure that's the only failure 
here, so maybe rather a clone? - I'll let the openssh maintainers decide)
reassign -1 libpam-modules
retitle -1 pam_loginuid fails in unprivileged containers
found -1 1.1.8-3.1+deb8u1
found -1 1.1.8-3.2
tags -1 + patch

Greets
Evgeni

[4] 
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pam/wily/view/head:/debian/patches-applied/pam-loginuid-in-containers

Bug#805083: polygraph: FTBFS: SSlv3 method

[Sebastian Andrzej Siewior]

On 2015-11-16 08:19:36 [-0700], Alex Rousskov wrote:
> On 11/14/2015 09:02 AM, Alex Rousskov wrote:
> 
> > If we can provide a small better fix, we will. If a better fix requires
> > too many unrelated changes to this Polygraph version, we will provide a
> > patch that disables SSLv3 (until a recent Polygraph version with a
> > comprehensive fix is released).
> 
> The attached patch allows Polygraph to be built with OpenSSL that does
> not support SSLv3 while preserving legacy functionality for those who
> need it.

Current 4.9.0 version still has the problem. Any reason why I should not NMU
it? Alex in case you need a sponsor then I could help with that.

> HTH,
> 
> Alex.

Sebastian

Bug#821338: win32-loader crashing in win7 x64 OEM version

[Pavel Veselý]

Package: win32-loader
Version:  0.7.8





description of the failure:




I have Windows 7 SP1 OEM version, x64, Business Premium version, Czech 
language, installed on my laptop, and mingw or cygwin were never installed 
in this computer previously. When I tried to start Debian installation via 
win32-loader, the program always has crashed with the universal win message 
(stop/try to debug). 




win32-loader.exe, package version via Windows Explorer:

version of file: 2015.4.27.1250, version of product 0.7.8+deb8u1 +net +pxe, 
date of change 2016-04-15 23:39, language English

The file was downloaded from the http://goodbye-microsoft.com/
(http://goodbye-microsoft.com/) today.




I have  tried  to debug the crash via Visual Studio 2010, with this report: 

"Unhandled exception at 0x69281559 in win32-loader.exe: 0xC005: Access 
violation reading location 0x000b."

Call Stack location: "> string.dll!69281559()  "





Then I have debugged the program under OllyDebugger version 2 (OllyDbg2) 
with this additional information acquired:




---


CPU Disasm
Address   Hex dump  Command  
Comments
69281559    8078 0B 3A  CMP BYTE PTR DS:[EAX+0B],3A


CPU - main thread, module string

EAX 
ECX 6928402A ASCII "partition="
EDX 6170
EBX 0028E798
ESP 0028E788
EBP 0028F7A0
ESI 00411840 ASCII "bcdedit_extract_partition"
EDI 69281512 string.bcdedit_extract_partition
EIP 69281559 string.69281559

C 0  ES 002B 32bit 0()
P 1  CS 0023 32bit 0()
A 0  SS 002B 32bit 0()
Z 1  DS 002B 32bit 0()
S 0  FS 0053 32bit 7EFDD000(FFF)
T 0  GS 002B 32bit 0()
D 0
O 0  LastErr 007E ERROR_MOD_NOT_FOUND
EFL 00010246 (NO,NB,E,BE,NS,PE,GE,LE)

ST0 empty 0.0
ST1 empty 0.0
ST2 empty 0.0
ST3 empty 0.0
ST4 empty 0.0
ST5 empty 0.0
ST6 empty 0.0625000 CONST 1/16.
ST7 empty 0.0
   3 2 1 0  E S P U O Z D I
FST 0120  Cond 0 0 0 1  Err 0 0 1 0 0 0 0 0 (LT)
FCW 027F  Prec NEAR,53  Mask    1 1 1 1 1 1
Last cmnd 0023:76AA99E9 GDI32.76AA99E9

XMM0    
XMM1    
XMM2    
XMM3    
XMM4    
XMM5    
XMM6    
XMM7 006F0072 00630069 004D 
    P U O Z D I
MXCSR 1F80  FZ 0 DZ 0  Err  0 0 0 0 0 0
    Rnd NEAR   Mask 1 1 1 1 1 1


CPU Stack
Address   Value  ASCII Comments
0028E768     
0028E76C   0028E9C4  ��(.
0028E770   FEEEFEEE  
0028E774   004F  ..O.
0028E778   00411840  @ A.  ; ASCII "bcdedit_extract_partition"
0028E77C   0028E798  ��(.
0028E780   69281512  (i  ; string.bcdedit_extract_partition
0028E784   69281559  Y (i  ; RETURN from msvcrt.7742DE4A to string.69281559
0028E788  /0028E798  ��(.
0028E78C  |6928402A  *@(i(mailto:*@(i)  ; ASCII "partition="
0028E790  |0055CA50  P�U.
0028E794  |03F8  � ..
0028E798  |615A0A0D  ..Za
0028E79C  |D864A076  v�d�
0028E7A0  |7020A163  c� p
0028E7A4  |72676F72  rogr
0028E7A8  |70206D61  am p
0028E7AC  |73206F72  ro s
0028E7B0  |E7756F70  pou�
0028E7B4  |A16ED874  t�n�
0028E7B8  |73797320   sys
0028E7BC  |756D8274  t�mu
0028E7C0  |6E695720   Win
0028E7C4  |73776F64  dows





--




I am not able to start the program under Administrator privileges, with 
antivirus and firewall from Comodo disabled.




I have not read some special recommendation in the documentation as for 
limits of some concrete Windows system  installation, software 
incompatibility or something similar. 

Nevertheless, it is all maybe my mistake. Suggestions, please? 




Thanks in advance, with regards Pavel

Bug#821280: refcard: updated french translation

[Holger Wansing]

Control: tags -1 + pending


Baptiste Jammet  wrote:
> Package: refcard
> Tags: l10n, patch
> Severity: wishlist
> 
> Hi,
> 
> Please find attached the updated french translation for refcard,
> proofread by the french localisation team.

committed.


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#821336: RM: gcc-4.8 -- ROM; obsolete GCC version

[Matthias Klose]

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

Not used any more as build dependency.

Bug#749354: isakmpd: FTBFS - cannot open /../../Makefile

[Sebastian Andrzej Siewior]

Hi,

The patch looks simple. Any reason why I should not use it and NMU it isakmpd?
It would make isakmpd build again and we would have one libssl1.0.0 user less.

Sebastian

Bug#821337: FTBFS on mipsel(64), gtk+3.0-3.20.3/testsuite/reftests/button-wrapping.ui: FAIL

[Michael Biebl]

Source: gtk+3.0
Version: 3.20.3-1
Severity: serious

The package FTBFS on mips(el).
The test-suite on fails in gtk-reftest, specifically

gtk+3.0-3.20.3/testsuite/reftests/button-wrapping.ui: FAIL

This seems to happen reproducibly, also on porterboxes (tried on etler).
I haven't further investigated this yet, if anyone wants to work on
that, this would be great.

Michael

[1] https://buildd.debian.org/status/package.php?p=gtk%2B3.0=sid
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#821335: repro: documentation/setup file create_postgresql_reprodb.sql missing

[Andreas B. Mundt]

Package: repro
Version: 1:1.10.0-1~bpo8+1
Severity: minor

Hi,

the file 'create_postgresql_reprodb.sql' seems to be missing in the 
Debian package in '/usr/share/doc/repro/'.

Thanks and best regards,

Andi


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

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

Versions of packages repro depends on:
ii  adduser3.113+nmu3
ii  libc-ares2 1.10.0-2
ii  libc6  2.19-18
ii  libdb5.3++ 5.3.28-9
ii  libfreeradius-client2  1.1.6-7
ii  libgcc11:4.9.2-10
ii  libmysqlclient18   5.5.43-0+deb8u1
ii  libpq5 9.4.6-0+deb8u1
ii  libpython2.7   2.7.9-2
ii  libresiprocate-1.101:1.10.0-1~bpo8+1
ii  libssl1.0.01.0.1k-3
ii  libstdc++6 4.9.2-10
ii  multiarch-support  2.19-18
ii  openssl1.0.1k-3

Versions of packages repro recommends:
ii  apache2-utils   2.4.10-10+deb8u4
ii  ejabberd [turn-server]  16.02-2~bpo8+1

Versions of packages repro suggests:
pn  jscommunicator-web-phone  

-- Configuration Files:
/etc/repro/repro.config changed:
LoggingType = syslog
SyslogFacility = LOG_DAEMON
LogLevel = DEBUG
LogFilename = /var/log/repro/repro.log
LogFileMaxBytes = 0
EnableSipMessageLogging = false
IPAddress =
UDPPort = 5060
TCPPort = 5060
TLSPort = 0
WSPort = 0
 
WSSPort = 0
DTLSPort = 0
TLSDomainName =
TLSCertificate = 
TLSPrivateKey = 
TLSPrivateKeyPassPhrase =
TLSClientVerification = None
TLSConnectionMethod = SSLv23
TLSUseEmailAsSIP = false
TlsDHParamsFilename = /etc/repro/dh2048.pem
DNSServers =
EnableIPv6 = true
DisableIPv4 = false
HttpBindAddress = 127.0.0.1, ::1
HttpPort = 5080
DisableHttpAuth = false
HttpAdminRealm = repro
HttpAdminUserFile = /etc/repro/users.txt
CommandBindAddress = 127.0.0.1, ::1
CommandPort = 5081
RegSyncPort = 0
RemoteRegSyncPort = 0
RegSyncPeer =
EnablePublicationRepication = true
TCPConnectionGCAge = 7200
RunAsUser = repro
RunAsGroup = repro
Daemonize = true
PidFile = /var/run/repro/repro.pid
CADirectory = /etc/ssl/certs
CertificatePath =
DefaultDatabase = 1
Database1Type = BerkeleyDB
Database1Path = /var/lib/repro/
SessionAccountingEnabled = false
SessionAccountingAddRoutingHeaders = false
SessionAccountingAddViaHeaders = false
RegistrationAccountingEnabled = false
RegistrationAccountingAddRoutingHeaders = false
RegistrationAccountingAddViaHeaders = false
RegistrationAccountingLogRefreshes = false
EnableCertServer = false
CongestionManagement = true
CongestionManagementMetric = WAIT_TIME
CongestionManagementTolerance = 200
StatisticsLogInterval = 3600
ThreadedStack = true
NumAuthGrabberWorkerThreads = 2
NumAsyncProcessorWorkerThreads = 2
Domains =
RecordRouteUri =
ForceRecordRouting = false
AssumePath = false
DisableRegistrar = false
EnablePresenceServer = true
PresenceUsesRegistrationState = false
PresenceNotifyClosedStateForNonPublishedUsers = true
EnumSuffixes =
EnumDomains = 
TimerC = 180
TimerT1 = 0
TCPConnectTimeout = 0
DisableOutbound = true
OutboundVersion = 5626
AssumeFirstHopSupportsOutbound = false
EnableFlowTokens = false
ClientNatDetectionMode = DISABLED
FlowTimer = 0
AlwaysAllowRelaying = false
NeverStripProxyAuthorizationHeaders = false
EnableCertificateAuthenticator = false
DisableAuth = false
StaticRealm =
HttpHostname =
DisableIdentity = false
EnablePAssertedIdentityProcessing = false
DisableAuthInt = true
RejectBadNonces = false
AllowBadReg = false
DisableRequestFilterProcessor = false
RequestFilterDefaultNoMatchBehavior =
RequestFilterDefaultDBErrorBehavior = 500, Server Internal DB Error
Routes =
ParallelForkStaticRoutes = false
ContinueProcessingAfterRoutesFound = false
ChallengeThirdPartiesCallingLocalDomains = false
MessageSiloEnabled = false
MessageSiloDestFilterRegex =
MessageSiloMimeTypeFilterRegex = application\/im\-iscomposing\+xml
MessageSiloExpirationTime = 2592000
MessageSiloAddDateHeader = true
MessageSiloMaxContentLength = 4096
MessageSiloSuccessStatusCode = 202
MessageSiloFilteredMimeTypeStatusCode = 200
MessageSiloFailureStatusCode = 480
RecursiveRedirect = false
GeoProximityTargetSorting = false
GeoProximityIPv4CityDatabaseFile = GeoLiteCity.dat
GeoProximityIPv6CityDatabaseFile =
GeoProximityRequestUriFilter = ^sip:mediaserver.*@mydomain.com$
GeoProximityDefaultDistance = 0
LoadBalanceEqualDistantTargets = true
QValue = true
QValueBehavior = EQUAL_Q_PARALLEL
QValueCancelBetweenForkGroups = true
QValueMsBeforeCancel = 3
QValueWaitForTerminateBetweenForkGroups = true
QValueMsBetweenForkGroups = 3000


-- no debconf information

Bug#821255: sane-backends: saned option to report network-attached devices

[Jörg Frings-Fürst]

Hello Dhionel,

Thank you for spending your time helping to make Debian better with
this bug report. 

I have check your patch. It looks good, so I add them to the next
release.

Many thanks !!

Cu
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#821183: [Pkg-samba-maint] Bug#821183: winbind: wbinfo -u is empty, wbinfo -g returns groups with samba as DC, ldap_search_with_timeout timeout

[Andrew Bartlett]

On Sun, 2016-04-17 at 11:19 +0200, John Wyzer wrote:
> On 17/04/16 07:16, Andrew Bartlett wrote:
> > > I have samba installed as a domain controller.
> > 
> > Which Samba version is on the DC?
> 4.3.3
> 
> >  Does dbcheck pass on the DC?
> > samba-tool dbcheck --cross-ncs
> 
> Yes. Without any error messages.
> 
> > How many users do you have?
> Only about 95.
> 

It would be really helpful to isolate the client from the server here. 
 Can you take a network sniff with wireshark, find the failing query,
and re-issue it with ldbsearch?  That way we can hopefully remove
winbindd from the equation.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#806046: horgand: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806046 + patch
thanks

>debian/rules override_dh_install
> make[1]: Entering directory '/<>'
> dh_install
> cp debian/horgand.wrapper /<>/debian/horgand/usr/bin/horgand
> cp: cannot create regular file 
> '/<>/debian/horgand/usr/bin/horgand': No such file or directory
> debian/rules:10: recipe for target 'override_dh_install' failed

Explanation: We are creating arch-independent packages only,
so debian/horgand/[...] does not exist because "horgand" is
arch-dependent.

The trivial fix is to override dh_install only when creating
arch-dependent packages.

Patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@
 override_dh_auto_configure:
dh_auto_configure -- --bindir=/usr/lib/horgand
 
-override_dh_install:
+override_dh_install-arch:
dh_install
cp debian/horgand.wrapper $(CURDIR)/debian/horgand/usr/bin/horgand
chmod 755 $(CURDIR)/debian/horgand/usr/bin/horgand

Bug#821334: approx: 'apt-get update' yields 'Err http://approx wheezy-updates/main amd64 Packages'

[David Christensen]

Package: approx
Version: 5.3-1
Severity: normal

Dear Maintainer,

Apt and/or Approx are having trouble fetching packages for
'wheezy-updates'.


Without Approx, Apt is happy:

# cat /etc/apt/sources.list
deb http://ftp.us.debian.org/debian wheezy  main
deb-src http://ftp.us.debian.org/debian wheezy  main
deb http://ftp.us.debian.org/debian wheezy-updates  main
deb-src http://ftp.us.debian.org/debian wheezy-updates  main
deb http://security.debian.org/ wheezy/updates  main
deb-src http://security.debian.org/ wheezy/updates  main

2016-04-17 11:59:52 root@cd2533 /etc/apt
# apt-get update
Get:1 http://ftp.us.debian.org wheezy Release.gpg [2373 B]  
Get:2 http://security.debian.org wheezy/updates Release.gpg [1554 B]
Get:3 http://ftp.us.debian.org wheezy-updates Release.gpg [1554 B]
Get:4 http://security.debian.org wheezy/updates Release [102 kB]
Get:5 http://ftp.us.debian.org wheezy Release [191 kB]
Get:6 http://security.debian.org wheezy/updates/main Sources [212 kB]
Get:7 http://ftp.us.debian.org wheezy-updates Release [151 kB]
Get:8 http://ftp.us.debian.org wheezy/main Sources [5984 kB]  
Get:9 http://security.debian.org wheezy/updates/main amd64 Packages [347 kB] 
Get:10 http://security.debian.org wheezy/updates/main Translation-en [202 kB]  
Get:11 http://ftp.us.debian.org wheezy/main amd64 Packages [5838 kB]   
Get:12 http://ftp.us.debian.org wheezy/main Translation-en [3846 kB]   
Get:13 http://ftp.us.debian.org wheezy-updates/main Sources [5516 B]   
Get:14 http://ftp.us.debian.org wheezy-updates/main amd64 Packages [7056 B]
Get:15 http://ftp.us.debian.org wheezy-updates/main Translation-en [4879 B]
Fetched 16.9 MB in 29s (579 kB/s)  
Reading package lists... Done


But with Approx, Apt is not happy:

2016-04-17 12:00:58 root@cd2533 /etc/apt
# cat /etc/apt/sources.list
deb http://approx:/debian   wheezy  main
deb-src http://approx:/debian   wheezy  main
deb http://approx:/debian   wheezy-updates  main
deb-src http://approx:/debian   wheezy-updates  main
deb http://approx:/security wheezy/updates  main
deb-src http://approx:/security wheezy/updates  main

2016-04-17 12:01:02 root@cd2533 /etc/apt
# grep -v '#' /etc/approx/approx.conf

debian  http://ftp.debian.org/debian
securityhttp://security.debian.org/debian-security



2016-04-17 12:01:14 root@cd2533 /etc/apt
# apt-get update
Get:1 http://approx wheezy Release.gpg [2373 B]
Get:2 http://approx wheezy-updates Release.gpg [1554 B]
Get:3 http://approx wheezy/updates Release.gpg [1554 B]
Get:4 http://approx wheezy Release [191 kB]
Get:5 http://approx wheezy-updates Release [151 kB]
Get:6 http://approx wheezy/updates Release [102 kB]
Get:7 http://approx wheezy/main Translation-en [3846 kB]
Get:8 http://approx wheezy-updates/main Translation-en [4879 B]
Get:9 http://approx wheezy/updates/main Translation-en [202 kB]
Get:10 http://approx wheezy/main Sources [7529 kB]  
Get:11 http://approx wheezy/main amd64 Packages [7635 kB]
Get:12 http://approx wheezy-updates/main Sources [5651 B]  
Get:13 http://approx wheezy/updates/main Sources [270 kB]
Get:14 http://approx wheezy/updates/main amd64 Packages [438 kB]   
Err http://approx wheezy-updates/main amd64 Packages   
  
Get:15 http://approx wheezy-updates/main amd64 Packages [7475 B]   
Fetched 20.4 MB in 9s (2049 kB/s)  
Reading package lists... Done


Perhaps the hyphen '-' in 'wheezy-updates' has something to do with
the error (?).


As a work-around, I can use Approx for 'wheezy' and 'wheezy/updates'
only:

2016-04-17 12:07:26 root@cd2533 /etc/apt
# grep -v '#' /etc/apt/sources.list
deb http://approx:/debian   wheezy  main
deb-src http://approx:/debian   wheezy  main
deb http://approx:/security wheezy/updates  main
deb-src http://approx:/security wheezy/updates  main


deb http://ftp.us.debian.org/debian wheezy-updates  main
deb-src http://ftp.us.debian.org/debian wheezy-updates  main

2016-04-17 12:07:35 root@cd2533 /etc/apt
# apt-get update
Hit http://approx wheezy Release.gpg
Hit http://approx wheezy/updates Release.gpg   
Hit http://approx wheezy Release   
Hit http://approx wheezy/updates Release 
Get:1 http://ftp.us.debian.org wheezy-updates Release.gpg [1554 B]   
Get:2 http://ftp.us.debian.org wheezy-updates Release [151 kB]
Hit http://approx wheezy/main Translation-en 
Get:3 http://ftp.us.debian.org wheezy-updates/main Sources [5516 B]  

Bug#821333: snapshot.debian.org: should advertise source-specific [check-valid-until=false] in preference to system-wide flag

[ydirson]

Package: snapshot.debian.org
Severity: important

Advertised "-o Acquire::Check-Valid-Until=false" will impact all sources, and 
using it
just suspends the protection, potentially leaving the user susceptible to 
attacks.

Using "deb [check-valid-until=false] http://snapshot.debian.org/archive/...; 
achieves
the intended purpose, without the big downfall of the old solution.

Bug#758888: lmms: Provide links to LADSPA plugins in /usr/lib/ladspa

[Javier Serrano Polo]

Here it is the discussion:
https://github.com/LMMS/lmms/issues/2731

We do not get any compromise about a stable set of standardized plugins.
There is no point in sharing the plugins from LMMS, since there is
nothing specific to the project. One exception is vocoder, which does
not seem to get into swh-plugins.
https://github.com/LMMS/lmms/issues/2366

Calf LADSPA plugins are not packaged in Debian.

I would ship vocoder in vocoder-ladspa, the Calf plugins in calf-ladspa
and use /usr/lib/ladspa like all the other LADSPA packages, forgetting
multi-arch.


smime.p7s
Description: S/MIME cryptographic signature

Bug#726661: login fails with pam_loginuid(sshd:session): set_loginuid failed

[Evgeni Golov]

Ohai,

On Thu, Nov 13, 2014 at 10:39:35AM +, Simon McVittie wrote:

> I cannot reproduce this bug on a (somewhat outdated) jessie system with
> sysvinit. I would like some more information from the people who are
> affected by it:
> 
> * Are you using a non-Debian kernel?
> * Does your kernel have AUDIT_LOGINUID_IMMUTABLE set in its configuration?
> * What init system are you using? (sysvinit? systemd? Upstart? something 
> else?)

I can reproduce this bug on a Debian Jessie system with LXC 2.0 (from Stretch).

Host: jessie with systemd as pid1, lxc and lxcfs from stretch
Guest: jessie with sysvinit as pid1 (systemd gives me headaches in containers 
yet)

I think the crucial part here is that I run my containers unprivileged in an 
user namespace.

# cat /proc/self/loginuid
4294967295

same value is returned for the sshd process

> Possible workarounds include:
> 
> * Remove pam_loginuid.so from the ssh configuration (confirmed to work,
>   but it would reopen #677440 and doesn't seem a great idea distro-wide)
> * Use a modern init system that starts system services via IPC to pid 1,
>   i.e. systemd or Upstart
>   - The restarted openssh-server has loginuid -1
>   - The transition from -1 to 4321 succeeds
>   - Everything's fine
> * Use a Debian kernel without AUDIT_LOGINUID_IMMUTABLE (?)
> * Drop pam_loginuid.so from required to optional in the ssh configuration (?)

There are PAM patches at [1][2][3], maybe they just need backporting to Jessie?

Greets
Evgeni

[1] 
https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=5825450540e6620ac331c64345b42fdcbb1d6e87
[2] 
https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=24f3a88e7de52fbfcb7b8a1ebdae0cdbef420edf
[3] 
https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a

Bug#806027: fwknop: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806027 + patch
thanks

>debian/rules override_dh_fixperms
> make[1]: Entering directory '/<>'
> chmod 600 /<>/debian/fwknop-server/etc/fwknop/access.conf
> chmod: cannot access 
> '/<>/debian/fwknop-server/etc/fwknop/access.conf': No such file 
> or directory

Explanation: We are creating arch-independent packages only, so
debian/fwknop-server/[...] does not exist because fwknop-server is
arch-dependent.

The trivial fix is to override dh_fixperms only when creating
arch-dependent packages.

While we are at it, we can even avoid using --exclude by putting
dh_fixperms first and chmod later.

Patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -57,10 +57,10 @@ override_dh_link:
dh_link -plibfko2-dev $(LIB_LIBFKODEV)/libfko.so.2.0.0 
$(LIB_LIBFKODEV)/libfko.so
dh_link --remaining-packages
 
-override_dh_fixperms:
+override_dh_fixperms-arch:
+   dh_fixperms
chmod 600 $(CURDIR)/debian/fwknop-server/etc/fwknop/access.conf
chmod 600 $(CURDIR)/debian/fwknop-server/etc/fwknop/fwknopd.conf
-   dh_fixperms --exclude access.conf --exclude fwknopd.conf
 
 override_dh_strip:
dh_strip --dbg-package=libfko2-dbg