Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[felipe]

Thanks for the response, Bastian!

I have been using this option since kernel 4.15, when the AMD Display Code was 
merged. Without these options the card
would panic and the system would crash.

Kernel 4.17 and 4.18 finds and load the firmware without problems and the 
system is stable.

Here is a part of /var/log/syslog booting from kernel 4.18 and using 
radeon.si_support=0 amdgpu.si_support=1


kernel: [8.680256] [drm] radeon kernel modesetting enabled.
kernel: [8.758332] EXT4-fs (sdb1): mounted filesystem with ordered data 
mode. Opts: (null)
kernel: [8.834082] radeon :01:00.0: SI support disabled by module param
kernel: [8.900903] snd_hda_intel :01:00.1: Handle vga_switcheroo audio 
client
kernel: [8.900907] snd_hda_intel :01:00.1: Force to non-snoop mode
kernel: [8.95] input: HDA ATI HDMI HDMI/DP,pcm=3 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input13
kernel: [8.988999] input: HDA ATI HDMI HDMI/DP,pcm=7 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input14
kernel: [8.989111] input: HDA ATI HDMI HDMI/DP,pcm=8 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input15
kernel: [8.989225] input: HDA ATI HDMI HDMI/DP,pcm=9 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input16
kernel: [8.989315] input: HDA ATI HDMI HDMI/DP,pcm=10 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input17
kernel: [8.989374] input: HDA ATI HDMI HDMI/DP,pcm=11 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input18
kernel: [9.073407] snd_hda_codec_realtek hdaudioC1D0: ALC1150: SKU not 
ready 0x
kernel: [9.073964] snd_hda_codec_realtek hdaudioC1D0: autoconfig for 
ALC1150: line_outs=4 (0x14/0x15/0x16/0x17/0x0)
type:line
kernel: [9.073968] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
kernel: [9.073977] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
kernel: [9.073980] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
kernel: [9.073983] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x11/0x1e
kernel: [9.073985] snd_hda_codec_realtek hdaudioC1D0:inputs:
kernel: [9.073989] snd_hda_codec_realtek hdaudioC1D0:  Front Mic=0x19
kernel: [9.073993] snd_hda_codec_realtek hdaudioC1D0:  Rear Mic=0x18
kernel: [9.073996] snd_hda_codec_realtek hdaudioC1D0:  Line=0x1a
kernel: [9.090101] input: HDA Digital PCBeep as 
/devices/pci:00/:00:14.2/sound/card1/input19
kernel: [9.090934] input: HDA ATI SB Front Mic as 
/devices/pci:00/:00:14.2/sound/card1/input20
kernel: [9.091020] input: HDA ATI SB Rear Mic as 
/devices/pci:00/:00:14.2/sound/card1/input21
kernel: [9.091102] input: HDA ATI SB Line as 
/devices/pci:00/:00:14.2/sound/card1/input22
kernel: [9.091189] input: HDA ATI SB Line Out Front as 
/devices/pci:00/:00:14.2/sound/card1/input23
kernel: [9.091316] input: HDA ATI SB Line Out Surround as 
/devices/pci:00/:00:14.2/sound/card1/input24
kernel: [9.091407] input: HDA ATI SB Line Out CLFE as 
/devices/pci:00/:00:14.2/sound/card1/input25
kernel: [9.091482] input: HDA ATI SB Line Out Side as 
/devices/pci:00/:00:14.2/sound/card1/input26
kernel: [9.091559] input: HDA ATI SB Front Headphone as 
/devices/pci:00/:00:14.2/sound/card1/input27
kernel: [9.423033] [drm] amdgpu kernel modesetting enabled.
kernel: [9.423511] Adding 15625212k swap on /dev/sda2.  Priority:-2 
extents:1 across:15625212k FS
kernel: [9.489482] usbcore: registered new interface driver snd-usb-audio
kernel: [9.509359] CRAT table not found
kernel: [9.509362] Virtual CRAT table created for CPU
kernel: [9.509362] Parsing CRAT table with 1 nodes
kernel: [9.509364] Creating topology SYSFS entries
kernel: [9.509376] Topology: Add CPU node
kernel: [9.509376] Finished initializing topology
kernel: [9.509435] kfd kfd: Initialized module
kernel: [9.509899] [drm] initializing kernel modesetting (PITCAIRN 
0x1002:0x6810 0x174B:0xE271 0x00).
kernel: [9.509912] [drm] register mmio base: 0xFEA0
kernel: [9.509912] [drm] register mmio size: 262144
kernel: [9.509915] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
kernel: [9.509916] [drm] probing mlw for device 1002:5a16 = 31cd02
kernel: [9.509917] [drm] add ip block number 0 
kernel: [9.509918] [drm] add ip block number 1 
kernel: [9.509919] [drm] add ip block number 2 
kernel: [9.509920] [drm] add ip block number 3 
kernel: [9.509920] [drm] add ip block number 4 
kernel: [9.509921] [drm] add ip block number 5 
kernel: [9.509921] [drm] add ip block number 6 
kernel: [9.509924] amdgpu :01:00.0: kfd not supported on this ASIC
kernel: [9.537536] [drm] BIOS signature incorrect 5b 7
kernel: [9.537593] ATOM BIOS: 113-1E27100-O48
kernel: [9.537799] [drm] vm size is 64 

Bug#904428: linux-image-4.17.0-1-amd64: sound pops/clicks with snd_hda_intel unless power saving is disabled

[Salvatore Bonaccorso]

Source: linux
Source-Version: 4.18~rc3-1~exp1

On Wed, Sep 12, 2018 at 06:31:24AM +0200, Gard Spreemann wrote:
> On Sunday 9 September 2018 14:55:05 CEST Romain Perier wrote:
> > Hi,
> > 
> > Just to let you know that 4.18.0-1 (that is kernel 4.18.6) is now in sid, so
> > you have to test this and no longer the one present in experimental.
> 
> Hi,
> 
> Sorry for taking so long, but I've now tried this kernel and it seems
> that it fixes the problem.

No problem! Thanks for confirming, I'm marking it as fixed with the
first version after the 4.18-rc1.

Regards,
Salvatore

Bug#908641: sbcl 2:1.4.11-1 makes pgloader FTBFS

[Adrian Bunk]

Package: sbcl
Version: 2:1.4.11-1
Severity: serious
Control: affects -1 src:pgloader

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

...
   debian/rules override_dh_auto_build-arch
make[1]: Entering directory '/build/1st/pgloader-3.5.2'
mkdir -p build/bin
mkdir -p /build/1st/pgloader-3.5.2/debian/home
buildapp --require sb-posix \
--require sb-bsd-sockets\
--load /usr/share/common-lisp/source/cl-asdf/build/asdf.lisp\
--asdf-path .   \
--asdf-tree /usr/share/common-lisp/systems  \
--load-system asdf-finalizers   \
--load-system asdf-system-connections   \
--load-system pgloader  \
--load src/hooks.lisp   \
--entry pgloader:main   \
--dynamic-space-size 4096   \
--compress-core \
--output build/bin/pgloader
; compiling file "/usr/share/common-lisp/source/cl-asdf/build/asdf.lisp" 
(written 12 MAY 2018 08:48:30 AM):

; 
/build/1st/pgloader-3.5.2/debian/home/.cache/common-lisp/sbcl-1.4.11.debian-linux-x64/usr/share/common-lisp/source/cl-asdf/build/asdf-tmpGHU3ALSV.fasl
 written
; compilation finished in 0:00:08.272
;; loading file #P"/usr/share/common-lisp/source/cl-asdf/build/asdf.lisp"
;; loading system "asdf-finalizers"
;; loading system "asdf-system-connections"
;; loading system "pgloader"
Fatal SIMPLE-ERROR:
  Compilation failed: Undefined instruction: MOVZXD in
 (INST MOVZXD RESULT MEMREF) in 
/usr/share/common-lisp/source/nibbles/sbcl-opt/x86-64-vm.lisp
make[1]: *** [debian/rules:29: override_dh_auto_build-arch] Error 1

Bug#908508: No org-loaddefs.el file could be found from where org.el is loaded

[bzg]

Hi Russ,

Russ Allbery  writes:

> WARNING: No org-loaddefs.el file could be found from where org.el is
> loaded.

This means Org has been packaged without org-loaddefs.el, which needs
to be manually created with ~$ make autoloads.

HTH,

-- 
 Bastien

Bug#902749: waiting for feedback

[Dima Kogan]

Hi. I have no strong opinion here, and insufficient free cycles to do
anything in this area right now. So do what you think is best.

Thanks!

Bug#908639: RM: python-facebook/0.svn20100209-3.1

[Adrian Bunk]

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

The REST API used by this package has been removed by Facebook
(for the Graph API) and thus this package is not useful.

Removal from unstable has been requested in #908624.

Bug#908621: targetcli-fb: targetcli create fails with: bad typecode

[Ritesh Raj Sarraf]

Hello Valentin,

Thank you for the bug report.

On Wed, 2018-09-12 at 00:02 +0200, Valentin Vidic wrote:
> Running create started to return an error in the new version:
> 
> # targetcli /backstores/block create name=default dev=/dev/loop0
> bad typecode (must be b, B, u, h, H, i, I, l, L, q, Q, f or d)
> 
> The fix seems to be this:
> 
> 
https://github.com/open-iscsi/targetcli-fb/commit/ed5ff9b9505e50b545e86dfbdd32077f0ddda0cb?diff=unified
> 

There's a new upstream release from last week, which is what I'd like
to see in Debian. But there are some dependency issues that we'll need
to get updated first.


> After applying that create works again as expected:
> 
> # targetcli /backstores/block create name=default dev=/dev/loop0
> Created block storage object default using /dev/loop0.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#908638: python-rtslib-fb: new upstream release v2.1.fb68

[Ritesh Raj Sarraf]

Source: python-rtslib-fb
Severity: wishlist

hi,

There's a new release of rtslib-fb, which is also used by LIO target.
Please consider packaging the latest.

Thanks,
Ritesh

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

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

Bug#908637: ITP: node-uri-js -- URI/IRI parsing/validating/resolving library

[Pirate Praveen]

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

* Package name    : node-uri-js
  Version : 4.2.2
  Upstream Author : Gary Court 
* URL : https://github.com/garycourt/uri-js
* License : BSD-2-Clause
  Programming Lang: JavaScript
  Description : URI/IRI parsing/validating/resolving library

 URI/IRI parsing/validating/resolving library
 This is an RFC 3986/3987 compliant, scheme extendable URI/IRI
 parsing/validating/resolving library for JavaScript.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a dependency of webpack 4.x and this is built using typescript +
babel + rollup so not suitable for embedding.

Bug#908636: htop: Feature request: enable delayacct support in htop build

[Rich]

Package: htop
Version: 2.2.0-1.1
Severity: wishlist

Dear Maintainer,

I recently learned about the fascinating delayacct feature hooks added in htop
 2.1, enabled with --enable-delayacct to configure.

Enabling this feature requires libnl-genl-3-dev (and presumably the associated
libnl-3-dev) at buildtime and libnl{-genl,}-3-200 at runtime, but is quite
useful sometimes.

(The package version is because I cut a local package build with the above
changes to be sure it was that simple and functioned appropriately.)

Thanks,
- Rich Ercolani

-- System Information:
Debian Release: 9.5
  APT prefers stable-debug
  APT policy: (1000, 'stable-debug'), (1000, 'stable'), (900, 'testing-debug'), 
(900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 
'stable-updates'), (500, 'proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/16 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 htop depends on:
ii  libc6 2.24-11+deb9u3
ii  libncursesw5  6.0+20161126-1+deb9u2
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2
ii  libtinfo5 6.0+20161126-1+deb9u2

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.89+dfsg-0.1
ii  strace  4.15-2

-- debconf-show failed

Bug#904428: linux-image-4.17.0-1-amd64: sound pops/clicks with snd_hda_intel unless power saving is disabled

[Gard Spreemann]

On Sunday 9 September 2018 14:55:05 CEST Romain Perier wrote:
> Hi,
> 
> Just to let you know that 4.18.0-1 (that is kernel 4.18.6) is now in sid, so
> you have to test this and no longer the one present in experimental.

Hi,

Sorry for taking so long, but I've now tried this kernel and it seems
that it fixes the problem.


 Best regards,
 Gard


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

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[Bastian Blank]

On Wed, Sep 12, 2018 at 12:45:12AM -0300, felipe wrote:
>The system fails to load amdgpu driver with
>linux-image-4.19-rc{2,3}-amd64-unsigned, making it impossible to
>start X session.

I see that you use _both_ radeon and amdgpu.  Is this combination even
supported?

| Kernel modules: radeon, amdgpu

> [9.235702] [drm] radeon kernel modesetting enabled.

Well, it uses radeon, not amdgpu.

> [9.277226] radeon :01:00.0: SI support disabled by module param

And you explicitely disbled SI for the in-use kernel mode support.

> [   10.072509] amdgpu :01:00.0: firmware: failed to load 
> amdgpu/pitcairn_mc.bin (-2)
> [   10.072563] firmware_class: See https://wiki.debian.org/Firmware for 
> information about missing firmware
> [   10.072612] amdgpu :01:00.0: Direct firmware load for 
> amdgpu/pitcairn_mc.bin failed with error -2
> [   10.072617] amdgpu :01:00.0: si_mc: Failed to load firmware 
> "amdgpu/pitcairn_mc.bin"
> [   10.072665] amdgpu :01:00.0: Failed to load mc firmware!
> [   10.072942] [drm:amdgpu_device_init.cold.28 [amdgpu]] *ERROR* sw_init of 
> IP block  failed -2
> [   10.072993] amdgpu :01:00.0: amdgpu_device_ip_init failed
> [   10.073036] amdgpu :01:00.0: Fatal error during GPU init

You are missing all the firmware for you device.

> [   10.073077] [drm] amdgpu: finishing device.
> [   10.073851] amdgpu: probe of :01:00.0 failed with error -2

Which makes it bail out.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Bug#895643: [Pkg-freeipa-devel] Bug#895643: Patch for building using default-jdk (openjdk10)

[Timo Aaltonen]

On 12.09.2018 00:27, Hilko Bengen wrote:
> control: tag -1 patch
> 
> Dear maintainer(s),
> 
> here's a patch that fixes the FTBFS issues with openjdk-10 and removes
> the openjdk-8 dependency.
> 
> Unfortunately, I do not know how to test whether the resulting package
> still works.

This is not for jss though?


-- 
t

Bug#908634: sucrack: The license declaration in d/copyright is not consistent with upstream

[林上智]

Package: sucrack
Version: 1.2.3-4
Severity: normal

The sucrack uses BSD 3-clause license, but it mentioned BSD 2-clause
license in d/copyright [1].

[1] 
https://salsa.debian.org/pkg-security-team/sucrack/blob/debian/master/debian/copyright

Thanks,

--

SZ Lin (林上智) , http://people.debian.org/~szlin

Debian Developer

4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

Bug#908635: wing FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: wing
Version: 0.7-31
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wing fails to cross build from source, because it uses the build
architecture compiler. debian/rules does not pass cross tools to make.
The easiest way to fix that is using dh_auto_build. Unfortunately, it
now uses the C compiler rather than the C++ compiler, because "CC"
usually is a C compiler. Fixing the upstream Makefile to use the
standard variable "CXX" makes the cross build succeed. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru wing-0.7/debian/changelog wing-0.7/debian/changelog
--- wing-0.7/debian/changelog   2017-10-18 18:01:52.0 +0200
+++ wing-0.7/debian/changelog   2018-09-12 06:02:59.0 +0200
@@ -1,3 +1,12 @@
+wing (0.7-31.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Use the standard variable for C++ compilers.
+
+ -- Helmut Grohne   Wed, 12 Sep 2018 06:02:59 +0200
+
 wing (0.7-31) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru wing-0.7/debian/patches/cross.patch 
wing-0.7/debian/patches/cross.patch
--- wing-0.7/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ wing-0.7/debian/patches/cross.patch 2018-09-12 06:02:55.0 +0200
@@ -0,0 +1,24 @@
+--- wing-0.7.orig/makefile.unx
 wing-0.7/makefile.unx
+@@ -3,7 +3,7 @@
+ 
+ TARGET := wing
+ 
+-CC := g++
++CXX := g++
+ CPPFLAGS := 
+ CFLAGS := -Wall -Wno-deprecated-declarations -g -O2
+ CXXFLAGS := $(CFLAGS)
+@@ -26,10 +26,10 @@
+ 
+ 
+ wing : $(OBJ)
+-  $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(OBJ) -o $(TARGET) $(LIBS)
++  $(CXX) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(OBJ) -o $(TARGET) $(LIBS)
+ 
+ .o : .cpp
+-  $(CC) $(CFLAGS) -c $^ -o $@
++  $(CXX) $(CFLAGS) -c $^ -o $@
+ 
+ clean:
+   rm -f *.o additional/*.o
diff --minimal -Nru wing-0.7/debian/patches/series 
wing-0.7/debian/patches/series
--- wing-0.7/debian/patches/series  2017-10-18 18:01:52.0 +0200
+++ wing-0.7/debian/patches/series  2018-09-12 06:02:34.0 +0200
@@ -1,2 +1,3 @@
 010_makefile.diff
 020_misc.diff
+cross.patch
diff --minimal -Nru wing-0.7/debian/rules wing-0.7/debian/rules
--- wing-0.7/debian/rules   2017-10-18 18:01:52.0 +0200
+++ wing-0.7/debian/rules   2018-09-12 06:02:12.0 +0200
@@ -9,7 +9,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) -f makefile.unx CPPFLAGS='$(CPPFLAGS)' CFLAGS='$(CFLAGS)' 
LDFLAGS='$(LDFLAGS)'
+   dh_auto_build --buildsystem=makefile -- -f makefile.unx 
CPPFLAGS='$(CPPFLAGS)' CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)'
 
 override_dh_install:
mkdir -p debian/wing-data/usr/share/games/wing

Bug#908633: mouseemu FTCBFS: upstream Makefile hard codes the build architecture compiler

[Helmut Grohne]

Source: mouseemu
Version: 0.15-10
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

mouseemu fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler. After making it
substitutable, mouseemu cross builds successfully. Please consider
applying the attached patch.

Helmut
--- mouseemu-0.15.orig/Makefile
+++ mouseemu-0.15/Makefile
@@ -1,5 +1,5 @@
 all:
-	gcc $(CFLAGS) -Wall -g $(LDFLAGS) -o mouseemu mouseemu.c
+	$(CC) $(CFLAGS) -Wall -g $(LDFLAGS) -o mouseemu mouseemu.c
 clean:
 	rm -f *.o core* mouseemu
 install:

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[felipe]

Package: src:linux
Version: 4.19~rc3-1~exp1
Severity: important

Dear Maintainer,

   The system fails to load amdgpu driver with
   linux-image-4.19-rc{2,3}-amd64-unsigned, making it impossible to
   start X session.

   If I boot without 'radeon.si_support=0 amdgpu.si_support=1' the
   system boots, I can start X session but it becomes unstable and
   eventually X crashes.

   Booting from kernel 4.18.6 makes it work again.

-- Package-specific info:
** Version:
Linux version 4.19.0-rc3-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-6)) #1 SMP Debian 4.19~rc3-1~exp1 (2018-09-10)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-rc3-amd64 
root=UUID=a1b73323-8a0d-46ad-9723-72b1f6ca6962 ro apparmor=1 security=apparmor 
amd_iommu=on iommu=pt quiet radeon.si_support=0 amdgpu.si_support=1 amdgpu.dc=1 
radeon.dpm=0 amdgpu.dpm=1

** Tainted: E (8192)
 * Unsigned module has been loaded.

** Kernel log:
[9.147023] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: 
(null)
[9.210656] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[9.210660] snd_hda_intel :01:00.1: Force to non-snoop mode
[9.235702] [drm] radeon kernel modesetting enabled.
[9.249358] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input13
[9.249428] input: HDA ATI HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input14
[9.249483] input: HDA ATI HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input15
[9.249569] input: HDA ATI HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input16
[9.249623] input: HDA ATI HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input17
[9.249671] input: HDA ATI HDMI HDMI/DP,pcm=11 as 
/devices/pci:00/:00:02.0/:01:00.1/sound/card0/input18
[9.277226] radeon :01:00.0: SI support disabled by module param
[9.394212] snd_hda_codec_realtek hdaudioC1D0: ALC1150: SKU not ready 
0x
[9.394785] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC1150: 
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[9.394789] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[9.394793] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[9.394796] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[9.394799] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x11/0x1e
[9.394801] snd_hda_codec_realtek hdaudioC1D0:inputs:
[9.394805] snd_hda_codec_realtek hdaudioC1D0:  Front Mic=0x19
[9.394809] snd_hda_codec_realtek hdaudioC1D0:  Rear Mic=0x18
[9.394812] snd_hda_codec_realtek hdaudioC1D0:  Line=0x1a
[9.403350] kvm: Nested Virtualization enabled
[9.403357] kvm: Nested Paging enabled
[9.412092] input: HDA Digital PCBeep as 
/devices/pci:00/:00:14.2/sound/card1/input19
[9.412858] input: HDA ATI SB Front Mic as 
/devices/pci:00/:00:14.2/sound/card1/input20
[9.412937] input: HDA ATI SB Rear Mic as 
/devices/pci:00/:00:14.2/sound/card1/input21
[9.413016] input: HDA ATI SB Line as 
/devices/pci:00/:00:14.2/sound/card1/input22
[9.413108] input: HDA ATI SB Line Out Front as 
/devices/pci:00/:00:14.2/sound/card1/input23
[9.413197] input: HDA ATI SB Line Out Surround as 
/devices/pci:00/:00:14.2/sound/card1/input24
[9.413303] input: HDA ATI SB Line Out CLFE as 
/devices/pci:00/:00:14.2/sound/card1/input25
[9.413388] input: HDA ATI SB Line Out Side as 
/devices/pci:00/:00:14.2/sound/card1/input26
[9.413474] input: HDA ATI SB Front Headphone as 
/devices/pci:00/:00:14.2/sound/card1/input27
[9.448004] MCE: In-kernel MCE decoding enabled.
[9.464568] EDAC amd64: Node 0: DRAM ECC disabled.
[9.464571] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[9.513818] EDAC amd64: Node 0: DRAM ECC disabled.
[9.513821] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[9.687950] Adding 15625212k swap on /dev/sda2.  Priority:-2 extents:1 
across:15625212k FS
[9.753144] [drm] amdgpu kernel modesetting enabled.
[9.935211] CRAT table not found
[9.935215] Virtual CRAT table created for CPU
[9.935217] Parsing CRAT table with 1 nodes
[9.935221] Creating topology SYSFS entries
[9.935252] Topology: Add CPU node
[9.935253] Finished initializing topology
[9.935358] kfd kfd: Initialized module
[

Bug#908630: jeex FTCBFS: uses the build architecture pkg-config and gcc

[Helmut Grohne]

Source: jeex
Version: 12.0.4-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

jeex fails to cross build from source, because it uses the build
architecture pkg-config as it hard codes it into its Makefiles. After
making it substitutable, it still fails, because it uses the
non-standard variable "cc" for the C compiler in plugins/Makefile. After
changing it to "CC", the compiler gets properly substituted and jeex
cross builds successfully. Please consider applying the attached patch.

Helmut
--- jeex-12.0.4.orig/Makefile
+++ jeex-12.0.4/Makefile
@@ -20,15 +20,16 @@
   html-export.o logging.o search.o \
   terminal-actions.o tools.o plugin.o
 CC  = gcc
+PKG_CONFIG   ?= pkg-config
 SUBDIRS  = po plugin
 INSTALL  = /usr/bin/install -D
 INSTALL_DIR  = /usr/bin/install -d
 INSTALL_DATA = $(INSTALL) -m 644
 DESTDIR  =
 
-CFLAGS = `pkg-config --cflags gtk+-2.0` $(C_PARAM)
+CFLAGS = `$(PKG_CONFIG) --cflags gtk+-2.0` $(C_PARAM)
 
-LINK= `pkg-config --libs --cflags gtk+-2.0` -lm -lmagic -pipe $(L_PARAM)
+LINK= `$(PKG_CONFIG) --libs --cflags gtk+-2.0` -lm -lmagic -pipe $(L_PARAM)
 
 ifeq ($(DEBUG), true)
   CFLAGS += -g -DDEBUG_ENABLE=1
--- jeex-12.0.4.orig/plugin/Makefile
+++ jeex-12.0.4/plugin/Makefile
@@ -16,15 +16,16 @@
 # MA 02110-1301, USA.
 
 objects = jeex_hello.o joiner.o
-cc = gcc
-cflags = `pkg-config --cflags gtk+-2.0` $(C_PARAM)
+CC = gcc
+PKG_CONFIG ?= pkg-config
+cflags = `$(PKG_CONFIG) --cflags gtk+-2.0` $(C_PARAM)
 
 ifeq ($(DEBUG), true)
   cflags += -g -Ddebug_enable=1
 endif
 
 %.o: %.c
-	$(cc) -c $< -o $@ $(cflags)
+	$(CC) -c $< -o $@ $(cflags)
 
 plugin: $(objects)
 	@echo "Plugin compiled."

Bug#908631: RM: goffice-0.8 -- ROM; obsolete

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
Control: affects -1 goffice-0.8

Please remove "goffice-0.8" from "unstable".

This is an obsolete package that we had to keep for GnuCash.
Nothing depends on goffice-0.8 any more.

Thanks.

-- 
Regards,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#908629: RFS: biometric-authentication/0.9.55-1 [ITP]

[handsome_feng]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "biometric-authentication"

 * Package name: biometric-authentication
   Version : 0.9.55-1
   Upstream Author : jianglinxuan 
 * URL : https://salsa.debian.org/kylin-team/biometric-
authentication
 * License : LGPL-3+
   Section : admin

  It builds those binary packages:

biometric-auth - Biometric Authentication Service
biometric-driver-community-multidevice - Biometric Authentication Driver
(community multidevice)
biometric-utils - Biometric authentication utils
libbiometric-dev - Biometric Identification DRIVER API - development files
libbiometric0 - Biometric Identification library

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

  https://mentors.debian.net/package/biometric-authentication


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

dget -x https://mentors.debian.net/debian/pool/main/b/biometric-
authentication/biometric-authentication_0.9.55-1.dsc

  More information about this can be obtained from https://github.com/ukui.


  Regards,
   handsome_feng



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

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

Bug#908628: RFS: ukui-biometric-auth/1.0.0-1 [ITP]

[handsome_feng]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "ukui-biometric-auth"

 * Package name: ukui-biometric-auth
   Version : 1.0.0-1
   Upstream Author : Yang Hao 
 * URL : https://salsa.debian.org/kylin-team/ukui-biometric-auth
 * License : GPL-3+
   Section : admin

  It builds those binary packages:

libpam-biometric - Insertable authentication module for PAM
ukui-polkit - UKUI authentication agent for PolicyKit-1

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

  https://mentors.debian.net/package/ukui-biometric-auth


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

dget -x https://mentors.debian.net/debian/pool/main/u/ukui-biometric-
auth/ukui-biometric-auth_1.0.0-1.dsc

  More information about this can be obtained from https://github.com/ukui.


  Regards,
   handsome_feng



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

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

Bug#908627: RFS: ukui-biometric-manager/1.0.0-1[ITP]

[handsome_feng]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "ukui-biometric-manager"

 * Package name: ukui-biometric-manager
   Version : 1.0.0-1
   Upstream Author : Yang Hao 
 * URL : https://salsa.debian.org/kylin-team/ukui-biometric-manager
 * License : GPL-3+
   Section : x11

  It builds those binary packages:

ukui-biometric-manager - Manager for biometric authentication

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

  https://mentors.debian.net/package/ukui-biometric-manager


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

dget -x https://mentors.debian.net/debian/pool/main/u/ukui-biometric-
manager/ukui-biometric-manager_1.0.0-1.dsc

  More information about hello can be obtained from https://github.com/ukui.


  Regards,
   handsome_feng



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

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

Bug#908626: RFS: ukui-greeter/1.1.4-1 [ITP]

[handsome_feng]

Package: sponsorship-requests
Severity: normal

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "ukui-greeter"

 * Package name: ukui-greeter
   Version : 1.1.4-1
   Upstream Author : yang hao 
 * URL : https://salsa.debian.org/kylin-team/ukui-greeter
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

ukui-greeter - Lightdm greeter for UKUI

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

  https://mentors.debian.net/package/ukui-greeter


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

dget -x https://mentors.debian.net/debian/pool/main/u/ukui-greeter/ukui-
greeter_1.1.4-1.dsc

  More information about ukui-greeter can be obtained from
https://github.com:ukui.


  Regards,
   handsome_feng



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

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

Bug#908568: nvidia-driver: build error

[Russ Allbery]

Vincent Lefevre  writes:
> On 2018-09-11 15:29:02 -0700, Russ Allbery wrote:
>> Vincent Lefevre  writes:

>>> This would mean that a breakage is possible after any patch (in
>>> particular with those "Update to SVN..." in the changelog).  Thus this
>>> means that the kernel module build system must check that the GCC
>>> Debian package version number matches the one used to build the
>>> kernel. For sid, GCC is often not in sync with the one used to build
>>> the kernel. This is a really big problem.

>> I don't think it's an NVIDIA-specific problem, though, right?  Doesn't
>> this happen with any kernel module build?

> I assume that this depends on which features of the interface are
> used.

Sorry, I should have checked before replying.  This is indeed an
NVIDIA-specific check in conftest.sh, not a general Linux issue.  It's not
doing any complicated logic; it's just parsing the version string and
aborting the compilation if it doesn't match.

If you set IGNORE_CC_MISMATCH=1 in the environment before installing the
package, does everything build and work correctly?

Apparently fglrx had a similar check, and the package maintainers chose to
patch it out.

-- 
Russ Allbery (r...@debian.org)   

Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Dale Harris]

On Tue, 11 Sep 2018 20:53:28 +0200 Sebastian Andrzej Siewior 
 wrote:
> On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote:
> > Dmitry already implemented my short-term workaround:
> > https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
> > 
> > When this has been built on all release architectures openssl can bump 
> > the version requirement.
> > 
> > Even more cautious would be to wait until testing migration of Qt.
> 
> now after what happens I consider this issue (#908567) fixed since the
> only affected package by this is fixed. Also adding versioned depends is
> not easy as I expected it in the morning without too much mess around
> it.
> 
> > cu
> > Adrian
> 
> Sebastian
> 
> 

Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Dale Harris]

On Tue, 11 Sep 2018 20:53:28 +0200 Sebastian Andrzej Siewior 
 wrote:
> On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote:
> > Dmitry already implemented my short-term workaround:
> > https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
> > 
> > When this has been built on all release architectures openssl can bump 
> > the version requirement.
> > 
> > Even more cautious would be to wait until testing migration of Qt.
> 
> now after what happens I consider this issue (#908567) fixed since the
> only affected package by this is fixed. Also adding versioned depends is
> not easy as I expected it in the morning without too much mess around
> it.
> 
> > cu
> > Adrian
> 
> Sebastian
> 
> 

Bug#908616: OpenAFS security release

[Benjamin Kaduk]

On Tue, Sep 11, 2018 at 10:02:20PM +0200, Salvatore Bonaccorso wrote:
> Hey!
> 
> On Tue, Sep 11, 2018 at 02:30:51PM -0500, Benjamin Kaduk wrote:
> > Source: openafs
> > Version: 1.6.9-2+deb8u7
> > Tags: security
> > Severity: serious
> > 
> > OpenAFS upstream released security releases 1.6.23 and 1.8.2 today, fixing:
> > http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt
> > http://openafs.org/pages/security/OPENAFS-SA-2018-002.txt
> > http://openafs.org/pages/security/OPENAFS-SA-2018-003.txt
> > 
> > No CVEs have been assigned yet.
> 
> Would it be possible, that you with both your maintainers and upstream
> part could request accordingly CVEs via http://cveform.mitre.org/ (and
> then loop back the assignment here once got those).

OPENAFS-SA-2018-001 is CVE-2018-16947.
OPENAFS-SA-2018-002 is CVE-2018-16948.
OPENAFS-SA-2018-003 is CVE-2018-16949.

-Ben

Bug#908568: nvidia-driver: build error

[Vincent Lefevre]

On 2018-09-11 15:29:02 -0700, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > This would mean that a breakage is possible after any patch (in
> > particular with those "Update to SVN..." in the changelog).  Thus this
> > means that the kernel module build system must check that the GCC Debian
> > package version number matches the one used to build the kernel. For
> > sid, GCC is often not in sync with the one used to build the
> > kernel. This is a really big problem.
> 
> I don't think it's an NVIDIA-specific problem, though, right?  Doesn't
> this happen with any kernel module build?

I assume that this depends on which features of the interface are
used.

> Or am I confused and this is an NVIDIA-specific check?

I don't know. It would be interesting to know the causes of the
failures.

I tried to search for information and found:

  https://www.kernel.org/doc/html/v4.14/process/stable-api-nonsense.html

Some issues may come from the kernel build options, and concerning
the compiler:

  "Depending on the version of the C compiler you use, different
  kernel data structures will contain different alignment of
  structures, and possibly include different functions in different
  ways (putting functions inline or not.) The individual function
  organization isn’t that important, but the different data structure
  padding is very important."

Well, concerning the alignment of structures and internal padding,
this is a much more general problem that could affect any library
that expose structures in their .h public header files. I assume
that this will never change, otherwise one would see a breakage
in various places. So, I'm wondering why this is mentioned.

Concerning inline functions, this would need explanations. In any
case, I don't see why this would change between minor versions.
And this is more likely to be affected by compiler options.

Moreover, it appears that NVIDIA's compiler version check predates
the change of numbering in GCC. See for instance:

  
https://devtalk.nvidia.com/default/topic/833061/nvidia-drivers-352-09-dont-install/

"Compiler version check failed:

The major and minor number of the compiler used to
compile the kernel:

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

does not match the compiler used here:

cc (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2"

In the past, GCC 4.6, 4.7, 4.8, 4.9 were indeed different releases,
but now, only the major number corresponds to some given release:
5, 6, 7, 8, 9 (GCC was using X.Y.Z where Z was a patchlevel, and
now uses X.Y where Y is a patchlevel, thus to be consistent with
the past test, NVIDIA should now just check X).

https://devtalk.nvidia.com/default/topic/960778/linux/having-trouble-with-the-340-96-driver-on-kali-linux-failing-cc-version-check/

says: "That's because the ABI (i.e. how parameters are passed, or
how the stack is laid out) changes between gcc versions, especially
between major version changes (here, v5's ABI is incompatible with
V6's)."

Thus only the *major* version matters.

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

Bug#908625: zsh 5.6 doesn't get terminal size change information with "less"

[Vincent Lefevre]

Package: zsh
Version: 5.6-1
Severity: important
Tags: upstream
Forwarded: http://www.zsh.org/mla/workers/2018/msg01253.html

Another major regression in zsh 5.6 [test with the Debian package]
and zsh 5.6.1 [test with upstream's tarball], tested with both xterm
and GNOME Terminal:

1. Open the terminal to some size.
2. View a file with "less" (do not quit).
3. Change the size of the terminal.
4. Quit "less".

The terminal becomes unusable (at least if the size has been reduced)
because zsh did not notice the change. If I echo $COLUMNS and $LINES,
they still have their old values.

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  curl   7.61.0-1 amd64command line tool for transferrin
ii  pulseaudio 12.2-1   amd64PulseAudio sound server
ii  systemd239-8amd64system and service manager
ii  udev   239-8amd64/dev/ and hotplug management daem
ii  vlc-bin3.0.4-1+b1   amd64binaries from VLC
ii  youtube-dl 2018.06.18-1 all  downloader of videos from YouTube

The following files were modified:

/etc/systemd/journald.conf
/etc/systemd/system.conf
/etc/systemd/logind.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.27-6
ii  libcap2 1:2.25-1.2
ii  libtinfo6   6.1+20180714-1
ii  zsh-common  5.6-1

Versions of packages zsh recommends:
ii  libc6 2.27-6
ii  libncursesw6  6.1+20180714-1
ii  libpcre3  2:8.39-11

Versions of packages zsh suggests:
ii  zsh-doc  5.6-1

-- no debconf information

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

Bug#907855: racket-mode: testsuite failure on arm64

[David Bremner]

David Bremner  writes:

> Gianfranco Costamagna  writes:
>
>> Source: racket-mode
>> Severity: important
>> Version: 20180731+0+g948c8aa-2
>>
>> Hello, since the last snapshot, testsuite has started to fail in Ubuntu (and 
>> I presume in Debian too), but only on arm64...
>>
>
> I can't duplicate this in a debian sid arm64 porterbox.
>
> The test in question looks like:

With the new version (and racket 7.0), I can now duplicate two failing
tests racket-tests/repl and racket-tests/run on amdahl. So I guess
that's progress. It still works fine on amd64 afaict.

d

Bug#908603: docker.io: consider backporting to stable

[Dmitry Smirnov]

On Wednesday, 12 September 2018 4:01:24 AM AEST Héctor Orón Martínez wrote:
>   Since `docker.io` reached testing, could you please consider backporting
> it to stable?

No, please... Maintaining Docker is an enormous time sink. I doubt backports 
will ever happen and certainly I don't want to be involved.
I'm contemplating orphaning Docker and the only reason I'm still looking 
after it is because I think it is strategically important for Debian success.

I don't like Docker. It is very sloppy, bloated, over engineered with 
selfish, uncooperative fork-obsessed upstream who refuses to adopt good 
versioning practices making our work very difficult.

Recently I've switched all my containers to _rkt_ and I'm very happy about 
that.

Whoever needs Docker can install it straight from "testing" since Docker is 
statically linked. I can't justify the effort required to maintain the 
official backport.


>   What kind of work would be needed to ease the path to provide such
> backport?

Man time required to backport hundreds of dependency libraries and even more 
time to maintain all those, resolve complicated transitions, build/test 
failures and tight versioning. Team of several people working full time for 
months - that's what it will take.

We are nowhere near the point where it would be safe to backport a monster 
package like Docker. First, I'd like to suggest having a real team 
maintaining Docker, not just myself. I've already invested too much time into 
Docker at the great personal cost and expense of other worthy projects/
packages. I'm not going to stick much longer...

Besides just keeping Docker in testing is a challenge due to build/test 
failures routinely exposed by CI. Docker dependency tree is very big and 
surface for problems is enormous.

I wholeheartedly recommend using _rkt_ instead and it looks like rkt would be 
actually possible to backport.

-- 
Cheers,
 Dmitry Smirnov.

---

We do our friends no favors by pretending not to notice flaws in their
work, especially when those who are not their friends are bound to notice
these same flaws.
-- Sam Harris


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

Bug#905783: marked as done (variety doesn't startup in mate and throws a bunch of python warnings)

[James Lu]

Control: notfixed bdfproxy 0.3.9-3
Control: reopen -1

Hello,

I think you got the wrong bug number, reopening

James

On 2018-09-11 01:42 PM, Debian Bug Tracking System wrote:
> Your message dated Tue, 11 Sep 2018 20:39:33 +
> with message-id 
> and subject line Bug#905783: fixed in bdfproxy 0.3.9-3
> has caused the Debian Bug report #905783,
> regarding variety doesn't startup in mate and throws a bunch of python 
> warnings
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#908624: Removal

[Ian Wienand]

Hello,

The REST API that is used by this package no longer exists, so it is
not actually useful.
Upstream development has stopped / been abandoned.

This is all replaced by the Graph API [1] which has all it's own SDK's etc.

-i

[1] https://developers.facebook.com/docs/graph-api/

Bug#908552: dh-golang: Built-Using is incorrect

[Michael Hudson-Doyle]

On Tue, 11 Sep 2018 at 15:57, Arnaud Rebillout <
arnaud.rebill...@collabora.com> wrote:

> Package: dh-golang
> Version: 1.35
> Severity: normal
>
> Dear Maintainer,
>
> it's been reported lately that the Built-Using field in docker.io is
> incorrect [1].
>
> I started to investigate, but docker.io is a complicated package with
> some embedded libraries and a hell of a debian/rules, so it's not the
> best package to investigate this issue.
>
> Instead, I found a more suitable package that also exhibits the issue:
> notary [2]. This package has a simple debian/rule, and excludes the
> vendor directory entirely.
>
> So I built the latest version of this package (0.6.1~ds1-2 at the
> moment), and checked the resulting Built-Using. It turns out that the
> following libraries from Build-Depends are missing in Built-Using:
>
> - golang-github-cloudflare-cfssl-dev
> - golang-github-mattn-go-sqlite3-dev
> - golang-github-miekg-pkcs11-dev
>
> Let's take these packages one by one:
>
> 
>
>   * golang-github-miekg-pkcs11-dev
>
> This build dependency is optional. We need it because we build notary
> with the build tag 'pkcs11'. dh_golang is not aware of that, so I guess
> that's why it doesn't detect this dependency.
>

Hmm, that's a tricky one. I'm sure that we could make it possible for a
package to have dh_golang pass -tags pkcs11 to all the various go list
commands it invokes. Would be better to not have to have the package
maintainer remember to do this, but I'm not sure I see a sane way to do
that.


>   * golang-github-cloudflare-cfssl-dev
>
> This dependency is needed for the testsuite only. If we don't have it,
> then there you go...
>
> # github.com/theupdateframework/notary/trustpinning
> src/
> github.com/theupdateframework/notary/trustpinning/certs_test.go:15:2: \
>   cannot find package "github.com/cloudflare/cfssl/config" in any of
> ...
>
> Should such a dep be eligigle to Built-Using or not?
>

It should not. No part of a package that is only used in the test suite is
copied into the binary package, which is (was) the criteria for Built-Using.

(Actually I think the current dh_golang is still over-broad: we should only
be mentioning in {X-Go-,}Built-Using the packages that contain dependencies
of Go pakckages that build binaries, not all Go packages. But this is
likely to be minor I think)


>   * golang-github-mattn-go-sqlite3-dev
>
> Similar to cloudflare: it's only needed for the testsuite.
>

Similar answer!


> 
>
> As a sidenote, I also spent some time investigating this issue on the
> docker.io package, and there's probably other problems to be solved
> there.
>
> I'm wondering, couldn't we generate the Built-Using field by recursing
> on the Build-Depends? Wouldn't it be more generic and failproof?
>

It used to copy build-depends, but I don't think it recursed. I think this
would in practice have different rather than better failure modes.

Cheers,
mwh


> Best regards,
>   Arnaud
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908055
> [2] https://salsa.debian.org/go-team/packages/notary
>
> 
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dh-golang depends on:
> ii  debhelper 11.3.5
> ii  dpkg  1.19.0.5+b1
> ii  libdpkg-perl  1.19.0.5
> ii  perl  5.26.2-7
>
> dh-golang recommends no packages.
>
> dh-golang suggests no packages.
>
> -- no debconf information
>
>

Bug#908624: RM: python-facebook -- ROM; The REST API used by this package has been removed by Facebook (for the Graph API) and thus this package is not useful.

[Ian Wienand]

Package: ftp.debian.org
Severity: normal

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[George B.]

Package: lightning
Followup-For: Bug #908494

> To see if I can reproduce this behavior anyhow I have setup now a
> complete new install of an Stretch system on i386 with and without the
> Thunderbird packages with a further dist-upgrade to testing

I am not running testing, I am running Sid. Package versions:

thunderbird/unstable,now 1:60.0-3 amd64 [installed,automatic]
thunderbird-l10n-en-gb/unstable,unstable,now 1:60.0-3 all [installed]
lightning/unstable,unstable,now 1:60.0-3 all [installed]

> The information from the first email is showing that debconf-show was
> failing. That is unusual and must have a reason.

I know nothing about debconf-show. Looking on the internet suggests it
is meant to be run with a package name as an argument. I have tried the
above 3 packages as arguments and there was no output and return code
was 0.

> Is Ctrl+Shift+C showing the Calendar?

No

> for me it makes not really sense to do a lot of Q about some really basic
> things if you can't do some more self research on your side.

What is it that you want me to do?


Thanks,

George

Bug#908623: ieee-data: URL to download updated IEEE OUI data is not available anymore.

[Simon Valiquette]

Package: ieee-data
Version: 20160613.1
Severity: normal

Hello,

update-ieee-data tries to download the newest version of the
Organizationally Unique Identifier (OUI) from:

http://standards.ieee.org/regauth/oui/oui.txt

while it has moved to the following URL (I included the other ones):

http://standards-oui.ieee.org/oui/oui.txt
http://standards-oui.ieee.org/oui28/mam.txt
http://standards-oui.ieee.org/oui36/oui36.txt
http://standards-oui.ieee.org/iab/iab.txt


Likewise, the URL in the package description is also broken:
http://standards.ieee.org/regauth/oui/index.shtml

I am not sure if it is the appropriate one, but that link seems a
reasonable choice both for the man page and the package description:
https://standards.ieee.org/products-services/regauth/index.html

The URL in the man page also need to be updated.

Have a nice day,

Simon Valiquette


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

Kernel: Linux 4.9.0-7-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1), LANGUAGE=fr_CA 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ieee-data depends on:
ii  curl 7.52.1-5+deb9u6
ii  libwww-perl  6.15-1
ii  wget 1.18-5+deb9u2

ieee-data recommends no packages.

ieee-data suggests no packages.

-- debconf-show failed

Bug#788791: fonts-cantarell: visual glitches in GNOME Shell until Shell is restarted

[Jeremy Bicha]

Control: tags -1 -moreinfo -unreproducible
Control: forwarded -1 https://gitlab.gnome.org/GNOME/cantarell-fonts/issues/2
Control: retitle -1 fonts-cantarell: visual glitches in GNOME Shell until Shell 
is restarted

This is a known issue. You need to restart your computer after
upgrading fonts-cantarell.

A Cantarell developer said this recently:
"The reason is that afaik FreeType's or FontConfig's glyph cache
 gets messed up when you replace the actual font file while it is
 in use by an application. It can also cause crashes (see e.g.
 https://gitlab.gnome.org/GNOME/gnome-shell/issues/101 )."

By the way, this is a major reason why GNOME Software only offers
offline upgrades. It allows you to avoid issues like this.

There's nothing really that we can fix here in fonts-cantarell
but I think it doesn't hurt to keep this bug open so that others
will see this bug easier.

Thanks,
Jeremy Bicha

Bug#908568: nvidia-driver: build error

[Russ Allbery]

Vincent Lefevre  writes:

> This would mean that a breakage is possible after any patch (in
> particular with those "Update to SVN..." in the changelog).  Thus this
> means that the kernel module build system must check that the GCC Debian
> package version number matches the one used to build the kernel. For
> sid, GCC is often not in sync with the one used to build the
> kernel. This is a really big problem.

I don't think it's an NVIDIA-specific problem, though, right?  Doesn't
this happen with any kernel module build?  Or am I confused and this is an
NVIDIA-specific check?

-- 
Russ Allbery (r...@debian.org)   

Bug#908622: showfoto crashes when clicking on "Color Effects"

[Peter Stefan Jan]

Package: showfoto
Version: 4:5.3.0-1
Severity: normal

Dear Maintainer,

* What led up to the situation?
Intention to use "Color Effects" functionality of showfoto

* What exactly did you do (or not do) that was effective (or
ineffective)?
I've opened a photo then clicked on "Effects | Color Effects"

* What was the outcome of this action?
showfoto crashed. Behaviour can be reproduced consistently.

* What outcome did you expect instead?
no crashing :)


* additional information
I've posted this to the backports mailing list but was referred to the package 
maintainers. cf:
https://lists.debian.org/debian-backports/2018/09/msg00040.html

Issue seems to be fixed already in version 5.6.0, cf:
https://cgit.kde.org/digikam.git/tree/project/NEWS.5.6.0
038 ==> 379806 - ShowFoto crashes when clicking Color Effects from menu.


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

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

Versions of packages showfoto depends on:
ii  digikam-private-libs  4:5.3.0-1
ii  kipi-plugins  4:5.3.0-1
ii  libc6 2.24-11+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libkf5configcore5 5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5i18n5   5.28.0-2
ii  libkf5notifications5  5.28.0-1
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18+deb9u1

Versions of packages showfoto recommends:
ii  dolphin  4:16.08.3-3

showfoto suggests no packages.

-- no debconf information

Bug#908551: apt-listchanges: apt update hangs if no mail system

[Robert Luberda]

RJ pisze:

An issue in apt-listchanges is that handling of Ctrl-C does not work,
when /bin/sh points to dash; this is visible here:

> ^CE: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10
> received signal 2.
> E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10

Pressing Ctrl-C causes apt-listchanges to exit with code 10, so the
above command should return 0, but... dash as parent process receives
SIGINT as well, what ends up with returning code 130.
bash works differently and returns 0, but I guess unfortunately dash
behavior's is correct according to POSIX. I will try to fix this inside
apt-listchanges somehow.

Regards,
robert

Bug#908621: targetcli-fb: targetcli create fails with: bad typecode

[Valentin Vidic]

Package: targetcli-fb
Version: 2.1.48-1
Severity: important

Dear Maintainer,

Running create started to return an error in the new version:

# targetcli /backstores/block create name=default dev=/dev/loop0
bad typecode (must be b, B, u, h, H, i, I, l, L, q, Q, f or d)

The fix seems to be this:

https://github.com/open-iscsi/targetcli-fb/commit/ed5ff9b9505e50b545e86dfbdd32077f0ddda0cb?diff=unified

After applying that create works again as expected:

# targetcli /backstores/block create name=default dev=/dev/loop0
Created block storage object default using /dev/loop0.

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

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

Versions of packages targetcli-fb depends on:
ii  python3 3.6.6-1
ii  python3-configshell-fb  1.1.24-1
ii  python3-gi  3.28.3-1
ii  python3-rtslib-fb   2.1.66-2
ii  python3-six 1.11.0-2

targetcli-fb recommends no packages.

targetcli-fb suggests no packages.

-- no debconf information

Bug#908568: nvidia-driver: build error

[Vincent Lefevre]

Control: retitle -1 nvidia kernel modules build error on GCC version mismatch

On 2018-09-11 09:54:06 -0700, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > Even with just a differing *minor* version? Note that since GCC 5,
> > an update of the minor version should just be bug fixes:
> 
> >   https://gcc.gnu.org/develop.html
> 
> The kernel uses GCC-specific features in an extremely aggressive way.  I'm
> not particularly surprised that ABI compatibility might break across minor
> versions.  Normally the linux-compiler-gcc-* packages express the required
> compiler version for building kernel modules and handle this, but they're
> only an upgrade ratchet, not a downgrade ratchet.  (Plus, that would just
> create an unsatisfiable dependency since the compiler packages aren't
> broken apart that way.)

This would mean that a breakage is possible after any patch
(in particular with those "Update to SVN..." in the changelog).
Thus this means that the kernel module build system must check
that the GCC Debian package version number matches the one used
to build the kernel. For sid, GCC is often not in sync with the
one used to build the kernel. This is a really big problem.

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

Bug#908609: gtkhash: cannot fulfill the build dependencies

[Unit 193]

Howdy,

A solution to the problem is to pull a commit from upstream and adjust the 
packaging, patch attached.


~Unit 193
Unit193 @ freenode
Unit193 @ OFTCdiff -Nru gtkhash-1.1.1/debian/changelog gtkhash-1.1.1/debian/changelog
--- gtkhash-1.1.1/debian/changelog  2018-07-16 07:46:10.0 -0400
+++ gtkhash-1.1.1/debian/changelog  2018-09-11 17:30:43.0 -0400
@@ -1,3 +1,11 @@
+gtkhash (1.1.1-3.1) unstable; urgency=medium
+
+  * d/p/11-support-thunarx-3.patch: Add upstream commit to support thunarx-3.
+  * d/control: Adjust build-dep: libthunarx-2-dev → libthunarx-3-dev.
+  * d/thunar-gtkhash.install: Adapt to the thunarx-3 path.
+
+ -- Unit 193   Tue, 11 Sep 2018 17:30:43 -0400
+
 gtkhash (1.1.1-3) unstable; urgency=medium
 
   * Fix Vcs-*.
diff -Nru gtkhash-1.1.1/debian/control gtkhash-1.1.1/debian/control
--- gtkhash-1.1.1/debian/control2018-07-16 07:16:59.0 -0400
+++ gtkhash-1.1.1/debian/control2018-09-11 17:30:43.0 -0400
@@ -8,7 +8,7 @@
  nettle-dev,
  libgtk-3-dev (>= 3.0.0),
  libnautilus-extension-dev (>= 3.0),
- libthunarx-2-dev,
+ libthunarx-3-dev,
  libnemo-extension-dev,
  libcaja-extension-dev,
  intltool (>= 0.40.6),
diff -Nru gtkhash-1.1.1/debian/patches/50-support-thunarx-3.patch 
gtkhash-1.1.1/debian/patches/50-support-thunarx-3.patch
--- gtkhash-1.1.1/debian/patches/50-support-thunarx-3.patch 1969-12-31 
19:00:00.0 -0500
+++ gtkhash-1.1.1/debian/patches/50-support-thunarx-3.patch 2018-09-11 
17:30:43.0 -0400
@@ -0,0 +1,54 @@
+From 9e35e3a0c248d57c62d064edbc14d3ed02c3bff8 Mon Sep 17 00:00:00 2001
+From: Tristan Heaven 
+Date: Sun, 20 May 2018 18:02:05 +0100
+Subject: [PATCH] add --with-thunarx= configure option for selecting thunarx
+ version (fixes #21)
+
+---
+ configure.ac | 14 ++
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 9b474f2..fd1f99c 100644
+--- a/configure.ac
 b/configure.ac
+@@ -69,7 +69,7 @@ GLIB_GSETTINGS
+ # check for gtk+ {{{
+ AC_MSG_CHECKING([which GTK+ version to use])
+ AC_ARG_WITH([gtk],
+-  [AS_HELP_STRING([--with-gtk=2.0|3.0], [GTK+ version to use [3.0]])],
++  [AS_HELP_STRING([--with-gtk=2.0|3.0], [GTK+ version to use 
[default=3.0]])],
+   [with_gtk="${withval}"], [with_gtk="3.0"])
+ AC_MSG_RESULT([${with_gtk}])
+ 
+@@ -340,12 +340,18 @@ AC_ARG_ENABLE([thunar],
+ AC_MSG_RESULT([${enable_thunar}])
+ AM_CONDITIONAL([ENABLE_THUNAR], [test "${enable_thunar}" = "yes"])
+ 
++AC_MSG_CHECKING([which Thunarx version to use])
++AC_ARG_WITH([thunarx],
++  [AS_HELP_STRING([--with-thunarx=2|3], [Thunarx version to use 
[default=3]])],
++  [with_thunar="${withval}"], [with_thunarx="3"])
++AC_MSG_RESULT([${with_thunarx}])
++
+ if test "${enable_thunar}" = "yes" ; then
+   # Check for thunar
+-  PKG_CHECK_MODULES([THUNAR], [thunarx-2])
++  PKG_CHECK_MODULES([THUNAR], ["thunarx-${with_thunarx}"])
+   AC_SUBST([THUNAR_CFLAGS])
+   AC_SUBST([THUNAR_LIBS])
+-  THUNAR_EXTENSION_DIR=`${PKG_CONFIG} --variable=extensionsdir thunarx-2`
++  THUNAR_EXTENSION_DIR=`${PKG_CONFIG} --variable=extensionsdir 
"thunarx-${with_thunarx}"`
+   AC_SUBST([THUNAR_EXTENSION_DIR])
+ fi
+ # }}}
+@@ -392,7 +398,7 @@ echo "  gtkhash: ${enable_gtkhash} (gtk+-${with_gtk})"
+ echo "  gtkhash-caja: ${enable_caja}"
+ echo "  gtkhash-nautilus: ${enable_nautilus}"
+ echo "  gtkhash-nemo: ${enable_nemo}"
+-echo "  gtkhash-thunar: ${enable_thunar}"
++echo "  gtkhash-thunar: ${enable_thunar} (thunarx-${with_thunarx})"
+ 
+ blake2_funcs="
+   BLAKE2b BLAKE2s BLAKE2bp BLAKE2sp"
+
diff -Nru gtkhash-1.1.1/debian/patches/series 
gtkhash-1.1.1/debian/patches/series
--- gtkhash-1.1.1/debian/patches/series 2018-07-16 07:14:44.0 -0400
+++ gtkhash-1.1.1/debian/patches/series 2018-09-11 17:30:43.0 -0400
@@ -2,3 +2,4 @@
 20-fix-component-id.patch
 30-add-image-screenshot.patch
 40-fix-invalid-tags.patch
+50-support-thunarx-3.patch
diff -Nru gtkhash-1.1.1/debian/thunar-gtkhash.install 
gtkhash-1.1.1/debian/thunar-gtkhash.install
--- gtkhash-1.1.1/debian/thunar-gtkhash.install 2017-12-19 02:45:34.0 
-0500
+++ gtkhash-1.1.1/debian/thunar-gtkhash.install 2018-06-05 17:29:28.0 
-0400
@@ -1,2 +1,2 @@
-usr/lib/*/thunarx-2/libgtkhash-properties-thunar.so
+usr/lib/*/thunarx-3/libgtkhash-properties-thunar.so
 usr/share/appdata/thunar-gtkhash.metainfo.xml usr/share/metainfo

Bug#908549: gimp: segfault when using measuring tool

[Bernhard Übelacker]

Hello,
just tried to reproduce this issue.

I think this is a case of stack exhaustion.



Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0xb7099247 in g_closure_ref (closure=0x259ffe0) at 
../../../../gobject/gclosure.c:547
547 ../../../../gobject/gclosure.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0xb7099247 in g_closure_ref (closure=0x259ffe0) at 
../../../../gobject/gclosure.c:547
#1  0xb7099b67 in g_closure_invoke (closure=0x259ffe0, return_value=0x0, 
n_param_values=1, param_values=0xbf800170, invocation_hint=0xbf800114) at 
../../../../gobject/gclosure.c:782
#2  0xb70ad04d in signal_emit_unlocked_R (node=node@entry=0x2452f30, 
detail=detail@entry=0, instance=instance@entry=0x2cd11a8, emission_return=0x0, 
instance_and_params=0xbf800170) at ../../../../gobject/gsignal.c:3565
#3  0xb70b59a3 in g_signal_emit_valist (instance=, 
signal_id=, detail=, var_args=0xbf8002dc "M5[") 
at ../../../../gobject/gsignal.c:3391
#4  0xb70b6155 in g_signal_emit (instance=0x2cd11a8, signal_id=567, detail=0) 
at ../../../../gobject/gsignal.c:3447
#5  0x005b3579 in gimp_tool_widget_changed (widget=0x2cd11a8) at 
gimptoolwidget.c:372
...
#67352 0x005b3579 in gimp_tool_widget_changed (widget=0x2cd11a8) at 
gimptoolwidget.c:372
#67353 0xb70a03c7 in g_object_notify_by_spec_internal (pspec=0x2cc5a68, 
object=0x2cd11a8) at ../../../../gobject/gobject.c:1175
#67354 g_object_notify (object=0x2cd11a8, property_name=0x8b565d "unit-angle") 
at ../../../../gobject/gobject.c:1223
#67355 0x0059a280 in gimp_tool_compass_update_angle 
(compass=compass@entry=0x2cd11a8, orientation=GIMP_COMPASS_ORIENTATION_AUTO, 
flip=flip@entry=0) at gimptoolcompass.c:1172
#67356 0x0059afaf in gimp_tool_compass_changed (widget=0x2cd11a8) at 
gimptoolcompass.c:460
#67357 0xb7099cc8 in g_closure_invoke (closure=0x259ffe0, return_value=0x0, 
n_param_values=1, param_values=0xbfffe7f0, invocation_hint=0xbfffe794) at 
../../../../gobject/gclosure.c:804
#67358 0xb70ad04d in signal_emit_unlocked_R (node=node@entry=0x2452f30, 
detail=detail@entry=0, instance=instance@entry=0x2cd11a8, emission_return=0x0, 
instance_and_params=0xbfffe7f0) at ../../../../gobject/gsignal.c:3565
#67359 0xb70b59a3 in g_signal_emit_valist (instance=, 
signal_id=, detail=, var_args=0xbfffe95c "M5[") 
at ../../../../gobject/gsignal.c:3391
#67360 0xb70b6155 in g_signal_emit (instance=0x2cd11a8, signal_id=567, 
detail=0) at ../../../../gobject/gsignal.c:3447
#67361 0x005b3579 in gimp_tool_widget_changed (widget=0x2cd11a8) at 
gimptoolwidget.c:372
#67362 0xb709d79d in g_object_notify_queue_thaw (object=object@entry=0x2cd11a8, 
nqueue=) at ../../../../gobject/gobject.c:296
#67363 0xb709f3fe in g_object_new_internal (class=class@entry=0x2286560, 
params=params@entry=0xbfffec5c, n_params=n_params@entry=7) at 
../../../../gobject/gobject.c:1856
#67364 0xb70a1010 in g_object_new_valist (object_type=, 
first_property_name=, var_args=) at 
../../../../gobject/gobject.c:2122
#67365 0xb70a10c9 in g_object_new (object_type=40330576, 
first_property_name=0x8c26e1 "shell") at ../../../../gobject/gobject.c:1642
#67366 0x0059b953 in gimp_tool_compass_new (shell=0x2824060, 
orientation=GIMP_COMPASS_ORIENTATION_AUTO, n_points=1, x1=896, y1=904, x2=0, 
y2=0, x3=0, y3=0) at gimptoolcompass.c:1192
#67367 0x0051e88a in gimp_measure_tool_start (coords=0xbfffef38, 
display=0x22dcf28, measure=0xd3ba60) at gimpmeasuretool.c:454
#67368 gimp_measure_tool_button_press (tool=0xd3ba60, coords=0xbfffef38, 
time=836017, state=GDK_BUTTON1_MASK, press_type=GIMP_BUTTON_PRESS_NORMAL, 
display=0x22dcf28) at gimpmeasuretool.c:250
#67369 0x0053f2f8 in gimp_tool_button_press (tool=0xd3ba60, coords=0xbfffef38, 
time=836017, state=GDK_BUTTON1_MASK, press_type=GIMP_BUTTON_PRESS_NORMAL, 
display=0x22dcf28) at gimptool.c:710
#67370 0x004f13a2 in tool_manager_button_press_active (gimp=0xd240a8, 
coords=0xbfffef38, time=836017, state=GDK_BUTTON1_MASK, 
press_type=GIMP_BUTTON_PRESS_NORMAL, display=0x22dcf28) at tool_manager.c:287
#67371 0x0058915a in gimp_display_shell_canvas_tool_events_internal 
(canvas=canvas@entry=0x280db90, event=event@entry=0x6b38b20, 
shell=shell@entry=0x2824060, next_event=0xb048) at 
gimpdisplayshell-tool-events.c:776
#67372 0x00589503 in gimp_display_shell_canvas_tool_events (canvas=0x280db90, 
event=0x6b38b20, shell=0x2824060) at gimpdisplayshell-tool-events.c:307
#67373 0xb7b4c6e7 in _gtk_marshal_BOOLEAN__BOXED (closure=0x282c1e0, 
return_value=0xb1d8, n_param_values=2, param_values=0xb220, 
invocation_hint=0xb1c4, marshal_data=0x0) at ./gtk/gtkmarshalers.c:84
#67374 0xb7099cc8 in g_closure_invoke (closure=0x282c1e0, 
return_value=0xb1d8, n_param_values=2, param_values=0xb220, 
invocation_hint=0xb1c4) at ../../../../gobject/gclosure.c:804
#67375 0xb70acf62 in signal_emit_unlocked_R (node=node@entry=0xeb03e0, 
detail=detail@entry=0, instance=instance@entry=0x280db90, 
emission_return=0xb2f8, instance_and_params=0xb220) at 

Bug#874961: [Pkg-kde-extras] Bug#874961: kmymoney: not ready for Qt5

[Micha Lenk]

Hi Pino,

Am 09.09.2018 um 23:08 schrieb Pino Toscano:
> In data domenica 9 settembre 2018 15:11:52 CEST, Micha Lenk ha scritto:
>> This is a short heads up that I intend to remove support for Qt4 from
>> libgwenhywfar on September 13th 2018. This will be done by dropping the
>> binary packages libgwengui-qt4-0 and libgwengui-qt4-dev from the
>> archive. As a consequence this will cause kmymoney to fail to build from
>> source in unstable due to the build dependency libgwengui-qt4-dev
>> becoming unavailable.
> 
> Well, thanks for the uncooperative pressure.  This is not helpful,
> given the current state of kmymoney (see below).

Please apologize for emitting some "uncooperative pressure", but the
reasons for not uploading kmymoney 5.0 to unstable were not visible
either. From what is visible in the Debian bug tracker, the package in
experimental looks like it is in a way better shape than the package in
unstable. For that reason I couldn't even imagine there are more issues
in kmymoney 5.0.1 than there are in 4.8.1. Also the upstream release
announcement for 5.0.0 sounds as if the 5.0 series is ready for prime
time now:

... this version has actually been used in production by
many of the developers, so it has actually had a significant
amount of testing.

I don't get what you're waiting for not uploading it to unstable. This
will not immediately make the package available to Debian stable users.
And users that deliberately install unstable/testing should know what
they are doing anyways, and hopefully file bugs for stuff that is
broken. Isn't this the release model that Debian is trying to drive?

> kmymoney 5.0.0 was the first version ported to Qt5/KF5, and was released
> after more than 2 years of upstream work, which included the actual
> Qt4->Qt5 and kdelibs4->KF5 switch. From my inspection of the release,
> there were bugs and regressions, and even the bugfix release 5.0.1 does
> not fix all of them.
> Sadly, the status of the development upstream is:
> - lots of refactoring commits, much less about fixing actual issues
> - stable branches sometimes get fixes, but then upstream almost does
>   not get to stabilize them into new bugfix releases (e.g. one year
>   between 4.8.0 and 4.8.1)
> 
> Upstream should release a 5.0.2 at the end of this month. My plan is to
> upload that to experimental, and see what's the feedback from users
> (not only Debian ones).
> 
> Considering that kmymoney is not a game nor a text editor, but an
> application that deals with personal money (and performs also online
> financial transactions), I was not confortable in uploading a new 5.0.0
> (or even 5.0.1) to unstable "just because". Of course YMMV on this.
> 
> Bottom line: if you make the rest of the work in unstable, even for
> the kdelibs4 version, harder for us (or me, at least), that would be
> very uncooperative, and really uncalled for.

Well, this is all news to me. So, this changes the picture for me quite
a lot. So, I think I will not do the announced removal of Qt 4 support
in libgwenhywfar, unless the Debian release managers poke me to do so.

I acknowledge, in the end the package maintainer who engages in some
upstream relation is in a much better position to decide whether a
certain upstream release is ready for unstable or not.

> And yes, I already know that kmymoney will be autoremoved from testing
> on 13th: this is thanks to another uncooperative DD, who likes to poke
> his nose into packages who he has no idea about.

Coordinating a Debian release is a pretty long term process and
sometimes means taking tough decisions. Yet, the release management team
can only digest the information that is available. If you don't speak
up, they can't help your case.

Regards,
Micha

Bug#895643: Patch for building using default-jdk (openjdk10)

[Hilko Bengen]

control: tag -1 patch

Dear maintainer(s),

here's a patch that fixes the FTBFS issues with openjdk-10 and removes
the openjdk-8 dependency.

Unfortunately, I do not know how to test whether the resulting package
still works.

Cheers,
-Hilko
>From 0c6569921d50bc0c9291653f9fe3b2d1cb9d79d8 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Subject: [PATCH] Add a cache for iconv_t handles to hive_t

It was brought to my attention that dumping a registry hive causes a
lot of time spent in disk I/O activity because iconv_open() and
iconv_close() are called for every key. Every iconv_open() call causes
/usr/lib/.../gconv/$ENCODING.so to be opened and mapped.

The iconv_t handles are now cached in the hive_h struct; they are
opened on-demand and re-used.

On my ~10 year old Lenovo T60, I have seen 57% savings in the overal
runtime of running

hivexregedit --export windows-8-enterprise-software.hive '\\'
---
 bootstrap|  1 +
 configure.ac |  2 ++
 lib/Makefile.am  |  2 ++
 lib/handle.c | 42 +-
 lib/hivex-internal.h | 31 ++-
 lib/node.c   |  6 +++---
 lib/utf16.c  | 38 --
 lib/value.c  | 10 +-
 lib/write.c  |  4 ++--
 m4/.gitignore|  2 ++
 10 files changed, 96 insertions(+), 42 deletions(-)

diff --git a/bootstrap b/bootstrap
index bd82477..373fad8 100755
--- a/bootstrap
+++ b/bootstrap
@@ -75,6 +75,7 @@ vc-list-files
 warnings
 xstrtol
 xstrtoll
+threadlib
 '
 
 $gnulib_tool			\
diff --git a/configure.ac b/configure.ac
index 547fb0d..8405774 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,7 +38,9 @@ AC_DEFINE([PACKAGE_VERSION_RELEASE],[hivex_release],[Release number])
 AC_DEFINE([PACKAGE_VERSION_EXTRA],["hivex_extra"],[Extra version string])
 
 gl_EARLY
+gl_THREADLIB_EARLY
 gl_INIT
+gl_THREADLIB
 
 AM_PROG_LIBTOOL
 
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 4a7cea1..62cdf35 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -38,6 +38,8 @@ libhivex_la_SOURCES = \
 	visit.c \
 	write.c
 
+libhivex_la_SOURCES += $(top_srcdir)/gnulib/lib/glthread/threadlib.c
+
 libhivex_la_LIBADD =  ../gnulib/lib/libgnu.la $(LTLIBOBJS)
 libhivex_la_LDFLAGS = \
 	-version-info 0:0:0 \
diff --git a/lib/handle.c b/lib/handle.c
index 9dcf81d..01b8d80 100644
--- a/lib/handle.c
+++ b/lib/handle.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef HAVE_MMAP
 #include 
@@ -62,6 +64,32 @@ header_checksum (const hive_h *h)
 
 #define HIVEX_OPEN_MSGLVL_MASK (HIVEX_OPEN_VERBOSE|HIVEX_OPEN_DEBUG)
 
+iconv_t *
+_hivex_get_iconv (hive_h *h, recode_type t)
+{
+  glthread_lock_lock (>iconv_cache[t].mutex);
+  if (h->iconv_cache[t].handle == NULL) {
+if (t == utf8_to_latin1)
+  h->iconv_cache[t].handle = iconv_open ("LATIN1", "UTF-8");
+else if (t == latin1_to_utf8)
+  h->iconv_cache[t].handle = iconv_open ("UTF-8", "LATIN1");
+else if (t == utf8_to_utf16le)
+  h->iconv_cache[t].handle = iconv_open ("UTF-16LE", "UTF-8");
+else if (t == utf16le_to_utf8)
+  h->iconv_cache[t].handle = iconv_open ("UTF-8", "UTF-16LE");
+  } else {
+/* reinitialize iconv context */
+iconv (h->iconv_cache[t].handle, NULL, 0, NULL, 0);
+  }
+  return h->iconv_cache[t].handle;
+}
+
+void
+_hivex_release_iconv (hive_h *h, recode_type t)
+{
+  glthread_lock_unlock (>iconv_cache[t].mutex);
+}
+
 hive_h *
 hivex_open (const char *filename, int flags)
 {
@@ -164,11 +192,17 @@ hivex_open (const char *filename, int flags)
 goto error;
   }
 
+  for (int t=0; t<3; t++) {
+glthread_lock_init (>iconv_cache[t].mutex);
+h->iconv_cache[t].handle = NULL;
+  }
+
   /* Last modified time. */
   h->last_modified = le64toh ((int64_t) h->hdr->last_modified);
 
   if (h->msglvl >= 2) {
-char *name = _hivex_windows_utf16_to_utf8 (h->hdr->name, 64);
+char *name = _hivex_recode (h, utf16le_to_utf8,
+h->hdr->name, 64, NULL);
 
 fprintf (stderr,
  "hivex_open: header fields:\n"
@@ -424,6 +458,12 @@ hivex_close (hive_h *h)
   else
 r = 0;
   free (h->filename);
+  for (int t=0; t<3; t++) {
+if (h->iconv_cache[t].handle != NULL) {
+  iconv_close (h->iconv_cache[t].handle);
+  h->iconv_cache[t].handle = NULL;
+}
+  }
   free (h);
 
   return r;
diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h
index 9a497ed..d04ae3c 100644
--- a/lib/hivex-internal.h
+++ b/lib/hivex-internal.h
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "byte_conversions.h"
 
@@ -35,6 +37,13 @@
 #define STRCASENEQLEN(a,b,n) (strncasecmp((a),(b),(n)) != 0)
 #define STRPREFIX(a,b) (strncmp((a),(b),strlen((b))) == 0)
 
+typedef enum {
+  utf8_to_latin1 = 0,
+  latin1_to_utf8,
+  utf8_to_utf16le,
+  utf16le_to_utf8,
+} recode_type;
+
 struct hive_h {
   char *filename;
   int fd;
@@ -79,6 +88,11 @@ struct hive_h {
   /* Internal data for 

Bug#908515: urwid interface can't call PAGER and crashes due to AttributeError

[Nis Martensen]

control: tags 908515 patch

> AttributeError: module 'reportbug.ui.urwid_ui' has no attribute 'system'

The pull request addressing #903969 fixes this one, too:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/4

Bug#908551: apt-listchanges: apt update hangs if no mail system

[Robert Luberda]

RJ writes:

reassign 908551 citadel-server  902-4
thanks

> 
> Versions of packages apt-listchanges suggests:
> ii  citadel-server [mail-transport-agent]  902-4


> -- Desription of problem:
> When performing a apt update today (Monday, September 10, 2018) there
> was a news bit about the Apache/2 package that required reading and
> confirmation.
> Upon confirmation the apt-listchanges script returned to attempt to send
> mail to the configured user email (which is just 'root' in this case.)

Yes, apt-listchanges tries to execute `/usr/sbin/sendmail -oi -t'
command. It skips sending mails if the command does not exist.

> IF a system either does not have a mail service installed 

You have citadel-server installed, that provides mail service, so it's
not the case.

> or is
> impropery configured, apt-listchanges will hang while attempting to send
> an email before it allows the update process to continue.

IMHO if a mail service is improperly configured than it should fail
instead of hanging... Then apt-listchanges would display warning message
like this (BTW. I've just temporaily installed the latest version of
citadel-server, trying to reproduce the bug, but its sendmail command
just fails, not hangs):

  apt-listchanges: Mail to root: apt-listchanges: changelogs for vox
citmail: can't connect: No such file or directory
apt-listchanges warning: Cannot send mail to root: Command
'['/usr/sbin/sendmail', '-oi', '-t']' returned non-zero exit status 3.

Then apt-listchanges would continue. I agree, that apt-listchanges could
have set some timeout for  the sendmail command, and I can try to add
such timeout in next version.

> 
> ** I was able to work around this by editing the apt-listchanges script
> file by commenting out the offending Mail section as follows:

A simpler solution would be to run `dpkg-reconfigure apt-listchanges'
and give an empty list of e-mail addresses in the question related to
mail addresses.

> As with the other related 'Wishlist' bug reports for apt-listchanges,
> there should be additional prompts added to this file to:
> 
> (1) Ask if the user wants to mail a report (default N). 

This is done during apt-listchanges installation time, providing that
your debconf settings allows the question about e-mail address list to
appear.

> - Also notify
> user that the process may hang if no mail subsystem exists (which I
> believe is now the case starting with stretch) or is improperly
> configured. (Just 'root')

I think that the sendmail command should hang when misconfigured or for
any other reason - that's why I am reassigning the bug report to
citadel-server. (BTW. I am not sure if this is possible in case of
citadel-server, but maybe sendmail command was trying to send e-mails
via network? How long did you wait before deciding that the command hung?).

> 
> (2) See other 3 reports related to MAIL for additional prompt suggestions.

Could you please be more specific? Which other 3 bug reports are related
to this one?

Regards,
robert

Bug#840032: Adopting execnet

[Scott Talbert]

On Tue, 11 Sep 2018, Scott Talbert wrote:

I don't mind adopting execnet as pytest-xdist uses it.  Do you mind granting 
me DM rights as you did for pytest-xdist?


BTW, I can take apipkg too.

Scott

Bug#840032: Adopting execnet

[Scott Talbert]

Hi Daniel,

I don't mind adopting execnet as pytest-xdist uses it.  Do you mind 
granting me DM rights as you did for pytest-xdist?


Thanks,
Scott

Bug#908557: [RESOLVED] Error while setting the maximum protocol version

[Heinrich Schuchardt]

The issue was resolved with libqt5network5_5.11.1+dfsg-8_amd64.deb

Bug#908323: gtk+3.0 breaks libgtk3-perl autopkgtest

[Jeremy Bicha]

Control: affects -1 src:gdk-pixbuf

On Tue, Sep 11, 2018 at 3:03 PM Paul Gevers  wrote:
> Control: affects -1 src:gtk+3.0
>
> Dear maintainers,
>
> With a recent upload of gtk+3.0 the autopkgtest of libgtk3-perl fails in
> testing when that autopkgtest is run with the binary packages of gtk+3.0
> from unstable. It passes when run with only packages from testing. This
> appears to be the same reason as reported in this bug.

The change that triggered this failure seems to be in gdk-pixbuf not
gtk3, but gdk-pixbuf is not a direct dependency of libgtk3-perl.

Thanks,
Jeremy Bicha

Bug#908620: jameica: Too many dependencies installed compared to official version

[Christian Weiske]

Package: jameica
Version: 2.8.1+dfsg-1
Severity: wishlist

Dear Maintainer,

When installing hibiscus via apt, 165 MiB worth of packages got installed.

When comparing this to the official packages
(jameica 25 MiB + 10 MiB for hibiscus)
this seems much too much.

It would be nice if installing hibiscus would not take so much space. 

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

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

Versions of packages jameica depends on:
ii  eclipse-platform-data 3.8.1-11
ii  eclipse-rcp   3.8.1-11
ii  libbcpkix-java1.60-1
ii  libbcprov-java1.60-1
ii  libcommons-cli-java   1.4-1
ii  libcommons-collections3-java  3.2.2-1
ii  libcommons-lang-java  2.6-8
ii  libcommons-logging-java   1.2-2
ii  libequinox-osgi-java  3.9.1-1
ii  libh2-java1.4.197-2
ii  libicu4j-49-java  49.1-3
ii  libjameica-datasource-java2.8.1+dfsg-3
ii  libjameica-util-java  2.8-2
ii  libnanoxml2-java  2.2.3.dfsg-6
ii  libpaperclips-java1.0.4-2
ii  libswt-cairo-gtk-4-jni4.6.3-2
ii  libswt-gtk2-4-jni 4.6.3-2
ii  libswtcalendar-java   0.5-2
ii  velocity  1.7-5

jameica recommends no packages.

Versions of packages jameica suggests:
ii  libmckoisqldb-java  1.0.6-2

-- no debconf information

Bug#908619: reportbug: Crash when reporting bug: TypeError: fixer() missing argument: 'check_hostname'

[Christian Weiske]

Package: reportbug
Version: 7.5.0
Severity: important

Dear Maintainer,

When trying to report a bug with "reportbug" that is configured to use
the gtk2 interface, it crashes.

Steps to reproduce:
1. Configure reportbug to use gtk2 interface
2. Run "reportbug reportbug"
3. It crashes:

cweiske:~> reportbug reportbug
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1049, in 
sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 1072, in 
get_reports
bugs = debianbts.get_bugs(pkg_filter, package)
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 410, in 
get_bugs
reply = soap_client.call('get_bugs', method_el)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 260, in 
call
self.xml_response = self.send(method, self.xml_request)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 313, in 
send
location, http_method, body=xml, headers=headers)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1395, in 
request
self.disable_ssl_certificate_validation)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 978, in 
__init__
timeout=timeout, context=context)
TypeError: fixer() missing 1 required positional argument: 'check_hostname'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2266, in 
main()
  File "/usr/bin/reportbug", line 1109, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1722, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1763, in 
func
args, kwargs = op.sync_pre_operation(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1051, in 
sync_pre_operation
error_dialog("Unable to connect to %s BTS." % sysinfo['name'])
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 137, in 
error_dialog
_assert_context(ui_context)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 92, in 
_assert_context
(_describe_context(really), _describe_context(expected)))
AssertionError: Function should be called in  
but was called in 



-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="text"

** /home/cweiske/.reportbugrc:
reportbug_version "7.5.0"
mode standard
ui text
email "cweiske+bugs.debian@cweiske.de"

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

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

Versions of packages reportbug depends on:
ii  apt1.6.4
ii  python33.6.6-1
ii  python3-reportbug  7.5.0
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
ii  claws-mail   3.17.1-1
pn  debconf-utils
pn  debsums  
pn  dlocate  
ii  dma [mail-transport-agent]   0.11-1+b1
pn  emacs24-bin-common | emacs25-bin-common  
ii  file 1:5.34-2
ii  gnupg2.2.10-1
pn  python3-urwid
pn  reportbug-gtk
ii  xdg-utils1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.6.4
ii  file   1:5.34-2
ii  python33.6.6-1
ii  python3-apt1.6.2
ii  python3-debian 0.1.33
ii  python3-debianbts  2.7.2
ii  python3-requests   2.18.4-2

python3-reportbug suggests no packages.

-- no debconf information

Bug#908618: jameica: MySQL not usable; class not found: com.mysql.jdbc.Driver

[Christian Weiske]

Package: jameica
Version: 2.8.1+dfsg-1
Severity: normal

Dear Maintainer,

I am running a hibiscus server in my network that stores its data in a MySQL
database. Several clients access this very database.

When trying to configure the jameica+hibiscus versions shipped with Debian to
do just this, it crashes because it cannot load the MySQL driver.

I manually installed libmysql-java for this and also added both
 /usr/share/java/mysql.jar
and
 /usr/share/java/mysql-connector-java.jar
to the class path (by running
 $ CLASSPATH=".:/usr/share/java/mysql.jar..." jameica
)
This did not help.

The exception message is:

[Tue Sep 11 22:27:13 CEST 2018][ERROR][main][de.willuhn.jameica.hbci.HBCI.call] 
unable to init db service
java.rmi.RemoteException: unable to load jdbc driver; nested exception is: 
java.lang.ClassNotFoundException: loader.jameica: class not found: 
com.mysql.jdbc.Driver
at de.willuhn.datasource.db.DBServiceImpl.start(DBServiceImpl.java:287)
at de.willuhn.jameica.hbci.HBCI.call(HBCI.java:331)
at de.willuhn.jameica.hbci.HBCI.init(HBCI.java:104)
at 
de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:395)
at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:240)
at de.willuhn.jameica.services.PluginService.init(PluginService.java:39)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:72)
at de.willuhn.jameica.system.Application.init(Application.java:103)
at 
de.willuhn.jameica.system.Application.newInstance(Application.java:87)
at de.willuhn.jameica.Main.main(Main.java:75)
Caused by: java.lang.ClassNotFoundException: loader.jameica: class not found: 
com.mysql.jdbc.Driver
at 
de.willuhn.util.MultipleClassLoader.load(MultipleClassLoader.java:300)
at 
de.willuhn.util.MultipleClassLoader.loadClass(MultipleClassLoader.java:227)
at de.willuhn.datasource.db.MyDriver.(MyDriver.java:47)
at de.willuhn.datasource.db.DBServiceImpl.start(DBServiceImpl.java:283)
... 11 more

Instructions how to switch jameica/hibiscus to MySQL are at:
https://www.willuhn.de/wiki/doku.php?id=support:mysql[]=server#hibiscus_konfigurieren

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

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

Versions of packages jameica depends on:
ii  eclipse-platform-data 3.8.1-11
ii  eclipse-rcp   3.8.1-11
ii  libbcpkix-java1.60-1
ii  libbcprov-java1.60-1
ii  libcommons-cli-java   1.4-1
ii  libcommons-collections3-java  3.2.2-1
ii  libcommons-lang-java  2.6-8
ii  libcommons-logging-java   1.2-2
ii  libequinox-osgi-java  3.9.1-1
ii  libh2-java1.4.197-2
ii  libicu4j-49-java  49.1-3
ii  libjameica-datasource-java2.8.1+dfsg-3
ii  libjameica-util-java  2.8-2
ii  libnanoxml2-java  2.2.3.dfsg-6
ii  libpaperclips-java1.0.4-2
ii  libswt-cairo-gtk-4-jni4.6.3-2
ii  libswt-gtk2-4-jni 4.6.3-2
ii  libswtcalendar-java   0.5-2
ii  velocity  1.7-5

jameica recommends no packages.

Versions of packages jameica suggests:
ii  libmckoisqldb-java  1.0.6-2

-- no debconf information

Bug#908471: atril: include AppArmor profile in the package

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-09-11 at 06:11 +, Mike Gabriel wrote:
> > I have to admit I'm quite confused to have atril forking a Webkit  
> > renderer for
> > a PDF file, but that also mean it's harder than just reusing the profile.
> 
> I think that the webkit stuff was added with epub support. I'll ping  
> upstream on this.
> 
> Please send over the file that you already have and I will continue  
> from their.

To be honest, I just got the two files linked above, ran s/evince/atril/ and
stored them in /etc/apparmor.d/usr.bin.atril and
/etc/apparmor.d/abstractions/atril. I didn't investigate further.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluYItsACgkQ3rYcyPpX
RFuC0ggAzVlClEmgCGmOnzGeDTGMp25xZSZx9nlyMS7NlJZxzaAjIyKYqYwW36E6
nv4BNJ379+uX182HCkaG/0y6kRtCquM51PaonjMDcrz3zT+LVu63+myvhLIOmtAu
ngrzvTA2YpL8eF+2SPuujnt1ADqqnFhKdM7sZ9PjNqfggHFoy04Soqy3VsgIt+GU
7yliv+5cpPBwCNOJ0WAwMJHlZxJaOFmEnxRkJbSGwqjG/I5dXS8yKidBl7O5Vt6W
Jos/u6RzPUiCFhQvkFCUoL0DpQYC/+Ag1UKL+xJR+LskQ4cGdV9I/IUVagaytsGj
RUyib97SdNA2ypqJZ7L8oHbfp+HEPg==
=oSQJ
-END PGP SIGNATURE-

Bug#792881: britney: Revise handling of "hijacked binaries"

[Paul Gevers]

On Sun, 19 Jul 2015 18:38:38 +0200 Niels Thykier  wrote:
> This bug is a reminder to look into this and patch Britney as
> necessary to handle this situation correctly (or document why the
> current practise is correct, if this is the case).

It seems that at least the autopkgtest code is (or was) not considering
"hijacks".

On 2018-04-22 21:37:05 UTC, britney triggered a run of libreoffice due
to x11proto-render while its binary x11proto-render-dev was taken over
by xorgproto.

https://ci.debian.net/data/autopkgtest/testing/amd64/libr/libreoffice/197534/log.gz

Paul



signature.asc
Description: OpenPGP digital signature

Bug#908616: OpenAFS security release

[Salvatore Bonaccorso]

Hey!

On Tue, Sep 11, 2018 at 02:30:51PM -0500, Benjamin Kaduk wrote:
> Source: openafs
> Version: 1.6.9-2+deb8u7
> Tags: security
> Severity: serious
> 
> OpenAFS upstream released security releases 1.6.23 and 1.8.2 today, fixing:
> http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt
> http://openafs.org/pages/security/OPENAFS-SA-2018-002.txt
> http://openafs.org/pages/security/OPENAFS-SA-2018-003.txt
> 
> No CVEs have been assigned yet.

Would it be possible, that you with both your maintainers and upstream
part could request accordingly CVEs via http://cveform.mitre.org/ (and
then loop back the assignment here once got those).

Regards,
Salvatore

Bug#908351: gajim: Throws errors soon after startup, doesn't work, won't quit

[W. Martin Borgert]

Quoting Matto Marjanovic :

Yes:  I've now compiled/installed from gajim's master (which includes that
commit), and it appears to be working a-ok.


Great! Thanks for testing!

I'll close the bug with the next upstream version then.

Bug#908610: prosody-modules: please add mod_register_web to package prosody-modules

[W. Martin Borgert]

Sven, you did very well with your bug report :~)
Thank you!

I'll add the module, if no problems arise with it.

Bug#908606: picocli: Incomplete debian/copyright?

[Miroslav Kravec]

Hello Chris,

On Tue, Sep 11, 2018 at 8:48 PM Chris Lamb  wrote:
>
> I just ACCEPTed picocli from NEW but noticed it was missing
> attribution in debian/copyright for at least Robert Zenz.
>
> This is in no way exhaustive so please check over the entire package
> carefully and address these on your next upload.

Thank you for processing and ACCEPTing picocli package.

I'm sorry for issue with debian/copyright. I'll check over entire
package, and add missing attributions, and make new (next) upload.

Kind regards,
Miroslav Kravec
On Tue, Sep 11, 2018 at 8:48 PM Chris Lamb  wrote:
>
> Source: picocli
> Version: 3.5.2-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Miroslav Kravec ,
> ftpmas...@debian.org
>
> Hi,
>
> I just ACCEPTed picocli from NEW but noticed it was missing
> attribution in debian/copyright for at least Robert Zenz.
>
> This is in no way exhaustive so please check over the entire package
> carefully and address these on your next upload.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#908494: lightning: no icon to access calendar after upgrade to TB 60

[Carsten Schoenert]

Control: severity -1 important
Control: tags -1 unreproducible

On Mon, Sep 10, 2018 at 05:23:22PM +0100, George B. wrote:
> > what have you tried to debug the issue?
> 
> Deleted my Thunderbird profile and tested with a fresh one.
> 
> Tried "thunderbird --jsconsole" but there is no output.
> 
> Lightning is the only extension installed.
> Extension is listed as enabled in the "Add-ons" screen.
> Clicking on "Tools -> Add-on Preferences -> Lightning" brings up the
> "Advanced" section of Tunderbird Preferences.

To see if I can reproduce this behavior anyhow I have setup now a
complete new install of an Stretch system on i386 with and without the
Thunderbird packages with a further dist-upgrade to testing and start
the testing again within a Gnome3 desktop environment.

At no point I've seen a broken Lighting installation, no matter if I
copy a existing HOME folder into new the user profile or if I add
additional a existing Thunderbird profile into the new user profile
finally. I got always a working Lightning. So it's currently not a
problem of the Thunderbird packages.

The information from above is unfortunately a bare minimum of
information about your system and setup. Without additional information
it's impossible to do any further debugging from here.
The information from the first email is showing that debconf-show was
failing. That is unusual and must have a reason. This hides some maybe
interesting additional information about the packages around TB on your
system.

You also have written that Lightning is shown within the Extension
overview, this means Thunderbird has successful detected the Lightning
extension. So from the application view Lighting is around.
Is Ctrl+Shift+C showing the Calendar?

Currently I have no further idea how I can debug this a bit more, for me
it makes not really sense to do a lot of Q about some really basic
things if you can't do some more self research on your side.

I'm happy if other user can step in and try to help to untagle this
report.

Regards
Carsten

Bug#908617: manpages-fr-extra: Description de l'option "status=progress" dans le man de "dd"

[clohr]

Package: manpages-fr-extra
Version: 20151231
Severity: minor
Tags: l10n

Chers traducteurs,
  Je remarque que l'option "status=progress" n'est pas mentionnée dans la
version française du man de "dd".

Cordialement
Christophe



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

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

manpages-fr-extra depends on no packages.

Versions of packages manpages-fr-extra recommends:
ii  manpages-fr  3.65d1p1-1

Versions of packages manpages-fr-extra suggests:
ii  man-db [man-browser]  2.8.4-2
ii  manpages-fr-dev   3.65d1p1-1

-- no debconf information

Bug#903698: fixed in dh-python 3.20180723

[Paul Gevers]

Hi all, dear Piotr,

On Tue, 24 Jul 2018 09:42:34 +0200 Paul Gevers  wrote:
> On Mon, 23 Jul 2018 13:34:11 + =?utf-8?q?Piotr_O=C5=BCarowski?=
>  wrote:
> >* dh_python{2,3}:
> >  - fix \.so.* symlink renaming for non-default Python versions
> >(closes: 739500, 903698)
> 
> Thanks for the fix. It worked on all arches where sphinxbase was rebuild
> except for mipsel64el (see below), hence I reopen the bug.

Any progress on this issue? Do I need to start work around the issue (if
this is possible)?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#908616: OpenAFS security release

[Benjamin Kaduk]

Source: openafs
Version: 1.6.9-2+deb8u7
Tags: security
Severity: serious

OpenAFS upstream released security releases 1.6.23 and 1.8.2 today, fixing:
http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt
http://openafs.org/pages/security/OPENAFS-SA-2018-002.txt
http://openafs.org/pages/security/OPENAFS-SA-2018-003.txt

No CVEs have been assigned yet.

-Ben

Bug#908597: Re : Bug#908597: nvidia-kernel-dkms: Unable to upgrade and to reinstall

[nicolas . patrois]

Le 11/09/2018 17:22:44, Luca Boccassi a écrit :

> Why are you running on sid with a years old 4.3 kernel? That's not
> supported...

Who knows… because until this morning it worked. I’ll keep it now as a rescue 
kernel.
I tried to upgrade to 4.18 and crash.
4.17 works fine, you can close the bug.

Thank you,
nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#908615: pyfai: FTBFS and autopkgtest fails with python3.7 in supported versions

[Paul Gevers]

Source: pyfai
Version: 0.15.0+dfsg1-1
Severity: serious
Tags: ftbfs
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

[X-Debbugs-CC set to: debian...@lists.debian.org,
python3-defau...@packages.debian.org]

Dear maintainers,

Since the python3.7 transition started (which added python3.7 to the
supported Python versions) the autopkgtest of pyfai fails in testing
when that autopkgtest is run with the binary packages of
python3-defaults from unstable. It passes when run with only packages
from testing. I copied some of the output at the bottom of this report.
It seems that this failure also causes the package to FTBFS on
reproducible builds:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyfai.html

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from python3-defaults should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

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

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyfai/972161/log.gz

autopkgtest [05:07:40]: test python3: [---
=== python3.7 ===
Unable to import pyFAI.ext.splitBBoxLUT for Look-up table based
azimuthal integration
Unable to import pyFAI.ext.splitPixel full pixel splitting: cannot
import name 'splitPixel' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitBBox Bounding Box pixel splitting:
cannot import name 'splitBBox' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.histogram Cython histogram implementation:
cannot import name 'histogram' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitBBoxCSR CSR based azimuthal integration:
cannot import name 'splitBBoxCSR' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitPixelFullCSR CSR based azimuthal
integration: cannot import name 'splitPixelFullCSR' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pyFAI/__init__.py", line 73, in tests
res = test.run_tests()
  File "/usr/lib/python3/dist-packages/pyFAI/test/__init__.py", line 59,
in run_tests
if not runner.run(suite()).wasSuccessful():
  File "/usr/lib/python3/dist-packages/pyFAI/test/__init__.py", line 50,
in suite
from . import test_all
  File "/usr/lib/python3/dist-packages/pyFAI/test/test_all.py", line 47,
in 
from . import test_histogram
  File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py",
line 45, in 
from ..ext.histogram import histogram, histogram2d
ModuleNotFoundError: No module named 'pyFAI.ext.histogram'
autopkgtest [05:07:41]: test python3: ---]
autopkgtest [05:10:47]: test python3-dbg: [---
=== python3.7 ===
/usr/lib/python3.7/importlib/_bootstrap.py:219: ImportWarning: can't
resolve package from __spec__ or __package__, falling back on __name__
and __path__
  return f(*args, **kwds)
/usr/lib/python3/dist-packages/h5py/_hl/base.py:19: DeprecationWarning:
Using or importing the ABCs from 'collections' instead of from
'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import (Mapping, MutableMapping, KeysView,
/usr/lib/python3.7/importlib/_bootstrap.py:219: ImportWarning: can't
resolve package from __spec__ or __package__, falling back on __name__
and __path__
  return f(*args, **kwds)
Unable to import pyFAI.ext.splitBBoxLUT for Look-up table based
azimuthal integration
Unable to import pyFAI.ext.splitPixel full pixel splitting: cannot
import name 'splitPixel' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitBBox Bounding Box pixel splitting:
cannot import name 'splitBBox' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.histogram Cython histogram implementation:
cannot import name 'histogram' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitBBoxCSR CSR based azimuthal integration:
cannot import name 'splitBBoxCSR' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)
Unable to import pyFAI.ext.splitPixelFullCSR CSR based azimuthal
integration: cannot import name 'splitPixelFullCSR' from 'pyFAI.ext'
(/usr/lib/python3/dist-packages/pyFAI/ext/__init__.py)

Bug#908614: bro: CVE-2018-16807: memory leak in kerberos scripts

[Salvatore Bonaccorso]

Source: bro
Version: 2.5-1
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for bro.

CVE-2018-16807[0]:
| In Bro through 2.5.5, there is a memory leak potentially leading to DoS
| in scripts/base/protocols/krb/main.bro in the Kerberos protocol parser.

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-16807
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16807
[1] https://github.com/bro/bro/commit/34d0cf886ca16c665f673a299e295b2a2bc14533

Regards,
Salvatore

Bug#908613: ruby-rspec breaks chef autopkgtest

[Paul Gevers]

Source: ruby-rspec, chef
Control: found -1 ruby-rspec/3.8.0c0e1m0s0-1
Control: found -1 chef/13.8.7-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of ruby-rspec the autopkgtest of chef fails in
testing when that autopkgtest is run with the binary packages of
ruby-rspec from unstable. It passes when run with only packages from
testing. I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
of ruby-rspec to testing [1]. Due to the nature of this issue, I filed
this bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-rspec

https://ci.debian.net/data/autopkgtest/testing/amd64/c/chef/972119/log.gz

Failures:

  1) Chef::RunContext::ChildRunContext with a run context with stuff in
it and a child run context resource_collection is not the same as the parent
 Failure/Error: expect(child.resource_collection).to include f

   expected {"instance_vars" => {:@resource_list =>
#},
"json_class" => "Chef::ResourceCollection"} to include 



  2) Shell::SoloLegacySession returns a collection based on it's
compilation object and the extra recipe provided by chef-shell
 Failure/Error: expect(@session.resource_collection).to include(kitteh)

   expected {"instance_vars" => {:@resource_list =>
#},
"json_class" => "Chef::ResourceCollection"} to include 



  3) Shell::SoloLegacySession generates its resource collection from the
compiled cookbooks and the ad hoc recipe
 Failure/Error: expect(@session.resource_collection).to
include(kitteh_cat, keyboard_cat)

   expected {"instance_vars" => {:@resource_list =>
#},
"json_class" => "Chef::ResourceCollection"} to include  and 



Finished in 2 minutes 55.5 seconds (files took 7.42 seconds to load)
11422 examples, 3 failures, 24 pending

Failed examples:

rspec ./spec/unit/run_context/child_run_context_spec.rb:54 #
Chef::RunContext::ChildRunContext with a run context with stuff in it
and a child run context resource_collection is not the same as the parent
rspec ./spec/unit/shell/shell_session_spec.rb:203 #
Shell::SoloLegacySession returns a collection based on it's compilation
object and the extra recipe provided by chef-shell
rspec ./spec/unit/shell/shell_session_spec.rb:220 #
Shell::SoloLegacySession generates its resource collection from the
compiled cookbooks and the ad hoc recipe

/usr/bin/ruby2.5  --format documentation failed




signature.asc
Description: OpenPGP digital signature

Bug#908612: stretch-pu: package ganeti/2.15.2-7+deb9u3

[Apollon Oikonomopoulos]

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

Dear SRMs,

I'd like to update ganeti in Stretch once more, fixing the following 
issues:

 - The fix for #895599 that was included in +deb9u2 unfortunately was 
   incomplete; I failed to cherry-pick an additional patch rendering the 
   fix ineffective.

 - Ganeti uses an embedded CA to establish trust between cluster nodes.  
   This CA signs certificates using SHA-1 digests by default and 
   SHA-1-signed certificates are not acceptable by OpenSSL when a 
   security level of 2 or higher is in effect. OpenSSL in Buster will 
   (most probably) have a security level of 2 on by default, meaning 
   that upon upgrading to Buster ganeti clusters will experience 
   breakage. Since SHA-1 is weak and deprecated anyway, I would like to 
   backport a change from unstable to make the CA use SHA-256 for 
   certificate signatures, to allow cluster administrators to upgrade 
   their crypto before actually upgrading to Buster. See #907216 and 
   #907569 for more information.

 - The bash completion script shipped in Stretch is ineffective.  
   Although nothing changed on Ganeti's side between Jessie and Stretch, 
   bash completion stopped working when dh_bash-completion stopped 
   placing scripts in /etc/bash_completion.d/ (see #668254) and moved to 
   /usr/share/bash-completion/ instead. This change broke ganeti's 
   completion because it is not autoloadable: there's only one script 
   which does not match any command name (see #864755). This has already 
   been fixed in unstable by symlinking the completion file to all 
   supported command names. This being really a regression from a 
   functional point of view, I would like to backport the fix to 
   Stretch.

Attached is the full source debdiff for the proposed update. I might 
update the wording in d/NEWS and the `gnt-cluster verify' output before 
uploading, but functionally I don't expect any further changes.

Regards,
Apollon
diff -Nru ganeti-2.15.2/debian/changelog ganeti-2.15.2/debian/changelog
--- ganeti-2.15.2/debian/changelog  2018-06-11 17:42:10.0 +0300
+++ ganeti-2.15.2/debian/changelog  2018-09-08 20:22:03.0 +0300
@@ -1,3 +1,14 @@
+ganeti (2.15.2-7+deb9u3) stretch; urgency=medium
+
+  * Properly verify SSL certificates during VM export (#2) (Closes: #895599, 
#908112)
+  * Sign generated certificates using SHA256 instead of SHA1 (Closes: #907569)
++ d/NEWS: ask users to run gnt-cluster renew-crypto
++ cluster verify: warn about weak certificates
+  * Make bash completions autoloadable (Closes: #864755)
++ Cleanup obsolete /etc/bash_completion.d/ganeti
+
+ -- Apollon Oikonomopoulos   Sat, 08 Sep 2018 20:22:03 
+0300
+
 ganeti (2.15.2-7+deb9u2) stretch; urgency=medium
 
   * Properly verify SSL certificates during VM export (Closes: #895599)
diff -Nru ganeti-2.15.2/debian/ganeti.maintscript 
ganeti-2.15.2/debian/ganeti.maintscript
--- ganeti-2.15.2/debian/ganeti.maintscript 1970-01-01 02:00:00.0 
+0200
+++ ganeti-2.15.2/debian/ganeti.maintscript 2018-09-08 20:22:03.0 
+0300
@@ -0,0 +1 @@
+rm_conffile /etc/bash_completion.d/ganeti 2.15.2-7+deb9u3~
diff -Nru ganeti-2.15.2/debian/gbp.conf ganeti-2.15.2/debian/gbp.conf
--- ganeti-2.15.2/debian/gbp.conf   2018-06-11 17:42:10.0 +0300
+++ ganeti-2.15.2/debian/gbp.conf   2018-09-08 20:22:03.0 +0300
@@ -4,6 +4,8 @@
 upstream-tag = v%(version)s
 upstream-tree = tag
 upstream-branch = stable-2.15
+debian-branch = debian/stable/stretch
+dist = stretch
 
 [git-buildpackage]
 export-dir = ../build-area/
diff -Nru ganeti-2.15.2/debian/NEWS ganeti-2.15.2/debian/NEWS
--- ganeti-2.15.2/debian/NEWS   2018-06-11 17:42:10.0 +0300
+++ ganeti-2.15.2/debian/NEWS   2018-09-08 20:22:03.0 +0300
@@ -1,3 +1,27 @@
+ganeti (2.15.2-7+deb9u2) stretch; urgency=medium
+
+  This version changes Ganeti's internal CA, which is used to secure
+  intra-cluster RPC, to use SHA256 digests when signing certificates.
+  Previously issued certificates were signed using SHA1 and will be rejected
+  by newer OpenSSL versions, causing cluster malfunction. This will be a
+  problem with the upcoming Debian Buster release, so Ganeti's CA must be
+  switched over to SHA-256 before upgrading to Buster.
+
+  After upgrading all nodes to this package version, please run
+
+gnt-cluster renew-crypto --new-cluster-certificate
+
+  at a convenient time to re-generate the cluster's certificates using the new
+  signing algorithm. This operation does not incur any instance downtime,
+  however you will not be able to issue any gnt-* commands while renew-crypto
+  is running.
+
+  If you are using built-in certificates for RAPI and/or spice, please
+  consider adding --new-rapi-certificate and --new-spice-certificate
+  respectively to the above command.
+
+ -- Apollon Oikonomopoulos   Mon, 03 Sep 2018 14:36:39 
+0300
+
 ganeti 

Bug#908611: morris: please re-enable gconf support for buster

[Adrian Bunk]

Package: morris
Version: 0.2-4
Severity: normal

gconf has been adopted and will be in buster,
please please re-enable gconf support to make
settings persistent again.

Bug#908610: prosody-modules: please add mod_register_web to package prosody-modules

[Sven Wagner]

Package: prosody-modules
Severity: wishlist

Dear Maintainer,

please add mod_register_web to prosody-modules package.
I run a server with debian stable and use the prosody and prosody-modules
package from the backports. It would be extremly helpfull for me, if 
mod_register_web would be available in the backports.
This is my first bugreport, so please excuse my mistakes and don't hesitate to
tell me, what I did wrong. 

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

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

Versions of packages prosody-modules depends on:
pn  lua-ldap  
pn  prosody   

prosody-modules recommends no packages.

prosody-modules suggests no packages.

Bug#908456: invesalius is no longer installable

[Andreas Tille]

On Tue, Sep 11, 2018 at 03:31:18PM -0300, Thiago Franco de Moraes wrote:
> >
> > This was easy - see my latest commit.
> 
> Thanks!

You are welcome.
 
> I created a patch to remove the python2 shebangs. This patch was already 
> applied into the upstream. But there is other problem:

Fine.
 
> W: invesalius: executable-not-elf-or-script 
> usr/share/invesalius/invesalius/gui/widgets/gradient.py
> W: invesalius: executable-not-elf-or-script 
> usr/share/invesalius/invesalius/data/viewer_slice.py
> W: invesalius: executable-not-elf-or-script 
> usr/share/invesalius/invesalius/data/viewer_volume.py
> 
> This is happening because these files have execution permission:
> 
> ▶ find -executable -type f -name "*.py"
> ./invesalius/data/viewer_slice.py
> ./invesalius/data/viewer_volume.py
> ./invesalius/gui/widgets/gradient.py

I decided to ignore this for this upload.
 
> This is a problem at the upstream. I don't know why this happened, maybe 
> someone using Windows ... I already fixed this problem at the upstream. But I 
> don't know how to solve this problem in the packaging.
> 
> ...
> So I think this is fixed.

Yes.  I just uploaded and leave those permission issues for a later
upload.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#908323: gtk+3.0 breaks libgtk3-perl autopkgtest

[Paul Gevers]

Control: affects -1 src:gtk+3.0

Dear maintainers,

With a recent upload of gtk+3.0 the autopkgtest of libgtk3-perl fails in
testing when that autopkgtest is run with the binary packages of gtk+3.0
from unstable. It passes when run with only packages from testing. This
appears to be the same reason as reported in this bug.

Currently this regression is contributing to the delay of the migration
of gtk+3.0 to testing [1]. To notify the maintainers of that package of
the reason of the delay, I write this message to this bug with them is CC.

More information about this message can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gtk+3.0

https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgtk3-perl/972111/log.gz




signature.asc
Description: OpenPGP digital signature

Bug#908609: gtkhash: cannot fulfill the build dependencies

[Adrian Bunk]

Source: gtkhash
Version: 1.1.1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=gtkhash

gtkhash build-depends on:
- libthunarx-2-dev:arm64
libthunarx-2-dev depends on missing:
- thunar-data:arm64 (= 1.6.15-1)


Ubuntu seems to have a fix for the
libthunarx-2-dev -> libthunarx-3-dev
transition.

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Sebastian Andrzej Siewior]

On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote:
> Dmitry already implemented my short-term workaround:
> https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
> 
> When this has been built on all release architectures openssl can bump 
> the version requirement.
> 
> Even more cautious would be to wait until testing migration of Qt.

now after what happens I consider this issue (#908567) fixed since the
only affected package by this is fixed. Also adding versioned depends is
not easy as I expected it in the morning without too much mess around
it.

> cu
> Adrian

Sebastian

Bug#908608: xfdesktop4: cannot fulfill the build dependencies

[Adrian Bunk]

Source: xfdesktop4
Version: 4.12.4-1
Severity: serious
Tags: ftbfs
Control: fixed -1 4.13.2-1
Control: close -1

The following packages have unmet dependencies:
 builddeps:xfdesktop4 : Depends: libthunarx-2-dev (>= 1.4.0) but it is not 
going to be installed


This is already fixed in experimental.

Bug#908607: pgformatter: Incomplete debian/copyright?

[Chris Lamb]

Source: pgformatter
Version: 3.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Christoph Berg , 
ftpmas...@debian.org

Hi,

I just ACCEPTed pgformatter from NEW but noticed it was missing 
attribution in debian/copyright for at least Beautify.pm, which
also appears to be a code copy (?).

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#908606: picocli: Incomplete debian/copyright?

[Chris Lamb]

Source: picocli
Version: 3.5.2-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Miroslav Kravec , 
ftpmas...@debian.org

Hi,

I just ACCEPTed picocli from NEW but noticed it was missing 
attribution in debian/copyright for at least Robert Zenz.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#908456: invesalius is no longer installable

[Thiago Franco de Moraes]

On Tue, Sep 11, 2018 at 1:49 PM Andreas Tille  wrote:
>
> Hi Thiago,
>
> On Tue, Sep 11, 2018 at 10:21:51AM -0300, Thiago Franco de Moraes wrote:
> > Hi Andreas,
> >
> > Done! I've just pulled the changes to Salsa. I created a new release 
> > (3.1.2).
>
> Good. :-)
>
> > But I'm getting this warning:
> >  dpkg-gencontrol: warning: Depends field of package invesalius: unknown 
> > substitution variable ${python:Depends}
>
> This was easy - see my latest commit.

Thanks!

> > This warning happens with both my last version and with the last change you 
> > did. I'm using "gbp buildpackage" to create the package in Ubuntu and 
> > Debian Sid. I tested the package in Debian Sid and it is working correctly.
>
> Hmmm, here is a less easy one - no idea why you do not get this.  There
> are some remaining Python2 scripts that need to be ported:
>
> E: invesalius: missing-dep-for-interpreter python2 => python:any | 
> python-minimal:any | python2:any | python2-minimal:any 
> (usr/share/invesalius/invesalius/data/viewer_slice.py) #!/usr/bin/python2
> N:
> N:You used an interpreter for a script that is not in an essential
> N:package. In most cases, you will need to add a Dependency on the package
> N:that contains the interpreter. If the dependency is already present,
> N:please file a bug against Lintian with the details of your package so
> N:that its database can be updated.
> N:  
> N:In some cases a weaker relationship, such as Suggests or Recommends,
> N:will be more appropriate.
> N:  
> N:Severity: important, Certainty: possible
> N:  
> N:Check: scripts, Type: binary
> N:
> E: invesalius: missing-dep-for-interpreter python2 => python:any | 
> python-minimal:any | python2:any | python2-minimal:any 
> (usr/share/invesalius/invesalius/data/viewer_volume.py) #!/usr/bin/python2
> E: invesalius: missing-dep-for-interpreter python2 => python:any | 
> python-minimal:any | python2:any | python2-minimal:any 
> (usr/share/invesalius/invesalius/gui/widgets/gradient.py) #!/usr/bin/python2

I created a patch to remove the python2 shebangs. This patch was already 
applied into the upstream. But there is other problem:

W: invesalius: executable-not-elf-or-script 
usr/share/invesalius/invesalius/gui/widgets/gradient.py
W: invesalius: executable-not-elf-or-script 
usr/share/invesalius/invesalius/data/viewer_slice.py
W: invesalius: executable-not-elf-or-script 
usr/share/invesalius/invesalius/data/viewer_volume.py

This is happening because these files have execution permission:

▶ find -executable -type f -name "*.py"
./invesalius/data/viewer_slice.py
./invesalius/data/viewer_volume.py
./invesalius/gui/widgets/gradient.py

This is a problem at the upstream. I don't know why this happened, maybe 
someone using Windows ... I already fixed this problem at the upstream. But I 
don't know how to solve this problem in the packaging.

There is other problem, but I already fixed. I used debuild to test a change in 
the packaging that I did. It worked but when I commit the change I also commit 
some changes in the source code of InVesalius. I think debuild didn't unapply 
the patches. This happened at the commit 83d10824. I fixed this problem at the 
commit 0a1dfc00. Using the git diff to see the differences between the head and 
the upstream/3.1.2 show the only difference are the debian folder:

git diff --name-only HEAD upstream/3.1.2
debian/changelog
debian/compat
debian/control
debian/copyright
debian/dirs
debian/docs
debian/invesalius-bin.install
debian/invesalius-examples.examples
debian/invesalius.desktop
debian/invesalius.install
debian/invesalius.lintian-overrides
debian/invesalius.manpages
debian/invesalius.xpm
debian/invesalius3.1
debian/links
debian/patches/10_import_cython_modules.patch
debian/patches/10_remove_python2_shebang.patch
debian/patches/10_sample_path.patch
debian/patches/series
debian/rules
debian/source/format
debian/source/options
debian/watch
(END)

So I think this is fixed.

> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de

Best regards

Bug#908605: postfixadmin: 'lib' directory missing

[Jakob Butler]

Package: postfixadmin
Version: 3.2-2
Severity: grave
Justification: renders package unusable

Hi,

Sorry, but it seems that the 'lib' directory is missing -- i.e. a similar issue 
as to bug #908317. Without this directory, the web interface won't work.

Maybe (?) you'll also want to include 'ADDITIONS' and 'VIRTUAL_VACATION' from 
the upstream package? (I don't use them, so don't know the relevance/benefit)

Thanks and best regards,
Jakob

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

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

Versions of packages postfixadmin depends on:
ii  apache2 [httpd] 2.4.34-1
ii  dbconfig-common 2.0.9
ii  debconf 1.5.69
ii  default-mysql-client1.0.4
ii  libapache2-mod-php  1:7.2+62
ii  libapache2-mod-php7.2 [libapache2-mod-php]  7.2.9-1
ii  php 1:7.2+62
ii  php-imap1:7.2+62
ii  php-mbstring1:7.2+62
ii  php-mysql   1:7.2+62
ii  php7.2 [php]7.2.9-1
ii  php7.2-imap [php-imap]  7.2.9-1
ii  php7.2-mbstring [php-mbstring]  7.2.9-1
ii  php7.2-mysql [php-mysqlnd]  7.2.9-1
ii  wwwconfig-common0.3.0

Versions of packages postfixadmin recommends:
ii  dovecot-core1:2.3.2.1-1
pn  mariadb-server  
ii  mariadb-server-10.1 [virtual-mysql-server]  1:10.1.35-1
ii  php7.2-cli [php-cli]7.2.9-1
ii  postfix-mysql   3.3.0-1+b1
ii  zendframework   1.12.20+dfsg-1

postfixadmin suggests no packages.

-- debconf information:
  postfixadmin/upgrade-backup: true
  postfixadmin/dbconfig-remove: true
  postfixadmin/remote/host: localhost
  postfixadmin/install-error: abort
  postfixadmin/upgrade-error: abort
  postfixadmin/mysql/method: Unix socket
  postfixadmin/db/dbname: postfixadmin
  postfixadmin/dbconfig-upgrade: true
  postfixadmin/remote/newhost:
  postfixadmin/internal/reconfiguring: false
  postfixadmin/remote/port:
  postfixadmin/passwords-do-not-match:
  postfixadmin/db/app-user: postfixadmin@localhost
  postfixadmin/dbconfig-reinstall: false
* postfixadmin/database-type: mysql
  postfixadmin/missing-db-package-error: abort
  postfixadmin/purge: false
* postfixadmin/mysql/admin-user: root
  postfixadmin/internal/skip-preseed: false
  postfixadmin/remove-error: abort
* postfixadmin/dbconfig-install: true

Bug#907791: lua-moses breaks lua-torch-nn autopkgtest

[Mattia Rizzolo]

Control: reopen -1

On Tue, Sep 11, 2018 at 02:51:55PM +, Mo Zhou wrote:
> Justification: not a bug.

Sure it is.
You are allowing the co-installation of two softwares that can't work
together.

> I'm aware of the breakage before uploading lua-moses to unstable
> since the affected packages are maintained by me. This is not
> a regression in lua-moses but simply an API bump.

So this means you should add
Breaks: lua-torch-nn (<= whatever)
to lua-moses, plus whatever other package you are breaking.

It's unfortunate that before autopkgtest many of these cases were
ignored, but this is what you should be doing.

-- 
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#908372: (temporarily) abandoning work

[Miroslav Kravec]

The package has quite complex unpackaged dependencies. And,
google-auto has got circular dependency on google-truth.

See dependencies of maven artifacts:

https://mvnrepository.com/artifact/com.google.auto.value/auto-value-parent/1.6.2
https://mvnrepository.com/artifact/com.google.truth/truth/0.42

I'm discontinuing work in favor of immutables, bug: 908511

Bug#908604: cups-browsed: An IPP printer and the GTK printdialog

[Brian Potkin]

Package: cups-browsed
Version: 1.21.2-1
Severity: normal
Tags: upstream



The cups service is not running and the print dialog of evince shows:

  Print to File
  LaserJet-300
  printUpstairs   Rejecting Jobs
  realq

LaserJet-300 and realq are remote, shared queues on a stretch server;
print is an ENVY 4500 printer with

 pdl=application/vnd.hp-PCL,image/jpeg,application/PCLm,image/urf

I reckon "Rejecting Jobs" is because evince knows the printer cannot
process the cairo-generated PDF it will send. I bit of a pain, really.

But cups-browsed has often come to the rescue in the past, so start it
(which starts cups).

Now the print dialog display is

  Print to File
  ENVY4500
  LaserJet-300
  LaserJet_300_desktop
  printUpstairs   Rejecting Jobs
  realq
  realq_desktop

Splendid; the ENVY 4500 can now be printed to. And, as a bonus, the
*_desktop entries can be filtered out to declutter the dialog.

But hold on! The ENVY4500 entry disappears a minute afterwards; a good
idea comes to nothing.

What I think is happening is that cups-browsed can hijack the realq and
LaserJet-300 destinations from cups but with print there is nothing to
take over, leading to cups managing a queue which is temporary. Close?

A better solution In this situation (without using cups-browsed) is

   lpadmin -p ENVY4500 -v ipp:// -E -m everywhere

Regards,

Brian.

Bug#908603: docker.io: consider backporting to stable

[Héctor Orón Martínez]

Package: docker.io
Version: 18.03.1+dfsg1-6
Severity: wishlist

Dear Maintainer,

  Since `docker.io` reached testing, could you please consider backporting it 
to stable?

  What kind of work would be needed to ease the path to provide such backport?

Regards

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

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

Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Dmitry Shachnev]

On Tue, Sep 11, 2018 at 07:18:28PM +0200, Kurt Roeckx wrote:
> > > If this is for a call to SSL_CTX_set_max_proto_version(), you can
> > > use 0 instead of TLS_MAX_VERSION.
> >
> > Good point, thanks.
> >
> > However as the patch is temporary, I do not think it is worth
> > a new upload to change that.
>
> But maybe you can get upstream to use that instead.

Done: https://codereview.qt-project.org/239603

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#907491: goobook fails to authenticate

[Sergio Mendoza]

Yes, goobook works fine and smooth.

Thanks,

Sergio.


-- 
Sergio Mendoza  
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio
On Tue, Sep 11, 2018 at 06:51:00PM +0200, Kurt Roeckx wrote:
> Now that bug #907278 is fixed, I think this is fixed too.
> 

Bug#908602: ITP: immutables-maven-shade-plugin -- maven-shade-plugin with everything "fixed"

[Miroslav Kravec]

Package: wnpp
Severity: wishlist

* Package name: immutables-maven-shade-plugin
  Version : 4
  Upstream Author : Immutables Authors and Contributors
Ievgen Lukash (e.luc...@gmail.com)
Ilya Vysharev (ivysha...@gmail.com)
Augusto Travillio (augusto.travil...@gmail.com)
* URL : https://github.com/immutables/maven-shade-plugin
* License : Apache-2.0
  Programming Lang: Java
  Description : maven-shade-plugin with everything "fixed"

Customized version of maven-shade-plugin:

1. Relocation with $ uglyfication,
2. ServiceResourceTransformer that actually works properly,
3. Minimize Jar that works properly

Needed to package #908511.

Bug#908589: ITP: gcc-8-doc -- documentation for the GNU compilers (gcc, g++, etc.)

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Wed, Sep 12, 2018 at 12:45:56AM +0900, Guo Yixuan wrote:
> I'm maintaining gcc-6-doc and have maintained several earlier versions.
> [1] As a DM, I need sponsor on the first upload, and would prefer DM upload
> permission for subsequent updates.
> 
> [1] 
> http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git;a=summary

That's an interesting URL that can't possibly work anymore.
And, incidentally, it has been considered outdated for many years
already.

-- 
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#870641: light-locker: screen stays black after closing and opening laptop lid

[Thomas Maaß]

I have a similar Problem. But not only when hibernating. I have set up
to lock when the screensaver gets activated. I have no screensaver
installed, but configured a black screen. But this issue is not always.
Sometimes, the unlock screen appears as it should. Sometimes i can enter
my pw blind to get my desktop session again. And sometimes I have to
switch to the console and back to come back to desktop.
Now I installed xscreensaver with none acitvated to use this lock.
Needs further testing...

Bug#908225: outdated sqlite dependency

[H.-Dirk Schmitt]

Reason for the weird behaviour below stretch is hat the sqlite
dependency is outdated.
The following entry needs to be updated to a more recent version:
> libsqlite3-0 (>= 3.14.0)
fix:  libsqlite3-0 (>= 3.24.0)

Looking into the dependencies shows also some more outdated
dependencies.

> libnspr4 (>= 2:4.10.9), libnss3 (>= 2:3.34~)

Comparing with the information shown below about:support this should be
fixed to: libnspr4 (>= 2:4.19), libnss3 (>= 2:3.38)

---

Explanation:


If just checked firefox v62 below buster - there the problem is not
reproducible.
So the problem seems to be specific to the pinning below stretch.


So I compared the libraries dependencies and upgraded to 
libsqlite3-0/buster.

This is fixing the problem.

So I updated my pinnning definition 
[30-app-firefox_c42conf.distrib_debian ]:
--

# take firefox from sid
Package: firefox firefox-l10n*
Pin: release o=Debian*,n=sid*
Pin-Priority: 700

Package: libnss3 libnspr4
Pin: release o=Debian*,n=sid*
Pin-Priority: 700

Package: *sqlite3*
Pin: release o=Debian*,n=buster*
Pin-Priority: 700

Package: zlib1g zlib1g-dev
Pin: release o=Debian*,n=buster*
Pin-Priority: 700

Package: libc6* libc-* locales locales-all libfontconfig* fontconfig*
Pin: release o=Debian*,n=buster*
Pin-Priority: 700

# packages that otherwise unisntallable due to libc6 requirement above
Package: nscd libnih1
Pin: release o=Debian*,n=buster*
Pin-Priority: 700
--

Bug#908138: hddemux: s390x must be added to architectures without knot-resolver

[Steve Langasek]

Package: hddemux
Version: 0.4-6
Followup-For: Bug #908138
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Hi Daniel,

The addition of the knot-resolver build-dependency regressed hddemux
buildability on s390x in Ubuntu, so I've patched the package there as
attached to keep it building.  Please consider applying in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru hddemux-0.4/debian/control hddemux-0.4/debian/control
--- hddemux-0.4/debian/control  2018-09-05 16:51:08.0 -0700
+++ hddemux-0.4/debian/control  2018-09-09 00:22:04.0 -0700
@@ -7,7 +7,7 @@
  debhelper (>= 11~),
  gnutls-bin [!arm64] ,
  knot-dnsutils [!arm64] ,
- knot-resolver [!arm64] ,
+ knot-resolver [!arm64 !s390x] ,
  libsystemd-dev,
  libuv1-dev,
  nginx-light [!arm64] ,
diff -Nru hddemux-0.4/debian/rules hddemux-0.4/debian/rules
--- hddemux-0.4/debian/rules2018-09-05 16:44:33.0 -0700
+++ hddemux-0.4/debian/rules2018-09-09 00:22:04.0 -0700
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-KRESD_BROKEN_ARCHES := arm64
+KRESD_BROKEN_ARCHES := arm64 s390x
 ifneq (, $(filter $(DEB_HOST_ARCH), $(KRESD_BROKEN_ARCHES)))
   DEB_BUILD_OPTIONS += nocheck
 endif

Bug#908601: glx: do not pick sRGB config for 32-bit RGBA visual

[Robert Trebula]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20161206-1
Severity: normal

Dear Maintainer,

After updating my stretch+backports PC to mesa 18, I have transparency
issues in kde plasma desktop and menus do not show up in firefox-esr 60.

I think the issue is already fixed upstream - please see the following
reports (the latter also contains a patch):
https://bugs.freedesktop.org/show_bug.cgi?id=105871
https://bugs.freedesktop.org/show_bug.cgi?id=103699

Kind regards,
Robert


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

lrwxrwxrwx 1 root root 13 Jul 13  2016 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct 14  2017 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:1912] (rev 06)

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

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

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.17.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.17.17-1~bpo9+1 
(2018-08-27)

Xorg X server log files on system:
--
-rw-r--r-- 1 robo robo 48698 Jun 18 19:33 
/home/robo/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 robo robo 41636 Sep  4 16:39 
/home/robo/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/robo/.local/share/xorg/Xorg.0.log):
-
[   226.119] (--) Log file renamed from 
"/home/robo/.local/share/xorg/Xorg.pid-2083.log" to 
"/home/robo/.local/share/xorg/Xorg.0.log"
[   226.120] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[   226.120] X Protocol Version 11, Revision 0
[   226.120] Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
[   226.120] Current Operating System: Linux aspire 4.17.0-0.bpo.3-amd64 #1 SMP 
Debian 4.17.17-1~bpo9+1 (2018-08-27) x86_64
[   226.120] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.17.0-0.bpo.3-amd64 
root=/dev/mapper/ssdvg-debianlv ro quiet video=eDP-1:d vsyscall=emulate
[   226.120] Build Date: 16 October 2017  08:19:45AM
[   226.120] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
[   226.120] Current version of pixman: 0.34.0
[   226.120]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   226.120] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   226.120] (==) Log file: "/home/robo/.local/share/xorg/Xorg.0.log", Time: 
Tue Sep  4 08:25:42 2018
[   226.121] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   226.123] (==) No Layout section.  Using the first Screen section.
[   226.123] (==) No screen section available. Using defaults.
[   226.123] (**) |-->Screen "Default Screen Section" (0)
[   226.123] (**) |   |-->Monitor ""
[   226.124] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   226.124] (==) Automatically adding devices
[   226.124] (==) Automatically enabling devices
[   226.124] (==) Automatically adding GPU devices
[   226.124] (==) Max clients allowed: 256, resource mask: 0x1f
[   226.124] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   226.124]Entry deleted from font path.
[   226.124] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   226.124] (==) ModulePath set to "/usr/lib/xorg/modules"
[   226.125] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   226.125] (II) Loader magic: 0x556bde05be00
[   226.125] (II) Module ABI versions:
[   226.125]X.Org ANSI C Emulation: 0.4
[   226.125]X.Org Video Driver: 23.0
[   226.125]X.Org XInput driver : 24.1
[   226.125]X.Org Server Extension : 10.0
[   226.126] (++) using VT number 2

[   226.131] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_32
[   226.133] (II) xfree86: Adding drm device (/dev/dri/card0)
[   226.135] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0
[   226.138] (--) PCI:*(0:0:2:0) 8086:1912:1458:d000 rev 6, Mem @ 
0xde00/16777216, 0xc000/268435456, I/O @ 0xf000/64, BIOS @ 
0x/131072
[   226.138] (II) LoadModule: "glx"
[   226.139] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   226.143] (II) Module glx: vendor="X.Org Foundation"
[   

Bug#908597: nvidia-kernel-dkms: Unable to upgrade and to reinstall

[Luca Boccassi]

On Tue, 2018-09-11 at 18:59 +0200, Nicolas Patrois wrote:
> Package: nvidia-kernel-dkms
> Version: 390.87-1
> Severity: important
> 
> Dear Maintainer,
> 
> The last upgrade (this morning) let me without X.
> nvidia-driver needs nvidia-kernel-dkms (NKD) but NKD can't upgrade
> because of an error (exit status 10).
> I rebooted, tried to reinstall and ditto.
> Is it because my kernel image is rather old?
> 
> -- Package-specific info:
> uname -a:
> Linux nicolas.home 4.3.0-1-686-pae #1 SMP Debian 4.3.5-1 (2016-02-06) 
> i686 GNU/Linux

Why are you running on sid with a years old 4.3 kernel? That's not
supported...

-- 
Kind regards,
Luca Boccassi

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

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Kurt Roeckx]

On Tue, Sep 11, 2018 at 08:14:35PM +0300, Dmitry Shachnev wrote:
> Hi Kurt,
> 
> On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote:
> > If this is for a call to SSL_CTX_set_max_proto_version(), you can
> > use 0 instead of TLS_MAX_VERSION.
> 
> Good point, thanks.
> 
> However as the patch is temporary, I do not think it is worth
> a new upload to change that.

But maybe you can get upstream to use that instead.

I'm thinking about removing that symbol from the public header,
but that would be a 1.2 thing in that case.


Kurt

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Dmitry Shachnev]

Hi Kurt,

On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote:
> If this is for a call to SSL_CTX_set_max_proto_version(), you can
> use 0 instead of TLS_MAX_VERSION.

Good point, thanks.

However as the patch is temporary, I do not think it is worth
a new upload to change that.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#908567: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Kurt Roeckx]

On Tue, Sep 11, 2018 at 02:28:02PM +0200, Jonas Smedegaard wrote:
> Jan-Marek Glogowski wrote:
> > Qt5 is just the first breaking package - I have no idea, how many 
> > packages use TLS_MAX_VERSION in their code.
> 
> According to https://codesearch.debian.net/search?q=TLS_MAX_VERSION the 
> following packages mention TLS_MAX_VERSION in source code:
> 
>  * fetchmail

Should still work

>  * musescore

Has a copy of the header only

>  * qtbase-opensource-src
>  * shim

Has a copy of the header only

>  * ncrack

Has a copy of the header only

>  * globus-gssapi-gsi

Should still work, only in comment, they don't want TLS 1.3


It really looks like qtbase-opensource-src is the only one that
breaks on it.


Kurt

Bug#908600: libdazzle: build tests fail on non-Linux

[Jeremy Bicha]

Source: libdazzle
Version: 3.28.1-1
Severity: important
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-CC: debian-...@lists.debian.org, debian-h...@lists.debian.org

libdazzle's build test fails on non-Linux.

The particular test is testing these functions which are commented as
Linux-only.

https://gitlab.gnome.org/GNOME/libdazzle/blob/master/src/files/dzl-recursive-file-monitor.c

GNOME Builder appears to use these functions.
https://gitlab.gnome.org/GNOME/gnome-builder/blob/master/src/libide/vcs/ide-vcs-monitor.c

Thanks,
Jeremy Bicha

Bug#865766: printer-driver-cups-pdf: Bdependenca problem - printer-driver-cups-pdf cannot be upgraded to 3.0.1

[Boyuan Yang]

Dear Hans,

I read your email in the previous bug report ( https://bugs.debian.org/865766 
) about cups-pdf in Debian and I cannot really understand what the problem 
was.

Could you elaborate further about your problem? Are you encountering this 
problem when doing system upgrade from a previous Debian release (e.g., Jessie 
)? Specifically, please consider providing detailed instruction about the 
action that could raise the dependency problem, so that the packagers and 
maintainers could reproduce the problem and fix it in a timely manner. If that 
is not possible, I suggest that we mark the bug report with "moreinfo" tag and 
await a cleaner description about the problem from Hans.

--
Regards,
Boyuan Yang

在 2017年6月24日星期六 EDT 下午4:19:25，您写道：
> Greetings,
> 
> I'm really not sure I understand what the problem is. Removing the
> transitional package 'cups-pdf' is entirely the job of whichever
> package manager you use, typically 'apt' or 'aptitude'. This is never
> handled by the packages themselves.
> 
> Martin-Éric
> 
> 2017-06-24 19:31 GMT+03:00 Hans-J. Ullrich :
> > Package: printer-driver-cups-pdf
> > Version: 3.0.1-4
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I am running debian/testing, and so I cannot upgrade to
> > printer-driver-cups-pdf, which is a successor to the package cups-pdf.
> > 
> > The problem is, that printer-driver-cups-pdf inhibits to upgrade, as the
> > installer got a dependency problem with the installed cups-pdf.
> > 
> > Workaround is, just to uninstall and purge cups-pdf, then install
> > printer-driver-cups-pdf. However, the debian package should know the
> > dependencies and uninstall cups-pdf automatically, then of course,
> > install printer-driver-cups-pdf.
> > 
> > I believe, you might want to inform the package team.
> > 
> > Thank you for reading this.
> > 
> > Best regards
> > 
> > Hans
> > 
> > 
> > -- System Information:
> > Debian Release: 9.0
> > 
> >   APT prefers testing
> >   APT policy: (500, 'testing'), (500, 'stable')
> > 
> > Architecture: i386 (i686)
> > 
> > Kernel: Linux 4.9.0-3-686-pae (SMP w/2 CPU cores)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
> > (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages printer-driver-cups-pdf depends on:
> > ii  cups2.2.3-2
> > ii  cups-client 2.2.3-2
> > ii  ghostscript 9.20~dfsg-3.2
> > ii  libc6   2.24-12
> > ii  libcups22.2.3-2
> > ii  libpaper-utils  1.1.24+nmu5
> > 
> > printer-driver-cups-pdf recommends no packages.
> > 
> > Versions of packages printer-driver-cups-pdf suggests:
> > ii  system-config-printer  1.5.7-3
> > 
> > -- no debconf information



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