Bug#931971: python-xarray: autopkgtest failure block netcdf4-python migration

[Bas Couwenberg]

Source: python-xarray
Version: 0.11.3-2
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest failures for python-xarray are blocking the testing migration
of netcdf4-python.

Please fix the tests in your package or remove them.

Kind Regards,

Bas

Bug#931970: gphoto2: autopkgtest failure block readline migration

[Bas Couwenberg]

Source: gphoto2
Version: 2.5.20-3
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The autopkgtest failures for gphoto2 are blocking the testing migration
of readline and its reverse dependencies.

Please fix the tests in your package or remove them.

Kind Regards,

Bas

Bug#931910: Installation report with missing UEFI boot entry

[Cyril Brulebois]

Control: reassign -1 efibootmgr
Control: forcemerge -1 905319

Steve McIntyre  (2019-07-12):
> Control: reassign efibootmgr
> Control: forcemerge -1 905319
> […]
> Merging the bugs...

Fixing the merging. ;)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931969: grub2 fails to boot on sparc64 systems with GPT partitioning

[John Paul Adrian Glaubitz]

Source: grub2
Version: 2.04-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

For some reason I haven't tracked down yet, grub2 fails to boot on
sparc64 systems with GPT partitioning with:

{0} ok boot
Boot device: disk  File and args: 
WARNING: Unsupported bootblk image, can not extract fcode

WARNING: Bootblk fcode extraction failed
GRUB 
ERROR: Last Trap: Illegal Instruction

{0} ok

This problem does not show with Sun partitioning on sparc64, it does
not show when building grub2 from upstream git and it does not show
with the last 2.02 package from Debian.

I will try to track this issue the following days but I suspect that one of
the Debian-specific patches is responsible for the problem. I will report
back to this bug report once I know more.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#931968: stretch-pu: package libtk-img/1:1.4.6+dfsg-1+deb9u1 pre-approval

[Sergei Golovan]

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

Hi release team,

I'd like to fix #931422 (see [1]) for stretch (the bug is already fixed
in unstable, see also #931967 [2]).

The diff with the current 1:1.4.6+dfsg-1 is attaced.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931422
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931967

-- System Information:
Debian Release: 10.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 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)
diff -Nru libtk-img-1.4.6+dfsg/debian/changelog 
libtk-img-1.4.6+dfsg/debian/changelog
--- libtk-img-1.4.6+dfsg/debian/changelog   2017-01-17 11:24:03.0 
+0300
+++ libtk-img-1.4.6+dfsg/debian/changelog   2019-07-12 17:28:05.0 
+0300
@@ -1,3 +1,10 @@
+libtk-img (1:1.4.6+dfsg-1+deb9u1) stretch; urgency=medium
+
+  * Switch from the internal copies of Jpeg, Zlib and PixarLog codecs to the
+libtiff ones (closes: #931422).
+
+ -- Sergei Golovan   Fri, 12 Jul 2019 17:28:05 +0300
+
 libtk-img (1:1.4.6+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff 
libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff
--- libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff2016-04-06 
23:11:12.0 +0300
+++ libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff2019-07-12 
17:28:05.0 +0300
@@ -327,6 +327,21 @@
TIFFTileRowSize && TIFFScanlineSize && _TIFFsetByteArray &&
TIFFVSetField   && TIFFSwabArrayOfShort
) {
+@@ -125,14 +125,10 @@
+ if (Zlibtcl_InitStubs(interp, ZLIBTCL_VERSION, 0) == NULL) {
+   return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_DEFLATE,  "Deflate",  
TkimgTIFFInitZip);
+-TIFFRegisterCODEC (COMPRESSION_ADOBE_DEFLATE, "AdobeDeflate", 
TkimgTIFFInitZip);
+ 
+ if (Jpegtcl_InitStubs(interp, JPEGTCL_VERSION, 0) == NULL) {
+   return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_JPEG, "JPEG", 
TkimgTIFFInitJpeg);
+-TIFFRegisterCODEC (COMPRESSION_PIXARLOG, "PixarLog", 
TkimgTIFFInitPixar);
+   }
+ }
+ return TCL_OK;
 --- a/tiff/tiffJpeg.c
 +++ b/tiff/tiffJpeg.c
 @@ -1599,7 +1599,7 @@
@@ -360,3 +375,25 @@
  sp->vgetparent = tif->tif_tagmethods.vgetfield;
  tif->tif_tagmethods.vgetfield = ZIPVGetField; /* hook for codec tags 
*/
  sp->vsetparent = tif->tif_tagmethods.vsetfield;
+--- a/tiff/configure
 b/tiff/configure
+@@ -8244,7 +8244,7 @@
+ #---
+ 
+ 
+-vars="tiff.c tiffJpeg.c tiffZip.c tiffPixar.c"
++vars="tiff.c"
+ for i in $vars; do
+   case $i in
+   \$*)
+--- a/tiff/configure.in
 b/tiff/configure.in
+@@ -75,7 +75,7 @@
+ # and PKG_TCL_SOURCES.
+ #---
+ 
+-TEA_ADD_SOURCES([tiff.c tiffJpeg.c tiffZip.c tiffPixar.c])
++TEA_ADD_SOURCES([tiff.c])
+ TEA_ADD_HEADERS([])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${srcdir}`\"])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${tkimg_SRC_PATH}`\"])

Bug#931781: rsync: Buster hangs when rsyncing large (400M) files over ssh. Same hardware works OK with Stretch

[hfvk]

Antti kirjoitti 10.7.2019 13:45:

Package: rsync
Version: 3.1.3-6
Severity: critical
Justification: breaks unrelated software



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

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

Versions of packages rsync depends on:
ii  base-files   10.3
ii  init-system-helpers  1.56+nmu1
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libpopt0 1.16-12
ii  lsb-base 10.2019051400

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.9p1-10
ii  openssh-server  1:7.9p1-10

-- no debconf information

I am rsyncing files with the following command:
/usr/bin/rsync --progress -avzse ssh 'user@host:/path/a/' '/path/b/'

I have succesfully run this command on Debian Stretch before the 
upgrade.


I updated to Debian Buster and now the system hangs when syncing large
(400M) files using the above command. I have tried also a clean Buster
installation but the problem persists.

Initially I suspected this a hardware issue but I tested the disks
with DD (on Buster) and even heavy load did not cause any issues.

This problem seems to be related to rsync and large files. Rsync with
small files works OK.

Disabling AppArmor on Buster does not help.

Symptoms:
Aftert issuing the command, the rsync starts OK. Even large files are
transferring OK at this point.
After a while, the CPU load on the system goes to 100 % and the system
becomes unresponsive.

I am running the system on VMWare ESXi 6.7 U2 host and the system is
using Broadcom 9440-8i RAID controller.

If I switch from Buster to Stretch, everything works OK.

Typically nothing can be seen in the dmesg but once I was able to
capture the following:

Jul 10 07:27:00 nasunas kernel: BUG: unable to handle kernel paging
request at 00f0416baec0
Jul 10 07:27:00 nasunas kernel: PGD 0 P4D 0
Jul 10 07:27:00 nasunas kernel: Oops:  [#1] SMP PTI
Jul 10 07:27:00 nasunas kernel: CPU: 0 PID: 1053 Comm: rsync Not
tainted 4.19.0-5-amd64 #1 Debian 4.19.37-5
Jul 10 07:27:00 nasunas kernel: Hardware name: VMware, Inc. VMware
Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00
12/12/2018
Jul 10 07:27:00 nasunas kernel: RIP: 0010:__radix_tree_lookup+0x4b/0xe0
Jul 10 07:27:00 nasunas kernel: Code: 48 83 e0 fe 0f b6 08 48 89 d8 48
d3 e0 48 83 e8 01 48 39 c6 0f 87 9e 00 00 00 49 83 f8 01 74 c9 4d 89
c1 48 89 f0 49 83 e1 fe $
Jul 10 07:27:00 nasunas kernel: RSP: 0018:9cba41893c28 EFLAGS: 
00010206

Jul 10 07:27:00 nasunas kernel: RAX: b580 RBX:
0040 RCX: 
Jul 10 07:27:00 nasunas kernel: RDX:  RSI:
b580 RDI: 88b8ef932420
Jul 10 07:27:00 nasunas kernel: RBP: 9cba41893c40 R08:
00f0416baec1 R09: 00f0416baec0
Jul 10 07:27:00 nasunas kernel: R10: 88b844d82dd8 R11:
0001 R12: 006200ca
Jul 10 07:27:00 nasunas kernel: R13: 88b8ef932418 R14:
b580 R15: b8675de0
Jul 10 07:27:00 nasunas kernel: FS:  7fa4bf1d4b80()
GS:88b8fba0() knlGS:
Jul 10 07:27:00 nasunas kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jul 10 07:27:00 nasunas kernel: CR2: 00f0416baec0 CR3:
00012ed28005 CR4: 003606f0
Jul 10 07:27:00 nasunas kernel: DR0:  DR1:
 DR2: 
Jul 10 07:27:00 nasunas kernel: DR3:  DR6:
fffe0ff0 DR7: 0400
Jul 10 07:27:00 nasunas kernel: Call Trace:
Jul 10 07:27:00 nasunas kernel:  radix_tree_lookup_slot+0x1e/0x50
Jul 10 07:27:00 nasunas kernel:  find_get_entry+0x19/0xf0
Jul 10 07:27:00 nasunas kernel:  pagecache_get_page+0x30/0x2c0
Jul 10 07:27:00 nasunas kernel:  ? jbd2_journal_stop+0xef/0x3c0 [jbd2]
Jul 10 07:27:00 nasunas kernel:  grab_cache_page_write_begin+0x1f/0x40
Jul 10 07:27:00 nasunas kernel:  ext4_da_write_begin+0xce/0x470 [ext4]
Jul 10 07:27:00 nasunas kernel:  generic_perform_write+0xf4/0x1b0
Jul 10 07:27:00 nasunas kernel:  ? file_update_time+0xed/0x130
Jul 10 07:27:00 nasunas kernel:  __generic_file_write_iter+0xfe/0x1c0
Jul 10 07:27:00 nasunas kernel:  ext4_file_write_iter+0xc6/0x400 [ext4]
Jul 10 07:27:00 nasunas kernel:  new_sync_write+0xfb/0x160
Jul 10 07:27:00 nasunas kernel:  vfs_write+0xa5/0x1a0
Jul 10 07:27:00 nasunas kernel:  ksys_write+0x4f/0xb0
Jul 10 07:27:00 nasunas kernel:  do_syscall_64+0x53/0x110
Jul 10 07:27:00 nasunas kernel:  
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Jul 10 07:27:00 nasunas kernel: RIP: 0033:0x7fa4bf2c0504
Jul 10 07:27:00 nasunas kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff
ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75
13 b8 01 00 00 00 0f 05 

Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval

[Sergei Golovan]

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

Hi release team,

I'd like to fix #931422 (see [1]) for buster (the bug is already fixed
in unstable and prospectively in testing).

The diff with the current 1:1.4.8+dfsg-1 is attaced, it's fairly small.

Also, I'd like to ask if I should make a source-only or binary upload to
stable (and/or oldstable) now?

-- System Information:
Debian Release: 10.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 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)
diff -Nru libtk-img-1.4.8+dfsg/debian/changelog 
libtk-img-1.4.8+dfsg/debian/changelog
--- libtk-img-1.4.8+dfsg/debian/changelog   2019-02-07 14:11:34.0 
+0300
+++ libtk-img-1.4.8+dfsg/debian/changelog   2019-07-12 16:35:27.0 
+0300
@@ -1,3 +1,10 @@
+libtk-img (1:1.4.8+dfsg-1+deb10u1) buster; urgency=medium
+
+  * Switch from the internal copies of Jpeg, Zlib and PixarLog codecs to the
+libtiff ones (closes: #931422).
+
+ -- Sergei Golovan   Fri, 12 Jul 2019 16:35:27 +0300
+
 libtk-img (1:1.4.8+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff 
libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff
--- libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff2019-02-07 
14:11:34.0 +0300
+++ libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff2019-07-12 
16:35:27.0 +0300
@@ -327,6 +327,21 @@
TIFFTileRowSize && TIFFScanlineSize && _TIFFsetByteArray &&
TIFFVSetField   && TIFFSwabArrayOfShort
) {
+@@ -125,14 +125,10 @@
+ if (Zlibtcl_InitStubs(interp, ZLIBTCL_VERSION, 0) == NULL) {
+   return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_DEFLATE,  "Deflate",  
TkimgTIFFInitZip);
+-TIFFRegisterCODEC (COMPRESSION_ADOBE_DEFLATE, "AdobeDeflate", 
TkimgTIFFInitZip);
+ 
+ if (Jpegtcl_InitStubs(interp, JPEGTCL_VERSION, 0) == NULL) {
+   return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_JPEG, "JPEG", 
TkimgTIFFInitJpeg);
+-TIFFRegisterCODEC (COMPRESSION_PIXARLOG, "PixarLog", 
TkimgTIFFInitPixar);
+   }
+ }
+ return TCL_OK;
 --- a/tiff/tiffJpeg.c
 +++ b/tiff/tiffJpeg.c
 @@ -1599,7 +1599,7 @@
@@ -360,3 +375,25 @@
  sp->vgetparent = tif->tif_tagmethods.vgetfield;
  tif->tif_tagmethods.vgetfield = ZIPVGetField; /* hook for codec tags 
*/
  sp->vsetparent = tif->tif_tagmethods.vsetfield;
+--- a/tiff/configure
 b/tiff/configure
+@@ -6719,7 +6719,7 @@
+ #---
+ 
+ 
+-vars="tiff.c tiffJpeg.c tiffZip.c tiffPixar.c"
++vars="tiff.c"
+ for i in $vars; do
+   case $i in
+   \$*)
+--- a/tiff/configure.in
 b/tiff/configure.in
+@@ -75,7 +75,7 @@
+ # and PKG_TCL_SOURCES.
+ #---
+ 
+-TEA_ADD_SOURCES([tiff.c tiffJpeg.c tiffZip.c tiffPixar.c])
++TEA_ADD_SOURCES([tiff.c])
+ TEA_ADD_HEADERS([])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${srcdir}`\"])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${tkimg_SRC_PATH}`\"])

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Adler, Mark]

Ben,

Ah, no, I did not test the jar files. I just did, and indeed I am seeing the 
reported zip bomb detections.

Thanks. I’ll look into it.

Mark


> On Jul 12, 2019, at 3:22 PM, Ben Caradoc-Davies  wrote:
> 
> On 13/07/2019 04:32, Adler, Mark wrote:
>> I downloaded the four false-positive zip files from the bugreport page, and 
>> none of them showed a zip bomb error (or any other error).
> 
> Mark,
> 
> the zip bomb error is seen when unzipping the 17 jar files contained within 
> the four zip files. Did you test these inner jar files? I used (in bash):
> 
> $ for f in *.jar; do echo $f; unzip -tq $f; done
> 
> The outer zip files are there because many email filters block all email with 
> jar attachments, and Debian BTS is email-based.
> 
> It would also be nice if unzip reported the filename when rejecting a 
> suspected zip bomb, as it does when reporting "No errors detected".
> 
> Kind regards,
> 
> -- 
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand

Bug#931710: [pkg-cryptsetup-devel] Bug#931710: Cryptroot-unlock Timeout on askpass

[Guilhem Moulin]

Hi,

On Wed, 10 Jul 2019 at 09:24:16 +, Luke Flinders wrote:
> So have done some more testing and it seems that the removal of
> cryptsetup-nuke-password resolves the issue.

What is that?  There is no such package in Debian.

> I had however tested this before and had it all functioning.
> Hopefully this helps direct debugging a little better.

For what it's worth, since I wrote it I'm using `cryptroot-unlock`
on a regular basis with src:cryptsetup from Stretch and Buster (and
sid), and I never saw the issue you encounter.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#931966: virt-what: Docker detection is broken

[brian m. carlson]

Package: virt-what
Version: 1.19-1
Severity: normal

When running virt-what inside a Docker container, no output is produced.
This is because virt-what uses the presence of /.dockerinit, which is no
longer used when running inside a Docker container.

It's probably best to do something like "grep docker /proc/1/cgroup"
instead.

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

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

Versions of packages virt-what depends on:
ii  dmidecode  3.2-2
ii  libc6  2.28-10

virt-what recommends no packages.

virt-what suggests no packages.

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#931965: squashfs-tools-ng: new package is available

[Steven Shiau]

Package: squashfs-tools-ng
Version: 0.4
Severity: wishlist

Dear Maintainer,

The package squashfs-tools has not been developed and
maintained by its upstream for more than 5 years.
However, a newer package "squashfs-tools-ng" is available:
https://sourceforge.net/p/squashfs/mailman/message/36709721/
This squashfs-like package is required for Debian live and its derivatives.
It would be great if squashfs-tools-ng can be available in the Debian
repository.
My 2 cents.

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

Kernel: Linux 4.18.0-0.bpo.3-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal

[Paul Wise]

On Sat, Jul 13, 2019 at 1:21 AM Joe Lobeck wrote:

> in the meantime I found that the most things work form kernel 5.0 or higher.
> Unfortunately so I will have to choose an other linux distribution as such a 
> kernel
> is for debian only from the experimantal repository avaiable.
> If you have any other idea how to make debian stable or testing run with this
> hardware please let me know.

There are several options, you could do them in parallel:

You could install the experimental Linux image package on stable.

At some point a newer version of Linux will enter unstable, then
testing and then stable-backports, you could switch to testing or use
stable+backports.

You could bisect the Linux kernel commits to find out which exact
commit fixed the problem, work on getting the patch backported to the
upstream -stable versions of the Linux kernel and then wait for a
Debian point release to include the latest -stable version of the
Linux kernel.

https://wiki.debian.org/DebianKernel/GitBisect
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#916776: ITS: python-pyocr

[Chris Lamb]

Hi Thomas,

> According to the ITS process, I will wait for any objections during 21
> days before uploading a new package into the DELAYED queue.

I think you've reached this 21 days. Fancy fixing #886306 on your
first upload? :)


Regards,

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

Bug#931962: diffoscope: Doesn't behave nicely in the face of NOBITS eh_frame

[Chris Lamb]

Hi Mike,

> The two attached files are […]

Did you, perhance, forget to attach these? :)


Best wishes,

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

Bug#931962: diffoscope: Doesn't behave nicely in the face of NOBITS eh_frame

[Mike Hommey]

On Sat, Jul 13, 2019 at 09:50:55AM +0900, Mike Hommey wrote:
> Package: diffoscope
> Version: 117
> Severity: important
> 
> Dear Maintainer,
> 
> When comparing Debian debug packages, diffoscope ends up showing hexdump
> diffs, when it could, in fact, output much nicer diffs.
> 
> The two attached files are a small .debug file from two
> jenkins.debian.net firefox debug package builds, that differ because of
> missing -fdebug-prefix-map flags.

As usual when someone says "attached files"... I forgot to attach the
files...

Here they are.

Mike


41aa9e49143d7d5d4fb5e05623976b644573b2.debug
Description: Binary data


b70f29bd619ba23d3879579b19209fda75ea3b.debug
Description: Binary data

Bug#931962: diffoscope: Falls back to raw hexdump with "NOBITS eh_frame" in ELF binaries

[Chris Lamb]

forwarded 931962 
https://salsa.debian.org/reproducible-builds/diffoscope/issues/58
thanks

I've "forwarded this upstream" here:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/58


Regards,

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

Bug#931964: Add sid to Vagrant Cloud boxes

[Andrew Pennebaker]

Package: cloud.debian.org
Version: *

Hey, neat that we have convenient VM's now for Debian! Could we get a VM
for sid as well?

-- 
Cheers,
Andrew

Bug#931963: diffoscope: Please include stderr from readelf in output

[Chris Lamb]

forwarded 931963 
https://salsa.debian.org/reproducible-builds/diffoscope/issues/59
thanks

I've "forwarded this upstream" here:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/59


Regards,

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

Bug#931962: diffoscope: Falls back to raw hexdump with "NOBITS eh_frame" in ELF binaries (was: "Re: diffoscope: Doesn't behave nicely in the face of NOBITS eh_frame")

[Chris Lamb]

clone 931962 -1 
reassign -1 diffoscope
retitle -1 diffoscope: Please include stderr from readelf in output
severity -1 normal
retitle 931962 diffoscope: Falls back to raw hexdump with "NOBITS eh_frame" in 
ELF binaries
thanks

Hi Mike,

Thank you for filing this. Just as a bit of bug triage, I'm going to
split this in two:

> First, there's the problem that diffoscope only displays readelf's
> stdout, and its stderr is lost, which it contains the most important
> information:
>   section '.eh_frame' has the NOBITS type - its contents are unreliable.

(This will be bug -1, keeping the rest as #931962.)


Best wishes,

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

Bug#931962: diffoscope: Doesn't behave nicely in the face of NOBITS eh_frame

[Mike Hommey]

Package: diffoscope
Version: 117
Severity: important

Dear Maintainer,

When comparing Debian debug packages, diffoscope ends up showing hexdump
diffs, when it could, in fact, output much nicer diffs.

The two attached files are a small .debug file from two
jenkins.debian.net firefox debug package builds, that differ because of
missing -fdebug-prefix-map flags.

When comparing them, the output looks like:
--- /tmp/41aa9e49143d7d5d4fb5e05623976b644573b2.debug
+++ /tmp/b70f29bd619ba23d3879579b19209fda75ea3b.debug
│┄ Command `readelf --wide --debug-dump=frames 
/tmp/41aa9e49143d7d5d4fb5e05623976b644573b2.debug` exited with 1.
Output:
│┄ 
@@ -30,161 +30,161 @@
 01d0:          
 01e0:          
 01f0:     1000     
 0200: 52e5 7464 0400  d00d     R.td
 0210: d03d    d03d     .=...=..
 0220:     3002     0...
 0230: 0100    0400  1400   
-0240: 0300  474e 5500 3341 aa9e 4914 3d7d  GNU.3A..I.=}
-0250: 5d4f b5e0 5623 976b 6445 73b2 4743 433a  ]O..V#.kdEs.GCC:
+0240: 0300  474e 5500 a8b7 0f29 bd61 9ba2  GNU).a..
+0250: 3d38 7957 9b19 209f da75 ea3b 4743 433a  =8yW.. ..u.;GCC:
 0260: 2028 4465 6269 616e 2038 2e33 2e30 2d31   (Debian 8.3.0-1
 0270: 3929 2038 2e33 2e30 0001     9) 8.3.0
 0280: 00f0    0001     
 0290: 0078 9c7b c3c0 c0c0 c400 021c 6032 4000  .x.{`2@.
 02a0: 4c31 0842 2886 4434 7e11 1abf 198d 3f05  L1.B(.D4~.?.
etc.

First, there's the problem that diffoscope only displays readelf's
stdout, and its stderr is lost, which it contains the most important
information:
  section '.eh_frame' has the NOBITS type - its contents are unreliable.

Second, this skips everything else that diffoscope would normally do,
instead of falling back to a hexdump diff of the concerned section only.

With a readelf wrapper that always exits 0, this is what the output
looks like:
--- /tmp/41aa9e49143d7d5d4fb5e05623976b644573b2.debug
+++ /tmp/b70f29bd619ba23d3879579b19209fda75ea3b.debug
├ readelf --wide --sections {}
│ @@ -23,19 +23,19 @@
│[18] .dynamic  NOBITS  3de0 000dd0 000200 10  
WA  4   0  8
│[19] .got  NOBITS  3fe0 000dd0 20 08  
WA  0   0  8
│[20] .got.plt  NOBITS  4000 000dd0 20 08  
WA  0   0  8
│[21] .data NOBITS  4020 000dd0 08 00  
WA  0   0  8
│[22] .bss  NOBITS  4028 000dd0 08 00  
WA  0   0  1
│[23] .comment  PROGBITS 00025c 1d 01  
MS  0   0  1
│[24] .debug_arangesPROGBITS 000279 5a 00   
C  0   0  1
│ -  [25] .debug_info   PROGBITS 0002d3 000330 00   
C  0   0  1
│ -  [26] .debug_abbrev PROGBITS 000603 da 00   
C  0   0  1
│ -  [27] .debug_line   PROGBITS 0006dd 000176 00   
C  0   0  1
│ -  [28] .debug_strPROGBITS 000853 0002c3 01 
MSC  0   0  1
│ -  [29] .debug_ranges PROGBITS 000b16 4e 00   
C  0   0  1
│ +  [25] .debug_info   PROGBITS 0002d3 00032e 00   
C  0   0  1
│ +  [26] .debug_abbrev PROGBITS 000601 da 00   
C  0   0  1
│ +  [27] .debug_line   PROGBITS 0006db 000176 00   
C  0   0  1
│ +  [28] .debug_strPROGBITS 000851 0002c4 01 
MSC  0   0  1
│ +  [29] .debug_ranges PROGBITS 000b15 4e 00   
C  0   0  1
│[30] .symtab   SYMTAB   000b68 000690 18   
  31  49  8
│[31] .strtab   STRTAB   0011f8 0002ca 00   
   0   0  1
│[32] .shstrtab STRTAB   0014c2 000137 00   
   0   0  1
│  Key to Flags:
│W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
│L (link order), O (extra OS processing required), G (group), T (TLS),
│C (compressed), x (unknown), o (OS specific), E (exclude),
├ readelf --wide --notes {}
│ @@ -1,4 +1,4 @@
│
│  Displaying notes found in: .note.gnu.build-id
│Owner Data sizeDescription
│ -  GNU  0x0014NT_GNU_BUILD_ID (unique build ID 
bitstring) Build ID: 3341aa9e9143d7d5d4fb5e05623976b644573b2
│ +  GNU  0x0014NT_GNU_BUILD_ID (unique build ID 
bitstring) Build ID: a8b70f29d619ba23d3879579b19209fda75ea3b
├ readelf --wide --debug-dump=rawline {}
│ @@ -21,19 +21,19 @@
│Opcode 8 has 0 args
│  

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[Finn Thain]

On Fri, 12 Jul 2019, user...@yahoo.com wrote:

> > Please see attached "all.tar.xz", which contains the following files:
> > 
> > "x11perf -all" tests:
> > 
> > 1) x11perf_8_fbdev.txt: Debian 8.11, mach64 removed
> > 2) x11perf_8_mach64.txt   : Debian 8.11, mach64 installed
> > 3) x11perf_sid_fbdev.txt  : Debian sid, mach64 removed
> > 4) x11perf_sid_mach64.txt : Debian sid, mach64 installed
> > 5) x11perfcomp.txt: comparison of the above four tests
> > 
> > "/var/log/Xorg.0.log" files:
> > 
> > 6) Xorg_8_fbdev.log  : Xorg log file for test (1)
> > 7) Xorg_8_mach64.log : Xorg log file for test (2)
> > 8) Xorg_sid_fbdev.log: Xorg log file for test (3)
> > 9) Xorg_sid_mach64.log   : Xorg log file for test (4)
> > 
> > "glxgears" (from mesa-utils) tests:
> > 
> > 10) glxgears.txt
> > ...
> 
> I added two tests.  Please see the attached "update.tar.xz", which
> contains the following six files:
> 
> "x11perf -all" tests:
> 
> 11) x11perf_sid_fbdev-1.txt  : Debian sid, mach64 removed, multiuser
> 12) x11perf_sid_mach64-1.txt : Debian sid, mach64 installed, multiuser
> 13) x11perfcomp_sid.txt  : comparison of 3), 4), 11) and 12)
> 
> "/var/log/Xorg.0.log" files:
> 
> 14) Xorg_sid_fbdev-1.log : Xorg log file for 11)
> 15) Xorg_sid_mach64-1.log: Xorg log file for 12)
> 
> serial console log:
> 
> 16) console_log.txt  : console log file for 11) and 12)
> 

Stan's x11perf benchmarks using fbdev show some serious regressions 
between xorg-server 2:1.16.4-1+deb8u2 and xorg-server 2:1.20.4-1.

The following test scores went backwards by more than 10 %.

34 % 500x500 tiled rectangle (216x208 tile)
30 % 100-pixel circle
28 % 500x500 tiled rectangle (161x145 tile)
26 % Circulate Unmapped window (200 kids)
26 % 500x500 tiled rectangle (17x15 tile)
25 % 100-pixel partial circle
25 % 100-pixel ellipse
25 % 100-pixel dashed circle
24 % Copy 500x500 from window to window
24 % 500x500 opaque stippled rectangle (17x15 stipple)
24 % 100-pixel wide ellipse
23 % Composite 500x500 from window to window
21 % 100x10 wide horizontal line segment
21 % 100-pixel horizontal line segment
20 % Char in 80-char aa line (Charter 10)
19 % Scroll 500x500 pixels
18 % Fill 100x100 equivalent triangle
17 % Char in 70-char line (8x13)
17 % 100-pixel fill chord partial ellipse
16 % 100-pixel dashed ellipse
15 % 100-pixel double-dashed ellipse
15 % 1-pixel solid circle
14 % 10-pixel vertical line segment
13 % PutImage XY 100x100 square
13 % Fill 300x300 tiled trapezoid (17x15 tile)
13 % Fill 100x100 equivalent complex polygons
12 % ShmGetImage XY 10x10 square
12 % Fill 100x100 trapezoid
12 % Char in 80-char rgb line (Charter 10)
12 % Char in 30-char line (TR 24)
12 % 100-pixel fill slice partial ellipse
11 % PutImage XY 500x500 square
11 % 500x500 rectangle
11 % 500x500 opaque stippled rectangle (161x145 stipple)
11 % 10x10 tiled rectangle (161x145 tile)
10 % Copy 500x500 1-bit deep plane
10 % Char in 30-char aa line (Charter 24)
10 % 500-pixel vertical line segment
10 % 10-pixel dashed segment

Those are the worst regressions. In total, 40% of x11perf measurements 
have regressed (though there's probably some measurement variation).

Michel, since this is fbdev not mach64, the bug you found cannot have 
caused this. Is this problem confined to powerpc or does it also appear in 
other Xorg regression tests?

-- 

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Benjamin Kaduk]

On Fri, Jul 05, 2019 at 07:25:26PM +0300, Martin-Éric Racine wrote:
> It is very much expected to be resolved.

Expected by whom?

> Please see:
> 
> https://manpages.debian.org/wheezy/dpkg/dpkg-maintscript-helper.1.en.html

I read most of this; it gives some general guidance that conffiles should
be removed from disk in the usual case, as well as details about good ways
to achieve that goal.
In this case, the maintainer of the package (Sam) has expressed a desire to
not remove the file.  Is there policy that overrides the maintainer's
discretion, here?

-Ben

Bug#931794:

[Mario.Limonciello]

Now that buster is out, I've just uploaded the latest released 1.2.9 to 
unstable.
Dell Corporation Limited is registered in England and Wales. Company 
Registration Number: 2081369
Registered address: Dell House, The Boulevard, Cain Road, Bracknell,  
Berkshire, RG12 1LF, UK.
Company details for other Dell UK entities can be found on  www.dell.co.uk.

Bug#931961: onboard not work

[Rodrigo Lima de Souto Leandro]

Package: onboard
Version: 1.4.1-4+b1
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
when I open the gnome terminal it opens and closes the onboard and standard
gnome keyboard, non-stop
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
open the terminal
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

Kernel: Linux 5.2.0-elm (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages onboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  iso-codes4.2-1
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcanberra0 0.30-7
ii  libdconf10.30.1-2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk-3-0   3.24.5-1
ii  libhunspell-1.7-01.7.0-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  librsvg2-common  2.44.10-2.1
ii  libstdc++6   8.3.0-6
ii  libudev1 241-5
ii  libx11-6 2:1.6.7-1
ii  libxi6   2:1.7.9-1
ii  libxkbfile1  1:1.0.9-2+b11
ii  libxtst6 2:1.2.3-1
ii  onboard-common   1.4.1-4
ii  python3  3.7.3-1
ii  python3-cairo1.16.2-1+b1
ii  python3-dbus 1.2.8-3
ii  python3-gi-cairo 3.30.4-1

Versions of packages onboard recommends:
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-ayatanaappindicator3-0.1  0.5.3-4
ii  onboard-data 1.4.1-4
ii  xdg-utils1.1.3-1

Versions of packages onboard suggests:
ii  mousetweaks  3.12.0-5

-- no debconf information

Bug#267357: closed by Hilmar Preuße (Re: Bug#267357: texinfo bugs fixed by upstream)

[積丹尼 Dan Jacobson]

>> Please consider testing your bug with the new version, and if you think
>> the bug is still present, do not hesitate to reopen the bug and/or
>> contact me.
>> 
B> No reaction from submitter for long time. Not even surely a bug in our
B> package.

B> Closing.

I probably saw "reopen" and thought you closed it already.

Bug#931960: RFS: jool/4.0.2-1 [ITP] -- IP/ICMP Translators

[Alberto Leiva Popper]

Package: sponsorship-requests
Severity: wishlist
Tags: ipv6

Dear mentors,

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

 * Package name: jool
   Version : 4.0.2-1
   Upstream Author : Jool Team 
 * URL : https://jool.mx
 * License : GPLv2
   Section : kernel

It builds those binary packages:

  jool-dkms - Kernel-based SIIT and NAT64 (IP/ICMP translation)
  jool-tools - Userspace utilities for the Jool kernel modules

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/j/jool/jool_4.0.2-1.dsc


Regards,
  Alberto Leiva Popper

Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid

[Cyril Brulebois]

Control: tag -1 patch pending

Hi,

Axel Beckert  (2018-10-22):
> haveged silently fails to start on one of my machines, seemingly due
> to apparmor. From /var/log/syslog after unsucessfully trying to start
> haveged:
> 
> Oct 22 15:40:26 someone haveged: haveged starting up
> Oct 22 15:40:26 someone kernel: [24678702.682596] audit: type=1400 
> audit(1540215626.982:65757): apparmor="DENIED" operation="mknod" 
> profile="/usr/sbin/haveged" name="/run/haveged.pid" pid=7421 comm="haveged" 
> requested_mask="c" denied_mask="c" fsuid=0 ouid=0
> 
> What helped was adding the line
> 
>   /run/haveged.pid w,
> 
> to /etc/apparmor.d/local/usr.sbin.haveged, so you should probably add
> that line to /etc/apparmor.d/usr.sbin.haveged.

Everyone: please deploy -8 (just uploaded) to your buster and/or
unstable systems and report back. I've tested this on a stretch system
that's running with systemd, using the daemon directly, or a hacked up
init script to make sure I was evading the initscript→systemd machinery
through LSB functions; and everything looks good with the patch.

But I'd be very happy to have success reports from sysvinit users before
considering backporting this to buster.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931959: fusiondirectory: unable to setup fusiondirectory on clean system

[Robert Middleton]

Package: fusiondirectory
Version: 1.2.3-4
Severity: normal

Dear Maintainer,

Installing fusiondirectory on a clean system does not install the proper PHP 
XML parser.

Steps to reproduce:
1. Install Debian 10 on a clean system
2. apt-get install fusiondirectory slapd apache2
3. Go to http://system-ip-addr/fusiondirectory and start the setup process
4. On the 'LDAP Setup' page, in the 'status' box, press 'retry' to try and 
connect to the LDAP server
5. PHP dies with an error, "Call to undefined function xml_parser_create"

I fixed it by doing the following manually:
apt-get install php7.3-xml
phpenmod xml
systemctl restart apache2


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

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

Versions of packages fusiondirectory depends on:
ii  apache2 [httpd] 2.4.38-3
ii  debconf [debconf-2.0]   1.5.71
ii  fusiondirectory-smarty3-acl-render  1.2.3-4
ii  gettext 0.19.8.1-9
ii  javascript-common   11
ii  libarchive-extract-perl 0.80-1
ii  libcrypt-cbc-perl   2.33-2
pn  libdigest-sha-perl  
ii  libfile-copy-recursive-perl 0.44-1
ii  libjs-prototype 1.7.1-3
ii  libjs-scriptaculous 1.9.0-2
ii  libnet-ldap-perl1:0.6500+dfsg-1
ii  libpath-class-perl  0.37-1
ii  libterm-readkey-perl2.38-1
ii  libxml-twig-perl1:3.50-1.1
ii  openssl 1.1.1c-1
ii  php 2:7.3+69
ii  php-cas 1.3.6-1
ii  php-curl2:7.3+69
ii  php-fpdf3:1.8.1.dfsg-2
ii  php-gd  2:7.3+69
ii  php-imagick 3.4.3-4.1
ii  php-imap2:7.3+69
ii  php-ldap2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-recode  2:7.3+69
ii  php7.3 [php]7.3.4-2
ii  php7.3-cli [php-cli]7.3.4-2
ii  php7.3-curl [php-curl]  7.3.4-2
ii  php7.3-gd [php-gd]  7.3.4-2
ii  php7.3-imap [php-imap]  7.3.4-2
ii  php7.3-ldap [php-ldap]  7.3.4-2
ii  php7.3-mbstring [php-mbstring]  7.3.4-2
ii  php7.3-recode [php-recode]  7.3.4-2
ii  schema2ldif 1.3-3
ii  smarty-gettext  1.6.1-1
ii  smarty3 3.1.33+20180830.1.3a78a21f+selfpack1-1

fusiondirectory recommends no packages.

Versions of packages fusiondirectory suggests:
pn  argonaut-server 
pn  fusiondirectory-schema  
ii  slapd   2.4.47+dfsg-3

-- debconf information:
  fusiondirectory/upgrade-canceled:
  fusiondirectory/upgrade-confirm: false

Bug#931957: On manpage say $PATH, not path

[Sandro Tosi]

> Use $PATH everywhere on the man page when you talk about "path". Else it
> is confusing. Nobody is completely sure which of the possible paths
> (-f's path, $PATH, etc.) you are talking about always.

I'm afraid we dont know what you're talking about. $PATH has a very
specific meaning (https://en.wikipedia.org/wiki/PATH_(variable)) and
nowhere in the manpage we mean that.

Closing,

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#931957: On manpage say $PATH, not path

[積丹尼 Dan Jacobson]

Package: reportbug
Version: 7.5.2
Severity: minor

Use $PATH everywhere on the man page when you talk about "path". Else it
is confusing. Nobody is completely sure which of the possible paths
(-f's path, $PATH, etc.) you are talking about always.

Bug#931958: package argument silently ignored if -f is present

[積丹尼 Dan Jacobson]

Package: reportbug
Version: 7.5.2

$ reportbug --template -f /usr/share/bash-completion/completions/umount mount
Finding package for '/usr/share/bash-completion/completions/umount'...   ^
Please re-run reportbug selecting one of these packages: ^
  bash-completion^
  mount  ^
 ^
But I did. It's right there -^

There is no error message, thus I am using the program correctly.
It is just silently throwing away the packagename argument.

And in this case there is no way for the user to successfully use the
program non-interactively. (dlocate is installed.)

P.S.,

   -f FILENAME, --filename=FILENAME Report a bug in the package
  containing FILENAME so you don't have to figure out what
  package the file belongs to...

should mention that it also adds a File: header to the report.

(OK, one can use
-f /usr/share/bash-completion/completions/umount$

But then the $ ends up on the File: line. BUG.)

Bug#931956: TAB expands symlinks when mounting, but not when umounting

[積丹尼 Dan Jacobson]

Package: mount
Version: 2.33.1-0.1
Severity: minor
File: /usr/share/bash-completion/completions/umount

I can TAB expand
# mount /some/symlink
but then when it is time to umount it, it won't let me TAB expand the
same path! It only knows about real paths.

Well it is true, it is great for umount only to expand the few paths for
mountpoints, instead of every file on the system.

But it should somehow remember what we called it when we mounted it.

And I suppose mount, instead of expanding every filename on the system,
should somehow magically instead only know real mount paths and symlink
mount paths...

Bug#883393:

[Alberto Leiva]

Looking for a sponsor...
https://mentors.debian.net/package/jool

On Thu, Jul 11, 2019 at 1:22 PM Alberto Leiva  wrote:
>
> > Hello. upstream author (and perhaps future upstream maintainer as well) 
> > here.
>
> Derp. I meant "Hello. Upstream author, upstream maintainer, and
> (perhaps) future package maintainer as well here."

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Ben Caradoc-Davies]

On 13/07/2019 04:32, Adler, Mark wrote:

I downloaded the four false-positive zip files from the bugreport page, and 
none of them showed a zip bomb error (or any other error).


Mark,

the zip bomb error is seen when unzipping the 17 jar files contained 
within the four zip files. Did you test these inner jar files? I used 
(in bash):


$ for f in *.jar; do echo $f; unzip -tq $f; done

The outer zip files are there because many email filters block all email 
with jar attachments, and Debian BTS is email-based.


It would also be nice if unzip reported the filename when rejecting a 
suspected zip bomb, as it does when reporting "No errors detected".


Kind regards,

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

Bug#931955: Shutting down virtual network doesn't remove all iptables rules

[etr]

Package: libvirt
Version: 5.0.0-4

After starting the default virtual network and then shutting down "-A 
FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable" remains 
in iptables rules. Each time you start and stop the service it adds 
another line of the same rule.


example:
net-start default
net-destroy default
iptables -S


"-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable" 
will remain in your iptables rules. Starting  an stopping the virtual 
network multiple times will continue to add more lines of the same rule

Bug#931954: sytemd user services are enabled twice

[Michael Biebl]

Package: gpg-agent
Version: 2.2.17-1
Severity: important
File: /usr/lib/systemd/user/gpg-agent.socket

Hi,

in 2.2.14-1, gnupg2 was switched to debhelper compat 12.
In that version, dh_installsystemduser is enabled by default.

As a result, the following files are created dynamically during
postinst:

/etc/systemd/user/sockets.target.wants/gpg-agent.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-browser.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
/etc/systemd/user/sockets.target.wants/gpg-agent-extra.socket
/etc/systemd/user/sockets.target.wants/dirmngr.socket

At the same time, the package also ships static symlinks in /usr/lib:

/usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-browser.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-extra.socket
/usr/lib/systemd/user/sockets.target.wants/dirmngr.socket

Those symlinks in /usr/lib/ date back iirc to a time when whe didn't
have dh_installsystemduser where I recommended to ship the enablement
symlinks directly in the package.

Since those are no longer necessary now, I would recommend removing
/usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-browser.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
/usr/lib/systemd/user/sockets.target.wants/gpg-agent-extra.socket
/usr/lib/systemd/user/sockets.target.wants/dirmngr.socket

like in the attached patch.


Regards,
Michael


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

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

Versions of packages gpg-agent depends on:
ii  gpgconf 2.2.17-1
ii  init-system-helpers 1.57
ii  libassuan0  2.5.3-2
ii  libc6   2.28-10
ii  libgcrypt20 1.8.4-5
ii  libgpg-error0   1.36-2
ii  libnpth01.6-1
ii  pinentry-curses [pinentry]  1.1.0-2
ii  pinentry-gnome3 [pinentry]  1.1.0-2
ii  pinentry-gtk2 [pinentry]1.1.0-2
ii  pinentry-qt [pinentry]  1.1.0-2

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.17-1

Versions of packages gpg-agent suggests:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 242-2
ii  pinentry-gnome31.1.0-2
pn  scdaemon   

-- Configuration Files:
/etc/logcheck/ignore.d.server/gpg-agent [Errno 13] Keine Berechtigung: 
'/etc/logcheck/ignore.d.server/gpg-agent'

-- no debconf information
diff --git a/debian/gpg-agent.links b/debian/gpg-agent.links
index 90f6ce115..292770149 100644
--- a/debian/gpg-agent.links
+++ b/debian/gpg-agent.links
@@ -1,6 +1,2 @@
 usr/lib/gnupg/gpg-preset-passphrase usr/lib/gnupg2/gpg-preset-passphrase
 usr/lib/gnupg/gpg-protect-tool usr/lib/gnupg2/gpg-protect-tool
-usr/lib/systemd/user/gpg-agent-browser.socket 
usr/lib/systemd/user/sockets.target.wants/gpg-agent-browser.socket
-usr/lib/systemd/user/gpg-agent-extra.socket 
usr/lib/systemd/user/sockets.target.wants/gpg-agent-extra.socket
-usr/lib/systemd/user/gpg-agent-ssh.socket 
usr/lib/systemd/user/sockets.target.wants/gpg-agent-ssh.socket
-usr/lib/systemd/user/gpg-agent.socket 
usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket

Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid

[Justin Pasher]

The fix below worked for me too. However, this means the error is still 
present in the buster version of the haveged package. I think it's a 
little more important to get this fixed, as the Buster release notes 
explicitly suggest using haveged as a possible means of improving the 
RNG entropy on first boot to avoid unnecessary boot delays. Without it, 
people will install haveged and either not notice that it fails to 
start, wonder why it refuses to start, or wonder why they are still 
getting boot delays.


It seems like a pretty trivial patch without any adverse side effects.

Justin Pasher

On Mon, 22 Oct 2018 16:01:51 +0200 Axel Beckert  wrote:
> Package: haveged
> Version: 1.9.1-6
> Severity: important
> Tags: patch
>
> Hi,
>
> haveged silently fails to start on one of my machines, seemingly due
> to apparmor. From /var/log/syslog after unsucessfully trying to start
> haveged:
>
> Oct 22 15:40:26 someone haveged: haveged starting up
> Oct 22 15:40:26 someone kernel: [24678702.682596] audit: type=1400 
audit(1540215626.982:65757): apparmor="DENIED" operation="mknod" 
profile="/usr/sbin/haveged" name="/run/haveged.pid" pid=7421 
comm="haveged" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

>
> What helped was adding the line
>
> /run/haveged.pid w,
>
> to /etc/apparmor.d/local/usr.sbin.haveged, so you should probably add
> that line to /etc/apparmor.d/usr.sbin.haveged.

Bug#452333: latex-beamer: beamer should generate pdf page labels using hyperref

[Hilmar Preuße]

On 21.11.07 23:41, Chung-chieh Shan wrote:

Hi,

https://bugs.debian.org/452333

Is the issue still present? If yes please be so kind to contact beamer
author yourself [1]. We don't have the time to care about bugs in single
LaTeX packages.

Thanks!

Hilmar

[1] https://github.com/josephwright/beamer/issues

> hyperref version 6.75p disables pdfpagelabels if \thepage is undefined
> when hyperref is loaded, which is the case when the first line of the
> document is \documentclass{beamer}.  Instead, beamer should (1) define
> \thepage earlier so that hyperref enables pdfpagelabels; (2) use the
> \thispdfpagelabel macro (introduced in hyperref version 6.71f) to set
> the pdf page label on every frame.  Currently, I achieve these effects
> by saying
> 
> \pagenumbering{arabic}
> \documentclass{beamer}
> \mode
> {
>   \setbeamertemplate{sidebar left}{\thispdfpagelabel{\insertframenumber}}
> }
> 
> in my presentation document.  The page labels are useful because they
> ease navigation in PDF viewers such as Acrobat Reader and pspresent
> (the latter in conjunction with a patch to pdftops that I will submit
> shortly).
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931818: Info received (Bug#931818: cups: Jobs webpage /usr/lib/cups/cgi-bin/jobs.cgi segfault after package login removes /etc/securetty)

[Bernhard Übelacker]

Hello Jeffrey Hundstad,
sorry, I forget to mention that it would help with the
backtrace if the debug symbols would be installed.
For jobs.cgi I assume this would be cups-dbgsym.

These packages are in a separate repository.
Details are about it are in this page:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Kind regards,
Bernhard

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Diederik de Haas]

Package: grub-efi-amd64
Followup-For: Bug #931896

I don't have grub-efi-amd64 installed, but I ran into the same problem.
The only enabled lines in /etc/default/grub are these:
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Which, afaik, is the default.
The versions reported are what's currently installed as with 2.04 my
system doesn't boot.

I'm not sure/don't understand what Colin meant with 'firmware'. My guess
would be my BIOS, but I haven't changed that recently.
But up until version 2.04 grub2 has worked perfectly well and I don't 
recall me having configured anything manually, so I wouldn't know why 
it would be misconfigured.
Downgrading to version 2.02+dfsg1-20 makes it work again

I can send my grub.cfg in a separate email if that would help.
(How can I do a followup with bugreport so that the full output is
reported as you'd get with an initial filing of a bug?)

I get no errors during the upgrade to 2.04:
root@host:~# aptitude unhold grub-pc
root@host:~# aptitude safe-upgrade
Resolving dependencies...
The following packages will be upgraded:
  grub-common grub-pc grub-pc-bin grub2-common
4 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/4,283 kB of archives. After unpacking 1,353 kB will be used.
Do you want to continue? [Y/n/?]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 514663 files and directories currently installed.)
Preparing to unpack .../grub2-common_2.04-1_amd64.deb ...
Unpacking grub2-common (2.04-1) over (2.02+dfsg1-20) ...
Preparing to unpack .../grub-pc_2.04-1_amd64.deb ...
Unpacking grub-pc (2.04-1) over (2.02+dfsg1-20) ...
Preparing to unpack .../grub-pc-bin_2.04-1_amd64.deb ...
Unpacking grub-pc-bin (2.04-1) over (2.02+dfsg1-20) ...
Preparing to unpack .../grub-common_2.04-1_amd64.deb ...
Unpacking grub-common (2.04-1) over (2.02+dfsg1-20) ...
Setting up grub-common (2.04-1) ...
Installing new version of config file /etc/grub.d/00_header ...
Installing new version of config file /etc/grub.d/10_linux ...
Installing new version of config file /etc/grub.d/20_linux_xen ...
Setting up grub2-common (2.04-1) ...
Setting up grub-pc-bin (2.04-1) ...
Setting up grub-pc (2.04-1) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-5-amd64
Found initrd image: /boot/initrd.img-4.19.0-5-amd64
Found linux image: /boot/vmlinuz-4.16.0-2-amd64
Found initrd image: /boot/initrd.img-4.16.0-2-amd64
Found linux image: /boot/vmlinuz-4.13.0-1-amd64
Found initrd image: /boot/initrd.img-4.13.0-1-amd64
Found linux image: /boot/vmlinuz-4.9.0-3-amd64
Found initrd image: /boot/initrd.img-4.9.0-3-amd64
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
Found Microsoft Windows XP Professional on /dev/sda2
done
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for install-info (6.6.0.dfsg.1-2) ...

WinXP doesn't actually boot iirc (been a LONG while since I tried) and
the remaining non-upgraded packages are due to #928631.

If you want/need more info, let me know.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 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 grub-efi-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.72
ii  grub-common2.02+dfsg1-20
pn  grub-efi-amd64-bin 
ii  grub2-common   2.02+dfsg1-20
ii  ucf3.0038+nmu1

grub-efi-amd64 recommends no packages.

grub-efi-amd64 suggests no packages.

Bug#931818: Info received (Bug#931818: cups: Jobs webpage /usr/lib/cups/cgi-bin/jobs.cgi segfault after package login removes /etc/securetty)

[Hundstad, Jeffrey E]

Here's some more, but not much better:

root@systemname:/usr/share/doc/systemd-coredump# gdb 
/usr/lib/cups/cgi-bin/jobs.cgi /tmp/ooo
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/cups/cgi-bin/jobs.cgi...(no debugging symbols 
found)...done.
[New LWP 26510]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/cups/cgi-bin/jobs.cgi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) backtrace full
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
No locals.
#1  0x7f16d9130dae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x55b36a21f41c in ?? ()
No symbol table info available.
#3  0x55b36a21fd3e in ?? ()
No symbol table info available.
#4  0x55b36a21f626 in ?? ()
No symbol table info available.
#5  0x55b36a2200b7 in ?? ()
No symbol table info available.
#6  0x55b36a21d68d in ?? ()
No symbol table info available.
#7  0x55b36a21b7c1 in ?? ()
No symbol table info available.
#8  0x7f16d90cd09b in __libc_start_main (main=0x55b36a21b670, argc=1, 
argv=0x7ffc607f86d8, init=, fini=, 
rtld_fini=, stack_end=0x7ffc607f86c8) at ../csu/libc-start.c:308
self = 
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -5082858722427954408, 
94229068101712, 140721927456464, 0, 0, -1303763130235512040, 
-1423866795149124840}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 
0x7ffc607f86e8, 0x7f16d9362190}, data = {prev = 0x0, cleanup = 0x0, 
  canceltype = 1618970344}}}
not_first_call = 
#9  0x55b36a21b87a in ?? ()
No symbol table info available.
(gdb) 




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#931131: tomcat9: CVE-2019-10072

[Salvatore Bonaccorso]

Source: tomcat9
Source-Version: 9.0.22-1

On Wed, Jun 26, 2019 at 08:39:00PM +0200, Salvatore Bonaccorso wrote:
> Source: tomcat9
> Version: 9.0.16-4
> Severity: important
> Tags: security upstream
> Control: found -1 9.0.16-1
> 
> Hi,
> 
> The following vulnerability was published for tomcat9.
> 
> CVE-2019-10072[0]:
> | The fix for CVE-2019-0199 was incomplete and did not address HTTP/2
> | connection window exhaustion on write in Apache Tomcat versions
> | 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE
> | messages for the connection window (stream 0) clients were able to
> | cause server-side threads to block eventually leading to thread
> | exhaustion and a DoS.

The issue was fixed upstream in 9.0.20, but the upload to unstable for
9.0.22 did not contain the bug closer. Closing thus manually.

Regards,
Salvatore

Bug#926712: evolution-ews: CVE-2019-3890

[Luca Boccassi]

On Tue, 2019-07-09 at 15:28 +0100, Luca Boccassi wrote:
> On Wed, 2019-07-03 at 11:38 +0100, Luca Boccassi wrote:
> > On Mon, 17 Jun 2019 11:39:13 +0100 Luca Boccassi <
> > bl...@debian.org
> > 
> > 
> > > wrote:
> > > On Tue, 9 Apr 2019 15:52:52 +0200 Sylvain Beucler <
> > > 
> > 
> > b...@beuc.net
> > 
> > 
> > 
> > > > wrote:
> > > > Package: evolution-ews
> > > > Version: 3.30.5-1
> > > > X-Debbugs-CC: 
> > 
> > t...@security.debian.org
> > 
> > 
> > 
> > > > Severity: grave
> > > > Tags: security
> > > > 
> > > > Hi,
> > > > 
> > > > The following vulnerability was published for evolution-ews.
> > > > 
> > > > CVE-2019-3890[0]:
> > > > No description was found (try on a search engine)
> > > > 
> > > > If you fix the vulnerability please also make sure to include
> > > > the
> > > > CVE (Common Vulnerabilities & Exposures) id in your changelog
> > 
> > entry.
> > > > For further information see:
> > > > 
> > > > [0] 
> > 
> > https://security-tracker.debian.org/tracker/CVE-2019-3890
> > 
> > 
> > 
> > > > 
> > 
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3890
> > 
> > 
> > 
> > 
> > https://gitlab.gnome.org/GNOME/evolution-ews/issues/27
> > 
> > 
> > 
> > 
> > https://gitlab.gnome.org/GNOME/evolution-ews/issues/36
> > 
> > 
> > 
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1678313
> > 
> > 
> > 
> > > > Note: depends on evolution-data-server patch
> > > > 
> > > > Cheers!
> > > > Sylvain Beucler / Debian LTS
> > > 
> > > Dear Maintainers,
> > > 
> > > I have backported the required patches and tested them on Buster,
> > 
> > they
> > > seem to work fine.
> > > 
> > > I have opened PRs against the 2 repos on Salsa, but they both
> > > require
> > 
> > a
> > > new debian/buster branch to be created as debian/master has moved
> > > on
> > 
> > to
> > > new releases:
> > > 
> > > 
> > 
> > https://salsa.debian.org/gnome-team/evolution-data-server/merge_requests/1
> > 
> > 
> > 
> > 
> > https://salsa.debian.org/gnome-team/evolution-ews/merge_requests/2
> > 
> > 
> > 
> > > It would be great if we could have evolution-ews in Buster, as
> > > it's
> > 
> > the
> > > only way to use exchange/o365 for Debian users.
> > > 
> > > Thanks!
> > 
> > Dear Maintainers,
> > 
> > As things stand, Buster users will have no way to use a GUI email
> > client with an Exchange/OWA/O365 email server. They will have to
> > stay
> > on Stretch and completely skip Buster, or move to a different
> > distribution. If they were to upgrade from Stretch to Buster, their
> > email accounts would simply disappear from their evolution
> > instances,
> > without any explanation nor warning.
> > 
> > I'd like to propose to upload the changes mentioned above to
> > unstable,
> > let them migrate to Bullseye and then upload to buster-backports,
> > so
> > that users on Buster have at least that path to avoid breaking this
> > functionality. This needs to be done before 3.32 moved from
> > experimental to unstable of course.
> > 
> > I'd be more than happy to do all of the above work via NMUs. The
> > evolution-data-server change is backward compatible and does not
> > require a rebuild of reverse dependencies. Are there any objections
> > to
> > this idea?
> > 
> > Thank you!
> 
> Dear Maintainers, Uploaders and Gnome Team,
> 
> As mentioned in the previous mail, I intend to upload to DELAYED/7
> NMUs
> for evolution-data-server and evolution-ews on Friday afternoon (GMT-
> ish). I am attaching the debdiffs for both.
> 
> Please let me know if there are any objections.
> 
> If there are no objections and the NMUs are not cancelled and make it
> to unstable, and then migrate to bullseye, I then intend to upload
> the
> equivalent ~bpo binary NMUs to buster-backports. This way, stretch
> users that enabled buster-backports before the dist upgrade should
> have
> an upgrade path that allows them not to lose their inboxes, calendars
> and so on.
> 
> Thank you!

Dear Maintainers, Uploaders and Gnome Team,

I have now uploaded the above mentioned NMUs to DELAYED/7 as previously
mentioned.

-- 
Kind regards,
Luca Boccassi


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

Bug#931818: cups: Jobs webpage /usr/lib/cups/cgi-bin/jobs.cgi segfault after package login removes /etc/securetty

[Hundstad, Jeffrey E]

This is what I was able to find after the systemd-coredump was installed:


Jul 12 16:11:45 systemname kernel: jobs.cgi[26510]: segfault at 0 ip
7f16d9205181 sp 7ffc607f5798 error 4 in
libc-2.28.so[7f16d90cb000+148000]
Jul 12 16:11:45 systemname kernel: Code: 84 00 00 00 00 00 0f 1f 00 31
c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0
83 e1 3f 83 f9 20 77 1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00
00 48 83 c7 20 83 e1
Jul 12 16:11:45 systemname systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
Jul 12 16:11:45 systemname systemd[1]: Started Process Core Dump (PID
26511/UID 0).
Jul 12 16:11:46 systemname systemd-coredump[26512]: Process 26510
(jobs.cgi) of user 7 dumped core.
   
 Stack trace of thread
26510:
 #0  0x7f16d9205181
n/a (libc.so.6)
 #1  0x7f16d9130dae
__strdup (libc.so.6)
 #2  0x55b36a21f41c
n/a (jobs.cgi)
 #3  0x55b36a21fd3e
n/a (jobs.cgi)
 #4  0x55b36a21f626
n/a (jobs.cgi)
 #5  0x55b36a2200b7
n/a (jobs.cgi)
 #6  0x55b36a21d68d
n/a (jobs.cgi)
 #7  0x55b36a21b7c1
n/a (jobs.cgi)
 #8  0x7f16d90cd09b
__libc_start_main (libc.so.6)
 #9  0x55b36a21b87a
n/a (jobs.cgi)
Jul 12 16:11:46 systemname systemd[1]:
systemd-coredump@0-26511-0.service: Succeeded.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#930103: ftp.debian.org: Please provide xz compressed Translation-* files

[Julian Andres Klode]

On Fri, Jun 07, 2019 at 12:11:06AM +0200, Julian Andres Klode wrote:
> On Fri, Jun 07, 2019 at 12:02:11AM +0200, Julian Andres Klode wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > APT in buster should now handle arbitrary compressors for translation
> > files, so it would be a good idea to switch from bzip2 to xz for bullseye
> > so we can maybe remove bzip2 support from apt in bullseye.
> 
> As a matter of fact, Ubuntu already ships .gz and .xz files since
> xenial (apt 1.2), so stable should be fine with that as well.
> 
> I just don't want to break d-i or stuff, so I guess limiting things
> to experimental while in freeze is probably a good idea.

debian-i18n: Is there anything on your side that would block this
atm?

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#931953: support bootspec entries for barebox

[Uwe Kleine-König]

Package: flash-kernel
Version: 3.99
Severity: wishlist
Tags: patch

Hello,

barebox can boot from partitions that contain a so called
bootspec entry (or several of them). It would be great if flash-kernel
supported writing these. I already opened a merge request for
flash-kernel at

https://salsa.debian.org/installer-team/flash-kernel/merge_requests/8

Thanks for considering,
Uwe

Bug#931818: cups: Jobs webpage /usr/lib/cups/cgi-bin/jobs.cgi segfault after package login removes /etc/securetty

[Bernhard Übelacker]

Hello Jeffrey Hundstad,
just looking at some crashes in some random packages,
I just tried to reproduce this issue inside a minimal qemu VM.
But hit just the line "Couldn't open...", not the segfault.
Also with a simple test printer configured and a test page job.

If it is possible you could install the package systemd-coredump.
Then journalctl should provide a backtrace for the crashing
process that could be forwarded to this bug.

Kind regards,
Bernhard

Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

[userm57]

On 7/11/19 10:49 AM, user...@yahoo.com wrote:
> On 7/4/19 1:07 PM, user...@yahoo.com wrote:
>> Correction: The CPU of the Wallstreet is 266 MHz, not 292 MHz.
> 
> Update:
> 
> Please see attached "all.tar.xz", which contains the following files:
> 
> "x11perf -all" tests:
> 
> 1) x11perf_8_fbdev.txt: Debian 8.11, mach64 removed
> 2) x11perf_8_mach64.txt   : Debian 8.11, mach64 installed
> 3) x11perf_sid_fbdev.txt  : Debian sid, mach64 removed
> 4) x11perf_sid_mach64.txt : Debian sid, mach64 installed
> 5) x11perfcomp.txt: comparison of the above four tests
> 
> "/var/log/Xorg.0.log" files:
> 
> 6) Xorg_8_fbdev.log  : Xorg log file for test (1)
> 7) Xorg_8_mach64.log : Xorg log file for test (2)
> 8) Xorg_sid_fbdev.log: Xorg log file for test (3)
> 9) Xorg_sid_mach64.log   : Xorg log file for test (4)
> 
> "glxgears" (from mesa-utils) tests:
> 
> 10) glxgears.txt
> ...

I added two tests.  Please see the attached "update.tar.xz", which
contains the following six files:

"x11perf -all" tests:

11) x11perf_sid_fbdev-1.txt  : Debian sid, mach64 removed, multiuser
12) x11perf_sid_mach64-1.txt : Debian sid, mach64 installed, multiuser
13) x11perfcomp_sid.txt  : comparison of 3), 4), 11) and 12)

"/var/log/Xorg.0.log" files:

14) Xorg_sid_fbdev-1.log : Xorg log file for 11)
15) Xorg_sid_mach64-1.log: Xorg log file for 12)

serial console log:

16) console_log.txt  : console log file for 11) and 12)

The G3 Wallstreet test system was booted multiuser into Debian sid using
the kernel 4.19.56-debian-pmac.  After the system was up, I logged in at
the serial console and ran "/etc/init.d/wdm stop" to stop X.  At that
point, I ran "xinit &" and the x11perf tests.

A quick look at the x11perfcomp_sid.txt file seems to show that it
doesn't make much difference whether running in single user mode or
multiuser mode.  For tests 11) and 12), there were no dbus errors in the
respective Xorg.log files (this may not have affected the earlier tests
much, anyway, since the dbus errors happened only once every ten seconds).

The "ps auxw" output (at the end of the serial console log) is
interesting.  It shows the following (while I'm logged in as a
non-privileged user at the console and as root at the serial console):

a) The total VSZ of all processes on the system is about 2.6 GB.

b) The total RSS of all processes on the system is about 738 MB.  That
suggests that some swapping will have to occur in multiuser mode with a
full Xfce desktop running, since the system has only 512 MB memory.

c) Just the X server by itself is using 58 MB memory (RSS):
root 891 14.6 11.6 149056 58472 tty7 Ssl+ 13:37 0:13 /usr/lib/xorg/Xorg

d) The systemd processes (including dbus) are using 53 MB (RSS).

e) The Xfce-related processes are using about 260 MB.

f) Between systemd, X, and a minimal desktop such as Xfce, it appears
that any system with less than about 58+53+260 = 371 MB memory would
experience fairly severe swapping trying to run a modern X11 desktop.
If the trend continues, only emulators running on modern hardware will
be able to do a decent job running powerpc distributions.  I realize the
bloat problem is not directly related to this bug report.

I'll backup the partitions I've been using for Debian 8.11 and sid in
case any further testing is needed.  If not, this bug report is complete.

Eventually, Michel's patch should make it to Debian sid (I'll ask about
that on the Debian powerpc mailing list), and when a new version is
available, I'll be happy to test it.

I'm still wondering whether this is a problem:
(II) FBDEV(0): hardware: OFfb ATY,RageLT (video memory: 3072kB)

If the FBDEV driver is being told by the kernel that the video memory is
3072 K, when it should be reported as 4096 K, how does that affect the
x11perf results for FBDEV?

Meanwhile, I'll be removing systemd and seeing if earlier versions of
Xorg and Xfce can be used on (or compiled for) Debian sid.

Thanks to all who have helped with this issue.

-Stan Johnson
 user...@yahoo.com


update.tar.xz
Description: Binary data

Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libmonkey-patch-perl

[Chris Lamb]

forwarded 931730 
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/8
thanks

I've "forwarded" this upstream here:

  https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/8


Regards,

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

Bug#931952: ITP: r-cran-party -- GNU R laboratory for recursive partytioning

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-party -- GNU R laboratory for recursive partytioning
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-party
  Version : 1.3
  Upstream Author : Torsten Hothorn,
* URL : https://cran.r-project.org/package=party
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R laboratory for recursive partytioning
 A computational toolbox for recursive partitioning.
 The core of the package is ctree(), an implementation of
 conditional inference trees which embed tree-structured
 regression models into a well defined theory of conditional
 inference procedures. This non-parametric class of regression
 trees is applicable to all kinds of regression problems, including
 nominal, ordinal, numeric, censored as well as multivariate response
 variables and arbitrary measurement scales of the covariates.
 Based on conditional inference trees, cforest() provides an
 implementation of Breiman's random forests. The function mob()
 implements an algorithm for recursive partitioning based on
 parametric models (e.g. linear models, GLMs or survival
 regression) employing parameter instability tests for split
 selection. Extensible functionality for visualizing tree-structured
 regression models is available. The methods are described in
 Hothorn et al. (2006) ,
 Zeileis et al. (2008)  and
 Strobl et al. (2007) .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-party

Bug#931951: lintian: False positive: command-in-sbin-has-manpage-in-incorrect-section for symlinks in sbin

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.16.0
Severity: normal

Hello,
I have been bitten by a Lintian check false positive on my package
(apt-listbugs):
command-in-sbin-has-manpage-in-incorrect-section

My package indeed ships "/usr/sbin/apt-listbugs" and the man page
is indeed in section 1 ("/usr/share/man/man1/apt-listbugs.1.gz").

But "/usr/sbin/apt-listbugs" is actually a symlink to
"/usr/bin/apt-listbugs":

  $ ls -altrF /usr/*bin/apt-listbugs
  lrwxrwxrwx 1 root root19 Apr 22 16:23 /usr/sbin/apt-listbugs -> 
../bin/apt-listbugs*
  -rwxr-xr-x 1 root root 22111 Apr 22 16:23 /usr/bin/apt-listbugs*


The reason is that, a long time ago, the package used to only ship
"/usr/sbin/apt-listbugs"; at a certain point, it was decided to move
the program to "/usr/bin/", since some of its operating modes
are useful to non-privileged users, too.
However, a number of users could have created custom scripts which
invoke "/usr/sbin/apt-listbugs": in order to avoid gratuitously
breaking all those scripts, it was decided to keep the program
in both "/usr/sbin" and "/usr/bin", with one path being a symlink to
the other.

I think the Lintian complaint is a false positive. Lintian should
look whether the "/usr/sbin/$file" is actually a symlink (to
"/usr/bin/$file") and refrain from emitting the complaint, if this
is the case.

I hope this bug may be fixed soon.

Thanks for your time.
Bye!


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-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 lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9.1
ii  diffstat   1.62-1
ii  dpkg   1.19.7
ii  dpkg-dev   1.19.7
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.13-2
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.36+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.7
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-compare-perl   0.53-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#931950: transition: libgeotiff

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 931949

For the Debian GIS team I'd like to transition to libgeotiff 1.5. This
version is required for PROJ 6 support.

This transition goes hand in hand with the proj transition. (#931949)

All reverse depenencies built successfully with the new libgeotiff, only
xastir & metview need to apply a patch to not FTBFS with PROJ 6.

A summary of the rebuilds is included below.


Ben file:

title = "libgeotiff";
is_affected = .depends ~ "libgeotiff2" | .depends ~ "libgeotiff5";
is_good = .depends ~ "libgeotiff5";
is_bad = .depends ~ "libgeotiff2";


Transition: libgeotiff

 libgeotiff2 (1.4.3-1) -> libgeotiff5 (1.5.1-1~exp3)

The status of the most recent rebuilds is as follows.

 libgeotiff-dfsg (1.4.3-1)  SKIP (obsolete)
 libgeotiff-epsg (1.4.3-1)  SKIP (obsolete)

 gdal(2.4.2+dfsg-1) OK
 gnudatalanguage (0.9.9-9)  OK
 grads   (3:2.2.1-1)OK
 librasterlite2  (1.1.0~beta0+really1.0.0~rc0+devel1-2) OK
 libterralib (4.3.0+dfsg.2-11)  OK
 ossim   (2.6.2-1)  OK

 liblas  (1.8.1-10) OK
 magics++(3.3.1-1)  OK
 otb (6.6.1+dfsg-1) OK
 pdal(1.8.0+ds-1)   OK
 xastir  (2.1.0-5)  OK [+]

 grass   (7.6.1-1)  OK
 metview (5.3.0-2)  OK [+]


Kind Regards,

Bas

Bug#931949: transition: proj

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html
Control: block -1 by 931914 931922 931931 931935 931940 931943 931945 931941 
931944 931948 931904 931908 931872

For the Debian GIS team I'd like to transition to PROJ 6.

This is a major change that affects the wider GIS ecosystem, with proj
being at the bottom of the dependency chain.

Most packages build successfully with the new version after defining
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H to use the deprecated proj_api.h.
Several of the affected packages already have this change in unstable.
Others have patches available in the BTS. For yet some others have a fix
available in a new upstream release that still needs to be packaged.

Some packages that FTBFS are dead upstream for quite a while and RM bug
have been filed for those.

The vtk6 & vtk7 packages and their rdeps (ifrit & lammps) are the
biggest issue, but the VTK packages can be updated to use their embedded
copy of PROJ 4. VTK upstream also has support for PROJ 6, but this is
not packaged yet.

libgeotiff-dfsg won't need a rebuild, libgeotiff will be moved to
unstable instead. This will trigger a transition too, but it only
affects 12 packages, 6 of which are also affected by the proj
transition. All libgeotiff rdeps built successfully with the new proj &
libgeotiff.

python-pyproj also won't need a rebuild, the version in experimental
will be moved to unstable as well. This won't trigger a transition.


Transition: proj

 libproj13 (5.2.0-1) -> libproj15 (6.1.1-1~exp1)

The status of the most recent rebuilds is as follows.
Packages marked with [+] have a patch available in the BTS.

 josm(0.0.svn15238+dfsg-1)  SKIP

 gpx2shp (0.71.0-7) FTBFS
(#931904)
 libgeo-proj4-perl   (1.09-3)   FTBFS
(#931908)
 libgeotiff-dfsg (1.4.3-1)  SKIP
 libgeotiff  (1.5.1-1~exp3) OK
 mshr(2018.1.0+dfsg1-7) OK
 octave-octproj  (1.1.5-4)  OK [+]
(#931914)
 osm2pgsql   (0.96.0+ds-3)  OK
 pdl (1:2.019-5)OK
 proj-rdnap  (2008-9)   OK
 python-cartopy  (0.17.0+dfsg-4)OK
 python-pyproj   (1.9.6-1 / 2.2.1+ds-1~exp1)FTBFS / OK
 sosi2osm(1.0.0-6)  OK
 spatialite  (4.3.0a-6) OK
 survex  (1.2.40-1) OK
 xygrib  (1.2.2-1)  OK [+]
(#931922)

 gdal(2.4.2+dfsg-1) OK
 magics++(4.0.3-1)  OK
 spatialite-gui  (2.1.0~beta0+really2.0.0~devel2-4) OK
 spatialite-tools(4.3.0-3)  OK
 xastir  (2.1.2-1)  OK [+]
(#931931)

 cdo (1.9.7.1-3)OK
 mapnik  (3.0.22+ds-2)  OK
 mapserver   (7.4.0-1)  OK
 merkaartor  (0.18.3+ds-6)  OK
 metview (5.3.0-2)  OK [+]
(#931945)
 ncl (6.6.2-1)  OK
 openorienteering-mapper (0.8.4-1)  OK [+]
(#931935)
 pdal(1.8.0+ds-1)   OK
 postgis (2.5.2+dfsg-1) OK
 qmapshack   (1.13.0-1) OK
 r-cran-sf   (0.7-6+dfsg-1) OK
 saga(2.3.1+dfsg-5) FTBFS
(#931941)
 sumo(1.1.0+dfsg1-1)OK [+]
(#931940)
 thuban  (1.2.2-14) FTBFS
(#931872)
 vtk6(6.3.0+dfsg2-2)FTBFS
(#931943)
 vtk7(7.1.1+dfsg1-12)   FTBFS
(#931944)

 

Bug#931911: user-setup: Fails to present no-root-password_first-user-sudoer option as a reasonable choice

[Josh Triplett]

On Fri, 12 Jul 2019 11:11:09 +0200 Philip Hands  wrote:
> I've just pushed a branch to salsa:
> 
>   
> https://salsa.debian.org/installer-team/user-setup/tree/bug-931911-empty-root-password-OK
> 
> that is an attempt to make this better.  Comments welcome.

That looks like an improvement. But could we go a step further, please?

In order, from least to most controversial:

1) Let's *always* install sudo, and *always* add the initial user to the
appropriate group to use sudo, with a low-priority expert-only debconf
question for preseeders to use to disable.

2) Let's fix anything that still asks for the root password to do
something compatible with a sudoer and no root password.

3) Let's ask for the root password as a medium-priority or lower
question, defaulting to not asking at all. If you actually need a root
password, it seems trivial to `sudo passwd root` later, or use
preseeding (ideally with a hashed password).

In an ideal world, I'd suggest a single prompt that asks:

User full name:  __
Username:__ (with guess from full name, as we do now)
Password:__
Repeat password: __
[ ] Advanced options

And "Advanced options" could support configurations like "set a root
password" and "don't create a user at all".

(I'd also like to see an easy way to configure almost nothing, and
install a system that boots up into a desktop "initial setup"
application, but that only applies if installing a system that'll boot
an interactive desktop environment (and have a local console), so we
still need the ability to completely set up the system from the
installer.)

Bug#929567: libgtk-3-0:amd64: Emacs constantly crashes on startup with "X protocol error: BadLength..."

[Andreas Beckmann]

Followup-For: Bug #929567
Control: tag -1 pending

Hi Rob,

I've prepared another update for emacs and uploaded it to DELAYED/10.
I primarily want to get rid of all the transitional emacsXX* packages
now that buster has been released, but I also included this RC bugfix.

As usual, you can find the changes in my fork:
https://salsa.debian.org/anbe/deb-emacs.git


Andreas
diff -Nru emacs-26.1+1/debian/.git-dpm emacs-26.1+1/debian/.git-dpm
--- emacs-26.1+1/debian/.git-dpm2019-02-03 15:42:30.0 +0100
+++ emacs-26.1+1/debian/.git-dpm2019-07-12 20:42:27.0 +0200
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-face2676a9d5a13b40eaeecfb09a16e81364e916
-face2676a9d5a13b40eaeecfb09a16e81364e916
+3cd4b72717032b17e596fce6f475f4a4029fa236
+3cd4b72717032b17e596fce6f475f4a4029fa236
 511a2cebd6df0f71ec24b5939564fb58726ead84
 511a2cebd6df0f71ec24b5939564fb58726ead84
 emacs_26.1+1.orig.tar.xz
diff -Nru emacs-26.1+1/debian/changelog emacs-26.1+1/debian/changelog
--- emacs-26.1+1/debian/changelog   2019-02-03 15:42:30.0 +0100
+++ emacs-26.1+1/debian/changelog   2019-07-12 20:42:27.0 +0200
@@ -1,3 +1,14 @@
+emacs (1:26.1+1-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  * Drop transitional versioned emacsXX* packages.
+
+  * Cherry-pick 408bf21a8c and 95b77b0451 to fix crashes with color fonts,
+thanks to Vincent Lefevre.  (Closes: #929567)
+
+ -- Andreas Beckmann   Fri, 12 Jul 2019 20:42:27 +0200
+
 emacs (1:26.1+1-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru emacs-26.1+1/debian/control emacs-26.1+1/debian/control
--- emacs-26.1+1/debian/control 2019-02-03 15:42:30.0 +0100
+++ emacs-26.1+1/debian/control 2019-07-12 20:42:27.0 +0200
@@ -114,20 +114,20 @@
  emacs-gtk (<< 1:25),
  emacs-lucid (<< 1:25),
  emacs-nox (<< 1:25),
- emacs21 (<< 1:25),
- emacs21-nox (<< 1:25),
- emacs22 (<< 1:25),
- emacs22-gtk (<< 1:25),
- emacs22-nox (<< 1:25),
- emacs23 (<< 1:25),
- emacs23-lucid (<< 1:25),
- emacs23-nox (<< 1:25),
- emacs24 (<< 1:25),
- emacs24-lucid (<< 1:25),
- emacs24-nox (<< 1:25),
- emacs25 (<< 1:25),
- emacs25-lucid (<< 1:25),
- emacs25-nox (<< 1:25),
+ emacs21,
+ emacs21-nox,
+ emacs22,
+ emacs22-gtk,
+ emacs22-nox,
+ emacs23,
+ emacs23-lucid,
+ emacs23-nox,
+ emacs24,
+ emacs24-lucid,
+ emacs24-nox,
+ emacs25,
+ emacs25-lucid,
+ emacs25-nox,
  apel (<< 10.8+0.20120427-4),
  edb (<< 1.32),
  egg (<< 4.2.0-2),
@@ -143,143 +143,3 @@
  GNU Emacs is the extensible self-documenting text editor.
  This package contains the elisp sources for the convenience of users,
  saving space in the main package for small systems.
-
-Package: emacs21
-Section: oldlibs
-Architecture: all
-Depends: emacs-gtk (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-gtk
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs21
- installed automatically upgrade to the new unversioned emacs-gtk
- package.
-
-Package: emacs21-nox
-Section: oldlibs
-Architecture: all
-Depends: emacs-nox (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-nox
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs21
- installed automatically upgrade to the new unversioned emacs-nox
- package.
-
-Package: emacs22
-Section: oldlibs
-Architecture: all
-Depends: emacs-gtk (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-gtk
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs22
- installed automatically upgrade to the new unversioned emacs-gtk
- package.
-
-Package: emacs22-gtk
-Section: oldlibs
-Architecture: all
-Depends: emacs-gtk (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-gtk
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs22
- installed automatically upgrade to the new unversioned emacs-gtk
- package.
-
-Package: emacs22-nox
-Section: oldlibs
-Architecture: all
-Depends: emacs-nox (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-nox
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs22
- installed automatically upgrade to the new unversioned emacs-nox
- package.
-
-Package: emacs23
-Section: oldlibs
-Architecture: all
-Depends: emacs-gtk (>= 1:25), ${misc:Depends}
-Description: GNU Emacs transitional package to emacs-gtk
- GNU Emacs is the extensible self-documenting text editor.  This
- package is a transitional package to ensure that systems with emacs23
- installed automatically upgrade to the new unversioned emacs-gtk
- package.
-
-Package: emacs23-lucid
-Section: oldlibs

Bug#931900: Program crashes with message "free(): double free detected in tcache 2"

[Alex Relis]

Oh, my bad. Weird that I didn't see it. Looks like there is a fix in
that other bug report. Good luck.

On 7/12/19 1:52 AM, Bernhard Übelacker wrote:
> Hello 
> the issue you observed might be already reported in:
> https://bugs.debian.org/924925
> 
> Kind regards,
> Bernhard
> 



signature.asc
Description: OpenPGP digital signature

Bug#931948: r-cran-lwgeom: FTBFS with PROJ 6

[Bas Couwenberg]

Source: r-cran-lwgeom
Version: 0.1-5+repack-1
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

It fails at configure because the epsg file is no longer included in
PROJ 6.

Upstream is aware of the issue, see:

 https://github.com/r-spatial/lwgeom/issues/42

Kind Regards,

Bas

Bug#931947: printer-driver-brlaser: Brother HL-1110 printer is unsupported in Debian, but it works upstream

[Jose Antonio Salgueiro A.]

Package: printer-driver-brlaser
Version: 4-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
I have an Brother printer HL-1110 . It worked in Ubuntu.
I have compiled git version on Raspberry PI 3. It works fine!

Please update package from repository:
https://github.com/pdewacht/brlaser



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

Kernel: Linux 4.19.16 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.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 printer-driver-brlaser depends on:
ii  libc6  2.28-10
ii  libcups2   2.2.10-6
ii  libcupsimage2  2.2.10-6
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6

printer-driver-brlaser recommends no packages.

printer-driver-brlaser suggests no packages.

-- no debconf information

Bug#931946: dkms mkdeb --source-only generates an architecture-dependent package

[sKUrZ0]

Package: dkms
Version: 2.6.1-4
Severity: normal
Tags: patch

Dear Maintainer,

Running dkms mkdeb --source-only generates an architecture-dependent package,
while it should generate an architecture-independent package.
Previous versions generated an architecture-independent package even when
--binaries-only option was given, as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558
However, the fix breaks the expected (and correct) behavior when --source-only
is given.

The attached patch solves this issue.
Note that if the --source-only option is not given, the generated package will
be still architecture-dependent.
I'm not sure if this would be the correct behavior (from my understanding
should be the correct way, as it is including architecture-dependent binaries).

This bug is confirmed on dkms 2.6.1-4 (current version in buster).



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.utf8, LC_CTYPE=ca_ES.utf8 (charmap=UTF-8), 
LANGUAGE=ca_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dkms depends on:
ii  build-essential  12.6
ii  coreutils8.30-3
ii  dpkg-dev 1.19.7
ii  gcc  4:8.3.0-1
ii  kmod 26-1
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-amd64  4.19+105
ii  lsb-release  10.2019051400
ii  sudo 1.8.27-1

Versions of packages dkms suggests:
ii  menu2.1.47+b1
pn  python3-apport  

-- no debconf information
2979c2979,2983
< debian_build_arch=$(dpkg-architecture -qDEB_BUILD_ARCH)
---
> if [[ $source_only ]];then
> debian_build_arch=all
> else
> debian_build_arch=$(dpkg-architecture -qDEB_BUILD_ARCH)
> fi

Bug#931794: fwupd doesn't work because of latest logitech firmware

[Alf]

I am hit by the same error when trying to update my Logitech Unifying
Receiver (current Firmware RQR12.03_B0025).
This Update is higly recommended to fix some recent vulnerabilitis in
the Firmware, see
https://www.heise.de/ct/artikel/Logitech-keyboards-and-mice-vulnerable-to-extensive-cyber-attacks-4464533.html.

Therefore this bug should be tagged "securuty".

Bug#931889: package-supports-alternative-init-but-no-init.d-script way too aggressive

[Francesco Poli]

On Thu, 11 Jul 2019 23:19:00 +0200 Michael Biebl wrote:

> Package: lintian
> Version: 2.16.0
> Severity: normal
> 
> Hi,
> 
> in several of my packages I get a lintian error since a few days ago:
> package-supports-alternative-init-but-no-init.d-script
> All of them false positives.

Hello!
I am another package maintainer who has just been bitten by this bug.

> There are a lot of cases where a service ships a systemd service file
> but not a sysv init script:
[...]
> - crontab vs systemd.timer/systemd.service

In my package (apt-listbugs), I added a systemd timer unit equivalent
to the preexisting daily cron job, in response to a lintian
complaint (see bug [#927970]).
And a systemd timer unit requires a corresponding systemd service unit,
but does not implement a daemon.
And indeed apt-listbugs does not ship any daemons!

Lintian should not complain for something that was added in response to
another Lintian complaint!   ;-)

[#927970]: 

> 
> Given the high probability of false positives, please consider
> downgrading that lintian check to informal or even pedantic.

Not only that, please!

The new Lintian check should try hard to be more accurate: for
instance, it should look whether there is a corresponding timer unit
along with the service unit. If this is the case, it should not emit
any complaint at all!

I hope this bug can be fixed soon.

Thanks for your time.
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


pgpmvgcPSaCkj.pgp
Description: PGP signature

Bug#931945: metview: FTBFS with PROJ 6

[Bas Couwenberg]

Source: metview
Version: 5.3.0-2
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://jira.ecmwf.int/browse/SUP-2809

Kind Regards,

Bas
diff -Nru metview-5.3.0/debian/changelog metview-5.3.0/debian/changelog
--- metview-5.3.0/debian/changelog  2019-02-28 16:32:29.0 +0100
+++ metview-5.3.0/debian/changelog  2019-04-14 08:14:49.0 +0200
@@ -1,3 +1,10 @@
+metview (5.3.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H for PROJ 6.0.0 compatibility.
+
+ -- Bas Couwenberg   Sun, 14 Apr 2019 08:14:49 +0200
+
 metview (5.3.0-2) unstable; urgency=medium
 
   * Check correct $(MMODDIR) for grib_api.mod. Closes: #923453
diff -Nru metview-5.3.0/debian/rules metview-5.3.0/debian/rules
--- metview-5.3.0/debian/rules  2019-02-28 16:32:29.0 +0100
+++ metview-5.3.0/debian/rules  2019-04-14 08:14:47.0 +0200
@@ -3,6 +3,10 @@
 # Uncomment this to turn on verbose mode.
 # export DH_VERBOSE=1
 
+# Workaround for proj_api.h deprecation in PROJ 6.0.0
+export DEB_CFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+export DEB_CXXFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+
 # DEB_LDFLAGS_MAINT_PREPEND:= -Wl,-z,defs -Wl,--as-needed
 DEB_BUILD_MAINT_OPTIONS:= hardening=+all,-format
 DEB_CFLAGS_MAINT_APPEND:= -Wall -pedantic -fPIC

Bug#931944: vtk7: FTBFS with PROJ 6

[Bas Couwenberg]

Source: vtk7
Version: 7.1.1+dfsg1-12
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

Disabling the PROJ support was not an option as it was for vtk6. You may
want to reinstate the embedded copy and use that instead.

Upstream is aware of the issue, see:

 https://github.com/eclipse/sumo/issues/5299

Kind Regards,

Bas

Bug#931943: vtk6: FTBFS with PROJ 6

[Bas Couwenberg]

Source: vtk6
Version: 6.3.0+dfsg2-2
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by dropping the PROJ support.

Upstream is aware of the issue, see:

 https://gitlab.kitware.com/vtk/vtk/issues/17554

You may want to consider using the embedded copy in vtk6 if you do not
want to disable the PROJ support.

Kind Regards,

Bas
diff -Nru vtk6-6.3.0+dfsg2/debian/changelog vtk6-6.3.0+dfsg2/debian/changelog
--- vtk6-6.3.0+dfsg2/debian/changelog   2018-03-23 22:34:02.0 +0100
+++ vtk6-6.3.0+dfsg2/debian/changelog   2019-04-16 19:28:15.0 +0200
@@ -1,3 +1,10 @@
+vtk6 (6.3.0+dfsg2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable PROJ support, not compatible with version 6.
+
+ -- Bas Couwenberg   Tue, 16 Apr 2019 19:28:15 +0200
+
 vtk6 (6.3.0+dfsg2-2) unstable; urgency=medium
 
   * [20d58f6] d/rules: Set java src/trgt version Closes: #893789
diff -Nru vtk6-6.3.0+dfsg2/debian/patches/series 
vtk6-6.3.0+dfsg2/debian/patches/series
--- vtk6-6.3.0+dfsg2/debian/patches/series  2018-03-23 22:34:02.0 
+0100
+++ vtk6-6.3.0+dfsg2/debian/patches/series  2019-04-16 19:27:39.0 
+0200
@@ -11,7 +11,7 @@
 97_fix_latex_doxygen.patch
 100_javac-heap.patch
 101_java_install_path.patch
-102_enable_system_proj4_lib.patch
+#102_enable_system_proj4_lib.patch
 104_fix_gcc_version_6.patch
 105_unforce_embedded_glew.patch
 106_install_doxygen_scripts_in_nodoc_build.patch
diff -Nru vtk6-6.3.0+dfsg2/debian/rules vtk6-6.3.0+dfsg2/debian/rules
--- vtk6-6.3.0+dfsg2/debian/rules   2018-03-23 22:34:02.0 +0100
+++ vtk6-6.3.0+dfsg2/debian/rules   2019-04-16 19:27:50.0 +0200
@@ -44,7 +44,7 @@
-DVTK_USE_SYSTEM_HDF5=ON \
-DHDF5_PREFER_PARALLEL=ON \
-DVTK_USE_SYSTEM_JPEG=ON \
-   -DVTK_USE_SYSTEM_LIBPROJ4=ON \
+   -DVTK_USE_SYSTEM_LIBPROJ4=OFF \
-DVTK_USE_SYSTEM_LIBXML2=ON \
-DVTK_USE_SYSTEM_OGGTHEORA=ON \
-DVTK_USE_SYSTEM_PNG=ON \

Bug#931942: RFS: libonig/6.9.2-1

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

   Package name: libonig
   Version : 6.9.2-1
   Upstream Author : K.Kosako 
   URL : https://github.com/kkos/oniguruma
   License : BSD-2-clause
   Section : libs

  It builds those binary packages:

 libonig-dev - regular expressions library — development files
 libonig5- regular expressions library

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.2-1.dsc

or

  https://jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.2-1

  Changes since the last upload:

  * New upstream release:
- Refresh symbols file.
- Refresh debian/patches/0100-source_typos.patch.
  * Rewrite debain/watch.
  * New debian/patches/0105-CVE-2019-13224.patch and
  debian/patches/0110-CVE-2019-13225.patch (Closes: #931878):
- Fixes CVE-2019-13224 A use-after-free in onig_new_deluxe() in regext.c.
- Fixes CVE-2019-13225 A NULL Pointer Dereference in match_at()
   in regexec.c.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Bump minimum debhelper version in debian/control to >= 12.
- debian/rules: Remove obsolete dh_install --fail-missing.

The build with sbuild and pdebuild and the tests with Lintain and
Piuparts are ok:

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 29572
Build-Time: 28
Distribution: sid
Host Architecture: amd64
Install-Time: 35
Job: /data/entwicklung/linux/debian/libonig/libonig_6.9.2-1.dsc
Lintian: info
Machine Architecture: amd64
Package: libonig
Package-Time: 80
Piuparts: pass
Source-Version: 6.9.2-1
Space: 29572
Status: successful
Version: 6.9.2-1

Finished at 2019-07-12T17:20:07Z
Build needed 00:01:20, 29572k disk space


  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

Bug#931941: saga: FTBFS with PROJ 6 (update to 7.3.0)

[Bas Couwenberg]

Source: saga
Version: 2.3.1+dfsg-5
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental, because it still uses
projects.h which was removed in PROJ 6.0.0.

SAGA 7.3.0 has added support for proj.h, introduced in PROJ 5.0.0.

Please update the saga package to 7.3.x to fix this issue.

Kind Regards,

Bas

Bug#931940: sumo: FTBFS with PROJ 6

[Bas Couwenberg]

Source: sumo
Version: 1.1.0+dfsg1-1
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://github.com/eclipse/sumo/issues/5299

Kind Regards,

Bas
diff -Nru sumo-1.1.0+dfsg1/debian/changelog sumo-1.1.0+dfsg1/debian/changelog
--- sumo-1.1.0+dfsg1/debian/changelog   2019-02-03 10:17:52.0 +0100
+++ sumo-1.1.0+dfsg1/debian/changelog   2019-04-13 20:41:36.0 +0200
@@ -1,3 +1,10 @@
+sumo (1.1.0+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H for PROJ 6.0.0 compatibility.
+
+ -- Bas Couwenberg   Sat, 13 Apr 2019 20:41:36 +0200
+
 sumo (1.1.0+dfsg1-1) unstable; urgency=medium
 
   [ Michael Behrisch ]
diff -Nru sumo-1.1.0+dfsg1/debian/rules sumo-1.1.0+dfsg1/debian/rules
--- sumo-1.1.0+dfsg1/debian/rules   2019-02-03 10:05:51.0 +0100
+++ sumo-1.1.0+dfsg1/debian/rules   2019-04-13 20:41:34.0 +0200
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+# Workaround for proj_api.h deprecation in PROJ 6.0.0
+export DEB_CFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+export DEB_CXXFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+
 %:
dh $@
 

Bug#931910: Installation report with missing UEFI boot entry

[Steve McIntyre]

Control: reassign efibootmgr
Control: forcemerge -1 905319

On Fri, Jul 12, 2019 at 10:22:01AM +0200, Michael Hoffmann wrote:
>Package: installation-reports
>
>Boot method: DVD image on USB stick
>Image version: https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
>debian-10.0.0-amd64-DVD-1.iso
>Date: Fri, 09 Jul 2019 02:20:00 +0200
>
>Machine: Dell XPS 13 9360
>Processor: Intel Core i7
>Memory: 16GB
>Partitions: 
>
>Comments/Problems:
>
>No UEFI boot entries were installed and after reboot my laptop
>wouldn't boot. I managed to add a UEFI boot entry manually in the BIOS
>setup, after which everything works fine.
>
>I'm attaching syslog from /var/log/installer/

Hi Michael,

This sounds like you're seeing exactly the same problem as Helen
reported (and demonstrated to me) in #905319. The onboard nvme disk on
the Dell XPS machines apparently isn't properly mapped in the firmware
so that new EFI boot variables don't work. grub-install adds an entry
pointing at the first "hard disk" which should normally work on most
machines.

Pending a firmware fix, there is a workaround - install to the
removable media path too. See

  
https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

for more information. Merging the bugs...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal

[Joe Lobeck]

Dear Mantainer, 

in the meantime I found that the most things work form kernel 5.0 or higher.
Unfortunately so I will have to choose an other linux distribution as such a 
kernel
is for debian only from the experimantal repository avaiable.
If you have any other idea how to make debian stable or testing run with this 
hardware please let me know.

Kind regards,

Joe

Quoting joe :

> Package: general
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate
> ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> After normal installation of Debian Buster (Testing) with Default desktop
> the
> grub screen comes up and the system boots. When it normally switches to
> graphics mode it shows only a blinking cursor.
> After installing firmware-linux and rebooting the system does not show the
> blinking server, but a black screen and the monitor shows "No signal".
> Tested with 3 monitors.
> Afterwards reinstalled without "Default desktop".
> Now the system started ok and ended in the login.
> After installing firmware-linux unfortunately the system did not show the
> login
> after booting, but ended once again in a black screen (no Monitor signal).
> With
> nomodeset in grub I could start, but had to press "Ctrl + alt + F2" to go
> in
> the login as the system stopped after initializing the network card.
> So graphical interface is not possible with this hardware configuration and
> Debian 10 Buster.
> Normally Kernel 4.19... should be good enough for Vega 3 graphics. Live
> system
> (LXDE) fails as well with blinking cursor. "Lubuntu 19.04" does the job,
> but I
> do not like it and would appreciate if I could stay with Debian.
> 
> 
> 
> 
> -- System Information:
> Debian Release: 9.9
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Santiago Vila]

> > (The Debian version in turn had already a bunch of other changes to
> > fix other CVE issues and other misc fixes, I hope there are not
> > incompatibilities).
> 
> Well, apparently there is an incompatibility. I can make no promises about 
> applying those commits to an unzip source of unknown provenance.

I understand, that's why I also contacted Steven Schweda for the
zipbomb issue.

> Where do I find this source?

The source is distributed as the original tarball (which you already have)
plus this:

http://deb.debian.org/debian/pool/main/u/unzip/unzip_6.0-24.debian.tar.xz

[ We use quilt here. Patches are in debian/patches and they are applied
  sequentially in the order stated by debian/patches/series ].

Thanks.

Bug#926790: gnuradio: Filter design tool not working

[Thomas Lorblanchès]

Dear maintainer,

I was able to launch the filter design tool manually, and here is the error 
message: "Please install PyQt4 to run this script 
(http://www.riverbankcomputing.co.uk/software/pyqt/download)".

It seems that this is only a dependency problem: gnuradio in Stretch has a 
dependency on python-qt4, but this dependency was dropped in the Buster version 
of the package. Would it be possible to add it?

Regards,
Thomas

Bug#928032: Default configuration for USBGuard

[Birger Schacht]

Hi,

I'm currently working on packaging the 0.7.5 release of usbguard, which
was released a little more than a week ago. I have looked at the various
options we have to tackle the default configuration.

I agree that the prompts at installation time should be minimized, so
I'm not convinced of my initial idea of asking the user for the value of
ImplicitPolicyTarget et al anymore. Setting ImplicitPolicyTarget to
allow by default seems wrong to me- it would mean users would have to
manually configure the service to actually do what it is intended to do.

I was torn between the solution to generate a policy and setting
PresentDevicePolicy to `keep`. For now, I have configured the package to
generate a rules file using `usbguard generate-policy` if no rules file
exists - and I will also reenable the service. Thats also what upstream
suggests in the bug report mentioned by Thiébaud. But I am open to
change that to the PresentDevicePolicy solution if there happen to come
up problems with that default configuration.

Thanks Antoine also for the information about the `plugdev` group, I'll
add a patch adding that group to the IPCAllowedGroups setting.

cheers,
Birger

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Santiago Vila]

On Fri, Jul 12, 2019 at 04:32:53PM +, Adler, Mark wrote:
> Santiago,
> 
> Thank you for the report.
> 
> I downloaded the four false-positive zip files from the bugreport page, and 
> none of them showed a zip bomb error (or any other error).
> 
> How exactly did you apply the fix? Did you download the complete source from 
> github?
> Or did you try to selectively apply a commit?

I applied the commits I believed to be the fix for the zipbomb issue, i.e.
these two:

commit 41beb477c5744bc396fa1162ee0c14218ec12213
  Fix bug in undefer_input() that misplaced the input state.
commit 47b3ceae397d21bf822bc2ac73052a4b1daf8e1c
  Detect and reject a zip bomb using overlapped entries.

(The Debian version in turn had already a bunch of other changes to
fix other CVE issues and other misc fixes, I hope there are not
incompatibilities).

Thanks.

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Adler, Mark]

On Jul 12, 2019, at 9:43 AM, Santiago Vila  wrote:
> I applied the commits I believed to be the fix for the zipbomb issue, i.e.
> these two:
> 
> commit 41beb477c5744bc396fa1162ee0c14218ec12213
>  Fix bug in undefer_input() that misplaced the input state.
> commit 47b3ceae397d21bf822bc2ac73052a4b1daf8e1c
>  Detect and reject a zip bomb using overlapped entries.
> 
> (The Debian version in turn had already a bunch of other changes to
> fix other CVE issues and other misc fixes, I hope there are not
> incompatibilities).

Well, apparently there is an incompatibility. I can make no promises about 
applying those commits to an unzip source of unknown provenance.

Where do I find this source?

Bug#890215: valgrind causes miscalculation

[Vincent Lefevre]

Control: found -1 1:3.14.0-3

On 2018-02-12 03:34:55 +0100, Vincent Lefevre wrote:
> Dame problem on Debian GNU/Linux 8 (jessie) and 9 (stretch).
   Same

and ditto with the current stable version.

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

Bug#931939: O: acpitool -- command line ACPI client

[Michael Meskes]

Package: wnpp
Severity: normal

I intend to orphan the acpitool package.

The package description is:
 AcpiTool is a Linux ACPI client. It's a small command line application,
 intended to be a replacement for the apm tool. The primary target audience are
 laptop users, since these people are most interested in things like battery
 status, thermal status and the ability to suspend (sleep mode). The program
 simply accesses the /proc/acpi or /sysfs entries to get or set ACPI values.
 It also supports various extensions for Toshiba, Asus, and IBM Thinkpad
 laptops.

Michael

Bug#931881: diffoscope: undeclared versioned dependency on file

[Mattia Rizzolo]

On Fri, 12 Jul 2019, 6:09 pm Chris Lamb,  wrote:

>   * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS=''
> → Fails; the required version is missing and unlisted.
>
>   * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS="foo bar"
> → Fails; the required version is missing and unlisted.
>

These shouldn't fail.  As in, the program is present, but the required
version is missing.  That variable isn't holding versions after all.

At least, having that fail in this case wasn't my intention when I wrote
that thing.  If you went down that route it would make that
variable/setting unusable in any circumstance where simply the required
version is missing.

Having said all of this, I think we should make the failing test able to
run with either of the file versions.  `file` keeps changing and breaking
our tests, but it would be awful to only support running the testsuite with
the latest version available.

>
>

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Adler, Mark]

Santiago,

Thank you for the report.

I downloaded the four false-positive zip files from the bugreport page, and 
none of them showed a zip bomb error (or any other error).

How exactly did you apply the fix? Did you download the complete source from 
github? Or did you try to selectively apply a commit?

Mark


> On Jul 12, 2019, at 12:41 AM, Santiago Vila  wrote:
> 
> Hello.
> 
> I applied your fix for the zip bomb issue to the Debian unzip package
> and shortly afterwards I received this bug report from one of our users
> (Ben Caradoc-Davies, in the Cc).
> 
> (Note: Our BTS is email-based, but I could also put an issue on github
> if you prefer).
> 
> The full report is available here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895
> 
> Thanks.
> 
> - Forwarded message from Ben Caradoc-Davies  -
> 
> Date: Fri, 12 Jul 2019 11:52:14 +1200
> From: Ben Caradoc-Davies 
> To: Debian Bug Tracking System 
> Subject: Bug#931895: unzip: zip bomb false positives in Java ecosystem
> X-Mailer: reportbug 7.5.2
> 
> Package: unzip
> Version: 6.0-24
> Severity: normal
> 
> Dear Maintainer,
> 
> zip bomb detection introduced in 6.0-24 (see #931433
>  and CVE-2019-13232)
> causes unzip to reject many jar files distributed in the Java ecosystem.
> 
> Workaround is to downgrade to unzip 6.0-23.
> 
> Examples:
> 
> $ find .gradle .m2 java -name "*.jar" -type f -size +0c -print -exec unzip -tq
> {} \; 2>&1 | grep -B1 invalid
> .gradle/wrapper/dists/gradle-5.2.1-bin/9lc4nzslqh3ep7ml2tp68fk8s/gradle-5.2.1/lib/groovy-
> all-1.0-2.5.4.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/gradle-
> kotlin-dsl-5.4.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
> kotlin-dsl-tooling-builders-5.4.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/plugins/gradle-
> kotlin-dsl-provider-plugins-5.4.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .gradle/wrapper/dists/gradle-5.4.1-bin/e75iq110yv9r9wt1a6619x2xm/gradle-5.4.1/lib/groovy-
> all-1.0-2.5.4.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/ow2/asm/asm-tree/5.0.3/asm-tree-5.0.3-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/ow2/asm/asm-util/5.0.3/asm-util-5.0.3-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/ow2/asm/asm-analysis/5.0.3/asm-analysis-5.0.3-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-orm/4.2.5.RELEASE/spring-
> orm-4.2.5.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-orm/4.3.7.RELEASE/spring-
> orm-4.3.7.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-beans/4.3.16.RELEASE/spring-
> beans-4.3.16.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-beans/4.2.5.RELEASE/spring-
> beans-4.2.5.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-beans/4.3.18.RELEASE/spring-
> beans-4.3.18.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> .m2/repository/org/springframework/spring-beans/4.3.7.RELEASE/spring-
> beans-4.3.7.RELEASE-sources.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-tooling-builders-5.5.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> java/gradle-5.5.1/lib/plugins/gradle-kotlin-dsl-provider-plugins-5.5.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> --
> java/gradle-5.5.1/lib/gradle-kotlin-dsl-5.5.1.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> java/gradle-5.5.1/lib/groovy-all-1.0-2.5.4.jar
> error: invalid zip file with overlapped components (possible zip bomb)
> 
> Kind regards,
> Ben.
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU 

Bug#931938: claws-mail: unable to connect to IMAP server

[Baptiste Jammet]

Package: claws-mail
Version: 3.17.1-1~bpo9+1
Severity: normal

Dear Maintainer,

Since mid-june, claws-mail seems unable to connect to IMAP server.
To my local Courier server, I get a "stream error", but I can telnet to
it (and user/pass are OK) 
To a remote IMAP e-mail provider, I get a "connection refused", but I
can openssl s_client -connect imaps.lautre.net:993 (and user/pass are
OK)

I have the same results with claws-mail from stretch (3.14) and from
stretch-backports (3.17).
But an old stretch system (not updated since ~february) works as
wanted.

I have a --debug output if needed.

Thanks for any pointer to an explanation or a workaround, 
and thanks for maintaining claws-mail in Debian.

Baptiste

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

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

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcompfaceg11:1.5.2-5+b2
ii  libdb5.3 5.3.28-12+deb9u1
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-3
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.44+dfsg-5+deb9u2
ii  liblockfile1 1.14-1+b1
ii  libnettle6   3.3-1+b2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  librsvg2-2   2.40.16-1+b1
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libsm6   2:1.2.2-1+b3
ii  xdg-utils1.1.1-1+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages claws-mail recommends:
ii  aspell-fr [aspell-dictionary]  0.50-3-8
ii  claws-mail-i18n3.14.1-3
ii  xfonts-100dpi  1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  claws-mail-doc 3.14.1-3
pn  claws-mail-tools   
ii  dillo [www-browser]3.0.5-3
ii  firefox-esr [www-browser]  60.7.2esr-1~deb9u1
pn  gedit | kwrite | mousepad | nedit  
ii  midori [www-browser]   0.5.11-ds1-4+b1
ii  uzbl [www-browser] 0.0.0~git.20120514-1.2
ii  w3m [www-browser]  0.5.3-34+deb9u1

-- no debconf information

Bug#931878: libonig: CVE-2019-13224 CVE-2019-13225

[Salvatore Bonaccorso]

Hi Jörg!

On Fri, Jul 12, 2019 at 11:36:13AM +0200, Jörg Frings-Fürst wrote:
> tags 931878 +pending
> thanks
> 
> Hello Salvatore,
> 
> I have the libonig release 6.9.2 with both upstream fixes for the CVEs
> ready for upload.
> 
> It is uploaded to mentors[1] and into the git[2].
> 
> Should the upload of the package be handled by the security team? 
> Or can I take care of it myself? 

Those issues do not really warrant a DSA on it's own, cf.
security-tracker entries which were marked no-dsa already. But:

Ideally as first follows an unstable upload addressing those issues.

Then ideally, and time permitting for you, propose to stable release
managers an update for libonig fixing those issues isolalated for
upcoming point releases for buster and for stretch.

Cf. 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

Does this help?

Regards,
Salvatore

Bug#931881: diffoscope: undeclared versioned dependency on file

[Chris Lamb]

Hi Mattia,

> >  I think we need to add "file" to the DIFFOSCOPE_TESTS_MISSING_TOOLS
> >  list in debian/tests/pytest. Mattia, can you confirm?
[…]
> mh, no. I think some logic needs tweaking, as file is definitely 
> present (it's an hard dependency of diffoscope), and that test should 
> just be skipped.

I just went to hack on this but, hmm, isn't this providing exactly
what we need? :) ie. skipping these tests when run with a insufficiently
new version of file?

My testcase is to run:

  $ py.test-3 -rsx tests/test_presenters.py::test_text_proper_indentation

… within current sid (ie. src:file 5.35-4) and then by variously exporting:

  * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS=[unset]
→ Skipped correctly.

  * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS=''
→ Fails; the required version is missing and unlisted.

  * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS="foo bar" 
→ Fails; the required version is missing and unlisted.

  * DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS="foo bar file"
→ Skipped correctly.

What am I missing here? :) (Note that I renamed this variable in
d5b9daf04).


Best wishes,

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

Bug#931937: rust-rustyline: needs updates for new nix

[Gianfranco Costamagna]

Source: rust-rustyline
Version: 3.0.0-2
Severity: serious
tags: patch

http://launchpadlibrarian.net/432819385/rust-rustyline_3.0.0-2build1_3.0.0-2ubuntu1.diff.gz

Feel free to grab and apply :)

G.

Bug#931936: rust-sniffglue: needs updates for new nix

[Gianfranco Costamagna]

Source: rust-sniffglue
Version: 0.8.2-4
Severity: serious
tags: patch

https://launchpadlibrarian.net/432828997/rust-sniffglue_0.8.2-4_0.8.2-4ubuntu1.diff.gz

Feel free to grab and apply :)

G.

Bug#931934: RFS: sane-backends/1.0.27-4~experimental1

[Gianfranco Costamagna]

 control: owner -1 !control: tags -1 moreinfo
Hello Joerg!thanks for the update!
some nitpicks I would like to see fixed before having another deeper 
look:debian/libsane1.NEWSis it still needed?
sane-backends-1.0.27/debian/libsane.dirssane-backends-1.0.27/debian/libsane.symbolssane-backends-1.0.27/debian/libsane.install
last little thing: 
I don't want to start another flamerwar such as the one in #908681, I hope this 
time nobody will complain... :/
btw you can see the build with the changes I requested 
herehttp://debomatic-amd64.debian.net/distribution#experimental/sane-backends/1.0.27-4~experimental1/buildlog
(mostly, delete old libsane.* files, and remove the NEWS file)
feel free to grab the dsc once the build is over, and then fix if you see other 
lintian complains.
thanks!
G.


Il venerdì 12 luglio 2019, 16:48:24 CEST, Jörg Frings-Fürst 
 ha scritto:  
 
 Package: sponsorship-requests
Severity: normal 

  Dear mentors,

  I am looking for a sponsor for my package "sane-backends"

  Package name    : sane-backends
  Version        : 1.0.27-4~experimental1
  Upstream Author : sane-de...@alioth-lists.debian.net
  URL            : http://www.sane-project.org
  License        : GPL-2+ with sane exception, GPL-2+, Artistic, 
                    LGPL-2.1+
  Section        : graphics

  It builds those binary packages:

sane-utils    - API library for scanners -- utilities
libsane-common - API library for scanners -- documentation and support files
libsane1      - API library for scanners
libsane-dev    - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends


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

    dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.27-4~experimental1.dsc

or 

  https://jff.email/cgit/sane-backends.git/?h=release%2F1.0.27-4_experimental1


  Changes since the last upload:

  * debian/rules:
    - Add --exclude=/sane/ to override_dh_makeshlibs-arch to generate
      only public symbols (Closes: #911597).
    - Don't install obsolete hal fdi file (Closes: #913282).
  * Remove architecture dependent symbols files.
  * Merge release 1.0.27-3.2 into source tree.
    - I disagree the changes from 1.0.27-3.1.
    - Thanks to John Paul Adrian Glaubitz for the bug fix.
  * New debian/patches/0725-fix_link_60-libsane_rule.patch:
    - Fix directory for 20-sane.hwdb (Closes: #916239).
  * New debian/patches/0155-genesys_gl847.patch:
    - Fix discolored bar on GL847 chip based scanners (Closes: #912603).
  * Fix missing set device to group scanner (Closes: #918358);
    - New debian/99-libsane.rules.
    - debian/libsane.install: Install File into /etc/udev/rules.d/
    - Change debian/TROUBLESHOOTING.Debian
  * debian/sane-utils.config: Remove the RUN parameter in compliance with
    Debian Policy Manual section 9.3.3.1 (Closes: #915197).
  * debian/copyright:
    - Add year 2019 for debian/*.
    - Add missing Uploaders to debian/*.
  * Fix the lintian warning "libsane: package-name-doesnt-match-sonames
    libsane1":
    - debian/control: rename package libsane to libsane1.
    - debian/rules: Change filenames and directories from libsane to libsane1.
    - Rename debian/99-libsane.rules to debian/99-libsane1.rules.
  * Refresh debian/patches/0100-source_spelling.patch.
  * New debian/libsane-common.lintian-overrides and
    debian/libsane1.lintian-overrides to override false positive spelling-error.
  * Fix autopkgtest.
  * Migrate to debhelper 12:
    - Change debian/compat to 12.
    - Bump minimum debhelper version in debian/control to >= 12.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * New debian/sane-utils.lintian-overrides to override false positve missing
    init.d script.
  * debian/control: Add Pre-Depends ${misc:Pre-Depends} to install invoke-rc.d.


Build with sbuild and pdebuild and the tests with Lintain and Piuparts
are ok:

+--+
| Summary                                                                      |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 405228
Build-Time: 467
Distribution: sid
Host Architecture: amd64
Install-Time: 84
Job: 
/data/entwicklung/linux/debian/sane-backends/sane-backends_1.0.27-4~experimental1.dsc
Lintian: info
Machine Architecture: amd64
Package: sane-backends
Package-Time: 566
Piuparts: pass
Source-Version: 1.0.27-4~experimental1
Space: 405228
Status: successful
Version: 1.0.27-4~experimental1

Finished at 2019-07-12T13:02:53Z
Build needed 00:09:26, 405228k disk space


  Regards,
  Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 

Bug#931798: anki: The "Enter" key to save the audio rather than cancel the recording.

[Jury Mazurov]

Package: anki
Version: 2.1.8+dfsg-1
Followup-For: Bug #931798


> Thanks for this patch.  I've submitted it upstream, but it turns out
> that there's something stranger going on.  I've come up with a better
> patch; have a look at the upstream bug report to see more.

Dear Maintainer,

I looked at everything and used your solution.
Your solution fixes the problem.

Best wishes, Jury.

Bug#635834: texlive-latex-extra: dependency problem: fancytooltips requires acrotex which is not packaged

[Hilmar Preuße]

On 29.07.11 00:09, Adrian wrote:

Hi Norbert,

could you care about this and push acrotex into TeX Live upstream?
According to [1] it is LPPL, hence there should be no licensing issue.

Hilmar

[1] https://ctan.org/tex-archive/macros/latex/contrib/acrotex
> observed behaviour:
> failure to compile, error message
> ! LaTeX Error: File `eforms.sty' not found.
> 
> work-around:
> install acrotex from mirror.ctan.org into local TEXINPUTS path
> 
> conclusion: 
> The package itself is *not* broken (it's slightly outdated with respect 
> to the current version at CTAN, but that's another matter), but it 
> depends on additional software which is not available within the Debian 
> packaging system.
> 
> recommendation: 
> Either take fancytooltips out of texlive-latex-extra or (better) include 
> acrotex as well. The acrotex distribution licence is 'LaTeX Project 
> Public License, either version 1.2 of this license or (at your option) 
> any later version' according to the header of 
> http://mirrors.ircam.fr/pub/CTAN/macros/latex/contrib/acrotex/acrotex.ins
> 
> 
> -- Package-specific info:
> If you report an error when running one of the TeX-related binaries 
> (latex, pdftex, metafont,...), or if the bug is related to bad or wrong
> output, please include a MINIMAL example input file that produces the
> error in your report. 
> 
> Please run your example with
>   (pdf)latex -recorder ...
> (or any other program that supports -recorder) and send us the generated
> file with the extension .fls, it lists all the files loaded during
> the run and can easily explain problems induced by outdated files in
> your home directory.
> 
> Don't forget to also include minimal examples of other files that are 
> needed, e.g. bibtex databases. Often it also helps
> to include the logfile. Please, never send included pictures!
> 
> If your example file isn't short or produces more than one page of
> output (except when multiple pages are needed to show the problem),
> you can probably minimize it further. Instructions on how to do that
> can be found at
> 
> http://www.latex-einfuehrung.de/mini-en.html (english)
> 
> or 
> 
> http://www.latex-einfuehrung.de/mini.html (german)
> 
> ##
> minimal input file
> 
> \documentclass{article}
> 
> \usepackage{xcolor}% either xcolor or color required by fancytooltips
> \usepackage[filename=tooltips]{fancytooltips}
> 
> \begin{document}
> \end{document}
> 
> ##
> other files
> 
> % the complete output of pdflatex with the above minimal example as input
> 
> This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
> entering extended mode
> (./ttt.tex
> LaTeX2e <2009/09/24>
> Babel  and hyphenation patterns for english, usenglishmax, dumylang, 
> noh
> yphenation, loaded.
> (/usr/share/texmf-texlive/tex/latex/base/article.cls
> Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
> (/usr/share/texmf-texlive/tex/latex/base/size10.clo))
> (/usr/share/texmf/tex/latex/xcolor/xcolor.sty
> (/etc/texmf/tex/latex/config/color.cfg)
> (/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def))
> (/usr/share/texmf-texlive/tex/latex/fancytooltips/fancytooltips.sty
> (/usr/share/texmf-texlive/tex/latex/ms/everyshi.sty)
> (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
> (/etc/texmf/tex/latex/config/graphics.cfg)))
> (/usr/share/texmf-texlive/tex/latex/xkeyval/xkeyval.sty
> (/usr/share/texmf-texlive/tex/generic/xkeyval/xkeyval.tex))
> (/usr/share/texmf-texlive/tex/latex/eso-pic/eso-pic.sty)
> 
> ! LaTeX Error: File `eforms.sty' not found.
> 
> Type X to quit or  to proceed,
> or enter new name. (Default extension: sty)
> 
> Enter file name: x
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931935: openorienteering-mapper: FTBFS with PROJ 6

[Bas Couwenberg]

Source: openorienteering-mapper
Version: 0.8.4-1
Severity: important
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: proj-6

Dear Maintainer,

Your package FTBFS with PROJ 6 from experimental.

The attached patch fixes the issue by defining 
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H.

Note that this is only a temporary workaround, proj_api.h will be
removed in PROJ 7 scheduled for March 2020.

Upstream is aware of the issue, see:

 https://github.com/OpenOrienteering/mapper/issues/1214

Kind Regards,

Bas
diff -Nru openorienteering-mapper-0.8.4/debian/changelog 
openorienteering-mapper-0.8.4/debian/changelog
--- openorienteering-mapper-0.8.4/debian/changelog  2018-12-25 
12:21:02.0 +0100
+++ openorienteering-mapper-0.8.4/debian/changelog  2019-04-13 
18:22:32.0 +0200
@@ -1,3 +1,10 @@
+openorienteering-mapper (0.8.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H for PROJ 6.0.0 compatibility.
+
+ -- Bas Couwenberg   Sat, 13 Apr 2019 18:22:32 +0200
+
 openorienteering-mapper (0.8.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru openorienteering-mapper-0.8.4/debian/rules 
openorienteering-mapper-0.8.4/debian/rules
--- openorienteering-mapper-0.8.4/debian/rules  2018-12-25 10:59:12.0 
+0100
+++ openorienteering-mapper-0.8.4/debian/rules  2019-04-13 18:22:30.0 
+0200
@@ -3,6 +3,10 @@
 # output every command that modifies files on the build system.
 #DH_VERBOSE = 1
 
+# Workaround for proj_api.h deprecation in PROJ 6.0.0
+export DEB_CFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+export DEB_CXXFLAGS_MAINT_APPEND=-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H
+
 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/*
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk

Bug#931827: lighttpd: server returnd 400, if %C0 is included in the URL

[Tetsuji OHNO]

Hello!

Thank you for your reply and helpful advice.
I'm not good at English, so please forgive me even if I'm rude.

By commenting out all the recommended and highly recommended modules,
I confirmed that the server works without errors.
( I had to comment out ALL new modules. )

Maybe, that's enough for me. but I look forward to solving this behavior.

Thank you again!

T.O.

2019/7/12(Fri.) 21:13 Helmut Grohne :
>
> Hi,
>
> On Thu, Jul 11, 2019 at 02:38:19AM +0200, OHNO Tetsuji wrote:
> > lighttpd server is returnd ”400 Bad Request", if %C0 (or any other
> > char.) is included in the URL.
> >
> > for example,
> > http://localhost/index.lighttpd.html : return OK (display index page)
> > http://localhost/index.lighttpd.html?%C0 : 400 Bad Request
> > http://localhost/index.lighttpd.html?%C1 : 400 Bad Request
> > http://localhost/index.lighttpd.html?%C2 : OK
> >
> > I can't understand this behavior.
>
> Thank you for the detailed report. I don't fully understand this either
> and am thus Ccing Glenn Strauss (upstream).
>
> > -- Configuration Files:
>
> Thank you for including the configuration.
>
> > server.http-parseopts = (
> >   "header-strict"   => "enable",# default
> >   "host-strict" => "enable",# default
> >   "host-normalize"  => "enable",# default
> >   "url-normalize-unreserved"=> "enable",# recommended highly
> >   "url-normalize-required"  => "enable",# recommended
> >   "url-ctrls-reject"=> "enable",# recommended
> >   "url-path-2f-decode"  => "enable",# recommended highly (unless breaks 
> > app)
> >  #"url-path-2f-reject"  => "enable",
> >   "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks 
> > app)
> >  #"url-path-dotseg-reject"  => "enable",
> >  #"url-query-20-plus"   => "enable",# consistency in query string
> > )
>
> You are using the new parsing defaults that Glenn implemented for
> buster. I suspect that by changing one of these to disable, you can
> restore the previous behaviour. (<- workaround)
>
> I guess that the behaviour is connected to buffer_is_valid_UTF8 in some
> way. If you pass the decoded buffer to buffer_is_valid_UTF8 you get 0
> (invalid) for "\xc0" and for "\xc1", but not for "\xc2". However, those
> cases where buffer_is_valid_UTF8 is involved would typically result in a
> 502 code rather than 400, so maybe this is wrong.
>
> Glenn, can you comment on this?
>
> Helmut



-- 
OHNO, Tetsuji
E-mail: t2o...@gmail.com

Bug#926039: "fixme" package: missing layout files

[Hilmar Preuße]

On 30.03.19 18:43, Ryan Kavanagh wrote:

Hi Ryan,

> This package does not install all layout files for the fixme package.
> 
> For example, latex complains as follows on MWE below:
> 
> ! LaTeX Error: File `fxlayoutmarginclue.sty' not found.
> 
> This is not the expected behaviour, based on my understanding of §3.5.2
> of the FiXme manual (see: texdoc fixme).
> 
> ##
> minimal input file
> 
> \documentclass{minimal}
> \usepackage{fixme}
> \fxloadlayouts{marginclue}
> \begin{document}
> \end{document}
> 
Are you sure you're using that package correctly?

The reason why I ask is that the file is not provided by the upstream
package. I've downloaded the ins and the dtx file from CTAN, generated
the Style-Files, but there was no fxlayoutmarginclue.sty among them. So
this is either a bug in upstream, a doc bug or a mis-use by the end
user. My impression that "marginclue" is rather an option for the fixme
package itself, like this:

\documentclass{minimal}
\usepackage[marginclue]{fixme}
%\fxloadlayouts{marginclue}
\begin{document}
test
\end{document}

However I'm not a user of fixme, hence I can't finally decide.

Please tell us, which of the three cases above we're looking at and call
back then.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#927165: More details

[Narcis Garcia]

I don't find today any filed bug about this in gnome-disks tracker:
https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues
and I'm not finding the way to register a user account to file a new bug
report there.

I've made some testing and bug seems only reproducible with LUKS2
formatted volumes. LUKS1 ones work perfectly, and gnome-disks by default
uses LUKS1 when creating new encrypted volumes.

I believe main problematic scenarios are:

1. When using gnome-disks to change passphrase for volumes created
during OS installation (Buster's DebianInstaller formats in LUKS2, and
no one of Cyril's proposals have been implemented, as expert install
question or kernel line option)

2. When using gnome-disks to change passphrase for volumes created with
other software, and user doesn't care about LUKS version.

Easiest solutions seem to be now:

A) Switching back DebianInstaller to use LUKS1 by default.

B) Not including buggy gnome-disk-utility in repositories, until Gnome's
bug is solved.

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

[Julian Andres Klode]

On Tue, Jul 09, 2019 at 03:31:07PM +0200, David Kalnischkies wrote:
> On Mon, Jul 08, 2019 at 12:19:36PM +0200, Julian Andres Klode wrote:
> > Anyway, this was not my thing so I might be misrepresenting or missing
> > things :)
> 
> First of all: I am happy that I still manage to "break the world" (FSVO
> world) – in other words that is "my thing" , but I mostly forgot about
> it as it was implemented two years ago at the start of the last
> release cycle so that everyone would have enough time to cry at me …
> worked brilliantly I guess… 
> 
> Anyway, that apt is enforcing the metadata isn't changing is a security
> feature in that if you don't check an attacker can reply to a request to
> foo-security with foo – perfectly signed and everything so apt has no
> chance to detect this and the user believes everything is fine – even
> seeing files downloaded from -security – while the user never receives
> data for -security. foo has no Valid-Until header so the attacker can
> keep that up for basically ever. Compared to that serving old versions
> of -security itself is guarded by Valid-Until. Not serving any data has
> basically the same result, but the errors involved might eventually
> raise some alarm bells. So that is a good strategy to keep you from ever
> installing security upgrades.

This should not happen silently, as there'll be a warning that the
name of the distro in the sources.list entry matches neither Codename
nor Suite. 

We also can't do a rollback attack from current testing to an older
testing either, as the Date is not allowed to roll backwards.

I'm not convinced we are adding any actual security here - we should
just upgrade the warning for name mismatch between sources.list and
Release file to an error for that.


> So, after establishing that metadata shouldn't change all the time, lets
> look at the individual metadata pieces. Th recent thread on (not) using
> suite/codename/version to refer to a release is not only done in
> documentation and sources.list, but also in configuration for example in
> apt_preferences (which apt could check theoretically) and unattended-
> upgrades (which apt can't realistically check). Many of these
> configuration pieces for break silently and/or run guard automatic
> processes.
> 
> People are also not very consistent in that they refer to an release in
> different ways depending on the situation: While the sources.list might
> refer to buster, the config for unattended upgrades could easily refer
> to packages from stable to install automatically.
> 
> 
> A) For a user with "debian stable" in sources.list the change of the
> Codename from buster to bullseye is a giant leap which should not
> be done carelessly or even automatically in the background.

That's true, but leaving the user stranded without updates is not
helpful either.

Regarding the automatic upgrades: It seems that unattended-upgrades
only considers upgrades that match the system's codename, so it won't
automatically upgrade you to a new release.

> 
> B) For a user with "debian buster" in sources.list the change of the
> Suite from e.g. stable to oldstable is an important event as well; not
> right at this moment as there is a grace period, but security support is
> about to end and plans should be set in motion on how to deal with that.

It's not an important enough change to starve them from further security
updates until they acknowledge it.

> A Release file can declare that it will "soon" change its the value of
> a field to foo and apt clients can notify users about this so
> they can prepare (or, for that matter help testing if they feel like
> it). In exchange, if the change happens and apt knows it announced it
> before it can choose to accept the change without explicit user
> confirmation & I would propose enabling that for the Suite field.
> 
> 
> So, lets see how that might look for Debian buster if I "will have had"
> deployed a time machine:
> 
> On 2019-06-11, perhaps a bit earlier:
> 
> $ cat buster/Release
> Codename: buster
> Future-Codename: bullseye
> Suite: testing
> Future-Suite: stable
> Future-Version: 10.0
> Future-Release-Notes: https://example.org/preparing-for-buster

It turns out the only reasonable point in time to do that is during release,
that is, stable would always contain Future-Suite: oldstable (and similar for
others). Two reasons:

* It's super annoying having to do those changes for all releases at like
  freeze time
* If your machine was offline in the time between adding Future and the
  new stable release, it will still be broken.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#631715: unattended-upgrades: Sends base64-encoded MIME message when message is long

[Balint Reczey]

Control: notfound -1 0.62.2
Control: tags -1 unreproducible

Hi,

I'm pretty sure this is not a bug in unattended-upgrades.
Currently the email headers in autopkgtest runs look like this:

>From root@ci-1562886795 Thu Jul 11 23:48:16 2019
Return-path: 
Envelope-to: root@ci-1562886795
Delivery-date: Thu, 11 Jul 2019 23:48:16 +
Received: from root by ci-1562886795 with local (Exim 4.90_RC3)
(envelope-from )
id 1hlinQ-0007WZ-BF
for root@ci-1562886795; Thu, 11 Jul 2019 23:48:16 +
Subject: [package on hold] unattended-upgrades result for ci-1562886795: SUCCESS
To: root@ci-1562886795
Auto-Submitted: auto-generated
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: root 
Message-Id: 
Date: Thu, 11 Jul 2019 23:48:16 +

Unattended upgrade result: All upgrades installed
...

The problem you reported is probably the result of local configuration.

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#931934: RFS: sane-backends/1.0.27-4~experimental1

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal 

  Dear mentors,

  I am looking for a sponsor for my package "sane-backends"

   Package name: sane-backends
   Version : 1.0.27-4~experimental1
   Upstream Author : sane-de...@alioth-lists.debian.net
   URL : http://www.sane-project.org
   License : GPL-2+ with sane exception, GPL-2+, Artistic, 
 LGPL-2.1+
   Section : graphics

  It builds those binary packages:

sane-utils - API library for scanners -- utilities
libsane-common - API library for scanners -- documentation and support files
libsane1   - API library for scanners
libsane-dev- API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.27-4~experimental1.dsc

or 

  https://jff.email/cgit/sane-backends.git/?h=release%2F1.0.27-4_experimental1


  Changes since the last upload:

  * debian/rules:
- Add --exclude=/sane/ to override_dh_makeshlibs-arch to generate
  only public symbols (Closes: #911597).
- Don't install obsolete hal fdi file (Closes: #913282).
  * Remove architecture dependent symbols files.
  * Merge release 1.0.27-3.2 into source tree.
- I disagree the changes from 1.0.27-3.1.
- Thanks to John Paul Adrian Glaubitz for the bug fix.
  * New debian/patches/0725-fix_link_60-libsane_rule.patch:
- Fix directory for 20-sane.hwdb (Closes: #916239).
  * New debian/patches/0155-genesys_gl847.patch:
- Fix discolored bar on GL847 chip based scanners (Closes: #912603).
  * Fix missing set device to group scanner (Closes: #918358);
- New debian/99-libsane.rules.
- debian/libsane.install: Install File into /etc/udev/rules.d/
- Change debian/TROUBLESHOOTING.Debian
  * debian/sane-utils.config: Remove the RUN parameter in compliance with
Debian Policy Manual section 9.3.3.1 (Closes: #915197).
  * debian/copyright:
- Add year 2019 for debian/*.
- Add missing Uploaders to debian/*.
  * Fix the lintian warning "libsane: package-name-doesnt-match-sonames
libsane1":
- debian/control: rename package libsane to libsane1.
- debian/rules: Change filenames and directories from libsane to libsane1.
- Rename debian/99-libsane.rules to debian/99-libsane1.rules.
  * Refresh debian/patches/0100-source_spelling.patch.
  * New debian/libsane-common.lintian-overrides and
debian/libsane1.lintian-overrides to override false positive spelling-error.
  * Fix autopkgtest.
  * Migrate to debhelper 12:
- Change debian/compat to 12.
- Bump minimum debhelper version in debian/control to >= 12.
  * Declare compliance with Debian Policy 4.4.0 (No changes needed).
  * New debian/sane-utils.lintian-overrides to override false positve missing
init.d script.
  * debian/control: Add Pre-Depends ${misc:Pre-Depends} to install invoke-rc.d.


Build with sbuild and pdebuild and the tests with Lintain and Piuparts
are ok:

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 405228
Build-Time: 467
Distribution: sid
Host Architecture: amd64
Install-Time: 84
Job: 
/data/entwicklung/linux/debian/sane-backends/sane-backends_1.0.27-4~experimental1.dsc
Lintian: info
Machine Architecture: amd64
Package: sane-backends
Package-Time: 566
Piuparts: pass
Source-Version: 1.0.27-4~experimental1
Space: 405228
Status: successful
Version: 1.0.27-4~experimental1

Finished at 2019-07-12T13:02:53Z
Build needed 00:09:26, 405228k disk space


  Regards,
   Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

Bug#701604: gkermit: cobwebby package description

[Justin B Rye]

Package: gkermit
Version: 1.0-10
Followup-For: Bug #701604

This bug should probably be merged with 732938.

> The package description for gkermit needs some routine maintenance.

This is gradually rising from the level of "routine", but not enough
to change the severity quite yet.
 
>>  [...]  The non-free package ckermit adds connection
>>  establishment, character-set translation and scripting features.

ckermit no longer even exists in stable/testing/unstable, so there's
no point comparing the two in this package description; my patch needs
a rewrite.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- control.pristine	2019-07-12 14:40:37.618636024 +0100
+++ control	2019-07-12 14:44:24.596388439 +0100
@@ -8,7 +8,6 @@
 Package: gkermit
 Architecture: any
 Depends: ${shlibs:Depends}
-Description: A serial and network communications package
- G-Kermit is a GPL'd kermit package. It offers medium-independent terminal
- session and file transfer. The non-free package ckermit adds connection
- establishment, character-set translation and scripting features.
+Description: GNU Kermit file transfer program
+ G-Kermit can serve as an endpoint for the Kermit protocol, supporting
+ text and binary file transfers on 7- and 8-bit serial connections.

Bug#931913: [Aptitude-devel] Bug#931913: aptitude: The certificate is NOT trusted when using https to fetch packages from security.debian.org in buster

[J. L. Lee]

Hi Axel,

Well done.

Regards,
JL


On 12/7/19 8:56 PM, Axel Beckert wrote:

Hi J.L.,

J. L. Lee wrote:

In this case, Debian Wiki page on SourcesList
(https://wiki.debian.org/SourcesList) needs to be rephrased slightly.

Thanks for this hint!

Done now: https://wiki.debian.org/SourcesList?action=diff=88=89

Regards, Axel

Bug#931819: Remove weak_crypto code

[Benjamin Kaduk]

On Wed, Jul 10, 2019 at 04:05:39PM -0400, Sam Hartman wrote:
> Hi.
> In krb5 1.17-4, DES is entirely removed.
> 
> src/aklog/aklog.c makes it look like openafs still requires
> des-cbc-crc.  If so, please upgrade this bug to RC.
> Kaduk thinks that's probably not the case though.
> 
> If not, please consider removing the weak_crypto code at this point.

https://gerrit.openafs.org/13689 has the first step at getting rid of
the weak crypto code (disable it by default and require opt-in if
there are stragglers using it).

-Ben

Bug#931807: libwebkit2gtk-4.0-37: JavaScript code fails without error message on ppc64el and s390x

[Alberto Garcia]

Control: reassign -1 libjavascriptcoregtk-4.0-18 2.24.3-1
Control: retitle -1 libjavascriptcoregtk-4.0-18: segfaults on powerpc64 and 
s390x

On Wed, Jul 10, 2019 at 09:54:59PM +0300, Dmitry Shachnev wrote:
>   for (var i = 0; i < 2; i++) {
> var foo = {};
> foo.bar = null;
>   }

Thank you very much for the test case. I can reproduce the bug easily
by saving that code to a file and running it with /usr/bin/jsc

Berto

Bug#920119: ITA: agrep -- text search tool with support for approximate patterns

[Roland Rosenfeld]

retitle 920119 ITA: agrep -- text search tool with support for approximate 
patterns
owner Roland Rosenfeld 
stop

I intent to adopt the agrep package.

As a first step I intent do merge all existing sources (alioth GIT
including some unpublished changes by Jari Alto) and move to salsa.

After this an update to 4.18.6 from the webglimpse is planned.

Also the move from non-free to main based on the ISC license (see
#827902).


And as a further option I think about moving from the glimpse version
to the https://github.com/Wikinaut/agrep fork (using a different
version numbering scheme, currently at 3.41.5/TG), but I'm not fully
sure, weather this is the optimal way, since both versions are far
away from each other and I do not yet understand which one is the
better one.

Greetings
Roland


signature.asc
Description: PGP signature

Bug#931933: Debian 10.0 sid hppa refuses to boot on HP C8000:

[Alex Ernst]

Package: kernel-package


Debian 10.0 sid hppa refuses to boot on HP C8000:

palo ipl 2.00 http://www.parisc-linux.org - Mon, 01 Jan 2018 21:07:58 +0100

Boot image contains:
0/vmlinux32 3051144(0) bytes @ 0xf9c800
0/vmlinux64 4083216(0) bytes @ 0x1285800
0/ramdisk 15425064 bytes @ 0xdb800

Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).

Command line for kernel: ' console=ttyS0 TERM=vt102 palo_kernel=0/vmlinuz'
Selected kernel: /vmlinuz from partition 0
Selected ramdisk: /ramdisk from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing
64-bit kernel
ELF64 executable

Entry 000e first 000e n 2
Segment 0 load 000e size 1240 mediaptr 0x1000
Segment 1 load 0140 size 4069188 mediaptr 0x2000
Loading ramdisk 15425064 bytes @ 3f139000...
Branching to kernel entry point 0x000e.  If this is the last
message you see, you may need to switch your console.  This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org

Uncompressing ...
Booting kernel ...
[0.00] Linux version 4.19.0-5-parisc64-smp (
debian-ker...@lists.debian.org) (gcc version 8.3.0 (GCC)) #1 SMP Debian
4.19.37-5 (2019-06-19)
[0.00] CPU0: thread -1, cpu 0, socket 0
[0.00] FP[0] enabled: Rev 1 Model 20
[0.00] The 64-bit Kernel has started...
[0.00] Kernel default page size is 4 KB. Huge pages enabled with 1
MB physical and 2 MB virtual size.
[0.00] bootconsole [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: 64 bit PAT.
[0.00] PAT: Running on cell 0 and location 1.
[0.00] model 88b0 0491  0002 5680c2cb53677fcd
10f0 0008 00b2 00b2
[0.00] vers  0302
[0.00] CPUID vers 20 rev 5 (0x0285)
[0.00] capabilities 0x35
[0.00] model 9000/785/C8000
[0.00] parisc_cache_init: Only equivalent aliasing supported!
[0.00] Memory Ranges:
[0.00]  0) Start 0x End 0x3fff Size
1024 MB
[0.00]  1) Start 0x0001 End 0x0002ffdf Size
8190 MB
[0.00]  2) Start 0x00404000 End 0x0040 Size
3072 MB
[0.00] Total Memory: 12286 MB
[0.00] initrd: 7f139000-7ffeee28
[0.00] initrd: reserving 3f139000-3ffeee28 (mem_max 2ffe0)
[0.00] PDT: type PDT_PAT_NEW, size 3000, entries 1, status 0,
dbe_loc 0x1c8a8ad00, good_mem 0 MB
[0.00] PDT: Firmware reports 1 entries of faulty memory:
[0.00] PDT: BAD MEMORY at 0x1c8a8ad00, DIMM slot 2a, permanent
multi-bit error.
[0.00] percpu: Embedded 27 pages/cpu s72576 r8192 d29824 u110592
[0.00] SMP: bootstrap CPU ID is 0
[0.00] Built 3 zonelists, mobility grouping on.  Total pages:
3096072
[0.00] Kernel command line:  console=ttyS0 TERM=vt102
palo_kernel=0/vmlinuz
[0.00] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608
bytes)
[0.00] Memory: 12299672K/12580864K available (11244K kernel code,
4460K rwdata, 1475K rodata, 1024K init, 816K bss, 281192K reserved, 0K
cma-reserved)
[0.00] random: get_random_u64 called from
__kmem_cache_create+0xd4/0xac8 with crng_init=0
[0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=8, Nodes=8
[0.00] rcu: Hierarchical RCU implementation.
[0.00] NR_IRQS: 128
[0.10] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every
4398046511103ns
[0.107172] Console: colour dummy device 160x64
[0.167145] Calibrating delay loop... 1988.60 BogoMIPS (lpj=3977216)
[0.283152] pid_max: default: 32768 minimum: 301
[0.347535] Security Framework initialized
[0.399167] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.487328] AppArmor: AppArmor initialized
[0.543613] Mount-cache hash table entries: 32768 (order: 6, 262144
bytes)
[0.635198] Mountpoint-cache hash table entries: 32768 (order: 6, 262144
bytes)
[0.734588] rcu: Hierarchical SRCU implementation.
[0.800331] smp: Bringing up secondary CPUs ...
[0.859164] smp: Brought up 3 nodes, 1 CPU
[0.919323] devtmpfs: initialized
[0.965657] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 764504178510 ns
[1.091214] futex hash table entries: 2048 (order: 4, 65536 bytes)
[1.187584] NET: Registered protocol family 16
[1.247402] audit: initializing netlink subsys (disabled)
[1.319316] audit: type=2000 audit(1562938915.316:1): state=initialized
audit_enabled=0 res=1
[1.431962] EISA bus registered
[1.471262] Searching for devices...
[1.627160] Found devices:
[1.659169] 1. Crestone Peak Fast? at 0xfe78 [128] { 0, 0x0,
0x88b, 0x4 }
[1.767166] 2. Crestone 

Bug#931932: CVE-2019-13574

[Moritz Muehlenhoff]

Package: ruby-mini-magick
Severity: grave
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13574

Cheers,
Moritz