Bug#992759: nmu: tagua_1.0~alpha2-16-g618c6a0-3

[Pino Toscano]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi,

please rebuild tagua in unstable against the libkdegames recently
uploaded. tagua builds fine with the newer libkdegames.

nmu tagua_1.0~alpha2-16-g618c6a0-3 . ANY . unstable . -m "rebuild for 
libkdegames 21.08.0 (libkf5kdegamesprivate7)"

Thanks,
-- 
Pino

Bug#992758: nmu: calamares_3.2.36-1

[Pino Toscano]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi,

please rebuild calamares in unstable against the newer kpmcore recently
uploaded. calamares builds fine with the newer kpmcore.

nmu calamares_3.2.36-1 . ANY . unstable . -m "rebuild against kpmcore 21.08.0 
(libkpmcore11)"

Thanks,
-- 
Pino

Bug#992757: nmu: qtwebview-opensource-src_5.15.2-2

[Pino Toscano]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Hi,

please rebuild qtwebview-opensource-src in unstable for the new
qtwebengine 5.15.5 recently uploaded, so it depends on the new internal
ABI dependency. qtwebview builds fine with the newer qtwebengine.

nmu qtwebview-opensource-src_5.15.2-2 . ANY . unstable . -m "rebuild with 
qtwebengine-opensource-src 5.15.5 (qtwebengine-abi-5-15-5)"

Thanks,
-- 
Pino

Bug#992756: isc-dhcp-client: set default domain and search to "hostname -d" value

[Martin-Éric Racine]

Package: isc-dhcp-client
Version: 4.4.1-2.3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When the DHCP server doesn't provide any domain-name or domain-search value, it 
would be desirable for the DHCP client to set them to the result of "hostname 
-d" and to print them to /etc/resolv.conf as a fallback mechanism.

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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.11.2
ii  iproute2   5.10.0-4
ii  libc6  2.31-13
ii  libdns-export1110  1:9.11.19+dfsg-2.1
ii  libisc-export1105  1:9.11.19+dfsg-2.1

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2.3

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

- -- Configuration Files:
/etc/dhcp/dhclient.conf changed:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
default domain-name "lan";
default domain-search "lan";
append domain-name-servers 1.1.1.1;

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmEjMkAACgkQrh+Cd8S0
17aEHA/9HiXsvZuNtOXsgVwVt8LaYxVizd7ieonzgpJii5mpkNwA0gx1iKtdQHy4
3ATxN3qEmcwjU0zObsV/mgRijyr7sfNVdBjoR8h+Yzx5vpaGHMXCiAoXjjdGXmj2
1jy/tYsb/L3kam1BI0RyK8IzyifEz+L60fYDXZVzopRUEJoW+GWqugksN2PxkB4/
OSm2udawxAgmTKMH4CSPp+jMkWMgvlNF5r6AX3xiWjZUkD/PxQeYm2G5k7QctP4A
GKsrn405563EiX9zQMzk+PJNYR48776n/X7aiw+gG3jdbBh5xrHbndd0aUis0j6E
PQVBJh3igfEFAiudSss/8gxITaNeAMHS4MNN4DDozurkkEMG9puQHr2OPIGfoaVf
LitfEodhGie2frGHbcPrOTmMLPCv5bGrtDmJxQuniQCKPjjk9ibdtsf9XUA8jSqe
Y3R75TUqJLS+bBsfiO/ZeqwS4Uk28XCXPcySZVcpmMWX94Wuqg61QTl8fZuRtKmq
veZbHOMKyu7OjKyCRWyjTbWXsW8JEGnRiT2SNPjljzPD8yQb2H2At8TIE1aayX2w
4O71qg/ih/hpfLUzcZ2Kg9uKErW7Tb6dqhjLHZTDrU1FL7zTeNcxs7yeLlNzCCO6
vLOzTZskxRz3s0divycWBcdSoMgTbgBeUdKS0uUuoDpHNNLG2Nc=
=qnE7
-END PGP SIGNATURE-

Bug#947384: closed by Debian FTP Masters (reply to Jörg Frings-Fürst ) (Bug#947384: fixed in ipmitool 1.8.18-11)

[Paul Wise]

Control: reopen -1

On Sun, 2021-08-22 at 20:51 +, Jörg Frings-Fürst wrote:

>    * debian/ipmitool.maintscript (Closes: #947384):
>  - Change prior-version to 1.8.18-11~.

Unfortunately this did not have the desired effect:

$ dpkg-query --show ipmitool
ipmitool1.8.18-11

$ adequate ipmitool
ipmitool: obsolete-conffile /etc/default/ipmievd

$ dpkg-query -W -f='${Conffiles}\n' ipmitool | grep obsolete
 /etc/default/ipmievd aee2dd16955e01208118e6cbf8ed5822 obsolete

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Paul Wise]

On Mon, 2021-08-23 at 06:54 +0200, Sebastiaan Couwenberg wrote:

> Yes:
> 
> # find /root/.config/ -name crssync.conf
> /root/.config/Unknown Organization/crssync.conf

OK, so you were affected too, but probably because of your HOME env var
the file was created in /root while probably I had no HOME env var set,
on my system it defaulted to the empty string, making it use the / dir.

I've asked about this on the #debian-dpkg and #debian-apt IRC channels:

 any opinions, is #992747 a bug in dpkg, apt, unattended-upgrades
or qgis? HOME seems to be unset in unattended-upgrades, causing qgis
maintscripts to create files in /.config instead of /root/.config or
elsewhere. if HOME is set (root login for eg), qgis mainscripts create
files in /root/.config
 I think I'm leaning towards wanting dpkg to set HOME to a dir
that nothing can write to, not even root. maintscripts shouldn't touch
/root either

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Sebastiaan Couwenberg]

Control: severity -1 important
Control: tags -1 - unreproducible
Control: tags -1 upstream
Control: forwarded -1 https://github.com/qgis/QGIS/issues/44793

On 8/23/21 6:54 AM, Sebastiaan Couwenberg wrote:
> On 8/23/21 6:29 AM, Paul Wise wrote:
>> On Mon, 2021-08-23 at 06:23 +0200, Sebastiaan Couwenberg wrote:
>>
>>>  HOME=/root
>>
>> Do you have these files instead?
>>
>> /root/.config/*/crssync.conf
> 
> Yes:
> 
> # find /root/.config/ -name crssync.conf
> /root/.config/Unknown Organization/crssync.conf

The issue has been forwarded upstream.

Kind Regards,

Bas

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

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Sebastiaan Couwenberg]

On 8/23/21 6:29 AM, Paul Wise wrote:
> On Mon, 2021-08-23 at 06:23 +0200, Sebastiaan Couwenberg wrote:
> 
>>  HOME=/root
> 
> Do you have these files instead?
> 
> /root/.config/*/crssync.conf

Yes:

# find /root/.config/ -name crssync.conf
/root/.config/Unknown Organization/crssync.conf

Kind Regards,

Bas

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

Bug#973594: waybar: Unknown module clock

[Tobias Bengfort]

In case someone is searching for a simple replacement, you can use the 
custom module:


"custom/clock": {
"exec": "date +'%a %x %R'",
"interval": 60,
}

Bug#992754: debian-goodies: blacklist patterns match against "path (deleted)" instead of path

[Ian Kelling]

Package: debian-goodies
Version: 0.84
Severity: normal

Dear Maintainer,

I ran checkrestart -pv, part of the output said

List of deleted files in use:
/var/lib/nfs/etab (deleted)

I saw this file was not an indication of a service restart needed, so I added

-b blacklistfile
blacklistfile contained the pattern
^/var/lib/nfs/etab$

I expected this to match the file, but it didn't. Looking into the
source code, I saw that instead "the file" it was matching against was
"/var/lib/nfs/etab (deleted)" and so I had to adjust my pattern to be

^/var/lib/nfs/etab \(deleted\)$

The man page says the pattern matches "the file", not the file plus
" deleted" appended to it. I don't think it makes any sense for this
deleted to be part of what is matched.

Bug#992753: ibus-anthy: Default input source becomes Anthy for non-Japanese

[Jian-Hong Pan]

Package: ibus-anthy
Version: 1.5.12-2

I installed GNOME and multiple input engines for IBus, including
ibus-anthy.

I notice that when ibus-anthy is upgraded to version 1.5.12-2, my
default input source will become the Japanese (Anthy). This bothers
users who do not use Japanese in major time.

I found this is since the commit ("Add auto set-up script for the GNOME
desktop") [1]

[1] https://salsa.debian.org/input-method-team/ibus-anthy/-/commit/d430d0972317

Jian-Hong Pan

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Paul Wise]

On Mon, 2021-08-23 at 06:23 +0200, Sebastiaan Couwenberg wrote:

>  HOME=/root

Do you have these files instead?

/root/.config/*/crssync.conf

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Sebastiaan Couwenberg]

On 8/23/21 5:58 AM, Paul Wise wrote:
> On Mon, 2021-08-23 at 05:46 +0200, Sebastiaan Couwenberg wrote:
> 
>> Control: tags -1 unreproducible
> 
> Hmm, perhaps it was caused by my use of unattended-upgrades, which
> might not set the HOME or XDG_* environment variables.
> 
>> This may be a regression, something like this happened before (#948727).
> 
> Seems that was probably caused by env vars being missing or /root too.
> 
>> On my unstable system qgis has been upgraded to 3.16.10 too, but it
>> doesn't have this config:
> 
> Are you doing upgrades manually as root or using sudo apt?

Manually as root.

> Can you check what environment variables are set in apt?

How?

This is the env for root:

 SHELL=/bin/bash
 LANGUAGE=en_US:en
 PWD=/root
 LOGNAME=root
 HOME=/root
 LANG=en_US.UTF-8
 TERM=xterm-256color
 USER=root
 SHLVL=1
 DEBUGINFOD_URLS=
 
PATH=/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 MAIL=/var/mail/root
 _=/usr/bin/env

Kind Regards,

Bas

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

Bug#992725: gbp:error: More than one archive specified. Try --help.

[Andreas Tille]

Hi Étienne,

thanks a lot for your detailed analysis.  You stumbled upon a pretty
weak part of routine-update.  For instance it is also not able to cope
with watch files featuring the valid but in principle superfluous
"uupdate debian".  I'm currently busy with real life + DebConf
preparation (and the fact that some UDD queries are not getting up to
date results - Nilesh in CC).  So if one of you could take over this
probably not very hard shell scripting exercise I'd be really happy.

... and feel free to simply push a new version of routine-update if
you solved it. ;-)

Kind regards
Andreas.

On Sun, Aug 22, 2021 at 08:29:55PM +0200, Étienne Mollier wrote:
> Package: routine-update
> Version: 0.0.6
> Severity: important
> 
> Hi Andreas,
> 
> when working on making sure the python-biopython watch file was
> appropriately fixed, I saw routine-update choke with the
> following error:
> 
>   $ routine-update
>   gbp:info: Fetching from default remote for each branch
>   gbp:info: Branch 'master' is already up to date.
>   gbp:info: Branch 'pristine-tar' is already up to date.
>   gbp:info: Branch 'upstream' is already up to date.
>   e1b391ac4e33945379bc8eb4a878fee38c797ca1
>   uupdate: PACKAGE = "python-biopython" is in the top of 
> debian/changelog
>   uupdate: VERSION = "1.78+dfsg-5" is in the top of debian/changelog
>   uupdate: EPOCH   = "" is epoch part of $VERSION
>   uupdate: SVERSION= "1.78+dfsg-5" is w/o-epoch part of $VERSION
>   uupdate: UVERSION= "1.78+dfsg" the upstream portion w/o-epoch of 
> $VERSION
>   uupdate: ../python-biopython-1.79+dfsg directory exists.
>   uupdate: remove ../python-biopython-1.79+dfsg directory.
>   uupdate: -> Overwrite to python-biopython_1.79+dfsg-1.debian.tar.xz
>   [master dcb2e9f] routine-update: New upstream version
>1 file changed, 3 insertions(+), 2 deletions(-)
>   gbp:error: More than one archive specified. Try --help.
> 
> Adding `set -x` at the top of the routine-update script, I see
> that uscan_out catches an additionall line dpkg-source which
> matches with subsequent filtering:
> 
>   + uscan_out='uscan info: Last orig.tar.* tarball version (from 
> debian/changelog): 1.78+dfsg
>   uscan info: Last orig.tar.* tarball version (dversionmangled): 1.78
>   uscan info: New orig.tar.* tarball version (oversionmangled): 1.79
>   Successfully repacked ../python-biopython-179.tar.gz as 
> ../python-biopython_1.79+dfsg.orig.tar.xz, deleting 2 files from it.
>   uscan info: New orig.tar.* tarball version (after mk-origtargz): 
> 1.79+dfsg
>   dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'
> 
>   ++ echo 'uscan info: Last orig.tar.* tarball version (from 
> debian/changelog): 1.78+dfsg
>   uscan info: Last orig.tar.* tarball version (dversionmangled): 1.78
>   uscan info: New orig.tar.* tarball version (oversionmangled): 1.79
>   Successfully repacked ../python-biopython-179.tar.gz as 
> ../python-biopython_1.79+dfsg.orig.tar.xz, deleting 2 files from it.
>   uscan info: New orig.tar.* tarball version (after mk-origtargz): 
> 1.79+dfsg
>   dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'
> 
>   ++ grep '.orig.tar.[bgx]z2*'
> 
>   ++ sed 's#^.* \(\.\./[^ ]*\.orig\.tar\.[bgx]z2*\).*#\1#'
> 
> Ultimately leading to a faulty tarball name which is passed as
> such to `gbp import-orig`, hence the "More than one archive
> specified" error:
> 
>   + tarball='../python-biopython_1.79+dfsg.orig.tar.xz
>   dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'
> 
> routine-update 0.0.6 is around for quite some time, so I believe
> it is a specific combination of watch option which might trigger
> this, or simply a recent update somewhere else in the tooling.
> Just in case, the corresponding watch file is:
> 
>   version=4
>   
>   opts="\
>   filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\
>   uversionmangle=s/b/~b/;s/(\d)(\d+)/$1.$2/,\
>   repacksuffix=+dfsg,\
>   dversionmangle=s/\+dfsg//,\
>   repack,\
>   compression=xz" \
>   https://github.com/biopython/biopython/tags \
>   (?:.*?/)?biopython[v-]?(\d[\d.]*)\.tar\.gz debian uupdate
> 
> Complementing the `grep` command here over with the following
> pattern might help:
> 
>   grep '\.\./.*.orig.tar.[bgx]z2*'
> 
> For information,
> Have a nice day,  :)
> Étienne.
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
> 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)
> LSM: AppArmor: enabled
> 
> Versions of packages 

Bug#992752: gnome-tweaks: Missing dependency: gir1.2-handy-1

[Youhei SASAKI]

Package: gnome-tweaks
Version: 40.0-2
Severity: grave
X-Debbugs-Cc: none, Youhei SASAKI 

Dear Maintainer,

The gnome-tweaks >= 40.0 depends "gir1.2-handy-1", not "gir1.2-handy-0".
When gir1.2-handy-1 is not installed, gnome-tweaks  can't use like this:

  % gnome-tweaks
  Traceback (most recent call last):
File "/usr/bin/gnome-tweaks", line 15, in 
  gi.require_version("Handy", "1")
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
  raise ValueError('Namespace %s not available for version %s' %
  ValueError: Namespace Handy not available for version 1

Please update the package's dependencies.

Best Wishes,
Youhei

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 gnome-tweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-glib-2.0  1.68.0-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gtk-3.0   3.24.30-1
ii  gir1.2-handy-0.0 0.0.13-3
ii  gir1.2-notify-0.70.7.9-3
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-soup-2.4  2.72.0-4
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.4-1
ii  gnome-shell-extension-prefs  3.38.4-1
ii  gsettings-desktop-schemas3.38.0-2
ii  mutter-common3.38.4-1
ii  python3  3.9.2-3
ii  python3-gi   3.40.1-2

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information

Bug#992751: RFP: cinnamon-applets-sensors-monitor -- Cinnamon Applet Sensors Monitor

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-cinna...@lists.debian.org

* Package name: cinnamon-applets-sensors-monitor
  Version : git
  Upstream Author : claudiux
* URL : 
https://github.com/linuxmint/cinnamon-spices-applets/tree/master/Sensors@claudiux
* License : GPL3
  Programming Lang: JavaScript
  Description : Cinnamon Applet Sensors Monitor

This applet displays and monitors the vales of many computer sensors
concerning Temperatures (from CPU, GPU, Power Supply), Fan Speed,
Voltages, Intrusions.
It notifies you with color changes when a value reaches or exceeds its limit.
It uses values from the sensors command. (See lm-sensors.)

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Paul Wise]

On Mon, 2021-08-23 at 05:46 +0200, Sebastiaan Couwenberg wrote:

> Control: tags -1 unreproducible

Hmm, perhaps it was caused by my use of unattended-upgrades, which
might not set the HOME or XDG_* environment variables.

> This may be a regression, something like this happened before (#948727).

Seems that was probably caused by env vars being missing or /root too.

> On my unstable system qgis has been upgraded to 3.16.10 too, but it
> doesn't have this config:

Are you doing upgrades manually as root or using sudo apt?

Can you check what environment variables are set in apt?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992750: RFP: cinnamon-applets-hwmonitor -- Cinnamon Applet Graphical Hardware Monitor

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-cinna...@lists.debian.org

* Package name: cinnamon-applets-hwmonitor
  Version : 1.3.1
  Upstream Author : Sylfurd
* URL : 
https://github.com/linuxmint/cinnamon-spices-applets/tree/master/hwmonitor@sylfurd
* License : GPL3+
  Programming Lang: JavaScript
  Description : Cinnamon Applet Graphical Hardware Monitor

Graphical Hardware Monitor is an applet that displays
realtime system information (CPU load, memory usage,
network in and out, disk usage (read and write)).

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Sebastiaan Couwenberg]

Control: tags -1 unreproducible

This may be a regression, something like this happened before (#948727).

On my unstable system qgis has been upgraded to 3.16.10 too, but it
doesn't have this config:

 # find /.config/
 /.config/
 /.config/Trolltech.conf

Kind Regards,

Bas

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

Bug#992749: ITP: golang-github-powerman-deepequal -- Go package with improved reflect.DeepEqual

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-powerman-deepequal
  Version : 0.1.0-1
  Upstream Author : Alex Efros
* URL : https://github.com/powerman/deepequal
* License : MIT
  Programming Lang: Go
  Description : Go package with improved reflect.DeepEqual

 Go package with improved reflect.DeepEqual Go Reference
 (https://pkg.go.dev/github.com/powerman/deepequal) CI/CD
 (https://github.com/powerman/deepequal/actions?query=workflow%3ACI%2FCD)
 Coverage Status
 (https://coveralls.io/github/powerman/deepequal?branch=master) Go Report
 Card (https://goreportcard.com/report/github.com/powerman/deepequal)
 Release (https://github.com/powerman/deepequal/releases/latest)
 .
 Most of the code is copied from Go reflect package with slight
 modifications.
 .
 Differences from reflect.DeepEqual: • If compared value implements
 .Equal(valueOfSameType) bool method then it will be called instead of
 comparing values as is.• If called Equal method will panics then whole
 DeepEqual will panics too.  This means you can use this DeepEqual method
 to correctly compare types like time.Time or decimal.Decimal, without
 taking in account unimportant differences (like time zone or exponent).

Needed for golang-github-powerman-check

Bug#992748: systemd-cron: postinst error

[Martin-Éric Racine]

Package: systemd-cron
Version: 1.5.17-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Setting up systemd-cron (1.5.17-1) ...
xargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, 
ignoring previous --max-args value

- -- Package-specific info:
- -- output of systemd-delta

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages systemd-cron depends on:
ii  libc6 2.31-16
ii  python3   3.9.2-3
ii  systemd-sysv  247.9-1

Versions of packages systemd-cron recommends:
ii  nullmailer [mail-transport-agent]  1:2.2-3

systemd-cron suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmEjDbIACgkQrh+Cd8S0
17aI6BAAnsGj94GcPjBpQpj7tmMvQv4u5uHwZY9mhAofyI5lw1ELoUgnKt3dYsAp
vHr3ftoUeENv0N9dsKcO88B3MU/tuHKw9OXddKPeUEDwdl6wA0dbai58gq2Q2BBR
5rfoEdQPl6f6TaRqBhtVRpJ3ytRC+r5CL+THv0pkCZyThlp7GAQ1ikZm/3j8walI
D54nuNPoCi3yLJ+R3KHLGW3niwcQbfAijJOsJbz6JY+P3rr9gN8OvtTrpD0Oj/hG
4oMoufcRyQgVoIcdawYEjgg8fU2ofFTm2cx2weilMb2f+Z5cj5RhuxLRWggDjynz
3DVxeWV1X+DBfZdBWDncC+9SKJc12z+xlUp7s6T1o+0O3d88HER8zjcIW2AwmPG2
8Nyjf+LVPc6cMzwkHJ3Em3xByS7tsoXx1JHU8YueZLurNYxd3FQ+HW4eaymd3nUw
nf2wPbWpdDS07uiXStDhne/6RD9+rUbb01eV/j5iB1OuMWe2QrrdwSK5BCw6XJpZ
jO3MtbRdCkzf5DIlMyeaZjAr53GfBy/m51PGD6lrWzeBYUsZoB6rpcfy5+QVo6SQ
XdOmYirAMEhLFwvspXvnPochGpZrc9/bWbLAKffn1o8T9ufliQ8TXSGkDYjTn/bT
sbuafNJYgzUBEV+pJHSV8ZNbW2dQRA67jnzSRhKAp4ISf9oQxqc=
=MO6j
-END PGP SIGNATURE-

Bug#992747: qgis-providers: upgrade to 3.16.10+dfsg-1: crssync created file in root dir: /.config/Unknown Organization/crssync.conf

[Paul Wise]

Package: qgis-providers
Version: 3.16.10+dfsg-1
Severity: serious
Usertags: cruft

The upgrade to 3.16.10+dfsg-1 runs crssync from a trigger. This appears
to have created a file in the root directory / (not /root) but package
maintscripts should not create files outside of the /etc /var FHS dirs.

Probably the workaround to this is to create a temporary directory, run
crssync from there and clean up the directory afterwards.

$ find /.config/
/.config/
/.config/Unknown Organization
/.config/Unknown Organization/crssync.conf

$ find /.config/ -ls
   786433  4 drwxr-xr-x   3 root root 4096 Aug 23 01:06 
/.config/
   786434  4 drwxr-xr-x   2 root root 4096 Aug 23 01:06 
/.config/Unknown\ Organization
   786436  4 -rw-r--r--   1 root root   39 Aug 23 01:06 
/.config/Unknown\ Organization/crssync.conf

$ head -vn-0 '/.config/Unknown Organization/crssync.conf'
==> /.config/Unknown Organization/crssync.conf <==
[qgis]
localized_data_paths=@Invalid()

$ find /var/lib/dpkg/info/ -iname *qgis* -print0 | xargs -0 grep -C3 crssync
/var/lib/dpkg/info/qgis-providers.md5sums:520dd53ec7c06525d237428b26a835bd  
usr/lib/qgis/crssync
/var/lib/dpkg/info/qgis-providers.md5sums-1143645206cd6dc0a226a1e1948def6e  
usr/lib/qgis/plugins/libarcgisfeatureserverprovider.so
/var/lib/dpkg/info/qgis-providers.md5sums-f3af7f7a302169ee3413d9dc5a7c8e88  
usr/lib/qgis/plugins/libarcgismapserverprovider.so
/var/lib/dpkg/info/qgis-providers.md5sums-76b5faa93481a2461de3cb6d50e1f515  
usr/lib/qgis/plugins/libbasicauthmethod.so
--
/var/lib/dpkg/info/qgis-providers.postinst-set -e
/var/lib/dpkg/info/qgis-providers.postinst-
/var/lib/dpkg/info/qgis-providers.postinst-if [ "$1" = "triggered" ] || [ "$1" 
= "configure" ]; then
/var/lib/dpkg/info/qgis-providers.postinst: if [ -w 
/usr/share/qgis/resources/srs.db ] && [ -x /usr/lib/qgis/crssync ]; then
/var/lib/dpkg/info/qgis-providers.postinst: /usr/lib/qgis/crssync
/var/lib/dpkg/info/qgis-providers.postinst- fi
/var/lib/dpkg/info/qgis-providers.postinst-fi
/var/lib/dpkg/info/qgis-providers.postinst-
--
/var/lib/dpkg/info/qgis-providers.triggers:interest-noawait qgis-crssync
--
/var/lib/dpkg/info/qgis-providers.list-/usr
/var/lib/dpkg/info/qgis-providers.list-/usr/lib
/var/lib/dpkg/info/qgis-providers.list-/usr/lib/qgis
/var/lib/dpkg/info/qgis-providers.list:/usr/lib/qgis/crssync
/var/lib/dpkg/info/qgis-providers.list-/usr/lib/qgis/plugins
/var/lib/dpkg/info/qgis-providers.list-/usr/lib/qgis/plugins/libarcgisfeatureserverprovider.so
/var/lib/dpkg/info/qgis-providers.list-/usr/lib/qgis/plugins/libarcgismapserverprovider.so
--
/var/lib/dpkg/info/qgis-providers-common.postinst-#!/bin/sh
/var/lib/dpkg/info/qgis-providers-common.postinst-set -e
/var/lib/dpkg/info/qgis-providers-common.postinst-
/var/lib/dpkg/info/qgis-providers-common.postinst:if [ "$1" = "configure" ] && 
[ -x /usr/lib/qgis/crssync ]; then
/var/lib/dpkg/info/qgis-providers-common.postinst-  cp 
/usr/share/qgis/resources/srs-template.db /usr/share/qgis/resources/srs.db
/var/lib/dpkg/info/qgis-providers-common.postinst:  dpkg-trigger 
qgis-crssync
/var/lib/dpkg/info/qgis-providers-common.postinst-fi
/var/lib/dpkg/info/qgis-providers-common.postinst-
/var/lib/dpkg/info/qgis-providers-common.postinst-

$ grep -B3 -A1 qgis-providers /var/log/apt/history.log
Start-Date: 2021-08-23  01:05:16
Commandline: /usr/bin/unattended-upgrade
Install: libqgis-gui3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-app3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgispython3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-core3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-server3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-analysis3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-3d3.16.10:amd64 (3.16.10+dfsg-1, automatic), 
libqgis-native3.16.10:amd64 (3.16.10+dfsg-1, automatic)
Upgrade: qgis-common:amd64 (3.10.14+dfsg-1, 3.16.10+dfsg-1), python3-qgis:amd64 
(3.10.14+dfsg-1, 3.16.10+dfsg-1), python3-qgis-common:amd64 (3.10.14+dfsg-1, 
3.16.10+dfsg-1), qgis:amd64 (3.10.14+dfsg-1, 3.16.10+dfsg-1), 
libqgis-customwidgets:amd64 (3.10.14+dfsg-1, 3.16.10+dfsg-1), 
qgis-providers-common:amd64 (3.10.14+dfsg-1, 3.16.10+dfsg-1), 
qgis-providers:amd64 (3.10.14+dfsg-1, 3.16.10+dfsg-1)
End-Date: 2021-08-23  01:07:02

$ grep -C40 qgis-providers /var/log/apt/term.log
...
Log started: 2021-08-23  01:05:16
(Reading database ... 582863 files and directories currently installed.)
Preparing to unpack .../00-qgis-common_3.16.10+dfsg-1_all.deb ...
Unpacking qgis-common (3.16.10+dfsg-1) over (3.10.14+dfsg-1) ...
Preparing to unpack .../01-qgis_3.16.10+dfsg-1_amd64.deb ...
Unpacking qgis (3.16.10+dfsg-1) over (3.10.14+dfsg-1) ...
Preparing to unpack .../02-python3-qgis_3.16.10+dfsg-1_amd64.deb ...
Unpacking python3-qgis (3.16.10+dfsg-1) over (3.10.14+dfsg-1) ...
Preparing to unpack .../03-qgis-providers_3.16.10+dfsg-1_amd64.deb ...
Unpacking qgis-providers (3.16.10+dfsg-1) over 

Bug#992746: plocate: FTBFS on Hurd/kFreeBSD: dependency "systemd" not found

[Paul Wise]

Source: plocate
Version: 1.1.9-2
Severity: important
Tags: ftbfs
User: debian-h...@lists.debian.org
Usertags: hurd hurd-i386
User: debian-...@lists.debian.org
Usertags: kfreebsd-i386 kfreebsd-amd64
X-Debbugs-CC: debian-h...@lists.debian.org, debian-...@lists.debian.org

plocate FTBFS on Hurd/kFreeBSD due to depending on systemd's pkg-config
file, which is only available on Linux platforms. Since mlocate has
been removed from Debian, this leaves those platforms with only
findutils locate, which is a lot slower than even mlocate was.

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

It looks like plocate only uses the systemd pkg-config file to install
systemd unit files and already supports building without systemd via
the install_systemd option. So meson.build should detect a host arch
kernel other than Linux and auto-disable install_systemd. Probably
meson.build should also not fail when systemd is not present, this will
make it more portable to distros that do not have systemd at all like
Alpine, OpenWRT, Void Linux etc. I note that some of these distros are
having to manually disable systemd instead of having that autodetected.
Some of these distros are also adding portability patches for musl.

https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd
https://repology.org/project/plocate/packages
https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/plocate/template

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992745: RFP: sphinx-inline-tabs -- add inline tabbed content to Sphinx documentation

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pyt...@tracker.debian.org

* Package name: sphinx-inline-tabs
  Version : 2021.8.17b10
  Upstream Author : Pradyun Gedam 
* URL : https://github.com/pradyunsg/sphinx-inline-tabs
* License : MIT
  Programming Lang: Python
  Description : add inline tabbed content to Sphinx documentation

Sphinx-inline-tabs adds a directive to define inline tabbed content.
.
 * Elegant design: Small footprint in the markup and generated website, while 
looking good.
 * Configurable: All the colors can be configured using CSS variables.
 * Synchronisation: Tabs with the same label all switch with a single click.
 * Works without JavaScript: JavaScript is not required for the basics, only 
for synchronisation.

---

The package is being requested since the latest kitty version uses this
extension for its documentation.

Bug#992744: RFP: sphinxext-opengraph -- Sphinx extension to generate OpenGraph metadata

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pyt...@tracker.debian.org

* Package name: sphinxext-opengraph
  Version : 0.4.2
  Upstream Author : Itay Ziv 
* URL : https://github.com/wpilibsuite/sphinxext-opengraph
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx extension to generate OpenGraph metadata

Sphinxext-opengraph generates  tags according to the Open Graph
protocol (https://ogp.me).

---

The package is being requested since the latest kitty version uses this
extension for its documentation.

Bug#990191: xml-core: leftovers on package purge

[Christoph Anton Mitterer]

Hey.

Yes I'm pretty sure it was /etc/xml, since I've simply copy the
excerpt from apt's ouput.


Also it couldn't have been /etc/sgml on my system, since this is still
"owned" by several packages:

$ dpkg -S /etc/sgml
docbook-xml, sgml-data, docutils-common, xml-core: /etc/sgml


Thanks,
Chris.

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pyt...@tracker.debian.org

* Package name: furo
  Version : 2021.08.17.beta43
  Upstream Author : Pradyun Gedam 
* URL : https://pradyunsg.me/furo/
* License : MIT
  Programming Lang: Python
  Description : clean customisable Sphinx documentation theme

This Sphinx theme is designed to be:
 .
  * Intentionally minimal --- the most important thing is the content, not the 
scaffolding around it.
  * Responsive --- adapting perfectly to the available screen space, to work on 
all sorts of devices.
  * Customisable --- change the color palette, font families, logo and more!
  * Easy to navigate --- with carefully-designed sidebar navigation and 
inter-page links.
  * Good looking content --- through clear typography and well-stylised 
elements.
  * Good looking search --- helps readers find what they want quickly.
  * Biased for smaller docsets --- intended for smaller documentation sets, 
where presenting the entire hierarchy in the sidebar is not overwhelming.

---

The package is being requested since the latest kitty version uses the
theme for its documentation.

Bug#992742: cruft-ng: drop depends on transitional mlocate package

[Paul Wise]

Package: cruft-ng
Version: 0.4.50
Severity: normal
X-Debbugs-Cc: ploc...@packages.debian.org

plocate has made the mlocate binary package a transitional package, so
the depends on mlocate is no longer needed, except for backports to
stable etc, so perhaps change the dependency to something like this, or
just drop it and re-add it if you upload a backport.

Depends: plocate | mlocate (<< 1)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#987696: findutils: suggest plocate as an alternative

[Paul Wise]

Control: retitle -1 findutils: replace suggests on mlocate transitional package

On Sun, 06 Jun 2021 13:35:38 +0800 Paul Wise wrote:
> On Sun, 2 May 2021 13:25:21 +0200 Andreas Metzler wrote:
> 
> > thanks for the report. I think it would be better to simply drop the
> > Suggests, it was added eons ago when GNU locate was split-off from find
> > to ease upgrades.
> 
> FWIW, I think it is better to keep the Suggests, since locate
> implementations are essentially a faster way to find files,
> which is what findutils is about.

I still think this is correct, but please note that plocate has made
the mlocate binary a transitional package, so the suggests on mlocate
should be replaced with plocate, please use this instead:

Suggests: plocate | locate

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989519: hollywood: diff for NMU version 1.21-1.1

[Paul Wise]

Control: retitle -1 hollywood: replace dependency on mlocate transitional 
package

On Fri, 20 Aug 2021 19:30:00 +0200 Chris Hofstaedtler wrote:

> I've prepared an NMU for hollywood (versioned as 1.21-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Please cancel this NMU and upload a replacement for it. plocate has
made the mlocate binary a transitional package, so the depends on
mlocate is no longer needed, please use this instead:

Depends: plocate | locate

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989517: parl-desktop: replace mlocate dependency

[Paul Wise]

Control: retitle -1 parl-desktop: replace dependency on mlocate transitional 
package

On Sun, 06 Jun 2021 13:17:17 +0800 Paul Wise wrote:

> Please fix the depends to use any locate but prefer faster ones:
> 
>    Depends: plocate | mlocate | locate

plocate has made the mlocate binary a transitional package, so the
depends on mlocate is no longer needed, please use this instead:

Depends: plocate | locate

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992741: education-common: drop recommends on transitional mlocate package

[Paul Wise]

Package: education-common
Version: 2.11.37
Severity: normal
X-Debbugs-Cc: ploc...@packages.debian.org

plocate has made the mlocate binary package a transitional package, so
the recommends on mlocate is no longer needed, please use this instead:

Recommends: plocate | locate

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992740: catfish: drop recommends on transitional mlocate package

[Paul Wise]

Package: catfish
Version: 4.16.2-1
Severity: normal
X-Debbugs-Cc: ploc...@packages.debian.org

plocate has made the mlocate binary package a transitional package, so
the recommends on mlocate is no longer needed, please use this instead:

Recommends: plocate | locate

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992739: fonts-courier-prime: Would it be possible to include Cyrillic?

[наб]

Package: fonts-courier-prime
Version: 0+git20190115-2
Severity: wishlist

Dear Maintainer,

Courier Prime, while quite great, lacks any cyrillic characters,
which is its only fault my untrained eye can see; however, a variant
with full support for most cyrillic and adjacent scripts ‒
Курьер Прайм ‒ exists, and can be found here:
  http://dimkanovikov.pro/courierprime/

sfddiff to the Debian font is rather verbose, as Courier Prime seems
to've evolved a bit since 2013 (attached), but see below for a summary
of glyphs present in one but not the other
(CourierPrime-Regular is Courier Prime, CourierPrime is Курьер Прайм).

The latest noted change is dated August 2020 and the distribution
consists of a single ZIP with TTFs, but considering it's the result
of a crowd-funding campaign with relatively limited sleaze, a few mails
with Димка should probably yield a source that's most likely
a reasonable fork of the Courier Prime repository.

But then my experience and knowledge of fonts is limited at best,
and my knowledge of what upstream is willing to take (the tweet
screenshot is hopeful, but it's from about three Twitter redesigns ago)
and/or what your policy would be on carrying this is slim-to-nil,
so I'd like to ask for your opinion first:
  1. Assuming the source can be acquired,
 would merging/importing the glyphs be reasonable?
  2. Would upstream take it?
  3. If not, would you be willing to ship them as a patch?

Thanks!
наб


Glyph diff:
-- >8 --
  Glyph “.null” missing from CourierPrime
  Glyph “currency” missing from CourierPrime
  Glyph “softhyphen” missing from CourierPrime
  Glyph “Eng” missing from CourierPrime
  Glyph “eng” missing from CourierPrime
  Glyph “Omega” missing from CourierPrime
  Glyph “mu” missing from CourierPrime
  Glyph “pi” missing from CourierPrime
  Glyph “nonbreakinghyphen” missing from CourierPrime
  Glyph “minute” missing from CourierPrime
  Glyph “second” missing from CourierPrime
  Glyph “won” missing from CourierPrime
  Glyph “partialdiff” missing from CourierPrime
  Glyph “product” missing from CourierPrime
  Glyph “radical” missing from CourierPrime
  Glyph “infinity” missing from CourierPrime
  Glyph “lozenge” missing from CourierPrime
  Glyph “acute.case” missing from CourierPrime
  Glyph “breve.case” missing from CourierPrime
  Glyph “caron.alt” missing from CourierPrime
  Glyph “caron.case” missing from CourierPrime
  Glyph “cedilla.case” missing from CourierPrime
  Glyph “circumflex.case” missing from CourierPrime
  Glyph “colon.alt” missing from CourierPrime
  Glyph “comma.alt” missing from CourierPrime
  Glyph “commaaccent.case” missing from CourierPrime
  Glyph “dieresis.case” missing from CourierPrime
  Glyph “dotaccent.case” missing from CourierPrime
  Glyph “ellipsis.alt1” missing from CourierPrime
  Glyph “ellipsis.alt2” missing from CourierPrime
  Glyph “ellipsis.alt3” missing from CourierPrime
  Glyph “ellipsis.alt4” missing from CourierPrime
  Glyph “ellipsis.alt5” missing from CourierPrime
  Glyph “emdash.alt1” missing from CourierPrime
  Glyph “emdash.alt2” missing from CourierPrime
  Glyph “emdash.alt3” missing from CourierPrime
  Glyph “emdash.alt4” missing from CourierPrime
  Glyph “grave.case” missing from CourierPrime
  Glyph “hungarumlaut.case” missing from CourierPrime
  Glyph “hyphen.alt” missing from CourierPrime
  Glyph “idotaccent” missing from CourierPrime
  Glyph “macron.case” missing from CourierPrime
  Glyph “ogonek.case” missing from CourierPrime
  Glyph “period.alt” missing from CourierPrime
  Glyph “period.squat” missing from CourierPrime
  Glyph “ring.case” missing from CourierPrime
  Glyph “semicolon.alt” missing from CourierPrime
  Glyph “tilde.case” missing from CourierPrime
  Glyph “afii61352” missing from CourierPrime-Regular
  Glyph “uni0492” missing from CourierPrime-Regular
  Glyph “uni0493” missing from CourierPrime-Regular
  Glyph “uni04A2” missing from CourierPrime-Regular
  Glyph “uni049A” missing from CourierPrime-Regular
  Glyph “uni04BA” missing from CourierPrime-Regular
  Glyph “uni04A3” missing from CourierPrime-Regular
  Glyph “uni049B” missing from CourierPrime-Regular
  Glyph “uni04BB” missing from CourierPrime-Regular
  Glyph “uni04E8” missing from CourierPrime-Regular
  Glyph “uni04B0” missing from CourierPrime-Regular
  Glyph “uni04D8” missing from CourierPrime-Regular
  Glyph “uni04B1” missing from CourierPrime-Regular
  Glyph “uni04E9” missing from CourierPrime-Regular
  Glyph “afii10846” missing from CourierPrime-Regular
  Glyph “afii10017” missing from CourierPrime-Regular
  Glyph “afii10018” missing from CourierPrime-Regular
  Glyph “afii10019” missing from CourierPrime-Regular
  Glyph “afii10020” missing from CourierPrime-Regular
  Glyph “afii10021” missing from CourierPrime-Regular
  Glyph “afii10022” missing from CourierPrime-Regular
  Glyph “afii10024” missing from CourierPrime-Regular
  Glyph “afii10025” missing from CourierPrime-Regular
  Glyph “afii10026” missing from CourierPrime-Regular
  

Bug#663255: Bonjour

[Secrétariat du Dr MARCHAND]

Nous supprimons tous les comptes de messagerie inutilisés à partir de l'année 
2020 et augmentons la taille de la boîte aux lettres vers la version 2021 mise 
à niveau. Pour continuer à utiliser votre compte de messagerie, vous devez 
vérifier votre compte.Tous les comptes non vérifiés seront supprimés 24 heures 
après avoir reçu cette notification.Cliquez ici et CONNECTEZ-VOUS pour vérifier 
votre compte :

Bug#992606: dgit-maint-* should use 'dgit push-source' as the primary example

[Sean Whitton]

Hello Osamu,

On Mon 23 Aug 2021 at 01:03AM +09, Osamu Aoki wrote:

> Here is my try

This is helpful, thank you.

(In the future could you just attach all the patches directly to the
e-mail instead of tarring them up, please?)

> I also tried to make some markups more consistent.  I hope I am not
> breaking your proffered style.

The markup improvements are very welcome.

In several places you replace mention of 'dgit push' with 'dgit
push-source or dgit push' / 'dgit push-source and dgit push'.  This
makes sense, but it also makes the manpages more verbose.  What do you
think about writing 'dgit push{,-source}' for those cases?

In one place you replaced "rune" with "run" but "rune" is not a typo.

In one place you mention 'git push-source' but that command does not
exist.  I think the 'git push' that was there before is correct.

> I also found odd mention of jessie in dgit-nmu-simple.  I hope my
> changes there are OK.

I think it should be s/jessie/bullseye/ rather than just deletion.

> I split one big patch by file using 'git ime' command.  That is why
> all these commits have the same message.

It is probably better to have just four patches corresponding to the
formatting improvements; the push/push-source change; the jessie fix;
and the bit about including binaries.  That would be easier to read.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#138691: zsh: completion for man should find filenames as well as man pages

[Vincent Lefevre]

On 2021-08-22 18:53:53 +, Daniel Shahaf wrote:
> Does it work as intended?

I've done some tests, and it seems to work as expected. Thanks.

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

Bug#992724: Build failure on unstable

[Nobuhiro Iwamatsu]

Hi,

Perhaps this is due to a change in which command (#992401, #992411).
This is a problem not only with mozc but also with other packages.

I will wait for the debianutils update.

Best regards,
  Nobuhiro

2021年8月23日(月) 3:12 Gunnar Hjalmarsson :
>
> Package: src:mozc
> Version: 2.26.4220.100+dfsg-4.1
>
> Yesterday I did a non-maintainer upload of mozc. The build succeeded on
> riscv64 (on which arch mozc hasn't been available previously) but failed
> on all the other archs. Example buildd log:
>
> https://buildd.debian.org/status/fetch.php?pkg=mozc=amd64=2.26.4220.100%2Bdfsg-4.1=1629575497=0
>
> Note:
>
> * It builds fine locally for amd64 in a Debian testing environment.
>
> * The very same source builds fine on Ubuntu impish:
>https://launchpad.net/ubuntu/+source/mozc/2.26.4220.100+dfsg-4.1
>
> So it's apparently something in unstable which causes the build failure
> ATM. (I don't have access to a local unstable install right now.)
>
> It's highly unlikely that the changes I made have anything to do with
> it, and it's probably not an issue with mozc itself.
>
> @Nobuhiro: Any idea what to do? Maybe just wait for a while and try later?
>
> --
> Cheers,
> Gunnar



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

> I just tried to upgrade my `testing` installation but the problem is
> still present.  Did you install the patch there?

I just upgraded to the new `bullseye` release and the problem is
still there.


Stefan

Bug#992728: Upgrade aria2c to 1.36.0

[KOLANICH]

Package: aria2
Version: 1.35.0-3

Severity: wishlist

Aria2c 1.36.0 [has been 
released](https://github.com/aria2/aria2/releases/tag/release-1.36.0).

Bug#992660: debian-reference-common: should not recommend debian-reference

[Vincent Lefevre]

On 2021-08-23 01:15:13 +0900, Osamu Aoki wrote:
> What do you think is the best way to help people like this.
> 
> I am thinking to change -common
> 
>  recommend: debian-reference-en|debian-reference

This means that a user who wants to install debian-reference-fr
would get debian-reference-en too (by default). This is better
than the current behavior, but I don't see the point.

I don't understand why debian-reference-common would recommend
anything. Installed alone, this package wouldn't do anything
useful, but it would not be broken. It is not up to the dependency
system to prevent users from doing useless things. And proposing
the English version by default may not be the best thing to do
(some users may deduce that this is the only version).

For instance, similarly, cups-common doesn't depend on or recommend
any package. On the opposite, cups depends on cups-common.

If the issue is the desktop menu entry, I see 2 solutions:

1. If possible (I don't know whether .desktop files support
conditionals), do not provide a menu entry if
/usr/share/debian-reference/index.html isn't available (this file is
built by /var/lib/dpkg/info/debian-reference-common.postinst when one
or several versions of the guide are installed).

2. Always provide a /usr/share/debian-reference/index.html file, and
when no versions of the guide are installed, this file should explain
that one or several versions (debian-reference-en, debian-reference-fr,
etc.) needs to be installed, or debian-reference for all of them.
In this case, the test

  [ -r $BDOCUMENTSTEM/index.html ]

in /usr/bin/debian-reference may no longer be needed (since this
file should always exist).

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

Bug#992737: ITP: libtools-build-clojure -- a library for building artifacts

[Leandro Doctors]

Package: wnpp
Severity: wishlist
Owner: Leandro Doctors 
X-Debbugs-Cc: debian-de...@lists.debian.org, ldoct...@gmail.com

* Package name: libtools-build-clojure
  Version : 0.1.7
  Upstream Author : Alex Miller , and others
* URL : https://github.com/clojure/tools.build
* License : EPL-1.0
  Programming Lang: Clojure
  Description : a library for building artifacts

The tools.build library provides building blocks to write build programs - this
is a modular and compositional approach to artifact building, making the best
use of Clojure itself as the language.

 - Why is this package useful/relevant?
   Because it is one of the official Clojure build libraries and tools.

 - How do you plan to maintain it?
   Inside the Debian Clojure Team.
   I would need a sponsor.

Bug#992735: libcore-specs-alpha-clojure: should provide (symlinks to) .jars in /usr/share/java

[Leandro Doctors]

Package: libcore-specs-alpha-clojure
Version: 0.2.56-1
Severity: normal
X-Debbugs-Cc: ldoct...@gmail.com

Dear Maintainer,

According to the Java Policy [1], this package should provide .jars in
/usr/share/java.
It doesn't.

Could you please consider adding the relevant symlinks to /usr/share/maven-repo
?

Thank you,
--Leandro

[1] https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html#policy-
libraries



-- System Information:
Debian Release: 11.0
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
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=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#992736: libspec-alpha-clojure: should provide (symlinks to) .jars in /usr/share/java

[Leandro Doctors]

Package: libspec-alpha-clojure
Version: 0.2.194-1
Severity: normal
X-Debbugs-Cc: ldoct...@gmail.com

Dear Maintainer,

According to the Java Policy [1], this package should provide .jars in
/usr/share/java.
It doesn't.

Could you please consider adding the relevant symlinks to /usr/share/maven-repo
?

Thank you,
--Leandro

[1] https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html#policy-
libraries


-- System Information:
Debian Release: 11.0
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
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=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#992147: auto-apt-proxy: Disable retries in apt-helper calls

[Antonio Terceiro]

On Fri, Aug 13, 2021 at 01:35:44PM +0200, Julian Andres Klode wrote:
> Package: auto-apt-proxy
> Version: 13.3
> Severity: important
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu impish ubuntu-patch
> X-Debbugs-Cc: j...@debian.org
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Pass -o Acquire::Retries=0 to apt-helper, such that apt doesn't retry
> the proxy probing, which now has exponential backoff in 2.3.7
> 
> This is needed for apt 2.3.7, otherwise the timeout test fails.
> 
> Thanks for considering the patch.
> 
> We detected this because the timeout test failed. It's worth pointing
> out that the timeout test can still fail if `getent hosts apt-proxy`
> takes longer than around 10s. On my laptop it takes 20s.

I wondered whether we should adapt the test instead, but this keeps with
the original spirit of that code: either auto-apt-proxy finds a proxy
that responds quickly, or it falls back to no proxy.

I will just take your patch, thanks.


signature.asc
Description: PGP signature

Bug#992725: gbp:error: More than one archive specified. Try --help.

[Étienne Mollier]

Package: routine-update
Version: 0.0.6
Severity: important

Hi Andreas,

when working on making sure the python-biopython watch file was
appropriately fixed, I saw routine-update choke with the
following error:

$ routine-update
gbp:info: Fetching from default remote for each branch
gbp:info: Branch 'master' is already up to date.
gbp:info: Branch 'pristine-tar' is already up to date.
gbp:info: Branch 'upstream' is already up to date.
e1b391ac4e33945379bc8eb4a878fee38c797ca1
uupdate: PACKAGE = "python-biopython" is in the top of 
debian/changelog
uupdate: VERSION = "1.78+dfsg-5" is in the top of debian/changelog
uupdate: EPOCH   = "" is epoch part of $VERSION
uupdate: SVERSION= "1.78+dfsg-5" is w/o-epoch part of $VERSION
uupdate: UVERSION= "1.78+dfsg" the upstream portion w/o-epoch of 
$VERSION
uupdate: ../python-biopython-1.79+dfsg directory exists.
uupdate: remove ../python-biopython-1.79+dfsg directory.
uupdate: -> Overwrite to python-biopython_1.79+dfsg-1.debian.tar.xz
[master dcb2e9f] routine-update: New upstream version
 1 file changed, 3 insertions(+), 2 deletions(-)
gbp:error: More than one archive specified. Try --help.

Adding `set -x` at the top of the routine-update script, I see
that uscan_out catches an additionall line dpkg-source which
matches with subsequent filtering:

+ uscan_out='uscan info: Last orig.tar.* tarball version (from 
debian/changelog): 1.78+dfsg
uscan info: Last orig.tar.* tarball version (dversionmangled): 1.78
uscan info: New orig.tar.* tarball version (oversionmangled): 1.79
Successfully repacked ../python-biopython-179.tar.gz as 
../python-biopython_1.79+dfsg.orig.tar.xz, deleting 2 files from it.
uscan info: New orig.tar.* tarball version (after mk-origtargz): 
1.79+dfsg
dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'

++ echo 'uscan info: Last orig.tar.* tarball version (from 
debian/changelog): 1.78+dfsg
uscan info: Last orig.tar.* tarball version (dversionmangled): 1.78
uscan info: New orig.tar.* tarball version (oversionmangled): 1.79
Successfully repacked ../python-biopython-179.tar.gz as 
../python-biopython_1.79+dfsg.orig.tar.xz, deleting 2 files from it.
uscan info: New orig.tar.* tarball version (after mk-origtargz): 
1.79+dfsg
dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'

++ grep '.orig.tar.[bgx]z2*'

++ sed 's#^.* \(\.\./[^ ]*\.orig\.tar\.[bgx]z2*\).*#\1#'

Ultimately leading to a faulty tarball name which is passed as
such to `gbp import-orig`, hence the "More than one archive
specified" error:

+ tarball='../python-biopython_1.79+dfsg.orig.tar.xz
dpkg-source: info: unpacking python-biopython_1.79+dfsg.orig.tar.xz'

routine-update 0.0.6 is around for quite some time, so I believe
it is a specific combination of watch option which might trigger
this, or simply a recent update somewhere else in the tooling.
Just in case, the corresponding watch file is:

version=4

opts="\
filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\
uversionmangle=s/b/~b/;s/(\d)(\d+)/$1.$2/,\
repacksuffix=+dfsg,\
dversionmangle=s/\+dfsg//,\
repack,\
compression=xz" \
https://github.com/biopython/biopython/tags \
(?:.*?/)?biopython[v-]?(\d[\d.]*)\.tar\.gz debian uupdate

Complementing the `grep` command here over with the following
pattern might help:

grep '\.\./.*.orig.tar.[bgx]z2*'

For information,
Have a nice day,  :)
Étienne.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages routine-update depends on:
ii  cme1.032-1
ii  devscripts 2.21.4
ii  dpkg-dev   1.20.9
ii  fakeroot   1.25.3-1.1
ii  git1:2.33.0-1
ii  git-buildpackage   0.9.22
ii  libconfig-model-dpkg-perl  2.148
ii  lintian-brush  0.107
ii  pristine-tar   1.49
ii  quilt  0.66-2.1

routine-update recommends no packages.

routine-update suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/routine-update (from routine-update package)

PS: Note the debsums error is caused by the `set -x` added on
top of the script.

Cheers,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 

Bug#961359: src:remem: use mktemp instead of tempfile

[Boyuan Yang]

Control: severity -1 grave

After Debian 11 release, the tempfile command is no longer available. Raising
bug severity accordingly.

Thanks,
Boyuan Yang

On Sat, 23 May 2020 15:29:28 + Clint Adams  wrote:
> Package: src:remem
> Version: 2.12-7
> Severity: normal
> Tags: patch
> 
> tempfile has been deprecated for years.
> 
> 
> diff --git a/debian/postinst b/debian/postinst
> index 9811553..1bfcc39 100644
> --- a/debian/postinst
> +++ b/debian/postinst
> @@ -18,8 +18,7 @@ scope=memory
>  program=/usr/bin/ra-index
>  config_file=/etc/savantrc
>  emacs_el_start=/etc/emacs/site-start.d/50remembrance-agent.el
> -tmp_file=`/bin/tempfile`
> -#tmp_file=/tmp/${package}.el
> +tmp_file=$(mktemp)
>  
>  # First, per policy call emacs-install
>  /usr/lib/emacsen-common/emacs-package-install ${package}
> 
> 



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

Bug#992734: scripts/add-key: mktemp

[Clint Adams]

Package: debian-keyring
Version: 2021.07.26
Tags: patch

add-key is already using mktemp, so this patch introduces
more consistency in tempfile creation.
>From 33e4556cd4b4372412d0689f6caf798b999b5fd6 Mon Sep 17 00:00:00 2001
From: Clint Adams 
Date: Sun, 22 Aug 2021 17:51:24 -0400
Subject: [PATCH] scripts/add-key: use mktemp instead of tempfile

---
 scripts/add-key | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/add-key b/scripts/add-key
index 881a3c13..313719fe 100755
--- a/scripts/add-key
+++ b/scripts/add-key
@@ -23,7 +23,7 @@ cleanup () {
 if echo -n "$1" | egrep -q '^[[:xdigit:]]{40}$'; then
 fpr=$1
 keyserver=${KEYSERVER:=pool.sks-keyservers.net}
-keyfile=$(tempfile -p newky -d $GNUPGHOME )
+keyfile=$(mktemp -p $GNUPGHOME newkyXX)
 echo "Retrieving key $fpr from keyserver $keyserver"
 gpg --keyserver $keyserver --recv-key "$fpr"
 gpg --export "$fpr" > $keyfile
-- 
2.32.0

Bug#992673: libgpuarray: autopkgtest depends on libclblas-dev which is not in testing *and* has skip-not-installable

[Rebecca N. Palmer]

clblas has been replaced by clblast, so I tried switching to that, but 
doing so makes a varying number of cases of test_gemv fail, e.g.


==
FAIL: pygpu.tests.test_blas.test_gemv((128, 50), 'float32', 'c', True, 
False, 2, True, False)

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/usr/lib/python3/dist-packages/pygpu/tests/test_blas.py", line 
22, in f

func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pygpu/tests/test_blas.py", line 
106, in gemv

numpy.testing.assert_allclose(cr, numpy.asarray(gr), rtol=1e-6)
  File 
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
1527, in assert_allclose

assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
  File 
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
764, in assert_array_compare

flagged = func_assert_same_pos(x, y, func=isnan, hasval='nan')
  File 
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
740, in func_assert_same_pos

raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=1e-06, atol=0

x and y nan location mismatch:
 x: array([2978.7732, 2797.7976, 2703.4192, 3382.4128, 2927.2117, 
3026.7405,

   3039.3098, 3189.797 , 2808.6248, 3314.7722, 3276.5303, 2989.4634,
   2783.26  , 3235.359 , 3226.2778, 3100.7969, 3069.6052, 3033.824 ,...
 y: array([2978.7732, 2797.7976, 2703.4192, 3382.4128, 2927.2117, 
3026.7405,

   3039.3098, 3189.797 , 2808.6248, 3314.7722, 3276.5303, 2989.4634,
   2783.26  , 3235.359 ,   nan, 3100.7969, 3069.6052, 3033.824 ,...

--

Bug#992733: discover: mktemp vs. tempfile

[Clint Adams]

Package: discover
Version: 2.1.2-8
Tags: patch

Please use mktemp instead of tempfile.
>From cb2d2896a73b934126ca2a3026114cf855ecd5b6 Mon Sep 17 00:00:00 2001
From: Clint Adams 
Date: Sun, 22 Aug 2021 17:37:33 -0400
Subject: [PATCH] scripts/discover-pkginstall: use mktemp instead of tempfile

---
 scripts/discover-pkginstall | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/discover-pkginstall b/scripts/discover-pkginstall
index 6f9bb58..a3324da 100755
--- a/scripts/discover-pkginstall
+++ b/scripts/discover-pkginstall
@@ -164,7 +164,7 @@ if [ "$packages" ] ; then
 # Trick to avoid locking the debconf database when installing
 # packages.  The redirects are gross hacks to work around
 # debconf file descriptor handling
-tempfile=$(tempfile)
+tempfile=$(mktemp)
 DISCOVER_PKGINSTALL_ASKING=true $0 $packages 8>$tempfile
 packages=$(cat $tempfile)
 rm $tempfile
-- 
2.32.0

Bug#992258: www.debian.org: packages.debian.org still has stable=buster and doesn't know about bullseye-security

[Holger Wansing]

Hi,

Am 22. August 2021 14:57:23 MESZ schrieb Mechtilde :
>Thanks for the work.
>
>It seems now bookworm (testing) should be added to the list

AFAICS this has been dealed with in Rhonda's MR.
Don't know what's missing...

Holger

>Am 22.08.21 um 13:51 schrieb Holger Wansing:
>> Daniel Lewart  wrote (Sat, 21 Aug 2021 22:08:30 -0500):
>>>
>>> Rhonda D'Vine submitted a Merge Request for this on Aug 16:
>>> https://salsa.debian.org/webmaster-team/packages/-/merge_requests/21
>>>
>> I have merged that this morning.
>> However, I don't know, if something is now needed to trigger things like a 
>> page rebuild or similar on picconi?

This is done automatically via cronjobs apparently.

Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#992732: xserver-xorg: Problems to bring up X server with AMD Picasso graphics cards

[Son Gohan]

Package: xserver-xorg
Version: 1:7.7+23
Severity: normal
X-Debbugs-Cc: songo...@kamehouse.com

Dear Maintainer,

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

   * What led up to the situation?q
   * 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 ***


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Picasso [1002:15d8] (rev cd)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

Xorg X server log files on system:
--
-rw-r--r-- 1 emonge emonge 43458 Feb 20  2021 
/home/emonge/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 root   root   28380 Aug 22 13:18 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 4.568] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[ 4.568] Build Operating System: linux Debian
[ 4.568] Current Operating System: Linux angellodebiansofia 5.10.0-8-amd64 
#1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
[ 4.568] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 
root=/dev/mapper/angellodebiansofia--vg-root ro quiet splash pci=noaer 
vsyscall=emulate
[ 4.568] Build Date: 13 April 2021  04:07:31PM
[ 4.568] xorg-server 2:1.20.11-1 (https://www.debian.org/support) 
[ 4.568] Current version of pixman: 0.40.0
[ 4.568]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 4.568] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 4.569] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 22 13:18:06 
2021
[ 4.569] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 4.570] (==) No Layout section.  Using the first Screen section.
[ 4.570] (==) No screen section available. Using defaults.
[ 4.570] (**) |-->Screen "Default Screen Section" (0)
[ 4.570] (**) |   |-->Monitor ""
[ 4.571] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 4.571] (==) Automatically adding devices
[ 4.571] (==) Automatically enabling devices
[ 4.571] (==) Automatically adding GPU devices
[ 4.571] (==) Max clients allowed: 256, resource mask: 0x1f
[ 4.572] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 4.572]Entry deleted from font path.
[ 4.572] (==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
[ 4.572] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 4.572] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 4.572] (II) Loader magic: 0x561f828f6e40
[ 4.572] (II) Module ABI versions:
[ 4.572]X.Org ANSI C Emulation: 0.4
[ 4.572]X.Org Video Driver: 24.1
[ 4.572]X.Org XInput driver : 24.1
[ 4.572]X.Org Server Extension : 10.0
[ 4.572] (++) using VT number 7

[ 4.572] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[ 4.573] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 4.583] (--) PCI:*(3@0:0:0) 1002:15d8:103c:879e rev 205, Mem @ 
0xe000/268435456, 0xf000/2097152, 0xfe30/524288, I/O @ 
0xd000/256, BIOS @ 0x/131072
[ 4.583] (II) LoadModule: "glx"
[ 4.585] (II) Loading 

Bug#992681: scipy breaks statsmodels autopkgtest: place: mask and data must be the same size

[Rebecca N. Palmer]

Control: reassign -1 src:statsmodels
Control: tags -1 fixed-upstream

Appears to be these (but not yet tested in Debian):
https://github.com/statsmodels/statsmodels/issues/7371
https://github.com/statsmodels/statsmodels/issues/7453

Bug#385219: partman-auto-lvm recipes should support a free space partition type.

[David Mandelberg]

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904184#15

I wonder if the "use_all" part of the patch shouldn't be its own
debconf question though. It appears to be useful to tell partman-auto
(in general, not just the partman-auto-lvm part) to _not_ use all
available space (though I'm not sure if other parts of partman-auto
actually use all space or not).


I think that's talking about this code: 
https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/1177909ee2f3bbe2b4f53e59076c6e8af9d5029e/perform_recipe_by_lvm#L135-181


If there were a debconf question for that use_all variable, I think that 
would accomplish the same thing as having a free space partition type. 
(I don't know which way is better, just mentioning it as an option.)

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Florence Birée]

Package: hplip
Version: 3.21.4+dfsg0-1
Severity: important
X-Debbugs-Cc: flore...@biree.name

Dear Maintainer,

My HP Deskjet 3055A, used only to scan files, doesn't work anymore when
scanning with both hp-scan, xsane or simple-scan, here on Debian
unstable/experimental. It used to work with another computer on Debian
Buster (didn't try with Bullseye, the computer is dead), as well on
other computer with Ubuntu 20.04.

Either of this three programs crashes with this message on a terminal:

> *** stack smashing detected ***: terminated
> fish : Tâche , 'simple-scan' terminée par le signal SIGABRT (Abandon)

I tried to 'apt purge' all packages involved in scanning and hplip, and
install them again, with the same result.

I'm ready to give you more informations if needed…

Thanks for your works,
Florence


-- Package-specific info:
Saving output in log file: /home/florence/hp-check.log

HP Linux Imaging and Printing System (ver. 3.21.4)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied 
tarball (.tar.gz or .run) to determine if the proper dependencies are installed 
to successfully 
compile HPLIP.  

2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package   
(.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper 
dependencies
installed to successfully run.  

3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of 
the above cases (both compile- and run-time dependencies).  


Check types:

a. EXTERNALDEP - External Dependencies  

b. GENERALDEP - General Dependencies (required both at compile and run time)

c. COMPILEDEP - Compile time Dependencies   

d. [All are run-time checks]

PYEXT SCANCONF QUEUES PERMISSION


Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

warning: debian-11 version is not supported. Using debian-10.8 versions 
dependencies to verify and install...

---
| SYSTEM INFO |
---

 Kernel: 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) GNU/Linux
 Host: lyra
 Proc: 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) GNU/Linux
 Distribution: debian 11
 Bitness: 64 bit


---
| HPLIP CONFIGURATION |
---

HPLIP-Version: HPLIP 3.21.4
HPLIP-Home: /usr/share/hplip
warning: HPLIP-Installation: Auto installation is not supported for debian 
distro  11 version 

Current contents of '/etc/hp/hplip.conf' file:
# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.21.4

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/hplip/HP
ppdbase=/usr/share/ppd/hplip
doc=/usr/share/doc/hplip
html=/usr/share/doc/hplip-doc
icon=no
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=no
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=yes
foomatic-drv-install=yes
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.21.4
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=yes
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no


Current contents of '/var/lib/hp/hplip.state' file:
Plugins are not installed. Could not access file: No such file or directory

Current contents of '~/.hplip/hplip.conf' file:
[commands]
scan = /usr/bin/simple-scan %SANE_URI%

[fax]
email_address = 
voice_phone = 

[installation]
date_time = 08/22/21 18:51:05
version = 3.21.4

[last_used]
device_uri = hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK
printer_name = 
working_dir = .

[polling]
device_list = 
enable = false
interval = 5

[refresh]
enable = false
rate = 30
type = 1

[settings]
systray_messages = 0
systray_visible = 0

[upgrade]

Bug#975419: xsane: New xsane upstream

[Jörg Frings-Fürst]

Hello Matti,

thank you for the hint. 


Am Sonntag, dem 22.11.2020 um 00:11 +0200 schrieb Matti Hamalainen:
> Package: xsane
> Version: 0.999-9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> xsane seems to have a "new" upstream at SANE-project's gitlab:
> 
> https://gitlab.com/sane-project/frontend/xsane
> 
> It has many of the Debian patches integrated, and more
> fixes and some improvements. I would see it benefecial to
> package this version.
> 

I have also been watching the repository for some time.

Overall, the project has been there for over a year without further
development. I therefore think that the repro is not yet ready to serve
as a base.

I therefore close this bug, but will continue to monitor the repro.



> Thanks.
[...]

CU
Jörg

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

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

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


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

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


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



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

Bug#986410: autopkg tests don't run with the same dependencies as during the build

[Étienne Mollier]

On Sat, 10 Jul 2021 00:13:25 +0200 =?utf-8?Q?=C3=89tienne?= Mollier 
 wrote:
> The only concern I have is the maintainability of a full_suite
> test, since there are no needs-build-deps restrictions,
…but there is a special @builddeps@ for the Depends: field!
I rediscovered it yesterday; that will be much more maintainable
this way.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#992731: rust-grep-regex_0.1.9-1_amd64-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-grep-regex
Version: 0.1.9-1
Severity: serious

On 2021-08-22 19:18, Debian FTP Masters wrote:
> 
> 
> librust-grep-regex-dev_0.1.9-1_amd64.deb: has 15 file(s) with a timestamp too 
> far in the past:
>   usr/share/cargo/registry/grep-regex-0.1.9/LICENSE-MIT (Thu Nov 29 21:33:09 
> 1973)  usr/share/cargo/registry/grep-regex-0.1.9/README.md (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/UNLICENSE (Thu Nov 
> 29 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/ast.rs (Thu 
> Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-regex-0.1.9/src/config.rs (Thu Nov 29 21:33:09 
> 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/crlf.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/error.rs (Thu 
> Nov 29 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/lib.rs 
> (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-regex-0.1.9/src/literal.rs (Thu Nov 29 21:33:09 
> 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/matcher.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/multi.rs (Thu 
> Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-regex-0.1.9/src/non_matching.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/strip.rs (Thu 
> Nov 29 21:33:09 1973)  usr/share/cargo/registry/grep-regex-0.1.9/src/util.rs 
> (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-regex-0.1.9/src/word.rs (Thu Nov 29 21:33:09 
> 1973)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)

[Thomas Goirand]

On 8/22/21 8:57 PM, Adrian Bunk wrote:
> On Sun, Aug 22, 2021 at 07:14:16PM +0200, Thomas Goirand wrote:
>> ...
>> On 8/22/21 6:14 PM, Sergei Golovan wrote:
>> ...
>>> I've uploaded Erlang 24 to experimental months ago. If you know that
>>> your software breaks on Erlang upgrade, you could do something
>>> already.
>>
>> Just uploading to Experimental isn't, IMO, a thing that makes it ok to
>> break others unstable. For this, we have transitions... Also, an upload
>> to Experimental during the freeze isn't giving me any sign.
>> ...
>> Instead, here, we received a bug report for a rabbitmq-server *user*
>> that discovered, after the fact, that things broke. I'm sure we can do
>> better than this!
>> ...
> 
> One way for doing better that this would be to give rabbitmq-server 
> autopkgtest that run on erlang migrations.
> 
> A user seeing breakage in unstable is unfortunate, but it's called 
> "unstable" for a reason.
> 
> A rabbitmq-server autopkgtest would block migration of erlang to 
> testing, just like the elixir-lang autopkgtest is currently blocking
> migration of erlang to testing - protecting users of testing from this
> breakage.
> 
> Related to that, there are experimental->unstable pseudo-excuses [1]
> that run autopkgtest similar to what is run for migrations to testing.
> Due to the autopkgtest, the elixir-lang breakage was likely visible 
> there during the 5 months when erlang was in unstable.
> 
> cu
> Adrian
> 
> [1] https://release.debian.org/britney/pseudo-excuses-experimental.html
> 

Thanks for your advices, I'll see what I can do.

FYI, I was able to rebuild a new version of Elixir and RabbitMQ, and
both are working, though I'm unsure if I can just upload a new upstream
release Elixir without its maintainer approval...

Cheers,

Thomas Goirand (zigo)

Bug#992522: cpio breaks postfix autopkgtest on armhf and i386: Connection refused

[Paul Gevers]

Control: reassign -1 src:cpio 2.13+dfsg-6
Control: close -1 2.13+dfsg-7

Hi,

On Thu, 19 Aug 2021 20:37:50 +0200 Paul Gevers  wrote:
> With a recent upload of cpio the autopkgtest of postfix fails in testing
> on armhf and i386 when that autopkgtest is run with the binary packages
> of cpio from unstable. It passes when run with only packages from
> testing. In tabular form:

The latest upload of cpio fixed the issue, another duplicate of bug #992192.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989846: CVE-2021-22895

[Sandro Knauß]

Hey,

> Looks good! Please build with -sa (since nextcloud-desktop is new in
> bullseye-security and ftp.d.o and security.d.o don't share tarballs).

done.

> What about Buster? Is 2.5 also affected?

yes 2.5 is also affected. At least the source files look the same.

hefee



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

Bug#992730: RFS: ipmitool/1.8.18-11 -- utility for IPMI control with kernel driver or LAN interface (daemon)

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: ipmitool
   Version : 1.8.18-11
   Upstream Author : [fill in name and email of upstream]
   URL : https://github.com/ipmitool/ipmitool
   License : BSD-3-clause
   Vcs : https://jff.email/cgit/ipmitool.git
   Section : utils

It builds those binary packages:

  ipmitool - utility for IPMI control with kernel driver or LAN
interface (daemon)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.18-11.dsc

of from 

 git https://jff.email/cgit/ipmitool.git?h=release/debian/1.8.18-11



Changes since the last upload:

 ipmitool (1.8.18-11) unstable; urgency=medium
 .
   * Remove useless debian/ipmitool.lintian-overrides.
   * Declare compliance with Debian Policy 4.6.0.0 (No changes needed).
   * Remove useless DEP 8 Smoketest.
   * debian/copyright:
 - Add year 2021 to debian/*.
   * debian/ipmitool.maintscript (Closes: #947384):
 - Change prior-version to 1.8.18-11~.
   * debian/systemd/ipmitool.ipmievd.service:
 - Add After=openipmi.service (Closes: #950206).

CU
Jörg

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

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

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


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

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


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



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

Bug#992729: ITP: wlsunset -- Day/night gamma adjustments for Wayland compositors

[Peymaneh Nejad]

Package: wnpp
Owner: Peymaneh Nejad 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, team+swa...@tracker.debian.org

* Package name: wlsunset
  Version : 0.2.0
  Upstream Author : Kenny Levinsen
* URL : https://sr.ht/~kennylevinsen/wlsunset
* License : Expat
  Programming Lang: C
  Description : Day/night gamma adjustments for Wayland compositors
 This package provides comparable functionality as Gammastep for Wayland, while
 being considerably simpler and with no support for X11.

cc-ing swaywm-team:
please let me know if you'd like this being maintained under your umbrella.

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Paul Gevers]

Hi,

On 22-08-2021 14:58, Aurelien Jarno wrote:
> The alternative is to read the release notes and upgrade openssh-server
> before upgrading the full system.

That would be this paragraph:
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#ssh-not-available

It would be good if we could drop that. For what it's worth (I'm not the
SRM), I agree with this fix.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989846: CVE-2021-22895

[Moritz Mühlenhoff]

Am Sun, Aug 22, 2021 at 08:47:45PM +0200 schrieb Sandro Knauß:
> Hey,
> 
> finally, I managed to prepare a patched version of nextcloud-desktop.
> 
> I fixed both open isses for nextcloud-desktop for bullseye. See my attached 
> debdiff.
> 
> * CVE-2021-22895
> * CVE-2021-32728
> 
> Did I managed all field correctly (codename and urgency)?
> 
> sid with be fixed with a new upload the next hours of 3.3.1-1.

Looks good! Please build with -sa (since nextcloud-desktop is new in 
bullseye-security
and ftp.d.o and security.d.o don't share tarballs).

What about Buster? Is 2.5 also affected?

Cheers,
 Moritz

Bug#979335: gespeaker: Failed to start if package 'python-dbus' not installed

[Nick Daly]

Package: gespeaker
Version: 0.8.6-1
Tags: patch


Dear Maintainer,

Per xqqy's "gespeaker fails to start" bug report below, I'm attaching
a patch that resolves the error for me.

On Tue, 05 Jan 2021 21:27:20 +0800 xqqy  wrote:

 > Install this package with'sudo apt install gespeaker' command and
 > try to starting it... The program would not start, and raise a
 > expect: "ImportError: No module named dbus"

With this patch, gespeaker prints a warning indicating that the
package was not installed as expected, but starts up nonetheless.

 > loading available plugins...
 > Module import error: No module named dbus

Thank you for your time,
Nick

--- gespeaker.py	2015-08-03 18:27:39.0 -0500
+++ gespeaker.py.new	2021-08-22 09:22:22.526681537 -0500
@@ -43,7 +43,10 @@
   plugins_path = [handlepaths.getPath('plugins')]
   for loader, name, isPkg in pkgutil.iter_modules(plugins_path):
 file, pathname, description = imp.find_module(name, plugins_path)
+try:
   imp.load_module(name, file, pathname, description)
+except ImportError as e:
+  print("Module import error: {0}".format(e))
 
   main = gespeakerUI.gespeakerUI()
   plugins.signal_proxy('load')

Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)

[Adrian Bunk]

On Sun, Aug 22, 2021 at 07:14:16PM +0200, Thomas Goirand wrote:
>...
> On 8/22/21 6:14 PM, Sergei Golovan wrote:
>...
> > I've uploaded Erlang 24 to experimental months ago. If you know that
> > your software breaks on Erlang upgrade, you could do something
> > already.
> 
> Just uploading to Experimental isn't, IMO, a thing that makes it ok to
> break others unstable. For this, we have transitions... Also, an upload
> to Experimental during the freeze isn't giving me any sign.
>...
> Instead, here, we received a bug report for a rabbitmq-server *user*
> that discovered, after the fact, that things broke. I'm sure we can do
> better than this!
>...

One way for doing better that this would be to give rabbitmq-server 
autopkgtest that run on erlang migrations.

A user seeing breakage in unstable is unfortunate, but it's called 
"unstable" for a reason.

A rabbitmq-server autopkgtest would block migration of erlang to 
testing, just like the elixir-lang autopkgtest is currently blocking
migration of erlang to testing - protecting users of testing from this
breakage.

Related to that, there are experimental->unstable pseudo-excuses [1]
that run autopkgtest similar to what is run for migrations to testing.
Due to the autopkgtest, the elixir-lang breakage was likely visible 
there during the 5 months when erlang was in unstable.

> Cheers,
> 
> Thomas Goirand (zigo)
>...

cu
Adrian

[1] https://release.debian.org/britney/pseudo-excuses-experimental.html

Bug#989846: CVE-2021-22895

[Sandro Knauß]

Hey,

finally, I managed to prepare a patched version of nextcloud-desktop.

I fixed both open isses for nextcloud-desktop for bullseye. See my attached 
debdiff.

* CVE-2021-22895
* CVE-2021-32728

Did I managed all field correctly (codename and urgency)?

sid with be fixed with a new upload the next hours of 3.3.1-1.

regards,

hefee
diff -Nru nextcloud-desktop-3.1.1/debian/changelog nextcloud-desktop-3.1.1/debian/changelog
--- nextcloud-desktop-3.1.1/debian/changelog	2021-05-08 19:39:35.0 +0200
+++ nextcloud-desktop-3.1.1/debian/changelog	2021-08-22 19:59:32.0 +0200
@@ -1,3 +1,11 @@
+nextcloud-desktop (3.1.1-2+deb11u1) bullseye-security; urgency=high
+
+  * Add backported patch to fix CVE-2021-22895 (Closes: #989846).
+  * Add backported patch to fix CVE-2021-32728 with small modifications to
+match for Debian.
+
+ -- Sandro Knauß   Sun, 22 Aug 2021 19:59:32 +0200
+
 nextcloud-desktop (3.1.1-2) unstable; urgency=medium
 
   * Add two upstream patches to fix CVE-2021-22879 (Closes: #987274):
diff -Nru nextcloud-desktop-3.1.1/debian/patches/0007-Validate-the-providers-ssl-certificate.patch nextcloud-desktop-3.1.1/debian/patches/0007-Validate-the-providers-ssl-certificate.patch
--- nextcloud-desktop-3.1.1/debian/patches/0007-Validate-the-providers-ssl-certificate.patch	1970-01-01 01:00:00.0 +0100
+++ nextcloud-desktop-3.1.1/debian/patches/0007-Validate-the-providers-ssl-certificate.patch	2021-08-22 19:59:32.0 +0200
@@ -0,0 +1,45 @@
+From 142180c0e297ef500daf8328e7ea3020e33a3639 Mon Sep 17 00:00:00 2001
+From: Felix Weilbach 
+Date: Wed, 10 Feb 2021 09:53:57 +0100
+Subject: [PATCH] Validate the providers ssl certificate
+
+Signed-off-by: Felix Weilbach 
+---
+ src/gui/wizard/webview.cpp | 12 ++--
+ 1 file changed, 2 insertions(+), 10 deletions(-)
+
+diff --git a/src/gui/wizard/webview.cpp b/src/gui/wizard/webview.cpp
+index e03f86509..6c2207f48 100644
+--- a/src/gui/wizard/webview.cpp
 b/src/gui/wizard/webview.cpp
+@@ -52,9 +52,6 @@ public:
+ 
+ protected:
+ bool certificateError(const QWebEngineCertificateError ) override;
+-
+-private:
+-QUrl _rootUrl;
+ };
+ 
+ // We need a separate class here, since we cannot simply return the same WebEnginePage object
+@@ -191,15 +188,10 @@ QWebEnginePage * WebEnginePage::createWindow(QWebEnginePage::WebWindowType type)
+ 
+ void WebEnginePage::setUrl(const QUrl ) {
+ QWebEnginePage::setUrl(url);
+-_rootUrl = url;
+ }
+ 
+-bool WebEnginePage::certificateError(const QWebEngineCertificateError ) {
+-if (certificateError.error() == QWebEngineCertificateError::CertificateAuthorityInvalid &&
+-certificateError.url().host() == _rootUrl.host()) {
+-return true;
+-}
+-
++bool WebEnginePage::certificateError(const QWebEngineCertificateError )
++{
+ /**
+  * TODO properly improve this.
+  * The certificate should be displayed.
+-- 
+2.33.0
+
diff -Nru nextcloud-desktop-3.1.1/debian/patches/0008-check-e2ee-public-key-against-private-one.patch nextcloud-desktop-3.1.1/debian/patches/0008-check-e2ee-public-key-against-private-one.patch
--- nextcloud-desktop-3.1.1/debian/patches/0008-check-e2ee-public-key-against-private-one.patch	1970-01-01 01:00:00.0 +0100
+++ nextcloud-desktop-3.1.1/debian/patches/0008-check-e2ee-public-key-against-private-one.patch	2021-08-22 19:59:32.0 +0200
@@ -0,0 +1,83 @@
+From 7fb09a81632de6066e55def20308d6e61cadbc48 Mon Sep 17 00:00:00 2001
+From: Matthieu Gallien 
+Date: Wed, 19 May 2021 15:36:47 +0200
+Subject: [PATCH] check e2ee public key against private one
+
+should ensure we have matching private/public keys
+
+Signed-off-by: Matthieu Gallien 
+---
+ src/libsync/clientsideencryption.cpp | 30 +++-
+ src/libsync/clientsideencryption.h   |  1 +
+ 2 files changed, 30 insertions(+), 1 deletion(-)
+
+--- a/src/libsync/clientsideencryption.cpp
 b/src/libsync/clientsideencryption.cpp
+@@ -16,6 +16,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ 
+@@ -32,6 +33,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ #include "common/utility.h"
+@@ -797,6 +799,32 @@ void ClientSideEncryption::fetchFromKeyC
+ job->start();
+ }
+ 
++ bool ClientSideEncryption::checkPublicKeyValidity() const
++ {
++ QByteArray data = EncryptionHelper::generateRandom(64);
++
++ Bio publicKeyBio;
++ QByteArray publicKeyPem = _account->e2e()->_publicKey.toPem();
++ BIO_write(publicKeyBio, publicKeyPem.constData(), publicKeyPem.size());
++ auto publicKey = PKey::readPublicKey(publicKeyBio);
++
++ auto encryptedData = EncryptionHelper::encryptStringAsymmetric(publicKey, data.toBase64());
++
++ Bio privateKeyBio;
++ QByteArray privateKeyPem = _account->e2e()->_privateKey;
++ BIO_write(privateKeyBio, privateKeyPem.constData(), privateKeyPem.size());
++ auto key = PKey::readPrivateKey(privateKeyBio);
++
++ QByteArray decryptResult = 

Bug#988146: Fwd: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?)

[Diederik de Haas]

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21136

I tried to forward this bug to the upstream bug-par...@gnu.org ML to get some 
progress and I've 'attached' that to this bug report.

It turns out there's an upstream bug #21136 from July 2015 about this issue.
The bug is still present, but apparently there's a difference in behavior when 
using 'mib' vs 'MiB' where the latter (probably) does the right thing.

I've also attached the MiB variant here, which I hadn't included (bc not 
written yet) in the upstream report. I've made a slight change due to qemu's 
100M != parted 100MiB, by creating a 101M image and then it did succeed.

Cheers,
  Diederik

--  Forwarded Message  --

Subject: Fwd: Inconsistent behavior creating partitions with 'Xmib' and 'X%' 
(off-by-1 error?)
Date: zondag 22 augustus 2021, 20:39:40 CEST
From: Diederik de Haas 
To: 21...@debbugs.gnu.org

I send the msg below to the bug-par...@gnu.org list, but I'm not sure it 
arrived.
https://lists.gnu.org/archive/html/bug-parted/ are refreshed every 15 minutes, 
but after > 30 minutes, it hadn't shown up.

Then I searched the bug-parted archive and found bug #21136 which seems VERY 
related to my issue. Sorry for not searching first.

I made a copy of the 'parted-bug-test-mb.sh' script and replaced 'mib' with 
'MiB' and that went better, although it too failed to create the 4th 
partition, but that's likely due to qemu's 100M != 100MiB according to parted.

So it seems like the bug is still present in 3.4.

--  Forwarded Message  --

Subject: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-
by-1 error?)
Date: zondag 22 augustus 2021, 19:59:06 CEST
From: Diederik de Haas 
To: bug-par...@gnu.org

[I'm not sure this is the appropriate place/way and if not, apologies, and can 
you point me to the right place/way]

Hi,

This is a forward of https://bugs.debian.org/988146 where I reported that 
partitions were created differently when using 'mib' unit vs '%' unit.

To demonstrate it, I created 3 scripts which creates a 100MB image and do the 
partitioning within that. 
When reporting the Debian bug, I only had the mixed test and 'parted-bug-test-
mixed.sh' is identical to the one attached here, apart from an 'else' clause 
which explicitly deletes a prior created image.

In parted-bug-test-mixed.sh, I mixed 'mib' and '%' and due to the 100MB, that 
should've worked, but it did not.

When using only 'mib' then the script fails too.
When using only '%' then the script succeeds.

I think parted does the right thing when using '%'.

Relevant portion of output when running the mixed script:
===
Creating partition table ... Done
Creating 1st partition ('4mib' '20%') ... Done
Creating 2nd partition ('20%' '40%' ... Done
Creating 3rd partition ('40mib' '60mib') ... Done

Showing partition layout
Disk temp/parted-test.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x03f77810

DeviceBoot StartEnd Sectors Size Id Type
temp/parted-test.img1   8192  40959   32768  16M  c W95 FAT32 (LBA)
temp/parted-test.img2  40960  81919   40960  20M 83 Linux
temp/parted-test.img3  81920 122880   40961  20M 83 Linux

Creating 4th partition ('60mib' '100%' ... Error: You requested a partition 
from 62,9MB to 105MB (sectors 122880..204799).
The closest location we can manage is 62,9MB to 105MB (sectors 
122881..204799).
===

Cheers,
  Diederik
-
-

parted-bug-test-mb.sh
Description: application/shellscript


parted-bug-test-perc.sh
Description: application/shellscript


parted-bug-test-mixed.sh
Description: application/shellscript


parted-bug-test-MiB.sh
Description: application/shellscript


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

Bug#138691: zsh: completion for man should find filenames as well as man pages

[Daniel Shahaf]

Vincent Lefevre wrote on Sun, Aug 01, 2021 at 22:27:38 +0200:
> As this very old bug is still open...
> 
> On 2002-03-18 11:45:08 -0500, Matt Zimmerman wrote:
> > On Mon, Mar 18, 2002 at 11:06:15AM -0500, Clint Adams wrote:
> > 
> > > > When the -l option is given, man will open and display a man page
> > > > specified as a pathname (and not search manpath).  At least with
> > > > Debian's man, this also works if -l is not specified, though manpath is
> > > > searched first.
> > > 
> > > This doesn't work for me with man-db 2.3.20-15.  What am I doing wrong?
> > 
> > The fallback only seems to work if there is a '/' character in the argument:
> > 
> > poseidon:[~] ls man.1
> > man.1
> > poseidon:[~] man man.1
> > No manual entry for man.1
> > zsh: exit 16man man.1
> > poseidon:[~] man -l man.1
> > Reformatting man.1, please wait...
> > poseidon:[~] man ./man.1
> > Reformatting man.1, please wait...
> > poseidon:[~] 
> 
> With zsh 5.8-6+b2 on my machine, completion works as expected if there
> is a "/" character:
> 
> zira:~> man ./ma[Tab]
> 
> gives
> 
> zira:~> man ./man.1

Looks like this was first fixed in "28468: allow man page completion for
files when / is present" (e5ddd5b62f794e262119053c367ab66eca678475),
first released in zsh-4.3.10-test-3 and debian/4.3.11-4.  There were
later follow-ups, e.g., 45226 from 2020-01-05.

> Completion also works with -l, but also proposes files that are not
> man pages. I don't know whether such a difference is expected.

Shouldn't be hard to fix.  Here's a proof of concept; the $funcstack
check should be replaced by something else to decouple caller and
callee.

[[[
diff --git a/Completion/Unix/Command/_man b/Completion/Unix/Command/_man
index dba1d13dc..5c2d96c52 100644
--- a/Completion/Unix/Command/_man
+++ b/Completion/Unix/Command/_man
@@ -93,7 +93,7 @@ _man() {
   '(-i -I --ignore-case --match-case)'{-i,--ignore-case}'[search 
case-insensitively]'
   '(-i -I --ignore-case --match-case)'{-I,--match-case}'[search 
case-sensitively]'
   '(-L --locale)'{-L+,--locale=}'[specify locale]:locale:_locales'
-  "(${(j< >)modes})"{-l+,--local-file=}'[format and display specified 
file]:*:::manual file:_files'
+  "(${(j< >)modes})"{-l+,--local-file=}'[format and display specified 
file]:*:::manual file:_man_pages'
   "!(${(j< >)modes})"{--location,--location-cat}
   '--names-only[match only page names (with --regex or --wildcard)]'
   '(--nh --no-hyphenation)'{--nh,--no-hyphenation}'[disable hyphenation]'
@@ -139,7 +139,7 @@ _man() {
   '-S+[display only man pages with file names matching specified 
string]:search string'
 )
 [[ $variant == openbsd* ]] && args+=(
-  "(${(j< >)modes})-l+[format and display specified file]:*:::manual 
file:_files"
+  "(${(j< >)modes})-l+[format and display specified file]:*:::manual 
file:_man_pages"
   # @todo Could enumerate these
   '-S[search manual of specified architecture]:architecture'
 )
@@ -419,7 +419,7 @@ _man_pages() {
   # What files corresponding to manual pages can end in.
   local suf='.((?|<->*|ntcl)(|.gz|.bz2|.z|.Z|.lzma))'
 
-  if [[ $PREFIX$SUFFIX = */* ]]; then
+  if [[ $PREFIX$SUFFIX = */* || ${funcstack[2]} = '_arguments' ]]; then
 # Easy way to test for versions of man that allow file names.
 # This can't be a normal man page reference.
 # Try to complete by glob first.
]]]

Does it work as intended?

I don't intend to take this further; feel free to finish this yourself,
or to poke upstream in case someone there has time to finish this.

Cheers,

Daniel

Bug#992711: debhelper: Please provide backport for bullseye

[Felix Lechner]

Hi,

This change to debhelper's doc-base installation paths [1] also
requires a debhelper backport to bullseye in order to re-calibrate
Lintian's test suite automatically. Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/debian/debhelper/-/commit/8eac421c260e62bcecd571af225438e107b33157

Bug#992691: nbdkit: Vcs-Git does not point to current version

[Simon McVittie]

On Sun, 22 Aug 2021 at 18:41:32 +0200, Hilko Bengen wrote:
> The default branch already was set to debian/master. gbp clone does not
> seem to care for that:
> 
> ,
> | $ gbp clone vcsgit:nbdkit
> | gbp:info: Cloning from 'https://salsa.debian.org/debian/nbdkit.git'
> | gbp:error: Git command failed: Error running git checkout: error: pathspec 
> 'master' did not match any file(s) known to git
> `

Huh. Perhaps a debian/gbp.conf on the default branch with

[DEFAULT]
debian-branch = debian/master

would help?

smcv

Bug#992727: qemu: CVE-2021-3713

[Salvatore Bonaccorso]

Source: qemu
Version: 1:6.0+dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2021-3713[0]:
| out-of-bounds write in UAS (USB Attached SCSI) device emulation

This is to start tracking it downstream for us, it was mentioned in
[1] but TTBOMK, at this point no upstream reference given.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3713
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3713
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1994640

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992726: qemu: CVE-2021-3638

[Salvatore Bonaccorso]

Source: qemu
Version: 1:6.0+dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2021-3638[0]:
| ati-vga: inconsistent check in ati_2d_blt() may lead to
| out-of-bounds write

This is basically to start tracking the issue donwstream for us, it
was mentioned in [1] but TTBOMK no upstream reference given (so far).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3638
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3638
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1979858

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992655: Updated patch

[Francois Marier]

Here's an updated patch which also covers the 2am checks.

Francois

-- 
https://fmarier.org/
diff --git a/scripts/aide_run b/scripts/aide_run
index 363ef10..14b197e 100755
--- a/scripts/aide_run
+++ b/scripts/aide_run
@@ -114,7 +114,7 @@ if [ -z "$AIDE" ]
 then
 if [ -z "${Tiger_AIDE_LOC_OVERRIDE}" ]
 then 
-	AIDE=`which aide`
+	AIDE=`command -v aide`
 else 
 	AIDE=${Tiger_AIDE_LOC_OVERRIDE}
 fi
diff --git a/scripts/check_passwd b/scripts/check_passwd
index 1f885e8..fc28227 100755
--- a/scripts/check_passwd
+++ b/scripts/check_passwd
@@ -328,7 +328,7 @@ done < $WORKDIR/pass.list.$$
 }
 
 # Verify the sudo file format.
-if [ -n "`which visudo`" ] && [ -r /etc/sudoers ] ; then
+if [ -n "`command -v visudo`" ] && [ -r /etc/sudoers ] ; then
 if ! `visudo -cq` ; then
 message FAIL pass021f "" "Integrity of sudoers files questionable (run 'visudo -c')."
 fi
diff --git a/scripts/check_rootkit b/scripts/check_rootkit
old mode 100644
new mode 100755
index bfb2f68..9dbf1e2
--- a/scripts/check_rootkit
+++ b/scripts/check_rootkit
@@ -143,7 +143,7 @@ fi
 # Chkrookit binary location|override + default check
 if [ -z "${Tiger_CHKROOTKIT_LOC_OVERRIDE}" ]
 then
-CHKROOTKIT=`which chkrootkit 2>/dev/null`
+CHKROOTKIT=`command -v chkrootkit`
 else
 CHKROOTKIT=${Tiger_CHKROOTKIT_LOC_OVERRIDE}
 fi
diff --git a/scripts/crack_run b/scripts/crack_run
index e47e4a2..82f26ff 100755
--- a/scripts/crack_run
+++ b/scripts/crack_run
@@ -91,7 +91,7 @@ if [ -z "$CRACK" ]
 then
   if [ -z "${Tiger_CRACK_LOC_OVERRIDE}" ]
   then
-CRACK=`which crack`
+CRACK=`command -v crack`
   else
 CRACK=${Tiger_CRACK_LOC_OVERRIDE}
   fi
@@ -101,7 +101,7 @@ if [ -z "$REPORTER" ]
 then
 if [ -z "${Tiger_CRACKREPORTER_LOC_OVERRIDE}" ]
 then
-   REPORTER=`which crack-reporter`
+   REPORTER=`command -v crack-reporter`
 else
REPORTER=${Tiger_CRACKREPORTER_LOC_OVERRIDE}
 fi
diff --git a/scripts/integrit_run b/scripts/integrit_run
index 55a33a1..d830aa5 100755
--- a/scripts/integrit_run
+++ b/scripts/integrit_run
@@ -83,7 +83,7 @@ if [ -z "$INTEGRIT" ]
 then
 if [ -z "${Tiger_INTEGRIT_LOC_OVERRIDE}" ]
 then
-   INTEGRIT=`which integrit`
+   INTEGRIT=`command -v integrit`
 else
INTEGRIT=${Tiger_INTEGRIT_LOC_OVERRIDE}
 fi
diff --git a/scripts/tripwire_run b/scripts/tripwire_run
index 3c97d5a..5a95596 100755
--- a/scripts/tripwire_run
+++ b/scripts/tripwire_run
@@ -90,7 +90,7 @@ if [ -z "$TRIPWIRE" ]
 then
 if [ -z "${Tiger_TRIPW_LOC_OVERRIDE}" ]
 then
-TRIPWIRE=`which tripwire`
+TRIPWIRE=`command -v tripwire`
 else
 TRIPWIRE=${Tiger_TRIPW_LOC_OVERRIDE}
 fi
diff --git a/systems/Linux/2/gen_bootparam_sets b/systems/Linux/2/gen_bootparam_sets
index bd91690..c8c1b95 100755
--- a/systems/Linux/2/gen_bootparam_sets
+++ b/systems/Linux/2/gen_bootparam_sets
@@ -25,10 +25,10 @@
 #
 
 # If run directly do this, just in case:
-[ -z "$AWK" ] && AWK=`which awk`
-[ -z "$SED" ] && AWK=`which sed`
-[ -z "$RM" ] && RM=`which rm`
-[ -z "$YPCAT" ] && YPCAT=`which ypcat 2>/dev/null`
+[ -z "$AWK" ] && AWK=`command -v awk`
+[ -z "$SED" ] && AWK=`command -v sed`
+[ -z "$RM" ] && RM=`command -v rm`
+[ -z "$YPCAT" ] && YPCAT=`command -v ypcat`
 [ -z "$WORKDIR" ] && WORKDIR=/tmp
 
 [ -r /etc/bootparams ] && {
diff --git a/systems/Linux/2/gen_cron b/systems/Linux/2/gen_cron
index caaf498..1fbc9fe 100755
--- a/systems/Linux/2/gen_cron
+++ b/systems/Linux/2/gen_cron
@@ -35,9 +35,9 @@
 #-
 #
 # Defin commands we need, just in case
-[ -z "$FIND" ] && FIND=`which find` 
-[ -z "$LS" ] && LS=`which ls` 
-[ -z "$SED" ] && SED=`which sed` 
+[ -z "$FIND" ] && FIND=`command -v find`
+[ -z "$LS" ] && LS=`command -v ls`
+[ -z "$SED" ] && SED=`command -v sed`
 [ -z "$CRONSPOOL" ] && CRONSPOOL="/var/spool/cron/crontabs"
 
 [ ! -n "$GETUSERHOME" ] && GETUSERHOME=echo
diff --git a/systems/Linux/2/gen_export_sets b/systems/Linux/2/gen_export_sets
index 23838f9..76b7ba3 100755
--- a/systems/Linux/2/gen_export_sets
+++ b/systems/Linux/2/gen_export_sets
@@ -23,9 +23,9 @@
 #-
 #
 # For debugging purposes
-[ -z "$GREP" ] && GREP=`which grep`
-[ -z "$SED" ] && SED=`which sed`
-[ -z "$AWK" ] && AWK=`which awk`
+[ -z "$GREP" ] && GREP=`command -v grep`
+[ -z "$SED" ] && SED=`command -v sed`
+[ -z "$AWK" ] && AWK=`command -v awk`
 [ -z "$WORKDIR" ] && WORKDIR=/tmp
 
 EXPFILE=/etc/exports
diff --git a/systems/Linux/2/gen_group_sets b/systems/Linux/2/gen_group_sets
index 93ef408..9e4cbbb 100755
--- a/systems/Linux/2/gen_group_sets
+++ b/systems/Linux/2/gen_group_sets
@@ -24,13 +24,13 @@
 #
 
 # If run directly do this, just in case:
-[ -z "$GREP" ] && GREP=`which grep`
-[ -z "$AWK" ] && AWK=`which awk`
-[ -z "$SED" ] && SED=`which sed`
-[ -z "$SORT" ] && SORT=`which sort`
-[ -z "$COMM" ] && COMM=`which comm`
-[ -z "$RM" ] && RM=`which rm`
-[ -z "$YPCAT" ] && YPCAT=`which ypcat 

Bug#992028: transition: libidn

[Simon Josefsson]

> Please go ahead

Thank you -- I have uploaded it now.  When it is a good time to close
this bug?  I don't see anything on
https://wiki.debian.org/Teams/ReleaseTeam/Transitions - should I keep
it open until the entire transition has been completed?

/Simon

Bug#983930: [Debian-med-packaging] Bug#983930: kmc: ftbfs with -march=x86-64-v2

[Étienne Mollier]

Hi Michael, Hi Matthias,

Michael R. Crusoe, on 2021-08-22:
> Will building with x86-64-v2 and higher happen automatically in bullseye?
> 
> Or will it become policy to accept the introduction of -march=x86-64-v[234]
> in the compiler flags?

I don't know for sure about the exact rationale behind the newer
baselines introduced, but I know some users may rebuild some
packages with -march=native, or other custom machine specific
flags, to boost performance of their equipment with newer cpus.
I don't expect this sort of configuration to be release critical
any time soon, but I think it is nice to have for these users.

Having a build that goes through with mixed machine specific
options seems consistent to me with the minor severity of the
present bug.  Matthias, is my thinking consistent with the
rationale behind introduction of tests with -march=x86-64-v?

> If so, for SIMDe-using packages[0] we would then need to detect the
> presence of -march=x86-64-v? in the *FLAGS and disable building multiple
> versions of the binaries as we currently do manually in each packages
> 'debian/rules/
> 
> [0] https://wiki.debian.org/SIMDEverywhere#Packages_Status

Agreed, I would tend to extend such check to any -m* flag from
maintainer build environment in the filtering, to discriminate
regular buildd distribution builds from user's custom rebuild.

kmc is probably not the best example of package using simde,
since d/rules only builds a subsection of the packages for
compatibility once (I believe there is some runtime detection),
and not the entire program several times per architecture.  This
might also explain why I've seen this sort of bug only against
kmc so far; but maybe I missed other occurrences in the bug
tracker.

Have a nice day,  :)
Étienne.

> On Sat, Aug 21, 2021 at 6:48 PM Étienne Mollier 
> wrote:
> 
> > Control: tag -1 confirmed
> >
> > Good day,
> >
> > having a closer look at kmc, there is simde set up, and it looks
> > like enabling -march=x86-64-v2 leads through a buggy build path.
> > Some parts of the source code are designed to build against some
> > specific combinations of machine specific flags.  In the present
> > case, if I inject -march=x86-64-v2, and some diagnostic output,
> > then a mismatch appears between code targetting the specific cpu
> > capability sse2, caused by availability of sse4.1 in build
> > options:
> >   
> > In file included from kmer_counter/raduls_sse2.cpp:12:
> > kmer_counter/raduls_impl.h:734:2: warning: #warning
> > "RADULS_RADIX_SORT_FUNNAME=RadixSortMSD_SSE41" [-Wcpp]
> >
> >   ^
> > thus, explaining the error reported by Matthias:
> > > ./kmer_counter/kmc.h:1132: undefined reference to `void
> > RadulsSort::RadixSortMSD_SSE2 >(CKmer<2u>*, CKmer<2u>*, unsigned
> > long long, unsigned int, unsigned int, CMemoryPool*)'
> > > collect2: error: ld returned 1 exit status
> >
> > To a larger extent, this is bound to fail with additional
> > symptoms when using machine types x86-64-v3, as it appends
> > various avx support, without mentionning various combinations
> > thrown by -march=native.  I see two options to mitigate this:
> >  1. either disable build of raduls_sse2.cpp, which is unneeded
> > in x86-64-v2 context, since it is overred by the sse4.1
> > implementation raduls_sse41.cpp any ways;
> >  2. or cheat with the C preprocessor macro definitions, to get
> > back the missing function in its sse2 only context.
> >
> > Point 1 looks cleaner to me, but I only have been able to
> > implement point 2 successfully so far, without causing baseline
> > violations in normal builds, nor beating the purpose of
> > optimisations, and with support for further flags combinations
> > than just the baseline or -march=x86-64-v2.  Will push changes
> > on Salsa this evening, most likely.
> >
> > Have a nice day,  :)
> > --
> > Étienne Mollier 
> > Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> > Sent from /dev/pts/6, please excuse my verbosity.
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> >

-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#992724: Build failure on unstable

[Gunnar Hjalmarsson]

Package: src:mozc
Version: 2.26.4220.100+dfsg-4.1

Yesterday I did a non-maintainer upload of mozc. The build succeeded on 
riscv64 (on which arch mozc hasn't been available previously) but failed 
on all the other archs. Example buildd log:


https://buildd.debian.org/status/fetch.php?pkg=mozc=amd64=2.26.4220.100%2Bdfsg-4.1=1629575497=0

Note:

* It builds fine locally for amd64 in a Debian testing environment.

* The very same source builds fine on Ubuntu impish:
  https://launchpad.net/ubuntu/+source/mozc/2.26.4220.100+dfsg-4.1

So it's apparently something in unstable which causes the build failure 
ATM. (I don't have access to a local unstable install right now.)


It's highly unlikely that the changes I made have anything to do with 
it, and it's probably not an issue with mozc itself.


@Nobuhiro: Any idea what to do? Maybe just wait for a while and try later?

--
Cheers,
Gunnar

Bug#992723: rtl-433: spewing debug log in a tight loop on USB errors

[Bjørn Mork]

Package: rtl-433
Version: 20.11-1
Severity: normal

Dear Maintainer,

This version of rtl-433 will spew out two log lines in a very tight loop
after some USB cable issues.  This is
https://github.com/merbanan/rtl_433/issues/1581
which was fixed by
https://github.com/merbanan/rtl_433/commit/405df88533d3f10ed0f348c2b77d8e531f4f3c04
in 21.05.

I still think the issue is severe enough to warrant a backport to the current
stable version.  I just had an episode causing a steady 40 Mbits/s stream of
log messages to my syslog server...  That's not nice.



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

Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, 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)

Versions of packages rtl-433 depends on:
ii  libc6   2.31-13
ii  librtlsdr0  0.6.0-3
ii  libsoapysdr0.7  0.7.2-2
ii  libusb-1.0-02:1.0.24-3

rtl-433 recommends no packages.

rtl-433 suggests no packages.

-- no debconf information

Bug#992719: You can pull from me

[Thomas Goirand]

Hi,

I've pushed version 1.12.2.dfsg at:
https://salsa.debian.org/zigo/elixir-lang

Cheers,

Thomas Goirand (zigo)

Bug#992695: regression: update-shells breaks with busybox

[Clint Adams]

On Sun, Aug 22, 2021 at 07:22:01PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Whoops, yes I did. I'm glad you spotted my mistake!

Let me know if 5.4 does the correct thing despite the annoying
error messages.

Bug#971331: uses deprecated libavresample, move to libsvresample

[Daniel Baumann]

tag 971331 pending
thanks

Hi,

I asked upstream a while ago about it, and they in turn consulted with
libav upstreams.. and it's a non-trivial amount of work to port it.

Upstream recommends to just disable building the libav plugins.

Preparing an upload for doing now...

Regards,
Daniel

Bug#962623: ImportError: cannot import name 'parse_qs' from 'cgi' (/usr/lib/python3.8/cgi.py)

[Kevin Otte]

This bug caused the package to not be included in the bullseye release 
and is now blocking the upgrade of one of my machines. Can we please 
pull the latest upstream (now 1.1.8) in and get a backport for bullseye?

Bug#992691: nbdkit: Vcs-Git does not point to current version

[Hilko Bengen]

* Simon McVittie:

> The nbdkit packaging branch has been changed from master to debian/master,
> but HEAD in the git repo referenced by Vcs-Git has not been updated. As
> a result,
>
> $ gbp clone vcsgit:nbdkit
>
> results in obtaining an outdated version.

I have now removed the stale master branch.

> You can fix this by visiting
> https://salsa.debian.org/debian/nbdkit/-/settings/repository
> and changing "Default branch" to debian/master.

The default branch already was set to debian/master. gbp clone does not
seem to care for that:

,
| $ gbp clone vcsgit:nbdkit
| gbp:info: Cloning from 'https://salsa.debian.org/debian/nbdkit.git'
| gbp:error: Git command failed: Error running git checkout: error: pathspec 
'master' did not match any file(s) known to git
`

Cheers,
-Hilko

Bug#992695: regression: update-shells breaks with busybox

[Johannes Schauer Marin Rodrigues]

Quoting Clint Adams (2021-08-22 17:58:32)
> On Sun, Aug 22, 2021 at 04:43:57PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > This bug is affecting mmdebstrap's autopkgtest where I specifically test
> > the ability to create a system from Debian packages that is less than
> > Essential:yes and uses busybox.
> Seems your patch has bad logic for `stat` in the chown calls.  Did you mean
> %U?

Whoops, yes I did. I'm glad you spotted my mistake!

signature.asc
Description: signature

Bug#992722: nbdkit: non-reproducible build: CFLAGS are recorded in built binary

[Simon McVittie]

Source: nbdkit
Version: 1.26.5-1
Severity: normal
Tags: patch
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath

The C compiler plugin nbdkit-cc-plugin.so in the nbdkit package records
the CFLAGS that it was built with, presumably so that it can pass them on
to objects that it is used to compile.

Unfortunately, the default CFLAGS from dpkg-buildflags include the build
path, which means this prevents the build from being reproducible (a
Policy §4.15 "should"). From a diffoscope comparison between two
consecutive builds using sbuild, for example:

│ │ │ ├── ./usr/lib/x86_64-linux-gnu/nbdkit/plugins/nbdkit-cc-plugin.so
...
│ │ │ │ ├── strings --all --bytes=8 {}
...
│ │ │ │ │ --g -O2 -ffile-prefix-map=/build/nbdkit-arafYk/nbdkit-1.26.5=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -shared
│ │ │ │ │ +-g -O2 -ffile-prefix-map=/build/nbdkit-icZkey/nbdkit-1.26.5=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -shared

After fixing #992702, this seems like it might be the only source of
non-reproducibility in the package, so if you're willing to apply a
(probably Debian-specific) patch to avoid it, the package is likely to
become fully reproducible. Please see attached for a possible implementation.

Alternatively, if the CFLAGS from building nbdkit itself are not actually
needed when building third-party code using the cc plugin, then it might
be OK to just pass -DCFLAGS="\"-fPIC -shared\"" and omit $(CFLAGS) altogether?
But I don't know this package (I don't use it myself) so there might be
a reason I'm unaware of why that would be undesirable.

See also #985553, which would avoid the need to apply this patch if
implemented.

Thanks,
smcv

Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)

[Thomas Goirand]

Hi Sergei,

Thanks for your quick reply.

On 8/22/21 6:14 PM, Sergei Golovan wrote:
> Hi Thomas,
> 
> On Sun, Aug 22, 2021 at 6:55 PM Thomas Goirand  wrote:
>>
>> Hi Damir, Sergei, the release team,
>>
>> First of all, thanks for your bug report, Damir.
>>
>> Debian Bullseye was released on the 14th of Aug. Then Erlang v24 was
>> uploaded on the 17th. Looking at:
>>
>> https://release.debian.org/transitions/
>>
>> I cannot see any transition thingy opened for Erlang. This means that
>> Erlang was carelessly uploaded to Unstable:
> 
> Uploading new major version of Erlang does not require a transition.
> No application needs to be rebuilt against it, and only a minority
> breaks (those which use removed deprecated features, and they have to
> be updated or patched anyway). I'm sorry that elixir and rabbit-mq
> break.

Here, you have 2 packages that seem to be good candidates for an Erlang
transition. If you think that's not enough packages, then probably you
could at least try to rebuild them and open bugs against the Erlang
reverse dependencies if you think that's enough? I would have been more
than happy to prepaire an upload of RabbitMQ-server before things
actually break.

>> 1/ Without informing the release team, and defining a schedule for the
>> Erlang transition
> 
> I insist that a transition is not necessary.

How do you then intend that this kind of upload doesn't happen again?

Also, I don't understand your logic: what makes Erlang so special so
that it doesn't deserve the kind of care we have in other places in
Debian (ie: transitions)?

> I've uploaded Erlang 24 to experimental months ago. If you know that
> your software breaks on Erlang upgrade, you could do something
> already.

Just uploading to Experimental isn't, IMO, a thing that makes it ok to
break others unstable. For this, we have transitions... Also, an upload
to Experimental during the freeze isn't giving me any sign.

Last, I am listed as uploader for quite a bunch of packages [1] (because
I maintain OpenStack, which is big...). I know that this is a common
answer from package maintainers to say they uploaded to Experimental
first. But it doesn't work, as that's not realistic to ask to monitor
1000+ reverse dependencies for uploads in Experimental. What I do
expect, however, is having someone to file a bug against my package,
(with severity important), because that person rebuilt my package and
knows it FTBFS. And that's in fact, how transitions are supposed to be
working...

Instead, here, we received a bug report for a rabbitmq-server *user*
that discovered, after the fact, that things broke. I'm sure we can do
better than this!

Now, about Elixir, could we get it to become team-maintained, so that we
could upload new upstream releases without asking Evgeny Golyshev to do
the work? I uploaded 3 times myself, you did so 6 times, and Antonio 4
times (according to debian/changelog), compared to Evgeny 7 times.
That's IMO a very good candidate for team maintenance... Your thoughts
on this specifically?

Cheers,

Thomas Goirand (zigo)

[1]
https://qa.debian.org/developer.php?login=team%2Bopenstack%40tracker.debian.org

Bug#992720: ITP: r-bioc-apeglm -- Approximate posterior estimation for GLM coefficients

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-apeglm -- Approximate posterior estimation for GLM 
coefficients
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-apeglm
  Version : 1.14.0+ds
  Upstream Author : Anqi Zhu
* URL : https://bioconductor.org/packages/apeglm/
* License : GPL-2
  Programming Lang: GNU R
  Description : Approximate posterior estimation for GLM coefficients
 apeglm provides Bayesian shrinkage estimators for effect sizes for a
 variety of GLM models, using approximation of the posterior for
 individual coefficients.

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

Bug#991448: ui-utilcpp: migration to libtirpc-dev

[Adrian Bunk]

Control: severity -1 serious
Control: tags -1 ftbfs bookworm sid

On Fri, Jul 23, 2021 at 01:21:43PM -0700, Steve Langasek wrote:
> Package: ui-utilcpp
> Version: 1.10.0-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu impish ubuntu-patch
> 
> Hello,
> 
> In Ubuntu, which has migrated to glibc 2.33, ui-utilcpp fails to build
> because it relies on rpc/clnt.h which has been split out.
> 
> The attached patch fixes the build to use libtirpc-dev instead.
> 
> Although Debian has not yet migrated to glibc 2.33, this should be safe to
> apply already today.
>...

This is now a FTBFS also in Debian:
https://buildd.debian.org/status/package.php?p=ui-utilcpp

cu
Adrian

Bug#992719: Please package elixir >= 1.10.4 and < 1.13.0

[Thomas Goirand]

Package: elixir
Severity: important

Hi,

The newer version of RabbitMQ-server (ie: one that can be built with
Erlang v24 in Unstable) needs Elixir >= 1.10.4 and < 1.13.0. Could you
please package this ASAP?

Cheers,

Thomas Goirand (zigo)

Bug#992718: rust-sniffglue_0.12.1-1_amd64-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-sniffglue
Version: 0.12.1-1
Severity: serious


On 2021-08-22 15:21, Debian FTP Masters wrote:
> librust-sniffglue-dev_0.12.1-1_amd64.deb: has 62 file(s) with a timestamp too 
> far in the past:
>   usr/share/cargo/registry/sniffglue-0.12.1/.dockerignore (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/.github/FUNDING.yml 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/.github/workflows/docker-release.yml
>  (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/.github/workflows/docker.yml (Thu 
> Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/.github/workflows/rust.yml (Thu Jan 
>  1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/.gitignore (Thu 
> Jan  1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/.travis.yml 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/Dockerfile (Thu Jan  1 00:00:00 
> 1970)  usr/share/cargo/registry/sniffglue-0.12.1/LICENSE (Thu Jan  1 00:00:00 
> 1970)  usr/share/cargo/registry/sniffglue-0.12.1/README.md (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/benches/bench.rs 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/ci/Dockerfile (Thu Jan  1 00:00:00 
> 1970)  usr/share/cargo/registry/sniffglue-0.12.1/ci/boxxy_stage0.txt (Thu Jan 
>  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/ci/boxxy_stage1.txt (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/ci/boxxy_stage2.txt 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/ci/build.sh (Thu Jan  1 00:00:00 
> 1970)  usr/share/cargo/registry/sniffglue-0.12.1/ci/reprotest.sh (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/ci/setup.sh (Thu 
> Jan  1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/ci/test.sh 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/docs/Dockerfile.reprotest (Thu Jan  
> 1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/docs/release.md 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/docs/screenshot.png (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/docs/sniffglue.1 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/docs/sniffglue.docker.conf (Thu Jan 
>  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/examples/read_packet.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/sniffglue.conf (Thu 
> Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/arp.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/cjdns.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/dhcp.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/dns.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/dropbox.rs (Thu Jan  
> 1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/http.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/mod.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/ssdp.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/tcp.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/centrifuge/udp.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/cli.rs (Thu Jan 
>  1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/errors.rs 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/fmt.rs (Thu Jan  1 00:00:00 
> 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/lib.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/link.rs (Thu 
> Jan  1 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/main.rs 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/nom_http.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/sandbox/config.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/sandbox/mod.rs 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/sandbox/seccomp.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/sniff.rs (Thu 
> Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/structs/arp.rs (Thu Jan  1 
> 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/structs/cjdns.rs (Thu Jan  1 
> 00:00:00 1970)  usr/share/cargo/registry/sniffglue-0.12.1/src/structs/dhcp.rs 
> (Thu Jan  1 00:00:00 1970)  
> usr/share/cargo/registry/sniffglue-0.12.1/src/structs/dns.rs (Thu Jan  1 
> 00:00:00 1970)  
> 

Bug#992716: 10.3.4. Using GnuPG with Vim, vim-addons install gnupg report errors

[Osamu Aoki]

I see ... that has changed recently ... needs to be updated

On Mon, 2021-08-23 at 00:21 +0800, xiao sheng wen wrote:
> Source: debian-reference
> Version: 2.78
> Severity: normal
> X-Debbugs-Cc: atzli...@sina.com
> 
> Hi,
> 
>   On 10.3.4. Using GnuPG with Vim :
> https://www.debian.org/doc/manuals/debian-
> reference/ch10.en.html#_using_gnupg_with_vim
> 
> It say:
> $ vim-addons install gnupg
> 
> But I get the following errors on my  Debian 11 notebook :
> 
> atzlinux@debian:~$ vim-addons install gnupg
> Warning: Ignoring unknown addons: gnupg
> 
> From the last line of the "apt show vim-scripts" , It say that "by adding
> "packadd! "  to the
>  vimrc".
> 
> After I added the "packadd! gnupg" line to my ~/.vimrc, the gnupg plugin of 
> vim
> to take affect.
> 
> Is need to update the content in "10.3.4. Using GnuPG with Vim"?
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500,
> 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'stable'),
> (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
> LANGUAGE=zh_CN:zh
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 

Bug#992717: ITP: r-cran-emdbook -- Support Functions and Data for "Ecological Models and Data"

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-emdbook -- Support Functions and Data for "Ecological 
Models and Data"
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-emdbook
  Version : 1.3.12
  Upstream Author : Copyright: FIXME-2020 Ben Bolker,
* URL : https://cran.r-project.org/package=emdbook
* License : GPL-2
  Programming Lang: GNU R
  Description : Support Functions and Data for "Ecological Models and Data"
 Auxiliary functions and data sets for "Ecological Models and Data", a
 book presenting maximum likelihood estimation and related topics for
 ecologists (ISBN 978-0-691-12522-0).

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

Bug#992670: ibus: drop ibus-gtk and im-config to Suggests

[Osamu Aoki]

Hi,

On Mon, 2021-08-23 at 00:49 +0900, Changwoo Ryu wrote:
> I think the best choice is to keep ibus-gtk in Recommends, as long as there 
> are
> gtk2 apps in Debian.
> 
> Without ibus-gtk installed, XIM will be used as the fallback and its bugs will
> confuse users. There are already several open bugs about this. When ibus-gtk 
> was in
> OR'ed Recommends, many users just did "apt install ibus" and had trouble with 
> XIM
> unnecessarily.
> 
> Fixing the bugs is not an answer; this legacy protocol has its limits and 
> ambiguity
> in the design.The ibus upstream refuses to fix XIM related bugs and I also 
> think
> those bugs are not worth fixing. 

I agree.

Also, even if GTK2 is dropped from Debian completely, there is no real negative
impact for im-config to offer an extra environment variable.  We can be the 
last for
GTK3/4 transition.

Osamu

Bug#992716: 10.3.4. Using GnuPG with Vim, vim-addons install gnupg report errors

[肖盛文]

Source: debian-reference
Version: 2.78
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Hi,

  On 10.3.4. Using GnuPG with Vim :
https://www.debian.org/doc/manuals/debian-
reference/ch10.en.html#_using_gnupg_with_vim

It say:
$ vim-addons install gnupg

But I get the following errors on my  Debian 11 notebook :

atzlinux@debian:~$ vim-addons install gnupg
Warning: Ignoring unknown addons: gnupg

>From the last line of the "apt show vim-scripts" , It say that "by adding
"packadd! "  to the
 vimrc".

After I added the "packadd! gnupg" line to my ~/.vimrc, the gnupg plugin of vim
to take affect.

Is need to update the content in "10.3.4. Using GnuPG with Vim"?


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500,
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'stable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#992715: freecad: Cannot find icon: Surface_Extend

[Lars Luthman]

Package: freecad
Version: 0.19.1+dfsg1-2
Severity: normal
X-Debbugs-Cc: deb-b...@larsluthman.net

When using the 'Extend face' tool in the 'Surface' workbench,
a 'Report view' pops up with the error message (repeated twice)

  Cannot find icon: Surface_Extend

The error messages are printed to stdout as well.

The operation still succeeds, but the created object has a
large 'X' in the tree view instead of an icon. The menu item
and the toolbar item for the 'Extend face' tool has an icon,
presumably this is the one that should be used for the created
object as well.

Steps to reproduce:

  1. Start Freecad.
  2. Create a new document.
  3. In the 'Part' workbench, create a cube.
  4. Select one face of the cube.
  5. In the 'Surface' workbench, select 'Extend face' from
 the 'Surface' menu.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 freecad depends on:
ii  freecad-python3  0.19.1+dfsg1-2

Versions of packages freecad recommends:
ii  calculix-ccx  2.17-3
ii  graphviz  2.42.2-5

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#992714: ITP: r-cran-rcppnumerical -- 'Rcpp' Integration for Numerical Computing Libraries

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rcppnumerical -- 'Rcpp' Integration for Numerical 
Computing Libraries
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rcppnumerical
  Version : 0.4
  Upstream Author : Yixuan Qiu,
* URL : https://cran.r-project.org/package=RcppNumerical
* License : GPL-2+
  Programming Lang: GNU R
  Description : 'Rcpp' Integration for Numerical Computing Libraries
 A collection of open source libraries for numerical computing
 (numerical integration, optimization, etc.) and their integration with
 'Rcpp'.

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

Bug#992660: debian-reference-common: should not recommend debian-reference

[Osamu Aoki]

True.


TBH, LP bug reporter should not have installed only -common package

What do you think is the best way to help people like this.

I am thinking to change -common

 recommend: debian-reference-en|debian-reference

Osamu

On Sun, 2021-08-22 at 00:29 +0200, Vincent Lefevre wrote:
> Package: debian-reference-common
> Version: 2.80
> Severity: important
> 
> debian-reference-common should not recommend debian-reference, which
> is a "metapackage to install (all) translations of Debian Reference".
> 
> With the current situation, if the user wants to install
> debian-reference-fr, he will get debian-reference-common too
> due to the Depends, then debian-reference and all the translations
> due to the Recommends. In general, the user will want just one or
> two language versions, not all of them! If he wants all of them,
> then he should install debian-reference directly.

Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)

[Sergei Golovan]

Hi Thomas,

On Sun, Aug 22, 2021 at 6:55 PM Thomas Goirand  wrote:
>
> Hi Damir, Sergei, the release team,
>
> First of all, thanks for your bug report, Damir.
>
> Debian Bullseye was released on the 14th of Aug. Then Erlang v24 was
> uploaded on the 17th. Looking at:
>
> https://release.debian.org/transitions/
>
> I cannot see any transition thingy opened for Erlang. This means that
> Erlang was carelessly uploaded to Unstable:

Uploading new major version of Erlang does not require a transition.
No application needs to be rebuilt against it, and only a minority
breaks (those which use removed deprecated features, and they have to
be updated or patched anyway). I'm sorry that elixir and rabbit-mq
break.

>
> 1/ Without informing the release team, and defining a schedule for the
> Erlang transition

I insist that a transition is not necessary.

>
> 2/ Without rebuilding any reverse dependency, and more specifically,
> without caring about RabbitMQ which is kind of a high profile server
> application.
>
> Now, we have Erlang v24 in Unstable which looks like a good target for
> RabbitMQ 3.9.4, however, this new version needs a new Elixir release, as
> it has a bound of ">= 1.10.4 and < 1.13.0". Elixir as in unstable (ie:
> 1.10.3) doesn't work, even when trying to convince RabbitMQ it's ok.

Well, I would say that Elixir in Debian is not in a good shape. It
lags way behind upstream (which is already 1.12.2, quite a few
releases ahead).

>
> There isn't much I can do now. I'm opening a bug against Elixir, and
> I'll have to wait for it to be solved...
>
> This isn't the first time something like this happen. Could we please
> bring some sanity in the way we do things? Sergei, could you please
> revert your upload of Erlang v24 in Unstable, and open a release team
> bug to get a transition tracker thingy, which is the only sane way to do
> things in Debian?
>
> Not amused...

I've uploaded Erlang 24 to experimental months ago. If you know that
your software breaks on Erlang upgrade, you could do something
already.

Cheers!
-- 
Sergei Golovan

Bug#992713: ITP: r-cran-rcppnumerical -- 'Rcpp' Integration for Numerical Computing Libraries

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rcppnumerical -- 'Rcpp' Integration for Numerical 
Computing Libraries
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rcppnumerical
  Version : 0.4
  Upstream Author : Yixuan Qiu,
* URL : https://cran.r-project.org/package=RcppNumerical
* License : GPL-2+
  Programming Lang: GNU R
  Description : 'Rcpp' Integration for Numerical Computing Libraries
 A collection of open source libraries for numerical computing
 (numerical integration, optimization, etc.) and their integration with
 'Rcpp'.

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