Bug#790814: ITP: kanboard -- A PHP project management system with a kanban workflow style interface and various integrations.

[Tom Fernandes]

Has development on the package already begun? If so, I'm willing to test
and give feedback.

Warm regards,


Tom

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi,
Just provided a new upstream package v1.1.5 and made debian
repository fit for autopkgtest.

Best regards,
Joël


On Fri, Nov 24, 2017 at 10:55 AM, Joël Krähemann  wrote:
> Hi,
> Since I (upstream) doesn't have the infrastructure to run integration
> tests configure.ac remains the same. But the fixes to the file
> functional-system-tests.mk.am just applied upstream.
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.2.x
>
> Bests,
> Joël
>
>
>
> On Fri, Nov 24, 2017 at 10:50 AM, Joël Krähemann  
> wrote:
>> Hi,
>> Just providing a patch. The target ags-integration-test wasn't take care
>> much.
>>
>> Apply the patch fix-integration-tests.patch
>> `patch -p1 < ../nongnu/gsequencer/fix-integration-tests.patch`
>> run `autoreconf -fi && ./configure`
>> then `make -j20 && make ags-integration-test`
>>
>> Bests,
>> Joël
>>
>>
>> On Fri, Nov 24, 2017 at 9:26 AM, Joël Krähemann  
>> wrote:
>>> Hi Dimitri,
>>> The make target ags-integration-test runs against installed libraries. Just 
>>> run
>>> `make check` which contains the very same functional tests. But this 
>>> requires
>>> to remove the following patch:
>>>
>>> debian/patches/disable-functional-tests.patch
>>>
>>> `make ags-integration-test` is only useful to run against installed 
>>> gsequencer
>>> package. Further libgsequencer.so can't be a private library if you want to 
>>> run
>>> them. So additional patch would be required to change library installation 
>>> path.
>>>
>>> Best regards,
>>> Joël Krähemann
>>>
>>>
>>> On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov  
>>> wrote:
 Package: gsequencer
 Version: 1.1.4-1
 Severity: normal

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Dear Maintainer,

 The autopkgtest included in gsequencer appears to not work at all
 anymore.

 It calls into debian/rules targets that do not exist anymore. I've
 tried fixing it up, by making the test depend on '@builddeps@` or
 using 'build-needed' restriction and modifying the test script
 appropriately only to see that `make ags-integration-test` fails.

 Could you please fix up integration test? Or remove it, as it cannot
 be executed anymore?

 Regards,

 Dimitri.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
 OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
 FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
 tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
 =zzou
 -END PGP SIGNATURE-

Bug#879857: xserver-xorg-video-intel: [i915] GPU hang after every suspend or hibernate on Debian 9 stretch

[Ferdinand Rau]

This issue is not resolved.

Dear Maintainer:

Could you kindly confirm that this bug was reported correctly?

Could you please comment on the next steps? Even if it is not possible or not 
reasonable to work on this bug, I would love to know this.

Should I report another bug, e.g. against the kernel package or against the 
upstream xorg project?

Kind regards,
Ferdinand Rau

Bug#873408: [Pkg-julia-devel] Bug#873408: julia: Please update to llvm-toolchain 4.0 or, better, 5.0

[Graham Inggs]

On 20 November 2017 at 20:54, Emilio Pozuelo Monfort  wrote:
> It should be fine now with 4.0. Would be good if this could move to either
> unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. 
> Bumping
> to serious as we want to remove 3.8 soon to reduce the high number of llvm
> versions that we currently ship.

Unfortunately julia 0.4.7 doesn't build with llvm/clang 4.0.
Julia 0.6.1 is available (#839668) but we are blocked by a lack of
support for https in libgit2 (#832798).
There is ongoing activity in the upstream PR, so we remain hopeful.

For now, julia can be removed from testing.

Bug#881097: Removing libnet-ping-external-perl from jessie, stretch and unstable

[Salvatore Bonaccorso]

Hi Tony!

Thanks for your reply, dropping LTS list since reply is specific for
oldstable, stable and unstable.

On Wed, Nov 22, 2017 at 03:32:36PM -0800, tony mancill wrote:
> On Wed, Nov 22, 2017 at 09:00:59PM +0100, Emilio Pozuelo Monfort wrote:
> > On 08/11/17 20:19, Ola Lundqvist wrote:
> > > Hi
> > > 
> > > Considering that this package is about to be removed from jessie I
> > > guess it should be removed from wheezy too. How is that done? Should I
> > > contact the FTP maintainers about it, or do we simply ignore the
> > > issue?
> > 
> > We don't have point releases, so I'm not sure we can get a package removed 
> > at
> > this stage without extra work by the ftp masters. So our options would be:
> > 
> > - mark as no-dsa if it's not important enough
> > - mark as unsupported / end-of-life
> > - fix it
> > - get it removed
> > 
> > The issue seems only exploitable if it's used by a service that is exposed
> > remotely or to other issues... and has no rdeps in wheezy. OTOH there is at
> > least one sponsor using that package. So removing it may not be the best 
> > course
> > given there is a proposed patch. So I'd go with either no-dsa or fix it,
> > depending on the assessed importance.
> 
> Hi,
> 
> My apologies for taking a while to join the thread.  As the most recent
> uploader of this package, I feel responsible for helping get it into a
> safe state if we opt to keep it.  However, I am not an active user, so
> if the package is to remain in Debian, it might be better to transition
> it to the Debian Perl Team (assuming that is amenable to the team).
> 
> I tend to agree with Emilio that removing it might not be the best
> course of action for our users, particularly given that we have a patch
> and the popcon [1] is non-zero.  Removing it from the distribution seems
> like it merely leaves users with a known vulnerability.  Also, the
> package might be used in derivatives.
> 
> I agree with Simon that it's a little odd for the patch to bump the
> version.  (OTOH, it makes it much easier to differentiate from the
> vulnerable 0.15.)  Still, I am inclined to take the patch as a patch
> against upstream 0.15 for the upload to unstable and then backport it
> for 0.13 for stable and oldstable.  Or perhaps Alexandr Ciornii (on the
> cc) would be willing to release 0.16 including the patch.
> 
> Thoughts?

The package is basically "unmaintained" (upstream)[*] and for almost
10 years did not address
https://rt.cpan.org/Public/Bug/Display.html?id=33230 (maybe you can
argue, as well a fault for various "downstreams" to not notice and
bring that earlier up, defintively. I wonder why only now it got
attention on oss-security, for which I then requested a CVE)

IMHO the best course of action is still to have it removed, in all
suites. For unstable, so that it's not included in buster. And for
oldstable and stable (as scheduled for the upcoming point releases)
via the point release announcements. The announcement will contain a
section which packages are removed from Debian, and for which reason,
so still users of Net::Ping::External are informed.

I agree as well that if one starts to argue that way that there are
old packages which do not see updates from upstream, then a whole more
should be removed from Debian ;-). My point was not this though, I'm
concernend that there was a bug with security implications for almost
10 years reported in public bugtracker, without even a reply to it to
acknowledge the problem.

Regards,
Salvatore

 [*] well not exactly, I know there was e.g. 0.15, so there is
 activity, but see remaining of sentence.

Bug#876191: most: configure cannot be built from source

[Helmut Grohne]

On Fri, Nov 24, 2017 at 06:22:05PM -0800, Benj. Mako Hill wrote:
> I'll also say that I'm skeptical about both the severity you've chosen
> here (serious), about describing this as a FTBFS issue, and about your
> suggestion that this is a DFSG issue.

I deliberately avoided the FTBFS language, because it is not a FTBFS.
It's different. It's like shipping a binary that cannot be regenerated
and using that during build. The term FTBFS is well defined and does not
cover this case.

> If there is a serious DFSG issue here, it's not a FTBFS issue but
> rather a question of whether or not the source package contains the
> full source in the first place. I'm open to being convinced otherwise
> but I think it does.

I do believe that this is a DFSG issue.

> If I generate a configure file with autoconf and then modify it by
> hand in order to create a working build script, I don't I've somehow
> made it impossible to provide source for that package. I think I'm
> still providing the preferred form of modification (as the GPL defines
> source). I agree that that situation is brittle and bad and should be
> avoided.  But I don't think it's a DFSG issue.

Would you say the same if you compile a binary, use a hex editor to fix
the binary and then ship the binary in your source package? I mean you
preferred to edit the binary with a hex editor, so wouldn't it be
preferred form for modification?

Now consider my case. Most commonly, I want to change AC_RUN_IFELSE into
AC_TRY_COMPILE or AC_COMPUTE_INT. That's a very simple change on
configure.ac that produces a big diff on the generated configure.

Also consider that autoconf projects tend to ship embedded copies of .m4
files. A bug in those .m4 files is often fixed upstream. Fixing it could
be a simple matter of updating the embedded copy if one could regenerate
configure.

In both of these examples, I very much do not prefer working with the
generated configure as it feels very much like editing a binary with a
hex editor. Thus I argue that configure is not the preferred form for
modification. Shipping only configure makes DFGS #3 practically moot.

> If this has been discussed elsewhere or if there is Debian policy on
> this I don't know about, I'd appreciate being pointed to this and I'm
> happy to defer to this. In the meantime, I'd appreciate help fixing
> this issue. I'm not likely to have bandwidth for a few more weeks.

I guess we should document this issue class centrally. It is similar to
the javascript bundling issue (where people suppose that minified or
concatenated javascript files could be considered source). A very
similar bu is #874261. #882538 could be called related.

This issue comes about every time Debian is bootstrapped for a new
architecture as configure tends to have bugs (e.g. ppc64el). I'm seeing
it now as I bootstrap Debian for something like a new architecture
(cross building). So this is the class of bugs to watch out.

Helmut

Bug#882384: ffmpeg: Gratuitous valgrind log

[James Cowgill]

Hi,

On 25/11/17 04:41, Kingsley G. Morse Jr. wrote:
> Hi Carl,
> 
>> Nearly all messages seem to relate to melt, not FFmpeg.
> 
> Thanks for your informed thoughts.
> 
>> Can you reproduce any issues with ffmpeg (the executable)?
>>
>> The crc issue surprises me a little: Can you produce different
>> output files if you use the valgrind option --malloc-fill?
> 
> Sure.
> 
> A script is attached.
> 
> It uses ffmpeg, without melt.
> 
> I also attached two log files from valgrind.
> 
> One ran it with --malloc-fill.
> 
> The other didn't.

None of the valgrind errors in your log are from ffmpeg. They all seem
to be caused by either glib or gobject.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#882600: Congratulationseses

[Mike Aymond]

You ur der winer

Bug#882642: RFS: quickcal/1.0 ITP

[Nathan SR]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: quickcal
   Version : 1.0
   Upstream Author :
 * URL : https://sourceforge.net/projects/quickcal/
 * License : GPL
   Section : utils

  It builds those binary packages:

quickcal   - It is a fast and easy to use calculator.

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/q/quickcal/quickcal_1.0.dsc

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

  Changes since the last upload:

Closes ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882566


  Regards,
   Nathan SR

Bug#882384: ffmpeg: Gratuitous valgrind log

[Kingsley G. Morse Jr.]

Hi Carl,

> Nearly all messages seem to relate to melt, not FFmpeg.

Thanks for your informed thoughts.

> Can you reproduce any issues with ffmpeg (the executable)?
> 
> The crc issue surprises me a little: Can you produce different
> output files if you use the valgrind option --malloc-fill?

Sure.

A script is attached.

It uses ffmpeg, without melt.

I also attached two log files from valgrind.

One ran it with --malloc-fill.

The other didn't.

So,
Kingsley

-- 
Time is the fire in which we all burn.

# Demonstrate ffmpeg valgrind errors.

# If they do not already exist, create 2 input files for valgrind-ing ffmpeg.
for bailout in 0.9 10 ; do
input_file_name="/tmp/mandelbrot_bailout_${bailout}.mkv"
if ! test -e "$input_file_name" ; then
ffmpeg -t 5 -y -f lavfi -i 
mandelbrot=inner=convergence:bailout=$bailout 
/tmp/mandelbrot_bailout_${bailout}.mkv
fi
done

valgrind --fullpath-after=  \
--leak-check=full   \
--track-origins=yes \
ffmpeg  -y  \
-i /tmp/mandelbrot_bailout_0.9.mkv  \
-i /tmp/mandelbrot_bailout_10.mkv   \
-filter:v tblend=all_mode=hardlight \
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv 2>&1   |
tee /tmp/valgrind_without_--malloc-fill.log

valgrind --fullpath-after=  \
--leak-check=full   \
--track-origins=yes \
 --malloc-fill= \
ffmpeg  -y  \
-i /tmp/mandelbrot_bailout_0.9.mkv  \
-i /tmp/mandelbrot_bailout_10.mkv   \
-filter:v tblend=all_mode=hardlight \
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv 2>&1   |
tee /tmp/valgrind_with_--malloc-fill.log

==32631== Memcheck, a memory error detector
==32631== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32631== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==32631== Command: ffmpeg -y -i /tmp/mandelbrot_bailout_0.9.mkv -i 
/tmp/mandelbrot_bailout_10.mkv -filter:v tblend=all_mode=hardlight 
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv
==32631== 
--32631-- WARNING: Serious error when reading debug info
--32631-- When reading debug info from 
/usr/lib/i386-linux-gnu/libavcodec.so.57.107.100:
--32631-- get_Form_contents: DW_FORM_strp points outside .debug_str
--32631-- WARNING: Serious error when reading debug info
--32631-- When reading debug info from 
/usr/lib/i386-linux-gnu/libavutil.so.55.78.100:
--32631-- get_Form_contents: DW_FORM_strp points outside .debug_str
ffmpeg version 3.4-3 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7 (Debian 7.2.0-14)
  configuration: --prefix=/usr --extra-version=3 --toolchain=hardened 
--libdir=/usr/lib/i386-linux-gnu --incdir=/usr/include/i386-linux-gnu 
--enable-gpl --disable-stripping --enable-avresample --enable-avisynth 
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray 
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme 
--enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband 
--enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr 
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame 
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp 
--enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq 
--enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 
--enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint 
--enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  WARNING: library configuration mismatch
  avutil  configuration: --prefix=/usr --extra-version=2+b1 
--toolchain=hardened --libdir=/usr/lib/i386-linux-gnu 
--incdir=/usr/include/i386-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame 
--enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus 
--enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine 
--enable-libsnappy 

Bug#875192: [simplescreenrecorder] Future Qt4 removal from Buster

[gregor herrmann]

Control: tag -1 + patch

On Sat, 09 Sep 2017 23:09:52 +0200, Lisandro Damián Nicanor Pérez Meyer wrote:

> Source: simplescreenrecorder
> Version: 0.3.8-2
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> [announced] 
> 

simplescreenrecorder bascially has Qt5 support upstream.
With a bit of trial I managed to build the package, and the
binary also seems to work afterwards :)

Find attached my changes
- as one diff
- as 3 git patches against HEAD of the packaging repo


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 VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: R.E.M.: All The Way To Reno
From 334dd7c277ea446fb28b18bf45e73a592d0a3a10 Mon Sep 17 00:00:00 2001
From: gregor herrmann 
Date: Sat, 25 Nov 2017 05:01:19 +0100
Subject: [PATCH 1/3] debian/control: adjust build dependencies for Qt5.

---
 debian/control | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index fd2dad7..12598a7 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,9 @@ Build-Depends:
  libjack-dev | libjack-jackd2-dev,
  liboss4-salsa-dev [!linux-any],
  libpulse-dev,
- libqt4-dev,
+ libqt5x11extras5-dev,
+ qtbase5-dev,
+ qttools5-dev-tools,
  libswscale-dev,
  libx11-dev,
  libxext-dev,
-- 
2.15.0

From b4b285c09df054f8614cb671a7add118a2654b18 Mon Sep 17 00:00:00 2001
From: gregor herrmann 
Date: Sat, 25 Nov 2017 05:01:49 +0100
Subject: [PATCH 2/3] debian/rules: update build flags for Qt5.

---
 debian/rules | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2914469..60316fc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,12 @@ include /usr/share/dpkg/default.mk
 
 ARCH = $(shell dpkg --print-architecture)
 
+export QT_SELECT=5
+# cf. https://github.com/MaartenBaert/ssr/issues/498
+export QT5_CFLAGS += -fpic
+INC = $(shell pkg-config --cflags-only-I Qt5Core Qt5Gui Qt5Widgets Qt5X11Extras)
+export QT5_CFLAGS += $(INC)
+
 %:
 	dh $@ --parallel --with autotools-dev
 
@@ -17,12 +23,14 @@ ARCH = $(shell dpkg --print-architecture)
 override_dh_auto_configure:
 ifeq ($(ARCH),$(filter $(ARCH),amd64 i386 hurd-i386 kfreebsd-amd64 kfreebsd-i386 x32))
 		dh_auto_configure -- \
-		--disable-assert
+		--disable-assert \
+		--with-qt5
 else
 		dh_auto_configure -- \
 		--disable-x86-asm \
 		--disable-assert \
-		--disable-glinjectlib
+		--disable-glinjectlib \
+		--with-qt5
 endif
 
 override_dh_auto_install:
-- 
2.15.0

From cecdc793ba8202533a28c197b682544ea9386c4a Mon Sep 17 00:00:00 2001
From: gregor herrmann 
Date: Sat, 25 Nov 2017 05:02:17 +0100
Subject: [PATCH 3/3] Add patch qt5_includes.patch: adjust includes for Qt5
 build.

---
 debian/patches/qt5_includes.patch | 39 +++
 debian/patches/series |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/qt5_includes.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/qt5_includes.patch b/debian/patches/qt5_includes.patch
new file mode 100644
index 000..c8c988a
--- /dev/null
+++ b/debian/patches/qt5_includes.patch
@@ -0,0 +1,39 @@
+Description: fix includes for qt5
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2017-11-25
+
+--- a/src/Global.h
 b/src/Global.h
+@@ -22,8 +22,8 @@
+ 
+ #include "config.h"
+ 
+-#include 
+-
++// for QT_VERSION*
++#include "qglobal.h"
+ #if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
+ 
+ #include 
+@@ -59,6 +59,20 @@
+ #include 
+ #include 
+ 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++#include 
++
++#else
++
++#include 
++
+ #endif
+ 
+ #include 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..c807aae
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+qt5_includes.patch
-- 
2.15.0

diff --git a/debian/control b/debian/control
index fd2dad7..12598a7 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,9 @@ Build-Depends:
  libjack-dev | libjack-jackd2-dev,
  liboss4-salsa-dev [!linux-any],
  libpulse-dev,
- libqt4-dev,
+ libqt5x11extras5-dev,
+ qtbase5-dev,
+ qttools5-dev-tools,
  libswscale-dev,
  libx11-dev,
  libxext-dev,
diff --git a/debian/patches/qt5_includes.patch b/debian/patches/qt5_includes.patch
new file mode 100644
index 000..c8c988a
--- /dev/null
+++ b/debian/patches/qt5_includes.patch
@@ -0,0 +1,39 @@
+Description: fix includes for qt5
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2017-11-25
+
+--- a/src/Global.h
 

Bug#877041: RFA: ublock-origin -- general-purpose lightweight ads, malware, trackers blocker

[Scott Hardin]

CCing maintainer to get his attention.

Bug#651919: Any update on this bug?

[Benda Xu]

Hi,

What is the recommended way to use netns with ifupdown?

Benda

Bug#882194: stretch-pu: package spamassassin/3.4.1-6+deb9u1

[Noah Meyerhans]

On Fri, Nov 24, 2017 at 10:52:06AM +, Adam D. Barratt wrote:
> > Hello. I'd like to fix a number of bugs in spamassassin, mostly
> > related to systemd service management. A debdiff against the current
> > stretch version is attached. All the changes have been in buster for
> > some time. I've tested them in fresh installation, upgrade, remove,
> > and purge scenarios.
> 
> Please go ahead.

Thanks. Uploaded.

noah



signature.asc
Description: PGP signature

Bug#882639: sfepy: please make the documentation reproducible

[Chris Lamb]

Source: sfepy
Version: 2016.2-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that sfepy's documentation could not be built reproducibly.

(The package will still be unreproducible due to a change in the
terms.x86_64-linux-gnu.so file generated from terms.pyx, unfortunately.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

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

Bug#882640: RFP: dm-zoned-tools -- utilities for the dm-zoned device mapper

[Ben Hutchings]

Package: wnpp
Severity: wishlist

* Package name: dm-zoned-tools
  Version : 1.0.0 (?)
  Upstream Author : Western Digital
* URL : https://github.com/hgst/dm-zoned-tools
* License : GPL-3
  Programming Lang: C
  Description : Utilities for the dm-zoned device mapper

The dm-zoned device mapper provides transparent write access to zoned block
devices (ZBC and ZAC compliant devices). It hides to the device user (a file
system or an application doing raw block device accesses) any sequential write
constraint on host-managed devices and can mitigate potential device-side
performance degradation with host-aware zoned devices.

The dmzadm utility is needed to set up a device with dm-zoned.

Bug#882638: gpaw: Incorrectly creates logging files called "-" instead of logging to stdout

[Chris Lamb]

Source: gpaw
Version: 1.3.0-1
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that gpaw could not be built reproducibly.

This was caused by gpaw incorrectly creating logging files called
"-" instead of logging to stdout.

Patch attached that simply removes the "open" call - the convert_string_to_fd
method in python-ase will do the right thing and open the file if
necessary.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/fix_stdout_output.patch1970-01-01 09:00:00.0 
+0900
--- b/debian/patches/fix_stdout_output.patch2017-11-25 11:28:29.927047735 
+0900
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-11-25
+
+--- gpaw-1.3.0.orig/gpaw/response/integrators.py
 gpaw-1.3.0/gpaw/response/integrators.py
+@@ -45,8 +45,6 @@ class Integrator():
+ 
+ if comm.rank != 0:
+ txt = devnull
+-elif isinstance(txt, str):
+-txt = open(txt, 'w')
+ self.fd = convert_string_to_fd(txt, comm)
+ 
+ self.timer = timer or Timer()
--- a/debian/patches/series 1970-01-01 09:00:00.0 +0900
--- b/debian/patches/series 2017-11-25 11:28:28.863030123 +0900
@@ -0,0 +1 @@
+fix_stdout_output.patch

Bug#876191: most: configure cannot be built from source

[Benj. Mako Hill]

Greetings Helmut!


> I was trying to fix a bug in most that requires modifying configure.
> Thus I tried to regenerate it and ... failed.

I'll start by saying that this is a real bug and that I agree that it
should be fixed. And thanks so much for notice and submitting it! And
for trying to fix the other issue!

I'll also say that I'm skeptical about both the severity you've chosen
here (serious), about describing this as a FTBFS issue, and about your
suggestion that this is a DFSG issue.

After all, the package still builds from its source and I think we
have everything that upstream has.

If there is a serious DFSG issue here, it's not a FTBFS issue but
rather a question of whether or not the source package contains the
full source in the first place. I'm open to being convinced otherwise
but I think it does.

If I generate a configure file with autoconf and then modify it by
hand in order to create a working build script, I don't I've somehow
made it impossible to provide source for that package. I think I'm
still providing the preferred form of modification (as the GPL defines
source). I agree that that situation is brittle and bad and should be
avoided.  But I don't think it's a DFSG issue.

If this has been discussed elsewhere or if there is Debian policy on
this I don't know about, I'd appreciate being pointed to this and I'm
happy to defer to this. In the meantime, I'd appreciate help fixing
this issue. I'm not likely to have bandwidth for a few more weeks.

Regards,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#882637: ITP: caja-seahorse -- Caja extension which allows encryption and decryption of OpenPGP files using GnuPG

[Simon Quigley]

Package: wnpp
Severity: wishlist
Owner: Simon Quigley 

* Package name: caja-seahorse
  Version : 1.18.2
  Upstream Author : Joel Barrios 
* URL : https://github.com/darkshram/seahorse-caja
* License : GPL-2
  Programming Lang: C++
  Description : ITP: caja-seahorse -- Caja extension which allows
encryption and decryption of OpenPGP files using GnuPG

Seahorse caja is an extension for caja which allows encryption and
decryption of OpenPGP files using GnuPG. It is integrated into the caja
right-click menu, but can also be used from the command line. It's based
on seahorse-nautilus.

This package will be maintained under the umbrella of the Debian MATE Team.

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#882390: libnet-twitter-perl: tweets are truncated to 140 characters

[Vincent Lefevre]

Control: retitle -1 libnet-twitter-perl: please document how to get extended 
tweets
Control: tags -1 - unreproducible

On 2017-11-24 23:21:56 +0100, gregor herrmann wrote:
> True but we might still fix the 140 character issue.
> 
> Except that I see no mention of "140" in the code (only in the POD)?!
> The update method seems to just POST to statuses/update, and that's
> it.

I'm not talking about the "update" method, but tweets that are read,
e.g. via user_timeline. The limit of 140 characters comes from Twitter,
with the old API. However, after searching a bit, I've found that it
doesn't need any code change. The POD documentation is just misleading
(one has the impression that it gives all the parameters that are
accepted) and incomplete with the current API.

According to

  https://developer.twitter.com/en/docs/tweets/tweet-updates

one needs the "Extended" mode for REST APIs.

For user_timeline, the documentation is:

   user_timeline
   Parameters: user_id, screen_name, since_id, max_id, count,
   trim_user, exclude_replies, include_rts, contributor_details
   Required: none
[...]

It should add the "tweet_mode" parameter, and say that it can be
set to "extended" for extended mode, and say that the tweet is
available in "full_text" instead of "text".

But since this applies to several methods, this could also be a
new section in the documentation. The initial example could also
be updated, by changing

 my $statuses = $nt->friends_timeline({ since_id => $high_water, 
count => 100 });
 for my $status ( @$statuses ) {
 print "$status->{created_at} <$status->{user}{screen_name}> 
$status->{text}\n";

to

 my $statuses = $nt->friends_timeline({ since_id => $high_water, 
count => 100, tweet_mode => 'extended' });
 for my $status ( @$statuses ) {
 print "$status->{created_at} <$status->{user}{screen_name}> 
$status->{full_text}\n";

(not tried on this particular example, but this worked in my scripts
for home_timeline and user_timeline).

BTW, the URL's to the API documentation are obsolete, so that this
didn't help at the beginning.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#875516: Pending fixes for bugs in the latexdraw package

[pkg-java-maintainers]

tag 875516 + pending
thanks

Some bugs in the latexdraw package are closed in revision
04938989c2c452b8f9eac1d6407afc02e39a0631 in branch 'master' by Stuart
Prescott

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

Commit message:

Stop installing obsolete mimelnk file

Closes: #875516

Bug#882636: RM: mensis -- RoM; RoQA; unmaintained

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc:pkg-fonts-de...@lists.alioth.debian.org

Please remove mensis from Debian unstable.

It was removed from Debian Testing a year ago because it doesn't build
with the latest fontforge and upstream is "dead". mensis was not
included in Debian 9 "Stretch".

See the final comment at https://bugs.debian.org/840393

On behalf of the Debian Fonts Team,
Jeremy Bicha

Bug#882635: libretro-mupen64plus: debian/copyright refers to CC0 by URL

[Nicolas Braud-Santoni]

Package: libretro-mupen64plus
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo


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

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

Versions of packages libretro-mupen64plus depends on:
ii  libc6  2.24-17
ii  libgcc11:7.2.0-16
ii  libgl1 1.0.0-1
ii  libgl1-mesa-glx17.2.5-1
ii  libstdc++6 7.2.0-16
pn  retroarch | libretro-frontend  

libretro-mupen64plus recommends no packages.

libretro-mupen64plus suggests no packages.

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYwG4ZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z45CoEACZr/Lsb1gYcilMTTI1vHds
JYjiZ5CXoBjUwWXV1nxru8qRpfPUw6kp6nPOadk3dos3FZWMt3NNU9+OJTnmJ2mJ
YPx/RMKYTkE4BL/Ubd+si8Wo9MaNH5dxLakY+hiddEj9drGyCKfQszJpxn8IW1DD
onm6fuWA0+6G6byodcc81ZMEyN+5okCRKLR+mIl0ujs81qRGUwmPbpJivj/nBv/S
1wPmCa4cotL+Et8B3Ztjw9cS/c9U+j2QIVA2rJnPBZlkl6HoWsowOMslyO9IVEpy
rjCg4dEzT8vYRvsp+MkJ+Me+4WdqiyfpFBeAEm84UMXeBuyiArNIzm44Ih0U44zZ
n8Mg8XORR4BLBInkxJxJf2Bx+jNRymEIQiwNNXYWv5AZX6IVpmEOdwT3UF70Zsbo
huiuv4jKxSzr2GcoBZaCkaJ2aliHAWUFmEmPyDvLA+prXJsKJutPY8mLNxHqfZsA
yoyJvhuR0jE6PY6MZRpFfA5QEZVk3wKqxhPmwp+fmO/xzE+Pl8hGAAoyToGkPq8y
vkX201zc+TNQlR5mPYu4AB7mshg4Wu7L5ZNNc3CqkMaKIVziV+dLxQthLuFaJ0LF
mWKCaWqcb9eav9uWaTljRRjk3AAhyInCHkUJ1SN+k2aAoZVXVDL6l45o2x11sgke
Su1N7kj5KElPSLvWjf2vVQ==
=uDYF
-END PGP SIGNATURE-

Bug#882634: glances: debian/copyright refers to CC0 by URL

[Nicolas Braud-Santoni]

Source: glances
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo


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

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

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYwA0ZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4wPNEADIcJY42DZhe9L319RMk4h+
mU93fI5jhYL8qXGy0uCMY3NP7sB8e2uYIS/hZFMq7tdNHAayPmkRPiVDYwDLhI25
GH9TfWN6cdmGmBmmW/Gor8pKpZKr4Yd+K3CUnKJDopHO87snAC8/hlcDvKz31gIr
skjZRP1QWctdhJR3+9Qc2t2m/x9ksa+aOjiwsQAHuhYGFkI9e+s0sy2KEaCoW3OZ
ndJ3qOPdWPdjHoL+r+UXKSRaGkYk36OWuAu9lfFWeGMHU0xbgaUkld7hWvCSmmvK
bH2srcpFG3RoIOTdI0DFuV721MQw00Es0o7AzPwsRqtFTimnCtl+up+N2KTUzIZN
qtygd7nZnnHvBD4IQUta2ncki1zgM0RDgvqoZ0qfmg8PyjuNo/9X0SNVfIFFk1Tl
AOge/IiEvLdwiHoAqvTTTUN8oTlQjmz9RvpRWVh4bieEsJF/+6/hU34b52qgyRIz
uOZWDUaMZkew8FmOCceUxQvOLRCBSJvt0Y1/HRqAEd98G5HNr3bqhrCHyunJ+W+C
pjZn2pi48jvE5lsPg2I84VUrCj3HJsnANrlJ1yUJiH3XC00TkrYVUII4BGlNOKjL
uQ2w2Tb+nBQR3kq3euKqxBu3G+pPuqfKcONoT2GPWp6t5dsCSxplH0c32CcVfACy
7pe2qPzHMcSMW1pgXz4XsQ==
=yEzK
-END PGP SIGNATURE-

Bug#882633: libsodium: debian/copyright refers to CC0 by URL

[Nicolas Braud-Santoni]

Source: libsodium
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYvzUZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z40lHD/9tlyMbG56LV9/BbvWukIJi
VwomZOp1s0sNKVZS6jFzgB784AmesABGCdg7DRIUvBLBnY5ZsnxcYrFSywwGooe7
+Rjmf2yrOroWpBKtM6M/cgawPPOvohiZzHivKurKpYEpHYxRgiLEF5q2xeL7rAhU
pEkRmFbSdD+Q833PBWN1rQ9wZldOywPaEPqbNd4EP1FNyXaNCHviSXxAqFJ0eyIT
1nArk3WuwXwhy2oeJggNjLJcf8NCJ2Rktkr1eRNwuSZapte1Z/e95M+nd8vVyTSl
uvCHKovTeQBzPGabT2JkbdKaknmvgTO5FKS/PhavcWvI6VKJ76W5uGQbk2J+70LK
sqXPSdwgfl7fNFk1kB5cBNhhaHy85RmiSSt/AlkvrdTL/FwFWl08cwLIukNBiLVk
HfRKjqGLZikoc2M9iw5zikKeZm2ea8tr1vO+lABGyJ604GsxIHa4hftaz0o0Zb1n
gQu4mQ3dEqgKwWAw587VzWyTqSqaZU/kEMdz4AnR8o0u+82Y7+Eal8NFUMzxnclY
TsEfPMaInc/0g8Z1505bbGYDAqKUtPqpNtWxD4PkqnZLoLTkeh5ouXIpZRt2FDuH
PccLeDWKTosL9hgjp9JXjkfZ22Nqh/tdkSfjxo+TxZI33gptf4yhJlsrSzTeLpFK
KcM01qLJ0zqLaDtoZKGOmg==
=tRkK
-END PGP SIGNATURE-

Bug#882632: libgit2: debian/copyright refers to CC0 by URL

[Nicolas Braud-Santoni]

Source: libgit2
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYvnMZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4yHuD/9tbJ7PtEMZPmRTYwJnwsFc
h4cxemzmDyseNQsSdym5rXTDr52fXObms0aAba+NLuDkbT5meWTg6Qjy1zRoEl0g
PL8+RbI/v1pfC+xoP5RUy+N4FhakgBoNaKSoRD/xenwzunDuZI9tTnkbZwbGQXcV
ob0SVRRVVZuLQJeVNbZX3MjpgKog189YfwTp738jDqNfHNTmAEPGKtdZMNcUsuQD
OaAmnjaJuak7PaATTNCXnFAtXzbshQu3Lok7/Lo851egymSgu5+aKriXWDFfoHNZ
L9ir/PQawshQqkF6p20EGPDm7m7wqEkt9/pqzoHfQyaXCKB5nUul+nro+WVKMhze
ujg+VaK04yb60q/dZ9XzLKYIgU0Lp47ccGImY2geC/y8FQwu6dtMRghzibg3hVb5
8X/4R2yjDWWC73sWM9D/OA90fHwZ7PYdlvX58ZAX8LCbnDeulAPvFxJgXr7xHtU9
3pzCxJkn3nMomDzyrAHLP/UoEzZ1s7Ige5VthSDx4jI8fOT9v3cahXXkm/rZNOQM
+iwqiOMlaAhSYLkTqTnb8glpUJbIZEquWiAdaHoXavWHFYj8NfpeI6DeqgvuBRum
D1jiigqkQ6J2p/1UvclOT/r4weCwR5BMGE956EqA5J6E1vgTP8ecrzGGjAgCJgR2
+KPyPuM7aB+VDqL6HjKV5A==
=9UK/
-END PGP SIGNATURE-

Bug#882631: picmi: debian/control refers to CC0 by URL

[Nicolas Braud-Santoni]

Package: picmi
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYvWcZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4xzKD/9S/Vc90wQ4KuAzDh9ORYNs
gtzeurhVF4h4SXdvrQap2USLCL8BGSOs9AsmKp7WrSgE+03v3WvPb/JvSVjv3hZN
l1ZoGGVVTE/GKEK2bApNFpkO82eVOdSwX35Og89Yh1Iy17httajDbvSA7x8HbJ9V
N4VUN3UmQ6IuyNR7rky0HShek1jLiMYb9/AFnMu8B7Zunl4OpBtej0ccT9wyXJrs
exfPUhkv5BgWcHRJHRePGQSNJUaljfXAFG1YZmin3GuTKdgGQwd1Q6Un5OoJIR8i
b/RsnOwxFgp1z+jDqI8+GJowB+l74NNOb7eu2kPx5L2lJzgbWaV+HAH6bVKm0LQW
TNVivhsn/WRL4oLoJhizjV44sbr8HxVE45L5AbbtFwKVEiczfLS4lt1FWz0tiBMA
Gpy/gyOLcwN6Joj9svJD1+utMV7JDsO9QmaiHfO2HRgFH24LMHC/gFNRIORBggxc
A9/LJsrQcfITqRxVnNzmzuLtLTe7H0kEPwc+C5VeKacro5UPy9CEbKXXRoJ2RO+G
VSReuWM0ZxiTGMzoCzi+zd0EhqZ4kbOYu046B7Iv8kRTVqdPIX7Se50wKEVvPWmF
L1RbfVVwyHD2stD/E6B6L8AW9P9x06A15ZrUp4VjTGCXRKV047Yq/ih0yS59fC4g
++/zCaiO9OtC/q4kpVMp7Q==
=Tm14
-END PGP SIGNATURE-

Bug#882630: systemd-bootchart: debian/control refers to CC0 by URL

[Nicolas Braud-Santoni]

Package: systemd-bootchart
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYvLAZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z46ptD/4htt8y2sskTGj9gEqrS6cB
ccvvPYkKqJ7an6p7BaEpA/EoAwMPJ67dFfgSw/e0s2a6Ne8asQCGH1prRtOkmXXx
bW7ZvuGzeQSbSXopGHVWHAMH7cByo5nFPZDSpqaRFaNFLSl9PTIQCrfd/TOlHXZd
iQujk/iKYyXEs41drTQKF1wxqI7twMtE9dT2osnTwNkcj3bhaOj9x6eWe0yzMCL6
zhIMkzS0ipsT5BEx6Y1Ifweu3D4dwc6Z0k0UgeueLkkzU0MitjRxBEZv1kB/qKp+
ceT+2LooMqJ/0ouhFedUqzGTn4gM8jC9bxfN3uQfwO1kXFc1eNX3IaeZY1YqZBnj
ml/yMCS0ZQ/8BTZMpLysLH7cNC6Z2AlhVLsnhk47ts75P+YFrgFbC9X2XCQ4e/LW
CakG0JvLjroHOZFxzNgc3KPUNriUifW6DSu8CMjK96dr9AzmBvzLiuE29NZj4gg/
5JokPgBXrs5g6gnleO/F+Ogrif79QVCsSxackj1ci06jW/yi1yXvUike1N8bqC7S
oXNg2TuLgTOO4yPsDcjcpL2pNiDYDCY2AMFvwC/e3PKEeNFAHhwphlz48WNXAvJe
Jz6YC+hTYLQPAy+Rh43FWEV4asYQpUII9ESnD8q3wZex5dWlJ5jqdKi+yIIZARNz
JTKkXvFo8CsCYXmiNClEQw==
=mVQK
-END PGP SIGNATURE-

Bug#882629: systemd: debian/copyright refers to the CC0 license by URL

[Nicolas Braud-Santoni]

Package: systemd
Version: 235-3
Severity: normal
Control: tag -1 + stretch buster
Control: block -1 by 882628

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

This package refers to the text of the Creative Commons Zero license by its URL
on creativecommons.org; as far as I understand, the Debian policy requires that
we ship the actual text of the license [0].

I requested (in #882628) that CC0 be shipped in /usr/share/common-licences, so
it might become possible to refer to that file if you do not wish to include the
whole text in debian/copyright.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYu/UZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z48wzD/0XQ1/RZx2KSz/lphxed0pq
U/e85zmFE1mRkKsoCxyBiZx67ArGzMFzBruqUi5FEQfNsS8CiKUoRn0aYaA4Vst8
5wzCrzX6KBg7de0fBQ5SpEELOkf1MOQ4msSVTS38zfi+94CqyfHmAAVQFD34czTN
I2C41JyI3HxFFVNnbITlpSzRm/G822WvpqlA9mjxPOaJ/ObCksvuU/ocWQHNOiUQ
ae0NRj0hGKYkCddTO9R5VXXQpk3sCC6/abO67HnVou4oPRRTJXswlpwUkHnMZOKi
fH9De097mb0iDmbO0/Gjb//A7ojhxGBcoyzfnKJpRG/eFFcKvCJVuu2xohgskN7J
xl0gvs3Moyyu44zhEADiKJOYG510nVbEgVANcmhzuV2GKz18qP/n27T5pMfbWi/e
GDO6zuwEYStbRCcOutUOjyUEGsWciAhaOwhKr0hzY/AI7c8Vg2u2b5pLxbDfMAaR
1w+xw8gI7a5F0fCJn2TDcw/R5Pw6F4Fr/kiGkRhRoiB3vj9b9Mae9cn00RFnSH71
nP6vz+tUVKJqf84Ruien/cH/rCf77nygijpe4m6I5lROHKjDDet16Vq1FNUXjZy1
gOTgmV5d/tVque3afrMev99RKaS0GbYxhrkTpa3njH7JEQxgP4HTaXzBWQoPSILA
3sTYIKOLIW5pnb7YaiJo9Q==
=tQZ2
-END PGP SIGNATURE-

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

On Fri, Nov 24, 2017 at 10:05:29PM +0100, Vincent Bernat wrote:
>  ❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni 
>  :
> For 8 packages, you can file the bug directly. As for severity, people
> may not agree with the interpretation of the policy: CC0 is equivalent
> to public domain and the license text is very verbose. It would be
> easier to push the change without a "threatening" severity.

Thanks a bunch for the explanation and upload  :)


signature.asc
Description: PGP signature

Bug#882628: base-files: Please ship CC0 in /usr/share/common-licences

[Nicolas Braud-Santoni]

Package: base-files
Version: 10
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainers,

A number of packages are licensed under the Creative Commons Zero license,
version 1.0, some of which refer to it by its URL at creativecommons.org (which
is a violation of Debian policy, for which I will open bugs on the individual
packages)

Could we ship the license in /usr/share/common-licences?
This would be fairly helpful in getting those packages fixed,
and keeping readable/concise debian/copyright files.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloYuPEZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z49auEADXQ6z4ioNs/zTMbiSAo3+j
JDlZAtXTXaY5jDwOZZrSDSpUEOnkL1ddcOuSFm4fGJQpyVMUOeOPc9msx7mX/04R
MpQQYEGCG+vFUc7PKaeaOgwCe5Q1RgQuS7Scn6fT313P0U90qvAwq0QhmBFJNlSn
KPhwUXEl1D8LpqZUsbFp0cgvndcrJDtn4QNO7o4ciEWloJLOP6ixtHuP37xyZPfp
fBf7yaV+CQhskyqwyh4UNrSbupx/UZRVZGmOs+02wKOOk4dxtBNTR9rKCq2Ci9B5
Ngv6cCoI+H7tIuMROFqCVHK7LnxpwCuP5JBIUTih/m2zojDnzMYJ4PaY0Eooz/ZT
S6o63ruAMUrT3SvkqriOdo9F/6O2O6YsGdJPp+50VIwb26ysfKU87FlYwQHILEkA
bawTUCtelzg3eNsxI6rY12BdaP8Hn1jW9DCaFs5OolV3W9DGcaAUMYL/hm3k/eYt
h7V4+rHWzYciSAKSS5P5DXSufzkRCl7XspEYVvg2lxKCJ8DjqXMZs4ZNOU5lCVtA
fZ1YQSkk+GsjkbRZuBiJf9YEPL98eDdHjIEiUJSZ+Hi4+IDB/Xs22IvWfrsibxne
ZttBu5Rtq3jXP9CmRaaprgSupDnEsmYZBuBHBZV2nmJIcUF9YcWqSIG4wWA4+Isk
3vPIgKMDyujjr+R7LhaaIg==
=cGXK
-END PGP SIGNATURE-

Bug#877403: stretch-pu: package dbus/1.10.24-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-11-23 at 23:30 +, Cyril Brulebois wrote:
> Simon McVittie  (2017-11-23):
> > On Thu, 23 Nov 2017 at 12:18:00 +, Adam D. Barratt wrote:
> > > This was uploaded and I was going to accept it, but then our
> > > tooling
> > > reminded me that dbus produces a udeb.
> > 
> > dbus-udeb and libdbus-1-3-udeb were requested because there was a
> > plan
> > to use AT-SPI in the graphical installer. I don't know whether this
> > ever
> > happened. https://wiki.debian.org/DebianInstaller/Accessibility
> > doesn't
> > document any features that seem AT-SPI-related (other than hearing
> > Orca
> > after installation, which doesn't need udebs), but perhaps it's out
> > of date?
> 
> We don't have big enough a team to guarantee we have a comprehensive
> or up-to-date documentation… anyway, I've just checked that there's
> nothing that seems to depend on either udebs in stretch, so feel free
> to go ahead with an accept.

Thanks; flagged for acceptance.

Regards,

Adam

Bug#882627: thunderbolt NULL pointer dereference

[Josh Triplett]

Package: src:linux
Version: 4.14-1~exp1
Severity: important

Got the following messages:

Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: NHI initialized, starting 
thunderbolt
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: allocating TX ring 0 of 
size 10
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: allocating RX ring 0 of 
size 10
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: control channel created
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: control channel starting...
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: starting TX ring 0
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: enabling interrupt at 
register 0x38200 bit 0 (0x0 -> 0x1)
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: starting RX ring 0
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: enabling interrupt at 
register 0x38200 bit 12 (0x1 -> 0x1001)
Nov 24 15:31:29 s kernel: thunderbolt :08:00.0: starting ICM firmware
Nov 24 15:31:29 s kernel: BUG: unable to handle kernel NULL pointer dereference 
at 0988
Nov 24 15:31:29 s kernel: IP: pci_write_config_dword+0x5/0x30
Nov 24 15:31:29 s kernel: PGD 0 P4D 0 
Nov 24 15:31:29 s kernel: Oops:  [#1] SMP
Nov 24 15:31:29 s kernel: Modules linked in: thunderbolt(+) rtsx_pci_ms 
videobuf2_core memstick videodev media cdc_mbim(+) cdc_wdm qcserial 
drm_kms_helper cfg80211 ucsi_acpi cdc_ncm thinkpad_acpi(+) typec_ucsi usb_wwan 
usbnet nvram mei_me drm snd mii i2c_algo_bit drbg(+) usbserial shpchp 
intel_pch_thermal mei typec so
Nov 24 15:31:29 s kernel:  thermal i2c_hid hid
Nov 24 15:31:29 s kernel: CPU: 0 PID: 297 Comm: systemd-udevd Not tainted 
4.14.0-trunk-amd64 #1 Debian 4.14-1~exp1
Nov 24 15:31:29 s kernel: Hardware name: LENOVO 20HRCTO1WW/20HRCTO1WW, BIOS 
N1MET37W (1.22 ) 07/04/2017
Nov 24 15:31:29 s kernel: task: 9b7714f3e000 task.stack: b3af811e4000
Nov 24 15:31:29 s kernel: RIP: 0010:pci_write_config_dword+0x5/0x30
Nov 24 15:31:29 s kernel: RSP: :b3af811e7a18 EFLAGS: 00010282
Nov 24 15:31:29 s kernel: RAX: 4126 RBX:  RCX: 
0050
Nov 24 15:31:29 s kernel: RDX: 0200 RSI: 0034 RDI: 

Nov 24 15:31:29 s kernel: RBP: b3af811e7a50 R08: 0200 R09: 
032e
Nov 24 15:31:29 s kernel: R10: 2000 R11:  R12: 

Nov 24 15:31:29 s kernel: R13: 0050 R14: 9b7713f68b30 R15: 

Nov 24 15:31:29 s kernel: FS:  7f289d3a98c0() GS:9b772240() 
knlGS:
Nov 24 15:31:29 s kernel: CS:  0010 DS:  ES:  CR0: 80050033
Nov 24 15:31:29 s kernel: CR2: 0988 CR3: 000294f1b006 CR4: 
003606f0
Nov 24 15:31:29 s kernel: Call Trace:
Nov 24 15:31:29 s kernel:  ? pcie2cio_write+0x43/0x90 [thunderbolt]
Nov 24 15:31:29 s kernel:  icm_driver_ready+0x175/0x270 [thunderbolt]
Nov 24 15:31:29 s kernel:  ? tb_ctl_start+0x50/0x90 [thunderbolt]
Nov 24 15:31:29 s kernel:  tb_domain_add+0x76/0xf0 [thunderbolt]
Nov 24 15:31:29 s kernel:  nhi_probe+0x19e/0x310 [thunderbolt]
Nov 24 15:31:29 s kernel:  local_pci_probe+0x42/0xa0
Nov 24 15:31:29 s kernel:  pci_device_probe+0x149/0x1b0
Nov 24 15:31:29 s kernel:  driver_probe_device+0x2ff/0x450
Nov 24 15:31:29 s kernel:  __driver_attach+0xa4/0xe0
Nov 24 15:31:29 s kernel:  ? driver_probe_device+0x450/0x450
Nov 24 15:31:29 s kernel:  bus_for_each_dev+0x6e/0xb0
Nov 24 15:31:29 s kernel:  driver_attach+0x1e/0x20
Nov 24 15:31:29 s kernel:  bus_add_driver+0x1c7/0x270
Nov 24 15:31:29 s kernel:  ? 0xc0801000
Nov 24 15:31:29 s kernel:  driver_register+0x60/0xe0
Nov 24 15:31:29 s kernel:  ? 0xc0801000
Nov 24 15:31:29 s kernel:  __pci_register_driver+0x5a/0x60
Nov 24 15:31:29 s kernel:  nhi_init+0x28/0x1000 [thunderbolt]
Nov 24 15:31:29 s kernel:  do_one_initcall+0x50/0x190
Nov 24 15:31:29 s kernel:  ? __vunmap+0x81/0xb0
Nov 24 15:31:29 s kernel:  do_init_module+0x5f/0x1f9
Nov 24 15:31:29 s kernel:  load_module+0x2542/0x2c00
Nov 24 15:31:29 s kernel:  ? security_kernel_post_read_file+0x6b/0x80
Nov 24 15:31:29 s kernel:  SYSC_finit_module+0xfc/0x120
Nov 24 15:31:29 s kernel:  ? SYSC_finit_module+0xfc/0x120
Nov 24 15:31:29 s kernel:  SyS_finit_module+0xe/0x10
Nov 24 15:31:29 s kernel:  do_syscall_64+0x80/0x120
Nov 24 15:31:29 s kernel:  entry_SYSCALL64_slow_path+0x25/0x25
Nov 24 15:31:29 s kernel: RIP: 0033:0x7f289cce6b69
Nov 24 15:31:29 s kernel: RSP: 002b:7ffdb6770e88 EFLAGS: 0246 ORIG_RAX: 
0139
Nov 24 15:31:29 s kernel: RAX: ffda RBX: 563263ed1fd0 RCX: 
7f289cce6b69
Nov 24 15:31:29 s kernel: RDX:  RSI: 7f289c9f92d5 RDI: 
0007
Nov 24 15:31:29 s kernel: RBP: 7f289c9f92d5 R08:  R09: 
563263ec7710
Nov 24 15:31:29 s kernel: R10: 0007 R11: 0246 R12: 

Nov 24 15:31:29 s kernel: R13: 563263ed4a50 R14: 0002 R15: 
7ffdb6770fa0

Bug#882043: apparmor should allow thunderbird to open links with firefox via exo-helper on xfce

[Ben Caradoc-Davies]

On 24/11/17 07:04, intrigeri wrote:

Could you please try reproducing this with thunderbird 1:52.4.0-2~exp1
or newer, currently available in Debian experimental?


This bug is still present in thunderbird 1:52.4.0-2~exp1. journalctl 
reports:


Nov 25 11:55:28 ripley audit[1401]: AVC apparmor="DENIED" 
operation="exec" profile="thunderbird" name="/usr/lib/firefox/firefox" 
pid=1401 comm="exo-helper-1" requested_mask="x" denied_mask="x" 
fsuid=1000 ouid=0
Nov 25 11:55:28 ripley kernel: audit: type=1400 
audit(1511564128.841:36): apparmor="DENIED" operation="exec" 
profile="thunderbird" name="/usr/lib/firefox/firefox" pid=1401 
comm="exo-helper-1" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0


Kind regards,
Ben.

Bug#882626: debhelper: dh_installdeb should error out on invalid dpkg-maintscript-helper arguments

[Andreas Beckmann]

Package: debhelper
Version: 10.10.9
Severity: normal

Since shell escaping the dpkg-maintscript-helper arguments can produce
invalid parameters, dh_installdeb should check whether the version and
package arguments (if given) are valid for a package name or version.
E.g. \$VARIABLE (after unescaping: $VARIABLE) cannot be a valid package
name or '1.2-3\~4' (after unescaping: 1.2-3\~4) cannot be a valid
version.

There is #880430 requesting a lintian check, but it would probably be
better not to generate known broken packages. This brokenness may not be
detected immediately, but only on special upgrade paths. (The lintian
bug has references to an occurrence in the package name (needed a
special upgrade path to show up) and another one in the version).


Andreas

Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config

[Manuel A. Fernandez Montecelo]

2017-11-24 14:03 GMT+01:00 Harshula :
> Upstream is planning a minor release. I'll include the fix to this with
> that.

Sounds good!  Thanks for the update.

-- 
Manuel A. Fernandez Montecelo 

Bug#874153: FTBFS with Java 9: jre/bin/java

[Emmanuel Bourg]

Le 24/11/2017 à 23:37, Dirk Eddelbuettel a écrit :

> I (very respectfully) decline.
> 
> I have had enough "fun" keeping this working, and I don't even use Java.  If
> *you* want to experiment, by all means do.  Change debian/{rules,control} for
> r-base, then try building r-cran-rjava.  I _seriously_ doubt we will get by
> with JRE because this setup is for _building_ R and Java interface, not just
> running one.

Sorry I don't understand, I thought you were looking for a way to test
building/running with OpenJDK 9, in this case pulling
default-jre/default-jdk from experimental is the best approach (you can
also play with update-java-alternatives or set the JAVA_HOME variable
but that's not strictly equivalent).

If you manage to drop the direct dependency on the openjdk-* packages
you won't have to update the R packages twice a year, I thought you
would appreciate a suggestion intended to lower your workload.

Emmanuel Bourg

Bug#882625: ring FTBFS with libopendht-dev 1.5.0-1

[Adrian Bunk]

Source: ring
Version: 20171024.1.eadbdeb~ds1-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ring.html

...
ringaccount.cpp: In member function 'void 
ring::RingAccount::loadAccountFromDHT(const string&, const string&)':
ringaccount.cpp:1139:33: error: no matching function for call to 
'dht::DhtRunner::bootstrap(std::vector >&)'
 dht_.bootstrap(bootstrap);
 ^
In file included from ringaccount.h:35:0,
 from ringaccount.cpp:24:
/usr/include/opendht/dhtrunner.h:205:10: note: candidate: void 
dht::DhtRunner::bootstrap(const std::vector&, 
dht::DoneCallbackSimple&&)
 void bootstrap(const std::vector& nodes, DoneCallbackSimple&& 
cb={});
  ^
/usr/include/opendht/dhtrunner.h:205:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const std::vector&'
/usr/include/opendht/dhtrunner.h:206:10: note: candidate: void 
dht::DhtRunner::bootstrap(const dht::SockAddr&, dht::DoneCallbackSimple&&)
 void bootstrap(const SockAddr& addr, DoneCallbackSimple&& cb={});
  ^
/usr/include/opendht/dhtrunner.h:206:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const dht::SockAddr&'
/usr/include/opendht/dhtrunner.h:212:10: note: candidate: void 
dht::DhtRunner::bootstrap(const std::vector&)
 void bootstrap(const std::vector& nodes);
  ^
/usr/include/opendht/dhtrunner.h:212:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const std::vector&'
/usr/include/opendht/dhtrunner.h:220:10: note: candidate: void 
dht::DhtRunner::bootstrap(const string&, const string&)
 void bootstrap(const std::string& host, const std::string& service);
  ^
/usr/include/opendht/dhtrunner.h:220:10: note:   candidate expects 2 arguments, 
1 provided
ringaccount.cpp: In member function 'void ring::RingAccount::doRegister_()':
ringaccount.cpp:2067:37: error: no matching function for call to 
'dht::DhtRunner::bootstrap(std::vector >&)'
 dht_.bootstrap(bootstrap);
 ^
In file included from ringaccount.h:35:0,
 from ringaccount.cpp:24:
/usr/include/opendht/dhtrunner.h:205:10: note: candidate: void 
dht::DhtRunner::bootstrap(const std::vector&, 
dht::DoneCallbackSimple&&)
 void bootstrap(const std::vector& nodes, DoneCallbackSimple&& 
cb={});
  ^
/usr/include/opendht/dhtrunner.h:205:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const std::vector&'
/usr/include/opendht/dhtrunner.h:206:10: note: candidate: void 
dht::DhtRunner::bootstrap(const dht::SockAddr&, dht::DoneCallbackSimple&&)
 void bootstrap(const SockAddr& addr, DoneCallbackSimple&& cb={});
  ^
/usr/include/opendht/dhtrunner.h:206:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const dht::SockAddr&'
/usr/include/opendht/dhtrunner.h:212:10: note: candidate: void 
dht::DhtRunner::bootstrap(const std::vector&)
 void bootstrap(const std::vector& nodes);
  ^
/usr/include/opendht/dhtrunner.h:212:10: note:   no known conversion for 
argument 1 from 'std::vector >' to 
'const std::vector&'
/usr/include/opendht/dhtrunner.h:220:10: note: candidate: void 
dht::DhtRunner::bootstrap(const string&, const string&)
 void bootstrap(const std::string& host, const std::string& service);
  ^
/usr/include/opendht/dhtrunner.h:220:10: note:   candidate expects 2 arguments, 
1 provided
mv -f .deps/libringacc_la-namedirectory.Tpo 
.deps/libringacc_la-namedirectory.Plo
Makefile:573: recipe for target 'libringacc_la-ringaccount.lo' failed
make[6]: *** [libringacc_la-ringaccount.lo] Error 1

Bug#868655: gnome-software: Missing dependancy to libgnome-menu-3-0

[Jeremy Bicha]

Control: tags -1 unreproducible

I can't reproduce this issue in either Debian 9.2 "Stretch" or in
Debian Testing. I uninstalled libgnome-menu-3-0 and made sure to
completely stop gnome-software. gnome-software worked fine.

Thanks,
Jeremy Bicha

Bug#874846: Are diffpdf and comparepdf dead?

[Stuart Prescott]

It seems that diffpdf and comparepdf have been close-sourced and while there 
are a couple of code-dumps of previous releases inside VCSes, there doesn't 
appear to be an active fork that will maintain them into the future.

In the absence of either a new upstream appearing or a new maintainer for Qt4 
appearing, it is perhaps sadly time to remove these packages from Debian.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#882624: sbd FTBFS with glibc 2.25

[Adrian Bunk]

Source: sbd
Version: 1.3.1-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sbd.html

...
sbd-common.c: In function 'watchdog_populate_list':
sbd-common.c:268:13: error: In the GNU C Library, "makedev" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "makedev", include 
 directly. If you did not intend to use a system-defined macro
 "makedev", you should undefine it after including . [-Werror]
   {makedev(10,130), 0};
 ^~~



   
sbd-common.c:293:13: error: In the GNU C Library, "makedev" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "makedev", include 
 directly. If you did not intend to use a system-defined macro
 "makedev", you should undefine it after including . [-Werror]
   watchdogs[num_watchdogs++] = makedev(major, minor);
 ^  



   
sbd-common.c:342:13: error: In the GNU C Library, "major" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "major", include 
 directly. If you did not intend to use a system-defined macro
 "major", you should undefine it after including . [-Werror]
 major(watchdogs[i]), minor(watchdogs[i]));
 ^~ 



 
sbd-common.c:342:13: error: In the GNU C Library, "minor" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "minor", include 
 directly. If you did not intend to use a system-defined macro
 "minor", you should undefine it after including . [-Werror]
cc1: all warnings being treated as errors
Makefile:397: recipe for target 'sbd-common.o' failed
make[3]: *** [sbd-common.o] Error 1

Bug#882623: mahimahi FTBFS with glibc 2.25

[Adrian Bunk]

Source: mahimahi
Version: 0.97-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mahimahi.html

...
g++ -DHAVE_CONFIG_H -I. -I../..  -std=c++11 -pthread -Wdate-time 
-D_FORTIFY_SOURCE=2 -pedantic -Wall -Wextra -Weffc++ -Werror -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -c -o socketpair.o 
socketpair.cc
socketpair.cc: In member function 'FileDescriptor UnixDomainSocket::recv_fd()':
socketpair.cc:73:67: error: reinterpret_cast from type 'const unsigned char*' 
to type 'int*' casts away qualifiers
 return *reinterpret_cast( CMSG_DATA( control_message ) );
   ^
Makefile:440: recipe for target 'socketpair.o' failed
make[4]: *** [socketpair.o] Error 1

Bug#882600: Allow maintainers to use different email addresses without raising NMU warnings

[Chris Lamb]

Hi Christoph,

> What would the lintian maintainers suggest?

As Russ suggests, adding yourself to Uploaders appears to be
cleanest option available at the moment.

Indeed, any solution that doesn't make the matching more fuzzy in
some way (eg. matching the name part only as you outline) must
necessarily capture the alternative address in the source package
*somewhere*.

In other words, it cannot be part of the local user's Lintian
configuration files or environment as that would mean it would warn
on lintian.d.o and other continuous integration platforms.

>From that point of view Uploaders seems more sensible than it first
appears, and somewhat more obvious than adding some kind of
"debian/source/other-uploaders" or somesuch.

However I wonder if there is a case for debian/source/lintian-options
that would enable name-matching per-package.. *g*


Best wishes,

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

Bug#874153: FTBFS with Java 9: jre/bin/java

[Dirk Eddelbuettel]

On 24 November 2017 at 23:15, Emmanuel Bourg wrote:
| Le 24/11/2017 à 20:10, Dirk Eddelbuettel a écrit :
| 
| > I may do another RC build before R 3.4.3 is out later next week.  Not
| > entirely sure how to test it because actual Depends: result from this.  So 
if
| > I start with java 9 it may be be java 9 and nothing else.
| 
| Ideally the package should depend on default-jre only, and not on
| openjdk-{8,9}-jre. This will avoid updating the R packages for new Java
| releases (they will now come every 6 months now, Java 10 is targeted for
| March 2018).
| 
| If you want to test with OpenJDK 9 as the default JRE you can install
| the default-jre package from experimental.


I (very respectfully) decline.

I have had enough "fun" keeping this working, and I don't even use Java.  If
*you* want to experiment, by all means do.  Change debian/{rules,control} for
r-base, then try building r-cran-rjava.  I _seriously_ doubt we will get by
with JRE because this setup is for _building_ R and Java interface, not just
running one.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#882622: networking-mlnx FTBFS: test failures

[Adrian Bunk]

Source: networking-mlnx
Version: 1:9.0.0~b1-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes networking-mlnx FTBFS:

https://tests.reproducible-builds.org/debian/history/networking-mlnx.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/networking-mlnx.html

...
==
FAIL: 
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test__output_hosts_file_log_only_twice
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test__output_hosts_file_log_only_twice
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File 
"/usr/lib/python2.7/dist-packages/neutron/tests/unit/agent/linux/test_dhcp.py", 
line 2178, in test__output_hosts_file_log_only_twice
dm._output_hosts_file()
  File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/dhcp.py", line 
702, in _output_hosts_file
if self._get_port_extra_dhcp_opts(port):
  File "networking_mlnx/dhcp/mlnx_dhcp.py", line 45, in 
_get_port_extra_dhcp_opts
if hasattr(port, edo_ext.EXTRADHCPOPTS):
AttributeError: 'module' object has no attribute 'EXTRADHCPOPTS'


==
FAIL: 
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_and_opts_file_on_net_with_V6_stateless_and_V4_subnets
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_and_opts_file_on_net_with_V6_stateless_and_V4_subnets
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File "networking_mlnx/tests/unit/dhcp/test_mlnx_dhcp.py", line 219, in 
test_host_and_opts_file_on_net_with_V6_stateless_and_V4_subnets
dm._output_hosts_file()
  File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/dhcp.py", line 
691, in _output_hosts_file
if not no_opts and self._get_port_extra_dhcp_opts(port):
  File "networking_mlnx/dhcp/mlnx_dhcp.py", line 45, in 
_get_port_extra_dhcp_opts
if hasattr(port, edo_ext.EXTRADHCPOPTS):
AttributeError: 'module' object has no attribute 'EXTRADHCPOPTS'


==
FAIL: 
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_and_opts_file_on_stateless_dhcpv6_network
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_and_opts_file_on_stateless_dhcpv6_network
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File 
"/usr/lib/python2.7/dist-packages/neutron/tests/unit/agent/linux/test_dhcp.py", 
line 2237, in test_host_and_opts_file_on_stateless_dhcpv6_network
dm._output_hosts_file()
  File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/dhcp.py", line 
691, in _output_hosts_file
if not no_opts and self._get_port_extra_dhcp_opts(port):
  File "networking_mlnx/dhcp/mlnx_dhcp.py", line 45, in 
_get_port_extra_dhcp_opts
if hasattr(port, edo_ext.EXTRADHCPOPTS):
AttributeError: 'module' object has no attribute 'EXTRADHCPOPTS'


==
FAIL: 
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_file_on_net_with_v6_slaac_and_v4
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_host_file_on_net_with_v6_slaac_and_v4
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File "networking_mlnx/tests/unit/dhcp/test_mlnx_dhcp.py", line 260, in 
test_host_file_on_net_with_v6_slaac_and_v4
dm._output_hosts_file()
  File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/dhcp.py", line 
702, in _output_hosts_file
if self._get_port_extra_dhcp_opts(port):
  File "networking_mlnx/dhcp/mlnx_dhcp.py", line 45, in 
_get_port_extra_dhcp_opts
if hasattr(port, edo_ext.EXTRADHCPOPTS):
AttributeError: 'module' object has no attribute 'EXTRADHCPOPTS'


==
FAIL: 
networking_mlnx.tests.unit.dhcp.test_mlnx_dhcp.TestMlnxDnsmasq.test_non_local_subnets

Bug#860994: libpodofo: CVE-2017-8053 partially fixed upstream

[Matthew Brincke]

Hello,

the "infinite recursion" part of this bug is already
fixed upstream since svn r1834 [1] in the trunk of the
PoDoFo repository, committed on 2017-03-24 as "Fix
stack overflow crash when XRef record references itself".

The "stack consumption" part, which can also lead to a stack
overflow when the relevant parts of the input file are large
enough or the stack size is small enough, has not been fixed
yet AFAIK, though I hope such a fix will be contributed on the
podofo-users mailing list shortly, so please stay tuned there.

[1] https://sourceforge.net/p/podofo/code/1834/

Bug#870771: gnome-software: packages with AGPL-3 license are claimed to be non-free

[Jeremy Bicha]

hoteldruid doesn't show in the GNOME Software app because of these issues:

https://appstream.debian.org/sid/main/issues/hoteldruid.html

To be more specific, your app icon needs to be at least 64x64.

I suggest removing the .xpm icon since it's legacy and not needed any
more (although it shouldn't cause AppStream problems any more).

The most common license for AppStream metadata is CC0-1.0.

Once those issues are fixed in Debian (and you've waited a day or two
for Debian's metadata to be updated), I expect hoteldruid will show
correctly in the GNOME Software app.

Thanks,
Jeremy Bicha

Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights

[Rene Engelhard]

On Fri, Nov 24, 2017 at 02:33:20PM +0100, Michael Ott wrote:
> Package: libreoffice
> Version: 1:5.4.3-2
> Severity: important
> 
> Dear Maintainer,
> 
> start libreoffice with
> soffice -env:UserInstallation=file:///tmp/test
> always works
> 
> start libreoffice with
> soffice -env:UserInstallation=file:///srv/home/michael/tmp/
> does not work. Home folder is srv/home/michael

Sigh. Feared something like this.

So you try to access stuff outside the LO profile?

>From the profile:

https://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/apparmor/program.soffice.bin#n93:

owner @{HOME}/.config/libreoffice{,dev}/** rwk,

so no access outside its profile allowed if I read that right.
I'd guess that soffice -env:UserInstallation=file:///srv/home/michael would 
work?

The profile also says:

"# This profile should enable the average LibreOffice user to get their 
# work done while blocking some advanced usage
# Namely not tested and likely not working : embedded plugins,
# Using the LibreOffice SDK and other development tasks"

> 1. Start system
> 2. Start libreoffice.
> -> cannot start because of to less user rights in config folder
> 3. Switch of apprmor with service apparmor teardown

Or aa-unconfined/-disable?

> 4. Start libreoffice
> -> works
> 5. Close libreoffice
> 6. Start apparmor
> 6. Start libreoffice
> -> works again

You mean _not_ after 6?. Otherwise this doesn't make sense?

> 
> I hope that it helps

Unfortunately there seems no way to install a profile but keep it
"unconfined), only to just disable it.. Maybe I should keep it
installed but disabled...

> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (700, 'unstable'), (650, 'testing'), (600, 'stable'), (500, 
> 'stable-updates'), (500, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Not that it's related, but yeah, right, install everything from
experimental. Well, unstable has higher prio still but
you got java-common/default-jre etc and libc6 from there...

Regards,

Rene

Bug#882390: libnet-twitter-perl: tweets are truncated to 140 characters

[gregor herrmann]

Control: tag -1 + unreproducible

On Fri, 24 Nov 2017 13:04:49 +0100, Florian Schlichting wrote:

> > Some time ago, Twitter has extended tweets to more than 140 characters.
> > But with Net::Twitter, tweets are truncated to 140 characters, and
> > even less (because they include a link to get the full tweet when this
> > occurs). This makes this module rather useless nowadays.
> > 
> > This module should be updated to the current Twitter API.
> 
> in https://github.com/semifor/Net-Twitter/issues/76 the upstream author
> makes clear that he considers Net::Twitter a dead end and has deprecated
> it in favour of Twitter::API. In fact, the git repo has added the
> following notice:
> 
> This module has been superseded by L. Please update as
> soon as you possibly can to use new features and the new API
> versions. This module will no longer be supported.

True but we might still fix the 140 character issue.

Except that I see no mention of "140" in the code (only in the POD)?!
The update method seems to just POST to statuses/update, and that's
it.

So let's try ...

*a bit later*

With the result of the attached script I got (no error, exit status
0, and): https://twitter.com/gregoa_/status/934184021684301824
(length 188 characters)


So I can't reproduce a 140 character limit in Net::Twitter.


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 VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Led Zeppelin: Dazed And Confused
#/usr/bin/perl

use strict;
use warnings;
use Net::Twitter;
use Scalar::Util 'blessed';

my $nt = Net::Twitter->new(
traits  => [qw/API::RESTv1_1/],
consumer_key=> ...,
consumer_secret => ...,
access_token=> ...,
access_token_secret => ...,
);

my $tweet
= 'Test for https://bugs.debian.org/882390 - what does Net::Twitter do with long messages? '
. '0123456789' x 10;

my $result = $nt->update($tweet);

if ( my $err = $@ ) {
die $@ unless blessed $err && $err->isa('Net::Twitter::Error');

warn "HTTP Response Code: ", $err->code, "\n",
 "HTTP Message..: ", $err->message, "\n",
 "Twitter error.: ", $err->error,   "\n";
}


signature.asc
Description: Digital Signature

Bug#882621: stretch-pu: package python2.7/2.7.13-2+deb9u2

[Moritz Muehlenhoff]

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

Hi,
I'd like to add a fix for a minor security issue in Python 2.7 to the
as a followup update to what's already in spu. debdiff is below.

This is fixed in unstable in 2.7.13-4.

Cheers,
Moritz

diff -u python2.7-2.7.13/debian/changelog python2.7-2.7.13/debian/changelog
--- python2.7-2.7.13/debian/changelog
+++ python2.7-2.7.13/debian/changelog
@@ -1,3 +1,10 @@
+python2.7 (2.7.13-2+deb9u2) stretch; urgency=medium
+
+  * Backport c3c9db89273fabc62ea1b48389d9a3000c1c03ae to address
+CVE-2017-1000158 / https://bugs.python.org/issue30657
+
+ -- Moritz Mühlenhoff   Fri, 24 Nov 2017 18:33:09 +0100
+
 python2.7 (2.7.13-2+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload with maintainer's permission
diff -u python2.7-2.7.13/debian/patches/series.in 
python2.7-2.7.13/debian/patches/series.in
--- python2.7-2.7.13/debian/patches/series.in
+++ python2.7-2.7.13/debian/patches/series.in
@@ -72,0 +73 @@
+CVE-2017-1000158.diff
only in patch2:
unchanged:
--- python2.7-2.7.13.orig/debian/patches/CVE-2017-1000158.diff
+++ python2.7-2.7.13/debian/patches/CVE-2017-1000158.diff
@@ -0,0 +1,29 @@
+From c3c9db89273fabc62ea1b48389d9a3000c1c03ae Mon Sep 17 00:00:00 2001
+From: Jay Bosamiya 
+Date: Sun, 18 Jun 2017 22:11:03 +0530
+Subject: [PATCH] [2.7] bpo-30657: Check & prevent integer overflow in
+ PyString_DecodeEscape (#2174)
+
+---
+ Objects/stringobject.c | 8 +++-
+ 3 files changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/Objects/stringobject.c b/Objects/stringobject.c
+index c78e19316a0..59d22e76946 100644
+--- a/Objects/stringobject.c
 b/Objects/stringobject.c
+@@ -612,7 +612,13 @@ PyObject *PyString_DecodeEscape(const char *s,
+ char *p, *buf;
+ const char *end;
+ PyObject *v;
+-Py_ssize_t newlen = recode_encoding ? 4*len:len;
++Py_ssize_t newlen;
++/* Check for integer overflow */
++if (recode_encoding && (len > PY_SSIZE_T_MAX / 4)) {
++PyErr_SetString(PyExc_OverflowError, "string is too large");
++return NULL;
++}
++newlen = recode_encoding ? 4*len:len;
+ v = PyString_FromStringAndSize((char *)NULL, newlen);
+ if (v == NULL)
+ return NULL;

Bug#869539: can be closed

[Phil Hagelberg]

Talking with the devs further, this is an intentional change in
libsdl2. It notices that caps lock has been mapped to ctrl, so when you
ask it whether ctrl is being pressed, it only checks caps lock and
ignores the physical ctrl even though they are both mapped to ctrl.

This can be closed as it is not relevant to the love package.

-Phil

Bug#874153: FTBFS with Java 9: jre/bin/java

[Emmanuel Bourg]

Le 24/11/2017 à 20:10, Dirk Eddelbuettel a écrit :

> I may do another RC build before R 3.4.3 is out later next week.  Not
> entirely sure how to test it because actual Depends: result from this.  So if
> I start with java 9 it may be be java 9 and nothing else.

Ideally the package should depend on default-jre only, and not on
openjdk-{8,9}-jre. This will avoid updating the R packages for new Java
releases (they will now come every 6 months now, Java 10 is targeted for
March 2018).

If you want to test with OpenJDK 9 as the default JRE you can install
the default-jre package from experimental.

Bug#882620: [CVE-2017-16879] ncurses: Stack-based buffer overflow

[Luciano Bello]

Package: ncurses
X-Debbugs-CC: t...@security.debian.org
secure-testing-t...@lists.alioth.debian.org
Severity: grave
Tags: security

Hi,

the following vulnerability was published for ncurses.

CVE-2017-16879[0]:
| Stack-based buffer overflow in the _nc_write_entry function in
| tinfo/write_entry.c in ncurses 6.0 allows attackers to cause a denial
| of service (application crash) or possibly execute arbitrary code via
| a crafted terminfo file, as demonstrated by tic.

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


I checked the PoC from [1] and looks like working in every supported
Debian distro at the moment.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-16879
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16879
[1] https://packetstormsecurity.com/files/download/145045/tic-overflow.tgz

Please adjust the affected versions in the BTS as needed.

Bug#882619: ITP: node-object.pick -- Returns a filtered copy of an object

[Julien Puydt]

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

* Package name: node-object.pick
  Version : 1.3.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/object.pick
* License : Expat
  Programming Lang: JavaScript
  Description : Returns a filtered copy of an object
 Returns the filtered copy of an object with only the specified keys.
 It is similar to the `_.pick` function in lodash and underscore.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a dep of nanomatch, which is a new dep of micromatch, already
packaged.

Snark on #debian-js

Bug#861597: libpodofo: CVE-2017-8378 was already fixed upstream

[Matthias Brinke]

Hello,

this bug was already fixed upstream before being reported here.
I'm sorry to not have noted that here earlier.
The fix is in svn r1833 [1] of the upstream PoDoFo repository
trunk, committed on 2017-03-24 as "Fix a crash when passing a PDF
file with an encryption dictionary reference to a nonexistent object".

[1] https://sourceforge.net/p/podofo/code/1833/

Best regards, Matthias

Bug#882618: libdbix-class-schema-loader-perl: Test failures

[gregor herrmann]

Package: libdbix-class-schema-loader-perl
Version: 0.07047-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=123681

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first seen on ci.debian.net [0], libdbix-class-schema-loader-perl's
test suite fails since recent changes in prerequsites. The same
happens during build which leads to a FTBFS bug:

DBIx::Class::ResultSource::schema(): Unable to perform storage-dependent 
operations with a detached result source (source 'Bar' is not associated with a 
schema). You need to use $schema->thaw() or manually set 
$DBIx::Class::ResultSourceHandle::thaw_schema while thawing. at 
t/20invocations.t line 18
# Looks like your test exited with 255 just after 7.
t/20invocations.t ... 
1..68
ok 1 - 'hardcode' isa 'DBIx::Class::Schema'
ok 2 - 'hardcode' isa 'DBIx::Class::ResultSet'
ok 3 - 'hardcode' isa 'DBICTest::Schema::_hardcode::Foo'
ok 4 - hardcode correct object
ok 5 - hardcode object created
ok 6 - No warnings during hardcode invocations
ok 7 - 'normal' isa 'DBIx::Class::Schema'
rmdir t/var/DDzUVkb6WU
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 61/68 subtests 

DBIx::Class::ResultSource::schema(): Unable to perform storage-dependent 
operations with a detached result source (source 'Bar' is not associated with a 
schema). You need to use $schema->thaw() or manually set 
$DBIx::Class::ResultSourceHandle::thaw_schema while thawing. at 
t/backcompat/0.04006/20invocations.t line 21
# Looks like your test exited with 255 just after 5.
t/backcompat/0.04006/20invocations.t  
1..32
ok 1 - 'hardcode' isa 'DBIx::Class::Schema'
ok 2 - 'hardcode' isa 'DBIx::Class::ResultSet'
ok 3 - hardcode
ok 4
ok 5 - 'normal' isa 'DBIx::Class::Schema'
rmdir t/var/BdN94D7OJ3
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 27/32 subtests 


While this is probably a bug in libhash-merge-perl (or one of its
dependencies), we have a problem here, and should update the
dependencies once it's fixed.


Cheers,
gregor


[0]
https://ci.debian.net/packages/libd/libdbix-class-schema-loader-perl/unstable/amd64/


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAloYlZxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYwzhAAxUrKJzSLaKMPQmrPVnau1NDrJBMRq4VcVcBBfFlwKul4f3hvSDIopGKO
JrQrqvq2Z53mwHAfMh1kCoCYUoQ3CDiQvsv5sPI1noKIRCBkebLne7kkxWIAMb5U
0TO4n/6nNMEF0lY4Ir2pUEaCC50/UuFRw8T+btb01gUcNP2TguTdvalM3YF+qSC/
YDHlYTnoIvB1gR/qpRvwxuIED0/mq3RiOsFdEJTAERJknlbpWkD4JZApXiAtOgeD
E0QQBJ3/+7Yk6qkgru/O+Gxb7gTpFW3Gur0C2uJ4UxMYt6xvZFysQHOU8GJzM+oC
RxgsMf96iLoF7IkMzChNmYVvbBgrjEuNOtEpYqPYvQk9ZcBVN6LY8JGXYhFCJcWk
rF1hZgjO7XOPNE0UrznPFqe36r5BKpfFIP7HqH2UdIBhTGBq8Xt33993SkQZ+1Pj
KEw3etFtPrI/H93LMRDnB09UlspJ+zRibzODRzK2Rt9RNeRdZ2EHQkliVL8kt9g/
YBdWW/kMMURB9+R/cLuQjMqmVm4JRyfM4tD14GmHl18+ZQI0ck2pB6xVGAW8dyZV
XV23yCuMqg0SChhrKk6jDtjSolcNWtWW1Ok8dfsS3GhQ9YxFtTvTk0HnAXGhikDq
JvMjtYt2CPcs24A1MWzyp2HH+gbXXiPUEZF6gfRmXn1AvhTCGSM=
=q5E3
-END PGP SIGNATURE-

Bug#882617: ITP: node-is-odd -- Helper function to test whether a given number is odd

[Julien Puydt]

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

* Package name: node-is-odd
  Version : 2.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/is-odd
* License : Expat
  Programming Lang: JavaScript
  Description : Helper function to test whether a given number is odd
 This little helper function provides a way to test whether a number
 is odd -- but it does check things a little more thoroughly, as it
 will also handle integers-as-string and report an error if the argument
 is not a valid number.
 .
 Node.js is an event-based server-side JavaScript engine.

I is a dep of node-nanomatch, which is a new dep of node-micromatch,
which is already in Debian.

Thanks,

Snark on #debian-js

Bug#882607: libdbus-1-3: steam crashes at start with latest libdbus update

[Simon McVittie]

Control: reassign -1 steam
Control: forwarded -1 
https://github.com/ValveSoftware/steam-for-linux/issues/5201

On Fri, 24 Nov 2017 at 18:45:10 +0100, Axel R. wrote:
> Updating libdbus-1-3:i386 (1.12.0-1, 1.12.2-1) led to steam client crashes 
> with:
> dbus[4877]: arguments to dbus_message_new_method_call() were incorrect, 
> assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 
> 1362.
> This is normally a bug in some application using the D-Bus library.
> D-Bus not built with -rdynamic so unable to print a backtrace

This is a bug in Steam, which I think is specifically in the bundled
copy of SDL 2.0.6 that it uses. It will crash in this way on everything
that isn't a Debian derivative.

On Debian derivatives, until recently a Debian-specific patch downgraded
the response to failing the precondition check to a warning (this was
done "temporarily" 11 years ago). "export DBUS_FATAL_WARNINGS=0" before
running Steam would do the same thing as that patch. This will avoid the
crash and just spam warnings instead, unless you are unlucky with the
contents of uninitialized memory, in which case it might still crash.

Workarounds:

* don't have or use ibus ("unset XMODIFIERS" before launching Steam
  is said to work)
* or, export DBUS_FATAL_WARNINGS=0

I think this would be better worked around in /usr/games/steam than in
libdbus, unless the same failure mode is very widespread (but hopefully
it isn't, because if it was, the same code would crash on non-Debian).

Steam will hopefully pick up SDL 2.0.7 soon, which is believed to fix
the crash.

Regards,
smcv

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Vincent Bernat]

 ❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni 
 :

>> Any MBF should be discussed first on debian-devel@ first. For me,
>> this seems a small violation and it would be preferable to stick with
>> severity normal to not appear too agressive.
>
> Only 8 source packages are concerned (re: not shipping the CC0 text),
> so I didn't realise that constituted a MBF.
>
> Thanks for the advise on the severity, I was under the impression that all
> policy violations should be `serious` or greater.  How should I
> proceed?

For 8 packages, you can file the bug directly. As for severity, people
may not agree with the interpretation of the policy: CC0 is equivalent
to public domain and the license text is very verbose. It would be
easier to push the change without a "threatening" severity.

>> > Thanks a bunch for the review,
>> 
>> Looks good. Tell me what you want to do about the remaining lintian
>> warning.
>
> If that's fine by you, I would rather have it uploaded as-is.

So, it's uploaded.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

Bug#882610: [Pkg-haproxy-maintainers] Bug#882610: Please drop haproxy.service-start-after-syslog.patch

[Apollon Oikonomopoulos]

Control: severity -1 wishlist
Control: tags -1 wontfix

Hi Laurent,

On 19:22 Fri 24 Nov , Laurent Bigonville wrote:
> Source: haproxy
> Version: 1.7.9-1
> Severity: normal
> 
> Hi,
> 
> I see in the haproxy.service file that you have a After=/Wants=syslog.service
> 
> The installed syslog implementation installed on the machine is always
> socket activated so adding After=/Wants=syslog.service is not needed
> (and can make the dependency chain more complex).
> 
> IMHO, the haproxy.service-start-after-syslog.patch patch should be
> dropped.
> 
> Do you have any specific reasons to keep this patch?

Unfortunately it's not that straightforward. HAProxy is running in a 
chroot under /var/lib/haproxy by default. To facilitate logging to 
syslog, we ship an rsyslog snippet that adds an additional syslog socket 
inside HAProxy's chroot. This socket does not take part in the socket 
activation mechanism, so we need an explicit dependency.

Now, we could probably discuss whether it makes sense to drop the chroot 
altogether in favor of something like ProtectSystem=full. But until 
then, I'm afraid the patch has to stay.

Regards,
Apollon

Bug#881097: Pending fixes for bugs in the libnet-ping-external-perl package

[pkg-perl-maintainers]

tag 881097 + pending
thanks

Some bugs in the libnet-ping-external-perl package are closed in
revision 701578a27f699b5b3b1540ee0e4a4f65333869b9 in branch 'master'
by tony mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libnet-ping-external-perl.git/commit/?id=701578a

Commit message:

Add patch for CVE-2008-7319 (Closes: #881097)

Bug#882616: lprng + ifhp + sssd (with fast memory cache) + sss_cache flush = no more printing

[Tomas Forsman]

Package: lprng
Version: 3.8.B-2.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgraded printer server to Stretch. After an hour, all printing failed.
Restarted lprng, it worked for a while, then all printing failed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Printed, then invalidated cache, then printed again.

   * What was the outcome of this action?

No paper.

   * What outcome did you expect instead?

Paper.


Necessary components to trigger this bug:
1) lprng
2) possibly ifhp, not entirely sure
3) sssd >=1.13, with fast memory cache support for initgroups (that
   lprng uses)
4) nss using sss
5) cache flushed (sss_cache -xxx) or sssd restarted



This was a tricky one.

TL;DR, sssd's newly implemented fast memory cache for initgroups
combined with "simulated close_on_exec" in lpd and an sssd restart /
cache invalidation causes lpd and sssd to stomp all over each others
file descriptors, closing them for each other (in the bad way), causing
printing to fail.

More verbose (some details/orders are possibly wrong, but the general
sense is what seems to happen after comparing source + strace's):

sssd has something called fast memory cache, lightly described at
https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/
(the orange box, #2) meaning sssd opens files within the client process
without client knowing about it.


In lprng/src/common/lpd_worker.c, in Make_lpd_call, we have:
/* close other ones to simulate close_on_exec() */
n = Max_fd+10;
for( i = passfd_count ; i < n; ++i ){
close(i);
}

In sssd/src/sss_client/nss_mc_common.c, in sss_nss_mc_destroy_ctx, we have:
if (ctx->fd != -1) {
close(ctx->fd);
}

What normally happens, roughly:
lpd starts and does some nss work, nss_sss opens an extra file to
/var/lib/sss/mc/initgroups inside lpd (without lpd knowing), then it's
time for lpd to fork and closes that initgroups file (without nss_sss
noticing) due to simulated close_on_exec. Then starts calling ifhp,
making network connections etc. Sockets are created, file descriptors
are dup2()'d to the left and right and then data is transmitted to the
printer. All is well.

If I then call sss_cache -E/-somethingelse or restart sssd, invalidating
the fast memory cache - meaning /var/lib/sss/mc/initgroups is deleted
and try again..

Then after the fork and after connections to the printer are made, nss
notices that the cache is invalid and munmap()'s it and closes the
filedescriptor it used to have. Unfortunately, that fd now belongs to
the printer network socket due to number reuse. New unix sockets are
created with nss calls, getting into that fd instead. lpd wants to send
data to the printer, but instead it goes to /var/lib/sss/pipes/nss -
which does not like PJL as much as printers do. That socket does not
respond PJL:y and the network socket is closed and dismissed with an
error.


Solution:
Make lpd actually use close on exec and/or only close the file
descriptors it has actually created itself. This is probably some work
and this bug probably affects very few, but I did want to get it
documented.


Workaround:

# cat /etc/systemd/system/lprng.service.d/sssd_memcache.conf
[Service]
Environment=SSS_NSS_USE_MEMCACHE=NO



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

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

Versions of packages lprng depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  libcomerr2 1.43.4-2
ii  libk5crypto3   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  libssl1.1  1.1.0f-3+deb9u1
ii  lsb-base   9.20161125

lprng recommends no packages.

Versions of packages lprng suggests:
pn  lprng-doc
pn  magicfilter  

-- Configuration Files:
/etc/lprng/lpd.conf changed:
default_printer=NOPRINTER
default_remote_host=printserver.cs.umu.se
lf=/var/log/lprng.log
lpd_printcap_path= /var/conf/lprng/lpd_printcap
mail_from=Print master
max_accounting_file_size=0
max_log_file_size=0
max_servers_active=128
mc=200
minfree=5
mx=100
printcap_path= /var/conf/lprng/printcap
sendmail=/usr/lib/sendmail -oi -t
user_lpc=hold,release,move,abort,kill


-- debconf information excluded

Bug#882615: cl-plus-ssl: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Source: cl-plus-ssl
Version: 20170630-1
Severity: serious
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
Control: block 871056 by -1

Please migrate to libssl-dev in the Buster cycle. I am very sorry for
this late report but this package was never on my list. It slipped
because it never B-D on libssl1.0-dev and it builds perfectly fine
against libssl1.1.
I have actually no idea why the package in archive links against
libssl1.0.2 because it B-D on libssl-dev and if I rebuild then it
depends on libssl1.1 instead.

If you move torvards libssl1.1 you should make sure it loads libssl1.1
and not "just" libssl1.0.2.

Function wise:
SSL_library_init() and a few other macros towards "OPENSSL_init_ssl(0, NULL)"
  so "normal" C will work but if nim is accessing the functions directly
  then it will fail.

SSLv23_client_method() and friends are also macros. 1.1 Code should use
  TLS_client_method() instead. Functions like TLSv1_method() should be
  avoided because they give you _only_ TLSv1 and _never_ TLSv1.1, and/or
  TLSv1.2 like SSLv23_client_method(). 
  If you want to exclude a certain TLS version you should use something
  like SSL_OP_NO_TLSv1 to disable TLSv1 only (and keep other version
  like v1.1 and v1.2 around).

Data strucures. All structures are opaque and you need to tell libssl to
allocate it and free it (especially in crypto code). I can't tell if you 
dereference them, I can't read lisp.

A larger collection of what changed in OpenSSL 1.0.2->1.1 is at
   https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

Sebastian

Bug#882598: libavutil55: segfault after upgrade

[James Cowgill]

Hi,

On 24/11/17 15:40, James Cowgill wrote:
> Control: severity -1 grave
> Control: retitle -1 libavutil55: ABI broken by "add vector_dmac_scalar()"
> Control: forwarded -1 https://trac.ffmpeg.org/ticket/6861
> Control: tag -1 - moreinfo
> Control: found -1 7:3.4-1
> 
> On 24/11/17 14:46, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I created FFmpeg ticket #6861, thank you for the report!
>> https://trac.ffmpeg.org/ticket/6861
> 
> That is not a nice bug.
> 
> I'll have to think about the best way to handle this. I guess we will
> have to revert the ABI breaking commit, identify the packages which are
> broken (including ffmpeg itself like in this bug), add some Breaks for
> them, and finally binNMU them. Alternatively we could force an ABI
> transition and rebuild everything, but I'm not sure if I want to do
> that (especially since we'll have to do another in a few months anyway).

On closer inspection (and reading the upstream bug), the ABI break
occurs in the private float_dsp.h header and the only consumers are
libavcodec and libavfilter. This makes things much easier than I
originally thought since the breakage is internal to ffmpeg.

I think this can be fixed by keeping the new ABI and use package
dependencies to enforce that it's used only with 3.4.

We need to ensure 3.4 libavcodec/libavfilter uses 3.4 libavutil, but
this is already guaranteed through the existing symbols system. We then
need to prevent 3.4 libavutil from being used with pre-3.4
libavcodec/libavfilter by adding this to libavutil55:

Breaks:
 libavcodec57 (<< 7:3.4),
 libavcodec-extra57 (<< 7:3.4),
 libavfilter6 (<< 7:3.4),
 libavfilter-extra6 (<< 7:3.4)

I think that will fix the bug. Can anyone see anything I've missed?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

On Fri, Nov 24, 2017 at 08:21:39PM +0100, Vincent Bernat wrote:
>  ❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni 
>  :
> 
> > - include the whole CC0 license in debian/copyright
> >   (this is already uploaded to mentors.d.n);
> > - open a bug against base-files to ship the CC0 in 
> > /usr/share/common-licences
> > - open bugs against concerned packages, to refer to the licence's text
> >   as installed by base-files;  (what should the severity be? I guess 
> > serious,
> >   since it is a violation of Debian policy 12.5 [1])
> >
> > [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0
> > [1]: https://www.debian.org/doc/debian-policy/#copyright-information
> 
> Any MBF should be discussed first on debian-devel@ first. For me,
> this seems a small violation and it would be preferable to stick with
> severity normal to not appear too agressive.

Only 8 source packages are concerned (re: not shipping the CC0 text),
so I didn't realise that constituted a MBF.

Thanks for the advise on the severity, I was under the impression that all
policy violations should be `serious` or greater.  How should I proceed?


> >> You override the debian-watch-may-check-gpg-signature, but you also need
> >> to override orig-tarball-missing-upstream-signature. Since the tooling
> >> to check signatures the way you need it is not here, an alternative
> >> would be to not ship upstream GPG signature.
> >
> > That's something lintian picks up in the changes file, and there is 
> > currently
> > no way to override those, if I'm not mistaken:
> >
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400
> 
> Oh, yes, I remember now. On my own packages, I have removed the GPG
> signature because of this. I don't know what's the stance of the FTP
> masters on this particular problem, so I don't know if it's best to get
> rid of the warning or just leave it as is. In your case, I would just
> remove the key since it is not used.

I would rather keep it there, to make it obvious which signing (sub)key
I am trusting for upstream.  :)


> > Thanks a bunch for the review,
> 
> Looks good. Tell me what you want to do about the remaining lintian
> warning.

If that's fine by you, I would rather have it uploaded as-is.


Thanks,

  nicoo


signature.asc
Description: PGP signature

Bug#784479: Patch available

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

There is patch available for this at 

We might want to wait for the last tandem of KF5 apps though.

-- 
A group of politicians deciding to dump a President because his morals
are bad is like the Mafia getting together to bump off the Godfather for
not going to church on Sunday.
  Russell Baker

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


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

Bug#882614: nmu: kodi-pvr-mediaportal-tvserver_2.4.14+dfsg1-1

[Sebastian Ramacher]

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

liblivemedia bumped the SONAME. So please binNMU kodi-pvr-mediaportal-tvserver.

nmu kodi-pvr-mediaportal-tvserver_2.4.14+dfsg1-1 . ANY . unstable . -m "Rebuild 
against liblivemedia61"

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#882600: Notice for donna Dc

[James McGlothlin]

Donna is dicieced please do not send anymore stuff

On Nov 24, 2017 11:57 AM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for donna uK

[James McGlothlin]

She is dead send nothing more please

On Nov 24, 2017 11:57 AM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#569136: Chinese pages not updated properly (security/index, security/YYYY/index, homepage)

[Laura Arjona Reina]

Hello

I have manually rebuilt the Chinese homepage (deleted the
index.zh-*.html files in www-master.debian.org, and run
update-parts-pabs to generate index with no subdirectories).

Attached you can find a patch for the /english/Makefile, which considers
Chinese variants when building index.wml, so this issue does not happen
again (hopefully).

I've tested in my local environment and it builds ok. I've tried
touching a file in english/security/2017 and the old Makefile does not
build the Chinese variants for the homepage, but the one containing this
patch builds them.

I plan to apply it in a week or so. If somebody else reviews it and
think it's safe to apply it sooner, please go ahead.

Note: the patch may be changed depending on the advice obtained about
using "=" or ":=" (see
https://lists.debian.org/debian-www/2017/11/msg00075.html for reference).

Best regards

-- 

Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Index: Makefile
===
RCS file: /cvs/webwml/webwml/english/Makefile,v
retrieving revision 1.102
diff -u -r1.102 Makefile
--- Makefile	23 Jul 2017 08:31:47 -	1.102
+++ Makefile	24 Nov 2017 16:45:03 -
@@ -14,11 +14,13 @@
 include $(WMLBASE)/Make.lang
 
 ifndef SUBLANG
+INDEXPAGE = index.$(LANGUAGE).html
 SITEMAP = sitemap.$(LANGUAGE).html
 DESTSITEMAP = $(HTMLDIR)/$(SITEMAP)
 SEARCHXML = search.$(LANGUAGE).xml
 DESTSEARCHXML =  $(HTMLDIR)/$(SEARCHXML)
 else
+INDEXPAGE = $(sort $(foreach i,$(SUBLANG),$(subst index,index.$(LANGUAGE)-$(i),index.html)))
 SITEMAP = $(sort $(foreach i,$(SUBLANG),\
 	$(patsubst %.wml,%.$(LANGUAGE)-$(i).html,sitemap.wml)))
 DESTSITEMAP = $(patsubst %.html,$(HTMLDIR)/%.html,$(SITEMAP))
@@ -26,13 +28,20 @@
 DESTSEARCHXML = $(patsubst %.xml,$(HTMLDIR)/%.xml,$(SEARCHXML))
 endif
 
-index.$(LANGUAGE).html: index.wml $(TEMPLDIR)/mainpage.wml $(GETTEXTDEP) \
+$(INDEXPAGE): index.wml $(TEMPLDIR)/mainpage.wml $(GETTEXTDEP) \
 		$(wildcard News/$(CUR_YEAR)/[0-9]*.wml) $(wildcard $(ENGLISHSRCDIR)/News/$(CUR_YEAR)/[0-9]*.wml) \
  		$(wildcard News/$(CUR_YEAR)/[0-9]*.title) \
 		$(wildcard security/$(CUR_YEAR)/dsa-[0-9]*.wml) $(wildcard $(ENGLISHSRCDIR)/security/$(CUR_YEAR)/dsa-[0-9]*.wml) \
 		$(TEMPLDIR)/ctime.wml $(TEMPLDIR)/recent_list.wml $(TEMPLDIR)/languages.wml \
 		$(TEMPLDIR)/release_info.wml $(TEMPLDIR)/release_images.wml
+ifeq "$(LANGUAGE)" "zh"
+	@echo -n "Processing $(

Bug#882613: libxml2: CVE-2017-16932: Infinite recursion in parameter entities

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.4+dfsg1-5.1
Severity: important
Tags: patch security upstream
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=759579

Hi,

the following vulnerability was published for libxml2.

CVE-2017-16932[0]:
| parser.c in libxml2 before 2.9.5 does not prevent infinite recursion in
| parameter entities.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-16932
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16932
[1] https://bugzilla.gnome.org/show_bug.cgi?id=759579 (not yet public)
[2] 
https://git.gnome.org/browse/libxml2/commit/?id=899a5d9f0ed13b8e32449a08a361e0de127dd961

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#881943: pending

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 pending


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

Bug#879844: Info received (clinicaltrial u have been selected to register!ebh1)

[Nellie Smith]

DO NOT SEND ANY OF YOU'RE EMAILS I DIDN'T SUBSCRIBE.SCAM SCAM SCAM

On Nov 24, 2017 1:21 PM, "Debian Bug Tracking System" 
wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
>  Ilias Tsitsimpis 
>
> If you wish to submit further information on this problem, please
> send it to 879...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 879844: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879844
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Vincent Bernat]

 ❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni 
 :

>> In d/copyright: you need to include the complete CC0 license.
>
> OK; I did so based on what other packages were doing, according to
> codesearch.d.n [0].  If that's an acceptable solution, I will
> - include the whole CC0 license in debian/copyright
>   (this is already uploaded to mentors.d.n);
> - open a bug against base-files to ship the CC0 in /usr/share/common-licences
> - open bugs against concerned packages, to refer to the licence's text
>   as installed by base-files;  (what should the severity be? I guess serious,
>   since it is a violation of Debian policy 12.5 [1])
>
> [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0
> [1]: https://www.debian.org/doc/debian-policy/#copyright-information

Any MBF should be discussed first on debian-devel@ first. For me,
this seems a small violation and it would be preferable to stick with
severity normal to not appear too agressive.

>> You override the debian-watch-may-check-gpg-signature, but you also need
>> to override orig-tarball-missing-upstream-signature. Since the tooling
>> to check signatures the way you need it is not here, an alternative
>> would be to not ship upstream GPG signature.
>
> That's something lintian picks up in the changes file, and there is currently
> no way to override those, if I'm not mistaken:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400

Oh, yes, I remember now. On my own packages, I have removed the GPG
signature because of this. I don't know what's the stance of the FTP
masters on this particular problem, so I don't know if it's best to get
rid of the warning or just leave it as is. In your case, I would just
remove the key since it is not used.

> Thanks a bunch for the review,

Looks good. Tell me what you want to do about the remaining lintian
warning.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

Bug#879844: clinicaltrial u have been selected to register!ebh1

[Nellie Smith]

On Nov 24, 2017 1:19 PM, "ClinicalTrials"  wrote:

> Imagine a day without Pain. Get Matched to a Legal Research Trial of CBD
> for your Pain
> Qualify for a 100% Legal Research Trial of CBD for your Pain
> Qualify for Natural Pain Relief! See How
> CBD is Changing Lives – See How
> 
>
> If you wish to unsubscribe from future mailings please clickhere
> 
> or writeto:10801StarkeyRdSte104-368 seminole,FL33777
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Your message dated Fri, 24 Nov 2017 19:50:03 +0200 with message-id
> <20171124175003.GA12197@localhost> and subject line haskell-pid1 is now
> in unstable has caused the Debian Bug report #879844, regarding ITP:
> haskell-pid1 -- Signal handling and orphan reaping for Unix PID1 init
> processes to be marked as done. This means that you claim that the problem
> has been dealt with. If this is not the case it is now your responsibility
> to reopen the Bug report if necessary, and/or fix the problem forthwith.
> (NB: If you are a system administrator and have no idea what this message
> is talking about, this may indicate a serious mail system misconfiguration
> somewhere. Please contact ow...@bugs.debian.org immediately.) -- 879844:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879844 Debian Bug
> Tracking System Contact ow...@bugs.debian.org with problems
>
> -- Forwarded message --
> From: Ilias Tsitsimpis 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Thu, 26 Oct 2017 15:43:30 +0300
> Subject: ITP: haskell-pid1 -- Signal handling and orphan reaping for Unix
> PID1 init processes
> Package: wnpp
> Severity: wishlist
> Owner: Ilias Tsitsimpis 
>
> * Package name: haskell-pid1
>   Version : 0.1.2.0
>   Upstream Author : Michael Snoyman 
> * URL : https://hackage.haskell.org/package/pid1
> * License : Expat
>   Programming Lang: Haskell
>   Description : Signal handling and orphan reaping for Unix PID1 init
> processes
>
> Do signal handling and orphan reaping for Unix PID1 init processes.
> .
> This provides a Haskell library, and an executable based on that
> library, for initializing signal handlers, spawning and child process,
> and reaping orphan processes. These are the responsibilities that must
> be fulfilled by the initial process in a Unix system, and in particular
> comes up when running Docker containers.
> .
> This library/executable will automatically detect if it is run as some
> process besides PID1 and, if so, use a straightforward exec system call
> instead.
>
> This package is required for latest upstream version of haskell-stack.
>
> This package will be maintained under the umbrella of the Debian Haskell
> Group.
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: 879844-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 24 Nov 2017 19:50:03 +0200
> Subject: haskell-pid1 is now in unstable
> haskell-pid1 is now in unstable:
> https://tracker.debian.org/pkg/haskell-pid1
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>

Bug#882573: mutt: displays text/html raw again instead of using mailcap

[Antonio Radici]

Tags: + pending

Hi Bob,
thanks for your report, I've fixed this in git, it will be included in 1.9.1-5

Bug#882612: ITP: python-django-channels -- Developer-friendly asynchrony for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-channels
  Version : 1.1.8
  Upstream Author : Django Software Foundation 
* URL : https://github.com/django/channels/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Developer-friendly asynchrony for Django

Channels is a project to make Django able to handle more than just plain HTTP
requests, including WebSockets and HTTP2, as well as the ability to run code
after a response has been sent for things like thumbnailing or background
calculation.
.
It’s an easy-to-understand extension of the Django view model, and easy to
integrate and deploy.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloYb68RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrUfAgAvm3ncost8O4M6p8FIsj8pU6weYZXjvLx
bNevDHHpaMyq+XSi3FIJSQUiqb3ruoFvAKiHI3QytTVsn98BUGcN9BZIj5SSNuja
NDuuhjNvVRPmf3FHXDsgROoZLG/OiQfQAnb3v/6J52JOfjt8dFS/2nGcftl92n7U
oLnRnVyn3lVd5WZaajRkYIUcKh2XMNuPHCq+1pDqhtaSl49BLEMtr7QiJ7L6ELW7
w0XoSHq7Gj70XtGIrfb5I4PfD0/wI4+ffViSwtLPA7UWB229xvTX2CvVoeEjHoaG
xq6o0fKFGOf9Us9MpwymAxPbP8HvbO5j9TR9T0F5cpibtf8ApycINg==
=TS5k
-END PGP SIGNATURE-

Bug#874153: FTBFS with Java 9: jre/bin/java

[Dirk Eddelbuettel]

Simon,

On 24 November 2017 at 13:56, Simon Urbanek wrote:
| Emmanuel,
| 
| 
| > On Nov 24, 2017, at 11:02 AM, Emmanuel Bourg  
wrote:
| > 
| > Le 24/11/2017 à 16:30, Simon Urbanek a écrit :
| >> Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. 
It was somewhat odd idiosyncrasy of the Debian configuration - I have not seen 
it on any other system.
| > 
| > Actually there is nothing Debian specific here, the jre/bin/ and bin/
| > directories have been there for ~20 years in all Java distributions. It
| > just changed two months ago with the release of Java 9.
| > 
| > If you are referring to the fact that Debian installs both the JRE and
| > the JDK in the same directory (/usr/lib/jvm/default-java) that's also
| > true for Fedora and Arch Linux.
| > 
| 
| Ah, sorry for the confusion, I was referring to JAVA being set to jre/bin 
while JAVAC was set to bin since most commonly bin did include tools in 
jre/bin. 
| 
| I think in your case you may possibly want to use
| JAVA=/usr/lib/jvm/default-java/bin/java JAVA_HOME=/usr/lib/jvm/default-java
| when configuring R to make sure it uses default-java that works both for Java 
1.8 and 1.9 (please double-check, though).

So we should do this when configuring R itself, correct?

I may do another RC build before R 3.4.3 is out later next week.  Not
entirely sure how to test it because actual Depends: result from this.  So if
I start with java 9 it may be be java 9 and nothing else.

Dirk

| 
| R doesn't actually care as long as the paths for JAVA and JAVAC actually 
exist and I see now that the issue was that jvm/default-java is pointing 
directly inside the Java installation, so if they change how Java ship things 
it breaks. 
| 
| One way around it is to point both JAVA and JAVAC to the symlinks managed by 
the distribution so it's not susceptible so changes in the Java distribution.
| 
| Cheers,
| Simon
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

[Simon Urbanek]

Emmanuel,


> On Nov 24, 2017, at 11:02 AM, Emmanuel Bourg  wrote:
> 
> Le 24/11/2017 à 16:30, Simon Urbanek a écrit :
>> Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. It 
>> was somewhat odd idiosyncrasy of the Debian configuration - I have not seen 
>> it on any other system.
> 
> Actually there is nothing Debian specific here, the jre/bin/ and bin/
> directories have been there for ~20 years in all Java distributions. It
> just changed two months ago with the release of Java 9.
> 
> If you are referring to the fact that Debian installs both the JRE and
> the JDK in the same directory (/usr/lib/jvm/default-java) that's also
> true for Fedora and Arch Linux.
> 

Ah, sorry for the confusion, I was referring to JAVA being set to jre/bin while 
JAVAC was set to bin since most commonly bin did include tools in jre/bin. 

I think in your case you may possibly want to use
JAVA=/usr/lib/jvm/default-java/bin/java JAVA_HOME=/usr/lib/jvm/default-java
when configuring R to make sure it uses default-java that works both for Java 
1.8 and 1.9 (please double-check, though).

R doesn't actually care as long as the paths for JAVA and JAVAC actually exist 
and I see now that the issue was that jvm/default-java is pointing directly 
inside the Java installation, so if they change how Java ship things it breaks. 

One way around it is to point both JAVA and JAVAC to the symlinks managed by 
the distribution so it's not susceptible so changes in the Java distribution.

Cheers,
Simon

Bug#882445: Proposed change of offensive packages to -offensive [and 1 more messages]

[Sean Whitton]

Hello Ian,

On Thu, Nov 23 2017, Ian Jackson wrote:

> I'm not wedded to this second half of the sentence.

Is this a proposal/seconding of the modified patch?

This bug needs one more second to be applied to the Policy repo.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882611: RM: skytools3 -- ROM; RoM; split into several new packages upstream

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Please remove skytools3. Upstream split the package into several new
source packages, and skytools3 itself should go.

Christoph


signature.asc
Description: PGP signature

Bug#882610: Please drop haproxy.service-start-after-syslog.patch

[Laurent Bigonville]

Source: haproxy
Version: 1.7.9-1
Severity: normal

Hi,

I see in the haproxy.service file that you have a After=/Wants=syslog.service

The installed syslog implementation installed on the machine is always
socket activated so adding After=/Wants=syslog.service is not needed
(and can make the dependency chain more complex).

IMHO, the haproxy.service-start-after-syslog.patch patch should be
dropped.

Do you have any specific reasons to keep this patch?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#258096: Very Urgent

[Pascaline LEVRARD]

Good day to you
Am Well pleased to inform you about an urgent business transaction I have for 
you.
kindly contact my private gmail for more details
(chenalice0...@gmail.com)

Thank you...

Best Regard

Que tengas un buen día
Me complace informarle acerca de una transacción comercial urgente que tengo 
para usted.
ponerse en contacto amablemente con mi gmail privado para más detalles
  (chenalice0...@gmail.com)

Gracias...

Cordial saludo






































































































































































?

?

Bug#882609: tryton-meta: tryton-modules-all is missing the notification_email module

[Nicolas Évrard]

Source: tryton-meta
Version: 4.6.0-1
Severity: normal

Hello Mattias,

I noticed that the module notification_email has not been packaged you
might want to include it I guess :).

Kind regards,

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

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

Bug#882600: Notice for suryavanshi.gourav OA

[gourav suryavanshi]

What u say .i dnt undurstand.

On Nov 24, 2017 23:27, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for robert TR

[robert gilbreath]

Stop sending

On Nov 24, 2017 11:57 AM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for Allen 1P2G

[Allen D]

Stop

On Fri, Nov 24, 2017 at 10:57 AM final notice 
wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for Kathleen xQ62

[Kathleen Doane]

I’m not interested in signing up for a subscription to your product

On Fri, Nov 24, 2017 at 9:57 AM final notice 
wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

-- 

"And the peace of God, which transcends all understanding, will guard your
hearts and your minds in Christ Jesus." - Philippians 4:7

With God, we have true, lasting peace! Thank you, Lord! ♥ ♥ ♥

Bug#882600: Notice for sade cg

[Lisette-Doll Mohogany]

Stop emailing me. I am not fucking interested in your Bullshit. STOP

On Nov 24, 2017 12:57 PM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for sonia jh

[Sonia Morell]

Who the hell r u

On Nov 24, 2017 12:57 PM, "final notice"  wrote:

important information
























































Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
"Christoph Berg " as Maintainer/Uploaders address in my packages, but when
I'm doing uploads from work, I'm using "Christoph Berg " in
debian/changelog to attribute my employer. The downside of this is that
lintian will raise the "NMU detected" flag. My usual workaround is to put
"Team upload" into the changelog, which is true in most cases, but
shouldn't really be necessary. Another workaround would be to simply
lintian-override the warnings, or add the other address to the Uploaders
list (which seems gross to me). I would suggest to do the NMU detection
simply based on matching real names, but this would not detect accidentally
mistyped addresses in debian/changelog or debian/control. (See also #820523
for the reverse problem where the real name differs.) What would the
lintian maintainers suggest? Christoph

Bug#882600: Notice for DAGON OH

[Paladin Sanchez]

Who dis?

On Nov 24, 2017 11:58 AM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for bobbyvarnell VADv

[bobby varnell]

Fuck you

On Nov 24, 2017 11:57 AM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for feliciatiffany92 Yl

[Felicia Tiffany Nise]

Sorry i never apply for this amazon. I will report the police if this
message is keep bothering me.thanks.
On 25 Nov 2017 01:57, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for nelson dL

[nelson torres]

stop

On Nov 24, 2017 12:57 PM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882600: Notice for Kerri-ann Lb

[Kerri Conway]

I'm sorry but the email is empty. Final notice for what?

On Nov 24, 2017 12:57 PM, "final notice"  wrote:

> important information
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using
> "Christoph Berg " as Maintainer/Uploaders address in my packages, but
> when I'm doing uploads from work, I'm using "Christoph Berg " in
> debian/changelog to attribute my employer. The downside of this is that
> lintian will raise the "NMU detected" flag. My usual workaround is to put
> "Team upload" into the changelog, which is true in most cases, but
> shouldn't really be necessary. Another workaround would be to simply
> lintian-override the warnings, or add the other address to the Uploaders
> list (which seems gross to me). I would suggest to do the NMU detection
> simply based on matching real names, but this would not detect accidentally
> mistyped addresses in debian/changelog or debian/control. (See also #820523
> for the reverse problem where the real name differs.) What would the
> lintian maintainers suggest? Christoph

Bug#882608: ruby-mechanize: FTBFS and Debci failure with ruby 2.3.5

[Adrian Bunk]

Source: ruby-mechanize
Version: 2.7.5-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/r/ruby-mechanize/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-mechanize.html

...

┌──┐
│ Run tests for ruby2.3 from debian/ruby-test-files.yaml   │
└──┘

RUBYLIB=/build/1st/ruby-mechanize-2.7.5/debian/ruby-mechanize/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-mechanize/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ \{\ 
\|f\|\ require\ f\ \}
Run options: --seed 47730

# Running:

...DEPRECATED: Use assert_nil if 
expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_page_meta_refresh.rb:115. 
This will fail in Minitest 6.
...E..DEPRECATED: assert_send. From 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize.rb:984
.F..E...EDEPRECATED: 
assert_send. From /build/1st/ruby-mechanize-2.7.5/test/test_mechanize.rb:946
..DEPRECATED: assert_send. From 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize.rb:965
.DEPRECATED: Use assert_nil if 
expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_cookie.rb:461. This will 
fail in Minitest 6.
...DEPRECATED: Use assert_nil if expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_util.rb:30. This will fail 
in Minitest 6.
.DEPRECATED: Use assert_nil if expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_form_encoding.rb:70. This 
will fail in Minitest 6.
.DEPRECATED:
 Use assert_nil if expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_page_link.rb:342. This will 
fail in Minitest 6.
..DEPRECATED: Use assert_nil if expecting nil from 
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize_page_link.rb:75. This will 
fail in Minitest 6.
..

Finished in 1.713436s, 384.0237 runs/s, 1220.9387 assertions/s.

  1) Error:
TestMechanize#test_get_http_refresh_disabled:
ArgumentError: header field value cannnot include CR/LF
/usr/lib/ruby/2.3.0/net/http/header.rb:76:in `set_field'
/usr/lib/ruby/2.3.0/net/http/header.rb:41:in `[]='

/build/1st/ruby-mechanize-2.7.5/debian/ruby-mechanize/usr/lib/ruby/vendor_ruby/mechanize/test_case/http_refresh_servlet.rb:6:in
 `do_GET'

/build/1st/ruby-mechanize-2.7.5/debian/ruby-mechanize/usr/lib/ruby/vendor_ruby/mechanize/test_case.rb:234:in
 `request'
/usr/lib/ruby/vendor_ruby/net/http/persistent.rb:999:in `request'

/build/1st/ruby-mechanize-2.7.5/debian/ruby-mechanize/usr/lib/ruby/vendor_ruby/mechanize/http/agent.rb:274:in
 `fetch'

/build/1st/ruby-mechanize-2.7.5/debian/ruby-mechanize/usr/lib/ruby/vendor_ruby/mechanize.rb:464:in
 `get'
/build/1st/ruby-mechanize-2.7.5/test/test_mechanize.rb:614:in 
`test_get_http_refresh_disabled'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:107:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:204:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:104:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:255:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:103:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:350:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:275:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:102:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:839:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:311:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:310:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:310:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:350:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest.rb:337:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest.rb:309:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `block in __run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `map'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `__run'

Bug#882537: biber FTBFS:

[Adrian Bunk]

On Fri, Nov 24, 2017 at 09:58:27AM +0900, Norbert Preining wrote:
> > # -  \\field{sortinithash}{f615fb9c6fba11c6f962fb3fd599810e}
> > # +  \\field{sortinithash}{07bbd5a529b5beaa311df5be05b874bc}
> 
> Yeah, usual mix up between libunicode-collate-perl as shipped with
> perl internally and with extra module.
> 
> Did you install libunicode-collate-perl package or used the perl
> internal provided?

The build log I linked to says:
  Unpacking libunicode-collate-perl (1.24-1) ...

> It is very unfortunate that perl provides a package but is not 100%
> compatible with it.
> 
> Norbert

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#882607: libdbus-1-3: steam crashes at start with latest libdbus update

[Axel R.]

Package: libdbus-1-3
Version: 1.12.2-1
Severity: important

Updating libdbus-1-3:i386 (1.12.0-1, 1.12.2-1) led to steam client crashes with:
dbus[4877]: arguments to dbus_message_new_method_call() were incorrect, 
assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace


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

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

Bug#882292: acpica-unix FTBFS on 32bit big endian: test failures

[James Cowgill]

Control: tags -1 patch

Hi,

On 23/11/17 18:01, James Cowgill wrote:
> On 21/11/17 07:28, Adrian Bunk wrote:
>> Begin compiling test package: [operand]
>> Begin compiling test package: [tests]
>> Begin compiling test package: [oarg]
>> Test path: 
>> /<>/tests/aslts/src/runtime/collections/complex/operand/tests/oarg
>> Type: nopt/32 Compile => Removing filesrm: cannot remove 'MAIN.asm': No 
>> such file or directory
>> rm: cannot remove 'MAIN.c': No such file or directory
>> rm: cannot remove 'MAIN.h': No such file or directory
>> rm: cannot remove 'MAIN.i': No such file or directory
>> rm: cannot remove 'MAIN.hex': No such file or directory
>> rm: cannot remove 'MAIN.lst': No such file or directory
>> rm: cannot remove 'MAIN.map': No such file or directory
>> rm: cannot remove 'MAIN.nsp': No such file or directory
>> rm: cannot remove 'MAIN.offset.h': No such file or directory
>> rm: cannot remove 'MAIN.src': No such file or directory
>>  => Done 
>> ls: cannot access 'oarg.aml': No such file or directory
>> mv: cannot stat 'oarg.aml': No such file or directory
>> Compiled test package: [oarg]
>> ...
>> WARNING: some test cases dont have AML code! (168)
>> ...
>> iASL: Segmentation Fault
> 
> I think this is caused by this in aslrules.y:
>> String
>> : PARSEOP_STRING_LITERAL{$$ = TrCreateValuedLeafOp 
>> (PARSEOP_STRING_LITERAL,
>> (ACPI_NATIVE_INT) 
>> AslCompilerlval.s);}
>> ;
> 
> Here we cast a (char*) to uint64.
> 
> In aslparseop.c we assign this uint64 into a union:
>> ACPI_PARSE_OBJECT *
>> TrCreateValuedLeafOp (
>> UINT32  ParseOpcode,
>> UINT64  Value)
>> {
>> ACPI_PARSE_OBJECT   *Op;
>>
>>
>> Op = TrAllocateOp (ParseOpcode);
>> Op->Asl.Value.Integer = Value;
> 
> This union us defined like this (aclocal.h):
>> typedef union acpi_parse_value
>> {
>> UINT64  Integer;/* Integer constant (Up 
>> to 64 bits) */
>> UINT32  Size;   /* bytelist or field 
>> size */
>> char*String;/* NULL terminated 
>> string */
>> UINT8   *Buffer;/* buffer or string */
>> char*Name;  /* NULL terminated 
>> string */
>> union acpi_parse_object *Arg;   /* arguments and 
>> contained ops */
>> ACPI_TAG_INFO   Tag;/* Resource descriptor 
>> tag info  */
>>
>> } ACPI_PARSE_VALUE;
> 
> On 32-bit big endian we end up putting the pointer into the _lower_ half
> of "Integer" which does not work when later reading from "String" (which
> will read from the _upper_ half).
> 
> I might have a go at getting a patch working for this. These bad casts
> make me despair :(

The attached patch works on mips. I didn't test the other failing
architectures.

Thanks,
James
--- a/source/compiler/aslparseop.c
+++ b/source/compiler/aslparseop.c
@@ -283,7 +283,16 @@ TrCreateValuedLeafOp (
 
 
 Op = TrAllocateOp (ParseOpcode);
-Op->Asl.Value.Integer = Value;
+if (ParseOpcode == PARSEOP_NAMESTRING ||
+ParseOpcode == PARSEOP_NAMESEG ||
+ParseOpcode == PARSEOP_STRING_LITERAL)
+{
+Op->Asl.Value.String = (char *) Value;
+}
+else
+{
+Op->Asl.Value.Integer = Value;
+}
 
 DbgPrint (ASL_PARSE_OUTPUT,
 "\nCreateValuedLeafOp  Ln/Col %u/%u NewOp %p  "
--- a/source/include/platform/aclinux.h
+++ b/source/include/platform/aclinux.h
@@ -225,10 +225,8 @@
 #endif
 
 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
-#if defined(__PPC64__) || defined(__s390x__)
 #define ACPI_BIG_ENDIAN
 #endif
-#endif
 
 #endif /* __KERNEL__ */
 


signature.asc
Description: OpenPGP digital signature

Bug#881834: systemd: lib/systemd/systemd-remount-fs fails with /dev/nfs in fstab

[Duncan Hare]

Michael
I agree. 

I ask because just ignoring the /dev/nfs fstab entry would appear not to be a 
solution, and point to a process (in Jessie) which worked.
 Regards
Duncan Hare
714 931 7952

  From: Michael Biebl 
 To: Duncan Hare ; "881...@bugs.debian.org" 
<881...@bugs.debian.org> 
 Sent: Friday, November 24, 2017 9:16 AM
 Subject: Re: Bug#881834: systemd: lib/systemd/systemd-remount-fs fails with 
/dev/nfs in fstab
   
Am 24.11.2017 um 17:03 schrieb Duncan Hare:
> Michael
> 
> Thanks, if /dev/nfs is ignored, then omitting it from fstab should work.
> 
> That also fails. The filesystem is mounted ro by the kernel, and the
> system is unusable.

Again, this is something for the maintainers of mount.nfs to figure out.

> What was the process on Debian Jessie? That worked.

No idea.


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