Bug#945283: users should check whether they get same packages as all other users get

[Simon Richter]

Hi,

On Fri, Nov 22, 2019 at 03:20:45PM +0300, dinar qurbanov wrote:

> so, in order to serve a package with malware to a
> user, disrtribution/repository admins would have to also serve wrong
> "packages" and "release" files to him. so, if user checks the
> "release" file, that it is ok, enough, he can be sure that packages
> are also ok.

There is also the Release.gpg and InRelease files, which contain a PGP
signature for the data in the Release file, anchoring the trust chain in a
public key distributed inside the Debian installer, so an attacker cannot
generate a Release file that will be accepted by apt.

It is possible to delay updates by several days as apt accepts older
timestamps on Release files, precisely so out-of-date mirrors can be used
for noncritical updates. The security updates are distributed centrally,
and the timestamp on those files is checked more stringently (the Release
file on the security mirror has a Valid-Until field, after that time apt
requires that package lists are refreshed).

> from point of view of users, debian
> may have to send malware to some users by government request. if to
> say about all distributions, there may be malicious distributions.

There is only one central point by which packages enter the mirror network,
so comparing packages across mirrors does not give any advantage. If the
central point is compromised, all mirrors are, if individual mirrors are
compromised, these are unable to serve packages at all, because they do not
have a valid signed Release file.

   Simon

Bug#945206: tracker.debian.org: Broken binaries link in glibc page

[Guillem Jover]

On Fri, 2019-11-22 at 09:09:20 +0100, Raphael Hertzog wrote:
> On Thu, 21 Nov 2019, Alexandros Prekates wrote:
> > Visiting https://tracker.debian.org/pkg/glibc
> > i noticed many dead links in the binaries section
> > of the page.
> 
> Those are binary packages that the glibc source package can build but that
> it only builds on non-release architectures... so indeed the binary
> packages are unknown by packages.debian.org which only knows about
> packages available on official mirrors.
> 
> And the list of binary packages is currently taken from the "Binary" field
> in the .dsc and there we don't have any detail about architecture support,
> etc.
> 
> The tracker also doesn't scan all architectures currently (for performance
> reasons) so it doesn't know which binary packages do really exist across
> all architectures.

These could be switched to use the Package-List field instead, which
contains this information.

Thanks,
Guillem

Bug#945288: ITP: prettyping -- A better ping tool based on iputils-ping

[think vifly]

Package: wnpp
Severity: wishlist

description: prettyping is a wrapper around the standard ping tool with the
objective of making the output prettier, more colorful, more compact, and
easier to read.
source code URL: https://github.com/denilsonsa/prettyping
LICENSE: MIT

Bug#945292: lightdm: needlessly(?) build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Source: lightdm
Version: 1.26.0-6
Severity: normal

Dear Maintainer,

I'm tired. Your package already build-depends on yelp-tools so I'm
going to just assume that the gnome-doc-utils build-dependency is
a leftover from before switching to yelp/itstool. I don't have the
energy left to build-test this for you. This message brought to you
because gnome-doc-utils has been deprecated for > 5 years and might
not survive to bullseye release because of the python2 removal.

Please drop the gnome-doc-utils build-dependency if it's not needed
(and if it is, please find another option soon).

Regards,
Andreas Henriksson

Bug#945066: buster-pu: package enigmail/2:2.1.3+ds1-4~deb10u1

[Adam D. Barratt]

On 2019-11-22 12:15, Jonas Meurer wrote:

Hello,

On Tue, 19 Nov 2019 17:11:05 +0800 Daniel Kahn Gillmor
 wrote:

thunderbird 68 is now in buster-new and in security.debian.org

sadly, the enigmail upstream versions are closely tied to the
thunderbird versions.  (enigmail 2.0.x works with TB 60, but 2.1.x 
works

with TB 68)  See https://bugs.debian.org/945014 for more details.

I'm proposing to upgrade the version of enigmail in buster to match 
the

new version of thunderbird.


Thanks a lot, Daniel!

Would be very nice to get this into Buster rather soon.


As a point of detail, we just had a point release, so no changes are 
happening to buster for a couple of months or so. (I'm aware that 
-updates exists, obviously.)



At the moment,
enigmail users either have to continue using a Thunderbird version with
known security vulnerabilities or have to uninstall enigmail (and
install the upstream version of Enigmail, which has its own drawbacks).


I was told on IRC that the plan was for this update to be released via 
the security archive.


Daniel, could you clarify, please?

Regards,

Adam

Bug#941803: debian-policy: dependencies on font packages

[Russ Allbery]

Julien Cristau  writes:

> I don't think this change is good as-is.  The "don't depend on X font
> packages" is still very much relevant, for applications that use the
> "traditional" X font system, where the X server loads the fonts.  The X
> server can still be on a different machine from the client.

Argh, you are of course entirely correct, so I think this change may be
wrong.  I just tested and indeed traditional bitmap fonts are still loaded
from the X server, not from the client.  I had thought I'd tested that
before but tested it incorrectly.

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

Bug#945297: direwolf: Missing architectures in the whitelist

[Adrian Bunk]

Source: direwolf
Version: 1.5+dfsg-3
Severity: normal

The following "new" architectures are also little endian:
mips64el
ia64
riscv64

Bug#945291: krb5-auth-dialog: needlessly build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Package: krb5-auth-dialog
Version: 3.26.1-2
Severity: normal
Tags: bullseye sid

Dear Maintainer,

I'm looking at reducing the reverse dependencies of gnome-doc-utils as
it's been deprecated for >5 years and found this in your packages
upstream ChangeLog:

"Use yelp-tools instead of gnome-doc-utils"

I stopped investigating there as it seems already clear that the
build-dependency on gnome-doc-utils is very likely obsolete.

Curiously I don't see a build-dependency on yelp-tools in your package.
Maybe something else drags it in? If so you might want to add an
explicit build-dependency on it. (Oh, I see now you have itstool in
build-deps. That might be enough and explain it.)

Regards,
Andreas Henriksson

Bug#932484: isso gives 404 when started via systemd

[Jelmer Vernooij]

That sounds great.

On 22 November 2019 08:27:12 GMT-08:00, Jonathan Watt  wrote:
>Perhaps it would be best to have separate 'isso' and 'isso-multi'
>systemd units?
>
>Additionally, is there somewhere that documents setting up Isso with
>the current
>unit? I guess maybe the man page (although that doesn't really contain
>anything
>useful right now)? How would I go about submitting changes for that?

Bug#925337: fixed in ublock-origin 1.22.2+dfsg-1~deb9u1

[Markus Koschany]

Hello,

You have to enable the -proposed-updates archive in Stretch to download
the latest version of ublock-origin. It will be merged to stable
eventually.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#945115: armagetronad does not find itself (and fails to start)

[Markus Koschany]

Control: tags -1 pending

Am 20.11.19 um 14:45 schrieb Bernhard Übelacker:
> Control: tags -1 + upstream fixed-upstream patch
> 
> 
> Dear Maintainer,
> the issue seems to be with newer gcc versions string literals
> get not put into memory mappings " r-xp ",
> instead they are mapped " r--p ".
> 
> Such a string literal is used to determine the location
> of the executable.
> 
> Upstream fixed it already [1] [2].
> The issue points also to a fallback if reading from
> memory fails, which might be worth to consider [3].
> 
> Kind regards,
> Bernhard
> 
> 
> [1] https://gitlab.com/armagetronad/armagetronad/issues/6
> [2] 
> https://gitlab.com/armagetronad/armagetronad/commit/aad48287a98d32112c8600ee8d1b96de25500987
> [3] 
> https://gitlab.com/armagetronad/armagetronad/commit/90036a889d6ca9fbcf4ce950e0e803eb2204e06b

Thanks for reporting. A upload is pending which will address this issue.

Best,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Simon McVittie]

On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote:
> I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1

It doesn't, but its dh_installsystemd integration currently does, so
maintainer scripts relying on it would currently be buggy. I think it
would be premature to recommend systemd-tmpfiles in Policy before it can
be used in a non-buggy way.

I had also thought that, in the current state of non-systemd-init-world,
having a dependency on a package containing systemd-tmpfiles was likely
to be practically problematic because it would indirectly conflict
with elogind, via libsystemd0 and its elogind reimplementation - but
looking more closely, systemd-tmpfiles and systemd-sysusers depend on
/lib/systemd/libsystemd-shared-243.so (and not on libsystemd0) so that
shouldn't actually be a problem.

smcv

Bug#945289: grub-common: grub-mount stuck on lvm snapshot partition

[Bruno Muller]

Package: grub-common
Version: 2.04-4
Severity: normal

Dear Maintainer,

I'm doing tests to use LVM snapshots to go back in case of apt dist-upgrade
errors and I'm having a problem when a new kernel version is installed:
I can not remove the snapshot because of a grub-mount.

You can reproduce the problem as follows:

root@sid:~# lvcreate -s -n snap -l 100%FREE /dev/sid-vg/root
  Logical volume "snap" created.
root@sid:~# dpkg-reconfigure linux-image-5.3.0-2-amd64 
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.3.0-2-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.3.0-2-amd64
Found initrd image: /boot/initrd.img-5.3.0-2-amd64
Found linux image: /boot/vmlinuz-4.19.0-6-amd64
Found initrd image: /boot/initrd.img-4.19.0-6-amd64
grub-probe : erreur : système de fichiers inconnu.
/usr/sbin/grub-probe : erreur : système de fichiers inconnu.
Found Debian GNU/Linux bullseye/sid on /dev/mapper/sid--vg-snap
done
root@sid:~# lvremove -f /dev/sid-vg/snap
  Logical volume sid-vg/snap in use.
root@sid:~# lsblk
NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr011:01 1024M  0 rom  
vda   254:00   20G  0 disk 
├─vda1254:10  243M  0 part /boot
├─vda2254:201K  0 part 
└─vda5254:50 19,8G  0 part 
  ├─sid--vg-swap_1253:104G  0 lvm  [SWAP]
  ├─sid--vg-root-real 253:20 11,8G  0 lvm  
  │ ├─sid--vg-root253:00 11,8G  0 lvm  /
  │ └─sid--vg-snap253:40 11,8G  0 lvm  
  └─sid--vg-snap-cow  253:304G  0 lvm  
└─sid--vg-snap253:40 11,8G  0 lvm
root@sid:~# lsof | grep 253,4
grub-moun 5276   root3r  BLK  253,4 
0t37715968  19527 /dev/dm-4
root@sid:~# ps auxww | grep 5276
root5276  0.0  0.0  11652  1744 ?Ss   16:17   0:00 grub-mount 
/dev/mapper/sid--vg-snap /var/lib/os-prober/mount
root5316  0.0  0.0   6084   912 pts/0S+   16:19   0:00 grep 5276
root@sid:~# kill 5276
root@sid:~# lvremove -f /dev/sid-vg/snap
  Logical volume "snap" successfully removed

Tell me if you need more information or if I can help you.
Thank you

Bruno Muller



-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/sid--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/vda1 /boot ext2 rw,relatime 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set 
root='lvmid/zHGMST-NX0C-Z5M1-hGW3-QDh9-Aaz1-ZcD7yn/mMOtdU-ITzf-3BOX-PaEG-R3rv-RHYw-WHNVVu'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/zHGMST-NX0C-Z5M1-hGW3-QDh9-Aaz1-ZcD7yn/mMOtdU-ITzf-3BOX-PaEG-R3rv-RHYw-WHNVVu'
  e0c2385a-abcd-439f-aecc-ef9ce7285df5
else
  search --no-floppy --fs-uuid --set=root e0c2385a-abcd-439f-aecc-ef9ce7285df5
fi
font="/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class 

Bug#945257: thunar: Thunar ignoger FREETYPE_PROPERTIES="truetype:interpreter-version=35"

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 21 Nov 2019 22:20:03 -0600 tubus  wrote:
> Package: thunar
> Version: 1.8.4-1
> Severity: important
> 
> Dear Maintainer,
> 
> I have set environment variable FREETYPE_PROPERTIES in /etc/environment
> FREETYPE_PROPERTIES="truetype:interpreter-version=35"
> Most of the applicaton shows font as expected for type 35
> 
> But not in Thunar, it ignores it and uses type 40.
> 
> Please, take a look on my screenshot. You will be able to notice that anti-
> alising on left and right windows is different.
> Left is Thunar, on the right is mousepad. Mousepad makes anti-alising with
> truetype:interpreter-version=35
> 
> Thunar is not, it uses version 40 or 38, which is the same.
> 
> Font anti-alising should be everywhere the same.

Is the variable properly set in Thunar environment, did you check it? Can you
stop thunar (thunar -q) then start it from the terminal with env var set?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3YGSsACgkQ3rYcyPpX
RFtnlAf+MKPAjapr50EZ6crpS/r6KHfIfBr6PrK37gMxjIw8afXYVrCBMPSlAnFs
pxnsDGlKrgkH4THGWA/RLULyj5iT6cNUe6dn79ELDtmuSXPZVZ4hN8KCUHFRWMuf
U+AdGv0EHxXVkeokj7zuOy0KGp2UVVFvZp7SXMCIKaEM5iVPkmeXYc5G2I3Omtqw
sK0pJlycqGxWjCSuwFTR52edsHN5o1OjTbhb1OKtFYoCZiBd/L153/Qyu6MC89gS
MZ+VT1hpBE9Gk/YeBDxxwQlRtUzE+vXluOcOze2cXXV8+gF2baFcQc5otPIevVMq
xTJF426FJS0fMN0H4VF8gutyAwRxDw==
=39WC
-END PGP SIGNATURE-

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Christian Göttsche]

What's wrong with a failed git checkout?


---
 gbp/deb/git.py  | 15 ---
 gbp/scripts/buildpackage.py |  2 ++
 gbp/scripts/export_orig.py  |  6 +-
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index 3584f6ff..fa45807a 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -316,13 +316,22 @@ class DebianGitRepository(PkgGitRepository):

source.upstream_version,
 comp))

-def create_upstream_tarball_via_pristine_tar(self, source,
output_dir, comp, component=None):
+def create_upstream_tarball_via_pristine_tar(self, source,
output_dir, comp, upstream_signatures, component=None):
 output = source.upstream_tarball_name(comp.type, component=component)
+gbp.log.debug("upstream signature state: %s" % upstream_signatures)
 try:
+signature = False if upstream_signatures.is_off() else True
 self.pristine_tar.checkout(source.name,
source.upstream_version, comp.type, output_dir,
-   component=component, quiet=True)
+   component=component,
quiet=True, signature=signature)
 except Exception as e:
-raise GitRepositoryError("Error creating %s: %s" % (output, e))
+if upstream_signatures.is_on():
+raise GitRepositoryError("Error creating %s with
attached signature file: %s" % (output, e))
+gbp.log.info("Failed to create '%s' with attached
signature file. Retrying without..." % output)
+try:
+self.pristine_tar.checkout(source.name,
source.upstream_version, comp.type, output_dir,
+   component=component,
quiet=True, signature=False)
+except Exception as e:
+raise GitRepositoryError("Error creating %s: %s" % (output, e))
 return True

 def create_upstream_tarball_via_git_archive(self, source,
output_dir, treeish,
diff --git a/gbp/scripts/buildpackage.py b/gbp/scripts/buildpackage.py
index 2aca53df..9b3d67fa 100755
--- a/gbp/scripts/buildpackage.py
+++ b/gbp/scripts/buildpackage.py
@@ -395,6 +395,8 @@ def build_parser(name, prefix=None):
   help="Compression type, default
is '%(compression)s'")
 orig_group.add_config_file_option(option_name="compression-level",
dest="comp_level",
   help="Compression level,
default is '%(compression-level)s'")
+orig_group.add_config_file_option(option_name="upstream-signatures",
dest="upstream_signatures",
+  help="use upstream signatures,
default is auto", type='tristate')
 orig_group.add_config_file_option("component", action="append",
metavar='COMPONENT',
   dest="components")
 branch_group.add_config_file_option(option_name="upstream-branch",
dest="upstream_branch")
diff --git a/gbp/scripts/export_orig.py b/gbp/scripts/export_orig.py
index 13be4f91..cad8297b 100755
--- a/gbp/scripts/export_orig.py
+++ b/gbp/scripts/export_orig.py
@@ -113,7 +113,8 @@ def pristine_tar_build_origs(repo, source,
output_dir, options):

source.upstream_tarball_name(comp.type
 repo.create_upstream_tarball_via_pristine_tar(source,
   output_dir,
-  comp)
+  comp,
+
options.upstream_signatures)
 for component in options.components:
 gbp.log.info("Creating %s" %
  os.path.abspath(os.path.join(output_dir,
@@ -121,6 +122,7 @@ def pristine_tar_build_origs(repo, source,
output_dir, options):
 repo.create_upstream_tarball_via_pristine_tar(source,
   output_dir,
   comp,
+
options.upstream_signatures,
   component=component)
 return True
 except GitRepositoryError:
@@ -303,6 +305,8 @@ def build_parser(name):
   help="Compression type, default
is '%(compression)s'")
 orig_group.add_config_file_option(option_name="compression-level",
dest="comp_level",
   help="Compression level,
default is '%(compression-level)s'")
+orig_group.add_config_file_option(option_name="upstream-signatures",
dest="upstream_signatures",
+  help="use upstream signature,
default is auto", type='tristate')
 orig_group.add_config_file_option("component", action="append",
metavar='COMPONENT',
   dest="components")
 branch_group.add_config_file_option(option_name="upstream-branch",
dest="upstream_branch")
-- 

Bug#945295: Unnecessary "invalid attribute length" and "failed to fetch key" warnings with libsimple-tpm-pk11.so

[Colin Watson]

On Fri, Nov 22, 2019 at 06:08:01PM +0100, Didier 'OdyX' Raboud wrote:
> For some time now, ssh (openssh-client) unnecessarily warns for:
> 
> > invalid attribute length
> > failed to fetch key
> 
> when SSH'ing to a host with libsimple-tpm-pk11.so as PKCS11Provider.
> 
> Relevant lines from a verbose connection:
> 
> $ ssh -vvv -oPKCS11Provider=libsimple-tpm-pk11.so ssh.example.com
> …
> debug1: Connecting to (…)
> debug1: Connection established.
> debug1: provider libsimple-tpm-pk11.so: manufacturerID  manufacturer> cryptokiVersion 0.1 libraryDescription  library> libraryVersion 0.1
> debug1: provider libsimple-tpm-pk11.so slot 0: label  
> manufacturerID  model  serial  flags 0x400
> debug1: have 1 keys
> invalid attribute length
> failed to fetch key
> …
> debug1: Will attempt key: libsimple-tpm-pk11.so RSA 
> SHA256:(xxx-hash-of-my-tpm-key-xxx) token
> …
> 
> This was initially reported at 
> https://github.com/ThomasHabets/simple-tpm-pk11/issues/48,
> and brought to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1710832,
> which fixed it.

I haven't looked very far into this yet, but as far as I can tell that
Fedora bug is *not* the same thing.  Fedora carries a patch set that
asks for the CKA_LABEL attribute, and that bug was because it was
(apparently incorrectly) requiring that attribute to have non-zero
length.

However, Debian does not carry that patch.  If you're seeing these
errors in the RSA case, it's because at least one of CKA_MODULES or
CKA_PUBLIC_EXPONENT is coming back as empty.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Christian Göttsche]

fix for previous patch:

diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index fa45807a..aa4562b4 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -324,7 +324,7 @@ class DebianGitRepository(PkgGitRepository):
 self.pristine_tar.checkout(source.name,
source.upstream_version, comp.type, output_dir,
component=component,
quiet=True, signature=signature)
 except Exception as e:
-if upstream_signatures.is_on():
+if not upstream_signatures.is_auto():
 raise GitRepositoryError("Error creating %s with
attached signature file: %s" % (output, e))
 gbp.log.info("Failed to create '%s' with attached
signature file. Retrying without..." % output)
 try:

Bug#945286: cloud.debian.org: debian buster: vagrant-vbguest kernel header installation fails because kernel ist outdated

[Christian Baumann]

Package: cloud.debian.org
Severity: normal

Dear Maintainer,

When starting the debian/buster64 vagrant box with virtualbox, vagrant-vbguest 
tries to install linux-headers-`uname -r` which is needed for the guest 
extensions.
This command failes, because the kernel version of the box is 1.19.0-5, but 
debian mirrors only have the newer 1.19.0-6 kernel version.
I think a new build of the box would fix the issue.

Best regards,
Christian Baumann

-- 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)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#932484: isso gives 404 when started via systemd

[Jonathan Watt]

Ignore what I said previously. I believe I've figured out why both Tiger!P and I
have been having problems.

I had assumed isso would be set up for normal use. However, it appears that the
systemd unit is set up for the "Multiple Sites" method documented here:

  https://posativ.org/isso/docs/setup/multiple-sites/

The consequences of this are that any .cfg files in /etc/isso.d/enabled must set
the 'name' value in the 'general' section.

The knock-on consequence of that is that any URLs to Isso files must be prefixed
by that name. For example, if you set the name to "bob", then instead of:

  

you would use:

  

Or, if like me you are using the "Sub-URI" method
(https://posativ.org/isso/docs/setup/sub-uri/) to host Isso from a
"subdirectory" of your site instead of from a sub-domain, then instead of;

  

you would use:

  

These path changes also apply to the 'data-isso' attribute on the 

Bug#945290: indicator-sensors: needlessly build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Package: indicator-sensors
Version: 0.9-2
Severity: normal

Dear Maintainer,

The gnome-doc-utils package is deprecated since >5 years. It's unlikely
to survive to the bullseye release because of the python2 removal.

I could not find anything in your package that actually uses
gnome-doc-utils and I also tested dropping the build-dependency
and your package seemed to still build successfully.

If this is an unnecessary build-dependency please consider dropping it.
(And if you actually need it for something, please find another option
soon.)

(Btw, if you drop it you might also want to update the snapcraft file
where it's also mentioned.)

Regards,
Andreas Henriksson

Bug#945259: povray FTCBFS: broken, oudated, embedded copy of AX_BOOST_BASE

[Andreas Beckmann]

Hi Helmut,

On 22/11/2019 06.25, Helmut Grohne wrote:
> povray fails to cross build from source, because it ships a broken,
> outdated, embedded copy of AX_BOOST_BASE in
> unix/config/ax_boost_base.m4. The actual bug #872256 is already fixed
> for a while in autoconf-archive, but povray happens to ship a copy of
> the bug. Please remove your embedded copy or - failing that - update it
> and register it with the security tracker. This bug report comes without
> a patch, because the actual bug is already fixed.

Does the latest version of ax_boost_base.m4 available from
https://www.gnu.org/software/autoconf-archive/ax_boost_base.html contain
the fixes? I'd like to point upstream to that location with "please
update your embedded copy of ..."

Andreas

Bug#940565: Update

[Sophie Brun]

Hi,

On Mon, 18 Nov 2019 09:35:20 + Mark Weyer  
wrote:
> In the mean time I realized the metioned behaviour is triggered by the 
> presence of a file named enum.py. Hence, the way to reproduce the bug in a 
> hitherto empty directory is:
> 
>   touch enum.py && echo "import PySide2.QtCore as core" | python3

I don't reproduce the segfault error with latest version 5.13.2-1 in unstable.
There is still an error but it's a Python3 error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/PySide2/__init__.py", line 51, in 

_setupQtDirectories()
  File "/usr/lib/python3/dist-packages/PySide2/__init__.py", line 21, in 
_setupQtDirectories
import shiboken2
  File "/usr/lib/python3/dist-packages/shiboken2/__init__.py", line 10, in 

import zipfile
  File "/usr/lib/python3.7/zipfile.py", line 12, in 
import shutil
  File "/usr/lib/python3.7/shutil.py", line 10, in 
import fnmatch
  File "/usr/lib/python3.7/fnmatch.py", line 14, in 
import re
  File "/usr/lib/python3.7/re.py", line 143, in 
class RegexFlag(enum.IntFlag):
AttributeError: module 'enum' has no attribute 'IntFlag'

Regards,
Sophie

Bug#945293: sensors-applet: needlessly build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Source: sensors-applet
Version: 3.0.0+git6-0.2
Severity: normal

Dear Maintainer,

The gnome-doc-utils package is deprecated since >5 years.
It will likely not survive to bullseye release because of the python2
removal.

It seems your package doesn't actually need the build-dependency
on gnome-doc-utils. I dropped it and build-tested without it and
your package built successfully without gnome-doc-utils.
(You already build-depend on yelp-tools so I assume that
gnome-doc-utils is a leftover from when upstream converted
to that.)

Please drop the gnome-doc-utils build-dependency.

Regards,
Andreas Henriksson

Bug#942106: python3.8 / pandas py2removal

[Graham Inggs]

Hi Rebecca

> The binNMUs (to add python3.8 support) of pandas and statsmodels failed.
>  I think this will make them work (but haven't tried it):
>
> - Apply the (existing) #943418 fix to python-xlrd.
> - Build matplotlib, pandas and statsmodels in that order.  (ben can't
> work this out because the declared dependencies are circular, but I
> think the actual strict test dependencies only go that way.)

Thanks for the info.  I was able to build matplotlib first, then
python-xlrd, then pandas.
Pandas has already finished on some of the faster architectures
(amd64/i386/ppc64el/s390x) and I scheduled statsmodels there, but it
still fails.

I'm not sure if this is due to python 3.8, or the new numpy.

Regards
Graham

Bug#945295: Unnecessary "invalid attribute length" and "failed to fetch key" warnings with libsimple-tpm-pk11.so

[Didier 'OdyX' Raboud]

Package: openssh-client
Version: 1:8.1p1-1
Severity: normal

For some time now, ssh (openssh-client) unnecessarily warns for:

> invalid attribute length
> failed to fetch key

when SSH'ing to a host with libsimple-tpm-pk11.so as PKCS11Provider.

Relevant lines from a verbose connection:

$ ssh -vvv -oPKCS11Provider=libsimple-tpm-pk11.so ssh.example.com
…
debug1: Connecting to (…)
debug1: Connection established.
debug1: provider libsimple-tpm-pk11.so: manufacturerID  cryptokiVersion 0.1 libraryDescription  
libraryVersion 0.1
debug1: provider libsimple-tpm-pk11.so slot 0: label  
manufacturerID  model  serial  flags 0x400
debug1: have 1 keys
invalid attribute length
failed to fetch key
…
debug1: Will attempt key: libsimple-tpm-pk11.so RSA 
SHA256:(xxx-hash-of-my-tpm-key-xxx) token
…

This was initially reported at 
https://github.com/ThomasHabets/simple-tpm-pk11/issues/48,
and brought to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1710832,
which fixed it.

Perhaps it also needs fixing in simple-tpm-pk11, but let's start with a
bugreport where the warning is emitted.

Cheers,
OdyX

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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.29-3
ii  libedit2  3.1-20191025-1
ii  libgssapi-krb5-2  1.17-6
ii  libselinux1   2.9-3+b1
ii  libssl1.1 1.1.1d-2
ii  passwd1:4.7-2
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
pn  libpam-ssh 
pn  monkeysphere   
ii  ssh-askpass1:1.2.4.1-10+b1

-- no debconf information

Bug#945257: thunar: Thunar ignoger FREETYPE_PROPERTIES="truetype:interpreter-version=35"

[Vas]

Control: retitle -1 Thunar ignores 
FREETYPE_PROPERTIES="truetype:interpreter-version=35"

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Simon McVittie  writes:
> On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote:

>> I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1

> It doesn't, but its dh_installsystemd integration currently does, so
> maintainer scripts relying on it would currently be buggy. I think it
> would be premature to recommend systemd-tmpfiles in Policy before it can
> be used in a non-buggy way.

> I had also thought that, in the current state of non-systemd-init-world,
> having a dependency on a package containing systemd-tmpfiles was likely
> to be practically problematic because it would indirectly conflict
> with elogind, via libsystemd0 and its elogind reimplementation - but
> looking more closely, systemd-tmpfiles and systemd-sysusers depend on
> /lib/systemd/libsystemd-shared-243.so (and not on libsystemd0) so that
> shouldn't actually be a problem.

There's also the problem that while systemd-tmpfiles doesn't currently
depend on systemd as PID 1, I'm dubious upstream is willing to make any
guarantees that this will continue to be the case.  It's also not clear
whether the project would be comfortable with us adopting new Policy
guidance that inherently breaks the non-Linux ports (since I believe the
systemd package does not build there).

Let's hold off on this until the GR.  The GR won't be too far into the
future, and will provide a very clear path forward for proposals like
this.

Thank you very much for starting to work on it, though, and I'd be very
happy to see specific proposed language in this bug that we can consider
once the GR makes it clear how the project wants us to proceed with
facilities like this.

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

Bug#945279: [pkg-gnupg-maint] Bug#945279: gpg-wks-client: --install-key does not create policy file

[Werner Koch]

On Fri, 22 Nov 2019 11:36, Hans-Christoph Steiner said:

> It should create a zero length file, as recommended in the draft: "it
> is sufficient if that file has a zero length".

Good idea.  Tracked upstream as https://dev.gnupg.org/T4753


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#886679: Status of ITA

[Emmanuel Arias]

Hi Ondřej,

I update the salsa repository [1]

but I am having son troubles to building the packge

Also, I need to work on [2]. Pygtk is no longer supported, and upstream used it.

[1] https://salsa.debian.org/ocaml-team/coccinelle
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885267

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mié., 20 de nov. de 2019 a la(s) 09:23, Emmanuel Arias
(emmanuelaria...@gmail.com) escribió:
>
> Hi Ondřej
>
> Thanks for contact me.
>
> I was focus on py2 removal. But, let me retake coccinelli again. I
> will working on that today and I will let you know
>
> Thanks!
>
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
>
> El mar., 19 de nov. de 2019 a la(s) 23:48, Ondřej Surý
> (ond...@sury.org) escribió:
> >
> > Hi,
> >
> > what’s the status of the adoption?
> >
> > We use coccinelle for BIND 9 and I would be happy to start things moving 
> > again.
> >
> > Ondrej
> > --
> > Ondřej Surý
> > ond...@sury.org

Bug#945098: kore: new upstream version 3.3.1 available (2019-06-03)

[Shih-Yuan Lee (FourDollars)]

OK, I will do it.

$4

On Tue, Nov 19, 2019 at 04:32:10PM +0100, Martin wrote:
> Source: kore
> Version: 2.0.0-4
> Severity: wishlist
> 
> Dear maintainer,
> 
> there were some releases since the last update of kore.
> 
> See e.g. https://blog.kore.io/posts/kore-3-released
> and https://blog.kore.io/posts/the-next-kore-release-is-out
> and https://github.com/jorisvink/kore/releases
> 
> Please consider packaging the latest release.
> 
> Thanks!


signature.asc
Description: PGP signature

Bug#945296: fonts-cabin: Please packaging new upstream version (2.2)

[Boyuan Yang]

Package: fonts-cabin
Version: 1.5-2
Severity: important

The upstream of fonts-cabin has migrated to https://github.com/impallari/Cabin
 with new upstream 2.2 release. Please consider packaging the new version.

-- 
Best,
Boyuan Yang


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

Bug#940578: fixed in cups 2.3.0-6

[Didier 'OdyX' Raboud]

Le jeudi, 21 novembre 2019, 08.46:43 h CET intrigeri a écrit :
> Hi,
> 
> Rudolf Polzer:
> > For me it is still not working, because I changed
> > /etc/cups/cups-pdf.conf
> > 
> > from
> > Out ${HOME}/Transport
> > to
> > Out ${HOME}
> > 
> > and get the error message
> > 
> > audit[5146]: AVC apparmor="DENIED" operation="mknod"
> > profile="/usr/lib/cups/backend/cups-pdf" name="/home/rudi/home_rudi.pdf"
> > pid=5146 comm="gs" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> 
> Indeed, the fix only covers sub-directories of $HOME.
> Technically it's easy to also support this use case.
> I'm happy to implement this if the CUPS maintainers
> prefer a more lenient AppArmor confinement of cups-pdf,
> in order to improve UX in this (arguably corner) case.

As CUPS maintainer; the current situation is fine; I find letting cups-pdf 
write to $HOME directly to be debatable; and the error makes sense.

Cheers,

OdyX

Bug#945066: buster-pu: package enigmail/2:2.1.3+ds1-4~deb10u1

[Jonas Meurer]

Hello,

On Tue, 19 Nov 2019 17:11:05 +0800 Daniel Kahn Gillmor
 wrote:
> thunderbird 68 is now in buster-new and in security.debian.org
> 
> sadly, the enigmail upstream versions are closely tied to the
> thunderbird versions.  (enigmail 2.0.x works with TB 60, but 2.1.x works
> with TB 68)  See https://bugs.debian.org/945014 for more details.
> 
> I'm proposing to upgrade the version of enigmail in buster to match the
> new version of thunderbird.

Thanks a lot, Daniel!

Would be very nice to get this into Buster rather soon. At the moment,
enigmail users either have to continue using a Thunderbird version with
known security vulnerabilities or have to uninstall enigmail (and
install the upstream version of Enigmail, which has its own drawbacks).

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#913146: user configurable debug output

[dann frazier]

I ran across a procedure for emitting debug info to a file:
  
https://lists.ofono.org/hyperkitty/list/edk2-de...@lists.01.org/message/XS2Y2POANJ6J65JLFEOOSH5DVPYFLTFY/

Given that, I wonder if there might be a way to create a single build
that users can optionally configure to enable debug output.

 -dann

Bug#932484: isso gives 404 when started via systemd

[Jonathan Watt]

Perhaps it would be best to have separate 'isso' and 'isso-multi' systemd units?

Additionally, is there somewhere that documents setting up Isso with the current
unit? I guess maybe the man page (although that doesn't really contain anything
useful right now)? How would I go about submitting changes for that?

Bug#945292: lightdm: needlessly(?) build-depends on deprecated gnome-doc-utils

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-11-22 at 17:18 +0100, Andreas Henriksson wrote:
> I'm tired. Your package already build-depends on yelp-tools so I'm
> going to just assume that the gnome-doc-utils build-dependency is
> a leftover from before switching to yelp/itstool. I don't have the
> energy left to build-test this for you. This message brought to you
> because gnome-doc-utils has been deprecated for > 5 years and might
> not survive to bullseye release because of the python2 removal.
> 
> Please drop the gnome-doc-utils build-dependency if it's not needed
> (and if it is, please find another option soon).

Hi Andreas, I'm not sure what to do with the tone of this bug report. If
gnome-doc-utils has been deprecated for > 5 years, why wasn't a bug report
submitted to actually ask dependencies to migrate?

I'm sorry if you're tired, but I don't closely follow everything in Debian, so
yeah, I missed that bit of information in that package. I'll take a look, when
I have time, hopefully before Bullseye freeze.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3YDJIACgkQ3rYcyPpX
RFue0gf+JirdXdht12oU172v9mH0KsPZ6GpiNqKLx7IfVtq6GkZcVzG3orx55cbh
Xl9DYR1spePLVg8DfiW5w6xYSXbTnONwHbnPhpEnkIC9Z7dL53f9mSjPQVx71IGQ
4DGEx1+37086xeD+cp95K3aJAguXU+SSRyfdwNz6HEb0F0nub3K7r8o3FFrjjTB5
hGEfJYuj/ePxvqR9EFf5HPxLKKhTkZK5xzS2YmXUofDI8no6KFhw5LPS0ZaOpa0r
+bXUR5YbVgncCA/ylgQ+rPPCd0I1CSS0pdDKpmoX6RWsK8+bjCH86VR/7gT8BwT1
MhWhIAas7jfsuMRrd0KFYiCWxzMCpA==
=mgXU
-END PGP SIGNATURE-

Bug#945287: libarchive: CVE-2019-19221

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.4.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1276

Hi,

The following vulnerability was published for libarchive.

CVE-2019-19221[0]:
| In Libarchive 3.4.0, archive_wstring_append_from_mbs in
| archive_string.c has an out-of-bounds read because of an incorrect
| mbrtowc or mbtowc call. For example, bsdtar crashes via a crafted
| archive.


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-19221
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19221
[1] https://github.com/libarchive/libarchive/issues/1276

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#945294: shotwell: needlessly build-depends on deprecated gnome-doc-utils

[Andreas Henriksson]

Source: shotwell
Version: 0.30.7-1
Severity: normal

Dear Maintainer,

The gnome-doc-utils package is deprecated since >5 years.
It will likely not survive the bullseye release because of the python2
removal.

It seems shotwell has been converted over to yelp/itstool (and you
already build-depend on itstool) upstream earlier, but possibly
you forgot to drop the obsolete gnome-doc-utils build-dependency.

Please consider dropping the build-dependency on gnome-doc-utils
(or if it's really still needed find another option soon).

Regards,
Andreas Henriksson

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Ansgar]

On Fri, 2019-11-22 at 12:07 +, Simon McVittie wrote:
> On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote:
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
> 
> Using tmpfiles.d(5) seems like a good thing to encourage, but using
> them *instead of* maintainer scripts is less simple. My understanding
> is that in current Debian policies and status, if a package relies
> on tmpfiles.d(5) for important functionality and does not depend on a
> tmpfiles implementation, that would usually be a grave bug.

Sure, I don't see a problem with that in principle though?

> The only tmpfiles implementation in Debian right now (that I know of) is
> the combination of systemd-tmpfiles(8), systemd-tmpfiles-setup.service
> (for creation of tmpfiles during boot), the maintainer script
> fragments generated by dh_installsystemd (for creation of tmpfiles
> during installation), and systemd as pid 1.

I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1
(though one GR option seems to imply systemd-tmpfiles and -sysusers are
somehow facilities that need alternative implementations for other
inits, but I don't think that claim was verified).

Both -tmpfiles and -sysusers seem to work for example in Docker
containers which don't run systemd-init.

> I'm not entirely sure why
> systemd doesn't have a trigger on tmpfiles.d, but perhaps it's because
> the sequencing would be wrong: a package's tmpfiles generally need to be
> created before its postinst reaches the point where services are started,
> and I don't think triggers would guarantee that.

I think the maintainer scripts would currently need to call systemd-
tmpfiles once, yes.  (The same would be true for -sysusers; see also
the --replace option in systemd-sysusers(8).)

> ( is an alternative implementation,
> but is not in Debian and would require adjustments to dh_installsystemd.)

I know it exists, but I don't think we need an alternative
implementation?  It would be useful for non-Linux, but if people don't
want to package it then we could also just recommend using
tmpfiles.d(5) on Linux only.

On Linux I see no advantage of having multiple implementations. People
are of course free to replace them locally if they want though, just
like they can for coreutils.

> Note that I am deliberately saying "without systemd as pid 1" rather than
> "with a non-systemd init", because there is a subtle difference. If you
> install (for example) dbus into a chroot or container that does not run an
> init system at all, then the current dh_installsystemd fragment will see
> that /run/systemd/system doesn't exist, so /usr/lib/tmpfiles.d/dbus.conf
> will not be processed and /var/lib/dbus will not be created.

We don't have to use dh_installsystemd and I think it was proposed to
use a different helper for tmpfiles anyway (for other reasons).

> (Reference:
> look in /var/lib/dpkg/info/dbus.postinst for "Automatically added
> by dh_installsystemd".) This doesn't matter for the D-Bus system
> service, because the D-Bus system service will not be started in those
> chroots/containers (there is no init to start it), but it does matter
> for dbus-x11 (which also wants to see /var/lib/dbus/machine-id for
> the autolaunching protocol) and anything else that is using the D-Bus
> machine ID.
> 
> This means that even if GR 2019-002 resolves that we will stop supporting
> non-systemd init systems, there will still be two cases to consider:
> systemd vs. no init at all.

Sure, I'm quite interested in supporting the no-init case (I think the
request to make the `init` package non-essential and optional came from
me ;-)).  I wouldn't be surprised if other distributions also care
about that, even when they only support systemd as init.

(It might even be useful to move helpers like -tmpfiles and -sysusers
to a separate packages so container images won't pull in the full
systemd package.)

"Other inits" are probably not much different han "no init", except
that they should call systemd-tmpfiles at some appropriate time during
boot.

> Another potential difficulty is that some tmpfiles.d(5) fragments might
> assume that systemd is installed: certain guarantees/constraints,
> such as /etc/machine-id behaving as documented in machine-id(5),
> are known to be true on systems with systemd as pid 1, but not on
> Debian systems in general. dbus' tmpfiles fragment creates a symlink
> /var/lib/dbus/machine-id -> /etc/machine-id based on the assumption that
> machine-id(5) is as documented, which is not necessarily true without
> systemd (again, this can mean either sysvinit as pid 1, or no init
> at all).

I think it is fine to blacklist specific cases such as using the
machine-id (at least without an explicit dependency).  I don't expect
many packages to use these anyway.  Same for the options related to
(btrfs) subvolumes and some 

Bug#944265: mailutils: local privilege escalation in maidag utility (fixed in 3.8)

[Jordi Mallach]

Hi all,

El dl. 11 de 11 de 2019 a les 21:32 +0100, en/na Salvatore Bonaccorso
va escriure:
> Control: retitle -1 mailutils: local privilege escalation in maidag
> utility (fixed in 3.8) (CVE-2019-18862)

Given this does not affect Debian by default, should my upload go
through debian-security or just s-p-u?

https://salsa.debian.org/debian/mailutils/commit/c1683e71301e3c7454ab407334a211759148d47e

Jordi
-- 
Jordi Mallach 

Bug#775096: darkhttpd

[kvaps]

Hi,

I'm also interested in adding this package.

> There are already lots and lots of HTTP servers in Debian for all sorts
of use-cases. What use-case is supported by darkhttpd but not by any other
existing HTTP server in Debian?

This one is for static files only, it is really tiny, fast and doing its
job well.
I can append that darkhttpd is widely use in Alpine Linux it would be nice
to add support for debian too.

- kvaps

Bug#879130: choose-mirror: empty mirror list on non released architectures

[Samuel Thibault]

Control: tags -1 + pending

Samuel Thibault, le lun. 18 nov. 2019 22:39:48 +0100, a ecrit:
> Samuel Thibault, le mer. 13 nov. 2019 00:12:50 +0100, a ecrit:
> > I have significantly reworked and simplified the patch:
> 
> I have modified it a bit to fix the "directory" value in the manual
> configuration, which should be /debian-ports/
> 
> That is useful for the case when there is no mirror for the ports
> architecture (which is e.g. the case for hurd-i386 ATM).
> 
> I could test it with success on hurd-i386 with a mirror for the arch,
> on hurd-i386 without a mirror for the arch, and on linux-amd64 (thus
> non-port), it behave fine.
> 
> Any red flag before I commit?

I have now commited it.

Samuel

Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running

[Guillem Jover]

On Wed, 2019-11-20 at 12:14:44 +0100, Raphael Hertzog wrote:
> On Wed, 20 Nov 2019, Guillem Jover wrote:
> > > To achieve this in a more elegant way, could you possibly implement some
> > > "dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or
> > > something similar ?
> > 
> > I'm not sure I understand why this is not done say via a trigger
> > instead? Also why this script cannot just called within the postinst
> > w/o putting it on the background?
> 
> The package provides many desktop files and the associated icons. The
> script scans the list of installed packages and installs/uninstalls the 
> desktop
> files corresponding to each package (we have a mapping desktop-file <-->
> binary package). The script might use dpkg-divert if the target desktop file
> already exists for some reason.

That still does not explain why this needs to be done outside the dpkg's
execution context, though?

> As a long as dpkg is running, we might install/remove packages and it
> might affect the set of desktop files to install/remove. Thus doing
> it only in the postinst is not a viable option.

I didn't mean to imply doing it within the postinst instead of anywhere
else, but just instead of in the background.

Running it in the postinst is necessary, even with triggers, at least
to catch the first run, in case no other package will activate the
trigger, or in case this package needs to inject newly updated content.

> Also I just want to perform the operation once, after all package
> operations have been completed. But path-based triggers are of no help
> as I really have to monitor the installation/removal of many packages.
> A named trigger would require changes in the hundreds of packages that
> can affect the menu. And the reason of kali-menu is precisely because
> we didn't want to have to fork hundreds of packages.

Triggers right now should get batched more aggressively than in the
past. And I'm not quite sure why they would not be preferable to a
hook which gets executed unconditionally every time, regardless of
any package unpacking on the interested paths. This is the kind of
thing triggers were designed to cover. The current way this is
deployed seems rather iffy to me TBH.

Thanks,
Guillem

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-11-08 at 21:55 +0100, Yves-Alexis Perez wrote:
> On Fri, 2019-11-08 at 20:53 +, Adam D. Barratt wrote:
> > Sorry for the delay in getting back to you.
> 
> Yeah, this time it's me who's really sorry.
> > That sounds OK, but it looks like the fix still hasn't made it to sid,
> > so I'm tagging this as moreinfo for now. Please remove the tag and
> > confirm the final debdiff once that's sorted.
> 
> Indeed, I'm still waiting on upstream to actually chose the way they bump
> the
> soname… I still don't have any answer on 
> https://github.com/libimobiledevice/libusbmuxd/issues/81
> 
> I'll keep you posted as soon as possible.

Sorry, I replied to the wrong bug. I'll upload the isolated fix soon, likely
this weekend, thanks.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3YDYgACgkQ3rYcyPpX
RFvwMAgA44f46WaXAiRV8ZQegxf3SD/Hwc/x+VJvaWVxumey2maP5C+YLU+z1CZx
d6FDNJ5ALSrtYes3BYALXecj/bieZpCbJVc261ffQGetTqH6UV+Yat58rCu8rcTZ
r61Yz8sW8nmUfQz/0C9V6+aA0connf+KpElTkFHQnmMY5EjDDAcCAC0As5B9YWCC
KpWETvTJErxCGr2jY487fjY2thAlnQzAfmdVwbhkhE9vXhLemU4bKdGD1J+HgVB5
MTEsz51fbcys0emdsUrVgR5crjgPmYHQlAjHjOp2Avs/N4GC0qi5fzkmzU8FgJkq
1NoPWCaJWCWTQoKLHjYNkrqs2jtv2Q==
=WoH/
-END PGP SIGNATURE-

Bug#941793: nmu: libimobiledevice_1.2.1~git20181030.92c5462-1

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2019-10-24 at 11:44 +0200, Emilio Pozuelo Monfort wrote:
> Just go ahead with the package rename / soname bump, no need to revert it and
> then do the transition in this case, given the rdeps are going to build fine 
> so
> there will be little disruption.


So, upstream went ahead and updated the soname on libusbmuxd (from libusbmuxd4
to libusbmuxd6) and tagged a new release (2.0.0, along with libplist 2.1.0).

I'll upload soon, likely this week-end, but NEW processing seems a bit stuck
so I'm unsure when it'll reach unstable.

Thanks anyway!

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3YDfoACgkQ3rYcyPpX
RFtrUQgAy4koWeosp0jpkyUb3HwGNkeMTF5PDcpmco67OxLsLJssA9fO5jZqtwaW
MMvibP5lIBf+ZyWA+1tYGRg6GG8vaFbdAisl7iM7zk6jqlsHCH/EKVpwEZNx+hPE
w0cbbSTgdxY4yOHvSj1qFJIB0HG9G0Oyq8LS5JO4xj6OFHgdDrgxlCgM/JH27SQd
mSNh+QBNR2SkPgHHLjtlk9TiJzB7QQnESNik/H0TUDz+twBF23eVMIQI9vMhXGni
xAh6/Q1VRFCHzsHjg5v/fnLc8LhYRXgdyqn25w/eCQUSAuyadFb1qX7GwmyjYIq0
ds6Eky9pvCA23rwfzphc6G4Nia+eFg==
=VWOi
-END PGP SIGNATURE-

Bug#882805: Some investigation

[Florian Bruhin]

Hey,

qutebrowser upstream here - I recently looked into this a bit, and partially
found out what's going on.

Turns out when supposed to display an error page, "jstProcess is not defined"
gets logged instead.

When I look at the source of the error page on my Archlinux machine, that
JavaScript function is properly defined, like it is upstream here:
https://cs.chromium.org/chromium/src/third_party/jstemplate/jstemplate_compiled.js?q=jstemplate_com=package:chromium=0

However, on Debian, the related code is simply missing from the error page.

I'm guessing this is somehow related to how Debian regenerates that file from
sources:
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/debian/5.12.5+dfsg-3/debian/rules#L135-141

Maybe there's something going wrong there, and the generated file is actually
empty or something?

FWIW, for now I added a workaround for this to qutebrowser,
which will be part of its v1.8.2 release:
https://github.com/qutebrowser/qutebrowser/commit/300b88fcbfe395988591cedcccdb63a199a9d355

Florian

-- 
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#934922: clevis: Reference to non-existant clevis-decrypt-http

[Jesus Angel]

Package: clevis-dracut
Version: 11-2
Followup-For: Bug #934922

Dear Maintainer,

This bug hasn't been fixed yet. As a workarround you can edit 
/usr/lib/dracut/modules.d/60clevis/module-setup.sh and change line 39 this way:

39c39
< clevis-decrypt-http \
---
> cryptsetup \

You have to replace clevis-decrypt-http with cryptsetup as shown above. Maybe 
you can just delete the clevis-decrypt-http line as I think cryptsetup is not 
used to open the Luks device, but systemd-cryptsetup is used instead.

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

Kernel: Linux 5.2.0-0.bpo.3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 clevis-dracut depends on:
ii  clevis-systemd  11-2
ii  dracut-network  048+80-2

clevis-dracut recommends no packages.

clevis-dracut suggests no packages.

-- no debconf information

Bug#945298: O: fet -- timetable generator

[Thiago Andrade Marques]

Package: wnpp
Severity: normal

I intend to orphan the fet package.
The upstream is active, but the program takes a long time to build on my pc.

The package description is:
 FET is a program for automatically generating the timetable
 of a school, high-school or university.
 .
 Usually, FET is able to solve a complicated timetable in maximum 5-20 minutes.
 For simpler timetables, it may take a shorter time, under 5 minutes (in some
 cases, a matter of seconds). For extremely difficult timetables, it may take
 a longer time, a matter of hours.

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Ansgar  writes:

> I think no option says we shouldn't use services that don't rely on
> systemd as pid-1 (which also includes widely used things like udev).

I agree, but if, say, Sam's option 3 wins, we can directly incorporate
this, whereas if, say, Ian's option wins, then we should have a
conversation with the sysvinit maintainers to see if they believe they can
adopt systemd-tmpfiles directly, and we should give them at least six
months (obviously shortened if it happens sooner) to update the packaging
and set up a mechanism to run systemd-tmpfiles (or a replacement of their
choice) at boot.

If you want to start those conversations now, then we could get the
proposal to a place where it would be fine for all possible GR options,
but I suspect the people that you'd need to talk to are focused on the GR
at the moment.

Meanwhile, it's going to take at least a week to hash out wording (just
based on past experience), and there's no reason not to start that now,
and by that point we may be pretty near a vote anyway.

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

Bug#882805: Some investigation

[Lisandro Damián Nicanor Pérez Meyer]

Hi Florian!

El vie., 22 nov. 2019 14:57, Florian Bruhin  escribió:

> Hey,
>
> qutebrowser upstream here - I recently looked into this a bit, and
> partially
> found out what's going on.
>
> Turns out when supposed to display an error page, "jstProcess is not
> defined"
> gets logged instead.
>
> When I look at the source of the error page on my Archlinux machine, that
> JavaScript function is properly defined, like it is upstream here:
>
> https://cs.chromium.org/chromium/src/third_party/jstemplate/jstemplate_compiled.js?q=jstemplate_com=package:chromium=0
>
> However, on Debian, the related code is simply missing from the error page.
>
> I'm guessing this is somehow related to how Debian regenerates that file
> from
> sources:
>
> https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/debian/5.12.5+dfsg-3/debian/rules#L135-141
>
> Maybe there's something going wrong there, and the generated file is
> actually
> empty or something?


Can you attach the related files? I'm this way we can compare them and see
if this is the case.

Thanks!

Bug#945312: libonig: CVE-2019-19203: heap-buffer-overflow in gb18030_mbc_enc_len

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/kkos/oniguruma/issues/163

Hi,

The following vulnerability was published for libonig.

CVE-2019-19203[0]:
| An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the
| function gb18030_mbc_enc_len in file gb18030.c, a UChar pointer is
| dereferenced without checking if it passed the end of the matched
| string. This leads to a heap-based buffer over-read.


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-19203
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19203
[1] https://github.com/kkos/oniguruma/issues/163

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#939414: fp-docs-3.0.4: All fcl docs are missing from binary package

[Abou Al Montacir]

It seems that fpdoc fails silently with an EInOutError exception and thus the
compilation of the docs is aborted. Moreover as the returned exit code seems to
be set to 0 and thus make does not catch the issue and continues with next job.

touch fpdoc.chk
mkdir fpdoc
mv -f fpdoc.html fpdoc/fpdoc.html
cp -f preamble.hevea preamble.inc
/usr/bin/hevea  chart.tex
touch chart.chk
mkdir chart
mv -f chart.html chart/chart.html
fpdoc --macro=FPCDIR=../fpcsrc --project=fcl-project.xml --format=html --
output=fcl  
FPDoc - Free Pascal Documentation Tool
Version 3.0.4 [2019/01/16]
(c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org
(c) 2005 - 2012 various FPC contributors

Exception at 0047BA16: EInOutError:
File not found: rtl.xct.
mkdir -p fcl
cp fpdoc.cst fcl/fpdoc.css
fpdoc --macro=FPCDIR=../fpcsrc --macro=FPCDIR=../fpcsrc --package=fcl-res --
warn-no-node --content=fclres.xct --import=fcl.xct --
import=rtl.xct,../rtl/ --input=../fpcsrc/packages/fcl-res/src/resource.pp --
descr=../fpcsrc/packages/fcl-res/xml/resource.xml  
--input=../fpcsrc/packages/fcl-res/src/resourcetree.pp --
descr=../fpcsrc/packages/fcl-res/xml/resourcetree.xml  
--input=../fpcsrc/packages/fcl-res/src/resdatastream.pp --
descr=../fpcsrc/packages/fcl-res/xml/resdatastream.xml  
--input=../fpcsrc/packages/fcl-res/src/resfactory.pp --
descr=../fpcsrc/packages/fcl-res/xml/resfactory.xml   
--input=../fpcsrc/packages/fcl-res/src/resreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/resreader.xml  
--input=../fpcsrc/packages/fcl-res/src/reswriter.pp --
descr=../fpcsrc/packages/fcl-res/xml/reswriter.xml  
--input=../fpcsrc/packages/fcl-res/src/bitmapresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/bitmapresource.xml  
--input=../fpcsrc/packages/fcl-res/src/acceleratorsresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/acceleratorsresource.xml  
--input=../fpcsrc/packages/fcl-res/src/groupresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/groupresource.xml  
--input=../fpcsrc/packages/fcl-res/src/groupiconresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/groupiconresource.xml  
--input=../fpcsrc/packages/fcl-res/src/groupcursorresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/groupcursorresource.xml  
--input=../fpcsrc/packages/fcl-res/src/stringtableresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/stringtableresource.xml   
--input=../fpcsrc/packages/fcl-res/src/versionconsts.pp --
descr=../fpcsrc/packages/fcl-res/xml/versionconsts.xml  
--input=../fpcsrc/packages/fcl-res/src/versiontypes.pp --
descr=../fpcsrc/packages/fcl-res/xml/versiontypes.xml  
--input=../fpcsrc/packages/fcl-res/src/versionresource.pp --
descr=../fpcsrc/packages/fcl-res/xml/versionresource.xml  
--input=../fpcsrc/packages/fcl-res/src/cofftypes.pp --
descr=../fpcsrc/packages/fcl-res/xml/cofftypes.xml   
--input=../fpcsrc/packages/fcl-res/src/coffreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/coffreader.xml  
--input=../fpcsrc/packages/fcl-res/src/coffwriter.pp --
descr=../fpcsrc/packages/fcl-res/xml/coffwriter.xml  
--input=../fpcsrc/packages/fcl-res/src/winpeimagereader.pp --
descr=../fpcsrc/packages/fcl-res/xml/winpeimagereader.xml  
--input=../fpcsrc/packages/fcl-res/src/elfconsts.pp --
descr=../fpcsrc/packages/fcl-res/xml/elfconsts.xml   
--input=../fpcsrc/packages/fcl-res/src/elfreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/elfreader.xml  
--input=../fpcsrc/packages/fcl-res/src/elfwriter.pp --
descr=../fpcsrc/packages/fcl-res/xml/elfwriter.xml  
--input=../fpcsrc/packages/fcl-res/src/machotypes.pp --
descr=../fpcsrc/packages/fcl-res/xml/machotypes.xml  
--input=../fpcsrc/packages/fcl-res/src/machoreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/machoreader.xml   
--input=../fpcsrc/packages/fcl-res/src/machowriter.pp --
descr=../fpcsrc/packages/fcl-res/xml/machowriter.xml  
--input=../fpcsrc/packages/fcl-res/src/externaltypes.pp --
descr=../fpcsrc/packages/fcl-res/xml/externaltypes.xml  
--input=../fpcsrc/packages/fcl-res/src/externalreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/externalreader.xml  
--input=../fpcsrc/packages/fcl-res/src/externalwriter.pp --
descr=../fpcsrc/packages/fcl-res/xml/externalwriter.xml   
--input=../fpcsrc/packages/fcl-res/src/dfmreader.pp --
descr=../fpcsrc/packages/fcl-res/xml/dfmreader.xml --format=html --
output=fclres   
FPDoc - Free Pascal Documentation Tool
Version 3.0.4 [2019/01/16]
(c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org
(c) 2005 - 2012 various FPC contributors

Exception at 0047BA16: EInOutError:
File not found: fcl.xct.

-- 
Cheers,
Abou Al Montacir


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

Bug#882805: Some investigation

[Florian Bruhin]

On Fri, Nov 22, 2019 at 06:19:17PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi Florian!
> 
> El vie., 22 nov. 2019 14:57, Florian Bruhin  escribió:
> 
> > Hey,
> >
> > qutebrowser upstream here - I recently looked into this a bit, and
> > partially
> > found out what's going on.
> >
> > Turns out when supposed to display an error page, "jstProcess is not
> > defined"
> > gets logged instead.
> >
> > When I look at the source of the error page on my Archlinux machine, that
> > JavaScript function is properly defined, like it is upstream here:
> >
> > https://cs.chromium.org/chromium/src/third_party/jstemplate/jstemplate_compiled.js?q=jstemplate_com=package:chromium=0
> >
> > However, on Debian, the related code is simply missing from the error page.
> >
> > I'm guessing this is somehow related to how Debian regenerates that file
> > from
> > sources:
> >
> > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/blob/debian/5.12.5+dfsg-3/debian/rules#L135-141
> >
> > Maybe there's something going wrong there, and the generated file is
> > actually
> > empty or something?
> 
> 
> Can you attach the related files? I'm this way we can compare them and see
> if this is the case.

Those only exist as part of the build process - I assume Archlinux uses the
compiled one shipped by Chromium (which I linked above).

I don't think I've ever built a Debian package from sources (I'm not a Debian
user, except on a server) and QtWebEngine isn't exactly easy to build, so I
won't be able to check how Debian's rebuilt file looks.

Florian

-- 
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#945304: Acknowledgement (calendar-google-provider: Please package version corresponding to thunderbird version)

[Jonathan Addleman]

Apologies for the duplicate submission. (#945393) Issues with my MTA, 
and I thought the first one had bounced, but it had just been delayed...


This report can be closed/deleted.

--
Jonathan Addleman - http://www.redowl.ca

Bug#945318: roger-router: FTBFS against current evolution-data-server

[Andreas Beckmann]

Source: roger-router
Version: 1.8.14-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

roger-router FTBFS against the current evolution-data-server version in
sid:
https://buildd.debian.org/status/package.php?p=roger-router=unstable

First error:

evolution.c:478:8: error: too few arguments to function 
‘e_book_client_remove_contact_by_uid_sync’
  478 |  ret = e_book_client_remove_contact_by_uid_sync(client, contact->priv, 
NULL, NULL);
  |^~~~
In file included from /usr/include/evolution-data-server/libebook/libebook.h:27,
 from evolution.c:37:
/usr/include/evolution-data-server/libebook/e-book-client.h:212:10: note: 
declared here
  212 | gboolean e_book_client_remove_contact_by_uid_sync
  |  ^~~~


Andreas

Bug#945319: RM: cvc3 -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove cvc3. It's unmaintained (last maintainer upload is from 2014
and the maintainer is also one of the authors) and FTBFSes since 1.5 years.

Cheers,
Moritz
 

Bug#945276: lintian: broken pattern matching in debian/source/lintian-overrides

[Chris Lamb]

Martin Pitt wrote:

[…]
> But these overrides now stopped working:
[…]

Without looking into too much detail, are the following the same issue?

  https://bugs.debian.org/945276
  https://bugs.debian.org/945299


Regards,

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

Bug#945304: calendar-google-provider: Please package version corresponding to thunderbird version

[Jonathan Addleman]

Package: calendar-google-provider
Version: 1:60.9.0-1~deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


Thunderbird and lightning packages were recently updated to 1:68.2.2-1~deb10u1
to fix security problems, but calendar-google-provider has not been updated.

Anyone using the calendar-google-provider package must keep using the old
thunderbird with security vulnerabilities until the package is updated.



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

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

Versions of packages calendar-google-provider depends on:
hi  lightning  1:60.9.0-1~deb10u1

calendar-google-provider recommends no packages.

calendar-google-provider suggests no packages.

-- no debconf information

Bug#945308: RM: node-array-from -- ROM; is only used by node-command-join

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (10) and is only used by node-command-join (see 
https://bugs.debian.org/945302).
If we ever need it again, it can be embedded (~ 200 LOC).

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Original ITP: https://bugs.debian.org/849178

Thanks, Paolo

Bug#945213: linux-image-5.2.0-3-amd64: OOM handling broken if hugepages are enabled

[Ben Hutchings]

Control: reassign -1 src:linux 5.2.17-1
Control: tag -1 moreinfo

On Thu, 2019-11-21 at 08:58 +, Anton Ivanov wrote:
> Package: linux-image-5.2.0-3-amd64
> Version: 5.2.17+1
> Severity: important
> 
> Dear Maintainer,
> 
> Dear Maintainer,
> 
> OOM handling appears to be broken in 5.2.17-1 if hugepages are enabled.
> 
> Test system: AMD A4-5300, 40G RAM, no swap, booted disklessly.
> 
> Without hugepages enabled can compile dpdk without any issues. With huge
> pages enabled it will reproducibly OOM when trying to link one of the
> libraries. There are 20G+ free RAM at that point according to free with the
> rest being mostly used as buffers.
> 
> It is sufficient to just enable huge pages to trigger this (2G out of 40G),
> they are not allocated or used by anything. 

What do you mean by "if hugepages are enabled"?  hugetlbfs and THP are
enabled by default.

You need to provide a log of the OOM messages.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.




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

Bug#945309: RM: node-roadrunner -- ROM; not used and unmaintained upstream

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (6) and is not used anywhere in Debian.
When the ITP (https://bugs.debian.org/846218) was filed it was required for 
yarnpkg, but they dropped the dependency:
https://github.com/yarnpkg/yarn/pull/3079

Also duck reports that the upstream repo is gone:
https://github.com/kittens/roadrunner
also the repo currently pointed at by npm regstry is gone:
https://github.com/sebmck/roadrunner

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Thanks, Paolo

Bug#922803: prometheus-node-exporter: Error "awk: not an option: -nf" generated on ipmitool text collector invocation

[skorpy]

Package: prometheus-node-exporter
Version: 0.17.0+ds-3+b11
Followup-For: Bug #922803

Dear Maintainer,

this can also be fixed when gawk is installed so I would suggest setting
it as a dependency.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages prometheus-node-exporter depends on:
ii  libc6 2.28-10
ii  moreutils 0.62-1
ii  systemd-sysv  241-7~deb10u2

Versions of packages prometheus-node-exporter recommends:
ii  dbus   1.12.16-1
ii  python33.7.3-1
ii  smartmontools  6.6-1

prometheus-node-exporter suggests no packages.

-- no debconf information

Bug#945303: calendar-google-provider: Please package version corresponding to thunderbird version

[Jonathan Addleman]

Package: calendar-google-provider
Version: 1:60.9.0-1~deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


Thunderbird and lightning packages were recently updated to 
1:68.2.2-1~deb10u1

to fix security problems, but calendar-google-provider has not been updated.

Anyone using the calendar-google-provider package must keep using the old
thunderbird with security vulnerabilities until the package is updated.



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)

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

Versions of packages calendar-google-provider depends on:
hi  lightning  1:60.9.0-1~deb10u1

calendar-google-provider recommends no packages.

calendar-google-provider suggests no packages.

-- no debconf information

Bug#945305: RM: node-graceful-readlink -- ROM; not used and unmaintained upstream

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (4) and was a build-dep of node-commander, but that 
dependency was removed with version 2.11.0:
https://github.com/tj/commander.js/blob/master/CHANGELOG.md#2110--2017-07-03
Also the upstream repo has last been updated 5 years ago.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Original ITP: https://bugs.debian.org/849178

Thanks, Paolo

Bug#945306: RM: node-object-assign-sorted -- ROM; currently not used

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (7) and is currently not used.
According to the ITP (https://bugs.debian.org/849255) it was required for lerna 
which was a dependency of babel-cli.
But in the meantime lerna is stuck at RFP (https://bugs.debian.org/849258) and 
babel-cli does not depend on either.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Thanks, Paolo

Bug#942106: python3.8 / pandas py2removal

[Rebecca N. Palmer]

On 22/11/2019 17:06, Graham Inggs wrote:

I scheduled statsmodels there, but it
still fails.


The error message points to joblib, which has just been uploaded 
(#942899): try again when the new version is available?

Bug#944284: xchm crashes on search

[Bernhard Übelacker]

Dear Maintainer,
I reported the issue upstream:

https://github.com/rzvncj/xCHM/issues/9

Kind regards,
Bernhard

Bug#945316: polymake: FTBFS with perl 5.30

[Andreas Beckmann]

Source: polymake
Version: 3.2r4-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libpolymake3.2

polymake FTBFS against perl 5.30:
https://buildd.debian.org/status/package.php?p=polymake=unstable

*** Summary ***

*** Failed tests ***

/<>/apps/polytope/src/gc_closure.cc:173: testcase 1
expected: regular return
 got: EXCEPTION: no more rules available to compute 
'HILBERT_BASIS_GENERATORS'

make[1]: *** [debian/rules:41: override_dh_auto_test] Error 1


Andreas

Bug#942106: python3.8 / pandas py2removal

[Graham Inggs]

On Fri, 22 Nov 2019 at 22:52, Rebecca N. Palmer  wrote:
> The error message points to joblib, which has just been uploaded
> (#942899): try again when the new version is available?

That worked, thanks.  I'll schedule the rest of the architectures later.

Bug#941803: debian-policy: dependencies on font packages

[Stephen Kitt]

On Fri, 22 Nov 2019 09:09:24 -0800, Russ Allbery  wrote:
> Julien Cristau  writes:
> > I don't think this change is good as-is.  The "don't depend on X font
> > packages" is still very much relevant, for applications that use the
> > "traditional" X font system, where the X server loads the fonts.  The X
> > server can still be on a different machine from the client.  
> 
> Argh, you are of course entirely correct, so I think this change may be
> wrong.  I just tested and indeed traditional bitmap fonts are still loaded
> from the X server, not from the client.  I had thought I'd tested that
> before but tested it incorrectly.

Yes, thanks Julien for pointing that out, I’ll follow up with a patch to
revert the change and update the explanation to remove mention of font
servers.

Regards,

Stephen


pgpjDyHN1sWds.pgp
Description: OpenPGP digital signature

Bug#945299: lintian: ignores all but last override of a tag

[Andreas Beckmann]

Package: lintian
Version: 2.37.0
Severity: serious
Justification: causes ftp-master autorejects

Hi,

this is a regression in 2.36 or 2.37. It worked fine up to 2.35.
In povray, I have this in debian/source/lintian-overrides:

= 8< =
# upstream did not release a source tarball,
# the .orig.tar.gz is an archived git tag
debian-watch-does-not-check-gpg-signature

# not used for the Unix build
source-contains-autogenerated-visual-c++-file windows/pvengine.rc
source-contains-autogenerated-visual-c++-file windows/resource.h
source-contains-autogenerated-visual-c++-file windows/cmedit/cmedit.rc
source-contains-autogenerated-visual-c++-file windows/cmedit/resource.h
source-contains-prebuilt-ms-help-file 
distribution/platform-specific/windows/Help/povray37.chm
source-contains-prebuilt-ms-help-file libraries/zlib/contrib/dotzlib/DotZLib.chm
= >8 =

and this in debian/povray-examples.lintian-overrides:

= 8< =
# these are a few small text files
duplicate-files usr/share/doc/povray/examples/templates/*.txt
duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/50_T_Stone2.jpg
 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/50_T_Stone3.jpg
= >8 =

but with lintian 2.37.0 I'm now getting these tags:

P: povray source: source-contains-autogenerated-visual-c++-file 
windows/pvengine.rc
P: povray source: source-contains-autogenerated-visual-c++-file 
windows/resource.h
P: povray source: source-contains-autogenerated-visual-c++-file 
windows/cmedit/cmedit.rc
E: povray source: source-contains-prebuilt-ms-help-file 
distribution/platform-specific/windows/Help/povray37.chm
I: povray source: testsuite-autopkgtest-missing

X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/51_T_Stone37.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/51_T_Stone38.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/00_Bright_Blue_Sky_Lo.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Skies_and_Clouds/00_Bright_Blue_Sky_Lo.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/50_T_Stone2.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/50_T_Stone3.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Metals/34_T_Silver_1A.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Metals/34_T_Silver_3A.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Mirrors_and_Glasses/82_NBglass_refraction.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Mirrors_and_Glasses/8B_VicksBottle_Glass_refr.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/41_T_Grnt23.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Stones_and_Granites/41_T_Grnt24.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Woods/10_EMBWood1.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Woods/11_DMFWood1.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Textures_Materials/Woods/31_PineWood2.txt
 
usr/share/doc/povray/examples/templates/Textures_Materials/Woods/32_PineWood3.txt
X: povray-examples: duplicate-files 
usr/share/doc/povray/examples/templates/Colors_in_textures/16_color_Gray25.txt 
usr/share/doc/povray/examples/templates/Colors_in_textures/17_color_Gray10.txt

This looks like only the last override for a tag is honored.

Setting severity to serious since this caused a ftp-master autoreject
for me (due to the .chm file).


Andreas

Bug#944794: stretch-pu: package dpdk/16.11.11+deb9u1

[Luca Boccassi]

On Fri, 2019-11-15 at 16:22 +, Adam D. Barratt wrote:
> On 2019-11-15 16:04, Luca Boccassi wrote:
> > On Fri, 2019-11-15 at 15:00 +, Adam D. Barratt wrote:
> > > On 2019-11-15 14:26, Luca Boccassi wrote:
> > > > This release has only one bug fix, which fixes a regression
> > > > introduced
> > > > by the fix for CVE-2019-14818 released on Tuesday via stretch-
> > > > security.
> > > 
> > > I assume that's not a sufficiently important regression that it
> > > needs
> > > fixing via -security? The next stretch point release is probably
> > > not
> > > for
> > > a couple of months.
> > > 
> > > Regards,
> > > 
> > > Adam
> > 
> > Hi,
> > 
> > It breaks some important functionality, but it does not introduce a
> > new
> > security issues. Does the security process allow a new -security
> > upload
> > in this case?
> 
> That's up to the Security Team. I'd suggest asking them and seeing
> what 
> they think.
> 
> Regards,
> 
> Adam

Hi,

The security team is OK with another DSA if it's a critical breakage.
I talked with the co-maintainer and we decided that it's uncommon
enough that we'll go through -pu unless someone raises a bug, and only
then consider an additional DSA.

We'd like the latest release in -pu regardless, so it should be
independent of this request.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#945301: libhsdis0-fcml: fails to install: find: '/usr/lib/jvm': No such file or directory

[Andreas Beckmann]

Package: libhsdis0-fcml
Version: 1.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up libhsdis0-fcml:amd64 (1.2.0-1) ...
  find: '/usr/lib/jvm': No such file or directory
  dpkg: error processing package libhsdis0-fcml:amd64 (--configure):
   installed libhsdis0-fcml:amd64 package post-installation script subprocess 
returned error exit status 1
  Processing triggers for libc-bin (2.29-3) ...
  Errors were encountered while processing:
   libhsdis0-fcml:amd64


cheers,

Andreas


libhsdis0-fcml_1.2.0-1.log.gz
Description: application/gzip

Bug#945302: RM: node-command-join -- ROM; currently not used

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (6) and is currently not used.

According to the ITP (https://bugs.debian.org/849254) it was required for lerna 
which was a dependency of babel-cli.
But in the meantime lerna is stuck at RFP (https://bugs.debian.org/849258) and 
babel-cli does not depend on either.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Thanks, Paolo

Bug#945276: lintian: ignores all but last override of a tag

[Felix Lechner]

Fixed in:


https://salsa.debian.org/lintian/lintian/commit/cbf3f6487b19d16a99e8582e24ddc2817a5487ac

Kind regards,
Felix Lechner

Bug#945313: libonig: CVE-2019-19204: heap-buffer-overflow in fetch_interval_quantifier due to double PFETCH

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/kkos/oniguruma/issues/162

Hi,

The following vulnerability was published for libonig.

CVE-2019-19204[0]:
| An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the
| function fetch_interval_quantifier (formerly known as
| fetch_range_quantifier) in regparse.c, PFETCH is called without
| checking PEND. This leads to a heap-based buffer over-read.


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-19204
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19204
[1] https://github.com/kkos/oniguruma/issues/162

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#937300: plaso: Python2 removal in sid/bullseye

[Sandro Tosi]

I've opened https://salsa.debian.org/pkg-security-team/plaso/merge_requests/1
and uploaded the same change sto DELAYED-7

On Fri, Nov 22, 2019 at 2:28 PM Moritz Mühlenhoff  wrote:
>
> On Wed, Nov 13, 2019 at 04:26:52PM -0500, Sandro Tosi wrote:
> > Hi Hilko,
> >
> > On Fri, 30 Aug 2019 07:31:12 + Matthias Klose  wrote:
> > > Package: src:plaso
> > > Version: 20190131-1
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-pyt...@lists.debian.org
> > > Usertags: py2removal
> >
> > can you just go ahead and remove py2 support here? thanks!
>
> And please also drop python-hachoir-core, python-hachoir-metadata and
> python-hachoir-parser from build deps. They're only used in the Py2
> package and blocking the removal of python-qt4 (and transitively
> Qt4).
>
> Cheers,
> Moritz



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Ansgar]

On Fri, 2019-11-22 at 09:05 -0800, Russ Allbery wrote:
> Simon McVittie  writes:
> > I had also thought that, in the current state of non-systemd-init-world,
> > having a dependency on a package containing systemd-tmpfiles was likely
> > to be practically problematic because it would indirectly conflict
> > with elogind, via libsystemd0 and its elogind reimplementation - but
> > looking more closely, systemd-tmpfiles and systemd-sysusers depend on
> > /lib/systemd/libsystemd-shared-243.so (and not on libsystemd0) so that
> > shouldn't actually be a problem.

As I said I'm interested in supporting environments with no init
installed and believe alternative init implementations happen to have
the same or similar needs here.  For environments with no init, it
would be useful to split out the -tmpfiles and -sysuser programs into a
separate package as people using container images are always concerned
about image sizes.

I tried linking -tmpfiles and -sysusers against a static version of
libsystemd-shared which increased binary size a bit: -tmpfiles was 212
kB (up from current 84 kB), -sysusers 137 kB (up from current 51 kB). 
But this should allow to safely split out the programs into a smaller
binary package.

> There's also the problem that while systemd-tmpfiles doesn't currently
> depend on systemd as PID 1, I'm dubious upstream is willing to make any
> guarantees that this will continue to be the case.

I would be surprised if upstream would break installing packages in
containers which often don't have systemd as pid-1 (as they have no
init at all).  There also seems no reason for them to use facilities
provided by pid-1.

> It's also not clear
> whether the project would be comfortable with us adopting new Policy
> guidance that inherently breaks the non-Linux ports (since I believe the
> systemd package does not build there).

We can make the guidance apply to only Linux and use other means on
non-Linux platform, just as we would for other Linux-specific parts
(any systemd .service files for example).  Altenratively, non-Linux
ports could choose to use an alternative implementation (which
reportedly already exists outside Debian).

> Let's hold off on this until the GR.  The GR won't be too far into the
> future, and will provide a very clear path forward for proposals like
> this.
> 
> Thank you very much for starting to work on it, though, and I'd be very
> happy to see specific proposed language in this bug that we can consider
> once the GR makes it clear how the project wants us to proceed with
> facilities like this.

I think no option says we shouldn't use services that don't rely on
systemd as pid-1 (which also includes widely used things like udev).

Ansgar

Bug#922568: ITA: jcc -- code generator producing a Python extension from Java classes

[Emmanuel Arias]

Hi,

I've just push to my own repository the new upstream release [1]

I have not access to [2].

Ludovico, could you give me access to [2], please? This way I can
update the package.

I will need sponsorship too :)

[1] https://salsa.debian.org/eamanu-guest/jcc
[2] https://salsa.debian.org/debian/jcc



Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El jue., 14 de nov. de 2019 a la(s) 17:52, Emmanuel Arias
(emmanuelaria...@gmail.com) escribió:
>
> Hi Ryan,
>
> Thanks for contact me.
>
> I was working on https://salsa.debian.org/eamanu-guest/jcc/. I can see
> that there a new upstream version 3.6
>
> I will update it today/tomorrow to last upstream version and I will let you 
> know
>
> I am not DD so, I will need sponsorship
>
> Thanks
>
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
>
> El jue., 14 de nov. de 2019 a la(s) 17:45, Ryan Tandy (r...@nardis.ca) 
> escribió:
> >
> > Dear Emmanuel,
> >
> > I was looking at the 'jcc' package and saw that your RFS bug (#925998)
> > was closed, but it doesn't look like an updated jcc was ever uploaded to
> > unstable.
> >
> > What's the status of jcc, please?
> >
> > Thank you,
> > Ryan

Bug#945310: clang-9: Sanitizer suppressions file can not be parsed

[Marco F]

Package: clang-9
Version: 1:9.0.0-3+b1
Severity: normal
Tags: upstream

Dear Maintainer,

clang-9 can not parse the sanitizer suppressions that it generated
itself.

To reproduce:

$ export UBSAN_OPTIONS="suppressions=./supp:report_error_type=1"
$  cat ./supp
implicit-signed-integer-truncation-or-sign-change:foo.cpp
$  cat ./foo.cpp
int f() { return (unsigned long){0} - 1; }
int main() { f(); }
$ clang++-9 -g -fsanitize=address,integer -o ./foo.exe ./foo.cpp && ./foo.exe
./foo.cpp:1:37: warning: implicit conversion from 'unsigned long' to 'int' 
changes value from 18446744073709551615 to -1 [-Wconstant-conversion]
int f() { return (unsigned long){0} - 1; }
  ~~ ~~~^~~
1 warning generated.
AddressSanitizer: failed to parse suppressions

To verify the suppression name has no typo, clear the file and run the
command again:

$  echo "" > ./supp
$ clang++-9 -g -fsanitize=address,integer -o ./foo.exe ./foo.cpp && ./foo.exe
./foo.cpp:1:37: warning: implicit conversion from 'unsigned long' to 'int' 
changes value from 18446744073709551615 to -1 [-Wconstant-conversion]
int f() { return (unsigned long){0} - 1; }
  ~~ ~~~^~~
1 warning generated.
foo.cpp:1:37: runtime error: unsigned integer overflow: 0 - 1 cannot be 
represented in type 'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: unsigned-integer-overflow foo.cpp:1:37 in
foo.cpp:1:18: runtime error: implicit conversion from type 'unsigned long' of 
value 18446744073709551615 (64-bit, unsigned) to type 'int' changed the value 
to -1 (32-bit, signed)
SUMMARY: UndefinedBehaviorSanitizer: 
implicit-signed-integer-truncation-or-sign-change foo.cpp:1:18 in

Note that everything can be properly suppressed when using `unsigned`
instead of `unsigned long`.

Thanks,
Marco

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

Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages clang-9 depends on:
ii  binutils   2.33.1-4
ii  libc6  2.29-3
ii  libc6-dev  2.29-3
ii  libclang-common-9-dev  1:9.0.0-3+b1
ii  libclang-cpp9  1:9.0.0-3+b1
ii  libgcc-8-dev   8.3.0-24
ii  libgcc11:9.2.1-19
ii  libllvm9   1:9.0.0-3+b1
ii  libobjc-8-dev  8.3.0-24
ii  libstdc++-8-dev8.3.0-24
ii  libstdc++6 9.2.1-19

Versions of packages clang-9 recommends:
ii  libomp-9-dev  1:9.0.0-3+b1
ii  llvm-9-dev1:9.0.0-3+b1
ii  python3   3.7.5-3

Versions of packages clang-9 suggests:
pn  clang-9-doc  

-- no debconf information

Bug#945315: pan: error sending posts

[Jerzy Wolinski]

Package: pan
Version: 0.146-1
Severity: important

Dear Maintainer,

pan stopped sending posts.

After "Send Article" it says:

There were problems with the post. / Error: bad email address. / Go back
Continue Anyway

After "Continue anyway" task is hanging.

In pan's Events register I can see

Posting of "Pst sub" failed: 441 Duplicate Content-Type: header

This error was observed on three Debian testing systems, using two news
servers.




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

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

Versions of packages pan depends on:
ii  gnome-keyring   3.34.0-1
ii  gnupg   2.2.17-3
ii  libc6   2.29-3
ii  libcairo2   1.16.0-4
ii  libenchant1c2a  1.6.0-11.3
ii  libgcc1 1:9.2.1-19
ii  libgcr-base-3-1 3.33.4-2
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1
ii  libglib2.0-02.62.2-3
ii  libgmime-3.0-0  3.2.4-1
ii  libgnutls30 3.6.10-5
ii  libgtk-3-0  3.24.12-1
ii  libgtkspell3-3-03.0.9-3
ii  libnotify4  0.7.8-1
ii  libpango-1.0-0  1.42.4-7
ii  libsecret-1-0   0.19.1-1
ii  libstdc++6  9.2.1-19
ii  zlib1g  1:1.2.11.dfsg-1+b1

pan recommends no packages.

pan suggests no packages.

-- no debconf information

Bug#945300: lists.debian.org: description update for debian-stable-announce

[Adam D. Barratt]

Package: lists.debian.org

Hi,

The list description for debian-stable-announce currently reads:

Announcements relating to the stable-update section include new uploads
and changes

The suite is named "stable-updates", and the wording doesn't quite feel
right. Thus, please change the description to:

Announcements relating to the stable-updates section, including new
uploads and changes

Thanks,

Adam

Bug#937300: plaso: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Wed, Nov 13, 2019 at 04:26:52PM -0500, Sandro Tosi wrote:
> Hi Hilko,
> 
> On Fri, 30 Aug 2019 07:31:12 + Matthias Klose  wrote:
> > Package: src:plaso
> > Version: 20190131-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> 
> can you just go ahead and remove py2 support here? thanks!

And please also drop python-hachoir-core, python-hachoir-metadata and
python-hachoir-parser from build deps. They're only used in the Py2
package and blocking the removal of python-qt4 (and transitively
Qt4).

Cheers,
Moritz

Bug#945307: RM: node-pad -- ROM; not used

[Paolo Greppi]

Package: ftp.debian.org
Severity: normal

This package has low popcon (7) and is not used anywhere in Debian.

The maintainer is the Debian Javascript Maintainers team of which I am part of.
My intention to remove it was announced in the team mailing list about 3 weeks 
ago:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/036848.html

Original ITP: https://bugs.debian.org/849182

Thanks, Paolo

Bug#945311: bbmap: Sources ship binary objects

[Adrian Bunk]

Source: bbmap
Version: 38.63+dfsg-1
Severity: serious

$ file jni/*.o jni/*.dylib
jni/BBMergeOverlapper.o:ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
jni/BandedAlignerJNI.o: ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
jni/IceCreamAlignerJNI.o:   ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
jni/MultiStateAligner11tsJNI.o: ELF 64-bit LSB relocatable, x86-64, version 1 
(SYSV), not stripped
jni/libbbtoolsjni.dylib:Mach-O 64-bit x86_64 dynamically linked shared 
library, flags:
bunk@localhost:/tmp/bbmap-38.63+dfsg$ less jni/libbbtoolsjni.dylib
$

The .o objects are rebuilt after removing them manually,
so adding *.o and *.dylib to Files-Excluded: should fix it.

Bug#945259: povray FTCBFS: broken, oudated, embedded copy of AX_BOOST_BASE

[Helmut Grohne]

Hi Andreas,

On Fri, Nov 22, 2019 at 05:05:33PM +0100, Andreas Beckmann wrote:
> Does the latest version of ax_boost_base.m4 available from
> https://www.gnu.org/software/autoconf-archive/ax_boost_base.html contain
> the fixes? I'd like to point upstream to that location with "please
> update your embedded copy of ..."

Your link points to
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_boost_base.m4.
This has advanced beyond the version in my patch and should work.

In any case, it would be much better if povray could use the version
from the autoconf-archive binary package. In case we encounter another
bug, that'd save a lot of time. It shouldn't matter which version
upstream embeds.

The fact that I've re-encountered this issue for the sixth time now is a
testament of how bad this practice of embedding the copy is. Embedding
would be cool if people were updating their copies, but AX_BOOST_BASE
was fixed more than two years ago. Policy discourages such copies for a
reason.

Helmut

Bug#945317: xcftools: CVE-2019-5086 CVE-2019-5087

[Salvatore Bonaccorso]

Source: xcftools
Version: 1.0.7-6
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for xcftools.

CVE-2019-5086[0]:
| An exploitable integer overflow vulnerability exists in the
| flattenIncrementally function in the xcf2png and xcf2pnm binaries of
| xcftools, version 1.0.7. An integer overflow can occur while walking
| through tiles that could be exploited to corrupt memory and execute
| arbitrary code. In order to trigger this vulnerability, a victim would
| need to open a specially crafted XCF file.


CVE-2019-5087[1]:
| An exploitable integer overflow vulnerability exists in the
| flattenIncrementally function in the xcf2png and xcf2pnm binaries of
| xcftools 1.0.7. An integer overflow can occur while calculating the
| row's allocation size, that could be exploited to corrupt memory and
| eventually execute arbitrary code. In order to trigger this
| vulnerability, a victim would need to open a specially crafted XCF
| file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-5086
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5086
[1] https://security-tracker.debian.org/tracker/CVE-2019-5087
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5087

Please adjust the affected versions in the BTS as needed.

Is xcftools still maintained (upstream)?

Regards,
Salvatore

Bug#945259: povray FTCBFS: broken, oudated, embedded copy of AX_BOOST_BASE

[Andreas Beckmann]

On 22/11/2019 21.51, Helmut Grohne wrote:
> In any case, it would be much better if povray could use the version
> from the autoconf-archive binary package. In case we encounter another
> bug, that'd save a lot of time. It shouldn't matter which version
> upstream embeds.

I'm now B-D: autoconf-archive and

@build:
+   set -e ; cd unix/config && for ax in *.m4 ; do if [ ! -h "$$ax" ] && [ 
-f "/usr/share/aclocal/$$ax" ]; then mv -v "$$ax" "$$ax.dist" ; ln -sv 
"/usr/share/aclocal/$$ax" ; fi ; done

@clean:
+   set -e ; cd unix/config && for ax in *.m4.dist ; do if [ -f "$$ax" ] ; 
then mv -v "$$ax" "$${ax%.dist}" ; fi ; done

Only some of the ax_*.m4 files used by povray are available in autoconf-archive 
:-(

Upload got autorejected due to Lintian bug #945299,
waiting for fixed lintian (already in sid) to reach ftp-master ...


Andreas

Bug#942022: librsvg: FTBFS on ppc64el: assertion failed: bounds.x1 >= bounds.x0

[Olivier Tilloy]

Note that ubuntu focal (current development version) has rustc 1.38,
and librsvg 2.44.15 fails to build from source with it. The upstream
project committed a fix to the 2.44 branch
(https://gitlab.gnome.org/GNOME/librsvg/commit/de26c4d8), but they
advise packaging 2.46 instead as 2.44 is EOL.

Bug#940578: fixed in cups 2.3.0-6

[Rudolf Polzer]

Hi intrigeri,

please make a suggestion how I should now proceed to get pdf printing 
running on my stable Debian, because selecting a subdirectory of home 
doesn't work - I get the same error message as before.


Regards,
Rudolf

Bug#944284: xchm crashes on search

[Bernhard Übelacker]

Control: tags -1 + upstream patch


Dear Maintainer,
I could reproduce the crash with some old versions of
php_enhanced_en.chm I found on the net [1].

The current version from php.net [2] does not crash.
While it looks like the search is also not working
and gives no results.

With a package built with the attached patch I could
search in both versions, and received the same results
like in windows.

Kind regards,
Bernhard


[1]
http://jftp.just.edu.tw/Edoc/php_enhanced_en.chm
http://ftp.ntu.edu.tw/php/distributions/manual/php_enhanced_kr.chm

[2]
https://www.php.net/distributions/manual/php_enhanced_en.chm

Backtrace:
(gdb) bt
#0  0x004a166e in memcpy (__len=, __src=, 
__dest=0xa2f4e0) at /usr/include/i386-linux-gnu/bits/string_fortified.h:34
#1  CHMFile::GetLeafNodeOffset (this=, text=..., 
initialOffset=, buffSize=, treeDepth=, ui=) at chmfile.cpp:974
#2  0x004a657f in CHMFile::IndexSearch (this=0xa5e720, text=..., 
wholeWords=true, titlesOnly=false, results=0xbf9b2848) at chmfile.cpp:818
#3  0x004be8a4 in CHMSearchPanel::OnSearch (this=0x97c060) at 
/usr/include/wx-3.0/wx/checkbox.h:63
#4  0xb75e9cdf in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, 
wxEventFunctor&, wxEvent&) const () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#5  0xb777c5f8 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase 
const&, wxEvtHandler*, wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#6  0xb777c716 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () 
from /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#7  0xb777caac in wxEvtHandler::TryHereOnly(wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
#8  0xb777cb3a in wxEvtHandler::ProcessEventLocally(wxEvent&) () from 
/usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
...
Description: Avoid crash and make search work for specific file
 This is an attempt to start the search at the begin
 every time a block is received from chm_retrieve_object.
 Delivers the same search results as Windows 7 CHM viewer.

Author: Bernhard Übelacker 

Bug-Debian: https://bugs.debian.org/944284
Forwarded: no
Last-Update: 2019-11-22

--- xchm-1.23.orig/src/chmfile.cpp
+++ xchm-1.23/src/chmfile.cpp
@@ -985,6 +985,7 @@ uint32_t CHMFile::GetLeafNodeOffset(cons
 			if(text.CmpNoCase(word) <= 0) {
 cursor32 = buffer.get() + i + word_len + 1;
 initialOffset = UINT32ARRAY(cursor32);
+i = sizeof(uint16_t);
 break;
 			}
 

# Buster/stable i386 qemu VM 2019-11-22

apt update
apt dist-upgrade

apt install dpkg-dev devscripts systemd-coredump xserver-xorg lightdm openbox 
xterm mc gdb xchm xchm-dbgsym
apt build-dep libchm1
apt build-dep xchm

reboot


mkdir /home/benutzer/source/xchm/orig -p
cd/home/benutzer/source/xchm/orig
apt source xchm
cd

mkdir /home/benutzer/source/libchm1/orig -p
cd/home/benutzer/source/libchm1/orig
apt source libchm1
cd


export LANG=C
export DISPLAY=:0





dmesg:
[78147.255491] xchm[18096]: segfault at 2749000 ip 0046d66e sp bfa35c30 error 4 
in xchm[46+3c000]
[78147.255515] Code: 04 0f 82 a5 fd ff ff 8b 06 8b 95 3c ff ff ff 89 02 8b 44 
0e fc 8d 7a 04 83 e7 fc 89 44 0a fc 89 d0 29 f8 01 c1 29 c6 c1 e9 02  a5 e9 
8d fd ff ff 8d 76 00 85 c0 0f 84 10 02 00 00 50 8b 85 10

0x0046d66e - 0x46 + 0x3c000 = 0x4966E

benutzer@debian:~$ addr2line --function --demangle --exe=/usr/bin/xchm 0x4966E
wxNavigationEnabled::AcceptsFocusRecursively() const
/usr/include/wx-3.0/wx/buffer.h:44


gdb -q --args /usr/bin/xchm

set width 0
set pagination off
directory /home/benutzer/source/xchm/orig/xchm-1.23/src
b main
run
dele 1

(gdb) info target
0x004196b0 - 0x00453d34 is .text

(gdb) find /b 0x004196b0, 0x00453d34, 0x04, 0x0f, 0x82, 0xa5, 0xfd, 0xff, 0xff, 
0x8b, 0x06, 0x8b, 0x95, 0x3c, 0xff, 0xff, 0xff, 0x89, 0x02, 0x8b, 0x44, 0x0e, 
0xfc, 0x8d, 0x7a, 0x04, 0x83, 0xe7, 0xfc, 0x89, 0x44, 0x0a, 0xfc, 0x89, 0xd0, 
0x29, 0xf8, 0x01, 0xc1, 0x29, 0xc6, 0xc1, 0xe9, 0x02, 0xf3, 0xa5, 0xe9, 0x8d, 
0xfd, 0xff, 0xff, 0x8d, 0x76, 0x00, 0x85, 0xc0, 0x0f, 0x84, 0x10, 0x02, 0x00, 
0x00, 0x50, 0x8b, 0x85, 0x10

0x425644 
1 pattern found.

(gdb) disassemble /r 0x425644,0x425644+62
Dump of assembler code from 0x425644 to 0x425682:
   0x00425644 :  04 0f   add$0xf,%al
   0x00425646 :  82 a5 fd ff ff 8b 06
andb   $0x6,-0x7403(%ebp)
   0x0042564d :  8b 95 3c ff ff ff   
mov-0xc4(%ebp),%edx
   0x00425653 :  89 02   mov
%eax,(%edx)
   0x00425655 :  8b 44 0e fc mov
-0x4(%esi,%ecx,1),%eax
   0x00425659 :  8d 7a 04lea
0x4(%edx),%edi
   0x0042565c :  83 e7 fcand
$0xfffc,%edi
   0x0042565f :  89 44 0a fc mov
%eax,-0x4(%edx,%ecx,1)
   0x00425663 :  89 d0   mov%edx,%eax
   0x00425665 :  29 f8   sub%edi,%eax
   0x00425667 :  01 c1   add%eax,%ecx
   0x00425669 :  29 c6   sub%eax,%esi
   0x0042566b :  c1 e9 02shr
$0x2,%ecx
   0x0042566e :  f3 a5   rep movsl 
%ds:(%esi),%es:(%edi)
   

Bug#945314: freecad: FTBFS on several architectures

[Andreas Beckmann]

Source: freecad
Version: 0.18.4+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libfreecad-python3-0.18

freecad did FTBFS on amd64, i386, armhf during the recent binNMU
against current pyside2, but this could be related to python3.8, too:
https://buildd.debian.org/status/package.php?p=freecad=unstable

Andreas

Bug#945308: RM: node-array-from -- ROM; is only used by node-command-join

[Scott Kitterman]

On Fri, 22 Nov 2019 20:33:26 +0100 Paolo Greppi  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> This package has low popcon (10) and is only used by node-command-join (see 
https://bugs.debian.org/945302).
> If we ever need it again, it can be embedded (~ 200 LOC).
> 
> The maintainer is the Debian Javascript Maintainers team of which I am part 
of.
> My intention to remove it was announced in the team mailing list about 3 
weeks ago:
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-October/
036848.html

Apparently there is another user:

Checking reverse dependencies...
# Broken Depends:
node-sinon: node-sinon

# Broken Build-Depends:
node-sinon: node-array-from

Dependency problem found.

Please remove the moreinfo to once that's resolved.  If you decide against the 
removal, please just close the bug.

Scott K

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

Bug#945321: Do not suggest practices discouraged by policy

[Ryan Kavanagh]

Source: maint-guide
Version: 1.2.43
Severity: normal
Tags: patch

§5.10 of maint-guide mentions using /etc/default to disable a demon. However,
§9.3.3.1 of Debian Policy states

An older practice, which should not be used, was to include a line
like DISABLED=yes in the package’s /etc/default file. The package’s
init script would not start the service until the local system
administrator changed this to DISABLED=no, or similar. [...]

maint-guide should not suggest discouraged practices as valid use cases.

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
From c5ad787ac447527aa12d1f5f20634d9a0e6a0db4 Mon Sep 17 00:00:00 2001
From: Ryan Kavanagh 
Date: Fri, 22 Nov 2019 18:17:36 -0500
Subject: [PATCH] /etc/default should not be used to disable services
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

§9.3.3.1 of Debian Policy states

An older practice, which should not be used, was to include a line
like DISABLED=yes in the package’s /etc/default file. The package’s
init script would not start the service until the local system
administrator changed this to DISABLED=no, or similar. [...]

maint-guide should not suggest discouraged practices as valid use cases.
---
 doc/05_dother.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/05_dother.xml b/doc/05_dother.xml
index 6e78b5a..31f70f9 100644
--- a/doc/05_dother.xml
+++ b/doc/05_dother.xml
@@ -341,7 +341,7 @@ be installed as
 /etc/default/package.  This
 file sets defaults that are sourced by the init script.  This
 package.default file
-is most often used to disable running a daemon, or to set some default flags or
+is most often used to set some default flags or
 timeouts.  If your init script has certain configurable
 features, you can set them in the package.default file,
 instead of in the init script itself.
-- 
2.24.0



signature.asc
Description: PGP signature

Bug#945322: ruby-maxitest: uninstallable in sid: Depends: ruby-minitest (< 5.12.0) but 5.13.0-1 is to be installed

[Andreas Beckmann]

Package: ruby-maxitest
Version: 3.1.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   ruby-maxitest : Depends: ruby-minitest (< 5.12.0) but 5.13.0-1 is to be 
installed


Cheers,

Andreas

Bug#945324: libldns2: CDS/CDNSKEY RRs are signed with ZSK instead of KSK (upstream patch attached)

[Jukka Salmi]

Package: libldns2
Version: 1.7.0-4

Dear maintainer

The ldns library from stable, testing and unstable (libldns2 1.7.0-4)
signs CDS and CDNSKEY RRs with the ZSK; such RRs must be signed with the
KSK instead (see RFC 7344 section 4.1). This bug makes managing DS RRs
in the parent zone via CDS and CDNSKEY RRs impossible.

This bug has been [1]reported and [2]fixed in ldns-1.7.1.

[1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=3437
[2] https://git.nlnetlabs.nl/ldns/commit/?id=f3c465b9

I applied [2]that patch on a Debian buster system and it indeed fixed
the problem. Please find the debdiff output attached.


Cheers, Jukka

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libldns2 depends on:
ii  libc6  2.28-10
ii  libssl1.1  1.1.1d-0+deb10u2

libldns2 recommends no packages.

libldns2 suggests no packages.

-- no debconf information

-- 
This email fills a much-needed gap in your mailbox.
diff -Nru ldns-1.7.0/debian/changelog ldns-1.7.0/debian/changelog
--- ldns-1.7.0/debian/changelog 2019-03-10 21:56:02.0 +
+++ ldns-1.7.0/debian/changelog 2019-11-23 00:05:23.0 +
@@ -1,3 +1,11 @@
+ldns (1.7.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix to sign CDS and CDNSKEY RRs with KSK instead of ZSK
+(as specified in RFC 7344 section 4.1)
+
+ -- Jukka Salmi   Sat, 23 Nov 2019 00:05:23 +
+
 ldns (1.7.0-4) unstable; urgency=medium
 
   * Fix invalid maintainer (Closes: #899938)
diff -Nru ldns-1.7.0/debian/patches/0004-sign-CDS-CDNSKEY-with-KSK.patch 
ldns-1.7.0/debian/patches/0004-sign-CDS-CDNSKEY-with-KSK.patch
--- ldns-1.7.0/debian/patches/0004-sign-CDS-CDNSKEY-with-KSK.patch  
1970-01-01 00:00:00.0 +
+++ ldns-1.7.0/debian/patches/0004-sign-CDS-CDNSKEY-with-KSK.patch  
2019-11-23 00:05:19.0 +
@@ -0,0 +1,38 @@
+From: Tony Finch 
+Date: Fri, 9 Mar 2018 17:55:58 +
+Subject: Your CDS RR is not signed with your KSK as specified in RFC7344
+
+Willem Toorop  wrote:
+
+> Yes indeed!  I've created a bug report for it:
+>
+> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=3437
+
+I think the following patch fixes it. (I don't have an account on your 
bugzilla)
+---
+ dnssec_sign.c | 13 -
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/dnssec_sign.c
 b/dnssec_sign.c
+@@ -1251,12 +1251,15 @@
+   
key_list,
+   
func,
+   
arg);
+-  if(!(flags_SIGN_DNSKEY_WITH_ZSK) &&
+-  cur_rrset->type == LDNS_RR_TYPE_DNSKEY)
+-  
ldns_key_list_filter_for_dnskey(key_list, flags);
+-
+-  if(cur_rrset->type != LDNS_RR_TYPE_DNSKEY)
++  if(cur_rrset->type == LDNS_RR_TYPE_DNSKEY ||
++ cur_rrset->type == LDNS_RR_TYPE_CDNSKEY ||
++ cur_rrset->type == LDNS_RR_TYPE_CDS) {
++  if(!(flags_SIGN_DNSKEY_WITH_ZSK)) {
++  
ldns_key_list_filter_for_dnskey(key_list, flags);
++  }
++  } else {
+   
ldns_key_list_filter_for_non_dnskey(key_list, flags);
++  }
+ 
+   /* TODO: just set count to zero? */
+   rr_list = ldns_rr_list_new();
diff -Nru ldns-1.7.0/debian/patches/series ldns-1.7.0/debian/patches/series
--- ldns-1.7.0/debian/patches/series2019-03-10 21:56:02.0 +
+++ ldns-1.7.0/debian/patches/series2019-11-23 00:04:49.0 +
@@ -1,2 +1,3 @@
 0002-Check-parse-limit-before-t-increment.patch
 0003-bugfix-1257-Free-after-reallocing-to-0-size.patch
+0004-sign-CDS-CDNSKEY-with-KSK.patch

Bug#945326: pysph ftbfs in unstable

[Matthias Klose]

Package: src:pysph
Version: 1.0~a6-3
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

pysph ftbfs in unstable.
https://buildd.debian.org/status/fetch.php?pkg=pysph=amd64=1.0%7Ea6-3%2Bb1=1574243914=0

= 45 failed, 635 passed, 283 skipped, 71 deselected, 179 warnings in 287.61
seconds =
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd
'/<>/.pybuild/cpython3_3.8/build'; python3.8 -m pytest -k 'not
test_sph_evaluator and not TestInterpolator'
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.8 3.7"
returned exit code 13
make: *** [debian/rules:7: build-arch] Error 255


most common error:

def _compile_text(template, text, filename):
identifier = template.module_id
source, lexer = _compile(template, text, filename,
 
generate_magic_comment=template.disable_unicode)

cid = identifier
if not compat.py3k and isinstance(cid, compat.text_type):
cid = cid.encode()
module = types.ModuleType(cid)
>   code = compile(source, cid, 'exec')
E File
"_build_pysph_QcCWdC_pysph_1_0_a6__pybuild_cpython3_3_8_build_pysph_sph_acceleration_eval_cython_mako",
line 20
E   def do_group(helper,group,level=):
E   ^
E   SyntaxError: invalid syntax

/usr/lib/python3/dist-packages/mako/template.py:711: SyntaxError

Bug#945327: python-pomegranate ftbfs in unstable

[Matthias Klose]

Package: src:python-pomegranate
Version: 0.11.1+dfsg2-1
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

[...]
==
ERROR: Failure: AttributeError (type object 'pomegranate.hmm.array' has no
attribute '__reduce_cython__')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in
loadTestsFromName
module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.8/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.8/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 702, in _load
  File "", line 671, in _load_unlocked
  File "", line 783, in exec_module
  File "", line 219, in _call_with_frames_removed
  File
"/<>/.pybuild/cpython3_3.8_pomegranate/build/tests/test_profile_hmm.py",
line 3, in 
from pomegranate import *
  File
"/<>/.pybuild/cpython3_3.8_pomegranate/build/pomegranate/__init__.py",
line 12, in 
from .parallel import *
  File "pomegranate/parallel.pyx", line 10, in init pomegranate.parallel
from .hmm import HiddenMarkovModel
  File "stringsource", line 105, in init pomegranate.hmm
AttributeError: type object 'pomegranate.hmm.array' has no attribute
'__reduce_cython__'

--
Ran 11 tests in 0.007s

FAILED (errors=11)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.8_pomegranate/build; python3.8 -m nose -v 
tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.8 3.7"
returned exit code 13
make: *** [debian/rules:10: build-arch] Error 255

Bug#930176: dh-golang: support cross building go packages

[Anthony Fok]

Hi Helmut,

Thank you for your contribution.
I have applied your patch in the upload of dh-golang 1.43.

I see that there are more challenges that need to be tackled with a
complete solution for cross-building Go Debian packages, so I have
reopened this bug, so please feel free to continue the discussion
here.  Alternatively, if you prefer to start another bug report,
please feel free to do that too and close this one instead.

Cheers,
Anthony

Bug#945206: tracker.debian.org: Broken binaries link in glibc page

[Paul Wise]

On Fri, Nov 22, 2019 at 4:21 PM Raphael Hertzog wrote:

> Those are binary packages that the glibc source package can build but that
> it only builds on non-release architectures... so indeed the binary
> packages are unknown by packages.debian.org which only knows about
> packages available on official mirrors.

packages.d.o is supposed to have support for the unofficial ports
arches, for example it knows about libc6 on hppa, including the
package contents. That it doesn't know about libc0.3 (for eg), which
does exist on the unofficial ports archive, seems like either a bug in
ports or in packages.d.o itself to me, not a bug in tracker.d.o.

https://packages.debian.org/sid/hppa/libc6/filelist
http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/glibc/libc0.3_2.29-3_hurd-i386.deb

-- 
bye,
pabs

https://wiki.debian.org/PaulWise