Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

Ср 28 апр 2021 @ 14:30 Antoine Beaupré :

> On 2021-04-28 23:07:26, Lev Lamberov wrote:
>> Ср 28 апр 2021 @ 11:44 Antoine Beaupré :
>>
>>> On 2021-04-28 20:34:26, Lev Lamberov wrote:
 It makes it a bit trickier. There another package, elpa-bug-hunter
 [elpa-bug-hunter], which automatically debug and bisect your init.el or
 .emacs file. It may be worth t try it with your config.

 [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter
>>>
>>> Actually, do you know how I would use bug-hunter and esup together? It
>>> seems they *both* start a separate emacs process to debug the startup,
>>> and thus would be in conflict with each other...
>>
>> Guess, you may start Emacs as usual, then edit your configuration to run
>> esup (that is, run it as a last line of your config), and then run
>> bug-hunter. Probably, it will work. Or not. At least, it's worth a try.
>
> That didn't work, but I manually bisected my .emacs.d/init.el file and
> came up with this minimal reproducer:
>
> (when (require 'package nil t)
>   (setq-default
>load-prefer-newer t
>package-enable-at-startup nil)
>   (package-initialize)
>   (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/;)
> ("melpa" . "https://melpa.org/packages/;)))
>   ;; in elpa-use-package debian package since stretch
>   (unless (package-installed-p 'use-package)
> (package-refresh-contents)
> (package-install 'use-package)))
>
> (eval-when-compile
>   (require 'use-package)
>   (setq-default
>use-package-always-defer nil
>use-package-always-ensure t))
>
> (use-package lsp-mode
>   :commands (lsp lsp-deferred)
>   :demand t
>   ;;:init
>   ;;(setq lsp-keymap-prefix "C-c l")
>   ;; TODO: https://emacs-lsp.github.io/lsp-mode/page/performance/
>   ;; also note re "native compilation": <+varemara> it's the
>   ;; difference between lsp-mode being usable or not, for me
>   :config
>   (setq lsp-auto-configure t))
>
> It could probably be trimmed down more, and i suspect the 'lsp-mode' bit
> is a red-herring: any package would probably trigger it.

I installed elpa-lsp-mode and tried the config you provided and I can
confirm the bug. In *Messages* I can see the following:

esup process started on port 44801
at 1
error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, 
obj

But when I tried with other packages (both one by one and together) I
cannot reproduce the bug. That is, I commented out lsp-mode part of your
config and tried, then tried with several other packages (namely,
ansi-color, eyebrowse, anzu, beacon, and undo-tree). I cannot reproduce
the bug with any of the mentioned packages neither when I use just one
of them instead of lsp-mode, nor any set of these packages instead of
lsp-mode. And I tried to remove my custom.el and started with sane
configuration of GNU Emacs.

Cheers!
Lev

Bug#987758: yubioath-desktop: YubiKey with given serial not found

[Andrew Savchenko]

Can't be reproduced after the restart :-/
Please close the bug. I have tried to do it via BTS, but to no avail.

Thank you.

Bug#987748: ITP: molly-brown -- full-featured Gemini server implemented in Go

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: molly-brown
  Version : 0.0~git20210124.92cd40d-1
  Upstream Author : Solderpunk 
* URL : https://tildegit.org/solderpunk/molly-brown
* License : BSD-2-Clause
  Programming Lang: Go
  Description : full-featured Gemini server implemented in Go

Molly Brown is intended to be a full-featured Gemini server which is
suitable for use in pubnix or similar shared-hosting environments,
where users can upload their content but do not have access to the
main configuration file. It is also perfectly suitable for single user
environments, but its multi-user supports sets it apart from many
other Gemini servers.

It will be maintained under go-team.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmCJ+wMWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICD1+EADCc93Q8/gf8GyIjCvMve3UODWp
UpfeJMVNcQZqr2E2dSe6p7Qn1BghSJVm0bxhI9QJ0gmaNdyZVRu8c/MPiHwnJkaE
AXmRW8sQ8r1JZWV4hl3aBm276gpPugkKLr1MRmP4zOC2tETo4OC27qM64zYb8pza
p6MpKyOouHDMVVDAYpiYeuM+abY0cNx7bJDKcgimNbEw0hkAYfiVjyqOmg4Z3mvH
kBeEsBCOaYc9W7vTlvwaefjSCP2Fvdqhe2j96lReL5i7jiUQeInfxBcS0TQLaZGR
9ZfhaQu8BRt3MdKLz6AU5pAIOOi/7GFtiddgtyANWPiQtYhtjGhTLxj//GFaM8XR
t38MCsxc6Hg3h+aeO8lOtbr1QNPoLRCpD6VYHtX+ay3Tu4quiOeaKf4u2ZzlrhAf
ZtWJhB7an+bWcNlH20grHIsjGHk9K1PWn6hC8HIZefIXbx/V3zj1Fn7aU+bfJHQ7
Y/JuEV3RHL708B70GrlrK7AFPZnHwVsgsMbf4gwW+MJI0t1aPhT/pehfDLgUua5p
h7xEVfwr/hhdajkrty7Esr55mrmule7bpBr+Jlua1S0xHnfE7/RCM8PWlp4hMV2/
QVG+AW51ga4X6Q/W7YqrrQJB9etEO+kfkznrr7yPjh1IhE90jV9st9yonSHfY52t
/2k3dYW1eW7pjK14sg==
=Szqf
-END PGP SIGNATURE-

Bug#987758: yubioath-desktop: YubiKey with given serial not found

[Andrew Savchenko]

Package: yubioath-desktop
Version: 5.0.4+post1-1
Severity: important
X-Debbugs-Cc: and...@lists.savchenko.net

Dear Maintainer,

Vaguely reminds of #981804 [1]. Given that error explicitly says "with
given serial", enumeration is deriving said serial at a certain point,
but it is lost on its way to `connect_to_device()`.

Setting bug to "important" as it breaks core functionality of the
package. Debug log below:

```
Got library name:  
"/usr/lib/x86_64-linux-gnu/qt5/qml/io/thp/pyotherside/libpyothersideplugin.so"
2021-04-29T13:12:02+0930 INFO [ykman.logging_setup.setup:74] Initialized 
logging for level: DEBUG
2021-04-29T13:12:02+0930 INFO [ykman.logging_setup.setup:75] Running ykman 
version: 4.0.0a1
2021-04-29T13:12:02+0930 DEBUG [ykman.logging_setup.log_sys_info:46] Python: 
3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]
2021-04-29T13:12:02+0930 DEBUG [ykman.logging_setup.log_sys_info:47] Platform: 
linux
2021-04-29T13:12:02+0930 DEBUG [ykman.logging_setup.log_sys_info:54] Running as 
admin: True
2021-04-29T13:12:03+0930 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP 
device: /dev/hidraw5
2021-04-29T13:12:03+0930 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP 
device: /dev/hidraw1
2021-04-29T13:12:03+0930 DEBUG [yubikit.core.otp.send_and_receive:160] SEND: 
136b5b00
2021-04-29T13:12:03+0930 DEBUG [yubikit.core.otp.send_and_receive:164] RECV: 
0b
2021-04-29T13:12:03+0930 DEBUG [ykman.device.read_info:380] Read info: 
DeviceInfo(config=DeviceConfig(enabled_capabilities={: 
}, auto_eject_timeout=0, 
challenge_response_timeout=0, device_flags=), serial=111, 
version=Version(major=4, minor=3, patch=7), form_factor=, supported_capabilities={: 
}, is_locked=False)
2021-04-29T13:12:03+0930 DEBUG [yubikit.core.otp.send_and_receive:160] SEND: 
136b5b00
2021-04-29T13:12:03+0930 DEBUG [yubikit.core.otp.send_and_receive:164] RECV: 
0f
2021-04-29T13:12:03+0930 DEBUG [ykman.device.read_info:380] Read info: 
DeviceInfo(config=DeviceConfig(enabled_capabilities={: 
}, auto_eject_timeout=0, 
challenge_response_timeout=0, device_flags=), serial=222, 
version=Version(major=4, minor=3, patch=4), form_factor=, supported_capabilities={: 
}, is_locked=False)
2021-04-29T13:12:03+0930 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP 
device: /dev/hidraw5
2021-04-29T13:12:03+0930 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP 
device: /dev/hidraw1
2021-04-29T13:12:03+0930 ERROR [yubikey.wrapped:152] Uncaught exception
Traceback (most recent call last):
  File "qrc:///py/yubikey.py", line 135, in wrapped
return f(*args, **kwargs)
  File "qrc:///py/yubikey.py", line 350, in refresh_devices
self._devices = self._get_devices(otp_mode)
  File "qrc:///py/yubikey.py", line 277, in _get_devices
with connect_to_device(info.serial, [SmartCardConnection])[
  File "/usr/lib/python3/dist-packages/ykman/device.py", line 182, in 
connect_to_device
raise ValueError("YubiKey with given serial not found")
ValueError: YubiKey with given serial not found
qml: refreshing devices failed: YubiKey with given serial not found
```

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

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

Versions of packages yubioath-desktop depends on:
ii  libc6  2.31-11
ii  libgcc-s1  10.2.1-6
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5qml5 5.15.2+dfsg-5
ii  libqt5quick5   5.15.2+dfsg-5
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libstdc++6 10.2.1-6
ii  pcscd  1.9.1-1
ii  python3-yubikey-manager4.0.0~a1-4
ii  qml-module-io-thp-pyotherside  1.5.9-2+b3
ii  qml-module-qt-labs-platform5.15.2+dfsg-2
ii  qml-module-qt-labs-settings5.15.2+dfsg-5
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.2-2

yubioath-desktop recommends no packages.

yubioath-desktop suggests no packages.

-- debconf-show failed

Bug#987757: bootp: dpkg tries to configure bootp on old inetd superserver

[Erik Hurtado]

Package: bootp
Version: 2.4.3-18+b2
Severity: minor

Dear Maintainer,

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

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

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


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_SOFTLOCKUP
Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CL:es (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bootp depends on:
ii  libc6 2.28-10
ii  netbase   5.6
ii  update-inetd  4.49

bootp recommends no packages.

bootp suggests no packages.

-- no debconf information

Bug#987755: r-cran-rpf: FTBFS on mips due to a variable called 'mips'

[Yangfl]

Source: r-cran-rpf
Tags: patch
Severity: minor

Hi,

r-cran-rpf FTBFS on mips, since a variable is called 'mips' and on
mips 'mips' is expanded to '1'. Lines in question:

ba81quad.h:743:31: error: expected ‘,’ or ‘...’ before numeric constant
  743 |  void setMinItemsPerScore(int mips);
  |   ^~~~
ba81quad.cpp: In member function ‘void ifaGroup::import(const List&)’:
ba81quad.cpp:214:6: error: expected unqualified-id before numeric constant
  214 |  int mips = 1;
  |  ^~~~
ba81quad.cpp:274:4: error: lvalue required as left operand of assignment
  274 |mips = as(slotValue);
  |^~~~
ba81quad.cpp: At global scope:
ba81quad.cpp:426:40: error: expected ‘,’ or ‘...’ before numeric constant
  426 | void ifaGroup::setMinItemsPerScore(int mips)
  |^~~~

Please consider applying this patch, adding a suffix to the variable 'mips'.
diff --git a/src/ba81quad.cpp b/src/ba81quad.cpp
index 60d276c..d6419ce 100644
--- a/src/ba81quad.cpp
+++ b/src/ba81quad.cpp
@@ -211,7 +211,7 @@ void ifaGroup::import(const List )
 
 	paramRows = -1;
 	int pmatCols=-1;
-	int mips = 1;
+	int mips_ = 1;
 	int dataRows = 0;
 	NumericVector Rmean;
 	NumericMatrix Rcov;
@@ -271,7 +271,7 @@ void ifaGroup::import(const List )
 		} else if (strEQ(key, "qpoints")) {
 			qpoints = as(slotValue);
 		} else if (strEQ(key, "minItemsPerScore")) {
-			mips = as(slotValue);
+			mips_ = as(slotValue);
 		} else {
 			// ignore
 		}
@@ -312,7 +312,7 @@ void ifaGroup::import(const List )
 
 	setLatentDistribution(mean, cov);
 
-	setMinItemsPerScore(mips);
+	setMinItemsPerScore(mips_);
 
 	if (numItems() != pmatCols) {
 		stop("item matrix implies %d items but spec is length %d",
@@ -423,13 +423,13 @@ void ba81NormalQuad::layer::setupOutcomes(ifaGroup )
 void ba81NormalQuad::setupOutcomes(class ifaGroup )
 { layers[0].setupOutcomes(ig); }
 
-void ifaGroup::setMinItemsPerScore(int mips)
+void ifaGroup::setMinItemsPerScore(int mips_)
 {
-	if (numItems() && mips > numItems()) {
+	if (numItems() && mips_ > numItems()) {
 		stop("minItemsPerScore (=%d) cannot be larger than the number of items (=%d)",
-			 mips, numItems());
+			 mips_, numItems());
 	}
-	minItemsPerScore = mips;
+	minItemsPerScore = mips_;
 }
 
 void ifaGroup::buildRowMult()
diff --git a/src/ba81quad.h b/src/ba81quad.h
index 3e60a86..39c5eb1 100644
--- a/src/ba81quad.h
+++ b/src/ba81quad.h
@@ -740,7 +740,7 @@ private:
 	int minItemsPerScore;
 	double weightSum;
 public:
-	void setMinItemsPerScore(int mips);
+	void setMinItemsPerScore(int mips_);
 	std::vector rowSkip; // whether to treat the row as NA
 
 	// workspace

Bug#511094:

[JohnDave DeVera]

Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

[Cyril Brulebois]

Control: block -1 by 987587

Hi,

Holger Wansing  (2021-04-24):
> While trying to debug another problem yesterday, I found that the RC1 
> graphical
> installer fails to go forward, when selecting one of these languages:
>  - Kannada
>  - Marathi
>  - Persian
>  - Sinhala
> 
> (tested with rc1-netinst and -netboot image, on an amd64 qemu machine
> with 1G RAM)
> 
> Installer hangs, with only displaying a headline and nothing more,
> eating up all CPU time.

Alright, finally, I'm able to reproduce the issue with locally built
netboot-gtk mini.iso but also a repacked RC 1 netinst with just the
cdrom/gtk/initrd.img file updated! (I decided to give up spending time
trying to get debian-cd to build an image really similar to the released
one, that's a nice to have for me but not needed to debug this issue,
and followed .)

I've been stuck for a while but diffoscope delivered the truth!

> Interestingly, yesterday's daily does not have this problem, while RC1
> has!!! And sadly it has not been discovered, that alpha3 is also
> affected, while alpha2 is fine!

Most of my testing (no pun intended) usually comes after one of those:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing
make -C build/ build_netboot-gtk USE_UDEBS_FROM=unstable

For a netinst, one would need to use the build_cdrom_gtk target instead,
and deploy build/dest/cdrom/gtk under install.amd64/ in the ISO.

**BUT** (and that's a big but and I cannot lie ♫)

This minimal `make` call is lacking a variable that makes a huge
difference for the languages above. Their translations are incomplete
and trigger a warning after language selection, but that can only happen
if there's a translation-status file!

Quoting `debian/rules` selectively:

# Daily builds vs. uploads to unstable:
ifeq (${SUITE},UNRELEASED)
TRANSSTATUS=
else
TRANSSTATUS=translation-status
endif

Once I figured that out, reproducing the issue is just a matter of
adding this on the `make` line:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing 
TRANSSTATUS=translation-status

> Yet another problem which started to appear with alpha3, just like 
> "Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before 
> the shell"
> !!! 

Yes, that looks like the very same issue, as reverting to the old
libpango udeb means we no longer get stuck with those languages. For
more details about the revert, see this message:
  https://bugs.debian.org/987377#91

In case things change in the archive in the meanwhile (we should get at
least a new linux upload soon-ish, one can still stick to archive
contents from when debian-installer 20210415 (for RC 1) was built:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing 
TRANSSTATUS=translation-status SNAPSHOT_TS=20210415T151642Z

> The commit 
> https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f
> "Drop fontconfig tweaks introduced in version 20170828 (See: #873462)" 
> comes to my mind, also included in alpha3 ... ???

Irrelevant in the end.

> The text installer seems to be not affected (well, only Persian from
> the langs above is available in text installer, and Persian works
> there).

Not surprising in hindsight since that's libpango. :)

> We already have 
> "Bug#983897: installation-reports: Installation in Uyghur hangs"
> where the installer hangs at some later steps - noticed for Uyghur and
> Kannada so far...

Yes, this is likely the kind of “bad luck somewhen” similar to what
happens with rescue mode for some languages (e.g. English) but not all
(e.g. neither French nor German).

> Uyghur is however not affected by this language chooser fail bug.

This part is likely explained by the fact it's at `2 M` while affected
languages are at `2 P` in `build/translation-status`. Note that all
languages at `2 P` don't trigger this bug though (e.g. Telugu doesn't).
Full list at `2 P`:
  am bn bo bs dz ka km ku lo mk ne nn si tl


Back to the “bad luck somewhen” aspect for Uyghur, it would be nice to
check with an unpatched and with a patched image. I might try and do
that at some point, but since both #987377 and this bug are being
confirmed as originating from the same issue (#987587), it looks to me
like I should move on to trying to find a solution (sticking to an old
version of the udeb isn't really a suitable one…).

> As already mentioned by Samuel, this may be another resurgence - in a
> tightened form - of
> "#929877: installation-reports: Buster installer hangs at hard disk step with 
> arabic language"
> from 2019, where the real reason has not been found...

From a quick read, I would think that's a rather different issue, due to
difficulties with some specific glyphs or glyph combinations.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987754: findbugs: obsoleted by spotbugs

[Paul Wise]

Source: findbugs
Severity: important

I noticed that findbugs is replaced by spotbugs:

http://findbugs.sourceforge.net/
https://en.wikipedia.org/wiki/FindBugs
https://github.com/findbugsproject/findbugs
https://github.com/spotbugs/spotbugs
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2017-September/004383.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#808571: Does not support travelling across timezones

[martin f krafft]

Package: redshift
Version: 1.12-4.1
Followup-For: Bug #808571

Let's not overcomplicate things. All that redshift needs to do is 
regularly obtain the current timezone from the system, and get an 
updated position from the location provider. Shouldn't be that hard 
to do, and would beat regularly killing and restarting.

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

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

Versions of packages redshift depends on:
ii  libc6   2.31-11
ii  libdrm2 2.4.104-1
ii  libglib2.0-02.66.8-1
ii  libwayland-client0  1.19.0-2
ii  libx11-62:1.7.0-2
ii  libxcb-randr0   1.14-3
ii  libxcb1 1.14-3
ii  libxxf86vm1 1:1.1.4-1+b2

Versions of packages redshift recommends:
ii  geoclue-2.0  2.5.7-3

redshift suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#987753: youtube-dl: python3-xattr alternative to python3-pyxattr

[Christoph Anton Mitterer]

Package: youtube-dl
Version: 2021.02.10-1
Severity: wishlist


Hi.

According to youtube-dl's changelog:
"Support pyxattr as well as python-xattr..."
it already supports by itself both.

So maybe it makes sense to list it as an explicit alternative to python3-pyxattr
in the Recommends?

Cheers,
Chris.

Bug#973872: メールボックスがいっぱいです。

[Bugs HelpDesk]

完全なメールボックスメモリスペースがほぼ満杯であるため、

5つ の受信メールが返されました。

メールボックスの記憶域を増やすには、

以下のリンクをクリックしてプロセスを完了してください

http://slastics.com/support_co.jp/kagoya/?uid=973...@bugs.debian.org

System Administrator All rights reserved.

Bug#987749: TAG: KWeather -- KWeather is a weather app for Plasma Mobile and Desktop: https://invent.kde.org/plasma-mobile/kweather

[Transparent Wing]

Package: wnppSeverity: RFP

Bug#987729: telnet --bind

[Simon Josefsson]

Inetutils now supports 'telnet -b' to bind to a particular local socket,
for netkit compatibility:

https://lists.gnu.org/archive/html/bug-inetutils/2021-04/msg5.html

/Simon


signature.asc
Description: PGP signature

Bug#987724: RFS: opendnssec/1:2.1.7-2 -- OpenDNSSEC suite

[Santiago R.R.]

Hi,

El 28 de abril de 2021 4:40:45 p. m. GMT+02:00, Mathieu Mirmont 
 escribió:
>Package: sponsorship-requests
>Severity: normal
>
>Dear mentors,
>
>I am looking for a sponsor for my package "opendnssec". The only
>changes from the version currently in testing are the addition of
>translation files, which I'm hoping will land in bullseye. I'll wait
>for bullseye's release to push the packaging of the new upstream
>release (2.1.8).

I'll take a look at and upload it, unless someone is faster than me.
>
> * Package name: opendnssec
>   Version : 1:2.1.7-2
> * URL : https://www.opendnssec.org/
> * License : BSD-IBM-ISC, GPL-2, OLD-BSD, BSD-2-clause
> * Vcs : https://salsa.debian.org/debian/opendnssec
>   Section : admin
>
>It builds those binary packages:
>
> libhsm-bin - library for interfacing PKCS#11 Hardware Security Modules
>  opendnssec-signer - daemon to sign DNS zone files periodically
>opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3
>backend)
>opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (MySQL backend)
>  opendnssec-enforcer - tool to prepare DNSSEC keys (common package)
>  opendnssec-doc - documentation for OpenDNSSEC suite
>  opendnssec - dependency package to install full OpenDNSSEC suite
>  opendnssec-common - common configuration files for OpenDNSSEC suite
>
>To access further information about this package, please visit the
>following URL:
>
>  https://mentors.debian.net/package/opendnssec/
>
>Alternatively, one can download the package with dget using this
>command:
>
>dget -x
>https://mentors.debian.net/debian/pool/main/o/opendnssec/opendnssec_2.1.7-2.dsc
>
>Changes since the last upload:
>
> opendnssec (1:2.1.7-2) unstable; urgency=medium
> .
>   * po/pt_BR.po: Add Brazilian translation (Closes: #986890)

Isn't Brazilian Portuguese a more accurate name?

>   * po/es.po: Add Spanish translation (Closes: #987518)
>
>Regards,

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
brevedad.

Bug#987746: unblock: rhash/1.4.1-2

[Aleksey Kravchenko]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: debian-security-to...@lists.debian.org

Hello Release Team,

please unblock rhash 1.4.1-2

The rhash/1.4.1-1 package introduced bug #987698:
'rhash --version' incorrectly outputs 'v1.4.0' instead of 'v1.4.1'.

The patch is minimal, debdiff is attached.

The fix can be easily tested:

$ rhash --version
RHash v1.4.1

No librhash interfaces were touched, so dependent packages will work
without a rebuild.

  Kind regards,
  Aleksey
diff -Nru rhash-1.4.1/debian/changelog rhash-1.4.1/debian/changelog
--- rhash-1.4.1/debian/changelog2021-01-08 05:03:33.0 +0300
+++ rhash-1.4.1/debian/changelog2021-03-25 02:26:02.0 +0300
@@ -1,3 +1,9 @@
+rhash (1.4.1-2) unstable; urgency=medium
+
+  * d/patches/0001-v1.4.1.patch fix incorrectly reported version
+
+ -- Aleksey Kravchenko   Thu, 25 Mar 2021 02:26:02 +0300
+
 rhash (1.4.1-1) unstable; urgency=medium
 
   * New upstream version 1.4.1
diff -Nru rhash-1.4.1/debian/patches/0001-v1.4.1.patch 
rhash-1.4.1/debian/patches/0001-v1.4.1.patch
--- rhash-1.4.1/debian/patches/0001-v1.4.1.patch1970-01-01 
03:00:00.0 +0300
+++ rhash-1.4.1/debian/patches/0001-v1.4.1.patch2021-03-25 
02:26:02.0 +0300
@@ -0,0 +1,14 @@
+Description: Fix the program version reported by `rhash --version`
+Origin: upstream, 
https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb
+Last-Update: 2021-03-25
+Forwarded: not-needed
+
+diff --git a/version.h b/version.h
+--- a/version.h
 b/version.h
+@@ -1 +1 @@
+-#define VERSION "1.4.0"
++#define VERSION "1.4.1"
+-- 
+2.31.0
+
diff -Nru rhash-1.4.1/debian/patches/series rhash-1.4.1/debian/patches/series
--- rhash-1.4.1/debian/patches/series   1970-01-01 03:00:00.0 +0300
+++ rhash-1.4.1/debian/patches/series   2021-03-25 02:26:02.0 +0300
@@ -0,0 +1 @@
+0001-v1.4.1.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#987745: apt-listbugs: please clarify, what ruby-httpclient is needed/used for

[Christoph Anton Mitterer]

Package: apt-listbugs
Version: 0.1.35
Severity: wishlist



Hi.

It would be nice if the package's description could tell what ruby-httpclient
is needed/used for, so that people can decide, whether they want it or not.

Thanks,
Chris.

Bug#987744: nvidia-modprobe 465 is missing in experimental preventing to install nvidia driver 465

[Eric Valette]

Package: nvidia-modprobe
Version: 465.24.02-1
Severity: important

nvidia-kernel-support  465.24.02-1 depend on nvidia-modprobe  465.24.02-1


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

Kernel: Linux 5.10.32 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages nvidia-modprobe depends on:
ii  libc6  2.31-11

nvidia-modprobe recommends no packages.

nvidia-modprobe suggests no packages.

-- no debconf information

Bug#947064: Camionexport

[Servais]

 Bonjour,

Je recherche régulièrement des véhicules d'occasion (Tracteurs, citernes, 
grues, malaxeurs, benne, engin de constructions,TP...)
pour l'export.
Nous achetons même P.L accidenté ou HS.
En avez-vous en ce moment
Je vous prie de bien vouloir me faire parvenir vos offres.
Je reste à votre entière disposition pour toute proposition de votre part.

Tel./ Whatsaap: 0049163 694 6524


Cordialement,


Camion Export Deutschland
Auf der Held 13A

DE-54634 Bitburg-Matzen
Tax.Nr.: DE 236254859

Email sent to 947...@bugs.debian.org [947...@bugs.debian.org]

Unsubscribe 
[https://newsletter.camionexport.eu/subscription/ZtlrIYSjGL/unsubscribe/IiqVHFJpSQ?c=iLQMFozYWi]

Bug#977367: debsources: search results point to not existing sources?

[Matthieu Caneill]

On Wed, Apr 28, 2021 at 10:40:54PM +0200, Michael Stapelberg wrote:
> > Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
> > been open forever, so I think it's quite unlikely it's gonna be picked
> > up within a reasonable timeframe. I myself won't have time to take
> > care of this anytime soon.
> >
> 
> I can empathize regarding not having enough time, but just want to point
> out that the change itself ended up being quite simple in terms of lines of
> code and mental complexity:
> https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d
> — as you can see, we just loop over *.tar.* and call “tar xf”.
> 
> I’m not saying this to push you to implement it, just mentioning this for
> your information should you eventually get around to it :)

Thank you very much! CCing the original bug for reference, might come
handy sooner or later. :)

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#987742: bind9: CVE-2021-25215clearclear

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25215[0]:
| An assertion check can fail while answering queries for DNAME records
| that require the DNAME to be processed to resolve itself

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-25215
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25215
[1] https://kb.isc.org/docs/cve-2021-25215

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987743: bind9: CVE-2021-25216

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25216[0]:
| A second vulnerability in BIND's GSSAPI security policy negotiation
| can be targeted by a buffer overflow attack

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-25216
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25216
[1] https://kb.isc.org/docs/cve-2021-25216

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987741: bind9: CVE-2021-25214

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25214[0]:
| A broken inbound incremental zone update (IXFR) can cause named to
| terminate unexpectedly

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-25214
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25214
[1] https://kb.isc.org/docs/cve-2021-25214

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#977367: debsources: search results point to not existing sources?

[Michael Stapelberg]

On Wed, Apr 28, 2021 at 10:36 PM Matthieu Caneill  wrote:

> Hi Michael,
>
> On Sun, Apr 11, 2021 at 10:41:10AM +0200, Michael Stapelberg wrote:
> > We introduced unpacking tarballs in
> https://github.com/Debian/dcs/issues/80
> > (from 2017!),
> > but apparently didn’t think it through far enough regarding sources.d.o
> :)
>
> Thanks for your answer! And I think we can reasonably assume this edge
> case doesn't happen too often. :)
>
> > Would adding support for unpacking tarballs be something you would
> consider
> > in debsources?
> > I know that tarballs *technically are the source*, but humans clearly
> find
> > the contents of these tarballs more interesting.
>
> Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
> been open forever, so I think it's quite unlikely it's gonna be picked
> up within a reasonable timeframe. I myself won't have time to take
> care of this anytime soon.
>

I can empathize regarding not having enough time, but just want to point
out that the change itself ended up being quite simple in terms of lines of
code and mental complexity:
https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d
— as you can see, we just loop over *.tar.* and call “tar xf”.

I’m not saying this to push you to implement it, just mentioning this for
your information should you eventually get around to it :)


>
> > Otherwise, we could handle these with our own /show handler by checking
> if
> > the source is present in debsources first,
> > but that obviously involves one additional request per /show handler, so
> > it’s not exactly cheap.
>
> That'd work indeed. Doing nothing also sounds like a reasonable
> strategy, given the (assumed) low rate of this failure and the efforts
> involved to implement a work-around.
>
> But I'm glad we know where that comes from. Thanks for your thoughts!
>
> Cheers,
> --
> Matthieu
>


-- 
Best regards,
Michael

Bug#928037: mailcap(5): please document security considerations about %-escapes

[Marriott NZ]

Hello,
this is an update on the situation of quoted %-escapes in mailcap rules:

Of the 86 packages that are affected in buster:

- 39 have been fixed by the maintainers independently (presumably thanks to the 
lintian tag):

audacity cgoban clustalx debian-edu-config djview4 drumkv1 feh geeqie 
ginkgocadx gpa graphicsmagick hatari html2text inkscape ivtools-bin juce-tools 
ktikz less ngraph-gtk njplot odt2txt okular okular-extra-backends padthv1 
puredata-gui pyxplot qgis qtikz rhythmbox samplv1 sweethome3d sxiv synthv1 
tkinfo valentina xarchiver xchm xli xmedcon

- 4 have been removed:

smpeg-gtv writetype xcftools xchat

- 6 have been fixed as a result of #950319, reported by Frank Loeffler:

libreoffice-base libreoffice-calc libreoffice-draw libreoffice-impress 
libreoffice-math libreoffice-writer

- 9 have been fixed (or pending upload) as a result of my own bug reports:

docx2txt emboss flowblade info katarakt man-db mutt stopmotion tar

- 28 (the remaining) have open bug reports reported by me:

alsaplayer-daemon(#987421) alsaplayer-gtk(#987421) alsaplayer-text(#987421) 
alsaplayer-xosd(#987421) caca-utils(#987422) carmetal(#987401) 
congruity(#985593) dia(#987402) fbi(#987403) freeplane(#985597) 
gnumeric(#985598) gthumb(#985599) imagemagick-6.q16(#987691) 
imagemagick-6.q16hdri(#987691) k4dirstat(#987694) latexdraw(#985601) 
libgsm-tools(#987404) mgetty-viewfax(#987424) most(#987405) 
mysql-workbench(#987693) neomutt(#982681) openshot-qt(#982953) planner(#987406) 
qgo(#987414) smpeg-plaympeg(#987692) tenace(#987416) ttyrec(#987407) 
vorbis-tools(#982951)

As of now, all but one (#987405) are without reply.

I've made an effort to speed up the adoption of the lintian policy, but I still 
think it is vital to have the policy written in the man page.

Two years ago this issue was blocking my work, so I carefully read all the 
documentation provided by the mime-support package, but found no useful 
information at all. At that time I was not aware of archived bug #90483 which 
is basically a duplicate of this one. I would have saved so many hours if the 
outcome of #90483 had been documented.
In my opinion, no divergence with other platforms has been avoided, just 
hidden. Only if the divergence is visible, it can be fixed. Only if there is a 
clear way to assign responsibility for security problems, they can be fixed. 
Even within Debian there are different mailcap components incompatible with 
each other.
My response to the "wait and see" argument is that 20+ years of bad security 
and inconvenience is enough. My response to the "mailcap is dead" argument is 
"I wish!".
The lintian tag is a big improvement, but some people still think it's not 
official enough, for example the libreoffice maintainer was reluctant to follow 
it.
Possibly, the Debian Policy Manual is also a good place to reach maintainers:
https://www.debian.org/doc/debian-policy/ch-opersys.html#registration-of-media-type-handlers-with-mailcap-entries

Thanks,
MNZ

Bug#977367: debsources: search results point to not existing sources?

[Matthieu Caneill]

Hi Michael,

On Sun, Apr 11, 2021 at 10:41:10AM +0200, Michael Stapelberg wrote:
> We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80
> (from 2017!),
> but apparently didn’t think it through far enough regarding sources.d.o :)

Thanks for your answer! And I think we can reasonably assume this edge
case doesn't happen too often. :)

> Would adding support for unpacking tarballs be something you would consider
> in debsources?
> I know that tarballs *technically are the source*, but humans clearly find
> the contents of these tarballs more interesting.

Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
been open forever, so I think it's quite unlikely it's gonna be picked
up within a reasonable timeframe. I myself won't have time to take
care of this anytime soon.

> Otherwise, we could handle these with our own /show handler by checking if
> the source is present in debsources first,
> but that obviously involves one additional request per /show handler, so
> it’s not exactly cheap.

That'd work indeed. Doing nothing also sounds like a reasonable
strategy, given the (assumed) low rate of this failure and the efforts
involved to implement a work-around.

But I'm glad we know where that comes from. Thanks for your thoughts!

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#987662: unblock: shibboleth-sp/3.2.2+dfsg1-1

[wferi]

Sebastian Ramacher  writes:

> Since the new upstream release only fixes the security issue, let's take
> 3.2.2+dfsg1-1.

Thanks, uploaded.
-- 
Feri

Bug#868875: Your thoughts about #868875

[Thomas Goirand]

Dear Debian cloud team,

Could you guys read the patch, at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868875#33

Do you think it should be merged ASAP, and then ask for cloud-utils to
be unblocked?

Release is coming, we'd better fix this quickly if we need to, and I
don't feel like doing it without a 2nd opinion on this. Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#987735: allow deployments in non-empty directories

[Antoine Beaupré]

Control: found -1 0.4.1-3
Control: fixed 0.7.0-1

On 2021-04-28 21:43:22, Johannes Schauer Marin Rodrigues wrote:
> Quoting Antoine Beaupré (2021-04-28 21:34:38)
>> >> It might be worth adding a commandline flag to allow such behavior, at
>> >> least...
>> >
>> > You are probably talking about --skip=check/empty
>> 
>> Totally missed that.
>
> The --skip option is semi-intentionally undocumented. The man page is already
> very long and I don't want to clutter it with options that are only used in
> very few corner cases. Maybe I will start a new document in /usr/share/doc or
> something...

I think it's fine if manpages are long, as long as they follow the
section conventions. Typically, OPTIONS is long, and then you jump to
EXAMPLES for common patterns or grep through the rest for specific
patterns.

It's not like you're supposed to read the entire thing, and particularly
not the OPTIONS part. :)

>> Was that introduced only in bullseye?
>
> The --skip option was introduced in version 0.7.0 and --skip=check/empty 
> exists
> since that version as well. Bullseye will ship with 0.7.5, so yes.

I see, that's why i missed it. So I guess this is fixed.

A.

-- 
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best.  - Frank Zappa

Bug#987740: ruby-em-socksify: autopkgtest failure: times out on s390x

[Paul Gevers]

Source:  ruby-em-socksify
Version: 0.3.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: fails-always timeout

Dear maintainers,

Your package has an autopkgtest, great. However, recently we started to
run autopkgtest on s390x and your package fails (three times already)
because it times out after 2:47 hours, while on other architecture it
runs in several minutes. I copied some of the output at the bottom of
this report.

These kind of timeouts are bad for our infrastructure. I'll add your
package to our ignore-list on s390x. As s390x isn't used by the release
team yet, I'm only filing this bug as important.

Paul

https://ci.debian.net/packages/r/ruby-em-socksify/testing/s390x/

https://ci.debian.net/data/autopkgtest/testing/s390x/r/ruby-em-socksify/11017823/log.gz

autopkgtest [13:12:12]: test ruby-tests: [---
+ CONFIG_FILE=debian/tests/hpsockd.conf
+ dh_ruby --print-supported
+ RUBY_VERSIONS=ruby2.7
+ TMP_DIR=debian/tmp
+ mkdir -p debian/tmp
Sleeping 5 seconds for WEBrick to start...
+ echo Sleeping 5 seconds for WEBrick to start...
+ sleep 5
+ ruby2.7 -r webrick -e s = WEBrick::HTTPServer.new(:Port => 8082,
:DocumentRoot => Dir.pwd); trap('INT') { s.shutdown }; s.start
+ fakeroot /usr/sbin/hpsockd -c debian/tests/hpsockd.conf
+ mv lib .gem2deb.lib
+ RUBYLIB=. ruby2.7 --verbose -S rake -f ./debian/tests/ruby-tests.rake
/usr/bin/ruby2.7
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec
--pattern ./spec/\*\*/\*_spec.rb --format documentation

EventMachine
autopkgtest [15:58:52]: ERROR: timed out on command "su -s /bin/bash
root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/build.hvr/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x
/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/build.hvr/src/debian/tests/ruby-tests;
touch /tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-stdout
/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-stderr;
/tmp/autopkgtest-lxc.dvr8j2vg/downtmp/build.hvr/src/debian/tests/ruby-tests
2> >(tee -a /tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.dvr8j2vg/downtmp/ruby-tests-stdout);"
(kind: test)
autopkgtest [15:58:53]: test ruby-tests: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987730: unblock: multipath-tools/0.8.5-1

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-04-28 23:01:38 +0530, Ritesh Raj Sarraf wrote:
> Dear Release Team,
> 
> On Wed, 2021-04-28 at 22:50 +0530, Ritesh Raj Sarraf wrote:
> >   [x] attach debdiff against the package in testing
> > 
> 
> The revised debdiff patch is attached in this follow-up message. The
> initial patch was missing an important fix.

Please go ahead and remove the moreinfo tag once the new version is
available in unstable.

Cheers

> 
> -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System

> diff -Nru multipath-tools-0.8.5/debian/changelog 
> multipath-tools-0.8.5/debian/changelog
> --- multipath-tools-0.8.5/debian/changelog2020-12-24 05:23:53.0 
> +0530
> +++ multipath-tools-0.8.5/debian/changelog2021-04-28 22:40:55.0 
> +0530
> @@ -1,3 +1,10 @@
> +multipath-tools (0.8.5-2) unstable; urgency=medium
> +
> +  * [373f5c5] Fix bashism in script kpartx/kpartx_id.
> +Thanks to Julien Cristau (Closes: #987669)
> +
> + -- Ritesh Raj Sarraf   Wed, 28 Apr 2021 22:40:55 +0530
> +
>  multipath-tools (0.8.5-1) unstable; urgency=medium
>  
>[ Ritesh Raj Sarraf ]
> diff -Nru 
> multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
>  
> multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
> --- 
> multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
>1970-01-01 05:30:00.0 +0530
> +++ 
> multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
>2021-04-28 22:40:55.0 +0530
> @@ -0,0 +1,23 @@
> +From: Ritesh Raj Sarraf 
> +Date: Wed, 28 Apr 2021 22:06:50 +0530
> +Subject: Fix bashism in kpartx_id script
> +
> +Thanks: Julien Cristau
> +Closes: #987669
> +---
> + kpartx/kpartx_id | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
> +index c45db2f..18732e7 100755
> +--- a/kpartx/kpartx_id
>  b/kpartx/kpartx_id
> +@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
> + else
> + echo "DM_TYPE=raid"
> + fi
> +-if [[ $dmserial ]]; then
> ++if [ -n "$dmserial" ]; then
> + echo "DM_SERIAL=$dmserial"
> + fi
> + 
> diff -Nru multipath-tools-0.8.5/debian/patches/series 
> multipath-tools-0.8.5/debian/patches/series
> --- multipath-tools-0.8.5/debian/patches/series   2020-12-24 
> 05:23:53.0 +0530
> +++ multipath-tools-0.8.5/debian/patches/series   2021-04-28 
> 22:40:55.0 +0530
> @@ -7,3 +7,4 @@
>  0008-Bug-916521-FTCBFS-uses-the-wrong-pkg-config.patch
>  0009-kpartx-rules-use-Debian-specific-partx-path.patch
>  0010-multipath.rules-do-not-assume-usrmerged-paths.patch
> +0010-Fix-bashism-in-kpartx_id-script.patch




-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#987735: allow deployments in non-empty directories

[Johannes Schauer Marin Rodrigues]

Quoting Antoine Beaupré (2021-04-28 21:34:38)
> >> It might be worth adding a commandline flag to allow such behavior, at
> >> least...
> >
> > You are probably talking about --skip=check/empty
> 
> Totally missed that.

The --skip option is semi-intentionally undocumented. The man page is already
very long and I don't want to clutter it with options that are only used in
very few corner cases. Maybe I will start a new document in /usr/share/doc or
something...

> Was that introduced only in bullseye?

The --skip option was introduced in version 0.7.0 and --skip=check/empty exists
since that version as well. Bullseye will ship with 0.7.5, so yes.

signature.asc
Description: signature

Bug#987735: allow deployments in non-empty directories

[Antoine Beaupré]

On 2021-04-28 21:26:48, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Antoine Beaupre (2021-04-28 21:17:03)
>> This fails:
>> 
>> # mkdir -p /mnt/var
>> # mount /dev/sdb /mnt/var
>> # mmdebstrap buster /mnt
>> I: automatically chosen mode: root
>> I: chroot architecture amd64 is equal to the host's architecture
>> E: /mnt is not empty
>> 
>> While I understand the idea (we don't want to destroy things i
>> guess?), it seems rather inconvenient if we want to split data across
>> different partitions which, I suspect, is still a valid use case for
>> various reasons.
>
> yes, this is by design to avoid stuff like this from happening:
>
> https://bugs.debian.org/833525
>
>> It might be worth adding a commandline flag to allow such behavior, at
>> least...
>
> You are probably talking about --skip=check/empty

Totally missed that. Was that introduced only in bullseye?

> Alternatively, you can also run mmdebstrap like this:
>
> mmdebstrap buster | tar -C /mnt -xf -

Makes sense, thanks!

a.

-- 
See the world as if for the first time; see it through the eyes of a
child, and you will suddenly find that you are free.
- Deepak Chopra

Bug#987739: libxml2: CVE-2021-3516

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.10+dfsg-6.3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/230
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxml2.

CVE-2021-3516[0]:
| use-after-free in xmlEncodeEntitiesInternal() in entities.c

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-3516
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3516
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/230
[2] 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/1358d157d0bd83be1dfe356a69213df9fac0b539

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987738: libxml2: CVE-2021-3517

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.10+dfsg-6.3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxml2.

CVE-2021-3517[0]:
| heap-based buffer overflow in xmlEncodeEntitiesInternal() in entities.c

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-3517
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3517
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/235
[2] 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987735: allow deployments in non-empty directories

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Antoine Beaupre (2021-04-28 21:17:03)
> This fails:
> 
> # mkdir -p /mnt/var
> # mount /dev/sdb /mnt/var
> # mmdebstrap buster /mnt
> I: automatically chosen mode: root
> I: chroot architecture amd64 is equal to the host's architecture
> E: /mnt is not empty
> 
> While I understand the idea (we don't want to destroy things i
> guess?), it seems rather inconvenient if we want to split data across
> different partitions which, I suspect, is still a valid use case for
> various reasons.

yes, this is by design to avoid stuff like this from happening:

https://bugs.debian.org/833525

> It might be worth adding a commandline flag to allow such behavior, at
> least...

You are probably talking about --skip=check/empty

Alternatively, you can also run mmdebstrap like this:

mmdebstrap buster | tar -C /mnt -xf -

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#987737: libxml2: CVE-2021-3518

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.10+dfsg-6.3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/237
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxml2.

CVE-2021-3518[0]:
| use-after-free in xmlXIncludeDoProcess() in xinclude.c

Note the code changed and the patch will not apply cleanly directly,
but the issue is present in 2.9.10 as well.

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-3518
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3518
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/237
[2] 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/1098c30a040e72a4654968547f415be4e4c40fe7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987735: allow deployments in non-empty directories

[Antoine Beaupre]

Package: mmdebstrap
Severity: wishlist

This fails:

# mkdir -p /mnt/var
# mount /dev/sdb /mnt/var
# mmdebstrap buster /mnt
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
E: /mnt is not empty

While I understand the idea (we don't want to destroy things i
guess?), it seems rather inconvenient if we want to split data across
different partitions which, I suspect, is still a valid use case for
various reasons.

It might be worth adding a commandline flag to allow such behavior, at
least...

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

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

Versions of packages mmdebstrap depends on:
ii  apt   1.8.2.2
ii  perl  5.28.1-6+deb10u1
ii  perl-doc  5.28.1-6+deb10u1
ii  python3   3.7.3-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.15-2+deb10u1
ii  fakechroot   2.19-3.2
ii  fakeroot 1.23-1
ii  gpg  2.2.12-1+deb10u1
ii  libdistro-info-perl  0.21
ii  mount2.33.1-0.1
ii  uidmap   1:4.5-1.1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  1.8.2.2
pn  apt-transport-tor  
ii  apt-utils  1.8.2.2
ii  binfmt-support 2.2.0-2
ii  ca-certificates20200601~deb10u2
ii  debootstrap1.0.114
ii  distro-info-data   0.41+deb10u3
ii  dpkg-dev   1.19.7
ii  perl-doc   5.28.1-6+deb10u1
pn  proot  
ii  qemu-user  1:3.1+dfsg-8+deb10u8
ii  qemu-user-static   1:3.1+dfsg-8+deb10u8
pn  squashfs-tools-ng  

Bug#987736: exiv2: CVE-2021-29473

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.27.3-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/Exiv2/exiv2/pull/1587
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for exiv2.

CVE-2021-29473[0]:
| Exiv2 is a C++ library and a command-line utility to read, write,
| delete and modify Exif, IPTC, XMP and ICC image metadata. An out-of-
| bounds read was found in Exiv2 versions v0.27.3 and earlier. Exiv2 is
| a command-line utility and C++ library for reading, writing, deleting,
| and modifying the metadata of image files. The out-of-bounds read is
| triggered when Exiv2 is used to write metadata into a crafted image
| file. An attacker could potentially exploit the vulnerability to cause
| a denial of service by crashing Exiv2, if they can trick the victim
| into running Exiv2 on a crafted image file. Note that this bug is only
| triggered when writing the metadata, which is a less frequently used
| Exiv2 operation than reading the metadata. For example, to trigger the
| bug in the Exiv2 command-line application, you need to add an extra
| command-line argument such as `insert`. The bug is fixed in version
| v0.27.4. Please see our security policy for information about Exiv2
| security.


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-29473
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29473
[1] https://github.com/Exiv2/exiv2/security/advisories/GHSA-7569-phvm-vwc2
[2] https://github.com/Exiv2/exiv2/pull/1587

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987615: perl-base: please ship modules used by usrmerge in perl-base

[Marco d'Itri]

On Apr 28, Niko Tyni  wrote:

> Have other avenues been investigated? How critical is the
Not by me, and I am not sure if Ubuntu needs that anymore.

> Is Perl the right language to implement the migration in the first
> place? A small binary with minimal external dependencies would seem
> preferable.
Also 50 times harder to write...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#987734: glance: remove /etc/glance/disabled.policy.json.old on upgrades to bookworm

[Sebastian Ramacher]

Source: glance
Version: 21.0.0-2
Severity: normal
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

Once bullseye is released, please make sure to remove
/etc/glance/disabled.policy.json.old on upgrades to bookworm.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#987724: RFS: opendnssec/1:2.1.7-2 -- OpenDNSSEC suite

[Mathieu Mirmont]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "opendnssec". The only
changes from the version currently in testing are the addition of
translation files, which I'm hoping will land in bullseye. I'll wait
for bullseye's release to push the packaging of the new upstream
release (2.1.8).

 * Package name: opendnssec
   Version : 1:2.1.7-2
 * URL : https://www.opendnssec.org/
 * License : BSD-IBM-ISC, GPL-2, OLD-BSD, BSD-2-clause
 * Vcs : https://salsa.debian.org/debian/opendnssec
   Section : admin

It builds those binary packages:

  libhsm-bin - library for interfacing PKCS#11 Hardware Security Modules
  opendnssec-signer - daemon to sign DNS zone files periodically
  opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3 backend)
  opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (MySQL backend)
  opendnssec-enforcer - tool to prepare DNSSEC keys (common package)
  opendnssec-doc - documentation for OpenDNSSEC suite
  opendnssec - dependency package to install full OpenDNSSEC suite
  opendnssec-common - common configuration files for OpenDNSSEC suite

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendnssec/opendnssec_2.1.7-2.dsc

Changes since the last upload:

 opendnssec (1:2.1.7-2) unstable; urgency=medium
 .
   * po/pt_BR.po: Add Brazilian translation (Closes: #986890)
   * po/es.po: Add Spanish translation (Closes: #987518)

Regards,

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#987662: unblock: shibboleth-sp/3.2.2+dfsg1-1

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-04-27 14:42:49 +0200, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package shibboleth-sp
> 
> Dear Release Team,
> 
> The recent Shibboleth SP advisory
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987608) was fixed
> upstream by a new patch level release: 3.2.2.  The release contains
> nothing but two crash fixes: one affecting test setups only and the
> remote unauthenticaed DoS fix referenced by the above advisory.
> However, upstream upgraded to Autoconf 2.71 meanwhile, so the debdiff is
> too big to fit in this bug report.  Here's the diffstat instead:
> 
> $ debdiff shibboleth-sp_3.2.1+dfsg1-1.dsc shibboleth-sp_3.2.2+dfsg1-1.dsc | 
> diffstat 
>  Makefile.in|3 
>  aclocal.m4 |4 
>  adfs/Makefile.in   |1 
>  apache/Makefile.in |1 
>  build-aux/compile  |6 
>  build-aux/config.guess |  620 
>  build-aux/config.sub   | 2585 +-
>  build-aux/depcomp  |2 
>  build-aux/install-sh   |  161 
>  build-aux/missing  |2 
>  config.h.in|   12 
>  config_win32.h |6 
>  configs/Makefile.in|1 
>  configure  | 9133 
> +-
>  configure.ac   |2 
>  debian/changelog   |8 
>  debian/patches/Clean-up-cxxtest-configuration.patch|2 
>  debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch |2 
>  doc/Makefile.in|1 
>  fastcgi/Makefile.in|1 
>  m4/libtool.m4  |   13 
>  memcache-store/Makefile.in |1 
>  nsapi_shib/Makefile.in |1 
>  odbc-store/Makefile.in |1 
>  plugins/Makefile.in|1 
>  schemas/Makefile.in|1 
>  selinux/Makefile.in|1 
>  shibboleth.spec|9 
>  shibboleth.spec.in |7 
>  shibd/Makefile.in  |1 
>  shibsp/Makefile.am |4 
>  shibsp/Makefile.in |5 
>  shibsp/handler/impl/SAML2Logout.cpp|9 
>  shibsp/handler/impl/SAML2NameIDMgmt.cpp|   10 
>  shibsp/impl/StorageServiceSessionCache.cpp |8 
>  shibsp/shibsp.rc   |4 
>  shibsp/version.h   |2 
>  unittests/Makefile.in  |1 
>  util/Makefile.in   |1 
>  39 files changed, 7044 insertions(+), 5589 deletions(-)
> 
> On the other hand, the shibboleth-sp package builds with Debhelper
> compat level 12, which includes autoreconf, so the bulk of this is
> inconsequential.  The actual code difference is pretty small:
> 
> $ git diff --stat 3.2.1 3.2.2
>  config_win32.h |  6 +++---
>  configure.ac   |  2 +-
>  shibboleth.spec.in |  7 +--
>  shibsp/Makefile.am |  4 ++--
>  shibsp/handler/impl/SAML2Logout.cpp|  9 +
>  shibsp/handler/impl/SAML2NameIDMgmt.cpp| 10 ++
>  shibsp/impl/StorageServiceSessionCache.cpp |  8 +++-
>  shibsp/shibsp.rc   |  4 ++--
>  shibsp/version.h   |  2 +-
>  util/resourceCommon.rci|  6 +++---
>  10 files changed, 35 insertions(+), 23 deletions(-)
> 
> So here is the debdiff with the Autocruft omitted:
> 
> diff -Nru shibboleth-sp-3.2.1+dfsg1/configure.ac 
> shibboleth-sp-3.2.2+dfsg1/configure.ac
> --- shibboleth-sp-3.2.1+dfsg1/configure.ac2021-03-16 14:33:31.0 
> +0100
> +++ shibboleth-sp-3.2.2+dfsg1/configure.ac2021-04-23 00:18:15.0 
> +0200
> @@ -1,5 +1,5 @@
>  

Bug#986995: linux-image-5.10.0-6-amd64: cdc_acm acm_port_activate fails

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream confirmed pending

Hi Yuri,

On Sun, Apr 25, 2021 at 09:00:22PM +0200, Yuri D'Elia wrote:
> On Sun, Apr 25 2021, Yuri D'Elia wrote:
> > Relevant upstream bug reports:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=212751
> > https://bugzilla.kernel.org/show_bug.cgi?id=212725
> 
> FIY the proposed/accepted patch:
> 
> https://lore.kernel.org/linux-usb/20210421074513.4327-1-oneu...@suse.com/raw
> 
> fixes the issue.

Thanks, and it was backported to 4.19.189 and 5.10.33 in particular,
so will be fixed for unstable in the next upload (and included as well
in the buster proposed update upload).

Regards,
Salvatore

Bug#987684: php-horde-crypt: flaky autopkgtest: Could not obtain public key from the keyserver

[Mike Gabriel]

Hi Paul,

On  Di 27 Apr 2021 20:00:13 CEST, Paul Gevers wrote:


Source: php-horde-crypt
Version: 2.7.12-5
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly
lately.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

By the way, if your test needs internet access, please mark that in the
restrictions with `needs-internet`.

Paul

[1] https://ci.debian.net/packages/p/php-horde-crypt/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-crypt/11893421/log.gz

autopkgtest [14:12:26]: test phpunit: [---
PHPUnit 9.5.2 by Sebastian Bergmann and contributors.

Runtime:   PHP 7.4.15
Configuration:
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/phpunit.xml

Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/Pgp/BinaryTest.php
   Class name was 'Horde_Crypt_Pgp_BinaryTest', expected
'BinaryTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php
   Class name was 'Horde_Crypt_PgpKeyserverTest', expected
'PgpKeyserverTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpParseTest.php
   Class name was 'Horde_Crypt_PgpParseTest', expected
'PgpParseTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/SmimeTest.php
   Class name was 'Horde_Crypt_SmimeTest', expected 'SmimeTest'

...SSE26 /
26 (100%)

Time: 00:30.896, Memory: 6.00 MB

There was 1 error:

1) Horde_Crypt_PgpKeyserverTest::testBrokenKeyserver
Horde_Crypt_Exception: Could not obtain public key from the keyserver.

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:110
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:230
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:80

--

There were 2 skipped tests:

1) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieve
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=0x4DE5B969:  
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=get=0x4DE5B969):

failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:46

2) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieveByEmail
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=index=mr=jan%40horde.org:
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=index=mr=jan%40horde.org):
failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:62

ERRORS!
Tests: 26, Assertions: 62, Errors: 1, Skipped: 2.
autopkgtest [14:12:58]: test phpunit: ---]


Oh well... That flakiness comes from the external keyserver being  
available and not available. I will patch the test to ignore a  
non-reachable keyserver.


Thanks for spotting this.

Mike (who currently is slightly over-worked and fails to get his work  
for Debian 11 done properly, grmpfwqerq...)




--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp9q7mYtmBY8.pgp
Description: Digitale PGP-Signatur

Bug#987718: unblock: fdroidserver/2.0.1-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Hans-Christoph,

On 28-04-2021 13:20, Hans-Christoph Steiner wrote:
> 2.0.1 release includes only narrow bug and compatibility fixes.  This
> package has an extensive autopkgtest suite.

I noticed it fails on ppc64el because zipalign is not available there.
Can you run part of the test suite without zipalign, or is it needed for
everything? If part of the testsuite can be skipped (it's a recommends
after all), then you could make this unblock unnecessary by skipping the
test dependency on ppc64el and skip the tests that need it on ppc64el.

Just saying it's an option, then you don't even need us.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987733: ITP:budgie-screensaver - desktop screensaver for the budgie desktop

[David Mohammed]

Package: wnpp
Severity: wishlist

Owner: David Mohammed (fossfree...@ubuntu.com)

Package name : budgie-screensaver
Version : 4.0
Upstream Author : Solus Project
URL : https://github.com/getsolus/budgie-screensaver
License : GPL-2
Programming Lang: C
Description : Screensaver and screen lock for the Budgie Desktop
 budgie-screensaver is a simple screen saver and screen lock and is a
 form of gnome-screensaver formerly used in older versions of the
 GNOME desktop environment and adopted for use in the Budgie Desktop
 .
 It is designed to support, among other things:
 .
  * the ability to lock down configuration settings
  * translation into other languages
  * user switching

Bug#987732: Stray debug-command in postinst? (/etc/rc.local.dpkg-old)

[Christoph Biedl]

Package: initscripts
Version: 2.96-7
Severity: minor

Hello,

setting up initscripts during an upgrade from 10 ("buster"):

| Setting up initscripts (2.96-7) ...
| Installing new version of config file /etc/default/devpts ...
(...)
| Installing new version of config file /etc/network/if-up.d/mountnfs ...
| 07bd00a3c6527c221d2bd7b6a6e952a2  /etc/rc.local.dpkg-old

The last line seems to come from 

| set -- "$@" 804d8261a41ed2aa9476d7cfac87acd8 # Debian-10
+ md5sum /etc/rc.local.dpkg-old
| for md5 ; do

and looks like a leftover from debugging. Care to check?

Christoph


signature.asc
Description: PGP signature

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

On 2021-04-28 23:07:26, Lev Lamberov wrote:
> Ср 28 апр 2021 @ 11:44 Antoine Beaupré :
>
>> On 2021-04-28 20:34:26, Lev Lamberov wrote:
>>> It makes it a bit trickier. There another package, elpa-bug-hunter
>>> [elpa-bug-hunter], which automatically debug and bisect your init.el or
>>> .emacs file. It may be worth t try it with your config.
>>>
>>> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter
>>
>> Actually, do you know how I would use bug-hunter and esup together? It
>> seems they *both* start a separate emacs process to debug the startup,
>> and thus would be in conflict with each other...
>
> Guess, you may start Emacs as usual, then edit your configuration to run
> esup (that is, run it as a last line of your config), and then run
> bug-hunter. Probably, it will work. Or not. At least, it's worth a try.

That didn't work, but I manually bisected my .emacs.d/init.el file and
came up with this minimal reproducer:

(when (require 'package nil t)
  (setq-default
   load-prefer-newer t
   package-enable-at-startup nil)
  (package-initialize)
  (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/;)
  ("melpa" . "https://melpa.org/packages/;)))
  ;; in elpa-use-package debian package since stretch
  (unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package)))

(eval-when-compile
  (require 'use-package)
  (setq-default
   use-package-always-defer nil
   use-package-always-ensure t))

(use-package lsp-mode
  :commands (lsp lsp-deferred)
  :demand t
  ;;:init
  ;;(setq lsp-keymap-prefix "C-c l")
  ;; TODO: https://emacs-lsp.github.io/lsp-mode/page/performance/
  ;; also note re "native compilation": <+varemara> it's the
  ;; difference between lsp-mode being usable or not, for me
  :config
  (setq lsp-auto-configure t))

It could probably be trimmed down more, and i suspect the 'lsp-mode' bit
is a red-herring: any package would probably trigger it.

A.

-- 
Gods don't like people not doing much work. People who aren't busy all
the time might start to think.
- Terry Pratchett, Small Gods

Bug#987567: systemd: upgrade to 247 breaks unprileged LXC startup

[Michael Biebl]

Am 25.04.2021 um 21:52 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Am 25.04.21 um 21:14 schrieb Wojciech Nizinski:

Package: systemd
Version: 247.3-1~bpo10+1
Severity: normal

Hello!

I think it will be nice to provide upgrade warning that due to chande of
default cgroup hierarchy in systemd, existing unprivileged containers 
cannot be

started and it may need manual intervention.


There is such an upgrade notice, see
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.NEWS#L1 



You need to have apt-listchanges installed (which should be the default).



I think the current NEWS entry is good enough as-is, thus closing

Regards,
Michael

Bug#987731: buster-pu: package openvpn/2.4.7-1

[Bernhard Schmidt]

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

Hi,

I would like to update openvpn in Buster fixing two no-dsa CVEs and one
performance issue.

CVE-2020-11810: No Debian Bug#, fixed upstream in 2.4.9
CVE-2020-15078: Bug#987380, cherry-picked for sid/bullseye in 2.5.1-2

TCP performance issue: Bug#968942, fixed upsteam in 2.4.8

Proposed debdiff attached.

Brnhard
diffstat for openvpn-2.4.7 openvpn-2.4.7

 changelog  |8 
 patches/CVE-2020-11810.patch   |   65 +
 patches/CVE-2020-15078.patch   |   37 +
 patches/increase-tcp-backlog.patch |   43 
 patches/series |3 +
 5 files changed, 156 insertions(+)

diff -Nru openvpn-2.4.7/debian/changelog openvpn-2.4.7/debian/changelog
--- openvpn-2.4.7/debian/changelog  2019-02-20 14:50:03.0 +0100
+++ openvpn-2.4.7/debian/changelog  2021-04-28 16:48:07.0 +0200
@@ -1,3 +1,11 @@
+openvpn (2.4.7-1+deb10u1) buster; urgency=medium
+
+  * Cherry-Pick upstream patches for CVE-2020-11810 and CVE-2020-15078
+(Closes: #987380)
+  * Cherry-Pick upstream fix to increase TCP socket backlog (Closes: #968942)
+
+ -- Bernhard Schmidt   Wed, 28 Apr 2021 16:48:07 +0200
+
 openvpn (2.4.7-1) unstable; urgency=medium
 
   [ Bernhard Schmidt ]
diff -Nru openvpn-2.4.7/debian/patches/CVE-2020-11810.patch 
openvpn-2.4.7/debian/patches/CVE-2020-11810.patch
--- openvpn-2.4.7/debian/patches/CVE-2020-11810.patch   1970-01-01 
01:00:00.0 +0100
+++ openvpn-2.4.7/debian/patches/CVE-2020-11810.patch   2021-04-28 
16:48:07.0 +0200
@@ -0,0 +1,65 @@
+From 37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab Mon Sep 17 00:00:00 2001
+From: Lev Stipakov 
+Date: Wed, 15 Apr 2020 10:30:17 +0300
+Subject: [PATCH] Fix illegal client float (CVE-2020-11810)
+
+There is a time frame between allocating peer-id and initializing data
+channel key (which is performed on receiving push request or on async
+push-reply) in which the existing peer-id float checks do not work right.
+
+If a "rogue" data channel packet arrives during that time frame from
+another address and  with same peer-id, this would cause client to float
+to that new address. This is because:
+
+ - tls_pre_decrypt() sets packet length to zero if
+   data channel key has not been initialized, which leads to
+
+ - openvpn_decrypt() returns true if packet length is zero,
+   which leads to
+
+ - process_incoming_link_part1() returns true, which
+   calls multi_process_float(), which commits float
+
+Note that problem doesn't happen when data channel key is initialized,
+since in this case openvpn_decrypt() returns false.
+
+The net effect of this behaviour is that the VPN session for the
+"victim client" is broken.  Since the "attacker client" does not have
+suitable keys, it can not inject or steal VPN traffic from the other
+session.  The time window is small and it can not be used to attack
+a specific client's session, unless some other way is found to make it
+disconnect and reconnect first.
+
+CVE-2020-11810 has been assigned to acknowledge this risk.
+
+Fix illegal float by adding buffer length check ("is this packet still
+considered valid") before calling multi_process_float().
+
+Trac: #1272
+CVE: 2020-11810
+
+Signed-off-by: Lev Stipakov 
+Acked-by: Arne Schwabe 
+Acked-by: Antonio Quartulli 
+Acked-by: Gert Doering 
+Message-Id: <20200415073017.22839-1-lstipa...@gmail.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19720.html
+Signed-off-by: Gert Doering 
+---
+ src/openvpn/multi.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
+index b42bcec97..056e3dc76 100644
+--- a/src/openvpn/multi.c
 b/src/openvpn/multi.c
+@@ -2577,7 +2577,8 @@ multi_process_incoming_link(struct multi_context *m, 
struct multi_instance *inst
+ orig_buf = c->c2.buf.data;
+ if (process_incoming_link_part1(c, lsi, floated))
+ {
+-if (floated)
++/* nonzero length means that we have a valid, decrypted 
packed */
++if (floated && c->c2.buf.len > 0)
+ {
+ multi_process_float(m, m->pending);
+ }
diff -Nru openvpn-2.4.7/debian/patches/CVE-2020-15078.patch 
openvpn-2.4.7/debian/patches/CVE-2020-15078.patch
--- openvpn-2.4.7/debian/patches/CVE-2020-15078.patch   1970-01-01 
01:00:00.0 +0100
+++ openvpn-2.4.7/debian/patches/CVE-2020-15078.patch   2021-04-28 
16:48:07.0 +0200
@@ -0,0 +1,37 @@
+From 0e5516a9d656ce86f7fb370c824344ea1760c255 Mon Sep 17 00:00:00 2001
+From: Arne Schwabe 
+Date: Tue, 6 Apr 2021 00:05:21 +0200
+Subject: [PATCH] Ensure key state is authenticated before sending push reply
+
+This ensures that the key state is authenticated when sending
+a push reply.
+---
+ 

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

Ср 28 апр 2021 @ 11:44 Antoine Beaupré :

> On 2021-04-28 20:34:26, Lev Lamberov wrote:
>> It makes it a bit trickier. There another package, elpa-bug-hunter
>> [elpa-bug-hunter], which automatically debug and bisect your init.el or
>> .emacs file. It may be worth t try it with your config.
>>
>> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter
>
> Actually, do you know how I would use bug-hunter and esup together? It
> seems they *both* start a separate emacs process to debug the startup,
> and thus would be in conflict with each other...

Guess, you may start Emacs as usual, then edit your configuration to run
esup (that is, run it as a last line of your config), and then run
bug-hunter. Probably, it will work. Or not. At least, it's worth a try.

Cheers!
Lev

Bug#947064: Budowlane Francja - Kampania NOWE: Unsubscription Confirmed

[Servais]

Title: 
  Budowlane Francja - Kampania NOWE


  


  
  
  

  
  


  

  


  

  


  

  Budowlane Francja - Kampania NOWE

  

  

  

  
  
  
  


  

  
  

  

  
  

  


  

  
  

  
  

  
  


  

  


  

  


  

  You Are Now Unsubscribed

  

  

  

  We have removed your email address from our list. If you unsubscribed by mistake, you can re-subscribe at:

  

  

  

  

  

  Subscribe

  

  

  

  

  

  For questions about this list, please contact:
ad...@camionexport.eu

  

  
  

  

  
  

  


  

  
  

  
  


  

  


  

  


  

  

  

  
  

  

  
  

  


  

  
  

  

  

  

Bug#987727: [Pkg-auth-maintainers] Bug#987727: fido2-tools: does not find available fido2 tokens

[Andreas Kemnade]

Hi Taowa,

On Wed, 28 Apr 2021 12:08:28 -0400
Taowa  wrote:

> Control: severity -1 wishlist
> 
> Hi Andreas,
> 
> As far as I can tell, fido2-tools only speaks USB (and has experimental
> support for NFC, but...):
> 
> > libfido2 provides library functionality and command-line tools to
> > communicate with a FIDO device over USB, and to verify attestation and
> > assertion signatures.  
> (https://developers.yubico.com/libfido2/)
> 
> Setting this bug to "wishlist" severity, and I'll look into whether this
> is something upstream might want to support.
> 
hmm, ok, seems to be part of libfido2. But the package fido2-tools
itself has no documentation about that limitation. I would expect
something like that in the manpage

Regards,
Andreas

Bug#987584: docker.io: docker-proxy does not bind to ipv6 "all network" address

[Shengjing Zhu]

On Mon, Apr 26, 2021 at 1:15 PM Jérémy Viès  wrote:
>
> Package: docker.io
> Version: 20.10.5+dfsg1-1+b1
> Severity: important
> Tags: ipv6
>
> Dear Maintainer,
>
>
>* What led up to the situation?
> I'm trying to expose some web app to the ipv6 Internet !
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I enabled ipv6 support in /etc/docker/daemon.json as explained in docker doc.
>* What was the outcome of this action?
> Exposed ports are only on ipv4 even if ipv6 is enabled in docker 
> configuration.
>* What outcome did you expect instead?
> The binding shall be done on both ipv4 and ipv6 networks.
>
> The issue is confirmed upstream : https://github.com/moby/moby/issues/42059
> It is due to https://github.com/moby/libnetwork/issues/2607
> It seems to be fixed already, and packaged in version 20.10.6 that has been
> just released.

While 20.10.6 fixes this issue, it introduces other regressions,
https://github.com/moby/moby/issues/42288

-- 
Shengjing Zhu

Bug#987615: perl-base: please ship modules used by usrmerge in perl-base

[Niko Tyni]

On Mon, Apr 26, 2021 at 03:26:02PM +0100, Dimitri John Ledkov wrote:
> Package: perl-base
> Version: 5.30.3-4
> Severity: normal
> 
> Dear Maintainer,
> 
> usrmerge will be needed to be installed upon upgrades to bookworm to
> convert systems to merged /usr. It would be helpful for small installs
> to be able to perform that without installing the larger perl package.

Thanks for raising this early. I'm copying the usrmerge maintainer.
 
> Please consider moving things that usrmerge & libfile-find-rule-perl
> use from per/perl-modules to perl-base.

I understand the concern, but I'm hesitant to do this. See below.

> In bookworm+1 you may drop these things from perl-base and add breaks
> on usrmerge.

Quoting the Debian policy:

  Maintainers should take great care in adding any programs, interfaces,
  or functionality to essential packages. Packages may assume that
  functionality provided by essential packages is always available without
  declaring explicit dependencies, which means that removing functionality
  from the Essential set is very difficult and is almost never done. Any
  capability added to an essential package therefore creates an obligation
  to support that capability as part of the Essential set in perpetuity.

Have other avenues been investigated? How critical is the
libfile-find-rule-perl dependency - would it be hard to replace it with
something that's already in the Essential set, for instance piping from
find(1) ? Could autodie usage be replaced with explicit error handling?

Is Perl the right language to implement the migration in the first
place? A small binary with minimal external dependencies would seem
preferable.

-- 
Niko Tyni   nt...@debian.org

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Wed, 2021-04-28 at 17:51 +0200, Cyril Brulebois wrote:
> > 
> > Why not just drop the dependency on udev and libopeniscsiusr
> entirely,
> > for the open-iscsi-udeb package ?
> 
> This is not sufficient:

Please review the attached patch. I build tested locally and the
results are below. If this looks good to you, then I'll prepare an
upload and ask the release team for an unblock.

I also opted to drop the explicit udev dependency.

rrs@priyasi:.../Result$ dpkg -I open-iscsi-udeb_2.1.3-2_amd64.udeb 
 new Debian package, version 2.0.
 size 248668 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-2
 Architecture: amd64
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1341
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.


Thanks,
Ritesh
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
From b98d26b860ef7c989438d2641eaa5d2c514d2b51 Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Wed, 28 Apr 2021 22:13:39 +0530
Subject: [PATCH] Make open-iscsi-udeb compatible with d-i

In this change, we add libopeniscsiusr shared object explicitly to the udeb package to
avoid any reference to the libopeniscsiusr .deb package

We also add an override in shlibs generation

This oddity, that of open-iscsi-udeb shipping a library but open-iscsi
not shipping the library, is purely in the context of debian-installer

So, let's override and instruct mkshlibs to do the requested thing

And finally,
Drop explicit dependency on libopeniscsiusr and udev
---
 debian/control | 2 --
 debian/rules   | 6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0a4627f..a69ce2c 100644
--- a/debian/control
+++ b/debian/control
@@ -144,8 +144,6 @@ Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
diff --git a/debian/rules b/debian/rules
index 10584dd..1152be3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -69,6 +69,9 @@ override_dh_auto_install:
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start sbin/iscsi-start
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.finish-install usr/lib/finish-install.d/10open-iscsi
 
+	# We do this to keep the udeb in the installer happy
+	dh_install -p open-iscsi-udeb libopeniscsiusr/libopeniscsiusr*.so.* usr/lib/${DEB_HOST_MULTIARCH}
+
 override_dh_installinit:
 	dh_installinit -p open-iscsi --name=iscsid
 	dh_installinit -p open-iscsi
@@ -96,3 +99,6 @@ override_dh_installdocs:
 
 override_dh_missing:
 	dh_missing --fail-missing
+
+override_dh_makeshlibs:
+	dh_makeshlibs --add-udeb=open-iscsi-udeb
-- 
2.31.1



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

Bug#987730: unblock: multipath-tools/0.8.5-1

[Ritesh Raj Sarraf]

Dear Release Team,

On Wed, 2021-04-28 at 22:50 +0530, Ritesh Raj Sarraf wrote:
>   [x] attach debdiff against the package in testing
> 

The revised debdiff patch is attached in this follow-up message. The
initial patch was missing an important fix.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
diff -Nru multipath-tools-0.8.5/debian/changelog multipath-tools-0.8.5/debian/changelog
--- multipath-tools-0.8.5/debian/changelog	2020-12-24 05:23:53.0 +0530
+++ multipath-tools-0.8.5/debian/changelog	2021-04-28 22:40:55.0 +0530
@@ -1,3 +1,10 @@
+multipath-tools (0.8.5-2) unstable; urgency=medium
+
+  * [373f5c5] Fix bashism in script kpartx/kpartx_id.
+Thanks to Julien Cristau (Closes: #987669)
+
+ -- Ritesh Raj Sarraf   Wed, 28 Apr 2021 22:40:55 +0530
+
 multipath-tools (0.8.5-1) unstable; urgency=medium
 
   [ Ritesh Raj Sarraf ]
diff -Nru multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
--- multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch	1970-01-01 05:30:00.0 +0530
+++ multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch	2021-04-28 22:40:55.0 +0530
@@ -0,0 +1,23 @@
+From: Ritesh Raj Sarraf 
+Date: Wed, 28 Apr 2021 22:06:50 +0530
+Subject: Fix bashism in kpartx_id script
+
+Thanks: Julien Cristau
+Closes: #987669
+---
+ kpartx/kpartx_id | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
+index c45db2f..18732e7 100755
+--- a/kpartx/kpartx_id
 b/kpartx/kpartx_id
+@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
+ else
+ echo "DM_TYPE=raid"
+ fi
+-if [[ $dmserial ]]; then
++if [ -n "$dmserial" ]; then
+ echo "DM_SERIAL=$dmserial"
+ fi
+ 
diff -Nru multipath-tools-0.8.5/debian/patches/series multipath-tools-0.8.5/debian/patches/series
--- multipath-tools-0.8.5/debian/patches/series	2020-12-24 05:23:53.0 +0530
+++ multipath-tools-0.8.5/debian/patches/series	2021-04-28 22:40:55.0 +0530
@@ -7,3 +7,4 @@
 0008-Bug-916521-FTCBFS-uses-the-wrong-pkg-config.patch
 0009-kpartx-rules-use-Debian-specific-partx-path.patch
 0010-multipath.rules-do-not-assume-usrmerged-paths.patch
+0010-Fix-bashism-in-kpartx_id-script.patch


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

Bug#987730: unblock: multipath-tools/0.8.5-1

[Ritesh Raj Sarraf]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package multipath-tools

[ Reason ]
It was discovered that one of the scripts, kpartx/kpartx_id, which
declares posix compatibility has a single line bashism

[ Impact ]
The script fails apart, under the condition where the bashism is used

[ Risks ]
Trivial, one-liner

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock multipath-tools/0.8.5-1

Please give me a Yes, and then I'll do the upload to Debian Unstable.
diff -Nru multipath-tools-0.8.5/debian/changelog 
multipath-tools-0.8.5/debian/changelog
--- multipath-tools-0.8.5/debian/changelog  2020-12-24 05:23:53.0 
+0530
+++ multipath-tools-0.8.5/debian/changelog  2021-04-28 22:40:55.0 
+0530
@@ -1,3 +1,10 @@
+multipath-tools (0.8.5-2) unstable; urgency=medium
+
+  * [373f5c5] Fix bashism in script kpartx/kpartx_id.
+Thanks to Julien Cristau (Closes: #987669)
+
+ -- Ritesh Raj Sarraf   Wed, 28 Apr 2021 22:40:55 +0530
+
 multipath-tools (0.8.5-1) unstable; urgency=medium
 
   [ Ritesh Raj Sarraf ]
diff -Nru 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch
--- 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
1970-01-01 05:30:00.0 +0530
+++ 
multipath-tools-0.8.5/debian/patches/0010-Fix-bashism-in-kpartx_id-script.patch 
2021-04-28 22:40:55.0 +0530
@@ -0,0 +1,23 @@
+From: Ritesh Raj Sarraf 
+Date: Wed, 28 Apr 2021 22:06:50 +0530
+Subject: Fix bashism in kpartx_id script
+
+Thanks: Julien Cristau
+Closes: #987669
+---
+ kpartx/kpartx_id | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
+index c45db2f..2b0b1de 100755
+--- a/kpartx/kpartx_id
 b/kpartx/kpartx_id
+@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
+ else
+ echo "DM_TYPE=raid"
+ fi
+-if [[ $dmserial ]]; then
++if [ -n $dmserial ]; then
+ echo "DM_SERIAL=$dmserial"
+ fi
+ 
diff -Nru multipath-tools-0.8.5/debian/patches/series 
multipath-tools-0.8.5/debian/patches/series
--- multipath-tools-0.8.5/debian/patches/series 2020-12-24 05:23:53.0 
+0530
+++ multipath-tools-0.8.5/debian/patches/series 2021-04-28 22:40:55.0 
+0530
@@ -7,3 +7,4 @@
 0008-Bug-916521-FTCBFS-uses-the-wrong-pkg-config.patch
 0009-kpartx-rules-use-Debian-specific-partx-path.patch
 0010-multipath.rules-do-not-assume-usrmerged-paths.patch
+0010-Fix-bashism-in-kpartx_id-script.patch

Bug#976704: po4a: Missing dependency on libpod-parser-perl

[Niko Tyni]

On Sun, Apr 25, 2021 at 09:40:02PM +0300, Adrian Bunk wrote:
> Control: reassign -1 perl 5.32.0-6
> Control: retitle -1 perl needs Breaks on more perl-modules-* packages
> Control: severity -1 serious
> Control: affects -1 po4a
> 
> On Mon, Dec 07, 2020 at 09:24:57AM +0100, Helge Kreutzmann wrote:
> >...
> > Versions of packages po4a depends on:
> >...
> > ii  perl5.32.0-5
> > ii  perl-modules-5.22 [libpod-parser-perl]  5.22.2-5
> >...
> 
> 5.32 != 5.22
> 
> #97 already fixed the same problem for perl-modules-5.24.

Indeed. As discussed there, certain versions of perl-modules-* in the
past Provided virtual packages such as libpod-parser-perl, without making
sure that those bundled modules were usable with the current /usr/bin/perl
on the system. This property broke later when perl was upgraded.

Versions earlier than 5.22 were not affected, and the issue was fixed
in perl-modules-5.26 5.26.2-5 with #899110. 5.24 (which was in stretch)
is already handled but I missed the other versions.

So this only happens with packages that were never in a stable
release. Not sure if that affects the severity. It should be easy to
fix by adding

 Breaks: perl-modules-5.22, perl-modules-5.26 (<< 5.26.2-5)

Any regressions seem improbable given these are leftovers from a time
before the current stable release.

Ubuntu has released with both 5.22 and an affected version of 5.26.
Haven't heard of similar issues there but a fix would possibly help
their users too (at least eventually.)

In general the coinstallability of older libperl5.xx and perl-modules-5.xx
packages with current ones is desirable to ease upgrades of packages
linking against libperl, such as postgresql.
-- 
Niko Tyni   nt...@debian.org

Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet

[Simon Josefsson]

Package: inetutils-telnet
Severity: wishlist

As discussed in https://bugs.debian.org/982253 netkit-telnet is not
(actively) maintained upstream or in Debian.  Inetutils may not be the
state of the art as a well-maintained project, but at least there are
upstream releases and good packaging in Debian.

I believe 'apt-get install telnet' should install inetutils-telnet
rather than netkit-telnet going forward.  Once bullseye is released it
is a good time to make the switch.  I'm opening this bug to find out
what needs to be done in order to make this happen, if there is
agreement that this is a good idea.

1) What needs to be done in d/control for the inetutils-telnet package?
Should it 'Provides: telnet' and 'Replaces: telnet'?  Anything more?

2) Is it required for 1) that the netkit-telnet package is removed from
Debian?  Maybe the package could live on and ship 'netkit-telnet'
instead of the 'telnet' package?  Perhaps that package could continue to
live on in unstable, but never ship with a future release in favor of
inetutils-telnet.

3) The implementations needs to be analyzed for compatibility.  The
--usage outputs are like this:

Usage: telnet.netkit [-4] [-6] [-8] [-E] [-L] [-a] [-d] [-e char] [-l user]
[-n tracefile] [ -b addr ] [-r] [host-name [port]]

Usage: inetutils-telnet [-468acdEKLrx?V] [-e CHAR] [-l USER] [-n FILE]
[-k REALM] [-X ATYPE] [--ipv4] [--ipv6] [--binary] [--login]
[--no-rc] [--debug] [--escape=CHAR] [--no-escape] [--no-login]
[--user=USER] [--binary-output] [--trace=FILE] [--rlogin]
[--encrypt] [--realm=REALM] [--disable-auth=ATYPE] [--help]
[--usage] [--version] [HOST [PORT]]

A quick comparison indicates that inetutils-telnet is missing the '-b
addr' command.  I'll try to verify that the parameter actually does the
intended thing in netkit-telnet, and then see if I can implement that
upstream in inetutils.

Further feature comparisons would be welcome though.

4) The man page for inetutils-telnet is less useful than the
netkit-telnet man page.  I think this could be improved upstream in
inetutils, and will work on that.

Similar thoughts applies to inetutils-telnetd vs netkit-telnetd too, but
I wanted to start with something simple so I chose inetutils-telnet.
Since telnet and telnetd is shipped from the same netkit-telnet source
package, it may that if 2) is involved above, something needs to happen
to inetutils-telnetd too, and then so be it.

Thoughts?

/Simon


signature.asc
Description: PGP signature

Bug#985669: Happy to help

[Brian Thompson]

> While I would love to package this myself, I do not work with
> JavaScript regularally (in part due to ecosystem problems like
> NPM's love of duplication).

I have some experience packaging JavaScript projects and could help you
out here.



signature.asc
Description: PGP signature

Bug#987488: unblock: ircci/20210314-1

[Jan Wagner]

Hi Daniel,

Am 28.04.21 um 18:52 schrieb Daniel Echeverri:
I will go to work in this, but I'm not sure how is the best way in the 
case. Could you give a orientation? I think I can't make a complete 
debdiff because  in version unstable I bumped debhelper to 13 and this 
change is not accepted at this stage of the release.


I think you need to prepare a new package version where you revert the 
debhelper bump. Anyway ... in this case I would ask RM for a 
pre-approval before uploading the new package to unstable (see 
bugs.debian.org/987178 for an example). This may save time for possible 
reupload, if RM requests more changes.


Cheers, Jan.
--
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS 
PE Y++

PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--

Bug#775215: Closing this bug

[Vincas Dargis]

I cannot reproduces this because remounting to produces "mount: /: mount point is 
busy." error.

Bug#987669: kpartx: bashism in /bin/sh script (kpartx_id)

[Julien Cristau]

On Wed, Apr 28, 2021 at 10:09:02PM +0530, Ritesh Raj Sarraf wrote:
> On Tue, 2021-04-27 at 15:52 +0200, Julien Cristau wrote:
> > 
> > Apr 27 13:44:47 ubc-enc2bl10/ubc-enc2bl10 systemd-udevd[50553]:
> > 'kpartx_id 254 29 mpath-3600c0ff00027786c559a785d0100'(err)
> > '/lib/udev/kpartx_id: 96: /lib/udev/kpartx_id: [[: not found'
> > 
> > /lib/udev/kpartx_id has a /bin/sh shebang, [[ is a bashism, so should
> > probably be replaced with the standard "test -n".
> 
> 
> Maybe I'm doing something very silly. But I don't get the desired
> output with "test -n"
> 
You need to quote "$x" and "$y".

Cheers,
Julien

Bug#987669: kpartx: bashism in /bin/sh script (kpartx_id)

[Ritesh Raj Sarraf]

On Tue, 2021-04-27 at 15:52 +0200, Julien Cristau wrote:
> 
> Apr 27 13:44:47 ubc-enc2bl10/ubc-enc2bl10 systemd-udevd[50553]:
> 'kpartx_id 254 29 mpath-3600c0ff00027786c559a785d0100'(err)
> '/lib/udev/kpartx_id: 96: /lib/udev/kpartx_id: [[: not found'
> 
> /lib/udev/kpartx_id has a /bin/sh shebang, [[ is a bashism, so should
> probably be replaced with the standard "test -n".


Maybe I'm doing something very silly. But I don't get the desired
output with "test -n"

rrs@priyasi:~$ cat /tmp/string.sh 
#!/bin/dash


x="Ritesh"
y=

if [ -n $x ]; then
echo Yes
fi

if [ -n $y ]; then
echo Yes
fi

test -n $x && echo Yes
test -n $y && echo Yes

rrs@priyasi:~$ /tmp/string.sh 
Yes
Yes
Yes
Yes


I rather propose this commit.

commit 7d3a38a2efd955e17b43edd43e866c8705f7d570 (HEAD -> patch-
queue/wip/ritesh/fix-bashism)
Author: Ritesh Raj Sarraf 
Date:   Wed Apr 28 22:06:50 2021 +0530

Fix bashism in kpartx_id script

Thanks: Julien Cristau
Closes: #987669

diff --git a/kpartx/kpartx_id b/kpartx/kpartx_id
index c45db2f8..e8448674 100755
--- a/kpartx/kpartx_id
+++ b/kpartx/kpartx_id
@@ -93,7 +93,7 @@ if [ -n "$dmdeps" ] ; then
 else
 echo "DM_TYPE=raid"
 fi
-if [[ $dmserial ]]; then
+if ! [ -z $dmserial ]; then
 echo "DM_SERIAL=$dmserial"
 fi
 


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#987488: unblock: ircci/20210314-1

[Daniel Echeverri]

Hi!

El dom, 25 de abr. de 2021 a la(s) 11:08, Jan Wagner (w...@cyconet.org)
escribió:

> Hi there,
>
> Am 25.04.21 um 09:35 schrieb Graham Inggs:
> > Control: retitle -1 unblock: ircii/20210314-1
> > Contro: tags -1 + moreinfo
> >
> > Hi Jan
> >
> > On Sat, 24 Apr 2021 at 16:21, Jan Wagner  wrote:
> >> [ Risks ]
> >> While the diffstat looks huge, a significant part is removed code.
> >
> > This debdiff is unreviewable.  Please provide a filtered debdiff along
> > with the command used to filter it.
> >
> > ++ Bump Debhelper-compat to 13.
> >
> > Bumping the debehlper compat level is not accepted at this stage of
> > the release [1].
> > Please revert this change.
>
> security stated, that ircii might not qualify to be released with
> bullseye (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987537#10
> ).
>
> I think I would leave it up to Daniel, who did the QA upload, if it's
> worth to work on this. If nobody is caring about ircii in bullseye, we
> should close this bug here.
>
> With kind regards, Jan.
>

I will go to work in this, but I'm not sure how is the best way in the
case. Could you give a orientation? I think I can't make a complete debdiff
because  in version unstable I bumped debhelper to 13 and this change is
not accepted at this stage of the release.

Thanks for your help!

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#832287: (no subject)

[ZenWalker]

the package:

https://ftp.secretchronicles.org/releases/TSC-2.1.0-sid-amd64.deb

taken from:

https://secretchronicles.org/en/download/

works very nicely on debian sid

please consider to package this amazing game into offical deb packages

Bug#947193: please coordinate the provider of crypt.h

[Reiner Herrmann]

Hi Helmut, Marco,

during a discussion on IRC today another option has been presented.
Upstream mentioned [0] some time ago that it is possible to link with
libxcrypt without using musl's crypt functions:

> You can just not install the musl crypt.h.
> Linking libxcrypt should automatically cause
> it to get used instead of the functions in libc.

I like this option as it would allow programs using musl to also use
newer crypt methods from libxcrypt.

In order to prevent accidental usage of musl's crypt functions (e.g.
by forgetting to pass -lcrypt), I will disable/remove the functions
in libc.so.
And additionaly musl's crypt.h will not be shipped.

Kind regards,
  Reiner

[0] https://www.openwall.com/lists/musl/2019/11/08/10


signature.asc
Description: PGP signature

Bug#983409: raspi-firmware: /etc/kernel/postinst.d/z50-raspi-firmware fails to ignore old-dkms initrds

[Gunnar Wolf]

Control: tags -1 - patch
Control: tags -1 + pending

Hi,

While your patch would work for arm64 (RPi 3 and 4 families), it would
not work for armel (RPi 0/1) or armhf (RPi 2). The suffix of the
kernel version denotes the machine type, not just the architecture;
our working armel kernel is -rpi, and our working armhf kernel is
-armmp.

We could set those suffixes based on the output of "dpkg
--print-architecture", but I fear that would also end up in unbootable
systems for some people who built their own kernels or so.

I will go the other route, and -same as I'm doing grep -v \.dpkg-bak$-
will exclude the known suffix you report for DKMS kernels. I hope that
solves the issue!

Bug#496791: geany: Copy text with middle mouse button doesn't work

[Claude Paroz]

On Mon, 1 Sep 2008 10:01:55 +0200 Enrico =?UTF-8?B?VHLDtmdlcg==?= 
 wrote:

> I had a look at this and I think if this is really a bug, it's a bug in
> Scintilla not directly in Geany (Scintilla is the embedded editing
> component in Geany).
>
> I tested this also with SciTE (also based on Scintilla) and with
> mousepad (based on GTK's TextView) from Xfce. And they both behave like
> you describe: pasting doesn't work once the selection is gone. I don't
> know the X selection specification (primary clipboard) but maybe this
> is the intended behaviour.

Looks like it was solved today in Scintilla:

https://sourceforge.net/p/scintilla/code/ci/921cb3dea3112a

I'd love this to be also fixed in the next Debian stable!

Claude

Bug#987727: [Pkg-auth-maintainers] Bug#987727: fido2-tools: does not find available fido2 tokens

[Taowa]

Control: severity -1 wishlist

Hi Andreas,

As far as I can tell, fido2-tools only speaks USB (and has experimental
support for NFC, but...):

> libfido2 provides library functionality and command-line tools to
> communicate with a FIDO device over USB, and to verify attestation and
> assertion signatures.
(https://developers.yubico.com/libfido2/)

Setting this bug to "wishlist" severity, and I'll look into whether this
is something upstream might want to support.

Taowa

Andreas Kemnade, 2021-04-28 11:57 -0400:
> Dear Maintainer,
> 
>* What led up to the situation?
> I paired a FIDO2 device via bluetoothctl
> FIDO service is available and found:
> $ mdbus2 -s org.bluez /org/bluez/hci0/dev_D0_CF_5E_06_F9_C4/service002d 
> org.freedesktop.DBus.Properties.GetAll org.bluez.GattService1
> ({'UUID': <'fffd--1000-8000-00805f9b34fb'>, 'Device':  '/org/bluez/hci0/dev_D0_CF_5E_06_F9_C4'>, 'Primary': , 'Includes': <@ao 
> []>},)
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I tried to list the available devices via fido2-token -L and tried to get
> information about these devices via fido2-token -I
>* What was the outcome of this action?
> $ fido2-token -L
> $ fido2-token -I D0:CF:5E:06:F9:C4
> fido2-token: fido_dev_open D0:CF:5E:06:F9:C4: FIDO_ERR_INTERNAL
> 
>* What outcome did you expect instead?
> I expected to see the list of available FIDO2 devices and information
> about that particular device. NB: I would expect better documentation in the 
> manpage how to properly specify a device in the commandline parameters.


-- 
Taowa (they)
people.debian.org/~taowa
LOC FN35EM

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Gard Spreemann  writes:

> Gard Spreemann  writes:
>
>> Andreas Tille  writes:
>>
>>> Hi Aaron,
>>>
>>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
 Please try adding a build dependency on libclfft-dev and replacing
 src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
 to
 
   find_package(clFFT)
 
 > Thanks a lot for your initial hint
>>>
>>> Thanks again.  I now tried to learn from this and added a similar patch
>>> for CLBLast[1] but as you can see in the new log[2] it is not that
>>> simple.  I tried to compare the content of
>>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
>>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
>>> like and I need to admit I have no idea why this fails.
>>
>> This seems to be just a typo on my part. The logs have
>>
>> ***
>> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
>>   By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
>>   asked CMake to find a package configuration file provided by "CLBLast", but
>>   CMake did not find one.
>>   Could not find a package configuration file provided by "CLBLast" with any
>>   of the following names:
>> CLBLastConfig.cmake
>> clblast-config.cmake
>>   Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
>>   "CLBLast_DIR" to a directory containing one of the above files.  If
>>   "CLBLast" provides a separate development package or SDK, be sure it has
>>   been installed.
>> ***
>>
>> libclblast-dev ships
>>
>>  /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake
>>
>> Notice that there's both "CLBLast" and "CLBlast" in there! I'll
>> investigate.
>
> Looks like an upstream bug; consider the inconsistent capitalization of
> the second l in "clblast" online 363 in
>
>  
> https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363
>
> I'll report it upstream and patch src:clblast.

Could you try with the patch from the debian/gspr/typo branch of [1]?
Alternatively, I put a built version of the patched clblast up at [2].


[1] https://salsa.debian.org/gspr/clblast.git

[2] https://nonempty.org/~gspr/clblast-typo/


 Best,
 Gard
 


signature.asc
Description: PGP signature

Bug#987728: wims-modules: depends on unavailable tinymce

[Andreas Beckmann]

Package: wims-modules
Version: 1:4.21f~dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

  The following packages have unmet dependencies:
   wims-modules : Depends: tinymce but it is not installable

tinymce has been removed recently: https://bugs.debian.org/977149


Cheers,

Andreas

Bug#987727: fido2-tools: does not find available fido2 tokens

[Andreas Kemnade]

Package: fido2-tools
Version: 1.5.0-2~bpo10+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
I paired a FIDO2 device via bluetoothctl
FIDO service is available and found:
$ mdbus2 -s org.bluez /org/bluez/hci0/dev_D0_CF_5E_06_F9_C4/service002d 
org.freedesktop.DBus.Properties.GetAll org.bluez.GattService1
({'UUID': <'fffd--1000-8000-00805f9b34fb'>, 'Device': , 'Primary': , 'Includes': <@ao 
[]>},)


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to list the available devices via fido2-token -L and tried to get
information about these devices via fido2-token -I
   * What was the outcome of this action?
$ fido2-token -L
$ fido2-token -I D0:CF:5E:06:F9:C4
fido2-token: fido_dev_open D0:CF:5E:06:F9:C4: FIDO_ERR_INTERNAL

   * What outcome did you expect instead?
I expected to see the list of available FIDO2 devices and information
about that particular device. NB: I would expect better documentation in the 
manpage how to properly specify a device in the commandline parameters.


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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fido2-tools depends on:
ii  libc6   2.28-10
ii  libcbor00.5.0+dfsg-2
ii  libfido2-1  1.5.0-2~bpo10+1
ii  libssl1.1   1.1.1d-0+deb10u6
ii  libudev1241-7~deb10u7

fido2-tools recommends no packages.

fido2-tools suggests no packages.

-- no debconf information

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi Ritesh,

Ritesh Raj Sarraf  (2021-04-28):
> That's an explicit dependency that got added in the merge I reviewed
> for 2.1.2.
> 
> Why not just drop the dependency on udev and libopeniscsiusr entirely,
> for the open-iscsi-udeb package ?

This is not sufficient:

--- a/debian/control
+++ b/debian/control
@@ -144,8 +144,6 @@ Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,

After a build:

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ dpkg --info 
../open-iscsi-udeb_2.1.3-2_amd64.udeb|grep Depends
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), 
libisns-udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libopeniscsiusr, 
libsystemd0 (>= 247.3), scsi-modules

Notice that libopeniscsiusr is still there, which isn't surprising at
all. Executables shipped in the udeb refer to shared objects that are
referenced in its shlibs file!

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ cat 
debian/libopeniscsiusr/DEBIAN/shlibs 
libopeniscsiusr 0.2.0 libopeniscsiusr

Random example:

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ objdump -x 
debian/open-iscsi-udeb/sbin/iscsiadm | grep NEEDED
  NEEDED   libisns.so.0
  NEEDED   libcrypto.so.1.1
  NEEDED   libmount.so.1
  NEEDED   libkmod.so.2
  NEEDED   libopeniscsiusr.so.0.2.0
  NEEDED   libc.so.6

Hence my suggestion: shipped shared object(s) in the udeb directly, so
that there's no reference towards external packages.

A similar package is haveged, using debian/shlibs.local to ensure that
the “library resolution” (dh_shlibdeps) doesn't pull the deb library, by
making it explicit for the udeb that it contains the required shared
object(s).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987726: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.143-1~deb10u1

[Andreas Beckmann]

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

Hi,

let's fix CVE-2021-1076 by updating the non-free
nvidia-graphics-drivers-legacy-390xx in buster to a new upstream release.

This a rebuild of the package in sid, thus it also contains the
additional packaging change: the creation of the missing
libnvidia-ml.so symlink.

Andreas
diff --git a/debian/changelog b/debian/changelog
index d22ddead..d85c2140 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+nvidia-graphics-drivers-legacy-390xx (390.143-1~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Wed, 28 Apr 2021 17:44:32 +0200
+
+nvidia-graphics-drivers-legacy-390xx (390.143-1) unstable; urgency=medium
+
+  * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076.  (Closes: #987218)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+  when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+  candidates, where the NVIDIA kernel module failed to build with error
+  "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann   Tue, 20 Apr 2021 02:04:19 +0200
+
+nvidia-graphics-drivers-legacy-390xx (390.141-3) unstable; urgency=medium
+
+  * nvidia-legacy-390xx-alternative: Add libnvidia-ml.so slave alternative if
+libnvidia-ml-dev is installed (460.56-2).  (Closes: #984881)
+
+ -- Andreas Beckmann   Sat, 13 Mar 2021 22:39:29 +0100
+
 nvidia-graphics-drivers-legacy-390xx (390.141-2~deb10u1) buster; urgency=medium
 
   * Rebuild for buster.
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 6decf255..577ad1e6 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,5 +1,5 @@
 a1db8e174e35b30f771fffdf4690ea8b  debian/control
 0a204645020c143be44b04bd5daf7b85  debian/control.in
 db12f898b07cdaf431ad34bd68a1662e  debian/gen-control.pl
-365281fc24d824d688be59ab97ae1ca5  debian/rules
+e0a6daa55d2509f44d21bbb591ccbad1  debian/rules
 181fae6bc60df1e667ef475560be4fdf  debian/rules.defs
diff --git a/debian/nvidia-alternative.postinst.in 
b/debian/nvidia-alternative.postinst.in
index 23b5ebc2..ba7573ad 100644
--- a/debian/nvidia-alternative.postinst.in
+++ b/debian/nvidia-alternative.postinst.in
@@ -80,10 +80,14 @@ if [ "$1" = "triggered" ]; then
$(add_slave /etc/nvidia/nvidia-modprobe.conf 
nvidia-modprobe.conf /etc/#PRIVATE#/nvidia-modprobe.conf)
$(add_slave /etc/nvidia/nvidia-load.conf nvidia-load.conf 
/etc/#PRIVATE#/nvidia-load.conf)
 "
+   libnvidia_ml_so_slave=
+   if [ -f /usr/include/nvml.h ]; then
+   libnvidia_ml_so_slave="$(add_multiarch_slave /usr/lib "" 
libnvidia-ml.so /usr/lib #PRIVATE#/)"
+   fi
if echo "$slaves" | grep -q "slave" ; then
-   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves
+   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave
# work around #916799 and re-register the alternative to 
clean-up leftover slaves
-   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves
+   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave
else
update-alternatives --remove nvidia /usr/lib/#PRIVATE#
fi
diff --git a/debian/nvidia-alternative.triggers.in 
b/debian/nvidia-alternative.triggers.in
index 451bead4..699759ac 100644
--- a/debian/nvidia-alternative.triggers.in
+++ b/debian/nvidia-alternative.triggers.in
@@ -5,3 +5,5 @@ interest-await /usr/lib/#PRIVATE#
 interest-await /usr/lib/i386-linux-gnu/#PRIVATE#
 interest-await /usr/lib/x86_64-linux-gnu/#PRIVATE#
 interest-await /usr/lib/arm-linux-gnueabihf/#PRIVATE#
+
+interest-await /usr/include/nvml.h
diff --git a/debian/rules b/debian/rules
index 6c291a1f..d87de133 100755
--- a/debian/rules
+++ b/debian/rules
@@ -138,9 +138,9 @@ debian/nv-readme.ids: debian/nv-readme.ids.common 
debian/nv-readme.ids.$(DEB_HOS
cat $^ | sort -u > $@
 
 nv-readme.ids: unpack-stamp debian/nv-readme.ids
-   sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*  
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\} 
\([0-9a-fA-F]\{4\}\) .*/10de\1/p};d' \
+   sed -r  -e '0,/A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/Appendix A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/^Below|APPENDIX B/{/ 0x/s/.*  
0x([0-9a-fA-F]{4}).*/10de\1/p; 

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

On 2021-04-28 20:34:26, Lev Lamberov wrote:
> It makes it a bit trickier. There another package, elpa-bug-hunter
> [elpa-bug-hunter], which automatically debug and bisect your init.el or
> .emacs file. It may be worth t try it with your config.
>
> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter

Actually, do you know how I would use bug-hunter and esup together? It
seems they *both* start a separate emacs process to debug the startup,
and thus would be in conflict with each other...

a.

-- 
There has been only one Christian.
They caught him and crucified him -- early.
- Mark Twain

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

On 2021-04-28 20:34:26, Lev Lamberov wrote:
> Ср 28 апр 2021 @ 08:50 Antoine Beaupré :
>
>> Control: severity -1 normal
>>
>> On 2021-04-28 09:00:46, Lev Lamberov wrote:
>>> Hi Antoine,
>>>
>>> Вт 27 апр 2021 @ 13:53 Antoine Beaupre :
>>> I have elpa-esup installed for a long time and I cannot reproduce the
>>> bug on my machine. Running esup starts another GNU Emacs session and
>>> gives me a proper report on startup like the following excerpt:
>>
>> Oh interesting! Maybe that's why it works, since the bytecode is older?
>
> Well, each update of GNU Emacs and at least sometimes updates of dh-elpa
> trigger recompilation of all installed packages. On my machine file
> /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup.elc starts with
>
> ```
> ;ELC^W^@^@^@
> ;;; Compiled
> ;;; in Emacs version 27.1
> ;;; with all optimizations.
> ```
>
> That is, it was recompiled at least with installation of GNU Emacs 27.1,
> which was first uploaded to unstable on 2020-10-24, but I still remember
> that there were more recompilation of all installed packages recently
> (probably, even on 2021-04-07 when Emacs 1:27.1+1-3.1 entered testing).

Mine says the same.

[...]

>>> So, may it be a bug in dh-elpa or GNU Emacs itself?
>>
>> Maybe! This is way beyond my elisp-fu unfortunately.
>>
>> One key information I have just discovered is that I can't reproduce
>> with `emacs -q`. So this is probably an interaction with my .emacs.d
>> configuration and the package, unfortunately. Downgrading severity.
>
> It makes it a bit trickier. There another package, elpa-bug-hunter
> [elpa-bug-hunter], which automatically debug and bisect your init.el or
> .emacs file. It may be worth t try it with your config.
>
> [elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter

Thanks, I'll try that next.

-- 
Never attribute to malice that which can be adequately explained by
stupidity, but don't rule out malice.
 - Albert Einstein

Bug#987725: buster-pu: package nvidia-graphics-drivers/418.197.02-1

[Andreas Beckmann]

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

Hi,

let's fix CVE-2021-1076 by updating the non-free nvidia-graphics-drivers
in buster to a new upstream release.
This driver version is in sid and bullseye available as
src:nvidia-graphics-drivers-tesla-418

There is an additional packaging change: the creation of the missing
libnvidia-ml.so symlink.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 154072b1..d50a7005 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+nvidia-graphics-drivers (418.197.02-1) buster; urgency=medium
+
+  * New upstream Tesla release 418.197.02 (2021-04-19).
+* Fixed CVE-2021-1076.  (Closes: #987216)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+
+  [ Andreas Beckmann ]
+  * nvidia-alternative: Add libnvidia-ml.so slave alternative if
+libnvidia-ml-dev is installed (460.56-2).  (Closes: #984881)
+
+ -- Andreas Beckmann   Tue, 20 Apr 2021 15:01:59 +0200
+
 nvidia-graphics-drivers (418.181.07-1) buster; urgency=medium
 
   * New upstream Tesla release 418.181.07 (2021-01-19).
@@ -607,6 +619,19 @@ nvidia-graphics-drivers (396.18-1) experimental; 
urgency=medium
 
  -- Andreas Beckmann   Sun, 22 Apr 2018 13:59:45 +0200
 
+nvidia-graphics-drivers (390.143-1) UNRELEASED; urgency=medium
+
+  * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076.
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+  when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+  candidates, where the NVIDIA kernel module failed to build with error
+  "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann   Mon, 19 Apr 2021 22:38:56 +0200
+
 nvidia-graphics-drivers (390.141-1) UNRELEASED; urgency=medium
 
   * New upstream legacy branch release 390.141 (2021-01-07).
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 0a0335ac..8eef27fc 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,5 +1,5 @@
 d821215e307c351bf49071c22198c3cf  debian/control
 e4f873e158ee77960509ee7b1737f5ae  debian/control.in
 db12f898b07cdaf431ad34bd68a1662e  debian/gen-control.pl
-cd0f1042158bc0093df3bde0a9f851b2  debian/rules
+bdecb50e210cbb969730b9369509aaed  debian/rules
 c461274a68eab2da346c5d34d32f2485  debian/rules.defs
diff --git a/debian/nvidia-alternative.postinst.in 
b/debian/nvidia-alternative.postinst.in
index 1069caa7..8f6bc805 100644
--- a/debian/nvidia-alternative.postinst.in
+++ b/debian/nvidia-alternative.postinst.in
@@ -82,10 +82,14 @@ if [ "$1" = "triggered" ]; then
$(add_slave /etc/nvidia/nvidia-modprobe.conf 
nvidia-modprobe.conf /etc/#PRIVATE#/nvidia-modprobe.conf)
$(add_slave /etc/nvidia/nvidia-load.conf nvidia-load.conf 
/etc/#PRIVATE#/nvidia-load.conf)
 "
+   libnvidia_ml_so_slave=
+   if [ -f /usr/include/nvml.h ]; then
+   libnvidia_ml_so_slave="$(add_multiarch_slave /usr/lib "" 
libnvidia-ml.so /usr/lib #PRIVATE#/)"
+   fi
if echo "$slaves" | grep -q "slave" ; then
-   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves
+   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave
# work around #916799 and re-register the alternative to 
clean-up leftover slaves
-   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves
+   update-alternatives --install /usr/lib/nvidia/nvidia nvidia 
/usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave
else
update-alternatives --remove nvidia /usr/lib/#PRIVATE#
fi
diff --git a/debian/nvidia-alternative.triggers.in 
b/debian/nvidia-alternative.triggers.in
index 153c0e6a..e4886029 100644
--- a/debian/nvidia-alternative.triggers.in
+++ b/debian/nvidia-alternative.triggers.in
@@ -4,3 +4,5 @@ interest-await /etc/#PRIVATE#
 interest-await /usr/lib/#PRIVATE#
 interest-await /usr/lib/i386-linux-gnu/#PRIVATE#
 interest-await /usr/lib/x86_64-linux-gnu/#PRIVATE#
+
+interest-await /usr/include/nvml.h
diff --git a/debian/rules b/debian/rules
index 5f8236c2..2c24bc17 100755
--- a/debian/rules
+++ b/debian/rules
@@ -169,9 +169,9 @@ nonglvnd/nvidia_icd.json: $(nvidia_icd.json.template)
sed 's/__NV_VK_ICD__/libGL.so.1/' $< > $@
 
 nv-readme.ids: unpack-stamp
-   sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*  
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\} 
\([0-9a-fA-F]\{4\}\) 

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Sun, 2021-04-25 at 22:02 +0200, Cyril Brulebois wrote:
> but it seems the experimental uploads weren't fetched for some reason
> (I only glanced at git, didn't check what happened on the archive
> side).
> 
> Since the problem is about the dependency between the udeb and one of
> the library from the same package, a possibly easy fix could be to
> just
> ship the contents of the said library inside the udeb, along with the
> current contents.
> 
> That'd probably be about adjusting a .install file as opposed to
> adding
> a dedicated library udeb that would need some care for SONAME bumps,
> etc. (plus NEW of course).


That's an explicit dependency that got added in the merge I reviewed
for 2.1.2.

Why not just drop the dependency on udev and libopeniscsiusr entirely,
for the open-iscsi-udeb package ?

If you agree, then I can prepare an upload just dropping these.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Gard Spreemann  writes:

> Andreas Tille  writes:
>
>> Hi Aaron,
>>
>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
>>> Please try adding a build dependency on libclfft-dev and replacing
>>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
>>> to
>>> 
>>>   find_package(clFFT)
>>> 
>>> > Thanks a lot for your initial hint
>>
>> Thanks again.  I now tried to learn from this and added a similar patch
>> for CLBLast[1] but as you can see in the new log[2] it is not that
>> simple.  I tried to compare the content of
>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
>> like and I need to admit I have no idea why this fails.
>
> This seems to be just a typo on my part. The logs have
>
> ***
> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
>   By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "CLBLast", but
>   CMake did not find one.
>   Could not find a package configuration file provided by "CLBLast" with any
>   of the following names:
> CLBLastConfig.cmake
> clblast-config.cmake
>   Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
>   "CLBLast_DIR" to a directory containing one of the above files.  If
>   "CLBLast" provides a separate development package or SDK, be sure it has
>   been installed.
> ***
>
> libclblast-dev ships
>
>  /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake
>
> Notice that there's both "CLBLast" and "CLBlast" in there! I'll
> investigate.

Looks like an upstream bug; consider the inconsistent capitalization of
the second l in "clblast" online 363 in

 
https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363

I'll report it upstream and patch src:clblast.


 Best,
 Gard

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

Ср 28 апр 2021 @ 08:50 Antoine Beaupré :

> Control: severity -1 normal
>
> On 2021-04-28 09:00:46, Lev Lamberov wrote:
>> Hi Antoine,
>>
>> Вт 27 апр 2021 @ 13:53 Antoine Beaupre :
>> I have elpa-esup installed for a long time and I cannot reproduce the
>> bug on my machine. Running esup starts another GNU Emacs session and
>> gives me a proper report on startup like the following excerpt:
>
> Oh interesting! Maybe that's why it works, since the bytecode is older?

Well, each update of GNU Emacs and at least sometimes updates of dh-elpa
trigger recompilation of all installed packages. On my machine file
/usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup.elc starts with

```
;ELC^W^@^@^@
;;; Compiled
;;; in Emacs version 27.1
;;; with all optimizations.
```

That is, it was recompiled at least with installation of GNU Emacs 27.1,
which was first uploaded to unstable on 2020-10-24, but I still remember
that there were more recompilation of all installed packages recently
(probably, even on 2021-04-07 when Emacs 1:27.1+1-3.1 entered testing).

>> ```
>> Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total 
>> GC Time: 0.065sec
>>
>> package.elc:16  0.134sec   37%
>> (byte-code "\301\302!\210\301\303!\210 [...]
>> ```
>>
>> I wonder how recompiling could fix the problem you face, since
>> installing/reinstalling the package or GNU Emacs itself should trigger
>> recompilation of it along with all other installed Emacs packages.
>
> Yeah, as I said I haven't tried to recompile myself, that's just what
> the upstream bug report says. If anything, maybe it's the opposite and
> if *you* recompile you'll trigger the bug? No idea.

I've tried to reinstall elpa-esup, which caused recompilation and still
I cannot reproduce your bug both with my config and with emacs -q.

>> So, may it be a bug in dh-elpa or GNU Emacs itself?
>
> Maybe! This is way beyond my elisp-fu unfortunately.
>
> One key information I have just discovered is that I can't reproduce
> with `emacs -q`. So this is probably an interaction with my .emacs.d
> configuration and the package, unfortunately. Downgrading severity.

It makes it a bit trickier. There another package, elpa-bug-hunter
[elpa-bug-hunter], which automatically debug and bisect your init.el or
.emacs file. It may be worth t try it with your config.

[elpa-bug-hunter] https://tracker.debian.org/pkg/elisp-bug-hunter

Cheers!
Lev

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Andreas Tille  writes:

> Hi Aaron,
>
> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
>> Please try adding a build dependency on libclfft-dev and replacing
>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
>> to
>> 
>>   find_package(clFFT)
>> 
>> > Thanks a lot for your initial hint
>
> Thanks again.  I now tried to learn from this and added a similar patch
> for CLBLast[1] but as you can see in the new log[2] it is not that
> simple.  I tried to compare the content of
> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
> like and I need to admit I have no idea why this fails.

This seems to be just a typo on my part. The logs have

***
CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
  By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "CLBLast", but
  CMake did not find one.
  Could not find a package configuration file provided by "CLBLast" with any
  of the following names:
CLBLastConfig.cmake
clblast-config.cmake
  Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
  "CLBLast_DIR" to a directory containing one of the above files.  If
  "CLBLast" provides a separate development package or SDK, be sure it has
  been installed.
***

libclblast-dev ships

 /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake

Notice that there's both "CLBLast" and "CLBlast" in there! I'll
investigate.

 Best,
 Gard

Bug#949767: arrayfire update fails in configure step

[Andreas Tille]

Hi Aaron,

On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
> Please try adding a build dependency on libclfft-dev and replacing
> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
> to
> 
>   find_package(clFFT)
> 
> > Thanks a lot for your initial hint

Thanks again.  I now tried to learn from this and added a similar patch
for CLBLast[1] but as you can see in the new log[2] it is not that
simple.  I tried to compare the content of
libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
like and I need to admit I have no idea why this fails.

Kind regards

Andreas.


[1] 
https://salsa.debian.org/science-team/arrayfire/-/blob/master/debian/patches/use_debian_packaged_libs.patch#L64
[2] https://salsa.debian.org/science-team/arrayfire/-/jobs/1611074#L1602

-- 
http://fam-tille.de

Bug#966294: Fwd: Processed: Re: #966294: asterisk: memory leak with PJSIP channel

[José Miguel Gonçalves]

Hi,

I'm currently using the asterisk build from buster-backports (16.16.1) 
and the leak does not happen on it.


Best regards,
José Gonçalves

Bug#987671: gnome-disk-utility: User could possibly format the hard disk without giving any password : Observation

[pascal martine]

 

Dear Maintainer,

 

I re-tested that bug and observing the process more closely, I saw that when the software (gnome-disk-utility) asks us for authentification (password), we just have time to see that behind the gnome box asking for the password, gnome-disk-utility seems to have already begun his process of formatting the USB stick (progression bar showing).

I really mean that the software seems to begin to format BEFORE having received confirmation+password. As if the user would never cancel the process at the last step : change of mind, forgetting the password, not being the right user, a child playing with the PC, whatever.

And so the USB is formatted everytime, whatever you do, if you go so far as this authentification/password box.

Remark : It is quick (instant) and simple formatting with no partition creation.

 

Imagine the disaster for the user if he wrongly chose the HDD instead of USB. Even after realising his mistake & cancelling at the last moment, the Hard Disk would be formatted anyway.

 

If the problem/bug is just giving the right order to the process, it would apparently not be difficult to repair/debug. Just begin the formatting+copying AFTER full confirmation+password from the user. But I imagine one has to consider the whole scheme/picture about this software.

 

Cordially,

Pascal.

 

Bug#966294: Fwd: Processed: Re: #966294: asterisk: memory leak with PJSIP channel

[Bernhard Schmidt]

Forgot to Cc the bug ...

Hi Chris,

hrm, Jose reported this issue appearing with the stable release only
(16.16.1 from his (back then) private backport fixing it), you tagged
the bug as still found in 16.16.1, and I cannot see this issue at all.

Unfortunately I don't know what to do with this bug.

Bernhard

Bug#987722: Segmentation fault at address 0x0 in 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5645ba71bb39]

[Erik Thiele]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1

lspci sais:
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev 
a2)


sometimes after some days, but again and again the Xserver crashes.
this is seen in the Xorg.log:

[627670.969] (EE) 
[627670.989] (EE) Backtrace:
[627671.046] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5645ba71bb39]
[627671.047] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7ff8193d877f]
[627671.242] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x250ae0) [0x7ff817b6bff0]
[627671.243] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x27239a) [0x7ff817bafe4a]
[627671.245] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x35f1e3) [0x7ff817d89d43]
[627671.246] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x27384f) [0x7ff817bb26bf]
[627671.247] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x273c62) [0x7ff817bb3312]
[627671.260] (EE) 7: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0x10619) [0x7ff8183cee39]
[627671.262] (EE) 8: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0xc9dc) [0x7ff8183c75ec]
[627671.263] (EE) 9: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_create_gc+0xccb7) [0x7ff8183c7d47]
[627671.263] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_finish+0xcf4) [0x7ff8183adca4]
[627671.264] (EE) 11: /usr/lib/xorg/Xorg (miCopyRegion+0x96) [0x5645ba6f9586]
[627671.264] (EE) 12: /usr/lib/xorg/Xorg (miDoCopy+0x476) [0x5645ba6f9c76]
[627671.265] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_finish+0x1870) [0x7ff8183af430]
[627671.266] (EE) 14: /usr/lib/xorg/Xorg (DamageRegionAppend+0x3726) 
[0x5645ba6a3846]
[627671.266] (EE) 15: /usr/lib/xorg/Xorg (SendGraphicsExpose+0x4ff) 
[0x5645ba5b8a9f]
[627671.267] (EE) 16: /usr/lib/xorg/Xorg (SendErrorToClient+0x35e) 
[0x5645ba5bc9fe]
[627671.267] (EE) 17: /usr/lib/xorg/Xorg (InitFonts+0x3b6) [0x5645ba5c09c6]
[627671.268] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) 
[0x7ff81922709b]
[627671.268] (EE) 19: /usr/lib/xorg/Xorg (_start+0x2a) [0x5645ba5aa67a]
[627671.268] (EE) 
[627671.268] (EE) Segmentation fault at address 0x0
[627671.268] (EE) 
Fatal server error:
[627671.269] (EE) Caught signal 11 (Segmentation fault). Server aborting
[627671.269] (EE) 
[627671.277] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[627671.277] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[627671.277] (EE) 
[627671.278] (II) AIGLX: Suspending AIGLX clients for VT switch
[627671.319] (EE) Server terminated with error (1). Closing log file.



cu
erik

Bug#987273: CVE-2021-21783

[Moritz Mühlenhoff]

Am Wed, Apr 21, 2021 at 12:03:59PM +0200 schrieb Mattias Ellert:
> tis 2021-04-20 klockan 20:32 +0200 skrev Moritz Muehlenhoff:
> > Package: libgsoap-2.8.104
> > Version: 2.8.104-2
> > Severity: important
> > File: gsoap
> > Tags: security
> > X-Debbugs-Cc: Debian Security Team 
> > 
> > This was assigned CVE-2021-21783:
> > https://talosintelligence.com/vulnerability_reports/TALOS-2021-1245
> > 
> > Cheers,
> >     Moritz  
> 
> Hi Moritz.
> 
> I can not fully comprehend this bug report.
> 
> If I read the CVE-2021-21783 report, it basically says:
> 
>   We have noticed that the vulnerability we previously reported
>   (CVE-2020-13576) was not fixed. We have therefore resubmitted it.
>   We have investigated the following versions:
> 
>   Genivia gSOAP 2.8.109
>   Genivia gSOAP 2.8.110
> 
> However, the fix for CVE-2020-13576 was in gSOAP 2.8.111, so that this
> was still present in the two tested versions is expected.
> 
> The page for previous CVE-2020-13576 does claim that it was fixed in an
> upstream release on 2020-11-20, which corresponds to version 2.8.109.
> 
> I do not think this statement is correct. From my understanding of
> comparing the reported fault (including code snippets) with the changes
> to the source repository, I understand it to have been fixed in version
> 2.8.111, and not in 2.8.109 as the report claims. Since the reported
> fixed version in incorrect I can see why it was reported again.
> 
> I think the reason for the wrong fixed version in the previous report
> is that the other 4 CVEs reported against gsoap at the same time
> (CVE-2020-13574, CVE-2020-13575, CVE-2020-13577 and CVE-2020-13578)
> were indeed fixed in version 2.8.109. So someone might just put the
> same fixed date on all 5 reports.
> 
> The fix for CVE-2020-13576 from version 2.8.111 is already applied as a
> patch in the debian package version gsoap/2.8.104-3. And if this new
> CVE is indeed a duplicate there is nothing more to fix.

Thanks, I agreed with what you summarised. This seems like an error at
TALOS. Probably the CVE should be rejected entirely, but for now I'll
simply mark it as a non-issue in the Debian Security Tracker.

Cheers,
Moritz

Bug#966294: #966294: asterisk: memory leak with PJSIP channel

[Chris Hofstaedtler]

Control: tags -1 + confirmed

I also see this problem, unfortunately.

Bug#986215: scrollz: CVE-2021-29376

[Tobias Frost]

Source: scrollz
Followup-For: Bug #986215
Control: tags -1 patch

Fixed upstream with commit: 
https://github.com/ScrollZ/ScrollZ/pull/26/commits/1155969d24e063b6d0b7e08b9b0c4ea8623f92ce

Bug#987721: ITP: ruby-ssrf-filter -- prevent server side request forgery (SSRF) attacks

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Debian packaging of https://rubygems.org/gems/ssrf_filter

Required for ruby-carrierwave 1.3.2

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

Control: severity -1 normal

On 2021-04-28 09:00:46, Lev Lamberov wrote:
> Hi Antoine,
>
> Вт 27 апр 2021 @ 13:53 Antoine Beaupre :
>
>> Package: elpa-esup
>> Version: 0.7.1-3
>> Severity: grave
>> Tags: upstream
>>
>> This package is unusable in Debian 11 bullseye in its current
>> state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get:
>>
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> *Messages* has this:
>>
>> Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el 
>> (source)...done
>> Starting esup...
>> esup process started on port 37851
>> at 1
>> error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
>> class), nil, obj
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> This is the upstream bug: https://github.com/jschaf/esup/issues/85
>>
>> It looks like it is a packaging issue, since, according to the above
>> bug report, recompiling the .el files fixes the problem (haven't tested).
>
> Thanks for reporting, investigating and forwarding!
>
> Is it a fresh install of elpa-esup?

Yes, installed from the Debian package in Bullseye.

> I have elpa-esup installed for a long time and I cannot reproduce the
> bug on my machine. Running esup starts another GNU Emacs session and
> gives me a proper report on startup like the following excerpt:

Oh interesting! Maybe that's why it works, since the bytecode is older?

> ```
> Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total 
> GC Time: 0.065sec
>
> package.elc:16  0.134sec   37%
> (byte-code "\301\302!\210\301\303!\210 [...]
> ```
>
> I wonder how recompiling could fix the problem you face, since
> installing/reinstalling the package or GNU Emacs itself should trigger
> recompilation of it along with all other installed Emacs packages.

Yeah, as I said I haven't tried to recompile myself, that's just what
the upstream bug report says. If anything, maybe it's the opposite and
if *you* recompile you'll trigger the bug? No idea.

[...]

> So, may it be a bug in dh-elpa or GNU Emacs itself?

Maybe! This is way beyond my elisp-fu unfortunately.

One key information I have just discovered is that I can't reproduce
with `emacs -q`. So this is probably an interaction with my .emacs.d
configuration and the package, unfortunately. Downgrading severity.

a.

-- 
While the creative works from the 16th century can still be accessed
and used by others, the data in some software programs from the 1990s
is already inaccessible.
 - Lawrence Lessig

Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

[Cyril Brulebois]

Hi Étienne,

Étienne Mollier  (2021-04-28):
> According to my observations, I does help with all the known bad
> cases I have hit so far; I notably double checked the "Generic"
> partition schemes:
> 
>   Device   en_US  fr_FR
>   /dev/sdb1ok ok
>   /dev/nvme0n1p1   ok ok
>   /dev/md/0ok ok
>   /dev/debian-vg/root  ok ok

\o/ \o/ \o/

> Just in case, the mini ISOs never booted EFI, and I never
> managed to get the ZBook to Bios boot USB thumbs.  So I had to
> carry out the NVMe test in a virtual machine to get some working
> Bios boot, and use PCI host passthrough on the second NVMe of
> the machine, to get it to be visible to the installer and rescue
> environment.  I don't believe it affected much the test results,
> but fyi, just in case it turned out it would make a difference.

Thanks for mentioning it.

> You're welcome, I hope the the above is reassuring.

It definitely is! We “just” need to find a proper fix now…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

[Étienne Mollier]

Hi Cyril,

Cyril Brulebois, on 2021-04-28 06:08:30 +0200:
> Let's see if this helps!
>   https://people.debian.org/~kibi/bug-987377/

According to my observations, I does help with all the known bad
cases I have hit so far; I notably double checked the "Generic"
partition schemes:

  Device   en_US  fr_FR
  /dev/sdb1ok ok
  /dev/nvme0n1p1   ok ok
  /dev/md/0ok ok
  /dev/debian-vg/root  ok ok

Just in case, the mini ISOs never booted EFI, and I never
managed to get the ZBook to Bios boot USB thumbs.  So I had to
carry out the NVMe test in a virtual machine to get some working
Bios boot, and use PCI host passthrough on the second NVMe of
the machine, to get it to be visible to the installer and rescue
environment.  I don't believe it affected much the test results,
but fyi, just in case it turned out it would make a difference.

> Also, thanks for all the tests so far, I've seen the follow-ups… that's
> much appreciated (even if slightly frightening if the image linked above
> doesn't make the problem go away altogether).

You're welcome, I hope the the above is reassuring.

Have a nice day,  :)
-- 
É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#987712: hashed apps (x apps) with Gnome / wayland.

[Y]

Package: gnome
Version: 1:3.38+3
Severity: important
X-Debbugs-Cc: robin.verdenal-talli...@laposte.net




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.17-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-5
ii  cheese   3.38.0-3
ii  cups-pk-helper   0.2.6-1+rpi1
ii  desktop-base 11.0.3
ii  evolution3.38.3-1
ii  evolution-plugins3.38.3-1
ii  file-roller  3.38.0-1
ii  gedit-plugins3.38.1-1
ii  gnome-calendar   3.38.2-1
ii  gnome-clocks 3.38.0-1
ii  gnome-color-manager  3.36.0-1
ii  gnome-core   1:3.38+3
ii  gnome-documents  3.34.0-2
ii  gnome-getting-started-docs   3.38.0-1
ii  gnome-maps   3.38.2-1
ii  gnome-music  3.36.7-1
ii  gnome-screenshot 3.38.0-1
ii  gnome-sound-recorder 3.38.0-3
ii  gnome-todo   3.28.1-6
ii  gnome-tweaks 3.34.0-4
ii  gnome-weather3.36.1-1
ii  gstreamer1.0-libav   1.18.3-1
ii  gstreamer1.0-plugins-ugly1.18.3-1
ii  libgsf-bin   1.14.47-1
ii  libproxy1-plugin-networkmanager  0.4.17-1
ii  libreoffice-calc 1:7.0.4-3
ii  libreoffice-gnome1:7.0.4-3
ii  libreoffice-impress  1:7.0.4-3
ii  libreoffice-writer   1:7.0.4-3
ii  network-manager-gnome1.20.0-3
ii  orca 3.38.2-1
ii  rhythmbox3.4.4-4
ii  rhythmbox-plugin-cdrecorder  3.4.4-4
ii  rhythmbox-plugins3.4.4-4
ii  rygel-playbin0.40.0-1
ii  rygel-tracker0.40.0-1
ii  seahorse 3.38.0.1-2
ii  shotwell 0.30.11-1
ii  simple-scan  3.38.1-1
ii  totem-plugins3.38.0-2
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.38+3
ii  gnome-remote-desktop0.1.9-5
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk3.00-1

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  goobox | sound-juicer
pn  polari   
pn  vinagre  
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.38.0-1
ii  at-spi2-core  2.38.0-2
ii  baobab3.38.0-1
ii  caribou   0.4.21-7.1
ii  chromium  89.0.4389.114-1
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  eog   3.38.2-1
ii  epiphany-browser  3.38.2-1
ii  evince3.38.2-1
ii  evolution-data-server 3.38.3-1
ii  firefox-esr   78.10.0esr-1
ii  fonts-cantarell   0.111-3
ii  gdm3  3.38.2.1-1
ii  gedit 3.38.1-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.66.0-2
ii  gnome-backgrounds 3.38.0-1
ii  gnome-bluetooth   3.34.3-2
ii  gnome-calculator  3.38.2-1
ii  gnome-characters  3.34.0-1
ii  gnome-contacts3.38.1-1+b1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-disk-utility3.38.2-1
ii  gnome-font-viewer 3.34.0-2+b1
ii  gnome-keyring 3.36.0-1
ii  gnome-logs3.36.0-2
ii  gnome-menus   3.36.0-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-online-miners   3.34.0-2
ii  gnome-session 3.38.0-4
ii  gnome-settings-daemon 3.38.1-3
ii  gnome-shell   3.38.4-1
ii  gnome-shell-extensions3.38.2-1
ii  gnome-software3.38.1-1
ii  gnome-sushi   3.38.0-1
ii  gnome-system-monitor  3.38.0-1
ii  gnome-terminal3.38.3-1
ii  gnome-themes-extra3.28-1
ii  gnome-user-docs   3.38.2-1
ii  gnome-user-share  3.34.0-2
ii  gsettings-desktop-schemas 3.38.0-2
ii  gstreamer1.0-packagekit   1.2.2-2
ii  gstreamer1.0-plugins-base 1.18.3-1
ii  gstreamer1.0-plugins-good 

Bug#944431: Salzburg BSP

[Markus Koschany]

Hi Philip,

thank you for the reminder and the debdiff. Indeed I wanted to fix this issue
in Buster too but it seems I forgot to do it. I have requested a buster-pu
(#987719) and already uploaded the package.

Cheers,

Markus


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

Bug#969463: Stops on big files

[Philipp Marek]

# gdb --args rsync -va --inplace --no-whole-file --progress --stats 
/var/lib/libvirt/images/win10.qcow2 win10.qcow2


went through without any problem.
So either the "--blocksize" is the reason -- or some bit pattern in the 
previous version.


Touching the file and re-trying with checksumming (-c) has nothing to 
copy and so did succeed; I'll try gdb when the file was changed.

Bug#987720: ITP: ksmbd-tools -- cifsd kernel server userspace utilities

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ksmbd-tools
  Version : 0+git20210428
  Upstream Authors: Namjae Jeon 
Sergey Senozhatsky 
* URL : https://github.com/namjaejeon/ksmbd-tools
* License : GPL-2-or-later
  Description : cifsd kernel server userspace utilities
 This is an alternative implementation of the CIFS/SMB3 control 
utilities.