Bug#919044: lists.d.o: wrong List-Archive for debian-private@

[Ansgar Burchardt]

Package: lists.debian.org
Severity: minor

Hi,

debian-private uses the following List-Archive field:

  List-Archive: 

It should be

  file://master.debian.org/home/debian/archive/debian-private/

instead.

See also RFC 8089 and in particular the following parts:

+---
|Non-local files:
|
|o  A non-local file with an explicit authority.  For example:
|
|   *  "file://host.example.com/path/to/file"
+---[ RFC 8089, Appendix B.  Example URIs ]

+---
| Common UNIX shells such as the Bourne-Again SHell (bash) and Z SHell
| (zsh) provide a function known as "tilde expansion" [Bash-Tilde] or
| "filename expansion" [Zsh-Tilde], where a path that begins with a
| tilde character "~" can be expanded out to a special directory name.
| No such facility exists using the file URI scheme; a tilde in a file
| URI is always just a tilde.
+---[ RFC 8089, D.1.  POSIX Systems ]

Ansgar

Bug#919042: This is not exactly a "metapackge" :-)

[Osamu Aoki]

Package: winff
Version: 1.5.5-5
Severity: minor

Problem:

The package description of the binary package winff states:

|  This package is a metapackage to pull in either the GTK+ or Qt variant.

This is not exactly correct due to somewhat implicit action of debhelper
to include /usr/share/applications/winff.desktop to winff package.

Also, the desktop file mentions "avconv" while current situation
uses FFmpeg and it is gtk even when it calls winff-qt.

Background:

When I installed only winff-gtk2 trusting package description of winff,
winff didn't have GUI staring entry point.  After looking into the
git source at https://salsa.debian.org/pascal-team/winff, I realize it
only has winff.desktop.  I see the problem.

Possible solution.

Option 1 (simple but sloppy fix):
Since winff-data is always called in by the dependency, move
winff.desktop to winff-data package.  This can be done simply by
renaming debian/winff.desktop to winff-data.desktop

 ... this is easier but Category becomes incorrect for QT package

Option 2 (good fix):
Make winff-gtk2 and winff-qt package to contain desktop file of the
respective package.  For this, remove debian/winff.desktop and add:

debian/winff-gtk2.desktop

[Desktop Entry]
Version=1.0
Name=WinFF
Comment=GUI for FFmpeg
MimeType=application/winff;
Exec=winff-gtk2 %f
Icon=winff
Terminal=false
Type=Application
Categories=AudioVideo;AudioVideoEditing;GTK;
Keywords=avconv;ffmpeg;wrapper;conversion;video;audio;
GenericName=Video converter
GenericName[en]=Video converter
GenericName[nl]=Video converteerder


debian/winff-gtk2.qt

[Desktop Entry]
Version=1.0
Name=WinFF
Comment=GUI for FFmpeg
MimeType=application/winff;
Exec=winff-qt %f
Icon=winff
Terminal=false
Type=Application
Categories=AudioVideo;AudioVideoEditing;QT;
Keywords=avconv;ffmpeg;wrapper;conversion;video;audio;
GenericName=Video converter
GenericName[en]=Video converter
GenericName[nl]=Video converteerder

Here, I fixed FFmpeg thing and QT thing.

Regards,

Osamu

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

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

Versions of packages winff depends on:
ii  winff-gtk2  1.5.5-5

winff recommends no packages.

winff suggests no packages.

-- no debconf information

Bug#917650: FTBFS: include/qi.h:104:29: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier]

[Andreas Beckmann]

Followup-For: Bug #917650

Hi,

qi also FTBFS in stretch and jessie with different errors, just tested
on abel.d.o. I think the will show up on sid as well once compilation
proceeds a bit further.

The minimal fix would probably be dropping -Werror (and getting a NULL
definition), without cosmetic fixes (debhelper, standards-version), and
to rebuild the fixed package for stretch ~deb9u1 and jessie ~deb8u1.


stretch:

dh binary
dh: Compatibility levels before 9 are deprecated (level 8 in use)
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
dh_auto_configure: Compatibility levels before 9 are deprecated (level 8 in use)
   debian/rules override_dh_auto_build
make[1]: Entering directory '/home/anbe/qi/qi-2013'
/usr/bin/make CPU=s3c2442 CROSS_COMPILE="" BUILD_BRANCH=debian 
BUILD_HEAD=2013-1.1
make[2]: Entering directory '/home/anbe/qi/qi-2013'
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/cpu/s3c2442/start.o src/cpu/s3c2442/start.S
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/cpu/s3c2442/lowlevel_init.o 
src/cpu/s3c2442/lowlevel_init.S
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/utils-phase2.o src/utils-phase2.c
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/memory-test.o src/memory-test.c
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/crc32.o src/crc32.c
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/blink_led.o src/blink_led.c
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/ctype.o src/ctype.c
gcc -Wall -Werror -I include -g -c -Os -fno-strict-aliasing -mlong-calls 
-fno-common -ffixed-r8 -msoft-float -fno-builtin -ffreestanding -march=armv4t 
-mno-thumb-interwork -Wstrict-prototypes -DBUILD_HOST="abel" 
-DBUILD_VERSION="debian_2013-1.1" -DBUILD_DATE="2019-01-12T06:59:40+00:00" 
-DQI_CPU="s3c2442" -o src/phase2.o src/phase2.c
src/phase2.c: In function 'do_params':
src/phase2.c:242:2: error: this 'if' clause does not guard... 
[-Werror=misleading-indentation]
  if (this_kernel->commandline_append)
  ^~
src/phase2.c:245:3: note: ...this statement, but the latter is misleadingly 
indented as if it is guarded by the 'if'
   if (commandline_rootfs_append[0])
   ^~
In file included from src/phase2.c:29:0:
src/phase2.c: At top level:
include/image.h:367:13: error: inline function 'image_print_contents_noindent' 
declared but never defined [-Werror]
 inline void image_print_contents_noindent (image_header_t *hdr);
 ^
include/image.h:366:13: error: inline function 'image_print_contents' declared 
but never defined [-Werror]
 inline void image_print_contents (image_header_t *hdr);
 ^~~~
cc1: all warnings being treated as errors
Makefile:69: recipe for target 'src/phase2.o' failed
make[2]: *** [src/phase2.o] Error 1
make[2]: Leaving directory '/home/anbe/qi/qi-2013'
debian/rules:8: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/home/anbe/qi/qi-2013'
debian/rules:6: recipe for target 'binary' failed 


jessie:

dh binary
   dh_testdir
   dh_auto_con

Bug#919041: Remove intrigeri from Uploaders

[intrigeri]

Source: backupninja
Version: 1.1.0-2.1
Severity: normal
Tags: patch

Hi,

as I've just announced on the upstream mailing list, I've retiring
from the backupninja project and package maintenance, mostly due to
lack of availability.

Here's a patch that removes myself from Uploaders.

Thanks in advance!

Cheers,
-- 
intrigeri

>From 3620e22ca427333ee063a594d960ab365bfce92d Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Sat, 12 Jan 2019 07:10:24 +
Subject: [PATCH] Remove myself from Uploaders.

---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 7ff1bc4..1b638f5 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,6 @@ Section: admin
 Priority: optional
 Maintainer: Debian backupninja maintainers 
 Uploaders: Micah Anderson ,
- intrigeri ,
  Jerome Charaoui 
 Build-Depends:
  debhelper (>= 10)
-- 
2.20.1

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Michael Gilbert]

On Fri, Jan 11, 2019 at 1:03 PM Patrick Häcker wrote:
> I can confirm, that version 72.0.3626.7-6 is fixing the issue. Thanks a lot 
> for
> pointing me to the unstable version.
>
> So as soon as this version enters testing, this bug report can be closed.

It can't be closed because the problem will still not be fixed in stretch.

This is only fixed in unstable since gcc 8 is now used to compile
chromium. Stretch only has gcc 6 and no one has identified yet which
compiler bug causes this or how to work around the problem with older
compilers.  For anyone that cares about this issue, figuring that out
would be very helpful.

Best wishes,
Mike

Bug#919040: Acknowledgement (zh_CN.po update)

[M. Zhou]

The patch is here
https://salsa.debian.org/chinese-team/dpkg/commit/9249b5a8ef455b951879267e63e14d29a0fe2f9d

Bug#919040: zh_CN.po update

[M. Zhou]

Package: dpkg
Version: 1.19.2
X-Debbugs-CC: by...@debian.org

Dear Dpkg maintainer,

This is the zh_CN.po update. Please poke byang if you need another
DD to review.

~/D/d/d/po ❯❯❯ msgfmt -v zh_CN.po
1116 translated messages.

Bug#918666: wine hardcodes /run/user/$UID directory

[Michael Gilbert]

control: tag -1 - moreinfo

On Sat, Jan 12, 2019 at 1:19 AM Michael Gilbert wrote:
> This is already the case.  The current implementation automatically
> falls back to TMPDIR if /run/user/$UID does not exist.  It also
> automatically handles creation of the wine subdirectory if it does not
> exist.
>
> There may corner cases that are yet unhandled, can you better define
> the problem you've actually seen?

I think I see the problem.  /run/user is checked for existence, not
/run/user/$UID.

Best wishes,
Mike

Bug#918666: wine hardcodes /run/user/$UID directory

[Michael Gilbert]

control: tag -1 moreinfo

On Tue, Jan 8, 2019 at 4:21 AM Julian Andres Klode wrote:
> wine hardcodes the use of /run/user/$UID/wine if it can determine
> $UID (if getuid() exists) as the place to store server information.
>
> It's not clear to me who is responsible for creating those directories,
> but I'm not sure we can rely on them being available, so wine should
> fallback to /tmp if /run/user/$UID does not exist, I guess.

This is already the case.  The current implementation automatically
falls back to TMPDIR if /run/user/$UID does not exist.  It also
automatically handles creation of the wine subdirectory if it does not
exist.

There may corner cases that are yet unhandled, can you better define
the problem you've actually seen?

> In fact, it should be using $XDG_RUNTIME_DIR, not
> hardcoding /run/user/$UID.

There is discussion in the upstream bug about the extra concerns that
would need to be handled to support XDG_RUNTIME_DIR.  At this time, I
plan to wait for upstream to decide how to handle that. In the
meantime, it will not be supported.

> (this surfaced in Ubuntu autopkgtest for gpgv-win32).

What was the actual error?

Best wishes,
Mike

Bug#917655: biojava4-live: FTBFS (cannot find symbol JAXBContext)

[tony mancill]

On Fri, Jan 11, 2019 at 10:26:58PM +0100, Andreas Tille wrote:
> Control: tags -1 help upstream
> 
> Hi,
> 
> I've commited a new minor upstream version to Git but the problem exists
> also in this version.  I've asked at debian-java list for help[1]

Hello Andreas,

I took a quick look at this and was able to resolve the build problems
by dropping the references to the java.se.ee. module and adding
jaxb-impl and jaxb-api JARs to the classpath.

It might not be the cleanest way - strictly speaking, you should only
need the jaxb-api JAR during the build and only the jaxb-impl on the
classpath while running tests.

Attached are a set of commits that let the package build for me locally.

Cheers,
tony
From f8f5c72b866718e05811b33f8445ee311228da12 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:17:27 -0800
Subject: [PATCH 1/3] Add build-dep on libjaxb-api-java and libjaxb-java

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

diff --git a/debian/control b/debian/control
index 1f6cc04..71257a0 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,9 @@ Build-Depends-Indep: libcommons-dbcp-java,
  liblog4j2-java,
  libslf4j-java,
  libxmlunit-java,
- libjgrapht-java
+ libjgrapht-java,
+ libjaxb-api-java,
+ libjaxb-java
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/biojava4-live
 Vcs-Git: https://salsa.debian.org/med-team/biojava4-live.git
-- 
2.20.1

From ac9fad6e89d9d5ff8501a05da46b26bd158af5f8 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:25:49 -0800
Subject: [PATCH 2/3] Add jaxb-api and jaxb-impl JARs to classpaths in
 debian/build.xml

---
 debian/build.xml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/build.xml b/debian/build.xml
index 250c143..fae837d 100644
--- a/debian/build.xml
+++ b/debian/build.xml
@@ -28,7 +28,7 @@
 	
 		
 	
-	
+	
 
 	
 
@@ -52,6 +52,8 @@
 
 
 
+
+
 			
 			
 
-- 
2.20.1

From c25549fd76d3378cad50029a6718353858f6cce4 Mon Sep 17 00:00:00 2001
From: tony mancill 
Date: Fri, 11 Jan 2019 20:36:27 -0800
Subject: [PATCH 3/3] Drop --add-modules java.se.ee from javadoc task

---
 debian/build.xml | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/debian/build.xml b/debian/build.xml
index fae837d..406f208 100644
--- a/debian/build.xml
+++ b/debian/build.xml
@@ -75,18 +75,9 @@
 	
 
 		
-
-
-
-http://java.sun.com/j2se/1.6.0/docs/api/"/>
-
-
-
-
-http://java.sun.com/j2se/1.6.0/docs/api/"/>
-
-
-
+
+http://java.sun.com/j2se/1.6.0/docs/api/"/>
+
 	
 	
 	
@@ -130,7 +121,6 @@
 
 
 
-  
   
   
   
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#916947: linux-image-4.18.0-0.bpo.3-amd64: Can't get image/audio output from external monitor

[N G]

Package: src:linux
Followup-For: Bug #916947

Dear Maintainer,

After upgrading to linux-image-4.19.0-0.bpo.1-amd64 I can use again the maximum
resolution using HDMI.
Therefore it's fixed now.




-- Package-specific info:
** Version:
Linux version 4.19.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.12-1~bpo9+1 
(2018-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.1-amd64 root=/dev/mapper/firebolt-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   17.105974] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.106015] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.106056] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.106096] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.106137] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.106177] amdgpu: [powerplay] Voltage value looks like a Leakage ID but 
it's not patched 
[   17.128206] amdgpu: [powerplay] Failed to retrieve minimum clocks.
[   17.128206] amdgpu: [powerplay] Error in phm_get_clock_info 
[   17.128291] [drm] DM_PPLIB: values for Engine clock
[   17.128293] [drm] DM_PPLIB:   214000
[   17.128293] [drm] DM_PPLIB:   551000
[   17.128294] [drm] DM_PPLIB:   734000
[   17.128295] [drm] DM_PPLIB:   921000
[   17.128296] [drm] DM_PPLIB:   98
[   17.128296] [drm] DM_PPLIB:   1046000
[   17.128298] [drm] DM_PPLIB: Validation clocks:
[   17.128298] [drm] DM_PPLIB:engine_max_clock: 104600
[   17.128299] [drm] DM_PPLIB:memory_max_clock: 125000
[   17.128300] [drm] DM_PPLIB:level   : 8
[   17.128302] [drm] DM_PPLIB: values for Memory clock
[   17.128303] [drm] DM_PPLIB:   30
[   17.128303] [drm] DM_PPLIB:   625000
[   17.128304] [drm] DM_PPLIB:   125
[   17.128305] [drm] DM_PPLIB: Validation clocks:
[   17.128306] [drm] DM_PPLIB:engine_max_clock: 104600
[   17.128306] [drm] DM_PPLIB:memory_max_clock: 125000
[   17.128307] [drm] DM_PPLIB:level   : 8
[   17.128462] [drm:dc_create [amdgpu]] *ERROR* DC: Number of connectors is 
zero!
[   17.129403] [drm] Display Core initialized with v3.1.59!
[   17.129483] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   17.129484] [drm] Driver supports precise vblank timestamp query.
[   17.171112] [drm] UVD and UVD ENC initialized successfully.
[   17.271122] [drm] VCE initialized successfully.
[   17.276598] [drm] Initialized amdgpu 3.27.0 20150101 for :03:00.0 on 
minor 1
[   17.551937] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   17.618326] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[   17.881602] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
(null)
[   18.864201] audit: type=1400 audit(1547271196.307:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=657 
comm="apparmor_parser"
[   18.881507] audit: type=1400 audit(1547271196.323:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=655 comm="apparmor_parser"
[   19.032081] audit: type=1400 audit(1547271196.475:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/libvirtd" pid=661 
comm="apparmor_parser"
[   19.032709] audit: type=1400 audit(1547271196.475:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/libvirtd//qemu_bridge_helper" pid=661 comm="apparmor_parser"
[   19.096909] audit: type=1400 audit(1547271196.539:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=663 
comm="apparmor_parser"
[   19.173063] audit: type=1400 audit(1547271196.615:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=659 comm="apparmor_parser"
[   19.173592] audit: type=1400 audit(1547271196.615:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=659 
comm="apparmor_parser"
[   19.173739] audit: type=1400 audit(1547271196.615:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/cupsd//third_party" pid=659 comm="apparmor_parser"
[   22.227161] ath10k_pci :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x address=0xffbf5760 flags=0x0020]
[   22.228155] ath10k_pci :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x address=0xffbf5790 flags=0x0020]
[   22.229135] ath10k_pci :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x address=0xffbf5780 flags=0x0020]
[   22.230121] ath10k_pci :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x address=0xffbf5820 flags=0x0020]
[   22.231138] a

Bug#919039: O: linuxbrew-wrapper -- Homebrew package manager for Linux

[M. Zhou]

Package: wnpp
Severity: normal

I'm not using linuxbrew anymore, and hence not interested in maintaining
it for longer.

Bug#912004: [R-pkg-team] Bug#912004: r-cran-rlang: autopkgtest regression

[Graham Inggs]

The following tests still fail with r-cran-rlang 0.3.1-1.  Does anyone
have any idea how serious they are?  Should we skip them?


══ testthat results  ═══
OK: 2489 SKIPPED: 11 FAILED: 6
1. Error: env_binding_type_sum() detects types (@test-env-binding.R#210)
2. Error: env_print() has flexible input (@test-env.R#252)
3. Error: locked bindings are pretty-printed (@test-env.R#272)
4. Error: large environments are truncated (@test-env.R#278)
5. Error: special names are backticked (@test-env.R#283)
6. Error: can print environment containing missing argument (@test-env.R#329)

Bug#919038: Duplicated procmailrc-example.gz and ChangeLog

[積丹尼 Dan Jacobson]

Package: procmail-lib
Version: 1:2009.1202-4
Severity: minor

I found repeated files,
$ find /usr/share/doc/procmail-lib/ -type f|xargs sum|sort -n|uniq 
--all-repeated --check-chars=5
23996 3 /usr/share/doc/procmail-lib/changelog.gz
23996 3 /usr/share/doc/procmail-lib/lib-aalto/ChangeLog.doc.gz
28808 5 /usr/share/doc/procmail-lib/examples/procmailrc-example.gz
28808 5 
/usr/share/doc/procmail-lib/lib-stebbens/examples/procmailrc-example.gz

Bug#919037: xmms2-scrobbler: Non-working maintainer address

[Scott Kitterman]

Package: xmms2-scrobbler
Version: 0.4.0-4
Severity: serious
Justification: Policy 3.3

A working maintainer address is required:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  r...@debian.org
Unrouteable address

Reporting-MTA: dns; muffat.debian.org

Action: failed
Final-Recipient: rfc822;r...@debian.org
Status: 5.0.0

Scott K

Bug#918918: dkms attempts to install incorrect headers (686-pae instead of plain 686)

[David Essam]

Package: dkms
Version: 2.6.1-3
Followup-For: Bug #918918

Dear Maintainer,

Quick update with more information.
   * What exactly did you do (or not do) that was effective (or ineffective)?
Unpacked the .deb edited control to include linux-headers-686 in addition to the
headers listed as a suitable depend, installed dkms using dpkg

put dkms on hold till this trivial-to-fix bug is fixed :-)

   * What was the outcome of this action?
Everything worked as expected, modules were built using the correct headers.
The built modules appear completely functional.



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

Kernel: Linux 4.19.0-1-686 (SMP w/1 CPU core)
Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dkms depends on:
ii  build-essential  12.5
ii  coreutils8.30-1
ii  dpkg-dev 1.19.2
ii  gcc  4:8.2.0-2
ii  kmod 25-2
ii  make 4.2.1-1.2
ii  patch2.7.6-3

Versions of packages dkms recommends:
ii  fakeroot   1.23-1
ii  linux-headers-686  4.19+101  *only because I edited control
ii  lsb-release10.2018112800
ii  sudo   1.8.26-2

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

-- no debconf information

Bug#919036: libopenexr24 botched upload issue also affects libopenexr23 and libilmbase23

[積丹尼 Dan Jacobson]

Package: libopenexr23
Version: 2.3.0-3
Severity: grave

Please replace these. I had to
Marking version 2.3.0-3 of package libopenexr23 as forbidden
Marking version 2.3.0-3 of package libilmbase23 as forbidden
and
install libopenexr23=2.2.1-4 libilmbase23=2.2.1-2
else gimp won't start, etc.

Bug#916079: hyperic-sigar FTBFS with glibc 2.28

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/ftbfs-glibc-2.28.diff: Fix FTBFS against glibc 2.28.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-13-generic (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
diff -Nru hyperic-sigar-1.6.4+dfsg/debian/patches/ftbfs-glibc-2.28.diff 
hyperic-sigar-1.6.4+dfsg/debian/patches/ftbfs-glibc-2.28.diff
--- hyperic-sigar-1.6.4+dfsg/debian/patches/ftbfs-glibc-2.28.diff   
1969-12-31 19:00:00.0 -0500
+++ hyperic-sigar-1.6.4+dfsg/debian/patches/ftbfs-glibc-2.28.diff   
2019-01-11 22:38:38.0 -0500
@@ -0,0 +1,22 @@
+Description: Fix FTBFS against glibc 2.28
+Author: Logan Rosen 
+Forwarded: https://github.com/hyperic/sigar/pull/127
+Last-Update: 2019-01-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/os/linux/linux_sigar.c
 b/src/os/linux/linux_sigar.c
+@@ -22,8 +22,13 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
++#ifdef __GNU_LIBRARY__
++#include 
++#endif
++
+ #include "sigar.h"
+ #include "sigar_private.h"
+ #include "sigar_util.h"
diff -Nru hyperic-sigar-1.6.4+dfsg/debian/patches/series 
hyperic-sigar-1.6.4+dfsg/debian/patches/series
--- hyperic-sigar-1.6.4+dfsg/debian/patches/series  2014-11-03 
00:25:28.0 -0500
+++ hyperic-sigar-1.6.4+dfsg/debian/patches/series  2019-01-11 
22:36:13.0 -0500
@@ -3,3 +3,4 @@
 0003-bindings-java-Use-sane-name-for-JNI-library.patch
 0004-make-the-package-compile-on-MIPS.patch
 no-m64-mips-arm.diff
+ftbfs-glibc-2.28.diff

Bug#918384: [PATCH 5/6] documentation style: Do not put "" around C<..>

[Paul Hardy]

On Fri, Jan 11, 2019 at 2:02 PM Ian Jackson
 wrote:
>
> In the default text manpage rendering, C produces a pair of quotes and
> the result is   ""..""   which is not desirable.

On the other 5 patches: ack.

On this patch: interesting.  What I actually proofread was the PDF
output of pod2man --> groff -man --> ps2pdf because a Roman font is
easier to read than a monospace font.  groff did not add the double
quotes.  But man output is what 99% of everybody will read, so that's
what matters (which is why I backed out of my attempts at a grave
accent for "a la" when "\`" and "\(ga" didn't render properly in man).

>
> Signed-off-by: Ian Jackson 
> ---
>  git-debrebase.1.pod | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod
> index e5b84a0b..aa7f459b 100644
> --- a/git-debrebase.1.pod
> +++ b/git-debrebase.1.pod
> @@ -420,7 +420,7 @@ failure to find an appropriate upstream.
>  Directory to look in for orig tarballs.
>  The default is the git config option
>  dgit.default.build-products-dir
> -or failing that, "C<..>".
> +or failing that, C<..>.
>  Passed on to dgit, if git-debrebase invokes dgit.
>
>  =item --[no-]origs
> --
> 2.11.0
>

Thanks again,


Paul Hardy

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Jo Shields]

Maybe a typo in debian/rules? I do my builds in a chroot, this kind of thing 
shouldn't happen 

Sent from my iPhone

> On 11 Jan 2019, at 20:03, Ingo Saitz  wrote:
> 
> Package: libmono-system4.0-cil
> Version: 5.16.0.220+dfsg3-1
> Severity: important
> 
> Dear Maintainer,
> 
> libmono-system4.0-cil contains in its dependencies on amd64 a dependency
> on mono-runtime-common 5.18:
> 
> Depends: ..., mono-runtime (>= 5.16.0.220), mono-runtime-common (>= 
> 5.18.0.225), mono-runtime (<< 5.16.0.221)
> 
> This probably will never work, since mono-runtime depends on the exact
> same version of mono-runtime-common. The dependency is not listed in
> debian/control, so it seems it must have been introduced by
> ${misc:Depends} or ${cli:Depends} - was this package built on a system
> with mono 5.18 packages installed?
> 
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers unstable
>  APT policy: (800, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.12-echse-4.1920181222 (SMP w/2 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: sysvinit (via /sbin/init)
> 
> Versions of packages libmono-system4.0-cil depends on:
> ii  libc62.28-4
> ii  libmono-corlib4.5-cil4.6.2.7+dfsg-2
> ii  libmono-security4.0-cil  4.6.2.7+dfsg-2
> ii  libmono-system-configuration4.0-cil  4.6.2.7+dfsg-2
> ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-2
> ii  mono-runtime 4.6.2.7+dfsg-2
> 
> Versions of packages libmono-system4.0-cil recommends:
> ii  ca-certificates-mono  4.6.2.7+dfsg-2
> 
> Versions of packages libmono-system4.0-cil suggests:
> ii  libasound2  1.1.7-2
> ii  libgamin0   0.1.10-5+b1
> 
> -- no debconf information
> 

Bug#918384: dgit: typo suggestions in man pages

[Paul Hardy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Dear Ian,

The patches I submitted for Debian bug #918384 were created
entirely by me, except for those changes Sean suggested
that I incorporated in the second patch set.

Attached is a signed Developer's Certificate of Origin for
your records.

Thank you,


Paul Hardy
unifoun...@unifoundry.com

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAlw5WKYACgkQGgkiex9D
WjPiMRAAn+kaAjVNryGhc2C5B2LqiYq9RYAdvLzc34tgfit9zWm+qJ4WZwLG3L38
XEltBBYwDb4vV29ObdgLsxw/SI6gFK9FuqY0l94ZMcRoA/M7I2h2aOTrPIyhQRlN
0nEb7e1ceh0aaUHMQKRueXCJ28bP38DdFOe+sjZ3aeJL1A4HbhMQfVU5ou8HGti+
DB4oos2I9KSKOjV481TmMKcf9/EfmN1brKEVS13xdKbY+LBx7BfNHP0VQjli62yI
a7XVhuntMEekPg8i0MqvBRIPNjpLv9zCNU76FBjJpOkJg1Bv8e7Ae6GRiFuxyBA3
5Hfa6OoBqLvKqDi9kftyD8pwB1+UKjqC/RJIxlFUuQNtwU/LB2Pu+NjpNM1aXIgw
OspOh95KwfyjNkl83P/vHjnO5q7ioIYp2Gex3tQjqNjoKPj5YqGnUvbXyIiquL7D
Gfjk+geclBvfzB7Z+iMeQcQhcAScoGx7i8tOu9rljdmHIlnLV8vyYwqsc+PrRc3x
p/NmzkrwD8kz0FumhIhOlkBk4QlxjSm8vXSu5GvovjdoqUQVJX48lnHeuP2BAhk1
oHmTm4vd8yca8HKxZxjmT8HvQKuG6uudalDPRw9JASzdVf7oS/GgT0AsmJU+V3+x
Vl6M63qxt3N+FCelj/4Cxuo3uxZf8ezbdKqn0yIMAUbJ/GZ1Mtk=
=NmjB
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Paul Hardy 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAlw5WGgACgkQGgkiex9D
WjNp+xAArO0H3RdWhxylAlR594/JYikvKEe8NiBY3HEwOxEgwUeqLKDEZrGqCVvs
ZYzrZ1psNABdxDXCzlT2jq8glrOz+mq+CNLhryuYwDR0T9IBXziW1NVDXaq15M5y
sdgvncefUwcXm433ALsNl0Yth4Y+6ptcxLKARZ+BRZUTRyOv9EszqkryPpo3epk9
8RTEVmtNfJZqkDGrfrWOPTxS5B6nN/wliZb7zhxY0dozl4ex58UVJAHhRYER5et6
Im6dpaD2sPS+dE/z5gD40eIclPY473sTmiET99kgbSO7kcoBcCA2RUUR+rjpHLel
syle0fxgbMv/MtA+/UgWuuVX/kNqXJBFcu/aITrBj7V8mLBsWGM/oR4LOrlJRVSK
PBD+TyvL50k5rNO9CVsuNBHZkeSFFDHFWM7EuZzJpOv1l92USaSluVGUE57LR1cf
nlpaXh7tqjGGQRnEJs+05Aw71PkmKfJz6VkEFtbkh9wwwqXJf60kT5QSo50mt489
HWbJkixlzOjTU5OrG8Hy5mmPOYo3hRrAx3mPCMh+sAR5bgIZSJ5bAtTcLHnb3CkC
fnuXuSQuan0BzfoRw0kwPpQxOatRXDy3U3WWUsC1AB0BIaCmILYylGv4U/dU+2nT
GVnB8CFNPl68bDzPJGYqIUsb8RdLinq5tQBh44eCnRw0o+cmz64=
=f//v
-END PGP SIGNATURE-

Bug#918839: systemd: LXC Container with debian buster can no longer start services after updating to systemd_240

[Fabian Grünbichler]

the original reporter did not mention it explicitly (although the kernel
version already indicates it ;)) - the original occurrence of this issue
was on a Debian derivative (Proxmox Virtual Environment), which does not
use Debian's kernel (and thus neither the same AppArmor LSM code nor
AppArmor feature set) as well as a different LXC version.

it is however easily reproduced using Debian Sid as well:

root@host:/# lxc-create -n test -t debian -- -r buster
[...]

(underlying storage is irrelevant)

then setup network (none in this case to just use host network, config
otherwise unedited)

root@host:/# lxc-attach -n test
root@test:/# apt install apache2
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
  apache2-bin apache2-data apache2-utils bzip2 file libapr1 libaprutil1 
libaprutil1-dbd-sqlite3 libaprutil1-ldap
  libbrotli1 libcurl4 libexpat1 libgdbm-compat4 libgdbm6 libicu63 libjansson4 
libldap-2.4-2 libldap-common
  liblua5.2-0 libmagic-mgc libmagic1 libnghttp2-14 libperl5.28 libpsl5 librtmp1 
libsasl2-2 libsasl2-modules
  libsasl2-modules-db libsqlite3-0 libssh2-1 libxml2 mime-support perl 
perl-modules-5.28 publicsuffix ssl-cert
  xz-utils
Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser 
bzip2-doc gdbm-l10n
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal 
libsasl2-modules-ldap libsasl2-modules-otp
  libsasl2-modules-sql perl-doc libterm-readline-gnu-perl | 
libterm-readline-perl-perl make libb-debug-perl
  liblocale-codes-perl openssl-blacklist
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils bzip2 file libapr1 libaprutil1 
libaprutil1-dbd-sqlite3
  libaprutil1-ldap libbrotli1 libcurl4 libexpat1 libgdbm-compat4 libgdbm6 
libicu63 libjansson4 libldap-2.4-2
  libldap-common liblua5.2-0 libmagic-mgc libmagic1 libnghttp2-14 libperl5.28 
libpsl5 librtmp1 libsasl2-2
  libsasl2-modules libsasl2-modules-db libsqlite3-0 libssh2-1 libxml2 
mime-support perl perl-modules-5.28
  publicsuffix ssl-cert xz-utils
0 upgraded, 38 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.6 MB of archives.
After this operation, 102 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://cdn-aws.deb.debian.org/debian buster/main amd64 perl-modules-5.28 
all 5.28.1-3 [2,873 kB]
Get:2 https://cdn-aws.deb.debian.org/debian buster/main amd64 libgdbm6 amd64 
1.18.1-2 [64.5 kB]
Get:3 https://cdn-aws.deb.debian.org/debian buster/main amd64 libgdbm-compat4 
amd64 1.18.1-2 [44.0 kB]

[...]

Setting up apache2-bin (2.4.37-1) ...
Setting up apache2 (2.4.37-1) ...
Enabling module mpm_event.
Enabling module authz_core.
Enabling module authz_host.
Enabling module authn_core.
Enabling module auth_basic.
Enabling module access_compat.
Enabling module authn_file.
Enabling module authz_user.
Enabling module alias.
Enabling module dir.
Enabling module autoindex.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module filter.
Enabling module deflate.
Enabling module status.
Enabling module reqtimeout.
Enabling conf charset.
Enabling conf localized-error-pages.
Enabling conf other-vhosts-access-log.
Enabling conf security.
Enabling conf serve-cgi-bin.
Enabling site 000-default.
Created symlink /etc/systemd/system/multi-user.target.wants/apache2.service → 
/lib/systemd/system/apache2.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/apache-htcacheclean.service → 
/lib/systemd/system/apache-htcacheclean.service.
Job for apache2.service failed because the control process exited with error 
code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: initscript apache2, action "start" failed.
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Fri 2019-01-11 20:32:56 UTC; 15ms 
ago
  Process: 902 ExecStart=/usr/sbin/apachectl start (code=exited, 
status=226/NAMESPACE)

Jan 11 20:32:56 test systemd[1]: Starting The Apache HTTP Server...
Jan 11 20:32:56 test systemd[902]: apache2.service: Failed to set up mount 
namespacing: Permission denied
Jan 11 20:32:56 test systemd[902]: apache2.service: Failed at step NAMESPACE 
spawning /usr/sbin/apachectl: Permission denied
Jan 11 20:32:56 test systemd[1]: apache2.service: Control process exited, 
code=exited, status=226/NAMESPACE
Jan 11 20:32:56 test systemd[1]: apache2.service: Failed with result 
'exit-code'.
Jan 11 20:32:56 test systemd[1]: Failed to start The Apache HTTP Server.
Processing triggers for libc-bin (2.28-2) ...
Processing triggers for systemd (240-2) ...

root@host:/# journalctl --since "-1min"
[...]
Jan 11 21:40:15 host audit[23555]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 

Bug#918384: [PATCH 1/6] documentation style: "appropriate configuration" as a mass noun

[Ian Jackson]

This is correct IMO.  dput has, of course, multiple configuration
files, and one might use a wrapper or something, or perhaps (unisely)
dgit command line options.

Signed-off-by: Ian Jackson 
---
 dgit-downstream-dsc.7.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit-downstream-dsc.7.pod b/dgit-downstream-dsc.7.pod
index ace4fbfb..73c10cfc 100644
--- a/dgit-downstream-dsc.7.pod
+++ b/dgit-downstream-dsc.7.pod
@@ -140,7 +140,7 @@ In this document we will assume you are using B.
 Setting up reprepro is not covered in this tutorial.
 Instead, we assume you already have reprepro working.
 
-You should also write an appropriate dput configuration file,
+You should also write appropriate dput configuration,
 since dgit uses dput to upload packages to the archive.
 This will involve choosing a dput host name.
 That's probably your distro name, I.
-- 
2.11.0

Bug#918384: [PATCH 2/6] documentation style: there is no "the restricted command"

[Ian Jackson]

I see "ssh restricted command" as a feature.  There is no command
provided; alternatively one could argue that the user is to provide a
script, which they will configure as the restricted command, in which
case "to make writing the ssh restricted command
script|implementation" or something, but that seems wordy.

Signed-off-by: Ian Jackson 
---
 dgit-downstream-dsc.7.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit-downstream-dsc.7.pod b/dgit-downstream-dsc.7.pod
index 73c10cfc..91d9023c 100644
--- a/dgit-downstream-dsc.7.pod
+++ b/dgit-downstream-dsc.7.pod
@@ -312,7 +312,7 @@ Either don't do that, or set up B.
 When a user who can push runs dgit,
 dgit uses ssh to access the git server.
 
-To make the ssh restricted command easier,
+To make use of ssh restricted command easier,
 and for the benefit of dgit-repos-server,
 dgit's ssh commands
 each start with a parseable commentish rune.
-- 
2.11.0

Bug#918384: [PATCH 5/6] documentation style: Do not put "" around C<..>

[Ian Jackson]

In the default text manpage rendering, C produces a pair of quotes and
the result is   ""..""   which is not desirable.

Signed-off-by: Ian Jackson 
---
 git-debrebase.1.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod
index e5b84a0b..aa7f459b 100644
--- a/git-debrebase.1.pod
+++ b/git-debrebase.1.pod
@@ -420,7 +420,7 @@ failure to find an appropriate upstream.
 Directory to look in for orig tarballs.
 The default is the git config option
 dgit.default.build-products-dir
-or failing that, "C<..>".
+or failing that, C<..>.
 Passed on to dgit, if git-debrebase invokes dgit.
 
 =item --[no-]origs
-- 
2.11.0

Bug#918384: [PATCH 6/6] documentation style: Two hunks of my personal preference

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 git-debrebase.1.pod | 2 +-
 git-debrebase.5.pod | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod
index aa7f459b..cbdf292b 100644
--- a/git-debrebase.1.pod
+++ b/git-debrebase.1.pod
@@ -370,7 +370,7 @@ and any ffq-prev is deleted.
 
 This is provided mostly for the test suite
 and for unusual situations.
-It should be used only with care and 
+It should only be used with care and 
 with a proper understanding of the underlying theory.
 
 Be sure to not accidentally treat the result as
diff --git a/git-debrebase.5.pod b/git-debrebase.5.pod
index c30b124d..d23c6b21 100644
--- a/git-debrebase.5.pod
+++ b/git-debrebase.5.pod
@@ -190,7 +190,7 @@ and the user's work
 can later be
 stitched into the fast-forwarding interchange form.
 
-An unstitched branch may be in the
+An unstitched branch may be in
 B
 state,
 which means it has a more particular special form
-- 
2.11.0

Bug#918384: [PATCH 4/6] documentation style: "branch" may be another kind ref

[Ian Jackson]

The thing being referred to here is `branch', not `the branch', since
it may not be a branch.  Put it in italics to make it clear that what
is referred to is the metasyntactic variable.

Signed-off-by: Ian Jackson 
---
 dgit.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit.1 b/dgit.1
index cd0419ee..d23dde01 100644
--- a/dgit.1
+++ b/dgit.1
@@ -448,7 +448,7 @@ and dgit actually imports the dsc
 dgit will make a pseudomerge
 so that the result is necessarily fast forward
 from the existing branch.
-Otherwise, if the branch already exists,
+Otherwise, if \fIbranch\fR already exists,
 dgit will stop with an error message.
 
 If
-- 
2.11.0

Bug#918384: [PATCH 3/6] documentation style: No "if ... ; consequence".

[Ian Jackson]

I think the parts of an if and its consequence may not be separated by
a semicolon.

Signed-off-by: Ian Jackson 
---
 dgit.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit.1 b/dgit.1
index b1bf0acc..cd0419ee 100644
--- a/dgit.1
+++ b/dgit.1
@@ -354,7 +354,7 @@ If there is an existing macro attribute line
 in .git/info/attributes,
 but it is insufficient,
 because it was made by an earlier version of dgit
-and git has since introduced new transforming attributes;
+and git has since introduced new transforming attributes,
 this modifies the macro to disable the newer transformations.
 
 (If there is already a macro attribute line
-- 
2.11.0

Bug#918959: gnucash crashes in Steuer-Bericht/ElStEr-Export when changing alteranate period to "use from-to"

[Bernhard Übelacker]

Hello Markus Blatt, dear Maintainer,
I just tried to reproduce the crash inside a minimal test VM,
with a new empty file, by these steps:

- Datei
- Neue Datei
- Weiter - Weiter - Weiter - Weiter - Weiter - Anwenden
- test.xml - Speichern
- Berichte - Steuer-Bericht & Elster Export
- Optionen
- Radiobuttons "Von" - "Bis"
- Anwenden

But I could not reproduce a crash.
So that might just manifest with some other special settings?
Could you reproduce it by using a newly created empty file
and if yes could you provide the exact steps to it ?

>From your backtrace I guess you have gnucash-dbgsym already installed?
You might add following packages to resolve also the shared libraries,
and resend another backtrace:

guile-2.2-libs-dbgsym libglib2.0-0-dbgsym libglib2.0-0-dbgsym 
libgtk-3-0-dbgsym libffi6-dbg libgtk-3-0-dbgsym libgc1c2-dbgsym

>From your backtrace it looks like the parameter to _wrap_gnc_mktime
points to invalid memory.


(Also it looks like gnucash "uses" some software written in guile
in this backtrace, but debians gdb does not include guile support,
and current gdb seems not to support guile-2.2 [1],
Is threre any way to see which guile software is
there currently interpreted? )

Kind regards,
Bernhard


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21104

Bug#919035: elpa-persp-projectile: broken with recent elpa-perspective

[Sean Whitton]

Package: elpa-persp-projectile
Version: 1:0.2.0-2
Severity: grave

`perspectives-hash' is now a function that returns something which does
not pass `hash-table-p'.  So patching is required.

Since this package is up for adoption, I won't be doing that patching
myself.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#918853: [qtcreator] ClangRefactoring impacts code model and causes crash on exit

[Johannes Zarl-Zierl]

Am Freitag, 11. Jänner 2019, 22:17:29 CET schrieb Lisandro Damián Nicanor 
Pérez Meyer:
> > Note: This is the same machine as mentioned in bug #918410, so everything
> > said
> > there applies here as well.
> 
> If this still true with the other bug solved?

Yes.

Bug#919008: python3-pdfminer: should depend on python3-pycryptodome, not recommend python3-crypto

[Daniele Tricoli]

Hello Sean,
meny thanks for this report!

On 11/01/2019 17:58, Sean Whitton wrote:
> Package: python3-pdfminer
> Version: 20181108+dfsg-2
> 
> Dear maintainer,
> 
> pdfminer.six's setup.py says that it requires pycryptodome, so I would
> expect to see
> 
> Depends: python3-pycryptodome
> 
> but instead there is
> 
> Recommends: python3-crypto
> 
> which seems to be wrong in two ways:
> 
> 1) it is a recommends, not a hard depends, but in setup.py it is listed
>as 'required'

You are right, it's listed as a hard depends, but it used only in the
following module:

>>> pdfminer.pdfdocument


If we look at the code we will see:

try:
from Crypto.Cipher import ARC4
from Crypto.Cipher import AES
from Crypto.Hash import SHA256
except ImportError:
AES = SHA256 = None
from . import arcfour as ARC4

So if an ImportError is raised the error will be catched and only AES
and SHA256 will be disabled. For ARC4 there is an implementation inside
pdfminer itself used as fallback.

This is why I chose recommends instead of depends, I think that could be
a valid usecase to not have pycrypto (or pycryptodome) as hard
dependency since it's not really required. I usually do this when I
discover that a library is not really required.

Is this causing some problems?

> 2) it is -crypto, rather than the -cryptodome fork.
> 
> I note that python3-pycryptodome is broken (#886291) and is not likely
> to be fixed before the transitions freeze, but I am not really sure
> whether that bug blocks this one or not.

I also stumbled on #886291, and since only AES, ARC4 and SHA256 are used
(and I don't think that the implementation in pycrypto of those
algorithms should worry us) I chose pycrypto (also it was used in the
original pdfminer) instead of pycryptodome.

I tested it with using the following steps (with python3-crypto installed):

❯ cat test.tex
\documentclass[a4paper]{article}

\begin{document}
\thispagestyle{empty}


This is a test!

\end{document}

❯ lualatex test.tex
[CUT output]

❯ qpdf --encrypt 1234 1234 40 -- test.pdf test-encrypted_ARC4.pdf
❯ pdf2txt -P 1234 test-encrypted_ARC4.pdf
This is a test!

❯ qpdf --encrypt 1234 1234 128 --use-aes=y -- test.pdf test-encrypted_AES.pdf
❯ pdf2txt -P 1234 test-encrypted_AES.pdf
This is a test!

Uninstalling python{,3}-crypto we will not be able do decrypt the file
encrypted with AES:

❯ pdf2txt -P 1234 test-encrypted_AES.pdf
Traceback (most recent call last):
  File "/usr/bin/pdf2txt", line 136, in 
if __name__ == '__main__': sys.exit(main())
  File "/usr/bin/pdf2txt", line 131, in main
outfp = extract_text(**vars(A))
  File "/usr/bin/pdf2txt", line 63, in extract_text
pdfminer.high_level.extract_text_to_fp(fp, **locals())
  File "/usr/lib/python3/dist-packages/pdfminer/high_level.py", line 80, in
extract_text_to_fp
check_extractable=True):
  File "/usr/lib/python3/dist-packages/pdfminer/pdfpage.py", line 129, in 
get_pages
doc = PDFDocument(parser, password=password, caching=caching)
  File "/usr/lib/python3/dist-packages/pdfminer/pdfdocument.py", line 577, in
__init__
self._initialize_password(password)
  File "/usr/lib/python3/dist-packages/pdfminer/pdfdocument.py", line 602, in
_initialize_password
raise PDFEncryptionError('Unknown algorithm: param=%r' % param)
pdfminer.pdfdocument.PDFEncryptionError: Unknown algorithm: param={'CF':
{'StdCF': {'AuthEvent': /'DocOpen', 'CFM': /'AESV2', 'Length': 16}}, 'Filter':
/'Standard', 'Length': 128, 'O':
b'\xc4\x8f\x00\x1f\xdcy\xa00\xd7\x18\xdf]\xbb\xda\xad\x81\xd1\xf6\xfe\xde\xc4\xa7\xb5\xcd\x98\rd\x13\x9e\xdf\xcb~',
'P': -4, 'R': 4, 'StmF': /'StdCF', 'StrF': /'StdCF', 'U':
b'\xfe\xeb\xed\x0e\x0f{2}r\xc5g\xc7\xf2]\xf0\xf4\x01"Ej\x91\xba\xe5\x13Bs\xa6\xdb\x13L\x87\xc4',
'V': 4}

but the ARC4 will be fine, due the provided implementation of pdfminer:

❯ pdf2txt -P 1234 test-encrypted_ARC4.pdf
This is a test!

Did you have problems with encryption? I only know qpdf to perform encryption,
so I used it, but if you can suggest more tools to test this feature I'll be
happy to try them.

Since all was fine I did not investigated more on pycryptodome, but please tell
me if I missed something.

> Please excuse my limited knowledge of python library packaging.

No need to excuse, your point are perfectly valid without an in-depth analysis
and I'm sorry for not putting what I just wrote in a README.Debian file inside
the package to explain why I did these choices. I did not thought about it, I
taken for granted... :(

My plan was to use python{,3}-crypto for Buster and then switch to pycryptodome
in Buster+1, but please tell me if something is not working or there is
something that I did not considered.

Regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org





signature.asc
Description: OpenPGP digital signature

Bug#914967: linux-image-4.18.0-3-amd64: errors "Failed to get unique processor _UID"

[Vincent Lefevre]

On 2019-01-11 11:17:03 -0500, Benjamin Redelings wrote:
> Package: src:linux
> Version: 4.18.20-2
> Followup-For: Bug #914967
> 
> Dear Maintainer,
> 
> Starting with package 4.18.0-3, my computer fails to finish booting.  I see 
> the message
> 
> acpi LNXCPU:bf: Failed to get unique processor _UID (0xff)
> 
> repeated many times (the bf seems to be a hexadecimal counter).

This is unrelated to the boot failure.

[...]
> board_name: X99 Extreme4/3.1
[...]

You're affected by the udev bug for the X99 chipset. See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918322

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

Bug#919004: ITP: node-rdf-canonize -- implementation of RDF Dataset Normalization Algorithm

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-01-12 01:45:34)
> Quoting David I. Lehn (2019-01-11 23:30:54)
> > On Fri, Jan 11, 2019 at 11:32 AM Jonas Smedegaard  wrote:
> > > ...
> > > * Package name: node-rdf-canonize
> > >   Version : 0.3.0
> > >   Upstream Author : David I. Lehn 
> > 
> > Any chance you could make the author a company?  I only played a part.
> > Upstream Author : Digital Bazaar 
> 
> Sure...:
> 
> Thing is, "Author" is asked for this bugreport but is not actually used 
> anywhere in the package.
> 
> As copyright holder in debian/copyright I will list only Digital Bazaar.
> 
> Is that fine with you, or did you want something else?

Here's what I've put together:
https://salsa.debian.org/js-team/node-rdf-canonize/blob/debian/master/debian/copyright


 - Jonas

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

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


signature.asc
Description: signature

Bug#919034: src:zeitgeist: Non-functional maintainer address

[Scott Kitterman]

Package: src:zeitgeist
Version: 1.0.1-0.3
Severity: serious
Justification: Policy 3.3

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  rai...@ubuntu.com
host mx.canonical.com [91.189.95.10]
SMTP error from remote mail server after RCPT TO::
550 5.1.1 : Recipient address rejected:
User unknown in virtual alias table

A working maintainer address is required.

Scott K

Bug#919033: src:zeitgeist: Non-functional maintainer address

[Scott Kitterman]

Package: src:zeitgeist
Version: 1.0.1-0.3
Severity: serious
Justification: Policy 3.3

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  rai...@ubuntu.com
host mx.canonical.com [91.189.95.10]
SMTP error from remote mail server after RCPT TO::
550 5.1.1 : Recipient address rejected:
User unknown in virtual alias table

A working maintainer address is required.

Scott K

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Vincent Lefevre]

On 2019-01-12 01:49:10 +0100, Vincent Lefevre wrote:
> Text is missing on the left. Moreover, I don't know why I get such
> a message (I haven't changed anything).

For the message itself, it is probably a consequence of this bug:

  https://github.com/systemd/systemd/issues/11264

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

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Axel Beckert]

Control: reopen -1
Control: found -1 240-3

Hi Michael,

Michael Biebl wrote:
> > I luckily can no more reproduce this with udev 240-3 and kernel
> > 4.19.13-1 or 4.20-1~exp1.
> 
> Ok, thanks for testing.

*sigh* I'm sorry to say, but it just happened again with udev 240-3
and kernel 4.20-1~exp1.

> > Since I can no more reproduce this with the versions above and I'm
> > also affected by (parts of) #918590 which make every reboot taking
> > about 8 to 9 minutes due to waiting for LVM (
> 
> If I would have to guess, I'd say it's another instance of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908796
> 
> You could try to add a sleep 5 at around line 179 in /etc/init.d/udev
> right before the udevadm calls.

Did that. And since the grub update (which calls LVM commands en
masse) took ages, I thought that I can maybe speed that up by
restarting udev with the modified init script:

"service udev restart" clearly didn't call "sleep 5", exited
successfully within a second or so.

So I did a "service udev stop" and a few seconds later a "service udev
start". After that 5 seconds of nothing, I got about a dozen lines of
warnings (something about mtp devices with I/O errors, maybe related
to my USB card reader without cards in it) and then was suddenly back
on my console login's getty.

Afterwards only init and the gettys were running.

Not sure if the still running grub package configuration triggered it
or part of the udev init script.

Another "service udev stop" and "service udev start" though didn't
trigger the issue again. Will try "udevadm control --reload-rules"
once grub is finished updating and then will reboot, see if that
changes anything (startup delays or process killings) and report more
details.

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

Bug#919032: RM: multiple [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; Unbuildable, out of date, no rdepends

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

In the way of the libcurl transition:

RM, failed to build or uninstallable, no deps

dak rm -p -R -B -n -a kfreebsd-amd64 amanda
dak rm -p -R -B -n -a kfreebsd-amd64,kfreebsd-i386,hurd-i386 xmms2-scrobbler
dak rm -p -R -B -n -a hurd-i386 trustedqsl
dak rm -p -R -B -n -a kfreebsd-amd64,kfreebsd-i386 libjson-rpc-cpp
dak rm -p -R -n -B -a kfreebsd-amd64,kfreebsd-i386 nixnote2
dak rm -p -R -n -B -a kfreebsd-amd64,kfreebsd-i386 janus
dak rm -p -R -n -B -a kfreebsd-amd64,kfreebsd-i386 libjson-rpc-cpp
dak rm -p -R -n -B -a kfreebsd-amd64,kfreebsd-i386,hurd-i386 php-solr

(requested on IRC by bigeasy)

Bug#918844: transition: gnustep-base, gnustep-gui

[Yavor Doganov]

Yavor Doganov wrote:
> Level 2
> ===
> # both -base and -gui; applies for the next levels as well
+ grr.app

I forgot grr.app here; mea culpa.

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Ingo Saitz]

Package: libmono-system4.0-cil
Version: 5.16.0.220+dfsg3-1
Severity: important

Dear Maintainer,

libmono-system4.0-cil contains in its dependencies on amd64 a dependency
on mono-runtime-common 5.18:

Depends: ..., mono-runtime (>= 5.16.0.220), mono-runtime-common (>= 
5.18.0.225), mono-runtime (<< 5.16.0.221)

This probably will never work, since mono-runtime depends on the exact
same version of mono-runtime-common. The dependency is not listed in
debian/control, so it seems it must have been introduced by
${misc:Depends} or ${cli:Depends} - was this package built on a system
with mono 5.18 packages installed?


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

Kernel: Linux 4.19.12-echse-4.1920181222 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages libmono-system4.0-cil depends on:
ii  libc62.28-4
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-2
ii  libmono-security4.0-cil  4.6.2.7+dfsg-2
ii  libmono-system-configuration4.0-cil  4.6.2.7+dfsg-2
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-2
ii  mono-runtime 4.6.2.7+dfsg-2

Versions of packages libmono-system4.0-cil recommends:
ii  ca-certificates-mono  4.6.2.7+dfsg-2

Versions of packages libmono-system4.0-cil suggests:
ii  libasound2  1.1.7-2
ii  libgamin0   0.1.10-5+b1

-- no debconf information

Bug#913214: libcurl3-gnutls: Connexion to a git server fails on "400 Bad Request"

[Antoine Amarilli]

Dear maintainer,

Would it be possible to update to curl 7.63.0 to fix this issue? Many
thanks!

Samuel, in the meantime my workaround is to downgrade to 7.60.0-1:

  sudo apt install libcurl3=7.60.0-1

Best regards,

-- 
Antoine Amarilli

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Vincent Lefevre]

Control: severity -1 grave

Raising to grave since:
  * grub-pc doesn't let me install GRUB (I assume the new version)
while this was normally needed.
  * The change in config.dat seems to imply that GRUB changed the
configuration in my back.

On 2019-01-12 01:49:10 +0100, Vincent Lefevre wrote:
> Package: grub-pc
> Version: 2.02+dfsg1-10
> Severity: important
> 
> When upgrading the grub packages, I got the following message:
> 
> ─┤ Configuring grub-pc 
> ├
> RUB boot loader was previously installed to a disk that is no
> r present, or whose unique identifier has changed for some reason.
>  important to make sure that the installed GRUB core image stays in
> with GRUB modules and grub.cfg. Please check again to make sure
> GRUB is written to the appropriate boot devices.
> 
> u're unsure which drive is designated as boot drive by your BIOS,
>  often a good idea to install GRUB to all of them.
> 
>  it is possible to install GRUB to partition boot records as well,
> ome appropriate partitions are offered here. However, this forces
> to use the blocklist mechanism, which makes it less reliable, and
> fore is not recommended.
> 
> install devices:
> 
> ] /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw on 
> /dev/dm
> ] /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___)
> ] - /dev/sda1 (254 MB; /boot)
> ] /dev/dm-1 (49 MB; zira--vg-root)
> 
> 
>  

After doing , I got another message, and the only thing I could
do was to continue without installing GRUB (otherwise, I was sent
back to the above message). The config.dat file changed in the
following way, which seems wrong:

 Name: grub-pc/install_devices
 Template: grub-pc/install_devices
-Value: /dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE
+Value: 
 Owners: grub-pc
 Flags: seen
 Variables:
  CHOICES = /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw 
on /dev/dm-0), /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA), - /dev/sda1 (254 
MB; /boot), /dev/dm-1 (49 MB; zira--vg-root)
  RAW_CHOICES = /dev/disk/by-id/dm-name-sda5_crypt, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA_15060EBA71EE-part1, 
/dev/disk/by-id/dm-name-zira--vg-root
 
 Name: grub-pc/install_devices_disks_changed
 Template: grub-pc/install_devices_disks_changed
+Value: 
 Owners: grub-pc
+Flags: seen
+Variables:
+ CHOICES = /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw 
on /dev/dm-0), /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___), - /dev/sda1 
(254 MB; /boot), /dev/dm-1 (49 MB; zira--vg-root)
+ RAW_CHOICES = /dev/disk/by-id/dm-name-sda5_crypt, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA15060EBA71EE, 
/dev/disk/by-id/ata-MTFDDAK512MAY-1AE1ZABHA15060EBA71EE-part1, 
/dev/disk/by-id/dm-name-zira--vg-root
 
 Name: grub-pc/install_devices_empty
 Template: grub-pc/install_devices_empty
-Value: false
+Value: true
 Owners: grub-pc
+Flags: seen

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

Bug#919030: kile: Crash when saving upon closing

[John Scott]

Package: kile
Version: 4:2.9.92-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When attempting to close Kile after modifying a document
and choosing to save it first, Kile often crashes in the
process. Fortunately, this doesn't have much of an affect
on usability as far as I can see.

I've got two different but similar backtraces that I'm
including and hope can be useful.

Thread 4 "KileParser::Doc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe3dfa700 (LWP 4303)]
ucstrncmp (l=, b=0x570981c8, a=0xd5554be2f458) at 
tools/qstring.cpp:685
685 tools/qstring.cpp: No such file or directory.
#0  ucstrncmp (l=, b=0x570981c8, a=0xd5554be2f458) at 
tools/qstring.cpp:685
#1  ucstrcmp (a=a@entry=0xd5554be2f458, alen=32767, b=0x570981c8, blen=11) 
at tools/qstring.cpp:899
#2  0x74d80b0a in qt_compare_strings (cs=Qt::CaseSensitive, rhs=..., 
lhs=...)
at ../../include/QtCore/../../src/corelib/tools/qstringview.h:275
#3  operator< (s1=..., s2=...) at tools/qstring.cpp:3214
#4  0x77bf8b10 in qMapLessThanKey (key2=..., key1=...)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:71
#5  QMapNode::lowerBound (akey=..., this=)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:155
#6  QMapData::findNode (this=, akey=...)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:287
#7  0x77bf54dc in QMap::constFind (akey=..., 
this=0x569f5bc0)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:869
#8  KileParser::LaTeXParser::parse (this=0x7fffd80025c0) at 
./src/parser/latexparser.cpp:186
#9  0x77bfb6cd in KileParser::ParserThread::run (this=0x559acd90) 
at ./src/parser/parserthread.cpp:193
#10 0x74d0dcd7 in QThreadPrivate::start (arg=0x559acd90) at 
thread/qthread_unix.cpp:367
#11 0x74a94fa3 in start_thread (arg=) at 
pthread_create.c:486
#12 0x778f788f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 "KileParser::Doc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe3dfa700 (LWP 4807)]
operator< (s1=..., s2=...) at tools/qstring.cpp:3214
3214tools/qstring.cpp: No such file or directory.
#0  operator< (s1=..., s2=...) at tools/qstring.cpp:3214
#1  0x77bf8b10 in qMapLessThanKey (key2=..., key1=...)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:71
#2  QMapNode::lowerBound (akey=..., this=)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:155
#3  QMapData::findNode (this=, akey=...)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:287
#4  0x77bf54dc in QMap::constFind (akey=..., 
this=0x569c0ad0)
at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmap.h:869
#5  KileParser::LaTeXParser::parse (this=0x7fffd80025c0) at 
./src/parser/latexparser.cpp:186
#6  0x77bfb6cd in KileParser::ParserThread::run (this=0x559369e0) 
at ./src/parser/parserthread.cpp:193
#7  0x74d0dcd7 in QThreadPrivate::start (arg=0x559369e0) at 
thread/qthread_unix.cpp:367
#8  0x74a94fa3 in start_thread (arg=) at 
pthread_create.c:486
#9  0x778f788f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

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

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

Versions of packages kile depends on:
ii  kinit  5.51.0-2
ii  kio5.51.0-1
ii  konsole-kpart  4:18.04.0-1
ii  libc6  2.28-2
ii  libgcc11:8.2.0-13
ii  libkf5codecs5  5.51.0-1
ii  libkf5completion5  5.51.0-1
ii  libkf5configcore5  5.51.0-1
ii  libkf5configgui5   5.51.0-1
ii  libkf5configwidgets5   5.51.0-1
ii  libkf5coreaddons5  5.51.0-1
ii  libkf5dbusaddons5  5.51.0-1
ii  libkf5guiaddons5   5.51.0-1
ii  libkf5i18n55.51.0-1
ii  libkf5iconthemes5  5.51.0-1
ii  libkf5jobwidgets5  5.51.0-1
ii  libkf5khtml5   5.51.0-1
ii  libkf5kiocore5 5.51.0-1
ii  libkf5kiofilewidgets5  5.51.0-1
ii  libkf5kiowidgets5  5.51.0-1
ii  libkf5parts5   5.51.0-1
ii  libkf5service-bin  5.51.0-1
ii  libkf5service5 5.51.0-1
ii  libkf5texteditor5  5.51.0-3
ii  libkf5textwidgets5 5.51.0-1
ii  libkf5widgetsaddons5   5.51.0-1
ii  libkf5windowsystem55.51.0-1
ii  libkf5xmlgui5  5.51.0-1+b1
ii  libpoppler-qt5-1   0.71.0-2
ii  libqt5core5a   5.11.3+dfsg-2
ii  libqt5dbus55.11.3+dfsg-2
ii  libqt5gui5 5.11.3+dfsg-2
ii  libqt5script5  5.11.3+dfsg-2
ii  libqt5widgets5 5.11.3+dfsg-2
ii  libqt5xml5 5.11.3+dfsg-2
ii  libstdc++6 8.2.0-13
ii  perl   5.28.1-3
ii 

Bug#919000: spyder: 1

[Drew Parsons]

Package: spyder
Version: 3.3.2+dfsg1-1
Followup-For: Bug #919000
Control: severity -1 normal

It's hardly critical.  Please don't overinflate bug severities.

https://www.debian.org/Bugs/Developer#severities

Bug#919004: ITP: node-rdf-canonize -- implementation of RDF Dataset Normalization Algorithm

[Jonas Smedegaard]

Hi Dave,

Quoting David I. Lehn (2019-01-11 23:30:54)
> On Fri, Jan 11, 2019 at 11:32 AM Jonas Smedegaard  wrote:
> > ...
> > * Package name: node-rdf-canonize
> >   Version : 0.3.0
> >   Upstream Author : David I. Lehn 
> 
> Any chance you could make the author a company?  I only played a part.
> Upstream Author : Digital Bazaar 

Sure...:

Thing is, "Author" is asked for this bugreport but is not actually used 
anywhere in the package.

As copyright holder in debian/copyright I will list only Digital Bazaar.

Is that fine with you, or did you want something else?


> > ...
> >   Description : implementation of RDF Dataset Normalization Algorithm
> 
> Probably should have "the" in there:
> Description : implementation of the RDF Dataset Normalization Algorithm

I went with just "RDF Dataset Normalization Algorithm" in short 
description (became too long a string).  But thanks anyway.


> > ...
> >  Universal RDF Dataset Normalization Algorithm 2015 (URDNA2015)
> >  is a method to normalize RDF datasets,
> >  needed to ease determining differencies,
> 
> Typo:
> differencies => differences

Ah. Thanks!


> There's an associated optional rdf-canonize-native package associated 
> with this one.  It's still a work-in-progress trying to figure out how 
> best to handle that setup.  May result in bogus native build failures 
> at the moment.  Can ignore that if just using the pure js code.
> 
> If any upstream changes are needed I'm happy to help.

Much appreciated!

Build routines require a range of additional packages not yet in Debian 
so if you happen to be able to easily shift upstream routines to only 
use what is in Debian then that would be awesome - but really I don't 
expect you to go through the trouble of that, there is nothing "wrong" 
with it.  Just now that you mention it is all.

Thanks for helping develop a nice piece of code!


 - Jonas

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

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


signature.asc
Description: signature

Bug#918844: transition: gnustep-base, gnustep-gui

[Yavor Doganov]

Emilio Pozuelo Monfort wrote:
> Go ahead with this.

Thanks a lot for the green light.  Both uploaded; gnustep-base would
need a give-back on armhf at the right moment as it got picked by the
arm64 buildd again.

> And yes, a combined list would be appreciated if the rebuilds need
> to be done in order. If order doesn't matter and I can schedule all
> the levels in one go, then I can combine them myself.

In previous transitions, the order was guaranteed because rdeps higher
up the stack were in state BD-Uninstallable until the library packages
they depend upon were rebuilt and installed.  But in this cycle we
have relaxed the dependencies between the -base/-gui binary packages
to allow co-installation of different library versions, thus
supporting partial upgrades.  (Incidentally, this should assist
transitions too as I think they will migrate as soon as their rdeps
with autopkgtests are binNMUed and their tests pass.  Previously, the
whole GNUstep stack migrated as one unit, usually waiting for the
slower arches to catch up.)

So the order will be undefined now if the binNMUs are scheduled at
once.  Packages up the stack that happen to build before their
dependencies below (e.g., lusernet.app building before pantomime) will
end up with warnings like:

| Linking app LuserNET ...
| /usr/bin/ld: warning: libgnustep-base.so.1.25, needed by 
/usr/lib/libPantomime.so, may conflict with libgnustep-base.so.1.26

This is harmless and relinking is not needed, but the lusernet.app
package will be broken for users (the program will abort on startup)
until pantomime is binNMUed.  I guess that's somewhat reluctantly
allowed during transitions ("unwritten law"); some packages are broken
right now in sid for users who upgraded -base and -gui because of the
programs from the -runtime packages which are available only for the
new library versions now.

What's important is that any package in this category which compiles
and runs tests at build time will FTBFS because the tests will abort.
This is precisely what happened to me with sogo when I tested it for
this transition; see #918795 for explanation (I closed the bug as it
turned out that sogo builds fine).  TTBOMK, gnustep-sqlclient and sogo
are the only rdeps that have tests, so you can schedule binNMUs for

gnustep-performance
sbjson
sope

first, wait for them to be installed everywhere and then schedule all
the rest in one go.  Alternatively, if the above is technically
difficult, schedule everything in one go and be ready for give-backs
on architectures where the wrong order leads to FTBFS.

And finally, if you feel now is not the proper time to experiment, you
can schedule them in batches, preserving the order and mimicking the
past transitions where the order naturally followed the dependency
chain.

Here is hopefully the complete list (I split them based on the
dependencies on the core libraries only to allow you to tweak the
binNMU changelogs, if you wish so; it doesn't matter otherwise):

Level 1
===
# packages that depend only on -base
biococoa
dbuskit
gnustep-netclasses
gnustep-performance
mknfonts.tool
openvpn-auth-ldap
pantomime
rsskit
sbjson
sope
unar

# packages that depend both on -base and -gui
aclock.app
addresses-for-gnustep
affiche
batmon.app
camera.app
cenon.app
charmap.app
chess.app
cynthiune.app
edenmath.app
etoile
fontmanager.app
ftp.app
gnustep-examples
gomoku.app
gorm.app
gridlock.app
gtamsanalyzer.app
helpviewer.app
lynkeos.app
mpdcon.app
paje.app
pikopixel.app
plopfolio.app
poe.app
popplerkit.framework
preview.app
price.app
projectcenter.app
renaissance
systempreferences.app
terminal.app
textedit.app
timemon.app
volumecontrol.app
wrapperfactory.app
zipper.app

Level 2
===
# only -base
gnustep-sqlclient
sogo

# both -base and -gui; applies for the next levels as well
agenda.app
gnumail
gnustep-dl2
gworkspace
lusernet.app
talksoup.app
viewpdf.app

Level 3
===
steptalk

Level 4
===
adun.app


Reverse dependencies that are deliberately omitted:

- fortunate.app (FTBFS, pending sourceful upload);
- gnustep-back (sourceful upload due at my sponsor's discretion; it
  tracks -gui versioning closely);
- pantomime1.2 (scheduled for removal; no point rebuilding it).

Bug#919029: grub-pc: meaningless message "RUB boot loader was previously installed..."

[Vincent Lefevre]

Package: grub-pc
Version: 2.02+dfsg1-10
Severity: important

When upgrading the grub packages, I got the following message:

─┤ Configuring grub-pc ├
RUB boot loader was previously installed to a disk that is no
r present, or whose unique identifier has changed for some reason.
 important to make sure that the installed GRUB core image stays in
with GRUB modules and grub.cfg. Please check again to make sure
GRUB is written to the appropriate boot devices.

u're unsure which drive is designated as boot drive by your BIOS,
 often a good idea to install GRUB to all of them.

 it is possible to install GRUB to partition boot records as well,
ome appropriate partitions are offered here. However, this forces
to use the blocklist mechanism, which makes it less reliable, and
fore is not recommended.

install devices:

] /dev/dm-0 (511850 MB; LVM PV RaDD9Y-cDSq-kdoy-fYKY-9eP0-kLkp-M1wVYw on /dev/dm
] /dev/sda (512110 MB; MTFDDAK512MAY-1AE1ZABHA___)
] - /dev/sda1 (254 MB; /boot)
] /dev/dm-1 (49 MB; zira--vg-root)


 

Text is missing on the left. Moreover, I don't know why I get such
a message (I haven't changed anything).

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/zira--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl,stripe=4 
0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
7b3de7fd-236a-47f6-bb85-64831a06ca1f
else
  search --no-floppy --fs-uuid --set=root 7b3de7fd-236a-47f6-bb85-64831a06ca1f
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1024x768 640x480
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=POSIX
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
7b3de7fd-236a-47f6-bb85-64831a06ca1f
else
  search --no-floppy --fs-uuid --set=root 7b3de7fd-236a-47f6-bb85-64831a06ca1f
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux, with Linux 4.19.0-1-amd64' --class debian --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-1-amd64-advanced-30a1ad7d-49ca-4b60-91d5-58f6f63d1c8e' {
savedefault
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
7b3de7fd-236a-47f6-bb85-64831a06

Bug#919028: chrome-gnome-shell: postinst fails on reconfigure or if json already exists

[Mike Miller]

Package: chrome-gnome-shell
Version: 10.1-4
Severity: normal
Tags: patch

Dear Maintainer,

The postinst script fails if

  /etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json

already exists on the system at the time of install. I've been able to
reproduce this two different ways so far:

1. I manually copied the file before upgrading to 10.1-4. The postinst
   attempted to symlink on top of an existing regular file and failed.

2. I ran `dpkg-reconfigure chrome-gnome-shell` after successful install.
   The postinst attempted to symlink on top an an already existing
   symlink that it had created when it was first installed.

There are probably several different ways you could address this, I'm
attaching a suggestion that works for me. In general I would think if
the destination already exists as a file or a symlink, you should avoid
trying to overwrite it at all.

Thanks!


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

Kernel: Linux 4.19.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chrome-gnome-shell depends on:
ii  gnome-shell   3.30.1-2
ii  python3   3.7.1-3
ii  python3-gi3.30.4-1
ii  python3-requests  2.20.0-2

chrome-gnome-shell recommends no packages.

Versions of packages chrome-gnome-shell suggests:
ii  chromium  72.0.3626.7-4
pn  firefox   

-- no debconf information
>From d8be8ae955cf79d0835b40718476561e97d79a9f Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Fri, 11 Jan 2019 15:53:55 -0800
Subject: [PATCH] Avoid failing install on link in /etc/opt/chrome

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

diff --git a/debian/postinst b/debian/postinst
index 703dfacc44a7..af0cada8695a 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -5,6 +5,8 @@ set -e
 #DEBHELPER#
 
 mkdir -p /etc/opt/chrome/native-messaging-hosts
-ln -s /usr/share/chrome-gnome-shell/org.gnome.chrome_gnome_shell.json 
/etc/opt/chrome/native-messaging-hosts/
+if [ ! -e 
/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json ]; then
+  ln -sf /usr/share/chrome-gnome-shell/org.gnome.chrome_gnome_shell.json 
/etc/opt/chrome/native-messaging-hosts/
+fi
 
 exit 0
-- 
2.20.1

Bug#915290: strace FTBFS with glibc 2.28

[Andreas Henriksson]

On Tue, Dec 04, 2018 at 02:53:22AM +, Steve McIntyre wrote:
> ACK, thanks for the pointer. I'm a few releases behind due to lack of
> time. Hoping to get that fixed shortly...

For your convenince I've pushed an updated version to branches to salsa:
wip/master
wip/upstream
wip/pristine-tar

If you don't have time to review, merge, upload I'm happy to help out
with a NMU. Just tell me about it

Regards,
Andreas Henriksson

Bug#891316: [MIA] Updating the cdebconf Uploaders list

[Holger Wansing]

Control: tags -1 + pending


Tobias Frost  (mia-teammaint) wrote:
> Source: cdebconf
> Version: 0.192 0.227 0.232 0.235 0.236 0.241
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
> 
> Regis Boudin  has not been working on
> the cdebconf package for quite some time.
> 
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.

Changed in GIT.

Tagging this bug as pending.



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#898696: Similar problem with version 4:18.08.1

[Pedro Celestino dos Reis Rodrigues]

On Fri, 4 Jan 2019 10:02:43 + Pedro Celestino dos Reis Rodrigues 
 wrote:
> For me this behavior starts after upgrading to 4:18.08.1
> 
> Thanks for any help
-- 
After a more detailed analysis of the current report I concluded that I have a 
different situation.
In my case the behavior is very close to that reported here: https://
bugs.kde.org/show_bug.cgi?id=400221

My best regards

Pedro

Bug#919027: wireshark: missing executables

[Stefan Pietsch]

Package: wireshark-common
Version: 2.6.6-1
Severity: normal

The wireshark-common package is missing these executable files:

- captype
- idl2wrs
- randpkt

Bug#918855: debconf: Impossible to upgrade from 1.5.59 -> 1.5.69

[Adrian Bunk]

On Wed, Jan 09, 2019 at 04:17:32PM -0800, Dima Kogan wrote:
> Package: debconf
> Version: 1.5.69
> Severity: serious
> 
> Hi.
> 
> I'm running a mostly-up-to-date Debian/sid system. I just tried updating
> it, and it barf at me when I ask it to update debconf:
>...
> The punchline is at the end. I haven't tried to figure out what this
> loop means, and I haven't attempted the setting suggested by the error
> message, since it sounds like it could break something. This probably
> shouldn't be happening. I'm attaching the output of 'dpkg -l'.

ii  perl  5.20.1-1 amd64
Larry Wall's Practical Extraction and Report Language
ii  perl-base 5.20.1-1 amd64
minimal Perl system
ri  perl-modules  5.20.1-1 all  
Core Perl modules

There are packages from unstable at some point between wheezy and jessie.
debconf 1.5.59 was pre-stretch unstable.

Are you somehow pinning/holding ancient packages on your system?

> Thanks!

cu
Adrian

-- 

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

Bug#919026: singularity-container: implausibly old timestamps when creating containers

[Afif Elghraoui]

Package: singularity-container
Version: 2.4-1
Severity: normal
Control: forwarded -1 https://github.com/sylabs/singularity/issues/1271

$  singularity exec docker://busybox whoami
Docker image path: index.docker.io/library/busybox:latest Cache folder set to 
/home/hayashis/.singularity/docker Creating container runtime... tar: ./.exec: 
implausibly old time stamp -9223372036854775808 tar: ./.run: implausibly old 
time stamp -9223372036854775808 tar: ./.shell: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/actions/exec: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/actions/run: implausibly old 
time stamp -9223372036854775808 tar: ./.singularity.d/actions/shell: 
implausibly old time stamp -9223372036854775808 tar: 
./.singularity.d/actions/start: implausibly old time stamp -9223372036854775808 
tar: ./.singularity.d/actions/test: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/actions: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/env/01-base.sh: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/env/90-environment.sh: 
implausibly old time stamp -9223372036854775808 tar: 
./.singularity.d/env/95-apps.sh: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/env/99-base.sh: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/env: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/libs: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/runscript: implausibly old 
time stamp -9223372036854775808 tar: ./.singularity.d/startscript: implausibly 
old time stamp -9223372036854775808 tar: ./.singularity.d: implausibly old time 
stamp -9223372036854775808 tar: ./.test: implausibly old time stamp 
-9223372036854775808 tar: ./dev: implausibly old time stamp 
-9223372036854775808 tar: ./environment: implausibly old time stamp 
-9223372036854775808 tar: ./etc/hosts: implausibly old time stamp 
-9223372036854775808 tar: ./etc/resolv.conf: implausibly old time stamp 
-9223372036854775808 tar: ./etc: implausibly old time stamp 
-9223372036854775808 tar: ./home: implausibly old time stamp 
-9223372036854775808 tar: ./proc: implausibly old time stamp 
-9223372036854775808 tar: ./root: implausibly old time stamp 
-9223372036854775808 tar: ./singularity: implausibly old time stamp 
-9223372036854775808 tar: ./sys: implausibly old time stamp 
-9223372036854775808 tar: ./tmp: implausibly old time stamp 
-9223372036854775808 tar: ./var/tmp: implausibly old time stamp 
-9223372036854775808 tar: ./var: implausibly old time stamp 
-9223372036854775808 tar: .: implausibly old time stamp -9223372036854775808 
user


This issue was reported upstream, but it's a debian bug introduced by an error 
in the reproducibile-builds patch from . That 
patch was applied in version 2.4-1 and affects all successive versions.

libexec/bootstrap-scripts/environment/Makefile.am is patched to call tar with 
the flag `--mtime="@${SOURCE_DATE_EPOCH:-$(date +%s)}"`, but the dollar sign 
isn't escaped in the patch, so Make just sees --mtime="@" and substitutes the 
implausibly old mtime for this invalid one.

Bug#919004: ITP: node-rdf-canonize -- implementation of RDF Dataset Normalization Algorithm

[David I. Lehn]

On Fri, Jan 11, 2019 at 11:32 AM Jonas Smedegaard  wrote:
> ...
> * Package name: node-rdf-canonize
>   Version : 0.3.0
>   Upstream Author : David I. Lehn 

Any chance you could make the author a company?  I only played a part.
Upstream Author : Digital Bazaar 


> ...
>   Description : implementation of RDF Dataset Normalization Algorithm

Probably should have "the" in there:
Description : implementation of the RDF Dataset Normalization Algorithm


> ...
>  Universal RDF Dataset Normalization Algorithm 2015 (URDNA2015)
>  is a method to normalize RDF datasets,
>  needed to ease determining differencies,

Typo:
differencies => differences

There's an associated optional rdf-canonize-native package associated
with this one.  It's still a work-in-progress trying to figure out how
best to handle that setup.  May result in bogus native build failures
at the moment.  Can ignore that if just using the pure js code.

If any upstream changes are needed I'm happy to help.

-dave

Bug#898550: Processed: Re: Bug#898550

[Agustin Martin]

On Fri, 4 Jan 2019 03:59:35 + (UTC) "J. Smith"
 wrote:
> reassign 898550 dictionaries-common
> stop
>
Hi, thanks for bringing this to dictionaries-common.

I am mostly out of my usual box, but will try to guess what is
happening, sorry if it is too wild a guess. I guess we are dealing
with hunspell-en-us Debian package.

> Your backtrace indicates that the error comes from 
> debian-ispell-preprocess-dicts-alist, which is provided by
> debian-ispell.el from the dictionaries-common package.

Error is actually in `decode-coding-string'

Debugger entered--Lisp error: (coding-system-error UTF-8)
  decode-coding-string("[']" UTF-8)
 ...

> This is corroborated by the fact that the error disappears with -Q, which 
> prevents loading
> of such site-lisp files. Perhaps the basic problem is using 'UTF-8 where 
> 'utf-8 is needed.

That last seems to be the actual problem. Using -q does not load the
initfile, but uses the registered value for hunspell-en-us which
happened to have uppercase UTF-8 string. Using -Q will ignore
everything and failure will not appear (no info at all about actual
dict). For Debian hunspell dicts using uppercase string when
registering (only hunspell-en-us AFAIK) this was noticed independently
and fixed in dictionaries-common 1.27.4 shortly after this bug report
was filed ,

https://salsa.debian.org/debian/dictionaries-common/commit/deece61f0068f20285d24d3a9ef9b3505cba748b

But for the general use (personal config files and autodetected info
from hunspell dicts) it is the config file or dictionary which should
be fixed. There is nothing dictionaries-common can do here, although
ispell.el could help by doing this lc conversion in
ispell-get-coding-system.

Not sure if there was a change in Emacs `decode-coding-string' around
that time, that may explain why it worked before.

Am I guessing too wildly?

Regards,

-- 
Agustin

Bug#918001: [intl:sv] Updated translation (sv) for apt-listbugs package

[Francesco Poli]

On Sat, 5 Jan 2019 14:49:16 +0100 Francesco Poli wrote:

[...]
> You're welcome: please let me know, so that I can fix these two last
> little details!

Since I haven't received any reply, I arbitrarily decided to
modify the translations as follows:


#: ../lib/aptlistbugs/logic.rb:533
msgid "You must install the reportbug package to be able to do this"
msgstr "Du måste installera paketet reportbug för att kunna göra det här"

[...]

#: ../lib/aptlistbugs/logic.rb:584
msgid "You must install a web browser package to be able to do this"
msgstr "Du måste installera en webbläsare för att kunna göra det här"

[...]

#: ../lib/aptlistbugs/logic.rb:647
msgid ""
"  - query the specified bug number\n"
" (uses %{prog} as user %{user}).\n"
msgstr ""
"- fråga efter det angivna felnumret\n"
"   (genom %{prog} som användare %{user}).\n"



Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp4E0wXxZKE0.pgp
Description: PGP signature

Bug#919021: gedit: TypeError in string_in_native_doc_encoding()

[Jakub Wilk]

* Jeremy Bicha , 2019-01-11, 15:36:

plugins/snippets/snippets/document.py contains the following code:

  cv = GLib.convert(s, -1, enc.get_charset(), 'UTF-8')

But GLib.convert() takes 3 arguments, not 4, so this will always fail 
with TypeError.


Do you have a sample file to help trigger the bug?


Difficult question. :-) I've never used gedit before. I noticed the bug 
by reading the code.


But OK, this is how you can trigger this:

1) Enable the "Snippets" plugin in settings.

2) Run:

  echo foo | iconv -t UTF-16 > foo.html
  gedit foo.html

3) Type "head" and press Tab.

You should get the following traceback:

  Traceback (most recent call last):
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
852, in on_view_key_press
  return self.run_snippet()
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
692, in run_snippet
  if not self.run_snippet_trigger(word, (start, end)):
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
664, in run_snippet_trigger
  return self.apply_snippet(snippets[0], bounds[0], bounds[1])
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
527, in apply_snippet
  env = self.get_environment()
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
491, in get_environment
  v = variables[var](buf)
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
345, in env_get_current_word
  return {'utf8': u8, 'noenc': self.string_in_native_doc_encoding(buf, u8)}
File "/usr/lib/i386-linux-gnu/gedit/plugins/snippets/document.py", line 
323, in string_in_native_doc_encoding
  cv = GLib.convert(s, -1, enc.get_charset(), 'UTF-8')
  TypeError: GLib.convert() takes exactly 3 arguments (4 given)

--
Jakub Wilk

Bug#917655: biojava4-live: FTBFS (cannot find symbol JAXBContext)

[Andreas Tille]

Control: tags -1 help upstream

Hi,

I've commited a new minor upstream version to Git but the problem exists
also in this version.  I've asked at debian-java list for help[1]

Kind regards

Andreas.

[1] https://lists.debian.org/debian-java/2019/01/msg00011.html

-- 
http://fam-tille.de

Bug#917511: harvest-tools: diff for NMU version 1.3-3.1

[Andreas Tille]

Hi Adrian,

On Fri, Jan 11, 2019 at 10:31:41PM +0200, Adrian Bunk wrote:
> I've prepared an NMU for harvest-tools (versioned as 1.3-3.1) and 
> uploaded it to DELAYED/14. Please feel free to tell me if I should 
> cancel it.

Thanks a lot for your work on this and sorry for missing this one.
Pretty please next time use maximum DELAYED/1 for Debian Med packages.
That's perfectly fine.  I could have speeded up the upload but I decided
to do some more polishing on the package and upload directly.

Thanks again for all your work

 Andreas.

PS: Most probably a ping to the bug report would have been sufficient
and might have saved your time. ;-)

-- 
http://fam-tille.de

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Keith Packard]

Alexander Larsson  writes:

>> I also fought with fontconfig for about a week when the release
>> including them was installed on my machine as firefox would spin
>> whenever it found a directory with no fonts. At the time, I felt injured
>> by this change.
>
> Hmm, why was it doing that though? Doesn't seem like it would have to.

A .uuid file was added and removed to every directory in the font tree
which contained no fonts or sub-directories; (a) the directory mtime was
changed, causing the system to re-scan the fonts and then
re-create/re-delete the .uuid file (goto a). Somehow this would
eventually stablize (I'm not entirely sure how). It was a 'surprising'
problem that happened only once in a while and it took several days of
searching to locate as the only symptom was that firefox would hang for
'a while' and then start working. Once I ran strace on the process while
hung, it was pretty easy to track down, but having fontconfig affecting
directory mtimes was not what I expected...

> You can't trust directory mtimes in this way. A file in the directory
> can be updated without modifying the directory mtime. That is only
> modified when you create or remove files.

Fontconfig already assumes that all 'interesting' changes result in
directory mtime changes -- it doesn't expect files to be changed in
place. If you have a system doing this, fontconfig will fail.

> However, the second problem is that it puts demands on the *host*, as
> it now has to match the layout of the runtimes so the pathnames can
> match identically.

Well, I was thinking that the runtime would dynamically adapt to the
host environment and change the configuration inside to match the
host.

Is it that flatpak treats fonts very specially, or are there other bits
of host data injected into the flatpak runtime in a similar fashion?

Essentially, I was imagining the flatpak runtime system would discover
the set of fontconfig directories exposed by the host and inject those
into the runtime using matching paths. Right now, you inject two fixed
paths (/usr/share/fonts and ~/.fonts), but if we really want to deal
with systems that put fonts in other places, then presumably flatpak
will need to adapt anyways.

Once you've discovered where fonts are being stored in the host, having
those get mounted in a matching path in the runtime doesn't seem like a
huge step to me. It's a fairly simple matter of changing the mount
target path and injecting an xml fragment file into /etc/fonts/conf.d

> Maybe "weird" setups like nix will run into issues. You might know
> this better.

Good point; as new distros start experimenting with different filesystem
layouts, we will need to be more cautious about assuming fixed paths
of any kind.

> Yes, but if you update the runtime and /usr/share/fonts-minimal
> changed in the new version (but has same mtime), then the stale cache
> file in the users homedir will still be used.

Ah. Thanks for explaining this. It seems like the only way this could
happen is if the cache file within the flatpak was stale and a
replacement generated and written to the user's homedir (as the only
writable location available).

I think that's just a bug in the flatpak generation -- the cache file
within the flatpak should always be up-to-date as (I assume) the
fontconfig library provided in the flatpak would have been used to
generate that cache file. And, a future flatpak shipped without that bug
would have a correct cache file, which would presumably be used in
preference to the one stored in the home directory?

> Initially I imagined uuid files would work somewhat like this. I.e.
> you put a .uuid file in the top /usr/share/fonts directory, and all
> the subdirectories would hash based on uuid + relative path.

That sounds like the same as my 'salt' idea, except you're storing it in
the font directories rather than the font configuration.

> However, flatpak will never parse the entire xml fontconfig file
> format (which isn't even really stable over time), so such a config
> would have to be external in a simpler config format.

The fontconfig xml format is quite stable and is designed to be
manipulated by tools that do not understand the full contents, hence
using XML and providing a suitable DTD.

However, in practice it's become far easier to use XML snippets instead,
so let's figure out how to do that instead.

> For example, we could have a /etc/fonts/uuids file which is a simple list 
> like:
>
> /usr/share/fonts b81b806a-fb12-4a31-b458-181b1be0ec23
>
> And then flatpak could read this and generate one for the sandbox that said:
>
> /run/host/fonts b81b806a-fb12-4a31-b458-181b1be0ec23

Yeah, moving the 'salt' out of the font directory and into the font
configuration seems like a good direction here. And placing it in a
separate file (although probably in XML format) seems like a better idea
than merging it into the existing  elements.

> However, the /etc/fonts/uuids file would still not be reproducible, so
> i'm not sur

Bug#919025: debian-installer: [armhf] Please add image for Sinovoip_Banana_Pi_M1+

[Frederic Daniel Luc Lehobey]

Package: debian-installer
Severity: wishlist
Tags: d-i

Dear Maintainer,

debian-installer already builds images for Banana Pro[1].

Could you please add images for Sinovoip Banana Pi M1+ ? It is a
variant of Banana Pro that differs in the sound connector[2].

Best regards,
Frédéric Lehobey

1. https://d-i.debian.org/daily-images/armhf/daily/u-boot/
2. http://linux-sunxi.org/Banana_Pro#Variants

Bug#919024: ITP: node-jsonld -- JSON-LD processor

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-jsonld
  Version : 1.4.0
  Upstream Author : Dave Longley 
* URL : https://github.com/digitalbazaar/jsonld.js
* License : Expat
  Programming Lang: JavaScript
  Description : JSON-LD processor

 This library is an implementation
 of the JSON-LD specification in JavaScript.
 .
 JavaScript Object Notation for Linked Data (JSON-LD)
 is a method of encoding Linked Data using JSON.
 .
 Linked Data is a method of publishing structured data
 so that it can be interlinked
 and become more useful through semantic queries.
 .
 This package contains jsonld usable with Node.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlw5EcoACgkQLHwxRsGg
ASHN9w//b1rHUPq1P/ZYMz3vcq9mxe2mzV9a0szSrm6vGTgdo8MG1nd/JvhID9tu
Ft1pJGx15CAJyrP1psEkdwJ0VBBax/1wz9P9F4lCKSBAQ+gNzFTCfH/qWUaDpt8Q
1psIiA2PeqQlwYrOEmhX6Ktc5iv+YPxqNq4NCkkLE7jxUp0XLdFcNIylCCKCLZuL
hPYYIiYTM6ffECEdWISF2a/IvI3XW1bhFAdoa9h0605kMkAqYb526i/Y859WSUmv
FU/O3/knXT5Rex5muOkxCPQG112JhgKQ8xgU9GKWfP4DQwblDefoNFdP6tiW16eF
ofr6ulJEJp49VDosbweezKFhQhILIJ9BBu85GEKhd4RGwkJyyklmo5CRW+90NBeI
ecksx7RZ24TRImLPDz9e+fG+HpUxHnYlOAeL69IrOcD88aBcIrAptjh1JwpVjpsy
T/cnGaTJwCqfMIDAMXrP31DiQxToubAgjBmMkit81E4By6l61M4V+tdE37bFgVPp
9z2uaWVZ400kzNyjbxtjSk177KJz/XHQg4fveNhndwnvu61w0e5PS/hVxILdgWnd
o1af/ADxQr3Qyz+UcyP4ubpiLMShficKSv+Dq79c9UwE65Z87WOZgbLyPima6Qrx
GftoBEPYJhiePseuVZbNcFTPdF5ju3E4k08wo6jZiT83A+WVPkg=
=Qu5y
-END PGP SIGNATURE-

Bug#907615: lxc-console not getting prompt with debian template

[Alex Mestiashvili]

> Is this issue occurring with root or unpriviledged containers ? 
> 

All are root containers:

lxc-info  --name test1 | grep PID
PID:5561

ps -ef | grep 5561
root  5561  5560  0 20:54 ?00:00:00 /sbin/init
root  5597  5561  0 20:54 ?00:00:00
/lib/systemd/systemd-journald
root  5640  5561  0 20:54 pts/200:00:00 /sbin/agetty --noclear
--keep-baud console 115200,38400,9600 vt220
root  5641  5561  0 20:54 ?00:00:00 /usr/sbin/sshd -D

Bug#918384: dgit: typo suggestions in man pages

[Ian Jackson]

Paul Hardy writes ("Bug#918384: dgit: typo suggestions in man pages"):
> Thank you for such a quick review.  Here is another git format-patch
> submission that incorporates the feedback from you both, for dgit
> version 8.3 this time.  I saw no new typos in version 8.3 document
> changes.

Thanks.  I have incorporated this.  Right now it is in an ad-hoc
branch, because you did not include a Signed-off-by line, and I want
to be clear about copyright status.  Can you confirm the facts stated
in the Developer Certificate of Origin ?  (I include a copy of this
below.)

Also I think I am going to revert or edit a handful of these hunks.
The best way to let you comment on that is for me to send patches to
do that to this bug for your comment.

Regards,
Ian.

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Bug#916639: Related bugs

[Fabian Grünbichler]

also see [0,1] for related discussions elsewhere.

0: https://github.com/lxc/lxc/issues/2778
1: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1811248

Bug#919023: Simplification of BOOTCFG_CreateGUID function

[Thomas Gaugler]

Package: win32-loader
Version: 0.9.3
Severity: normal
Tags: patch

The conversion of an UUID value into a string can be achieved by just 
using the g (GUID) type of the System plug-in. As a consequence the 
Win32 API calls could be eliminated.


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

Kernel: Linux 4.18.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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

win32-loader depends on no packages.

win32-loader recommends no packages.

Versions of packages win32-loader suggests:
pn  wine  
>From e735da16c5059c680d279a00de8cdf3c0e1bf53e Mon Sep 17 00:00:00 2001
From: Thomas Gaugler 
Date: Fri, 11 Jan 2019 22:04:52 +0100
Subject: [PATCH] Simplification of BOOTCFG_CreateGUID function

The conversion of an UUID value into a string can be achieved by just using the g (GUID) type of the System plug-in. As a consequence the Win32 API calls could be eliminated.
---
 include/bootcfg.nsh | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/include/bootcfg.nsh b/include/bootcfg.nsh
index 59ca3f4..3b087e4 100644
--- a/include/bootcfg.nsh
+++ b/include/bootcfg.nsh
@@ -1868,7 +1868,6 @@ FunctionEnd
   Push $0
   Push $1
   Push $2
-  Push $3
 
   ; Initialize return value
   StrCpy $0 ""
@@ -1876,24 +1875,11 @@ FunctionEnd
   ${If} $2 != 0
 System::Call "rpcrt4::UuidCreate(p r2) i.r1"
 ${If} $1 == 0
-  ; Create reference pointer
-  System::Call "*(&t0) p.r3"
-  ${If} $3 != 0
-System::Call "rpcrt4::UuidToString(p r2, pr3r3) i.r1"
-${If} $1 == 0
-  ; Extract string from reference pointer
-  System::Call "*$3(p .r0)"
-  System::Call "*$0(&t${NSIS_MAX_STRLEN} .r0)"
-  StrCpy $0 "{$0}"
-  System::Call "rpcrt4::RpcStringFree(pr3)"
-${EndIf}
-System::Free $3
-  ${EndIf}
+  System::Call "*$2(g .r0)"
 ${EndIf}
 System::Free $2
   ${EndIf}
 
-  Pop $3
   Pop $2
   Pop $1
   Exch $0
-- 
2.20.1

Bug#885178: closed by Georges Khaznadar (this bug is closed in revision 1.3-1)

[Jonas Smedegaard]

control: reopen -1

python-sympy 1.3-1 still depend on ipython, where this bugreport states 
that it should instead declare that it enhances ipython.

Below bug-closure claims to contain an explanation, but I fail to locate 
any.

Please either change the package relation, or provide a reason not to do 
so.


 - Jonas

Quoting Debian Bug Tracking System (2019-01-11 19:39:13)
> This is an automatic notification regarding your Bug report
> which was filed against the python-sympy package:
> 
> #885178: python-sympy: should enhance ipython (not recommend it)
> 
> It has been closed by Georges Khaznadar .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Georges Khaznadar 
>  by
> replying to this email.
> 
> 
> -- 
> 885178: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885178
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
> 
> thx
> 
> -- 
> Georges KHAZNADAR et Jocelyne FOURNIER
> 22 rue des mouettes, 59240 Dunkerque France.
> Téléphone +33 (0)3 28 29 17 70
> 
> 
> 
> Package: python-sympy
> Version: 1.1.1-2
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> python-sympy currently recommends ipython, and transitively a range of
> other packages as well, all of which seemingly relevant only  for
> _interactive_ use.
> 
> Package relations are directional, and it seems to me that while it
> makes sense for isympy to depend on ipython, it is not sensible for
> the python _library_ to (even weakly) depend on the iPython integration.
> 
> Please therefore change from "Recommends: ipython" to "Enhances: ipython".
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlpBQpUACgkQLHwxRsGg
> ASHvXBAAmQDnz/tguJsrVHto/kQE6bhtYGZgEGJ3y8v7wXv+fZ4y4E0FFOJu08L3
> 6zcZvjmCLQ9P4HN4PuG4SoOG3jqEoOaMK2wEXsXYJ3Apr5MvB9d3qtEhIJ0kOspU
> S9uElMkFBHHTeK0rDqtSZZfYoct0pIUySAdJD7zriyMhaR0alB0pge5uh4fCbyi3
> jyWjCN22nrgaq7GbGNG8Bu/4s4MWVZUmvm4u9qlWy5doyd9P7jVQ2IzZ7e4sUm0w
> JkVF+cSKnM6fNrhqLprhtc8N6+zAHegipLoMtd+9Fwxkitn8zrgTpfei0OigdHfc
> H1n7qmn2lrJgI9eyTwRnq/lzrdNh10kpC3BC4ReI5C4aW2D69SbAZ8oXs/H9wa3H
> l77W7owNjlFdjSFsDEgKBOTg6V2JJ4YdJY3UvhCJe+B5Tpi1C7s4h2+Y7PHCUPd8
> LiEttwL8cSmCqV3o1/xlnuNjtbQUBNoHrsgm5fkn5jJ1HhD4kw9aQzSMiIPESzTB
> qQURFVgyY9R7QXlj2iLIHGoKoSSs51ZkfRiVqiQ2xumRt6eA/ypRsfXYdphD+JKr
> D5jFo3+a2Ynk0hxWIV4NgYBl5UOslh4rxhFxiIgegkXbI0VBPWNhjm0q1ryInfD5
> a4KhoUrme6Jv9q3TRE3yJxtJkWqqNbDXhvKUibbWNQaPf5T9VnQ=
> =2zMe
> -END PGP SIGNATURE-

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

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


signature.asc
Description: signature

Bug#870448: hw-detect - stop using modprobe -l

[Holger Wansing]

Hi,

Vincent McIntyre  wrote:
> On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> > On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> > > Package: hw-detect
> > > Version: 1.124
> > > Severity: normal
> > > Tags: patch
> > > 
> > > I keep seeing this in installer logs, back to jessie.
> > > 
> > > Aug  2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option 
> > > -- 'l'
> > > 
> > > 
> > > I rated this normal rather than minor because the way it is working
> > > now the is_available() function always returns 1 (failure)
> > > 
> > > My suggestion is to use modinfo instead.
> > > This will return multiline output inside the quotes but
> > > a couple of tests suggests that is ok.
> > > It does fail with some modules (nvidia), not sure if we care.
> > >
> > > diff --git a/hw-detect.sh b/hw-detect.sh
> > > index 7977814..d8196c1 100755
> > > --- a/hw-detect.sh
> > > +++ b/hw-detect.sh
> > > @@ -43,7 +43,7 @@ is_not_loaded() {
> > >  }
> > >  
> > >  is_available () {
> > > -   [ "$(modprobe -l $1)" ] || return 1
> > > +   [ "$(modinfo $1)" ] || return 1
> > >  }
> > 
> > But this still prints error messages for missing modules.  I think the
> > function should be implemented as:
> > 
> > is_available () {
> > modprobe -qn "$1"
> > }
> > 
> 
> That seems much better, can someone please apply Ben's version?
> Thanks for tickling this Holger.

Any objections against this?

Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#918853: [qtcreator] ClangRefactoring impacts code model and causes crash on exit

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 9 ene. 2019 19:12, Johannes Zarl-Zierl  escribió:

> Package: qtcreator
> Version: 4.8.0-1
> Severity: normal
>
> --- Please enter the report below this line. ---
>
> When starting qtcreator with the ClangRefactoring plugin enabled, the code
> model seems to get confused (Pressing F2 to jump to the implementation of
> a
> method, as well as showing uses of a symbol does not work anymore).
>
> Also, when the plugin is enabled, I get a segfault on exit.
>
> If the plugin is not loaded, both problems disappear.
>
> Note: This is the same machine as mentioned in bug #918410, so everything
> said
> there applies here as well.
>

If this still true with the other bug solved?

>

Bug#917872: Automatically uninstall/reinstall Mroonga plugin on upgrade

[Otto Kekäläinen]

Hello!

> > The postinst of Mroong install is, and the postrm uninstalls it
> > correctly. There is however no code that would on a
> > postinst/preinst/upgrade scenario reinstall the plugin if the path has
> > changed (eg. as it does on in MariaDB 10.3 when the soname path
> > updates from libmariadb18 to libmaridb19).
>
> Just out of curiosity, what is the best way to detect
> soname path updates in maintainer script?
> If there is a similar package which treats this kind of issue, I want to know.

I don't know, unfortunately.

You can try if you find any examples via
https://codesearch.debian.net/ or discuss it on debian-devel@ mailing
list or on IRC. If your questions are MariaDB-specific you can ask
help on the MariaDB developers mailing list or Zulip chat.

Bug#907615: lxc-console not getting prompt with debian template

[Alex Mestiashvili]

On 1/11/19 1:57 PM, Pierre-Elliott Bécue wrote:
> Hi Alex,
> 
> Le 11/01/2019 à 10:59, Alex Mestiashvili a écrit :
>> On 1/10/19 11:52 PM, Pierre-Elliott Bécue wrote:
>>> Hi,
>>>
>>> Le jeudi 30 août 2018 à 09:58:31+0200, Alex Mestiashvili a écrit :
 Package: lxc
 Version: 1:2.0.9-6
 Severity: normal


 Steps to reproduce:

 install lxc, create a container with debian template (backing store
 doesn't matter in this case)

 lxc-create -n deb2 -t debian -B zfs --zfsroot=ocz/lxc

 lxc-console -n deb2 -l trace -o console_deb2.lxc.log
>>>
>>> Why using -l, which tend to ruin the interface and hence compromise the
>>> readability of the output?
>>
>> Well, -l is for the logpriority, that's why it is there. Sorry if that
>> was useless.
> 
> I'm pretty sorry if I gave you the impression that it was useless. My
> intent was more to suggest that as this output lacks sufficient intel,
> you can get rid of it. :)

No problem at all.

> 
>> I just gave it another try. And I think I narrowed down the issue with
>> the template.
> 
> With what version of lxc did you give it another try?

It's a buster installation with lxc 1:3.1.0-1:

dpkg -l | perl -lanE '/lxc/ && say $F[1],"\t",$F[2]'
liblxc1 1:3.1.0-1
lxc 1:3.1.0-1
lxc-templates   3.0.3-1
lxcfs   3.0.3-2

> 
>> When attaching to a newly created debian container (lxc-create -t
>> debian) with lxc-attach -n  I can see that there is only 1
>> console and no ttys are spawned:
>>
>> root@deb2:/etc# ps -ef | grep agetty
>> root73 1  0 09:42 console  00:00:00 /sbin/agetty --noclear
>> --keep-baud console 115200,38400,9600 vt220
>>
>> While in an ubuntu template there are 1 console and 4 pts:
>>
>> ps -ef | grep agetty
>> root   102 1  0 08:58 pts/000:00:00 /sbin/agetty --noclear
>> --keep-baud pts/0 115200 38400 9600 vt220
>> root   103 1  0 08:58 console  00:00:00 /sbin/agetty --noclear
>> --keep-baud console 115200 38400 9600 vt220
>> root   104 1  0 08:58 pts/300:00:00 /sbin/agetty --noclear
>> --keep-baud pts/3 115200 38400 9600 vt220
>> root   105 1  0 08:58 pts/100:00:00 /sbin/agetty --noclear
>> --keep-baud pts/1 115200 38400 9600 vt220
>> root   106 1  0 08:58 pts/200:00:00 /sbin/agetty --noclear
>> --keep-baud pts/2 115200 38400 9600 vt220
>>
>> So my initial bug report wasn't exactly correct.
>> One can get login prompt on container created with debian template, but
>> only by calling lxc-console -n  -t 0
>>
>> This "-t 0" is not obvious and I can imagine some people don't know
>> about it.
>>
>> lxc and lxc-console are totally ok. It's the debian template with
>> systemd which is by default have a not optimal setup.
>> No idea how to fix that, spent some time, but lost in systemd
>> crosslinked docs.
> 
> This is interesting, but I'm surprised, I'm not meeting such an issue,
> my Debian containers work perfectly fine.
> 
> Do you get any message? Can you use trace on lxc-create and log all of
> this in a file?
> 

I've got another box with up-to-date debian buster installed.
Installed lxc with apt-get install lxc (lxc 1:3.1.0-1, lxc-templates
3.0.3-1) created a new container with this command:

lxc-create -t debian -n test1

after that started the container:

lxc-start -dn test1

tried to lxc-console to the container:

lxc-console -n test1

Connected to tty 1
Type  to exit the console,  to enter Ctrl+a itself

Not getting prompt, however lxc-console -n test1 -t 0 does give a prompt.

lxc-attach with ps -ef:

lxc-attach -n test1
root@test1:~# ps -ef
UIDPID  PPID  C STIME TTY  TIME CMD
root 1 0  0 19:54 ?00:00:00 /sbin/init
root36 1  0 19:54 ?00:00:00
/lib/systemd/systemd-journald
root76 1  0 19:54 pts/200:00:00 /sbin/agetty --noclear
--keep-baud console 115200,38400,9600 vt220
root77 1  0 19:54 ?00:00:00 /usr/sbin/sshd -D
root79 0  0 20:06 pts/300:00:00 /bin/bash

So the issue is reproducible on a testing system.

When creating a container with -l trace I just get this:

lxc-create -l debug -o /tmp/lxc-create_debian.txt -t debian -n test5

cat  /tmp/lxc-create_debian.txt

lxc-create test7 20190111201044.860 DEBUGstorage -
storage/storage.c:get_storage_by_name:231 - Detected rootfs type "dir"

The same issue I observe with a sid container on another Debian buster
installation, only 1 aggety instance listening on console - t 0.

Regards,
Alex

Bug#659955: update-rc.d: add option to specify alternative root (like insserv -p)

[Jesse Smith]

On 1/11/19 8:36 AM, Dmitry Bogatov wrote:
> 
> [ I believe this bug should be reassigned to bin:insserv, if current
>   maintainer of bin:init-system-helpers agree. ]
> 
> [2012-02-15 11:33] Peter Eisentraut 
>> part   text/plain 238
>> Package: sysv-rc
>> Version: 2.88dsf-22
>> Severity: wishlist
>>
>> Please add an option like insserv -p or chkconfig --root to specify an
>> alternative root for the init scripts.  This would be useful for
>> testing and for fixing other file systems.
> 
> According to insserv(8), it must be possible (insserv=1.18.0):
> 
>[[/]path/to/init.d/]
>   Relative or absolute path to the init  scripts  base  directory.
>   This  defaults to /etc/init.d/ in compliance with the LSB speci‐
>   fication.  In this case insserv does not add or remove a  script
>   to  the  runlevels  declared  in  the  script  headers,  but may
>   re-order the runlevels if the order  of  the  currently  enabled
>   scripts  has  changed  (see option -d).  Note that if a relative
>   path is used insserv has to be called from the root directory.
> 
> but I failed to make use of it:
> 
>   $ mkdir /tmp/temp-1
>   $ cp -r /etc/init.d .
>   $ /sbin/insserv init.d
>   $ ls
>   init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d rcS.d
>   $ find -empty
>   ./rcS.d
>   ./rc6.d
>   ./rc5.d
>   ./rc4.d
>   ./rc3.d
>   ./rc2.d
>   ./rc1.d
>   ./rc0.d
> 
> Jesse, am I holding it wrong?
> 


The quoted part of the insserv manual page says when a relative path is
used insserv must be called from the root directory. In this case I
wonder if the man page is being ambiguous about whether it means root as
in "/" or root as in the top-level directory the user is working in. I'm
starting to suspect the former.

What happens if the steps are changed to be as follows:

mkdir /tmp/temp-1
cd /tmp/temp-1
cp -r /etc/init.d .
cd /
/sbin/insserv tmp/temp-1/init.d



If this way works then it's a limitation of insserv and should be better
documented on my end. If it doesn't work, then we have a bug I need to fix.

Bug#919021: gedit: TypeError in string_in_native_doc_encoding()

[Jeremy Bicha]

On Fri, Jan 11, 2019 at 3:00 PM Jakub Wilk  wrote:
> plugins/snippets/snippets/document.py contains the following code:
>
>cv = GLib.convert(s, -1, enc.get_charset(), 'UTF-8')
>
> But GLib.convert() takes 3 arguments, not 4, so this will always fail
> with TypeError.

Do you have a sample file to help trigger the bug?

In general, it might be better to first report upstream bugs upstream
and then file here if you need a fix backported.

https://gitlab.gnome.org/GNOME/gedit/issues

Thanks,
Jeremy Bicha

Bug#917511: harvest-tools: diff for NMU version 1.3-3.1

[Adrian Bunk]

Control: tags 917511 + pending

Dear maintainer,

I've prepared an NMU for harvest-tools (versioned as 1.3-3.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru harvest-tools-1.3/debian/changelog harvest-tools-1.3/debian/changelog
--- harvest-tools-1.3/debian/changelog	2018-11-26 08:48:51.0 +0200
+++ harvest-tools-1.3/debian/changelog	2019-01-11 22:27:35.0 +0200
@@ -1,3 +1,11 @@
+harvest-tools (1.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix from Peter Michael Green for FTBFS with new capng.
+(Closes: #917511)
+
+ -- Adrian Bunk   Fri, 11 Jan 2019 22:27:35 +0200
+
 harvest-tools (1.3-3) unstable; urgency=medium
 
   [ Jelmer Vernoo ]
diff -Nru harvest-tools-1.3/debian/patches/series harvest-tools-1.3/debian/patches/series
--- harvest-tools-1.3/debian/patches/series	2018-11-26 08:48:51.0 +0200
+++ harvest-tools-1.3/debian/patches/series	2019-01-11 22:27:32.0 +0200
@@ -3,3 +3,4 @@
 hardening.patch
 remove_memwrap.patch
 parallel.patch
+use-c++-14.patch
diff -Nru harvest-tools-1.3/debian/patches/use-c++-14.patch harvest-tools-1.3/debian/patches/use-c++-14.patch
--- harvest-tools-1.3/debian/patches/use-c++-14.patch	1970-01-01 02:00:00.0 +0200
+++ harvest-tools-1.3/debian/patches/use-c++-14.patch	2019-01-11 22:27:35.0 +0200
@@ -0,0 +1,28 @@
+Description: Use c++14 rather than c++11 for compatibility with new capng.
+Author: Peter Michael Green 
+Bug-Debian: https://bugs.debian.org/917511
+Last-Update: 2018-12-27
+
+Index: harvest-tools-1.3/configure.ac
+===
+--- harvest-tools-1.3.orig/configure.ac
 harvest-tools-1.3/configure.ac
+@@ -29,7 +29,7 @@ then
+ 	AC_MSG_ERROR([Cap'n Proto compiler (capnp) not found.])
+ fi
+ 
+-CPPFLAGS="-I$with_protobuf/include -I$with_capnp/include -std=c++11"
++CPPFLAGS="-I$with_protobuf/include -I$with_capnp/include -std=c++14"
+ 
+ AC_CHECK_HEADER(google/protobuf/stubs/common.h, [result=1], [result=0])
+ 
+Index: harvest-tools-1.3/Makefile.in
+===
+--- harvest-tools-1.3.orig/Makefile.in
 harvest-tools-1.3/Makefile.in
+@@ -1,4 +1,4 @@
+-CXXFLAGS += -std=c++11 -Isrc -I@protobuf@/include -I@capnp@/include
++CXXFLAGS += -std=c++14 -Isrc -I@protobuf@/include -I@capnp@/include
+ 
+ UNAME_S=$(shell uname -s)
+ 

Bug#919022: is it a transition if the only rdep is already broken: libgpuarray

[Rebecca N. Palmer]

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

I have just been given permission to take over libgpuarray.

I would like to update it from 0.6.9 to 0.7.6, which bumps SONAME from 2 
to 3 and is described by upstream as including API changes [0].


The only other Debian package that (optionally) uses libgpuarray is 
theano.  This part of theano *only* works with the *new* libgpuarray, 
i.e. is currently broken [1].


libgpuarray is currently not in testing because it is RC buggy, but that 
can and will be fixed with or without going to the new upstream version.


I can prepare this tonight, but not necessarily upload it as I am only a 
DM and don't have rights for this package.


theano uses the Python interface to libgpuarray, so it will not need to 
be binNMUd and there is no real point in having a formal transition tracker.


[0] https://github.com/Theano/libgpuarray/releases
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901487

Bug#907615: lxc-console not getting prompt with debian template

[Pierre-Elliott Bécue]

Le 11 janvier 2019 21:21:54 GMT+01:00, Alex Mestiashvili 
 a écrit :
>On 1/11/19 1:57 PM, Pierre-Elliott Bécue wrote:
>> Hi Alex,
>> 
>> Le 11/01/2019 à 10:59, Alex Mestiashvili a écrit :
>>> On 1/10/19 11:52 PM, Pierre-Elliott Bécue wrote:
 Hi,

 Le jeudi 30 août 2018 à 09:58:31+0200, Alex Mestiashvili a écrit :
> Package: lxc
> Version: 1:2.0.9-6
> Severity: normal
>
>
> Steps to reproduce:
>
> install lxc, create a container with debian template (backing
>store
> doesn't matter in this case)
>
> lxc-create -n deb2 -t debian -B zfs --zfsroot=ocz/lxc
>
> lxc-console -n deb2 -l trace -o console_deb2.lxc.log

 Why using -l, which tend to ruin the interface and hence compromise
>the
 readability of the output?
>>>
>>> Well, -l is for the logpriority, that's why it is there. Sorry if
>that
>>> was useless.
>> 
>> I'm pretty sorry if I gave you the impression that it was useless. My
>> intent was more to suggest that as this output lacks sufficient
>intel,
>> you can get rid of it. :)
>
>No problem at all.
>
>> 
>>> I just gave it another try. And I think I narrowed down the issue
>with
>>> the template.
>> 
>> With what version of lxc did you give it another try?
>
>It's a buster installation with lxc 1:3.1.0-1:
>
>dpkg -l | perl -lanE '/lxc/ && say $F[1],"\t",$F[2]'
>liblxc1 1:3.1.0-1
>lxc 1:3.1.0-1
>lxc-templates   3.0.3-1
>lxcfs   3.0.3-2
>
>> 
>>> When attaching to a newly created debian container (lxc-create -t
>>> debian) with lxc-attach -n  I can see that there is only
>1
>>> console and no ttys are spawned:
>>>
>>> root@deb2:/etc# ps -ef | grep agetty
>>> root73 1  0 09:42 console  00:00:00 /sbin/agetty
>--noclear
>>> --keep-baud console 115200,38400,9600 vt220
>>>
>>> While in an ubuntu template there are 1 console and 4 pts:
>>>
>>> ps -ef | grep agetty
>>> root   102 1  0 08:58 pts/000:00:00 /sbin/agetty
>--noclear
>>> --keep-baud pts/0 115200 38400 9600 vt220
>>> root   103 1  0 08:58 console  00:00:00 /sbin/agetty
>--noclear
>>> --keep-baud console 115200 38400 9600 vt220
>>> root   104 1  0 08:58 pts/300:00:00 /sbin/agetty
>--noclear
>>> --keep-baud pts/3 115200 38400 9600 vt220
>>> root   105 1  0 08:58 pts/100:00:00 /sbin/agetty
>--noclear
>>> --keep-baud pts/1 115200 38400 9600 vt220
>>> root   106 1  0 08:58 pts/200:00:00 /sbin/agetty
>--noclear
>>> --keep-baud pts/2 115200 38400 9600 vt220
>>>
>>> So my initial bug report wasn't exactly correct.
>>> One can get login prompt on container created with debian template,
>but
>>> only by calling lxc-console -n  -t 0
>>>
>>> This "-t 0" is not obvious and I can imagine some people don't know
>>> about it.
>>>
>>> lxc and lxc-console are totally ok. It's the debian template with
>>> systemd which is by default have a not optimal setup.
>>> No idea how to fix that, spent some time, but lost in systemd
>>> crosslinked docs.
>> 
>> This is interesting, but I'm surprised, I'm not meeting such an
>issue,
>> my Debian containers work perfectly fine.
>> 
>> Do you get any message? Can you use trace on lxc-create and log all
>of
>> this in a file?
>> 
>
>I've got another box with up-to-date debian buster installed.
>Installed lxc with apt-get install lxc (lxc 1:3.1.0-1, lxc-templates
>3.0.3-1) created a new container with this command:
>
>lxc-create -t debian -n test1
>
>after that started the container:
>
>lxc-start -dn test1
>
>tried to lxc-console to the container:
>
>lxc-console -n test1
>
>Connected to tty 1
>Type  to exit the console,  to enter Ctrl+a
>itself
>
>Not getting prompt, however lxc-console -n test1 -t 0 does give a
>prompt.
>
>lxc-attach with ps -ef:
>
>lxc-attach -n test1
>root@test1:~# ps -ef
>UIDPID  PPID  C STIME TTY  TIME CMD
>root 1 0  0 19:54 ?00:00:00 /sbin/init
>root36 1  0 19:54 ?00:00:00
>/lib/systemd/systemd-journald
>root76 1  0 19:54 pts/200:00:00 /sbin/agetty --noclear
>--keep-baud console 115200,38400,9600 vt220
>root77 1  0 19:54 ?00:00:00 /usr/sbin/sshd -D
>root79 0  0 20:06 pts/300:00:00 /bin/bash
>
>So the issue is reproducible on a testing system.
>
>When creating a container with -l trace I just get this:
>
>lxc-create -l debug -o /tmp/lxc-create_debian.txt -t debian -n test5
>
>cat  /tmp/lxc-create_debian.txt
>
>lxc-create test7 20190111201044.860 DEBUGstorage -
>storage/storage.c:get_storage_by_name:231 - Detected rootfs type "dir"
>
>The same issue I observe with a sid container on another Debian buster
>installation, only 1 aggety instance listening on console - t 0.
>
>Regards,
>Alex

Is this issue occurring with root or unpriviledged containers ? 
-- 
PEB from my phone.

Bug#713905: mention that there is nothing wrong with one's system upon warning

[Jesse Smith]

> Jesse, could you please take a look at this. This message is generated
> by insserv. Probably we could use more gentle tone, like
> 
>   'info: default start runlevel arguments (2 3 4 5) differs from default 
> (S). Proceeding as requested'.
> 

I looked at this and I do not see anywhere in the insserv code where
this message could be generated.  However, it does appear to match line
415-416 of the update-rc.d script. I think this message would have to be
changed there.

- Jesse

Bug#916148: lpr: diff for NMU version 1:2008.05.17.3

[Adrian Bunk]

Control: tags 916148 + patch
Control: tags 916148 + pending

Dear maintainer,

I've prepared an NMU for lpr (versioned as 1:2008.05.17.3) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru lpr-2008.05.17.2/debian/changelog lpr-2008.05.17.3/debian/changelog
--- lpr-2008.05.17.2/debian/changelog	2016-09-25 16:08:29.0 +0300
+++ lpr-2008.05.17.3/debian/changelog	2019-01-11 22:06:54.0 +0200
@@ -1,3 +1,12 @@
+lpr (1:2008.05.17.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with glibc 2.28. (Closes: #916148)
+  * Sugggest ghostscript instead of gs. (Closes: #601355)
+  * Build with -g to get non-empty -dbgsym.
+
+ -- Adrian Bunk   Fri, 11 Jan 2019 22:06:54 +0200
+
 lpr (1:2008.05.17.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lpr-2008.05.17.2/debian/control lpr-2008.05.17.3/debian/control
--- lpr-2008.05.17.2/debian/control	2016-09-25 16:08:29.0 +0300
+++ lpr-2008.05.17.3/debian/control	2019-01-11 22:06:54.0 +0200
@@ -10,7 +10,7 @@
 Package: lpr
 Architecture: any
 Depends: ${shlibs:Depends}, netbase
-Suggests: magicfilter | apsfilter, gs
+Suggests: magicfilter | apsfilter, ghostscript
 Conflicts: suidmanager (<< 0.50)
 Replaces: logcheck-database
 Description: BSD lpr/lpd line printer spooling system
diff -Nru lpr-2008.05.17.2/debian/rules lpr-2008.05.17.3/debian/rules
--- lpr-2008.05.17.2/debian/rules	2016-09-25 16:08:29.0 +0300
+++ lpr-2008.05.17.3/debian/rules	2019-01-11 22:06:54.0 +0200
@@ -5,8 +5,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-CFLAGS = -Wall -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
-CPPFLAGS = -Wall -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
+CFLAGS = -Wall -g -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
+CPPFLAGS = -Wall -g -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
 # -D_BSD_SOURCE
 
 build: build-stamp
diff -Nru lpr-2008.05.17.2/lpr/lpr.c lpr-2008.05.17.3/lpr/lpr.c
--- lpr-2008.05.17.2/lpr/lpr.c	2008-05-18 01:47:19.0 +0300
+++ lpr-2008.05.17.3/lpr/lpr.c	2019-01-11 20:58:27.0 +0200
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 

Bug#915689: prevent from migrating to testing

[Michael Stone]

On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote:
There never should have been an NMU simply replacing rng-tools with 
rng-tools5. I did not notice that this had happened.


Also, the correct fix for buster is an upload to put things back the way 
they were, which is going to be ugly.

Bug#919021: gedit: TypeError in string_in_native_doc_encoding()

[Jakub Wilk]

Source: gedit
Version: 3.30.2-2
Tags: upstream

plugins/snippets/snippets/document.py contains the following code:

  cv = GLib.convert(s, -1, enc.get_charset(), 'UTF-8')

But GLib.convert() takes 3 arguments, not 4, so this will always fail 
with TypeError.


--
Jakub Wilk

Bug#919020: llvm-dev: Provide /usr/lib/bfd-plugins/LLVMgold.so

[Marc Glisse]

Package: llvm-dev
Version: 1:7.0-47
Severity: normal

Dear Maintainer,

as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631178
, it would be nice to provide a symlink for LLVMgold.so in
/usr/lib/bfd-plugins . Gcc does it for their plugin
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865690). It would let
tools like nm, ar, etc understand LTO files automatically.

/tmp $ clang e.c -flto -c
/tmp $ file e.o
e.o: LLVM IR bitcode
/tmp $ nm e.o
nm: e.o: file format not recognized

[adding the symlink]

/tmp $ nm e.o
 T main

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

Kernel: Linux 4.19.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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages llvm-dev depends on:
ii  llvm  1:7.0-47
ii  llvm-7-dev1:7.0.1-4
ii  llvm-runtime  1:7.0-47

llvm-dev recommends no packages.

llvm-dev suggests no packages.

-- no debconf information

Bug#918187: fai - hook error handling completely broken

[Holger Levsen]

On Fri, Jan 11, 2019 at 08:26:36PM +0100, Bastian Blank wrote:
> On Fri, Jan 11, 2019 at 01:51:53PM +0100, Thomas Lange wrote:
> > since you did not justified why this bug is grave, I will downgrade
> > it to normal.
> Well, I consider it RC for the cloud stuff as it makes image build silently
> break.  Do you really want to play this every time?
 
sounds 'important' to me: "serious impact for some while not making it
completly unusable for everyone"...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#551555: mountnfs.sh: start should declare dependency on name resolver

[Petter Reinholdtsen]

[Dmitry Bogatov]
>> No objections, but note there used to be several scripts in rcS.d/
>> depending on /usr/ being mounted, and these need to be moved from S to
>> (2 3 4 5) first.
>
> As far as I can tell, we can assume /usr being mounted (if it is
> separate from /) at time /sbin/init is launched.

Even on diskless workstations and thin clients using LTSP?  It is the
use case I know about, but it is years since I tracked its status, so I
do not know if it is still an issue there.

> Another issue is that definition of $remote_fs is *all* file systems are
> mounted. And there is some scripts, which 'Default-Start: S', depending
> on $remote_fs.  Seems to get this issue resolved, we need to get
> following list of packages to get rid of dependency on $remote_fs or
> move to (2 3 4 5) runlevels. Correct?

I can not confirm the list, but yes, every script in rcS.d/ depending on
$remote_fs will have to move to (2 3 4 5).  Traditionally (as in
Solaris/SysV systems) mounting /usr/ was done in rc[2345].d/, but this
was for some strange reason never done in Debian.  I tried to move
$remote_fs there, but ran out of steem before I managed to convince
enough maintainers to do the switch.

-- 
Happy hacking
Petter Reinholdtsen

Bug#917567: maintainer-script-should-not-use-dpkg-maintscript-helper matched valid calls

[Sven Hartge]

Um 18:32 Uhr am 11.01.19 schrieb Sven Hartge:

I also looked at some packages listed at 
https://lintian.debian.org/tags/maintainer-script-should-not-use-dpkg-maintscript-helper.html,
 
mainly those with low line numbers.

Looking at chain, haproxy, gnucash and debci, only debci seems to have a 
manually added dpkg-maintscript-helper line, the rest have all been 
created by dh_installdeb.

It looks to me that this lintian check should only be used on source 
pacakges and not binary ones.

Grüße,
Sven.

Bug#918187: fai - hook error handling completely broken

[Bastian Blank]

On Fri, Jan 11, 2019 at 01:51:53PM +0100, Thomas Lange wrote:
> since you did not justified why this bug is grave, I will downgrade
> it to normal.

Well, I consider it RC for the cloud stuff as it makes image build silently
break.  Do you really want to play this every time?

> Did you tried to set STOP_ON_ERROR to a lower value? 

I looked at the code and this variable is not used near the hook stuff:

| call_hook() {
| for cl in $classes; do
| hfile=$FAI/hooks/$hook.$cl
| if [ -x $hfile ]; then
| $hfile $dflag "$@"
| check_status $hook.$cl $?
| fi
| done
| }

> I have ideas how to add this feature also to hook, and I will try to
> implement this soon.

set -e works wonders.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5

Bug#894824: popt FTCBFS: api-sanity-checker dependency unsatisfiable

[Michael Jeanson]

On 2018-12-28 7:24 a.m., Niels Thykier wrote:
> Hi Michael,
> 
> Could I perhaps convince you to do an upload with this patch in
> time for buster?  It will enable us to remove one hack/work around
> in the "bootstrap.sh" script currently in use for bootstrapping
> new architectures (as well as improve our cross-building stats for
> buster). Also, you mention that you have applied it in git but I
> cannot see it in salsa (admittedly, I only checked the master
> branch).  Have you perhaps forgotten to push it?
> 
> If you would like some additional changes/improvements to popt
> (albeit unrelated to this bug), then I can think of:
> 
> * The override for dh_auto_build might be redundant now that
> debhelper passes --disable-silent-rules (as of
> debhelper/9.20140613)
> 
> * The popt looks like a package that might be able to build with 
> "Rules-Requires-Root: no" set in the Source in d/control. - If that
> fails in sid because the upstream build system relies on root,
> please set "Rules-Requires-Root: binary-targets" explicitly. This
> will enable us to flip the default and make "(fake)root" opt-in
> rather than opt-out in the future.
> 
> Thanks, ~Niels

Sorry for the lack of reply, I've just uploaded a package with the fix
included as well as addressing your other comments.

Michael

Bug#915689: prevent from migrating to testing

[Michael Stone]

There never should have been an NMU simply replacing rng-tools with 
rng-tools5. I did not notice that this had happened.


On Fri, Jan 11, 2019 at 07:21:49PM +0100, Andreas Henriksson wrote:

That has apparently failed to materialize well in time for buster.
Looking at the contents of the binary packages it seems rng-tools
(in unstable) has more contents and likely provides more
functionality/integration (but I haven't looked into details, eg.
rng-tools5 has no /etc/default file which might be a good thing as those
are generally frowed upon in the current systemd service age, but has
there been any work on actual migration of current rng-tools users
configuration to what rng-tools5 uses?)


It's not possible to migrate people from rng-tools to rng-tools5 as the 
functionality does not entirely overlap. There's no meaningful 
conversion from one to the other, nor does there need to be. (A user 
currently running rng-tools has no need to move to rng-tools5.) There's 
a chance (though increasingly small as the legacy hardware ages) that 
forcing a migration from rng-tools to rng-tools5 will break an existing 
setup.


The intent of transitioning was entirely to make it easier for people 
reading non-debian-specific instructions on the internet telling them to 
install "rng-tools" in order to get certain functionality (specifically 
RDRAND/RDSEED) would get the package they were expecting. The end result 
for buster would be rng-tools2 and rng-tools5 packages, with an 
rng-tools package pulling in rng-tools2 as a replacement. 

Given that the kernel seems to be moving in the direction of allowing 
RDRAND/RDSEED to seed /dev/random without blocking (see 
RANDOM_TRUST_CPU) I'm not sure a package renaming dance is worthwhile as 
the most common reason for installing rng-tools5 will no longer be 
as relevant.


Another option is to simply remove rng-tools, which eliminates the 
confusion. But, doing that will mean dropping support for certain 
(legacy) configurations supported in the current rng-tools package but 
not rng-tools5.

Bug#896025: Segfault in test suite of new upstream version (Was: python-mne FTBFS with python-matplotlib 2.2.2-1)

[Andreas Tille]

Hi,

any success with fixing this?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#919019: Interval timers with CLOCK_*_CPUTIME_ID fail to reschedule with 4.19.13-1

[anomie]

Package: linux-image-4.19.0-1-amd64
Version: 4.19.13-1

The attached test program should print about 100 lines each for "Hit
CLOCK_MONOTONIC!", "Hit CLOCK_PROCESS_CPUTIME_ID!", and "Hit
CLOCK_THREAD_CPUTIME_ID!".

On my laptop running kernel linux-image-4.19.0-1-amd64 version
4.19.13-1, however, it prints the ~100 for CLOCK_MONOTONIC but only one
each for CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

On a VirtualBox virtual machine, freshly installed and dist-upgraded to
sid, I see the same thing. Downgrading to version 4.19.12-1 from
https://snapshot.debian.org/package/linux-signed-amd64/4.19.12%2B1/#linux-image-4.19.0-1-amd64_4.19.12-1
(and rebooting, of course) causes the test program to give the expected
output.

I don't know if this was something broken upstream or if it's something
specific to Debian's kernel package. Please forward upstream if
appropriate. Thanks!
/* Compile:
   gcc foo.c -o foo -lrt
*/

#include 
#include 
#include 
#include 
#include 
#include 

void handle_event( union sigval sv ) {
printf( "Hit %s!\n", (const char *)sv.sival_ptr );
}

void test( const char *name, clockid_t clock_id ) {
timer_t timer;
struct sigevent ev;
struct itimerspec start = { { 0, 2000 }, { 0, 2000 } };
struct itimerspec zero = { { 0, 0 }, { 0, 0 } };
struct timespec ts0, ts1;

printf( "Testing %s...\n", name );

memset( &ev, 0, sizeof(ev) );
ev.sigev_notify = SIGEV_THREAD;
ev.sigev_notify_function = handle_event;
ev.sigev_value.sival_ptr = (void *)name;

if ( timer_create( clock_id, &ev, &timer ) != 0 ) {
fprintf( stderr, "Failed to create %s timer: %s\n", name, strerror( errno ) );
return;
}
if ( timer_settime( timer, 0, &start, NULL ) != 0 ) {
fprintf( stderr, "Failed to start %s timer: %s\n", name, strerror( errno ) );
return;
}

clock_gettime( clock_id, &ts0 );
ts1 = ts0;
ts0.tv_sec += 2;
while ( ts1.tv_sec < ts0.tv_sec || ts1.tv_sec == ts0.tv_sec && ts1.tv_nsec < ts0.tv_nsec ) {
clock_gettime( clock_id, &ts1 );
}

if ( timer_settime( timer, 0, &zero, NULL ) != 0 ) {
fprintf( stderr, "Failed to stop %s timer: %s\n", name, strerror( errno ) );
}
if ( timer_delete( timer ) != 0 ) {
fprintf( stderr, "Failed to delete %s timer: %s\n", name, strerror( errno ) );
}
printf( "Done testing %s\n", name );
}

int main( void ) {
test( "CLOCK_MONOTONIC", CLOCK_MONOTONIC );
test( "CLOCK_PROCESS_CPUTIME_ID", CLOCK_PROCESS_CPUTIME_ID );
test( "CLOCK_THREAD_CPUTIME_ID", CLOCK_THREAD_CPUTIME_ID );
return 0;
}

Bug#918751: python-shade: BSP tag

[Stewart Ferguson]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2019-01-nl-venlo
thank you


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

Bug#917055: blktool: diff for NMU version 4-7.1

[Adrian Bunk]

Control: tags 917055 + pending

Dear maintainer,

I've prepared an NMU for blktool (versioned as 4-7.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru blktool-4/debian/changelog blktool-4/debian/changelog
--- blktool-4/debian/changelog	2015-07-08 02:13:29.0 +0300
+++ blktool-4/debian/changelog	2019-01-11 20:35:44.0 +0200
@@ -1,3 +1,12 @@
+blktool (4-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with glibc 2.28. (Closes: #917055)
+  * Package description improvement from Aputsiaq Janussen.
+(Closes: #636500)
+
+ -- Adrian Bunk   Fri, 11 Jan 2019 20:35:44 +0200
+
 blktool (4-7) unstable; urgency=low
 
   * New maintainer. (Closes: #695127).
diff -Nru blktool-4/debian/control blktool-4/debian/control
--- blktool-4/debian/control	2015-07-08 01:17:17.0 +0300
+++ blktool-4/debian/control	2019-01-11 20:35:44.0 +0200
@@ -16,5 +16,5 @@
  device.  It is like hdparm but a more general tool, as it works on
  SCSI, IDE and SATA devices.
  .
- This program is for those who know what they're doing and should be
- used it at your own risk as it could cause damage to your hardware.
+ This program is for those who know what they're doing and it should
+ be used at your own risk as it could cause damage to your hardware.
diff -Nru blktool-4/debian/patches/0004-fix-ftbfs-glibc-2.28.patch blktool-4/debian/patches/0004-fix-ftbfs-glibc-2.28.patch
--- blktool-4/debian/patches/0004-fix-ftbfs-glibc-2.28.patch	1970-01-01 02:00:00.0 +0200
+++ blktool-4/debian/patches/0004-fix-ftbfs-glibc-2.28.patch	2019-01-11 20:35:38.0 +0200
@@ -0,0 +1,14 @@
+Description: Fix FTBFS with glibc 2.28
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/917055
+
+--- blktool-4.orig/blktool.c
 blktool-4/blktool.c
+@@ -18,6 +18,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru blktool-4/debian/patches/series blktool-4/debian/patches/series
--- blktool-4/debian/patches/series	2015-06-13 01:05:10.0 +0300
+++ blktool-4/debian/patches/series	2019-01-11 20:35:44.0 +0200
@@ -1,3 +1,4 @@
 0001-fix-typos-in-manpage.patch
 0002-fix-string-error.patch
 0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
+0004-fix-ftbfs-glibc-2.28.patch

Bug#918671: python-shade: BSP tag

[Stewart Ferguson]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2019-01-nl-venlo
thank you


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

Bug#918996: steam: does not start due to missing libGL.so.1

[Simon McVittie]

On Fri, 11 Jan 2019 at 14:55:00 +, George B. wrote:
> I installed steam package (on amd64) and it automatically brought in a
> bunch of i386 libs, but [not] enough as the app did not start due to missing
> libGL.so.1 library file.

Which Nvidia proprietary driver packages did you have installed?
(You can use "dpkg-query -W | grep -E 'libgl1|nvidia'" to get a list of
relevant packages, and then use /var/log/apt/history.log to see which
ones you only installed while solving this)

What is the exact error message you got?

> I had to manually install libgl1-nvidia-glvnd-glx:386 to get it to work
> (the amd64 version of the package was already installed).

The problem we have here is:

If we don't add a dependency on Nvidia proprietary drivers, then people
in your situation will sometimes end up with only the amd64 Nvidia driver
installed, but not the i386 Nvidia driver. You do have *an* i386 OpenGL
implementation (the i386 OpenGL implementation from Mesa is in steam's
dependencies), but it's the wrong one for your hardware (and installing
the amd64 version of the Nvidia proprietary driver disables the Mesa
drivers), so it won't work.

However, if we add a dependency on Nvidia proprietary drivers, then people
whose hardware doesn't actually use those drivers will accidentally
install them when they install Steam. Apart from the Nvidia driver
being proprietary code some of which runs as root, the mechanisms used
to choose between the Nvidia and Mesa drivers are quite elaborate, so
we shouldn't apply the extra complexity of those mechanisms to systems
that don't have the hardware that would benefit from them.

I feel as though a dependency on an Nvidia driver by steam is the wrong
dependency: there's nothing special about Steam that makes it require
Nvidia drivers, it just needs *some* working OpenGL driver. Unfortunately,
there's no way to write "if you have glx-alternative-nvidia then you
must also have nvidia-driver-libs:i386" as a dependency.

I think part of the problem might be that if you installed the Nvidia
driver before you enabled the i386 foreign architecture, then the
nvidia-driver-libs Recommends on nvidia-driver-libs-i386 is unsatisfiable
at the time that you installed nvidia-driver-libs, and apt leaves that
Recommends broken even after you add the i386 foreign architecture and
nvidia-driver-libs-i386 becomes available.

Perhaps the least bad solution would be for Debian's /usr/games/steam
wrapper script to detect the broken situation (amd64 Nvidia driver, but
no i386 Nvidia driver) and try to use PackageKit to fix it...

smcv

Bug#919018: out-of-the-box monodoc-http fails to show documentation

[Daniel Llewellyn]

Package: monodoc-http
Version: 4.2-2
Tags: stretch, buster

This bug affects at least stretch and buster. I've not tested sid yet.

Quoting from my similar bug in Ubuntu's Launchpad Issue Tracker 
(https://bugs.launchpad.net/ubuntu/+source/mono-tools/+bug/1811444):


The out-of-the-box configuration for monodoc-http does not find any 
documentation. It is configured to look for documentation at 
/mono/lib/monodoc-ios/ and reports an HTTP 500 error when trying to 
navigate to http://localhost:8084/monodoc.



System.ArgumentException
basedir
Parameter name: Base documentation directory at '/mono/lib/monodoc-ios/' 
doesn't exist

Description: HTTP 500.Error processing request.

Details: Non-web exception. Exception origin (name of application or 
object): monodoc.


Exception stack trace:
  at Monodoc.RootTree.LoadTree (System.String basedir, System.Boolean 
includeExternal) [0x00031] in <496c0b0510da4601a8fa1704154167ef>:0
  at Mono.Website.Global.Application_Start () [0x0002d] in 
:0
  at (wrapper managed-to-native) 
System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, 
System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder 
binder, System.Object[] parameters, System.Globalization.CultureInfo 
culture) [0x00038] in <8f2c484307284b51944a1a13a14c0266>:0



Should the documentation path be changed? what to? Should we change 
monodoc-http to ensure it depends upon an appropriate documentation 
package to provide the path that the server is configured to serve? Or 
should we do both?

Bug#917085: pyzo: diff for NMU version 4.4.3-1.2

[Adrian Bunk]

Control: tags 917085 + patch
Control: tags 917085 + pending

Dear maintainer,

I've prepared an NMU for pyzo (versioned as 4.4.3-1.2) and uploaded
it to DELAYED/10. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru pyzo-4.4.3/debian/changelog pyzo-4.4.3/debian/changelog
--- pyzo-4.4.3/debian/changelog	2018-11-30 17:17:18.0 +0200
+++ pyzo-4.4.3/debian/changelog	2019-01-11 20:09:52.0 +0200
@@ -1,3 +1,11 @@
+pyzo (4.4.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on python3-pkg-resources,
+thanks to Julien Cervelle. (Closes: #917085)
+
+ -- Adrian Bunk   Fri, 11 Jan 2019 20:09:52 +0200
+
 pyzo (4.4.3-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru pyzo-4.4.3/debian/control pyzo-4.4.3/debian/control
--- pyzo-4.4.3/debian/control	2017-10-09 21:59:11.0 +0300
+++ pyzo-4.4.3/debian/control	2019-01-11 20:09:52.0 +0200
@@ -21,7 +21,8 @@
 Architecture: all
 Depends: ${misc:Depends},
  ${python3:Depends},
- python3-qtpy
+ python3-qtpy,
+ python3-pkg-resources
 Suggests: pyzo-doc
 Description: interactive editor for scientific Python
  Pyzo is a cross-platform Python IDE focused on interactivity and introspection,

Bug#915689: prevent from migrating to testing

[Andreas Henriksson]

Hello Aron Xu and everyone else,

On Thu, Dec 06, 2018 at 01:25:03PM +0800, Aron Xu wrote:
> Package: rng-tools
> Version: 5-1
> Severity: serious
> Tags: sid
> 
> We need to prevent this version of rng-tools from migrating to testing
> before finding a solution of coordinating with the rng-tools5 package.

I'm interested in rng-tools and would like to see it in good shape
for buster, but the current state makes me uncomfortable.

Could you please update me on what the current state is since this
bug report was opened? Have any progress been made or attempted
that isn't tracked here?

The initial changelog entry of rng-tools5 states:
"This is part of an intended transition, with this package becoming the
default rng-tools post stretch release."

That has apparently failed to materialize well in time for buster.
Looking at the contents of the binary packages it seems rng-tools
(in unstable) has more contents and likely provides more
functionality/integration (but I haven't looked into details, eg.
rng-tools5 has no /etc/default file which might be a good thing as those
are generally frowed upon in the current systemd service age, but has
there been any work on actual migration of current rng-tools users
configuration to what rng-tools5 uses?)

I'd be really interested to hear what people have on their minds for
this task and how I can help out.

Regards,
Andreas Henriksson

Bug#874880: [freemedforms-project] Future Qt4 removal from Buster

[Andreas Tille]

Hi Eric,

I realised that you registered a login on Salsa and added you to the
Debian Med team.  So you have access to

https://salsa.debian.org/med-team/freemedforms-project

I'd strongly recommend to do this soonish since we are approaching
the freeze.

Thanks a lot for your contribution

   Andreas.

On Thu, Sep 27, 2018 at 04:52:14PM +0200, Andreas Tille wrote:
> On Thu, Sep 27, 2018 at 03:28:48PM +0200, Eric Maeker wrote:
> > Howard Can i read build errors on salsa.d.o ?
> 
> You can not.  You can clone the repository and try to build the package.
>  
> Did you registered on Salsa?  It is not needed for annonymous cloning but
> if you want to maintain the package in the future it is necessary.
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#919017: mixmaster: Default updater is broken, update is insecure

[Christoph Biedl]

Package: mixmaster
Version: 3.0.0-8.1
Severity: important

Dear Maintainer,

while I understand mixmaster no longer exists in unstable/testing,
there are issues in stable and oldstable that require attention:

* noreply.org is gone

The shipped value "SOURCE noreply" in /etc/mixmaster/update.conf causes
error messages from /etc/cron.daily/mixmaster since noreply.org no
longer exists and will not come back - and also was last updated in
September 2018.

Suggested solution: Change to an operational service, "austria" works
for me.

* Updates are in the plain

These updates are done in plaintext http, and no, they are no cryptographic
signatures that could provide integrity.

Suggested solution: Check for services that provide the data using
https as well, and update /etc/mixmaster/allpingers.txt accordingly.
Again, "austria" (i.e. www.tahina.priv.at) supports this.


Both issues should be fixed in the still supported versions, via a
point release in stretch, and by an upload to LTS for jessie. Since as
of now, the anonymity mixmaster should provide might no longer be
granted.

Christoph

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

Kernel: Linux 4.19.13 (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: unable to detect

Versions of packages mixmaster depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libmailtools-perl  2.18-1
ii  libncurses56.0+20161126-1+deb9u2
ii  libpcre3   2:8.39-3
ii  libssl1.0.21.0.2q-1~deb9u1
ii  libtinfo5  6.0+20161126-1+deb9u2
ii  libwww-perl6.15-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages mixmaster recommends:
pn  postfix | mail-transport-agent  

Versions of packages mixmaster suggests:
ii  mutt  1.7.2-1+deb9u1



signature.asc
Description: PGP signature