date:20220131


Source: ruby-pygments.rb
Version: 2.3.0+ds-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ruby-pygments.rb the autopkgtest of 
ruby-pygments.rb fails in testing when that autopkgtest is run with the 
binary packages of ruby-pygments.rb from unstable. It passes when run 
with only packages from testing. It fails in the same way in a pure 
unstable environment, so it's not version skew. In tabular form:


   passfail
ruby-pygments.rb   from testing2.3.0+ds-1
all others from testingfrom testing

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

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


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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-pygments.rb

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-pygments.rb/18819910/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby2.7 
   │

└──┘

GEM_PATH= ruby2.7 -e gem\ \"pygments.rb\"

┌──┐
│ Run tests for ruby2.7 from debian/ruby-tests.rake 
   │

└──┘

mv lib ./.gem2deb.lib
RUBYLIB=. GEM_PATH= ruby2.7 -S rake -f debian/ruby-tests.rake
/usr/bin/ruby2.7 -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/test_pygments.rb" -v
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:13:in 
`read': No such file or directory @ rb_sysopen - 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/../lib/pygments/mentos.py 
(Errno::ENOENT)
	from 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:13:in 
`'
	from 
/tmp/autopkgtest-lxc.9r2fsd4_/downtmp/build.ktY/src/test/test_pygments.rb:10:in 
`'
	from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in 
`require'
	from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in 
`require'
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in 
`block in '
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in 
`select'
	from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in 
`'

rake aborted!
Command failed with status (1): [ruby -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/test_pygments.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in 
`'

Tasks: TOP => default
(See full trace by running task with --trace)
mv ./.gem2deb.lib lib
autopkgtest [01:10:58]: test gem2deb-test-runner



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004702: libtorrent-rasterbar: b-d on python3-all-dev, but not built for all supported Python3 versions

2022-01-31 Thread Graham Inggs

Source: libtorrent-rasterbar
Version: 2.0.5-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10 python3-all-dev

Hi Maintainer

This package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions.  This is seen
on the transition tracker for adding python3.10 support [1] and
creates false positives.

Please either replace the b-d python3-all-dev with python3-dev, or
build for all supported Python3 versions.  With the former solution
yet get later exposure to a new python3 version, with the latter
solution you get early exposure.

Regards
Graham


[1] https://release.debian.org/transitions/html/python3.10-add.html

Bug#1004701: ima-evm-utils: Backport for bullseye

2022-01-31 Thread Bastian Germann


Source: ima-evm-utils
Version: 1.4-1.2
Severity: wishlist

Please provide a bullseye-backport for the current ima-evm-utils version, which has significant feature additions to 
1.1-1 in bullseye. I can offer to upload a backport (as you cannot upload to the NEW queue).

Bug#1004700: barcode man page: undocumented encoding types

2022-01-31 Thread Jakub Wilk


Package: barcode
Version: 0.99-5

The barcode manual page says:

To get a list of supported encoding type names, please call the program 
with "-h" option.


Please document the encoding types directly in the manual page.

--
Jakub Wilk

Bug#1004699: libdigest-bcrypt-perl breaks libdancer2-plugin-passphrase-perl autopkgtest: Bcrypt needs encoded text


Source: libdigest-bcrypt-perl, libdancer2-plugin-passphrase-perl
Control: found -1 libdigest-bcrypt-perl/1.212-1
Control: found -1 libdancer2-plugin-passphrase-perl/3.3.4-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libdigest-bcrypt-perl the autopkgtest of 
libdancer2-plugin-passphrase-perl fails in testing when that autopkgtest 
is run with the binary packages of libdigest-bcrypt-perl from unstable. 
It passes when run with only packages from testing. In tabular form:


  passfail
libdigest-bcrypt-perl from testing1.212-1
libdancer2-plugin-passphrase-perl from testing3.3.4-1
all othersfrom testingfrom testing

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

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


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

Paul

[1] https://qa.debian.org/excuses.php?package=libdigest-bcrypt-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libd/libdancer2-plugin-passphrase-perl/18819128/log.gz

t/001_basics.t .. 1..1
ok 1 - use Dancer2::Plugin::Passphrase;
ok
t/003_default_settings.t  1..3
ok 1 - RFC compliant hash generated
ok 2 - Match plaintext to hash
ok 3 - Incorrect passwords should be rejected
ok
t/004_all_algorithm_matching.t .. 1..26
ok 1 - With Salt - Match plaintext to hash => MD5
ok 2 - With Salt - Incorrect passwords should be rejected => MD5
ok 3 - With Salt - Match plaintext to hash => SHA-1
ok 4 - With Salt - Incorrect passwords should be rejected => SHA-1
ok 5 - With Salt - Match plaintext to hash => SHA-224
ok 6 - With Salt - Incorrect passwords should be rejected => SHA-224
ok 7 - With Salt - Match plaintext to hash => SHA-256
ok 8 - With Salt - Incorrect passwords should be rejected => SHA-256
ok 9 - With Salt - Match plaintext to hash => SHA-384
ok 10 - With Salt - Incorrect passwords should be rejected => SHA-384
ok 11 - With Salt - Match plaintext to hash => SHA-512
ok 12 - With Salt - Incorrect passwords should be rejected => SHA-512
ok 13 - With Salt - Match plaintext to hash => Bcrypt
ok 14 - With Salt - Incorrect passwords should be rejected => Bcrypt
ok 15 - No Salt - Match plaintext to hash => MD5
ok 16 - No Salt - Incorrect passwords should be rejected => MD5
ok 17 - No Salt - Match plaintext to hash => SHA-1
ok 18 - No Salt - Incorrect passwords should be rejected => SHA-1
ok 19 - No Salt - Match plaintext to hash => SHA-224
ok 20 - No Salt - Incorrect passwords should be rejected => SHA-224
ok 21 - No Salt - Match plaintext to hash => SHA-256
ok 22 - No Salt - Incorrect passwords should be rejected => SHA-256
ok 23 - No Salt - Match plaintext to hash => SHA-384
ok 24 - No Salt - Incorrect passwords should be rejected => SHA-384
ok 25 - No Salt - Match plaintext to hash => SHA-512
ok 26 - No Salt - Incorrect passwords should be rejected => SHA-512
ok
t/005_random_passphrase.t ... 1..3
ok 1 - Basic password generation
ok 2 - Custom password length
ok 3 - Custom chracter set
ok
t/006_return_object.t ... 1..20
ok 1 - An object of class 'Dancer2::Plugin::Passphrase::Hashed' isa 
'Dancer2::Plugin::Passphrase::Hashed'

ok 2 - Contains RFC 2307 representation
ok 3 - Contains correct scheme
ok 4 - Contains correct cost
ok 5 - Contains raw salt
ok 6 - Contains hex hash
ok 7 - Contains base64 hash
ok 8 - Contains raw salt
ok 9 - Contains hex salt
ok 10 - Contains base64 salt
ok 11 - Contains correct plaintext
ok 12 - Extracted raw salt is the same as the defined raw salt
ok 13 - Extracted base64 salt is the same as the defined base64 salt
ok 14 - Extracted hex salt is the same as the defined hex salt
ok 15 - Extracted raw hash is the same as the defined raw hash
ok 16 - Extracted base64 hash is the same as the defined base64 hash
ok 17 - Extracted hex hash is the same as the defined hex hash
ok 18 - Contains a defined, but empty raw salt
ok 19 - Contains a defined, but empty hex salt
ok 20 - Contains a defined, but empty base64 salt
ok
t/007_no_salt.t . 1..2
ok 1 - Match plaintext to it's pre-computed hash
ok 2 - Match plaintext to it's generated hash
ok
t/008_unicode_matching.t  1..8
ok 1 - UTF8 matches UTF8 for SHA-1
ok 2 - SHA-1 needs encoded text
ok 3 - UTF8 matches UTF8 for SHA-256
ok 4 - SHA-256 needs encoded text
ok 5 - UTF8 matches UTF8 for MD5
ok 6 - MD5 needs encoded text
ok 7 - UTF8 matches UTF8 for Bcrypt
not ok 8 - Bcrypt needs encoded text

#   Failed test 'Bcrypt needs encoded text'
#   at

Bug#1004698: Package: stunnel4

2022-01-31 Thread Andreas Hasenack

Package: stunnel4
Version: 3:5.60+dfsg-1
Severity: normal

Dear Maintainer,

please consider updating stunnel to the latest upstream version, which
is 5.62 at the moment. Of note is that at least version 5.61 is
required to build with openssl 3, which is currently in Debian
Experimental.

Thanks!

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Chris Hofstaedtler

Hello Helmut,

Thank you for the very detailed research (which I have removed
in my reply below).

* Helmut Grohne  [220131 17:09]:
> > #966468 & #982944 asked for rename.ul to return (though the latter rather
> > confuses the removal vs alternatives issue)
> 
> I think it is relatively uncontroversial to return rename.ul in some
> non-essential form. Chris vaguely offered including it in bsdextrautils
> (without a clear plan on how). How about adding rename as
> /usr/bin/rename.ul to bsdextrautils without participating in
> alternatives?
> Would you, Chris, agree to that? I think doing so would
> please some users and reduce the conflict.

With conflict I assume you mean the Conflicts relationship on the
involved packages.
>From a technical perspective: sure, that could be done. I also agree
it avoids new relationships on the involved packages.

> Those people could then ln -s
> /usr/bin/rename.ul /usr/local/bin/rename on their systems. It may not be
> as convenient as installing a package or using update-alternatives, but
> it isn't that hard either.

I believe we (as a distro) should make a choice what /usr/bin/rename
should be, and ship -that-. Today this is prename, with an aborted
effort to make rename.ul possible instead. Given this previous
effort, and some earlier discussion here, I think it is valid to say
"/usr/bin/rename should be rename.ul" - but then it should be that,
and prename should be prename.
Otherwise I would like to keep the status quo: our choice for
/usr/bin/rename is prename.

There are a number of very good "distribution builders" out there,
plus a number of distributions which seem to subscribe to "ship
everything that exists".
I however believe that Debian should make choices, for our users and
in their interest. Shipping both (or maybe all rename-like tools)
and having that user-configurable is IMO not a good technical choice
and IMO also not in the interest of the larger community.

It appears "we" cannot make up our mind about this very small
utility. Why should we delegate this to our users then? If they are
interested, they will sink even more time into it and maybe create a
configuration that possibly causes problems in the future.

Best,
Chris

Bug#1004697: bugs.debian.org: Desktop sometimes fails to respond after idling for long periods

2022-01-31 Thread Sebastian Crane

Package: bugs.debian.org
Severity: important

Dear Maintainer,

I am running a Debian 11 system that I installed on my desktop PC in
October 2021. On three occasions, all within the last month, I have
returned to my desktop after a couple of hours of it idling to find it
unresponsive. When this happens, my two displays cannot detect a signal
and do not find one after being restarted. USB power is still
operational, but peripherals are clearly not communicating with the PC -
the NumLock, CapsLock and ScrollLock status can not be changed and the
'magic' REISUB process doesn't work as it usually does. This issue isn't
related to suspend mode, which I have disabled.

The system is running conventional desktop software; the only 'unusual'
program that was running on all occasions was a Docker daemon.

Here's the output from Neofetch:

seabass@seabass-debian
--
OS: Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 5.10.0-11-amd64
Uptime: 8 mins
Packages: 2843 (dpkg), 18 (flatpak)
Shell: bash 5.1.4
Resolution: 1920x1080, 1920x1080
DE: Xfce 4.16
WM: Xfwm4
WM Theme: Default
Theme: Adwaita [GTK2/3]
Terminal: xfce4-terminal
CPU: Intel i3-3220 (4) @ 3.300GHz
GPU: Intel HD Graphics
Memory: 1979MiB / 15701MiB

I had to force-restart the system by using the motherboard's power
button - explaining the low uptime listed in the data above!
Unfortunately, I cannot reproduce this bug.

Best wishes,

Sebastian

Bug#1004696: barcode man page: undocumented -p, -s

2022-01-31 Thread Jakub Wilk


Package: barcode
Version: 0.99-5

barcode's help message reads:

   -p  page size (refer to the man page)
   -s   streaming mode (refer to the man page)

But there's no additional information in the manual page, besides this:

"Please refer to texinfo doc for more information."

--
Jakub Wilk

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long


Hi YunQiang,

On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
Your package src:gcc-defaults-mipsen has been trying to 
migrate for 62 days [2]. Hence, I am filing this bug.


Any progress? It has been 1.5 months and I haven't seen anything 
happening. This is NOK. gcc-defaults-mipsen is a key package, so I can't 
just remove it. Please ensure the package can migrate. It seems to me 
that your failing to build all kind of required packages, although it's 
not clear if those should come from e.g. gcc-11 (which apparently 
started to build again itself on mipsel and mips64el. I'm not versed 
enough in how this piece of toolchain should work. If you need my help 
as a Release Team member, don't hesitate to reach out, but I don't want 
to spend time on reverse engineering this *.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004695: stunnel4: DEP8 failure with python 3.10

2022-01-31 Thread Andreas Hasenack

Package: stunnel4
Version: 3:5.60+dfsg-1
Severity: normal

Dear Maintainer,

the upcoming python 3.10 deprecates SSL.PROTOCOL_TLS[1]:

Deprecated since version 3.10: TLS clients and servers require
different default settings for secure communication. The generic TLS
protocol constant is deprecated in favor of PROTOCOL_TLS_CLIENT and
PROTOCOL_TLS_SERVER.

This is used in debian/tests/python/struntime/__main__.py:437:[2]

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)

With python3.10, the above line will cause this warning to be printed to stderr:

debian/tests/python/struntime/__main__.py:437: DeprecationWarning:
ssl.PROTOCOL_TLS is deprecated

Which will break the test since `allow-stderr` is not used.

We could, of course, allow stderr, but let's take the opportunity to
fix the warning and not use a deprecated value. Given the context,
this should probably be replaced with PROTOCOL_TLS_CLIENT, but that
brings in another change[3]:

...
The protocol enables CERT_REQUIRED and check_hostname by default.

Namely, the `check_hostname` bit being set to True. And that fails a
test a bit later:

Failed to connect to 127.0.0.1:6503: [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address
mismatch, certificate is not valid for '127.0.0.1'. (_ssl.c:1129)

Since the test certificate only has a commonName of "localhost".

I propose:
a) this patch:
--- a/debian/tests/python/struntime/__main__.py
+++ b/debian/tests/python/struntime/__main__.py
@@ -434,7 +434,7 @@ async def test_connect(cfg: Config, conn:
TestConnection) -> None:
 try:
 if conn.encrypted:
 print(f"[{tag}] Creating an SSL context")
-ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
+ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
 print(f"[{tag}] - cert required")
 ctx.verify_mode = ssl.CERT_REQUIRED
 print(f"[{tag}] - load_verify_locations()")

b) regenerate the test certificate with an extra -addext
"subjectAltName = IP:127.0.0.1". Something like:

openssl req -new -x509 -days 3650 -nodes -out
debian/tests/certs/certificate.pem -keyout debian/tests/certs/key.pem
-addext "subjectAltName = IP:127.0.0.1"


Alternatively, one could set check_hostname to False in the ssl
context, restoring the behavior of the deprecated ssl.PROTOCOL_TLS
value.

Thanks for any comments, and please let me know if you would like to
have a salsa PR with the above.

Cheers!

1. https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS
2. 
https://salsa.debian.org/debian/stunnel/-/blob/master/debian/tests/python/struntime/__main__.py#L437
3. https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS_CLIENT

Bug#996414: python-fastimport: autopkgtest regression: 2 failures + lots of RuntimeError: maximum recursion depth exceeded


Hi Jelmer, all,

On Wed, 13 Oct 2021 21:30:36 +0200 Paul Gevers  wrote:

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


I see that pypy support was dropped, the offending test is when run with 
pypy and uses the dropped pypy-fastimport package. I believe it was just 
an oversight that the test wasn't dropped.


If nobody beats me to it, I'll upload an NMU dropping the pypy based 
autopkgtest in a couple of days.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#334419: wish: "sudo -v command" feature

2022-01-31 Thread Marc Haber

On Wed, Oct 12, 2005 at 11:36:34PM -0700, Karl Chen wrote:
> Currently, "sudo -v" will check the timestamp, and prompt
> for the password if necessary.
> 
> I would like a command "sudo -v command" that will prompt
> for the password only if "sudo command" would prompt for the
> password.  I.e., if the user has NOPASSWD access to that
> command, just exit with a 0 return code without prompting.

Can you check whether the -l option will probably do what you intend to
do?

Greetings
Marc

Bug#990855: sudo: enable python plugin support

2022-01-31 Thread Marc Haber

Hi Mika,

On Fri, Jul 09, 2021 at 03:04:09PM +0200, Michael Prokop wrote:
> since sudo v1.9.0 it's possible to write sudo plugins in Python 3,
> see e.g. https://blog.sudo.ws/posts/2020/01/whats-new-in-sudo-1.9-python/
> 
> This requires to build the package with --enable-python though,
> to provide the according python_plugin.so.

I'd like to give this a shot, at least for experimental. Do you have an
example plugin that I could try and probably even base an autopkgtest
on, maybe with some explanation how I would use it?

Greetings
Marc

Bug#1004694: samba: CVE-2022-0336

Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14950
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2022-0336[0]:
| Samba AD users with permission to write to an account can impersonate
| arbitrary services

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-2022-0336
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0336
[1] https://www.samba.org/samba/security/CVE-2022-0336.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14950

Regards,
Salvatore

Bug#1004693: samba: CVE-2021-44142

Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14914
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-44142[0]:
| Out-of-bounds heap read/write vulnerability in VFS module vfs_fruit
| allows code execution

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-44142
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44142
[1] https://www.samba.org/samba/security/CVE-2021-44142.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14914

Regards,
Salvatore

Bug#1004692: samba: CVE-2021-44141

Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14911
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

The following vulnerability was published for samba.

CVE-2021-44141[0]:
| Information leak via symlinks of existance of files or directories
| outside of the exported share

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-44141
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44141
[1] https://www.samba.org/samba/security/CVE-2021-44141.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14911

Regards,
Salvatore

Bug#1004691: samba: CVE-2021-43566

Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=13979
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-43566[0]:
| All versions of Samba prior to 4.13.16 are vulnerable to a malicious
| client using an SMB1 or NFS race to allow a directory to be created in
| an area of the server file system not exported under the share
| definition. Note that SMB1 has to be enabled, or the share also
| available via NFS in order for this attack to succeed.


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-43566
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43566
[1] https://www.samba.org/samba/security/CVE-2021-43566.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=13979

Regards,
Salvatore

Bug#1004690: samba: CVE-2021-20316

Source: samba
Version: 2:4.13.14+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14842
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.13.13+dfsg-1~deb11u2
Control: found -1 2:4.9.5+dfsg-5+deb10u2

Hi,

The following vulnerability was published for samba.

CVE-2021-20316[0]:
| Symlink race error can allow metadata read and modify outside of the
| exported share.

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-20316
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20316
[1] https://www.samba.org/samba/security/CVE-2021-20316.html
[2] https://bugzilla.samba.org/show_bug.cgi?id=14842

Regards,
Salvatore

Bug#517979: xttitle: titles with umlauts or characters like É cannot be set

2022-01-31 Thread Paulo


Hi, in version 1.1~git20181024.b52256 the bug is fixed.

thanks


On Tue, 03 Mar 2009 11:57:46 +0100 "Axel K. Stammler" 
 wrote:

Package: xttitle
Version: 1.0-5
Severity: important

Even in a "uxterm" the title may only contain 7-bit ASCII characters and are 
cut off at
the first nonconformist character:

$ xttitle "RTÉ Radio 1"

displays only "RT" as the title.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24.4 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xttitle depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries

xttitle recommends no packages.

Versions of packages xttitle suggests:
ii  aterm-ml [x-terminal-em 1.0.1-4  Afterstep XVT - a VT102 emulator f
ii  eterm [x-terminal-emula 0.9.5-1  Enlightened Terminal Emulator
ii  gnome-terminal [x-termi 2.22.3-3 The GNOME 2 terminal emulator appl
ii  konsole [x-terminal-emu 4:3.5.9.dfsg.1-6 X terminal emulator for KDE
ii  kterm [x-terminal-emula 6.2.0-46 Multi-lingual terminal emulator fo
ii  mlterm [x-terminal-emul 2.9.4-5  MultiLingual TERMinal
ii  rxvt [x-terminal-emulat 1:2.6.4-14   VT102 terminal emulator for the X 
ii  rxvt-ml [x-terminal-emu 1:2.6.4-14   multi-lingual VT102 terminal emula
ii  wterm-ml [x-terminal-em 6.2.9-8  lightweight multilingual terminal 
ii  xterm [x-terminal-emula 235-2X terminal emulator


-- debconf-show failed





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004689: xterm: CVE-2022-24130

Source: xterm
Version: 370-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for xterm.

CVE-2022-24130[0]:
| xterm through Patch 370, when Sixel support is enabled, allows
| attackers to trigger a buffer overflow in set_sixel in
| graphics_sixel.c via crafted text.


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-2022-24130
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24130
[1] https://www.openwall.com/lists/oss-security/2022/01/30/2
[3] https://www.openwall.com/lists/oss-security/2022/01/30/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1004688: shadow: Improved version of manual page chfn

2022-01-31 Thread Markus Hiereth

Source: shadow
Version: 4.8.1
Severity: normal

Hi Serge,

attached here, the edited xml file of the manual page and a diff file. In
the first phrase of the description section I introduced/mentioned the
file /etc/passwd to help understanding why we refer to the input data
as "fields". I hope this is OK.

Best regards
Markus

---

"Serge E. Hallyn"  schrieb am 31. Januar 2022 um 05:03

> On Tue, Jan 25, 2022 at 03:47:09PM +0100, Markus Hiereth wrote:
> > Hi Serge,
> > 
> > attached four strings from chfn. There is one error, the others are
> > minor points where things could be improved when eliminating the error in 
> > the xml file for the manpage.
> > 
> > Best regards
> > Markus
> 
> > #MH111 As "real name" is only used once and even the command's description
> > #uses "full name" instead of "real name" and chfn focusses on the GECOS 
> > field:
> > s/real user name and information /full user name and other GECOS data
> 
> Good point, and switching 'real name' for 'full name' seems sensible
> given that 'chfn' (AFAIK) stands for 'change full name' :)
> 
> Many users won't know what GECOS means, so in the command's description
> I'd rather leave it as "and information".

OK

> > #MH170:
> > #Called by any user with the exeption of the system administrator, chfn 
> > expects
> > #authentification with the user's password, therefore: add somewhere 
> > #"A normal user needs to authentficate himself to change personal data."
> > #Called by the system administrator without specifying an account, changes 
> > affect his own account
> > #Called by the system adiminstrator and with a specified username, changes 
> > will affect this users account
> > #FIXME
> > #s/Without options, /Without LOGIN as argument.
> 
> I would prefer "If LOGIN is not specified,"

Just the phrase dealing with no LOGIN has gone up to the section DESCRIPTION

> > #MH
> > #move this paragraph which does not deal with options away from section
> > #OPTIONS towards section DESCRIPTION
> > #: chfn.1.xml:181(para)
> > msgid ""
> > "If none of the options are selected, chfn operates in 
> > an "
> > "interactive fashion, prompting the user with the current values for all of 
> > "
> > "the fields. Enter the new value to change the field, or leave the line 
> > blank "
> > "to use the current value. The current value is displayed between a pair of 
> > "
> > "[ ] marks. Without options, 
> > chfn > "command> prompts for the current user account."
> 
> If you move that, please make it "If no options are specified,"

The rest remained at place with no changes except starting for "If
none of the options IS selected ..." I assumed none needs singular
form of the verb.

http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [

]>

  Julianne Frances
  Haugh
  Creation, 1990

  Thomas
  Kłoczko
  kloc...@pld.org.pl
  shadow-utils maintainer, 2000 - 2007

  Nicolas
  François
  nicolas.franc...@centraliens.net
  shadow-utils maintainer, 2007 - now

chfn
1
User Commands
shadow-utils
_UTILS_VERSION;

chfn
change full user name and information

  chfn

options

LOGIN

DESCRIPTION

  The chfn command changes the user's full name,
  office room number, office phone number, and home phone number information
  for an account in the respective fields of 
/etc/passwd.
  This information is typically printed by

finger1
   and similar programs. A normal user may only change
  the fields for her own account, subject to the restrictions in
  /etc/login.defs. (The default configuration is to
  prevent users from changing their fullname.) The superuser may change
  any field for any account. Additionally, only the superuser may use
  the -o option to change the undefined portions of the
  GECOS field.

  These fields must not contain any colons. Except for the
  other field, they should not contain
  any comma or equal sign. It is also recommended to avoid
  non-US-ASCII characters, but this is only enforced for the phone
  numbers. The other field is used to
  store accounting information used by other applications.

  If LOGIN is not specified, 
chfn
  prompts for the current user account.

OPTIONS

  The options which apply to the chfn command are:

  -f, 
--full-nameFULL_NAME

  Change the user's full name.

  -h, 
--home-phoneHOME_PHONE

  Change the user's home phone number.

  -o, 
--otherOTHER

Change the user's other GECOS information. This field is used to
store accounting information used by other applications, and can

Bug#1004682: src:pure-ftpd: fails to migrate to testing for too long: uploader built arch:all binaries

2022-01-31 Thread Stefan Hornburg (Racke)


On 31/01/2022 19:39, Paul Gevers wrote:

Source: pure-ftpd
Version: 1.0.49-4.1
Severity: serious
Control: close -1 1.0.50-2
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing and 
unstable for more than 60 days as having a Release Critical bug in testing [1]. 
Your package src:pure-ftpd has been trying to migrate for 61 days [2]. Hence, I 
am filing this bug.

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

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

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

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

Paul

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



Hello Paul,

I will do a source-only upload in the next few days. Thanks for the report.

Regards
Racke


--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004686: broker: unnecessary X-Python3-Version field in control file

2022-01-31 Thread Julian Gilbey

Source: broker
Version: 1.4.0+ds1-1
Severity: normal
Tags: patch

This package has the line:

X-Python3-Version: ${python3:Versions}

in debian/control in the binary package python3-broker.  This is
unnecessary: the X-Python3-Version field only has meaning in the
source package section (and in this case, it is not needed there
either).

Patch: remove this line from debian/control.

Best wishes,

   Julian

Bug#1004658: [Pkg-javascript-devel] Bug#1004658: Bug#1004658: Help to compile a wasm package


On 31/01/2022 19:23, Jonas Smedegaard wrote:

Quoting Jan Niehusmann (2022-01-31 18:01:58)

On Mon, Jan 31, 2022 at 05:29:23PM +0100, Geert Stappers wrote:

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
is adviced:

   source-map-mappings should be packaged separately,
   and then build-depended on from package node-source-map.


Would this really solve the issue?


No.

But it would shift the issue from being handled as some asset needed by
a NodeJS module, to being handled as the primary prupose of a Rust
library.



The artifact needed by node-source-map is a WASM binary of
source_map_mappings_wasm_api. What kind of deb package would provide
that file?

The description of source-map-mappings says:
"This is intended to be compiled to WebAssembly and eventually used from
the mozilla/source-map library. This is not a general purpose source
maps library."

It seems to be a integral part of node-source-map, and only
distributed separately because it's written in a different language.

So I wonder if a debian package of source-map-mappings would be useful
at all.

Is this a good reason to include it in the debian source package of
node-source-map?


It might arguably be sensible to package both projects together, if done
in a way that ensured that both parts were treated carefully
(Debian-specific compiler options applied, Debian-specific install paths
used, Debian-specific test tricks applied, etc.).

So mybe if done by a maintainer knowledgeable on both NodeJS and
Rust and bold enough to invent some tooling to compete with pkg-js-tools
and debcargo (because at least debcargo is not fit for use outside the
Rust team).  Personally I do not recommend to reinvent CDBS...

...or that one single package could contain all the custom rules to
handle things correctly *without* custom tooling.  Then the maintainer
would need to keep track of what wisdom evolves in the related unused
tools and reimplement that for this one single package.


No need to do this, the only goal of source-map-mapping is to produce 
mapping.wasm which is then embedded in JS package (package isn't publish 
anywhere else). The job is done (see debian/rules), we just have to find 
the good dependencies and fix the build since built wasm isn't exactly 
what upstream embeds in node-source-map, maybe some unpublished work...

Bug#1004685: openstructure: upgrade failed

2022-01-31 Thread Patrice DUROUX

Package: openstructure
Version: 2.3.1-1
Severity: normal

Dear Maintainer,

Here is what I am facing:

Setting up openstructure (2.3.1-1) ...
dpkg: error processing package openstructure (--configure):
 installed openstructure package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 openstructure
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Thanks,
Patrice

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

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

Versions of packages openstructure depends on:
ii  libboost-filesystem1.74.0   1.74.0-14
ii  libboost-iostreams1.74.01.74.0-14
ii  libboost-program-options1.74.0  1.74.0-14
ii  libc6   2.33-5
ii  libgcc-s1   11.2.0-14
ii  libost-base2.3  2.3.1-1
ii  libost-conop2.3 2.3.1-1
ii  libost-gui2.3   2.3.1-1
ii  libost-io2.32.3.1-1
ii  libost-mol-alg2.3   2.3.1-1
ii  libost-mol2.3   2.3.1-1
ii  libpython3.93.9.10-1
ii  libqt5core5a5.15.2+dfsg-14
ii  libqt5gui5  5.15.2+dfsg-14
ii  libqt5widgets5  5.15.2+dfsg-14
ii  libstdc++6  11.2.0-14
ii  python3 3.9.8-1
ii  python3-ost 2.3.1-1

openstructure recommends no packages.

openstructure suggests no packages.

-- no debconf information

Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Kamil Jońca

David Bauer  writes:

> Hi Andrej
>
> On 1/31/22 18:49, Andrej Shadura wrote:
>> Hi,
>> I have received this bug report for wpa-supplicant 2.10.
>
> Please see this thread [0] and this patch. [1]
>
> [0] http://lists.infradead.org/pipermail/hostap/2022-January/040178.html
> [1] http://lists.infradead.org/pipermail/hostap/2022-January/040185.html
>
> Best
> David
>

Thanks. I can confirm that after applied changes from [1] recompiled 
wpa_supplicant
started to work.

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Bug#1004684: src:ddnet: fails to migrate to testing for too long: FTBFS on armel and mipsel


Source: ddnet
Version: 15.6.2-1
Severity: serious
Control: close -1 15.8.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ddnet has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source on armel and mipsel built there in the past. The error seems to 
be: undefined reference to `__atomic_store_8', which I recollect from 
having seen before in other packages recently so might be a toolchain 
change than requires explicit linking to atomic or something.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004683: gcc-12: cross-no-locale-include.diff no longer applies

2022-01-31 Thread Helmut Grohne

Source: gcc-12
Version: 12-20220126-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

cross-no-locale-include.diff no longer applies, because the target file
cppdefault.c was renamed to cppdefault.cc. This is easily fixed:

sed -i -e 's/cppdefault\.c//' debian/patches/cross-no-locale-include.diff

Helmut

Bug#1004682: src:pure-ftpd: fails to migrate to testing for too long: uploader built arch:all binaries


Source: pure-ftpd
Version: 1.0.49-4.1
Severity: serious
Control: close -1 1.0.50-2
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:pure-ftpd has been trying to migrate for 
61 days [2]. Hence, I am filing this bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004522: debian-policy: Proposing new virtual package: wayland-session

2022-01-31 Thread Andrei POPESCU

On Lu, 31 ian 22, 10:57:04, Stephan Lachnit wrote:
> On Mon, Jan 31, 2022 at 10:38 AM Bill Allombert  wrote:
> >
> > On Mon, Jan 31, 2022 at 10:13:19AM +0100, Stephan Lachnit wrote:
> > >
> > > Actually, just out of curiosity: the folder is called
> > > "wayland-sessions", but the files are all called "*.desktop". Are
> > > there other possibilities than "*.desktop", and if so what is the
> > > difference?
> >
> > .desktop is just a standard file format used to register applications
> > with desktop environment, see
> > 
> 
> Ah thanks! I somehow didn't expect it to be the same as the usual
> .desktop file format as for applications.
> 
> Then I agree on the "wayland-session" name. But maybe the description
> should remove the word "desktop" then.

Well, a more generic option would be "Wayland graphical session", though
it's a bit of a tautology :)

Would "Graphical session using the Wayland display protocol" be too
long?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#1004658: [Pkg-javascript-devel] Bug#1004658: Help to compile a wasm package

2022-01-31 Thread Jonas Smedegaard

Quoting Jan Niehusmann (2022-01-31 18:01:58)
> On Mon, Jan 31, 2022 at 05:29:23PM +0100, Geert Stappers wrote:
> > At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
> > is adviced:
> > 
> >   source-map-mappings should be packaged separately,
> >   and then build-depended on from package node-source-map.
> 
> Would this really solve the issue?

No.

But it would shift the issue from being handled as some asset needed by 
a NodeJS module, to being handled as the primary prupose of a Rust 
library.

> The artifact needed by node-source-map is a WASM binary of
> source_map_mappings_wasm_api. What kind of deb package would provide
> that file?
> 
> The description of source-map-mappings says:
> "This is intended to be compiled to WebAssembly and eventually used from
> the mozilla/source-map library. This is not a general purpose source
> maps library."
> 
> It seems to be a integral part of node-source-map, and only
> distributed separately because it's written in a different language.
> 
> So I wonder if a debian package of source-map-mappings would be useful 
> at all.
> 
> Is this a good reason to include it in the debian source package of 
> node-source-map?

It might arguably be sensible to package both projects together, if done 
in a way that ensured that both parts were treated carefully 
(Debian-specific compiler options applied, Debian-specific install paths 
used, Debian-specific test tricks applied, etc.).

So mybe if done by a maintainer knowledgeable on both NodeJS and 
Rust and bold enough to invent some tooling to compete with pkg-js-tools 
and debcargo (because at least debcargo is not fit for use outside the 
Rust team).  Personally I do not recommend to reinvent CDBS...

...or that one single package could contain all the custom rules to 
handle things correctly *without* custom tooling.  Then the maintainer 
would need to keep track of what wisdom evolves in the related unused 
tools and reimplement that for this one single package.

Simpler and easier maintainable is to not do such custom hack but 
maintain a NodeJS package and a Rust library package as two separate 
things, using separate tooling.  It is hard enough to link the Rust 
library with the NodeJS code without dealing with the tedious common 
parts of integrating the Rust library with Debian 
libraries-are-in-shared-locations-not-on-the-web structure.

See also Debian Policy § 4.13: 
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

 - Jonas

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

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

signature.asc
Description: signature

Bug#1004680: upgrade-reports: beep when selecting logout


Control: tags -1 moreinfo

Dear Roger,

On 31-01-2022 18:50, Roger wrote:

My previous release was: Buster
I upgraded to: Bullseye
Archive date: 
Upgrade date: January 2022
uname -a before upgrade: 
uname -a after upgrade: Linux Roger 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1
(2021-12-08) x86_64 GNU/Linux
Method: I edited the sources lists and used sudo apt.

Contents of /etc/apt/sources.list:
deb http://ftp.us.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/ bullseye-security contrib non-free main
deb http://ftp.us.debian.org/debian/ bullseye-updates contrib non-free main
# deb
http://ftp.ca.debian.org/debian/pool/main/k/keepassxc/keepassxc_2.6.6+dfsg.1-1_amd64.deb
bullseye main


- Were there any non-Debian packages installed before the upgrade?  If
   so, what were they? Yes, but unknown.

- Was the system pre-update a pure sarge system? If not, which packages
   were not from sarge?  It was a Buster system.

- Did any packages fail to upgrade?  Not that I know of.

- Were there any problems with the system after upgrading?  Not that I know of.


I'm failing to see what upgrade problem you are reporting. What is it 
that you think is going wrong during the upgrade?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#964199: nsjail: Package ready for review/submission

2022-01-31 Thread Russell Hernandez Ruiz

Howdy, I created a package for `nsjail`, then noticed it's already been
worked on, but this bug has been open a while. There any way I can help?
Or I'm happy to take over as well.

Thanks.

Bug#1003899: wavemon: New upstream release (v0.9.4, 2021 Sep 18)

2022-01-31 Thread Samuel Henrique

Hello Jonathan,

I have interest in the wavemon package, as I use the scan mode a lot.

I would like to co-maintain the package with you, put it under a team, or
take over the maintenance , also putting it over a team (if you don't want
to keep maintaining it).

This new release is a good opportunity to upload the packaging to salsa as
well.

Please let me know what you think about this, in the case of no response I
will go ahead and add myself as an Uploader (without removing you) and push
the new release.

Thank you,

-- 
Samuel Henrique

Bug#1003969: sudo: FQDN option not overridable early on.

2022-01-31 Thread Sven Mueller

Hi Marc.

Any chance of an upload of a new sudo package any time soon, so that
the fix to this bug is available?

I would love to upgrade from 1.9.5 to >=1.9.8 because of some of the
fixes, but currently can't due to the issue in this bug.
I saw that you updated the repo on alioth to 1.9.9, which means the
patch I mentioned before has been integrated.

Cheers,
Sven

Am Sa., 22. Jan. 2022 um 16:13 Uhr schrieb Marc Haber
:
>
> tags 1003969 confirmed pending - patch
> thanks
>
> On Wed, Jan 19, 2022 at 01:29:19PM +0100, Sven Mueller wrote:
> > Tags 1003969 + fixed-upstream patch confirmed
>
> Only the package maintainer should set the "confirmed" tag. Please
> refrain from doing this in the future. See
> https://www.debian.org/Bugs/Developer
>
> > https://www.sudo.ws/repos/sudo/rev/8c6eaa503793 has the upstream patch.
>
> Thanks for spotting this. I have written an autopkgtest that fails
> without this patch and succeeds with this patch, and have pushed both
> the test and the fix. Will be in the next package.
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1004681: ITP: wcag-contrast-ratio -- Library computing contrast ratios required by WCAG 2.0

2022-01-31 Thread Carsten Schoenert

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

* Package name: wcag-contrast-ratio
  Version : 0.9
  Upstream Author : Geoffrey Sneddon 
* URL : https://github.com/gsnedders/wcag-contrast-ratio
* License : MIT
  Programming Lang: Python
  Description : Library computing contrast ratios required by WCAG 2.0

 This package provides a Python library that calculates the contrast ratio of
 colors based on the Web Content Accessibility Guidelines (WCAG) 2 standard,
 published by the Web Accessibility Initiative (WAI). The actual WCAG technical
 documents are created by the Accessibility Guidelines Working Group (AG WG),
 which are part of the WAI.
 .
 This library also provides some checking if contrast meets the required level.

This packge is a new build dependency for recent versions of pygments.

It will be maintained within the Python Team.

Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Andrej Shadura

Hi,

I have received this bug report for wpa-supplicant 2.10.

-- 
Cheers,
  Andrej

- Original message -
From: Kamil Jonca 
To: Debian Bug Tracking System 
Subject: Bug#1004524: wpasupplicant: After upgrading cannot connect to wifi
Date: Saturday, 29 January 2022 22:18

Package: wpasupplicant
Version: 2:2.10-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have upgraded some packages on my laptop with

24:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 
802.11a/b/g/n

controller. After I was not able to up wlan interface and in logs I have 
entries like:

=
2022-01-29T21:54:57.996370+01:00 bambus wpa_supplicant[22258]: wlan0: 
CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
=
When I downgrade to 2:2.9.0-22+b1 (and only this package was downgraded)
everything started to work.


(I make this report on different machine that wpasupplicant is installed)
some info below.

~%uname -a
Linux bambus 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 
GNU/Linux

%dpkg -l broadcom-sta-dkms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--
ii  broadcom-sta-dkms 6.30.223.271-17 all  dkms source for the Broadcom 
STA Wireless driver

- Original message -
From: kjo...@poczta.onet.pl
To: "1004...@bugs.debian.org" <1004...@bugs.debian.org>
Subject: Bug#1004524: additional logs
Date: Monday, 31 January 2022 18:33

Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.


wpa.wlan0.gz
Description: application/gzip

Bug#1004524: Fwd: Bug#1004524: additional logs

2022-01-31 Thread Andrej Shadura

Hi,

I have received this bug report for wpa-supplicant 2.10.

-- 
Cheers,
  Andrej

- Original message -
From: Kamil Jonca 
To: Debian Bug Tracking System 
Subject: Bug#1004524: wpasupplicant: After upgrading cannot connect to wifi
Date: Saturday, 29 January 2022 22:18

Package: wpasupplicant
Version: 2:2.10-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have upgraded some packages on my laptop with

24:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 
802.11a/b/g/n

controller. After I was not able to up wlan interface and in logs I have 
entries like:

=
2022-01-29T21:54:57.996370+01:00 bambus wpa_supplicant[22258]: wlan0: 
CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
=
When I downgrade to 2:2.9.0-22+b1 (and only this package was downgraded)
everything started to work.


(I make this report on different machine that wpasupplicant is installed)
some info below.

~%uname -a
Linux bambus 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 
GNU/Linux

%dpkg -l broadcom-sta-dkms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--
ii  broadcom-sta-dkms 6.30.223.271-17 all  dkms source for the Broadcom 
STA Wireless driver

- Original message -
From: kjo...@poczta.onet.pl
To: "1004...@bugs.debian.org" <1004...@bugs.debian.org>
Subject: Bug#1004524: additional logs
Date: Monday, 31 January 2022 18:33

Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.


wpa.wlan0.gz
Description: application/gzip

Bug#1004524: additional logs

2022-01-31 Thread kjonca

Sorry, but I use (now deprecated) method with /etc/network/interfaces
I added -dd to wpa supplicant and extracted wpa_supllicant log from 
syslog
 
grep 36696 /var/log/syslog|gzip -9v - > /tmp/wpa.wlan0.gz
 
result are in attachment.
Hope this is enough.
Another thing  I forgot to mention.
When I use usb card based on "Qualcomm Atheros Communications AR9271 802.11n"  
this work flawelessly regardless of wpa_supplicant version.

wpa.wlan0.gz
Description: application/gzip

Bug#859279: Updating the ygl Uploaders list

2022-01-31 Thread Mattia Rizzolo

On Mon, 31 Jan 2022, 6:02 pm Nilesh Patra,  wrote:

> Since this package was last uploaded in 2009 (~13 years ago) and the
> maintainer stated that they have no bandwidth to keep maintaining it
> plus Uploader has retired, and this had 3 RC bugs opened (for a long
> time), I fixed the RC bugs, and made the "Debian QA Team" as the package
> maintainer (effectively orphaning it) and did a upload for this package.
> The said bug that I am replying to right now has been open for 4+ years
> (almost 5) and hence from a pragmatic pov, I found it right to do.
>

Yes, this is perfectly fine, thank you.

Unless Kumar has plans of stepping in, do you think we should close this
> bug report too?
>

Rather, instead of closing it please reassign to wnpp and retitle it to
match the O bugs template title.

Bug#859279: Updating the ygl Uploaders list

2022-01-31 Thread Nilesh Patra

Hi Mattia, Kumar,

Kumar, would you have any plans to adopt this?

On Wed, 12 Apr 2017 09:27:20 +0200 Mattia Rizzolo  wrote:

On Wed, Apr 12, 2017 at 12:55:35PM +0530, Prabhu Ramachandran wrote:
> I am afraid I don't exactly know what to do or have the bandwidth for stepping
> in as a maintainer.  However, Kumar Appaiah (CC'd) said that he would be able 
to
> help.

Well, techinically you are already the maintainer.  From the current
package:

Source: ygl
Priority: extra
Maintainer: Prabhu Ramachandran  
Uploaders: Ramakrishnan Muthukrishnan 

In that case, probably this package should be orphaned instead?
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#orphaning

Since this package was last uploaded in 2009 (~13 years ago) and the 
maintainer stated that they have no bandwidth to keep maintaining it 
plus Uploader has retired, and this had 3 RC bugs opened (for a long 
time), I fixed the RC bugs, and made the "Debian QA Team" as the package 
maintainer (effectively orphaning it) and did a upload for this package.
The said bug that I am replying to right now has been open for 4+ years 
(almost 5) and hence from a pragmatic pov, I found it right to do.

Unless Kumar has plans of stepping in, do you think we should close this 
bug report too?

Let me know.

Regards,
Nilesh

Bug#1004679: [Pkg-deepin-devel] Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly

2022-01-31 Thread Boyuan Yang

Control: tags -1 +moreinfo +unreproducible
Control: severity -1 normal

I could not reproduce this issue. Depending on your computer's performance,
installation may take up to **one hour** due to icon cache refreshing. Please
try again and wait patiently. Please let me know if it does take more than one
hour, and also let me know your PC's model.

Thanks,
Boyuan Yang

在 2022-01-31星期一的 17:09 +0100，Michael Tatge写道：
> Package: papirus-icon-theme
> Version: 20220101-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
>    Trying to upgrade from 20220101-1 to 20220101-2
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    apt full-upgrade
> 
>    * What was the outcome of this action?
>    upgrade process hangs indefinitly an package
> 
>    * What outcome did you expect instead?
>    clean install
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages papirus-icon-theme depends on:
> ii  hicolor-icon-theme  0.17-2
> 
> papirus-icon-theme recommends no packages.
> 
> papirus-icon-theme suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-deepin-devel mailing list
> pkg-deepin-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-deepin-devel



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

Bug#1004658: Help to compile a wasm package

2022-01-31 Thread Geert Stappers

control: tag -1 -pending
I might be wrong about the removal of that tag, do feel free to re-add it.


On Mon, Jan 31, 2022 at 03:11:00PM +0100, Yadd wrote:
(fully quoted because I'm adding 1004...@bugs.debian.org to the loop)
> On 31/01/2022 15:00, Geert Stappers wrote:
> > On Mon, Jan 31, 2022 at 01:09:43PM +0100, Yadd wrote:
> > > Hi all,
> > > 
> > > to update a nodejs package,
> > 
> > Which package is that? Please provide an URL.
> 
> Hi
> 
> thanks for your answer. Here is the working package:
> https://salsa.debian.org/js-team/node-source-map
> 
> (embedded component source-map-mappings)

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004658#35
is adviced:

  source-map-mappings should be packaged separately,
  and then build-depended on from package node-source-map.
 

> > > I need to build a wasm file using cargo. I succeed to do it
> > 
> > OKay, nice.
> > 
> > 
> > > but it downloads some package during build process:
> > >   * libc-0.2.116
> > >   * rand-0.4.6
> > >   * vlq-0.5.1
> > > 
> > > Which package do I have to install as dependency to avoid this ?
> > 
> > Some how I do read "How to avoid dependency?"
> > 
> > Please elaborate your question. Because I don't understand it,
> > but want to understand it.
> 
> With network enabled, "cargo build" downloads these 3 packages and stores
> them in ~/.cargo
> 
> > > PS: sorry, I don't know anything about rust packaging,
> > >  neither rust/cargo themselves...
> > > 
> > 
> > Some how I do read "I fear the yet unknown rust and unknown cargo world"
> > 
> > Just tell more about "starting point"
> > > to update a nodejs package,
> 
> https://salsa.debian.org/js-team/node-source-map
> 
> Cheers,
> Yadd
> 

Now I understand the

} } }  it builds
} } }  there are dependencies  (they are fetched by Cargo)

the problem^Wchallenge in my words

} } }  It builds when Internet access is allowed.
} } }  During "debian build" is Internet access not allowed
} } }  (to prevent unreproduceable builds).
} } }  How to get the missing build dependencies?


Rust packages / crates needs to packaged for Debian.

> > >   * libc-0.2.116
With 
https://packages.debian.org/search?suite=stable=all=any=all=libc+rust
did I found `librust-libc-dev`.

> > >   * rand-0.4.6
There is Debian package `librust-rand+libc-dev`.


> > >   * vlq-0.5.1
That one seems to be missing.



Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#1004676: [Pkg-javascript-devel] Bug#1004676: node-istanbul: please make the build reproducible


Control: fixed -1 0.4.5+repack10+~cs97.25.57-3

On 31/01/2022 16:48, Chris Lamb wrote:

Source: node-istanbul
Version: 0.4.5+repack10+~cs97.25.57-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
node-istanbul could not be built reproducibly.

This is because it embedded the current working directory in the
generated manpage, which means that the current working directory
is embedded.

A patch is attached that strips this out.

  [0] https://reproducible-builds.org/


Hi,

I always fixed that some hours ago with another patch: 
https://salsa.debian.org/js-team/node-istanbul/-/commit/a696d49


Cheers,
Yadd

Bug#1004667: linux-signed-arm64: Please enable CONFIG_TASK_DELAY_ACCT

Control: tags -1 + moreinfo

Hi,

On Mon, Jan 31, 2022 at 03:18:49PM +0100, Matthias Urlichs wrote:
> Package: linux-signed-arm64
> Version: 5.10.46+4
> Severity: minor
> X-Debbugs-Cc: sm...@smurf.noris.de
> 
> "iotop" complains:
> 
> CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %
> 
> As ARM64 machines with swap space aren't exactly uncommon and it's useful
> to figure out which process is actually swapping: please enable this option.
> 
> It's enabled on amd64, if that helps.

CONFIG_TASK_DELAY_ACCT is already (in fact quite a while back in the
versions) in Debian. Thus closing the bugreport but adding a moreinfo
tag. As I have to assume you are not running a own kernel, what is
special about your setup?

Regards,
Salvatore

Bug#826045: systemd: New kernels are not booted

2022-01-31 Thread Andre Heider


On 30/01/2022 21:51, Michael Biebl wrote:

For anyone interested, I've submitted
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138

Which also ships some very basic /etc/kernel hooks and a simplistic 
postinst.


Would welcome feedback / follow-up fixes if needed.


That looks nice, thanks for working on this!

I'm still using the very same scripts I posted above, it's still working 
like a charm after 5 years with all the kernel updates and whatnot :)


I haven't tested your PR, and I lack the confirmed account on salsa to 
comment there, so I'll add it here, including answers to questions over 
there:


- removing sd-boot from the root fs won't render the system unbootable, 
since sd-boot needs to be installed to the efi partition. There's 
`bootctl remove` for that


- likewise with updating it. `bootctl status` reports "systemd-boot 
247.9-4" here, while the systemd package is already at 250.3-2, I'd have 
to `bootctl update` it to update it to that version


- checking if sd-boot is used can be checked via bootctl and should 
probably be used by the containing scripts instead of test -d /boot/efi:

$ bootctl is-installed; echo $?
yes
0

- contrary to the comments on salsa `kernel-install` is not part of your 
new package and I think it makes sense to move there. While it's using 
the "Boot Loader Specification", it's only used for stuff that's already 
part of this package. Even if there's a need for it without using 
sd-boot, one can install the sd-boot package without actually using it 
for booting the box (assuming the package scripts don't enforce it)


Regards,
Andre

Bug#1004674: libnss-systemd: SIGABRT on getgrent pass 2 ( with dynamic user)

2022-01-31 Thread Michael Biebl



Control: tags -1 + moreinfo

Am 31.01.22 um 16:31 schrieb Antonio Russo:


I discovered this issue when running "metastore -s":

Assertion 'name' failed at src/basic/strv.c:22, function strv_find(). Aborting.


..


I don't know if this reproduces on other non-Debian systems. The only related 
upstream bug I could find
is [1] which is resolved by [2], and is apparently included as of 247.3-6 (by 
inspection of source).



Since we don't ship any Debian specific modifications in that regard, it 
would be great if you can try with systemd v250 from unstable/testing 
and if it's still reproducible there, report the issue at

https://github.com/systemd/systemd/issues

Thanks,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004679: papirus-icon-theme 20220101-2 fails to install and hangs indefinitly

2022-01-31 Thread Michael Tatge

Package: papirus-icon-theme
Version: 20220101-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   Trying to upgrade from 20220101-1 to 20220101-2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   apt full-upgrade

   * What was the outcome of this action?
   upgrade process hangs indefinitly an package

   * What outcome did you expect instead?
   clean install

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

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

Versions of packages papirus-icon-theme depends on:
ii  hicolor-icon-theme  0.17-2

papirus-icon-theme recommends no packages.

papirus-icon-theme suggests no packages.

-- no debconf information

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Helmut Grohne

Hi,

On Mon, Jan 31, 2022 at 10:11:19AM +, Matthew Vernon wrote:
> The two renames have substantially different CLI syntax, making them
> unsuitable for an alternatives arrangement

I think that much of the discussion has taken this point for granted,
but it is one of the aspects that the submitter takes issue with. I
question: Is it really the case that incompatible interfaces make a tool
unsuitable for alternatives?

Maybe we should consider some similar cases? There are two that come to
my mind.

python3 is sufficiently different to python2 that it was deemed unfit to
fill the name /usr/bin/python in general. Yet, we have packages
python-is-python2 and python-is-python3. This is not using alternatives,
but it is an example where it is useful to allow a name to be taken by
different tools with substantially different interfaces. At the same
time, we have a policy that nothing in Debian may make use of
/usr/bin/python to allow this flexibility.

Another is renames. When nodejs was first introduced, it was denied
using the name /usr/bin/node. That other use of the name has since been
faded out and the name has been given to nodejs. Again, not using
alternatives, but a substantially changed interface.

I wasn't able to find cases where alternatives were used with
substantial interface differences. Often times it seems to be used for
changing the implementation of some command which is used by other
packages (popular example: awk).

Another way to look at it is figuring what uses /usr/bin/rename.
Searching for it is not easy as the term is so generic. I've found some
uses.

All of these use the file-rename syntax:
https://sources.debian.org/src/duplicity/0.8.21-1/testing/manual/run-coverage.sh/?hl=58#L58
https://sources.debian.org/src/gdcm/3.0.10-1/Utilities/gdcmjpeg/dcmtk.sh/?hl=18#L18
https://sources.debian.org/src/firebird3.0/3.0.8.33535.ds4-1/debian/make_packages.sh/?hl=185#L185
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/fontmerge.sh/?hl=22#L22
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/convert-layer.sh/?hl=63#L63
Most of them seem to be utility scripts for development.

A particular entertaining one is this:
https://sources.debian.org/src/rclone-browser/1.8.0-1.2/scripts/release_AppImage.sh/?hl=150#L150
It uses both syntaxes in the same source.

Beyond that, no package depends on rename and only xymon suggests it.

So maybe changing /usr/bin/rename to something else is not the worst of
options, but using alternatives for that task likely is the wrong tool.

As such, it does not seem too absurd to add some policy forbidding the
use of /usr/bin/rename (deferring in-archive users to
implementation-specific names). Once that is in place, the decision of
what /usr/bin/rename points to can be deferred to administrators (which
seems to be what the ctte filing is about) by some means other than
alternatives. Perhaps, we need file-is-file-rename and
file-is-rename.ul?

In any case, what I sketched here is a larger transition that shouldn't
be dumped on the util-linux maintainer somehow.

Dirk, would you be interested in working on a transition plan?

> #966468 & #982944 asked for rename.ul to return (though the latter rather
> confuses the removal vs alternatives issue)

I think it is relatively uncontroversial to return rename.ul in some
non-essential form. Chris vaguely offered including it in bsdextrautils
(without a clear plan on how). How about adding rename as
/usr/bin/rename.ul to bsdextrautils without participating in
alternatives? Would you, Chris, agree to that? I think doing so would
please some users and reduce the conflict. Those people could then ln -s
/usr/bin/rename.ul /usr/local/bin/rename on their systems. It may not be
as convenient as installing a package or using update-alternatives, but
it isn't that hard either.

In any case, I fear we may run counter to §6.3.5 (no detailed design
work). It seems pretty clear that the issue is in large part a
communication issue. As such, maybe we can wind this down already?

Helmut

Bug#1004678: git-lfs: allow offline operation

2022-01-31 Thread Barak A. Pearlmutter

Package: git-lfs
Version: 3.0.2-1
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter 

I have a repo whose only remote is on a gitlab instance. I'm using
git-lfs to manage large binary files in this repo. The remote goes down.
Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs,
freezes! Waits forever for the remote when trying to transfer the big
blobs.

This violates what I consider a central concept of git, namely that
operations are local unless you explicitly fetch or push. It means you
cannot work with lfs while offline, like on an aeroplane, or even (as
above) when the gitlab instance is offline for maintenance.

There is also a potential security issue. Users might reasonably assume
they can safely do "git add/commit/rebase" operations locally, with
intermediate steps exposing secret information that is later removed
before doing a push. Nope!

Anyway: I *wish* git-lfs allowed remote operation, like git-annex does.
It seems like it should be technically possible to wait until an
lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge
stub) is actually pushed before transferring the associated big binary
blob. Or at the very least, giving up and remembering to try again later
if there's a big binary blob transfer problem.

-- System Information:
Versions of packages git-lfs depends on:
ii  git1:2.34.1-1
ii  libc6  2.33-5

Bug#1004677: dh-golang: Please support skipping specific tests

2022-01-31 Thread Benjamin Drung

Package: dh-golang
Version: 1.53
Severity: normal

Hi,

golang-github-mdlayher-netlink ships test cases in several directories.
Running the package build, dh_auto_test is running this go test command:

   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
   cd _build && go test -vet=off -v -p 12
   github.com/mdlayher/netlink
   github.com/mdlayher/netlink/internal/integration
   github.com/mdlayher/netlink/nlenc
   github.com/mdlayher/netlink/nltest

I want to disable running the internal integration tests since they
would introduce circular dependencies. According to the man page, there
is no way to specify tests to exclude. It would be nice if dh-golang
would support excluding tests, e.g. by specifying:

export DH_GOLANG_TEST_EXCLUDES := internal/integration/

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#1004676: node-istanbul: please make the build reproducible

2022-01-31 Thread Chris Lamb

Source: node-istanbul
Version: 0.4.5+repack10+~cs97.25.57-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
node-istanbul could not be built reproducibly.

This is because it embedded the current working directory in the
generated manpage, which means that the current working directory
is embedded.

A patch is attached that strips this out.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2022-01-31 07:33:34.236984222 -0800
--- b/debian/rules  2022-01-31 07:45:32.099399485 -0800
@@ -9,6 +9,7 @@
 
 override_dh_auto_build:
help2man -N -n 'istanbul command line interface' nyc/bin/nyc.js >nyc.1
+   sed -i -e 's@default: "/.*"@default: current dir@g' nyc.1
 
 override_dh_fixperms:
dh_fixperms

Bug#1004673: dh-make-perl: Debian::Dependency should not fail on additional commas

Package: dh-make-perl
Version: 0.116
Severity: normal
Tags: patch

Hi,

dpkg tools accepts additional commas in dependencies but not
Debian::Dependency:

  Build-Depends: , debhelper-compat (=13)

Easy to fix:

  --- a/lib/Debian/Dependency.pm
  +++ b/lib/Debian/Dependency.pm
  @@ -352,7 +352,7 @@ sub parse {
   }
   );
   }
  -else {
  +elsif ($str) {
   die "Unable to parse '$str'";
   }
   }

Bug#1004467: libostree-1-1: flatpak crashes when creating a bundle

2022-01-31 Thread Philipp Huebner

Am 28.01.22 um 11:44 schrieb Simon McVittie:
> On Fri, 28 Jan 2022 at 08:27:19 +0100, Philipp Huebner wrote:
>> On Debian Bullseye, flatpak crashes when trying to create a bundle.
> 
> Is this specific to being in an ecryptfs directory, or some other special
> filesystem configuration?

Yes, it hangs/crashes when $HOME is ecrypfs encrypted. On a simple clean
Debian 11 without ecryptfs the bundling finishes successfully.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004672: libdebian-copyright-perl: Debian::Copyright should accept Files-Included and Files-Excluded-

Package: libdebian-copyright-perl
Version: 0.2-4
Severity: important

Hi,

debian/copyright accepts some fields for mk-origtargz including:
 * Files-Included
 * Files-Excluded-
 * Files-Included-

For now Debian::Copyright fails. It is easy to add "Files_Included" in
Debian/Copyright/Stanza/Header.pm but handling Files-Excluded-
requires to change more things.

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

2022-01-31 Thread Marcel Partap




Dear Guillem et al.,
don't know whether there already has been that called-for discussion on debian-devel 
about the technical burden of zstd support in dpkg. But obviously, ubuntu's move to 
compress debs with zstd by default in July last year (in favor of better UX) has made 
picking packages from their (or any third-party) repository (like their rtl8821ce-dkms) 
"a bit more difficult". And it seems somewhat unlikely they will roll back that 
decision..

So here's the patch rebased again on current git tip.
https://salsa.debian.org/mpartap-guest/dpkg/-/tree/zstd-rebased

Best Regards
Marcel 

Bug#1004670: [Pkg-javascript-devel] Bug#1004670: pkg-js-tools: restrictive regex for d/nodejs/component_links