Bug#970194: pmix FTBFS on armel/mipsel: No atomic primitives available

[John Paul Adrian Glaubitz]

Control: retitle -1 pmix FTBFS on armel/m68k/mipsel/sh4: No atomic primitives 
available

Hi Adrian!

This issue affects m68k and sh4 as well, so the architecture list should 
include them:

+ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mipsel sh4))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif

Thanks,
Adrian

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

Bug#970219: kernel boot messages are not longer reliably kept by default

[Scott Nanni]

package: systemd
version: 241-7~deb10u2
severity: important

Prior to adopting systemd we had a init.d script /etc/init.d/bootmisc.sh
which had run just before login and at the end of this script it had done a
dmesg > /var/log/dmesg preserving the boot time kernel messages.

As a long time supporter on IRC, I consider these messages to be critical
to providing support to our users. I had been frustrated by this no longer
being available and then I found journalctl -k and thought I'd found a
reliable solution.

However it has come to my attention in doing support tonight, that a user
said they only had two lines in the output of journalctl -k and I have
checked all my systems and found that I too had one that has been up 27
days and journalctl -k only had two lines in it. I have machines here that
have been up far longer and go all the way back to boot. Including machines
up over 90 days with more than 3G worth of logs where the machine I have
with this issue has only 38.2M of logs, only 11% of /run in use, and all
logs pass verification, yet I don't have my boot messages. All my machines
are using the default journald configs and do not have the persistent logs
dir.

My concern is that we find a way that all our users preserve these kernel
boot messages by default for support purposes so as volunteer supporters we
have a reliable method of checking these messages for issues. If journald
is supposed to address this, I now have two confirmed cases from one of my
machines and another supporter's machine where this is not the case. I
don't care if we just have a systemd oneshot unit that mimics the behavior
of bootmisc.sh and simply does dmesg > /var/log/dmesg at boot, but I feel
it is critical to providing good support that we make sure that these
messages are preserved.

If there is any more information I could provide, please let me know.

Bug#970198: src:openrocket: fails to migrate to testing for too long: Depends on openjdk-8 which is blocked from testing

[Bdale Garbee]

Paul Gevers  writes:

> Your package Depends on openjdk-8, which isn't supposed to be used in
> testing since beginning 2019.

FYI, this dependency will remain until/unless upstream makes a new
release, and is still present in the version in unstable.

Bdale


signature.asc
Description: PGP signature

Bug#970218: ITP: deepin-reader -- Document Viewer is a tool for reading document files, supporting PDF, DJVU, etc.

[tuqinggang]

Package:wnpp
Severity: wishlist
Owner: Tu Qinggang 
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name    :deepin-reader
  Version : 5.7.0.23
  Upstream Author : Deepin Technology Co, Ltd.
* URL : https://github.com/linuxdeepin/deepin-reader
  License : GPL-3.0
  Programming Lang: C++

Description: Document Viewer is a tool for reading document files, 
supporting PDF, DJVU, etc.
 Document Viewer is a small, fast and full-featured tool for viewing 
documents,

 supporting PDF and DJVU formats, multi-window and multi-tab management,
 thumbnail viewing, adding bookmarks and notes, magnifying, slide show,
 searching texts, rotation, etc.
.
 It is part of Deepin software and DDE (Deepin Desktop Environment)
.
 I intend to maintaining this.

Bug#970217: java-propose-classpath does not run as it does not find jcf-dump

[Pierre Gruet]

Package: java-propose-classpath
Version: 0.77
Severity: normal

Hello,

I launched java-propose-classpath on (for instance) the jar in the packages 
jebl2 and libdistlib-java.

The line

find: ‘jcf-dump’: No such file of directory

is printed several times and the program exits with no further input.

Thanks for your attention,
Pierre Gruet

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 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 java-propose-classpath depends on:
ii  fastjar 2:0.98-7
ii  javahelper  0.77

java-propose-classpath recommends no packages.

java-propose-classpath suggests no packages.

-- no debconf information

Bug#970216: RM: pygalmesh [armhf] -- ROM; insufficient memory for build

[Drew Parsons]

Package: ftp.debian.org
Severity: normal

The pygalmesh build has relatively high memory requirements.  This is
common with other packages using CGAL (e.g. mshr) and is related to the
provisioning of the CGAL package as header-only.  Consequently
pygalmsh does not build on all arches (the same is true of mshr).

Previously pygalmesh built on armhf.  Now with pygalmesh 0.7.1, it no
longer builds on armhf.  The error message is
  virtual memory exhausted: Cannot allocate memory

This now puts armhf in the same situation as mipsel, which has never
built pygalmesh. 

Memory requirements have already been reduced by compiling with -g0.
I don't think there is anything more we can reasonably do for armhf.

CGAL itself does not build on armel and several minor arches.  It's a
delicate package with strange memory requirements.

I think the best action is to just remove pygalmesh from armhf and
handle it as "never built", same as mipsel.  This will enable the
package to migrate to testing for the other arches.

I'm not certain, does it also need to be removed from testing, or will
it get removed from there automatically?

Bug#816406: mdadm mkconf doesn't parse mdadm.conf correctly(whitespace)

[Felix Lechner]

Hi Adam,

> /usr/share/mdadm/mkconf attempts to read DEVICE out of
> /etc/mdadm/mdadm.conf, using sed.  It does this, with a simple regex,
> "s/^DEVICE //p". This is not valid.

Doesn't mkconf merely transfer the value? I think the code works as
expected. It may not work for other whitespace, as you point out. For
multiple spaces, the field value is also not trimmed, but mkconf does
not run repeatedly. Either way, I do not think there is a need for
mkconf to parse the value the way you describe.

Do you have a problem as a result of the code, or are you making an
academic point? Thanks for helping to make mdadm better for everyone!

Kind regards
Felix Lechner

Bug#970215: otb-bin: programs fail with symbol lookup error

[Sebastiaan Couwenberg]

Control: block -1 by 957653

On 9/13/20 6:15 AM, Andrew Harvey wrote:
> /usr/bin/otbApplicationLauncherCommandLine: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libOTBApplicationEngine-7.1.so.1: undefined
> symbol:
> _ZN3itk9Directory16GetNumberOfFilesEv

Aka itk::Directory::GetNumberOfFiles().

otb may need to be rebuilt for recent changes in insighttoolkit4, but
for that it will first need to built successfully with gcc-10. (#957653)

otb is no longer in testing due to that, so don't expect it to work in
unstable either until that is resolved.

Kind Regards,

Bas

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

Bug#970106: This bug was marked pending but is not mentioned in Git

[Felix Lechner]

Hi Chris,

> Bug reopened

I usually indicate pending bugs with a commit message, which marks the
bug pending *and* generates a changelog message that closes the bug.

With new releases provided nearly weekly, I found that an acceptable
workflow (while we deal with large numbers of bugs) especially for
this one, which was fixed in Git  before being filed. Apparently, some
people disagree.

Perhaps you could also check your draft changelogs against pending
bugs before a release, if you do not already do so. Thanks!

Kind regards
Felix Lechner

Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME

[Richard Laager]

FWIW, this looks good to me. This is a new upstream release, but it's a
bug-fix only (adding a translation update at the same time seems fine).

Is there a particular reason this should NOT be uploaded?

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#970215: otb-bin: programs fail with symbol lookup error

[Andrew Harvey]

Package: otb-bin
Version: 7.1.0+dfsg-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

otbcli -h

   * What was the outcome of this action?

/usr/bin/otbApplicationLauncherCommandLine: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libOTBApplicationEngine-7.1.so.1: undefined
symbol:
_ZN3itk9Directory16GetNumberOfFilesEv

   * What outcome did you expect instead?

no error



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

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

Versions of packages otb-bin depends on:
ii  libc62.31-3
ii  libgcc-s110.2.0-7
ii  libinsighttoolkit4.134.13.3withdata-dfsg1-2
ii  libotb-apps  7.1.0+dfsg-1+b1
ii  libotbcommandline-7.1-1  7.1.0+dfsg-1+b1
ii  libotbcommon-7.1-1   7.1.0+dfsg-1+b1
ii  libstdc++6   10.2.0-7

otb-bin recommends no packages.

otb-bin suggests no packages.

-- no debconf information

Bug#970214: RFS: rednotebook/2.20+ds-1 [ITP] [Team] -- Modern desktop diary and personal journaling tool

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rednotebook":

 * Package name: rednotebook
   Version : 2.20+ds-1
   Upstream Author : Jendrik Seipp 
 * URL : https://rednotebook.app
 * License : LGPL-3+, GPL-3+, CC0-1.0, PSF-2, GPL-2+
 * Vcs : https://github.com/jendrikseipp/rednotebook
   Section : text

It builds those binary packages:

  rednotebook - Modern desktop diary and personal journaling tool

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.20+ds-1.dsc

Changes since the last upload:

 rednotebook (2.20+ds-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream version 2.20.
   * Reintroduction to debian - ITP. (Closes: #970204)

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#970207: libvirt: Couldn't create default storage pool '/var/lib/libvirt/images

[Phil Wyett]

On Sun, 2020-09-13 at 09:19 +1000, ElongatedYeet wrote:
> Source: libvirt
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>This error occured when trying to create a new VM with libvirt
>When creating a new VM, the error that is returned is "Error: --
> disk size=10: Couldn't create default storage pool
> '/var/lib/libvirt/images': Could not build storage pool: unable to
> control COW flag on '/var/lib/libvirt/images', not btrfs: Function not
> implemented
>This should not occur as I followed the KVM guide on the wiki.
> Virt-Manager also could not create a VM
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

Hi,

This issue seems to have been reported upstream and fixed in the latest
release. See link below.

https://gitlab.com/libvirt/libvirt/-/issues/73

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME

[Phil Wyett]

On Sun, 2020-07-26 at 04:55 +0100, Phil Wyett wrote:
> On Tue, 28 Apr 2020 03:54:59 +0100 Phil Wyett <
> philip.wy...@kathenas.org
> > wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "gnome-maps"
> > 
> >  * Package name: gnome-maps
> >Version : 3.30.3.1-0+deb10u1
> >Upstream Author : maps-l...@gnome.org
> >  * URL : https://wiki.gnome.org/Apps/Maps
> >  * License : GPL-2+
> >  * Vcs : https://salsa.debian.org/gnome-team/gnome-maps
> >Section : gnome
> > 
> > It builds those binary packages:
> > 
> >   gnome-maps - map application for GNOME
> > 
> > To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/gnome-maps
> > 
> > Alternatively, one can download the package with dget using this
> > command:
> > 
> >   dget -x 
> > 
> https://mentors.debian.net/debian/pool/main/g/gnome-maps/gnome-maps_3.30.3.1-0+deb10u1.dsc
> > Changes since the last upload:
> > 
> >* Non-maintainer upload
> >* New upstream release
> >  - Make the shape layer renderer use the tile size specified in
> the
> > dynamic
> >service file, fixing an issue with misaligned shape layer
> > (GeoJSON, GPX,
> >KML) rendering with the new 512 pixel tile
> >  - Update Icelandic translation
> > 
> > ===
> > 
> > Note: Package requires sponsor for stable updates upload.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947464
> > 
> > Regards
> > 
> > Phil
> > 
> 
> Hi all,
> 
> Bump. Anyone fancy sponsoring with a stable release imminent?
> 
> This RFS has been additionally mailed to the gtk-gnome list and the
> gnome maintainers with zero replies/interaction to date.
> 
> Regards
> 
> Phil
> 

Hi all,

Ping.

Can we have this uploaded for the upcoming 10.6? Still seen no love and
missed so many point releases now. Just need someone with permissions to
do it and a little time.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#970212: gdm3: XDMCP does not work with ShowLocalGreeter=true

[Ryutaroh Matsumoto]

Package: gdm3
Version: 3.37.90-2
Severity: important

Dear Maintainer,

[xdmcp]
Enable=true
ShowLocalGreeter=false

works almost fine. But with
ShowLocalGreeter=true

gdm3 does not show a login window to a remote X server,
even without touching keyboard nor mouse of the
computer running gdm3.

If the combination of ShowLocalGreeter=true and Enable=true
in [xdmcp], the Enable=true should also mean ShowLocalGreeter=false.

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.8.0-1-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 gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.36.0-1
ii  dconf-gsettings-backend   0.36.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.37.90-2
ii  gnome-session [x-session-manager] 3.37.0-2
ii  gnome-session-bin 3.37.0-2
ii  gnome-session-common  3.37.0-2
ii  gnome-settings-daemon 3.37.92-1
ii  gnome-shell   3.37.92-3
ii  gnome-terminal [x-terminal-emulator]  3.36.2-3
ii  gsettings-desktop-schemas 3.37.2-1
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3+b1
ii  libc6 2.31-3
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdm1   3.37.90-2
ii  libglib2.0-0  2.64.4-1
ii  libglib2.0-bin2.64.4-1
ii  libgtk-3-03.24.22-1
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd246.4-1
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.48.8+dfsg-1
ii  libselinux1   3.1-2
ii  libsystemd0   246.4-1
ii  libx11-6  2:1.6.10-3
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.36.5-1
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+20
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.36.1-1
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.8-2
ii  xserver-xorg1:7.7+20
ii  zenity  3.32.0-5

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
[security]
[xdmcp]
Enable=true
ShowLocalGreeter=true
[chooser]
[debug]


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#970203: xdg-screensaver: does not work on windows with no title or non-ASCII title

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.3-2ubuntu1
Severity: normal
Tags: patch

Here is the upstream bug and patch: 
https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/98

Owing to the glacial rate of xdg-maintenance currently (and with thanks to
those currently trying to speed the process up!) it would be great if this
patch could be applied for the moment in Debian. In particular, it stops
Caffeine from working properly when a full-screen window has no title or a
non-ASCII title. (I’m the Caffeine upstream maintainer.)

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=GNOME

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

Kernel: Linux 5.4.0-47-generic (SMP w/16 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 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.29-1
ii  libnet-dbus-perl   1.2.0-1
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#948771: #948771: guile-*: usrmerge variation for GREP, MKDIR_P, SED, etc.

[Vagrant Cascadian]

On 2020-03-09, Vagrant Cascadian wrote:
>> The attached patch sets SHELL, GREP, SED and MKDIR_P from configure,
>> otherwise the path varies depending on weather it was built on a
>> usrmerge system. e.g. /usr/bin/grep vs. /bin/grep. Since a /bin is a
>> symlink to /usr/bin on a usrmerge system, use the /bin location.

As mentioned on IRC, an arguably preferable option would be to not ship
/usr/share/doc/guile-3.0-dev/examples/Makefile.gz in the package at all,
instead shipping the relevent Makefile.am/Makefile.in files only, as the
generated Makefile contains embedded build-paths in addition to the
issues triggered by usrmerge, and would thus need to be regenerated on
the end-user's system anyways in order to be practically useful.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#970211: gdm3: XDMCP Authentication is required to create a color profile

[Ryutaroh Matsumoto]

Package: gdm3
Version: 3.37.90-2
Severity: minor

Dear Maintainer,

When gdm3 responds to an XDMCP query, it always displays
(at least the default installation with Debian installer weekly build of Sept. 
2020)
"Authentication Required
Authentication is required to create a color profile"

One can click "cancel" and both gdm3 and gnome session work fine.
This is a minor cosmetic problem, but the default installation can be
hopefully more friendly...

I do not see a similar message with LightDM XDMCP login...

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.8.0-1-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 gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.36.0-1
ii  dconf-gsettings-backend   0.36.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.37.90-2
ii  gnome-session [x-session-manager] 3.37.0-2
ii  gnome-session-bin 3.37.0-2
ii  gnome-session-common  3.37.0-2
ii  gnome-settings-daemon 3.37.92-1
ii  gnome-shell   3.37.92-3
ii  gnome-terminal [x-terminal-emulator]  3.36.2-3
ii  gsettings-desktop-schemas 3.37.2-1
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3+b1
ii  libc6 2.31-3
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdm1   3.37.90-2
ii  libglib2.0-0  2.64.4-1
ii  libglib2.0-bin2.64.4-1
ii  libgtk-3-03.24.22-1
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd246.4-1
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.48.8+dfsg-1
ii  libselinux1   3.1-2
ii  libsystemd0   246.4-1
ii  libx11-6  2:1.6.10-3
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.36.5-1
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+20
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.36.1-1
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.8-2
ii  xserver-xorg1:7.7+20
ii  zenity  3.32.0-5

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
[security]
[xdmcp]
Enable=true
ShowLocalGreeter=false
[chooser]
[debug]


-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#970210: forcemerge vs. pkgreport.cgi

[積丹尼 Dan Jacobson]

Package: bugs.debian.org

One would expect
forcemerge A B
to cause
pkgreport.cgi?package=X
to list A, not B.
I mean B gets A's version, etc.

OK maybe pkgreport.cgi always lists the lower numbered bug no matter
what.

Well https://www.debian.org/Bugs/server-control#forcemerge should
mention that.

> "B" == Debian Bug Tracking System  writes:
>> forcemerge 970076 968589
B> Bug #970076 [ppp] Update to work with systemd-resolved
B> Bug #968589 [ppp] PPP name resolver not restarted upon upgrade
B> Merged 968589 970076

OK but wasn't 970076 the master, 968589 the slave?
Why does https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=ppp now
only list the slave?
Yes, it is merged with the master but one would expect to see the
master there.

OK, now trying
> forcemerge 968589 970076
Bug #968589 [ppp] PPP name resolver not restarted upon upgrade
Bug #970076 [ppp] Update to work with systemd-resolved
Bug #970076 [ppp] Update to work with systemd-resolved
Merged 968589 970076

Didn't help.
Well all I can do at this point is
> retitle 968589 ppp needs to be updated to work with systemd-resolved

Bug#970122: lexgrog: NAME section: does not recognize the \[...] form for a "dash"

[Colin Watson]

Control: tag -1 fixed-upstream

On Fri, Sep 11, 2020 at 10:09:01PM +, Bjarni Ingi Gislason wrote:
> cweb (1) - (unknown subject)

Thanks; fixed for the next upstream release.

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=bccecbffb21a50048876cc7c3a3bb842d11cf5dc

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#970209: mhonarc: -conlen mbox parsing breaks on messages with last line starting with "From " (despite Content-Length)

[Guilhem Moulin]

Package: mhonarc
Version: 2.6.19-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

Consider the attached UUCP-style mbox, where for each message the
byte-length of its body is indicated with a Content-Length: header.
The ‘-conlen’ [0] flag is meant to make MHonArc read the correct body
length and remove the need for unescaping lines starting with “From: ”.
This works well except when it's the *last* line that starts with
“From: ”.

$ mhonarc -conlen -outdir /tmp/out - 
 Date:
.

Writing mail ...
Writing /tmp/out/maillist.html ...
Writing /tmp/out/threads.html ...
Writing database ...
3 new messages
3 total messages

$ grep X-Message-Id /tmp/out/msg*.html
/tmp/out/msg0.html:
/tmp/out/msg1.html:
/tmp/out/msg2.html:

That's because MHonArc slurps “bogus” lines after after the message with

# Slurp up bogus data if required (should I do this?)
while (!/$FROM/o && !eof($handle)) {
  $_ = <$handle>;
}

where $_ is initially set to the last body line…  (By that loop is
AFAICT required to read “\nFrom …\n”.)  The fix is use a post condition
instead:

$ mhonarc -conlen -outdir /tmp/out - 
/tmp/out/msg1.html:

Cheers,
-- 
Guilhem.

[0] https://www.mhonarc.org/MHonArc/doc/resources/conlen.html


test.mbox
Description: application/mbox
--- mhonarc-2.6.19/lib/mhamain.pl
+++ mhonarc-2.6.19/lib/mhamain.pl
@@ -1017,9 +1017,9 @@
 		}
 	}
 	# Slurp up bogus data if required (should I do this?)
-	while (!/$FROM/o && !eof($handle)) {
+	do {
 		$_ = <$handle>;
-	}
+	} while (!/$FROM/o && !eof($handle));
 
 	} else {# No content-length
 	while (<$handle>) {


signature.asc
Description: PGP signature

Bug#970208: mhonarc: -gzipfiles flag yields partially broken archives when the temporary filename ends with '_z'

[Guilhem Moulin]

Package: mhonarc
Version: 2.6.19-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

When ‘-gzipfiles’ [0] is set, MHonArc generates a temporary file on
which to call gzip(1) afterwards.  The template doesn't include a suffix
so there is no guaranty that the filename won't end with ‘.gz’, ‘-gz’,
‘.z’, ‘-z’ or ‘_z’ (ignoring case).  Stumbling upon such a filename is
not that seldom on large archive, and cause gzip(1) to fail with

already has .gz suffix -- unchanged

(Setting ‘-fasttempfiles’ doesn't appear to help.)  The fix is trivial:
call `gzip -f` instead in order to avoid the suffix sanity check.  (For
Debian `gzip -f` isn't a problem, but I'm not sure how common that flag
is on other systems.  In doubt one may want to dump the file into
`gzip`'s standard input instead.)

Cheers,
-- 
Guilhem.

[0] https://www.mhonarc.org/MHonArc/doc/resources/gzipfiles.html
--- a/mhonarc-2.6.19/lib/mhfile.pl	2010-12-31 22:20:41.0 +0100
+++ b/mhonarc-2.6.19/lib/mhfile.pl	2020-09-13 00:52:32.677416587 +0200
@@ -98,7 +98,7 @@
 sub file_gzip {
 my $file = shift;
 return  if ($file =~ /\.gz$/i);
-if (system($GzipExe, $file) != 0) {
+if (system($GzipExe, '-f', '--', $file) != 0) {
 	die qq/ERROR: Failed to exec "$GzipExe $file": $! $?\n/;
 }
 }


signature.asc
Description: PGP signature

Bug#970207: libvirt: Couldn't create default storage pool '/var/lib/libvirt/images

[ElongatedYeet]

Source: libvirt
Severity: important

Dear Maintainer,

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

   This error occured when trying to create a new VM with libvirt
   When creating a new VM, the error that is returned is "Error: --disk 
size=10: Couldn't create default storage pool '/var/lib/libvirt/images': Could 
not build storage pool: unable to control COW flag on 
'/var/lib/libvirt/images', not btrfs: Function not implemented
   This should not occur as I followed the KVM guide on the wiki. Virt-Manager 
also could not create a VM

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


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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970206: "pylint doclifter" produces a lot of warnings

[Bjarni Ingi Gislason]

Package: doclifter
Version: 2.19-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  Issuing "doclifter groff_diff.7", which produced a few lines on
standard error.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

  Running "pylint /usr/bin/doclifter"

   * What was the outcome of this action?

  A lot of warnings, issues.


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

Kernel: Linux 5.7.17-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages doclifter depends on:
ii  python3  3.8.2-3

Versions of packages doclifter recommends:
ii  groff-base  1.22.4-5
pn  plotutils   

doclifter suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#834016: ddd: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

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

Bug#776938: sendfile: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

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

Bug#777185: cli-common-dev: please make the debhelper script additions reproducible

[Chris Lamb]

Dear Maintainer,

> Source: cli-common
> Version: 0.8.2
> Tags: patch

There hasn't seem to be any update on this bug in 1283 days, in which
time the Reproducible Builds effort has come on a long way.

Would you consider applying this patch and uploading?


Regards,

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

Bug#777413: mailto: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

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

Bug#838713: python-xlib: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

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

Bug#970205: pmix: Please avoid pandoc in Build-Depends for arch:any

[John Paul Adrian Glaubitz]

Source: pmix
Severity: important
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

pmix currently has pandoc in Build-Depends which causes the package to
be BD-Uninstallable on a number of architectures.

The reason for this is that pandoc requires a very long list of Haskell
dependencies before it can be built which means that a package that
Build-Depends on pandoc will end up very late in the build queue when
bootstrapping on a new architecture.

Since pmix is apparently required for openmpi and openmpi is used by many
other packages, it would be nice if src:pmix could be modified such that
pandoc is used for Build-Depends-Indep only, i.e. only for building the
arch:all packages which makes more sense anyway since pandoc generates
documentation which is usually architecture-independent.

Could you modify src:pmix such that pandoc is not required for binary-arch
builds?

Thanks,
Adrian

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

Bug#970204: ITP: rednotebook -- Modern desktop diary and personal journaling tool.

[Phil Wyett]

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

* Package name: rednotebook
  Version : 2.20+ds-1
  Upstream Author : Jendrik Seipp 
* URL : https://github.com/jendrikseipp/rednotebook
* License : GPL-2+
  Programming Lang: Python
  Description : Modern desktop diary and personal journaling
tool.  

It lets you format, tag and search your entries. You can also add
pictures, links and customisable templates, spell check your notes, and
export to plain text, HTML, LaTeX or PDF.

Additional notes:

A return of the package to debian.

I shall maintain this package.

Package will need salsa repo and appropriate permissions creating.

RFS to follow.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#970201: vcs-field-not-canonical explanation mildly confusing

[Russ Allbery]

Russ Allbery  writes:

> I had a package with control fields:

> Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
> Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl

Argh, sorry, that should have been:

Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl
Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl

Important to cut and paste *before* I fixed the issue, not afterwards.

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

Bug#970202: ITP: forensics-samples -- Set of useful files to help to learn or test forensics tools and techniques

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: forensics-samples
  Version : 1.0
  Upstream Author : Joao Eriberto Mota Filho 
* URL : https://github.com/eribertomota/forensics-samples
* License : MIT and CC-BY-SA-4.0
  Description : Set of useful files to help to learn or test forensics 
tools and techniques

 forensics-samples is a set of useful files to help to learn or test forensics
 tools and techniques. These files are examples of pictures, filesystems and
 other possible artifacts as memory dumps (not available yet).

 forensics-samples is useful for students and CI tests. The main intent of this
 work is provide a standardized set of files to avoid time waste in some tasks
 when learning about forensics or testing tools.

 There are some filesystem images available (currently: ext2, ext4, btrfs,
 NTFS, FAT2 (vfat) and extFAT). Inside each filesystem image, all files from
 "original-files" directory were copied and, after this, all directories ending
 with "2" in their names were deleted. Is possible use tools to analyse the
 files and their metadata or carvers to recover deleted files.

 On Debian, forensics-samples also is useful to provide files to be used by
 other packages in CI tests (autopkgtest), making several source-packages
 smallest (e.g.: metacam, ext4magic, foremost, magicrescue, scrounge-ntfs,
 etc). All you need is use it as a dependency for your test in
 debian/tests/control file.

Bug#970201: vcs-field-not-canonical explanation mildly confusing

[Russ Allbery]

Package: lintian
Version: 2.94.0
Severity: minor

I had a package with control fields:

Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl

This produces the following Lintian diagnosis:

I: libpgp-sign-perl source: vcs-field-not-canonical 
https://salsa.debian.org/rra/libpgp-sign-perl 
https://salsa.debian.org/rra/libpgp-sign-perl.git
N:
I: vcs-field-not-canonical
N:
N:   The VCS-* field contains an uncanonical URI. Please update to use the
N:   current canonical URI instead. This reduces the network bandwidth used
N:   and makes debcheckout work independent of the port forwarding and
N:   redirections properly working.
N:   
N:   The definition of canonical used here is the URIs announced by the
N:   Alioth admins (see reference).
N:   
N:   Note that this check is based on a list of known URIs. Lintian did not
N:   send an HTTP request to the URI to test this.
N:   
N:   Refer to
N:   https://lists.debian.org/debian-devel-announce/2011/05/msg9.html
N:   for details.
N:   
N:   Severity: info
N:   
N:   Check: fields/vcs

There are a couple of things that make this mildly confusing:

1. The tag information doesn't indicate a line number or field name, so it's
   not immediately apparent whether it refers to Vcs-Git or Vcs-Browser.
   (I know it refers to Vcs-Git, but that's because I have information that
   not everyone may have.)

2. The second and fourth paragraphs of the long tag description appear to be
   unrelated to the specific problem Lintian is diagnosing in this case.  I
   think they may be left over from the original purpose of this tag, which
   was for Alioth hosting.  In particular, following the instructions in that
   email message will now lead one astray for Salsa as I understand it.

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

Kernel: Linux 5.8.0-1-amd64 (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)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35-3
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch

Bug#777170: Similar problem solved - turn power management off

[Michal Zarnay]

Hello,

I have had similar issue in Kubuntu 20.04, laptop HP Probook 4340s. Not 
so many CTRL-EVENT-SIGNAL-CHANGE messages, but regular disconnection 
from wi-fi a few minutes after system start followed by an endless loop 
of connecting and disconnecting to/from the wi-fi. This rendered the 
wi-fi connection useless and the only solution had been a system 
restart. In addition, the problem had been occurring on some wi-fi-s only!


What seems to have solved my problem is the advice in
https://ubuntuforums.org/showthread.php?t=2011191
namely setting power management to off permanently by:
/ . gksudo gedit /etc/pm/power.d/wireless/
(this will create or edit a configuration file that will override the 
default power management behavior) and

 . enter the following:
/#!/bin/sh //
///sbin/iwconfig wlan0 power off //
/above /exit0/,
(in my case the file was new, i.e. empty)
 . then save gedit, close and reboot.

So far, no more problems.

Good luck!
Michal

Bug#970200: ITP: rednotebook -- Modern desktop diary and personal journaling tool.

[Phil Wyett]

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

* Package name: rednotebook
  Version : 2.20+ds-1
  Upstream Author : Jendrik Seipp 
* URL : https://github.com/jendrikseipp/rednotebook
* License : GPL-2+
  Programming Lang: Python
  Description : Modern desktop diary and personal journaling tool.  
It lets you format, tag and search your entries. You can also add
pictures, links and customisable templates, spell check your notes, and
export to plain text, HTML, LaTeX or PDF.

Additional notes:

A return of the package to debian.

I shall maintain this package.

Package will need salsa repo and appropriate permissions creating.

RFS to follow.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#970199: glibc: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: glibc
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#970198: src:openrocket: fails to migrate to testing for too long: Depends on openjdk-8 which is blocked from testing

[Paul Gevers]

Source: openrocket
Version: 15.03.5
Severity: serious
Control: close -1 15.03.6
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 929650

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:openrocket in
its current version in unstable has been trying to migrate for 60 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.

Your package Depends on openjdk-8, which isn't supposed to be used in
testing since beginning 2019.

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.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#957388: jeex: diff for NMU version 12.0.4-1.1

[Sudip Mukherjee]

Control: tags 957388 + patch
Control: tags 957388 + pending
--

Dear maintainer,

I've prepared an NMU for jeex (versioned as 12.0.4-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru jeex-12.0.4/debian/changelog jeex-12.0.4/debian/changelog
--- jeex-12.0.4/debian/changelog2012-04-08 08:25:55.0 +0100
+++ jeex-12.0.4/debian/changelog2020-09-12 20:34:22.0 +0100
@@ -1,3 +1,10 @@
+jeex (12.0.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957388)
+
+ -- Sudip Mukherjee   Sat, 12 Sep 2020 20:34:22 
+0100
+
 jeex (12.0.4-1) unstable; urgency=low
 
   * New upstream version
diff -Nru jeex-12.0.4/debian/patches/gcc-10.patch 
jeex-12.0.4/debian/patches/gcc-10.patch
--- jeex-12.0.4/debian/patches/gcc-10.patch 1970-01-01 01:00:00.0 
+0100
+++ jeex-12.0.4/debian/patches/gcc-10.patch 2020-09-12 20:32:35.0 
+0100
@@ -0,0 +1,88 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957388
+Forwarded: no
+
+---
+
+--- jeex-12.0.4.orig/src/header.h
 jeex-12.0.4/src/header.h
+@@ -167,7 +167,8 @@ struct info_byte
+   GtkWidget *l_binary, *e_binary;
+   GtkWidget *l_octal, *e_octal;
+   GtkWidget *l_hex, *e_hex;
+-} byte_info;
++};
++extern struct info_byte byte_info;
+ 
+ /* Structure for textview manage */
+ typedef struct info_textview
+@@ -182,11 +183,11 @@ typedef struct info_textview
+   GtkWidget *textview;
+ } textview_info;
+ 
+-textview_info *textview;
++extern textview_info *textview;
+ 
+ /* These widget are used in the main window. */
+-GtkWidget *bar, *viewport, *table_info;
+-GtkStatusIcon *sysicon;
++extern GtkWidget *bar, *viewport, *table_info;
++extern GtkStatusIcon *sysicon;
+ 
+ /* Structure for autocompletion manage */
+ struct _ac
+@@ -197,7 +198,8 @@ struct _ac
+ gboolean (*string_exist) (char *);
+   void (*add_string) (char *);
+   int (*strcasecmp) (gconstpointer a, gconstpointer b);
+-} *ac;
++};
++extern struct _ac *ac;
+ 
+ typedef struct _jeex_types {
+   GtkWidget *main_window;
+--- jeex-12.0.4.orig/src/main.c
 jeex-12.0.4/src/main.c
+@@ -33,6 +33,10 @@ GtkWidget *jeex_main_window;
+ gboolean support_opacity = TRUE;
+ JeexToolbar *jeex_toolbar;
+ JeexTypes *jeex_types;
++struct jeex_notebook *notebook;
++struct info_byte byte_info;
++textview_info *textview;
++struct _ac *ac;
+ 
+ static void *make_toolbar (GtkWidget *);
+ static void *make_bytes_info_field (void);
+@@ -52,7 +56,6 @@ main (int argc, char **argv)
+   extern JeexFileInfo *file[64];
+   extern JeexFileRecent *recent_file;
+   extern JeexMenu *jeex_menu;
+-  extern struct jeex_notebook *notebook;
+   extern JeexLog *jeex_log;
+   GtkWidget *table, *menu_bar, *widget, *hbox_panel;
+   gboolean chk = FALSE, opt_chk = TRUE;
+--- jeex-12.0.4.orig/src/notebook-manage.h
 jeex-12.0.4/src/notebook-manage.h
+@@ -37,7 +37,7 @@ struct jeex_notebook
+   int current;
+ };
+ 
+-struct jeex_notebook *notebook;
++extern struct jeex_notebook *notebook;
+ 
+ 
+ /* make_new_notebook_page ()
+--- jeex-12.0.4.orig/src/view.c
 jeex-12.0.4/src/view.c
+@@ -31,6 +31,8 @@
+ #include 
+ #include "header.h"
+ 
++GtkWidget *bar, *viewport, *table_info;
++GtkStatusIcon *sysicon;
+ 
+ /* Function for alternating cell color  */
+ static void
diff -Nru jeex-12.0.4/debian/patches/series jeex-12.0.4/debian/patches/series
--- jeex-12.0.4/debian/patches/series   2012-04-08 08:25:55.0 +0100
+++ jeex-12.0.4/debian/patches/series   2020-09-12 20:23:02.0 +0100
@@ -1 +1,2 @@
 00-fix_Makefile.patch
+gcc-10.patch

Bug#970196: iceweasel: tons of “Sandbox: unsupported fd-relative fstatat” warnings

[Thorsten Glaser]

Package: iceweasel
Version: 68.12.0esr-1~deb9u1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

After upgrading to version 78, after starting iceweasel and
exiting it, I have tons of these messages on the terminal:

[…]
96 4096 1.
Sandbox: unsupported fd-relative fstatat(33, "", 0x7FFC07F20D60, 4096)
Sandbox: seccomp sandbox violation: pid 15267, tid 15267, syscall 262, args 33 
140426714714878 140720441789792 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(37, "", 0x7FFC07F208B0, 4096)
Sandbox: seccomp sandbox violation: pid 15267, tid 15267, syscall 262, args 37 
140426714714878 140720441788592 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D800, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085060608 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D700, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085060352 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D760, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085060448 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D660, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085060192 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525CFE0, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085058528 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D040, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085058624 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(32, "", 0x7FFF3525D2B0, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 32 
140524853535486 140734085059248 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(56, "", 0x7FFD13BB34B0, 4096)
Sandbox: seccomp sandbox violation: pid 15219, tid 15219, syscall 262, args 56 
140121447920382 140724934489264 4096 4096 1.
Sandbox: unsupported fd-relative fstatat(39, "", 0x7FFF3525D080, 4096)
Sandbox: seccomp sandbox violation: pid 15295, tid 15295, syscall 262, args 39 
140524853535486 140734085058688 4096 4096 1.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages iceweasel depends on:
ii  feistermops450 [firefox-esr]  45.9.0m2
ii  firefox-esr   78.2.0esr-1

iceweasel recommends no packages.

iceweasel suggests no packages.

-- no debconf information

Bug#970197: src:giac: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: giac
Version: 1.5.0.87+dfsg1-7
Severity: serious
Control: close -1 1.6.0.7+dfsg1-2
Tags: sid bullseye
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:giac 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.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#970195: src:xcscope-el: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Source: xcscope-el
Version: 1.4-1
Severity: serious
Control: close -1 1.5-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:xcscope-el 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=xcscope-el




signature.asc
Description: OpenPGP digital signature

Bug#969834: Bug#969819: dmidecode: autopkgtest should be marked superficial

[Paul Gevers]

Control: severity -1 serious

Hi Jörg,

> On Wed, Sep 9, 2020 at 11:08 AM Jörg Frings-Fürst  wrote:
>> you write "should be marked". Should be is IMHO not serious.

Notwithstanding the wording, the Release Team is happy with the bugs
that Sudip is filing. Because of the way that autopkgtests are used in
the Debian infrastructure to influence migration from unstable to
testing [1], it is very important that autopkgtests are recognized for
what they are. If an autopkgtest isn't really testing the installed
binaries (and yes, the boundary is unfortunately not well defined) it's
crucial that the test is marked as superficial, conform our rc_policy
[2]. The Release Team has decided that the examples that Sudip tagged,
i.e. --version, --help, checking for some installed file and the Python
import check, are superficial.

Paul

[1] reduced age for packages with successful non-trivial autopkgtests
and (since bullseye) packages with non-trivial autopkgtests are allowed
to migrate in a later stage of the freeze than other packages:
https://release.debian.org/bullseye/freeze_policy.html
[2] https://release.debian.org/bullseye/rc_policy.txt



signature.asc
Description: OpenPGP digital signature

Bug#960863: Help needed with perl-tk NMU

[Damyan Ivanov]

-=| Damyan Ivanov, 11.09.2020 12:08:04 +0300 |=-
> I tried the "new upstream release" route because otherwise there 
> would be several patches to import, one of them adding 10k-lines 
> ppport.h
> 
> The result is at https://salsa.debian.org/dmn/perl-tk and builds with 
> per 5.32. There are many lintian/hardening warnings, but since this is 
> a NMU, the changes are bare minimum.
> 
> I haven't tested the resulting package yet, will have to find a way 
> to do so without disturbing the rest of the system. (perhaps 
> docker+vnc would help).

I got around to try this and the results seem acceptable to me.

All the examples seemed OK.

I tried two packages that depend on perl-tk: nama and mapivi.

nama seemed OK to me - no crashes, some windows appeared with menus 
buttons etc.

mapivi worked OK as long as no unicode was involved. It is a JPEG 
viewer with a file browser and unicode directory names are shown as 
latin1 garbage. When trying to open such a directory it complains on 
the console with 'Cannot cd to /path/to/spëcial: No such file or 
directory at /usr/lib/x86_64-linux-gnu/perl5/5.32/Tk/DirTree.pm'. This 
problem is also present in the version in unstable so it is not 
a regression.

Please tell me if there is another test I should perform.

Would uploading to delayed-7 in a week or so be in line with the plans 
for the arrival of 5.32 to unstable?


Cheers,
dam

Bug#540782: Please provide dwarf2-eh version of mingw-i686

[Stephen Kitt]

Hi Ximin,

On Sun, 9 Aug 2020 03:08:39 +0100, Ximin Luo  wrote:
> I am the maintainer of rustc in Debian. I am trying to provide
> cross-compiling libraries for windows. I have 64-bit working fine, however
> 32-bit is not working because rustc expects dw2 exceptions but Debian's
> mingw only provides sjlj.
> 
> I therefore request the maintainer to provide the dw2 version.
> 
> There were previously arguments saying this would be confusing for users;
> however I note that we *already* provide two mingw toolchains - one for the
> pthreads threading model, and one for the win32 threading model.
> Incidentally, rustc requires the latter.
> 
> I am not suggesting that we provide 4 toolchains, only 3, the 3rd one being
> win32+dw2. We could call it gcc-mingw-w64-i686-win32+dw2 for example.

The problem with providing another toolchain is that the ABI is rather
different between SJLJ and Dw2, so we’d end up having two toolchains claiming
to target *-w64-mingw32 but producing incompatible artifacts. Technically
POSIX and Win32 threads are in a similar situation, but in practice it
doesn’t cause problems as far as I’m aware; SJLJ/Dw2 are more likely to.

I’ve spent some time looking into this and I can’t really think of a sensible
workaround.

> For other context, Fedora in fact recently switched from sjlj to dw2,
> ditching the former completely, largely because of rust:
> 
> https://fedoraproject.org/wiki/Changes/Mingw32GccDwarf2

This, along with the long-standing MSYS2 switch, make me more inclined to
follow suit and drop SJLJ in favour of Dwarf2, for Bullseye.

I’m not sure how to reach all the users of the MinGW-w64 toolchain in Debian,
feel free to point people to this bug...

Regards,

Stephen


pgpbDAzRpTjon.pgp
Description: OpenPGP digital signature

Bug#970194: pmix FTBFS on armel/mipsel: No atomic primitives available

[Adrian Bunk]

Source: pmix
Version: 3.2.0~rc1-1
Severity: serious
Tags: ftbfs patch

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

...
configure: error: No atomic primitives available for arm-unknown-linux-gnueabi


Fix:

--- debian/rules.old2020-09-12 18:52:20.106150933 +
+++ debian/rules2020-09-12 18:52:31.126056610 +
@@ -2,6 +2,10 @@
 
 export DH_VERBOSE=1
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel mipsel))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 

Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).

[Nick Strauss]

Hi Hilmar,

> Not sure, why you name it -3. Normally one bumps the Debian revision
> only if the the previous revision has been uploaded to Debian.

My repo won't let me replace, so I needed to increment. At least, that's my 
understanding.

> now to apply the patch and build? what next?
> 
> Now that the package is probably lintian clean you may again ask for a
> sponsor. I'm not a DD, I can't help here.

Can I keep this same bug number 969446 or should I open a new bug report?

Thanks!

nick strauss
https://www.nick-strauss.com





On Saturday, September 12, 2020, 03:45:29 AM CDT, Hilmar Preuße 
 wrote: 






Am 12.09.2020 um 05:24 teilte Nick Strauss mit:

Hi,

>> The tar ball I provided contains a patch, which changes this to "/usr".
> 
> I have added your changes to my repo as vguitar_2.6-3
> 
Not sure, why you name it -3. Normally one bumps the Debian revision
only if the the previous revision has been uploaded to Debian.

> can be accessed as
> 
> now to apply the patch and build? what next?
> 
Now that the package is probably lintian clean you may again ask for a
sponsor. I'm not a DD, I can't help here.


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

Bug#970193: openmpi: build dependency on libpmix-dev should be (>> 3.2.0~rc1-1~)

[Adrian Bunk]

Source: openmpi
Version: 4.0.5-3
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=openmpi=4.0.5-3

The FTBFS are due to older pmix on some architectures.

Bug#970192: ITP: clark -- accurate and versatile classification of biological sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: clark -- accurate and versatile classification of biological 
sequences
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: clark
  Version : 1.2.6.1
  Upstream Author : Rachid Ounit 
* URL : http://clark.cs.ucr.edu/
* License : GPL-3.0+
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : accurate and versatile classification of biological 
sequences
 The problem of DNA sequence classification is central to several
 application domains in molecular biology, genomics, metagenomics and
 genetics. Although several software tools have been developed for this
 problem, it is still computationally challenging due to the size of
 datasets generated by modern sequencing instruments and the growing
 size of reference sequence databases.
 .
 CLARK is based on a supervised sequence classification using
 discriminative k-mers. Considering two distinct specific classification
 problems (see the article for details), namely (1) the taxonomic
 classification of metagenomic reads to known bacterial genomes,
 and (2) the assignment of BAC clones and transcript to chromosome
 arms/centromeres (in the absence of a finished assembly for the reference
 genome), CLARK aspires to outperforms in classification speed and
 precision the best state-of-the-art methods.
 .
 Three classifiers from the CLARK framework are provided:
 .
  * CLARK (default): created for powerful workstation, it can require
a significant amount of RAM to run with large database (e.g., all
bacterial genomes from NCBI/RefSeq). This classifier is the standard
in the CLARK tool series. It builds discriminative k-mers from all
k-mers in the targets, queries k-mers with exact matching, and, in
its fastest mode, classifies 1 million short reads in few seconds...;
  * CLARK-l : created for workstations with limited memory (i.e., "l"
for light), this software tool provides precise classification on
small metagenomes. Indeed, for metagenomics analysis, CLARK-l works
with a sparse or ''light'' database (up to 4 GB of RAM) while still
performing ultra accurate and fast results. This classifier builds
discriminative k-mers from non-overlapping and distant k-mers in the
targets and queries k-mers with exact matching;
  * CLARK-S: created for powerful workstations and exploiting spaced
k-mers (i.e., "S" for spaced), this classifier requires a higher RAM
usage than CLARK or CLARK-l, but it does offer a higher sensitivity
than CLARK at the species level (see the peer-reviewed publication in
Bioinformatics). CLARK-S completes the series of classifiers from the
CLARK framework.
 .
 Other applications of CLARK are, for example, the detection of
 contaminants, the identification of chimerism and vector contamination
 in sequenced BACs (cf. "Overview" tab).

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/clark

Bug#968042: upgrading packet python2 from 2.7.17-2 up to 2.7.18-2 asks packets deletion

[Diederik de Haas]

On Fri, 07 Aug 2020 18:11:20 +0300 Vladmimir Stavrinov  
wrote:
> Now there are no problems with python2 but dependencies are still broken for 
> python itself:

It's now a month later and this problem still exists (on my Debian Sid 
system).
Are the following packages supposed to be deleted from the system?
python python-minimal libpython-stdlib

I'd still have the python2 variants of those packages installed btw.

Bug#970156: systemd.socket fails with Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected

[Michael Biebl]

Am 12.09.20 um 13:33 schrieb Wolfgang Walter:
> Package: systemd
> Version: 246.4-1
> Severity: important
> 
> Since upgrading (to 246 think) our socket services terminate sometimes every 
> hour with:
> 
> "Failed to queue service startup job (Maybe the service file is missing or 
> not 
> a template unit?): Transport endpoint is not connected"
> 
> I think this is this bug:
> 
> https://www.spinics.net/lists/systemd-devel/msg04761.html
> https://www.spinics.net/lists/systemd-devel/msg04784.html
> 
> So commit 86e045ecefc404d4fccbeb78aa212ec4714a5763 should fix this.
> 
> Would it be possible to include this fix into debian's systemd?

Sure. Would you be willing to confirm that this commit fixes your issue?




signature.asc
Description: OpenPGP digital signature

Bug#970191: bookworm: Python3 syntax errors at configure step

[Julien Rabier]

Package: bookworm
Version: 1.1.2+git20200823-1
Severity: normal
Tags: upstream

Hi,

When at configure step, an error occurs:

> Setting up bookworm (1.1.2+git20200823-1) ...
>  File 
> "/usr/share/com.github.babluboy.bookworm/scripts/mobi_lib/mobiml2xhtml.py", 
> line 249
>print " - fixed by injecting empty start tag ", tname
>  ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(" 
> - fixed by injecting empty start tag ", tname)?

It seems related to this upstream issue: 
https://github.com/babluboy/bookworm/issues/330

Unrelated, binary name is com.github.babluboy.bookworm which is annoying
when one wants to launch the app from the command line. I don't know if
it's something fix-able on the packaging side or if it's worth reporting
upstream.

Thanks for packaging/maintaining Bookworm,
Julien

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/8 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 bookworm depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  html2text1.3.2a-28
ii  libc62.31-3
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgee-0.8-2 0.20.3-1
ii  libglib2.0-0 2.66.0-1
ii  libgranite5  5.5.0-1
ii  libgtk-3-0   3.24.23-1
ii  libpango-1.0-0   1.46.1-1
ii  libpoppler-glib8 20.09.0-2
ii  libsoup2.4-1 2.70.0-1
ii  libsqlite3-0 3.33.0-1
ii  libwebkit2gtk-4.0-37 2.28.4-1
ii  libxml2  2.9.10+dfsg-6
ii  poppler-utils20.09.0-2
ii  python3  3.8.2-3
ii  unar 1.10.1-2+b6
ii  unzip6.0-25

bookworm recommends no packages.

bookworm suggests no packages.

-- no debconf information

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Samuel Thibault]

Niels Thykier, le sam. 12 sept. 2020 17:46:03 +0200, a ecrit:
> It occurs to me that this can be done via a custom dh addon using
> something like:

That's not exactly simple :)

My general concern is about making free software contribution as simple
as possible. When discussing with people about bug fixing etc. I would
tell them that I like the Debian way of hacking software: apt-get source
... ; apt-get build-dep ... ; modify source ; dpkg-buildpackage, and
voilà, you have a modified package in your usual testing environment
(unlike getting source from upstream, with different dependencies
compatibilities etc.).

But the "modify source ; dpkg-buildpackage" part needs to be as simple
as possible for people to consider this as an accessible thing to
do. That's why I'm looking for a solution that people would be able to
use easily, e.g. an environment variable that we could document them to
use, such as

DH_REBUILD=dh_auto_build dpkg-buildpackage -B -nc
or
DH_REBUILD=dh_auto_configure dpkg-buildpackage -B -nc

depending on the need.

Samuel

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Niels Thykier]

Samuel Thibault:
> [...]
>> The devil in the detail here is that I suspect that you also want to
>> re-run dh_auto_test and that is on the "wrong" side of that "restart
>> point".
> 
> That may happen, yes, although way less often.
> 
> Could there perhaps be a way to specify at which point we want to make
> -nc restart from?
> 
> Samuel
> 

It occurs to me that this can be done via a custom dh addon using
something like:

"""
mkdir -p /some/where/Debian/Debhelper/Sequence/
cat <<'EOF' > /some/where/Debian/Debhelper/Sequence/skip_commands.pm

my @cmds = qw(
   dh_autoreconf
   dh_auto_configure
   dh_auto_build
);
for my $cmd (@cmds) {
  remove_command($cmd);
}

1;
EOF

PERL5LIB=/some/where DH_EXTRA_ADDONS=skip-commands \
   dpkg-buildpackage .. -nc
"""

Except you have to manually list the commands to skip.


It is not entirely simple, but it should work already today but assumes
you inject the perl library and the two ENV variables smoothly.

You can generate the @cmd list by using:

  dh build --no-act

plus a bit of selective copy/paste.

Thanks,
~Niels

Bug#970190: gpg(1) --card-edit documentation HOWTO page is not correct

[xiscu]

Package: gpg
Version: 2.2.20-1
Severity: minor

Dear Maintainer,
the current documentation for the --card-edit option seems to be outdated:

--card-edit
   Present  a menu to work with a smartcard. The subcommand "help" provides an 
overview on available com‐
   mands. For a detailed description, please see the Card HOWTO  at  
https://gnupg.org/documentation/how‐
   tos.html#GnuPG-cardHOWTO .  

as on https://gnupg.org/documentation/howtos.html (2020.09.12) I fail to find
the corresponding (anchor to) GnuPG-cardHOWTO 

Thanks in advance,
xiscu

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

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 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 gpg depends on:
ii  gpgconf2.2.20-1
ii  libassuan0 2.5.3-7.1
ii  libbz2-1.0 1.0.8-4
ii  libc6  2.31-3
ii  libgcrypt201.8.6-2
ii  libgpg-error0  1.38-2
ii  libreadline8   8.0-4
ii  libsqlite3-0   3.33.0-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gpg recommends:
ii  gnupg  2.2.20-1

gpg suggests no packages.

-- no debconf information

Bug#970187: Updating the tox Uploaders list

[Pierre-Elliott Bécue]

Source: tox
Version: 3.7.0-2 3.15.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the tox package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970188: Updating the twine Uploaders list

[Pierre-Elliott Bécue]

Source: twine
Version: 1.13.0-1 3.2.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the twine package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970189: Updating the xonsh Uploaders list

[Pierre-Elliott Bécue]

Source: xonsh
Version: 0.8.10+dfsg-1 0.9.20+dfsg-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the xonsh package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970186: rust-rand-core-0.3: Unaligned memory access resulting in undefined behavior

[Alexander Kjäll]

Source: rust-rand-core-0.3
Version: 0.3.0-2
Severity: normal
Tags: upstream, security

Dear Maintainer,


Versions under 0.4.2 violated alignment when casting byte slices to integer 
slices, resulting in undefined behavior.

Advisory: https://rustsec.org/advisories/RUSTSEC-2019-0035.html


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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

Bug#970185: rust-rand-core-0.2: Unaligned memory access resulting in undefined behavior

[Alexander Kjäll]

Package: rust-rand-core-0.2
Version: 0.2.2-1
Severity: normal
Tags: upstream, security

Dear Maintainer,


Versions under 0.4.2 violated alignment when casting byte slices to integer 
slices, resulting in undefined behavior.

Advisory: https://rustsec.org/advisories/RUSTSEC-2019-0035.html


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

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 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

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Samuel Thibault]

Niels Thykier, le sam. 12 sept. 2020 16:49:17 +0200, a ecrit:
> Samuel Thibault:
> > Niels Thykier, le sam. 12 sept. 2020 14:12:55 +0200, a ecrit:
> >> It occurs to me that you need this for debugging.  Would it help you if
> >> debhelper provided a way for you to intercept the failure and resume the
> >> build from there?
> > 
> > That can be a start yes, indeed.
> > 
> > It happens that another thing I often do is build the package, install
> > it, try what I get, change the source, quickly rebuild the package with
> > -nc, reinstall, etc.  With dh < 10 I used a homemade dh_rebuild script
> > that clears all steps after dh_auto_build in the log. Is there a way to
> > achieve the same with dh >= 10?
> 
> By default, debhelper tracks that it has run the build target and will
> resume from there on a "-nc".

Ah, right.

> The devil in the detail here is that I suspect that you also want to
> re-run dh_auto_test and that is on the "wrong" side of that "restart
> point".

That may happen, yes, although way less often.

Could there perhaps be a way to specify at which point we want to make
-nc restart from?

Samuel

Bug#970184: initramfs-tools: amd64-specific autopkgtests need to be skipped on !amd64

[Simon McVittie]

Package: initramfs-tools
Version: 0.137
Severity: important
X-Debbugs-Cc: debian...@lists.debian.org

The initramfs-tools autopkgtests now fail on arm64 (and would fail
on other non-amd64 architectures, if we had test runners for them)
because the test-dependencies are not installable. By default, the CI
infrastructure considers this to be a test failure.

Please add "Restrictions: skip-not-installable" to the amd64-* tests, so
that they will be skipped if the test-dependencies are uninstallable.

Alternatively, if you want to diagnose uninstallability on amd64
as a test failure, you could use "Restrictions: skippable", depend
on "linux-image-amd64 [amd64]", and make the test script exit 77 on
non-amd64 architectures.

Please see
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
for more details.

Thanks,
smcv

Bug#958004: xtron: ftbfs with GCC-10

[Boyuan Yang]

Hi Uwe,

On Thu, 23 Jul 2020 22:48:43 +0200 Reiner Herrmann 
wrote:
> Control: tags -1 + patch
> 
> Hi,
> 
> I attached a patch that fixes the FTBFS with GCC 10.

Now that we have a patch here, can we fix this bug soon? It seems that
package xtron saw no upload for 12 years and we really need a new
upload to fix this FTBFS problem and do some refreshing to packaging.

Thanks and let me know if you need any help.

Regards,
Boyuan Yang


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

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Niels Thykier]

Samuel Thibault:
> Hello,
> 
> Niels Thykier, le sam. 12 sept. 2020 14:12:55 +0200, a ecrit:
>> It occurs to me that you need this for debugging.  Would it help you if
>> debhelper provided a way for you to intercept the failure and resume the
>> build from there?
> 
> That can be a start yes, indeed.
> 
> It happens that another thing I often do is build the package, install
> it, try what I get, change the source, quickly rebuild the package with
> -nc, reinstall, etc.  With dh < 10 I used a homemade dh_rebuild script
> that clears all steps after dh_auto_build in the log. Is there a way to
> achieve the same with dh >= 10?
> 
> Samuel
> 

By default, debhelper tracks that it has run the build target and will
resume from there on a "-nc".  The devil in the detail here is that I
suspect that you also want to re-run dh_auto_test and that is on the
"wrong" side of that "restart point".

~Niels

Bug#970182: Updating the singledispatch Uploaders list

[Pierre-Elliott Bécue]

Source: singledispatch
Version: 3.4.0.3-2 3.4.0.3-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the singledispatch package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970181: Updating the six Uploaders list

[Pierre-Elliott Bécue]

Source: six
Version: 1.12.0-1 1.15.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the six package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970183: Updating the wheel Uploaders list

[Pierre-Elliott Bécue]

Source: wheel
Version: 0.32.3-2 0.34.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the wheel package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software

[Tobias Frost]

Control: owner -1 !

Ok, finally found time \o/, but did not have enough to complete the review :-(

(The review is based on the package from mentors uploaded 2020-09-10 19:38.)

Not yetreviewed:
dep3-headers on patches, d/changelog and d/copyright as Alec is actively
working on those (as per private mail)
Two remarks:
- d/changelog You could bumpt the timestamp on the changelog from time to time, 
though
;-): dch -r "" is a nice trick ;-)
- (nitpick) d/changelog Please be consitent on the Closes: Stancas
  - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use
either with '#' or without '#' … just for my eyes to relief…

d/control:
- you can drop opencpn-plugins; I guess this is for people who
  installed before Debian had the package. OK to keep the
  Break/Replace until opencpn has been released with a Debian stable
  release. (I cant check if the version constraint is right, because "<<"
  is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the
  first version with an empty plugins package?; It would be safe to us <<
  4.8.8~, though. Update: #917561 seems to indicate that this change was
  actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would
  be too old…)
- is wx3.0-i18n really required to run opencpn? Maybe Recommends is
  enough?
- opencpn recommends binutils. Can you say why, its a bit unusual for
  non-development applications.

d/opencpn.install and d/rules…
There are some issues, I'll follow up later on those,
probably with a patch/MR (hint to update salsa, see below).

d/clean
- NSIS.template.in is appearantly recreated during build, it should be
  deleted via d/clean. (Then debuild twice will work, too)


d/rules:
In the override
- instead of making the links to the licenses, you could use dh_links(1)


multiarch:
- the plugin *.so are not installed in an multiarch aware path.

nitpicks:
- theres a trailing space in README.source (use wrap-and-sort(1) ;-))


Wishlist:
- please enable salsa-ci on the packaging repo…

(wishlist items related to README.Debian)
- I see docs are not packaged for privacy reasons. Could they be when
  the docs being patches (not an unseen in Debian)?
  (e.g I hate it if the docs are not matching the version I have
  installed, as often the docs for the newer version won't apply well
  enough)
- (as you are upstream-involved, this is probably easy to fix on your
  side:) The plugin code could also look into alternative directories…
  - The /usr/share/ hierachicy is reserved for packaged stuff, so
encouraging users to copy stuff there is a bit meeeh; it can
create problems when e.g a new package provides this file.
  - So probably /usr/local/… or /opt/… would be a better
recommendation.
  - Additionally, when users should be able to install plugins without
being root, something like $HOME/.local/… (not sure if this is
consenus in Debian, though)

- dont forget to push to salsa…;-) -- I can also review from there
  (only for the final upload I prefer to do with a package from
   mentors, just to make sure that I upload the right orig.tar.)
  Plus I can offer MRs instead of snarky comments ;-)

-- 
tobi


signature.asc
Description: PGP signature

Bug#970177: Updating the python-progress Uploaders list

[Pierre-Elliott Bécue]

Source: python-progress
Version: 1.2-1 1.5-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-progress package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970178: Updating the python-flake8 Uploaders list

[Pierre-Elliott Bécue]

Source: python-flake8
Version: 3.6.0-1 3.8.3-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-flake8 package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970180: Updating the python-nose-exclude Uploaders list

[Pierre-Elliott Bécue]

Source: python-nose-exclude
Version: 0.5.0-1 0.5.0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-nose-exclude package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970179: Updating the pytest-instafail Uploaders list

[Pierre-Elliott Bécue]

Source: pytest-instafail
Version: 0.4.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the pytest-instafail package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970176: Please move f2fs-tools to version 1.14 from upstream; 1.11 does NOT support compression

[Charles Cropper]

Package: f2fs-tools
Version: 1.11.0-1.1

I installed f2fs on a 4TB SSD. This SSD was for testing purposes to manipulate 
some versioned backups.

When I attempted to make a new f2fs file system with compression enabled using 
the 'options' flag  the program says invalid 
option. All of the upstream documentation states that this option IS 
supported.

I am using Debian Buster, kernel 5.7.0-0.bpo.2-amd64 #1 SMP Debian 
5.7.10-1~bpo10+1 (2020-07-30) x86_64 GNU/Linux.

Thank you for your work.

Bug#969970: wfuzz: Please update to new release 3.0.1

[Samuel Henrique]

Control: tag -1 - pending

New release is on git, upload is temporarily blocked by an issue I had
with ftpmaster, should be unblocked in a couple of days max.

The new release does remove the tight pycurl version requirements, so
the migration will proceed.

Thanks,

-- 
Samuel Henrique 

Bug#970175: ITP: ruby-elasticsearch-rails -- Ruby on Rails integrations for Elasticsearch

[Sruthi Chandran]

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

* Package name: ruby-elasticsearch-rails
  Version : 7.1.1
  Upstream Author : Elasticsearch B.V.
* URL : https://github.com/elasticsearch/elasticsearch-rails/
* License : Apache-2.0
  Description : Ruby on Rails integrations for Elasticsearch
 The elasticsearch-rails library is a companion for the
elasticsearch-model library, providing features suitable for Ruby on
Rails applications.




signature.asc
Description: OpenPGP digital signature

Bug#970174: lintian-brush: should not bump compat level if lintian override exist (but should warn/notify)

[Holger Levsen]

Package: lintian-brush
Version: 0.77
Severity: minor

Dear Jelmer,

I've just ran lintian-brush to convert debian-security-support from debhelper 11
to 12 and was very happy it changed debian/rules to move the --fail-missing
argument to dh_missing, then ran debuild -S, which ran lintian, which made me
discover there still was an override for that in 
debian/source/lintian-overrides.

I'm not sure what the default behavior should be but i'm slightly leaning 
towards
"do nothing and explain there's an override" instead of also removing the 
override.
But i'll happily leave that to you :)

Thanks for lintian-brush, it's super cool!


-- 
cheers,
Holger

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

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Bug#970173: node-fetch: CVE-2020-15168

[Salvatore Bonaccorso]

Source: node-fetch
Version: 1.7.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.7.3-1

Hi,

The following vulnerability was published for node-fetch.

CVE-2020-15168[0]:
| node-fetch before versions 2.6.1 and 3.0.0-beta.9 did not honor the
| size option after following a redirect, which means that when a
| content size was over the limit, a FetchError would never get thrown
| and the process would end without failure. For most people, this fix
| will have a little or no impact. However, if you are relying on node-
| fetch to gate files above a size, the impact could be significant, for
| example: If you don't double-check the size of the data after fetch()
| has completed, your JS thread could get tied up doing work on a large
| file (DoS) and/or cost you money in computing.


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-2020-15168
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15168
[1] 
https://github.com/node-fetch/node-fetch/security/advisories/GHSA-w7rc-rwvf-8q5r

Regards
Salvatore

Bug#970172: cifs-utils: CVE-2020-14342: Shell command injection vulnerability in mount.cifs

[Salvatore Bonaccorso]

Source: cifs-utils
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14442
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:6.8-2
Control: found -1 2:6.9-1

Hi,

The following vulnerability was published for cifs-utils.

CVE-2020-14342[0]:
| It was found that cifs-utils' mount.cifs was invoking a shell when
| requesting the Samba password, which could be used to inject arbitrary
| commands. An attacker able to invoke mount.cifs with special
| permission, such as via sudo rules, could use this flaw to escalate
| their privileges.


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-2020-14342
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14342
[1] https://bugzilla.samba.org/show_bug.cgi?id=14442
[2] https://lists.samba.org/archive/samba-technical/2020-September/135747.html
[3] 
https://git.samba.org/cifs-utils.git/?p=cifs-utils.git;a=commit;h=48a654e2e763fce24c22e1b9c695b42804bbdd4a]

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#970171: Updating the voluptuous Uploaders list

[Pierre-Elliott Bécue]

Source: voluptuous
Version: 0.11.1-1 0.11.1-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the voluptuous package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Samuel Thibault]

Hello,

Niels Thykier, le sam. 12 sept. 2020 14:12:55 +0200, a ecrit:
> It occurs to me that you need this for debugging.  Would it help you if
> debhelper provided a way for you to intercept the failure and resume the
> build from there?

That can be a start yes, indeed.

It happens that another thing I often do is build the package, install
it, try what I get, change the source, quickly rebuild the package with
-nc, reinstall, etc.  With dh < 10 I used a homemade dh_rebuild script
that clears all steps after dh_auto_build in the log. Is there a way to
achieve the same with dh >= 10?

Samuel

Bug#970169: Updating the python-cachecontrol Uploaders list

[Pierre-Elliott Bécue]

Source: python-cachecontrol
Version: 0.11.7-1 0.12.6-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-cachecontrol package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970168: Updating the python3-openid Uploaders list

[Pierre-Elliott Bécue]

Source: python3-openid
Version: 3.1.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python3-openid package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970166: Updating the python-distro Uploaders list

[Pierre-Elliott Bécue]

Source: python-distro
Version: 1.3.0-1 1.5.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-distro package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970167: Updating the lazr.smtptest Uploaders list

[Pierre-Elliott Bécue]

Source: lazr.smtptest
Version: 2.0.3-1 2.0.3-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the lazr.smtptest package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970163: Updating the python-pip Uploaders list

[Pierre-Elliott Bécue]

Source: python-pip
Version: 18.1-5 20.1.1-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-pip package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970170: Updating the pyflakes Uploaders list

[Pierre-Elliott Bécue]

Source: pyflakes
Version: 2.0.0-1 2.2.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the pyflakes package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970165: Updating the python-persistent Uploaders list

[Pierre-Elliott Bécue]

Source: python-persistent
Version: 4.2.2-2 4.2.2-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-persistent package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970162: Updating the html5lib Uploaders list

[Pierre-Elliott Bécue]

Source: html5lib
Version: 1.0.1-1 1.0.1-3 1.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the html5lib package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#970164: Updating the pycurl Uploaders list

[Pierre-Elliott Bécue]

Source: pycurl
Version: 7.43.0.2-0.1 7.43.0.6-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the pycurl package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#969890: cmake: segfaults in dl-lookup.c:158 check_match() "UI_set_result"

[Bernhard Übelacker]

On Tue, 8 Sep 2020 15:26:14 +0100 Claude Heiland-Allen  
wrote:
> I resolved these problems with
> sudo apt install --reinstall libssl1.1
> no clue why/how it was damaged
> sorry for the noise

Hello Claude Heiland-Allen,
you might want to let a memory checker run
to exclude that as the source of the issue.

Kind regards,
Bernhard

Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions

[Bernhard Übelacker]

Hello Jason,

> #0  0x7efbfb5f3204 n/a (libgtk-3.so.0)
> #1  0x7efbfb779a53 n/a (libgtk-3.so.0)
> #2  0x7efbfb779b11 n/a (libgtk-3.so.0)
> #3  0x7efbfb779ff1 n/a (libgtk-3.so.0)
> #4  0x7efbf96c38ee ffi_call_unix64 (libffi.so.6)
> ...

I assume you updated inkscape to current version 1.0-5~bpo10+1 ?

The above part of your backtrace would translate to this
when debug symbols are installed.

(gdb) bt
#0  0x7f5ab0050204 in _gtk_gesture_get_pointer_emulating_sequence () at 
../../../../gtk/gtkgesture.c:1811
#1  0x7f5ab01d6a53 in _gtk_widget_get_emulating_sequence () at 
../../../../gtk/gtkwidget.c:4183
#2  0x7f5ab01d6b11 in _gtk_widget_set_sequence_state_internal () at 
../../../../gtk/gtkwidget.c:4245
#3  0x7f5ab01d6ff1 in event_controller_sequence_state_changed () at 
../../../../gtk/gtkwidget.c:17330
#4  0x7f5aae1208ee in ffi_call_unix64 () from 
/lib/x86_64-linux-gnu/libffi.so.6
...

The instruction at this address originates from following location
and tries to read memory from the address the variable "data->event"
points to. The data variable is retrieved before by g_hash_table_iter_next.

https://sources.debian.org/src/gtk+3.0/3.24.5-1/gtk/gtkgesture.c/#L1811

Also this location is quite different from what the original segfault
lines in the first message was showing for the previous bpo version.


Unfortunately I guess this will not be sufficient for the maintainer
to find out the problem or create a fix.

If you receive such crashes multiple times, are the backtraces always
different? If yes you might consider to check for memory faults.

Also running inkscape through "valgrind --undef-value-errors=no inkscape"
might reveal something, but might be too slow to work long enough with it,
if there are no exact steps known to reproduce it.

Also you might add the debug symbols to your system to generate
backtraces with more information, like described here:

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

Kind regards,
Bernhard

Bug#970161: RFS: pdf2djvu/0.9.17.1-1 [RC] -- PDF to DjVu converter

[Hsieh-Tseng Shen]

Package: sponsorship-requests
Severity: important
Tags: upstream, ftbfs

Dear mentors,

I am looking for a sponsor for my package "pdf2djvu":

 * Package name: pdf2djvu
   Version : 0.9.17.1-1
   Upstream Author : Jakub Wilk 
 * URL : http://jwilk.net/software/pdf2djvu
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/pdf2djvu
   Section : text

It builds those binary packages:

  pdf2djvu - PDF to DjVu converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pdf2djvu/pdf2djvu_0.9.17.1-1.dsc

Changes since the last upload:

 pdf2djvu (0.9.17.1-1) unstable; urgency=medium
 .
   * New upstream release.
 + Fix build failure with Poppler ≥ 20.08 (Closes: #969888).
   * deb/control: add Rules-Requires-Root: no.
   * deb/rules: remove --as-needed linker flag to fix lintian.

Please DDs review this upload and also give me a upload permission as DM
when I'm responsible to care next maintenance. Very appreciated.

Regards,

-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature

Bug#970160: Updating the python-whoosh Uploaders list

[Pierre-Elliott Bécue]

Source: python-whoosh
Version: 2.7.4+git6-g9134ad92-4 2.7.4+git6-g9134ad92-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the python-whoosh package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#966707: debhelper: dh not keeping command log results in package rebuild

[Niels Thykier]

Samuel Thibault:
> Package: debhelper
> Version: 13.2
> Severity: normal
> 
> Hello,
> 

Hi,

> Since debhelper compat 10, "The dh command will no longer use log files
> to track which commands have been run.  The dh command still keeps track
> of whether it already ran the "build" sequence and skip it if it did."
> 
> How does it keep track now? In some file or only live? Is there a way to
> get back to a file-tracking? Only by creating timestamps ourself?
> 

It no longer tracks this via files except for being able to tell that
the entire build target has already run.  There is no way to get the
previous behaviour back.

> My concern is that it seems to be thus running ./configure each time
> I invoke dpkg-buildpackage, and thus the packaging system basically
> rebuilds everything. The problem comes when there is a build failure at
> some point, and I want to run dpkg-buildpackage -nc to resume building
> the package after fixing the build failure ; since ./configure is
> invoked again, the build system rebuilds everything! This can be
> extremely time-consuming for very big packages, basically making
> debhelper compat 10 unusable for packages with big build time.
> 
> I have attached a test case:
> 
> 
> [...]
> 
> 
> Yes, ideally upstream's ./configure would be idempotent and be cautious
> with timestamps of identically-generated files, and thus not actually
> trigger a rebuild, but I believe it's far from being a general case
> for upstream source, and getting this "rebuild-from-start" behavior by
> default is painful.
> 
> [...]
> 
> Samuel
> 
> [...]

Interestingly, I have had people asking me to *remove* the logging
because they were tired of it getting it their way with -nc rebuilds.
Presumably they worked with idempotent "configure" steps.

It occurs to me that you need this for debugging.  Would it help you if
debhelper provided a way for you to intercept the failure and resume the
build from there?

Thanks,
~Niels

Bug#970159: aptly: Please consider backporting 1.4.0 to buster

[Baptiste Beauplat]

Package: aptly
Severity: wishlist

Dear maintainer,

aptly 1.4.0 bring compatibility for GnuPG 2.x. It would be very nice to
have this backported to buster.

Best,
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#959228: grub2: Grub2 V2.04-7 does not recognize BTRFS RAID1c4 filesystem

[waxhead]

Steve McIntyre wrote:

Hi!

On Fri, May 01, 2020 at 10:57:15AM +0200, waxhead wrote:

Steve McIntyre wrote:

On Fri, May 01, 2020 at 10:11:23AM +0200, waxhead wrote:

Source: grub2
Version: 2.04-7
Severity: important

Dear Maintainer,

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

* What led up to the situation?

 I waited for grub 2.04-7 to support the BTRFS RAID1c3/RAID1c4 features.
 it found that it had migraded to testing this morning, did an apt update + 
apt upgrade to get it.
 Made sure I ran update-grub, and btrfs balance start -mconvert=raid1c4 /
 also checked with apt-get source grub2 , browsed the btrfs.c to check , 
all the raid1c34 parts
 seemed to be in place.
 ran systemd reboot and grub failed with unknown filesystem.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

Fired up the latest testing live cd and rebalanced my rootfs back to btrfs 
raid1


Try again next Monday - the live images are only updated weekly. Grub
version 2.04-7 only just migrated to testing in the last 24h...


Uhmmm, not sure I understand. The bugreport has nothing to do with the live
images (they where suitable for me to recover).

The bugreport is for grub2 v2.04-7 which, as you say just migrated to
testing. Problem: grub2 v2.04-7 should support RAID1c34 and does not seem to
do so.


Apologies - misunderstood "Fired up the latest testing live cd". Need
more coffee, clearly... :-/


Howdy,

Just wanted to add that this bug can be closed and buried. I took the 
leap of faith and tested out grub (2.04-8) on a Raid1c4 (metadata) and 
Raid1c3 (data) btrfs which boots just fine!

Bug#871312: dh-systemd: please drop transitional package dh-systemd

[Niels Thykier]

Michael Biebl:
> Hi
> 
> [...]
> 
> The remaining bugs have been bumped to serious, causing affected
> packages to be AUTORMed on 02.09.
> I guess we are ready to proceed with the removal.
> 
> Regards,
> Michael
> 

Thanks. :)

I will probably do a 13.2.1 bug fix release without this change to avoid
unnecessary hold up (some of the AUTORM counters have been reset).  But
I will include it in a feature update soonish (13.3 or so).

Once again, thanks for handling this transition!

~Niels

Bug#970158: Updating the pyparsing Uploaders list

[Pierre-Elliott Bécue]

Source: pyparsing
Version: 2.2.0+dfsg1-2 2.4.7-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Barry Warsaw  has retired, so can't work on
the pyparsing package anymore.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#964784: debhelper [INTL:pt] Update on Portuguese translation of manpage

[Niels Thykier]

Américo Monteiro:
> Package: debhelper
> Version: 13.2
> 3ags: l10n, patch-
> Severity: wishlist
> 
> Updated Portuguese translation for  debhelper's manpage
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' 
> 

Thanks.

Let me know if you would like/prefer to have direct commit access to the
debhelper repo for future updates.

~Niels

Bug#970157: ITP: seriation --- Finds a suitable linear order for a set of objects

[Nilesh Patra]

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

* Package name: seriation
  Version : 0.1+git20200810
  Upstream Author : Alexandre Amory
* URL : https://github.com/amamory/seriation
* License : Expat
  Programming Lang: C
  Description : Finds a suitable linear order for a set of objects
 This software is an efficient implementation of the
 seriation problem which 'finds a suitable linear
 order for a set of objects'. It has been used
 to order a network of proteins such that 'related'
 nodes are closer in the other.

I shall maintain this package.