Bug#994631: RFS: color-picker/1.0.2-1 -- Powerful screen color picker based on Qt

2021-09-18 Thread Hugo Torres
Necessary the creation of the Debian repository in Salsa.

I created the repository in my account to make the migration: 
https://salsa.debian.org/f9kill/colorpicker

--
Hugo Torres de Lima
0x365C8CEF4233E3D8

Sent with ProtonMail Secure Email.

signature.asc
Description: OpenPGP digital signature


Bug#994634: RM: node-stringprep -- ROM; Useless, buggy and unmaintained upstream

2021-09-18 Thread Yadd
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 994...@bugs.debian.org

Hi,

following #994603, this package is useless (no reverse dependencies),
unmaintained and RC-buggy. It can be safely removed from Debian.

Cheers,
Yadd



Bug#992668: ricochet-im: does not start

2021-09-18 Thread Paul Wise
On Sun, 2021-09-19 at 00:20 -0400, The Hermit wrote:

> Failed at:
> root@nevermore:/usr/src# sudo debi --upgrade
> debi: cannot find readable debian/changelog anywhere!
> Are you in the source code tree?

Woops, debi needs to be run from the unpacked source package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#994412: OK I removed both, then reinstalled one

2021-09-18 Thread 積丹尼 Dan Jacobson
Well on a vanilla system I still get:

# aptitude -s purge debian-el
The following packages will be REMOVED:
  debian-el{p} elpa-debian-el{u}

aptitude show says:

Package: elpa-debian-el
Version: 37.10
State: installed
Automatically installed: yes

Package: debian-el
Version: 37.10
State: installed
Automatically installed: no

True, when I installed them I had:

APT::AutoRemove::RecommendsImportant false;
APT::AutoRemove::SuggestsImportant false;
APT::Cache::AllVersions false;
APT::Clean-Installed false;
APT::Default-Release "unstable";
APT::Get::Fix-Missing true;
APT::Get::Purge true;
APT::Install-Recommends false;
APT::Keep-Downloaded-Packages true;
APT::Periodic::Enable false;
Acquire::PDiffs true;
Acquire::http::No-Cache true;
Aptitude::CmdLine::Always-Prompt true;
Aptitude::CmdLine::Show-Deps true;
Aptitude::CmdLine::Show-Why true;
Aptitude::CmdLine::Verbose 1;
Aptitude::Purge-Unused true;
Binary::apt::APT::Keep-Downloaded-Packages true;

OK, now doing purge, install, purge again, with my above settings list I
get:

# aptitude purge debian-el
The following packages will be REMOVED:
  debian-el{p}  elpa-debian-el{pu} (D: debian-el)

OK, I'll just purge debian-el, and then
install elpa-debian-el.
OK, now it is not marked Automatically Installed.

(I only dare use -s when I don't have my settings list installed,
as it might delete all my downloaded packages, etc.)



Bug#994631: RFS: color-picker/1.0.2-1 -- Powerful screen color picker based on Qt

2021-09-18 Thread Hugo Torres de Lima
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "color-picker":

 * Package name: color-picker
   Version : 1.0.2-1
   Upstream Author : https://github.com/keshavbhatt/ColorPicker/issues
 * URL : https://github.com/keshavbhatt/ColorPicker
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/color-picker
   Section : graphics

It builds those binary packages:

  color-picker - Powerful screen color picker based on Qt

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

  https://mentors.debian.net/package/color-picker/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/color-picker/color-picker_1.0.2-1.dsc

Changes since the last upload:

 color-picker (1.0.2-1) unstable; urgency=medium
 .
   * New upstream version 1.0.2
   * Upload to unstable.
   * debian/control: Bumped Standards-Version to 4.6.0.

Regards,
--
  Hugo Torres de Lima



Bug#992668: ricochet-im: does not start

2021-09-18 Thread The Hermit

First, thank you. ;)

Failed at:
root@nevermore:/usr/src# sudo debi --upgrade
debi: cannot find readable debian/changelog anywhere!
Are you in the source code tree?

I tried doing this from /usr/local/src and then /usr/src.
Not that familiar with Debian builds so not sure where I went wrong.  I 
rarely build anything from source now days to try and keep the system clean.


Package was built so
apt install ./ricochet-im_1.1.4-3_amd64.deb

On 9/18/21 1:06 AM, Paul Wise wrote:

Control: usertatgs -1 + confirmed

On Sat, 21 Aug 2021 23:57:06 -0400 The Hermit wrote:


hermit@~:ricochet
/usr/include/c++/9/bits/move.h:194:7: runtime error: load of value 279, which 
is not a valid value for type 'Type'

I get this too and I noticed that rebuilding ricochet fixes it.
I'll request the release team to rebuild it in bullseye/bookworm.
Until that happens, you can rebuild it using these commands:

sudo apt install devscripts
sudo apt build-dep ricochet-im
apt source --build ricochet-im
sudo debi --upgrade





Bug#994633: new upstream 470.63.01

2021-09-18 Thread Harald Dunkel
Package: nvidia-kernel-dkms
Version: 470.57.02-2

Since upstream's kernel 5.13 has reached EOL and since nvidia-graphics-drivers
470.63.01 seems to build fine with 5.14 (http://rglinuxtech.com/?cat=18) I 
wonder
if it would be possible to provide the new version for Sid?


Regards
Harri



Bug#992957: Solved, i guess - Re: apticron: Wrong path of binary "hostname" inside /usr/sbin/apticron

2021-09-18 Thread Tiago Bortoletto Vaz
Hi Tim, thanks for the follow-up, glad you found the issue at your side!

I'm close this bug then.

Bests,

--
Tiago

On Wed, Sep 15, 2021 at 12:00:54PM +0200, Tim Boneko wrote:
> Hello!
> Never mind about this, it seems to have been a DNS issue. My router
> couldn't resolve its own ip address. After fixing this, apticron
> started working again.
> Cheers,
> 
>   tim



Bug#994632: libjpeg-turbo: New upstream version available

2021-09-18 Thread Andrew Chadwick
Source: libjpeg-turbo
Version: 1:2.0.6-4
Severity: wishlist
X-Debbugs-Cc: a.t.chadw...@gmail.com

Dear Maintainer,

A new upstream release, version 2.1.1, is available. At your convenience, 
please can the Debian package be updated?

https://github.com/libjpeg-turbo/libjpeg-turbo/releases
https://sourceforge.net/projects/libjpeg-turbo/files/2.1.1/


Thanks,
Andrew Chadwick



Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

2021-09-18 Thread Christoph Anton Mitterer
On Sun, 2021-09-19 at 03:05 +0200, Guilhem Moulin wrote:
> No.  How did you test this?

Hmm, strange, there must have been some mess in my initramfs image...
now it's in the correct place.

Sorry for the noise.



Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

2021-09-18 Thread Guilhem Moulin
On Sun, 19 Sep 2021 at 02:12:18 +0200, Christoph Anton Mitterer wrote:
> Did I observe correctly, and cryptroot places *any* keyscript into:
> /lib/cryptsetup/scripts/
> ?

No.  How did you test this?

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#994630: ITP: golang-github-knqyf263-go-apk-version -- A golang library for parsing apk package versions

2021-09-18 Thread Nobuhiro Iwamatsu
Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-apk-version
  Version : 0.0~git20200609.041fdbb
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-apk-version
* License : Apache-2.0
  Programming Lang: Go
  Description : A golang library for parsing apk package versions

 go-apk-version is a golang library for parsing and comparing versions for apk.



Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts

2021-09-18 Thread Christoph Anton Mitterer
Hey.

One more on this.

Did I observe correctly, and cryptroot places *any* keyscript into:
/lib/cryptsetup/scripts/
?

Cause that would likely mean that if the "systemwide" keyscript in
/lib/cryptsetup/scripts/ and one with any other path (which is then
specified as keyscript=/foo/bar/baz.sh) share the same name, ...
including both fails.


I guess the simplest solution would be to include any keyscripts into
one fixed area with the whole path, so e.g.
/cryptroot/keyscripts/

Even doing something like:
- all from /lib/cryptsetup/scripts/ into /lib/cryptsetup/scripts/ within the 
initramfs
- all not from /lib/cryptsetup/scripts/ into /lib/cryptsetup/scripts/$PATH 
wouldn't really fix that 100%; cause a user could specify a keyscript
as "/decrypt_gnupg".


Cheers,
Chris.



Bug#994629: ITP: tml -- tiny tool and go library for markup language for terminal output

2021-09-18 Thread Nobuhiro Iwamatsu
Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: tml
  Version : 0.4.0
  Upstream Author : Liam Galvin
* URL : https://github.com/liamg/tml
* License : public-domain
  Programming Lang: Go
  Description : tiny tool and go library for markup language for terminal 
output

 A Go library and standalone binary to make the output of coloured/formatted
 text in the terminal easier and more readable.



Bug#994623: xfce4-power-manager: Suspend doesn't notice the screen locker

2021-09-18 Thread Stefan
Package: xfce4-power-manager
Version: 4.16.0-1
Severity: normal

Dear Maintainer,

Recently (probably linked to the upgrade to bullseye), the following started to
happen:

When I ask to suspend the machine, the machine does not suspend but instead I
get a dialog box saying:

None of the screen lock tools ran successfully, the screen will not
be locked.
Do you still want to continue to suspend the system?

I'm running `xscreensaver` as screen locker.

The same dialog box pops up in my account when I suspend the machine from a
session opened by another user.  In that case the machine does suspend, tho,
and I just see those dialog boxes later when I wake the machine up and log into
my session.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 xfce4-power-manager depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libupower-glib3   0.99.11-2
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxrandr22:1.5.1-1
ii  upower0.99.11-2
ii  xfce4-power-manager-data  4.16.0-1

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  247.3-6
ii  xfce4-power-manager-plugins  4.16.0-1

xfce4-power-manager suggests no packages.



Bug#994628: gexiv2: Please package 0.12.2 or higher

2021-09-18 Thread Jeremy Bicha
Source: gexiv2
Version: 0.12.1-1
Severity: wishlist

gexiv2 0.14.0 is now available.

The latest version of nautilus, the GNOME file browser, requires gexiv2 0.12.2.

Please package the new version of gexiv2.

Thanks,
Jeremy Bicha



Bug#994627: bullseye-pu: package debian-edu-config/2.11.56+deb11u1

2021-09-18 Thread Wolfgang Schweer
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

Bug #993935 (Netboot image exposes private data and crypto keys) has 
already been fixed in unstable, but should also be fixed in stable.

[ Reason ]
This bug has been introduced while integrating the re-written LTSP into 
Debian Edu 11 (bullseye). The bug shows up in case someone installs a 
system with both Main-Server and LTSP-Server profiles on the same 
machine (aka combined server). The manual recommends to use separate 
machines but the turnkey solution 'combined server' seems to be used 
quite often.

[ Impact ]
Skilled users on the internal Debian Edu network would be able to get 
access to sensible data.

[ Tests ]
Manual tests have been done for both existent and new installations.

[ Risks ]
No actual risks, the fix is trivial and only Debian Edu installations 
are involved.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Add sensible data concerning directories and files to the 
main server related exclude list for the SquashFS image.
Mask slapd and make sure autofs is configured correctly to ensure home 
directory access after this change.
Also mask xrdp-sesman to avoid a useless (false) failure message during 
client boot.

[ Other info ]
Holger Levsen will upload the package in case of approval.

Thanks for caring,
Wolfgang


diff -Nru debian-edu-config-2.11.56/debian/changelog 
debian-edu-config-2.11.56+deb11u1/debian/changelog
--- debian-edu-config-2.11.56/debian/changelog  2021-06-05 00:06:13.0 
+0200
+++ debian-edu-config-2.11.56+deb11u1/debian/changelog  2021-09-09 
12:52:03.0 +0200
@@ -1,3 +1,13 @@
+debian-edu-config (2.11.56+deb11u1) UNRELEASED; urgency=medium
+
+  * Adjust sbin/debian-edu-ltsp-install. (Closes: #993935)
+Thanks to Dominik George for spotting and reporting the issue.
+- Extend main server related exclude list.
+- Add slapd and xrdp-sesman to the list of masked services.
+- Ensure home directory access after above changes.
+
+ -- Wolfgang Schweer   Thu, 09 Sep 2021 12:52:03 +0200
+
 debian-edu-config (2.11.56) unstable; urgency=medium
 
   [ Wolfgang Schweer ]
diff -Nru debian-edu-config-2.11.56/sbin/debian-edu-ltsp-install 
debian-edu-config-2.11.56+deb11u1/sbin/debian-edu-ltsp-install
--- debian-edu-config-2.11.56/sbin/debian-edu-ltsp-install  2021-06-05 
00:06:13.0 +0200
+++ debian-edu-config-2.11.56+deb11u1/sbin/debian-edu-ltsp-install  
2021-09-09 12:52:03.0 +0200
@@ -17,7 +17,7 @@
 # Author/Copyright:Wolfgang Schweer 
 # Licence: GPL2+
 # first edited:2019-11-21
-# last edited: 2021-04-26
+# last edited: 2021-09-14
 
 set -e
 
@@ -197,6 +197,27 @@
 # FIXME: On the main server even more additional excludes might be useful.
 if echo "$PROFILE" | grep -Eq 'Main-Server' ; then
cat <> /etc/ltsp/image-local.excludes
+etc/apache2
+etc/bind
+etc/dbconfig-common
+etc/dovecot
+etc/etckeeper
+etc/gosa
+etc/freeradius
+etc/icinga
+etc/icinga2
+etc/icingaweb2
+etc/krb5kdc
+etc/krb5.keytab.imap
+etc/krb5.keytab.ldap
+etc/krb5.keytab.smtp
+etc/mysql
+etc/nagios
+etc/nagios-plugins
+etc/nagios3
+etc/samba
+etc/slbackup
+etc/slbackup-php
 usr/lib/apache2
 usr/lib/exim4
 usr/lib/icinga
@@ -219,9 +240,12 @@
 var/lib/dpkg/*
 var/lib/exim4/*
 var/lib/icinga/*
+var/lib/ldap/*
 var/lib/munin/*
 var/lib/munin-node/*
 var/lib/nfs/*
+var/lib/samba/*
+var/log/apache2/*
 var/log/cfengine/*
 var/log/installer/*
 var/log/munin/*
@@ -470,10 +494,11 @@
# is disabled, but it is needed for diskless workstations.
# OTOH some services need to be disabled, i.e. 'masked'.
cat <> /etc/ltsp/ltsp.conf
+PRE_INIT_AUTOFS="echo 'LDAPURI=ldap://ldap' >> /etc/default/autofs"
 PRE_INIT_MAIN_SERVER="systemctl enable autofs"
 POST_INIT_USE_FQDN="sed -i '/10.0.2.2/ s/server/tjener.intern tjener/' 
/etc/hosts"
 MASK_SYSTEM_SERVICES="apache2 named cups dovecot etckeeper exim4 squid 
tftpd-hpa \
-icinga2 nmbd smbd systemd-journald xrdp krb5-kdc mariadb cfengine3 
isc-dhcp-server"
+icinga2 nmbd slapd smbd systemd-journald xrdp xrdp-sesman krb5-kdc mariadb 
cfengine3 isc-dhcp-server"
 EOF
else
cat <> /etc/ltsp/ltsp.conf
@@ -500,6 +525,7 @@
fi
# Clean up ltsp.conf from specific items.
sed -i '/PRE_INIT_MAIN/d' /etc/ltsp/ltsp.conf
+   sed -i '/PRE_INIT_AUTOFS/d' /etc/ltsp/ltsp.conf
sed -i '/MASK_SYSTEM/d' /etc/ltsp/ltsp.conf
 fi



signature.asc
Description: PGP signature


Bug#993173: Bug#992920: Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Adam D. Barratt
On Sun, 2021-09-19 at 00:08 +0200, Hilmar Preuße wrote:
> Am 19.09.2021 um 00:03 teilte Adam D. Barratt mit:
> 
> Hi,
> 
> > However, neither appears to be fixed in unstable yet. Is that
> > correct?
> > If so, please resolve the issues in unstable first, as that is a
> > basic
> > prerequisite for fixing them in (old)stable. If the issues are in
> > fact
> > fixed in unstable, please make this clearer by adding appropriate
> > fixed
> > versions to the bugs.
> > 
> Upload to unstable was performed right now, sorry the delay.
> 
> > It also doesn't look like a release.debian.org p-u request has yet
> > been
> > filed for either of the uploads. Assuming I haven't simply missed
> > them,
> > please do file the bugs, preferably using "reportbug
> > release.debian.org" and following the prompts.
> > 
> Will do so, ASAP.
> 

Thanks, and apologies if I was slightly impatient in jumping on the
uploads. In general, however, we'd expect the unstable upload to at
least have happened first, if not to have also had some time to weed
out any obvious issues.

Regards,

Adam



Bug#992920: Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Hilmar Preuße

Am 19.09.2021 um 00:03 teilte Adam D. Barratt mit:

Hi,


However, neither appears to be fixed in unstable yet. Is that correct?
If so, please resolve the issues in unstable first, as that is a basic
prerequisite for fixing them in (old)stable. If the issues are in fact
fixed in unstable, please make this clearer by adding appropriate fixed
versions to the bugs.


Upload to unstable was performed right now, sorry the delay.


It also doesn't look like a release.debian.org p-u request has yet been
filed for either of the uploads. Assuming I haven't simply missed them,
please do file the bugs, preferably using "reportbug
release.debian.org" and following the prompts.


Will do so, ASAP.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature


Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Adam D. Barratt
Hi,

On Sat, 2021-09-18 at 18:41 +0200, Hilmar Preuße wrote:
> Am 18.09.2021 um 12:01 teilte Salvatore Bonaccorso mit:
> > On Sat, Sep 18, 2021 at 11:09:18AM +0200, Chris Hofstaedtler wrote:
> > > * Chris Hofstaedtler  [210904 13:27]:
> > > > * Hilmar Preuße  [210903 10:42]:
> 
> Hi,
> 
> > > > > Try here: https://freeshell.de/hille42/993173/
> > > > 
> > > > I have tried these packages out (on buster, obviously), and can
> > > > confirm they work as expected. Also together with proftpd-mod-
> > > > vroot.
> > > 
> > > Do you think this could make it into the next stable point
> > > release?
> > 
> > I think the issue can go in via a point release indeed. The
> > planning
> > has been announced as
> > https://lists.debian.org/debian-live/2021/09/msg00026.html and
> > https://lists.debian.org/debian-live/2021/09/msg00027.html FWIW.
> > 
> I'll try to upload ASAP.
> 

I see that uploads for both of these bugs have landed in the stable-new 
queues for both buster and bullseye.

However, neither appears to be fixed in unstable yet. Is that correct?
If so, please resolve the issues in unstable first, as that is a basic
prerequisite for fixing them in (old)stable. If the issues are in fact
fixed in unstable, please make this clearer by adding appropriate fixed
versions to the bugs.

It also doesn't look like a release.debian.org p-u request has yet been
filed for either of the uploads. Assuming I haven't simply missed them,
please do file the bugs, preferably using "reportbug
release.debian.org" and following the prompts.

Thanks,

Adam



Bug#964077: Fix build-time and autopkg tests

2021-09-18 Thread Guillem Jover
Control: severity -1 wishlist

Hi!

On Wed, 2020-07-01 at 11:35:14 +0200, Christian Ehrhardt wrote:
> Package: liburing
> Version: 0.6-3

> But in regard to build time and autopkgtests I found that these always
> failed.
> I've taken a look at that as I'd love to get some actual test coverage onto
> liburing in Debian

Yeah me too, and I've been fixing these upstream to try to get there. But
unfortunately these tests are highly kernel version dependent, and new
ones tend to have very recent kernel requirements.

The various architectures supported in Debian have wildly different
support and kernel versions in the buildds. So I don't find it
realistic to enforce them right now, TBH.

I still want to run them to be able to check the results from time to
time, though.

> Note, the tests at build and at autopkgtest time are mostly the same.
> Therefore I've kept "Rules-Requires-Root: no" in d/control which means it
> will
> in most cases not test at build time (unless you e.g. sudo sbuild ...). But
> since the same tests will run at autopkgtest that is ok for me, if you
> want/need build time checks please change R³ to yes and they will work.

Yeah, I'd rather not require root for building.

> I have eventually done a cross-arch build [3] and test [4] on Ubuntu to see
> how !x86 behaves now that the tests work on x86. Depending on the outcome
> of this we might disable a few more tests maybe, but they are still
> running? Since CI so far considers these always-failed we can go on as-is,
> since in the worst case non-x86 will stay that way until we further improve.

See above, this does not seem realistic in Debian. :/

> P.S. unfortunately the packaging repo doesn't contain the actual liburing
> source. Due to that I had to always ex/import from this repo onto a
> directory actually having the liburing source - is there any reason not to
> package it "as usual" with the source as in orig tarball present as well?

I find the workflow of keeping the upstream sources in the packaging
repos to be wrong-headed, and very confusing for people that are not
into Debian packaging. I've written about this elsewhere but probably
need to create a wiki page or similar to point to people that might be
curious why. :)


> From a08a5f39885e965994bf84e537956a559ac7ca46 Mon Sep 17 00:00:00 2001
> From: Christian Ehrhardt 
> Date: Tue, 30 Jun 2020 14:54:44 +0200
> Subject: [PATCH 3/6] d/t/test-build: io_uring-link no more exists as example,
>  but link-cp does

Thanks, in 0.7-1, I reworked the autopkgtest to use a loop and fixed
this by renaming the example name.

So thanks for all the patches, although as it is now, I think I'm
unlikely to pull in the rest of the patches, given that this is currently
going to be a major burden until uring support stabilizes in the kernel
for all arches. Perhaps I'll add one autopkgtest running as root though,
but that's probably it.

Thanks,
Guillem



Bug#991896: 2.1.1 works

2021-09-18 Thread Peter Samuelson


Can confirm that Lukas's patch builds zfs 2.1.1 when I update abigail
build-dep to (>= 1.8) and unfuzz patches.

Seems to work, too, at least with the kernel I'm booted into,
5.13.0-trunk-amd64 from experimental.  (Which zfs 2.0.x does not
support.)

Peter



Bug#994626: lintian-brush 0.112 depends on python3-breezy (>= 3.2.1-1)

2021-09-18 Thread Stig Sandbeck Mathisen
Package: lintian-brush
Version: 0.112
Severity: normal
Tags: patch

Dear Maintainer,

The "lintian-brush" package uses Repository.get_revision_deltas from
python3-breezy.  This is not available in 3.1.0-8, but us available in 3.2.1-1.

The bug is only visible on a "stable" system using lintian-brush from
"unstable".


With lintian-brush 0.112 and python3-breezy 3.1.0-8 installed I get an error
after changes have been made, but before any git operation:

$ lintian-brush 
   
Traceback (most recent call last):
  File "/usr/bin/lintian-brush", line 33, in 
sys.exit(load_entry_point('lintian-brush==0.112', 'console_scripts', 
'lintian-brush')())
  File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", line 
328, in main
overall_result = run_lintian_fixers(
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 
1187, in run_lintian_fixers
result, summary = run_lintian_fixer(
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 
1041, in run_lintian_fixer
dch_guess = guess_update_changelog(
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 95, in guess_update_changelog
ret = _guess_update_changelog_from_branch(tree.branch, debian_path)
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 200, in _guess_update_changelog_from_branch
(changelog_only, other_only, mixed, dch_references) = _changelog_stats(
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 157, in _changelog_stats
get_deltas = branch.repository.get_revision_deltas
AttributeError: 'LocalGitRepository' object has no attribute 
'get_revision_deltas'


With lintian-brush 0.112 and python3-breezy 3.2.1-1 installed, lintian-brush
runs as expected, and makes the world a little bit better again.


$ lintian-brush   
[...]
Lintian tags fixed: {'out-of-date-standards-version', 
'package-uses-deprecated-debhelper-compat-version'}
[...]



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (499, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.21.3
ii  python3  3.9.2-3
ii  python3-breezy   3.2.1-1
ii  python3-debian   0.1.39
ii  python3-debmutate0.38
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.23-1
ii  python3-iniparse 0.4-3
ii  python3-iso8601  0.1.13-1
ii  python3-ruamel.yaml  0.16.12-2
ii  python3-tqdm 4.57.0-2
ii  python3-upstream-ontologist  0.1.22-1

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-2
ii  libdebhelper-perl13.3.4
ii  lintian  2.104.0
pn  ognibuild
ii  python3-asyncpg  0.21.0-1+b2
ii  python3-bs4  4.9.3-1
ii  python3-docutils 0.16+dfsg-4
ii  python3-levenshtein  0.12.2-1
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-markdown 3.3.4-1
ii  python3-pyinotify0.9.6-1.3
ii  python3-tomlkit  0.6.0-2

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

-- no debconf information
>From cb8cd33862370f263f12c02bb6badfaecb23d802 Mon Sep 17 00:00:00 2001
From: Stig Sandbeck Mathisen 
Date: Sat, 18 Sep 2021 23:06:33 +0200
Subject: [PATCH] Bump dependency on python3-breezy

Class "Repository" does not have get_revision_deltas in 3.1.0
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 64318d3..60ba1e2 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: bash-completion,
dos2unix,
python3-all,
python3-bs4,
-   python3-breezy (>= 3.1.0-8),
+   python3-breezy (>= 3.2.1-1),
python3-breezy.tests,
python3-dulwich (>= 0.19.7),
python3-distro-info,
-- 
2.30.2



Bug#994625: ITP: carl9170fw -- libre firmware for AR9170 USB wireless adapters

2021-09-18 Thread John Scott
Package: wnpp
Severity: wishlist
Owner: John Scott 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org
Control: block -1 by 986778
Control: block 890601 by -1
Control: affects -1 linux-firmware-free

* Package name    : carl9170fw
  Version : 1.9.9-399-gcd480b9
  Upstream Author : Linux wireless maintainers 
* URL : https://github.com/chunkeey/carl9170fw
* License : mostly GPLv2-only
  Programming Lang: C
  Description : libre firmware for AR9170 USB wireless adapters

This is carl9170, the libre firmware for Qualcomm Atheros's AR9170
802.11n USB wireless adapters that complements the carl9170 Linux
driver.

carl9170 is already shipped in firmware-linux-free, but the primary
objective of transitioning it into this new source package is to get it
building from source. This is possible with the SuperH bare-metal cross
toolchain I'm packaging.

I will need sponsorship for this package (and am currently seeking
sponsors for the cross toolchain too); the Kernel Team may help with
the former. Regardless, co-maintainers/uploaders are welcome and I'd be
glad to help prospective contributors get adapters, as they can be a
little tricky to find.


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


Bug#989000: distutils: missing CFLAGS/LDFLAGS from environment

2021-09-18 Thread Samuel Thibault
Matthias Klose, le ven. 17 sept. 2021 12:18:53 +0200, a ecrit:
> On 9/12/21 9:37 PM, Samuel Thibault wrote:
> > Hello,
> > 
> > From: Debian FTP Masters 
> >>* Fix CFLAGS in the python3.x-config scripts. Closes: #992669, #989000.
> > 
> > Thanks for fixing CFLAGS!
> > 
> > However LDFLAGS are still missing:
> > 
> > Samuel Thibault, le sam. 22 mai 2021 23:10:16 +0200, a ecrit:
> >> blhc also notices that LDFLAGS is not getting included:
> >>
> >> https://salsa.debian.org/a11y-team/brltty/-/jobs/1660079
> >>
> >> 2438:LDFLAGS missing (-Wl,-z,now): x86_64-linux-gnu-gcc -pthread -shared 
> >> -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro 
> >> -g -fwrapv -O2 -g 
> >> -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
> >> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> >> -D_FORTIFY_SOURCE=2 ./../../../Bindings/Python/bindings.o ./brlapi.auto.o 
> >> -L./../../Programs -lbrlapi -lpthread -o 
> >> build/lib.linux-x86_64-3.9/brlapi.cpython-39-x86_64-linux-gnu.so
> > 
> > That is still the case, see for instance:
> > 
> > https://salsa.debian.org/a11y-team/brltty/-/jobs/1938826
> 
> I don't see these flags anymore in
> 
>   /usr/lib/python3.9/_sysconfigdata__x86_64-linux-gnu.py

They are there:

'BLDSHARED': 'x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 '
  '-Wl,-Bsymbolic-functions '
  ' -Wl,-z,relro -g '
  '-fwrapv -O2   ',

 'LDFLAGS': ' -Wl,-z,relro -g -fwrapv '
'-O2   ',

The command shown above is basically

$BLDSHARED $LDFLAGS $CFLAGS ./../../../Bindings/Python/bindings.o [...]

(where CFLAGS is indeed now properly coming from environment, but
LDFLAGS is still as set in _sysconfigdata__x86_64-linux-gnu.py and not
from the environment.

Samuel



Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

2021-09-18 Thread Pirate Praveen

Package: libreoffice
Version: 1:7.2.1-1
Severity: grave
Justification: the package is unusable

$ libreoffice
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error: 
/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: 
_ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE




Bug#963901: O: glm -- C++ library for OpenGL GLSL type-based mathematics

2021-09-18 Thread Andrea Pappacoda

> I intend to orphan the glm package.

Hi, I would like to maintain the glm package. I'm not a Debian 
maintainer, but I'm trying to become one (see 
https://mentors.debian.net/packages/uploader/and...@pappacoda.it/ ).


I've used glm in the past and upstream doesn't release often... A 
perfect place to start, right? :)


How can I start maintaining the package?

Thanks



Bug#994513: buster-pu: package debconf/1.5.71+deb10u1

2021-09-18 Thread Colin Watson
On Fri, Sep 17, 2021 at 12:16:21AM +0100, Colin Watson wrote:
> [ Tests ]
> The reproduction recipe in #994042 is worth testing with this change,
> though that isn't sufficient.  To test this bug directly, the simplest
> approach is to install whiptail and/or dialog before an upgrade from
> buster to bullseye, but then deliberately break them somehow (for
> example by using dpkg-divert to replace them with shell scripts that
> write something to standard error and then exit non-zero).
> 
> At the moment I've only done some very basic tests along these lines,
> but I'll do full upgrade tests before uploading, assuming this request
> is accepted.  With a point release coming up soon I thought I'd better
> get this request in now.

I've now done buster-to-bullseye upgrade tests after first installing my
patch, both with and without deliberately breaking whiptail/dialog, and
it behaves as expected in both cases.  (As explained in my original bug
report, it doesn't actually fix the upgrade issue in #994042, but would
fix other similar situations if we run into just the wrong ordering.)

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



Bug#994288: [Debichem-devel] Bug#994288: Bug#994288: libinchi1: feature request, add InChI trust, reference executable

2021-09-18 Thread Michael Banck
Hi,

On Thu, Sep 16, 2021 at 10:40:02AM +0300, Andrius Merkys wrote:
> Control: owner -1 !
> Control: tags -1 + pending
> 
> Hi Norwid,
> 
> On 2021-09-16 09:26, Norwid Behrnd wrote:
> >> Am I right to assume you are requesting here for the 'inchi_main'
> >> executable being included in Debian packages for inchi?
> > 
> > Yes, this is .true. and you are right.  If technical possible and
> > InChI trust's license permitting, I would like to install their .sdf
> > to InChI conversion packaged for Debian such that this may be run
> > from the CLI.
> 
> Thanks for clarification. I have just packaged the executable in a new
> binary package, libinchi-bin, it how has to pass the NEW queue.

A bit late, but maybe "inchi-bin" or even juust "inchi" would be also
appropriate?


Michael



Bug#991235:

2021-09-18 Thread Luca Olivetti

El 18/9/21 a les 20:08, Luca Olivetti ha escrit:

Maybe that was introduced as a fix for the recent vulnerability in 
mail-whois-lines.conf?

If so it's not going to work.


yes, that's it

https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm

unfortunately the "fix" breaks if one is using bsd-mailx (as I am), 
which, according to the report, doesn't suffer from the same vulnerability.




Bug#991235:

2021-09-18 Thread Luca Olivetti
The problem is that the "mail" commands in 
/etc/fail2ban/action.d/mail*.conf have a wrong "-E 'set escape'" option 
(it wasn't there before).

According to "man mail"

-E  Don't send messages with an empty body.


so, since -E doesn't take any option, it interprets "set" and "escape" 
as recipients.

I removed the "-E 'set escape'" from the command.
Maybe that was introduced as a fix for the recent vulnerability in 
mail-whois-lines.conf?

If so it's not going to work.



Bug#886263: There's an unreleased upstream fix for this

2021-09-18 Thread Distributed Shenanigans
I've had similar problems with piper. I tested with 0.5.1-1.

With libgtk3-nocsd0 3-1, this program (written in Python) uses CSD
regardless.

With libgtk3-nocsd0 git, the problem went away; piper used server-side
decorations.

Further testing quickly showed that the commit which fixes upstream issue 16
(https://github.com/PCMan/gtk3-nocsd/issues/16) is sufficient.



Bug#994620: ITP: python3-fbtftp -- fbtftp is Facebook's implementation of a dynamic TFTP server framework. It lets you create custom TFTP servers and wrap your own logic into it in a very simple manne

2021-09-18 Thread Luiz Amaral
Package: wnpp
Severity: wishlist
Owner: Luiz Amaral 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python3-fbtftp
  Version : 0.5
  Upstream Author : Angelo Failla 
* URL : https://github.com/facebook/fbtftp/
* License : (MIT)
  Programming Lang: (Python)
  Description : fbtftp is Facebook's implementation of a dynamic TFTP 
server framework. It lets you create custom TFTP servers and wrap your own 
logic into it in a very simple manner.

python3-fbtftp is a dependency of a TFTP proxy built by me that is used
to provision hardware at our datacenter. We currently build it
internally and publish it on our internal repository, but I figured this
would be a nice opportunity to get started with official Debian
Packaging.

I need a sponsor for this package.



Bug#985196:

2021-09-18 Thread Luca Olivetti
I just upgraded my lacie ns2 (armel) from buster to bullseye and found 
the same problem.

The workaround from Dave Holland did the job.



Bug#994603: [Pkg-javascript-devel] Bug#994603: Bug#994603: errormsg

2021-09-18 Thread Jonas Smedegaard
Quoting Jérémy Lal (2021-09-18 18:25:10)
> node-stringprep is totally abandoned. It would be so great to drop 
> that package.

Agreed - no need to keep that alive.


 - Jonas

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

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

signature.asc
Description: signature


Bug#994619: xpra: recommends gir1.2-appindicator3-0.1 which is no longer available

2021-09-18 Thread Stephen Kitt
Package: xpra
Version: 3.0.13+dfsg1-1
Severity: normal

Dear Maintainer,

xpra recommends gir1.2-appindicator3-0.1 but the latter is no longer available.

Regards,

Stephen


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 xpra depends on:
ii  adduser   3.118
ii  gir1.2-gtk-3.03.24.24-4
ii  init-system-helpers   1.60
ii  libavcodec58  7:4.3.2-0+deb11u2
ii  libavformat58 7:4.3.2-0+deb11u2
ii  libavutil56   7:4.3.2-0+deb11u2
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpam0g  1.4.0-9
ii  libswscale5   7:4.3.2-0+deb11u2
ii  libsystemd0   247.3-6
ii  libturbojpeg0 1:2.0.6-4
ii  libvpx6   1.9.0-1
ii  libwebp6  0.6.1-2.1
ii  libx11-6  2:1.7.2-1
ii  libx264-160   2:0.160.3011+gitcde9a93-2.1
ii  libx265-192   3.4-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxkbfile1   1:1.1.0-1
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python3   3.9.2-3
ii  python3-cairo 1.16.2-4+b2
ii  python3-gi3.38.0-2
ii  python3-rencode   1.0.6-1+b3
ii  x11-xserver-utils 7.7+8
ii  xserver-xorg-video-dummy  1:0.3.8-1+b1
ii  xvfb  2:1.20.11-1

Versions of packages xpra recommends:
pn  gir1.2-appindicator3-0.1  
ii  keyboard-configuration1.205
ii  openssh-client1:8.4p1-5
ii  python3-brotli1.0.9-2+b2
ii  python3-cpuinfo   5.0.0-2
ii  python3-dbus  1.2.16-5
ii  python3-dns   3.2.1-1
ii  python3-gssapi1.6.1-1+b3
ii  python3-kerberos  1.1.14-3.1+b3
ii  python3-lz4   3.1.3+dfsg-1
ii  python3-lzo   1.12-3+b4
ii  python3-numpy 1:1.19.5-1
ii  python3-opengl3.1.5+dfsg-1
ii  python3-paramiko  2.7.2-1
ii  python3-pil   8.1.2+dfsg-0.3
ii  python3-setproctitle  1.2.1-1+b1
ii  python3-uritools  3.0.0-2
ii  python3-xdg   0.27-2
ii  python3-zeroconf  0.26.1-1
ii  ssh-askpass   1:1.2.4.1-10+b1

Versions of packages xpra suggests:
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
pn  cups-pdf   
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  gstreamer1.0-plugins-base  1.18.4-2
ii  gstreamer1.0-plugins-good  1.18.4-2
ii  gstreamer1.0-plugins-ugly  1.18.4-2
ii  openssh-server 1:8.4p1-5
ii  pulseaudio 14.2-2
ii  pulseaudio-utils   14.2-2
pn  python3-avahi  
ii  python3-cryptography   3.3.2-1
ii  python3-cups   2.0.1-4+b1
ii  python3-gst-1.01.18.3-1
ii  python3-netifaces  0.10.9-0.2+b3
pn  python3-opencv 
ii  python3-pyinotify  0.9.6-1.3
pn  python3-pyopencl   
pn  python3-uinput 
ii  python3-yaml   5.3.1-5
pn  v4l2loopback-dkms  

-- no debconf information



Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

2021-09-18 Thread Andreas Tille
On Sat, Sep 18, 2021 at 05:54:59PM +0200, Mattia Rizzolo wrote:
> On Fri, Sep 17, 2021 at 03:58:55PM -0700, Sean Whitton wrote:
> > > Gentle ping to Policy editors for that seconding :-)  It would be really
> > > nice to move this info from tribal knowledge to documentation.
> > 
> > There's no patch to be seconded ...?

I need to admit that I'm not up for such a patch despite the fact
that I was involved into Files-Excluded invention.  I'm lagging
way too much behind my usual Debian work (and this is for a reason
which I announced some time ago in debian-private.
 
> I'm interested in seconding such patch.
> 
> For whoever is going to write it, remember to talk about:
>  * Files-Excluded-$component
>  * Files-Included
> which are even less-known bits of the "specification" (Files-Included is
> also *very* new, in Debian times).

Ahhh, nice to learn about this.  I never heard about it before.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Bug#994618: abcm2ps: please package release 8.14.12

2021-09-18 Thread Nicolas Boulenguez
Package: abcm2ps
Version: 8.14.11
Severity: wishlist
Tags: patch

Hello.
The attached patches update abcm2ps to version 8.14.12.
The first one can be regenerated by uscan and gbp.
Please upload them to the archive.
From: Nicolas Boulenguez 
Subject: [PATCH 1/2] Import abcm2ps_8.14.12.orig.tar.gz

--- a/abcparse.c
+++ b/abcparse.c
@@ -3,7 +3,7 @@
  *
  * This file is part of abcm2ps.
  *
- * Copyright (C) 1998-2020 Jean-François Moine (http://moinejf.free.fr)
+ * Copyright (C) 1998-2021 Jean-François Moine (http://moinejf.free.fr)
  * Adapted from abc2ps, Copyright (C) 1996-1998 Michael Methfessel
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -2040,10 +2040,10 @@
 		case CHAR_NOTE:
 			p = parse_note(p - 1, flags);
 			flags &= ABC_F_GRACE;
-			parse.last_sym->u.note.slur_st = slur;
-			slur = 0;
-			if (parse.last_sym->u.note.notes[0].len > 0) /* if not space */
-curvoice->last_note = parse.last_sym;
+			if (slur && parse.last_sym->u.note.notes[0].len) {
+parse.last_sym->u.note.slur_st = slur;
+slur = 0;
+			}
 			break;
 		case CHAR_SLASH:		/* '/' */
 			if (flags & ABC_F_GRACE)
@@ -2078,9 +2078,10 @@
 			if (p[1] != ':') {
 p = parse_note(p - 1, flags); /* chord */
 flags &= ABC_F_GRACE;
-parse.last_sym->u.note.slur_st = slur;
-slur = 0;
-curvoice->last_note = parse.last_sym;
+if (slur && parse.last_sym->u.note.notes[0].len) {
+	parse.last_sym->u.note.slur_st = slur;
+	slur = 0;
+}
 break;
 			}
 
@@ -2271,7 +2272,6 @@
 			}
 			if (p[-1] == '<')
 i = -i;
-			broken_rhythm(curvoice->last_note, i);
 			curvoice->last_note->u.note.brhythm = i;
 			break;
 		case CHAR_IGN:			/* '*' & '`' */
@@ -2496,8 +2496,11 @@
 
 do_brhythm:
 	if (curvoice->last_note
-	 && curvoice->last_note->u.note.brhythm != 0)
+	 && curvoice->last_note->u.note.brhythm != 0) {
+		broken_rhythm(curvoice->last_note,
+curvoice->last_note->u.note.brhythm);
 		broken_rhythm(s, -curvoice->last_note->u.note.brhythm);
+	}
 add_deco:
 	if (dc.n > 0) {
 		memcpy(s->abc_type != ABC_T_MREST ? >u.note.dc
@@ -2511,6 +2514,8 @@
 		syntax("Not a note in grace note sequence", p);
 		goto err;
 	}
+	if (s->u.note.notes[0].len > 0) /* if not space */
+		curvoice->last_note = s;
 	return p;
 
 err:
--- a/buffer.c
+++ b/buffer.c
@@ -29,7 +29,7 @@
 static float ln_scale[BUFFLN];	/* scale of buffered lines */
 static signed char ln_font[BUFFLN];	/* font of buffered lines */
 static float cur_lmarg = 0;	/* current left margin */
-static float min_lmarg, max_rmarg;	/* margins for -E/-g */
+static float max_rmarg;		/* margins for -E/-g */
 static float cur_scale = 1.0;	/* current scale */
 static float maxy;		/* usable vertical space in page */
 static float remy;		/* remaining vertical space in page */
@@ -129,8 +129,7 @@
 /* (used only with eps -E and svg -g) */
 void marg_init(void)
 {
-	min_lmarg = cfmt.pagewidth;
-	max_rmarg = cfmt.pagewidth;
+	cur_lmarg = max_rmarg = 0;
 }
 
 /* -- initialize the postscript file (PS or EPS) -- */
@@ -141,11 +140,10 @@
 	char version[] = "/creator [(abcm2ps) " VERSION "] def";
 
 	if (epsf) {
-		cur_lmarg = min_lmarg - 10;
 		fprintf(fout, "%%!PS-Adobe-2.0 EPSF-2.0\n"
 			"BoundingBox: 0 0 %.0f %.0f\n",
 			((p_fmt->landscape ? p_fmt->pageheight : p_fmt->pagewidth)
-- cur_lmarg - max_rmarg + 10) * PPI_96_72,
+- cur_lmarg - max_rmarg) * PPI_96_72,
 			-bposy * PPI_96_72);
 		marg_init();
 	} else {
@@ -233,7 +231,6 @@
 /* -- initialize the svg file (option '-g') -- */
 static void init_svg(char *str)
 {
-	cur_lmarg = min_lmarg - 10;
 	output = svg_output;
 #if 1 //fixme:test
 	if (file_initialized > 0)
@@ -241,7 +238,7 @@
 #endif
 	define_svg_symbols(str, nepsf,
 		(p_fmt->landscape ? p_fmt->pageheight : p_fmt->pagewidth)
-- cur_lmarg - max_rmarg + 10,
+- cur_lmarg - max_rmarg,
 		-bposy);
 	file_initialized = 1;
 	user_ps_write();
@@ -732,7 +729,6 @@
 		close_fout();
 	else
 		file_initialized = 0;
-	cur_lmarg = 0;
 	cur_scale = 1.0;
 }
 
@@ -937,12 +933,6 @@
 	ln_buf[ln_num] = mbf;
 	ln_pos[ln_num] = multicol_start == 0 ? bposy : 1;
 	ln_lmarg[ln_num] = cfmt.leftmargin;
-	if (epsf) {
-		if (cfmt.leftmargin < min_lmarg)
-			min_lmarg = cfmt.leftmargin;
-		if (cfmt.rightmargin < max_rmarg)
-			max_rmarg = cfmt.rightmargin;
-	}
 	ln_scale[ln_num] = cfmt.scale;
 	ln_font[ln_num] = outft;
 	ln_num++;
--- a/configure
+++ b/configure
@@ -1,17 +1,17 @@
 #! /bin/sh
 
 # (automatic update)
-VERSION=8.14.11
-VDATE=2020-12-05
+VERSION=8.14.12
+VDATE=2021-07-14
 
-CC=gcc
-PKG_CONFIG=pkg-config
-CFLAGS="-g -O2 -Wall -pipe"
+: "${CC:=gcc}"
+: "${PKG_CONFIG:=pkg-config}"
+CFLAGS="-g -O2 -Wall -pipe $CFLAGS"
 
 srcdir=.
-prefix=/usr/local
+: "${prefix=/usr/local}"
 
-INSTALL="/usr/bin/install -c"
+: "${INSTALL:=/usr/bin/install -c}"
 
 if test -f ./custom; then
 	. ./custom
@@ -58,19 +58,13 @@
 	DEFAULT_FDIR="$prefix/share/abcm2ps"
 fi
 
-if which $PKG_CONFIG > /dev/null ; then
-	if $PKG_CONFIG --exists freetype2 ; then
-	

Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Hilmar Preuße

Am 18.09.2021 um 12:01 teilte Salvatore Bonaccorso mit:

On Sat, Sep 18, 2021 at 11:09:18AM +0200, Chris Hofstaedtler wrote:

* Chris Hofstaedtler  [210904 13:27]:

* Hilmar Preuße  [210903 10:42]:


Hi,


Try here: https://freeshell.de/hille42/993173/


I have tried these packages out (on buster, obviously), and can
confirm they work as expected. Also together with proftpd-mod-vroot.


Do you think this could make it into the next stable point release?


I think the issue can go in via a point release indeed. The planning
has been announced as
https://lists.debian.org/debian-live/2021/09/msg00026.html and
https://lists.debian.org/debian-live/2021/09/msg00027.html FWIW.


I'll try to upload ASAP.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature


Bug#994603: [Pkg-javascript-devel] Bug#994603: errormsg

2021-09-18 Thread Jérémy Lal
node-stringprep is totally abandoned. It would be so great to drop that
package.


Bug#986230: davfs2: After silent crash of mount.davfs background process, accessing user space program hangs busy

2021-09-18 Thread Pelzi
I cannot reproduce that behaviour nor did it happen ever since. My speculation 
is that some trouble on WebDAV server side (nextcloud) may have caused the 
crash, but I was unable to nail down the exact operation where that crash did 
happen.

I still believe it was worth the effort to stabilize the kernel (fuse module) 
against crashed user processes. Looking at the existing report 
(https://bugzilla.kernel.org/show_bug.cgi?id=115971), I’d like to add that the 
impact I observed was even more severe:
- a user space program (mv) accessing the affected mount was shown as hanging 
busy, consuming CPU
- it was *not* possible to kill this process
- the status of the process did not seem to match its actual state
- it was *not* possible to unmount or force unmount the mount point
- the only means to recover the whole machine from this state has been to 
reboot, which is quite drastic IMHO.

Far from being an expert, to me this looks like broken error handling in the 
fuse kernel module. Instead of returning an I/O error to the calling program 
(mv), the syscall seems to be looping around busy.

I’m not sure how to deal with this issue - it seems it is less an issue of 
davfs2 but rather of the fuse kernel module?



Bug#994613: [Pkg-javascript-devel] Bug#994613: nodejs salsa ci fail

2021-09-18 Thread Jérémy Lal
Le sam. 18 sept. 2021 à 16:33, Bastien Roucariès <
roucaries.bast...@gmail.com> a écrit :

> Package: nodejs
> Version: 12.22.5~dfsg-2
> Severity: important
>
> Dear Maintainer,
>
> Nodejs salsa ci fail. It seems they are difference between debci and salsa.
>
> Therefore some test should be disabled on salsa
>

The two failing tests are both expecting binding to a privileged port
raises a EACCES error,
which does not happen in salsa ci. Which is odd !

Jérémy


Bug#994617: h5py: please be more forgiving about mismatching HDF5 versions

2021-09-18 Thread Mattia Rizzolo
Package: python3-h5py
Version: 3.3.0-2
Severity: minor

Dear maintainer,

I'm currently seeting this while running a python's package testsuite:

=== warnings summary ===
../../../../../usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/__init__.py:36

  /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/__init__.py:36: 
UserWarning: h5py is running against HDF5 1.10.7 when it was built against 
1.10.6, this may cause problems
_warn(("h5py is running against HDF5 {0} when it was built against {1}, "


-- Docs: https://docs.pytest.org/en/stable/warnings.html


Now, whilst I appreciate that might be true for really different
versions, the concept of ABI is there for a reason, and I trust the
Debian's package version restrictions to prevent me from installing a
combination of hdf5 and h5py that is incompatible.

As such, I'd ask if you could either disable that warning, or at least
make it emit is only when there is a really different version that could
indeed cause problem.

Thank you.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#994582: also in bullseye, has to do with python version?

2021-09-18 Thread Jaap van Wingerde
This bug appears also in bullseye.

According to AgNitrate on
 it has
to do with the python version:
"AgNitrate (agnitrate) wrote on 2020-05-27: #3
Ubuntu 20.04 ships with Python 3.8, which Deluge doesn't seem to play
well with. If you update python3 to point to Python 3.7, it should
start up fine."

jaap@jaap:~$ deluge-gtk
Unhandled error in Deferred:
17:13:33 [CRITICAL][twisted   :154 ] Unhandled
error in Deferred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/log.py", line 87, in
exception yield LoggingLoggerClass.exception(self, msg, *args, **kwargs)
  File "/usr/lib/python3.9/logging/__init__.py", line 1477, in exception
self.error(msg, *args, exc_info=exc_info, **kwargs)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
1613, in unwindGenerator return _cancellableInlineCallbacks(gen)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
1529, in _cancellableInlineCallbacks _inlineCallbacks(None, g, status)
---  ---
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
1418, in _inlineCallbacks result = g.send(result)
  File "/usr/lib/python3/dist-packages/deluge/log.py", line 79, in error
yield LoggingLoggerClass.error(self, msg, *args, **kwargs)
  File "/usr/lib/python3.9/logging/__init__.py", line 1471, in error
self._log(ERROR, msg, args, **kwargs)
  File "/usr/lib/python3.9/logging/__init__.py", line 1573, in _log
fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel)
builtins.TypeError: findCaller() takes from 1 to 2 positional arguments
but 3 were given

Temporarily disabling observer LegacyLogObserverWrapper(>) due to exception: [Failure instance:
Traceback: : findCaller() takes from 1 to 2
positional arguments but 3 were given
/usr/lib/python3/dist-packages/twisted/internet/defer.py:1418:_inlineCallbacks
/usr/lib/python3/dist-packages/twisted/internet/defer.py:962:__del__
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit ---
 ---
/usr/lib/python3/dist-packages/twisted/logger/_observer.py:131:__call__
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:93:__call__
/usr/lib/python3/dist-packages/deluge/log.py:204:emit
/usr/lib/python3.9/logging/__init__.py:1489:critical
/usr/lib/python3.9/logging/__init__.py:1573:_log ] Traceback (most
recent call last): File
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418,
in _inlineCallbacks result = g.send(result) File
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 962,
in __del__ log.failure(format, File
"/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 190,
in failure self.emit(level, format, log_failure=failure, **kwargs) File
"/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 144,
in emit self.observer(event) ---  --- File
"/usr/lib/python3/dist-packages/twisted/logger/_observer.py", line 131,
in __call__ observer(event) File
"/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 93, in
__call__ self.legacyObserver(event) File
"/usr/lib/python3/dist-packages/deluge/log.py", line 204, in emit
getattr(LoggingLoggerClass, event_dict['log_level'].name)( File
"/usr/lib/python3.9/logging/__init__.py", line 1489, in critical
self._log(CRITICAL, msg, args, **kwargs) File
"/usr/lib/python3.9/logging/__init__.py", line 1573, in _log fn, lno,
func, sinfo = self.findCaller(stack_info, stacklevel)
builtins.TypeError: findCaller() takes from 1 to 2 positional arguments
but 3 were given
jaap@jaap:~$



Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition

2021-09-18 Thread Mattia Rizzolo
On Fri, Sep 17, 2021 at 03:58:55PM -0700, Sean Whitton wrote:
> On Fri 17 Sep 2021 at 06:24PM -04, Nicholas D Steeves wrote:
> > Sean Whitton  writes:
> >> On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote:
> >>> Is this truly the case that all that's needed is a new patch? Can we get
> >>> an official ACK from one of the policy editors? I'd be happy to re-write
> >>> the original patch to apply against HEAD if that's all that is required.
> >>
> >> Well, it would need seconding, but otherwise, ACK.
> >>
> >> Thank you for your interest.
> >>
> >
> > Gentle ping to Policy editors for that seconding :-)  It would be really
> > nice to move this info from tribal knowledge to documentation.
> 
> There's no patch to be seconded ...?

I'm interested in seconding such patch.

For whoever is going to write it, remember to talk about:
 * Files-Excluded-$component
 * Files-Included
which are even less-known bits of the "specification" (Files-Included is
also *very* new, in Debian times).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#994577: lintian: node-* arch:all package should depends on nodejs:any and b-d on nodejs:native

2021-09-18 Thread Bastien ROUCARIES
Le sam. 18 sept. 2021 à 16:57, Mattia Rizzolo  a écrit :

> (this reply is not related to lintian directly)
>
> On Fri, Sep 17, 2021 at 09:34:43PM +, Bastien Roucariès wrote:
> > In order to improve cross build of nodejs ecosystem, node-* arch:all
> package
> > should depends on nodejs:any and b-d on nodejs:native
>
> IMHO, you should make your tooling produce this "nodejs:any" binary
> dependency, instead of having each package have it manually listed in
> d/control (see ${perl:Depends} as an example, since, it's actually the
> very same thing, producing perl:any dependencies).
>

Bug already opened. Thanks for thé idea

>
> > Maybe this test should be restricted to ma: foreign package
>
> It shouldn't be IMHO.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>


Bug#990994: llvm-12-tools cannot be installed for a foreign architecture

2021-09-18 Thread Michel Dänzer
On 2021-09-18 14:41, Helmut Grohne wrote:
> 
> So the real goal is cross building using clang I guess. Please correct
> me if that's wrong.

My main motivation for this bug report is only installing llvm-*-dev for 
foreign architectures, for cross building Mesa (in its upstream CI).

That said, cross building using clang might be useful for Mesa's CI in the 
future as well.


> I can immediately identify two problems with foreign installation of
> llvm-V-dev. That's certainly not exhaustive, but each of them is a
> show-stopper. It's the dependencies on llvm-V-tools and on llvm-V. The
> former was already evident from the bug report. The latter is an issue,
> because a foreign llvm-V-dev will pull a foreign llvm-V, which contains
> all the /usr/bin/llvm-*-V tools for a foreign architecture and we'll be
> unable to run them. So it might become installable, but in a useless
> way.

Not always useless. In particular, consider cases like installing 
llvm-*-dev:i386 on an amd64 host.

In Mesa's CI, it even works with ppc64el & s390x packages on amd64 hosts, by 
transparently running foreign binaries via qemu-user-static.


> Given the length of this mail, I guess nobody makes it to the end. I can
> write arbitrary nonsense here and nobody will notice.

Nice try. :)


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer



Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

2021-09-18 Thread Diego M. Rodriguez
On Sat, 18 Sep 2021 05:06:59 +0200 Jeroen Ploemen  wrote:
> It does. Copyrights have expiry dates too, so the most recent year matters.

Thanks - I updated the copyright line in order to include the most
recent year as well, along with the comment.

-- 
Diego M. Rodriguez



Bug#994610: cryptsetup: creation/cleanup of /etc/crypttab

2021-09-18 Thread Guilhem Moulin
On Sat, 18 Sep 2021 at 17:04:41 +0200, Guilhem Moulin wrote:
> I don't see why it makes more sense to og-rwx /etc/crypttab by default
> compared to /etc/fstab or /etc/systemd/system.  If that makes sense in
> YOUR environment, then YOU are free to do it manually

Note however that if cryptsetup-initramfs is installed, and some disks
need to be unlocked at early boot, then a crypttab snippet is included
in the initramfs image.  That image is world-readable by default, so
extra steps need to be taken not to leak data.  Perhaps update-initramfs
should error out when it's about to generate a world-readable image
containing files/directories with restrictions, but it doesn't AFAIK.

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#994616: xfce4-power-manager: On 'suspend' : locking only occurs after resume

2021-09-18 Thread Olaf Skibbe
Package: xfce4-power-manager
Version: 4.16.0-1
Severity: important
Tags: none
X-Debbugs-Cc: n...@kravcenko.com

Dear Maintainer,

On a Lenovo X260 runing Debain bulseye, the Power Manager settings are:

"When laptop lid is closed: suspend"
"Lock screen when system is going to sleep"

When I close the lid, the computer suspends as required. When I open the lid
again I see the unlocked session. Only after a few seconds, the screen is
locked.

I would have expected that the screen is locked before the suspend.

I consider this bug serious since crucial data might be displayed to
unauthorized persons.

The bug seems to be known at XFCE, see
https://bugzilla.xfce.org/show_bug.cgi?id=15929
A patch is provided there.

This behaviour started after the upgrade from Debian buster to bullseye. With
buster the problem did not occur.

Kind regards and thanks for your nice work,
Olaf


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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libupower-glib3   0.99.11-2
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxrandr22:1.5.1-1
ii  upower0.99.11-2
ii  xfce4-power-manager-data  4.16.0-1

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  247.3-6
ii  xfce4-power-manager-plugins  4.16.0-1

xfce4-power-manager suggests no packages.



Bug#994600: mirror submission for mirror.johnnybegood.fr

2021-09-18 Thread Valentin DI BETTA
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.johnnybegood.fr
Type: leaf
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Valentin DI BETTA 
Country: FR France
Location: Paris




Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/mirror.johnnybegood.fr



Bug#994532: Installer only gives internal hand drive install option not external USB drive

2021-09-18 Thread Mattia Rizzolo
Control: reassign -1 installation-reports

On Fri, Sep 17, 2021 at 06:47:00PM +0800, Ross Maloney wrote:
> Package: debian-testing-amd64-netinst.iso

Reassigning to a "real" package (BCCing the installer team).

> Hello.
> 
> I have tried to install Bullseye from both the standard 11.0.0 release and
> also the daily builds of 16 and 17 of this month.  I am installing on a
> MacPro 2019 using a boot image which I dd from the netinst.iso posted
> images.  Everything functions normally in the non-graphical install until
> the manual partitioning of the disk phase.  At this stage, the USB drive I
> have connected to the MacPro is not seen.  This is the problem. 
> Installation on this external drive is the aim of the installation.
> 
> I have previously installed Bullseye sid on this hardware configuration. 
> That image dated 12 October 2020 gives the identification 5.8.0-2-amd64.
> This problem appears to be related to the installer.  I have checked the
> hardware configuration by installing the old October 2020 image successfully
> today.
> 
> Is there a reason the installer now in use only offers limitted drive
> options, or is this a bug?
> 
> Regards,
> 
> Ross Maloney

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#994610: cryptsetup: creation/cleanup of /etc/crypttab

2021-09-18 Thread Guilhem Moulin
On Sat, 18 Sep 2021 at 16:30:38 +0200, Christoph Anton Mitterer wrote:
> On Sat, 2021-09-18 at 16:04 +0200, Guilhem Moulin wrote:
>> src:cryptsetup isn't the only consumer of /etc/crypttab, so this is a
>> wontfix.
> 
> Who else uses it that can work without cryptsetup? Systemd via
> libcryptsetup?

crypttab is part of our public API, and any (packaged or not) software
can hook into into without without explicitly depending on
cryptsetup-bin let alone cryptsetup.  Removing that API is a wontfix.

> Then perhaps better to have a -common package that all can depend
> upon, than leaving cruft behind after purge?

I don't think the cleanup is worth the extra metadata and package cruft
overhead…

> And still, one could tighten the permissions.

I don't see why it makes more sense to og-rwx /etc/crypttab by default
compared to /etc/fstab or /etc/systemd/system.  If that makes sense in
YOUR environment, then YOU are free to do it manually; src:cryptsetup
control files shouldn't change existing permission/ownership (it'd be a
valid bug if they do).  Moreover tighter permissions have arguably
undesired side effects, such as broken bash completion for `sudo
cryptdisks_start `.

Also FWIW /etc/crypttab is typically created by d-i, at least when a
using the “encrypted root FS” layout.  I don't have data at hand to back
that up, but I believe that preinst snippet is usually a noop.

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings

2021-09-18 Thread Diego M. Rodriguez
Control: tag -1 - moreinfo

Hello Jeroen,

> copyright:
>  * various copyright holders listed in d/copyright don't have their names
>appear anywhere in the sources. Please refresh and/or add comment
>fields detailing what the affected entries are based on.

The extra copyright holders were added during the initial ITP review
[1], and it seems they corresponded to the upstream git contributors to
each individual file by the time of the 0.5-3 release. I have refreshed
d/copyright to ensure it matches the authors explicitly mentioned in
upstream current LICENSE file and other headers.

> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Pinging back after tackling the rest of the issues too - thanks (once
again)!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#27

-- 
Diego M. Rodriguez



Bug#994615: ITP: r-bioc-residualmatrix -- Creating a DelayedMatrix of Regression Residuals

2021-09-18 Thread Nilesh Patra
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Subject: ITP: r-bioc-residualmatrix -- Creating a DelayedMatrix of Regression 
Residuals
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: r-bioc-residualmatrix
  Version : 1.2.0
  Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/ResidualMatrix/
* License : GPL-3
  Programming Lang: GNU R
  Description : Creating a DelayedMatrix of Regression Residuals
 Provides delayed computation of a matrix of residuals after fitting a
 linear model to each column of an input matrix. Also supports partial
 computation of residuals where selected factors are to be preserved in the
 output matrix. Implements a number of efficient methods for operating on
 the delayed matrix of residuals, most notably matrix multiplication
 and calculation of row/column sums or means.

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



Bug#994614: telegram-desktop: segfault when opening conversation

2021-09-18 Thread twied
Package: telegram-desktop
Version: 2.9.2+ds-1
Severity: important
X-Debbugs-Cc: tw...@gmx.net

Dear Maintainer,

starting telegram, opening a conversation, telegram segfaults.

```
$ telegram-desktop

(telegram-desktop:7194): Telegram-WARNING **: 16:56:36.484: Application has
been built with foreign rlottie, animated emojis won't be colored to the
selected pack.

(telegram-desktop:7194): Telegram-WARNING **: 16:56:36.484: Application was
built without embedded fonts, this may lead to font issues. On Debian-based
systems, make sure you have the fonts-open-sans package installed
error: : cannot open
error: : cannot open
error: : cannot open
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
qt.svg: Error while inflating gzip file: SVG format check failed
Segmentation fault
```


-- Package-specific info:

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

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


Bug#994598: dh_dwz: pass -l/-L options

2021-09-18 Thread Matthias Urlichs
Package: debhelper
Version: 13.5.1
Severity: normal

"dwz" has limits which are too low for some programs, particularly when
they're heavy on C++ and templates and such stuff. Thus, dh_dwz needs -l/-L
options it can forward to dwz; see its manpage.

Seen when building the latest upstream version of PrusaSlicer.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (750, 'stable'), (700, 'oldstable'), (600, 'unstable'), (550, 
'oldoldstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.12.0-1
ii  dpkg 1.20.9
ii  dpkg-dev 1.20.9
ii  dwz  0.14-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.5.1
ii  libdpkg-perl 1.20.9
ii  man-db   2.9.4-2
ii  perl 5.32.1-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202003

-- no debconf information



Bug#994577: lintian: node-* arch:all package should depends on nodejs:any and b-d on nodejs:native

2021-09-18 Thread Mattia Rizzolo
(this reply is not related to lintian directly)

On Fri, Sep 17, 2021 at 09:34:43PM +, Bastien Roucariès wrote:
> In order to improve cross build of nodejs ecosystem, node-* arch:all package
> should depends on nodejs:any and b-d on nodejs:native

IMHO, you should make your tooling produce this "nodejs:any" binary
dependency, instead of having each package have it manually listed in
d/control (see ${perl:Depends} as an example, since, it's actually the
very same thing, producing perl:any dependencies).

> Maybe this test should be restricted to ma: foreign package

It shouldn't be IMHO.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#994610: cryptsetup: creation/cleanup of /etc/crypttab

2021-09-18 Thread Christoph Anton Mitterer
On Sat, 2021-09-18 at 16:04 +0200, Guilhem Moulin wrote:
> src:cryptsetup isn't the only consumer of /etc/crypttab, so this is a
> wontfix.

Who else uses it that can work without cryptsetup? Systemd via
libcryptsetup? Then perhaps better to have a -common package that all
can depend upon, than leaving cruft behind after purge?


And still, one could tighten the permissions.



Bug#994613: nodejs salsa ci fail

2021-09-18 Thread Bastien Roucariès
Package: nodejs
Version: 12.22.5~dfsg-2
Severity: important

Dear Maintainer,

Nodejs salsa ci fail. It seems they are difference between debci and salsa.

Therefore some test should be disabled on salsa

Bastien



Bug#994612: nodjes: Please fix nodejs debci regression

2021-09-18 Thread Bastien Roucariès
Package: nodjes
Version: 12.22.5~dfsg-3
Severity: serious

Dear Maintainer,

Debci fail with against 12.22.5~dfsg-2 with:
  duration_ms: 0.293
  severity: fail
  exitcode: 1
  stack: |-
assert.js:101
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected

+ 'EOVERFLOW'
- 'Unknown system error -75'
at /tmp/autopkgtest-
lxc.zt0_cfzb/downtmp/build.DQ4/src/test/parallel/test-uv-errno.js:21:10
at Array.forEach ()
at Object. (/tmp/autopkgtest-
lxc.zt0_cfzb/downtmp/build.DQ4/src/test/parallel/test-uv-errno.js:15:6)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:60:12)
at internal/main/run_main_module.js:17:47 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: 'EOVERFLOW',
  expected: 'Unknown system error -75',
  operator: 'strictEqual'
}
  ...

This RC bug is for blocking nodejs to unstable until we find the problem.

I do not find myself the problem -75 is for me  'EOVERFLOW', and I do not
understand why it build normally and why debci fail.



Bug#994611: node-sqlite3: Please remove architecture field

2021-09-18 Thread Bastien Roucariès
Package: node-sqlite3
Severity: minor

Dear Maintainer,

Buildd are clever and will not build this package is nodejs ins not ready

Please do not add architecture constraint



Bug#994610: cryptsetup: creation/cleanup of /etc/crypttab

2021-09-18 Thread Christoph Anton Mitterer
Package: cryptsetup
Version: 2:2.4.0-1
Severity: normal


Hi.

With respect to /etc/crypttab:
1) Right now it's created by cryptsetup.preinst, but never cleaned up on purge.

2) I'd suggest to create it readable by root only.


Could provide a patch for both, if it helps you.


Cheers,
Chris.



Bug#994168: Acknowledgement (aide-common: unexpected character: '/')

2021-09-18 Thread Marc Haber
tags #994168 confirmed
thanks

On Fri, Sep 17, 2021 at 07:22:46AM +0200, Jochen Pawletta wrote:
> I changed these 2 lines:
>   printf 
> "/var/cache/munin/www/%s/(index\\.html|%s/[-_[:alnum:]]+\\.(png|html))$ f 
> VarFile" "${DOMAIN}\\n" "${DHOST}"
>   printf "/var/lib/munin/%s/%s-.*\\.rrd$ f VarFile" "${DOMAIN}" 
> "${DHOST}\\n"
> 
> to this:
> 
>   printf 
> "/var/cache/munin/www/%s/(index\\.html|%s/[-_[:alnum:]]+\\.(png|html))$ f 
> VarFile\\n" "${DOMAIN}" "${DHOST}"
>   printf "/var/lib/munin/%s/%s-.*\\.rrd$ f VarFile\\n" "${DOMAIN}" 
> "${DHOST}"

Thanks for spotting this, fixed in git.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#994609: ITP: python-exhale -- Sphinx automated C++ API generation support

2021-09-18 Thread Timo Röhling
Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org, roehl...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-exhale
  Version : 
  Upstream Author : Stephen McDowell
* URL : https://exhale.readthedocs.io/en/latest/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Sphinx automated C++ API generation support

Exhale is a Sphinx extension that depends on the excellent Breathe
extension which enables parsing Doxygen documentation into the Sphinx
domain. Exhale provides a layer of automation, enabling launching
Doxygen and generating the full website all from your conf.py.

This package is a new dependency of CycloneDDS 0.8.0. I will package and
maintain it as part of the Python Team.


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmFF7RkACgkQ+C8H+466
LVnUuwwApQrc5TjTguqoBw/Ssne1Zet6IW6m7ojoiuznb23FF60nIyV7duzsuNQq
7l9+pD72tKCTAtD/6y8FiBysIWgCbbdMhcABMG3lptJ2dmZJgrD6mOOKXEecb+y7
ieaFbmzYE2meysXb7nHd/wfg3JGzjsMfZrpRPiTnX5B0vJ6v56vYPOSwsga15OVJ
n8u9XkAjPypw7jDcxgmWxmOAtk4c4iHu0SlWRnXnLDfXIC/TMboCAhvV6EeuLK38
PJHYuM+2a4EgBIaXn1wz/ZDetBhrwon42fRVAaTE/V2uH08N+uYPn3KrTHMVfp7d
4BJ46dCAyXI7uXCZY4PVs7UUps0Q1MmX51dY49OQeX71ysX//7hj0q/REsiT1FKo
SboUviunhR6dILXuBY1RZr4Qo3inqCboqRuPaduVQnw4iFEbk9iEGJhcCym0Z+Xy
QrwocIW1Elw43xZ7cCUXVKUQ4AibcytP3YOL2e5ZL66QCOXwCon73ijuQEbUhv03
F8kTmf9Y
=rUKn
-END PGP SIGNATURE-


Bug#994598: dh_dwz: pass -l/-L options

2021-09-18 Thread Niels Thykier
Control: tags -1 moreinfo

On Sat, 18 Sep 2021 12:39:34 +0200 Matthias Urlichs
 wrote:
> Package: debhelper
> Version: 13.5.1
> Severity: normal
> 
> "dwz" has limits which are too low for some programs, particularly when
> they're heavy on C++ and templates and such stuff. Thus, dh_dwz needs -l/-L
> options it can forward to dwz; see its manpage.
> 
> Seen when building the latest upstream version of PrusaSlicer.
> 
> 
> [...] 
Hi Matthias,

You can pass -l/-L to dwz by using:

override_dh_dwz:
   dh_dwz -- 

And thereby tuning dwz better to your concrete package.


Thanks,
~Niels



Bug#994608: ITP: python-lsp-flake8 -- Flake8 plugin for the Python Language Server

2021-09-18 Thread Jochen Sprickerhof
Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-flake8
  Version : 0.4.0
  Upstream Author : Randy Eckman
* URL : https://github.com/Richardk2n/pylsp-flake8
* License : Expat
  Programming Lang: Python
  Description : Flake8 plugin for the Python Language Server

Plugin to support the flake8 code checker in editors that support the Python 
Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-flake8



Bug#994607: ITP: python-pytest-xprocess -- pytest plugin for managing processes across test runs

2021-09-18 Thread Thomas Goirand
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-pytest-xprocess
  Version : 0.18.1
  Upstream Author : Holger Krekel 
* URL : https://github.com/pytest-dev/pytest-xprocess/
* License : Expat
  Programming Lang: Python
  Description : pytest plugin for managing processes across test runs

 Pytest has for objective to allow the developers to limit the boilerplate code
 around the tests, promoting the use of built-in mechanisms such as the assert
 keyword.
 .
 Pytest-xprocess is a pytest plugin for managing processes across test runs.



Bug#994606: ITP: python-lsp-isort -- Isort plugin for the Python Language Server

2021-09-18 Thread Jochen Sprickerhof
Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-isort
  Version : 0.2.2
  Upstream Author : Florian Mounier
* URL : https://github.com/paradoxxxzero/pyls-isort
* License : Expat
  Programming Lang: Python
  Description : Isort plugin for the Python Language Server

Plugin to support the isort import sorter in editors that support the
Python Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-isort



Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

2021-09-18 Thread Romain Francoise
Hi Adam,

On Sat, Sep 18, 2021 at 01:30:27PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Ok, uploaded. I noticed while I was doing the upload that I had left a
typo in the changelog entry and applied the following on top of the diff
you have already reviewed. Sorry about that.

Thanks!


diff -u tmux-3.1c/debian/changelog tmux-3.1c/debian/changelog
--- tmux-3.1c/debian/changelog  2021-09-11 23:24:41.0 +0200
+++ tmux-3.1c/debian/changelog  2021-09-18 15:02:56.0 +0200
@@ -1,11 +1,11 @@
 tmux (3.1c-1+deb11u1) bullseye; urgency=medium

-  * Cherry-pick commit 7a4aa14618 from upstream to fix race condition
+  * Cherry-pick commit 7a4aa14618 from upstream to fix a race condition
 which results in the config not being loaded if several clients are
 interacting with the server while it's initializing (upstream GitHub
 issue #2438, closes: #992202).

- -- Romain Francoise   Sat, 11 Sep 2021 23:24:41 +0200
+ -- Romain Francoise   Sat, 18 Sep 2021 15:02:56 +0200

 tmux (3.1c-1) unstable; urgency=medium



Bug#994605: ITP: python-lsp-mypy -- Mypy plugin for the Python Language Server

2021-09-18 Thread Jochen Sprickerhof
Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-lsp-mypy
  Version : 0.5.2
  Upstream Author : Richard Kellnberger, Tom van Ommeren
* URL : https://github.com/Richardk2n/pylsp-mypy
* License : Expat
  Programming Lang: Python
  Description : Mypy plugin for the Python Language Server

Plugin to support the Mypy static type checker in editors that support
the Python Language Server.

I intent to maintain the package as part of the Debian Python team here:

https://salsa.debian.org/python-team/packages/python-lsp-mypy



Bug#994603: errormsg

2021-09-18 Thread Bastien ROUCARIES
 debian/upstream

To fix the situation please do the following:
  1) Examine debian/copyright_* and referenced files
  2) Update debian/copyright as needed
  3) Replace debian/copyright_hints with debian/copyright_newhints
touch debian/stamp-copyright-check
touch debian/stamp-upstream-cruft
node-gyp configure
gyp info it worked if it ends with ok
gyp info using node-gyp@7.1.2
gyp info using node@12.22.5 | linux | x64
gyp info find Python using Python version 3.9.7 found at "/usr/bin/python3"
gyp info spawn /usr/bin/python3
gyp info spawn args [
gyp info spawn args   '/usr/share/nodejs/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/tmp/node-stringprep/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/share/nodejs/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/include/nodejs/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/usr/include/nodejs',
gyp info spawn args   '-Dnode_gyp_dir=/usr/share/nodejs/node-gyp',
gyp info spawn args
'-Dnode_lib_file=/usr/include/nodejs/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/tmp/node-stringprep',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info ok
touch debian/stamp-node-gyp-configure
V=1  CC="cc"  CXX="g++"  CFLAGS="-g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security"  CXXFLAGS="-g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security"  CPPFLAGS="-Wdate-time
-D_FORTIFY_SOURCE=2"  LDFLAGS="-Wl,-z,relro -Wl,-z,now" \
node-gyp build
gyp info it worked if it ends with ok
gyp info using node-gyp@7.1.2
gyp info using node@12.22.5 | linux | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[1] : on entre dans le répertoire « /tmp/node-stringprep/build »
  g++ -o Release/obj.target/node_stringprep/node-stringprep.o
../node-stringprep.cc '-DNODE_GYP_MODULE_NAME=node_stringprep'
'-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1'
'-DV8_DEPRECATION_WARNINGS=1' '-DV8_DEPRECATION_WARNINGS'
'-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_LARGEFILE_SOURCE'
'-D_FILE_OFFSET_BITS=64' '-D__STDC_FORMAT_MACROS'
'-DBUILDING_NODE_EXTENSION' -I/usr/include/nodejs/include/node
-I/usr/include/nodejs/src -I/usr/include/nodejs/deps/openssl/config
-I/usr/include/nodejs/deps/openssl/openssl/include
-I/usr/include/nodejs/deps/uv/include -I/usr/include/nodejs/deps/zlib
-I/usr/include/nodejs/deps/v8/include -I../../../usr/share/nodejs/nan
-fPIC -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fPIC -O3
-fno-omit-frame-pointer -fno-rtti -std=gnu++1y `pkg-config icu-i18n
--cflags` -MMD -MF
./Release/.deps/Release/obj.target/node_stringprep/node-stringprep.o.d.raw
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security -c
../node-stringprep.cc:20:26: error: ‘Handle’ has not been declared
   20 |   static void Initialize(Handle target)
  |  ^~
../node-stringprep.cc:20:32: error: expected ‘,’ or ‘...’ before ‘<’ token
   20 |   static void Initialize(Handle target)
  |^
../node-stringprep.cc:154:5: warning: dynamic exception specifications
are deprecated in C++11 [-Wdeprecated]
  154 | throw(UnknownProfileException)
  | ^
../node-stringprep.cc: In static member function ‘static void
StringPrep::Initialize(int)’:
../node-stringprep.cc:28:5: error: ‘target’ was not declared in this scope
   28 | target->Set(Nan::New("StringPrep").ToLocalChecked(),
t->GetFunction());
  | ^~
../node-stringprep.cc:28:81: error: no matching function for call to
‘v8::FunctionTemplate::GetFunction()’
   28 | target->Set(Nan::New("StringPrep").ToLocalChecked(),
t->GetFunction());
  |
 ^
In file included from /usr/include/nodejs/src/node.h:67,
 from ../../../usr/share/nodejs/nan/nan.h:56,
 from ../node-stringprep.cc:1:
/usr/include/nodejs/deps/v8/include/v8.h:6126:46: note: candidate:
‘v8::MaybeLocal
v8::FunctionTemplate::GetFunction(v8::Local)’
 6126 |   V8_WARN_UNUSED_RESULT MaybeLocal GetFunction(
  |  ^~~
/usr/include/nodejs/deps/v8/include/v8.h:6126:46: note:   candidate
expects 1 argument, 0 provided
../node-stringprep.cc: In static member function ‘static
Nan::NAN_METHOD_RETURN_TYPE
StringPrep::New(Nan::NAN_METHOD_ARGS_TYPE)’:
../node-stringprep.cc:48:48: error: no matching function for call to

Bug#994604: gimp: Gimp crashes when exiting at the end of the batch process

2021-09-18 Thread Adrian
Package: gimp
Version: 2.10.22-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gimp depends on:
ii  gimp-data2.10.22-4
ii  graphviz 2.42.2-5
ii  libaa1   1.4p5-48
ii  libbabl-0.1-01:0.1.82-1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgegl-0.4-01:0.4.26-2
ii  libgexiv2-2  0.12.1-1
ii  libgimp2.0   2.10.22-4
ii  libglib2.0-0 2.66.8-1
ii  libgs9   9.53.3~dfsg-7+deb11u1
ii  libgtk2.0-0  2.24.33-2
ii  libgudev-1.0-0   234-1
ii  libharfbuzz0b2.7.4-1
ii  libheif1 1.11.0-1
ii  libilmbase25 2.5.4-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjson-glib-1.0-0   1.6.2-1
ii  liblcms2-2   2.12~rc1-2
ii  liblzma5 5.2.5-2
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.4-2
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpoppler-glib8 20.09.0-3.1
ii  librsvg2-2   2.50.3+dfsg-1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2.1
ii  libwebpdemux20.6.1-2.1
ii  libwebpmux3  0.6.1-2.1
ii  libwmf0.2-7  0.2.8.4-17
ii  libx11-6 2:1.7.2-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages gimp recommends:
ii  ghostscript  9.53.3~dfsg-7+deb11u1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.46.2-1
ii  libasound21.2.4-1.1

-- no debconf information

Follows copy from the GIMP Crash Debug:

```
GNU Image Manipulation Program version 2.10.22
git-describe: GIMP_2_10_20-217-g0c8a7891f7
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-10 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

# Libraries #
using babl version 0.1.82 (compiled against version 0.1.86)
using GEGL version 0.4.26 (compiled against version 0.4.28)
using GLib version 2.66.8 (compiled against version 2.66.8)
using GdkPixbuf version 2.42.2 (compiled against version 2.42.2)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.46.2 (compiled against version 1.46.2)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 

Bug#992871: darkplaces: Segfault when using custom texturepack

2021-09-18 Thread Bernhard Übelacker

Dear Maintainer,
I found now another way to get it working by removing the
intermediate function my_setjmp, like in attached patch.

It looks like the compiler needs to be aware of the setjmp.
Before this patch, I tried defining my_setjmp with attribute
returns_twice, but that was not enough.

Kind regards,
Bernhard
Description:  Replace my_setjmp by original setjmp
Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/992871
Forwarded: no
Last-Update: 2021-09-18

Index: darkplaces-0~20180908~beta1/image_png.c
===
--- darkplaces-0~20180908~beta1.orig/image_png.c
+++ darkplaces-0~20180908~beta1/image_png.c
@@ -36,16 +36,6 @@
 // implementations of setjmp()/longjmp() (it either does or doesn't save the
 // signal mask), acting on different definitions of the jmp_buf struct.
 # include 
-
-// libpng calls longjmp() internally, and expects its callers to call the
-// version of setjmp() corresponding to the longjmp() call that libpng would
-// make. Set this up before including any other headers that might
-// change which flavour of setjmp() we get.
-static inline int
-my_setjmp (jmp_buf env)
-{
-	return setjmp (env);
-}
 #endif
 
 #include "quakedef.h"
@@ -54,7 +44,7 @@ my_setjmp (jmp_buf env)
 
 #ifdef LINK_TO_PNG
 
-#define qpng_setjmp(png) my_setjmp (png_jmpbuf (png))
+#define qpng_setjmp(png) (setjmp (png_jmpbuf (png)))
 
 #define qpng_set_sig_bytes png_set_sig_bytes
 #define qpng_sig_cmp png_sig_cmp


Bug#994603: node-stringprep: FTBFS or build empty lib

2021-09-18 Thread Bastien Roucariès
Source: node-stringprep
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

Trying to convert this package to arch:foreign due to an upstream error when we
removed icu-config this package does not compile source, thus ship an empty
lib..

I tried to get the source compiled but now the package FTBFS due to API
changes.

Could you help me.

Thanks

Bastien



Bug#993283: mariadb-10.5 10.5.12-0+deb11u1 flagged for acceptance

2021-09-18 Thread Adam D Barratt
package release.debian.org
tags 993283 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mariadb-10.5
Version: 10.5.12-0+deb11u1

Explanation: new upstream stable release; security fixes [CVE-2021-2372 
CVE-2021-2389]



Bug#993282: galera-4 26.4.9-0+deb11u1 flagged for acceptance

2021-09-18 Thread Adam D Barratt
package release.debian.org
tags 993282 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: galera-4
Version: 26.4.9-0+deb11u1

Explanation: new upstream stable release; solve circular Conflicts with 
galera-3 by no longer providing a virtual "galera" package



Bug#993281: galera-3 25.3.34-0+deb11u1 flagged for acceptance

2021-09-18 Thread Adam D Barratt
package release.debian.org
tags 993281 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: galera-3
Version: 25.3.34-0+deb11u1

Explanation: new upstream stable release



Bug#994602: wings3d: Hangs on startup after upgrading to bookworm

2021-09-18 Thread Harri Haataja
Package: wings3d
Version: 2.2.6.1-2
Severity: normal
X-Debbugs-Cc: x...@iki.fi

Dear Maintainer,

After upgrading a desktop to bookworm, I tested a few applications.
Wings3d window pops up, but is completely unresponsive.
Menus open, but selections do nothing. Window closing is not effective.
Removing .config/Wings3D/ made no difference either.

Output:

(Erlang:5870): dbind-WARNING **: 15:40:25.597: AT-SPI: Error retrieving 
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files
Internal Error
Version: 2.2.6.1
Window: [wings,wings,<0.89.0>]
Reason: {error,undef,
   [{wxGLCanvas,setCurrent,[{wx_ref,546,wxGLCanvas,[]}],[]},
{wings_gl,window,4,[{file,"wings_gl.erl"},{line,82}]},
{wings_gl,init,1,[{file,"wings_gl.erl"},{line,47}]},
{wings,init,1,[{file,"wings.erl"},{line,71}]},
{proc_lib,init_p_do_apply,3,
  [{file,"proc_lib.erl"},{line,226}]}]}

2021-09-18T15:40:34.257881+03:00 error:
wxe_server:303: Callback fun crashed with {'EXIT, badarg, [{erlang,send,
[wings,quit],
[{error_info,
  #{module =>
 
erl_erts_errors}}]},
   {wings_frame,
  ...


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

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

Versions of packages wings3d depends on:
ii  erlang-base [erlang-abi]  1:24.0.6+dfsg-2
ii  erlang-cl 1.2.4-1+b1
ii  erlang-esdl   1.3.1-4.1
ii  erlang-wx 1:24.0.6+dfsg-2
ii  erlang-xmerl  1:24.0.6+dfsg-2
ii  libc6 2.31-17

wings3d recommends no packages.

Versions of packages wings3d suggests:
pn  erlang-dialyzer  
pn  erlang-tools 
pn  yafaray | aqsis  

-- no debconf information



Bug#993656: bullseye-pu: package mutter/3.38.6-2~deb11u1

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2021-09-04 at 11:48 +0100, Simon McVittie wrote:
> I updated mutter and gnome-shell along the 3.38.x branch in unstable
> while we're waiting for the gnome-shell 40 transition to be ready,
> and I think it could make sense to backport them to bullseye and take
> the benefit of upstream's stable-branch maintenance.
> 

As with the gnome-shell update, the Vcs-* references want an
s/unstable/bullseye/g.

Please go ahead.

Regards,

Adam



Bug#993720: bullseye-pu: package automysqlbackup/2.6+debian.4-3

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sun, 2021-09-05 at 15:21 +0200, Thomas Goirand wrote:
> I'd like to fix #986462 in Stable as well.
> 
> [ Impact ]
> Crash of the script if using the LATEST=yes option in
> /etc/default/automysqlbackup
> 

Please go ahead.

Regards,

Adam



Bug#990994: llvm-12-tools cannot be installed for a foreign architecture

2021-09-18 Thread Helmut Grohne
Hi,

Christoph asked me to comment on this.

On Fri, Sep 17, 2021 at 03:43:21PM +0200, Sylvestre Ledru wrote:
> Hello,
> 
> Le 17/09/2021 à 15:28, Christoph Berg a écrit :
> > Re: Michel Dänzer
> > > Package: llvm-12-tools
> > > Version: 1:12.0.1~+rc4-1
> > > Severity: normal
> > > 
> > > llvm-12-tools requires python3 packages from the same architecture. This 
> > > prevents installing llvm-12-tools (and by extension llvm-12-dev) for a 
> > > foreign architecture.
> > > 
> > > E.g. trying to install llvm-12-tools:i386 with aptitude gives:
> > > 
> > >   llvm-12-tools:i386 : Depends: python3:i386 but it is not going to be 
> > > installed
> > >Depends: python3-yaml:i386 but it is not going to 
> > > be installed
> > > 
> > > See 
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833/diffs?commit_id=af0fde955c518447ccd92134517b4e69308e10b2#3f46a9fa9651371b76f0894b75d719a4c5659642_44_45
> > >  for how I had to work around this in Mesa's upstream CI.

I confirm that it is not possible to install llvm-12-tools for a foreign
architecture in unstable.

> > > (In buster it was still possible to install llvm-*-dev packages for 
> > > foreign architectures)

I confirm. The change that made a difference here is that llvm-V-dev now
depends on llvm-N-tools while it didn't do that in buster. llvm-V-tools
was never installable for foreign architectures.

> > The fix for this question is "Depends: python3:any" I believe.

Unfortunately, it's not that easy. There also is python3-pygments and
python3-yaml. Luckily, python3-pygments is already M-A:foreign.
python3-yaml however is M-A:allowed. So if you go this route, it'll be:

Depends: python3:any, python3-pygments, python3-yaml:any

That totally leaves open the question of whether that change is correct.
It merely states that the originally proposed change is insufficient.

> > Different take on a related issue:
> > 
> > When cross-compiling, I cannot install clang-11 and llvm-11-dev for
> > the build-architecture when installing the host-architecture
> > postgresql-server-dev-13. I think the fix is annotating (some subset
> > of) the llvm packges with "Multi-Arch: allowed".

I'm afraid I didn't notice this in time for the bullseye release. Cross
building with clang on bullseye is quite simply broken it seems.

Please refrain from adding "M-A:allowed" without thought. It is a
heavy-handed sword. Think of it like adding an epoch. Consulting d-devel
or at least a multiarch expert would be good as it is very difficult to
revert M-A:allowed in case it turns out to be wrong.

> > Please consider applying these fixes so clang can be used for
> > cross-compilation.

I fear what needs to be fixed is quite non-obvious.

> If you folks want to see progress on this, I would need help. ( 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/tree/12/debian )
> I don't know how to test that properly (so, testcase which aren't rebuild 
> postgresql would be appredciated)
> and I made too many mistakes in the past with
> the multi-arch flag to trust myself :)

I concur that adding a test case would help a lot. It would be even
better if that could be an autopkgtest, but I'm unsure whether we can
mix architectures in autopkgtests like that. Failing that, maybe
something based on mmdebstrap could do it.

Thus far, much of my reply was about explaining why the proposed
solutions don't work. That's not very constructive. So I have two things
to say to actually improve the situation.

First and foremost, llvm is very broken when it comes to multiarch. It
has a lot of M-A:same annotations that factually are lies. They've been
reported by the multiarch hinter for quite a long while:

libc++-12-dev conflicts on 3 files starting with 
/usr/lib/llvm-12/lib/libc++ on any two of amd64, arm64, armel, armhf, and 5 more
libc++1-12 conflicts on /usr/lib/llvm-12/lib/libc++.so.1.0 on any two of 
amd64, arm64, armel, armhf, and 5 more
libc++abi-12-dev conflicts on /usr/lib/llvm-12/lib/libc++abi.a on any two 
of amd64, arm64, armel, armhf, and 5 more
libc++abi1-12 conflicts on /usr/lib/llvm-12/lib/libc++abi.so.1.0 on any two 
of amd64, arm64, armel, armhf, and 5 more
libomp5-12 conflicts on 3 files starting with /usr/lib/llvm-12/lib/libomp 
on any two of amd64, arm64, armhf, i386, and 2 more
libunwind-12 conflicts on /usr/lib/llvm-12/lib/libunwind.so.1.0 on any two 
of amd64, arm64, armhf, i386, and 2 more
libunwind-12-dev conflicts on /usr/lib/llvm-12/lib/libunwind.a on any two 
of amd64, arm64, armhf, i386, and 2 more

The above are serious issues and result in dpkg unpack errors (the least
thing you'd want). They're trivially fixed by removing Multi-Arch: same
from the mentioned packages. Please do so as soon as possible for all
llvm releases.

clang-12-doc could be marked Multi-Arch: foreign
llvm-12-doc could be marked Multi-Arch: foreign

These two are quite simple fixes that don't have a big impact, but you
can easily 

Bug#993655: bullseye-pu: package gnome-shell/3.38.6-1~deb11u1

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2021-09-04 at 11:47 +0100, Simon McVittie wrote:
> I updated mutter and gnome-shell along the 3.38.x branch in unstable
> while we're waiting for the gnome-shell 40 transition to be ready,
> and I think it could make sense to backport them to bullseye and take
> the benefit of upstream's stable-branch maintenance.
> 

One small note:

-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-shell.git -b
debian/unstable

That probably wants updating to point to the bullseye branch instead.

Please go ahead; thanks.

Regards,

Adam



Bug#993396: bullseye-pu: package flatpak/1.10.3-0+deb11u1

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Fri, 2021-09-10 at 18:00 +0100, Simon McVittie wrote:
> On Tue, 31 Aug 2021 at 20:10:17 +0100, Simon McVittie wrote:
> >   [x] attach debdiff against the package in (old)stable
> >   - It's a filtered git diff rather than a debdiff, but I
> > upload with
> > dgit, so what's in git has to match what's uploaded. I did
> > a diff
> > between patched trees, because the majority of the upstream
> > code
> > changes were previously in debian/patches.
> 
> Sorry, I was sure I'd attached the diff but it must have got lost.
> See
> attached.
> 

Please go ahead; thanks.

Regards,

Adam



Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2021-09-11 at 21:55 +, Romain Francoise wrote:
> I'm seeking permission to upload tmux/3.1c-1+deb11u1 to bullseye; it
> fixes a regression which results in tmux not loading its
> configuration
> during startup in some situations (#992202).
> 

Please go ahead.

Regards,

Adam



Bug#994111: bullseye-pu: package shellcheck/0.7.1-1+deb11u1

2021-09-18 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2021-09-11 at 22:57 +0100, Samuel Henrique wrote:
> The manpage of shellcheck has been broken on Debian for a while now,
> at least since oldstable/buster. The issue is that the long form of
> the options are having its double dashes corrupted by pandoc due to
> the way the manpage is generated.
> Eg.: option "--list-optional" becomes "–list-optional"
> 

Please go ahead.

Regards,

Adam



Bug#994601: Fwd: [containers/podman] Pre-release v3.4.0-rc1 - v3.4.0-RC1

2021-09-18 Thread Reinhard Tartler
Package: libpod
Severity: wishlist

-- Forwarded message -
From: Matthew Heon 
Date: Thu, Sep 16, 2021, 18:16
Subject: [containers/podman] Pre-release v3.4.0-rc1 - v3.4.0-RC1
To: containers/podman 
Cc: Subscribed 


v3.4.0-RC1 

Repository: containers/podman  · Tag:
v3.4.0-rc1  · Commit:
bd47b9e

· Released by: mheon 
Features

   - Pods now support init containers! Init containers are containers which
   run before the rest of the pod starts. There are two types of init
   containers: "always", which always run before the pod is started, and
   "once", which only run the first time the pod starts and are subsequently
   removed. They can be added using the podman create command's --init-ctr
   option.
   - Support for init containers has also been added to podman play kube
   and podman generate kube - init containers contained in Kubernetes YAML
   will be created as Podman init containers, and YAML generated by Podman
   will include any init containers created.
   - The podman play kube command now supports building images. If the
   --build option is given and a directory with the name of the specified
   image exists in the current working directory and contains a valid
   Containerfile or Dockerfile, the image will be built and used for the
   container.
   - The podman play kube command now supports a new option, --teardown,
   which removes any pods and containers created by the given Kubernetes YAML.
   - A new command has been added, podman pod logs, to return logs for all
   containers in a pod at the same time.
   - Two new commands have been added, podman volume export (to export a
   volume to a tar file) and podman volume import) (to populate a volume
   from a given tar file).
   - The podman auto-update command now supports simple rollbacks. If a
   container fails to start after an automatic update, it will be rolled back
   to the previous image and restarted again.
   - Pods now share their user namespace by default, and the podman pod
   create command now supports the --userns option. This allows rootless
   pods to be created with the --userns=keep-id option.
   - The podman pod ps command now supports a new filter with its --filter
   option, until, which returns pods created before a given timestamp.
   - The podman image scp command has been added. This command allows
   images to be transferred between different hosts.
   - The podman stats command supports a new option, --interval, to specify
   the amount of time before the information is refreshed.
   - The podman inspect command now includes ports exposed (but not
   published) by containers (e.g. ports from --expose when --publish-all is
   not specified).
   - The podman inspect command now has a new boolean value, Checkpointed,
   which indicates that a container was stopped as a result of a podman
   container checkpoint operation.
   - Volumes created by podman volume create now support setting quotas
   when run atop XFS. The size and inode options allow the maximum size and
   maximum number of inodes consumed by a volume to be limited.
   - The podman info command now outputs information on what log drivers,
   network drivers, and volume plugins are available for use (#11265
   ).
   - The podman info command now outputs the current log driver in use, and
   the variant and codename of the distribution in use.

Changes

   - The podman build command has a new alias, podman buildx, to improve
   compatibility with Docker. We have already added support for many docker
   buildx flags to podman build and aim to continue to do so.
   - Podman commands run as root now ignore XDG_RUNTIME_DIR when
   determining where to place temporary files, which should resolve a number
   of issues including #10745
    and #10806
   .
   - Cases where Podman is run without a user session or a writable
   temporary files directory will now produce better error messages.
   - The default log driver has been changed from file to journald. The file
   driver did not properly support log rotation, so this should lead to a
   better experience. If journald is not available on the system, Podman will
   automatically revert to the file.
   - Podman no longer depends on ip for removing networks (#11403
   ).
   - The deprecated --macvlan flag to podman network create now warns when
   it is used. It will be removed entirely in the Podman 4.0 release.
   - The podman machine start command now prints a message when the VM is
   successfully started.
   - The podman 

Bug#994599: ITP: python-tomli -- lil' TOML parser for Python

2021-09-18 Thread Michael R. Crusoe
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: python-tomli -- lil' TOML parser for Python
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: python-tomli
  Version : 1.2.1
  Upstream Author : Taneli Hukkinen
* URL : https://github.com/hukkin/tomli
* License : Expat
  Programming Lang: Python
  Description : lil' TOML parser for Python
 Tomli is a Python library for parsing TOML. https://toml.io/
 Tomli is fully compatible with TOML v1.0.0. https://toml.io/en/v1.0.0

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-tomli



Bug#984904: reportbug: differing behaviour between src:samba and --source samba

2021-09-18 Thread Paul Wise
On Sat, 2021-09-18 at 12:57 +0200, Nis Martensen wrote:

> When you use --source then reportbug expects you to give the name of
> a binary package and will figure out the source package name for you.
> With the src: prefix shortcut you need to give the name of the source
> package directly.

Hmm, OK. I was expecting the behaviour would become identical,
although I am not sure which of the two behaviours I prefer...

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#984904: reportbug: differing behaviour between src:samba and --source samba

2021-09-18 Thread Nis Martensen
On 10 Mar 2021 Paul Wise wrote:
> 
> The reportbug behaviour differs between src:samba and --source samba,
Even with the bug fixed there is still a small difference. Just
mentioning it here for completeness:

When you use --source then reportbug expects you to give the name of a
binary package and will figure out the source package name for you. With
the src: prefix shortcut you need to give the name of the source package
directly.



Bug#994597: exim4-config: add macro to set protocol to smtps (or other)

2021-09-18 Thread Bill Allombert
Package: exim4-config
Version: 4.94.2-7
Severity: wishlist

Dear Debian Exim Maintainers,

It would be useful if exim4.conf.template has a macro to set the protocol
for the transport.
Somethink like (new macro REMOTE_SMTP_SMARTHOST_PROTOCOL)

- - - 
remote_smtp_smarthost:
  debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
  driver = smtp
.ifdef REMOTE_SMTP_SMARTHOST_PROTOCOL
  protocol = REMOTE_SMTP_SMARTHOST_PROTOCOL
.endif
- - - 

Then the user could add to update-exim4.conf.conf
something like

REMOTE_SMTP_SMARTHOST_PROTOCOL=smtps
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS=smtp.example.com
dc_smarthost='smtp.example.com::465'

to connect with smtps without having to change exim4.conf.template.

Thanks for maintaining exim4!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#994596: tcllib: no calendar module available

2021-09-18 Thread greg
Package: tcllib
Version: 1.20+dfsg-1
Severity: normal
X-Debbugs-Cc: gre...@gmx.de

Dear Maintainer,

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

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

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


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 tcllib depends on:
ii  iproute2  5.14.0-1
ii  tcl   8.6.11+1

tcllib recommends no packages.

Versions of packages tcllib suggests:
ii  tcllib-critcl  1.20+dfsg-1



Bug#994578: [Pkg-javascript-devel] Bug#994578: Bug#994578: node-node-sass: Please split between arch:all arch:any package

2021-09-18 Thread Jonas Smedegaard
Quoting Nilesh Patra (2021-09-18 11:49:51)
> On 18 September 2021 3:19:59 am IST, "Bastien Roucariès" 
>  wrote:
> >node-node-sass should be split between arch:all and arch:any package.
> >
> >The first one should be ma:foreign (if possible), the second one ma: 
> >same
> >
> >It will improve crossbuilt and moreover be ma friendly
> 
> Thank you very much for reporting. I fully agree with you.
> 
> However, as you might notice in this bug report[1] that node-node-sass 
> has been officially deprecated in favour of dart-sass. Which will take 
> time to be packages I believe.
> 
> But I'm unsure if it's worth to go for such a split and loop via the 
> NEW queue again provided the package is not under active maintainance 
> anymore. node-node-sass does not have many reverse dependencies 
> either, thought.

If a package is actively used then it makes sense to maintain it - which 
includes improving support for cross-building.

I do not expect dart-sass soon in Debian: Requires someone to package 
and maintain and stabilize the dart compiler first, and then dart-sass - 
i.e. multiple visit through NEW in addition to the packaging efforts 
themselves.


 - Jonas

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

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

signature.asc
Description: signature


Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Salvatore Bonaccorso
Hi,

On Sat, Sep 18, 2021 at 11:09:18AM +0200, Chris Hofstaedtler wrote:
> Hello Hilmar,
> 
> * Chris Hofstaedtler  [210904 13:27]:
> > * Hilmar Preuße  [210903 10:42]:
> > > Try here: https://freeshell.de/hille42/993173/
> > 
> > I have tried these packages out (on buster, obviously), and can
> > confirm they work as expected. Also together with proftpd-mod-vroot.
> 
> Do you think this could make it into the next stable point release?

I think the issue can go in via a point release indeed. The planning
has been announced as
https://lists.debian.org/debian-live/2021/09/msg00026.html and
https://lists.debian.org/debian-live/2021/09/msg00027.html FWIW.

Regards,
Salvatore



Bug#994595: libuser1-dev: Missing dependencies against libglib2.0-dev

2021-09-18 Thread Laurent Bigonville
Package: libuser1-dev
Version: 1:0.62~dfsg-0.4
Severity: serious
Tags: bullseye bookworm sid

Hello,

Looking at the libuser.pc file, it seems that the libuser1-dev is
missing a dependency against libglib2.0-dev

Could you please add it?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy



Bug#965056: Please enable SELinux support

2021-09-18 Thread Laurent Bigonville

tags 965056 + patch
thanks

On Wed, 15 Jul 2020 11:39:48 +0200 Laurent Bigonville  
wrote:


> Hello,
>
> Would be nice to enable SELinux support in libuser
>
> That however cannot be done before #956354 is fixed.

#956354 is now fixed, could you please enable SELinux support in libuser 
(see attached patch)?


Kind regards,

Laurent Bigonville

diff -Nru libuser-0.63~dfsg/debian/control libuser-0.63~dfsg/debian/control
--- libuser-0.63~dfsg/debian/control	2021-09-18 03:55:14.0 +0200
+++ libuser-0.63~dfsg/debian/control	2021-09-18 11:38:25.0 +0200
@@ -12,6 +12,7 @@
  libpam0g-dev,
  libpopt-dev,
  libpython3-dev,
+ libselinux-dev [linux-any],
  linuxdoc-tools,
  pkg-config,
  python3,
diff -Nru libuser-0.63~dfsg/debian/rules libuser-0.63~dfsg/debian/rules
--- libuser-0.63~dfsg/debian/rules	2021-09-18 03:57:11.0 +0200
+++ libuser-0.63~dfsg/debian/rules	2021-09-18 11:38:25.0 +0200
@@ -15,6 +15,10 @@
 DPKG_EXPORT_BUILDTOOLS = 1
 include /usr/share/dpkg/default.mk
 
+ifeq (linux,$(DEB_HOST_ARCH_OS))
+ENABLE_SELINUX = --with-selinux
+endif
+
 %:
 	dh $@
 
@@ -24,7 +28,7 @@
 override_dh_auto_configure:
 	dh_auto_configure -- \
 	--program-transform-name="s/lid/libuser-lid/" \
-	--with-python=no
+	--with-python=no $(ENABLE_SELINUX)
 
 execute_after_dh_auto_install:
 	find . -name '*.la' -delete


Bug#994578: [Pkg-javascript-devel] Bug#994578: node-node-sass: Please split between arch:all arch:any package

2021-09-18 Thread Nilesh Patra
Hi Bastien,

On 18 September 2021 3:19:59 am IST, "Bastien Roucariès" 
 wrote:
>Package: node-node-sass
>Severity: important
>
>Dear Maintainer,
>
>
>node-node-sass should be split between arch:all and arch:any package.
>
>The first one should be ma:foreign (if possible), the second one ma: same
>
>It will improve crossbuilt and moreover be ma friendly

Thank you very much for reporting. I fully agree with you.

However, as you might notice in this bug report[1] that node-node-sass has 
been officially deprecated in favour of dart-sass. Which will take time to 
be packages I believe.

But I'm unsure if it's worth to go for such a split and loop via the NEW 
queue again provided the package is not under active maintainance anymore. 
node-node-sass does not have many reverse dependencies either, thought.

I'm personally not motivated to fix this bug, to be very honest, since my 
workload of things with higher importance is a lot already.
I'm however perfectly fine if someone wants to do a team upload for this 
package.

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

Thanks again for the bug report!
Cheers,

Nilesh
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#994594: ITP: time-decode -- timestamp decoder and converter

2021-09-18 Thread Jan Gru
Package: wnpp
Severity: wishlist
Owner: Jan Gru 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-security-to...@lists.debian.org

* Package name: time-decode
  Version : 3.1.1
  Upstream Author : Corey Forman
* URL : https://github.com/digitalsleuth/time_decode
* License : MIT
  Programming Lang: Python
  Description : timestamp decoder and converter

time-decode provides the functionality to decode various timestamps
and UUIDs to aid digital forensics and incident response
processes. The supported formats range from common ones, like Unix
epochs, WebKit/Chrome timestamps and Microsoft's FILETIME to more
exotic formats like LDAP/Active Directory timestamps and Metasploit
payload UUIDs. In addition, even timestamps used by some social media
services, like Twitter, are included.

** Relevance of the package
In most DFIR investigations temporal information is particularly
important. Analysts often stumble over various timestamps and need to
convert and normalize them quickly. While toolkits like plaso can help
with the normalization of logfiles in bulk, Debian's package archives
lack tooling for the convenient conversion of single timestamps of
either known or unknown format. Given this finding and my experience
from using it, time-decode seems to be an valuable prospective package
to round off Debian's collection of forensic tools.

** Maintainenace plan
I suggest to maintain time-decode inside the pkg-security-team's
repository on salsa, since most of the packages related to forensics
live there. However, I am looking for a sponsor for this package -
ideally a member of the pkg-security-team.



Bug#993180: [Pkg-matrix-maintainers] Bug#993180: Make matrix-mirage unusable

2021-09-18 Thread Jonas Smedegaard
Quoting Scorpion2185 via Pkg-matrix-maintainers (2021-09-17 21:42:57)
> I upgraded it to the testing version:
> 
> apt install python3-matrix-nio
> [...]
> python3-matrix-nio is already the newest version (0.18.6-1).
> 
> And it solved the problem so it is fault of that package if matrix -mirage 
> doesn't work.

Thanks for the (additional) confirmation, Scorpion2185.

 - Jonas

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

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

signature.asc
Description: signature


Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server

2021-09-18 Thread Chris Hofstaedtler
Hello Hilmar,

* Chris Hofstaedtler  [210904 13:27]:
> * Hilmar Preuße  [210903 10:42]:
> > Try here: https://freeshell.de/hille42/993173/
> 
> I have tried these packages out (on buster, obviously), and can
> confirm they work as expected. Also together with proftpd-mod-vroot.

Do you think this could make it into the next stable point release?

Thanks,
Chris



  1   2   >