Bug#975428: RFS: task-spooler/1.0+dfsg1-1 -- personal job scheduler

[Alexander Inyukhin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "task-spooler":

 * Package name: task-spooler
   Version : 1.0+dfsg1-1
   Upstream Author : Lluís Batlle i Rossel 
 * URL : http://viric.name/soft/ts/
 * License : GPL-2, LDP-GPL-1
 * Vcs : https://salsa.debian.org/debian/task-spooler/
   Section : misc

It builds those binary packages:

  task-spooler - personal job scheduler

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

  https://mentors.debian.net/package/task-spooler/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_1.0+dfsg1-1.dsc

Changes since the last upload:

 task-spooler (1.0+dfsg1-1) unstable; urgency=medium
 .
   * Update Vcs-Git and Vcs-Browser fields in debian/control.
   * Use https for copyright-format
   * Add upstream metadata file
   * Fix buffer overflow (closes: #975321)
   * Update to standards version 4.5.0
   * Exclude copyrighted material and unneeded files
   * Upgrade watch file to version 4 and repack source
   * New upstream version 1.0+dfsg1
   * Use debhelper v13

Bug#974218: node-requirejs: Please embed typescript definitions

[Xavier]

Le 14/11/2020 à 12:14, László Böszörményi (GCS) a écrit :
> Hi,
> 
> On Wed, Nov 11, 2020 at 2:39 PM Xavier Guimard  wrote:
>> Package: node-requirejs
> [...]
>> to avoid version conflicts, JS team decided to remove typescript
>> definitions (node-typescript-types) and embed them directly in the
>> relevant packages.
>>
>> node-requirejs isn't under JS Team umbrella, so we can't do it for
>> @types/requirejs. But we need to synchronize this work (needs to
>> repack node-typescript-types and add a "Breaks" in your package).
>> Could you do it or give us its maintenance?
>  If you ask me, feel free to take over. But please note that recent
> uploads are done by Georges. You should get his permission first as
> well.
> 
> Regards,
> Laszlo/GCS

Hi,

for the same reason, can I also takeover libjs-sizzle maintenance ?

Cheers,
Xavier

Bug#975427: icedax: Issues in man pages

[Helge Kreutzmann]

Package: icedax
Severity: minor

Dear icedax maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including icedax) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Man page: cdda2ogg.1
Issue: strange first sentence, bad markup

"B BfileprefixE> "
"command to extract all audio tracks with the BfileprefixE> "
"command and encode them using the B respective IcensoredE> "
"MP3 encoder. The scripts are not intended to be full-featured music "
"archiving programs, but only for quick storing of few audio data.  It does "
"not use databases like CDDB or have any extra features. You may look at "
"B if you need them."
--
Man page: cdda2ogg.1
Issue: cddawav → B(1)

"Defines the command to run the cdda2wav program"
--
Man page: cdda2ogg.1
Issue: cdda2ogg (cdda2mp3) → B (B)

"See cdda2ogg (cdda2mp3) script file to get the default values"
--
Man page: cdda2ogg.1
Issue: alioth no longer exists, link needs update

"This manpage describes the program implementation of B as shipped "
"by the cdrkit distribution. See B for details. It is a spinoff from the original program distributed by the "
"cdrtools project. However, the cdrtools developers are not involved in the "
"development of this spinoff and therefore shall not be made responsible for "
"any problem caused by it. Do not try to get support for this program by "
"contacting the original authors."
--
Man page: cdda2ogg.1
Issue: broken markup

"This manual page was written by Eduard Bloch (bl...@debian.org) for the "
"B to copy, distribute and/or modify this document under the terms of "
"the GNU General Public License, Version 2 as published by the Free Software "
"Foundation."
--
Man page: cdda2ogg.1
Issue: cdda2ogg → B

"See cdda2ogg script file to get the default values"

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#974729: #974729, mailcap 3.67: obsolete conffiles

[Xk2c]

Hi,

% command dpkg-query -W -f='${Conffiles}\n' mime-support
 /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete

% command dpkg-query -W -f='${Conffiles}\n' media-types
 /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35

% command dpkg-query -W -f='${Conffiles}\n' mailcap
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

As it seems dpkg keeps track of conffiles in /var/lib/dpkg/status.
Here is an excerpt, watch out for the Conffiles sections:


,[  /var/lib/dpkg/status  ]

Package: mime-support
Status: install ok installed
Priority: standard
Section: net
Installed-Size: 17
Maintainer: Mime-Support Packagers 


Architecture: all
Multi-Arch: foreign
Version: 3.66
Depends: mailcap, media-types
Conffiles:
 /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
.
.
.
Package: media-types
Status: install ok installed
Priority: standard
Section: net
Installed-Size: 46
Maintainer: Mime-Support Packagers 


Architecture: all
Multi-Arch: foreign
Version: 1.0.1
Replaces: mime-support (<= 3.64)
Breaks: mime-support (<= 3.64)
Conffiles:
 /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35
.
.
.
Package: mailcap
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 86
Maintainer: Mime-Support Packagers 


Architecture: all
Multi-Arch: foreign
Version: 3.67
Replaces: mime-support (<= 3.64)
Provides: run-mailcap
Depends: perl, media-types
Recommends: bzip2, file, xz-utils
Breaks: mime-support (<= 3.64)
Conffiles:
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
`---

did a backup and manually removed the Conffiles section from pkg
mime-support.

Now i have:

% command dpkg-query -W -f='${Conffiles}\n' mime-support
[empty line, no output]

% command dpkg-query -W -f='${Conffiles}\n' media-types
 /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35

% command dpkg-query -W -f='${Conffiles}\n' mailcap
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

unless someone says that breaks s.th. i live with that.

Thanks.



kind regards,

 Thilo

Bug#968980: installation-reports: systemctl status networking.service "failed" but Wicd works fine (LXDE)

[Avinash Sonawane]

On Tue, 25 Aug 2020 01:42:52 -0300 nora-v  wrote:
> $ systemctl status networking.service
> ● networking.service - Raise network interfaces
>Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
> prese
>Active: failed (Result: exit-code) since Mon 2020-08-24 22:41:10 -03; 2h 
> 54mi
>  Docs: man:interfaces(5)
>  Main PID: 423 (code=exited, status=1/FAILURE)
>
> And also:
>
> $ cat /etc/network/interfaces
> source-directory /etc/network/interfaces.d
> $ cat /etc/network/interfaces.d/setup
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet dhcp

I experienced this exact same issue with this exact
/etc/network/interfaces.d/setup file contents with Debian 10.6.0 live
XFCE non-free iso fetched from
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current-live/amd64/iso-hybrid/debian-live-10.6.0-amd64-xfce+nonfree.iso

I fixed it with this command:
$ sudo sed -i 's/eth0/enp1s0/g' /etc/network/interfaces.d/setup

where I found `enp1s0` in `$ ip l` output.

Bug#975416: [Pkg-nagios-devel] Bug#975416: icinga2: FTBFS against boost_1.74

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/Icinga/icinga2/issues/8493

Hi Anton,

Thanks for reporting this issue, I've forwarded it upstream.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#975424: cinnamon: systemd NetworkManager units disabled, dhclient still asking for ip at boot

[frankenDist]

Package: cinnamon
Version: 4.6.6-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
· I'm trying to disable dhclient, i see this when 
capturing traffic:
---
sudo tcpdump -vv -i enp37s0 |grep -i 
dhc -a20
tcpdump: listening on enp37s0, link-type EN10MB (Ethernet), capture 
size 262144 bytes
[...]
01:27:52.961625 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], 
proto UDP (17), length 314)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, 
Request from [edited_mac_from_my_cablemodem] (oui Unknown), length 286, xid 
0x5afcab45, secs 60504, Flags [none] (0x)
  Client-Ethernet-Address [edited_mac_from_my_cablemodem] (oui 
Unknown)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 
[edited_mac_from_my_cablemodem]
Requested-IP Option 50, length 4: 192.168.0.10
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 7: 
  Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
  Domain-Name, BR, NTP
Vendor-Class Option 60, length 12: "udhcp 1.19.3"

I am almost 100% sure that the MAC address is from my 
cablemodem, since it only differs in the last bit from the MAC of the 
cablemodem my Debian OS knows in the arp -a output, the tcpdump mac ends with 2 
and the arp -a entry ends with 0.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
· The DHCP server in my cablemodem is disabled, the APs 
are also disabled (just to be clear, the DHCPDISCOVER isn't from other device), 
no more devices are connected to my main (and only one network device).
+ I have systemctl disable && systemctl mask the 
following units:
- NetworkManager.service
- NetworkManager-wait-online.service
- NetworkManager-dispatcher.service
· I have also edited the line 
"ExecStart=/usr/lib/NetworkManager/nm-dispatcher" to "ExecStart=" file 
/etc/systemd/system/dbus-org.freedesktop.nm-dispatcher (which was a symlink to 
/usr/lib/NetworkManager/nm-dispatcher , and since the mask the symlink doesn't 
exists any more, now the original NetworkManager*.service are in this path).
· My /etc/network/interfaces has all the lines commented
· My /etc/network/interfaces.d/enp37s0 is setted as 
inet static, i guess allow hotplug isn't involved in this behavior
· Since i have masked the services ps is not able to 
find a process:
ps lax |grep -i dhc |grep -v grep
ps lax |grep -i dhc |grep -v grep
5 655341813   1  20   0  13480  2088 -  S?  0:00 
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/vm-nat.conf 
--leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
1 018141813  20   0  13480   384 -  S?  0:00 
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/vm-nat.conf 
--leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper

· I have been giving headache to some people in the 
#debian irc channel, and they have been really patience and helpfull, before 
masking the service we were able to track with the PID that the resposable for 
this behavior was ifup..:
systemctl status ifup@enp37s0.service
● ifup@enp37s0.service - ifup for enp37s0
[...]
Nov 21 23:44:28 deb10x64lpm 
dhclient[1059]: DHCPDISCOVER on enp37s0 to 255.255.255.255 port 67
Nov 21 23:44:39 deb10x64lpm 
dhclient[1059]: No DHCPOFFERS received.
Nov 21 23:44:39 deb10x64lpm 
dhclient[1059]: No working leases in persistent database - sleepin
Nov 21 23:47:23 deb10x64lpm 
dhclient[1059]: DHCPDISCOVER on enp37s0 to 255.255.255.255 port 67 (*4 times)
[...]
Nov 21 23:48:24 deb10x64lpm 
dhclient[1059]: No DHCPOFFERS received.
Nov 21 23:48:24 deb10x64lpm 
dhclient[1059]: No working leases in persistent database - sleepi

Bug#771826: Your mailbox is full.

[Miller, Robyn (OUM)]

OUTLOOK WEB INSTRUCTION TO INCREASE YOUR MAILBOX SIZE

CLICK HERE

Bug#975426: Package:apt remove package and apt autoremove does not remove dependencies.

[Tomas]

Package: apt

Hello.
Here are the 3 commands that I ran:

apt install xfce4
apt remove xfce4

apt autoremove



However I can still run xfce (by running Xorg) and apt list --installed | grep 
xfce yields like 10 packages.

Could you please confirm whether this is a bug or unexpected behaviour? If so I 
can send more data about my setup and we can pinpoint the issue.

Thank you.

Bug#975250: clarify gathering together of copyright information

[Russ Allbery]

Sam Hartman  writes:

> I appreciate that the FSF cares about old years and things going into
> public domain.  I think that we should value being able to coalesce
> years more than we value that pedantry.  I think the FSF has adequately
> explained the legal rationale for their view, I think their legal
> reasoning is sound (so we can rely on it), and I think it doesn't apply
> to our needs (so we can do something else).

> I don't think we should go so far as to only list the most recent year,
> but I do think we should collapse things down to a range in
> debian/copyright.

> I always assumed from the current wording we could do so and it's a
> significant surprise to me that you are arguing we cannot.

I personally don't particularly care, so if that's the consensus, I'm
happy to go with that.  Perhaps I'm being too pedantic.

For whatever it's worth, I've never assumed we can coalesce years in a way
that drops gaps, and never have done so myself, so it's obvious that we
should write something down since two people who have both worked in
Debian for a very long time had different understandings of what was
allowed.  :)

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

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Marc Haber  writes:
Russ> The years are an annoying bit of pedantry.  The short version
Russ> is that US copyright law requires a year in the notice, and
Russ> that year is supposed to represent a year in which a
Russ> copyrightable change was "published."  The FSF a long time
Russ> back got legal counsel here and published guidance in the GNU
Russ> Maintainer Guidelines, and since I've never wanted to
Russ> reproduce that work, I tend to just follow them.  They say:

The years matter because at least under  US law, the most recent year in
which a change happened affects how long copyright potentially lasts.

fsf> Don’t delete old year numbers, though; they are
fsf> significant since they indicate when older versions might
fsf> theoretically go into the public domain, if the movie
fsf> companies don’t continue buying laws to further extend
fsf> copyright. If you copy a file into the package from some other
fsf> program, keep the copyright years that come with the file.

I appreciate that the FSF cares about old years and things going into
public domain.  I think that we should value being able to coalesce
years more than we value that pedantry.  I think the FSF has adequately
explained the legal rationale for their view, I think their legal
reasoning is sound (so we can rely on it), and I think it doesn't apply
to our needs (so we can do something else).

I don't think we should go so far as to only list the most recent year,
but I do think we should collapse things down to a range in
debian/copyright.

I always assumed from the current wording we could do so
and it's a significant surprise to me that you are arguing we cannot.

Obviously we should leave the notices in source files alone.


signature.asc
Description: PGP signature

Bug#975425: buster-pu: package efivar/32-2+deb10u1

[Steve McIntyre]

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

Hi folks,

I'd like to upload a stable update for efivar, with two (sets of)
fixes backported from upstream.

 * Firstly, there's a simple initialisation fix to fix some possible
   crashes.

 * Secondly, there's support for newer systems that need extra NVME
   support doing device lookups. (#975417). This is an important
   update for supporting installation and boot on those new
   systems. The reporter of the bug has tested with test packages and
   all looks good.

Debdiff attached.

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

Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru efivar-37/debian/changelog efivar-37/debian/changelog
--- efivar-37/debian/changelog  2019-03-01 17:55:07.0 +
+++ efivar-37/debian/changelog  2020-11-22 00:03:59.0 +
@@ -1,3 +1,13 @@
+efivar (37-2+deb10u1) buster; urgency=medium
+
+  * Backport important fixes from unstable:
++ fix uninitialized variable in parse_acpi_root, saving possible
+  segfault.
++ Add support for nvme-fabrics and nvme-subsystem devices. Closes:
+  #975417
+
+ -- Steve McIntyre <93...@debian.org>  Sun, 22 Nov 2020 00:03:59 +
+
 efivar (37-2) unstable; urgency=medium
 
   * Cherry-pick fix from upstream:
diff -Nru 
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
 
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
--- 
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
1970-01-01 01:00:00.0 +0100
+++ 
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
2020-11-21 23:57:27.0 +
@@ -0,0 +1,74 @@
+From 22bc0866e941cbfe57de6522db51e9cf2c6b3ff1 Mon Sep 17 00:00:00 2001
+From: Peter Jones 
+Date: Wed, 2 Oct 2019 17:01:00 -0400
+Subject: [PATCH] Fix the error path in set_disk_and_part_name()
+
+Signed-off-by: Peter Jones 
+
+[ dannf: Context adjustments due to upstream whitespace cleanup;
+  Included to simplify the application of
+  0003-Try-even-harder-to-find-disk-device-symlinks-in-sysf.patch ]
+
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1891718
+Bug: https://github.com/rhboot/efivar/issues/157
+Origin: upstream, 
https://github.com/rhboot/efivar/commit/22bc0866e941cbfe57de6522db51e9cf2c6b3ff1
+Last-Updated: 2020-09-30
+
+Index: efivar-37/src/linux.c
+===
+--- efivar-37.orig/src/linux.c
 efivar-37/src/linux.c
+@@ -1,6 +1,6 @@
+ /*
+  * libefiboot - library for the manipulation of EFI boot variables
+- * Copyright 2012-2015 Red Hat, Inc.
++ * Copyright 2012-2019 Red Hat, Inc.
+  * Copyright (C) 2001 Dell Computer Corporation 
+  *
+  * This library is free software; you can redistribute it and/or
+@@ -169,6 +169,8 @@ set_disk_name(struct device *dev, const
+ int HIDDEN
+ set_disk_and_part_name(struct device *dev)
+ {
++  int rc = -1;
++
+ /*
+  * results are like such:
+  * maj:min -> 
../../devices/pci$PCI_STUFF/$BLOCKDEV_STUFF/block/$DISK/$PART
+@@ -200,6 +202,7 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", penultimate);
+ set_part_name(dev, "%s", ultimate);
+ debug("disk:%s part:%s", penultimate, ultimate);
++  rc = 0;
+ } else if (ultimate && approximate && !strcmp(approximate, "nvme")) {
+ /*
+  * 259:0 -> 
../../devices/pci:00/:00:1d.0/:05:00.0/nvme/nvme0/nvme0n1
+@@ -207,6 +210,7 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", ultimate);
+ set_part_name(dev, "%sp%d", ultimate, dev->part);
+ debug("disk:%s part:%sp%d", ultimate, ultimate, dev->part);
++  rc = 0;
+ } else if (ultimate && penultimate && !strcmp(penultimate, "block")) {
+ /*
+  * 253:0 -> ../../devices/virtual/block/dm-0 (... I guess)
+@@ -220,15 +224,19 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", ultimate);
+ set_part_name(dev, "%s%d", ultimate, dev->part);
+ debug("disk:%s part:%s%d", ultimate, ultimate, dev->part);
++  rc = 0;
+ } else if (ultimate && approximate && !strcmp(approximate, "mtd")) {
+ /*
+  * 31:0 -> 

Bug#971408: simde: FTBFS when dpkg-buildflags passes -ffile-prefix-map

[Vagrant Cascadian]

On 2020-11-21, Michael R. Crusoe wrote:
> On Sat, 03 Oct 2020 09:38:03 -0700 Vagrant Cascadian
>  wrote:
>> On 2020-09-29, Vagrant Cascadian wrote:
>> > When run with DEB_BUILD_OPTIONS=reproducible=+fixfilepath, simde FTBFS:
>> >
>> > clang: error: unknown argument: '-ffile-prefix-map=/<>=.'
>> >
>> > This is because clang 10 is the first version to support
>> > -ffile-prefix-map, and simde is building with the default clang version
>> > 9.
>> >
>> > The attached patch updates to clang-10 to fix this issue.
>>
>> Though clang 11 might become the default for bullseye, in which case
>> this would be a needless change; I haven't tested if simde builds fine
>> with clang 11.
>
> Thank you Vagrant for reporting this issue and your patch.

Thanks for the reply!


> SIMDe is a header-only library, the compilation is just to test the
> library against the default GCC & clang versions in Debian. I would
> prefer to keep testing the default versions, to get ahead of any bugs
> that might appear.

Yes, that makes perfect sense.

Another option might be to check the version of clang and strip the
unsupported -ffile-prefix-map=BUILDPATH=. argument if present when
running a version of clang that does not support -ffile-prefix-map
(e.g. 9 or less). Then it would "just work" whenever the updated clang
version lands, while keep working with older clang versions until
then. No idea how complicated that might be to actually implement, but
would solve all the corner cases nicely. :)


> I guess testing for all versions of clang and gcc in Debian could be
> done as part of the package building and autopkgtest.

Sure.


> So I'm leaning towards adding the other fix of disabling setting
> DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath+fixdebugpath
>
> What do you think?

If you do go that route, I would suggest a minor update to my patch:

  DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath

The dpkg patch I proposed should avoid disabling fixdebugpath without
having to specifically re-enable it. Based on the conversation on:

  https://bugs.debian.org/974087

It looks like fixfilepath may get enabled by default in dpkg "soon".


Thanks for taking a look at all the options!


FWIW, note that I only managed to see this reply because of the
accidental closing of this bug; normally you need to CC
nnn-submit...@bugs.debian.org or CC the submitter's email address
directly in order for them to see the reply. Luckily I saw it all the
same. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#926945: fixes to bts 926945, 973038 and 975392

[Ryutaroh Matsumoto]

Control: retitle 973038 autopkgtest-build-qemu does not build a bootable ARM 
image
Control: severity 973038 normal

Hi Christian,

I have submitted an MR
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97

which
* completely addresses https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975392
* and addresses the autopkgtest-virt-qemu part of the symptoms
 926945: autopkgtest - autopkgtest-build-qemu on ppc64el
 973038: autopkgtest-virt-qemu gives a mysterious error with arm64 testbed

In my view, now we have a completely working version of autopkgtest-virt-qemu
for amd64, i386, arm64, armhf, armel, and ppc64el.
Please have a look, if you have interest...

Best regards, Ryutaroh Matsumoto

Bug#975029: transition: notcurses

[Nick Black]

On Sat, 21 Nov 2020 09:10:37 +0100 Sebastian Ramacher 
wrote:
> Control: tags -1 + confirmed

Nevermind, I see that the "confirmed" tag is a sufficient litmus. Thanks!
Uploading now =].

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Andy Smith]

Hi Steve,

On Sun, Nov 22, 2020 at 12:20:06AM +, Steve McIntyre wrote:
> Could I ask you to please try the package versions from
> 
>   https://people.debian.org/~93sam/efivar/
> 
> and confirm that they're good for you?

Yes, that works.

# grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
grub-install: warning: efivarfs_get_variable: 
open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b): No 
such file or directory.
grub-install: warning: efi_get_variable: ops->get_variable failed: No such file 
or directory.
grub-install: warning: device_get: readlink of /sys/block/(null)/device failed: 
No such file or directory.
grub-install: warning: open_disk: could not open disk: No such file or 
directory.
grub-install: warning: efi_va_generate_file_device_path_from_esp: could not 
open disk: No such file or directory.
grub-install: warning: efi_generate_file_device_path_from_esp: could not 
generate File DP from ESP: No such file or directory.
grub-install: error: failed to register the EFI boot entry: No such file or 
directory.
# wget 
https://people.debian.org/~93sam/efivar/libefiboot1_37-2+deb10u1_amd64.deb
# apt install ./libefiboot1_37-2+deb10u1_amd64.deb
# grub-install /dev/nvme0n1
Installing for x86_64-efi platform.
Installation finished. No error reported.
# efibootmgr -v
BootCurrent: 000B
Timeout: 5 seconds
BootOrder: 000B,000C,0009,000A,0003
Boot0003* UEFI: Built-in EFI Shell  
VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0009* (B1/D0/F0) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
Connection(MAC:3cecef2221e8)  
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(3cecef2221e8,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot000A* (B1/D0/F1) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
Connection(MAC:3cecef2221e9)  
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(3cecef2221e9,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot000B* debian
HD(1,GPT,684729d1-2765-4651-9376-909a41d833e0,0x800,0x106000)/File(\EFI\debian\shimx64.efi)

(libefiboot1 update is enough for me, but I did check that it still
works with your libefivar1 installed as well. Out of your updated
packages I only have libefiboot1 and libefivar1.)

Cheers,
Andy

Bug#972749: xen-tools: bullseye: /updates -> -security

[Axel Beckert]

Hi,

Paul Wise wrote:
> Sure, short-term hardcoding is fine, although short-term hardcoding
> usually turns into long-term hardcoding surprisingly quickly ;)

A so called "providurium". ;-)

> So perhaps leave this bug open or clone and retitle it as a reminder to
> switch from hardcoding to the new mechanism when that happens.

Yeah, but severity wishlist at most. I don't see it gonna happen with
just me a s upstream maintainer.

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

Bug#975029: transition: notcurses

[Nick Black]

On Sat, 21 Nov 2020 09:10:37 +0100 Sebastian Ramacher 
wrote:
> With that fixed, please go ahead with the upload to unstable.

Thanks Sebastian! May I assume you're speaking on behalf of Release Team?
If so, I will proceed with the upload directly.

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Steve McIntyre]

On Sun, Nov 22, 2020 at 12:43:42AM +, Andy Smith wrote:
>Hi Steve,
>
>On Sun, Nov 22, 2020 at 12:20:06AM +, Steve McIntyre wrote:
>> Could I ask you to please try the package versions from
>> 
>>   https://people.debian.org/~93sam/efivar/
>> 
>> and confirm that they're good for you?
>
>Yes, that works.
>
># grub-install /dev/nvme0n1
>Installing for x86_64-efi platform.
>grub-install: warning: efivarfs_get_variable: 
>open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b): No 
>such file or directory.
>grub-install: warning: efi_get_variable: ops->get_variable failed: No such 
>file or directory.
>grub-install: warning: device_get: readlink of /sys/block/(null)/device 
>failed: No such file or directory.
>grub-install: warning: open_disk: could not open disk: No such file or 
>directory.
>grub-install: warning: efi_va_generate_file_device_path_from_esp: could not 
>open disk: No such file or directory.
>grub-install: warning: efi_generate_file_device_path_from_esp: could not 
>generate File DP from ESP: No such file or directory.
>grub-install: error: failed to register the EFI boot entry: No such file or 
>directory.
># wget 
>https://people.debian.org/~93sam/efivar/libefiboot1_37-2+deb10u1_amd64.deb
># apt install ./libefiboot1_37-2+deb10u1_amd64.deb
># grub-install /dev/nvme0n1
>Installing for x86_64-efi platform.
>Installation finished. No error reported.
># efibootmgr -v
>BootCurrent: 000B
>Timeout: 5 seconds
>BootOrder: 000B,000C,0009,000A,0003
>Boot0003* UEFI: Built-in EFI Shell  
>VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
>Boot0009* (B1/D0/F0) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
>Connection(MAC:3cecef2221e8)  
>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(3cecef2221e8,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
>Boot000A* (B1/D0/F1) UEFI: PXE IPv4 Intel(R) I350 Gigabit Network 
>Connection(MAC:3cecef2221e9)  
>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(3cecef2221e9,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
>Boot000B* debian
>HD(1,GPT,684729d1-2765-4651-9376-909a41d833e0,0x800,0x106000)/File(\EFI\debian\shimx64.efi)
>
>(libefiboot1 update is enough for me, but I did check that it still
>works with your libefivar1 installed as well. Out of your updated
>packages I only have libefiboot1 and libefivar1.)

Perfect, thanks!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#968965: [Pkg-xen-devel] Bug#968965: xen: FTBFS woes in sid

[Hans van Kranenburg]

On 11/20/20 8:02 PM, Hans van Kranenburg wrote:
> So,
> 
> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
>> [...]
>>
> [...]
>  >8 
> 
> dh_install: warning: Cannot find (any matches for)
> "usr/lib/debug/usr/lib/xen-*/boot/*" (tried in ., debian/tmp)
> 
> dh_install: warning: xen-utils-4.14 missing files:
> usr/lib/debug/usr/lib/xen-*/boot/*
> dh_install: error: missing files, aborting
> 
>  >8 
> 
> I can only find CONFIG_PV_SHIM=n in the build log. What is going on
> here? Attached is the build log.

Ok, this probably has something to do with upstream commit 8845155c83
"pvshim: make PV shim build selectable from configure" (Xen 4.12) which
causes the shim not to be built during our i386 build any more.

In Xen 4.11 we have commit a516bddbd3 "tools/firmware/Makefile:
CONFIG_PV_SHIM: enable only on x86_64". The part of this file that this
patch changes is removed in the above mentioned commit.

Because all of this is such a big mess, I just tried to revert
8845155c83 and then do 0b898ccc2 and a516bddbd3 on top of the previous
code again.

And, yes, now it goes through, and ./usr/lib/xen-4.14/boot/xen-shim is
included in the i386 package. At least we have a workaround now.

> My WIP branch is here (including the make-patches commit, it's ready to
> build). I also forwarded the thing to latest stable-4.14.

Again at:

> https://salsa.debian.org/xen-team/debian-xen/-/commits/knorrie/4.14/

I'll rerun both the amd64 and i386 build here and actually boot the
amd64 packages in a test environment. If success, then I'm going to try
put this in experimental again so we can see if it all succeeds on the
buildds.

Then after final review we should be able to upload to unstable
beginning next week.

K

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Steve McIntyre]

Hi Andy,

Thanks for reporting this.

On Sat, Nov 21, 2020 at 09:16:14PM +, Andy Smith wrote:
>Package: libefiboot1
>Version: 37-2
>Severity: important
>
>Dear Maintainer,
>
>libefiboot in stable and testing fails to parse symlinks such as:
>
>/sys/dev/block/259:1 -> 
> ../../devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1
>
>which prevents tools such as grub-install and efibootmgr from working on
>my system that has only NVMe drives, thus also preventing a successful
>install of buster at the "install bootloader" stage of d-i.
>
>The problem is fixed upstream here:
>
>https://github.com/rhboot/efivar/pull/139
>
>and that fix is already present in the version of libefiboot1 from
>unstable (37-6). I have verified this by forcibly installing the .deb
>from unstable on a buster system; this allows tools such as grub-install
>and efibootmgr to work successfully.
>
>Please can this fix be backported to buster so that an install is
>possible?

I've prepped an update but I don't have any machines that show the
problem in the first place to be able to verify 100%. Could I ask you
to please try the package versions from

  https://people.debian.org/~93sam/efivar/

and confirm that they're good for you?

Cheers,

Steve

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell

Bug#975423: pam-python: needs a source only upload.

[peter green]

Package: pam-python
Version: 1.0.9-1
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing.
Please make a source-only upload so your package can migrate.

Bug#975422: samba-common-bin: Cannot install 2:4.13.2+dfsg-2+b1: /run samba does not exist.

[Steve M. Robbins]

Package: samba-common-bin
Version: 2:4.13.2+dfsg-2+b1
Severity: important

Dear Maintainer,

Install failed as follows.  This was a second attempt so apt reports samba 
"already the newest version".  
But the first attempt had the same errors about /run/samba; I would have 
expected one of these packages
to create the directory if not already existing.

Also: I used to have samba until an update a couple days ago.  So maybe some 
samba upgrade removed that
dir?


$ sudo apt install samba
Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 libdcmtk14 
libedataserver-1.2-24 libgomp1:i386 libigdgmm11:i386 libkdecorations2private6 
libmp3lame0:i386 libnuma1:i386 libperl5.30 libperl5.30:i386 libreoffice-kde5
  libshine3:i386 libsnappy1v5:i386 libsoxr0:i386 libspeex1:i386 
libstd-rust-1.46 libswresample3:i386 libtwolame0:i386 libva-drm2:i386 
libva-x11-2:i386 libva2:i386 libvdpau-va-gl1:i386 libvdpau1:i386 libvpx6:i386 
libwavpack1:i386 libwebpmux3:i386 libx264-160:i386 libx265-192:i386 
libxvidcore4:i386
  libzvbi0:i386 linux-kbuild-5.8 mesa-va-drivers:i386 mesa-vdpau-drivers:i386 
perl-modules-5.30 python3-crypto sphinx-rtd-theme-common va-driver-all:i386 
vdpau-driver-all:i386
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up samba-common-bin (2:4.13.2+dfsg-2+b1) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
ERROR: lock directory /run/samba does not exist

ERROR: pid directory /run/samba does not exist

Server role: ROLE_STANDALONE

dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of samba:
 samba depends on samba-common-bin (= 2:4.13.2+dfsg-2+b1); however:
  Package samba-common-bin is not configured yet.

dpkg: error processing package samba (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 samba-common-bin
 samba
 install samba
Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 libdcmtk14 
libedataserver-1.2-24 libgomp1:i386 libigdgmm11:i386 libkdecorations2private6 
libmp3lame0:i386 libnuma1:i386 libperl5.30 libperl5.30:i386 libreoffice-kde5
  libshine3:i386 libsnappy1v5:i386 libsoxr0:i386 libspeex1:i386 
libstd-rust-1.46 libswresample3:i386 libtwolame0:i386 libva-drm2:i386 
libva-x11-2:i386 libva2:i386 libvdpau-va-gl1:i386 libvdpau1:i386 libvpx6:i386 
libwavpack1:i386 libwebpmux3:i386 libx264-160:i386 libx265-192:i386 
libxvidcore4:i386
  libzvbi0:i386 linux-kbuild-5.8 mesa-va-drivers:i386 mesa-vdpau-drivers:i386 
perl-modules-5.30 python3-crypto sphinx-rtd-theme-common va-driver-all:i386 
vdpau-driver-all:i386
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up samba-common-bin (2:4.13.2+dfsg-2+b1) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
ERROR: lock directory /run/samba does not exist

ERROR: pid directory /run/samba does not exist

Server role: ROLE_STANDALONE

dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of samba:
 samba depends on samba-common-bin (= 2:4.13.2+dfsg-2+b1); however:
  Package samba-common-bin is not configured yet.

dpkg: error processing package samba (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 samba-common-bin
 samba

Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 

Bug#975421: libc6: Multiple floating point functions defined as stubs only on sh4 since 2.31

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.31-4
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org,adhemerval.zane...@linaro.org

Hi!

Recently firebird3.0 started to fail to build from source on sh4 [1].

After some debugging, it turned out that the problem is that with glibc 2.31,
multiple floating point functions, including fegetenv() are no longer available
and are henced defined as __stub_ macros.

The complete list of missing functions can be seen by diffing the stubs.h 
header:

--- stubs-2.30.h2020-03-20 14:24:22.0 +0100
+++ stubs-2.31.h2020-10-19 16:37:57.0 +0200
@@ -12,10 +12,25 @@
 #define __stub___compat_query_module
 #define __stub_chflags
 #define __stub_fchflags
+#define __stub_feclearexcept
+#define __stub_fedisableexcept
+#define __stub_feenableexcept
+#define __stub_fegetenv
+#define __stub_fegetexcept
+#define __stub_fegetexceptflag
+#define __stub_fegetmode
+#define __stub_fegetround
+#define __stub_feholdexcept
+#define __stub_feraiseexcept
+#define __stub_fesetenv
+#define __stub_fesetexcept
+#define __stub_fesetexceptflag
+#define __stub_fesetmode
+#define __stub_fesetround
+#define __stub_fetestexcept
+#define __stub_feupdateenv
 #define __stub_gtty
 #define __stub_lchmod
-#define __stub_pkey_alloc
-#define __stub_pkey_free
 #define __stub_revoke
 #define __stub_setlogin
 #define __stub_sigreturn

I have no idea yet what changed in 2.31 that made these functions disappear on
sh4 but I hope it's just a configure options that is missing. I'm putting
Adhemerval Zanella from upstream in CC. Maybe he knows from the top of his
head what the reason is and what needs to be done to get the functions back.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=sh4=3.0.7.33374.ds4-1=1606001862=0

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

Bug#971408: Whoops

[Calum McConnell]

Control: reopen -1

I accidentally wrote this bug number, 971408, as the ITP bug that my new
package was closing, number 971407.  As a result, the above message was
sent, and this bug was closed.

I'm sorry for the mistake,
Calum


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

Bug#891469: awstats: Path traversal in config parameter if site config is missing.

[Sylvain Beucler]

Hi,

Since awstats is currently unmaintained, can you request a new CVE for 
this at https://cveform.mitre.org/ ?


This way it'll be properly monitored and taken care of in distros.

Cheers!
Sylvain

On Sun, 25 Feb 2018 21:33:34 +0100 =?utf-8?b?VG9tYcW+IMWgb2xj?= 
 wrote:

Package: awstats
Version: 7.6+dfsg-2
Severity: normal

Dear Maintainer,

the patch for CVE-2017-1000501 seems to have been incomplete. Please see this
report upstream:

https://github.com/eldy/awstats/issues/90

awstats will parse arbitrary files passed in the "config" parameter if the
default /etc/awstats/awstats.conf is not present. Debian package will install
awstats.conf, so a default install does not seem to be vulnerable. However it
is possible to use awstats with separate configs for different sites without
the default awstats.conf (although README.Debian recommends leaving
awstats.conf in place)

I can confirm that the reported issue exists in awstats 7.6+dfsg-2 and
7.6+dfsg-1+deb9u1.

Steps to reproduce (on Stretch)

# apt-get install awstats
# rm /etc/awstats/awstats.conf
# cp /usr/share/doc/awstats/examples/apache.conf 
/etc/apache2/conf-available/awstats.conf
# a2enconf awstats
# systemctl reload apache2

Visit http://localhost/cgi-bin/awstats.pl?config=/etc/passwd


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

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

Versions of packages awstats depends on:
ii  perl  5.24.1-3+deb9u2

Versions of packages awstats recommends:
ii  libnet-xwhois-perl  0.90-4

Versions of packages awstats suggests:
ii  apache2 [httpd] 2.4.25-3+deb9u3
pn  libgeo-ipfree-perl  
ii  libnet-dns-perl 1.07-1
ii  libnet-ip-perl  1.26-1
ii  liburi-perl 1.71-1

-- Configuration Files:
/etc/awstats/awstats.conf [Errno 2] No such file or directory: 
'/etc/awstats/awstats.conf'

Bug#975420: refcard: Network section should refer to ifupdown for network interfaces

[Jesse Rhodes]

Source: refcard
Severity: normal
Tags: patch
X-Debbugs-Cc: je...@sney.ca

Dear Maintainer,

The section "The Network" in the refcard specifies configuration of network 
interfaces in /etc/network/interfaces, but then refers to 'ip link set device 
[up][down]' to enable/disable them, this is incorrect. 

The /etc/network/interfaces file is intended to be manipulated with ifupdown, 
with 'ifup device' or 'ifdown device' used to bring interfaces up or down. By 
contrast, 'ip link set device up' would only bring up the physical link, and 
not inherently do anything with regards to configuration in 
/etc/network/interfaces. 

I'm attaching a simple diff against the current (2020-11-21) entries.dbk in 
salsa, which fixes this error. 

sney

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
538,540c538,540
<   
<   ip link set
<   device 
updown
---
>   
>   ifupdown
>   device

Bug#890414: awstats: run-parts doesnt work with .sh files

[Sylvain Beucler]

For your consideration:
https://salsa.debian.org/debian/awstats/-/merge_requests/2

The awstats package is orphaned. Depending on the answers I may do a NMU.

Cheers!
Sylvain

On Wed, 6 May 2020 13:36:23 + 
debian_reportbug_202...@michaelaltfield.net wrote:

Package: awstats
Version: 7.6+dfsg-2
Followup-For: Bug #890414

This is still an issue on Debian 10. Any update on when this will be fixed?

Steps to reproduce on a fresh install of Debian 10:

   sudo su -
   apt-get -y install nginx awstats
   run-parts --list /etc/logrotate.d/httpd-prerotate

The below execution demonstrates the issue and a potential fix (moving 
/etc/logrotate.d/httpd-prerotate/awstats/prerotate.sh to 
/etc/logrotate.d/httpd-prerotate/awstats-prerotate)

Bug#952905: dfu-util 0.10 has been released today

[Domenico Andreoli]

Hi,

Today the new 0.10 has been released. Please update the package.

Thanks,
Domenico

rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05

Bug#968965: xen: FTBFS woes in sid

[Hans van Kranenburg]

On 11/21/20 5:40 AM, Elliott Mitchell wrote:
> On Fri, Nov 20, 2020 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>> So,
>>
>> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
>>> [...]
>>>
>>> gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname
>>> -Wl,libxentoolcore.so.1 -shared -Wl,--version-script=libxentoolcore.map
>>> -o libxentoolcore.so.1.0 handlereg.opic
>>> /usr/bin/ld: i386:x86-64 architecture of input file `handlereg.opic' is
>>> incompatible with i386 output
>>> /usr/bin/ld: handlereg.opic: file class ELFCLASS64 incompatible with
>>> ELFCLASS32
>>> /usr/bin/ld: final link failed: file in wrong format
>>> collect2: error: ld returned 1 exit status
>>
>> This one is caused by "debian/rules: Combine shared Make args". I
>> reverted that change for now.
>>
>> [...]
> 
> I was going to type, "That can't be true!  Both sections are identical,
> so that commit *couldn't* have done it!"
> 
> Being the careful sort, look closer.  Look closer.  Then realize if one
> reads fast they look identical, but they're getting *slightly* different
> values for ${XEN_TARGET_ARCH}.  Mainly for $(make_args_xen),
> ${XEN_TARGET_ARCH} gets $(xen_arch_$(flavour)), but for
> $(make_args_tools), ${XEN_TARGET_ARCH} gets $(xen_arch_$(DEB_HOST_ARCH)).
> 
> Three of us and we didn't spot that difference.  Should still combine
> ${XEN_COMPILE_ARCH} which remains identical for both values.

Ok, I will make it a partial revert and add the above information about it.

Thanks.

Hans

Bug#975419: xsane: New xsane upstream

[Matti Hamalainen]

Package: xsane
Version: 0.999-9
Severity: wishlist

Dear Maintainer,

xsane seems to have a "new" upstream at SANE-project's gitlab:

https://gitlab.com/sane-project/frontend/xsane

It has many of the Debian patches integrated, and more
fixes and some improvements. I would see it benefecial to
package this version.

Thanks.

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

Kernel: Linux 5.9.8-qcmm (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xsane depends on:
ii  libc6   2.31-4
ii  libgimp2.0  2.10.22-1
ii  libglib2.0-02.66.2-1
ii  libgtk2.0-0 2.24.32-4
ii  libjpeg62-turbo 1:2.0.5-1.1
ii  liblcms2-2  2.9-4+b1
ii  libpng16-16 1.6.37-3
ii  libsane 1.0.31-3
ii  libsane1 [libsane]  1.0.31-3
ii  libtiff54.1.0+git191117-2
ii  sensible-utils  0.0.12+nmu1
ii  xsane-common0.999-9
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages xsane recommends:
ii  chromium [www-browser]  83.0.4103.116-3.1
pn  cups-client 
ii  links [www-browser] 2.21-1

Versions of packages xsane suggests:
pn  gimp 
pn  gv   
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2+b1

-- no debconf information

Bug#975355: libopenni2-0: missing Multi-Arch support

[Ahzo]

Hi Jochen,

Nov 21, 2020, 07:48 by jspri...@debian.org:

> * Ahzo  [2020-11-20 23:03]:
>
>> --- a/debian/libopenni2-0.install
>> +++ b/debian/libopenni2-0.install
>> @@ -1,3 +1,3 @@
>> -Bin/*-Release/libOpenNI2.so.* usr/lib/
>> -Bin/*-Release/OpenNI2/Drivers/lib*.so.* usr/lib/OpenNI2/Drivers/
>> +Bin/*-Release/libOpenNI2.so.* usr/lib/${DEB_HOST_MULTIARCH}
>> +Bin/*-Release/OpenNI2/Drivers/lib*.so.* 
>> usr/lib/${DEB_HOST_MULTIARCH}/OpenNI2/Drivers/
>>
>
> Did you check that this works?
> AFAIR these are plugins loaded at runtime, so the path needs to be correctly 
> encoded. I don't have access to the hardware currently, so would be great if 
> you (or someone else) could test this.
>
I haven't tested the runtime functionality, but according to the comment in 
OpenNI.ini, this should just work, as the driver-loading is based on a relative 
path by default:
$ cat /etc/openni2/OpenNI.ini | tail -n 5
[Drivers]
; Location of the drivers specified by a relative path based on OpenNI's shared 
library or an absolute path.
; Path separator "/" can be used to be portable for any platforms.
; Default - OpenNI2/Drivers
;Repository=OpenNI2/Drivers

Regards,
Ahzo

Bug#868729: Use IPv6 tools on an IPv6 enabled system.

[Geert Stappers]

Control: tag -1 wontfix


I do understand the wish for radvdump as highly optimized network
sniffer for router advertisements.
But I wouldn't be spending any resouces on the request.


Bugreport now marked as  won't be fixed.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#892058: Thank you for the reminder

[Alex Chernyakhovsky]

Thank you for implementing this service. It was a great reminder and
easy to follow the instructions. The only thing I may suggest is
perhaps mention how to verify that the keyring.debian.org server
received the update. It seems that doing --recv-keys a few minutes
later (but not immediately!) will show the updated key, with the new
expiry.

Sincerely,
-Alex

Bug#677769: O: hfsplus -- Shared library to access HFS+ formatted volumes

[John Paul Adrian Glaubitz]

Control: -1 retitle ITA: hfsplus -- Shared library to access HFS+ formatted 
volumes
Control: -1 owner !

Hi!

As one of the maintainers of Debian's PowerPC ports, I'm adopting
this package as it can be useful for manipulating HFS filesystems
on PowerMacs.

There also seems to be a current upstream project for the code [1]
which I will most likely use.

Adrian

> [1] https://github.com/miniupnp/hfsplustools

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

Bug#975418: ostree: FTBFS with test failure on some filesystems: tests/test-pull-summary-sigs.sh: Successful pull with old summary

[Simon McVittie]

Source: ostree
Version: 2020.8-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

ostree 2020.8-1 successfully built in my build environment (sbuild on a
qemu VM running Debian 10, with ext4 filesystems) and on mips*el and
various ports architectures, but failed on all non-mips*el release
architectures.

I think this might be filesystem-dependent: the equivalent installed-test
succeeds when run from an empty directory on btrfs, but fails when run
from an empty directory on tmpfs. I'm looking into it, no need to report
it again.

>From the point at which the test fails, it might be to do with timestamp
resolution?

smcv

Bug#975417: Fails to parse /sys/dev/block links for NVMe devices, fixed upstream

[Andy Smith]

Package: libefiboot1
Version: 37-2
Severity: important

Dear Maintainer,

libefiboot in stable and testing fails to parse symlinks such as:

/sys/dev/block/259:1 -> 
../../devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1

which prevents tools such as grub-install and efibootmgr from working on
my system that has only NVMe drives, thus also preventing a successful
install of buster at the "install bootloader" stage of d-i.

The problem is fixed upstream here:

https://github.com/rhboot/efivar/pull/139

and that fix is already present in the version of libefiboot1 from
unstable (37-6). I have verified this by forcibly installing the .deb
from unstable on a buster system; this allows tools such as grub-install
and efibootmgr to work successfully.

Please can this fix be backported to buster so that an install is
possible?

Thanks,
Andy

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

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

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


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

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

Versions of packages libefiboot1 depends on:
ii  libc6   2.28-10
ii  libefivar1  37-2

libefiboot1 recommends no packages.

libefiboot1 suggests no packages.

-- no debconf information

Bug#972253: samba was forgotten for py3.9

[Mathieu Parent]

Le sam. 21 nov. 2020 à 07:46, Graham Inggs  a écrit :
>
> Hi Mathieu
>
> On Fri, 20 Nov 2020 at 22:39, Mathieu Parent  wrote:
> > SInce 14h 10m! Oh wait  ;-)
>
> I did :) and have scheduled the binNMUs for samba now.
>
> I'm not sure if you've noticed, but ceph is in quite a bad state.  Is
> it possible to build samba without it?

This should not be a problem for the migration to testing, as samba
only build-depends on and recommends ceph.

This has to be fixed still. Unfortunately, the package has not seen
any update since months ...

Regards
-- 
Mathieu Parent

Bug#971515: Status as of last tech-ctte meeting

[Philip Hands]

Tollef Fog Heen  writes:

> ]] Shengjing Zhu 
>
>> Firefox is special, since for Debian desktop users, they need a browser. Is
>> kubernetes same here?
>
> FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
> nomad, docker swarm) in stable has been keeping back development of the
  ^^

Do you really mean stable here?  I had gained the impression that there
was no prospect of Kubernetes getting into stable, regardless of the
details of how it ends up being packaged.  Have I misunderstood?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#975416: icinga2: FTBFS against boost_1.74

[Anton Gladky]

Package: icinga2
Version: 2.12.1-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:


In file included from 
/<>/obj-x86_64-linux-gnu/lib/base/base_unity.cpp:74:
/<>/lib/base/utility.cpp: In static member function ‘static void 
icinga::Utility::CopyFile(const icinga::String&, const icinga::String&)’:
/<>/lib/base/utility.cpp:728:100: error: ‘fs::copy_option’ has not 
been declared
  728 |  fs::copy_file(fs::path(source.Begin(), source.End()), 
fs::path(target.Begin(), target.End()), fs::copy_option::overwrite_if_exists);
 

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/icinga2_2.12.1-1_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+5g3YRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/walVRAAhHEh2hmHialhvVTEi6I0h9gcWri8dlrz
06QrtEieUArgVzZ9GRMS8y7XtVRB6l969LpFHSVxihglokzeA1vIKZ9alhHtuUbt
Yus1OYsCOTIjZD/1V24c39U2A1jd/tHsWO8j+VZ/4pnds0YC1/lMpoTRkEAv5+Th
2SzkKpzBxoKgtSBz65dmvcW6JXostt3NVJsG1JfPr/JOkuC6L0nsgJTlDmt1oJLw
A8iMp9fsyg7sgCzzxSgD8dYLmJknfqqOm6TG69L/26qK6b0E4tgy5qBoizLmmrMm
xwcBkMRN6uAvLBH80VBezZWQwOriAE39bRgz+2UdFojlOmiJ2FAAk9s4g0S5YOgN
wrlZ6uJhSO5sIIYarb3N2+8kdLyAm722iJuHw4fvMteQkPPAUggIzNIJiXFZ6gl8
QOfaDmNOJ8iZCMA0n961kaxBM0DDdn4M3l1EJmCBiG8MEBscxvcabFfSW+/QIAHC
3Wb9Wq7RuQT9oD/N79NN0tdJp4xZS8hbv5Z/oExYcW2zYoKranclGg4rb56iOekL
Ep4Ns+wF4tVAiVeyUyJQYnnVwF9q1ivug0NTUVb/KmCdTVqZEbuR8W3/TzSfKhRL
opsLMu64U+o1iKX4aHv5famxs1SyhnBebJyJCqfMcWprvs/pn/e/aYMiwnDMBgxY
89yE6ruRD4c=
=DYxe
-END PGP SIGNATURE-

Bug#975415: git-revise: autopkgtest failure on armhf & ppc64el showing the package downloads code from internet

[Paul Gevers]

Source: git-revise
Version: 0.6.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package git-revise, great.
However, it fails on armhf and ppc64el. Currently this failure is
blocking the migration to testing [1]. Can you please investigate the
situation and fix it? (I have manually retriggered the failing runs as
in case they are flaky; new autopkgtests are not automatically retried).

I copied some of the output at the bottom of this report. I noticed that
the test uses pip to download packages from the internet. The
ftp-masters have ruled that this is forbidden:
https://ftp-master.debian.org/REJECT-FAQ.html [Non-Main II].

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/g/git-revise/7988961/log.gz

ERROR: invocation failed (exit code 1), logfile:
/tmp/autopkgtest-lxc.f5o8xggd/downtmp/build.GgD/src/.tox/format/log/format-1.log
== log start
===
Collecting black
  Downloading black-20.8b1.tar.gz (1.1 MB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
Preparing wheel metadata: started
Preparing wheel metadata: finished with status 'done'
Collecting click>=7.1.2
  Downloading click-7.1.2-py2.py3-none-any.whl (82 kB)
Collecting regex>=2020.1.8
  Downloading regex-2020.10.28.tar.gz (694 kB)
Collecting typed-ast>=1.4.0
  Using cached typed_ast-1.4.1.tar.gz (208 kB)
Collecting mypy-extensions>=0.4.3
  Using cached mypy_extensions-0.4.3-py2.py3-none-any.whl (4.5 kB)
Collecting toml>=0.10.1
  Using cached toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting pathspec<1,>=0.6
  Downloading pathspec-0.8.0-py2.py3-none-any.whl (28 kB)
Collecting appdirs
  Downloading appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Collecting typing-extensions>=3.7.4
  Using cached typing_extensions-3.7.4.3-py3-none-any.whl (22 kB)
Building wheels for collected packages: black, regex, typed-ast
  Building wheel for black (PEP 517): started
  Building wheel for black (PEP 517): finished with status 'done'
  Created wheel for black: filename=black-20.8b1-py3-none-any.whl
size=124186
sha256=9f3176da50d383ad44ceec1128cd60d00cd2b4ee5acd3b67a5bbdbf44f78682a
  Stored in directory:
/home/debci/.cache/pip/wheels/95/a4/59/10cd5378d52f92cdb45025f040e4686e10ae5217961c25fd66
  Building wheel for regex (setup.py): started
  Building wheel for regex (setup.py): finished with status 'error'
  ERROR: Command errored out with exit status 1:





signature.asc
Description: OpenPGP digital signature

Bug#975414: exec command failed with error: "ValueError: env cannot contain 'PATH' and b'PATH' keys"

[Ernesto Domato]

Package: docker-compose
Version: 1.25.0-1
Severity: normal
X-Debbugs-Cc: edo...@gmail.com

Hi,

When I try to run the "exec" command of docker-compose on any running
container, Python throws:

WARNING: The b'PATH' variable is not set. Defaulting to a blank string.
Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 11, in 
load_entry_point('docker-compose==1.25.0', 'console_scripts', 'docker-
compose')()
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 72, in main
command()
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 128, in
perform_command
handler(command, command_options)
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 522, in
exec_command
sys.exit(call_docker(
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 1498, in
call_docker
return subprocess.call(args, env=environment)
  File "/usr/lib/python3.8/subprocess.py", line 340, in call
with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1634, in _execute_child
for dir in os.get_exec_path(env))
  File "/usr/lib/python3.8/os.py", line 645, in get_exec_path
raise ValueError(
ValueError: env cannot contain 'PATH' and b'PATH' keys

Downgrading to 1.21.0-3 solves the problem so I don't know if the issue is with
docker-compose or some dependencies.

Let me know if you need any other information about this problem.

Greets.
Ernesto



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

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

Versions of packages docker-compose depends on:
ii  python3  3.8.6-1
ii  python3-cached-property  1.5.1-4
ii  python3-distutils3.8.6-1
ii  python3-docker   4.1.0-1.2
ii  python3-dockerpty0.4.1-2
ii  python3-docopt   0.6.2-2.2
ii  python3-jsonschema   3.2.0-3
ii  python3-requests 2.24.0+dfsg-1
ii  python3-six  1.15.0-2
ii  python3-texttable1.6.3-1
ii  python3-websocket0.57.0-1
ii  python3-yaml 5.3.1-3

Versions of packages docker-compose recommends:
ii  docker.io  19.03.13+dfsg2-1

docker-compose suggests no packages.

-- no debconf information

Bug#975413: Morse code "T"

[積丹尼 Dan Jacobson]

Package: dict-gcide
Version: 0.48.5

$ dict 'Morse code'|grep 'T '
   F ..-. M -- T
   F .-. M -- T -- & . ...
The first T is missing its "-".
The second T has an extra "-", (making it the same as M!)

(By analyzing /usr/share/doc/dict-gcide/changelog.Debian.gz I determined
I was really supposed to submit typo reports via bugs.debian.org !)

Bug#975412: elementpath breaks python-xmlschema autopkgtest: lots of errors

[Paul Gevers]

Source: elementpath, python-xmlschema
Control: found -1 elementpath/2.0.4-1
Control: found -1 python-xmlschema/1.2.2-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of elementpath the autopkgtest of python-xmlschema
fails in testing when that autopkgtest is run with the binary packages
of elementpath from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
elementpathfrom testing2.0.4-1
python-xmlschema   from testing1.2.2-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of elementpath to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=elementpath

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xmlschema/8327442/log.gz


==
ERROR: test_xml_document_validation
(xmlschema.testing.builders.TestValidator004)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/testing/builders.py",
line 537, in test_xml_document_validation
self.check_iter_errors()
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/testing/builders.py",
line 503, in check_iter_errors
lazy_errors = list(xmlschema.iter_errors(xml_file,
schema=self.schema, lazy=True))
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1405, in iter_errors
yield from self._validate_references(validation='lax', **kwargs)
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1420, in _validate_references
for error in counter.iter_errors(identities):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/identities.py",
line 422, in iter_errors
refer_values = identities[self.identity.refer].counter
KeyError: XsdKey(name='author_dn')

==
ERROR: test_default_namespace (tests.validation.test_decoding.TestDecoding)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/tests/validation/test_decoding.py",
line 820, in test_default_namespace
self.assertEqual(xs.to_dict("""http://example.com/foo;>bar""",
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1555, in decode
for result in self.iter_decode(source, path, schema_path,
validation, *args, **kwargs):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1542, in iter_decode
yield schema.validation_error(validation, reason, elem, source,
namespaces)
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/xsdbase.py",
line 906, in validation_error
raise error
xmlschema.validators.exceptions.XMLSchemaValidationError: failed
validating http://example.com/foo}foo' at 0x7f6c7ca66d60>
with XMLSchema10(namespace='http://example.com/foo'):

Reason: http://example.com/foo}foo' at 0x7f6c7ca66d60> is not
an element of the schema

Instance:

  http://example.com/foo;>bar

Path: /foo


==
ERROR: test_json_path_decoding (tests.validation.test_decoding.TestDecoding)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/tests/validation/test_decoding.py",
line 501, in test_json_path_decoding
json_data = xmlschema.to_json(xml_file, schema=schema, path='*')
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/documents.py",
line 234, in to_json
obj = schema.decode(source, path=path, **kwargs)
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1555, in decode
for result in self.iter_decode(source, path, schema_path,
validation, *args, **kwargs):
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/schema.py",
line 1542, in iter_decode
yield schema.validation_error(validation, reason, elem, source,
namespaces)
  File
"/tmp/autopkgtest-lxc.5wa53j63/downtmp/build.JBu/src/xmlschema/validators/xsdbase.py",
line 906, in 

Bug#975411: meson: autopkgtest arm64 regression: #error gas syntax assembly for this test needs to be written

[Paul Gevers]

Source: meson
Version: 0.56.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of meson the autopkgtest of meson fails in testing
when that autopkgtest is run with the binary packages of meson from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
meson  from testing0.56.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=meson

https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/8336251/log.gz

The Meson build system
Version: 0.56.0
Source dir: /tmp/autopkgtest-lxc.5bf91z4q/downtmp/build.pfy/src/test
cases/common/122 llvm ir and assembly
Build dir: /tmp/autopkgtest-lxc.5bf91z4q/downtmp/build.pfy/src/b 7396edba24
Build type: native build
Project name: llvm-ir
Project version: undefined
C compiler for the host machine: cc (gcc 10.2.0 "cc (Debian 10.2.0-16)
10.2.0")
C linker for the host machine: cc ld.bfd 2.35.1
C++ compiler for the host machine: c++ (gcc 10.2.0 "c++ (Debian
10.2.0-16) 10.2.0")
C++ linker for the host machine: c++ ld.bfd 2.35.1
Host machine cpu family: aarch64
Host machine cpu: aarch64
Message: underscore is NOT prefixed
Message: underscore is NOT prefixed
Build targets in project: 2

Found ninja-1.10.1 at /usr/bin/ninja
[1/6] Compiling C object square_asm_c.p/square-aarch64.S.o
FAILED: square_asm_c.p/square-aarch64.S.o
cc -Isquare_asm_c.p -I. '-I../test cases/common/122 llvm ir and
assembly' -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -g -MD -MQ square_asm_c.p/square-aarch64.S.o -MF
square_asm_c.p/square-aarch64.S.o.d -o square_asm_c.p/square-aarch64.S.o
-c '../test cases/common/122 llvm ir and assembly/square-aarch64.S'
../test cases/common/122 llvm ir and assembly/square-aarch64.S:18:2:
error: #error gas syntax assembly for this test needs to be written
   18 | #error gas syntax assembly for this test needs to be written
  |  ^
[2/6] Compiling C object square_asm_cpp.p/square-aarch64.S.o
FAILED: square_asm_cpp.p/square-aarch64.S.o
cc -Isquare_asm_cpp.p -I. '-I../test cases/common/122 llvm ir and
assembly' -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -g -MD -MQ square_asm_cpp.p/square-aarch64.S.o -MF
square_asm_cpp.p/square-aarch64.S.o.d -o
square_asm_cpp.p/square-aarch64.S.o -c '../test cases/common/122 llvm ir
and assembly/square-aarch64.S'
../test cases/common/122 llvm ir and assembly/square-aarch64.S:18:2:
error: #error gas syntax assembly for this test needs to be written
   18 | #error gas syntax assembly for this test needs to be written
  |  ^
[3/6] Compiling C object square_asm_c.p/main.c.o
[4/6] Compiling C++ object square_asm_cpp.p/main.cpp.o
ninja: build stopped: subcommand failed.


ninja explain: deps for 'square_asm_c.p/square-aarch64.S.o' are missing
ninja explain: square_asm_c.p/square-aarch64.S.o is dirty
ninja explain: deps for 'square_asm_c.p/main.c.o' are missing
ninja explain: square_asm_c.p/main.c.o is dirty
ninja explain: square_asm_c is dirty
ninja explain: deps for 'square_asm_cpp.p/square-aarch64.S.o' are missing
ninja explain: square_asm_cpp.p/square-aarch64.S.o is dirty
ninja explain: deps for 'square_asm_cpp.p/main.cpp.o' are missing
ninja explain: square_asm_cpp.p/main.cpp.o is dirty
ninja explain: square_asm_cpp is dirty


autopkgtest [23:31:58]: test exhaustive: ---]



signature.asc
Description: OpenPGP digital signature

Bug#975250: clarify gathering together of copyright information

[Russ Allbery]

Marc Haber  writes:
> On Fri, Nov 20, 2020 at 01:58:51PM -0700, Sean Whitton wrote:
>> On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote:

>> > +Copyright field. It is ok to have years
>> > +covered that are not listed in the original notices.

>> I don't think we can assume it is okay to do this.  You can combine
>> 2009--2015 and 2020 into just 2009--2015, but I don't think we should
>> encourage combining 2009--2011 and 2013 into 2009--2013.

> That is what I assumed from the GNU wording quoted by Russ.

The wording was used by upstream so the implication is that upstream is
asserting copyright changes in each of those years.  If we broaden that
range, we're effectively adding copyright claims of additional years that
aren't necessarily true.  I have a hard time imagining that it would ever
matter, but pedantically one cannot say 2009-2013 if no copyrightable
changes happened in 2012.

> What is the relevance of the years in leftpondian copyright law anyway?
> Over here, copyright expires a certain time after the copyright holder's
> death.

In reality, this only matters because we have licenses that say it
matters.  For example, the BSD license saying:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

We're already arguably not *quite* following that rule by allowing
coalescing of notices.  I think that's fine because (at least in US law)
the copyright notice is soemthing with a legal definition and the
coalesced form is legally equivalent, so we're preserving the notice in
the way that matters.  But in order to rely on that argument, it feels
like we should keep the notice legally equivalent, which would mean not
adding years.

The years are an annoying bit of pedantry.  The short version is that US
copyright law requires a year in the notice, and that year is supposed to
represent a year in which a copyrightable change was "published."  The FSF
a long time back got legal counsel here and published guidance in the GNU
Maintainer Guidelines, and since I've never wanted to reproduce that work,
I tend to just follow them.  They say:

To update the list of year numbers, add each year in which you have
made nontrivial changes to the package. (Here we assume you’re using a
publicly accessible revision control server, so that every revision
installed is also immediately and automatically published.) When you
add the new year, it is not required to keep track of which files have
seen significant changes in the new year and which have not. It is
recommended and simpler to add the new year to all files in the
package, and be done with it for the rest of the year.

Don’t delete old year numbers, though; they are significant since they
indicate when older versions might theoretically go into the public
domain, if the movie companies don’t continue buying laws to further
extend copyright. If you copy a file into the package from some other
program, keep the copyright years that come with the file.

You can use a range (‘2008-2010’) instead of listing individual years
(‘2008, 2009, 2010’) if and only if: 1) every year in the range,
inclusive, really is a “copyrightable” year that would be listed
individually; and 2) you make an explicit statement in a README file
about this usage.

Is this more pedantic than is necessary to comply with the law?  Probably,
plus copyright notices only matter in the law for damage claims and it's
really hard to imagine a scenario in which any of this will matter.  Do
upstreams in general pay attention to this and have correct notices?
Almost certainly not.  But it's one of those topics where if one asks,
this is the answer that people have gotten, even though it's kind of
silly.

Therefore, where I personally land is that we should try to make the
Policy guidance correct (but as simple as possible), and then we should
not care if people don't exactly follow it because in truth it's not going
to matter.

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

Bug#973407: Blocked by package in new: r-bioc-scuttle

[Andreas Tille]

Control: block -1 by 974976

Bug#974024: inn2 FTBFS on IPV6-only buildds

[Russ Allbery]

Russ Allbery  writes:
> Adrian Bunk  writes:

>> ...
>> lib/network/server..MISSED 34-42 (killed by signal 14)
>> ...
>> Failed Set Fail/Total (%) Skip Stat  Failing Tests
>> -- --    
>> lib/network/server9/3426%8   --  34-42

>> Failed 9/3631 tests, 99.75% okay, 55 tests skipped.
>> Files=60,  Tests=3631,  12.90 seconds (2.43 usr + 1.92 sys = 4.35 CPU)
>> make[2]: *** [Makefile:38: test] Error 1

> I'm working on a fix.  It's unfortunately rather complicated because the
> assumption that binding on any address will provide two sockets ran fairly
> deep.

> I think the problem only affects the test suite.

This is fixed by upstream commits r10388 (trunk) and r10396 (stable).

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

Bug#975410: src:sieve-connect: fails to migrate to testing for too long: maintainer built arch:all binary

[Paul Gevers]

Source: sieve-connect
Version: 0.88-1.1
Severity: serious
Control: close -1 0.90-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:sieve-connect
in its current version in unstable has been trying to migrate for 61
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=sieve-connect




signature.asc
Description: OpenPGP digital signature

Bug#974178: python3-biom-format: debci tests fail: Object of type bytes is not JSON serializable

[Nilesh Patra]

Hi,

debci seems happy now.

https://ci.debian.net/packages/p/python-biom-format/unstable/amd64/
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-biom-format/8336917/log.gz

Should this bug be closed now? Please let me know/do so if you feel this is
done.

(I can close it myself in a few days when there are more logs)

Nilesh

Bug#975388: calibre no more usable

[Grand T]

apt policy calibre-bin
calibre-bin:
  Installé : 5.5.0+dfsg-1+b1
  Candidat : 5.5.0+dfsg-1+b1
 Table de version :
 *** 5.5.0+dfsg-1+b1 990
990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 3.39.1+dfsg-3 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
 2.75.1+dfsg-1 500
500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Pack


  *   calibre-bin seems really depends pn python3.9

root@debian:~# apt-rdepends  calibre-bin | grep 3.9
Reading package lists... Done
Building dependency tree
Reading state information... Done
  Depends: libpython3.9 (>= 3.9.0~b4)
  Depends: libcom-err2 (>= 1.43.9)
  Depends: libcom-err2 (>= 1.43.9)
libpython3.9
  Depends: libpython3.9-stdlib (= 3.9.0-5)
libpython3.9-stdlib
  Depends: libpython3.9-minimal (= 3.9.0-5)
libpython3.9-minimal
  Depends: lsb-base (>= 1.3-9ubuntu2)
  Depends: libpython3-stdlib (= 3.9.0-3)
  Depends: python3.9 (>= 3.9.0-1~)
  PreDepends: python3-minimal (= 3.9.0-3)
  Depends: libpython3.9-stdlib (>= 3.9.0-1~)
python3.9
  Depends: libpython3.9-stdlib (= 3.9.0-5)
  Depends: python3.9-minimal (= 3.9.0-5)
python3.9-minimal
  Depends: libpython3.9-minimal (= 3.9.0-5)
  PreDepends: python3.9-minimal (>= 3.9.0-1~)

Bug#975409: pwman FTBFS: ModuleNotFoundError: No module named 'cryptography'

[Adrian Bunk]

Source: pwman3
Version: 0.12.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pwman3=all=0.12.1-1=1605944549=0

...
dh_auto_clean
I: pybuild base:232: python3.8 setup.py clean 
Traceback (most recent call last):
  File "setup.py", line 390, in 
import pwman
  File "/<>/pwman/__init__.py", line 33, in 
from pwman.data.factory import check_db_version
  File "/<>/pwman/data/__init__.py", line 1, in 
from . import factory
  File "/<>/pwman/data/factory.py", line 25, in 
from pwman.data.database import DatabaseException
  File "/<>/pwman/data/database.py", line 22, in 
from pwman.util.crypto_engine import CryptoEngine
  File "/<>/pwman/util/crypto_engine.py", line 29, in 
from cryptography.fernet import Fernet
ModuleNotFoundError: No module named 'cryptography'
E: pybuild pybuild:353: clean: plugin distutils failed with: exit code=1: 
python3.8 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.8 3.9" returned 
exit code 13
make[1]: *** [debian/rules:15: override_dh_auto_clean] Error 25

Bug#973293: gcc-10: internal compiler error: ‘verify_gimple’ failed

[Alberto Garcia]

On Wed, Oct 28, 2020 at 12:07:03AM +0100, Alberto Garcia wrote:
> Package: gcc-10
> Version: 10.2.0-15
> Severity: important
> 
> Hi,
> 
> gcc is causing a FTBFS on the latest releases of webkit2gtk and
> wpewebkit (2.30.2-1 in both cases) on armel and armhf with the
> following error message:

We have a workaround for this in WebKit so this is not stopping the
build anymore. Feel free to lower the severity if you want.

https://trac.webkit.org/changeset/269948/webkit

Berto

Bug#975408: sddm: "ENTER" keys don't work and I cannot log in

[Georgi Naplatanov]

Package: sddm
Version: 0.19.0-2
Severity: normal
X-Debbugs-Cc: go...@oles.biz

Dear Maintainer,

when I enter my password and hit "ENTER" key the system does nothing and I 
cannot log in. I have standard keyboard for desktop computer and tried with 
both enter keys - the standar one and the other next to right number pad.


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

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
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:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.74
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-16
ii  libpam0g1.3.1-5
ii  libqt5core5a5.15.1+dfsg-2
ii  libqt5dbus5 5.15.1+dfsg-2
ii  libqt5gui5  5.15.1+dfsg-2
ii  libqt5network5  5.15.1+dfsg-2
ii  libqt5qml5  5.15.1+dfsg-3
ii  libqt5quick55.15.1+dfsg-3
ii  libstdc++6  10.2.0-16
ii  libsystemd0 246.6-2
ii  libxcb-xkb1 1.14-2
ii  libxcb1 1.14-2
ii  qml-module-qtquick2 5.15.1+dfsg-3
ii  x11-common  1:7.7+21
ii  xauth   1:1.0.10-1
ii  xserver-xorg [xserver]  1:7.7+21

Versions of packages sddm recommends:
ii  haveged  1.9.8-4
ii  libpam-systemd   246.6-2
ii  sddm-theme-debian-maui [sddm-theme]  0.19.0-2

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.19.5-3
ii  qtvirtualkeyboard-plugin  5.15.1+dfsg-2

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#974762: apt-listbugs: [INTL:pt] Portuguese translation for debconf messages

[Francesco Poli]

On Sun, 15 Nov 2020 15:54:44 +0100 Francesco Poli wrote:

> On Sat, 14 Nov 2020 20:13:48 + tra...@debianpt.org wrote:
> 
> > Package: apt-listbugs
> > Version: 0.1.34
> > Tags: l10n, patch
> > Severity: wishlist
> > 
> > Updated Portuguese translation for apt-listbugs debconf messages.
> > Feel free to use it.
> [...]
> 
> Hello Miguel!
> Thanks for the updated translation.
> 
> I have a few questions.
> Please note that I do not speak Portuguese, hence I may be completely
> off-track. Please bear with me!
> 
> 
> First question
> ==
> 
> #: ../lib/aptlistbugs/logic.rb:66
> msgid ""
> " -F   : Automatically pin all buggy packages.\n"
> msgstr ""
> " -F   : Fazer pin automaticamente a todos os pacotes com bugs.\n"
> 
> #: ../lib/aptlistbugs/logic.rb:67
> msgid ""
> " -N   : Never automatically pin packages.\n"
> msgstr ""
> " -N   : Nunca fazer pin automaticamente a pacotes.\n"
> 
> 
> The word "pin" has been translated as "fixar" elsewhere: can we improve
> consistency and use the same translation here, as well?
> Would something like the following be OK?
> 
> " -F   : Fixar automaticamente todos os pacotes com bugs.\n"
> 
> " -N   : Nunca fixar automaticamente pacotes.\n"
> 
> 
> Second question
> ===
> 
> #. TRANSLATORS: %{plist} is a comma-separated list of %{npkgs} packages to be 
> pinned.
> #: ../lib/aptlistbugs/logic.rb:576 ../lib/aptlistbugs/logic.rb:655
> msgid ""
> "The following %{npkgs} package will be pinned:\n"
> " %{plist}\n"
> "Are you sure?"
> msgid_plural ""
> "The following %{npkgs} packages will be pinned:\n"
> " %{plist}\n"
> "Are you sure?"
> msgstr[0] ""
> "O seguinte %{npkgs} pacote será marcado como 'pinned':\n"
> " %{plist}\n"
> "Tem a certeza?"
> msgstr[1] ""
> "Os seguintes %{npkgs} pacotes serão marcados como 'pinned':\n"
> " %{plist}\n"
> "Tem a certeza?"
> 
> 
> Same doubt here.
> Would something like the following be OK?
> 
> msgstr[0] ""
> "O seguinte %{npkgs} pacote será fixado:\n"
> " %{plist}\n"
> "Tem a certeza?"
> msgstr[1] ""
> "Os seguintes %{npkgs} pacotes serão fixados:\n"
> " %{plist}\n"
> "Tem a certeza?"
> 
> 
> Third question
> ==
> 
> #. TRANSLATORS: %{blist} is a comma-separated list of %{nbugs} bugs to be 
> dodged.
> #: ../lib/aptlistbugs/logic.rb:614
> msgid ""
> "The following %{nbugs} bug will be dodged:\n"
> " %{blist}\n"
> "Are you sure?"
> msgid_plural ""
> "The following %{nbugs} bugs will be dodged:\n"
> " %{blist}\n"
> "Are you sure?"
> msgstr[0] ""
> "Osi seguintes %{nbugs} serão evitados:\n"
> " %{blist}\n"
> "Tem a certeza?"
> msgstr[1] ""
> "Os seguintes %{nbugs} serão esquivados:\n"
> " %{blist}\n"
> "Tem a certeza?"
> 
> 
> I have some doubts here: why is "dodged" translated with two different
> words? If I understand an online dictionary correctly, they seem to be
> synonyms, but I would choose one translation and use it consistently,
> anyway...
> Moreover, where is the word "bug" in the translation?
> Finally, is the singular form really singular?
> 
> Would something like the following be OK?
> 
> msgstr[0] ""
> "O seguinte %{nbugs} bug será evitado:\n"
> " %{blist}\n"
> "Tem a certeza?"
> msgstr[1] ""
> "Os seguintes %{nbugs} bugs serão evitados:\n"
> " %{blist}\n"
> "Tem a certeza?"
> 
> 
> Fourth question
> ===
> 
> #: ../lib/aptlistbugs/logic.rb:664
> msgid "All selected packages are already pinned. Ignoring %s command."
> msgstr "Todos os pacotes já estão marcados como 'pinned'. A ignorar o comando 
> %s."
> 
> 
> Once again, would something like the following be OK?
> 
> msgstr "Todos os pacotes já estão fixados. A ignorar o comando %s."
> 
> 
> Fifth question
> ==
> 
> #: ../lib/aptlistbugs/logic.rb:670
> msgid "There are no dodge/pin/ignore operations to undo. Ignoring %s command."
> msgstr "Não existem operações dodge/pin/ignore para desfazer. A ignorar o 
> comando %s."
> 
> #: ../lib/aptlistbugs/logic.rb:672
> msgid ""
> "All the dodge/pin/ignore operations will be undone.\n"
> "Are you sure?"
> msgstr ""
> "Todas as operações dodge/pin/ignore serão desfeitas.\n"
> "Tem a certeza?"
> 
> 
> Since "dodge" has been translated as "evitar", "pin" as "fixar", and
> "ignore" as "ignorar", it would perhaps be better to also translate
> these words here.
> Would something like the following be OK?
> 
> msgstr "Não existem operações de evitar/fixar/ignorar para desfazer. A 
> ignorar o comando %s."
> 
> msgstr ""
> "Todas as operações de evitar/fixar/ignorar serão desfeitas.\n"
> "Tem a certeza?"
> 
> 
> Sixth question
> ==
> 
> #: ../lib/aptlistbugs/logic.rb:685
> msgid ""
> " y - continue the APT installation.\n"
> msgstr ""
> " y - contar a instalação do APT.\n"
> 
> 
> Is "contar" the correct translation for "continue"?
> Would something like the following be better?
> 
> " y - continuar a instalação do APT.\n"
> 
> 
> Seventh question
> 
> 
> #. 

Bug#975405: [Pkg-javascript-devel] Bug#975405: wabt: Please build wabt.js

[Jonas Smedegaard]

Quoting Xavier Guimard (2020-11-21 18:45:47)
> wabt.js upstream repository is a minified file built from wabt. This 
> package is a reverse dependency of many packages in Debian (via 
> webpack, webassembly, jest,...). Without it, those packages works but 
> some features are missing.

Sidenote: It seems that one set of artifacts in the wabt.js project is 
exact replicas of the command-line tools of wabt.  It is probably worth 
investigating if some of the reverse dependencies (especially those 
_build-depending_ on wabt.js) could instead use the wabt package 
directly.


 - Jonas

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

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

signature.asc
Description: signature

Bug#818996: From Lisa

[lw29874]

Je vous ai invité à remplir le formulaire suivant :
Formulaire sans titre

Pour remplir ce formulaire, consultez :
https://docs.google.com/forms/d/e/1FAIpQLSfkXJFwmAuGwoHhx2QwLuILIPlOXu3n3BB47pMKhn3GTxlgkA/viewform?vc=0c=0w=1flr=0usp=mail_form_link

 Hi Dear,

  I was just going through the Internet search when I found your email  
address, I want to make a new and special friend, so I decided to contact  
you to see how we can make it work out if we can. Please I wish you will  
have the desire with me so that we can

get to know each other better and see what happens in future.

 My name is Lisa Williams, I am an American, but presently I live in the  
UK, I will be glad to see your reply for us to know each other better to  
exchange pictures and details about us.


  Yours
  Lisa

Google Forms vous permet de créer des enquêtes et d'en analyser les  
résultats.

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Sylvain Beucler]

Hi,

It seems likely that this issue won't get a proper fix soon, due to 
upstream inactivity in that area, and the requirement of breaking binary 
compatibility.


Use-after-free is a serious vulnerability as it can lead to various 
issues including code execution, and the issue was rated 8.1/10 by NVD:

http://cwe.mitre.org/data/definitions/416.html
https://nvd.nist.gov/vuln/detail/CVE-2018-1311

RedHat introduced a trade-off with the simple attached patch which fixes 
this issue at the expense of a memory leak.
(you can also get it from 
http://vault.centos.org/7.7.1908/updates/Source/SPackages/xerces-c-3.1.1-10.el7_7.src.rpm)


Do we want to follow suit?

Cheers!
Sylvain Beucler
Debian LTS Team

On Thu, 26 Dec 2019 21:40:38 +0100 Salvatore Bonaccorso 
 wrote:

Source: xerces-c
Version: 3.2.2+debian-1
Severity: important
Tags: security upstream
Forwarded: https://issues.apache.org/jira/browse/XERCESC-2188
Control: found -1 3.1.4+debian-2+deb9u1
Control: found -1 3.1.4+debian-1

Hi,

The following vulnerability was published for xerces-c. There is no
upstream fix and only suggested mitigations, at time of writing the
bugreport.

CVE-2018-1311[0]:
| The Apache Xerces-C 3.0.0 to 3.2.2 XML parser contains a use-after-
| free error triggered during the scanning of external DTDs. This flaw
| has not been addressed in the maintained version of the library and
| has no current mitigation other than to disable DTD processing. This
| can be accomplished via the DOM using a standard parser feature, or
| via SAX using the XERCES_DISABLE_DTD environment variable.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1311
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1311
[1] https://issues.apache.org/jira/browse/XERCESC-2188
[2] https://xerces.apache.org/xerces-c/secadv/CVE-2018-1311.txt
[3] https://marc.info/?l=xerces-c-users=157653840106914=2

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1311

--- xerces-c-3.0.1/src/xercesc/internal/IGXMLScanner.cpp.cve1311
+++ xerces-c-3.0.1/src/xercesc/internal/IGXMLScanner.cpp
@@ -1533,7 +1533,6 @@
 DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager);
 declDTD->setSystemId(sysId);
 declDTD->setIsExternal(true);
-Janitor janDecl(declDTD);
 
 // Mark this one as a throw at end
 reader->setThrowAtEnd(true);
@@ -3154,7 +3153,6 @@
 DTDEntityDecl* declDTD = new (fMemoryManager) DTDEntityDecl(gDTDStr, false, fMemoryManager);
 declDTD->setSystemId(src.getSystemId());
 declDTD->setIsExternal(true);
-Janitor janDecl(declDTD);
 
 // Mark this one as a throw at end
 newReader->setThrowAtEnd(true);

Bug#945404: grub2-common: '/boot/grub/.background_cache.png' is not created on LUKS encrypted system

[Steve McIntyre]

Control: tags -1 +patch

On Wed, Aug 12, 2020 at 12:53:46PM +0200, Gábor Gombás wrote:
>Package: grub2-common
>Version: 2.04-9
>Followup-For: Bug #945404
>
>The reason is lack of LUKS2 support. Specifically, in
>grub-core/osdep/devmapper/getroot.c, grub_util_get_dm_abstraction() has:
>
>  if (strncmp (uuid, "CRYPT-LUKS1-", 12) == 0)
>{
>  grub_free (uuid);
>  return GRUB_DEV_ABSTRACTION_LUKS;
>}
>
>That will not match LUKS2-encrypted volumes, so grub-probe thinks the
>filesystem will be readable.
>
>Although grub upstream has some LUKS2 support now (see
>https://savannah.gnu.org/bugs/?55093), that does not seem to cover this
>part of the code yet.

ACK, you've worked out the cause of the problem here. I have a system
that shows exactly the same issue here.

Looking at the wider picture, at boot grub will not be able to read
the background graphic on lots of systems where the user has an
unencrypted /boot and so has has not configured grub to unencrypt
anything. This is the default setup for encrypted systems created
using debian-installer, so it's going to be quite common. (It's how I
found this!)

To be honest, I'm thinking we should just change the Debian theme
setup here to *always* copy the background image to
/boot/grub/.background_cache.png and use it from there. Not all users
need it, but it makes the logic simpler and more consistent here. It's
only a single graphic that's copied into /boot, after all...

@Colin: thoughts?

Patch attached for review.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall
diff --git a/debian/grub.d/05_debian_theme b/debian/grub.d/05_debian_theme
index 786888d3f..78fce2f33 100755
--- a/debian/grub.d/05_debian_theme
+++ b/debian/grub.d/05_debian_theme
@@ -23,7 +23,8 @@ set -e
 # We want to work in /boot/grub/ only.
 test -d /boot/grub; cd /boot/grub
 
-# Set the location of a possibly necessary cache file for the background image.
+# Set the location of a cache file for the background image that will
+# always be readable by grub at boot.
 # NOTE: This MUST BE A DOTFILE to avoid confusing it with user-defined images.
 BACKGROUND_CACHE=".background_cache"
 
@@ -94,13 +95,9 @@ set_background_image(){
 		return 4
 	fi
 
-	# Step #5: Check if GRUB can read the background image directly.
-	# If so, we can remove the cache file (if any). Otherwise the background
-	# image needs to be cached under /boot/grub/.
-	if is_path_readable_by_grub "${1}"; then
-		rm --force "${BACKGROUND_CACHE}.jpeg" \
-			"${BACKGROUND_CACHE}.png" "${BACKGROUND_CACHE}.tga"
-	elif cp "${1}" "${BACKGROUND_CACHE}.${reader}"; then
+	# The background image needs to be cached under /boot/grub/ to
+	# make sure it's always readable at boot.
+	if cp "${1}" "${BACKGROUND_CACHE}.${reader}"; then
 		set -- "${BACKGROUND_CACHE}.${reader}" "${2}" "${3}"
 	else
 		return 5

Bug#975289: systemd: always reporting unit file has "changed on disk" when override.conf is present

[Michael Biebl]

Control: tags -1 + upstream

Hello Richard

Am 20.11.20 um 06:42 schrieb Richard van den Berg:
> Package: systemd
> Version: 246.6-2~bpo10+1
> Severity: normal
> 
> I added a system wide drop-in at 
> /etc/systemd/system/service.d/90-pushover.conf and a specific drop-in at 
> /etc/systemd/system/prometheus.service.d/override.conf
> Now systemd always complains for prometheus.service:
> 
> # systemctl status prometheus
> Warning: The unit file, source configuration file or drop-ins of
> prometheus.service changed on disk. Run 'systemctl daemon-reload' to
> reload units.

Could you report this upstream please at
https://github.com/systemd/systemd/issues/



signature.asc
Description: OpenPGP digital signature

Bug#975400: [247~rc2-2] 2 minutes delay at "systemctl poweroff"

[Michael Biebl]

Control: tags -1 + moreinfo

Am 21.11.20 um 17:47 schrieb Roderich Schupp:
> Package: systemd
> Version: 247~rc2-2
> Severity: normal
> X-Debbugs-Cc: roderich.sch...@gmail.com
> 
> Since upgrading to version 247~rc2-2, poweroff reprodicably experiences
> a 2 minute delay. You can see it at line 526 (Nov 17 01:03:38 -> Nov 17
> 01:05:20) of the attached excerpt from journalctl.

Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: State 'stop-sigterm'
timed out. Killing.
Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: Killing process 1141
(systemd) with signal SIGKILL.
Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: Killing process 1286
(ssh-agent) with signal SIGKILL.
Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: Killing process
163646 (dbus-daemon) with signal SIGKILL.
Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: Main process exited,
code=killed, status=9/KILL
Nov 17 01:05:38 nuc8 systemd[1]: user@1000.service: Failed with result
'timeout'.

I suppose this is your problem.
You have processes (ssh-agent and dbus-daemon) in your user session,
which apparently do not stop in a timely manner, thus causing the delay,
afaics.

Is this problem reproducible with a new user account?

Michael



signature.asc
Description: OpenPGP digital signature

Bug#975394: fish: honor scripts in /etc/profile.d

[Patrice Duroux]

Here is my awful solution used sure only on my personal system:

~> cat /etc/fish/conf.d/etc-profile.fish
#
eval (/usr/bin/sh -c 'envfile=$(mktemp -t fish_importenv.XX) ; export | 
sort  > "$envfile" ; for f in $(ls /etc/profile.d/*.sh) ; do . "$f" ; done ; 
export | sort | comm -3 "$envfile" - | sed -r "s/export ([^=]+)=(.*)/set -x \1 
\2;/g" ; rm -f "$envfile"')


At least this working to set PATH also according to 
/etc/profile.d/apps-bin-path.sh
and IM_CONFIG_CHECK_ENV according to /etc/profile.d/im-config_wayland.sh.

Here is a potential list of candidate packages:

~> apt-file search /etc/profile.d
bash-completion: /etc/profile.d/bash_completion.sh
byobu: /etc/profile.d/Z97-byobu.sh
chkboot: /etc/profile.d/chkboot-profilealert.sh
cloud-init: /etc/profile.d/Z99-cloud-locale-test.sh
debian-mate-default-settings: 
/etc/profile.d/debian-mate-default-settings_gtk-accessibility.sh
environment-modules: /etc/profile.d/modules.sh
flatpak: /etc/profile.d/flatpak.sh
gawk: /etc/profile.d/gawk.csh
gawk: /etc/profile.d/gawk.sh
im-config: /etc/profile.d/im-config_wayland.sh
junior-config: /etc/profile.d/debian-junior.sh
lammps: /etc/profile.d/lammps.csh
lammps: /etc/profile.d/lammps.sh
libvte-2.91-common: /etc/profile.d/vte-2.91.sh
libvte-2.91-common: /etc/profile.d/vte.csh
lmod: /etc/profile.d/lmod.sh
med-config: /etc/profile.d/debian-med.sh
mobile-tweaks-common: /etc/profile.d/mobile-tweaks.sh
osc: /etc/profile.d/osc.csh
packagekit-command-not-found: /etc/profile.d/PackageKit.sh
pan-config: /etc/profile.d/debian-pan.sh
safe-rm: /etc/profile.d/safe-rm.sh
sbmltoolbox: /etc/profile.d/SBMLToolbox.sh
science-config: /etc/profile.d/debian-science.sh
sendfile: /etc/profile.d/sendfile
snapd: /etc/profile.d/apps-bin-path.sh
sumo: /etc/profile.d/sumo.csh
sumo: /etc/profile.d/sumo.sh
undistract-me: /etc/profile.d/undistract-me.sh
vala-panel-appmenu-common: /etc/profile.d/vala-panel-appmenu.sh

Bug#975405: [Pkg-javascript-devel] Bug#975405: wabt: Please build wabt.js

[Jonas Smedegaard]

Quoting Xavier Guimard (2020-11-21 18:45:47)
> wabt.js upstream repository is a minified file built from wabt. This 
> package is a reverse dependency of many packages in Debian (via 
> webpack, webassembly, jest,...). Without it, those packages works but 
> some features are missing.
> 
> You can either build the full nodejs package or simply wabt.js (and 
> then I'll create node-wabt.js with a link to your files.
> 
> I posted a question to know which target corresponds to this build 
> (see https://github.com/AssemblyScript/wabt.js/issues/20).

Building wabt for webassembly would involve emscripten, so even though 
technically possible to have wabt provide a build of itself for 
webassembly, that would create a circular build-dependency and require 
tracking two sources in one source package.

I therefore think it is better to have wabt provide a package 
wabt-source, and have a new source package node-wabt build that for 
webassembly.


 - Jonas

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

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

signature.asc
Description: signature

Bug#975407: bibledit-cloud: Move git to pkg-crosswire-team

[Bastian Germann]

Source: bibledit-cloud
Severity: wishlist

bibledit-cloud's git repository should be moved over to the
pkg-crosswire-team GitLab organization.

Bug#858174: Please provide an AppArmor profile for Firefox

[Stefan Kangas]

intrigeri  writes:

> In any case, they don't enforce the profile by default, according to
> https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles

If I read that page correctly, Ubuntu enables the profile for Firefox by
default in 20.04 LTS (released on April 23, 2020) and in 20.10.

Bug#975406: bzflag: BZFlag lacks IPv6 support

[Bruno Kleinert]

Package: bzflag
Version: 2.4.20-1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: fu...@debian.org

Hi there,

BZFlag lacks IPv6 support. I searched the bzfs manpage and /usr/share/doc/bzfs-
server for a switch without success.

Since an increasing number of internet service providers in Germany (and
probably in other countries) do not natively support IPv4 anymore, but IPv6, it
is impossible to host a BZFlag server on a dial-up connection. BZFlag should
support IPv6.

Cheers,
Bruno



-- 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)

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.utf-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bzflag depends on:
ii  bzflag-client  2.4.20-1
pn  bzflag-server  

bzflag recommends no packages.

bzflag suggests no packages.

Bug#975405: wabt: Please build wabt.js

[Xavier Guimard]

Package: wabt
Version: 1.0.20-1
Severity: important
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

Hi,

wabt.js upstream repository is a minified file built from wabt. This
package is a reverse dependency of many packages in Debian (via webpack,
webassembly, jest,...). Without it, those packages works but some
features are missing.

You can either build the full nodejs package or simply wabt.js (and then
I'll create node-wabt.js with a link to your files.

I posted a question to know which target corresponds to this build (see
https://github.com/AssemblyScript/wabt.js/issues/20).

Cheers,
Xavier

Bug#971515: Status as of last tech-ctte meeting

[Tollef Fog Heen]

]] Shengjing Zhu 

> Firefox is special, since for Debian desktop users, they need a browser. Is
> kubernetes same here?

FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
nomad, docker swarm) in stable has been keeping back development of the
next generation way of handling Debian services, since that will need a
reasonable container orchestation platform to build on.  The lack of a
platform is not the only reason for the delay, but it surely hasn't
helped either.

-- 
Tollef Fog Heen, speaking for himself, but as a DSA member

Bug#975404: ITP: annotation-detector -- scan class path for annotated classes, methods, or instance variables

[Bdale Garbee]

Package: wnpp
Severity: wishlist
Owner: Bdale Garbee 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: annotation-detector
  Version : 3.0.5
  Upstream Author : XIAM Solutions B.V. (http://www.xiam.nl)
* URL : https://github.com/rmuller/infomas-asl
* License : Apache
  Programming Lang: Java
  Description : scan class path for annotated classes, methods, or instance 
variables

This library can be used to scan (part of) the class path for annotated 
classes, methods 
or instance variables. Main advantages of this library compared with similar 
solutions 
are: light weight (no dependencies, simple API, 20 kb jar file) and very fast 
(fastest 
annotation detection library as far as I know).


I'm packaging this because it's a build dependency for openrocket, which I 
would like to 
move back from being a "jar installer" in contrib to a real build from source 
in main.

Bdale

Bug#744924: file: buggy magic: mistakes text as diff

[Vincent Lefevre]

Control: found -1 1:5.39-3

This bug is still there:

zira% file --version
file-5.39
magic file from /etc/magic:/usr/share/misc/magic
zira% echo '*** Title' | file -
/dev/stdin: diff output, ASCII text

The upstream bug https://bugs.astron.com/view.php?id=184 says that
it is fixed in 5.39. Is there anything specific to Debian?

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

Bug#975403: RM: knocker -- ROM; unmaintained, better alternatives

[Marcos Fouces]

Package: ftp.debian.org
Severity: normal

Please, remove knocker package. It is unmaintained upstream and it is
affected by #957411. Also there are other better network scanners
(nmap, hping3...).

Also it has a low popcon (72 at the time of writing).

Thanks in advance.

Marcos.

Bug#975322: broken mlterm 3.9 definitions

[Yuri D'Elia]

On Sat, Nov 21 2020, Sven Joachim wrote:
>>> mlterm-256color:\
>>> k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~
>>>
>>> Removing this (so that mlterm sends it's usual \EOP/*) fixes the
>>> background-color rendering.
>>>
>>> I'm puzzled as of why this override would influence this at all?
>>
>> It sounds like a problem in mlterm, e.g., in the way it stores the "ut"
>> (terminfo "bce") capability.  It doesn't appear to read the ncurses
>> terminal database, which (since bce worked when I tested it) says it
>> does back-color-erase, while the compiled-in termcap says it does not.
>>
>> If the mlterm package changed that ut-default setting, then providing your
>> own termcap settings may have reset the behavior to match the compiled-in
>> NON-ut default.
>
> That seems to have hit the mark.  Indeed, if ":ut" is added to Yuri's
> termcap example, mlterm works correctly again.
>
> Yuri, would you like to bring this to the attention of the mlterm
> developers?

Absolutely. Thanks for helping out on this!

Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists

[Tzafrir Cohen]

  
  
Hi,



On abel in a armel chroot the issue is
  reproduced by running:


  man -Thtml 



even on an empty man page.



Right now you can try:


$ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml
  ~tzafrir/test.8 >/dev/null
  pre-grohtml: fatal error: cannot create temporary file: File
  exists
  man: command exited with status 1: /usr/lib/man-db/zsoelim |
  /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE |
  preconv -e UTF-8 | tbl | groff -mandoc -Thtml


Not reproduced in a armhf chroot there or in a qemu armel chroot
  on my laptop.



-- Tzafrir

  

Bug#975402: libmagic-mgc: messages for Git objects have an incorrect id

[Vincent Lefevre]

Package: libmagic-mgc
Version: 1:5.39-3
Severity: normal
Tags: upstream fixed-upstream patch

The messages for Git objects have an incorrect id: only the first
sequence of decimal digits is retrieved instead of the full sequence
of hexadecimal digits. This is due to a bad regexp in
"magic/Magdir/git".

$ echo "commit d617e0c0ca8fac42361b00c8861eb2a59ab7a7d8" | file -
/dev/stdin: Git commit 617

This was fixed upstream several months ago:

  https://bugs.astron.com/view.php?id=176

I've attached my patch.

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Fix messages for Git objects.
Bug: https://bugs.astron.com/view.php?id=176
Author: Vincent Lefevre 
Last-Update: 2020-08-05

--- file-5.38-a/magic/Magdir/git2019-10-04 18:46:29.0 +
+++ file-5.38-b/magic/Magdir/git2020-08-05 11:56:09.704167516 +
@@ -4,10 +4,10 @@
 # git:  file(1) magic for Git objects
 
 0  string  blob\040
->5 regex   [0-9]+  Git blob %s
+>5 regex   [0-9a-f]+   Git blob %s
 
 0  string  tree\040
->5 regex   [0-9]+  Git tree %s
+>5 regex   [0-9a-f]+   Git tree %s
 
 0  string  commit\040
->7 regex   [0-9]+  Git commit %s
+>7 regex   [0-9a-f]+   Git commit %s

Bug#975401: clamav-daemon: clamd uses large amounts of memory

[Stephen Kitt]

Package: clamav-daemon
Version: 0.102.4+dfsg-0+deb10u1
Severity: normal

Dear Maintainer,

I noticed that clamd now uses large amounts of memory:

clamav1006  1.9  3.6 1405692 1186776 ? Ssl  17:53   0:12 
/usr/sbin/clamd --foreground=true

I don’t remember it doing so until the last few weeks. Restarting it
or even rebooting doesn’t fix things.

What can I do to help investigate the causes?

Regards,

Stephen


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory = "/tmp"
DatabaseDirectory = "/var/lib/clamav/"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "10485760"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav/"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "12"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer = "localhost"
HTTPProxyPort = "3128"
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = "30"
ReceiveTimeout = "30"
SafeBrowsing disabled
Bytecode = "yes"

clamav-milter.conf not found

Software settings
-
Version: 0.102.4
Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 
LIBXML2 PCRE2 ICONV JSON 

Database information

Database 

Bug#975322: broken mlterm 3.9 definitions

[Sven Joachim]

On 2020-11-20 20:08 -0500, Thomas Dickey wrote:

> On Fri, Nov 20, 2020 at 10:42:51PM +0100, Yuri D'Elia wrote:
>> On Fri, Nov 20 2020, Sven Joachim wrote:
>> > Which version of mlterm do you use?
>>
>> I'm also using mlterm 3.9.0-1.
>>
>> So after some scrambling, I have a custom ~/.mlterm/termcap config to
>> override the sequence sent by F[1-4]:
>>
>> mlterm-256color:\
>> k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~
>>
>> Removing this (so that mlterm sends it's usual \EOP/*) fixes the
>> background-color rendering.
>>
>> I'm puzzled as of why this override would influence this at all?
>
> It sounds like a problem in mlterm, e.g., in the way it stores the "ut"
> (terminfo "bce") capability.  It doesn't appear to read the ncurses
> terminal database, which (since bce worked when I tested it) says it
> does back-color-erase, while the compiled-in termcap says it does not.
>
> If the mlterm package changed that ut-default setting, then providing your
> own termcap settings may have reset the behavior to match the compiled-in
> NON-ut default.

That seems to have hit the mark.  Indeed, if ":ut" is added to Yuri's
termcap example, mlterm works correctly again.

Yuri, would you like to bring this to the attention of the mlterm
developers?

Cheers,
   Sven

Bug#975399: murrine-themes: Should stop recommending removed albatross-gtk-theme

[Witold Baryluk]

Package: murrine-themes
Version: 0.98.11
Severity: minor
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

it looks like murrine-themes Recommends package albatross-gtk-theme

But this package was removed a bit over a year ago from testing.


https://tracker.debian.org/news/1068370/removed-174-1-from-unstable/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941357

Reason: ROM; unmaintained; lack of GTK3 support.

Looking at upstream github, it looks there is GTK3 support, but last
commit was 5 years ago, so probably it is incomplete and dead.



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

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

Versions of packages murrine-themes depends on:
ii  gtk2-engines-murrine  0.98.2-3

Versions of packages murrine-themes recommends:
pn  albatross-gtk-theme  
ii  blackbird-gtk-theme  0.4+20171213-2
ii  bluebird-gtk-theme   1.3-2
ii  greybird-gtk-theme   3.22.10-1

murrine-themes suggests no packages.

-- no debconf information

Bug#971770: webext-dav4tbsync: Incompatible with Thunderbird 78

[Jonas Smedegaard]

No-op post to bump timestapm of this bugreport: Helps nudge the 
kick-packages-with-broken-rdeps-from-testing machinery to look further 
back at thunderbird for the real cause.


 - Jonas

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

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

signature.asc
Description: signature

Bug#975398: reportbug crashes with Python 3.9

[Roderich Schupp]

Package: python3-reportbug
Version: 7.8.0
Severity: normal
Tags: patch
X-Debbugs-Cc: roderich.sch...@gmail.com

Trying to retrieve a bug page in "reportbug" (using Python 3.9 which
just became the default in unstable) results in

  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line 435, in
pulse
return self.isAlive()
AttributeError: 'BugPage' object has no attribute 'isAlive'

Note: class BugPage is derived from threading.Thread)

Reason (from "What's New In Python 3.9"):
The :meth:`~threading.Thread.isAlive()` method of :class:`threading.Thread` has
been removed. It was deprecated since Python 3.8. Use
:meth:`~threading.Thread.is_alive()` instead.

Patch attached.


Cheers, Roderich



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

Kernel: Linux 5.10.0-rc4 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-reportbug depends on:
ii  apt2.1.11
ii  file   1:5.39-3
ii  python33.9.0-3
ii  python3-apt2.1.5
ii  python3-debian 0.1.38
ii  python3-debianbts  3.0.2
ii  python3-requests   2.24.0+dfsg-1
ii  sensible-utils 0.0.12+nmu1

python3-reportbug recommends no packages.

Versions of packages python3-reportbug suggests:
ii  reportbug  7.8.0

-- no debconf information
python3-reportbug: /usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py

Bug#968102: tbsync: Incompatible with Thunderbird 78

[Jonas Smedegaard]

Another no-op post to bump timestapm of this bugreport: Helps nudge the 
kick-packages-with-broken-rdeps-from-testing machinery to look further 
back at thunderbird for the real cause.

 - Jonas

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

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

signature.asc
Description: signature

Bug#975381: Subject: libinih: drop Debian's custom vendorisation

[Stephan Lachnit]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: tech-ctte
Severity: wishlist

Currently the package libinih uses some heavy patches, which aren't upstream
and aren't used by any other distro. I'm in favor of dropping this, but the
current maintainer disagrees and we weren't able to make any progess in the
discussion, so I want to put this here. Parts of the discussion can be found on
this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2

To understand this, one has to look a bit at the history behind inih. Upstream
was designed as a static library for embedded devices, and therefore has a lot
of compile time options. At this point, the current maintainer created a patch
to make all compile time option available on runtime.

When gamemode started using inih, I wanted to get rid of shipped inih code and
upstreamed a build system to inih for a shared library, that any distro can
use. This was done in version 48. Due to the popularity of gamemode, inih is
now found in most major distros (all without Debian's patches):
https://repology.org/project/inih/versions

There is a notable "exception": inih is not in Ubuntu's main repository. This
is a bit weird because gamemode is in main, but with the shipped inih source
which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
not sure why, but I suspect the heavy patches make it harder to be included in
main.

Because the library was designed for embedded use cases where every little bit
of performance matters, the runtime patch was refused upstream. Dropping the
runtime patch from Debian actually isn't problem, no reverse dependency of
libinih uses compile time options anyway. However, due to the history of inih
in Debian is has the soversion 1, while upstream is soversion 0.

I want to drop the vendorisation of Debian and start a transition to soversion
0 (which is also a reason I contact the Technical Committee, as it's not clear
how this would be done). A transition is needed anyway since dropping the patch
is a breaking change anyway. If the Technical Committee agrees to this, I would
also gladly help to maintain this package since it is 2 version behind upstream
since almost half a year and I maintain gamemode, which is directly affected by
this.

This isn't urgent, but it would be nice to get this done till bulleseye.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl+5BWIACgkQs1tJ6l1W
Pv7dyA//QMHV+BGlUzXIMCcBlkVnYe85/TT8xH2peZTZ7j5ULBwvGGVhYG1Dt8/A
PcziDIcVLhmEN6N5r9vTispp0McTy5nNpotVgZ/5KJ1+WzRS+7D1YGXyS6YOTF7H
p4rK7PMMok8Yvjrxe/k8TRqRL6tw9+1cXRYhSBQg0TQGPTCEPh5nlWSgSOTKyHAe
ZAcpeUmLXvI0fLHiKAyxtI2nVPadWy+MFlJP4oJU1ml5+4ZUqDZ/DcC+qeHE8tSh
8oFdtG4/3REtb1e2x0LfeV45oj/MBv7X6IyWaw5vvjzLEiZHxuY8SRgMpgBzkNaC
y675orpcwNKFFkA5PdlxtGstDfzoUi70Gl8sNMNFt26w3+eX9+w/CxpgSIftHp6/
2cJRlgjfN6a2Eog9skq6XhGGoVZ1HHjq1mAtinKw9Wv0L88hd62PCzRu+ZVScGr8
MNK43VxbP2PCBMWY5z9uFlANBbgY4R4wPbKjZmH9NJW3yJDXHeKjCGfDrw3KX/5l
eIC+CbfEMuPHl02HY6TJwn0cDeEsRiyrLA+4aHrG1Vxy92L+4PPsQuJts6DzmGej
HNiyXvaSC88ovkOk2mgxtPx+dgI3qpmpMzJYqkpHg2Eo5zn12DpiubsZRHmR/1Fz
hrE4lwvV3W1DN4ztQs/Faa9zsRgPrhgEVKJMuqCwLSDeMovXCsY=
=kj7T
-END PGP SIGNATURE-

Bug#975397: RM: cantor-backend-scilab [armhf i386] -- ROM; no more built on some archs, as no more usable there

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove cantor-backend-scilab on armhf and i386, as it is no more
built on these architectures as result of #973703.

Thanks,
-- 
Pino

Bug#975396: node-webassemblyjs: known breakage should be documented in README.Debian

[Jonas Smedegaard]

Package: node-webassemblyjs
Version: 1.9.1+repack+~cs10.9.15-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Quoting Debian FTP Masters (2020-11-21 09:48:33)
> Changes:
>  node-webassemblyjs (1.9.1+repack+~cs10.9.15-1) unstable; urgency=medium
>  .
>* Team upload
>* No more embed wabt (source unavailable) and repack. This will break
>  @webassemblyjs/wasm-parser and wast-loader (Closes: #975360)

Thanks a lot for the swift fixing of those source-less wasm bugs.

When a package is known to deviate from upstream, as it seems from above 
changelog snippet is now the case for node-webassemblyjs, it is best to
mention it in README.Debian.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+42goACgkQLHwxRsGg
ASG/mRAAkmAGrcfxoLRfeMYkZyYMFsFoA04Il2noof6OvkHTL32KHjP6Zsmm2H6h
VbA7o5zrbezCsxKmrAUiBFMWaGFfqGmTFXVhdup3zZa4l0n+Fsq/0OeMkImZgfaN
wE7aCpxYGwMdkHPRmAgJphmRgG5T+kZGyEgonoGVuYU5HbjjIKLfK5k2nz7pCmPe
gl69GlSPPscqMBfrnjaWnps88+DqYBgb6ke8pmnenwHUgjb7XgZ/jMO48rSOW3Mc
rplaydX4LTyH0cGA9VapK7RXBteL9c2brNLM/u0fBygwtU5ZozuCYP2xJC2DbQgQ
i9cniafXP4ECJv5bxDVFgIhkQJHHufmzbcKEj/+SXnwVPvbv3xbAH67rZeACNXBN
wY9veX0EecoIcm9//neG7/rExZJcp2/WAy/eautRJB2wcREIUiIMYuaJcb8kciEN
SaHcLd84VbYkoHQeE8+ZZctBuLJ1gXi3bMtO9Uigfnq490Daxts8thFaDSDtCU/y
09ip8EEFFl95+20IPHtD2/Fp4XpKyuiReN+JLNXufeqYhs5V6b1n4HgBrs2EyJk0
W7l5XyyTWmWotZmLSWtXzRUucT6iJ+YNySD5mdk0g+hZE31sKYb0lmY7FZ29n2lJ
ExDL4HBtZ5wWfsF3SPERocFqmt0UcMnVdOo9bT8xwVqT2b6fm5s=
=p/xB
-END PGP SIGNATURE-

Bug#975395: anki: Fails with Python3.9 due to use of deprecated unescape() method

[Simon Ruderich]

Package: anki
Version: 2.1.15+dfsg-2
Severity: normal
Tags: patch

Hello,

since the update to python3.9 Anki fails with the following
exception when reviewing more complex HTML templates:

: 'HTMLParser' object has no attribute 'unescape'

The following patch fixes this issue for me:

--- /usr/share/anki/aqt/reviewer.py.orig2019-08-27 07:24:40.0 
+0200
+++ /usr/share/anki/aqt/reviewer.py 2020-11-21 16:49:53.517798570 +0100
@@ -353,13 +353,12 @@
 buf = buf.replace("", "")
 hadHR = len(buf) != origSize
 # munge correct value
-parser = html.parser.HTMLParser()
 cor = self.mw.col.media.strip(self.typeCorrect)
 cor = re.sub("(\n||)+", " ", cor)
 cor = stripHTML(cor)
 # ensure we don't chomp multiple whitespace
 cor = cor.replace(" ", "")
-cor = parser.unescape(cor)
+cor = html.parser.unescape(cor)
 cor = cor.replace("\xa0", " ")
 cor = cor.strip()
 given = self.typedAnswer

It looks like unescape() was never intended to be exposed via the
HTMLParser() object. But since Python 3.4 html.parser provides it
directly.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#975393: hexchat: Workaround

[Manuel Bilderbeek]

Package: hexchat
Version: 2.14.3-3+b2
Followup-For: Bug #975393

Same problem here. A workaround is to remove hexchat-python3, but that also
removes Python script support, of course.

Kind regards,
Manuel

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
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:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hexchat depends on:
ii  hexchat-common  2.14.3-3
ii  libc6   2.31-4
ii  libcanberra00.30-7
ii  libdbus-glib-1-20.110-5
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.2-1
ii  libgtk2.0-0 2.24.32-4
ii  libnotify4  0.7.9-1
ii  libpango-1.0-0  1.46.2-3
ii  libproxy1v5 0.4.15-14
ii  libssl1.1   1.1.1h-1
ii  libx11-62:1.6.12-1

Versions of packages hexchat recommends:
ii  hexchat-perl 2.14.3-3+b2
ii  hexchat-plugins  2.14.3-3+b2
pn  hexchat-python3  
ii  libglib2.0-bin   2.66.2-1

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- no debconf information

Bug#975394: fish: honor scripts in /etc/profile.d

[Patrice Duroux]

Package: fish
Version: 3.1.2-3
Severity: wishlist

Dear Maintainer,

Using fish as a login shell may leave apart some package provided env settings.
For instance snapd provides a SH script to extends $PATH (and other variables).

It should be possible by default or under comments (or notified in a
README.Debian or...) in the system-wide /etc/fish/config.fish to execute those
.sh scripts by running 'sh' command to get their effects at least for the ones
doing well their job.

May be this should be addressed to any virtual Debian SHELL team as it may not
concern only fish but also other shells! ;-)

Thanks,
Patrice



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fish depends on:
ii  bc  1.07.1-2+b2
ii  chromium [www-browser]  83.0.4103.116-3.1
ii  dpkg1.20.5
ii  firefox [www-browser]   83.0-1
ii  firefox-esr [www-browser]   78.5.0esr-1
ii  fish-common 3.1.2-3
ii  google-chrome-stable [www-browser]  87.0.4280.66-1
ii  libc6   2.31-4
ii  libpcre2-32-0   10.34-7
ii  libstdc++6  10.2.0-18
ii  libtinfo6   6.2+20201114-1
ii  lynx [www-browser]  2.9.0dev.6-1
ii  man-db  2.9.3-2
ii  python3 3.9.0-3
ii  python3-distutils   3.8.6-1
ii  vivaldi-stable [www-browser]3.4.2066.106-1

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#971515:

[Janos LENART]

Dear interested parties,

I would like to express my appreciation for everyone's valuable input; the
time and effort put into this matter. I doubt there is much left to be
added as both sides argued at length.

Speaking from a technological point of view, I want to restate that I also
do not like the current extreme vendoring situation (which plagues Go,
especially, but not only). In the particular case of Kubernetes though,
while it is not ideal, I still do not see a better way for now. I have
tried to carefully weigh this in March, and have reevaluated it again over
the past few months. After the TC decides I am planning carry on with the
work to make Kubernetes happen in Debian, in some form or another. For
example. at the moment it is quite some work to set up a workable cluster
(I have set up test clusters passing the integration tests with every
binary I have uploaded).

Speaking personally, as a DD since 2001, I have read copious amounts of
bickering on debian-private and debian-devel. So I was pretty sure that a
heated discussion is all but unavoidable. I was not looking forward to it,
but I wanted progress. I have attempted to convey this in README.Debian
too, but in retrospect those were not the most cooling words either, and I
am sorry for that (reworded in 1.19.4-2, linking to this bug). The amount
of personal insults I have received, both publicly and in private, is truly
alarming :-( Debian will blaze ahead with or without Kubernetes in stable
(or at all), it won't however work at all without people.

Thank you.

-- 
LÉNÁRT, János

Bug#975388: calibre no more usable

[Grand T]

Hello

I added python3.9

libpython3.9-minimal/testing,unstable,now 3.9.0-5 amd64  [installé, automatique]
libpython3.9-stdlib/testing,unstable,now 3.9.0-5 amd64  [installé, automatique]
libpython3.9/testing,unstable,now 3.9.0-5 amd64  [installé, automatique]
python3.9-minimal/testing,unstable,now 3.9.0-5 amd64  [installé]
python3.9/testing,unstable,now 3.9.0-5 amd64  [installé]

Managed the links

ls -alrt /usr/bin/python*
-rwxr-xr-x 1 root root 3672400 20 avril  2020 /usr/bin/python2.7
-rwxr-xr-x 1 root root 5233216 25 sept. 11:36 /usr/bin/python3.8
-rwxr-xr-x 1 root root 5483872 19 oct.  11:51 /usr/bin/python3.9
lrwxrwxrwx 1 root root  18 21 nov.  15:44 /usr/bin/python2 -> 
/usr/bin/python2.7
lrwxrwxrwx 1 root root  18 21 nov.  15:48 /usr/bin/python3 -> 
/usr/bin/python3.9




ls -alrt /etc/alternatives/python*
lrwxrwxrwx 1 root root 18 21 nov.  15:05 /etc/alternatives/python -> 
/usr/bin/python3.9
lrwxrwxrwx 1 root root 18 21 nov.  15:12 /etc/alternatives/python3 -> 
/usr/bin/python3.9


update-alternatives --display python
python - mode automatique
  link best version is /usr/bin/python3.9
 le lien pointe actuellement sur /usr/bin/python3.9
  link python is /usr/bin/python
/usr/bin/python2 - priorité 1
/usr/bin/python3 - priorité 2
/usr/bin/python3.9 - priorité 3

update-alternatives --display python3
python3 - mode automatique
  link best version is /usr/bin/python3.9
 le lien pointe actuellement sur /usr/bin/python3.9
  link python3 is /usr/bin/python3
/usr/bin/python3.9 - priorité 1

Reinstall calibre

apt install --reinstall calibre
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
0 mis à jour, 0 nouvellement installés, 1 réinstallés, 0 à enlever et 0 non mis 
à jour.
Il est nécessaire de prendre 24,5 Mo dans les archives.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Réception de :1 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 
calibre all 5.5.0+dfsg-1 [24,5 MB]
24,5 Mo réceptionnés en 32s (754 ko/s)
(Lecture de la base de données... 236556 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de .../calibre_5.5.0+dfsg-1_all.deb ...
Dépaquetage de calibre (5.5.0+dfsg-1) sur (5.5.0+dfsg-1) ...
Paramétrage de calibre (5.5.0+dfsg-1) ...
Traitement des actions différées (« triggers ») pour bamfdaemon (0.5.4-2) ...
Rebuilding /usr/share/applications/bamf-2.index...
Traitement des actions différées (« triggers ») pour desktop-file-utils 
(0.26-1) ...
Traitement des actions différées (« triggers ») pour hicolor-icon-theme 
(0.17-2) ...
Traitement des actions différées (« triggers ») pour gnome-menus (3.36.0-1) ...
Traitement des actions différées (« triggers ») pour man-db (2.9.3-2) ...
Traitement des actions différées (« triggers ») pour shared-mime-info (2.0-1) 
...
Traitement des actions différées (« triggers ») pour mailcap (3.67) ...






And that's it calibre is happy

Bug#975086: buster-pu: package dav4tbsync

[Adam D. Barratt]

On Sat, 2020-11-21 at 14:04 +0100, Mechtilde Stehmann wrote:
> I hope this is the file you missed.

Well, yes and no. That looks more like the diff between the current
package in unstable and what you're proposing to upload, whereas I was
more thinking of the diff between 1.21-1~deb10u1 and the proposed new
version.

Comparing the package from p-u against unstable gives us:

176 files changed, 7432 insertions(+), 2366 deletions(-)

of which a significant portion appears to be Google Javascript
libraries. I assume the new upstream version is needed specifically to
allow Thunderbird 78 compatibility, rather than simply adding the
manifest.json changes?

> and yes, the bug number in mind was is #975020

Thanks.

Regards,

Adam

Bug#975393: hexchat segfault on startup after +b2 build

[Holger Schröder]

Package: hexchat
Version: 2.14.3-3+b2
Severity: important

Dear Maintainer,

hexchat (2.14.3-3+b2) segfault on startup after +b2 build and terminate.


Nov 21 16:05:13 hsp1 kernel: hexchat[6113]: segfault at 10 ip 7f87df08a645
sp 7fff776ab468 error 4 in libpython3.9.so.1.0[7f87def55000+285000]
Nov 21 16:05:13 hsp1 kernel: Code: 48 8d 35 2e ae 19 00 48 8d 3d 5f b0 19 00 e8
92 47 04 00 66 90 48 8b 05 e1 b6 37 00 48 8b 90 38 02 00 00 48 8d b8 58 01 00
00 <48> 8b 4a 10 48 8d 71 40 e9 0e fe ff ff 66 66 2e 0f 1f 84 00 00 00

Cheers
Holger...



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hexchat depends on:
ii  hexchat-common  2.14.3-3
ii  libc6   2.31-4
ii  libcanberra00.30-7
ii  libdbus-glib-1-20.110-5
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.3-1
ii  libgtk2.0-0 2.24.32-4
ii  libnotify4  0.7.9-1
ii  libpango-1.0-0  1.46.2-3
ii  libproxy1v5 0.4.15-15
ii  libssl1.1   1.1.1h-1
ii  libx11-62:1.6.12-1

Versions of packages hexchat recommends:
ii  hexchat-perl 2.14.3-3+b2
ii  hexchat-plugins  2.14.3-3+b2
ii  hexchat-python3  2.14.3-3+b2
ii  libglib2.0-bin   2.66.3-1

Versions of packages hexchat suggests:
pn  hexchat-otr  
pn  unifont  

-- no debconf information

Bug#933948: Config value incorrectly parsed in init.d script

[Norbert Harrer]

I don't think it's systemd's fault. There is a sub-optimal sed regex in
most courier init.d scripts. Here is a scenario with courier-mta-ssl as
an example (though, it also happens to other parts like courier-imap-ssl):

Usually, the config file /etc/courier/esmtpd-ssl contains:

ESMTPDSSLSTART=YES

And everything works fine. However, when you save the config through the
admin webpage, it changes it to:

ESMTPDSSLSTART="YES"

This should be fine as well, since the shell command executed by the
admin page parses it just the same:

> /usr/sbin/esmtpd-ssl stop ; . /etc/courier/esmtpd-ssl ; test 
"$ESMTPDSSLSTART" != YES || /usr/sbin/esmtpd-ssl start


But in /etc/init.d/courier-mta-ssl it is parsed with sed:

DO_START=$(sed -ne 's/^ESMTPDSSLSTART=\([^[:space:]]*\)/\1/p' 
/etc/courier/esmtpd-ssl | tr "A-Z" "a-z")


Which leads to DO_START containing the value "yes" including the quotes.
Further down the line in /usr/lib/courier/init-d-script-courier this
causes the script to exit quietly, if DO_START is anything other then yes.
After replacing the line with:

DO_START=$(sed -ne 's/^ESMTPDSSLSTART=\W*\(\w\+\)\W*/\1/p' 
/etc/courier/esmtpd-ssl | tr "A-Z" "a-z")


"systemctl restart courier-mta-ssl" works again.


Note 1: The ugly thing is, that when you make the changes through the web
interface, everything continues to work fine, because it parses the
config files correctly during restart. Then some time later, when you
restart the machine or restart the service with systemctl, it doesn't
come up again with no hints at all in the log files. I also think it
happens when courier crashes, and systemd tries to restart the service.

Note 2: Another thing is curious: Not all courier services use the init.d
scripts, some have their own systemd config in /lib/systemd/system/
which bypass the init.d script:

> systemctl status `systemctl -t service | grep courier | awk '{ print 
$1; }'` | grep Loaded


   Loaded: loaded (/lib/systemd/system/courier-authdaemon.service; 
enabled; vendor preset: enabled)

   Loaded: loaded (/etc/init.d/courier-imap-ssl; generated)
   Loaded: loaded (/lib/systemd/system/courier-imap.service; enabled; 
vendor preset: enabled)

   Loaded: loaded (/etc/init.d/courier-msa; generated)
   Loaded: loaded (/etc/init.d/courier-mta-ssl; generated)
   Loaded: loaded (/etc/init.d/courier-pop-ssl; generated)
   Loaded: loaded (/lib/systemd/system/courier-pop.service; enabled; 
vendor preset: enabled)

   Loaded: loaded (/etc/init.d/courier; generated)
   Loaded: loaded (/etc/init.d/courierfilter; generated)

So only the services

  courier-imap-ssl
  courier-msa
  courier-mta-ssl
  courier-pop-ssl

are prone to this bug, which gives the whole thing an even more sporadic
character.

Regards,
Norbert

Bug#971408: simde: FTBFS when dpkg-buildflags passes -ffile-prefix-map

[Michael R. Crusoe]

On Sat, 03 Oct 2020 09:38:03 -0700 Vagrant Cascadian
 wrote:
> On 2020-09-29, Vagrant Cascadian wrote:
> > When run with DEB_BUILD_OPTIONS=reproducible=+fixfilepath, simde FTBFS:
> >
> > clang: error: unknown argument: '-ffile-prefix-map=/<>=.'
> >
> > This is because clang 10 is the first version to support
> > -ffile-prefix-map, and simde is building with the default clang version
> > 9.
> >
> > The attached patch updates to clang-10 to fix this issue.
>
> Though clang 11 might become the default for bullseye, in which case
> this would be a needless change; I haven't tested if simde builds fine
> with clang 11.

Thank you Vagrant for reporting this issue and your patch.

SIMDe is a header-only library, the compilation is just to test the
library against the default GCC & clang versions in Debian. I would
prefer to keep testing the default versions, to get ahead of any bugs
that might appear.

I guess testing for all versions of clang and gcc in Debian could be
done as part of the package building and autopkgtest.

So I'm leaning towards adding the other fix of disabling setting
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath+fixdebugpath

What do you think?

-- 
Michael R. Crusoe




signature.asc
Description: OpenPGP digital signature

Bug#975392: autopkgtest-virt-qemu assumes child qemu-system-* is quiet to stdout

[Ryutaroh Matsumoto]

Package: autopkgtest
Version: 5.15
Severity: important
Tags: patch
Control: block 926945 by -1
Control: block 973038 by -1

Dear Maintainer,

/usr/bin/autopkgtest-virt-qemu starts child qemu-system-*
by subprocess.Popen(argv).
This invocation implicitly assumes that child qemu-system-*
writes nothing to stdout, as the child shares its stdout with
autopkgtest-virt-qemu.

On the other hand, autopkgtest-virt-qemu communicates with
parent autopkgtest via stdout
When qemu-system-* writes "Welcome GRUB" or something similar
to stdout, autopkgtest receives "Welcome GRUB" as a message
from autopkgtest-virt-qemu. Nobody wants such communication!!

qemu-system-x86_64 or qemu-system-i386 does not write anything
to stdout. On the other hand, qemu-system-aarch64, qemu-system-arm,
and qemu-system-ppc64le write lots of "Welcome GRUB" and likes to
stdout, and autopkgtest gets really confused.
This is the reason why autopkgtest-virt-qemu fails with arm 
and ppc64el QEMU testbeds.

Just giving stdout=subprocess.DEVNULL and such to subprocess.Popen
solves this problem. The attached patch,
against "apt-get source autopkgtest",
does this modification.
I think autopkgtest-virt-qemu should set its child qemu-system-*'s
stdio to reasonable values.

Now we become able to use autopkgtest-virt-qemu for
arm64, armhf, armel, and ppc64el in additon to amd64 and i386!

Best regards, Ryutaroh Matsumoto


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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.11
ii  libdpkg-perl1.20.5
ii  procps  2:3.3.16-5
ii  python3 3.8.6-1
ii  python3-debian  0.1.38

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  2020.08-1
ii  qemu-efi-aarch64  2020.08-1
ii  qemu-efi-arm  2020.08-1
ii  qemu-system   1:5.1+dfsg-4+b1
ii  qemu-utils1:5.1+dfsg-4+b1
pn  schroot   
ii  vmdb2 0.19-1

-- no debconf information
--- autopkgtest-5.15/virt/autopkgtest-virt-qemu-5.152020-11-21 
23:10:54.688621286 +0900
+++ autopkgtest-5.15/virt/autopkgtest-virt-qemu 2020-11-21 23:13:30.243027411 
+0900
@@ -623,7 +623,7 @@
 if args.qemu_options:
 argv.extend(args.qemu_options.split())
 
-p_qemu = subprocess.Popen(argv)
+p_qemu = subprocess.Popen(argv, stdin=subprocess.DEVNULL, 
stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 
 try:
 try:

Bug#975391: RFS: zam-plugins/3.13~repack3-1 -- Collection of LV2

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zam-plugins":

* Package name : zam-plugins
Version : 3.13~repack3-1
Upstream Author : Damien Zammit
* URL : https://github.com/zamaudio/zam-plugins
* License : GPL-2+, LGPL-2.1+, ISC, LGPL, MIT/X11, CUSTOM, LGPL-2+
* Vcs : https://salsa.debian.org/multimedia-team/zam-plugins
Section : sound

It builds those binary packages:

zam-plugins - Collection of LV2, LADSPA, LINUX-VST and JACK plugins

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


https://mentors.debian.net/package/zam-plugins/

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

dget -x 
https://mentors.debian.net/debian/pool/main/z/zam-plugins/zam-plugins_3.13~repack3-1.dsc


Changes since the last upload:

zam-plugins (3.13~repack3-1) unstable; urgency=medium
.
[ Ondřej Nový ]
* d/copyright: Use https protocol in Format field
* d/control: Set Vcs-* to salsa.debian.org
* d/changelog: Remove trailing whitespaces
* Use debhelper-compat instead of debian/compat
.
[ Felipe Sateler ]
* Change maintainer address to debian-multime...@lists.debian.org
.
[ Olivier Humbert ]
* Update copyright (http -> https)
.
[ Dennis Braun ]
* New upstream version 3.13~repack3
+ Manually repacked with the current dpf submodule @ 08669d1
+ The lib dir is removed, we use zita-convolver4 from debian
* d/control:
+ Add me as uploader
+ Bump dh-compat to 13
+ Add libjack-jackd2-dev, libsamplerate0-dev & libzita-convolver-dev as B-D
+ Bump S-V to 4.5.1
+ Set RRR: no
+ Remove trailing whitespace
+ Add ZamVerb and ZamGrains to the description of the package
* d/copyright:
+ Add comment
+ Update copyright year
+ Add myself to the d/ section
+ Remove non-existent dpf/distrho/src/vestige/aeffectx.h
+ Update dpf/dgl/src/pugl entries
* Remove debian/source/local-options
* Remove patches, deprecated
* Clean d/rules & fix stripping
* Add d/upstream/metadata
* Bump d/watch to version 4
* Add d/zam-plugins.lintian-overrides

Regards,
Dennis

Bug#953129: ITP: dpf-plugins -- Audio plugin collection from DISTRHO

[Dennis Braun]

Fixed some issues, now i think its in a good shape and ready to upload:

https://mentors.debian.net/package/dpf-plugins/

Bug#916638: ITP : dragonfly-reverb - an audio reverb software

[Dennis Braun]

Fixed some issues, now i think its in a good shape and ready to upload:

https://mentors.debian.net/package/dragonfly-reverb/

Bug#975389: RFS: dpf-plugins/1.3+git8ae021b-1 [ITP] -- Audio plugin collection from DISTRHO (metapackage)

[Dennis Braun]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dpf-plugins":

* Package name : dpf-plugins
Version : 1.3+git8ae021b-1
Upstream Author : Filipe Coelho
* URL : https://github.com/falkTX/DPF-Plugins
* License : GPL-2+, LGPL-3+, LGPL-2.1+, ZLIB, ISC, MIT, bitstream-vera, 
GPL-3+

* Vcs : https://salsa.debian.org/multimedia-team/dpf-plugins
Section : sound

It builds those binary packages:

dpf-plugins-dssi - Audio plugin collection from DISTRHO (DSSI plugins)
dpf-plugins-vst - Audio plugin collection from DISTRHO (VST2 plugins)
dpf-plugins-lv2 - Audio plugin collection from DISTRHO (LV2 plugins)
dpf-plugins-ladspa - Audio plugin collection from DISTRHO (LADSPA plugins)
dpf-plugins-common - Audio plugin collection from DISTRHO (common files)
dpf-plugins - Audio plugin collection from DISTRHO (metapackage)

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


https://mentors.debian.net/package/dpf-plugins/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dpf-plugins/dpf-plugins_1.3+git8ae021b-1.dsc


Changes for the initial release:

dpf-plugins (1.3+git8ae021b-1) unstable; urgency=medium
..
* Initial debian release (Closes: #953129)
+ Merge with 1.3+git8ae021b-0ubuntu1 release
+ Use dh-compat instead of debian/compat and bump to 13
+ Change Maintainer to Debian Multimedia Maintainers
+ Remove XSBC-Original-Maintainer field, not needed for debian
+ Remove unused ${shlibs:Depends} from the dpf-plugins package
+ Add Vcs-Git & Vcs-Browser fields
+ Add myself as an uploader
+ Bump S-V to 4.5.1
+ Set RRR: no
+ Fix description of dpf-plugins-vst
+ Update the license texts for the *gpl* licenses in d/copyright
+ Fix misspellings of the path names in d/copyright
+ Add myself to the d/ section of d/copyright
+ Add lintian-overrides
+ d/rules: Add DEB_BUILD_MAINT_OPTIONS for hardening
+ d/rules: Fix stripping
+ Add d/upstream/metadata
+ Fix d/watch file

Regards,
Dennis

Bug#975390: RFS: dragonfly-reverb/3.2.1-1 [ITP] -- Reverb effect plugins (metapackage)

[Dennis Braun]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dragonfly-reverb":

* Package name : dragonfly-reverb
Version : 3.2.1-1
Upstream Author : Michael Willis and rghvdberg
* URL : https://michaelwillis.github.io/dragonfly-reverb/
* License : GPL-2+, OFL-1.1, ZLIB, ISC, Expat, MIT, bitstream-vera, 
GPL-3+, GPL-3

* Vcs : https://salsa.debian.org/multimedia-team/dragonfly-reverb
Section : sound

It builds those binary packages:

dragonfly-reverb-lv2 - Reverb effect plugins - LV2 plugins
dragonfly-reverb-vst - Reverb effect plugins - VST plugins
dragonfly-reverb-standalone - Reverb effect plugins - standalone 
applications

dragonfly-reverb - Reverb effect plugins (metapackage)

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


https://mentors.debian.net/package/dragonfly-reverb/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dragonfly-reverb/dragonfly-reverb_3.2.1-1.dsc


Changes for the initial release:

dragonfly-reverb (3.2.1-1) unstable; urgency=medium
.
[ Olivier Humbert ]
* Initial release. (Closes: #916638)
.
[ Ondřej Nový ]
* Use debhelper-compat instead of debian/compat
* d/control: Deprecating priority extra as per policy 4.0.1
* d/rules: Remove trailing whitespaces
.
[ Dennis Braun ]
* Merge debian files with ubuntu version 3.2.1-0ubuntu1
* d/control:
+ Sort B-Ds
+ Bump S-V to 4.5.1
+ Change Maintainer and add uploaders
+ Re-Add Vcs-Git and Vcs-Browser
+ Remove ${shlibs:Depends} from dragonfly-reverb Depends
* d/copyright: http > https, add myself to the d/ section and update year
* Update d/dragonfly-reverb-standalone.lintian-overrides
* d/rules:
+ Clean build flags
+ Add hardening
+ Fix stripping
+ Export DESTDIR and PREFIX
+ Use dh_auto_build instead of $(MAKE)
* Add d/upstream/metadata

Regards,
Dennis

Bug#975388: calibre no more usable

[GT]

Package: calibre
Version: 5.5.0+dfsg-1
Severity: important

Dear Maintainer,

I cant use calibre no more

~$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 509, in main
app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 122, in init_qt
app = Application(args, override_program_name=override,
windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 885, in __init__
from calibre_extensions import progress_indicator
ImportError: /usr/lib/calibre/calibre/plugins/progress_indicator.so: undefined
symbol: _Py_FatalErrorFunc

Version of python

root@debian:~# ls -alrt  /etc/alternatives/python*
lrwxrwxrwx 1 root root 16 16 sept. 22:08 /etc/alternatives/python ->
/usr/bin/python3
root@debian:~# ls -alrt /usr/bin/python3
lrwxrwxrwx 1 root root 9 13 oct.  21:25 /usr/bin/python3 -> python3.8




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

Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  5.5.0+dfsg-1+b1
ii  dpkg 1.20.5
ii  fonts-liberation 1:1.07.4-11
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  libjpeg-turbo-progs  1:2.0.5-1.1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils20.09.0-3
ii  python3  3.8.6-1
ii  python3-apsw 3.32.2-r1-1+b1
ii  python3-bs4  4.9.3-1
ii  python3-chardet  3.0.4-7
ii  python3-chm  0.8.6-2+b2
ii  python3-css-parser   1.0.4-2
ii  python3-cssselect1.1.0+ds-1
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-4
ii  python3-dbus 1.2.16-4
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b2
ii  python3-html5lib 1.1-2
ii  python3-lxml 4.6.1-1
ii  python3-markdown 3.3.3-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  0.6.2-1+b1
ii  python3-netifaces0.10.9-0.2+b2
ii  python3-pil  8.0.1-1
ii  python3-pkg-resources50.3.0-1
ii  python3-pygments 2.3.1+dfsg-4
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.1+dfsg-2+b2
ii  python3-pyqt5.qtsvg  5.15.1+dfsg-2+b2
ii  python3-pyqt5.qtwebengine5.15.1-1+b1
ii  python3-regex0.1.20200714-1+b1
ii  python3-routes   2.4.1-2
ii  python3-zeroconf 0.26.1-1
ii  xdg-utils1.1.3-2

Versions of packages calibre recommends:
pn  python3-dnspython  
ii  udisks22.9.1-2

Versions of packages calibre suggests:
ii  python3-openssl   19.1.0-2
pn  python3-unrardll  

-- no debconf information

Bug#975387: libspectre1: evince hangs with PS files, is there a need to rebuild it?

[Patrice Duroux]

Package: libspectre1
Version: 0.2.9-1
Severity: important

Dear Maintainer,

I am facing the exact situation reported here with evince:
https://bbs.archlinux.org/viewtopic.php?id=259223
and their solution was:
https://github.com/archlinux/svntogit-
packages/commits/packages/libspectre/trunk

Maybe libspectre should be rebuilt using 9.53.3~dfsg-5. No?

Thanks,
Patrice



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/12 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libspectre1 depends on:
ii  libc6   2.31-4
ii  libgs9  9.53.3~dfsg-5

libspectre1 recommends no packages.

libspectre1 suggests no packages.

-- no debconf information