Bug#902649: openbabel: CMake v3.11.2 deprecation warnings

[Andrius Merkys]

Source: openbabel
control: forwarded -1 https://github.com/openbabel/openbabel/issues/1860

Hello.

Running ``cmake`` with CMake v3.11.2 results in the following CMake deprecation 
warnings being issued:

CMake Deprecation Warning at CMakeLists.txt:11 (cmake_policy):
  The OLD behavior for policy CMP0005 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:13 (cmake_policy):
  The OLD behavior for policy CMP0042 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.

The input files for CMake should be updated in order not to use the deprecated 
features.

Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#894757: (No Subject)

[Fjfj109]

Judging from the reply ... is this actually fixed now and the bug just isn't 
closed or is it not fixed?

Bug#902648: xtrlock: stop using xmkmf

[Helmut Grohne]

Source: xtrlock
Version: 2.8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block 873764 by -1

We want to remove xmkmf from Debian (see #873764), because it is
unmaintained and breaks cross compilation. The attached patch
reimplements the simple build system in debian/rules to remove the
dependency on xmkmf. Please consider applying it.

Helmut
diff --minimal -Nru xtrlock-2.8/debian/changelog 
xtrlock-2.8+nmu1/debian/changelog
--- xtrlock-2.8/debian/changelog2016-05-21 20:08:12.0 +0200
+++ xtrlock-2.8+nmu1/debian/changelog   2018-06-29 06:22:10.0 +0200
@@ -1,3 +1,10 @@
+xtrlock (2.8+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop using xmkmf. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jun 2018 06:22:10 +0200
+
 xtrlock (2.8) unstable; urgency=low
 
   * patch from Simon Tatham to add a -f option [fork, and return success
diff --minimal -Nru xtrlock-2.8/debian/control xtrlock-2.8+nmu1/debian/control
--- xtrlock-2.8/debian/control  2014-01-07 15:26:09.0 +0100
+++ xtrlock-2.8+nmu1/debian/control 2018-06-29 06:21:18.0 +0200
@@ -2,7 +2,7 @@
 Maintainer: Matthew Vernon 
 Section: x11
 Priority: optional
-Build-Depends: libx11-dev, x11proto-core-dev, xutils-dev, dpkg-dev (>= 1.16.1~)
+Build-Depends: libx11-dev, x11proto-core-dev, dpkg-dev (>= 1.16.1~)
 Standards-Version: 3.9.1
 
 Package: xtrlock
diff --minimal -Nru xtrlock-2.8/debian/rules xtrlock-2.8+nmu1/debian/rules
--- xtrlock-2.8/debian/rules2015-03-07 23:34:07.0 +0100
+++ xtrlock-2.8+nmu1/debian/rules   2018-06-29 06:21:04.0 +0200
@@ -2,10 +2,12 @@
 # debian/rules file for xtrlock-2.0
 # Based upon the sample debian.rules file by Ian Jackson.
 
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+
 package=xtrlock
 
-arch=$(shell dpkg --print-architecture)
-STRIP=strip
+STRIP=$(DEB_HOST_GNU_TYPE)-strip
 
 DPKG_EXPORT_BUILDFLAGS = 1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
@@ -15,8 +17,7 @@
 
 build:
$(checkdir)
-   xmkmf
-   $(MAKE) CFLAGS="$(CFLAGS)" CDEBUGFLAGS="" LOCAL_LDFLAGS="$(LDFLAGS)" 
xtrlock
+   $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt 
-lX11
touch build
 
 clean:

Bug#902647: maelstrom FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: maelstrom
Version: 1.4.3-L3.0.6+main-9
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

maelstrom fails to cross build from source, because it configures for
the build architecture. I'd normally suggest using dh_auto_configure
here, but dh_auto_configure passes --runstatedir and maelstrom's
./configure doesn't like that. Thus the attached patch adds the relevant
--build and --host flags explicitly. Please consider applying it.

Helmut
diff --minimal -Nru maelstrom-1.4.3-L3.0.6+main/debian/changelog 
maelstrom-1.4.3-L3.0.6+main/debian/changelog
--- maelstrom-1.4.3-L3.0.6+main/debian/changelog2018-03-01 
01:04:45.0 +0100
+++ maelstrom-1.4.3-L3.0.6+main/debian/changelog2018-06-28 
23:19:50.0 +0200
@@ -1,3 +1,10 @@
+maelstrom (1.4.3-L3.0.6+main-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Jun 2018 23:19:50 +0200
+
 maelstrom (1.4.3-L3.0.6+main-9) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru maelstrom-1.4.3-L3.0.6+main/debian/rules 
maelstrom-1.4.3-L3.0.6+main/debian/rules
--- maelstrom-1.4.3-L3.0.6+main/debian/rules2015-09-30 22:00:00.0 
+0200
+++ maelstrom-1.4.3-L3.0.6+main/debian/rules2018-06-28 23:19:50.0 
+0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 TMPDIR=maelstrom
 BINDIR=debian/${TMPDIR}/usr/games
 LIBDIR=debian/${TMPDIR}/usr/lib/games/maelstrom
@@ -22,7 +24,7 @@
 build:
cp /usr/share/misc/config.guess .
cp /usr/share/misc/config.sub .
-   ./configure CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
+   ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) 
CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)"
$(MAKE)
touch build
 

Bug#721007: #721007 clipit: Wakes up too many times per second and prevents deep sleep of cpu

[Dmitry Smirnov]

I've just uploaded clipit-1.4.4 to "unstable" and it seems to behave, staying 
below "/usr/sbin/acpid", and "/usr/lib/firefox/firefox" in powertop.

Is 1.4.4 still wakes up too often for you?

-- 
All the best,
 Dmitry Smirnov.

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill


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

Bug#900856: enlightenment: Sound fails to work after upgrade

[Felipe Sateler]

Hi Mike,

On Thu, Jun 28, 2018 at 6:15 PM Mike Brodbelt  wrote:

> On 21/06/18 12:34, Felipe Sateler wrote:
>
> > Patches welcome. If you decide to implement this, make sure that the
> > code is only active with a running sysvinit (ie, don't affect chroots).
> > It is not trivial, which is why I didn't implement it myself. You
> > probably need to integrate ucf to handle all the corner cases.
>
> Patch attached.


Thanks. However, it has some flaws that need to be reworked for this to
work at all:

1. We can't rely on gcc being installed
2. It doesn't check /proc is actually mounted
3. dpkg status check is racy: sysvinit might be upgraded at the same time,
and thus not be "installed"
4. dpkg status check is for the wrong package: sysvinit no longer exists (I
think you want sysvinit-core).
5. The postinst should be the one for libpulse0, not pulseaudio

I would suggest poking around in /proc/1/ instead to check for sysvinit.


> I haven't gone through all the steps of integrating ucf
> - the disable autospawn file isn't currently marked in the package as a
> conffile, so this patch, while it works in my limited testing, could
> still be improved on there.
>

You missed the conffile mark because it is shipped in libpulse0 :)


>
> LMK what you think - if you're happy with this approach and will
> integrate it, I can work on ucf integration as well.
>

I don't have objections in principle, but I want a good and relatively
not-risky implementation first.

BTW, it might be easier to do the review/fixup dance in a merge request on
salsa: https://salsa.debian.org/pulseaudio-team/pulseaudio

-- 

Saludos,
Felipe Sateler

Bug#902646: python3-pexpect: Failure to install with Python 3.7

[Austin Roach]

Package: python3-pexpect
Version: 4.2.1-1
Severity: serious

Installation fails with python3.7 installed:

Setting up python3-pexpect (4.2.1-1) ...
  File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py"
def expect(self, pattern, timeout=-1, searchwindowsize=-1, async=False):
SyntaxError: invalid syntax

'async' is a reserved keyword in Python 3.7. This issue has been
previously reported upstream, and was fixed in version 4.3 of
pexpect.[1] The current upstream version is 4.6.

[1] https://github.com/pexpect/pexpect/issues/453

Bug#900473: krank: Proposing NMU to solve #862181 and #900473

[Boyuan Yang]

X-Debbugs-CC: un...@debian.org pkg-games-de...@lists.alioth.debian.org

Hi Dmitry and Debian Games Team,

I noticed that package "krank" under Debian Fonts Team hasn't receive any 
uploads since 2012. I am proposing an upload to fix the following two bugs:

* #862181: krank: Please do not depends on transitional dummy pkg ttf-dejavu

* #900473:  krank: please update Vcs-* for migration to salsa.debian.org

..plus this issue:

* https://lists.debian.org/debian-devel/2018/05/msg00499.html
  "packages which have not been rebuild since December 2016"
  (they need to be rebuilt)

I am wondering if anyone would like to help to sponsor such an upload. If not, 
I might file an RFS bug for an NMU about 7 days later.

The full source diff is pasted here:

=
commit dc7d02ebb10dce7a2d8497e92c44fb95e6025c67
Author: Boyuan Yang <073p...@gmail.com>
Date:   Fri Jun 29 11:13:17 2018 +0800

debian: Prepare NMU for #900473 and #862181.

diff --git a/debian/changelog b/debian/changelog
index e3cbd5a..ae931ba 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+krank (0.7+dfsg2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Vcs-* fields for migration to salsa.debian.org.
+Closes: #900473.
+  * Replace dependency to ttf-dejavu with fonts-dejavu.
+Closes: #862181.
+  * Replace Priority: extra with Priority: optional to reflect requirement
+of new policy.
+
+ -- Boyuan Yang <073p...@gmail.com>  Fri, 29 Jun 2018 11:12:19 +0800
+
 krank (0.7+dfsg2-3) unstable; urgency=low
 
   * Fixed description, closes: #628129.
diff --git a/debian/control b/debian/control
index a143605..a0d1c63 100644
--- a/debian/control
+++ b/debian/control
@@ -1,18 +1,18 @@
 Source: krank
 Section: games
-Priority: extra
+Priority: optional
 Maintainer: Dmitry E. Oboukhov 
 Uploaders: Debian Games Team 
 Standards-Version: 3.9.3
 Build-Depends: debhelper (>=7.0), cdbs
 Build-Depends-Indep: imagemagick
-Vcs-Browser: http://git.debian.org/?p=collab-maint/krank.git;a=summary
-Vcs-Git: git://git.debian.org/collab-maint/krank.git
+Vcs-Browser: https://salsa.debian.org/games-team/krank
+Vcs-Git: https://salsa.debian.org/games-team/krank.git
 Homepage: http://krank.sourceforge.net/
 
 Package: krank
 Architecture: all
-Depends: python-pygame, python-yaml, ttf-dejavu, ${misc:Depends}
+Depends: python-pygame, python-yaml, fonts-dejavu, ${misc:Depends}
 Description: game of dexterity where you match stones together
  krank is a game of dexterity, being somewhere between Breakout and billiard,
  where the aim of each level is to shove floating stones towards compatible
=


Thanks!

--
Regards,
Boyuan Yang

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

Bug#902645: /usr/bin/plasmashell: plasmashell keeps requesting to mount nfs for no reason

[Jiri Kanicky]

Package: plasma-workspace
Version: 4:5.12.5-1
Severity: normal
File: /usr/bin/plasmashell

Dear Maintainer,

ISSUE:
plasmashell keeps requesting to mount nfs for no reason.

syslog:
Jun 29 12:31:48 superman systemd[1]: Unmounting /mnt/megatron-media...
Jun 29 12:31:48 superman systemd[1]: Unmounted /mnt/megatron-media.
Jun 29 12:31:48 superman systemd[1]: mnt-megatron\x2dmedia.automount: Got 
automount request for /mnt/megatron-media, triggered by 1248 (plasmashell)
Jun 29 12:31:48 superman systemd[1]: Mounting /mnt/megatron-media...
Jun 29 12:31:49 superman systemd[1]: Mounted /mnt/megatron-media.

I have NFS mounts in /etc/fstab which permit user to mount and also
automacially unmount the FS if idle.
# megatron.internal.corp:/mnt/storage/media /mnt/megatron-medianfs4
noauto,user,noatime,nodiratime,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min
  0   0

EXPECTATION:
I believe there is no reason for these requests to mount it. Plasmashell
should not request to mount the filesystem until i click on the mount in
Dolphin.


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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.12.8-3
ii  drkonqi  5.12.5-1
ii  frameworkintegration 5.47.0-1
ii  gdb-minimal [gdb]7.12-6+b2
ii  iso-codes3.79-1
ii  kactivitymanagerd5.12.5-1
ii  kde-cli-tools4:5.12.5-1
ii  kded55.47.0-1
ii  kinit5.47.0-1
ii  kio  5.47.0-1
ii  kpackagetool55.47.0-1
ii  kwin-common  4:5.12.5-1
ii  libappstreamqt2  0.12.1-1
ii  libc62.27-3
ii  libcln6  1.3.4-4
ii  libcolorcorrect5 4:5.12.5-1
ii  libgcc1  1:8.1.0-8
ii  libgps23 3.17-5+b1
ii  libice6  2:1.0.9-2
ii  libkf5activities55.47.0-1
ii  libkf5auth5  5.47.0-1
ii  libkf5baloo5 5.47.0-1
ii  libkf5bookmarks5 5.47.0-1
ii  libkf5calendarevents55.47.0-1
ii  libkf5completion55.47.0-1
ii  libkf5config-bin 5.47.0-1
ii  libkf5configcore55.47.0-1
ii  libkf5configgui5 5.47.0-1
ii  libkf5configwidgets5 5.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5dbusaddons55.47.0-1
ii  libkf5declarative5   5.47.0-1
ii  libkf5globalaccel-bin5.47.0-1
ii  libkf5globalaccel5   5.47.0-1
ii  libkf5guiaddons5 5.47.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5iconthemes55.47.0-1
ii  libkf5idletime5  5.47.0-1
ii  libkf5itemviews5 5.47.0-1
ii  libkf5jobwidgets55.47.0-1
ii  libkf5js55.47.0-1
ii  libkf5jsembed5   5.47.0-1
ii  libkf5kdelibs4support5   5.47.0-1
ii  libkf5kiocore5   5.47.0-1
ii  libkf5kiofilewidgets55.47.0-1
ii  libkf5kiogui55.47.0-1
ii  libkf5kiowidgets55.47.0-1
ii  libkf5networkmanagerqt6  5.47.0-1
ii  libkf5newstuff5  5.47.0-1
ii  libkf5notifications5 5.47.0-1
ii  libkf5notifyconfig5  5.47.0-1
ii  libkf5package5   5.47.0-1
ii  libkf5plasma55.47.0-1
ii  libkf5plasmaquick5   5.47.0-1
ii  libkf5prison55.47.0-1
ii  libkf5quickaddons5   5.47.0-1
ii  libkf5runner55.47.0-1
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
ii  libkf5solid5 5.47.0-1
ii  libkf5texteditor55.47.0-1
ii  libkf5textwidgets5  

Bug#902287: systemctl unmask --runtime no longer supported

[Carl Suster]

On Sun, 24 Jun 2018 16:25:14 +0200 Michael Biebl  
wrote> According to codesearch we currently have two packages in the archive

using unmask --runtime: avahi and policykit-1

https://sources.debian.org/src/avahi/0.7-3.1/debian/avahi-daemon.postrm/?hl=7#L7

https://sources.debian.org/src/policykit-1/0.105-20/debian/policykit-1.postinst/?hl=58#L58
https://sources.debian.org/src/policykit-1/0.105-20/debian/policykit-1.preinst/?hl=15#L15


The postrm script of modemmanager is also affected: see #902260.

Bug#902260: modemmanager: postrm script broken: --runtime cannot be used with unmask

[Carl Suster]

From the recent changelog of systemd:

systemd (239-3) unstable; urgency=medium

   * Revert "systemctl: when removing enablement or mask symlinks, 
cover both /run and /etc"
 We currently have packages in the archive which use "systemctl 
--runtime unmask" and are broken by this change. This is a intermediate 
step until it is clear whether upstream will revert this commit or 
whether we will have to update affected packages to deal with this 
changed behaviour.

See #902287 and https://github.com/systemd/systemd/issues/9393

-- Michael Biebl  Wed, 27 Jun 2018 14:46:06 +0200

Looks like this package is also affected by #902287

Bug#899613: mokomaze: Invalid maintainer address pkg-fso-ma...@lists.alioth.debian.org

[Paul Wise]

On Thu, 24 May 2018 09:44:13 +0200 (CEST) Christoph Biedl wrote:

> This affects your package mokomaze since the list address
> pkg-fso-ma...@lists.alioth.debian.org used in the Maintainer: field was
> not transferred to the alioth-lists service that provides a
> continuation for the lists in the @lists.alioth.debian.org domain.

I'll probably move this to the games team during DebCamp18.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#901427: Unable to enable ext4 journaled quota

[Elliott Mitchell]

On Sun, Jun 17, 2018 at 02:31:29PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jun 15, 2018 at 07:37:19PM -0700, Elliott Mitchell wrote:
> > 
> > During the process I ended up running `e2fsck -f` multiple times.  I
> > ended up running `e2fsck -f` after enabling each feature (`tune2fs`
> > really didn't like enabling multiple features at once).

> I will note that if you are starting with an ext2/ext3 file system (one
> without extents and the uninit_bg or metadata_csum features), you will
> get much better performance in the long run if you create a new ext4
> file system and then copy all of the data from the ext2 file system to
> ext4.
> 
> My experience from when we did an ext2 upgrade to ext4 (in no-journal
> mode) some six or seven years ago, for our workload, which was for a
> cluster file system, was comparing the performance of an existing file
> system upgrading to ext4 in place, versus the performance of a freshly
> created ext4 file system, was that the upgrade-in-place experience
> resulted in roughly half the performance improvement compared to a
> fresh ext4 file system.
> 
> So if you are going to need to run tune2fs and e2fsck -f multiple
> times  what are you trying to do?  What's the goal here?

Performance isn't a critical issue for this system.  As long as
performance is reasonable and ideally not too much system admin time is
spent, that is good enough.  I'm more concerned with keeping the system
up to date.  Everything is moving off ext3 onto ext4 and since one
crucial utility finally got updated for ext4, I'm doing upgrades.

One thing which had been an issue was getting journalled quotas.  Doing
full quota checks by having `repquota` do what amounts to an `fsck` is
kind of a bit slow.  I thought I'd managed to accomplish that while still
on ext3, but I wasn't absolutely certain...

> Don't get me wrong; if you can get me a reproducible test case, I'm
> happy to look at it.  But Red Hat doesn't support upgrading file
> systems via tune2fs.  And that's because there are all sorts of corner
> cases and it's very hard to do regression testing or bug
> reproductions.  We have used tune2fs to upgrade file systems at
> Google, but it's something we testetd extensively, and we only did it
> where it makes sense.

RedHat support isn't an issue for me if you notice where this report
appeared.  :-)  It was my understanding upgrade via `tune2fs` is supposed
to work, so I used the handy tool.


> > > And do you really need to enable user, group, and project quota
> > > tracking?  Please keep in mind there is a performance cost for
> > > enabling quota tracking; it is definitely not free
> > 
> > I definitely want user quota with journal.  I'm unsure of group and
> > project.
> 
> For each quota type that you enable, you basically end up paying for
> an extra random write, and potentially a random read, associated with
> block or inode allocation for a given user or group id, every five
> seconds.  So if you don't need group or project tracking, don't turn
> it on.  We only track usage based on a group basis, so we only enable
> group quotas.
> 
> As far as the turning on the quota feature and that terrible error
> message --- did the file system have any quota files before, and did
> you check to see if the file system was full (e.g., not enough blocks
> to allocate the quota file)?

Yes.  I could well believe `tune2fs` is unable to upgrade quota type, and
that is where the problem came from.  Disabling one quota type may be
worthwhile.

`dumpe2fs -h` with magic numbers stripped, filesystem 0:

Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index filetype 
needs_recovery extent 64bit mmp sparse_super large_file metadata_csum
Filesystem flags: signed_directory_hash 
Default mount options:user_xattr acl
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  262144
Block count:  1047552
Reserved block count: 52377
Free blocks:  828522
Free inodes:  253868
First block:  0
Block size:   4096
Fragment size:4096
Group descriptor size:64
Reserved GDT blocks:  255
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8192
Inode blocks per group:   512
Filesystem created:   Fri May 12 18:59:53 2017
Last mount time:  Tue Jun 12 23:30:50 2018
Last write time:  Tue Jun 12 23:30:50 2018
Mount count:  2
Maximum mount count:  22
Last checked: Tue Jun 12 22:52:53 2018
Check interval:   0 ()
Lifetime writes:  350 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Default directory hash:   half_md4
MMP block 

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[James McCoy]

Control: reassign -1 src:astroid
Control: retitle -1 Not compatible with Python 3.7
Control: tag -1 upstream
Control: affects -1 devscripts

On Thu, Jun 28, 2018 at 03:12:14PM -0400, Lev Lazinskiy wrote:
> The current CI process fails in unstable[1]. It appears to be due to Python
> 3.7 being released in the last few days[2].
> 
> The issue is:
> 
> 
> : generator raised StopIteration
> 
> 
> It can be reproduced by running:
> 
> python3.7 -m flake8 --max-line-length=99
> debdiff-apply reproducible-check sadt suspicious-source wrap-and-sort
> devscripts setup.py
> 
> in unstable.

I think you mean "-m pylint" here, since the astroid modules are used by
pylint.

https://github.com/PyCQA/astroid/issues/539

> This appears to be an intentional regression that is caused by python
> 3.7 enforcing PEP 479 [3].
> 
> 
> [1] https://salsa.debian.org/levlaz-guest/devscripts/-/jobs/28131
> [2] https://www.python.org/downloads/release/python-370/
> [3] https://www.python.org/dev/peps/pep-0479/

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

Bug#902644: upower: Upower breaks power saving settings after upgrade to 0.99.8-1

[Adilson dos Santos Dantas]

Package: upower
Version: 0.99.8-1
Severity: important

Dear Maintainer,

After upgrading upower to 0.99.8-1, my KDE power saving settings stops working.
There is no reaction when I unplug and plug back my notebook AC power.
Only the battery charge status changes after a few minutes.

The only workaround found, for this problem, is a downgrade back to 0.99.7-2.

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

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

Versions of packages upower depends on:
ii  dbus   1.12.8-3
ii  libc6  2.27-3
ii  libglib2.0-0   2.56.1-2
ii  libgudev-1.0-0 232-2
ii  libimobiledevice6  1.2.1~git20180302.3a37a4e-1
ii  libplist3  2.0.0-3
ii  libupower-glib30.99.8-1
ii  libusb-1.0-0   2:1.0.22-2
ii  udev   239-3

Versions of packages upower recommends:
ii  policykit-1  0.105-20

upower suggests no packages.

-- no debconf information

Bug#902643: buggy magic: dump previous vs current swapped

[Elliott Mitchell]

Package: file
Version: 1:5.30-1+deb9u1

SSIA.  When examining files produced by `dump` it gives a date for the
current file and the date of the previous dump.  Unfortunately the date
it is giving for the "Previous dump" is the date on the file being
examined, whereas the date for "This dump" is the date of the previous
dump.

I find it odd that level 1 or level 2 dumps generate "Level 1" or
"Level 2" in `file`'s output, whereas level 0 gets "Level zero"
(consistent use of arabic or localized units would be handy).


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

Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS

[Scott Kitterman]

I had hoped to work on this this week.  It hasn't happened and it's not going 
to.

In the end, I the Qt4 stuff has to go, so I wouldn't wait on this for the 
transition.

Scott K

On June 28, 2018 1:23:31 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>El miércoles, 27 de junio de 2018 16:25:23 -03 Niko Tyni escribió:
>> On Tue, Jun 19, 2018 at 10:05:09AM -0300, Lisandro Damián Nicanor
>Pérez 
>Meyer wrote:
>[snip] 
>> > > Copying the debconf maintainers as well.
>> > 
>> > Hi! I have just pinged the rest of the Qt/KDE team for thoughts, as
>I have
>> > never used this myself so I might not have a good view on the
>issue.
>> > 
>> > I'll try to follow up soon, but please ping me again (IRC is valid
>too) if
>> > I don't cam up with a reply in, let's say, 5 to 7 days.
>> 
>> Hi, any news here? FWIW Perl 5.28.0 final was released recently and
>is
>> now in experimental. It would be great to get this issue moving
>forward
>> one way or another.
>
>For what I know Scott (CCed) was waiting on a reply from someone wrt
>this. 
>That's all I could gather I'm afraid.

Bug#900469: firefox: Spell checker stopped working after upgrading from version 60 to 61.0~b8

[Ben Caradoc-Davies]

Upstream report (forwarded set):
https://bugzilla.mozilla.org/show_bug.cgi?id=1469740

I can confirm that downgrade to 60.0.2-2 is an effective workaround 
(notfound set).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#902642: qpdf.1: Minor fixes to the manual

[Bjarni Ingi Gislason]

Package: qpdf
Version: 8.1.0-1
Severity: minor
Tags: patch

Input file is qpdf.1

Add a period in front of the first two comment lines, otherwise troff
creates the first page to be empty.

Test nr. 13:

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

18:\fBqpdf --help\fR.  A complete manual can be found in

#

Test nr. 21:

Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them.

  Or

add the italic corrections.
[1] man-pages(7) [package "manpages"]

8:[ \fIoptions \fR] \fIinfilename [ outfilename ]\fR

#

  The patch:

--- qpdf.1  2018-06-23 13:17:28.0 +
+++ qpdf.1.new  2018-06-28 19:28:31.0 +
@@ -1,11 +1,11 @@
-\" This file is not processed by autoconf, but rather by build.mk in
-\" the manual directory.
+.\" This file is not processed by autoconf, but rather by build.mk in
+.\" the manual directory.
 .TH QPDF "1" "April 2008" "qpdf version 8.1.0" "User Commands"
 .SH NAME
 qpdf \- PDF transformation software
 .SH SYNOPSIS
 .B qpdf
-[ \fIoptions \fR] \fIinfilename [ outfilename ]\fR
+.RI "[ " options " ] " infilename " [ " outfilename " ]"
 .SH DESCRIPTION
 The qpdf program is used to convert one PDF file to another equivalent
 PDF file.  It is capable of performing a variety of transformations
@@ -15,5 +15,5 @@ options for inspecting or checking PDF f
 useful primarily to PDF developers.
 .PP
 For a summary of qpdf's options, please run
-\fBqpdf --help\fR.  A complete manual can be found in
+\fBqpdf \-\-help\fR.  A complete manual can be found in
 /usr/share/doc/qpdf/qpdf-manual.html or /usr/share/doc/qpdf/qpdf-manual.pdf.


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

Kernel: Linux 4.9.110-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qpdf depends on:
ii  libc62.27-3
ii  libgcc1  1:8.1.0-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libqpdf218.1.0-1
ii  libstdc++6   8.1.0-8
ii  zlib1g   1:1.2.11.dfsg-1

qpdf recommends no packages.

qpdf suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump

[Wouter Verhelst]

On Thu, Jun 28, 2018 at 04:27:12PM +0200, Guillem Jover wrote:
> On Thu, 2018-06-28 at 14:34:06 +0200, Wouter Verhelst wrote:
> > On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote:
> > > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote:
> > > > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> > > > > The requirement to consult d-d has worked very well with Pre-Depends.
> > > > > Many pointless and harmful Pre-Depends have been avoided this way,
> > > > > with very low levels of project-wide effort.
> > > > 
> > > > Yes. There's a difference though.
> > > 
> > > Sure, but not in their harmfulness, though. :)
> > 
> > That's just a matter of opinion.
> 
> I don't think it is though. I'd even say bogus epochs bumps are
> potentially more harmful than Pre-Depends!

How and in which ways are bogus epochs harmful that uploading a package
with the +really convention is not?

Downgrading a package is harmful, that's true. In that respect, using a
bogus epoch is problematic. However, none of those harmful effects are a
result of the use of the epoch; instead, they are a result of the
downgrading of a package.

Using an epoch in that way is harmful; not because the file now has an
extra non-implicit version number (which is just a technical thing), but
because you're effectively causing a downgrade on a user's system which
breaks dependency relations in unexpected ways.

Should we discourage downgrading packages? Yes, absolutely. But that's
not what this proposal does.

> Pre-Depends are localized in a single package, and their effects can
> be easily tested,

Not unless you can come up with a solution for the halting problem.

> but the validity of the rationale for its introduction might be
> difficult or impossible to check automatically, though. But the full
> effects of epoch bumps are not easily testable at all and they are
> changes with global effect, for all rdepends (in-archive and local),
> local forks, etc.

I guess your definition of "global effect" differs from mine.

At any rate, this isn't really the core of my argument, so meh.

[...]
> When breaking the release continuity, and forcing an invalidation of
> all relationships, it means we might be breaking upgrade scenarios,
> satisfiability checks, interface requirement checks, etc, this is a
> silent and very harmful thing.

Yes, but the issue lies not with epochs; rather, it lies with the
fact that you're downgrading the upstream software, which happens
regardless of whether you use an epoch or the +really convention.

Note: I'm not recommending people use epochs for when the +really
convention would suffice. In fact, I'm recommending against downgrading
at all, I think we should avoid those if even remotely possible. But
adding bureaucracy around epochs because people misuse them for things
that they weren't made for and *that are a bad idea to begin with* seems
like a pretty bad idea to me.

[...]
> BTW something I missed in my previous reply, the fact that it might
> (should! :) be considered a stigma is IMO a good thing, because it
> might make people think at least twice before introducing them. :)

Yes, there is that :)

[...]
> generally missunderstood. I realize that can obviously end up coming
> across as very condescending. :/

No worries, been there done that.

[...]
> > True, but sometimes being bug-compatible can be the right thing to do.
> 
> "can" perhaps, I don't think "right" is the word though. :)

Fair enough :)

[...]
> > I currently maintain two packages which have a non-zero epoch. I think
> > that in both cases the decision to bump the epoch was the right one.
> 
> In the two packages you mention, the bump looks entirely legitimate
> and for what epochs were intended to be used. For the pmw case I'd
> have probably tried to avoid it by talking with upstream so that
> they'd have switched to use 4.240 after 4.231 instead of using 4.24.

Honestly, I should have called it 4.23.1 rather than 4.231, which is
what upstream intended but which he couldn't encode due to
implementational details.

Ah well.

> The other one you have in your DDPO (python-webob), which you were not
> involved in, but serves as a nice example, is completely bogus, it was
> a release revert, followed by the next upload restoring the continuity.
> :(

Yeah, like you say, I wasn't involved. I really only did a single
sponsored upload of python-webob once, don't even remember the details
of it...

Anyway, I've said my thing, I think people know about it now. I don't
think we should make this a requirement in any form or shape (but would
be happy with a strong recommendation if needs be); if I'm alone with
that sentiment though, then that probably means the consensus disagrees
with me and I'll have to live with it.

So, EOT for me.

Regards,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#902545: sagemath: sage 8.2-4 fails to start with error /usr/bin/env: ‘sage-python23’: No such file or directory

[Gilles Crèvecœur]

Hi,

I have looked for a get around for this bug.
It seems due to some files in 
/usr/share/sagemath/bin
The command:
 grep sage-python23 /usr/share/sagemath/bin/*
yields:
/usr/share/sagemath/bin/sage-eval:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-fixdoctests:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-ipython:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-list-packages:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-preparse:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-run-cython:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-runtests:#!/usr/bin/env sage-python23
/usr/share/sagemath/bin/sage-startuptime.py:#!/usr/bin/env sage-python23

For the moment, I suggest to symlink
the file: 
sage-python23 to sage-python
in the directory /usr/share/sagemath/bin with commands:
cd /usr/share/sagemath/bin && ln -s sage-python sage-python23

It seems to work for me.

Cheers.
--
Gilles Crèvecœur

Bug#902544: linux-image-4.16.0-2-amd64: Kernel installation fails when /boot is FAT partition

[Ben Hutchings]

Control: severity -1 wishlist

On Wed, 2018-06-27 at 18:21 +0200, Josef Kufner wrote:
[...]
> Reason why it is unable to make the backup link is that my /boot is on EFI
> partition which is FAT:
[...]

This will occur if you upgrade *any* package that installs files on
/boot.  For that reason, Debian does not support /boot being on FAT or
similarly limited filesystems, and the conventional location for
mounting the EFI boot partition is /boot/efi.

(Certain Debian derivatives do support your configuration by not having
any packages that install files in /boot.)

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#902350: systemd-container: /proc/1/environ doesn't contain

[Ben Hutchings]

On Fri, 2018-06-29 at 06:16 +0900, Hideki Yamane wrote:
> Hi,
> 
> On Mon, 25 Jun 2018 16:55:40 +0200 Cyril Brulebois 
> wrote:
> > Please anchor the grep pattern to avoid accidental matches against
> > variables whose name ends with container (e.g. foo_container), and
> > values which start with lxc-libvirt (e.g. lxc-libvirt-something-else);
> > adding ^ on the left and $ on the right would do that.
> 
>  Thanks, indeed. And Ben suggested just use $container and it's
>  better.

It would be better than running 'env' to test a single variable value,
but it is still not right to assume that the container environment
variable is inherited.  In fact, I checked with 'systemd-nspawn -B' and
it was not inherited by a login shell.

As I commented on the merge request, reading /run/systemd/container (if
present) and then pid 1's environment seems like it will be the most
reliable approach.

Ben.

> 
> > It seems there are quite a number of other places with such issues.
> 
>  I'll look into it, later.
> 
> 
-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#902641: RFS: streamlink/0.14.0+dfsg-1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 0.14.0.

 * Package name: streamlink
   Version : 0.14.0+dfsg-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.14.0+dfsg-1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the last upload:
streamlink (0.14.0+dfsg-1) unstable; urgency=low

  * tests: fix shellcheck warnings
  * docs: move fonts-font-awesome and lib-modernizr to recommends
  * docs: revert to fonts-font-awesome v4
  * Check modernizr symlink in check_docs and refactor it
  * New upstream version 0.14.0+dfsg
  * Remove patches applied upstream: freezegun, missing test files,
escape sequences
  * Update patches

 -- Alexis Murzeau   Fri, 29 Jun 2018 00:16:46 +0200


Note: currently, the command4 autopkgtest test will fail on unstable
until fonts-font-awesome is reverted to v4 (merge requests to do this
are pending).
This is because fonts-font-awesome v5 has breaking changes including a
fonts rework.
See also: #899124.

Regards,
--
 Alexis Murzeau
 PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F






signature.asc
Description: OpenPGP digital signature

Bug#902640: magit: FTBFS if machine has no domain

[Santiago Vila]

Package: src:magit
Version: 2.13.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed.
BuIld log follows:


[...]
dpkg-buildpackage: info: source package magit
dpkg-buildpackage: info: source version 2.13.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Rémi Vanicat 
 dpkg-source --before-build magit-2.13.0
 fakeroot debian/rules clean
dh clean --with elpa
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/<>'
make[2]: Entering directory '/<>/lisp'
Cleaning lisp/*...
make[2]: Leaving directory '/<>/lisp'
make[2]: Entering directory '/<>/Documentation'
Cleaning Documentation/*...
make[2]: Leaving directory '/<>/Documentation'
Cleaning...
make[1]: Leaving directory '/<>'
   debian/rules override_dh_clean
make[1]: Entering directory '/<>'
dh_clean
make[1]: Leaving directory '/<>'
 debian/rules build-indep
dh build-indep --with elpa
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make info
make[2]: Entering directory '/<>'
make[3]: Entering directory '/<>/Documentation'
Generating magit.info
Generating dir
make[3]: Leaving directory '/<>/Documentation'
make[2]: Leaving directory '/<>'
do not run make
make[1]: Leaving directory '/<>'
   debian/rules override_dh_elpa_test
make[1]: Entering directory '/<>'
make test
make[2]: Entering directory '/<>'
Loading /<>/t/magit-tests.el (source)...
Cannot determine Magit’s version (error "/<>/lisp/magit.el" repo 
static elpa debug)
Running 16 tests (2018-06-22 15:45:52+)
   passed   1/16  magit--with-safe-default-directory
Keeping test directory:
  /tmp/magit-244342AY/
Test magit-get backtrace:
  (let ((dir (file-name-as-directory (make-temp-file "magit-" t))) (pr
  (lambda nil (let ((dir (file-name-as-directory (make-temp-file "magi
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test magit-get nil (lambda nil (let ((di
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test m
  ert-run-tests(t #[385 "\306\307\"\203G auto-detect email address (got 
'buildd@yoda2.(none)') (in /tmp/magit-24434EFx/remote/)")
   FAILED  15/16  magit-toplevel:submodule
   passed  16/16  magit-toplevel:tramp

Ran 16 tests, 11 results as expected, 5 unexpected (2018-06-22 15:45:54+)

5 unexpected results:
   FAILED  magit-get
   FAILED  magit-get-{current|next}-tag
   FAILED  magit-list-{|local-|remote-}branch-names
   FAILED  magit-status:log-sections
   FAILED  magit-toplevel:submodule

Makefile:105: recipe for target 'test' failed
make[2]: *** [test] Error 1
make[2]: Leaving directory '/<>'
debian/rules:22: recipe for target 'override_dh_elpa_test' failed
make[1]: *** [override_dh_elpa_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:12: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


There is an interesting line saying "unable to auto-detect email address"
where it may be seen that my machine has no domain. However, having a
domain has never been a requirement to build Debian packages. In fact,
one might ask: The fact that such test fails means the package will
not work in machines not having a domain?

To reproduce, please try "dpkg-buildpackage -A" on a machine not
having a domain.

Thanks.

Bug#902639: Use of uninitialized value $3 in concatenation (.) or string at /usr/share/perl5/vendor_perl/App/Licensecheck.pm

[Sandro Mani]

Package: licensecheck
Version: 3.0.36

As reported downstream at 
https://bugzilla.redhat.com/show_bug.cgi?id=1595880:


When running licensecheck on OpenJDK sources[1] I'm getting this:
Use of uninitialized value $3 in concatenation (.) or string at 
/usr/share/perl5/vendor_perl/App/Licensecheck.pm line 678, <$fh> line 61.


On that line I see:
$gen_license->( 'apache', $1, $2, "bsd_${3}_clause" );

Changing it to:
$gen_license->( 'apache', $1, $2, $3 ? "bsd_${3}_clause" : "" );

makes it work.

Steps to Reproduce:
1. $ licensecheck dynalink.operation.copyright.txt (see attachment)

Note: downstream bug is against 3.0.33, but also applies with 
licensecheck-3.0.36-1.fc29.noarch as packaged in Fedora Rawhide.


/*
 * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * This file is available under and governed by the GNU General Public
 * License version 2 only, as published by the Free Software Foundation.
 * However, the following notice accompanied the original version of this
 * file, and Oracle licenses the original version of this file under the BSD
 * license:
 */
/*
   Copyright 2015 Attila Szegedi

   Licensed under both the Apache License, Version 2.0 (the "Apache License")
   and the BSD License (the "BSD License"), with licensee being free to
   choose either of the two at their discretion.

   You may not use this file except in compliance with either the Apache
   License or the BSD License.

   If you choose to use this file in compliance with the Apache License, the
   following notice applies to you:

   You may obtain a copy of the Apache License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
   implied. See the License for the specific language governing
   permissions and limitations under the License.

   If you choose to use this file in compliance with the BSD License, the
   following notice applies to you:

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions are
   met:
   * Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
   * Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the distribution.
   * Neither the name of the copyright holder nor the names of
 contributors may be used to endorse or promote products derived from
 this software without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
   IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
   TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
   PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDER
   BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
   CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
   SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
   BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
   WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
   OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
   ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

Bug#902637: autoradio: FTBFS in buster/sid

[Santiago Vila]

Package: src:autoradio
Version: 2.8.10-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
dpkg-buildpackage: info: source package autoradio
dpkg-buildpackage: info: source version 2.8.10-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Andrea Capriotti 

 dpkg-source --before-build autoradio-2.8.10
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
dh_auto_clean
dh_auto_clean: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_clean: This feature will be removed in compat 12.
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py clean -a
django_extensions is not installed; I do not use it
Traceback (most recent call last):
  File "setup.py", line 16, in 
django.setup()
  File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in 
populate
app_config.import_models()
  File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 202, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/<>/autoradio/jingles/models.py", line 4, in 
from autoradio.autoradio_config import *
  File "/<>/autoradio/autoradio_config.py", line 75, in 
locale.setlocale(locale.LC_ALL, config['autoradiod']['locale'])
  File "/usr/lib/python2.7/locale.py", line 581, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
dh_auto_clean: python setup.py clean -a returned exit code 1
debian/rules:5: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 1
make[1]: Leaving directory '/<>'
debian/rules:3: recipe for target 'clean' failed
make: *** [clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2


The build was made with "dpkg-buildpackage -A" in my autobuilder
but it also fails in reproducible builds:

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

In this case the error is different: "ImportError: No module named magic".

If this is really a bug in one of the build-depends and you have to
use "reassign", please use "affects" as well, so that this is still
visible in the BTS page for this package.

Thanks.

Bug#902638: mwic: FTBFS in buster/sid (dh: unable to load addon python3)

[Santiago Vila]

Package: src:mwic
Version: 0.7.4-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
dpkg-buildpackage: info: source package mwic
dpkg-buildpackage: info: source version 0.7.4-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Georg Faerber 
 dpkg-source --before-build mwic-0.7.4
 debian/rules clean
dh clean --with=python3
dh: unable to load addon python3: Can't locate 
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 9) line 
1.
BEGIN failed--compilation aborted at (eval 9) line 1.

debian/rules:4: recipe for target 'clean' failed
make: *** [clean] Error 2
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2


The build was made with "dpkg-buildpackage -A" in my autobuilder
but it also fails in reproducible builds:

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

If this is really a bug in one of the build-depends and you have to
use "reassign", please use "affects" as well, so that this is still
visible in the BTS page for this package.

Thanks.

Bug#900856: enlightenment: Sound fails to work after upgrade

[Mike Brodbelt]

On 21/06/18 12:34, Felipe Sateler wrote:

Patches welcome. If you decide to implement this, make sure that the 
code is only active with a running sysvinit (ie, don't affect chroots).  
It is not trivial, which is why I didn't implement it myself. You 
probably need to integrate ucf to handle all the corner cases.


Patch attached. I haven't gone through all the steps of integrating ucf 
- the disable autospawn file isn't currently marked in the package as a 
conffile, so this patch, while it works in my limited testing, could 
still be improved on there.


LMK what you think - if you're happy with this approach and will 
integrate it, I can work on ucf integration as well.


Mike
--- /var/lib/dpkg/info/pulseaudio.postinst	2018-04-05 19:55:56.0 +0100
+++ pulseaudio.postinst	2018-06-28 23:01:17.801244088 +0100
@@ -16,6 +16,34 @@
 
 PULSEAUDIO=/usr/bin/pulseaudio
 
+check_sysvinit() {
+  # Get the major/minor numbers for the root device
+  local rdev=$(printf %04.0f $(stat -c %D /) | sed 's/../&:/')
+  # Get the default target triplet for the system
+  local arch=$(gcc -print-multiarch)
+  # Retrieve PID 1's mapped binaries from the root fs
+  local binmaps=`awk "/$rdev/ {print \\$6}" /proc/1/maps | grep -v $arch | uniq | xargs`
+
+  local status
+  status=$(dpkg -s sysvinit 2>/dev/null | grep ^Status: | sed -e 's/^Status: \(.*\) \(.*\) \(.*\)/\3/g')
+
+  # If the sysvinit package is installed, and it's binary is mapped as PID 1,
+  # then we can assume we are on a sysvinit system, and not simply in a chroot
+  # environment.
+  if  [ -n "$status" ] && [ "$status" == "installed" ]; then
+	  if  [ -n "$binmaps" ] && [ "$binmaps" == "/sbin/init" ]; then
+		  return 0
+	  fi
+  fi
+  return 1
+}
+
+config_autospawn() {
+	if check_sysvinit; then
+		rm -f /etc/pulse/client.conf.d/00-disable-autospawn.conf
+	fi
+}
+
 trigger_udev() {
 	if ! which udevadm >/dev/null 2>&1 ; then
 		return 0;
@@ -36,6 +64,7 @@
   addgroup --quiet --system pulse-access
 fi
 trigger_udev
+config_autospawn
   ;;
   abort-upgrade|abort-remove|abort-deconfigure)
   ;;

Bug#902636: linssid: Newer versions of linssid are available

[Arjan Opmeer]

Package: linssid
Version: 2.9-4
Severity: wishlist
Tags: upstream

Dear Maintainer,

Please consider packaging a newer version of linssid.

In the last month there has been a flurry of activity in the development of
linssid. At the moment of writing we are up to version 3.6 already. This
version of linssid uses polkit (policykit) to obtain root privileges and
(partly) fixes the problems mentioned in bug #858191.


Thanks,

Arjan

-- 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.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linssid depends on:
ii  iw4.14-0.1
ii  libboost-regex1.62.0  1.62.0+dfsg-5.1
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-9
ii  libqt5core5a  5.10.1+dfsg-7
ii  libqt5gui55.10.1+dfsg-7
ii  libqt5widgets55.10.1+dfsg-7
ii  libqwt-qt5-6  6.1.3-1
ii  libstdc++68.1.0-9
ii  wireless-tools30~pre9-12+b1

linssid recommends no packages.

linssid suggests no packages.

-- no debconf information

Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64

[John Paul Adrian Glaubitz]

Source: qtscript-opensource-src
Version: 5.10.1+dfsg-2
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

I just noticed there is an easy workaround to address the Javascript crashes on
sparc64 [1]. JavaScriptCore allows one to use a 32-bit JSValue - even on 64-bit
systems. In fact, this is done on PPC64 for some reason.

I have tried this for sparc64 as well and it seems that the Javascript engine
works correctly with that change.

Attaching a patch, please include in the next upload.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Use 32-bit JSValue on sparc64
 sparc64 has a very large virtual address space such that 64-bit tagged
 pointers can become corrupted. Workaround this problem by limiting
 JSValue to 32 bits.
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2018-06-28

--- 
qtscript-opensource-src-5.10.1+dfsg.orig/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
+++ 
qtscript-opensource-src-5.10.1+dfsg/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
@@ -960,9 +960,9 @@
 #endif
 
 #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && 
!defined(WTF_USE_JSVALUE32_64)
-#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || 
CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
+#if (CPU(X86_64) && !CPU(X32) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || 
OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || 
CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
 #define WTF_USE_JSVALUE64 1
-#elif CPU(ARM) || CPU(PPC64)
+#elif CPU(ARM) || CPU(PPC64) || CPU(SPARC64)
 #define WTF_USE_JSVALUE32 1
 #elif OS(WINDOWS) && COMPILER(MINGW)
 /* Using JSVALUE32_64 causes padding/alignement issues for JITStubArg

Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS

[Nicholas D Steeves]

On Fri, Jun 29, 2018 at 06:08:52AM +0900, Norbert Preining wrote:
> Hi Nicholas,
> 
> > I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git
> > 
> > If it's possible to fix the FTBR on i386 in sid, then that fix seems
> > like it ought to included into the proposed 0.4.4-2 upload.  Sadly I
> > don't know why it's occurring so can't fix it.
> 
> I am not sure what is the problem on i386, does the current 0.4.4-2 not
> build there?

It builds for i386, but fails to build reproducibly.  It might just be
a transient error.
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/html5-parser.html
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/html5-parser.html
  
However it currently FTBFS for arm64 (maybe transient error, or maybe
the cause is elsewhere):
  https://tests.reproducible-builds.org/debian/unstable/arm64/index_FTBFS.html

> Should I upload 0.4.4-2?

Upside: will allow the backport to build.

Downside: https://tracker.debian.org/pkg/html5-parser states "This
package is part of the ongoing testing transition known as
python3.7. Please avoid uploads unrelated to this transition, they
would likely delay it and require supplementary work from the release
managers."

Fixing the FTBFS on arm64 would definitely justify an upload, but I'm
not sure if my additions and updates are sufficient.  CCing the Python
Team to find out.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#900486: python-pydap: FTBFS and Debci failure with NumPy 1.14

[Graham Inggs]

Control: tags -1 + patch

The attached patch adjusts the test output for NumPy 1.14.

However, with this patch in place, python-pydap will need a
build-dependency on python-numpy (>= 1:1.14~) and its autopkgtests
will fail with NumPy 1.13.
Description: Fix FTBFS with NumPy 1.14
Bug-Debian: https://bugs.debian.org/900486
Author: Graham Inggs 
Last-Update: 2018-06-20

--- a/src/pydap/tests/test_responses_ascii.py
+++ b/src/pydap/tests/test_responses_ascii.py
@@ -48,7 +48,7 @@
 ('XDODS-Server', 'pydap/' + __version__),
 ('Content-description', 'dods_ascii'),
 ('Content-type', 'text/plain; charset=ascii'),
-('Content-Length', '440')]))
+('Content-Length', '436')]))
 
 def test_body(self):
 """Test the generated ASCII response."""
@@ -66,8 +66,8 @@
 } SimpleSequence;
 -
 cast.id, cast.lon, cast.lat, cast.depth, cast.time, cast.temperature, cast.salinity, cast.pressure
-"1", 100, -10, 0, -1, 21, 35, 0
-"2", 200, 10, 500, 1, 15, 35, 100
+1, 100, -10, 0, -1, 21, 35, 0
+2, 200, 10, 500, 1, 15, 35, 100
 
 """)
 
--- a/src/pydap/tests/test_wsgi_functions.py
+++ b/src/pydap/tests/test_wsgi_functions.py
@@ -45,8 +45,8 @@
  '-\n'
  'cast.id, cast.lon, cast.lat, cast.depth, cast.time, '
  'cast.temperature, cast.salinity, cast.pressure\n'
- '"1", 100, -10, 0, -1, 21, 35, 0\n'
- '"2", 200, 10, 500, 1, 15, 35, 100\n'
+ '1, 100, -10, 0, -1, 21, 35, 0\n'
+ '2, 200, 10, 500, 1, 15, 35, 100\n'
  '\n')
 
 def test_projection(self):
@@ -161,7 +161,7 @@
  '-\n'
  'cast.id, cast.lon, cast.lat, cast.depth, cast.time, '
  'cast.temperature, cast.salinity, cast.pressure\n'
- '"2", 200, 10, 500, 1, 15, 35, 100\n'
+ '2, 200, 10, 500, 1, 15, 35, 100\n'
  '\n')
 
 def test_subset_with_selection(self):
@@ -185,7 +185,7 @@
  '-\n'
  'cast.id, cast.lon, cast.lat, cast.depth, cast.time, '
  'cast.temperature, cast.salinity, cast.pressure\n'
- '"1", 100, -10, 0, -1, 21, 35, 0\n'
+ '1, 100, -10, 0, -1, 21, 35, 0\n'
  '\n')
 
 def test_projection(self):
@@ -224,7 +224,7 @@
  '-\n'
  'cast.id, cast.lon, cast.lat, cast.depth, cast.time, '
  'cast.temperature, cast.salinity, cast.pressure\n'
- '"1", 100, -10, 0, -1, 21, 35, 0\n'
+ '1, 100, -10, 0, -1, 21, 35, 0\n'
  '\n')
 
 def test_grads_step(self):
--- a/src/pydap/tests/test_wsgi_ssf.py
+++ b/src/pydap/tests/test_wsgi_ssf.py
@@ -68,7 +68,7 @@
 } SimpleSequence;
 -
 cast.id, cast.lon, cast.lat, cast.depth, cast.time, cast.temperature, cast.salinity, cast.pressure
-"2", 200, 10, 500, 1, 15, 35, 100
+2, 200, 10, 500, 1, 15, 35, 100
 
 """)
 

Bug#902633: RFA: php-elisp -- php mode for emacs

[Ola Lundqvist]

Package: php-elisp

I still use the package but I do not have the time to update to newer
releases.

So if anyone would like to help or even better take it over, please do so.

Send me an email so I know

/ Ola

Bug#902634: RFS: flashplugin-nonfree/1:3.7+nmu1 [NMU] [RC] -- Adobe Flash Player - browser plugin

[James Lu]

Package: sponsorship-requests
Severity: important
Control: block 851066 by -1
Control: block 889804 by -1

Dear mentors,

I'm looking for a sponsor for an NMU of flashplugin-nonfree, which fixes
some old bugs making the downloader unusable since at least January
2017[1]. The maintainer (Bart Martens) has not responded to that bug at
all, nor has anyone replied to the intent to NMU that I posted last week[2].

This upload includes a patch from Gianluigi Tiesi which removes all
references to Bart's people.debian.org page, which has not seen any
updates during his apparent absence. These include tarball checksum and
GPG verification checks via his site that are *removed* since Adobe
doesn't seem to provide them (instead, they rely on HTTPS).

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851066
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851066;msg=127

At the same time, I've also included changes to fix some trivial but
non-RC bugs[3][4].

[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862144
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885119

The source of the package is available at mentors[5] as well as Salsa[6]
- note that the current package in unstable never defined a Vcs, so I'm
only using the latter so far as tracking for these fixes.

[5]: https://mentors.debian.net/package/flashplugin-nonfree
[6]: https://salsa.debian.org/jlu-guest/flashplugin-nonfree/

A debdiff (as of writing) is attached, which should be equivalent to the
Salsa diff
https://salsa.debian.org/jlu-guest/flashplugin-nonfree/compare/f9cdfd78a...master

The RFS info:

 * Package name: flashplugin-nonfree
   Version : 1:3.7+nmu1
   Upstream Author : Bart Martens 
 * URL : http://wiki.debian.org/FlashPlayer
 * License : GPL-2
   Section : web

Full changelog:

flashplugin-nonfree (1:3.7+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Remove broken references to https://people.debian.org/~bartm/; patch
from
Gianluigi Tiesi (Closes: #851066, #889804, #884262)
- This removes checksum verification of the Flash tarballs and PGP
  validation of get-upstream-version.pl, which were previously
provided by
  that site.
- It also rewrites the upstream version parsing to fetch from Adobe
  directly.
- Remaining changes to this patch: don't use --no-check-certificate
  with wget
  * Add Recommends: libwebkit2gtk-4.0-37-gtk2. (Closes: #862144)
  * Remove remaining calls to gpg and the dependency on gnupg.
(Closes: #885119)

 -- James Lu   Fri, 22 Jun 2018 16:27:56 -0700

Best,
James
diff -Nru flashplugin-nonfree-3.7/debian/changelog 
flashplugin-nonfree-3.7+nmu1/debian/changelog
--- flashplugin-nonfree-3.7/debian/changelog2016-08-03 22:49:06.0 
-0700
+++ flashplugin-nonfree-3.7+nmu1/debian/changelog   2018-06-22 
16:27:56.0 -0700
@@ -1,3 +1,21 @@
+flashplugin-nonfree (1:3.7+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken references to https://people.debian.org/~bartm/; patch from
+Gianluigi Tiesi (Closes: #851066, #889804, #884262)
+- This removes checksum verification of the Flash tarballs and PGP
+  validation of get-upstream-version.pl, which were previously provided by
+  that site.
+- It also rewrites the upstream version parsing to fetch from Adobe
+  directly.
+- Remaining changes to this patch: don't use --no-check-certificate
+  with wget
+  * Add Recommends: libwebkit2gtk-4.0-37-gtk2. (Closes: #862144)
+  * Remove remaining calls to gpg and the dependency on gnupg.
+(Closes: #885119)
+
+ -- James Lu   Fri, 22 Jun 2018 16:27:56 -0700
+
 flashplugin-nonfree (1:3.7) unstable; urgency=medium
 
   * update-flashplugin-nonfree: Delete old cached get-upstream-version.pl.
diff -Nru flashplugin-nonfree-3.7/debian/control 
flashplugin-nonfree-3.7+nmu1/debian/control
--- flashplugin-nonfree-3.7/debian/control  2016-08-03 22:49:06.0 
-0700
+++ flashplugin-nonfree-3.7+nmu1/debian/control 2018-06-22 15:45:59.0 
-0700
@@ -8,7 +8,8 @@
 
 Package: flashplugin-nonfree
 Architecture: i386 amd64
-Depends: debconf | debconf-2.0, wget, gnupg | gnupg2, libatk1.0-0, libcairo2, 
libfontconfig1, libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0 (>= 2.14), 
libnspr4, libnss3, libpango1.0-0, libstdc++6, libx11-6, libxext6, libxt6, 
libcurl3-gnutls, binutils, ${misc:Depends}, ${shlibs:Depends}
+Depends: debconf | debconf-2.0, wget, libatk1.0-0, libcairo2, libfontconfig1, 
libfreetype6, libgcc1, libglib2.0-0, libgtk2.0-0 (>= 2.14), libnspr4, libnss3, 
libpango1.0-0, libstdc++6, libx11-6, libxext6, libxt6, libcurl3-gnutls, 
binutils, ${misc:Depends}, ${shlibs:Depends}
+Recommends: libwebkit2gtk-4.0-37-gtk2
 Pre-Depends: ca-certificates
 Suggests: iceweasel, firefox-esr, konqueror-nsplugins, 
ttf-mscorefonts-installer, fonts-dejavu, ttf-xfree86-nonfree, 
flashplugin-nonfree-extrasound [i386], hal-flash
 Conflicts: flashplugin (<< 6), 

Bug#902350: systemd-container: /proc/1/environ doesn't contain

[Hideki Yamane]

Hi,

On Mon, 25 Jun 2018 16:55:40 +0200 Cyril Brulebois  wrote:
> Please anchor the grep pattern to avoid accidental matches against
> variables whose name ends with container (e.g. foo_container), and
> values which start with lxc-libvirt (e.g. lxc-libvirt-something-else);
> adding ^ on the left and $ on the right would do that.

 Thanks, indeed. And Ben suggested just use $container and it's
 better.


> It seems there are quite a number of other places with such issues.

 I'll look into it, later.


-- 
Hideki Yamane 

Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS

[Norbert Preining]

Hi Nicholas,

> I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git
> 
> If it's possible to fix the FTBR on i386 in sid, then that fix seems
> like it ought to included into the proposed 0.4.4-2 upload.  Sadly I
> don't know why it's occurring so can't fix it.

I am not sure what is the problem on i386, does the current 0.4.4-2 not
build there?

Should I upload 0.4.4-2?

Best

Norbert

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

Bug#902611: kate: add build dependency for editorconfig support

[Martin Steigerwald]

Pino Toscano - 28.06.18, 21:57:
> In data giovedì 28 giugno 2018 14:19:26 CEST, Martin Steigerwald ha
> scritto:
> > Please add libeditorconfig-dev as a build dependency for Kate in
> > order to enable editorconfig support.
> 
> Kate has no editorconfig support, so there is no build dependency to
> add.
> ktexteditor has editorconfig support, and it is already enabled (see
> the dependencies of libkf5texteditor5).

Thank you. I missed that. Sorry for the noise.

Ciao,
-- 
Martin

Bug#553401: cleaning up unmaintained parts of emacs-goodies-el

[David Bremner]

Control: severity -1 normal
Control: retitle -1 drop sys-apropos.el

Since, as you say the functionality is there in the man command, and
sys-apropos has no upstream, I propose to just drop it from
emacs-goodies.

If someone disagrees and wants to adopt it upstream, please drop a note
on this bug.

Bug#814190: Ping

[Antoine Beaupré]

Control: found 814190 5.0.6+dfsg-1~bpo9+1

On 2018-06-28 16:22:07, Antoine Beaupré wrote:
> Control: fixed 814190 5.0.6+dfsg-1~bpo9+1

Scratch that: it started out well, but it ended up falling apart in the
end..

It *looks* like it mostly finished correctly, but failed to
unmount. Here's the output in the text area:

tails-amd64-3.8.iso sélectionné
Clearing unreadable partition table.
Partitionnement du périphérique /dev/sdc
Formatage de /dev/sdc1 en FAT32
Vérification du système de fichiers...
Extraction de l'image live vers le périphérique cible...
Écriture sur le périphérique effectuée à 1 Mo/sec
Lecture du MBR extrait depuis /usr/lib/syslinux/mbr/gptmbr.bin
Installation du chargeur de démarrage...
Synchronisation des données sur le disque...
Démontage des systèmes de fichiers sur '/dev/sdc1'
sync

['/sbin/sgdisk', '--print', '/dev/sdc']
Problem opening /dev/sdc for reading! Error is 13.
You must run this program as root or use sudo!

['/sbin/sgdisk', '--zap-all', '/dev/sdc']
Problem opening /dev/sdc for reading! Error is 13.
You must run this program as root or use sudo!
Problem opening '' for writing! Program will now terminate.
Warning! MBR not overwritten! Error is 2!

sync

sync

sync

sync

sync

sync

sync

/usr/bin/pkexec /usr/bin/syslinux  -d syslinux /dev/sdc1
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
Error executing command as another user: Not authorized

This incident has been reported.

Un problème est survenu lors de l'exécution de la commande suivante : 
`/usr/bin/pkexec /usr/bin/syslinux  -d syslinux /dev/sdc1`
Un journal d'erreurs plus détaillé a été écrit dans le fichier 
`/tmp/tails-installer-a8bqjE`.
L'installation de Tails a échoué !

And on the console:

$ tails-installer 
Could not guess underlying block device: Argument 1 does not allow None as a 
value

(tails-installer:16000): Gtk-WARNING **: Failed to measure available space: 
Erreur d'obtention des informations du système de fichiers pour 
/media/anarcat/d-live nf 9.4.0 ci amd64 : Aucun fichier ou dossier de ce type

(tails-installer:16000): Gtk-WARNING **: Failed to measure available space: 
Erreur d'obtention des informations du système de fichiers pour 
/media/anarcat/disk : Aucun fichier ou dossier de ce type

(tails-installer:16000): Gtk-WARNING **: Failed to measure available space: 
Erreur d'obtention des informations du système de fichiers pour 
/media/anarcat/disk : Aucun fichier ou dossier de ce type
 AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/syslinux' as the super user
Authenticating as: Antoine Beaupre,,, (anarcat)
Password: 
 AUTHENTICATION FAILED ===
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/dist-packages/tails_installer/gui.py", line 264, in 
run
self.live.log.exception(unicode(e))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal 
not in range(128)


I did enter my password at the prompt, but it failed to do the right
thing.

A.

-- 
Au nom de l'état, la force s'appelle droit.
Au main de l'individu, elle s'appelle crime.
- Max Stirner

Bug#900248: The proposed patch in nvidia conf fix DRI but many other problems remains

[Eric Valette]

On 6/28/18 7:16 PM, Jiri Palecek wrote:

Are you using xserver 1.20 from unstable or 1.19.6 from testing? I've 
had similar problems when I updated, and they went away when I 
downgraded xserver-xorg-core.


1.20 from unstable.

-- eric

Bug#902624: Please support running in parallel

[Josh Triplett]

On Thu, Jun 28, 2018 at 07:55:39PM +0100, Chris Lamb wrote:
> forcemerge 842837 902624
> thanks
> 
> Hi Josh,
> 
> > I'm running diffoscope on a system with plenty of memory and CPUs;
> > diffoscope benefits from the memory, but not the CPUs. Could diffoscope
> > do comparisons in parallel?
> 
> Indeed; whilst there is already:
> 
>   https://bugs.debian.org/842837
> 
> … there has actually been quite a bit of work done on this in various
> branches. Alas, none merged into master yet. :)

Ah, I didn't find that bug when I searched open bugs; sorry for the
duplicate.

Bug#814190: Ping

[Antoine Beaupré]

Control: fixed 814190 5.0.6+dfsg-1~bpo9+1

On 2018-06-28 07:55:00, u wrote:
> Hi Antoine,
>
> in order to eventually close this bug sometime, could you reply to
> intrigeri's last question?
>
> Thanks & cheers!

Hi,

So this was a while ago. I'm on a different machine now and all my
machines are running stretch.

I tried to reproduce this with an up to date backport. I am now running
under "i3" instead of "awesome WM" but I am still not using a "proper
desktop environment" (e.g. GNOME or KDE). Here is the output of the
command as requested:

[998]anarcat@curie:~127$ pkexec whoami
 AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/whoami' as the super user
Authenticating as: Antoine Beaupre,,, (anarcat)
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.

Obviously, there's something wrong with polkit, even if it's installed
and polkit.service is running.

That said, tails-installer itself *works* now in stretch and in my
configuration. So presumably this bug can be closed in buster and so
on... I have done so from the backports version.

Cheers!

-- 
The value of a college education is not the learning of many facts but
the training of the mind to think.
   - Albert Einstein

Bug#899998: nvidia-legacy-340xx-kernel-dkms: Dmesg output: "Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'nvidia_stack_t'"

[Uoti Urpala]

On Thu, 24 May 2018 09:14:34 -0500 Phil Miller  wrote:
> At present, this doesn't hurt functionality of a default configuration system,
> but it would prevent someone using the nvidia driver from enabling the 
> kernel's
> usercopy protections. In future kernel releases where those protections are
> enabled by default, this bug will become more serious.

Kernel package version 4.16.16-1 has this:
* hardening: enable FORTIFY_SOURCE, disable HARDENED_USERCOPY_FALLBACK

I think this means that the driver is broken with the current kernel in
unstable. Booting with the kernel commandline parameter
"slab_common.usercopy_fallback=Y" may work around the problem?

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

[Sébastien Villemot]

On Fri, Jun 29, 2018 at 03:04:56AM +0800, Drew Parsons wrote:
> On Thu, 28 Jun 2018 20:57:52 +0200 =?iso-8859-1?Q?S=E9bastien?=
> Villemot  wrote:
> > > 
> > > The patch is trivial. Replace all  with  config.h>.
> > > 
> > > config.h was already deprecated, and is now removed in octave
> 4.4.0.
> > 
> > Yes, but then you get many numerical test failures, which are not
> trivial at
> > all to fix…
> > 
> 
> Does 
> https://bitbucket.org/odepkg/odepkg/commits/d4f56c4f3678f7f55d8dc84c96fbd0f98f8d4191
> help?
> 
> Perhaps with 
> https://bitbucket.org/odepkg/odepkg/commits/d60b477d520c762ba4093e1a8f7a036d50b80db1
> 
> 
> Or does latest the upstream git work, should we just grab that?

I remember having tried to apply some upstream patches, but maybe not the
second one that you linked to. In any case, someone has to try again.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#902624: Please support running in parallel

[Chris Lamb]

Dear Josh,

> Ah, I didn't find that bug when I searched open bugs; sorry for the
> duplicate.

Not at all; I consider it a friendly "+1" for this feature! :-)


Regards,

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

Bug#902627: Please create temporary files in a subdirectory

[Chris Lamb]

tags 902627 + pending
thanks

Good idea. Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/6e6afd3f63c963cbed9af6b7d3201769442c2727

  diffoscope/tempfiles.py | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)


Regards,

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

Bug#902625: libmath-gsl-perl: needs a versioned dependency on libgsl23 (>= 2.5) or so

[gregor herrmann]

On Thu, 28 Jun 2018 21:17:31 +0300, Niko Tyni wrote:

> This package uses symbols from libgsl23 >= 2.5, but that isn't
> reflected in the package dependencies because of #902623 (libgsl23
> missing shlibs information). Once that bug is fixed, libmath-gsl-perl
> needs a rebuild so that the package dependencies get updated. A binNMU
> should be enough but we might as well make a sourceful one and declare
> a build dependency on fixed gsl versions.

Fixed in git (locally), waiting for gsl 2.5+dfsg-4 to hit the
mirrors.
 
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: Tom Waits: Innocent When You Dream


signature.asc
Description: Digital Signature

Bug#902626: Stretch kvm accelerated qemu-system-i386 on i386 archirecture enters infinite loop at startup

[Michael Tokarev]

28.06.2018 21:19, Bernard wrote:
> Package: qemu-system-x86
> Version: 1:2.8+dfsg-6+deb9u4
> Severity: important
> 
> I am on i386 architecture with a CodeDuo processor.
[]
> I tried the 4.16 kernel from stretch-backport, and the behaviour was
> the same: ok without acceleration, black screen with -enable-kvm.
> 
> Workaround: my CPU is actually amd64 capable; I have a partition where
> amd64 Strech is installed for tests, and surprise there the VMs are
> running fine and are kvm accelerated with qemu-system-i386. So I ended
> up crossgrading the kernel to amd64 (explains the "amd64" in the
> system information section below) on my main brand new Stretch i386
> system, and now the VMs are working ok and are accelerated.
> 
> So the problem seems kvm.ko and kvm_intel.ko related, but to me it
> seemed more logical to raise the bug through the package triggering
> the bug.

No, the problem is most likely due to qemu, not kvm modules, but that's
not really interesting.

The fact is that we aren't testing any 32bit host mode at all. In the past
it often failed to _compile_, now there's an automatic compile farm that
constantly tries to compile things and alarms when it doesn't work. But
no one tries to run the binaries on 32bit host. I used to do that in the
past but that time was long gone.

I can say even more: upstream is seriously thinking about dropping 32bit
host support completely, not only on x86 but on other architectures too,
because supporting 32bit mode, especially to run 64bit guests, is not
easy at all.  So don't be surprized if one day it wont work at all,
by definition (not by incident like now)

I for one don't have any 32bit system here to test it on. My main system
is 64bits and it runs all the software I use every day, in order to
install 32bit system I'll have to move partitions around to find an
empty space and reboot to another system. I don't have other computers
over here. Maybe it will work in a chroot, I dunno, but there, it is
always a pain to work with anyway.

But even if I'll able to see what you see, I've very little confidence
in whenever it will be fixable. These bugs are definitely of a very low
priority for upstream, and especially not interesting for old versions
(current qemu version is 2.12, next is 3.0).

Also, think how many people are running stretch now, but you're the first
to notice this issue.

So, in short, please don't hold your breath waiting till this will be fixed.
Instead, try to switch to 64bit, -- that will be the real fix.

Thanks,

/mjt

Bug#898075: I'll confirm this occurs for me as well

[Daniel Lakeland]

My particular CD doesn't ask me for multiple entries, it just detects 
the CD's identity correctly, and then segfaults without any input from me.

Bug#639221: replace folding.el with elpa-folding

[Nicholas D Steeves]

It looks like there is a precedent on debian-legal for rejecting
uploads due to "All rights reserved" when GPL is simultaneously
declared.

Issue forwarded here:
https://github.com/jaalto/project-emacs--folding-mode/issues/4


signature.asc
Description: PGP signature

Bug#902631: devscripts: CI fails in unstable due to Python 3.7

[Lev Lazinskiy]

Package: devscripts
Version: 2.18.3
Severity: normal

Dear Maintainer,

The current CI process fails in unstable[1]. It appears to be due to Python
3.7 being released in the last few days[2].

The issue is:


: generator raised StopIteration


It can be reproduced by running:

python3.7 -m flake8 --max-line-length=99
debdiff-apply reproducible-check sadt suspicious-source wrap-and-sort
devscripts setup.py

in unstable.


This appears to be an intentional regression that is caused by python
3.7 enforcing PEP 479 [3].


[1] https://salsa.debian.org/levlaz-guest/devscripts/-/jobs/28131
[2] https://www.python.org/downloads/release/python-370/
[3] https://www.python.org/dev/peps/pep-0479/

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc"
DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID="7F826F1C"

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

Kernel: Linux 4.9.87-linuxkit-aufs (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-3
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-6
ii  python3   3.6.5-3
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.6.2
ii  at  3.1.20-6
ii  curl7.60.0-2
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.06.24
ii  dput1.0.2
ii  equivs  2.1.0
ii  fakeroot1.22-2
ii  file1:5.33-3
ii  gnupg   2.2.8-3
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.34-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.91
ii  man-db  2.8.3-2
ii  patch   2.7.6-2
ii  patchutils  0.3.4-2
ii  python3-apt 1.6.1
ii  python3-debian  0.1.32
ii  python3-magic   2:0.4.15-1
ii  python3-requests2.18.4-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
ii  gpgv 2.2.8-3
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.4-1+b1
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.7p1-2
pn  piuparts 
pn  postgresql-client
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

-- 
Lev Lazinskiy
e: l...@levlaz.org
w: https://levlaz.org/about-me/

Bug#386417: folding.el corrupts files when using utf8

[Nicholas D Steeves]

Control: block 639221 by -1

Hi Jeremy and Jari,

On Mon, Sep 11, 2006 at 07:40:09AM -0400, Jeremy Hankins wrote:
> jari.aa...@cante.net writes:
> 
> > Thanks for the report. I tested with the latest code under Ubuntu 6.06
> > using:
> >
> >   $ LANG=en_US.UTF-8 emacs -q --no-site-file -name folding -fn fixed \
> >   -l folding.el -f folding-mode folding.el
> 
> I downloaded folding.el from your v3.35 link and got the same behavior
> that you did.  But when I tried it on my gnus init file I got the ctrl-M
> stuff.  I've attached a test file with a snippet from my gnus init file
> that triggers the problem for me.  From what I can tell, it's not enough
> to set LANG (maybe it was at one time, or maybe my memory is playing
> tricks), but utf8 chars will trigger it.  A less of the saved file will
> show the '^M' in reverse video in the folded sections.
> 

Sorry for the delay following up on this bug.  The Debian Emacsen team
has only recently adopted emacs-goodies-el.  At the moment we're
planning to package folding-mode from: 
https://github.com/jaalto/project-emacs--folding-mode

Jeremy, if possible, would you please confirm if this issue is present
in folding mode from Jari Aalto's github project?  If so, then we
ought to open an issue there.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#902630: libtinfo6: tiparm("") returns NULL

[Jakub Wilk]

Package: libtinfo6
Version: 6.1+20180210-4

I'm not sure what are the exact circumstances, but tiparm("") sometimes 
returns NULL instead of empty string:


  $ make test-tiparm LDLIBS=-ltinfo
  cc test-tiparm.c  -ltinfo -o test-tiparm

  $ ./test-tiparm
  tiparm("") = NULL
  tiparm("foo") = "foo"
  tiparm("") = ""


-- System Information:
Architecture: i386

Versions of packages libtinfo6 depends on:
ii  libc6  2.27-3

--
Jakub Wilk
#include 

#include 

void test_tiparm(const char *s)
{
	const char *t = tiparm(s);
	printf("tiparm(\"%s\") = ", s);
	if (t)
		printf("\"%s\"", t);
	else
		printf("NULL");
	printf("\n");
}

int main(int argc, char **argv)
{
	setupterm(NULL, 1, NULL);
	test_tiparm("");
	test_tiparm("foo");
	test_tiparm("");
	return 0;
}

Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]

[Nicholas D Steeves]

Hi Chris,

On Thu, Jun 28, 2018 at 07:47:19PM +0100, Chris Lamb wrote:
> Nicholas,
> 
> > It seems like ${python:Depends} is taking care of pulling in
> > bin:python-lxml_4.2.1-1~bpo9+1 for
> > bin:python-html5-parser_0.4.4-1~bpo9+1, so there's no rush to upload
> > an html5-parser_0.4.4-2, no?
> 
> It FTBFS if you don't have 3.8.0 installed as the testsuite fails so
> won't it fail on the builds?

P.S. feel free to block this RFS bug by #902629 if appropriate

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

[Drew Parsons]

On Thu, 28 Jun 2018 20:57:52 +0200 =?iso-8859-1?Q?S=E9bastien?=
Villemot  wrote:
> > 
> > The patch is trivial. Replace all  with .
> > 
> > config.h was already deprecated, and is now removed in octave
4.4.0.
> 
> Yes, but then you get many numerical test failures, which are not
trivial at
> all to fix…
> 

Does 
https://bitbucket.org/odepkg/odepkg/commits/d4f56c4f3678f7f55d8dc84c96fbd0f98f8d4191
help?

Perhaps with 
https://bitbucket.org/odepkg/odepkg/commits/d60b477d520c762ba4093e1a8f7a036d50b80db1


Or does latest the upstream git work, should we just grab that?

Drew

Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS

[Nicholas D Steeves]

Package: html5-parser
Version: 0.4.4-1
Severity: normal

Continuing from Bug#889854: RFS: lxml/4.2.1-1~bpo9+1

Hi Chris,

On Thu, Jun 28, 2018 at 07:47:19PM +0100, Chris Lamb wrote:
> Nicholas,
> 
> > It seems like ${python:Depends} is taking care of pulling in
> > bin:python-lxml_4.2.1-1~bpo9+1 for
> > bin:python-html5-parser_0.4.4-1~bpo9+1, so there's no rush to upload
> > an html5-parser_0.4.4-2, no?
> 
> It FTBFS if you don't have 3.8.0 installed as the testsuite fails so
> won't it fail on the builds?

Oh, that's good point.  Consequently I'm filing this bug.

Hi Norbert,

I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git

If it's possible to fix the FTBR on i386 in sid, then that fix seems
like it ought to included into the proposed 0.4.4-2 upload.  Sadly I
don't know why it's occurring so can't fix it.

Sincerely,
Nicholas

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

[Sébastien Villemot]

On Fri, Jun 29, 2018 at 02:50:36AM +0800, Drew Parsons wrote:
> On Sat, 23 Jun 2018 12:54:19 +0300 Adrian Bunk  wrote:
> > ...
> > odepkg_octsolver_mebdfdae.cc:42:10: fatal error: config.h: No such
> file or directory
> >  #include 
> >   ^~
> 
> 
> The patch is trivial. Replace all  with .
> 
> config.h was already deprecated, and is now removed in octave 4.4.0.

Yes, but then you get many numerical test failures, which are not trivial at
all to fix…

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#902628: curl: segfaults with http2 on libcurl 7.60.0

[Graham Inggs]

Source: curl
Version: 7.60.0-1
Severity: normal
Control: affects -1 src:r-cran-curl
Forwarded: https://github.com/curl/curl/issues/2674
User: debian...@lists.debian.org
Usertags: breaks

Hi Maintainer

The issue below, detected by autopkgtests, appears to be related to a
known bug in curl.

Regards
Graham


On 20 May 2018 at 20:11, Paul Gevers  wrote:
> Dear maintainers,
>
> [This e-mail is automatically sent. V3.2 (20180518)]
>
> tl;dr: curl/7.60.0-1 appears to break r-cran-curl/3.2-1 autopkgtest in testing
> see: https://ci.debian.net/packages/r/r-cran-curl/testing/amd64/
> and https://qa.debian.org/excuses.php?package=curl
>
> As recently announced [1] Debian is now running autopkgtests in testing
> to check if the migration of a new source package causes regressions. It
> does this with the binary packages of the new version of the source
> package from unstable.
>
> With a recent upload of curl the autopkgtest of r-cran-curl
> started to fail in testing [2]. This is currently delaying the migration
> of curl version 7.60.0-1 [3].
>
> This e-mail is meant to trigger prompt direct communication between the
> maintainers of the involved packages as one party has insight in what
> changed and the other party insight in what is being tested. Please
> therefore get in touch with each other with your ideas about what the
> causes of the problem might be, proposed patches, etc. A regression in a
> reverse dependency can be due to one of the following reasons (of course
> not complete):
> * new bug in the candidate package (fix the package)
> * bug in the test case that only gets triggered due to the update (fix
>   the reverse dependency, but see below)
> * out-of-date reference date in the test case that captures a former bug
>   in the candidate package (fix the reverse dependency, but see below)
> * deprecation of functionality that is used in the reverse dependency
>   and/or its test case (discussion needed)
> * regression due to other packages from unstable that are installed to
>   fulfill (versioned) Depends (contact maintainers of those).
> Triaging tips are being collected on the Debian Wiki [4].
>
> Unfortunately sometimes a regression is only intermittent. Ideally this
> should be fixed, but it may be OK to just have the autopkgtest retried
> (a link is available in the excuses [3]).
>
> There are cases where it is required to have multiple packages migrate
> together to have the test cases pass, e.g. when there was a bug in a
> regressing test case of a reverse dependency and that got fixed. In that
> case the test cases need to be triggered with both packages from
> unstable (reply to this e-mail and/or contact the ci-team [5]) or just
> wait until the aging time is over (if the fixed reverse dependency
> migrates before that time, the failed test can be retriggered [3]).
>
> Of course no system is perfect. In case a framework issue is suspected,
> don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to
> me is also fine for initial cross-check).
>
> To avoid stepping on peoples toes, this e-mail does not automatically
> generate a bug in the BTS, but it is highly recommended to forward this
> e-mail there (psuedo-header boilerplate below [6,7]) in case it is
> clear which package should solve this regression.
>
> It can be appropriate to file an RC bug against the depended-on package,
> if the regression amounts to an RC bug in the depending package, and to
> keep it open while the matter is investigated. That will prevent
> migration of an RC regression.
>
> If the maintainers of the depending package don't have available effort
> to fix a problem, it is appropriate for the maintainers of the
> depended-on package to consider an NMU of the depending package. Any
> such an NMU should take place in accordance with the normal NMU rules.
>
> Neither of the above steps should be seen as hostile; they are part of
> trying to work together to keep Debian in tip-top shape.
>
> If you find that you are not able to agree between you about the right
> next steps, bug severities, etc., please try to find a neutral third
> party to help you mediate and/or provide a third opinion. Failing that
> your best bet is probably to post to debian-devel.
>
> [1] https://lists.debian.org/debian-devel-announce/2018/05/msg1.html
> [2] https://ci.debian.net/packages/r/r-cran-curl/testing/amd64/
> [3] https://qa.debian.org/excuses.php?package=curl
> [4] https://wiki.debian.org/ContinuousIntegration/TriagingTips
> [5] #debci on oftc or debian...@lists.debian.org
> [6] curl has an issue
> 
> Source: curl
> Version: 7.60.0-1
> Severity: normal or higher
> Control: affects -1 src:r-cran-curl
> User: debian...@lists.debian.org
> Usertags: breaks
> 
> [7] r-cran-curl has an issue
> 
> Source: r-cran-curl
> Version: 3.2-1
> Severity: normal or higher
> Control: affects -1 src:curl
> User: debian...@lists.debian.org
> Usertags: needs-update
> 

Bug#902624: Please support running in parallel

[Chris Lamb]

forcemerge 842837 902624
thanks

Hi Josh,

> I'm running diffoscope on a system with plenty of memory and CPUs;
> diffoscope benefits from the memory, but not the CPUs. Could diffoscope
> do comparisons in parallel?

Indeed; whilst there is already:

  https://bugs.debian.org/842837

… there has actually been quite a bit of work done on this in various
branches. Alas, none merged into master yet. :)


Regards,

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

Bug#902198: octave-odepkg FTBFS with octave 4.4.0

[Drew Parsons]

On Sat, 23 Jun 2018 12:54:19 +0300 Adrian Bunk  wrote:
> ...
> odepkg_octsolver_mebdfdae.cc:42:10: fatal error: config.h: No such
file or directory
>  #include 
>   ^~


The patch is trivial. Replace all  with .

config.h was already deprecated, and is now removed in octave 4.4.0.

Drew

Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]

[Chris Lamb]

Nicholas,

> It seems like ${python:Depends} is taking care of pulling in
> bin:python-lxml_4.2.1-1~bpo9+1 for
> bin:python-html5-parser_0.4.4-1~bpo9+1, so there's no rush to upload
> an html5-parser_0.4.4-2, no?

It FTBFS if you don't have 3.8.0 installed as the testsuite fails so
won't it fail on the builds?


Regards,

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

Bug#902622: I am also affected by this issue

[Jan Janský]

I am also affected by this bug since 61beta releases installed from
Debian repositories.

The problem is with system dictionaries as well as with those installed
as addons.  When activating spell checking the following error is
printed to the console (here trying to use czech dictionary, but it is
equivalent with all others):

System dictionaries:

error: file:///usr/lib/firefox/dictionaries/cs_CZ.aff: cannot open
error: file:///usr/lib/firefox/dictionaries/cs_CZ.dic: cannot open
error: file:///usr/lib/firefox/dictionaries/cs_CZ.aff: cannot open

Dictionaries installed as an addon (profile directory substituted):

error:
file:///home/mister/.mozilla/firefox/[profileID]/extensions/cs@dictiona
ries.addons.mozilla.org/dictionaries/cs.aff: cannot open
error:
file:///home/mister/.mozilla/firefox/[profileID]/extensions/cs@dictiona
ries.addons.mozilla.org/dictionaries/cs.dic: cannot open
error:
file:///home/mister/.mozilla/firefox/[profileID]/extensions/cs@dictiona
ries.addons.mozilla.org/dictionaries/cs.aff: cannot open

There is an upstream bug report here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1469740

Regards,
Jan Janský

Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]

[Nicholas D Steeves]

On Thu, Jun 28, 2018 at 06:18:35PM +0100, Chris Lamb wrote:
> Nicholas,
> 
> > > Okay, I've re-uploaded lxml_4.2.1-1~bpo9+1_amd64.changes. Did
> > > html5-parser make it though yesterday? Let me know if not.
> > 
> > If https://ftp-master.debian.org/backports-new.html is up-to-date,
> > then no, it didn't.
> 
> Rebuilt and uploaded html5-parser_0.4.4-1~bpo9+1_amd64.changes.

Thank you :-)

> You might want to make the following change to the Builds-Depends:
> 
>   - python3-lxml
>   + python3-lxml (>= 3.8.0),

I agree.  Fixed in unreleased 0.4.4-2 at
g...@salsa.debian.org:debian/html5-parser.git

It seems like ${python:Depends} is taking care of pulling in
bin:python-lxml_4.2.1-1~bpo9+1 for
bin:python-html5-parser_0.4.4-1~bpo9+1, so there's no rush to upload
an html5-parser_0.4.4-2, no?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#902618: why: autopkgtest failure has no output

[Ralf Treinen]

Hi,

On Thu, Jun 28, 2018 at 03:13:30PM +0200, Paul Gevers wrote:

> The why source package has an autopkgtest, great. However, with upload
> of why3 version 1.0.0-1 the autopkgtest of why started to fail, delaying
> the migration of why3 to testing by 13 days. I tried to figure out what
> the issue is, but the test suite doesn't log anything at all, making it
> difficult to judge.
> 
> Could you please improve the autopkgtest to produce debugging output?
> Preferably always, but in any case during failure?
> 
> As you are also the maintainer of why3, please figure out where this
> regression should be fixed.

this is a bug of why which needs to be ported to upstream to produce
the new syntaxe of the WhyML language that was introduced with why3
version 1.0.0.

-Ralf.

Bug#902623: libgsl23: missing shlibs information for 2.5 symbols

[Dirk Eddelbuettel]

On 28 June 2018 at 21:05, Niko Tyni wrote:
| Package: libgsl23
| Version: 2.5+dfsg-3
| Severity: serious
| 
| The 2.5 versions of this package introduced new symbols, but that isn't
| reflected in the shlibs file. It looks like this is caused by a simple
| typo: debian/libgsl23.shlib should be named debian/libgsl23.shlibs .
| So its contents aren't currently reflected in the binary package.

Nice catch!

Building -4 in a moment.

Dirk

| (This is showing up in the autopkgtest checks of the new libmath-gsl-perl
|  package, which was built in sid against the new libgsl23 versions but
|  didn't gain a corresponding versioned dependency, so it's installable
|  but broken with the old libgsl23 in testing.)
| -- 
| Niko Tyni   nt...@debian.org

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

Bug#902618: why: autopkgtest failure has no output

[Paul Gevers]

Hi,

On 28-06-18 20:26, Ralf Treinen wrote:
> this is a bug of why which needs to be ported to upstream to produce
> the new syntaxe of the WhyML language that was introduced with why3
> version 1.0.0.

Is this an issue for why, or only for its autopkgtest? In the former,
please raise a migration blocking bug against why3 until why is fixed.
In both cases, may I suggest to add a versioned Breaks in why3 if why
can be fixed before why3 migrates?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#902627: Please create temporary files in a subdirectory

[Josh Triplett]

Package: diffoscope
Version: 96
Severity: normal

diffoscope creates thousands of files directly in /tmp (or $TMPDIR); to
reduce the noise, please consider creating a single top-level temporary
directory and putting all the temporary files in there. (This would also
avoid the need to repeatedly generate non-conflicting names on the
filesystem.)

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

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

Versions of packages diffoscope depends on:
ii  libpython3.6-stdlib3.6.6~rc1-4
ii  python33.6.5-3
ii  python3-distro 1.0.1-2
ii  python3-distutils  3.6.6-1
ii  python3-libarchive-c   2.1-3.1
ii  python3-magic  2:0.4.15-1
ii  python3-pkg-resources  39.2.0-1

Versions of packages diffoscope recommends:
pn  abootimg   
ii  acl2.2.52-3+b1
pn  apktool
pn  binutils-multiarch 
ii  bzip2  1.0.6-8.1
pn  caca-utils 
pn  colord 
pn  db-util
pn  default-jdk-headless | default-jdk | java-sdk  
ii  device-tree-compiler   1.4.6-1
pn  docx2txt   
ii  e2fsprogs  1.44.2-1
pn  enjarify   
pn  fontforge-extras   
pn  fp-utils   
pn  genisoimage
ii  gettext0.19.8.1-6+b1
ii  ghc8.2.2-4
pn  ghostscript
pn  giflib-tools   
pn  gnumeric   
pn  imagemagick
pn  jsbeautifier   
pn  libarchive-tools   
pn  llvm   
pn  mono-utils 
pn  odt2txt
pn  oggvideotools  
ii  openssh-client 1:7.7p1-2
pn  pgpdump
ii  poppler-utils  0.63.0-2
pn  procyon-decompiler 
pn  python3-argcomplete
pn  python3-binwalk
ii  python3-debian 0.1.32
pn  python3-defusedxml 
pn  python3-guestfs
pn  python3-jsondiff   
pn  python3-progressbar
pn  python3-pyxattr
pn  python3-tlsh   
pn  r-base-core
pn  sng
pn  sqlite3
pn  squashfs-tools 
ii  tcpdump4.9.2-3
ii  unzip  6.0-21
ii  vim-common 2:8.1.0089-1
pn  xmlutils   
ii  xxd2:8.1.0089-1
ii  xz-utils   5.2.2-1.3

Versions of packages diffoscope suggests:
ii  libjs-jquery  3.2.1-1

-- no debconf information

Bug#902626: Stretch kvm accelerated qemu-system-i386 on i386 archirecture enters infinite loop at startup

[Bernard]

Package: qemu-system-x86
Version: 1:2.8+dfsg-6+deb9u4
Severity: important

I am on i386 architecture with a CodeDuo processor.

# cat /proc/cpuinfo
rocessor: 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz
stepping: 6
microcode   : 0xd0
cpu MHz : 1596.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm kaiser tpr_shadow dtherm
bugs: cpu_meltdown spectre_v1 spectre_v2
bogomips: 4270.08
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU  6400  @ 2.13GHz
stepping: 6
microcode   : 0xd0
cpu MHz : 1596.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm kaiser tpr_shadow dtherm
bugs: cpu_meltdown spectre_v1 spectre_v2
bogomips: 4270.08
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

I upgraded recently a Jessie system to Stretch. The old Jessie ran
flawlessly a few kvm accelerated qemu VMs (command
qemu-system-i386). The Debian upgrade went fine, except that now the
kvm accelerated qemu are stalled even before any Seabios message: the
screen is completely black, and I have 100% CPU for the qemu process.

In the qemu console I can verify that kvm is indeed activated (command
"info kvm" returns "kvm support: enabled").

Modules kvm.ko and kvm_intel.ko are loaded fine:

# lsmod|grep kvm
kvm_intel 192512  0
kvm   593920  1 kvm_intel
irqbypass  16384  1 kvm

# ls -alt /dev/kvm
crw-rw+ 1 root kvm 10, 232 juin  27 23:17 /dev/kvm

But the sames VM without -enable-kvm work ok. Of course it's not
usable as it's extremely slow.

I tried the 4.16 kernel from stretch-backport, and the behaviour was
the same: ok without acceleration, black screen with -enable-kvm.

Workaround: my CPU is actually amd64 capable; I have a partition where
amd64 Strech is installed for tests, and surprise there the VMs are
running fine and are kvm accelerated with qemu-system-i386. So I ended
up crossgrading the kernel to amd64 (explains the "amd64" in the
system information section below) on my main brand new Stretch i386
system, and now the VMs are working ok and are accelerated.

So the problem seems kvm.ko and kvm_intel.ko related, but to me it
seemed more logical to raise the bug through the package triggering
the bug.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20161027.b991c67-1
ii  libaio1 0.3.110-3
ii  libasound2  1.1.3-5
ii  libbluetooth3   5.43-2+deb9u1
ii  libbrlapi0.65.4-7
ii  libc6   2.24-11+deb9u3
ii  libcacard0  1:2.5.0-3
ii  libfdt1 1.4.2-1
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libglib2.0-02.50.3-2
ii  libgnutls30 3.5.8-5+deb9u3
ii  libjpeg62-turbo 1:1.5.1-2
ii  libncursesw56.0+20161126-1+deb9u2
ii  libnettle6  3.3-1+b2
ii  libnuma12.0.11-2.1
ii  libpixman-1-0   0.34.0-1
ii  libpng16-16 1.6.28-1
ii  libpulse0   10.0-1+deb9u1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libsdl1.2debian 1.2.15+dfsg1-4
ii  libseccomp2 2.3.1-2.1
ii  libspice-server10.12.8-2.1+deb9u1
ii  libtinfo5   6.0+20161126-1+deb9u2
ii  libusb-1.0-02:1.0.21-1
ii  libusbredirparser1  0.7.1-1
ii  libvdeplug2 2.3.2+r586-2.1
ii  

Bug#902625: libmath-gsl-perl: needs a versioned dependency on libgsl23 (>= 2.5) or so

[Niko Tyni]

Package: libmath-gsl-perl
Version: 0.39-2
Severity: serious
Control: block -1 with 902623
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package uses symbols from libgsl23 >= 2.5, but that isn't
reflected in the package dependencies because of #902623 (libgsl23
missing shlibs information). Once that bug is fixed, libmath-gsl-perl
needs a rebuild so that the package dependencies get updated. A binNMU
should be enough but we might as well make a sourceful one and declare
a build dependency on fixed gsl versions.

(This was noticed by the awesome ci.debian.net autopkgtest migration
 checks, which highlighted that the package is installable but broken
 with the libgsl23 version currently in testing.)

 https://ci.debian.net/packages/libm/libmath-gsl-perl/testing/amd64/
-- 
Niko Tyni   nt...@debian.org

Bug#894245: [Pkg-salt-team] Bug#894245: Bug#894245: Salt, Tornado Incompatibility, and ZMQ Timeline

[Benjamin Drung]

Am Donnerstag, den 28.06.2018, 18:59 +0300 schrieb Vincas Dargis:
> On Thu, 28 Jun 2018 09:42:41 +0200 Benjamin Drung 
>  wrote:
> > Am Samstag, den 16.06.2018, 22:02 +0300 schrieb Vincas Dargis:
> > > 2017.7.6 is released now [0], could this fix the issue?
> > > 
> > > [0] https://docs.saltstack.com/en/latest/topics/releases/2017.7.6.
> > > html
> > 
> > Sadly no, since we use Python 3 and this combination still does not
> > work: https://github.com/saltstack/salt-jenkins/issues/995
> 
> Oh well.
> 
> I guess I should switch my salt-master to some Stretch VM then.
> 
> Does this kind of "hard breakage" occurs frequently on Sid with Salt
> (I 
> use Sid for less than a year)?

It's the first time since I'm involved.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.

Bug#902624: Please support running in parallel

[Josh Triplett]

Package: diffoscope
Version: 96
Severity: wishlist

I'm running diffoscope on a system with plenty of memory and CPUs;
diffoscope benefits from the memory, but not the CPUs. Could diffoscope
do comparisons in parallel?

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

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

Versions of packages diffoscope depends on:
ii  libpython3.6-stdlib3.6.6~rc1-4
ii  python33.6.5-3
ii  python3-distro 1.0.1-2
ii  python3-distutils  3.6.6-1
ii  python3-libarchive-c   2.1-3.1
ii  python3-magic  2:0.4.15-1
ii  python3-pkg-resources  39.2.0-1

Versions of packages diffoscope recommends:
pn  abootimg   
ii  acl2.2.52-3+b1
pn  apktool
pn  binutils-multiarch 
ii  bzip2  1.0.6-8.1
pn  caca-utils 
pn  colord 
pn  db-util
pn  default-jdk-headless | default-jdk | java-sdk  
ii  device-tree-compiler   1.4.6-1
pn  docx2txt   
ii  e2fsprogs  1.44.2-1
pn  enjarify   
pn  fontforge-extras   
pn  fp-utils   
pn  genisoimage
ii  gettext0.19.8.1-6+b1
ii  ghc8.2.2-4
pn  ghostscript
pn  giflib-tools   
pn  gnumeric   
pn  imagemagick
pn  jsbeautifier   
pn  libarchive-tools   
pn  llvm   
pn  mono-utils 
pn  odt2txt
pn  oggvideotools  
ii  openssh-client 1:7.7p1-2
pn  pgpdump
ii  poppler-utils  0.63.0-2
pn  procyon-decompiler 
pn  python3-argcomplete
pn  python3-binwalk
ii  python3-debian 0.1.32
pn  python3-defusedxml 
pn  python3-guestfs
pn  python3-jsondiff   
pn  python3-progressbar
pn  python3-pyxattr
pn  python3-tlsh   
pn  r-base-core
pn  sng
pn  sqlite3
pn  squashfs-tools 
ii  tcpdump4.9.2-3
ii  unzip  6.0-21
ii  vim-common 2:8.1.0089-1
pn  xmlutils   
ii  xxd2:8.1.0089-1
ii  xz-utils   5.2.2-1.3

Versions of packages diffoscope suggests:
ii  libjs-jquery  3.2.1-1

-- no debconf information

Bug#902623: libgsl23: missing shlibs information for 2.5 symbols

[Niko Tyni]

Package: libgsl23
Version: 2.5+dfsg-3
Severity: serious

The 2.5 versions of this package introduced new symbols, but that isn't
reflected in the shlibs file. It looks like this is caused by a simple
typo: debian/libgsl23.shlib should be named debian/libgsl23.shlibs .
So its contents aren't currently reflected in the binary package.

(This is showing up in the autopkgtest checks of the new libmath-gsl-perl
 package, which was built in sid against the new libgsl23 versions but
 didn't gain a corresponding versioned dependency, so it's installable
 but broken with the old libgsl23 in testing.)
-- 
Niko Tyni   nt...@debian.org

Bug#902621: kitty: please render and ship HTML versions of asciidoc

[James McCoy]

Control: forcemerge 897003 -1

On Thu, Jun 28, 2018 at 05:53:43PM +0100, Chris Lamb wrote:
> Please render and ship HTML versions of the asciidoc
> documentation. :)

That's been done and is why kitty is currently in NEW. *cough* Upstream
has fixed the Lenna issue, so once there's a new release, I'll upload
again.

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

Bug#842081: gnucash: Incorrect autocomplete after entering two characters

[Kenyon Ralph]

Package: gnucash
Version: 1:2.6.15-1
Followup-For: Bug #842081

This bug still exists and is EXTREMELY annoying. Strangely, it only
happens on one of my two Debian machines. Not sure how to figure out
what causes the difference.

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

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

Versions of packages gnucash depends on:
ii  gnucash-common 1:2.6.15-1
ii  guile-2.0  2.0.13+1-4
ii  guile-2.0-libs 2.0.13+1-4
ii  libaqbanking35 5.6.12-1+b1
ii  libaqbanking35-plugins 5.6.12-1+b1
ii  libc6  2.24-11+deb9u3
ii  libcairo2  1.14.8-1
ii  libcrypt-ssleay-perl   0.73.04-2
ii  libdate-manip-perl 6.57-1
ii  libdbi10.9.0-4+deb9u1
ii  libfinance-quote-perl  1.38-1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2
ii  libgnome-keyring0  3.12.0-1+b2
ii  libgnomecanvas2-0  2.30.3-3
ii  libgoffice-0.8-8   0.8.17-7
ii  libgtk2.0-02.24.31-2
ii  libgwengui-gtk2-0  4.15.3-5+b1
ii  libgwenhywfar604.15.3-5+b1
ii  libhtml-tableextract-perl  2.13-1
ii  libhtml-tree-perl  5.03-2
ii  libktoblzcheck1v5  1.48-2.1+b1
ii  libofx61:0.9.10-2+deb9u1
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpython2.7   2.7.13-2+deb9u2
ii  libwebkitgtk-1.0-0 2.4.11-3
ii  libwww-perl6.15-1
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  libxslt1.1 1.1.29-2.1
ii  perl   5.24.1-3+deb9u4
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnucash recommends:
ii  dbus1.10.26-0+deb9u1
ii  dbus-x111.10.26-0+deb9u1
pn  gnucash-docs
pn  python-gnucash  
ii  yelp3.22.0-1

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
pn  libdbd-sqlite3  

-- no debconf information

-- 
Kenyon Ralph


signature.asc
Description: PGP signature

Bug#902622: s

[Josh Triplett]

Package: firefox
Version: 61.0-1
Severity: normal

Since upgrading to 61.0-1, Firefox highlights every single word in every
textbox as misspelled, as though missing its dictionary of words.

-- Package-specific info:


-- Addons package information

-- 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.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-3
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.8-3
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.1.0-9
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-1
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.1-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.1.0-9
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-1
ii  libxcb1   1.13-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
ii  libgtk2.0-02.24.32-2

-- no debconf information

Bug#902598: siproxd: Sends replies to wrong address

[Paul Chitescu]

Hello!

Are you sure it's a bug?

The SIP standard states that the reply should be sent to the topmost Via
address, in this case:

  Via: SIP/2.0/UDP 213.95.149.23:5060;branch=z9hG4bK45607d54

Some applications and in particular VoLTE require that the Via address
to be honored.
Of course that breaks NAT traversal - but the SIP standard was written
well before that became common.

Some additional info: http://babel.de/art20080317a.html

Paul Chitescu


On 06/28/2018 12:00 PM, Matthias Urlichs via Pkg-voip-maintainers wrote:
> Package: siproxd
> Version: 1:0.8.1-4.1
> Severity: important
>
> siproxy sends SIP registration replies to the wrong address.
>
> Specifically, this hostname couldn't be resolved, thus the REGISTER is
> rejected:
>
> [pid 10545] recvfrom(4, "REGISTER sip:pbx1 SIP/2.0\r\nVia: SIP/2.0/UDP 
> 213.95.149.23:5060;branch=z9hG4bK45607d54\r\nMax-Forwards: 70\r\nFrom: 
> ;tag=as323b8169\r\nTo: 
> \r\nCall-ID: 
> 14f44c1b7facb9c843d3b30d046503a1@127.0.1.1\r\nCSeq: 152 
> REGISTER\r\nSupported: replaces, timer\r\nUser-Agent: 
> Smurf-O-Asterisk\r\nExpires: 120\r\nContact: 
> \r\nContent-Length: 0\r\n\r\n", 8195, 0, 
> {sa_family=AF_INET, sin_port=htons(5060), 
> sin_addr=inet_addr("10.107.8.134")}, [16]) = 408
> [pid 10545] sendto(4, "SIP/2.0 408 Request Timeout\r\nVia: SIP/2.0/UDP 
> 213.95.149.23:5060;branch=z9hG4bK45607d54\r\nFrom: 
> ;tag=as323b8169\r\nTo: 
> \r\nCall-ID: 
> 14f44c1b7facb9c843d3b30d046503a1@127.0.1.1\r\nCSeq: 152 
> REGISTER\r\nContent-Length: 0\r\n\r\n", 280, 0, {sa_family=AF_INET, 
> sin_port=htons(5060), sin_addr=inet_addr("213.95.149.23")}, 16) = 280
>
> SIP states that INVITEs et al. shall go to the address named in
> the Contact: header. This however is not an INVITE but a reply to
> a registration attempt. It needs to be sent to the host+port which
> transmitted the original request.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable'), (550, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.13.0-1-amd64 (SMP w/1 CPU core)
> 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/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages siproxd depends on:
> ii  adduser  3.117
> ii  libc62.27-3
> ii  libltdl7 2.4.6-2.1
> pn  libosip2-11  
>
> siproxd recommends no packages.
>
> siproxd suggests no packages.

Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]

[Chris Lamb]

Nicholas,

> > Okay, I've re-uploaded lxml_4.2.1-1~bpo9+1_amd64.changes. Did
> > html5-parser make it though yesterday? Let me know if not.
> 
> If https://ftp-master.debian.org/backports-new.html is up-to-date,
> then no, it didn't.

Rebuilt and uploaded html5-parser_0.4.4-1~bpo9+1_amd64.changes.

You might want to make the following change to the Builds-Depends:

  - python3-lxml
  + python3-lxml (>= 3.8.0),

> https://mentors.debian.net/debian/pool/main/l/lxml/lxml_4.2.1-1~bpo9+1.dsc

This did make it according to backports-new.html.


Regards,

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

Bug#900248: The proposed patch in nvidia conf fix DRI but many other problems remains

[Jiri Palecek]

Hi,

On 6/28/18 12:54 PM, Eric Valette wrote:



Just a quick note to say that indeed the proposed patch to look for 
DRI modules at the right place is working. However, I have a bunch of 
other problems since driver update even with the fix in place:


  * Sddm does not start. I get only a black screen with the mouse
pointer. I have should check but I think I have a backtrace that
points to qtRenderGlthread that is crashing in systemd-nss lib,
  * using lightdm and using plasma I'm able to get back to my kde
environment however the kde setup takes ages to start (and I have
no more the DRI message in Xorg.0.log),
  * The lock screen also takes ages to start, black screen for 30s or
so with keyboar input or mous move not working,
  * Launching Kodi, takes 40s but is fluid afterwards
  * Checked both glxinfo, vdpau info : all normal,


Are you using xserver 1.20 from unstable or 1.19.6 from testing? I've 
had similar problems when I updated, and they went away when I 
downgraded xserver-xorg-core.


Regards

   Jiri Palecek

Bug#828218: Software::License Debian patches will be removed

[Dominique Dumont]

On Sun, 20 May 2018 20:41:18 +0200 Dominique Dumont  wrote:
> Here's the first stab:
> 
> http://search.cpan.org/~ddumont/Software-LicenseMoreUtils-0.001/

Debian package is available:
https://tracker.debian.org/pkg/libsoftware-licensemoreutils-perl

Next version of libsoftware-license-perl will warn when Debian specific 
features are used.

These Debian specific features will be removed from unstable once Buster is 
out.

All the best

Bug#900746: xen toolstack xl causes a Segmentation fault on create domu

[Hans van Kranenburg]

Hi,

On 06/28/2018 09:58 AM, Damian Pietras wrote:
> I've also hit it on one of my boxes with
> 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8
> 
> This is related to too small stack size set for threads in XEN utils
> which explicitly set it to use 16KB. Similar issue is reported here for
> NTP: https://bugzilla.redhat.com/show_bug.cgi?id=1564527
> 
> I've recompilled the package with the attached patch to increase the
> stack size from 16KB to 32KB and it works.

Thanks for doing "bug triaging"!

> Technical details:
> 
> The issue appears with modern CPU that support AVX-512 instruction set,
> in my case it's Intel(R) Xeon(R) Gold 6148. More details are in this
> bug report against glibc: https://bugzilla.redhat.com/show_bug.cgi?id=1
> 527887#c18
> 
> There was a post on xen-users acknowledging the bug that says it's
> fixed in XEN 4.11: https://lists.xenproject.org/archives/html/xen-users
> /2018-05/msg00034.html

Following that post and what happened afterwards leads me to upstream
commit 448c03b3cb "tools/xenstore: try to get minimum thread stack size
for watch thread", which seems to solve this problem without hardcoding
some size.

Maybe this should be a nice candidate for upstream backport to stable
branches, since users are buying newer hardware and otherwise cannot use
Debian Stable without recompiling their Xen packages?

Ian?

Thanks,
Hans

Bug#889854: RFS: lxml/4.2.1-1~bpo9+1 [intent to maintain bpo]

[Nicholas D Steeves]

Hi Chris,

On Thu, Jun 28, 2018 at 09:22:17AM +0100, Chris Lamb wrote:
> Nicholas,
> 
> Okay, I've re-uploaded lxml_4.2.1-1~bpo9+1_amd64.changes. Did
> html5-parser make it though yesterday? Let me know if not.

If https://ftp-master.debian.org/backports-new.html is up-to-date,
then no, it didn't.  Let's say that was my fault, because I didn't
notice the orig tarballs didn't match what was already in the archive.
Here are the updated dscs I uploaded yesterday.  By the way, calibre
uses pristine-tar so its bpo didn't have this issue.

  
https://mentors.debian.net/debian/pool/main/h/html5-parser/html5-parser_0.4.4-1~bpo9+1.dsc
  https://mentors.debian.net/debian/pool/main/l/lxml/lxml_4.2.1-1~bpo9+1.dsc

> > >   The following packages will be REMOVED:
> > > calibre-build-deps
> […]
> > This issue sounds like "Using backported debhelper considered tricky"
> > ( https://lists.debian.org/debian-backports/2018/06/msg00037.html ).
> 
> Ew. Okay, "fixed" and uploaded calibre_3.26.0+dfsg-1~bpo9+1_amd64.changes.

Thanks!  Sébastien Villemot also just took care of this issue in the
debhelper bpo:
  
https://salsa.debian.org/debian/debhelper/commit/1bc4ca340f8f3e2d5b188e5bb811be02360132e5


Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#902621: kitty: please render and ship HTML versions of asciidoc

[Chris Lamb]

Package: kitty
Version: 0.9.0-1
Severity: wishlist

Hi,

Please render and ship HTML versions of the asciidoc
documentation. :)


Best wishes,

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

Bug#901789: mesa: white screen when running Xfwm4 with compositing

[Margot Berg]

On Tue, 2018-06-19 at 20:30 +0200, Yves-Alexis Perez wrote:
>
> I've uploaded xfwm4 4.13.0-2 which disables GL support through libepoxy (and
> mesa), so the problems is workarounded, but it'd be nice if mesa could be
> fixed.
>

 

Hello Yves-Alexis,

 

many thanks for your hint with disable GL.

I've compile xfwm4 without that, and now is it ok.

 

regards

MB

Bug#714572: emacs-goodies-el: csv-mode customize-mode

[Nicholas D Steeves]

Control: tags -1 + moreinfo
Hi Kevin,

On Thu, Jun 28, 2018 at 04:39:50PM +1000, Kevin Ryde wrote:
> Nicholas D Steeves  writes:
> >
> > This bug will be closed with the next upload of emacs-goodies-el.  If
> > the issue you reported still exists, please file a new bug against the
> > package elpa-csv-mode.
> 
> The bug still exists for me in csv-mode 1.7.  If that's the one you're
> about to split out, and if you haven't patched, then don't close but
> reassign when ready please.

Thank you for the quick follow-up!  Ok, keeping this bug open.  Please
share what Debian release this bug now applies to, and what version of
emacs.  If you'd like to test the new package, purge emacs-goodies-el
(all released versions contain a patch in a custom "convenience"
customisation group for csv-mode) and remove the csv-mode-1.7 that is
currently installed, then install the following package:

https://drive.google.com/open?id=1_Px3qfnoI9ISSckhI31wVPIZ1MArsfVE

which was built from:
  https://salsa.debian.org/emacsen-team/csv-mode.git

After purging emacs-goodies-el, which purges goodies' group
customisation in emacs-goodies-custom.el, and installing the new
elpa-csv-mode, the following occurs on my stretch system with
emacs-25.1.1:

start emacs
M-x csv-mode
M-x customize-mode
M-x CSV;; no candidates for completion
M-x csv;; csv-field-index-mode [Sole completion]

If I understand correctly, this bug exists because the "*Customize
Group: Csv*" aka the "Csv group:" that is discoverable by going into
customization, searching for csv, and finally selecting "CsvMajor mode
for editing files of comma-separated value type" ought to be reachable
via M-x customize-mode, M-x csv ?

Pending confirmation, I plan to forward this bug upstream, but if
you'd rather have it fixed right now please consider submitting a
patch against csv-mode/1.7; I'll apply it without delay and forward
your patch upstream instead :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#902620: certbot.service should not use root privileges

[Roland Tapken]

Package: certbot
Version: 0.10.2-1
Severity: serious
Tags: security
Justification: 5.b

Dear Maintainer,

certbot.service is configured to be executed with root privileges.
This leads to a potential attack vector while renewing certificates,
especially when using the 'standalone' authenticator.

For most setups it should be sufficient to run 'certbot --renew' as
an unprivileged user 'certbot'. This would require the following changes in the
default setup:

- /etc/letsencrypt and /var/letsencrypt must be owned and writable by
  'certbot'

- for standalone authenticator, the default port has to be changed to an
  unprivileged one (e.g. 8080).

- for webroot authenticator, a seperate directory for the acme challenge
  owned and writable by 'certbot' must be created (e.g.
  /etc/letsencrypt/acme-challenge) and an Apache rewrite rule must
  redirect requests to this directory:

  RewriteRule ^/(\.well-known/acme-challenge/.*)$ \
  /etc/letsencrypt/acme-challenge$1 [L]
  
  AllowOverride none
  Require all granted
  

  For nginx, a similar configuration would be required.

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

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

Versions of packages certbot depends on:
ii  init-system-helpers  1.48
ii  python   2.7.13-2
ii  python-certbot   0.10.2-1

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-apache  
pn  python-certbot-doc 

-- no debconf information

Bug#902619: coturn: Systemd configuration

[Jörg Sommer]

Package: coturn
Version: 4.5.0.5-1+b1
Severity: normal

Hi,

I've created a configuration for Systemd to replace the autogenerated
one. Maybe you would like to include this in the package. Systemd doesn't
need the `TURNSERVER_ENABLED`, because it supports enabling/disabling
services itself.

I've used the file at
https://github.com/coturn/coturn/blob/master/rpm/turnserver.service.fc as
template.

[Unit]
Description=coturn
Documentation=man:coturn(1) man:turnadmin(1) man:turnserver(1)
After=network.target

[Service]
User=turnserver
Group=turnserver
# if you use SSL
#SupplementaryGroups=ssl-cert
Type=simple
PIDFile=/run/turnserver.pid
ExecStart=/usr/bin/turnserver -c /etc/turnserver.conf --pidfile /dev/null 
--log-file stdout
Restart=on-abort

LimitNOFILE=99
LimitNPROC=6
LimitRTPRIO=infinity
LimitRTTIME=700
CPUSchedulingPolicy=other
UMask=0007

[Install]
WantedBy=multi-user.target

Regards Jörg

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

Versions of packages coturn depends on:
ii  adduser  3.117
ii  libc62.27-3
pn  libevent-core-2.1-6  
pn  libevent-extra-2.1-6 
pn  libevent-openssl-2.1-6   
pn  libevent-pthreads-2.1-6  
pn  libhiredis0.13   
pn  libmariadbclient18   
ii  libpq5   10.4-2
ii  libsqlite3-0 3.24.0-1
ii  libssl1.11.1.0h-4
ii  lsb-base 9.20170808
ii  telnet [telnet-client]   0.17-41

coturn recommends no packages.

Versions of packages coturn suggests:
pn  sip-router   
pn  xmpp-server  


signature.asc
Description: PGP signature

Bug#894245: [Pkg-salt-team] Bug#894245: Salt, Tornado Incompatibility, and ZMQ Timeline

[Vincas Dargis]

On Thu, 28 Jun 2018 09:42:41 +0200 Benjamin Drung 
 wrote:

Am Samstag, den 16.06.2018, 22:02 +0300 schrieb Vincas Dargis:
> 2017.7.6 is released now [0], could this fix the issue?
> 
> [0] https://docs.saltstack.com/en/latest/topics/releases/2017.7.6.html


Sadly no, since we use Python 3 and this combination still does not
work: https://github.com/saltstack/salt-jenkins/issues/995


Oh well.

I guess I should switch my salt-master to some Stretch VM then.

Does this kind of "hard breakage" occurs frequently on Sid with Salt (I 
use Sid for less than a year)?

Bug#901023: vlc: Hadware decoding does not work with 3.0.2

[Vincas Dargis]

On Mon, 11 Jun 2018 20:20:18 +0300 =?ISO-8859-1?Q?R=E9mi?= 
Denis-Courmont  wrote:
You either have to use libav, or a more recent FFmpeg, or manually turn off 
threaded decoding in VLC preferences.


Whatn FFmpeg version I should build VLC with for threading to work, can 
I simply grab the latest 4.x?


Could it be that bug #898428 could be avoided with latest FFmpeg?

Thanks!

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898428

Bug#590994: show-wspace.el is obsolete

[David Bremner]

user debian-em...@lists.debian.org
usertag -1 elpafy
retitle -1 drop show-wspace.el, maybe replace elpa-highlight-chars
severity -1 normal
quit

According to upstream

  https://www.emacswiki.org/emacs/show-wspace.el

is obsolete and replaced by

   https://www.emacswiki.org/emacs/highlight-chars.el

Since there's probably no smooth transition possible, one option is to
just drop show-wspace.el and reassign this bug to wnpp as an RFP.  TBH
I'm a bit skeptical of packages primarily hosted in emacswiki, but if
someone (else) wants to take responsibility for it, fine.

Bug#902618: why: autopkgtest failure has no output

[Paul Gevers]

Source: why
Version: 2.40-3
User: debian...@lists.debian.org
Usertags: issue

Dear OCaml maintainers,

The why source package has an autopkgtest, great. However, with upload
of why3 version 1.0.0-1 the autopkgtest of why started to fail, delaying
the migration of why3 to testing by 13 days. I tried to figure out what
the issue is, but the test suite doesn't log anything at all, making it
difficult to judge.

Could you please improve the autopkgtest to produce debugging output?
Preferably always, but in any case during failure?

As you are also the maintainer of why3, please figure out where this
regression should be fixed.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/w/why/523013/log.gz

autopkgtest [03:18:46]: test frama-c+jessie+alt-ergo:
[---
autopkgtest [03:18:47]: test frama-c+jessie+alt-ergo:
---]

autopkgtest [03:18:49]: test krakatoa+alt-ergo: [---
autopkgtest [03:18:50]: test krakatoa+alt-ergo: ---]



signature.asc
Description: OpenPGP digital signature

Bug#902617: gnome-maps: Can not move map

[Onno Leerink]

Package: gnome-maps
Version: 3.28.2-1
Severity: important
Tags: patch

Dear Maintainer,

Since installing Debian buster it is not possible to move the map using the
mouse in gnome-maps. Before this, moving the map was no problem.

I found the following temporary solution in Redhat bug 1560481, start gnome-
maps with:

allow_rgb10_configs=false gnome-maps

This causes to gnome-maps to function normally again.

This same solution also solves a bug concerning Totem not playing videos
anymore.

I have a amd graphics card.



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  geoclue-2.0  2.4.7-1
ii  gir1.2-champlain-0.120.12.16-2
ii  gir1.2-clutter-1.0   1.26.2+dfsg-4
ii  gir1.2-cogl-1.0  1.22.2-3
ii  gir1.2-gdkpixbuf-2.0 2.36.11-2
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-geocodeglib-1.0   3.25.4.1-4
ii  gir1.2-gfbgraph-0.2  0.2.3-2
ii  gir1.2-glib-2.0  1.56.1-1
ii  gir1.2-goa-1.0   3.28.0-1
ii  gir1.2-gtk-3.0   3.22.29-3
ii  gir1.2-gtkchamplain-0.12 0.12.16-2
ii  gir1.2-gtkclutter-1.01.8.4-3
ii  gir1.2-gweather-3.0  3.28.1-1
ii  gir1.2-rest-0.7  0.8.0-2
ii  gir1.2-secret-1  0.18.6-1
ii  gir1.2-soup-2.4  2.62.1-1
ii  gir1.2-webkit2-4.0   2.20.3-1
ii  gjs  1.52.3-2
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libchamplain-0.12-0  0.12.16-2
ii  libclutter-1.0-0 1.26.2+dfsg-4
ii  libcogl-pango20  1.22.2-3
ii  libcogl-path20   1.22.2-3
ii  libcogl201.22.2-3
ii  libdrm2  2.4.92-1
ii  libegl1  1.0.0+git20180308-3
ii  libfolks25   0.11.4-1+b2
ii  libfribidi0  0.19.7-2
ii  libgbm1  18.1.2-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgee-0.8-2 0.20.1-1
ii  libgeocode-glib0 3.25.4.1-4
ii  libglib2.0-0 2.56.1-2
ii  libglib2.0-bin   2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  librest-0.7-00.8.0-2
ii  libsoup2.4-1 2.62.1-1
ii  libwayland-client0   1.15.0-2
ii  libwayland-cursor0   1.15.0-2
ii  libwayland-egl1  1.15.0-2
ii  libwayland-server0   1.15.0-2
ii  libx11-6 2:1.6.5-1
ii  libxcomposite1   1:0.4.4-2
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxkbcommon00.8.0-2
ii  libxml2  2.9.4+dfsg1-7
ii  libxrandr2   2:1.5.1-1

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#893649: xvt: should this package be removed?

[Boyuan Yang]

X-Debbugs-CC: s...@debian.org

On Tue, 20 Mar 2018 22:36:31 +0100 Adam Borowski  wrote:
> Package: xvt
> Version: 2.1-20.3
> Severity: serious
> Justification: QA query
> 
> Hi!
> I believe that xvt is no longer suitable for inclusion in Debian, and thus
> propose its removal.  Not only has it been dead upstream since times
> immemorial but also it lacks features so basic it's mind-boggling.
> 
> For example, I believed that Windows 3.11's TELNET.EXE was the last terminal
> in existence that lacked color support.  Turns out, here we ship xvt, in
> 2018.  Or, no UTF-8 support is probably worth a RC bug on its own.
> 
> More than two decades ago, xvt was superseded by its fork rxvt, which in
> turn spawned a multitude of forks on its own.  I for one remember using a
> bunch of them on IRIX, when the world was still young...  Those forks have
> then died out around the beginning of this millenium, of them only
> rxvt-unicode is still struggling along.
> 
> As this package is still nominally maintained (well, your last upload was in
> 2006...), I can't file a RoQA immediately.  Thus, please tell me whether it
> should be removed.  If not, please close this bug, otherwise I'll ask for
> removal before Buster freeze.

Hi Sam,

I noticed that the maintainer field still points to your old email (non 
@debian.org one). I'm forwarding this mail to your @debian.org mail address 
again to eusure mail delivery.

I personally second the idea of requesting package removal for xvt. If you 
agree with that, it would be better for us to do it earlier than later.

--
Regards,
Boyuan Yang

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

Bug#902616: /usr/share/man/man5/deb-changes.5.gz: deb-changes(5): typo s/Change-by/Changed-by/

[Uwe Kleine-König]

Package: dpkg-dev
Version: 1.19.0.5
Severity: minor
File: /usr/share/man/man5/deb-changes.5.gz

Hello,

the BUGS section reads: "The Change-By and Maintainer fields have
confusing names." There is no "Change-By" field, it must read
"Changed-By".

Best regards
Uwe

Bug#902615: krb5-auth-dialog: Krb5-auth-dialog does not open up by clicking on the tray icon on KDE 5.28

[Alfred Egger]

Package: krb5-auth-dialog
Version: 3.20.0-2+b1
Severity: important

Krb5-auth-dialog does not open up when clicking the taskbar icon on KDE
5.28 on Debian 9 Stretch. Right clicking also doesn't open up any
context menu of the app. The app does work though and the
re-authentication window appears before the ticket expires.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AT.UTF-8, LC_CTYPE=en_AT.UTF-8 (charmap=locale: Cannot
set LC_CTYPE to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages krb5-auth-dialog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libc62.24-11+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libkrb5-31.15-1+deb9u1
ii  libnm-glib4  1.6.2-3
ii  libnotify4   0.7.7-2
ii  libpam0g 1.1.8-3.6

krb5-auth-dialog recommends no packages.

krb5-auth-dialog suggests no packages.

-- debconf information excluded

Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump

[Guillem Jover]

On Thu, 2018-06-28 at 14:34:06 +0200, Wouter Verhelst wrote:
> On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote:
> > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote:
> > > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> > > > The requirement to consult d-d has worked very well with Pre-Depends.
> > > > Many pointless and harmful Pre-Depends have been avoided this way,
> > > > with very low levels of project-wide effort.
> > > 
> > > Yes. There's a difference though.
> > 
> > Sure, but not in their harmfulness, though. :)
> 
> That's just a matter of opinion.

I don't think it is though. I'd even say bogus epochs bumps are
potentially more harmful than Pre-Depends! Pre-Depends are localized
in a single package, and their effects can be easily tested, but the
validity of the rationale for its introduction might be difficult or
impossible to check automatically, though. But the full effects of
epoch bumps are not easily testable at all and they are changes with
global effect, for all rdepends (in-archive and local), local forks,
etc.

From the categorization I did in the dpkg FAQ, there are two main
scenarios:

  * valid bumps due to version schema change, where even though the
version-space gets reset, the releases have continuity.
  * invalid bumps, either because they are completely unnecessary, or
because the releases break the continuity.

When breaking the release continuity, and forcing an invalidation of
all relationships, it means we might be breaking upgrade scenarios,
satisfiability checks, interface requirement checks, etc, this is a
silent and very harmful thing. As I mention on the FAQ the
relationships can be hidden in many places, not just in control
metadata, which makes checking for this way more difficult.

And just to be clear, epochs have their place, that's why they were
created. They might be somewhat ugly and confusing, but when used
correctly they are better than any other alternative, and any
ill-effects are unavoidable anyway. The problem is when those
ill-effects are caused by bogus usage of epochs.

> > > Incorrect pre-depends are actively harmful. They may cause dependency
> > > loops which dpkg cannot fix, and may therefore result in problems that
> > > go way beyond the package which introduced the incorrect pre-depends. In
> > > that context, I agree that trying to reach consensus on -devel before
> > > introducing a pre-depends is a good idea.
> > > 
> > > Incorrect epochs are a nuisance at best. There's a myth going around
> > > that they cause a "stigma", which I suspect is where this comes from,
> > > but in actual fact they're just a few extra characters in a version
> > > number with some special semantics, and nothing beyond that.
> ^^

BTW something I missed in my previous reply, the fact that it might
(should! :) be considered a stigma is IMO a good thing, because it
might make people think at least twice before introducing them. :)

> > No, they are not just a decorator for the version, they have a
> > semantic meaning,
> 
> I know that.

Sorry, my apologies, I missed that part you underline. I my defense I'd
say that over the years I've seen so many very experienced maintainers
using epochs incorrectly or trying to defend their non-problematic nature
and goodness, that I've reached a point where I just assume epochs are
generally missunderstood. I realize that can obviously end up coming
across as very condescending. :/

> > they just reset the sorting order of all previous versions and thus
> > invalidate any previous relationships.
> 
> Not any more than do upstream version numbers towards debian revisions.
> 
> If you consider epoch-zero versions to have "no epoch" (which is wrong),
> then yes, they imply a "reset". 
> 
> But really, an epoch is just prepending an extra version component
> before the version number. epochless versions have an implicit zero
> (okay, I shouldn't be telling you this).

See my comment above about release continuity.

> Honestly, if this is going to become a requirement, and I didn't want to
> be bothered with it, I would just use . rather than : as my epoch
> separator whenever I need to introduce an epoch. The result regarding
> upgrades etc is *exactly* the same.

Anything that has the same semantic effect of an epoch has potentially
the same ill-consequences. The +really convention is as harmful as
using an epoch, the main advantage is that any uncaught breakage in
relationships will eventually remedy itself once the package gets back
into its previous release continuity.

Using a convention that keeps appending the different version schemas
just to avoid epochs, seems would be even more ugly and confusing than
simply using an epoch when that's the intended use! :)

> > For the valid use cases that's an unavoidable transition that one has
> > to handle, but for the invalid cases it's just unnecessary breakage in
> > the archive and out-of-archive, 

Bug#902555: radeon.4: Some fixes in the manual

[G. Branden Robinson]

At 2018-06-28T11:31:30+0200, Michel Dänzer wrote:
> 
> Please send this kind of change directly upstream to the
> amd-...@lists.freedesktop.org list for review, split up into one patch
> per logical change.

Well, a lot of these changes aren't "logical", they're stylistic.

> On 2018-06-27 09:07 PM, Bjarni Ingi Gislason wrote:
> > 
> > Don't begin a sentence with a digit.
> 
> Why not? What's the problem with that?

It's considered substandard English style.

See, e.g., [1]

https://www.editage.com/insights/scientific-writing-avoid-starting-sentences-with-a-number-or-abbreviation

The Chicago Manual of Style, which is the preferred style guide of
Michael Kerrisk of the Linux Man-Pages Project, is paywalled[2], but my
copy of the 14th edition says:

§8.9 "At the beginning of a sentence any number that would ordinarily be
set in numerals is spelled out, regardless of any inconsistency this may
create [...]".

Other style guides broadly agree, though they might not be quite as
militant about it as Chicago is.

> > Add a comma after "e.g.".
> 
> That looks odd to me.

It's standard to have the comma.

Chicago, 14th ed. again:

§5.62 "A comma is usually used after such expressions as _that is_,
_namely_, _i.e._, and _e.g._  The punctuation preceding such expressions
should be determined by the magnitude of the break in continuity.  If
the break is minor, a comma should be used.  If the break is greater
than that signaled by a comma, a semicolon or an em dash may be used, or
the expression and the element it introduces may be enclosed in
parentheses". [italics replaced by underscore delimeters]

I've run into Bjarni in the groff and man-pages projects.  He's a
detail-oriented style maven after my own heart and I can vouch that his
proposed corrections are usually sound ones.

[1] ;-)
[2] >:( http://www.chicagomanualofstyle.org/16/ch06/ch06_toc.html
redirects me to a login screen.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#439888: Processed: retitle to RFP: macaulay2 -- Software system for algebraic geometry research

[Doug Torrance]

Control: retitle -1 ITP: macaulay2 -- Software system for algebraic geometry 
research
Control: owner -1 !

On 06/28/2018 06:24 AM, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
>> retitle 439888 RFP: macaulay2 -- Software system for algebraic geometry 
>> research
> Bug #439888 [wnpp] ITP: macaulay2 -- Software system for algebraic geometry 
> research
> Changed Bug title to 'RFP: macaulay2 -- Software system for algebraic 
> geometry research' from 'ITP: macaulay2 -- Software system for algebraic 
> geometry research'.
>> noowner 439888
> Bug #439888 [wnpp] RFP: macaulay2 -- Software system for algebraic geometry 
> research
> Removed annotation that Bug was owned by Doug Torrance 
> .
>> stop
> Stopping processing here.

I still intend to package Macaulay2.

Bug#902614: lynis: Update watchfile for new URLs

[John Scott]

Source: lynis
Version: 2.6.2-1
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

uscan hasn't been working for Lynis, so I've made a patch
and am including it here since there doesn't seem to be a
Salsa repo at the moment.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

- -- no debconf information

*** patch
diff -urN lynis-a/debian/upstream/signing-key.asc 
lynis-b/debian/upstream/signing-key.asc
- --- lynis-a/debian/upstream/signing-key.asc   1969-12-31 19:00:00.0 
-0500
+++ lynis-b/debian/upstream/signing-key.asc 2018-06-28 09:13:56.055629570 
-0400
@@ -0,0 +1,51 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+
+mQINBFRZVLABEACsVZ8ieubM0BMhQespYUST0aKijnzTnHvusQV/18a5iwQCtGga
+0lP5LZi92FpiXv8TFxxjFuneJkYSFdEFu0vYh8zLZ9m1av+XrFL3um4CiKH+c82r
+06YlMq7+0Dn5yVh7nvlgPZPeD5pl+8phr1Tkl60XGFOysUSmNqf+3vBb/KVIT4HT
+fTOY5jKCykM88AxuEFJBUg4PCV6QiCyNimFrBO2PLsQ78Nz6lQO3oqtosO7SuDHk
+SGVU2wa0W+Ddj9EHlLtDTfnsBUKyZqvIHxba9NnynG+hxTOI2iHoLYUfqq6DwxCY
+nN/QUzp4z3dpWgRLR2pONoQKzsxnOf26lZ56HXa8nmez7l3w1REWr0jxuvl9V2Ts
+8AYLAXJTOmosMgDmo8gSeG26lZcUBGH+gu01ui1uxFJKjqve2zLuBpOqVyjIgBXQ
+5QHF3U5ynWtsHL72dZJMYOlJ/wSLN44GjZ6mS9K2B6Zkxq9++O0NrbKhj01+Qvg4
+4goKUiLg/ErSVd9TQeOju3UcBQ6RhtOLaBkdOdHouT/iKhwWW1020Kae+OzzeQj8
+MhxTzKZejNFBFcak1azdqJcmpEpPLViw72V2vayImTr1/N3c4KwkoeBFFPc6Zt7X
+CdgYrrvkC7e5c7DKEpa5xObjNk2BbEgqcqBRiM5/WmcUeExw/dMod4qhRQARAQAB
+tDNDSVNPZnkgKFNvZnR3YXJlIFNpZ25pbmcgS2V5KSA8c2VjdXJpdHlAY2lzb2Z5
+LmNvbT6JAj4EEwECACgFAlRZVLACGwMFCR4TOAAGCwkIBwMCBhUIAgkKCwQWAgMB
+Ah4BAheAAAoJEEKaVm/Vt5JR9LwP/R4l5AjM/dbLUUgqufkx6BNfC38IUNwPc94Q
+0y2ePRAf6FDGSrHc3f2iQ4TwchOe8bQMirxsFAzJ6CYSAx2haw07R60DqvGae5OX
+2CgttuY7NEzeE1t0OtNAASd+i8MuDEg2zOy7R6I+cWuBvrRLbydPcCh94fi7tAWv
+iZNF4im1W4oSkBEvBR4AO5Wv4BLyUrz2D501XMwonDt6jgFTZs8TN+mLC7iJkCGL
+PIRgcZ/1gLjfzXa5VgLJhr3tBw9z+jl7SasNlmrvl8jlE0hC75tg0k0dn9Z/VmMr
+/7qTRr9c3RrExUYd5SstjhwNqYt1FSq228wM07/0dMj9gmPkgHP7eElrrIS5ZR8u
+2GN7bYdzOQLbE+hYsXqS2GgI7p9y8eC8Yq9ybNJEuQAhveEwyq+V7n3gTQz2YZAw
+MzoEJH455lwoHmjxGtntIaxcNblHLO6vTuuz9+BTjyayiq5itox9V1gbqon0IB8F
+bGVcKxqsx4d01zfPEMfkGdA13qpkxkJEARTXFOmVMEdXp7WUSv7gF4JX/Jdk162U
+Pqukn4V0UuWS6/9jKUOn/QUwZGkA3WGfIXj2ku6FZdoAgoKWvqTBzdoGBPfRclj+
+hRX8YGQgm6WuwBJgw+JC/hHDB1G6PlhUCBXm28gw1sO3qTkTxvPkFhNdO1fd3Jn6
+PZLTcDRTuQINBFRZVLABEADE/16arIO3nAbyltJaV313fXHFq3cffWeT+u+mPXbu
+/JM7LZVjRcNASQmnSZHIdj5jgDmLSWMJ8Wb0dQF+hhMenrv351lSXhpeygzqHpHK
+pHJ9R8rAFFauwYYmmfkkSSIwCJHb4oizq+e3R2MjFUzyA7YSTFT9GTk4P82aYL7B
+FKGUrus739QCC09dFKbmKR34ELYYNqX/VaTzGRu3Yt/nDOZ/usvsIZn6wKKDZTBk
+FsXJwB4gkHoEXjd7VnkOLEOII2p7dt8dib1vVHQg10BHWHrPtMANGNePItAiLEV7
+Irgakqhb2ioV4RF37Zp9xU3PriizVxNqUc/MQUm9jx1i9QDHI4Q86pVlpMhWAF04
+/VnVO+JvxmVPGdB/m9daU9xs8wHVPV9R93fbT+RS6WFN2fqN+6pmq1sLulUQMuoE
+21D2W8GprLX9k9cASS5Nb4w/B5zk1jUxzOeseIhuyK+xlVr/9DmSOJqOzxi7HRxk
+VYX7zZ9cAT7ReoGs+IcC/K/rPY/54JRZq9R1RrxAjcinOBj4KV/cJ8PnilFuuVbq
+lNrrcR3GWVqYTbGFbK2MkbHgfl869aO7bB2tWqOsdL2uVWGkD1BeIbyBkEILygPp
+2csg80P1tvEFCi51ZXwmtpdcEGzciGvTZWSTKJJ9NBfjIMqAbKc8c0UXygS7M49G
+OQARAQABiQIlBBgBAgAPBQJUWVSwAhsMBQkeEzgAAAoJEEKaVm/Vt5JR4lsP/0C1
+hTruxiAyGWAokbhHSQVzulkq/BGVuBQ2v9BBgeTvud4WjetgOSH7bqUBtl9cUiIN
+Bt0Qdka6eSRymvrLE3RvYfXErBrE64PzmoOz8i+cJ70NNuD0WexWzbfKjaMrHztY
+V8SBxbCXp0yP0XMLwKJDq2xhXjGBjJPAGYPMKtxlzZATB9rPzeN+sexw3GNljIT3
+FrFlAqg8MklUEZ3tG22jh218CJsL0Khwjc5H6H/u6YIqn6J70DZfzE5D5xaANCyZ
+q/CmAGVAtzT1SukZlZLArZl/SWKSbS205/7PDzi381Ow2ryOATsEglF07Qqmx0MF
+fwkxZbH04cQnUPgea72sNA379ADjnUsX7QYFM5qRb/IF5t+3qdU6yanXJ/ljK6ZY
+2Jga9y+CcnZFzJzAXpxAXsC6/UmZ/AItr6pVVVu+w/hVCFUSqqN6crtCFj6ToOy9
+sSffsS6VqNWXA91Yi1ICrz9nKXCTCvGy2bd0UwWuZbMIp/4eaaMR0saaUNaRaZz4
+hxKlQuG91K5mfLS+gwKNpymOiruc2tX05UliP9tnIzD7zrXCG6eM3Tihk1XQjKWD
+K+kJazRzGpFKX3ll+GvbwuECOXF3HZ53WOak+B1Rt3DqPdy2K4Wj34vjQ6JfQDgd
+o/DD0RXrmQVG+n4te2uVV1FNLKfq3kZeYayAAJZA
+=tRyA
+-END PGP PUBLIC KEY BLOCK-
\ No newline at end of file
diff -urN lynis-a/debian/watch lynis-b/debian/watch
- --- lynis-a/debian/watch  2018-06-28 09:14:44.138043151 -0400
+++ lynis-b/debian/watch2018-06-28 09:11:27.552063047 -0400
@@ -1,2 +1,2 @@
- -version=3
- -https://cisofy.com/download/lynis   
https://cisofy.com/files/lynis-(.*)\.tar\.gz
+version=4
+opts=pgpsigurlmangle=s/$/.asc/ 
https://downloads.cisofy.com/lynis/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAls04dcACgkQfWFEpid5
MHK/CQf/bTbVbMMv4ykslqmH2UmzQPaeKigGmNzPLah8ChGakZjGpQMQtjKHvorY
eFn4kw5ISSXoAvImG5efmPhQGe/OgZ9EyPyeqM0qPJOFKtOyjmSuI0OXpd7MQ8ke
42GyqAjtiNW6gpkR0OoFsu9GLe30tXS7uoCSibTyFYORZl1U6doN33raJq9M1Vhg
FmAUYZgioJbxW/wsoVmw4pj4oYcsRTt/NR7jzDAeqAHW+Eu6uciMknuwZc6Eg5Og

Bug#902613: RFS: i2pd/2.19.0-1

[Yangfl]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: i2pd
   Version : 2.19.0-1
   Upstream Author : R4SAS
 * URL : https://github.com/PurpleI2P/i2pd
 * License : BSD
   Section : net


  It builds those binary packages:

i2pd  - Full-featured C++ implementation of I2P client

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/i/i2pd/i2pd_2.19.0-1.dsc

  Changes since the last upload:

* New upstream release


Regards,
Yangfl