Bug#902470: influxdb-python: FTBFS in buster/sid (failing tests)

[Andreas Tille]

Control: tags -1 help

Hi,

the diff can be found here

 'foo,hello=there 0="1",1=1i,2=1.1 0\nfoo,hello=there 
0="2",1=2i,2=2.2 36000\n' !=
 'foo,hello=there 0="1",1=1i,2=1.111 0\nfoo,hello=there 
0="2",1=2i,2=2.222 36000\n'
^^  
  ^^

So the precision of floats is to digits less than expected.

May be somebody has a clue why this is happening.

Kind regards

  Andreas.

Disclaimer: I'm not involved in influxdb-python packaging - I just had
a quick look whether I can help since this bug affects some Debian Med
packages.  Unfortunately I have no idea what to do to fix the precision
issue.

-- 
http://fam-tille.de

Bug#884797: ITP: anbox -- Run Android applications on any GNU/Linux operating system

[Shengjing Zhu]

Hi Chris,

On Sat, Jun 23, 2018 at 2:22 AM Chris Lamb  wrote:
>
> > Acked from Ben[1], let's wait for next 4.17 kernel.
>
> Thanks Shengjing; please keep me informed. :)

linux 4.17.3 is in unstable now, although linux-lastest haven't updated yet.

Could you continue looking at anbox?
I've uploaded new version to mentors.d.n,
https://mentors.debian.net/debian/pool/contrib/a/anbox/anbox_0.0~git20180612-1.dsc

Or you can get it from salsa
https://salsa.debian.org/zhsj-guest/anbox/

below is copied from mentors.d.n,

> Longer long description would be nice
I copied more words from upstream readme. And added one sentence about
the android image and kernel modules.

> install -d $(CURDIR)/debian/anbox/usr/share/pixmaps/ vs debian/dirs seems 
> unfortunately ugly/complicated

all directories are installed by d/dirs and d/install now.

> double newline before override_dh_auto_configure

fixed

> could we have autopkgtests for this? :)

I had added one in d/tests/control. should have more?
I think it's too much to test running android entirely, eg, need a
kernel greater than 4.17.3, and graphics, and download android
image...
So d/test/control only test the `anbox` command.

> tests seem to hang for me:

I don't know the reason from your log. the log says
buffered_io_stream_tests stared but not finished. Does this happen in
sbuild or other environment?
It's fine on my side and I can't reproduce (in sbuild).

--
Best regards,
Shengjing Zhu

Bug#902969: mupdf FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: netkit-tftp
Version: 0.17-20
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

netkit-tftp fails to cross build from source, because it builds for the
build architecture. Nothing tells ./configure to use a cross compiler. A
simple way of doing so is exporting a suitable CC. We can defer that
task to dpkg's buildtools.mk. Then it fails, because it tries running
compiled binaries, which generally fails with an Exec format error
during cross compilation. After patching ./configure to avoid running
binaries, netkit-tftp cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru netkit-tftp-0.17/debian/changelog 
netkit-tftp-0.17/debian/changelog
--- netkit-tftp-0.17/debian/changelog   2018-07-03 17:30:38.0 +0200
+++ netkit-tftp-0.17/debian/changelog   2018-07-04 06:39:53.0 +0200
@@ -1,3 +1,12 @@
+netkit-tftp (0.17-20.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dpkg's buildtools.mk export cross tools.
++ cross.patch: Don't run compiled binaries.
+
+ -- Helmut Grohne   Wed, 04 Jul 2018 06:39:53 +0200
+
 netkit-tftp (0.17-20) unstable; urgency=medium
 
   * configure: Exit with appropiate return code so that
diff --minimal -Nru netkit-tftp-0.17/debian/patches/cross.patch 
netkit-tftp-0.17/debian/patches/cross.patch
--- netkit-tftp-0.17/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ netkit-tftp-0.17/debian/patches/cross.patch 2018-07-04 06:39:53.0 
+0200
@@ -0,0 +1,26 @@
+--- netkit-tftp-0.17.orig/configure
 netkit-tftp-0.17/configure
+@@ -75,10 +75,7 @@
+ if [ x"$CC" = x ]; then
+ echo -n 'Looking for a C compiler... '
+ for TRY in egcs gcc g++ CC c++ cc; do
+-   (
+-   $TRY __conftest.c -o __conftest || exit 1;
+-   ./__conftest || exit 1;
+-   ) >/dev/null 2>&1 || continue;
++   $TRY __conftest.c -o __conftest >/dev/null 2>&1 || continue;
+CC=$TRY
+break;
+ done
+@@ -91,10 +88,7 @@
+ echo "$CC"
+ else
+ echo -n 'Checking if C compiler works... '
+-if (
+-  $CC __conftest.c -o __conftest || exit 1
+-  ./__conftest || exit 1
+-   ) >/dev/null 2>&1; then
++if $CC __conftest.c -o __conftest >/dev/null 2>&1; then
+  echo 'yes'
+  else
+  echo 'no'
diff --minimal -Nru netkit-tftp-0.17/debian/patches/series 
netkit-tftp-0.17/debian/patches/series
--- netkit-tftp-0.17/debian/patches/series  2018-07-03 17:29:51.0 
+0200
+++ netkit-tftp-0.17/debian/patches/series  2018-07-04 06:39:53.0 
+0200
@@ -3,3 +3,4 @@
 memory_corruption.patch
 manpage_warning.patch
 875885.patch
+cross.patch
diff --minimal -Nru netkit-tftp-0.17/debian/rules netkit-tftp-0.17/debian/rules
--- netkit-tftp-0.17/debian/rules   2018-07-03 13:01:36.0 +0200
+++ netkit-tftp-0.17/debian/rules   2018-07-04 06:39:32.0 +0200
@@ -11,6 +11,9 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+DPKG_EXPORT_BUILDTOOLS=1
+-include /usr/share/dpkg/buildtools.mk
+
 build: build-stamp
 build-stamp:
dh_testdir

Bug#902968: mupdf FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: mupdf
Version: 1.13.0+ds1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mupdf fails to cross build from source, because it uses the build
architecture compiler. The easiest way of fixing that is using
dh_auto_build. Doing so turned out to be rather invasive, because mupdf
has its own mechanism for handling parallel building rather than using
dh --parallel. To have make install benefit from --parallel it needs to
be calling dh_auto_install. Switching to dh_auto_install means passing
DESTDIR to make, which upstream understands, but the packaging already
stuffs the DESTDIR value into prefix, so it ends up twice and makes
mupdf fail to build. After shrinking prefix, it works again, but that's
quite a pile of changes for making it use dh_auto_build.

Can you apply the patch? Alternatively, can you include dpkg's
buildtools.mk setting DPKG_EXPORT_BUILDTOOLS=1 to pass cross tools to
make?

Helmut
diff --minimal -Nru mupdf-1.13.0+ds1/debian/changelog 
mupdf-1.13.0+ds1/debian/changelog
--- mupdf-1.13.0+ds1/debian/changelog   2018-04-30 04:17:25.0 +0200
+++ mupdf-1.13.0+ds1/debian/changelog   2018-07-04 05:55:48.0 +0200
@@ -1,3 +1,10 @@
+mupdf (1.13.0+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh_auto_build/dh_auto_install --parallel. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 04 Jul 2018 05:55:48 +0200
+
 mupdf (1.13.0+ds1-1) unstable; urgency=medium
 
   * New upstream version 1.13.0+ds1
diff --minimal -Nru mupdf-1.13.0+ds1/debian/control 
mupdf-1.13.0+ds1/debian/control
--- mupdf-1.13.0+ds1/debian/control 2018-04-30 02:07:32.0 +0200
+++ mupdf-1.13.0+ds1/debian/control 2018-07-04 05:55:48.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Kan-Ru Chen (陳侃如) 
 Uploaders: Quoc-Viet Nguyen 
-Build-Depends: debhelper (>= 7.0.50~), dpkg-dev (>= 1.16.1.1~),
+Build-Depends: debhelper (>= 7.4.10~), dpkg-dev (>= 1.16.1.1~),
  libfreetype6-dev, pkg-config, libjpeg-dev, libjbig2dec-dev,
  libopenjp2-7-dev, libx11-dev, libxext-dev, zlib1g-dev,
  libharfbuzz-dev, freeglut3-dev
diff --minimal -Nru mupdf-1.13.0+ds1/debian/rules mupdf-1.13.0+ds1/debian/rules
--- mupdf-1.13.0+ds1/debian/rules   2018-04-30 02:53:33.0 +0200
+++ mupdf-1.13.0+ds1/debian/rules   2018-07-04 05:55:48.0 +0200
@@ -18,18 +18,13 @@
 CFLAGS += -DJBIG_NO_MEMENTO
 CFLAGS += -fPIC
 
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-   NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
-   MAKEFLAGS += -j$(NUMJOBS)
-endif
-
-BUILD_FLAGS=build=debian OS=Linux verbose=yes XCFLAGS="$(CFLAGS)" 
XLDFLAGS="$(LDFLAGS)"
+BUILD_FLAGS=build=debian OS=Linux verbose=yes XCFLAGS="$(CFLAGS)" 
XLDFLAGS="$(LDFLAGS)" prefix=/usr
 
 override_dh_auto_build:
-   $(MAKE) $(BUILD_FLAGS)
+   dh_auto_build -- $(BUILD_FLAGS)
 
 override_dh_auto_install:
-   $(MAKE) $(BUILD_FLAGS) prefix=$(CURDIR)/debian/tmp/usr install
+   dh_auto_install -- $(BUILD_FLAGS)
install -m744 -T $(CURDIR)/debian/mupdf.sh 
$(CURDIR)/debian/tmp/usr/bin/mupdf
 
 override_dh_auto_clean:
@@ -38,4 +33,4 @@
-rm -f include/mupdf/pdf/name-table.h source/pdf/pdf-name-table.h
 
 %:
-   dh $@
+   dh $@ --parallel

Bug#902774: jetty9: CVE-2017-7656 CVE-2017-7657 CVE-2017-7658 CVE-2018-12536 CVE-2018-12538

[Salvatore Bonaccorso]

Control: retitle -1 jetty9: CVE-2018-12536
Control: retitle 902953 jetty9: CVE-2017-7656 CVE-2017-7657 CVE-2017-7658
Hi

After discussion with Emmanuel, CVE-2017-7656, CVE-2017-7657 and
VE-2017-7658 are fixed all in 9.2.25-1 with
https://github.com/eclipse/jetty.project/commit/a285deea .

So keeping this bug for the remaining one open for CVE-2018-12536.

Regards,
Salvatore

Bug#902967: RFS: ddnet/11.2.1-1

[Yangfl]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ddnet
   Version : 11.2.1-1
   Upstream Author : Dennis Felsing
 * URL : http://ddnet.tw/
 * License : zlib (code), CC-BY-SA 3.0 (data)
   Section : games

It builds those binary packages:

  ddnet - Teeworlds modification with a unique cooperative gameplay
 ddnet-data - Data for DDNet
 ddnet-server - Server for DDNet
 ddnet-tools - Tools for DDNet

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/d/ddnet/ddnet_11.2.1-2.dsc

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

Changes since the last upload:

  * New upstream release


Regards,
 Yangfl

Bug#902966: pstore: crypto_comp_decompress failed

[Shengjing Zhu]

Package: src:linux
Version: 4.17.3-1
Severity: normal

Dear Maintainer,

Updating to 4.17, dmesg shows pstore: crypto_comp_decompress failed
I didn't know what's pstore used for, maybe efi?
Looking at config, maybe some pstore_*_compress should be set?

grep -i pstore /boot/config-4.17.0-1-amd64
CONFIG_CHROMEOS_PSTORE=m
CONFIG_EFI_VARS_PSTORE=m
# CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_DEFLATE_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
# CONFIG_PSTORE_LZ4HC_COMPRESS is not set
# CONFIG_PSTORE_842_COMPRESS is not set
CONFIG_PSTORE_COMPRESS=y
CONFIG_PSTORE_DEFLATE_COMPRESS_DEFAULT=y
CONFIG_PSTORE_COMPRESS_DEFAULT="deflate"
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_PMSG is not set
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=m


-- Package-specific info:
** Version:
Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-24)) #1 SMP Debian 4.17.3-1 (2018-07-02)

** Command line:
initrd=\EFI\debian\initrd.img 
root=PARTUUID=71249354-e7c1-4e69-bd05-608837ff5c42 rootfstype=ext4

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[3.979407] pstore: decompression failed: -22
[3.979479] pstore: crypto_comp_decompress failed, ret = -22!
[3.979479] pstore: decompression failed: -22
[3.979551] pstore: crypto_comp_decompress failed, ret = -22!
[3.979552] pstore: decompression failed: -22
[3.979624] pstore: crypto_comp_decompress failed, ret = -22!
[3.993509] intel_rapl: Found RAPL domain package
[3.994563] pstore: decompression failed: -22
[3.995407] intel_rapl: Found RAPL domain core
[3.996682] pstore: crypto_comp_decompress failed, ret = -22!
[3.997418] intel_rapl: Found RAPL domain uncore
[3.998554] pstore: decompression failed: -22
[3.998645] pstore: crypto_comp_decompress failed, ret = -22!
[3.999333] intel_rapl: Found RAPL domain dram
[4.000469] pstore: decompression failed: -22
[4.117259] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4350-pcie 
for chip BCM4350/8
[4.117743] pstore: Registered efi as persistent store backend
[4.118512] brcmfmac :3a:00.0: firmware: failed to load 
brcm/brcmfmac4350-pcie.clm_blob (-2)
[4.319451] brcmfmac :3a:00.0: Direct firmware load for 
brcm/brcmfmac4350-pcie.clm_blob failed with error -2
[4.319453] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available 
(err=-2), device may have limited channels available
[4.319926] input: Dell WMI hotkeys as 
/devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input13
[4.320113] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4350/8 wl0: Oct 22 
2015 06:16:26 version 7.35.180.119 (r594535) FWID 01-e791c176
[4.342410] Adding 3906556k swap on /dev/nvme0n1p4.  Priority:-2 extents:1 
across:3906556k SSFS
[4.376820] EXT4-fs (nvme0n1p5): mounted filesystem with ordered data mode. 
Opts: (null)
[4.378394] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[4.381003] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[4.381050] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[4.381093] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[4.381135] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[4.381177] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[4.381220] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[4.523423] brcmfmac :3a:00.0 wlp58s0: renamed from wlan0
[4.552166] input: DLL0704:01 06CB:76AE Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DLL0704:01/0018:06CB:76AE.0002/input/input21
[4.553357] hid-multitouch 0018:06CB:76AE.0002: input,hidraw1: I2C HID v1.00 
Mouse [DLL0704:01 06CB:76AE] on i2c-DLL0704:01
[4.662333] media: Linux media interface: v0.10
[4.672019] Linux video capture interface: v2.00
[4.725124] tun: Universal TUN/TAP device driver, 1.6
[4.725831] Bluetooth: Core ver 2.22
[4.727165] NET: Registered protocol family 31
[4.728338] Bluetooth: HCI device and connection manager initialized
[4.729884] Bluetooth: HCI socket layer initialized
[4.731053] Bluetooth: L2CAP socket layer initialized
[4.731804] Bluetooth: SCO socket layer initialized
[4.735967] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (0c45:670c)
[4.769924] usbcore: registered new interface driver btusb
[4.787516] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not 
initialized!
[4.788399] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not 
initialized!
[4.789657] uvcvideo 1-5:1.0: Entity type for entity 

Bug#902965: xserver-xorg-core: lxdm fails to start xserver with 2:1.20.0-3

[Arthur Marsh]

Package: xserver-xorg-core
Version: 2:1.20.0-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

upgrading to 2:1.20.0-3 results in lxdm failing to start xserver

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

downgrading to 2:1.20.0-2 resulted in a working system

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Apr 10  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 May 25 01:53 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Venus LE [Radeon HD 8830M] [1002:682b] (rev 87)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1323 Jun 18 17:46 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
Identifier  "Radeon Cape Verde"
#Driver "vesa"
#Driver "radeonhd"
Driver  "radeon"
# for amdgpu set:
# GRUB_CMDLINE_LINUX_DEFAULT="radeon.si_support=0 amdgpu.si_support=1" 
# in /etc/default/grub and re-run update-grub 
#Driver "amdgpu"
#Option "CustomEDID""VGA-0:/etc/X11/hp7500.edid" # UMS only
#Option  "AccelMethod"   "shadowfb"
#Option  "AccelMethod"   "exa"
#Option  "AccelMethod"   "xaa"
#Option "DRI" "on"
#Option "DRI" "off"
#Option "EXAVSync"  "on"
#Option "TearFree"  "on"
#Option "EnablePageFlip" "off"
#Option "SwapbuffersWait" "off"
#Option "AccelMethod" "glamor"
#Option "DRI" "3"
#
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  #options radeon modeset=1
  #blacklist radeon

Kernel version (/proc/version):
---
Linux version 4.18.0-rc3+ (root@am64) (gcc version 8.1.0 (Debian 8.1.0-9)) 
#3127 SMP PREEMPT Tue Jul 3 09:36:29 ACST 2018

Xorg X server log files on system:
--
-rw-r--r-- 1 amarsh04 amarsh04 24891 Dec 19  2015 
/home/amarsh04/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 root root 12045 Jun 25  2017 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 27830 Jul  4 11:46 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[  1107.216] 
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[  1107.217] Build Operating System: Linux 4.9.0-6-amd64 x86_64 Debian
[  1107.217] Current Operating System: Linux am64 4.18.0-rc3+ #3127 SMP PREEMPT 
Tue Jul 3 09:36:29 ACST 2018 x86_64
[  1107.217] Kernel command line: BOOT_IMAGE=/vmlinuz-4.18.0-rc3+ 
root=UUID=39706f53-7c27-4310-b22a-36c7b042d1a1 ro page_owner=on
[  1107.217] Build Date: 24 May 2018  04:23:27PM
[  1107.217] xorg-server 2:1.20.0-2 (https://www.debian.org/support) 
[  1107.217] Current version of pixman: 0.34.0
[  1107.217]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1107.217] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1107.217] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul  4 11:46:56 
2018
[  1107.217] (==) Using config file: "/etc/X11/xorg.conf"
[  1107.217] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1107.217] (==) No Layout section.  Using the first Screen section.
[  1107.217] (==) No screen section available. Using defaults.
[  1107.217] (**) |-->Screen "Default Screen Section" (0)
[  1107.217] (**) |   |-->Monitor ""
[  1107.217] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[  1107.217] (**) |   |-->Device "Radeon Cape Verde"
[  1107.217] (==) No 

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Ryan Tandy]

Control: found -1 4.17.3-1

Hi,

On Mon, Jul 02, 2018 at 08:42:45PM -0700, Ryan Tandy wrote:
However it looks like it might be resolved with the kernel in 
unstable. I will run some more iterations and let you know.


The issue still reproduces with stretch userland and the current 
unstable kernel.


It cannot be reproduced with buster's glibc because lock elision was 
disabled in #878071, citing this issue.


Thanks
Ryan

Bug#902964: RM: udj-desktop-client -- RoQA; unmaintained; Upstream dead; Service broken; depends on deprecated Qt4

[Boyuan Yang]

Package: ftp.debian.org
X-Debbugs-CC: nhand...@debian.org
Severity: normal

Dear FTP Masters,

As reported in https://bugs.debian.org/901385, I found that package udj-
desktop-client is currently

* Upstream dead (homepage defunct and turned into an advertisement site)
* Upstream GitHub repository dead (no development since 2013)
* Seen no Debian upload since 2012
* With low popcon
* Affected by Qt4 Removal (https://wiki.debian.org/Qt4Removal)
* Needs an account on udjplayer.com to be functional but this website is dead 
and replaced by as advertisement site thus the package is completely useless.

Its maintainer (Nathaniel Harrison Handler) also had no activity in Debian 
since 2015, according to [1]. My previous mail trying to contact with the 
maintainer sent 21 days earlier also got no reply.

Package udk-desktop-client also has no reverse dependencies.

As a result, I am requesting to have this package removed from Debian 
unstable. Thanks!

--
Regards,
Boyuan Yang


[1] https://contributors.debian.org/contributor/nhandler%40debian.org/

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

Bug#902946: Fails to load autofs module through autofs4 alias

[Ben Hutchings]

Control: notfound -1 239-1
Control: found -1 238-5
Control: found -1 239-3

On Tue, 2018-07-03 at 23:42 +0200, Michael Biebl wrote:
> Am 03.07.2018 um 23:10 schrieb Ben Hutchings:
> > On Tue, 2018-07-03 at 23:08 +0200, Michael Biebl wrote:
> > > Am 03.07.2018 um 20:11 schrieb Ben Hutchings:
> > > > Package: systemd
> > > > Version: 239-1
> > > > Severity: serious
> > > > 
> > > > Starting with Linux 4.18, the autofs4 kernel module is renamed
> > > > to autofs, but retaining an 'autofs4' alias.
> > > > 
> > > > Despite the presence of the alias, systemd fails to load the
> > > > autofs module:
> > > > 
> > > > systemd[1]: Failed to insert module 'autofs4': No such file or 
> > > > directory
> > > > 
> > > > Opened as 'serious' since I think autofs supports critical
> > > > functionality in systemd.
> > > 
> > > Is there a 4.18 kernel available where this can be tested?
> > 
> > I've uploaded it to experimental and it's currently in NEW.
> 
> Ok, thanks.
> 
> Just to be sure: Since you marked this found in version 239-1, is this
> is a regression or already reproducible with v238. I'm asking because
> this bug will block systemd from entering testing.

Just tested, and it's not a regression.  I'm correcting the found
versions to be those I've actually tested with Linux 4.18.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



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

Bug#902963: dns-root-data: Added entry in /usr/share/dns/root.ds breaks dnsmasq startup

[Mark Blackburn]

Package: dns-root-data
Version: 2017072601~deb8u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Installed dnsmasq on a stock system with ARM arch.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Downgraded to dns-root-data 2017072601~deb8u1 (Had to download directly from
repository and use dpkg instead of apt-get)
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 8.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.4.91-etc-r13 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#902962: mandelbulber2: Missing Replaces: header

[Matthias Urlichs]

Package: mandelbulber2
Version: 2.08.3-1+b1
Severity: serious
Justification: file conflicts

Unpacking mandelbulber2 (2.13.2-3) over (2.08.3-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/mandelbulber2_2.13.2-3_amd64.deb (--unpack):
 trying to overwrite '/usr/share/mandelbulber2/language/de.qm', which is also 
in package mandelbulber2-data 2.08.3-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../mandelbulber2-data_2.13.2-3_all.deb ...
Unpacking mandelbulber2-data (2.13.2-3) over (2.08.3-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/mandelbulber2-data_2.13.2-3_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/mandelbulber2.1.gz', which is also in 
package mandelbulber2 2.08.3-1+b1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages mandelbulber2 depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-9
ii  libgl1  1.0.0+git20180308-3
ii  libgl1-mesa-glx 18.1.2-1
ii  libgomp18.1.0-9
ii  libgsl232.4+dfsg-6
ii  libgslcblas02.4+dfsg-6
ii  libpng16-16 1.6.34-1
ii  libqt5core5a5.10.1+dfsg-7
ii  libqt5gui5  5.10.1+dfsg-7
ii  libqt5network5  5.10.1+dfsg-7
ii  libqt5test5 5.10.1+dfsg-7
ii  libqt5widgets5  5.10.1+dfsg-7
ii  libstdc++6  8.1.0-9
ii  mandelbulber2-data  2.08.3-1

mandelbulber2 recommends no packages.

mandelbulber2 suggests no packages.

-- no debconf information

Bug#878362: mozjs52: embedded code copy: icu v58

[Simon McVittie]

On Fri, 13 Oct 2017 at 09:23:42 -0400, Jeremy Bicha wrote:
> On Fri, Oct 13, 2017 at 3:54 AM, Simon McVittie  wrote:
> > mozjs52 has an embedded code copy of libicu.
> 
> Ubuntu developers would like to update gjs/mozjs in Ubuntu LTS
> releases. Because new versions of icu bump the soname and there are a
> lot of reverse depends, it looks like Ubuntu LTS won't be able to use
> the system icu library.
> 
> I mention this because it might make sense for Debian to also update
> gjs/mozjs in stable releases.

Worst-case, those stable updates could go back to using the bundled
icu when the system icu gets too old, like Firefox does? (I'm not sure
how likely it is for Debian to hop between branches of mozjs in stable
in practice.)

With #902197 fixed and #902961 worked around with the patches attached to
those bugs, the attached patch was enough to make mozjs52 use the system
ICU, if we ever want to do that. There are some unit test failures where
strings differ slightly between the bundled ICU and the system ICU,
which would need to be addressed or worked around, so this is really
only a proof-of-concept. I haven't tried it on a real system.

smcv
>From 1746aa4a80c3b19645e1ee898383915b18fedcea Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 18 May 2018 10:11:52 +0100
Subject: [PATCH] Build-depend on libicu-dev (>= 58.1) and use system libicu

Leave the patches and workarounds in place, but gate them behind
a WITH_SYSTEM_ICU Make variable, to facilitate backporting
as mentioned on #878362.

Closes: #878362
---
 debian/changelog  |  7 +++
 debian/control|  6 +++---
 debian/control.in |  2 +-
 debian/rules  | 16 +++-
 4 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 6b2680fb..aac90bc0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -17,6 +17,13 @@ mozjs52 (52.3.1-8) UNRELEASED; urgency=medium
   * Add patch to add build support for ia64:
 - ia64-support.patch (Closes: #897178)
 
+  [ Simon McVittie ]
+  * Build-depend on libicu-dev (>= 58.1) and use system libicu
+(Closes: #878362)
+- Leave the patches and workarounds in place, but gate them behind
+  a WITH_SYSTEM_ICU Make variable, to facilitate backporting
+  as mentioned on #878362
+
  -- Jeremy Bicha   Fri, 20 Oct 2017 19:51:21 -0400
 
 mozjs52 (52.3.1-7) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index ffe6f3e3..0380f928 100644
--- a/debian/control
+++ b/debian/control
@@ -1,16 +1,16 @@
 # This file is autogenerated. DO NOT EDIT!
-# 
+#
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
 Source: mozjs52
 Section: libs
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Iain Lane , Jeremy Bicha 
+Uploaders: Iain Lane , Jeremy Bicha , Tim Lunn 
 Build-Depends: debhelper (>= 10.3),
gnome-pkg-tools,
autoconf2.13,
-   libicu-dev,
+   libicu-dev (>= 58.1),
libreadline-dev,
zlib1g-dev (>= 1:1.2.3),
pkg-config,
diff --git a/debian/control.in b/debian/control.in
index f109b519..cb6de987 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -6,7 +6,7 @@ Uploaders: @GNOME_TEAM@
 Build-Depends: debhelper (>= 10.3),
gnome-pkg-tools,
autoconf2.13,
-   libicu-dev,
+   libicu-dev (>= 58.1),
libreadline-dev,
zlib1g-dev (>= 1:1.2.3),
pkg-config,
diff --git a/debian/rules b/debian/rules
index f593..0876a10a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -42,6 +42,17 @@ else
 CONFIGURE_FLAGS += --enable-pie
 endif
 
+# Switch to no if backporting
+WITH_SYSTEM_ICU = yes
+
+ifeq ($(WITH_SYSTEM_ICU),yes)
+
+CONFIGURE_FLAGS += --with-system-icu
+
+else # !WITH_SYSTEM_ICU
+
+CONFIGURE_FLAGS += --without-system-icu
+
 ifeq ($(DEB_HOST_ARCH_ENDIAN),little)
 ICU_DATA_FILE = icudt58l.dat
 else
@@ -49,6 +60,8 @@ ICU_DATA_FILE = icudt58b.dat
 endif
 export ICU_DATA_FILE
 
+endif #!WITH_SYSTEM_ICU
+
 %:
 	dh $@ --sourcedirectory=$(SRCDIR) --with gnome,pkgkde-symbolshelper --without autoreconf
 
@@ -68,15 +81,16 @@ override_dh_clean:
 # The bundled copy of icu prefers clang, which we need to override to
 # use gcc because clang doesn't support our DEB_CFLAGS_MAINT_APPEND
 override_dh_auto_configure:
+ifneq ($(WITH_SYSTEM_ICU),yes)
 	CC=$${CC:-$(DEB_HOST_GNU_TYPE)-gcc} \
 	CXX=$${CXX:-$(DEB_HOST_GNU_TYPE)-g++} \
 	VERBOSE=1 python intl/icu_sources_data.py "$(CURDIR)"
+endif
 	cd $(SRCDIR) && $(SHELL) configure \
 		--host=$(DEB_HOST_GNU_TYPE) \
 		--target=$(DEB_BUILD_GNU_TYPE) \
 		--prefix=/usr \
 		--libdir=/usr/lib/${DEB_HOST_MULTIARCH}/ \
-		--without-system-icu \
 		--enable-posix-nspr-emulation \
 		--with-system-zlib \
 		--enable-tests \
-- 
2.18.0

Bug#902197: mozjs52 FTBFS with icu 60.2

[Simon McVittie]

On Wed, 04 Jul 2018 at 00:14:25 +0100, Simon McVittie wrote:
> Having fixed that, I get a different FTBFS

This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902961

Bug#901919: nvidia-driver: black screen with the latest Linux kernel

[Andreas Beckmann]

On 2018-07-04 01:30, Andreas Beckmann wrote:
> On 2018-07-03 20:31, Andreas Beckmann wrote:
>> On 2018-07-03 17:49, Raphael Hertzog wrote:
>>> RedHat published a much less invasive patch that you can use
>>> in the mean time:
>>> https://bugzilla.redhat.com/attachment.cgi?id=1425704
>>> (part of https://bugzilla.redhat.com/show_bug.cgi?id=1570493 )
>>
>> Thanks for the pointer!
> 
> Hi Luca,
> 
> I've prepared that in the 390 branch - could you give it a test run
> (with all workarounds disabled)?

patch is not backwards compatible to older kernels:

/usr/src/modules/nvidia-kernel/nvidia/nv.c: In function 'nvidia_init_module':
/usr/src/modules/nvidia-kernel/common/inc/nv-linux.h:1103:5: error: implicit 
declaration of function 'kmem_cache_create_usercopy'; did you mean 
'kmem_cache_create'? [-Werror=implicit-function-declaration]
 kmem_cache_create_usercopy(name, size, align, flags, useroffset, usersize, 
ctor)
 ^
/usr/src/modules/nvidia-kernel/common/inc/nv-linux.h:1113:5: note: in expansion 
of macro 'NV_KMEM_CACHE_CREATE_FULL_USERCOPY'
 NV_KMEM_CACHE_CREATE_FULL_USERCOPY(name, sizeof(type), 0, 0, 0, 
sizeof(type), NULL)
 ^~
/usr/src/modules/nvidia-kernel/nvidia/nv.c:796:28: note: in expansion of macro 
'NV_KMEM_CACHE_CREATE_USERCOPY'
 nvidia_stack_t_cache = 
NV_KMEM_CACHE_CREATE_USERCOPY(nvidia_stack_cache_name,
^
/usr/src/modules/nvidia-kernel/nvidia/nv.c:796:26: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 nvidia_stack_t_cache = 
NV_KMEM_CACHE_CREATE_USERCOPY(nvidia_stack_cache_name,


Andreas

Bug#902961: mozjs52: FTBFS in recent unstable: ReserveProcessExecutableMemory() fails during tests

[Simon McVittie]

Source: mozjs52
Version: 52.3.1-8
Severity: serious
Justification: fails to build from source (but built successfully in the past)

(X-Debbugs-Cc to contributors to #897178, to which this seems related,
and #902197)

After fixing #902197, the mozjs52 build-time tests failed on the amd64
Debian porterbox barriere. Specifically, the smoke-test in debian/test.sh
that's run before trying the actual test suite:

"$SRCDIR/js/src/js" -e 'print("Hello, world")'

fails, with js exiting 1.

Running it under gdb reveals that this is because
ReserveProcessExecutableMemory() in js/src/jit/ProcessExecutableMemory.cpp
fails during startup, causing JS_Init() to fail. js helpfully has no
diagnostics at all for this, it just silently exits with EXIT_FAILURE.
(Ignore the first implementation of ReserveProcessExecutableMemory(),
which is for Windows; the Unix implementation is around line 300.)

That function gets a random address, and passes it as the first argument
of mmap(., 1 gigabyte, PROT_NONE, MAP_PRIVATE | MAP_ANON, -1, 0) on
64-bit machines, or the same but with 128M instead of 1G on 32-bit.
This now seems to be failing and returning NULL.

I was surprised to find that on the same machine, if I install gjs (a
GNOME wrapper around mozjs) and the slightly older mozjs 52.3.1-7 that it
depends on, gjs-console -c 'print("hello")' works OK. (We don't package
mozjs' own command-line tool 'js' any more, so no precompiled copy is
available.) The changes between 52.3.1-7 and what I'm compiling all seem
to be specific to non-amd64 architectures, so maybe this is about the
environment in which mozjs was built, rather than the source code used?

A hack that works to avoid this is to retry the mmap() without the address
hint, like in Jason Duerstock's debian/patches/ia64-support.patch,
but for non-IA64 architectures as well; see attached. I suspect this
might be the wrong solution, but perhaps it points someone who knows
this better than I do in the direction of a better solution...

This also makes me wonder whether the failure addressed by
ia64-support.patch was in fact a generic issue with newer $something
(kernel? compiler? dpkg-buildflags?), which happened to only be seen
by ia64 porters because everyone else was compiling and testing mozjs52
with an older $something?

smcv
From: Simon McVittie 
Date: Tue, 3 Jul 2018 23:47:20 +0100
Subject: If executable memory can't be mapped,
 retry without randomization on all architectures

---
 js/src/jit/ProcessExecutableMemory.cpp | 6 --
 1 file changed, 6 deletions(-)

diff --git a/js/src/jit/ProcessExecutableMemory.cpp b/js/src/jit/ProcessExecutableMemory.cpp
index 31836f1..5e7ea5c 100644
--- a/js/src/jit/ProcessExecutableMemory.cpp
+++ b/js/src/jit/ProcessExecutableMemory.cpp
@@ -291,19 +291,13 @@ ReserveProcessExecutableMemory(size_t bytes)
 void* p = MozTaggedAnonymousMmap(randomAddr, bytes, PROT_NONE, MAP_PRIVATE | MAP_ANON,
  -1, 0, "js-executable-memory");
 
-#ifndef __ia64__
-if (p == MAP_FAILED)
-return nullptr;
-#else
 if (p == MAP_FAILED) {
-// the comment above appears to be incorrect on ia64, so retry without the hint
 p = MozTaggedAnonymousMmap(NULL, bytes, PROT_NONE, MAP_PRIVATE | MAP_ANON,
  -1, 0, "js-executable-memory");
 if (p == MAP_FAILED)
 return nullptr;
 }
 return p;
-#endif
 }
 
 static void

Bug#901919: this bug hits hard

[Vladimir Zhuravlev]

Please at the very least spread the word about the 
usercopy_fallback workaround, if the bug cannot be fixed for 
now.


I was also  affected, it took me several hours to find what 
the problem was. There was also an unrelated timidity bug 
that killed sound too in the recent update. So yesterday I 
updated the system and both video and audio went down hard.


By the way, why is this an "important" bug? I think it 
should be classified as "grave" or "critical". It clearly 
broke my system, and made the package unusable.

Bug#901919: nvidia-driver: black screen with the latest Linux kernel

[Andreas Beckmann]

On 2018-07-03 20:31, Andreas Beckmann wrote:
> On 2018-07-03 17:49, Raphael Hertzog wrote:
>> RedHat published a much less invasive patch that you can use
>> in the mean time:
>> https://bugzilla.redhat.com/attachment.cgi?id=1425704
>> (part of https://bugzilla.redhat.com/show_bug.cgi?id=1570493 )
> 
> Thanks for the pointer!

Hi Luca,

I've prepared that in the 390 branch - could you give it a test run
(with all workarounds disabled)?


Andreas

Bug#902197: mozjs52 FTBFS with icu 60.2

[Simon McVittie]

Control: tags -1 + patch

On Sat, 23 Jun 2018 at 16:33:40 +0100, Simon McVittie wrote:
> On Sat, 23 Jun 2018 at 12:52:01 +0300, Adrian Bunk wrote:
> > make[3]: *** No rule to make target 'ParagraphLayout.ao', needed by 
> > '../lib/libiculx.a'.  Stop.
> 
> It looks as though Ubuntu might have a fix for this
> ...
> +  * Don't build-depend on libicu-dev

This didn't work for me: even with a Build-Conflicts, I got the same
failure. However, a better solution seems to be to pass --disable-layoutex
to the bundled icu's configure script, as in the attached. That makes
some sense to me at least: the bundled icu's configure script has an
"automagic" dependency on the icu-le-hb layout engine library, which until
recently we didn't have. However, the bundled icu is incomplete/minimal
and doesn't actually have the source code for the optional paragraph
layout feature that requires icu-le-hb. We can resolve that by turning
the feature off, which isn't a regression because the versions of mozjs52
that compiled successfully didn't have it either.

Having fixed that, I get a different FTBFS: the mozjs command-line entry
point fails to start up. I'll open a separate bug to track that. I can
work around it, but I'm reasonably sure my workaround isn't the proper
solution.

smcv
From: Mike Hommey 
Date: Sat, 19 May 2018 11:23:18 +0900
Subject: Add --disable-layoutex when running ICU configure. r=froydnj,
 a=RyanVM

In some recent ICU update, --enable-layoutex changed from defaulting
to the "same-as-layout" to "yes", so --disable-layout doesn't imply
--disable-layoutex anymore, but we removed the layoutex files.

Applied-upstream: https://hg.mozilla.org/mozilla-unified/rev/31d4880fde31
---
 intl/icu_sources_data.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/intl/icu_sources_data.py b/intl/icu_sources_data.py
index 7d2d983..fc95d6a 100644
--- a/intl/icu_sources_data.py
+++ b/intl/icu_sources_data.py
@@ -122,6 +122,7 @@ def update_data_file(topsrcdir):
  '--disable-extras',
  '--disable-icuio',
  '--disable-layout',
+ '--disable-layoutex',
  '--disable-tests',
  '--disable-samples',
  '--disable-strict'],

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
Followup-For: Bug #902626

> 29.06.2018 23:24, Bernard wrote:
> []
> >> 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)
> > 
> > You mean the kvm acceleration part is not easy with 64bit guests on
> > 32bits hosts? I expect the pure emulation part of qemu to be still
> > maintained, it's its core idea and useful for testing new
> > architectures/configurations.
>
> Nope, it is worse. No qemu developers run any 32bit system at all.
> This qemu-system-i386 works when it is a 64bit x86 application.
> But it fails for you when it is a 32bit application. But no
> developer even _tries_ to run a 32bit qemu application, not to
> say about maintaining anything.
>
> That's why qemu team is considering dropping 32bi host support
> completely. No one actually maintains it, and even keeping
> 32bit qemu executables to be _compilable_ requires quite some
> effort, sometimes non-trivial (recent story was about 64bit

Well, you are basically saying that i386 can no more be a full citizen
architecture supported by Debian.

> atomic counters which does not exist in 32bit app since even
> 64bit increment is implemented in multiple instructions on 32bit)

It's my understanding that's its always possible to reach the desired
atomicity, but at the expense of added code complexity and poor
performance; which upstream may not want to consider if the i386 user
base is shrinking.

> []
> > But looking at the current i386 rank vs. the amd64 one on the
> > Popularity Contest web page, I realize now I should not have been
> > surprised.
>
> 32bit code with today hardware comes with lots of pitfails. Especially
> the memory management in the kernel which should be able to use all
> system memory which is often >4Gb (absolute limit for 32bit addressing).
> All current smartphones comes with 4+Gb RAM so have to run 64bit code.
> There are many other limitations, for example 32bit x86 has less
> available registers in the CPU than 64bit code.
>
> And I suspect that even in-CPU 32bit compatibility support is bit-rotting
> these days - expect more recent CPUs to break old 32bit applications..
>
> >> 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.
> > 
> > So I understand that you want to move the bug in the "won't fix" category. 
> > Fair enough.
>
> I don't "want" it to move, really. I'm saying something slightly different.
> You're running bitrotting configuration. Even if this particular BIG issue
> will be fixed, you risk to hit other issues, and it's good if it will just
> crash or refuse to start, - worse if it result in some data loss...

I think I have understand your point.

> BTW, I've installed stretch i386 chroot and installed qemu-system-x86 on it.
> qemu-system-i386 works just fine here.

You mean kvm accelerated?

> Become curious, installed 32bit kernel too - the same, qemu-system-i386 works
> just fine.

If your main host is amd64, you can't install there a 32bit kernel?

>
> So I *guess* your issue has something to do with your host CPU too, --
> Core2duo is quite old and lacks several kvm-related features found on
> modern CPUs (eg, nested page tables), - without these, some old and
> quite complex code paths in qemu and kernel are being executed.
> Probably bit-rotted too, but here, I definitely can't help you,
> since I just don't have that hardware and there's no where I can
> get it.

I stumbled on that bug:

https://lkml.org/lkml/2017/8/5/145
https://bbs.archlinux.org/viewtopic.php?id=228645

while looking about mine. Here kvm modules didn't even load. Was
corrected in kernel 4.15; I tested here the 4.16 kernel from debian
backport, my bug was still present.

So yes, it's quite possible it's CPU related.

Sincerely.

--

Bernard

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

[Guilhem Moulin]

Hi Michal,

On Tue, 03 Jul 2018 at 18:23:12 +0200, Michal Humpula wrote:
> Entry in /proc/mounts for ZFS is different as it refers to the actual ZFS 
> filesystem not to the devices of the underlying zpool. Which, from my point 
> of 
> view, makes more sense. Do you see a way to export all the required 
> information in sysfs that would be acceptable by you? From top of my head, I 
> can think of something like `/sys/fs/zfs/$FS/devices` where $FS can be 
> something like `tank/my/fs`.

So $FS is what's found in /proc/mounts' first column?  For block devices
this value is not canonical (eg. /dev/mapper/xyz vs. /dev/dm-0 vs.
/dev/disks/by-uuid/$UUID vs. /dev/block/$maj:$min, etc.), but there is a
documented way to normalise it and get the corresponding sysfs
directory·ies dev/block/$maj:$min.  For “traditional” file systems it's
enough to run `stat -L -c%t:%T` and convert the values to base 10; for
btrfs (and I guess some other FS:es I'm not aware of) the list is under
/sys/fs/$FSTYPE/$UUID/devices, where $UUID is canonical and can be
obtained from /proc/mounts' first column using a generic (non
FS-specific) command.

Since ZFS doesn't expose a block device one would need another
documented way to resolve /sys/fs/zfs/$FS.  Hopefully ‘tank/my/fs’ is
unique and can't be aliased to something else, can it?  (Again for LVM,
/dev/mapper/$vgname-$lvname, /dev/dm-$n, /dev/$vgname/$lvname denote the
same device, and AFAIK whether /proc/mounts contains one or the other is
not documented.)

Do the slash characters in ‘tank/my/fs’ hint at a hierarchy, or is it a
flat string?  In the latter case it makes sense to encode the slashes as
hex-sequences (\x2f), like udev does for names under /dev/disk/by-label.
FWIW /proc/mounts encodes special characters such as tabs, linefeeds,
and spaces using octal escapes.  While it's our scripts' job and not
ZFS's to decode these, if there is any mangling under /sys/fs/zfs then
this should be documented.

> I think few other upcoming filesystems will have similar problems, e.g.
> bcachefs.

So it'd be great do expose the sysfs directories in a similar way;
thanks for bringing that up :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#902960: ITP: sweed -- assessment of SNPs for their evolutionary advantage

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: sweed
  Version : 3.2.1
* URL : https://sco.h-its.org/exelixis/web/software/sweed/
* License : GPL
  Programming Lang: C
  Description : assessment of SNPs for their evolutionary advantage


About to be team-maintained with salsa.debian.org/med-team/sweed

Bug#892278: stretch-pu: package reportbug/7.1.7+deb9u1

[Markus Koschany]

Am 03.07.2018 um 21:10 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Wed, 2018-03-07 at 17:53 +0100, Markus Koschany wrote:
>> as requested in #891918 I am hereby filing another stretch-pu update
>> for reportbug, so that we can fix #878088 in stable too. Please find
>> attached the debdiff.
> 
> +reportbug (7.1.7+deb9u1) stretch; urgency=medium
> 
> That version number has already been used in stretch, for the secure-
> testing removal update, so this will need to be rebased on top of that
> to become 7.1.7+deb9u2.
> 
> Assuming that doing so produces no other changes relative to the
> supplied debdiff, please go ahead; apologies for the delay.

I've rebased the changes on top of 7.1.7+deb9u1 without any changes and
uploaded it to Stretch.

Thank you

Markus



signature.asc
Description: OpenPGP digital signature

Bug#826560: progress

[Christoph Lehnberger]

Hi Ross,

any progress about the changes. Maybe I can help somehow.

Best regards,
Christoph

Bug#901919: nvidia-driver: black screen with the latest Linux kernel

[Vincent Lefevre]

On 2018-07-03 20:31:55 +0200, Andreas Beckmann wrote:
> On 2018-07-03 17:49, Raphael Hertzog wrote:
> > Hi,
> > 
> > On Fri, 22 Jun 2018, Luca Boccassi wrote:
> >> I am downgrading as I verified there is a working workaround, add the
> >> following to the kernel cmdline:
> >>
> >> slab_common.usercopy_fallback=y
> > 
> > It's still hitting users hard until they find out this bug report.
> 
> I added a NEWS entry with the workaround, but probably only few of the
> affected users have apt-listbugs installed ...

apt-listchanges

But users may also have upgraded the Linux kernel before the
nvidia-driver version that has this NEWS entry, in particular
because linux-image-4.16.0-2-amd64 4.16.16-2 has already reached
testing, contrary to the new nvidia-driver version.

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

Bug#902959: pluginhook: switch Build-Depends to golang-golang-x-crypto-dev

[Andreas Beckmann]

Source: pluginhook
Version: 0~20150216.0~a320158-2
Severity: serious
Tags: sid buster

The transitional package golang-go.crypto-dev is gone. Please adjust
the Build-Depends and use golang-golang-x-crypto-dev instead.


Andreas

Bug#902893: x11vnc: Error in `x11vnc': corrupted size vs. prev_size: 0x000055f181552530

[Moritz Both]

Hi Nikita,

Thank you for the quick reply. I am afraid it works today - I cannot 
reproduce the problem anymore, although I didn't install any new package 
on the system. Meanwhile, I used the system in question sitting at the 
console, locked the kde console again in the evening... now I can run 
x11vnc from remote without any problem.


I swear yesterday it happened every time I tried.

I will get back to this in case it happens again.

Slightly embarrassed, thanks again,
moritz


Am 03.07.2018 um 09:08 schrieb Nikita Youshchenko:

Hello Mortiz.

Please check latest package version from sid/testing.
(it should not have any dependences not available in stretch)

I believe issue with memory corruption is resolved there.

I can't comment on input issue yet, did not face it.

Nikita



Package: x11vnc
Version: 0.9.13-2
Severity: important

Dear Maintainer,

for me x11vnc does not accept any input although I can see the
remove screen. I use tightvnc viewer 2.6 on windows 7 as the client.

Also, x11vnc shows a memory corruption issue. Output of the session follows.

###
#@#
#@   @#
#@  **  WARNING  **  WARNING  **  WARNING  **  WARNING  **   @#
#@   @#
#@YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!!@#
#@   @#
#@  This means anyone with network access to this computer   @#
#@  may be able to view and control your desktop.@#
#@   @#
#@ >>> If you did not mean to do this Press CTRL-C now!! <<< @#
#@   @#
#@#
#@   @#
#@  You can create an x11vnc password file by running:   @#
#@   @#
#@   x11vnc -storepasswd password /path/to/passfile  @#
#@  or   x11vnc -storepasswd /path/to/passfile   @#
#@  or   x11vnc -storepasswd @#
#@   @#
#@  (the last one will use ~/.vnc/passwd)@#
#@   @#
#@  and then starting x11vnc via:@#
#@   @#
#@  x11vnc -rfbauth /path/to/passfile@#
#@   @#
#@  an existing ~/.vnc/passwd file from another VNC  @#
#@  application will work fine too.  @#
#@   @#
#@  You can also use the -passwdfile or -passwd options. @#
#@  (note -passwd is unsafe if local users are not trusted)  @#
#@   @#
#@  Make sure any -rfbauth and -passwdfile password files@#
#@  cannot be read by untrusted users.   @#
#@   @#
#@  Use x11vnc -usepw to automatically use your  @#
#@  ~/.vnc/passwd or ~/.vnc/passwdfile password files.   @#
#@  (and prompt you to create ~/.vnc/passwd if neither   @#
#@  file exists.)  Under -usepw, x11vnc will exit if it  @#
#@  cannot find a password to use.   @#
#@   @#
#@   @#
#@  Even with a password, the subsequent VNC traffic is  @#
#@  sent in the clear.  Consider tunnelling via ssh(1):  @#
#@   @#
#@http://www.karlrunge.com/x11vnc/#tunnelling@#
#@   @#
#@  Or using the x11vnc SSL options: -ssl and -stunnel   @#
#@   @#
#@  Please Read the documention for more info about  @#
#@  passwords, security, and encryption. @#
#@   @#
#@http://www.karlrunge.com/x11vnc/faq.html#faq-passwd@#
#@   @#
#@  To disable this warning use the -nopw option, or put @#
#@  'nopw' on a line in your ~/.x11vncrc file.   @#
#@   @#
#@#
###
03/07/2018 04:58:08 x11vnc version: 0.9.13 lastmod: 2011-08-10  pid: 26307
03/07/2018 04:58:08 XOpenDisplay("") failed.
03/07/2018 04:58:08 

Bug#902958: obfs4proxy: switch Build-Depends to golang-golang-x-crypto-dev

[Andreas Beckmann]

Source: obfs4proxy
Version: 0.0.7-3
Severity: serious

The transitional package golang-go.crypto-dev is gone. Please adjust
the Build-Depends and use golang-golang-x-crypto-dev instead.


Andreas

Bug#758100: versioned Provides reverted in src:perl for now

[gregor herrmann]

On Tue, 03 Jul 2018 18:50:52 +0300, Niko Tyni wrote:

> On Sun, Jul 09, 2017 at 08:27:57PM +0300, Niko Tyni wrote:
> > The versioned Provides were introduced in sid with perl_5.24.1-5 a week
> > ago, and in the meantime a separate issue (that we could probably have
> > lived with for a bit longer at least) was found in autopkgtest and is
> > tracked as #867081.
> These bugs are now fixed (and deployed on the Debian infrastructure),
> so we could try again.

Yay.
Thanks alot for all the work you put into getting this fixed.
 
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: Cat Stevens: Come On And Dance


signature.asc
Description: Digital Signature

Bug#902957: golang-ed25519-dev: switch Build-Depends to golang-golang-x-crypto-dev

[Andreas Beckmann]

Source: golang-ed25519-dev
Version: 0~20140907.d2b94fd-3
Severity: serious

The transitional package golang-go.crypto-dev is gone. Please adjust
the Build-Depends and use golang-golang-x-crypto-dev instead.


Andreas

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Andrew Bartlett]

On Tue, 2018-07-03 at 23:19 +0200, Josip Rodin wrote:

> Yet, this isn't one, as I've long given up on expecting that upgrade path to
> be fixed - I've reverted to arguing simply that if there's a piece of
> functionality (Unix extensions) in the software, the documentation for the
> software should mention its basic characteristics, esp. those that have been
> known to cause annoying behavior in practice.
> 
> It would be akin to having the Apache documentation describe its HTTPS
> support with two sentences in a manual, and have nothing else whatsoever
> (yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit
> of info, and there's other docs too).

Please take this upstream, with a patch.  This isn't the forum, and
won't achieve your aims.

Sorry,

Andrew Bartlett

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

Bug#902946: Fails to load autofs module through autofs4 alias

[Michael Biebl]

Am 03.07.2018 um 23:10 schrieb Ben Hutchings:
> On Tue, 2018-07-03 at 23:08 +0200, Michael Biebl wrote:
>> Am 03.07.2018 um 20:11 schrieb Ben Hutchings:
>>> Package: systemd
>>> Version: 239-1
>>> Severity: serious
>>>
>>> Starting with Linux 4.18, the autofs4 kernel module is renamed
>>> to autofs, but retaining an 'autofs4' alias.
>>>
>>> Despite the presence of the alias, systemd fails to load the
>>> autofs module:
>>>
>>> systemd[1]: Failed to insert module 'autofs4': No such file or directory
>>>
>>> Opened as 'serious' since I think autofs supports critical
>>> functionality in systemd.
>>
>> Is there a 4.18 kernel available where this can be tested?
> 
> I've uploaded it to experimental and it's currently in NEW.

Ok, thanks.

Just to be sure: Since you marked this found in version 239-1, is this
is a regression or already reproducible with v238. I'm asking because
this bug will block systemd from entering testing.


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



signature.asc
Description: OpenPGP digital signature

Bug#889056: [RFC: original vs fork] Re: Bug#889056: replace apache-mode.el with elpa package

[Nicholas D Steeves]

Hi!

Thank you for your comments, they are much appreciated :-)

On Tue, Jun 26, 2018 at 08:21:41AM +0100, Sean Whitton wrote:
> Hello,
> 
> On Mon, Jun 25 2018, Nicholas D. Steeves wrote:
> 
> > P.S. Will RFSs or ITPs need to be filed for each of the 90
> > emacs-goodies-el subpackages? :-/
> 
> ITPs definitely not.  They are not new in Debian.

What about in the case of forks?  Eg: goodies' apache-mode is the
original, by Jonathan Marten.

https://github.com/martenjj/apachemode is also by Jonathan Marten
  - Notes that it merges the features of three forks back into the
original.
https://github.com/emacs-php/apache-mode/ is a fork by Karl Chen, and
I wonder if it would be as smooth of a transition.  The fork would
be new to Debian...

At any rate, the RFC: Do we want the version by the original author,
which merges the features from three forks, or do we want the version
on MELPA.  If necessary, I'd be happy to contact Jonathan Marten to
ask him if he would be willing to push his package to MELPA.

> I would suggest a joint RFS containing all of them.

Ok, I'll do this for all the legacy subpackages we decide to maintain.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#902956: RM: golang-pty-dev [all] -- NBS; replaced and provided by golang-github-kr-pty-dev

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

golang-pty-dev was a transitional package, the successor package still
provides the old name, so still satisfies the build-dependencies:

* package golang-pty-dev in version 1.0.0-2 is no longer built from source
  - suggested command:
dak rm -m "[auto-cruft] no longer built from source" -s unstable -a all -p 
-R -b golang-pty-dev
  - broken Build-Depends:
rkt: golang-pty-dev


Andreas

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Mon, Jul 02, 2018 at 01:39:34PM +1200, Andrew Bartlett wrote:
> We simply don't have the resources to manage the tasks you suggest

I'm saying one shouldn't send a message to n-close@bugs.d.o and instead
just keep an existing bug open. That change alone actually conserves
resources. Sending a message to the control bot to tag it upstream and
perhaps mark it wontfix or a custom tag called triaged or something like
that - doesn't sound particularly more taxing compared to closing.

> Upstream (non-packaging) bugs filed here at best have to be copied into
> Samba's bugzilla before any progress can be made and the lossy nature
> of that just makes work for everyone. 

This is literally what every other maintainer is taught to do - weed through
the chaff and forward upstream stuff upstream.

> Finally, debates, even meta debates, about unsupported and ancient
> Samba and MacOS versions are simply not productive.  

Yet, this isn't one, as I've long given up on expecting that upgrade path to
be fixed - I've reverted to arguing simply that if there's a piece of
functionality (Unix extensions) in the software, the documentation for the
software should mention its basic characteristics, esp. those that have been
known to cause annoying behavior in practice.

It would be akin to having the Apache documentation describe its HTTPS
support with two sentences in a manual, and have nothing else whatsoever
(yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit
of info, and there's other docs too).

-- 
 2. That which causes joy or happiness.

Bug#902955: transition: liblouis

[Samuel Thibault]

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

Hello,

As seen on
https://release.debian.org/transitions/html/auto-liblouis.html
a liblouis transition needs to take place.

The rdeps do build fine with the new packages.

Samuel

Ben file:

title = "liblouis";
is_affected = .depends ~ "liblouis14" | .depends ~ "liblouis16";
is_good = .depends ~ "liblouis16";
is_bad = .depends ~ "liblouis14";


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

Kernel: Linux 4.17.0 (SMP w/4 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: systemd (via /run/systemd/system)

-- 
Samuel
 sauf que le firewall bloque tout sauf internet
 -+- ben ouais, il bloque ipx/spx ! -+-

Bug#902604: emacs-goodies-el: replace graphviz-dot-mode.el with elpa-graphviz

[Nicholas D Steeves]

On Thu, Jun 28, 2018 at 07:13:18AM -0300, David Bremner wrote:
> Package: emacs-goodies-el
> Version: 37.0
> Severity: normal
> Tags: newcomer
> User: debian-emac...@lists.debian.org
> Usertags: elpafy
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This mode seems to be useful to people, and there's a maintained
> version on melpa/github, so let's package that instead.

Leaving this bug open for a newcomer claim.  graphviz-dot-mode.el was
removed from goodies in commit 21d3accaca567404a130c58a51f963fe7283692b

Comment added to d/control Dependency section as a reminder that the
team will need to elpafy packages such as these before the freeze, if
a newcomer doesn't step forward.


signature.asc
Description: PGP signature

Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

[Dmitry Shachnev]

On Tue, Jul 03, 2018 at 06:00:34PM -0300, eamanu15 wrote:
> Hello Dimitry,
>
> Thanks for you email. I Will make the changes that you recommend.
>
> I have a cuestion for you. When I update to the version 1.40, Do I merge
> all the changelog entries, including 1.35-1 upload, isn't?

Yes, it is better to merge these entries and keep one entry per actual
upload to archive.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#902946: Fails to load autofs module through autofs4 alias

[Michael Biebl]

Am 03.07.2018 um 20:11 schrieb Ben Hutchings:
> Package: systemd
> Version: 239-1
> Severity: serious
> 
> Starting with Linux 4.18, the autofs4 kernel module is renamed
> to autofs, but retaining an 'autofs4' alias.
> 
> Despite the presence of the alias, systemd fails to load the
> autofs module:
> 
> systemd[1]: Failed to insert module 'autofs4': No such file or directory
> 
> Opened as 'serious' since I think autofs supports critical
> functionality in systemd.

Is there a 4.18 kernel available where this can be tested?


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



signature.asc
Description: OpenPGP digital signature

Bug#902946: Fails to load autofs module through autofs4 alias

[Ben Hutchings]

On Tue, 2018-07-03 at 23:08 +0200, Michael Biebl wrote:
> Am 03.07.2018 um 20:11 schrieb Ben Hutchings:
> > Package: systemd
> > Version: 239-1
> > Severity: serious
> > 
> > Starting with Linux 4.18, the autofs4 kernel module is renamed
> > to autofs, but retaining an 'autofs4' alias.
> > 
> > Despite the presence of the alias, systemd fails to load the
> > autofs module:
> > 
> > systemd[1]: Failed to insert module 'autofs4': No such file or directory
> > 
> > Opened as 'serious' since I think autofs supports critical
> > functionality in systemd.
> 
> Is there a 4.18 kernel available where this can be tested?

I've uploaded it to experimental and it's currently in NEW.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman



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

Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

[eamanu15]

Hello Dimitry,

Thanks for you email. I Will make the changes that you recommend.

I have a cuestion for you. When I update to the version 1.40, Do I merge
all the changelog entries, including 1.35-1 upload, isn't?

Thanks
Regards

Arias Emmanuel
eamanu.com


El mar., 3 de jul. de 2018 17:17, Dmitry Shachnev 
escribió:

> Control: merge 898416 898811 900368
>
> Hi Emmanuel!
>
> On Tue, May 29, 2018 at 12:35:25PM -0300, eamanu15 wrote:
> > Package: sponsorship-requests
> > Severity: normal
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "pygithub"
>
> Note that I am merging your three RFS bugs. If you want to ping, just reply
> to the existing bug, not file a new one.
>
> Here are my comments about your changes.
>
> - It would be nice if you based the repository on the existing Git
>   repository [1], rather than starting from scratch.
>
>   Also for new team repositories as this one, it is better to use Gbp-Pq
>   workflow as described in the team wiki [2].
>
> - Please merge the last three changelog entries, as 1.35-1 upload did not
>   happen.
>
> - When building in the current sid, I get Lintian warnings about three
> files
>   shipped in /usr/lib/python3.7/dist-packages/.
>
>   That probably happens because of output of 2to3 is slightly different in
>   Python 3.6 and 3.7 (e.g. files.items() vs. iter(files.items())), and
>   dh_python3 does not remove the file if it does not match.
>
>   I would recommend removing debian/python3-github/usr/lib/python3.*
> manually
>   in debian/rules. Keeping debian-python@ in Cc in case someone has a
> better
>   idea.
>
> - A new stable 1.40 release has been released on June 26th [3].
>   Can you update from alpha to the stable version?
>
>   Also please add uversionmangle to debian/watch (like here [4]), to make
> it
>   treat 1.40 as a higher version than 1.40aN.
>
> [1]:
> https://alioth-archive.debian.org/git/users/kaction-guest/pygithub.git.tar.xz
> [2]: https://wiki.debian.org/Python/GitPackagingPQ
> [3]: https://pypi.org/project/PyGithub/1.40/
> [4]: https://pypi.debian.net/PyGithub/watch
>
> --
> Dmitry Shachnev
>

Bug#902954: CVE-2018-12227

[Moritz Muehlenhoff]

Source: asterisk
Severity: normal
Tags: security

Please see http://downloads.asterisk.org/pub/security/AST-2018-008.html

Cheers,
Moritz

Bug#902943: cryptsetup-initramfs: Encrypted rootfs in LVM is not found after upgrade

[Guilhem Moulin]

On Tue, 03 Jul 2018 at 20:01:02 +0200, doak wrote:
> After system upgrade the system is not bootable anymore due the
> initramfs is unable to find the "source" for the rootfs and boot
> hangs.

Not forever, though.  It drops to a debug shell after ‘rootdelay’
(default 180) seconds, unless you've set the ‘panic=’ boot
parameter.

> linux-debian_crypt UUID=979d71b4-f9a9-45cb-b72e-6c81754ab504 none luks

We're now relying on lvm2's /scripts/local-block/lvm2 to activate the VG
holding our source device, which doesn't work with UUIDs:


https://sources.debian.org/src/lvm2/2.02.176-4.1/debian/initramfs-tools/lvm2/scripts/local-block/lvm2/

I'd argue that this is a bug in lvm2's local-block script.  The very
same problem happens if /usr is held by a dedicated LV (whether / is
held by a different LV in the same VG, in another VG, or by a non mapped
device) and the FS is specified using its UUID in the fstab(5).

If you specify the source device as /dev/mapper/linux-debian or
/dev/linux/debian then you should be able to boot.  “Should”, because
for LUKS we're using UUIDs internally, so right now this won't work.

When the source device is mapped we can use its (mangled) name instead.
But coming up with our own logic to activate VGs is beyond the scope of
cryptsetup IMHO.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#648703: please include rfc speedbar

[Nicholas D Steeves]

On Mon, Nov 14, 2011 at 11:24:15AM +0100, Thomas Koch wrote:
> Package: emacs-goodies-el
> Version: 35.2
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> this looks like a useful addition to the rfc view mode:
> http://www.neilvandyke.org/rfcview/sb-rfcview.el
> 
> Currently the speedbar is not of much help to navigate rfc documents.
> 
> Regards, Thomas Koch

Sorry it took so long for someone to reply to your bug.  The Debian
Emacsen team has recently adopted emacs-goodies-el and we are in the
process of transitioning it to a dummy packages that depends on a
series of non-native elpafied packages.  Consequently, we aren't
adding any new els.

Are you still interested in having this package in Debian?  If so, do
you know of an alternate upstream for this package?  I wasn't able to
find one that either uses a VCs or provides actual releases.  If a
suitable upstream is found we can change this to a RFP bug for an
elpafied package.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#689549: emacs-goodies-el: Add iedit and/or mark-multiple

[Nicholas D Steeves]

Dear Axel,

On Thu, Oct 04, 2012 at 12:41:38AM +0200, Axel Beckert wrote:
> Package: emacs-goodies-el
> Version: 35.2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> via [1] I stumbled over iedit[2] and I think that would be a neat
> addition to emacs-goodies-el. Alternatively [3] (via comments to [1])
> sounds like an alternative for similar features, too.
> 
> [1] 
> http://www.masteringemacs.org/articles/2012/10/02/iedit-interactive-multi-occurrence-editing-in-your-buffer/
> [2] https://github.com/eproxus/emacs-iedit,
> http://www.emacswiki.org/emacs/iedit.el
> [3] https://github.com/magnars/mark-multiple.el

Sorry it took so long for someone to reply to your bug.  The Debian
Emacsen team has recently adopted emacs-goodies-el and we are in the
process of transitioning it to a dummy packages that depends on a
series of non-native elpafied packages.  Consequently, we aren't
adding any new els.

elpa-iedit provides [1] and [2]
[3] states "mark-multiple has been superseded by multiple-cursors"
[4] https://github.com/magnars/multiple-cursors.el

If you would still like [4], please reassign this bug to wnpp and
retitle it to "RFP: multiple-cursors-el -- multiple cursors for
emacs", or file a new bug, or ask me to do it for you, as you prefer
;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#690484: emacs-goodies-el: reasonable to add fill-column-indicator?

[Nicholas D Steeves]

Hi Rob!

On Sun, Oct 14, 2012 at 02:24:50PM -0500, Rob Browning wrote:
> 
> Package: emacs-goodies-el
> Severity: wishlist
> 
> Wondered if this might be a reasonable candidate for inclusion:
> 
>   http://www.emacswiki.org/FillColumnIndicator

As I'm sure you know, we're not adding anything new to
emacs-goodies-el.  Also, I support David's position that we generally
shouldn't package emacswiki els as elpafied packages; however, there
might be a living upstream for this one :-D

  https://github.com/alpaker/Fill-Column-Indicator

If that's something you would still find to be useful, would you
please reassign this bug to wnpp and make it a RFP?  Extra points for
adding the elpafy usertag ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Michael Stapelberg]

On Tue, Jul 3, 2018 at 10:29 PM, Adam D. Barratt 
wrote:

> On Tue, 2018-07-03 at 22:20 +0200, Michael Stapelberg wrote:
> >
> >
> > On Tue, Jul 3, 2018 at 10:01 PM, Adam D. Barratt  > barratt.org.uk> wrote:
> [...]
> > > The metadata for #891919 suggests that it affects the version of
> > > i3-wm
> > > in unstable - is that correct? If it is, then please fix the
> > > package in
> > > unstable first; if not, then please fix the metadata.
> >
> > i3 ≥ 4.14 contain the fix, so the versions in testing and unstable
> > are fixed.
> >
> > I’m not good with the BTS. Can you share the correct command to do
> > what’s required before we can move forward please?
>
> 4.14-1 seems to have been the first unstable upload from that upstream
> release, so either send "fixed 891919 4.14-1" to control@bugs.d.o or
> use the bts tool from devscripts to do the same.
>

Thanks, done.


>
> Regards,
>
> Adam
>



-- 
Best regards,
Michael

Bug#902951: RFP: highlight-chars-el -- highlight specified sets of characters, including whitespace

[Nicholas D Steeves]

P.S. I agree with David that emacswiki projects generally don't
contain "code we want to be adding to debian" (Bug #514518).

I filed this bug for completeness sake rather than because I genuinely
believe the package would be a good fit for Debian.


signature.asc
Description: PGP signature

Bug#584306: Bug#584303: tail.el - Bug reports

[Nicholas D Steeves]

Control: fixed -1 emacs-goodies-el/38.0

Dear Kevin, Peter, and Benjamin,

Sorry this bug wasn't resolved as expected.  The Debian Emacsen team
dropped the now-unmaintained tail.el in commit
a5aa8d7c0c8f8966e4e86bc692575416e0634888 which was part of
emacs-goodies-el/38.0.  The bug associated with the removal of tail.el
is #584305

If an upstream maintainer for tail.el materialises and there is demand
for this package, then we can package it, and this bug can be
reassigned to elpa-tail.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

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

[Jon Westgate]

Package: firefox
Version: 61.0-1
Followup-For: Bug #900469

Dear Maintainer,

If it helps the build of firefox on mozilla.org doesn't have this
problem if you mv /usr/lib/firefox out of the way and untar
firefox-61.0.tar.bz2 in it's place all is good.

-- Package-specific info:

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

Kernel: Linux 4.17.2 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), 
LANGUAGE=en_GB:en (charmap=ISO-8859-1)

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


Versions of packages firefox depends on:
ii  debianutils   4.8.6
ii  fontconfig    2.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-6    2.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig1    2.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.1.0-9
ii  libgdk-pixbuf2.0-0    2.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-0    3.22.30-2
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-0    1.42.1-2
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++6    8.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  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  libxrender1   1:0.9.10-1
ii  libxt6    1:1.1.5-1
ii  procps    2:3.3.15-2
ii  zlib1g    1:1.2.11.dfsg-1

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.16-2
ii  libgtk2.0-0    2.24.32-2

-- no debconf information

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Adam D. Barratt]

On Tue, 2018-07-03 at 22:20 +0200, Michael Stapelberg wrote:
> 
> 
> On Tue, Jul 3, 2018 at 10:01 PM, Adam D. Barratt  barratt.org.uk> wrote:
[...]
> > The metadata for #891919 suggests that it affects the version of
> > i3-wm
> > in unstable - is that correct? If it is, then please fix the
> > package in
> > unstable first; if not, then please fix the metadata.
> 
> i3 ≥ 4.14 contain the fix, so the versions in testing and unstable
> are fixed.
> 
> I’m not good with the BTS. Can you share the correct command to do
> what’s required before we can move forward please?

4.14-1 seems to have been the first unstable upload from that upstream
release, so either send "fixed 891919 4.14-1" to control@bugs.d.o or
use the bts tool from devscripts to do the same.

Regards,

Adam

Bug#902952: tcpreplay: CVE-2018-13112

[Salvatore Bonaccorso]

Source: tcpreplay
Version: 4.2.6-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/appneta/tcpreplay/issues/477

Hi,

The following vulnerability was published for tcpreplay.

CVE-2018-13112[0]:
| get_l2len in common/get.c in Tcpreplay 4.3.0 beta 1 allows remote
| attackers to cause a denial of service (heap-based buffer over-read and
| application crash) via crafted packets, as demonstrated by tcpprep.

its verifiable as well with the upstream attached poc and an ASAN
build of tcpreplay.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-13112
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-13112
[1] https://github.com/appneta/tcpreplay/issues/477

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Michael Stapelberg]

On Tue, Jul 3, 2018 at 10:01 PM, Adam D. Barratt 
wrote:

> Control: tags -1 + moreinfo
>
> On Mon, 2018-03-12 at 19:23 +0100, Michael Stapelberg wrote:
> > I would like to apply the attached update to the i3-wm package to
> > satisfy a user
> > request (#891919) for a backported upstream fix to address a crash
> > when using
> > window marks and restarting i3 in-place.
> >
>
> Apologies for the delay in getting back to you.
>
> The metadata for #891919 suggests that it affects the version of i3-wm
> in unstable - is that correct? If it is, then please fix the package in
> unstable first; if not, then please fix the metadata.
>

i3 ≥ 4.14 contain the fix, so the versions in testing and unstable are
fixed.

I’m not good with the BTS. Can you share the correct command to do what’s
required before we can move forward please?


>
> Regards,
>
> Adam
>



-- 
Best regards,
Michael

Bug#902564: emacs-goodies-el: replace session.el with elpa-session

[Nicholas D Steeves]

On Wed, Jun 27, 2018 at 10:08:58PM -0300, David Bremner wrote:
> Package: emacs-goodies-el
> Version: 37.0
> Severity: normal
> Tags: newcomer
> User: debian-emac...@lists.debian.org
> Usertags: elpafy
> 
> It looks like session.el is worth preserving (there's about 42k
> downloads on melpa), so let's replace it with a dh-elpa based
> elpa-session (or similar name) package.
> 
> There's an updated version on sourceforge at
> 
> http://emacs-session.sourceforge.net/
> 

Leaving this bug open for a newcomer claim.  Session.el was removed
from goodies in commit 344060a9b6fbaa612998a47cb36d995491cd3f27

Comment added to d/control Dependency section as a reminder that the
team will need to elpafy packages such as these before the freeze, if
a newcomer doesn't step forward.


signature.asc
Description: PGP signature

Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

[Dmitry Shachnev]

Control: merge 898416 898811 900368

Hi Emmanuel!

On Tue, May 29, 2018 at 12:35:25PM -0300, eamanu15 wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pygithub"

Note that I am merging your three RFS bugs. If you want to ping, just reply
to the existing bug, not file a new one.

Here are my comments about your changes.

- It would be nice if you based the repository on the existing Git
  repository [1], rather than starting from scratch.

  Also for new team repositories as this one, it is better to use Gbp-Pq
  workflow as described in the team wiki [2].

- Please merge the last three changelog entries, as 1.35-1 upload did not
  happen.

- When building in the current sid, I get Lintian warnings about three files
  shipped in /usr/lib/python3.7/dist-packages/.

  That probably happens because of output of 2to3 is slightly different in
  Python 3.6 and 3.7 (e.g. files.items() vs. iter(files.items())), and
  dh_python3 does not remove the file if it does not match.

  I would recommend removing debian/python3-github/usr/lib/python3.* manually
  in debian/rules. Keeping debian-python@ in Cc in case someone has a better
  idea.

- A new stable 1.40 release has been released on June 26th [3].
  Can you update from alpha to the stable version?

  Also please add uversionmangle to debian/watch (like here [4]), to make it
  treat 1.40 as a higher version than 1.40aN.

[1]: 
https://alioth-archive.debian.org/git/users/kaction-guest/pygithub.git.tar.xz
[2]: https://wiki.debian.org/Python/GitPackagingPQ
[3]: https://pypi.org/project/PyGithub/1.40/
[4]: https://pypi.debian.net/PyGithub/watch

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#891788: stretch-pu: package starplot/0.95.5-8.2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-02-28 at 22:45 +0200, Adrian Bunk wrote:
>    * Add patch from Bernhard Übelacker to fix startup crash.
>  (Closes: #862065)

Please go ahead.

Regards,

Adam

Bug#253513: this is a bug

[Niels Thykier]

Control: severity -1 important

On Wed, 6 Sep 2017 10:52:32 +0100 Daniel Pocock  wrote:
> 
> According to policy
> 
> /usr/share/doc/debian-policy/policy.txt.gz
> 
> "Non-conformance with
>  guidelines denoted by _should_ (or _recommended_) will generally be
>  considered a bug, but will not necessarily render a package unsuitable
>  for distribution."
> 
> and further down:
> 
> "If your package needs to know what hostname to use on (for example)
>  outgoing news and mail messages which are generated locally, you
>  should use the file `/etc/mailname'.  It will contain the portion
>  after the username and `@' (at) sign for email addresses of users on
>  the machine (followed by a newline)."
> 
> Note that policy uses the word "should" for mailname, so wishlist doesn't 
> appear to be a suitable severity for this issue.
> 
> [...]
> 

I am downgrading to important.  While I agree this is not a wishlist
item, "should" is not sufficient to consider it sufficiently important
to potentially block a release (and nor is the fact that it affects new
installations either).

Thanks,
~Niels

Bug#891791: stretch-pu: package local-apt-repository/0.4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-02-28 at 23:02 +0200, Adrian Bunk wrote:
>    * Backport changes from Joachim Breitner to stop breaking apt
>  when the package is removed but not purged. (Closes: #881753)

Please go ahead.

Regards,

Adam

Bug#891784: stretch-pu: package abiword/3.0.2-2+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-02-28 at 22:35 +0200, Adrian Bunk wrote:
>    * Solve binary file conflict between abiword-dbgsym
>  and abiword-plugin-grammar-dbgsym (Closes: #868537).

Please go ahead.

Regards,

Adam

Bug#895537: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-04-12 at 11:42 +0100, James Cowgill wrote:
> This fixes CVE-2018-10017 which is a security bug tagged as "no-DSA"
> by the security team.
> 
> The fix is quite simple and looks correct to me. I've done some
> testing to make sure things still work after this update.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#902934: [pkg-php-pear] Bug#902934: phpunit: Invalid maintainer address pkg-php-p...@lists.alioth.debian.org

[David Prévot]

On Tue, Jul 03, 2018 at 07:25:09PM +, Thorsten Glaser wrote:
> David Prévot dixit:
> 
> >pkg-php-pear != pkg-php-maint
> 
> But all those Alioth lists no longer exist.

This one does, thanks to the lists.alioth.debian.org migration. I do get
your messages to the BTS through it.

https://lists.debian.org/debian-devel-announce/2018/04/msg4.html
https://alioth-lists.debian.net/pipermail/pkg-php-pear/2018-July/011192.html

Regards

David


signature.asc
Description: PGP signature

Bug#892764: stretch-pu: package i3-wm/4.13-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2018-03-12 at 19:23 +0100, Michael Stapelberg wrote:
> I would like to apply the attached update to the i3-wm package to
> satisfy a user
> request (#891919) for a backported upstream fix to address a crash
> when using
> window marks and restarting i3 in-place.
> 

Apologies for the delay in getting back to you.

The metadata for #891919 suggests that it affects the version of i3-wm
in unstable - is that correct? If it is, then please fix the package in
unstable first; if not, then please fix the metadata.

Regards,

Adam

Bug#891793: stretch-pu: package obfsproxy/0.2.13-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-02-28 at 23:17 +0200, Adrian Bunk wrote:
>    * Don't install the broken AppArmor profile. (Closes: #882103)

Please go ahead.

Regards,

Adam

Bug#590994: show-wspace.el is obsolete

[Nicholas D Steeves]

Control: fixed -1 emacs-goodies-el/38.0

On Thu, Jun 28, 2018 at 12:53:42PM -0300, David Bremner wrote:
> 
> 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.

Cross-referencing this bug with Bug #902951 RFP: highlight-chars-el --
highlight specified sets of characters, including whitespace.

show-wspace.el was dropped in emacs-goodies-el/38.0.


signature.asc
Description: PGP signature

Bug#892070: stretch-pu: package obs-build/20160921-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-03-04 at 23:23 +0100, Hector Oron wrote:
[...]
> 2018-03-04 23:13 GMT+01:00 Héctor Orón Martínez :
[...]
> >   I would like to push security fix into stable for `obs-build`.
> >   The patch fixes CVE-2017-14804 as described in #887306.
> >  

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#880037: stretch-pu: package dput-ng/1.13

[Mattia Rizzolo]

On Tue, Jul 03, 2018 at 08:46:30PM +0100, Adam D. Barratt wrote:
> +  * Add "olstable" to the "protected distributions".  Closes: #742136
> 
> s/olstable/oldstable/

Oops, thank you!

> Please go ahead.

Uploaded!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#892031: stretch-pu: package wayland/1.12.0-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2018-03-04 at 12:42 +0100, Héctor Orón Martínez wrote:
>   I would like to apply fix in stable for #889681.
> 

The metadata for that bug report suggests that it still applies to
unstable, possibly because the current changelog is based on the
experimental uploads and contains no reference to either the 1.14.0-2
upload or #889681. Please confirm that the bug is actually fixed in
unstable and fix up the metadata appropriately.

Regards,

Adam

Bug#902951: RFP: highlight-chars-el -- highlight specified sets of characters, including whitespace

[Nicholas D Steeves]

Package: wnpp
Severity: minor

Package name: highlight-chars-el
Version : 0
Upstream Author : Drew Adams (concat "drew.adams" "@" "oracle" ".com")
URL : https://www.emacswiki.org/emacs/highlight-chars.el
License : GPL-3+
Programming Lang: elisp
Description : highlight specified sets of characters, including whitespace

This library provides commands and non-interactive functions for
highlighting the following:
  * Tab chars
  * Hard space (aka no-break space, aka non-breaking space) chars
  * Hard hyphen (aka non-breaking hyphen) chars
  * Trailing whitespace: tabs, spaces, and hard spaces at the end of
a line of text
  * Any set of chars.  One can specify characters in four ways:
(1) individually, (2) using ranges, (3) using character classes
(e.g. [:digit:]), and (4) using character sets
(e.g. `iso-8859-1' or `lao').

One can also specify characters that are excluded from highlighting.

--

I have upgraded the severity from wishlight to minor, because this
package provides functionality that is being dropped from
emacs-goodies-el (see Bug #590994).  When packaging
highlight-chars-el, please take care to use dh-elpa.

Regards,
Nicholas

Bug#891559: stretch-pu: package awffull/3.10.2-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-02-26 at 19:20 +0200, Adrian Bunk wrote:
>    * Don't use removed options in /etc/cron.daily/awffull,
>  thanks to Ludovic Rousseau. (Closes: #728362)

Please go ahead.

Regards,

Adam

Bug#891470: stretch-pu: package auto-complete-el/1.3.1-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-02-25 at 22:59 +0200, Adrian Bunk wrote:
>   * Add upstream fix for emacs25. (Closes: #849240)
> emacs24 and emacs25 are co-installable.
> 
>   * Adjust the emacs dependencies to the emacs versions in stretch.
> (Closes: #746982)
> We ship two emacs versions in stretch, it should be possible
> to remove the older one without forcing auto-complete-el removal.
> 
>   * Set auto-complete-el.emacsen-compat to silence installation
> warning.

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#880037: stretch-pu: package dput-ng/1.13

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2018-05-24 at 11:09 +0200, Mattia Rizzolo wrote:
> Control: tag -1 - moreinfo
> 
> Hi!
> 
> On Sat, Nov 18, 2017 at 06:20:57PM +, Adam D. Barratt wrote:
> > Thanks for looking at fixing these bugs in stable. Unfortunately,
> > I'm
> > not happy to approve the diff as-is; specific comments below.
> 
> Please let me kindly hijack this pu request and propose a new
> debdiff, here attached.
> I included new commits, and stashed out stuff that was nack'ed in the
> first iteration.

+  * Add "olstable" to the "protected distributions".  Closes: #742136

s/olstable/oldstable/

Please go ahead.

Regards,

Adam

Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure

[Niko Tyni]

On Sun, Jun 10, 2018 at 12:36:09AM +0300, Niko Tyni wrote:

> This bisects to
>   
> https://github.com/makamaka/JSON-PP/commit/87bd6a49bacc3a2634cbb1dd0ce9cc75675bb524
> and I've filed
>   https://github.com/makamaka/JSON-PP/issues/39
> about it.
> 
> Not sure yet if it's a bug or if others need to adapt.

Upstream(s) are somewhat quiet, so just noting that this can be worked
around with a build dependency on libjson-xs-perl if there's no better
fix.

For runtime, maybe a Recommends entry would be appropriate?
-- 
Niko Tyni   nt...@debian.org

Bug#902945: igraph: FTBFS with ARPACK 3.6

[Andreas Tille]

Control: forwarded -1 https://github.com/igraph/igraph/issues/1107
Control: tags -1 help
Control: tags -1 upstream

Hi,

thanks for the bug report.  I've forwarded the issue upstream.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Nicholas D Steeves]

On Thu, Jun 28, 2018 at 06:03:52PM -0300, David Bremner wrote:
> 
> 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.

Removed in commit:5b855efd2e7c47dcb7417640c6b27e02e8ca7f17

Of course if someone adopts it as an upstream it can be resurrected as
elpa-sys-apropose and goodies will add a dependency.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#902632: nvidia-legacy-340xx-kernel-dkms: the compiled module fails to load with error 'Invalid module format'

[François Revol]

I also had this bug when upgrading today.

I had this in dmesg:

module: nvidia: Unknown rela relocation: 4

Possibly some issue with the linker or the elf loader in the newer kernel.


Anyway, I just upgraded the kernel to 4.16 and added the correct arg to
/etc/defaults/grub and it's working again.

Bug#902934: [pkg-php-pear] Bug#902934: phpunit: Invalid maintainer address pkg-php-p...@lists.alioth.debian.org

[Thorsten Glaser]

David Prévot dixit:

>pkg-php-pear != pkg-php-maint

But all those Alioth lists no longer exist.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#902938: kerneloops-applet takes 100% of a core

[François Revol]

I should add I'm using gnome-shell as DE. I didn't really test another
desktop recently but I could try the fallback session.

François.

Bug#902950: libjpeg-turbo: CVE-2018-1152

[Salvatore Bonaccorso]

Source: libjpeg-turbo
Version: 1:1.5.1-2
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for libjpeg-turbo.

CVE-2018-1152[0]:
| libjpeg-turbo 1.5.90 is vulnerable to a denial of service
| vulnerability caused by a divide by zero when processing a crafted BMP
| image.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1152
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1152

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#892278: stretch-pu: package reportbug/7.1.7+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2018-03-07 at 17:53 +0100, Markus Koschany wrote:
> as requested in #891918 I am hereby filing another stretch-pu update
> for reportbug, so that we can fix #878088 in stable too. Please find
> attached the debdiff.

+reportbug (7.1.7+deb9u1) stretch; urgency=medium

That version number has already been used in stretch, for the secure-
testing removal update, so this will need to be rebased on top of that
to become 7.1.7+deb9u2.

Assuming that doing so produces no other changes relative to the
supplied debdiff, please go ahead; apologies for the delay.

Regards,

Adam

Bug#902935: units_cur: missing input validation

[Stephen Kitt]

Control: forwarded adri...@gnu.org

Hi Adrian,

I thought you’d be interested in this bug report... A straightforward partial
fix would be to switch to the https URIs, better still would be to add
certificate validation of some sort, but I think a real fix would involve
format validation and data sanitization (as Jakub mentions).

Regards,

Stephen


On Tue, 3 Jul 2018 18:55:40 +0200, Jakub Wilk  wrote:

> Package: units
> Version: 2.17-1
> Tags: security
> 
> units_cur does no sanitization of the data it downloads. Malicious 
> operators of the servers or man-in-the-middle attackers[*] could exploit 
> this to execute arbitrary code.
> 
> As a proof of concept, I patched units_cur to emulate Yahoo returning 
> malicious data. After updating the data, /var/lib/units/currency.units 
> looks like this:
> 
>southkoreawon1|0
>!set PAGER cowsay${IFS}pwned;exit;
># US$
> 
> And this happens:
> 
>$ units
>Currency exchange rates from finance.yahoo.com on 2018-07-03
>3048 units, 109 prefixes, 109 nonlinear units
> 
>You have: help kg
> ___
>< pwned >
> ---
>\   ^__^
> \  (oo)\___
>(__)\   )\/\
>||w |
>|| ||
> 
> 
> [*] Conveniently, all the data in downloaded over HTTP, so there's no 
> authentication.
> 
> -- 
> Jakub Wilk


pgpYuAsSw91U3.pgp
Description: OpenPGP digital signature

Bug#886777: crashes with Mustek scanner which worked before

[W. Martin Borgert]

On 2018-01-11 10:08, W. Martin Borgert wrote:
> I can try an older kernel, but because it works in jessie, I
> assume something purely user space, right?

Same exception with

Linux 3.16.0-6-amd64 #1 SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64 
GNU/Linux

Any more ideas? The workaround with the Jessie chroot is OK, but.. ;~)

Bug#902949: RFS: elpy/1.22.0-1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear Chris,

I have CCed you because you've sponsored past releases of Elpy.  To
add to the changelog, I realised that it would ease long-term
maintenance to make 0001-Disable-failing-tests.patch more granular—at
a minimum, a patch for a test known to always fail on buildd, and a
patch that tests interoperation with a package that Debian does not
provide.

Dear mentors,

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

Package name: elpy
Version : 1.22.0-1
Upstream Author : Jorgen Schaefer 
URL : https://github.com/jorgenschaefer/elpy
License : GPL-3+
Section : devel

It builds this binary package:

  elpa-elpy  - Emacs Python Development Environment

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.22.0-1.dsc

Or clone with git:

  git clone https://salsa.debian.org/emacsen-team/elpy.git

More information about elpy can be obtained from 
https://github.com/jorgenschaefer/elpy

Changes since the last upload:

elpy (1.22.0-1) unstable; urgency=medium

  [ Nicholas D Steeves ]
  * New upstream version.
  * Add 0002-Disable-tests-for-black-code-formatter.patch
- Debian does not yet provide a package for Black, "the uncompromising
  Python code formatter" (https://github.com/ambv/black).
- Disable these tests until there is something to test.
  * Rename 0001-Disable-failing-tests.patch to
-> 0001-Disable-test-shell-send-region-or-buffer.patch

 -- Nicholas D Steeves   Tue, 03 Jul 2018 14:39:24 -0400

elpy (1.21.0-1) unstable; urgency=medium


Regards,
Nicholas D Steeves

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 03/07/2018 à 20:01, Thorsten Glaser a écrit :

> I’m not sure… building (and then running) most of tarent’s
> software products, which unfortunately are often not publicly
> available due to them containing customer-relevant information
> (some is OSS though).

I'm only referring to issues with Maven and its dependencies, like the
one you reported in #901881. I can't do much about not packaged
applications.

Bug#902948: drop upstart-mode.el?

[Nicholas D Steeves]

Source: emacs-goodies-el
Version: 38.0
Severity: normal

I couldn't find an active upstream for this one, Debian hasn't shipped
with upstart support since Jessie, Ubuntu switched away from it for
15.04 (spring 2015) and their 14.04 LTS will reach EOL shortly before
Buster is released.  On the other hand, Wikipedia claims it's still
used in Chromium/Chrome OS, RHEL/CentOS/Scientific/Oracle 6, and LG's
webOS-based devices and appliances.

Stig, as the author of this mode are you interested in maintaining it
as an upstream?  The Debian Emacsen team is in the process of
transitioning src:emacs-goodies-el from a native package of bundled
lisp files to a dummy package that depends on a series of elpafied
non-native packages with independent upstreams.

Cheers,
Nicholas

Bug#902947: seafile-daemon and seafile-cli are unusable in 6.2.0

[Moritz Schlarb]

Source: seafile
Version: 6.2.0-1
Severity: serious
Tags: upstream
Justification: Policy 3.5

This bug is mainly to prevent migration of the 6.2.0 package.

Upstream is working on removing the ccnet dependency, but right now they've
only done that for the non-python parts of the package.



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

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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#901919: nvidia-driver: black screen with the latest Linux kernel

[Andreas Beckmann]

On 2018-07-03 17:49, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 22 Jun 2018, Luca Boccassi wrote:
>> I am downgrading as I verified there is a working workaround, add the
>> following to the kernel cmdline:
>>
>> slab_common.usercopy_fallback=y
> 
> It's still hitting users hard until they find out this bug report.

I added a NEWS entry with the workaround, but probably only few of the
affected users have apt-listbugs installed ...

>> It might be possible to fix, and someone at gr security published a
>> patch that among other things changes the module to use the correct API
>> (although for an older version):
>> https://www.grsecurity.net/~paxguy1/nvidia-drivers-387.12-pax.patch
>>
>> but given it's non-trivial and there is a working cmdline workaround,
>> I'm not going to try and apply that patch, and Nvidia is looking into
>> it.
> 
> RedHat published a much less invasive patch that you can use
> in the mean time:
> https://bugzilla.redhat.com/attachment.cgi?id=1425704
> (part of https://bugzilla.redhat.com/show_bug.cgi?id=1570493 )

Thanks for the pointer!

> 
> In 
> https://devtalk.nvidia.com/default/topic/1031067/linux/-linux416-nvidia-390-48-nvidia_stack_cache-rip-0010-usercopy_warn-0x7e-0xa0/post/5268599/#5268599
>  someone confirmed that the above patch works so it's no longer "untested" 
> contrary to what its author said.
> 
> Otherwise, according to various bug reports, it seems to not happen in
> version 396.24 although the above patch seems to not have been applied
> in this version. Maybe you could update the package to this version at
> least in experimental?

396.xx sitting in experimental/NEW for a month or so now ...


Andreas

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 15, 2018 at 01:06:43PM +0100]:
> Thank you for this.
> 
> Let's use POSIX.1-2017 rather than relying on the download filenames.
> 
> Please find a revised patch below; hopefully Gunnar will renew his
> second, and perhaps you'll second too, Simon.  Again, all that the patch
> does is:

Sorry for the delay!

Of course, I second the following text.

> - replace the string "SUSv3" with "POSIX.1-2017" wherever it appears
> - update the footnote which gives the download URI for the standard
> 
> > or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> > to refer to the latest version of the POSIX.1 standard.
> 
> This is an interesting suggestion.  So far as I can see the only
> advantage to this is that we don't need Policy bugs to bump the version
> of the standard we target.  That does not strike me as a large enough
> advantage to justify giving up explicit control over the version of the
> standard that applies to Debian -- do you see other advantages?
> 
> Patch:
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 90ae58a..f31a3b4 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >  
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
> > Command
> >  Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +POSIX.1-2017.. [#]_
> >  
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -238,13 +238,13 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >  
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > +If a shell script requires non-POSIX.1-2017 features from the shell 
> > interpreter
> >  other than those listed above, the appropriate shell must be specified
> >  in the first line of the script (e.g., ``#!/bin/bash``) and the package
> >  must depend on the package providing the shell (unless the shell package
> >  is marked "Essential", as in the case of ``bash``).
> >  
> > -You may wish to restrict your script to SUSv3 features plus the above
> > +You may wish to restrict your script to POSIX.1-2017 features plus the 
> > above
> >  set when possible so that it may use ``/bin/sh`` as its interpreter.
> >  Checking your script with ``checkbashisms`` from the devscripts package
> >  or running your script with an alternate shell such as ``posh`` may help
> > @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> > complicated and difficult to manage.
> >  
> >  .. [#]
> > -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> > -   (POSIX), and is available on the World Wide Web from `The Open
> > -   Group `_ after free
> > -   registration.
> > +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> > +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> > +   available on the World Wide Web from `The Open Group
> > +   `_.
> >  
> >  .. [#]
> > These features are in widespread use in the Linux community and are
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d85c00..32619e8 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -479,7 +479,7 @@ configurable values should not be placed directly in 
> > the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> >  extra file should be sourced by the script when the script runs. It must
> > -contain only variable settings and comments in SUSv3 ``sh`` format. It
> > +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. 
> > It
> >  may either be a ``conffile`` or a configuration file maintained by the
> >  package maintainer scripts. See :ref:`s-config-files` for
> >  more details.


signature.asc
Description: PGP signature

Bug#902946: Fails to load autofs module through autofs4 alias

[Ben Hutchings]

Package: systemd
Version: 239-1
Severity: serious

Starting with Linux 4.18, the autofs4 kernel module is renamed
to autofs, but retaining an 'autofs4' alias.

Despite the presence of the alias, systemd fails to load the
autofs module:

systemd[1]: Failed to insert module 'autofs4': No such file or directory

Opened as 'serious' since I think autofs supports critical
functionality in systemd.

Ben.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-4
ii  libaudit11:2.8.3-1
ii  libblkid12.32-0.1
ii  libc62.27-3
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.3-4
ii  libgcrypt20  1.8.3-1
ii  libgnutls30  3.5.18-1
ii  libgpg-error01.31-1
ii  libidn11 1.33-2.2
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32-0.1
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.3-2
ii  libselinux1  2.8-1
ii  libsystemd0  239-1
ii  mount2.32-0.1
ii  procps   2:3.3.15-2
ii  util-linux   2.32-0.1

Versions of packages systemd recommends:
ii  dbus1.12.8-3
ii  libpam-systemd  239-1

Versions of packages systemd suggests:
ii  policykit-10.105-20
ii  systemd-container  239-1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131~1.gbp0170b7
ii  udev 239-1

-- no debconf information

Bug#902945: igraph: FTBFS with ARPACK 3.6

[Graham Inggs]

Source: igraph
Version: 0.7.1-2.1
Severity: serious
Tags: ftbfs

Hi maintainer

Since the upload of arpack 3.6.0-1 to unstable, igraph FTBFS [1] with
the following test failures:

BLAS, LAPACK and ARPACK based functions

191: Basic BLAS functions (igraph_blas_*):   ok
192: Dense symmetric eigenvalues and eigenvectors (igraph_lapack_dsyevr): ok
193: Dense non-symmetric eigenvalues and eigenvectors (igraph_lapack_dgeev): ok
194: Dense non-symmetric eigenvalues and eigenvectors (igraph_lapack_dgeevx): ok
195: Solving linear systems with LU factorization (igraph_lapack_dgesv): ok
196: Upper Hessenberg transformation (igraph_lapack_dgehrd): ok
197: Eigenvector centrality (igraph_eigenvector_centrality): FAILED
(arpack.at:59)
198: Non-symmetric ARPACK solver (igraph_arpack_rnsolve): FAILED (arpack.at:66)

Bipartite graphs

199: Create bipartite graphs (igraph_create_bipartite): ok
200: Projection of bipartite graphs (igraph_bipartite_projection): ok

Centralization

201: Centralization (igraph_centralization_*):   FAILED
(centralization.at:26)

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/history/amd64/igraph.html

Bug#902944: kamailio: Support for a kamailio-dev package for external modules?

[Guillem Jover]

Source: kamailio
Source-Version: 5.1.4-1
Severity: wishlist

Hi!

We've got several local kamailio modules, and it would be nice to be
able to build them separately and not have to hook them into the
kamailio source and build systems. I suppose others might find this
useful too.

I started pondering what adding support for this would imply, and I
think the first step is whether this is something you think upstream
and you'd be happy supporting? It could be that the internal interfaces
are completely unstable and providing this might be a support nightmare,
for example, or other similar concerns.

I think what would be needed is:

  - Support installing the library .so symlinks into the -dev package.
(The module .so I think would need to stay in the main and module
packages, because some stuff loads them as module.so directly?)
  - Support installing the kamailio core, library and module .h files
into the -dev package. AFAIUI modules can have inter-module
dependencies and they might use interfaces from both kamailio core
itself, the shared libraries or other modules.
  - Provide a pkg-config file with the necessary compile and link runes
(-I, -L, -rpath and similar) to be able to build 3rd party modules
easily.

While checking this, I noticed there's a src/lib/Makefile.defs, which
has a TYPE variable to install headers and similar, but it does not
appear to be currently used?

Thanks,
Guillem

Bug#902837: Bug#902839: ITP: elpa-bm -- visible bookmarks in Emacs buffers

[Nicholas D Steeves]

This one is ready to sponsor from git.

  git clone https://salsa.debian.org/emacsen-team/bm-el.git


signature.asc
Description: PGP signature

Bug#902942: systemd: please ship man/*.xml files

[Dominique Dumont]

Package: systemd
Version: 239-3
Severity: wishlist

Dear Maintainer,

libconfig-model-systemd-perl provides a model so that cme command can
check or edit some systemd configuration files. [1]

This systemd model is generated [2] from the systemd documentation provided
in man/*.xml (man pages are not used because they are much harder to parse)

Currently this model is generated upstream and the generated model is
shipped in the source tarball [3] of libconfig-model-systemd-perl.

To be compliant with Debian policy, libconfig-model-systemd-perl package
should:
* drop systemd model from upstream tarball
* regenerate systemd model from systemd xml files

The latter should be done using xml files shipped as binary package,
either in systemd package (along the man pages) or in a systemd-source
package.

Could you ship these xml file in a binary package ?

All the best

[1] 
https://github.com/dod38fr/config-model/wiki/Managing-systemd-configuration-with-cme
[2] 
https://github.com/dod38fr/config-model-systemd/blob/master/contrib/parse-man.pl
[3] 
https://cpan.metacpan.org/authors/id/D/DD/DDUMONT/Config-Model-Systemd-0.238.2.tar.gz

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

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

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


-- Package-specific info:

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-4+b1
ii  libaudit11:2.8.3-1
ii  libblkid12.32-0.1
ii  libc62.27-3
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.3-4
ii  libgcrypt20  1.8.3-1
ii  libgnutls30  3.5.18-1
ii  libgpg-error01.31-1
ii  libidn11 1.33-2.2
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32-0.1
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  239-3
ii  mount2.32-0.1
ii  procps   2:3.3.15-2
ii  util-linux   2.32-0.1

Versions of packages systemd recommends:
ii  dbus1.12.8-3
ii  libpam-systemd  239-3

Versions of packages systemd suggests:
ii  policykit-10.105-20
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 239-3

-- no debconf information

Bug#902943: cryptsetup-initramfs: Encrypted rootfs in LVM is not found after upgrade

[doak]

Package: cryptsetup-initramfs
Version: 2:2.0.3-4
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   After system upgrade the system is not bootable anymore due the
   initramfs is unable to find the "source" for the rootfs and boot
   hangs.
   Before the upgrade this worked seamlessly for a long time, UUID of FS
   did not change recently.

   When breaking into initramfs (kernel argument 'break'), I am able to
   activate the LVM logical volume manually with 'lvm lvchange -a y linux'.
   Resuming the boot after that works, i.e. the passphrase is asked and
   boot continues after successful decryption.

   Please let me know if I should provide more detailed debug
   information.

   Regards,
   doak


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.16.0-2-amd64 root=/dev/mapper/linux-debian_crypt ro quiet

-- /etc/crypttab
linux-debian_crypt UUID=979d71b4-f9a9-45cb-b72e-6c81754ab504 none luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/linux-debian_crypt /   ext4errors=remount-ro 0  
 1
# /boot was on /dev/sda5 during installation
UUID=42edef9b-e7dc-4ceb-a5e1-05d958d6ea6f /boot ext4 defaults 0 2
/SWAP   noneswapdefaults0   0

-- lsmod
Module  Size  Used by
ctr16384  6
ccm20480  9
cmac   16384  0
rfcomm 86016  0
fuse  118784  3
ipt_MASQUERADE 16384  1
nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
nf_conntrack_netlink49152  0
nfnetlink  16384  2 nf_conntrack_netlink
xfrm_user  45056  1
xfrm_algo  16384  1 xfrm_user
iptable_nat16384  1
nf_conntrack_ipv4  16384  3
nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
nf_nat_ipv416384  1 iptable_nat
xt_addrtype16384  2
xt_conntrack   16384  1
nf_nat 36864  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack  151552  7 
nf_conntrack_ipv4,ipt_MASQUERADE,nf_conntrack_netlink,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
libcrc32c  16384  2 nf_conntrack,nf_nat
br_netfilter   24576  0
bridge184320  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
bnep   24576  2
overlay   102400  0
ebtable_filter 16384  0
ebtables   36864  1 ebtable_filter
devlink61440  0
ip6table_filter16384  0
ip6_tables 32768  1 ip6table_filter
iptable_filter 16384  1
snd_hda_codec_hdmi 57344  1
binfmt_misc20480  1
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
coretemp   16384  0
kvm_intel 180224  0
uvcvideo  106496  0
arc4   16384  2
kvm   704512  1 kvm_intel
videobuf2_vmalloc  16384  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 28672  1 uvcvideo
videobuf2_common   49152  2 uvcvideo,videobuf2_v4l2
irqbypass  16384  1 kvm
iTCO_wdt   16384  0
cdc_mbim   16384  0
wmi_bmof   16384  0
btusb  53248  0
iwlmvm290816  0
iTCO_vendor_support16384  1 iTCO_wdt
videodev  204800  3 uvcvideo,videobuf2_common,videobuf2_v4l2
mac80211  802816  1 iwlmvm
cdc_wdm24576  1 cdc_mbim
btrtl  16384  1 btusb
intel_cstate   16384  0
btbcm  16384  1 btusb
media  45056  2 uvcvideo,videodev
cdc_ncm40960  1 cdc_mbim
btintel24576  1 btusb
intel_uncore  131072  0
usbnet 49152  2 cdc_mbim,cdc_ncm
iwlwifi   225280  1 iwlmvm
i915 1650688  20
bluetooth 626688  14 btrtl,btintel,bnep,btbcm,rfcomm,btusb
mii16384  1 usbnet
cdc_acm32768  2
intel_rapl_perf16384  0
evdev  28672  29
joydev 24576  0
snd_hda_codec_realtek   110592  1
serio_raw  16384  0
snd_hda_codec_generic86016  1 snd_hda_codec_realtek
pcspkr 16384  0
snd_hda_intel  45056  8
drbg   28672  1
ansi_cprng 16384  0
snd_hda_codec 151552  4 
snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
ecdh_generic   24576  1 bluetooth
cfg80211  737280  3 iwlmvm,iwlwifi,mac80211
sg 36864  0
rtsx_pci_ms20480  0
snd_hda_core   94208  5 

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Thorsten Glaser]

On Tue, 3 Jul 2018, Emmanuel Bourg wrote:

> Please report any incompatibility spotted when running Maven with Java 8
> and I'll see if it can be fixed. What is the scope of the ecosystem you
> envision?

I’m not sure… building (and then running) most of tarent’s
software products, which unfortunately are often not publicly
available due to them containing customer-relevant information
(some is OSS though).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#901164: caja-eiciel FTCBFS: configure.ac hard codes build architecture pkg-config

[Helmut Grohne]

On Tue, Jul 03, 2018 at 05:51:08PM +0200, Alex ARNAUD wrote:
> The Github link here is not for Caja but for Nautilus. Here we're talking
> about Caja only. So https://github.com/darkshram/mate-eiciel is the right
> place for us.

Well, since caja is the fork, working upstream means nautilus, no?

> What file manager are you using? Caja or Nautilus?

coreutils

> Are you able to use eiciel with Caja? If not, I assume it's why there is a
> fork.

No clue, I just tried to build it (as part of QA). That failed and I
sent a patch. I've sent more than 1000 patches fixing build failures now
and I admit that I don't try using each and every package that I fix.

Looks like upstream's mail bounces. Is nautilus eiciel dead upstream? If
so maybe take over rather than fork?

Helmut

Bug#898711: myspell-da: Convert into dummy transitional package depending on hunspell-da

[Jonas Smedegaard]

Quoting Agustin Martin (2018-07-03 18:31:16)
> Control: severity -1 wishlist
> 
> On Tue, May 15, 2018 at 01:52:32PM +0200, Pander wrote:
> > Package: myspell-da
> > Version: 1.6.36-9
> > Severity: normal
> > Tags: l10n
> > 
> > Convert myspell-bg into dummy transitional package depending on
> > hunspell-da and gradually phase out myspell-da. Myspell is no longer
> > shipped and most other packages have migrated to the Hunspell package
> > names. For example, see also
> > https://packages.debian.org/stretch/myspell-af and
> > https://packages.debian.org/stretch/myspell-ca Note that the internal
> > format of the files for Myspell and Hunspell is identical, so this
> > concerns only the packaging.

> In this particular case, lo-dicts ships hunspell-da, however from 
> different author
> 
> hunspell-da: 
>   Copyright (C) 2014 Foreningen for frit tilgængelige sprogværktøjer
>   Website: http://www.stavekontrolden.dk
>   E-mail: i...@stavekontrolden.dk
>   License: GPL 2.0/LGPL 2.1/MPL 1.1 tri-license
> 
> myspell-da:
>   Copyright (C) 1998-2004 Skåne Sjælland Linux User Group 
>  and the contributors.
>   License: GPL 2+
>   Website: http://da.speling.org/fejlmelding/  
> 
> In these cases, we usually select one of them only if there is a clear 
> consensus that one is clearly better than the other. Otherwise, I 
> personally prefer to keep both.
> 
> Jonas, what the Danish users groups think about these two dicts?
> 
> Considering current versions, if it is clear that hunspell-da should 
> supersede myspell-da, it is better if lo-dicts ships the transitional 
> myspell-da. Once it reaches testing we can remove old myspell-da and 
> the transition would be complete.
> 
> Note that this requires agreement from myspell-da maintainer(s).

hunspell-da and myspell-da is indeed different dictionaries.

They cannot be merged due to different licensing: The oldest and most 
comprehensive project (DSDO) chose a strong copyleft license, and the 
newer project (Stavekontrolden) started from scratch to be able to 
choose a different license.

myspell-da is _not_ obsolete - it is arguably superior to hunspell-da 
despite its older - but compatible - container format.


 - Jonas

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

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


signature.asc
Description: signature

Bug#880952: maven: Version display does not disable bold/color output in non-interactive context

[Emmanuel Bourg]

fixed 880952 3.5.2-1
close 880952

Bug#902941: libuv1/1.21.0-1 appears to break lua-luv/1.9.1-0-2 autopkgtest

[Paul Gevers]

Source: libuv1, lua-luv
Version: libuv1/1.21.0-1
Version: lua-luv/1.9.1-0-2
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of libuv1 the autopkgtest of lua-luv started to
fail in unstable and testing. I have copied the error below.

Currently this regression is delaying the migration of libuv1 to testing
by 13 days. Could you please investigate the situation and resolve which
package needs to be fixed and assign it?

More information about this bug and the reason of it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lua-luv/550804/log.gz

ok 9 fs - fs.scandir
  ./tests/test-fs.lua:83: UNKNOWN FS TYPE 29

  stack traceback:
[C]: in function 'assert'
./tests/test-fs.lua:83: in function 'fn'
./lib/tap.lua:53: in function <./lib/tap.lua:42>
[C]: in function 'xpcall'
./lib/tap.lua:42: in function 'run'
./lib/tap.lua:136: in function 'tap'
tests/run.lua:35: in main chunk
[C]: ?
not ok 10 fs - fs.realpath



signature.asc
Description: OpenPGP digital signature

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Le 03/07/2018 à 16:53, Thorsten Glaser a écrit :

> This will break all kinds of things here, we’ll need Maven and
> the whole ecosystem around it.

Please report any incompatibility spotted when running Maven with Java 8
and I'll see if it can be fixed. What is the scope of the ecosystem you
envision?