Bug#844685: openrc: System reboots instead of shutting down (su -c halt)

[lumin]

Hi,

I encountered the same problem after replacing sysv-rc
with openrc on sid/kfreebsd-amd64. "sudo poweroff" just
triggers a reboot instead of real poweroff.

This can be fixed by installing sysv-rc back.

openrc/unstable 0.21-4 kfreebsd-amd64

Bug#846908: netsurf: crashes on many websites

[Helge Kreutzmann]

Package: netsurf
Version: 3.6-3
Severity: important

Typical example I can provide (many) more:
helge@samd:~$ netsurf bugs.debian.org/netsurf
Speicherzugriffsfehler

(english: Segmentation fault)

If you need further infos (strace, debug build run in gdb, ..) please
let me know.

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

Kernel: Linux 4.5.5samd.10-grsec (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages netsurf depends on:
ii  netsurf-gtk  3.6-3

netsurf recommends no packages.

netsurf suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#846773: tarantool: FTBFS: ld: final link failed: Nonrepresentable section on output

[Roman Tsisyk]

Hi Lucas,

>Saturday, December  3, 2016 12:11 PM +03:00 from Lucas Nussbaum 
>:
>During a rebuild of all packages in sid, your package failed to build on
>amd64.
>
>Relevant part (hopefully):
>> /usr/bin/ld: host/minilua.o: relocation R_X86_64_32S against `.rodata' can 
>> not be used when making a shared object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> collect2: error: ld returned 1 exit status

I already realized the root cause of this problem after explanation in #845484.
A new package will be pushed soon.

-- 
WBR,
  Roman Tsisyk 
  http://tarantool.org/ - an efficient in-memory data store and a Lua 
application server

Bug#844395: gdm3: Black screen starting gnome with mutter=3.22.2-1

[Osamu Aoki]

control: retitle -1 gdm3: Black screen starting gnome with mutter=3.22.2-1

Hi,

As I see this bug report, this bug was hit under unstable system with
mutter=3.22.2-1.

mutter=3.22.2-1 migration to testing has happened yesterday.

So this seems to be the same problem I faced under testing as reported
to mutter:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846898

According to Ivan, It does not happen in mutter=3.22.1-2.

I will keep this bug report here for others wondering how to start gnome from
gdm3 with the updated title, but this problem looks like the issue with
mutter=3.22.2-1.

Osamu

Bug#846809: O: xoscope -- digital oscilloscope

[Bhavani Shankar R]

Hi Tobi,

Sorry for the late response as I was busy with real world stuff

However, have uploaded a new version of the package and have raised
bug no 846906 to get it into debian

Would love to continue contributing to debian as long as I can and
will have a check regularly from now on

Thanks,

-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

Bug#846907: debian-edu-install: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: debian-edu-install
Version: 1.908
Severity: wishlist
Tags: l10n patch

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 ***

Russian debconf templates translation update is attached.

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

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


ru.po.gz
Description: application/gzip

Bug#846906: RFS: xoscope/2.2-1

[Bhavani Shankar R]

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

  Dear mentors,

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

 * Package name: xoscope
   Version : 2.2-1
   Section : x11

  It builds those binary packages:

xoscope- digital oscilloscope

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/x/xoscope/xoscope_2.2-1.dsc

  Changes since the last upload:

  xoscope (2.2-1) unstable; urgency=low
 .
   * ACK NMU. Thanks Petter.
 + NMU closes gtkdatabox transition (Closes: #845349)
   * Return to Debian. (Closes: #846809)
   * Update my email.
   * Correct pakage description length. Thanks Lintian.

Regards,

-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

Bug#845058: [Pkg-fonts-devel] Bug#845058: Bug#845058: fonts-noto: Installing the package freezes all graphical applications.

[陳昌倬]

Control: severity -1 normal

Lower the severity to normal since it just causes temporary freeze.


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#846905: ITP: node-fancy-log -- Log things, prefixed with a timestamp

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-fancy-log
  Version : 1.2.0
  Upstream Author : Blaine Bublitz  (http://iceddev.com)
* URL : https://github.com/phated/fancy-log#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Log things, prefixed with a timestamp



signature.asc
Description: OpenPGP digital signature

Bug#846439: ltsp: add libfl-dev to Build-Depends

[Vagrant Cascadian]

Control: tags 846439 +pending

On 2016-12-01, Helmut Grohne wrote:
> ltsp will soon fail to build from source, beause flex drops its
> dependency on libfl-dev. Since ltsp uses parts of libfl-dev (e.g.
> libl.a, libfl.a or FlexLexer.h), it should add libfl-dev to its
> Build-Depends. This change was previously announced[1] to
> debian-devel in accordance with DevRef 7.1.1. Please add the missing
> dependency.

Thanks for the bug report!

Committed to git, will include in an upload soon:

  
https://anonscm.debian.org/cgit/collab-maint/ltsp.git/commit/?id=9c006d98111addb7362dbd5de2632b79640545a2


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#846903: ITP: node-has-gulplog -- Check if gulplog is available before attempting to use it

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-has-gulplog
  Version : 0.1.0
  Upstream Author : Blaine Bublitz  (http://iceddev.com)
* URL : https://github.com/gulpjs/has-gulplog#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Check if gulplog is available before attempting to
use it



signature.asc
Description: OpenPGP digital signature

Bug#846904: node-glogg -- Global logging utility

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-glogg
  Version : 1.0.0
  Upstream Author : Blaine Bublitz 
(http://iceddev.com/)
* URL : https://github.com/undertakerjs/glogg#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Global logging utility




signature.asc
Description: OpenPGP digital signature

Bug#479841: [Pkg-zsh-devel] Bug#479841: Inconsistent return code of subshell when immediately assigning local variables

[Daniel Shahaf]

Axel Beckert wrote on Sun, Dec 04, 2016 at 04:11:38 +0100:
> Daniel Shahaf wrote on 30th of January 2016:
> > I asked upstream and the conclusion was, they won't change this
> > behaviour.  However, the behaviour will be pointed out in the manual in
> > 5.3 and newer.
> 
> I haven't found an according commit upstream, but also wasn't really
> sure for what I should be looking. Can you point out that commit?

Sure:

commit 3b69b121def33bb02d01ba23a7148129ab2aed46
Author: Daniel Shahaf 
Date:   Fri Jan 29 09:18:34 2016 +

37831: typeset: Document exit status difference from parameter 
assignment statements

That patch is buried in the 37609 thread, which is cross-referenced from
this bug via the 'forwarded' metadatum.

Cheers,

Daniel

Bug#846902: mark libxfce4ui-common Multi-Arch: foreign

[Helmut Grohne]

Package: libxfce4ui-common
Version: 4.12.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:garcon src:lightdm-gtk-greeter src:parole 
src:ristretto src:xfburn src:xfce4-cpufreq-plugin src:xfce4-cpugraph-plugin 
src:xfce4-equake-plugin src:xfce4-hdaps src:xfce4-indicator-plugin 
src:xfce4-messenger-plugin src:xfce4-notifyd src:xfce4-places-plugin 
src:xfce4-power-manager src:xfce4-pulseaudio-plugin src:xfce4-settings 
src:xfce4-whiskermenu-plugin src:xfce4-wmdock-plugin src:xfswitch-plugin 
src:xfwm4

The packages listed above (and probably more) fail to satisfy their
cross build dependencies, because their transitive dependency on
libxfce4ui-common is unsatisfiable. In general, Architecture: all
packages can never be used to satisfy cross Build-Depends unless marked
Multi-Arch: foreign.  In this case, such a marking is correct, because
libxfce4ui-common does not have any maintainer scripts nor dependencies.

The attached patch also adds a number of other Multi-Arch headers for
all but libxfce4ui-utils. Please consider applying all of them. Since
libxfce4ui already uses multiarch paths, no packaging changes are
required beyond adding those headers.

Helmut
diff --minimal -Nru libxfce4ui-4.12.1/debian/changelog 
libxfce4ui-4.12.1/debian/changelog
--- libxfce4ui-4.12.1/debian/changelog  2015-05-06 15:36:18.0 +0200
+++ libxfce4ui-4.12.1/debian/changelog  2016-12-04 06:11:56.0 +0100
@@ -1,3 +1,10 @@
+libxfce4ui (4.12.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Multi-Arch annotations to all but libxfce4ui-utils (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 04 Dec 2016 06:11:56 +0100
+
 libxfce4ui (4.12.1-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru libxfce4ui-4.12.1/debian/control 
libxfce4ui-4.12.1/debian/control
--- libxfce4ui-4.12.1/debian/control2015-03-03 22:07:22.0 +0100
+++ libxfce4ui-4.12.1/debian/control2016-12-04 06:11:53.0 +0100
@@ -16,6 +16,7 @@
 Package: libxfce4ui-1-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, libxfce4ui-common (>= 4.11)
 Description: widget library for Xfce - Gtk+2 variant
@@ -27,6 +28,7 @@
 Package: libxfce4ui-1-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libxfce4ui-1-0 (= ${binary:Version}), ${misc:Depends}, libgtk2.0-dev,
  libxfce4util-dev (>= 4.10.0), libxfconf-0-dev (>= 4.10.0)
 Description: Development files for libxfce4ui - Gtk+2 variant
@@ -39,6 +41,7 @@
 Section: debug
 Priority: extra
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, libxfce4ui-1-0 (= ${binary:Version}),
  ${misc:Depends}
 Description: debugging symbols for libxfce4ui - Gtk+2 variant
@@ -49,6 +52,7 @@
 Package: libxfce4ui-2-0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, libxfce4ui-common (>= 4.11)
 Description: widget library for Xfce - Gtk+3 variant
@@ -60,6 +64,7 @@
 Package: libxfce4ui-2-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libxfce4ui-2-0 (= ${binary:Version}), ${misc:Depends}, libgtk-3-dev,
  libxfce4util-dev (>= 4.10.0), libxfconf-0-dev (>= 4.10.0)
 Description: Development files for libxfce4ui - Gtk+3 variant
@@ -72,6 +77,7 @@
 Section: debug
 Priority: extra
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, libxfce4ui-2-0 (= ${binary:Version}),
  ${misc:Depends}
 Description: debugging symbols for libxfce4ui - Gtk+3 variant
@@ -82,6 +88,7 @@
 Package: libxfce4ui-common
 Section: xfce
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: libxfce4ui-2-0 | libxfce4ui-1-0, devhelp
 Provides: xfce-keyboard-shortcuts
@@ -107,6 +114,7 @@
 Section: debug
 Priority: extra
 Architecture: any
+Multi-Arch: same
 Depends: libxfce4ui-utils (= ${binary:Version}), ${shlibs:Depends},
  ${misc:Depends}
 Breaks: libxfce4ui-1-dbg (<< 4.10.0-4)
@@ -118,6 +126,7 @@
 Section: oldlibs
 Priority: extra
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, libxfce4ui-common
 Description: xfce keyboard shortcuts configuration (transitional package)
  This package only contains the default shortcut configuration for Xfce.

Bug#846901: nload FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: nload
Version: 0.7.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nload fails to cross build from source, because it configures for the
build architecture. ./configure thus fails finding ncurses, which is
only requested for the host architecture. Indirecting the explicit
./configure invocation through dh_auto_configure makes nload cross build
successfully because dh_auto_configure knows when to pass the right
--host flag to ./configure. Please consider applying the attached patch.

Helmut
diff --minimal -Nru nload-0.7.4/debian/changelog nload-0.7.4/debian/changelog
--- nload-0.7.4/debian/changelog2012-05-28 11:37:04.0 +0200
+++ nload-0.7.4/debian/changelog2016-12-04 05:43:42.0 +0100
@@ -1,3 +1,11 @@
+nload (0.7.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to ./configure (Closes:
+#-1)
+
+ -- Helmut Grohne   Sun, 04 Dec 2016 05:43:42 +0100
+
 nload (0.7.4-1) unstable; urgency=low
 
   * [29fb6c5] Imported Upstream version 0.7.4
diff --minimal -Nru nload-0.7.4/debian/rules nload-0.7.4/debian/rules
--- nload-0.7.4/debian/rules2012-05-28 11:37:04.0 +0200
+++ nload-0.7.4/debian/rules2016-12-04 05:43:40.0 +0100
@@ -8,7 +8,7 @@
dh_testdir
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
-   ./configure --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info --sysconfdir=/etc CFLAGS="$(CFLAGS)"
+   dh_auto_configure -- CFLAGS="$(CFLAGS)"
touch configure-stamp
 
 build: configure build-stamp

Bug#846814: Updating the uploaders list

[Bhavani Shankar R]

Opened up Bug Number 846899 for package upload against sponsorship requests.

On Sun, Dec 4, 2016 at 9:19 AM, Bhavani Shankar R  wrote:
> Hi Tobi,
>
> Sorry for the late response as I was busy in real world stuff
>
> Actually have uploaded my package and will look for a sponsor now
>
> Your upload of the package 'mobile-broadband-provider-info' to
> mentors.debian.net was
> successful. Others can now see it. The URL of your package is:
> https://mentors.debian.net/package/mobile-broadband-provider-info
>
> The respective dsc file can be found at:
> https://mentors.debian.net/debian/pool/main/m/mobile-broadband-provider-info/mobile-broadband-provider-info_20161204-1.dsc
>
> If you do not yet have a sponsor for your package you may want to go to
> https://mentors.debian.net/sponsors/rfs-howto/mobile-broadband-provider-info
> and set the "Seeking a sponsor" option to highlight your package on the
> welcome page.
>
> You can also send an RFS (request for sponsorship) to the debian-mentors
> mailing list. Your package page will give your suggestions on how to
> send that mail.
>
> Good luck in finding a sponsor!
>
> Thanks,
>
> I still wish to continue my contributions as long as possible.
>
>
> --
> Bhavani Shankar
> Ubuntu Developer   |  www.ubuntu.com
> https://launchpad.net/~bhavi



-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

Bug#846898: Only works with Gnome wayland from gdm3

[Ivan Martinez]

Hello,

I am experimenting the same problem.  It does not happen in
mutter=3.22.1-2.

gnome-session-f reports a segfault while i am logging in so a black screen
appears.

gnome-session-f [PID] : segfault at 0 ip 7f3e807b0a29 sp
7fff0b07b2e0 error 4 in libgtk-3.so.0.2200.4[7f3e804ce000+6f7000]

Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

[Guillem Jover]

Hi!

On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> Right, this was reported the other day on IRC by Mattia Rizzolo. The
> combination of -Sextreme -z9 and parallel xz makes this use more than
> the available address space. I'll change the code to limit based on
> memory available. Although as was mentioned on a thread on d-d, those
> settings are pretty unfriendly IMO, even more for memory constrained
> arches, but oh well. dpkg should never fail to operate on those
> conditions.

I've got the attached patch now, but I've been unable to test that
specific incarnation as I don't have 32-bit machine with many cores.
And neither are the i386 nor armhf porter boxes. I've just verified
that it does what it is intended by hardcoding the number of threads
to 32 and setting the physical memory limit to 2 GiB. And it reduced
the threads down to 12 when building one of those font packages.

If someone could test this on such 32-bit machine, that would be
appreciated.

Thanks,
Guillem
From 981fe7b1cc828e9d446bc07298264e421a970ac9 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 4 Dec 2016 02:35:27 +0100
Subject: [PATCH] libdpkg: Decrease xz encoder threads to not exceed memory
 limits

---
 lib/dpkg/compress.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/lib/dpkg/compress.c b/lib/dpkg/compress.c
index 2eda658fa..05e056b22 100644
--- a/lib/dpkg/compress.c
+++ b/lib/dpkg/compress.c
@@ -529,9 +529,9 @@ filter_xz_init(struct io_lzma *io, lzma_stream *s)
 	uint32_t preset;
 	lzma_check check = LZMA_CHECK_CRC64;
 #ifdef HAVE_LZMA_MT
+	uint64_t mt_memlimit;
 	lzma_mt mt_options = {
 		.flags = 0,
-		.threads = sysconf(_SC_NPROCESSORS_ONLN),
 		.block_size = 0,
 		.timeout = 0,
 		.filters = NULL,
@@ -548,6 +548,27 @@ filter_xz_init(struct io_lzma *io, lzma_stream *s)
 
 #ifdef HAVE_LZMA_MT
 	mt_options.preset = preset;
+
+	/* Set the multi-threaded memory limit to half the physical RAM,
+	 * or to 128 MiB if we cannot infer the number. */
+	mt_memlimit = lzma_physmem() / 2;
+	if (mt_memlimit == 0)
+		mt_memlimit = 128 * 1024 * 1024;
+
+	mt_options.threads = lzma_cputhreads();
+	if (mt_options.threads == 0)
+		mt_options.threads = 1;
+
+	/* Check that we have enough RAM to use the multi-threaded encoder,
+	 * and decrease them up to single-threaded to reduce memory usage. */
+	for (; mt_options.threads > 1; mt_options.threads--) {
+		uint64_t mt_memusage;
+
+		mt_memusage = lzma_stream_encoder_mt_memusage(&mt_options);
+		if (mt_memusage < mt_memlimit)
+			break;
+	}
+
 	ret = lzma_stream_encoder_mt(s, &mt_options);
 #else
 	ret = lzma_easy_encoder(s, preset, check);
-- 
2.11.0.rc1.160.g51e66c2

Bug#846891: integrit: please make the build reproducible (fileordering)

[Vagrant Cascadian]

On 2016-12-04, Valerie R Young wrote:
> --- implicit  2016-12-03 17:05:39.0 -0500
> +++ implicit  2016-12-03 17:57:02.682034599 -0500
> @@ -87,7 +87,7 @@
>   : debian/$*/DEBIAN/md5sums
>   @rm -f debian/$*/DEBIAN/md5sums
>   @cd debian/$* && find * -path 'DEBIAN' -prune -o \
> -   -type f -exec md5sum {} >>DEBIAN/md5sums \;
> +   -type f -exec md5sum {} \; | LC_ALL=C sort >>DEBIAN/md5sums

Not positive, but I'm guessing the "\;" should be at the end of the
line:

  +   -type f -exec md5sum {} | LC_ALL=C sort >>DEBIAN/md5sums \;


Though I haven't tested or looked deeper into the code...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#820381: rar crashes.

[Beedxe' Suugakujin]

Package: rar
Version: 2:5.3.b2-1
Followup-For: Bug #820381

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: stretch/sid
  APT prefers testing
  APT policy: (970, 'testing'), (810, 'unstable'), (760, 'stable'), (710, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

When I installed rar and unrar packages together the compress operation or the 
decompress operation not work. So, if I have to unpack .rar files I have to 
unistall rar package. This occurs in graphical mode in files navigator or 
console. 

Bug#844701: dpkg: buggy dpkg 1.8.11 and above ? Package: dpkg

[Guillem Jover]

Hi!

On Mon, 2016-11-21 at 05:00:39 +0530, shirish शिरीष wrote:
> On 21/11/2016, Guillem Jover  wrote:
> > On Mon, 2016-11-21 at 01:47:45 +0530, shirish शिरीष wrote:
> >> The patch didn't work :(
> >
> > Well that it didn't work was actually also very useful! Because in
> > your case it should not have worked due to having debug output
> > enabled. If you retry it again w/o debugging enabled it should work,
> > and the attached patch should make it impervious to debug settings.

> >> So it seems some issue is still there. I'll reboot and see if the
> >> issue still persists.
> >
> > Yes and no. The original problem should be gone (the problem with the
> > exit code, the new problem with the non-empty output string due to the
> > debug output is new, but very welcome as it should make the code more
> > robust. Thanks for that. Attached new patch.

> Anyways, think it got through but for some reason dpkg died/failed it
> says , see -

I don't think this is related to this problem. The error report from
whoever is reporting that is not very helpful though. :/

In any case, I've now implemented an actual set of validators instead
of abusing the --compare-versions to do the validation. Which will
have defined exit codes and not output stuff on debugging modes.

At least I've added a --validate-pkgname and a --validate-version.
I'll try to do a release tomorrow or so.

Thanks,
Guillem

Bug#846900: mate-applets: fails to show weather of any city

[fabz67]

Package: mate-applets
Version: 1.8.1+dfsg1-3
Severity: normal

Dear Maintainer,

I can't see the weather in the taskbar, it shows only an empty space

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

   * What led up to the situation?
--> Nothing, it worked this summer, but now, it's broke


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
--> I tried to change city, country, anything, but it don't work


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



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

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

Versions of packages mate-applets depends on:
ii  gir1.2-mate-panel   1.8.1+dfsg1-3
ii  gsettings-desktop-schemas   3.14.1-1
ii  gstreamer0.10-alsa  0.10.36-2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+deb8u2
ii  gvfs1.22.2-1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u6
ii  libcairo2   1.14.0-2.1+deb8u1
ii  libcpufreq0 008-1
ii  libdbus-1-3 1.8.20-0+deb8u1
ii  libdbus-glib-1-20.102-1
ii  libfontconfig1  2.11.0-6.3+deb8u1
ii  libfreetype62.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libgtksourceview2.0-0   2.10.5-2
ii  libgtop2-7  2.28.5-2+b1
ii  libice6 2:1.0.9-1+b1
ii  libmate-desktop-2-171.8.1+dfsg1-3+deb8u1
ii  libmate-panel-applet-4-11.8.1+dfsg1-3
ii  libmateweather1 1.8.0-2
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libpolkit-gobject-1-0   0.105-15~deb8u2
ii  libsm6  2:1.2.2-1+b1
ii  libstartup-notification00.12-4
ii  libupower-glib3 0.99.1-3.2
ii  libwnck22   2.30.7-2
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.1+dfsg1-5+deb8u3
ii  mate-applets-common 1.8.1+dfsg1-3
ii  mate-icon-theme 1.8.0-1
ii  mate-panel  1.8.1+dfsg1-3
ii  python  2.7.9-1
ii  python-dbus 1.2.0-2+b3
ii  python-gi   3.14.0-1
ii  python-gobject  3.14.0-1
ii  python-gst0.10  0.10.22-3
ii  python-notify   0.1.1-4

Versions of packages mate-applets recommends:
ii  cpufrequtils 008-1
ii  mate-media   1.8.0+dfsg1-3
ii  mate-polkit  1.8.0+dfsg1-4
ii  mate-system-monitor  1.8.0+dfsg1-2

mate-applets suggests no packages.

-- no debconf information

Bug#846899: RFS: mobile-broadband-provider-info/20161204-1

[Bhavani Shankar R]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "mobile-broadband-provider-info"

 * Package name: mobile-broadband-provider-info
   Version : 20161204-1
   Section : admin

  It builds those binary packages:

mobile-broadband-provider-info - database of mobile broadband
service providers

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

  https://mentors.debian.net/package/mobile-broadband-provider-info


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

dget -x 
https://mentors.debian.net/debian/pool/main/m/mobile-broadband-provider-info/mobile-broadband-provider-info_20161204-1.dsc

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

  Changes since the last upload:

   mobile-broadband-provider-info (20161204-1) unstable; urgency=low
 .
   * Ack NMU. Thanks Martin.
   * Return Back to Debian (Closes: #846814)
   * Merge latest changes from git:
 - no: add Phonero APN
 - mt: add APN for Melita Mobile
 - cz: add O2 balance check and top-up
 - bd: add data for Bangladesh providers
 - fi: update Finland provider DNA
 - nl: t-mobile update
 - nl: KPN update
 - cl: add extra mnc to Movistar Chile Network
 - build: Run configure from the builddir
   * Update year in debian/copyright

Regards,


-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

[Guillem Jover]

Control: severity -1 wishlist
Control: retitle -1 dpkg: Please remove packages seclected for deinstall on 
Multi-Arch version skew

[ I'm actually a bit undecided whether this is normal or wishlist in dpkg
  itself, see below. ]

[ BTW David, do not forget to CC pkgname@packages.d.o either! :) ]

Hi!

On Tue, 2016-11-22 at 18:50:51 +0100, David Kalnischkies wrote:
>  On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote:
> > --\ Packages to be upgraded (17)
> […]
> > iuA nvidia-driver-libs367.57-1 
> > 367.57-2
> […]
> > --\ Packages being removed because they are no longer used (27)
> […]
> > idA nvidia-driver-libs:i386 -180 kB   367.57-1 
> > 367.57-2
> […]
> > dpkg: error processing package nvidia-driver-libs:amd64 (--configure):
> >  package nvidia-driver-libs:amd64 367.57-2 cannot be configured because 
> > nvidia-driver-libs:i386 is at a different version (367.57-1)
> 
> This looks like a bug in dpkg as it is not considering the removal of
> nvidia-driver-libs:i386 as solution to the problem it runs into here
> even through libapt has told it via selections that it wants it removed.

Hmm, dpkg does not remove other packages at configure time, it only
ever does that at unpack time. Removing this kind of packages at
unpack time would seem gratuituous though, as it might or might not end
up seeing an updated packages, and version-skew (I like screw too BTW :)
is not a problem at unpack time anyway. Also remember that an unpack of
the selected to be deinstalled package would reset that selection.

So, this seems like a new kind of feature to me. Also the frontends
would need to handle the current dpkg anyway when doing upgrades, so
it seems this needs to be handled in frontends right now no matter
what?

Thanks,
Guillem

Bug#846814: Updating the uploaders list

[Bhavani Shankar R]

Hi Tobi,

Sorry for the late response as I was busy in real world stuff

Actually have uploaded my package and will look for a sponsor now

Your upload of the package 'mobile-broadband-provider-info' to
mentors.debian.net was
successful. Others can now see it. The URL of your package is:
https://mentors.debian.net/package/mobile-broadband-provider-info

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/main/m/mobile-broadband-provider-info/mobile-broadband-provider-info_20161204-1.dsc

If you do not yet have a sponsor for your package you may want to go to
https://mentors.debian.net/sponsors/rfs-howto/mobile-broadband-provider-info
and set the "Seeking a sponsor" option to highlight your package on the
welcome page.

You can also send an RFS (request for sponsorship) to the debian-mentors
mailing list. Your package page will give your suggestions on how to
send that mail.

Good luck in finding a sponsor!

Thanks,

I still wish to continue my contributions as long as possible.


-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs

[gregor herrmann]

On Mon, 24 Oct 2016 07:23:30 +0100, Colin Watson wrote:

> I (obviously) agree.  How about this patch?  I'm seeking seconds for
> this proposal.
> 
> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..ab4f736 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9610,9 +9610,7 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
> that a dynamically allocated id can be used.  In this case
> you should choose an appropriate user or group name,
> discussing this on debian-devel and checking
> -   with the  -   they do not wish you to use a statically allocated id
> -   instead.  When this has been checked you must arrange for
> +   that it is unique.  When this has been checked you must arrange for
> your package to create the user or group if necessary using
> adduser in the preinst or
> postinst script (again, the latter is to be

Seconded.


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kings of Convenience: Scars On Land


signature.asc
Description: Digital Signature

Bug#846898: Only works with Gnome wayland from gdm3

[Osamu Aoki]

Package: mutter
Version: 3.22.2-1
Severity: normal

PROBLEM:No more "gnome"
WORKAROUND: Use "gnome in wayland"
IMPACT: testing (December 3rd-), unstable
ATTACHED: upgraded package list (excluding gcc and libreoffice ...)

SITUATION:

Upon starting PC today, I can not start Gnome (it was my default) from
GDM3.  It is just black screen.  (I still have linux console on
CTRL-ALT-F3.  But C-A-F1 and C-A-F2 does not work...  is this normal
these days?)

I just updated mutter a day before, so this is the most suspicious
package causing this problem in retrospective.  (I followed testing)

My first reaction was to upgrade my system to unstable, ... which did
not solve my issue.

After reading somewhat unrelated bug report on GDM3:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844395#15
I rebooted and logged in to "gnome in wayland" from gdm3, voila! it works.

I rebooted and tried to login to "gnome" from gdm3, again black screen.

So something broke non-wayland standard gnome session.

According to my package update history, mutter is the only thing updated
which is related to starting desktop session.

It is strange I do not see people complained ... maybe people following
unstable may be using "gnome in wayland"...

Excuse me not being more explicit on the bug ...

Regards,

Osamu

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

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

Versions of packages mutter depends on:
ii  gsettings-desktop-schemas  3.22.0-1
ii  libc6  2.24-7
ii  libglib2.0-0   2.50.2-2
ii  libmutter0i3.22.2-1
ii  libx11-6   2:1.6.3-1
ii  libxcomposite1 1:0.4.4-1
ii  mutter-common  3.22.2-1
ii  zenity 3.22.0-1

Versions of packages mutter recommends:
ii  gnome-session [x-session-manager]  3.22.2-1

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.22.1-1
ii  xdg-user-dirs 0.15-2

-- no debconf information
Start-Date: 2016-12-03  22:04:51
Commandline: apt-get dist-upgrade -y
Requested-By: osamu (1000)
Upgrade:
 appstream:amd64 (0.10.3-1, 0.10.4-1)
 base-files:amd64 (9.6, 9.7)
 dialog:amd64 (1.3-20160828-1, 1.3-20160828-2)
 fonts-opensymbol:amd64 (2:102.7+LibO5.2.3~rc1-4, 2:102.7+LibO5.2.3-2)
 gir1.2-lokdocview-0.1:amd64 (1:5.2.3~rc1-4, 1:5.2.3-2)
 gir1.2-mutter-3.0:amd64 (3.22.1-2, 3.22.2-1)
 gnome-packagekit-data:amd64 (3.20.0-1, 3.22.1-1)
 gnome-packagekit:amd64 (3.20.0-1, 3.22.1-1)
 hwinfo:amd64 (21.32-1, 21.37-1)
 lib32asan3:amd64 (6.2.0-13, 6.2.1-5)
 lib32atomic1:amd64 (6.2.0-13, 6.2.1-5)
 lib32cilkrts5:amd64 (6.2.0-13, 6.2.1-5)
 lib32gcc-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 lib32gcc1:amd64 (1:6.2.0-13, 1:6.2.1-5)
 lib32gomp1:amd64 (6.2.0-13, 6.2.1-5)
 lib32itm1:amd64 (6.2.0-13, 6.2.1-5)
 lib32mpx2:amd64 (6.2.0-13, 6.2.1-5)
 lib32quadmath0:amd64 (6.2.0-13, 6.2.1-5)
 lib32stdc++-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 lib32stdc++6:amd64 (6.2.0-13, 6.2.1-5)
 lib32ubsan0:amd64 (6.2.0-13, 6.2.1-5)
 libappstream4:amd64 (0.10.3-1, 0.10.4-1)
 libasan3:amd64 (6.2.0-13, 6.2.1-5)
 libatomic1:amd64 (6.2.0-13, 6.2.1-5)
 libcc1-0:amd64 (6.2.0-13, 6.2.1-5)
 libcilkrts5:amd64 (6.2.0-13, 6.2.1-5)
 libgcc-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libgcc1:amd64 (1:6.2.0-13, 1:6.2.1-5)
 libgcj-common:amd64 (1:5.3-1, 1:6.2-1)
 libgcj17-awt:amd64 (6.2.0-13, 6.2.1-5)
 libgcj17:amd64 (6.2.0-13, 6.2.1-5)
 libgfortran-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libgfortran3:amd64 (6.2.0-13, 6.2.1-5)
 libglpk40:amd64 (4.60-2+b1, 4.60-3)
 libgomp1:amd64 (6.2.0-13, 6.2.1-5)
 libgphoto2-6:amd64 (2.5.10-3, 2.5.11-1)
 libgphoto2-l10n:amd64 (2.5.10-3, 2.5.11-1)
 libgphoto2-port12:amd64 (2.5.10-3, 2.5.11-1)
 libhd21:amd64 (21.32-1, 21.37-1)
 libhtml-tagset-perl:amd64 (3.20-2, 3.20-3)
 libitm1:amd64 (6.2.0-13, 6.2.1-5)
 liblibreofficekitgtk:amd64 (1:5.2.3~rc1-4, 1:5.2.3-2)
 liblsan0:amd64 (6.2.0-13, 6.2.1-5)
 libmail-sendmail-perl:amd64 (0.79.16-1, 0.79.16-2)
 libmpx2:amd64 (6.2.0-13, 6.2.1-5)
 libmutter0i:amd64 (3.22.1-2, 3.22.2-1)
 libnghttp2-14:amd64 (1.16.0-1, 1.17.0-1)
 libobjc-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libobjc4:amd64 (6.2.0-13, 6.2.1-5)
 libquadmath0:amd64 (6.2.0-13, 6.2.1-5)
 libstdc++-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libtsan0:amd64 (6.2.0-13, 6.2.1-5)
 libubsan0:amd64 (6.2.0-13, 6.2.1-5)
 libx32asan3:amd64 (6.2.0-13, 6.2.1-5)
 libx32atomic1:amd64 (6.2.0-13, 6.2.1-5)
 libx32cilkrts5:amd64 (6.2.0-13, 6.2.1-5)
 libx32gcc-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libx32gcc1:amd64 (1:6.2.0-13, 1:6.2.1-5)
 libx32gomp1:amd64 (6.2.0-13, 6.2.1-5)
 libx32itm1:amd64 (6.2.0-13, 6.2.1-5)
 libx32quadmath0:amd64 (6.2.0-13, 6.2.1-5)
 libx32stdc++-6-dev:amd64 (6.2.0-13, 6.2.1-5)
 libx32stdc++6:amd64 (6.2.0-13, 6.2.1-5)
 libx32ubsan0:amd64 (6.2.0-13, 6.2.1-5)
 login:amd64 (1:4.2-3.2, 1:4.2-

Bug#479841: [Pkg-zsh-devel] Bug#479841: Inconsistent return code of subshell when immediately assigning local variables

[Axel Beckert]

Hi Daniel,

Daniel Shahaf wrote on 30th of January 2016:
> I asked upstream and the conclusion was, they won't change this
> behaviour.  However, the behaviour will be pointed out in the manual in
> 5.3 and newer.

I haven't found an according commit upstream, but also wasn't really
sure for what I should be looking. Can you point out that commit?

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

Bug#817779: Dask & Toolz

[Stefan van der Walt]

Yes, absolutely no problem on both counts. I'm happy to be a 
backup/support, so let me know if there is anything you need me to do.

Bug#846897: cryptsetup should not lockout for 60 on 3 bad passwords

[luke]

Package: cryptsetup
Version: 2:1.7.3-2
Severity: normal
Tags: patch

Dear Maintainer,

Failed passwords entered on the local console should not cause a reboot
or long pause.

`cryptsetup` has introduced a locking mechanism on multiple decryption
key unlock failure after CVE-2016-4484. The mechanism itself is wrong
rather than the implementation broken:

- What good does sleeping do? If the threat model is for a local
  user with physical access to the machine, the threat model is
  really one of casual attempts to unlock a machine (in which case
  the users' decryption password should be its own throttling
  mechanism) - otherwise a user will do automated offline decryption
  after physical removal of the key from the drive.

  Rebooting the machine forcibly on failure is the worst thing to do
  in any case, and could be argued to be a simple DoS vector,
  particularly when the machine in question has an expensive reboot
  cost associated with it (my laptop for example has a slow BIOS
  setup process, and my workstation takes around 2 minutes after
  checking PXE and IPMI, plus a long pause in the BIOS launch,
  which means when I enter my complex password incorrectly a few times,
  I'm sometimes not able to login for 10 minutes or so if I'm having
  a bad typing day.

  In any case, the rebooting is the wrong fix for a nonexistent
  problem. Sleeping 15 seconds before reboot has *no* value at all
  as far as I understand.

  The second issue is the infinite loop. This only serves to turn a
  machine into a brick if `reboot` fails, and will force the user to
  pull the plug, causing possible damage to the machine. The user
  may have remote serial access, but no physical access, forcing a
  trip to the datacentre.

  The behavoiur I personally would expect from a decryption key
  setup program is to simply loop forever; If the root partition is
  encrypted with a strong password, what is the threat model from asking
  for the password again?

  I've attached a patch as to what I think should go some way to
  solving the issue (but I'll admit total unfamiliarity with the
  system, and haven't done any real research on what the canonical
  expected behaviour would be in a program of this kind). My feeling
  is that CVE-2016-4484 is something of a red-herring, and the
  current implementation is more damaging than useful.

  I'm happy to try things out if it's any help.

  Thanks

  Luke


-- Package-specific info:

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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.7.3-2
ii  debconf [debconf-2.0]  1.5.59
ii  dmsetup2:1.02.136-1
ii  libc6  2.24-7

Versions of packages cryptsetup recommends:
ii  busybox 1:1.22.0-19
ii  console-setup   1.154
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kbd 2.0.3-2

Versions of packages cryptsetup suggests:
ii  dosfstools  4.0-2
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b1

-- debconf information excluded
diff --git a/debian/initramfs/cryptroot-script b/debian/initramfs/cryptroot-script
index 01e568f..b8563e7 100644
--- a/debian/initramfs/cryptroot-script
+++ b/debian/initramfs/cryptroot-script
@@ -70,7 +70,6 @@ parse_options()
 	cryptkeyscript=""
 	cryptkey="" # This is only used as an argument to an eventual keyscript
 	cryptkeyslot=""
-	crypttries=3
 	crypttcrypt=""
 	cryptveracrypt=""
 	cryptrootdev=""
@@ -124,14 +123,6 @@ parse_options()
 		keyslot=*)
 			cryptkeyslot=${x#keyslot=}
 			;;
-		tries=*)
-			crypttries="${x#tries=}"
-			case "$crypttries" in
-			  *[![:digit:].]*)
-crypttries=3
-;;
-			esac
-			;;
 		tcrypt)
 			crypttcrypt="yes"
 			;;
@@ -179,7 +170,7 @@ activate_vg()
 
 setup_mapping()
 {
-	local opts count cryptopen cryptremove NEWROOT
+	local opts cryptopen cryptremove NEWROOT
 	opts="$1"
 
 	if [ -z "$opts" ]; then
@@ -265,7 +256,6 @@ setup_mapping()
 
 	# We've given up, but we'll let the user fix matters if they can
 	if [ ! -e "${cryptsource}" ]; then
-		
 		echo "  ALERT! ${cryptsource} does not exist."
 		echo "	Check cryptopts=source= bootarg: cat /proc/cmdline"
 		echo "	or missing modules, devices: cat /proc/modules; ls /dev"
@@ -298,9 +288,9 @@ setup_mapping()
 	cryptremove="/sbin/cryptsetup remove $crypttarget"
 	NEWROOT="/dev/mapper/$crypttarget"
 
-	# Try to get a satisfactory password $crypttries times
+	# Try to g

Bug#846896: Patching

[Derric Atzrott]

I don't know Vala (but I do know other languages), but I'd be happy to
try to work it out and submit a patch to fix this problem if someone
would be willing to point me in the general direction of where the code
that actually handles the fade is.

I imagine this should be a fairly easy fix.



signature.asc
Description: OpenPGP digital signature

Bug#845381: Bug#845596: krb5: FTBFS on hurd-i386

[Benjamin Kaduk]

On Sat, Dec 03, 2016 at 06:31:59PM +0100, Svante Signell wrote:
> Hi,
> 
> The patches in 845596 and 845341 are different. Maybe it is better to
> include that definition in a header file? Whatever, it is now more than
> a week ago that you promised a new upload. Is anything hindering a new
> Debian version of that package soon?

I believe we talked about putting the definition in a header file some time
ago and decided that it's better to keep the contamination localized.

A few things were hindering a new Debian version over the past week that
no longer are: #846088 was filed and we needed to find out its disposition
upstream, I needed to research when SYS_getrandom was added to linux and
how that affected a potential decision to change the default PRNG, and
I had to divert my packaging time to a security update of openafs.
Those are all resolved now, though in the meantime upstream has released
1.15 final, so it seems that some of the packaging work will need to be
redone anyway.  But I do not know of any blockers other than maintainer time
anymore.

-Ben

Bug#674827: Gdb backtrace against latest version of scim/1.4.17-1 using Gimp 2.8.18-1

[William L. DeRieux IV]

--
Gdb backtrace against latest version of scim/1.4.17-1 using Gimp 2.8.18-1

(gimp:16410): Gdk-WARNING **: 
/build/gtk+2.0-pW7LUB/gtk+2.0-2.24.31/gdk/x11/gdkdrawable-x11.c:874 
drawable is not a pixmap or window



Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0x771fc878 in IA__gdk_x11_drawable_get_xdisplay 
(drawable=0x5867cad0 [GdkOffscreenWindow]) at 
./gdk/x11/gdkdrawable-x11.c:908

908./gdk/x11/gdkdrawable-x11.c: No such file or directory.
(gdb) bt
#0  0x771fc878 in IA__gdk_x11_drawable_get_xdisplay 
(drawable=0x5867cad0 [GdkOffscreenWindow]) at 
./gdk/x11/gdkdrawable-x11.c:908
#1  0x7fffd3df2e2e in scim_bridge_key_event_gdk_to_bridge () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#2  0x7fffd3df27b1 in  () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#3  0x7fffd3df2a74 in  () at 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-scim.so
#4  0x77575933 in gtk_im_multicontext_filter_keypress 
(context=0x58571c30 [GtkIMMulticontext], event=0x5847c090) at 
./gtk/gtkimmulticontext.c:333
#5  0x77522b3c in gtk_entry_key_press 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=0x5847c090) at ./gtk/gtkentry.c:4073
#10 0x73d44faf in [GtkSpinButton]> (instance=instance@entry=0x56a89cd0, 
signal_id=, detail=detail@entry=0)

at ././gobject/gsignal.c:3447
#6  0x7758c84c in _gtk_marshal_BOOLEAN__BOXED 
(closure=0x55ed1130, return_value=0x7fffd3f0, 
n_param_values=, param_values=0x7fffd450, 
invocation_hint=, marshal_data=) at 
./gtk/gtkmarshalers.c:86
#7  0x73d29ecf in g_closure_invoke 
(closure=closure@entry=0x55ed1130, 
return_value=return_value@entry=0x7fffd3f0, n_param_values=2, 
param_values=param_values@entry=0x7fffd450, 
invocation_hint=invocation_hint@entry=0x7fffd3d0) at 
././gobject/gclosure.c:804
#8  0x73d3c37d in signal_emit_unlocked_R 
(node=node@entry=0x55ed1400, detail=detail@entry=0, 
instance=instance@entry=0x56a89cd0, 
emission_return=emission_return@entry=0x7fffd560, 
instance_and_params=instance_and_params@entry=0x7fffd450) at 
././gobject/gsignal.c:3673
#9  0x73d4466f in g_signal_emit_valist (instance=out>, signal_id=, detail=, 
var_args=var_args@entry=0x7fffd610)

at ././gobject/gsignal.c:3401
#11 0x776a498c in gtk_widget_event_internal 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:5010
#12 0x776a4c57 in IA__gtk_widget_event 
(widget=widget@entry=0x56a89cd0 [GtkSpinButton], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:4807
#13 0x776b83bf in IA__gtk_window_propagate_key_event 
(window=0x7fffe0ac1450 [GimpImageWindow], event=0x5847c090) at 
./gtk/gtkwindow.c:5199

#14 0x5577ee6b in  ()
#19 0x73d44faf in [GimpImageWindow]> (instance=instance@entry=0x7fffe0ac1450, 
signal_id=, detail=detail@entry=0)

at ././gobject/gsignal.c:3447
#15 0x7758c84c in _gtk_marshal_BOOLEAN__BOXED 
(closure=0x55ed1130, return_value=0x7fffd940, 
n_param_values=, param_values=0x7fffd9a0, 
invocation_hint=, marshal_data=) at 
./gtk/gtkmarshalers.c:86
#16 0x73d29f75 in g_closure_invoke 
(closure=closure@entry=0x55ed1130, 
return_value=return_value@entry=0x7fffd940, n_param_values=2, 
param_values=param_values@entry=0x7fffd9a0, 
invocation_hint=invocation_hint@entry=0x7fffd920) at 
././gobject/gclosure.c:804
#17 0x73d3c37d in signal_emit_unlocked_R 
(node=node@entry=0x55ed1400, detail=detail@entry=0, 
instance=instance@entry=0x7fffe0ac1450, 
emission_return=emission_return@entry=0x7fffdab0, 
instance_and_params=instance_and_params@entry=0x7fffd9a0) at 
././gobject/gsignal.c:3673
#18 0x73d4466f in g_signal_emit_valist (instance=out>, signal_id=, detail=, 
var_args=var_args@entry=0x7fffdb60)

at ././gobject/gsignal.c:3401
#20 0x776a498c in gtk_widget_event_internal 
(widget=widget@entry=0x7fffe0ac1450 [GimpImageWindow], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:5010
#21 0x776a4c57 in IA__gtk_widget_event 
(widget=widget@entry=0x7fffe0ac1450 [GimpImageWindow], 
event=event@entry=0x5847c090) at ./gtk/gtkwidget.c:4807
#22 0x7758b0ef in IA__gtk_propagate_event (widget=0x7fffe0ac1450 
[GimpImageWindow], event=0x5847c090) at ./gtk/gtkmain.c:2475
#23 0x7758b3cb in IA__gtk_main_do_event (event=0x5847c090) 
at ./gtk/gtkmain.c:1696
#24 0x77200cec in gdk_event_dispatch (source=, 
callback=, user_data=) at 
./gdk/x11/gdkevents-x11.c:2425
#25 0x7384e7f7 in g_main_context_dispatch 
(context=0x55e92910) at ././glib/gmain.c:3203
#26 0x7384e7f7 in g_main_context_dispatch 
(context=context@entry=0x55e92910) at ././glib/gmain.c:3856
#27 0x7384ea60 in g_main_context_iterate 
(con

Bug#846312: vim package fails to build with missing man files

[David Barnett]

I did notice the apparent duplication in the path, but I'm not seeing any
evidence that any commands in a define'd variables like that get executed,
e.g. if I change them to "echo blah", "/bin/false", or a bunch of
non-syntactically-valid gibberish.

David

On Fri, Dec 2, 2016 at 7:28 PM James McCoy  wrote:

> That implies that $(DESTDIR) is being set to debian/tmp/debian/tmp.
> $(DESTDIR) is set by the line:
>
> install-stamp-indep: DESTDIR=$(CURDIR)/debian/tmp
>
> so is $(CURDIR) somehow debian/tmp when install-stamp-indep is run?
>
> > The issue here seems to be that the munge-man-directories helper in
> debian/
> > rules is not getting invoked, those directory moves are skipped, and
> there is
> > no man/ru/ directory at the expected path (only man/ru.UTF-8/ and
> man/ru.KOI8-R
> > /, which never got moved/deleted).
>
> I'm not sure that's actually the case.  It seems to be related to the
> above problem.  It's odd that you're encountering this but it's not
> being hit elsewhere.
>
> Is it somehow being evaluated twice or $(CURDIR) being carried over into
> the sub-make which then expands?
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>

Bug#775744: libapp-stacktrace-perl: FTBFS: Failed 1/4 test programs. 1/6 subtests failed.

[Axel Beckert]

Hi Chris,

Chris Lamb wrote:
> libapp-stacktrace-perl fails to build from source in unstable/amd64 too:

Yes, but that might be a different bug, as I suspect your experinced
issue (which I can confirm, too, btw.) happens on _all_ architectures.

>From the initial bug report:
> > # Cannot access memory at address 0x200147b0

>From your log:
>   # Cannot access memory at address 0x8ad29718

Just having read
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814929#10, it sounds
as if Niko's observation about longer addresses could also have
triggered the FTBFS you ran into, too, although it's likely
different code involved. (If so, I'd clone this bug to track the
recent FTBFS on probably all architectures separately and downgrade
the old one to important again.)

Niko: What do you think?

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

Bug#846896: gnome-mines: No option to turn off fade in of revealed squares

[Derric Atzrott]

Package: gnome-mines
Version: 1:3.14.1-2
Severity: normal
Tags: upstream

Dear Maintainer,

When clicking on squares in gnome-mines there is a fade-in effect for
revealing squares. There is no option to turn this off. On slower systems
this can cause the game to hang for a few seconds, if the player is fast at
playing minesweeper.

I have marked this as normal instead of minor because it can cause issues
with getting a fast score in minesweeper, which I think, all decent
minesweeper players would agree, is the whole point.

There needs to be an option to remove the fade-in so that those with slower
system can play the game properly. In previous builds of gnome-mines there
was no fade-in.


-- System Information:
Debian Release: 8.6
  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.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 gnome-mines depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  libc62.19-18+deb8u6
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk-3-0   3.14.5-1+deb8u1

Versions of packages gnome-mines recommends:
ii  yelp  3.14.1-1

gnome-mines suggests no packages.

-- no debconf information

Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201

[Gabriel Filion]

intrigeri:
>> Also, when using the above-mentioned technique for forcing the driver to
>> "intel" (I've confirmed that it loaded by looking at
>> ~/.local/share/xorg/Xorg.log.0), I don't see visual flashes anymore.
> … and no crashes either?

right, no crashes either. I've been running with newest package and
intel driver since I wrote my last email and there weren't any crashes.



signature.asc
Description: OpenPGP digital signature

Bug#846526: cloud-init: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

On Sat, Dec 03, 2016 at 08:15:50PM -0200, Tiago Ilieve wrote:

Hi Marcin and Tiago,

Thank you for your comments.

> The differences between the original Portuguese (from Portugal) and
> Brazilian Portuguese may be very subtle, which looks like to be the
> case here.

I agree. Thanks for the explanation.

> Were this translation reviewed by debian-l10n-portuguese@l.d.o (I do
> not follow that list)? I'll not suggest any changes here, as I do not
> know how the translation team works. If they reviewed it indeed, we
> can certainly include this file for the next release.

Yes, the translation was reviewed by the team, you can see the history
at the list archives:
https://lists.debian.org/debian-l10n-portuguese/2016/11/threads.html#00037

Tiago, if you have some suggestions to improve the translation, please
feel free to send them either to me or to the list.

After researching about the fallback data source, I would propose a new
round of translations.
http://cloudinit.readthedocs.io/en/latest/topics/datasources/fallback.html

Marcin, can you wait until a new reviewed version is prepared, please?


signature.asc
Description: Digital signature

Bug#838229: libmygpo-qt-dev: missing cmake targets file, which makes whole cmake stuff useless

[Jérémy Bobbio]

Hi Pino!

Pino Toscano:
> > libmygpo-qt-dev ships configuration files for cmake, so that doing
> > 
> >   find_package(Mygpo-qt)
> >   ..
> >   include_directories(${LIBMYGPO_QT_INCLUDE_DIRS})
> >   ..
> >   target_link_libraries(myapp ${LIBMYGPO_QT_LIBRARIES})
> > 
> > works -- or at least, it should wihout fail when linking.
> > The problem is that the Mygpo-qtTargets-${BUILD_TYPE}.cmake config file
> > for cmake, correctly installed by the upstream build system, is not
> > shipped in libmygpo-qt-dev, and thus the "mygpo-qt" imported library
> > target cannot be loaded.
> > 
> > Attached there is a simple patch for libmygpo-qt-dev.install, to
> > install the missing file, no matter what is the build type set in cmake.
> > I'd like to enable the gpodder.net integration in amarok (#655362),
> > but this bug causes build issues.
> […]
> Still an issue with 1.0.9-1 -- please fix this.

Thanks for the reminder! Please accept my apologies for having
overlooked your patches for weeks. I'll try to fix this as soon as
possible.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#837728: New Heimdal RC

[Jelmer Vernooij]

Just a quick update to this bug: some awesome people upstream (thanks!) have
taken on the effort of getting another Heimdal release out. A RC has been
pushed out, and hopefully a final 7 release will follow before the end of the 
year.

Unfortunately, with the release schedule for Debian being what it is, the
timing is far from ideal [1].

[1] The irony is that the impending removal of Heimdal from Debian
highlighted the urgency for upstream of getting a release out.

Bug#846622: debootstrap: refers to log that is already deleted

[Cyril Brulebois]

Control: severity -1 normal

Hi,

Ritesh Raj Sarraf  (2016-12-02):
> Here's a case. debootstrap operation has failed.

A reproducer would be welcome.

> Now debootstrap mentions to look at the logs to determine the cause
> of the failure. But this log file is inside the chroot. The same
> chroot that debootstrap removes as part of cleanup, because of the
> failure.

There's the --keep-debootstrap-dir option, to avoid the cleanup.

> So even before the user could act of the message, it is already
> deleted. debootstrap should put the log in an absolute path on the
> Host OS.

debootstrap's working inside a specific directory and not outside seems
like a reasonable approach to me, but I suspect the error message could
be a bit more helpful here.

See logic around $TARGET/var/log/bootstrap.log (cp/mv) in debootstrap.


KiBi.


signature.asc
Description: Digital signature

Bug#840652: any status on this?

[Sandro Knauß]

Hi,

so I created a first set of patches to get rid of kf5gpgmepp.
Just to make it super clear if I talk about kf5gpgmepp I mean [0], 
if I say GpgME is mean [1], that inclued Gpgmepp and QGpgME).

* kwallet-kf5 - is fixed
   ( the support of GppME >= 1.7.1 is already provided by upstream)
* messagelib/kdepim/kleopatra:
   I created a patch to get rid of direct dependency of kf5gpgmepp

messagelib[debian/sid] 16da74f8b884e02a2835c6c1c92f8c2041aa27a1
kdepim[debian/sid] fe28dd2cc76a4c13b5f214fb8d024a529bf2bb9c
kleopatra[debian/sid] f5bf98dabe305aa781eb43abcc0c345bd265a38d

sune/maxy: please review

the tricky part is libkleo. Because parts of libkleo the moved into QGpgME,
and we have changes of boost::shared_ptr -> std::shared_ptr and other such
kind of changes. I created a patch to compile libkleo on its own without 
Kf5Gpgme.
But if I try to use this libkleo to build messagelib it fails :(

libkleo[dev/hefee] ee3cae709395e14070cdc9b7979771029d576b16

buildlof of messagelib:
[...]
/<>/messagecomposer/src/composer/keyresolver.cpp: In function 
'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)':
/<>/messagecomposer/src/composer/keyresolver.cpp:119:75: error: 
'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)' redeclared as different 
kind of symbol
 static inline bool ByKeyID(const GpgME::Key &left, const GpgME::Key &right)
   ^
In file included from /usr/include/gpgme++/key.h:27:0,  
 from /usr/include/KF5/libkleo/keyapprovaldialog.h:45,  
 from /usr/include/KF5/Libkleo/KeyApprovalDialog:1,
 from 
/<>/messagecomposer/src/composer/keyresolver.h:41,
 from 
/<>/messagecomposer/src/composer/keyresolver.cpp:37:
/usr/include/gpgme++/key.h:426:1: note: previous declaration 
'template class Op> struct ByKeyID'
 GPGMEPP_MAKE_STRCMP(ByKeyID, .keyID());
 ^   
messagecomposer/src/CMakeFiles/KF5MessageComposer.dir/build.make:917: recipe 
for target 
'messagecomposer/src/CMakeFiles/KF5MessageComposer.dir/composer/keyresolver.cpp.o'
 failed


At least one questino from my side, if we update all fist dependencies to not
use gpgmepp, we would also need to recompile the second level of dependencies
 (f.ex. libkleo->messagelib->kdepim). This is normally handled by a transition,
but now we have transitions freeze... So how we get rid of kf5gpgmepp for
stretch smoothly( after we found a way to handle libkleo)?

Best Regards,

sandro

[0] KF5Gpgmepp: https://tracker.debian.org/pkg/gpgmepp
[1] GpgME: https://tracker.debian.org/pkg/gpgme1.0

--
Am Montag, 28. November 2016, 23:39:50 CET schrieb Daniel Kahn Gillmor:
> Hi Qt/KDE maintainers--
> 
> Any status on https://bugs.debian.org/840652 ?  If we could remove the
> gpgmepp source package from the archive, it will help us make stretch
> more maintainable.
> 
> I understand that we might not be able to remove kdepimlibs due to qt4
> remaining in the archive, but i think even having two co-installable
> versions of gpgmepp in stretch would be better than having three
> co-installable versions.
> 
>--dkg



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

Bug#846895: libfile-stripnondeterminism-perl: Treat .par files as Zip archives

[Anders Kaseorg]

Package: libfile-stripnondeterminism-perl
Version: 0.028-1
Tags: patch

.par files are Zip archives 
(http://search.cpan.org/~rschupp/PAR-Repository-0.21/lib/PAR/Repository/Zip.pm).

This patch should allow barnowl to build reproducibly.

---
 lib/File/StripNondeterminism.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/File/StripNondeterminism.pm b/lib/File/StripNondeterminism.pm
index 8648a3c..cc36bcb 100644
--- a/lib/File/StripNondeterminism.pm
+++ b/lib/File/StripNondeterminism.pm
@@ -100,7 +100,7 @@ sub get_normalizer_for_file {
  
\&File::StripNondeterminism::handlers::javaproperties::normalize;
}
# zip
-   if (m/\.(zip|pk3|epub|whl|xpi|htb|zhfst)$/
+   if (m/\.(zip|pk3|epub|whl|xpi|htb|zhfst|par)$/
&& _get_file_type($_) =~ m/Zip archive data|EPUB document/) {
return \&File::StripNondeterminism::handlers::zip::normalize;
}
-- 
2.11.0

Bug#846788: neovim-runtime: man plugin breaks startup

[James McCoy]

On Sat, Dec 03, 2016 at 08:10:24PM +0100, Philipp Marek wrote:
> Hmmm..
> I had a
> 
> runtime ftplugin/man.vim
> 
> in ~/.config/nvim/init.vim, but up to and including 0.1.6-5 that never 
> hurt. Commenting that line out makes 0.1.7 work too.
> 
> I bind "K" to ":Man"; guess that I got it from one of the various sites 
> recommending that...
> https://www.google.at/search?q="runtime+ftplugin/man.vim";

Those are referring to Vim's man.vim.  Neovim's is a complete rewrite,
which specifically removed the need to load the ftplugin just to be able
to use :Man.

> So, the priority isn't that high (anymore) - but still, it's a regression, 
> and might hurt a few people.

Yeah, I thought there had been an effort to avoid causing problems in
those scenarios.  I'll take a look.

> Thanks for pointing me in the right direction. I know that I did test with 
> "-U", but it seems that nvim doesn't have that anymore and just ignores it.

Well, -U controls loading of the gvimrc, which doesn't exist.  -u
controls loading of the vimrc or init.vim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#845982: cwltool accesses internet -- missing dependency

[Kevin Murray]

Hi,

I had a look at the build of cwltool, and it appears it depends upon the
`keepalive` python package. I will file an RFS bug for this (and prepare a
package as time permits).

Cheers,
K

---
Kevin Murray

Bug#846863: /usr/bin/debuild: debuild: pass lintian options to dpkg-buildpackage

[James McCoy]

On Sat, Dec 03, 2016 at 07:56:00PM +, Niels Thykier wrote:
> On Sat, 03 Dec 2016 20:49:34 +0100 Vincent Danjean 
> wrote:
> >   debuild is passing lintian options to dpkg-buildpackage which, of course, 
> > do
> > not recognize these options and fail:
> > 
> > [...]
> > 
> >   The --display-info option, after the --lintian-opts option, should not be
> > passed to dpkg-buildpackage but, instead, kept and passed to lintian 
> > itself. 
> 
> FYI, dpkg-buildpackage has a --check-command + --check-option now to run
> lintian (with given arguments).  It is available since dpkg 1.17 (i.e.
> stable).  So technically, dpkg-buildpackage supports it (if wrapped with
> a --check-command). :)

Which is what debuild should be doing automatically, to preserve
debuild's interface.  I must've botched something there.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#846385: [Pkg-gmagick-im-team] Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[Antonio Terceiro]

On Thu, Dec 01, 2016 at 03:55:02PM +0100, roucaries bastien wrote:
> On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
>  wrote:
> > Package: imagemagick
> > Version: 6.9.9.6+dfsg-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > We recently merged imagemagick 6.9.9.6+dfsg-1 in Ubuntu 17.04; however
> > we see autopkgtest failures in ruby-rmagick and php-imagick with this
> > version (note that Debian is seeing similar failures).
> >
> > At least for ruby-rmagick, it seems like (possibly) upstream made an ABI
> > change without bumping the SONAME for libmagickcore, and ruby-rmagick
> > ends up pulling in the wrong dependency
> > (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz).
> >
> > More specifically, we are building against imagemagick
> > 8:6.9.6.6+dfsg-1ubuntu2:
> > https://launchpadlibrarian.net/295470626/buildlog_ubuntu-zesty-arm64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz.
> >
> > During the build, the tests pass succesfully (using the above version of
> > imagemagick), but you can see that the the resulting binary package has
> > dependencies that are more relaxed than that specific version:
> >
> >  Depends: ruby (>= 1:2.3~0), libc6 (>= 2.17), libmagickcore-6.q16-2 (>= 
> > 8:6.8.8.9), libruby2.3 (>= 2.3.0~preview2)
> >
> > Therefore, when the autopkgtest runs:
> > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz,
> > imagemagick 8:6.8.9.9-7ubuntu9 is used, and a segmentation fault occurs.
> >
> > Thanks to Marc Deslauriers' research, it seems like there might have
> > been at least one ABI breakage upsream in libmagickcore:
> > https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html,
> > which might be related.
> >
> > What is your opinion on this as the Debian maintainer? Should the SONAME
> > be bumped and symbols files be updated?
> 
> Some detail:
> *  GetDefaultOpenCLEnv is not a problem because opencl is disable on debian
> * struct _DrawInfo (1) is not a problem from a C point of view because
> it should be set and destry by API function. It is a opaque object. So
> no need to so bump for this

I don't think that is the case.

After initializing a _Drawinfo struct, ruby-rmagick needs to operate on
it, by assigning values to its fields. So unless I am missing some API
in imagemagick to set fields of _Drawinfo, it is *not* opaque for API
users. If the structure size changes without a proper SONAME bump, this
*will* cause segfaults.

Please reconsider this, and do SONAME bumps when there are ABI
changes.

> *  _ElementReference (1) is part of _Drawinfo so not a problem
> * _GradientInfo (3) is the same
> * For _image is an opaque type so it is the same
> 
> Now for interpreted language you may need the size of this kind of
> structure and thus need stricter dependencies or use at
> innitialisation a runtime check of imagesize returned by
> AcquireImage() function.

See above.


signature.asc
Description: PGP signature

Bug#793134: Packaging of newest upstream version in progress

[Felix Lechner]

Uploaded and pending in NEW.


On Fri, Dec 2, 2016 at 12:11 AM, Nobuhiro Iwamatsu 
wrote:

> Hi,
>
> > Newest version will be uploaded soon. Upstream is reviewing configured
> > ciphers and options.
>
> ping?
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>

Bug#846894: bgoffice-computer-terms: VCS links are dead

[Robbie Harwood]

Package: bgoffice-computer-terms
Severity: normal

Dear Maintainer,

The VCS links for this package have stopped working.  Please update them to
your actual VCS.

Thanks!

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

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

Bug#846893: flac: please make the build reproducible (buildpath)

[Dafydd Harries]

Package: libflac-doc
Version: 1.3.1-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath

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

In particular, the generated file doc/FLAC.tag captures the path of the build
directory. The attached path modifies the file to use the install path instead.

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

Regards,

Daf
>From 0533326767646c6970bca03f895af81c75c05baf Mon Sep 17 00:00:00 2001
From: Dafydd Harries 
Date: Sat, 3 Dec 2016 16:58:53 -0500
Subject: [PATCH] remove build path from generated FLAC.tag file

Use sed to update paths to point to locations in /usr/include rather than
locations in the source directory at build time.
---
 doc/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 4681bf8..8fc5172 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -25,6 +25,7 @@ FLAC.tag: Doxyfile
 	rm -rf html/api
 	mv doxytmp/html html/api
 	rm -rf doxytmp
+	sed -ie 's,>.*/include/,>/usr/include/,' FLAC.tag
 else
 FLAC.tag:
 	touch $@
-- 
2.9.3

Bug#846891: integrit: please make the build reproducible (fileordering)

[Valerie R Young]

Package: integrit
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

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

The attached patch sorts the md5sums files. Once applied,
along with the other reproducible patched pending on integrit ,
integrit can be built reproducibly in our current experimental framework.

Best,
Valerie

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

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

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

--- implicit	2016-12-03 17:05:39.0 -0500
+++ implicit	2016-12-03 17:57:02.682034599 -0500
@@ -87,7 +87,7 @@
 	: debian/$*/DEBIAN/md5sums
 	@rm -f debian/$*/DEBIAN/md5sums
 	@cd debian/$* && find * -path 'DEBIAN' -prune -o \
-	  -type f -exec md5sum {} >>DEBIAN/md5sums \;
+	  -type f -exec md5sum {} \; | LC_ALL=C sort >>DEBIAN/md5sums
 %.deb-DEBIAN: %.deb-checkdir %.deb-DEBIAN-base %.deb-DEBIAN-scripts \
 	  %.deb-DEBIAN-md5sums
 	: debian/$*/DEBIAN/ ok

Bug#846892: pkg-mozilla-archive-keyring: build generates a keybox file instead of a gpg transferable key

[Clint Adams]

Package: pkg-mozilla-archive-keyring
Version: 1.1
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

With gnupg 2 as the default, the $(KEYRING) target in debian/rules
generates a GPG keybox database version 1 instead of an RFC4880
OpenPGP Transferable Key, or "GPG key public ring".

All of the other keyrings in /etc/apt/trusted.gpg.d or /usr/share/keyrings
are in the latter format.

Also I suspect that this has an effect on the package's reproducibility
but I'm unsure because `kbxutil --cut` doesn't do what I expected it
to do.

Two ways this could be changed are

1) gpg --dearmor -o $@ $<

2) hot dearmor < $< > $@

Bug#808784: Refresh the xserver-xorg-video-openchrome package

[Dylan]

Hi the Debian X Strike Force team,
The package of xserver-xorg-video-openchrome is quite outdated, with
the reborn of openchrome project and the approaching of the Debian
Freeze, it could be great to refresh the package.

Since the package is RFA, I propose myself to update this package,
maybe not to adopt in a first time. Let's see how I deal with it.
Moreover, I don't have access to a supported hardware so a
(co-?)maintainer with the hardware should be better.

I am only DM, so I will need sponsor for this package. I have already
started to update the package [1].

Best regards,
Dylan

[1] https://bitbucket.org/Dybian/openchrome/

Bug#846890: ipsvd: please make the build reproducible (fileordering)

[Valerie R Young]

Package: ipsvd
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

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

The attached patch sorts the md5sums files. Once applied,
along with the other reproducible patched pending on ipsvd :),
ipsvd can be built reproducibly in our current experimental framework.

Best,
Valerie

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

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

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

--- implicit	2016-12-03 17:51:36.201566371 -0500
+++ implicit	2016-12-03 17:51:04.081699831 -0500
@@ -87,7 +87,7 @@
 	: debian/$*/DEBIAN/md5sums
 	@rm -f debian/$*/DEBIAN/md5sums
 	@cd debian/$* && find * -path 'DEBIAN' -prune -o \
-	  -type f -exec md5sum {} >>DEBIAN/md5sums \;
+	  -type f -exec md5sum {} \; | LC_ALL=C sort >>DEBIAN/md5sums
 %.deb-DEBIAN: %.deb-checkdir %.deb-DEBIAN-base %.deb-DEBIAN-scripts \
 	  %.deb-DEBIAN-md5sums
 	: debian/$*/DEBIAN/ ok

Bug#846861: layout is not displayed correctly

[Egmont Koblinger]

I've halved all the size numbers in the config, and it still appears
perfectly for me (now the overall window is a "regular" window, smaller
than the screen in both dimensions).

Just for the record: What is your desktop environment / window manager?

thx,
egmont

Bug#846889: gnupg2: FTBFS on hppa - Please don't link static version with -pie on hppa

[John David Anglin]

Source: gnupg2
Version: 2.1.16-2
Severity: normal

Dear Maintainer,

The build fails here:

make[2]: Entering directory '/<>/build-gpgv-static/g10'
gcc -Wall -Wno-pointer-sign -Wpointer-arith  -g -O2 
-fdebug-prefix-map=/<>=. -Wformat -Werror=format-security  -pie 
-static -o gpgv gpgv.o build-packet.o compress.o  free-packet.o getkey.o 
keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o 
progress.o misc.o rmd160.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o 
sig-check.o keylist.o pkglue.o ecdh.o verify.o ../kbx/libkeybox.a 
../common/libcommon.a ../common/libgpgrl.a -lz-lgcrypt 
-L/usr/lib/hppa-linux-gnu -lgpg-error
/usr/bin/ld: /usr/lib/gcc/hppa-linux-gnu/6/crtbeginT.o: relocation 
R_PARISC_DPREL21L can not be used when making a shared object; recompile with 
-fPIC
/usr/lib/gcc/hppa-linux-gnu/6/crtbeginT.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:788: recipe for target 'gpgv' failed

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=hppa&ver=2.1.16-2&stamp=1479760527

The build will complete successfully if "-pie" is removed from the following
line in debian/rules:
cd build-gpgv-static/g10 && $(MAKE) LDFLAGS="$$LDFLAGS -pie -static" gpg
v

PIE support is not well tested on hppa.  Further, gcc on hppa is not built
with --enable-pie-default.  So, archive libraries and executable code are
not built by default with -fPIE.  So, in general, linking with -pie and -static
isn't going to work.

As things stand, the crt* files in gcc are not position independent except
for the shared versions.  They would be if gcc was built with 
--enable-pie-default.

There is also an issue that the startup file from glibc is not position
independent on hppa.

So, for now, I think the best approach is to remove "-pie" from the above
statement on hppa.

Regards,
Dave Anglin


-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.8.12+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#846888: depmod crashes after detecting a dependency cycle

[Ben Hutchings]

Package: kmod
Version: 23-1
Severity: normal

In this build log:


https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=4.9~rc7-1~exp1&stamp=1480766537

the initial error messages are:

depmod: ERROR: Found 8 modules in dependency cycles!
depmod: ERROR: Cycle detected: remoteproc -> virtio
depmod: ERROR: Cycle detected: remoteproc -> virtio_ring
depmod: ERROR: Cycle detected: qcom_mdt_loader -> remoteproc
*** Error in `depmod': free(): invalid next size (fast): 0x0055bf918060 
***

I assume that the dependency cycle is real and this needs to be
fixed in the kernel, but depmod shouldn't crash while reporting
this.

Ben.

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

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

Versions of packages kmod depends on:
ii  libc6 2.24-7
ii  libkmod2  23-1
ii  lsb-base  9.20161125

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

Bug#846861: layout is not displayed correctly

[Egmont Koblinger]

Hi,

I cannot reproduce this issue on Ubuntu 16.10 with Terminator-1.90 using
your config. I get a terminator window occupying the entire screen, with
2x2 terminals in an equal split.

Your config seems to contain hardcoded pixel values like 3200, 1672,
1600... The exact behavior might easily depend on their relation to the
actual screen size.

What's your screen size? My one is 1920x1080.

e.

Bug#846887: gitlab:backup:create fails with undefined method `zero?' for nil:NilClass

[Johannes Schauer]

Package: gitlab
Version: 8.13.3+dfsg1-2
Severity: important

Hi,

in an effort to fix the problem I reported as #845935, I thought I'd try
to backup my installation, do a fresh install in a completely new and
clean container and restore the backup there. Unfortunately, that plan
failed because gitlab was unable to create a backup. It quit with:

# su gitlab
$ cd /usr/share/gitlab
$ export $(cat /etc/gitlab/gitlab-debian.conf)
$ rake gitlab:backup:create RAILS_ENV=production --trace
[...]
 * debian-bootstrap/bootstrap ... [DONE]
 * debian-bootstrap/bootstrap.wiki ...  [SKIPPED]
 * debian-bootstrap/bootstrap_debian_net ... [DONE]
 * debian-bootstrap/bootstrap_debian_net.wiki ...  [SKIPPED]
 * debian-bootstrap/botch ... [DONE]
 * debian-bootstrap/botch.wiki ...  [DONE]
 * debian-bootstrap/botch-tests ... rake aborted!
NoMethodError: undefined method `zero?' for nil:NilClass
/usr/share/gitlab/lib/backup/repository.rb:19:in `block in dump'
/usr/lib/ruby/vendor_ruby/active_record/relation/batches.rb:51:in `block (2 
levels) in find_each'
/usr/lib/ruby/vendor_ruby/active_record/relation/batches.rb:51:in `each'
/usr/lib/ruby/vendor_ruby/active_record/relation/batches.rb:51:in `block in 
find_each'
/usr/lib/ruby/vendor_ruby/active_record/relation/batches.rb:124:in 
`find_in_batches'
/usr/lib/ruby/vendor_ruby/active_record/relation/batches.rb:50:in `find_each'
/usr/lib/ruby/vendor_ruby/active_record/querying.rb:9:in `find_each'
/usr/share/gitlab/lib/backup/repository.rb:8:in `dump'
/usr/share/gitlab/lib/tasks/gitlab/backup.rake:72:in `block (4 levels) in '
/usr/lib/ruby/vendor_ruby/rake/task.rb:240:in `block in execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:172:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:165:in `invoke'
/usr/share/gitlab/lib/tasks/gitlab/backup.rake:12:in `block (3 levels) in '
/usr/lib/ruby/vendor_ruby/rake/task.rb:240:in `block in execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:235:in `execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:172:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:165:in `invoke'
/usr/lib/ruby/vendor_ruby/rake/application.rb:150:in `invoke_task'
/usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `block (2 levels) in 
top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `each'
/usr/lib/ruby/vendor_ruby/rake/application.rb:106:in `block in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:115:in `run_with_threads'
/usr/lib/ruby/vendor_ruby/rake/application.rb:100:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:78:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:176:in 
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:75:in `run'
/usr/bin/rake:27:in `'
Tasks: TOP => gitlab:backup:repo:create


What can I do?

Thanks!

cheers, josch

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[Matthias Klose]

On 03.12.2016 22:04, John Paul Adrian Glaubitz wrote:
> On 12/03/2016 10:02 PM, Andreas Schwab wrote:
>>> patching file src/gcc/ada/s-memory.adb
>>> Hunk #1 FAILED at 47.
>>> Hunk #2 succeeded at 113 (offset 13 lines).
>>> 1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
>>> patching file src/gcc/ada/s-memory.ads
>>
>> According to PR48835, this is no longer necessary.
> 
> Ah, thanks for letting us know. I was already suspecting that, but I didn't
> have the time yet to verify it.
> 
> @Matthias:
> 
> Do you agree that we can drop this particular patch then?

Adrian, I would appreciate if you could look at a package first before calling
for actions, and then ask a complete question. We also have the
m68k-revert-pr45144 patch in the build which apparently needs some decision.

Thanks, Matthias

Bug#840424: RFS: verilog-mode

[Sean Whitton]

Dear Kiwamu,

On Fri, Nov 25, 2016 at 09:41:16PM +0900, Kiwamu Okabe wrote:
> On Sun, Nov 20, 2016 at 5:15 AM, Sean Whitton  
> wrote:
> > Thank you for your work to bring this new package to Debian!  As I said,
> > I can't sponsor the upload, but I hope this more detailed review is
> > useful to you.
> 
> Of course, your precisive review is very useful for me. Thanks.

Just a few more things and it will be ready for upload :)

After you make changes, you need to run `dch -r` to update the timestamp
in d/changelog.

> > 1. The line "Only support emacs and xemacs" doesn't make sense (what
> > else would you be supporting?).  What were you trying to say?
> 
> Fixed. It's my simple mistake. I should say "Support emacs and xemacs."

In that case, I think you should just delete that line altogether.
Normally, uploads of new packages have a changelog entry with only a
single line, closing the ITP.

> > 2. There is a Lintian error:
> >
> > E: verilog-mode: info-document-missing-dir-section 
> > usr/share/info/verilog.info.gz
> 
> You are right. I miss it out. It's fixed by
> debian/patches/fix-dircategory.patch.
> The patch is pull-requested to upstream:
> 
> https://github.com/veripool/verilog-mode/pull/13

Good work.  Please add a DEP-3 patch header, including a Forwarded:
field to show that the patch has been forwarded upstream.

> > 3. Some files are not GPL-3+.  For example,
> > tests/auto_delete_whitespace.v.  Please check every file's copyright
> > status and detail in d/copyright.
> 
> The debian/copyright is updated.

The copyright for Makefile is still not correct.

> > 5. You've missed some steps of the Emacs policy.[1]  For example, you
> > are missing a emacsen compat level.  Please check the policy carefully.
> >
> > [1] https://www.debian.org/doc/packaging-manuals/debian-emacs-policy
> 
> I added "verilog-mode.emacsen-compat" file.
> And I think that there are no other violation.

Looks good.

> > 3. You are generating ChangeLog.txt but not installing it.  You can use
> > dh_installchangelogs(1).
> 
> I think it's not useful.

Agreed.  Thank you for confirming.

> > 4. How about installing verilog-lex.el as an example?  See
> > dh_installexamples(1).  Or possibly somewhere else.
> 
> Sorry. I can't understand why it becomes as example,
> because I'm not a expert for both Emacs and Verilog.

It has a function `verilog-lex' which might be useful to someone.

Maybe it would be better to install it with the other *.el files, and
bytecompile it?  I'm not sure what I was thinking when I suggested
installing it as an example.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#846886: RM: jakarta-taglibs-standard -- ROM; replaced by taglibs-standard

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the jakarta-taglibs-standard package, its binary packages
libjakarta-taglibs-standard-java and libjstl1.1-java are no longer used
and have been replaced by libtaglibs-standard-spec-java and 
libtaglibs-standard-impl-java.

Thank you,

Emmanuel Bourg

Bug#840610: UnicodeEncodeError: 'ascii' codec can't encode character

[Matthias Klose]

Control: severity -1 important

On 16.10.2016 00:34, Kalle Olavi Niemitalo wrote:
> Robert Luberda  writes:
> 
>> According to GNU gettext documentation[1]: "The variable LANGUAGE is
>> ignored if the locale is set to ‘C’."
> 
> That exception was added on 2001-01-03, for glibc 2.2.1.
> In glibc 2.2, LANGUAGE used to override LC_ALL=C.
> 
> In Python 2.0 (released on 2000-10-16), 2.7, and 3.5.0, gettext.py
> checks LANGUAGE first, like glibc 2.2.  The loop that checks the
> environment variables is exactly the same in these three versions.
> 
> I searched for "gettext" at bugs.python.org but it didn't find a
> bug report for the priority of LANGUAGE vs. LC_ALL=C in gettext.
> http://bugs.python.org/issue1166948 says 'LANGUAGE is honoured
> even if the default locale is "C"' but I think that refers to
> locale.getdefaultencoding, not to gettext.

I looked at recent behavior changes for that in the updates after the 3.5.2
release, but couldn't find one.   It would be good to have a self-contained
example to show the exact issue.

Bug#230990: Changing libncurses SONAME

[Thomas Dickey]

On Wed, Nov 30, 2016 at 08:54:02PM +0100, Sven Joachim wrote:
> On 2012-01-22 10:58 +0100, Sven Joachim wrote:
> 
> > tags 230990 + help
> > thanks
> >
> > On 2005-06-12 17:20 +0200, Daniel Jacobowitz wrote:
> >
> >> On Tue, Feb 03, 2004 at 03:06:45PM -0500, Daniel Burrows wrote:
> >>>   It would be nice if the ncurses mouse API could be used to track wheel
> >>> events.  (reported in X11 as buttons 4/5)  At the moment, ncurses seems
> >>> to report all wheel events as button 4.
> >>
> >> FYI, the latest version of ncurses (uploading soon) does support this -
> >> but it's disabled, because the change is binary incompatible.  The next
> >> time we need a new SONAME for libncurses, I intend to enable this.
> >
> > Unfortunately, switching SONAME seems to be out of the question since
> > even after the introduction of libtinfo5 we still have dozens of
> > libraries linking against libncurses.  My feeble attempt to fix a few
> > of them has not changed anything yet.
> >
> > The only safe way to do this seems to be to introduce versioned symbols
> > in ncurses, and I don't know at all how to do that in a way which
> >
> > a) is acceptable for upstream;
> >
> > b) works correctly for all the bazillion configuration options that
> >change the ABI, for instance "--enable-widec", "--enable-ext-colors",
> >"--enable-ext-mouse", "--with-termlib=...", "--with-ticlib=..." etc.
> 
> Fortunately this has all been done by upstream in the meantime, the
> ncurses package in Debian uses versioned symbols[1], and all reverse
> dependencies in testing have been rebuilt[2].  So the long requested
> soname bump can finally happen after the Stretch release. :-)
> 
> Before I start working, there are some things which should be decided.
> 
> - Right now we ship both wide and non-wide versions of the libraries and
>   the -dev packages, with the ncursesw headers shipped in a separate
>   directory.  This leads to problems where reverse dependencies use the
>   wrong headers, see [3] for an example, and I want to change it.
> 
>   There are two possibilities here:
> 
>1. Install the headers for the wide libraries only, and use them for
>   the non-wide libraries.  This is expected to work and is what
>   Fedora has been doing for a long time, but there seem to be a few
>   compatibility problems in the ncurses 6 API[4].

The problem is that ncurses6 uses extended color information which can't
fit into chtype's (the basis of non-wide ncurses5).  That makes it use
cchar_t's (which are the basis of wide ncurses5/ncurses6).

The Red Hat bug report points out that the macros which use details of
the WINDOW structure are a problem which prevents using the headers as-is
between the three flavors (ncurses5 normal/wide and ncurses6).  In a quick
review of curses.h, those are

wattrset
wattr_set
wattr_get

If the macros are not available, the library provides functions for
each of those macros.  The performance impact for using the functions
rather than the macros may not be that high.
 
>2. Remove the non-wide libraries altogether and link everything with
>   ncursesw.  This is what Archlinux is doing.  The packaging becomes
>   much simpler, but programs who don't need wchar support will use
>   more memory[5].
> 
>   I'm leaning towards option 1, but this is something that could be
>   discussed on a wider audience (e.g. debian-devel).
> 
> - Should we continue to distribute separate debugging libraries? Nobody
>   else does that, apparently.
> 
> - The multilib packages have been a constant source of bugs and are
>   considered unsupportable by the dpkg maintainer[6], I want to get rid
>   of them.  Reverse dependencies are grub-legacy and readline whose
>   multilib packages don't have any reverse dependencies themselves.
> 
> - Should we continue to ship libncurses5 and libncursesw5 packages?  As
>   long as upstream supports building them, this might make sense.

I've no intention of breaking the ncurses5 stuff (keeping in mind that
LSB specifies ABI 5...).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#846664: [Debian-med-packaging] Bug#846664: Bug#846664: src:adapterremoval: New version available

[Kevin Murray]

Hi all,

On 07:52 03/12, Andreas Tille wrote:
> Hi,
> 
> there is a new upstream version of adapterremoval.  I have deactivated
> the attempt to create an adapterremoval-benchmark package for the moment
> so feel free to upgrade to the latest upstream version if you like to.

I've now prepared the package of the latest upstream release, so a review &
upload would be required. Thanks in advance!

Cheers,
K

---
Kevin Murray

Bug#844746: jessie-pu: package ca-certificates/20141019+deb8u2

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-11-20 at 15:38 +, Jonathan Wiltshire wrote:
> Control: tag -1 + confirmed
> 
> On Fri, Nov 18, 2016 at 09:57:13AM -0600, Michael Shuler wrote:
> > I would like to upload ca-certificates to stable to bring the Mozilla CA
> > bundle up to the current version 2.9 and fix one important bug, #825730
> > "using --noawait triggers breaks downloader packages". The stable
> > debdiff is attached.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#846648: chromium: Chromium still "Aw, Snaps" on many websites

[Benjamin FRANCOIS]

Package: chromium
Version: 55.0.2883.75-1
Followup-For: Bug #846648

I confirm, it's now worse than ever. Scrolling all the way down of this article 
randomly leads to the "Aw, snap" error for no apparent reason.

http://www.lemonde.fr/pixels/article/2016/06/23/super-mario-64-etait-d-une-philosophie-toute-differente-immense-audacieux-un-peu-fou_4956739_4408996.html

And it's crashing all tabs at once :(



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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.1-1
ii  libavformat577:3.2.1-1
ii  libavutil55  7:3.2.1-1
ii  libc62.24-7
ii  libcairo21.14.6-1.1
ii  libcups2 2.2.1-2
ii  libdbus-1-3  1.10.14-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libexpat12.2.0-1
ii  libflac8 1.3.1-4
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.2.1-5
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libharfbuzz0b1.2.7-1+b1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8
ii  libnettle6   3.3-1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.26-2
ii  libpulse09.0-5
ii  libre2-3 20161101+dfsg-2
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.2.1-5
ii  libvpx4  1.6.0-3
ii  libwebp6 0.5.1-3
ii  libwebpdemux20.5.1-3
ii  libx11-6 2:1.6.3-1
ii  libx11-xcb1  2:1.6.3-1
ii  libxcb1  1.12-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  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1.1
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.29-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
ii  chromium-l10n  55.0.2883.75-1

-- no debconf information

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> I notice the autobuilders work, the ci.debian.org builders work, but
> the reproducable build builders do not.  No idea what the difference
> is.

This is not quite accurate.  All autobuilders except the x32 one work.
And only of of the two amd64 autobuilders for the reproducable build
work, the other fail due to missing perf access.

The new message explain the problem quite nicely.  I suggest we close
this bug as fixed with the new message, as we can not really "fix" coz
to work without the kernel feature it require to do the profiling.  The
message look like this (from the second reproducable build on amd64):

  Failed to open perf event. Consider tweaking
  /proc/sys/kernel/perf_event_paranoid to 2 or less (current value is
  3), or run coz as a privileged user (with CAP_SYS_ADMIN).

I guess it could be made clearer, but it contain enough to google up an
explanation about what is going wrong.

I found https://lkml.org/lkml/2016/7/27/305 > providing some
background information about the value 3.  Apparently is block "all
access to performance events by users without CAP_SYS_ADMIN", and is the
default in Debian and Android.

-- 
Happy hacking
Petter Reinholdtsen

Bug#846770: gridengine: FTBFS: cc: error: libsched.a: No such file or directory

[Afif Elghraoui]

Control: tag -1 + moreinfo unreproducible

Hello,

على السبت  3 كانون الأول 2016 ‫00:46، كتب Lucas Nussbaum:
> Source: gridengine
> Version: 8.1.9+dfsg-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161202 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> cc -o qmod -L. -Wl,-z,relro -rdynamic -Wl,-rpath,\$ORIGIN/../../lib/lx-amd64 
>>  qmod.o sig_handlers.o usage.o sge_options.o -lgdi -lsgeobj -lsgeobjd -lcull 
>> -lcomm -lcommlists -luti  -lmunge -lssl -lcrypto  -luti -ldl  -lm -lpthread 
>> -ljemalloc -lmunge
>> cc: error: libsched.a: No such file or directory
>> cc -o qevent -L. -Wl,-z,relro -rdynamic 
>> -Wl,-rpath,\$ORIGIN/../../lib/lx-amd64  qevent.o  usage.o sig_handlers.o 
>> sge_options.o sge_mt_init.o -lmir -levc -lgdi -lsgeobj -lsgeobjd -lcull 
>> -lcomm -lcommlists -luti  -lmunge -lssl -lcrypto  -luti -ldl  -lm -lpthread 
>> -ljemalloc -lmunge
>> ../daemons/common/Makefile:94: recipe for target 'pdc' failed
>> make[2]: *** [pdc] Error 1
> 
> The full build log is available from:
>http://aws-logs.debian.net/2016/12/02/gridengine_8.1.9+dfsg-3_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
I have just tried a parallel build on an up-to-date unstable chroot on
amd64 and it builds just fine for me. Can you confirm?

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#839615: libelfin: Library do not work with clang

[Petter Reinholdtsen]

Control: blocked -1 by 797038

This problem has solved itself, according to
https://ci.debian.net/packages/libe/libelfin/unstable/amd64/ >.
The automatic checking indicate that it was fixed when clang migrated
from version 1:3.6-33 to 1:3.8-34.  A closer look in the changelog make
me believe it was fixed in this version of clang:

llvm-toolchain-3.8 (1:3.8.1-6) unstable; urgency=medium

  * Ship libFuzzer in its own package (libfuzzer-X.Y-dev) (Closes: #820159)
  * Sync from Ubuntu. Many thanks to Matthias Klose
- drop-avx512-from-skylake.diff: Don't enable AVX512 on Skylake, as it's
  a server cpu feature and breaks llvmpipe on workstations.
- Remove the build tree before calling dh_strip; at least the amd64 buildd
  runs out of diskspace at this step.
- Add support for gcc's attribute abi_tag (needed for compatibility with
  GCC 5's libstdc++); taken from the trunk (Closes: #797038)
  (LP: #1510042, #1488254)
  D17567-PR23529-Sema-part-of-attrbute-abi_tag-support.diff
  D18035-PR23529-Mangler-part-of-attrbute-abi_tag-support.diff

 -- Sylvestre Ledru   Thu, 28 Jul 2016 11:15:04 +0200

A look at https://bugs.debian.org/797038 > confirm this.  Because
of this, I belive this issue should be closed.  I did consider
reassigning it to clang, but closing it seem like the approach causing
the least amount of noise.

-- 
Happy hacking
Petter Reinholdtsen

Bug#845682: closed by Vincent Danjean (Bug#845682: fixed in ocl-icd 2.2.10-1)

[Simon Richter]

Hi,

>  + clGetPlatformInfo is now taken is priority from the dispatch table
>(Closes: #845682)

clGetPlatformInfo from the dispatch table is safe only after
clGetPlatformInfo has returned that the ICD supports the cl_khr_icd
extension.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#845382: reported upstream

[Václav Ovsík]

https://bugs.freedesktop.org/show_bug.cgi?id=98987

Bug#846526: cloud-init: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Tiago Ilieve]

Hi Marcin,

On 3 December 2016 at 18:25, Marcin Kulis  wrote:
> I had a quick looks into file you've provided and the PT translation we 
> already
> have. I have some questions (sorry in advance if those are lame but I don't
> understand Portuguese almost at all).
> Are those two really so different? pt_BR.po looks slightly different but not 
> so
> much and for example line 102 for me looks like is not translated at all, do
> you want to keep it that way?
>
> If you're really happy with this po file I'll add it to the package and it
> probably will find it's way into the next cloud-init release.

As you may guess, I'm a native Portuguese speaker. The differences
between the original Portuguese (from Portugal) and Brazilian
Portuguese may be very subtle, which looks like to be the case here.

I've analyzed the diff[1] between `pt.po` and `pt_BR.po` and, although
there are lines that really should be translated to make sense for
Brazilian users, there are some which I'm not sure if they are
properly translated. I never really did a Portuguese -> Brazilian
Portuguese translation, so I may be biased to think that some
sentences should (or shouldn't) be changed.

-

Adriano,

Were this translation reviewed by debian-l10n-portuguese@l.d.o (I do
not follow that list)? I'll not suggest any changes here, as I do not
know how the translation team works. If they reviewed it indeed, we
can certainly include this file for the next release.

Regards,
Tiago.

[1]: https://paste.debian.net/900453/

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

Bug#794064: Confirmed

[D. B.]

I get this sometimes in unstable of today, even without automatic login
being enabled.

Did anyone ever find a fix? This can be hugely disruptive.

Sometimes messing around with the Ctrl+Alt+F1 etc works to get a working
login screen, but I don't think this always works, so sometimes, the
session is simply lost, which can be fatal.

Cheers

Bug#842369: closing as won't fix

[Matthias Klose]

Control: tags -1 + wontfix

closing as won't fix, not deviating from upstream.  please consider living with 
it.

Bug#846885: paxrat: Vcs-Git is incorrect

[Robbie Harwood]

Package: paxrat
Severity: minor
Tags: patch

Dear Maintainer,

The `Vcs-git:` field should point to a URL that can be checked out.  For this
package, the correct remote would be
https://anonscm.debian.org/git/collab-maint/paxrat.git

Thanks!

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

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

Bug#846884: cups-browsed: incomplete app armor profile

[Robert Fantini]

Package: cups-browsed
Version: 1.0.61-5+deb8u3
Severity: normal

Dear Maintainer,

 syslog was flooded with thousands of lines like this:

Mar 14 16:01:32 s022 kernel: [106968.865214] audit: type=1400 
audit(1457985692.167:106957): apparmor="DENIED" operation="connect" 
info="Failed name lookup - disconnected path" error=-13 
profile="/usr/sbin/cups-browsed" name="run/cups/cups.sock" pid=7006 
comm="cups-browsed" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

* I asked about this at proxmox forum [ thread: 
https://forum.proxmox.com/threads/cups-print-server-on-pve-floods-logs.26813/#post-134662
 ]

and was told:
 File a bugreport in the Debian bug tracker for the incomplete app armor 
profile, extend it locally yourself, don't use cups-browsed or don't confine it 
with apparmor (recommended in that order ;))


 uninstall cups-browsed stopped log flooding.


PS:
 if there is any more info needed ping me. 




-- System Information:
Debian Release: 8.6
  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)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#846683: Pending fixes for bugs in the libspring-java package

[pkg-java-maintainers]

tag 846683 + pending
thanks

Some bugs in the libspring-java package are closed in revision
adae00218715da9fd12381967929e55931606764 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libspring-java.git/commit/?id=adae002

Commit message:

No longer build spring-instrument-tomcat (obsolete) (Closes: #846683)

Bug#842374: closing as won't fix

[Matthias Klose]

Control: tags -1 + wontfix

closing as won't fix, not deviating from upstream.  please consider living with 
it.

Bug#846883: ITP: libsdp-api-java -- SDP API for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs 

* Package name: libsdp-api-java
  Version : 1.0
  Upstream Author : Daniel Pocock 
* URL : https://github.com/opentelecoms-org/java-sdp-api
* License : Apache 2.0
  Programming Lang: Java
  Description : SDP API for Java

SDP API Specification of JSR 141

The SDP API is an extended Java API used by a couple of projects,
e.g. ice4j, Jitsi, Apache Camel and others.

The JSR hasn't been updated for many years and this package mostly consists
of interfaces, it won't involve much maintenance, if any.

Bug#846882: libdrm2: wrong scale for backlight with Xfce

[Alain]

Package: libdrm2
Version: 2.4.73-1~bpo8+1
Severity: normal

The scale of change of the intensity of the backlight is wrong.
Changing this is done with the hot keys to increase or decrease.

The minimum get a black screen.
cat /sys/class/backlight/eeepc/brigthness
0
cat /sys/class/backlight/intel_backlight/brigthness
0

1st press on the hot key : get also a black screen.
cat /sys/class/backlight/eeepc/brigthness
1
cat /sys/class/backlight/intel_backlight/brigthness
79787

2nd press : get a medium intensity.
cat /sys/class/backlight/eeepc/brigthness
2
cat /sys/class/backlight/intel_backlight/brigthness
159374

3rd to 12th press get a normal change of the backlight.
To : 796875
But the intensity of the 12th is less than the 11th.

Expected :
The minimum should not light off the screen.
/sys/class/backlight/intel_backlight/brigthness
159374
>From /sys/class/backlight/eeepc/brigthness=1 to 10 or 12, the backlight 
should change linearly without light off.

This buggy behaviour was seen only with Xfce, not with lightdm or the Linux 
console.

The older libdrm and xserver-xorg work fine.

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

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

Versions of packages libdrm2 depends on:
ii  libc6  2.19-18+deb8u6
ii  multiarch-support  2.19-18+deb8u6

libdrm2 recommends no packages.

libdrm2 suggests no packages.

-- no debconf information

Bug#846881: ITP: libsip-api-java -- SIP API for Java

[Ingo Bauersachs]

Package: wnpp
Severity: wishlist
Owner: Ingo Bauersachs 

* Package name: libsip-api-java
  Version : 1.2
  Upstream Author : Daniel Pocock 
* URL : https://github.com/opentelecoms-org/java-sip-api
* License : Apache 2.0
  Programming Lang: Java
  Description : SIP API for Java

SIP API Specification of JSR 32

The SIP API is an extended Java API used by a couple of projects,
e.g. ice4j, Jitsi, Apache Camel and others.

The JSR hasn't been updated for many years and this package mostly consists
of interfaces, it won't involve much maintenance, if any.

Bug#846880: lintian: warn if B-D-A or B-D-I is used in sources without Arch:any or Arch:all packages, respectively

[Johannes Schauer]

Package: lintian
Version: 2.5.48
Severity: wishlist

Hi,

Using the Build-Depends-Arch header doesn't make sense if there are no
Architecture:any packages in debian/control. Conversely, using
Build-Depends-Indep doesn't make any sense if there are no
Architecture:all packages.

The situation where a maintainer would miss this can easily arise.
Picture the situation where the maintainer removes an Architecture:any
package from a debian/control that otherwise only has Architecture:all
packages. At this point, there should be no Build-Depends-Arch header,
because no architecture-specific binary packages are being built. But
this problem might easily go undetected by the maintainer as even if
they use sbuild or pbuilder, they might run full builds which in turn
will also install the B-D-A dependencies and thus let the build pass. If
now a source-only upload is done, it will fail on the Arch:all
autobuilders. This exact thing just happened to me.

It would be nice if lintian could detect this kind of problem before the
upload is done and building the package fails.

Unfortunately, implementing this *properly* might become a bit tricky.
Imagine this situation:

Source: foo
Build-Depends-Indep: blub 

Package: foo
Architecture: all
Build-Profiles: 

This package build depends on "blub" but only if the "stage1" profile is
active. But with the stage1 profile active, no Arch:all packages are
being built. Thus, lintian should throw a warning here about an
apparently wrong B-D-I header - it is of no use what-so-ever. A similar
example can be constructed with architecture restrictions instead of
build profiles.

Thanks!

cheers, josch

Bug#844246: ignores Route Preference in received router advertisements

[Marc Haber]

Hi Andreas,

I appreciate the work and detail you have put into this issue and
apologize for my flawed preparation of the bug report in advance.

On Thu, Nov 17, 2016 at 04:26:30PM +0100, Andreas Henriksson wrote:
> When *not* using networkd (ie. kernel ndisc handling) the route gets set
> up with preference medium though.

You're so right. I observed the issue on my personal notebook which is
the -only- system in my environment that does -not- run
systemd-networkd for its lack of WPA support. I therefore filed this
bug report against the wrong package. Feel free to close this.

>  I looked at the kernel code and ended up at
>  http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L1238 which
>  seems to explain why as I seem to (unintentionally) have:
> 
> $ cat /proc/sys/net/ipv6/conf/eth2/accept_ra_rtr_pref 
> 0

I observed the same and put
net.ipv6.conf.enp0s25.accept_ra_rtr_pref=1
in /etc/sysctl.conf. restarting systemd-sysctl made the 1 show up in
/proc until the next reboot, when it was zero again. restarting
systemd-sysctl made the 1 show up again. I guess that systemd-sysctl
is started too early.

Having the 1 in accept_ra_rtr_pref doesn't change the route priority
though, it still gets set up with priority medium.

It might be interesting as well that accept_ra_rtr_pref has a
functional default of "enabled" if accept_ra is enabled. I do have
accept_ra set to 2.

> Is there any chance your route wasn't actually set up by systemd-networkd?

You're so right. I apologize.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#839958: gnome-settings-daemon: Custom keyboard shortcut no longer working

[Nicolas LE CAM]

Package: gnome-settings-daemon
Version: 3.22.1-1
Followup-For: Bug #839958

Dear Maintainer,

Confirming.
The same exact custom shortcut (Ctrl-Alt-T) stopped working after a reboot 
today.

journalctl contains following warnings :
Dec 03 22:21:42 rio gnome-settings-[955]: Could not find accelerator for accel 
id 153
Dec 03 22:21:42 rio gnome-settings-[955]: Could not find accelerator for accel 
id 153
Dec 03 22:21:42 rio gnome-settings-[955]: Could not find accelerator for accel 
id 153
Dec 03 22:21:42 rio gnome-settings-[955]: Could not find accelerator for accel 
id 153
Dec 03 22:21:38 rio gnome-settings-[955]: Could not find accelerator for accel 
id 153

Searching for this message popped this Arch Linux thread : 
https://bbs.archlinux.org/viewtopic.php?id=218910
I've followed the advice pointed there (i.e. recreating shortcut and restarting 
DE) and it fixed the problem for me.

I'm not sure which package update did generate this bug, I'm updating on a 
daily basis and previous reboot was on november the 26th. I can provide apt 
history.log if this can help.

regards,
Nicolas

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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gsettings-desktop-schemas3.22.0-1
ii  libasound2   1.1.2-1
ii  libc62.24-7
ii  libcairo21.14.6-1.1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcolord2   1.3.3-2
ii  libcups2 2.2.1-2
ii  libfontconfig1   2.11.0-6.7
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgeoclue-2-0   2.4.4-1
ii  libgeocode-glib0 3.20.1-2
ii  libglib2.0-0 2.50.2-2
ii  libgnome-desktop-3-123.22.2-1
ii  libgtk-3-0   3.22.4-1
ii  libgudev-1.0-0   230-3
ii  libgweather-3-6  3.20.3-1
ii  liblcms2-2   2.7-1
ii  libnm0   1.4.2-3
ii  libnotify4   0.7.7-1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpam-systemd   232-6
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpolkit-gobject-1-00.105-17
ii  libpulse-mainloop-glib0  9.0-5
ii  libpulse09.0-5
ii  librsvg2-2   2.40.16-1
ii  libupower-glib3  0.99.4-4
ii  libwacom20.22-1
ii  libwayland-client0   1.11.0-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1.1
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.22.1-2

Versions of packages gnome-settings-daemon recommends:
pn  iio-sensor-proxy  
ii  pulseaudio9.0-5

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#808420: [debian-mysql] Bug#808420: Implemented systemd scripts for MariaDB

[Johannes Kliemann]

Hi,

thanks for your feedback.

I looked what the init script does and stripped it down to create the
service file from this.

Johannes Kliemann

Am 03.12.2016 um 21:47 schrieb Otto Kekäläinen:
> Hello!
> 
> Great! We are indeed missing systemd files, good that you took the
> time to work on them.
> 
> How do these relate to the upstream systemd scripts in 10.1 and 10.2?
> Or is it based on MySQL 5.6 systemd scripts?
> 
> https://github.com/MariaDB/server/tree/10.2/support-files
> https://jira.mariadb.org/browse/MDEV-427
> 
> 
> 
> 2016-12-03 19:41 GMT+02:00 Johannes Kliemann :
>> I have implemented a systemd service file for MariaDB.
>>
>> Johannes Kliemann
>>
>> ___
>> pkg-mysql-maint mailing list
>> pkg-mysql-ma...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#846587: include all non-ASCII

[Bill Allombert]

On Sat, Dec 03, 2016 at 10:31:45AM +0100, Adam Borowski wrote:
> After a thought, it doesn't make any sense to somehow exclude a handful of
> non-ASCII symbols when the whole rest of Unicode is hard-coded in the
> kernel.  Thus, let's make them all work the same.
> 
> I guess it'd be best to change kernel code to use proper character
> identification functions (iswfoo()) like GUI terminals do; that's certainly
> impossible before stretch though.

Actually, the kernel should be changed to allow /dev/vcsa to be
mmap()able. This way, consolation would be able to read the characters
on screen directly and all of this could be done in user-space.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#846879: cython: please strip path prefixes from generated symbols and values, in order to make build-dependent -dbgsym packages reproducible

[Clint Adams]

Source: cython
Version: 0.24.1-2
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath

cythonize generates code like

char __pyx_k_tmp_python_gssapi_1_2_0_gssapi[] = 
"/tmp/python-gssapi-1.2.0/gssapi/raw/sec_contexts.pyx";

where the source path "/tmp/python-gssapi-1.2.0/" is embedded twice

This makes debug symbol packages unreproducible.

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

Dear Nicholas,

Thanks again for your work on this.  I'm looking forward to seeing the
cleaned-up package in Debian stretch.

Before I reply to your message, let me note a few more things to fix:

1. s/Muse-el/muse-el/ in the changelog

2. You need to re-run `dch -r` so the timestamp is later than your
changes.

3. "Includes changes to debian/control, debian/rules, NEWS"

This is not very informative.  I'm not saying that you have to list
every change, but see how much more informative this is:

- Update Build-Depends; Maintainer; Uploaders [or whatever fields you updated]
- Rewrite d/rules
- Update NEWS

For a sample, see the most recent changelog entry of the yasnippet
package, which I recently converted to use dh_elpa.

4. "Add patch ..."

When you say that you added a patch, it is best to explicitly state the
patch filename so that someone searching the changelog for that patch
name can find it easily.

5. "Add depends on doc-base to register Quickstart.pdf as
muse-quickstart."

Build-Depends?  Binary package dependency?

Are you sure you need this?  doc-base registration uses triggers, so you
don't generally need to depend on it.

6. In d/NEWS,

> Unfortunately, it is not possible to distribute this manual with the
> muse-el Debian package because the Debian project has chosen to remove
> most GFDL'd documentation.

Wouldn't you say the unfortunate thing is that the manual has not been
relicensed under a DFSG-compatible license? ;)

7. I'm pretty sure you shouldn't compress
/usr/share/doc/elpa-muse/QuickStart.pdf.  It might break doc-base
clients, and in any case, I doubt that gzip compression is very good for
PDFs.

8. In the patch header for use_see_not_open.diff, it would be good to
know why you're applying the patch.  What's the advantage of see(1) over
open(1)?

9. There is still a lot of Lintian output.  Please make the package
Lintian clean.  Please ensure you turn on experimental and informational
tags:

I: muse-el source: binary-control-field-duplicates-source field "priority" 
in package muse-el
E: muse-el source: license-problem-gfdl-invariants README invariant part 
is: with no invariant sections, and with the front-cover texts and back-cover 
texts as specified in the manual
I: muse-el source: debian-watch-file-is-missing
I: elpa-muse: debian-news-entry-uses-asterisk
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/generic-header.html 
(http://www.mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
(http://blog.mwolson.org/index.rss)
X: elpa-muse: privacy-breach-generic 
usr/share/doc/elpa-muse/examples/mwolson/templates/header.html 
(http://mwolson.org/web/aboutme.html)
X: elpa-muse: privacy-breach-generic ... use --no-tag-display-limit to see 
all (or pipe to a file/program)
I: muse-el: debian-news-entry-uses-asterisk
I: muse-el: description-synopsis-might-not-be-phrased-properly

10. How are the *.py files meant to be used?  Are they supposed to be
copied into a pyblosxom installation, or run directly from where they
are installed?  If the latter, they should be bytecompiled and installed
into /usr/share/elpa-muse/contrib.  If the former, they are fine as they are.

11. I've now reviewed d/copyright.  Unfortunately, you can't claim that
the debian/ directory is GPL-3+ without contacting each of the authors
you name and confirming they are happy to release their contributors
under that license, since it was not explicitly stated.  What happens if
one of them is only happy with GPL-2, and no later versions?

I think this means that you can't switch to copyright format 1.0, and
have to keep the old copyright file.  You could add credit for revamping
the package for yourself if you like.

12. Your change in the "Priority:" field is not in the changelog.

13. You bumped the standards-version but didn't mention it in the
changelog.  Did you review the upgrading checklist?[1]

14. Consider s/emacs24/emacs25/ in build-depends-indep.

15. Why does elpa-muse depend on emacs-goodies-el?  Maybe add a comment
to the control file.

16. muse-el is not a library.  It shouldn't be in section: oldlibs.

17. The deletion of d/emacsen-* is not in the changelog.  Similarly,
d/muse-el.dirs.

18. At dh compat 10, you can drop --parallel from d/rules.

19. I think you should remove Joey Hess's copyright notice in d/rules,
since you're not using old-style debhelper at all anymore.

On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote:
> On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote:
> > In the future, when submitting a new bug, please use X-Debbugs-CC: rather
> > than CC: so that the bug gets assigned a number before reaching my
> > inbox.
> 
> Would you please share how to get X-Debbugs-CC: to show up in mutt's
> edit_headers?  It seems to be ignored unless it is set using this:
> my_hdr X-Debbugs-CC: bogus_value

You can j

Bug#834520: duck: FTBFS with '.' removed from perl's @INC

[Simon Kainz]

tags 834520 pending
thanks

Hello,

i applied your patch. Thank you for help. And thank your for using duck.

All the best,

Simon

Am 2016-08-18 um 13:53 schrieb Simon Kainz:
> Hello,
> 
> thank you very much for this, very much appreciated.
> I will fix this ASAP.
> 
> Regards,
> 
> 
> 
> Am 2016-08-16 um 18:31 schrieb Dominic Hargreaves:
>> Source: duck
>> Version: 0.10
>> Severity: important
>> User: debian-p...@lists.debian.org
>> Usertags: perl-cwd-inc-removal
>> Tags: patch
>>
>> This package FTBFS when '.' is removed from @INC, as seen at [1].
>> In order to test against the current version of DUCK.pm (as opposed
>> to the version which might happen to be installed in /usr/share on
>> the build system) you need to add -I. to the perl invocation as per the
>> attached patch.
>>
>> This change is being made for security reasons; for more background,
>> see #588017 and [2].
>>
>> This bug will become RC when the perl package change removing '.' from
>> @INC by default is uploaded to unstable, expected in a week or two.
>>
>> Thanks,
>> Dominic.
>>
>> [1] 
>> 
>> [2] 
>>

Bug#846540: hplip-gui: hp-toolbox and hp-setup cannot load

[Michael Weghorn]

Hi Alejandro,

I just installed "hplip-gui" on unstable/sid in a VM and running
hp-setup or hp-check did work for me. (I did not check the
functionality, just that the problem you described did not occur.)

Do you have the package "libhpmud0" installed?
It contains the respective shared library file "libhpipp.so.0" that is
mentioned in the error message you get:

~~~
$ dpkg -S /usr/lib/x86_64-linux-gnu/libhpipp.so.0
libhpmud0:amd64: /usr/lib/x86_64-linux-gnu/libhpipp.so.0
~~~

As far as I understand, the package should automatically be installed as
it is declared as a dependency of package "hplip" (which is itself a
dependency of "hplip-gui").

If I explicitly ignore that dependency and force the removal of the
package "libhpmud0", I can reproduce the error messages you wrote about:

~~~
$ sudo dpkg --purge libhpmud0
dpkg: dependency problems prevent removal of libhpmud0:amd64:
 libsane-hpaio:amd64 depends on libhpmud0.
 printer-driver-hpcups depends on libhpmud0.
 hplip depends on libhpmud0 (= 3.16.10+repack0-1).

dpkg: error processing package libhpmud0:amd64 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libhpmud0:amd64
$ sudo dpkg --purge --force-all libhpmud0
dpkg: libhpmud0:amd64: dependency problems, but removing anyway as you
requested:
 libsane-hpaio:amd64 depends on libhpmud0.
 printer-driver-hpcups depends on libhpmud0.
 hplip depends on libhpmud0 (= 3.16.10+repack0-1).

(Reading database ... 75747 files and directories currently installed.)
Removing libhpmud0:amd64 (3.16.10+repack0-1) ...
Processing triggers for libc-bin (2.24-7) ...
$ hp-setup
Traceback (most recent call last):
  File "/usr/bin/hp-setup", line 48, in 
from base import device, utils, tui, models, module, services, os_utils
  File "/usr/share/hplip/base/device.py", line 41, in 
from . import status
  File "/usr/share/hplip/base/status.py", line 32, in 
import cupsext
ImportError: libhpipp.so.0: cannot open shared object file: No such file
or directory
~~~

As far as I understand it so far, "libhpmud0" should always be present
in normal cases because of the declared dependencies.

Michael

Bug#846878: taggrepper: please make the build reproducible

[Valerie R Young]

Package: taggrepper
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org,
spectran...@riseup.net

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed
that taggrepper could not be built reproducibly.
Specifically, the permissions of some directories are influenced by the
umask and the order of the md5sums file can vary.

The attached patch fixes those issues.

Best,
Valerie

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

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

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

--- rules	2016-12-03 11:26:39.675091955 -0500
+++ rules	2016-12-03 13:30:25.447018646 -0500
@@ -72,6 +72,8 @@
 install: checkroot build
 	$(checkdir)
 	$(MAKE) DESTDIR=$(CURDIR)/$(PACKAGE_DIR) install
+	# fix directory permissions
+	find '$(PACKAGE_DIR)' -type d -print0 | xargs -0r chmod 0755
 
 # Build architecture-independent files here.
 binary-indep: checkroot build install
@@ -97,7 +99,7 @@
 endif
 	dpkg-shlibdeps $(PACKAGE_DIR)/usr/bin/taggrepper
 	$(INSTALL_DIR) $(PACKAGE_DIR)/DEBIAN
-	cd $(PACKAGE_DIR) && find * -type f ! -regex '^DEBIAN/.*' -print0 | xargs -r0 md5sum > DEBIAN/md5sums
+	cd $(PACKAGE_DIR) && find * -type f ! -regex '^DEBIAN/.*' -print0 | LC_ALL=C sort -z | xargs -r0 md5sum > DEBIAN/md5sums
 	dpkg-gencontrol -p$(PACKAGE_NAME) -P$(PACKAGE_DIR)
 	find $(PACKAGE_DIR) -newermt "@$$SOURCE_DATE_EPOCH" -print0 | \
 		xargs -0r touch --no-dereference --date="@$$SOURCE_DATE_EPOCH"

Bug#846877: plasma-desktop: Sddm can not start kde. Then panel is not working.

[laurent B]

Package: plasma-desktop
Version: 4:5.8.4-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
   upgrade some packages on debian sid (this week from 28 november to 2th 
december 2016)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 try to login in plasma-kde from sddm
   * What was the outcome of this action?
   the blackcreen with K icon  showed off but hand out indefinitely. However I 
found a simple workaourd : go to tty1 then back to tty7 and get greeted with 
the sound of plasma login. However then at some point  the panel will stop work 
and i could only manage to switch from one windows to another going in the to 
left side of the screen.  
   



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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.8.4-1
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.4-1
ii  kded55.28.0-1
ii  kio  5.28.0-1
ii  libc62.24-7
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.7
ii  libgcc1  1:6.2.1-5
ii  libkf5activities55.28.0-1
ii  libkf5activitiesstats1   5.28.0-1
ii  libkf5archive5   5.28.0-1
ii  libkf5auth5  5.28.0-1
ii  libkf5baloo5 5.28.0-1
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-1
ii  libkf5configgui5 5.28.0-1
ii  libkf5configwidgets5 5.28.0-1
ii  libkf5coreaddons55.28.0-1
ii  libkf5dbusaddons55.28.0-1
ii  libkf5emoticons-bin  5.28.0-1
ii  libkf5emoticons5 5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-1
ii  libkf5iconthemes55.28.0-1
ii  libkf5itemmodels55.28.0-1
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-1
ii  libkf5kcmutils5  5.28.0-1
ii  libkf5kdelibs4support5   5.28.0-1
ii  libkf5kiocore5   5.28.0-1
ii  libkf5kiofilewidgets55.28.0-1
ii  libkf5kiowidgets55.28.0-1
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5parts5 5.28.0-1
ii  libkf5people55.28.0-1
ii  libkf5peoplewidgets5 5.28.0-1
ii  libkf5plasma55.28.0-1
ii  libkf5plasmaquick5   5.28.0-1
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-2
ii  libkf5sonnetui5  5.28.0-1
ii  libkf5wallet-bin 5.28.0-1
ii  libkf5wallet55.28.0-1
ii  libkf5widgetsaddons5 5.28.0-1
ii  libkf5windowsystem5  5.28.0-1
ii  libkf5xmlgui55.28.0-1
ii  libkfontinst54:5.8.4-1
ii  libkfontinstui5  4:5.8.4-1
ii  libkworkspace5-5 4:5.8.4-1
ii  libpackagekitqt5-0   0.9.6-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  9.0-5
ii  libpulse09.0-5
ii  libqt5concurrent55.7.1~20161021+dfsg-6
ii  libqt5core5a 5.7.1~20161021+dfsg-6
ii  libqt5dbus5  5.7.1~20161021+dfsg-6
ii  libqt5gui5   5.7.1~20161021+dfsg-6
ii  libqt5network5   5.7.1~20161021+dfsg-6
ii  libqt5printsupport5  5.7.1~20161021+dfsg-6
ii  libqt5qml5  

Bug#846875: djagios: Don't depend on nagios3 which has been removed from unstable

[Bas Couwenberg]

Source: djagios
Version: 0.1.3+dfsg-7
Severity: normal
Tags: patch
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: nagios3-rm

Dear Maintainer,

Please update your package to deal with the nagios3 removal from Debian
(#845765).

Consider applying the attached patch.

Kind Regards,

Bas
diff -Nru djagios-0.1.3+dfsg/debian/changelog djagios-0.1.3+dfsg/debian/changelog
--- djagios-0.1.3+dfsg/debian/changelog	2016-09-24 23:58:51.0 +0200
+++ djagios-0.1.3+dfsg/debian/changelog	2016-12-03 22:09:12.0 +0100
@@ -1,3 +1,10 @@
+djagios (0.1.3+dfsg-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't depend on nagios3 which has been removed from Debian.
+
+ -- Bas Couwenberg   Sat, 03 Dec 2016 22:08:53 +0100
+
 djagios (0.1.3+dfsg-7) unstable; urgency=medium
 
   * debian/control:
diff -Nru djagios-0.1.3+dfsg/debian/control djagios-0.1.3+dfsg/debian/control
--- djagios-0.1.3+dfsg/debian/control	2016-09-24 23:58:51.0 +0200
+++ djagios-0.1.3+dfsg/debian/control	2016-12-03 22:08:49.0 +0100
@@ -20,7 +20,7 @@
  python-mysqldb | python-pysqlite2 | python-psycopg2
 Recommends: apache2,
 libapache2-mod-wsgi | libapache2-mod-python
-Suggests: nagios3
+Suggests: icinga
 XB-Python-Version: ${python:Versions}
 Description: tool to help configure nagios written in Django
  Djagios is an open source Nagios web based configuration tool with a complete
diff -Nru djagios-0.1.3+dfsg/debian/patches/icinga.patch djagios-0.1.3+dfsg/debian/patches/icinga.patch
--- djagios-0.1.3+dfsg/debian/patches/icinga.patch	1970-01-01 01:00:00.0 +0100
+++ djagios-0.1.3+dfsg/debian/patches/icinga.patch	2016-12-03 22:08:43.0 +0100
@@ -0,0 +1,103 @@
+Description: Update default paths for icinga on Debian.
+Author: Bas Couwenberg 
+
+--- a/djagios/core/models.py
 b/djagios/core/models.py
+@@ -1172,23 +1172,23 @@ class NagiosCfg(NagiosObject, models.Mod
+ FILE_NAME = 'nagios.cfg'
+ server_name = models.CharField(max_length=255, default='localhost', unique=True)
+ log_file = models.ForeignKey(CfgPath, related_name='NC_lf_CP',\
+-default=lambda : CfgPath.get('/var/log/nagios/nagios.log').id)
++default=lambda : CfgPath.get('/var/log/icinga/icinga.log').id)
+ cfg_file = models.ManyToManyField(CfgPath, related_name='NC_cfg_file_CP',\
+ blank=True,null=True)
+ cfg_dir = models.ManyToManyField(CfgPath, related_name='NC_cfg_dir_CP',\
+ blank=True,null=True)
+ object_cache_file = models.ForeignKey(CfgPath, related_name='NC_ocf_CP',\
+-default=lambda : CfgPath.get('/var/nagios/objects.cache').id)
++default=lambda : CfgPath.get('/var/cache/icinga/objects.cache').id)
+ precached_object_file = models.ForeignKey(CfgPath, related_name='NC_pof_CP',\
+-default=lambda : CfgPath.get('/var/nagios/objects.precache').id)
++default=lambda : CfgPath.get('/var/cache/icinga/objects.precache').id)
+ resource_file = models.ForeignKey(CfgPath, related_name='NC_rf_CP',\
+-default=lambda : CfgPath.get('/etc/nagios/resource.cfg').id)
++default=lambda : CfgPath.get('/etc/icinga/resource.cfg').id)
+ temp_file = models.ForeignKey(CfgPath, related_name='NC_tf_CP',\
+-default=lambda : CfgPath.get('/var/nagios/nagios.tmp').id)
++default=lambda : CfgPath.get('/var/cache/icinga/icinga.tmp').id)
+ temp_path = models.ForeignKey(CfgPath, related_name='NC_tp_CP',\
+ default=lambda : CfgPath.get('/tmp').id)
+ status_file = models.ForeignKey(CfgPath, related_name='NC_sf_CP',\
+-default=lambda : CfgPath.get('/var/nagios/status.dat').id)
++default=lambda : CfgPath.get('/var/lib/icinga/status.dat').id)
+ status_update_interval = models.IntegerField(default=1)
+ nagios_user = models.CharField(max_length=20, default='nagios')
+ nagios_group = models.CharField(max_length=20, default='nagios')
+@@ -1200,19 +1200,19 @@ class NagiosCfg(NagiosObject, models.Mod
+ enable_event_handlers = models.NullBooleanField(blank=True,null=True)
+ log_rotation_method = models.CharField(max_length=1, choices=LOG_ROTATION_METHODS, default='n')
+ log_archive_path = models.ForeignKey(CfgPath, related_name='NC_laf_CP',\
+-default=lambda : CfgPath.get('/var/log/nagios/archives').id)
++default=lambda : CfgPath.get('/var/log/icinga/archives').id)
+ check_external_commands = models.NullBooleanField(blank=True,null=True)
+ command_check_interval = models.IntegerField(default=1)
+ command_file = models.ForeignKey(CfgPath, related_name='NC_cf_CP',\
+-default=lambda : CfgPath.get('/var/nagios/rw/nagios.cmd').id)
++default=lambda : CfgPath.get('/var/lib/icinga/rw/icinga.cmd').id)
+ external_command_buffer_slots = models.IntegerField(default=512)
+ check_for_updates = models.NullBooleanField(blank=True,null=True)
+ bare_update_c

Bug#846876: fai-diskimage uses nic name from host

[Thomas Lange]

Package: fai-server
Version: 5.3
Severity: minor

When calling fai-diskimage, FAI sets NIC1 to the nic name of the host
system, which maybe wlan0 or eth4 or some other value. NIC1 is used
for creating /etc/network/interfaces.

This can easily be fixed by setting NIC1=eth0 in a class/*.var file.
-- 
regards Thomas

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[Andreas Schwab]

On Dez 03 2016, John Paul Adrian Glaubitz  wrote:

> patching file src/gcc/ada/s-memory.adb
> Hunk #1 FAILED at 47.
> Hunk #2 succeeded at 113 (offset 13 lines).
> 1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
> patching file src/gcc/ada/s-memory.ads

According to PR48835, this is no longer necessary.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Bug#830482: [Pkg-clamav-devel] Bug#830482: clamav-freshclam: duplicate logging with systemd

[Sebastian Andrzej Siewior]

On 2016-07-08 14:39:26 [+0200], Marki wrote:
> freshclam is configured to log to its logfile by itself (UpdateLogFile).
> However systemd unit file (as shipped with jessie) runs freshclam in
> foreground and redirects its stdout to syslog.
> 
> LogSyslog false
> Foreground false

According to the source code of freshclam this should not happen if
LogSyslog and Foreground is set to false like you have. I have
clamav-freshclam on a fresh box to double check and confirmed it.
(On my server I have freshclam run from cron so I could not check the
problem existed otherwise)
Is the freshclam.conf you attached to the bug report from the machine
that logs twice?

Sebastian

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/03/2016 10:02 PM, Andreas Schwab wrote:
>> patching file src/gcc/ada/s-memory.adb
>> Hunk #1 FAILED at 47.
>> Hunk #2 succeeded at 113 (offset 13 lines).
>> 1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
>> patching file src/gcc/ada/s-memory.ads
> 
> According to PR48835, this is no longer necessary.

Ah, thanks for letting us know. I was already suspecting that, but I didn't
have the time yet to verify it.

@Matthias:

Do you agree that we can drop this particular patch then?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#840694: gcc: /usr/bin/gcc should use /etc/alternatives

[Matthias Klose]

Control: tags -1 + wontfix

On 14.10.2016 00:45, Peter Chubb wrote:
> Package: gcc
> Version: 4:6.1.1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I currently have gcc versions 4.7, 5.0 and 6.0 installed.  I'd
> like to be able to switch between them on a regular basis.  The
> simplest way to do this would be to use update-alternatives to
> switch, but currently /usr/bin/gcc and its friends
> are direct symlinks to /usr/bin/gcc-6
> 
> By `friends' I mean cpp, c++, c89 c99 gcc-ar gcc-ranlib gcc-nm etc.
> 
> The same goes for the various cross compilers (arm-linux-gnueabi-gcc etc)

no it should not. different GCC versions can offer different ABI versions, use
the versioned names to select a specific version. "Simple" isn't correct here.

Bug#846874: monitoring-plugins: Don't depend on nagios3 which has been removed from unstable

[Bas Couwenberg]

Source: monitoring-plugins
Version: 2.1.2-3
Severity: normal
Tags: patch
User: pkg-nagios-de...@lists.alioth.debian.org
Usertags: nagios3-rm

Dear Maintainer,

Please update your package to deal with the nagios3 removal from Debian
(#845765).

Consider applying the attached patch.

Kind Regards,

Bas
diff -Nru monitoring-plugins-2.1.2/debian/changelog monitoring-plugins-2.1.2/debian/changelog
--- monitoring-plugins-2.1.2/debian/changelog	2016-11-18 12:22:37.0 +0100
+++ monitoring-plugins-2.1.2/debian/changelog	2016-12-03 21:52:44.0 +0100
@@ -1,3 +1,10 @@
+monitoring-plugins (2.1.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't depend on nagios3 which has been removed from Debian.
+
+ -- Bas Couwenberg   Sat, 03 Dec 2016 21:52:39 +0100
+
 monitoring-plugins (2.1.2-3) unstable; urgency=medium
 
   * [8bab78d] d/control: Replacing build-dep libmysqlclient-dev with
diff -Nru monitoring-plugins-2.1.2/debian/control monitoring-plugins-2.1.2/debian/control
--- monitoring-plugins-2.1.2/debian/control	2016-11-18 12:22:37.0 +0100
+++ monitoring-plugins-2.1.2/debian/control	2016-12-03 21:52:18.0 +0100
@@ -26,7 +26,7 @@
 Depends: monitoring-plugins-basic, monitoring-plugins-standard, ${misc:Depends}
 Replaces: nagios-plugins (<< 1.5-4~)
 Breaks: nagios-plugins (<< 1.5-4~)
-Suggests: icinga | icinga | nagios3, nagios-plugins-contrib
+Suggests: icinga | icinga2, nagios-plugins-contrib
 Description: Plugins for nagios compatible monitoring systems (metapackage)
  Plugins for nagios compatible monitoring systems like Naemon and Icinga.
  .
@@ -41,7 +41,7 @@
 Depends: ucf, ${misc:Depends}, ${shlibs:Depends}
 Replaces: nagios-plugins-common (<< 1.5-4~)
 Breaks: nagios-plugins-common (<< 1.5-4~)
-Suggests: icinga | icinga | nagios3
+Suggests: icinga | icinga2
 Description: Common files for plugins for nagios compatible monitoring
  Common files for plugins for nagios compatible monitoring systems like Naemon
  and Icinga.
@@ -60,7 +60,7 @@
 Recommends: libcap2-bin [linux-any]
 Replaces: nagios-plugins-basic (<< 1.5-4~)
 Breaks: nagios-plugins-basic (<< 1.5-4~)
-Suggests: icinga | icinga | nagios3
+Suggests: icinga | icinga2
 Description: Plugins for nagios compatible monitoring systems (basic)
  Plugins for nagios compatible monitoring systems like Naemon and Icinga. It
  contains the following plugins:
@@ -96,7 +96,7 @@
 snmp,
 ${shlibs:Recommends}
 Suggests: fping,
-  icinga | icinga | nagios3,
+  icinga | icinga2,
   postfix | sendmail-bin | exim4-daemon-heavy | exim4-daemon-light,
   qstat
 Description: Plugins for nagios compatible monitoring systems (standard)