Bug#1004254: ITA: mpdscribble -- Last.fm reporting client for mpd

[Andrey Rahmatullin]

On Sun, Feb 06, 2022 at 08:22:15AM +0100, Geoffroy Youri Berret wrote:
> On Sun, 23 Jan 2022 21:28:34 +0500 Andrey Rahmatullin 
> wrote:
> > I request an adopter for the mpdscribble package.
> 
> I've imported v0.23 release and made some changes (mainly switch to meson).
> Keeping the package in MPD-team.
> 
> https://salsa.debian.org/kaliko/mpdscribble
Feel free to adopt it and thank you for your contributions!


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1004254: ITA: mpdscribble -- Last.fm reporting client for mpd

[Geoffroy Youri Berret]

On Sun, 23 Jan 2022 21:28:34 +0500 Andrey Rahmatullin  
wrote:

I request an adopter for the mpdscribble package.


I've imported v0.23 release and made some changes (mainly switch to 
meson). Keeping the package in MPD-team.


https://salsa.debian.org/kaliko/mpdscribble

Thanks Andrey
Geoff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005055: lbdb: Missing dependency on libauthen-sasl-perl?

[Daniel Gröber]

Package: lbdb
Version: 0.49
Severity: important
X-Debbugs-Cc: d...@darkboxed.org

Dear Maintainer,

after installing and configuring lbdb for ldap lookup I'm getting the
following perl import error on running lbdbq:

Can't locate Authen/SASL.pm in @INC (you may need to install the 
Authen::SASL module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/bin/mutt_ldap_query line 
26,  line 960.
BEGIN failed--compilation aborted at /usr/bin/mutt_ldap_query line 26, 
 line 960.
lbdbq: no matches

mutt_ldap_query has:

use Authen::SASL qw(Perl);

right at the top which seems to suggest libauthen-sasl-perl is pretty
much required to use it. Currently the package only suggests this
library but I believe this should be a stronger dependency such as
reccommends so you don't end up with a broken installation by default
:)

Thanks,
--Daniel

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

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

Versions of packages lbdb depends on:
ii  libc62.31-13+deb11u2
ii  libvformat0  1.13-12
ii  perl 5.32.1-4+deb11u2

lbdb recommends no packages.

Versions of packages lbdb suggests:
pn  abook
ii  elpa-lbdb0.49
pn  finger   
pn  goobook  
pn  khard
ii  libauthen-sasl-perl  2.1600-1.1
ii  libnet-ldap-perl 1:0.6800+dfsg-1
pn  libpalm-perl 
ii  maildir-utils1.4.15-1
pn  mutt 
pn  procmail 

-- Configuration Files:
/etc/lbdb.rc changed [not included]
/etc/lbdb_ldap.rc changed [not included]

-- no debconf information

Bug#1005054: dnsperf: Backporting dnsperf to bullseye

[Daniel Gröber]

Package: dnsperf
Version: 2.9.0-1~bpo11+1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: d...@darkboxed.org

Dear Maintainer,

it would be good to have dnsperf available in bullseye, so I've taken
the time to try a make a quick backport[1]. No changes to the
packaging were required to make it work which is always nice :)

Would you be interested in sponsoring the upload or helping to
maintain the backport by any chance?

Thanks,
--Daniel

[1]: https://mentors.debian.net/package/dnsperf/

Bug#992344: wireguard-tools ought not depend on linux-image-rt-amd64

[Unit 193]

Howdy,

wireguard-tools does not actually depend on linux-image-rt-amd64, but it 
recommends 'wireguard-modules | wireguard-dkms' since all but the most unusual 
cases you'll want to be able to actually run WireGuard.  The former tries to 
pull in a kernel that supports WireGuard.


In your setup, rather than running `apt install -y wireguard-tools` you should 
instead try running `apt install --no-install-recommends -y wireguard-tools` and 
this problem should go away, since wireguard-modules is only recommended and not 
a hard depend.


Does this solve your problem?


Thanks!

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#993985: wireguard should not depend on wireguard-dkms now that wireguard is in mainline

[Unit 193]

Howdy,

The 'wireguard' package is a metapackage that depends on wireguard-tools and 
'wireguard-modules | wireguard-dkms', and the current Debian kernels provide the 
former.  This means that if you install the metapackage and have a current 
kernel, then only the wireguard-tools package is installed.  If you for some 
reason don't have a Debian kernel installed, or on a much older release, then 
-dkms is pulled in.


This seems to be working as expected, and isn't pulling in -dkms on current 
systems.  Is there a bug in this somewhere?



Thanks,

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#894889: mini-dinstall: please allow creating MD5 checksums for packages

[Unit 193]

Howdy,

I presume now that stable has aptly 1.0, which finally supports more than just 
MD5, this is a moot point?


There's been a push to deprecate md5sum, and even sha1 in some places, so I 
think at this point turning md5sum back on doesn't really make sense.



~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1005053: salt FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: salt
Version: 3004+dfsg1-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=salt=all

...
=== FAILURES ===
__ test_connected_ids __

def test_connected_ids():
"""
test ckminion connected_ids when
local_port_tcp returns 127.0.0.1
"""
opts = {"publish_port": 4505, "detect_remote_minions": False}
minion = "minion"
ip = salt.utils.network.ip_addrs()
mdata = {"grains": {"ipv4": ip, "ipv6": []}}
ckminions = salt.utils.minions.CkMinions({"minion_data_cache": True})
patch_net = patch("salt.utils.network.local_port_tcp", 
return_value={"127.0.0.1"})
patch_list = patch("salt.cache.Cache.list", return_value=[minion])
patch_fetch = patch("salt.cache.Cache.fetch", return_value=mdata)
with patch.dict(ckminions.opts, opts):
with patch_net, patch_list, patch_fetch:
ret = ckminions.connected_ids()
>   assert ret == {minion}
E   AssertionError: assert set() == {'minion'}
E Extra items in the right set:
E 'minion'
E Use -v to get the full diff

/<>/tests/pytests/unit/utils/test_minions.py:22: AssertionError
__ test_connected_ids_remote_minions ___

def test_connected_ids_remote_minions():
"""
test ckminion connected_ids when
detect_remote_minions is set
"""
opts = {
"publish_port": 4505,
"detect_remote_minions": True,
"remote_minions_port": 22,
}
minion = "minion"
minion2 = "minion2"
minion2_ip = "192.168.2.10"
ip = salt.utils.network.ip_addrs()
mdata = {"grains": {"ipv4": ip, "ipv6": []}}
mdata2 = {"grains": {"ipv4": [minion2_ip], "ipv6": []}}
ckminions = salt.utils.minions.CkMinions({"minion_data_cache": True})
patch_net = patch("salt.utils.network.local_port_tcp", 
return_value={"127.0.0.1"})
patch_remote_net = patch(
"salt.utils.network.remote_port_tcp", return_value={minion2_ip}
)
patch_list = patch("salt.cache.Cache.list", return_value=[minion, 
minion2])
patch_fetch = patch("salt.cache.Cache.fetch", side_effect=[mdata, 
mdata2])
with patch.dict(ckminions.opts, opts):
with patch_net, patch_list, patch_fetch, patch_remote_net:
ret = ckminions.connected_ids()
>   assert ret == {minion2, minion}
E   AssertionError: assert {'minion2'} == {'minion', 'minion2'}
E Extra items in the right set:
E 'minion'
E Use -v to get the full diff

/<>/tests/pytests/unit/utils/test_minions.py:51: AssertionError
...
FAILED tests/pytests/unit/utils/test_minions.py::test_connected_ids - Asserti...
FAILED 
tests/pytests/unit/utils/test_minions.py::test_connected_ids_remote_minions
= 2 failed, 9692 passed, 1751 skipped, 5 xfailed, 4 xpassed, 552 warnings in 
470.23s (0:07:50) =
Exception ignored in: 
Traceback (most recent call last):
  File "/<>/salt/transport/ipc.py", line 702, in _read
TypeError: catching classes that do not inherit from BaseException is not 
allowed
Exception ignored in: 
Traceback (most recent call last):
  File "/<>/salt/transport/ipc.py", line 702, in _read
TypeError: catching classes that do not inherit from BaseException is not 
allowed
make[1]: *** [debian/rules:35: override_dh_auto_test] Error 1

Bug#1004289: libpod package stops buld at override_dh_auto_build

[Reinhard Tartler]

Can you reproduce this in a sid chroot?

May I ask you why you marked this issue as 'important'? -- Unfortunately I
do not have the capacity to support builds for backports.

Best regards,
-rt

On Mon, Jan 24, 2022 at 7:33 AM Elimar Riesebieter 
wrote:

> Source: libpod
> Version: 3.4.4=ds1
> Severity: important
> X-Debbugs-Cc: hostmast...@hostsharing.net
>
> Dear Maintainers,
>
> I tried to backport libpod in bullseye. The build-dep's are installed
> in two steps: apt build-dep libpod && apt build-dep -t unstable
> libpod. The build stops at:
>
> dh_auto_build: error: cd _output && go install -trimpath -v -p 20 -tags
> apparmor,ostree,seccomp,selinux,systemd -ldflags "-X
> main.buildInfo=3.4.4+ds1-1" github.com
>
> make[1]: *** [debian/rules:29: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/source/podman/libpod-3.4.4+ds1'
> make: *** [debian/rules:25: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> debuild: fatal error at line 1182:
> dpkg-buildpackage -us -uc -ui failed
>
> The very same error is triggered by building version 3.0.1+dfsg1.
>
> Did that in a bullseye environment and in a pbuilder chroot.
>
> Thanks
> Elimar
>
> -- System Information:
> Debian Release: 11.2
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
> 'stable-security'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.15.0-0.bpo.2-amd64 (SMP w/20 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

-- 
regards,
Reinhard

Bug#768073: ITP: lxd - The Linux Container Daemon

[Mathias Gibbens]

  For those following this ITP, the end is in sight! I have whittled
down the huge list of missing dependencies to just nine packages, all
of which are ready for upload. They're just waiting on sponsorship
and/or other dependencies to make it through into unstable.

  The packaging work for LXD is also largely complete. The git repo is
available on salsa [1], and I would invite interested parties to take a
look and provide any feedback. This is the most complicated package
I've created to date, so I'm sure there's room for improvement.

Mathias

[1] -- https://salsa.debian.org/go-team/packages/lxd


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

Bug#1005049: lintian: incorrect leading comma in "sub oxford_enumeration"

[Felix Lechner]

Control: tags -1 + pending

Hi,

On Sat, Feb 5, 2022 at 4:39 PM Chris Lamb  wrote:
>
> The code in question is as follows:

The code for the serial comma is relatively well-tested. It is also
used on the website. On the website, you can see that a citation is
being swallowed ("social contract item 2"). [1] An empty string is
presented instead.

A look at the tag declaration confirms that an additional citation is
present but not being shown. [2] The bug is (or was) probably located
elsewhere.

More significantly, I can no longer reproduce the bug with the
development version in Git, per the output below.

May I please close this bug? Thank you!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/patch-not-forwarded-upstream
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/p/patch-not-forwarded-upstream.tag#L12

* * *

➤ bin/lintian --info --tags patch-not-forwarded-upstream
debian/test-out/packages/checks/debian/patches/dep3/empty-forwarded-no-bug/
empty-forwarded-no-bug_1.0-1.dsc
N:
I: empty-forwarded-no-bug source: patch-not-forwarded-upstream
[debian/patches/silent.patch]
N:
N:   According to the DEP-3 headers, this patch has not been forwarded upstream.
N:
N:   Please forward the patch and try to have it included in
upstream's version control system. If the patch is not suitable for
N:   that, please mention not-needed in the Forwarded field of the patch header.
N:
N:   Please refer to social contract item 2, Coordination with
upstream developers (Section 3.1.4) in the Debian Developer's
N:   Reference, Changes to the upstream sources (Section 4.3) in the
Debian Policy Manual, and Bug#755153 for details.
N:
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/patches/dep3
N:   Renamed from: send-patch
N:

Bug#1005051: golang-github-sylabs-sif: Please update to upstream version 2.3.1

[Reinhard Tartler]

Source: golang-github-sylabs-sif
Version: 1.0.9-2.1
Severity: normal
X-Debbugs-Cc: siret...@tauware.de

A newer version 2.3.1 has been released upstream. This version is required for 
building
newer versions of github:containers/image, which is required for podman 4.0


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

Kernel: Linux 5.10.76-1.fc32.qubes.x86_64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1005050: rust-csv - autopkgtest failure

[Peter Michael Green]

Package: rust-csv
Version: 1.1.5-2
Severity: serious

rust-csv's autopkgtest is failing, which is blocking it's migration to 
testing.



--- cookbook_read_basic stdout 
thread 'cookbook_read_basic' panicked at 'command spawns successfully: Os { code: 2, 
kind: NotFound, message: "No such file or directory" }', tests/tests.rs:412:33
stack backtrace:
0: rust_begin_unwind
  at /usr/src/rustc-1.56.0/library/std/src/panicking.rs:517:5
1: core::panicking::panic_fmt
  at /usr/src/rustc-1.56.0/library/core/src/panicking.rs:101:14
2: core::result::unwrap_failed
  at /usr/src/rustc-1.56.0/library/core/src/result.rs:1617:5
3: core::result::Result::expect
  at /usr/src/rustc-1.56.0/library/core/src/result.rs:1259:23
4: tests::cmd_output_with
  at ./tests/tests.rs:412:21
5: tests::cookbook_read_basic
  at ./tests/tests.rs:27:15
6: tests::cookbook_read_basic::{{closure}}
  at ./tests/tests.rs:25:1
7: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.56.0/library/core/src/ops/function.rs:227:5
8: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.56.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.
Doing some experiments running the tests manually, it appears the 
culprit is the "--all-targets" option
passed to cargo test by the autopkgtests. This seems to stop cargo from 
building the examples in a

runnable form.

I'm not sure what the best way forward here is, one could override 
debian/tests/control, but experiance
shows that is a maintinance burden, because debian/tests/control 
hardcodes the crate version.


The other option would be to just disable the tests in question. Not 
ideal but probablly not a disaster

either.

Does anyone have any better ideas?

Bug#1005049: lintian: incorrect leading comma in "sub oxford_enumeration"

[Chris Lamb]

Package: lintian
Version: 2.114.0
Severity: minor

Hi,

I see output like this:

N:   Please refer to , Debian Developer's Reference section 3.1.4, Debian
N:   Policy Manual section 4.3, and Bug#755153 for details.
^^^

The code in question is as follows:

  sub oxford_enumeration {
  my ($self, $conjunctive, @alternatives) = @_;

  return $EMPTY
unless @alternatives;

  # remove and save last element
  my $final = pop @alternatives;

  my $maybe_comma = (@alternatives > 1 ? $COMMA : $EMPTY);

  my $text = $EMPTY;
  $text = join($COMMA . $SPACE, @alternatives) . "$maybe_comma $conjunctive 
"
if @alternatives;

  $text .= $final;

  return $text;
  }

I don't think the "join($COMMA . $SPACE, @alternatives)" is right,
otherwise the first item in the list starts with a comma, as we can
see in the output quoted above.

(I would change it directly, but I can't immediately grok what is going
on with $maybe_comma, etc. so I don't want to break anything.)


Regards,

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

Bug#1005011: lots of missing entries in debian/copyright

[Thorsten Alteholz]

Hi Tony,

On 05.02.22 17:26, tony mancill wrote:


I believe there is ambiguity here.  For this bug to be severity serious,
doesn't policy need to be revised to change "should" to "must" so that
it is clear that **every** upstream author **must** be enumerated in
debian/copyright?  If this is a requirement for software to be part of
Debian, policy should say so directly.


I am afraid you are mixing two different things here.
The paragraph above is about the header section of the machine readable 
copyright file. You are right, information about the upstream author must 
not be present there. This field is just meant to easily find a person to 
contact for this software.


The severity of the bug is related to §2.3 which says that 
debian/copyright must have "... verbatim copy of its distribution 
license(s) ...". This means that all copyright holder must be listed in 
the corresponding license blocks below the header. If some are missing, 
you both infringe policy and don't comply to the licenses. Both violations 
justify a severity of "serious".



In my personal opinion, policy requiring an exhaustive debian/copyright
is less useful for our users than functioning free software that
correctly documents the provenance of the software, albeit perhaps not
down to the detail of every individual who has ever contributed a line
of code.


I have to object here. If you work with open source software, you got some 
rights from the author, but you also have to fulfill some duties. One of 
the duties is to comply with the license the author has choosen. Most 
licenses require that you add information about the author to binary 
distributions of the software. In Debian this is achieved by adding 
debian/copyright to the binary package.
Our users benefit from this compilation as well. First, Debian gives them 
the right to further distribute the software, even only in binary form. 
But of course the users need to know under what conditions they are 
allowed to do this. Second, they can check whether Debian keeps a promise, 
namely point 1 of the Social Contract. Debian promises to distribute 100% 
free software. If you know of any other way how to achieve this goal, 
please let me know.



I expect that I could trivially find thousands of source
packages in the main archive for which such a requirement does not hold.


Ok, I challenge your word. Please file a bug for every incomplete 
debian/copyright.



But that is beside the point.  The point is that I don't understand the
policy basis upon which this bug is severity serious.


Ok, I hope my explanation above make things clearer now and I thank you 
for packaging open source software for Debian.


  Thorsten

Bug#1005048: elpa-lua-mode: Emacs hangs when I press enter twice on line 534 of a lua file

[Nils Dagsson Moskopp]

Package: elpa-lua-mode
Version: 20201010-1
Severity: normal
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

when working on Mineclonia https://git.minetest.land/Mineclonia/Mineclonia/
Emacs hung itself.  I have attached a lua file that is part of Mineclonia.
Pressing enter twice on line 534 reproducibly hangs Emacs on my machine.

I expected Emacs to not hang when I pressed enter twice on line 534 of 
the attached file.

Greetings!

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

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

Versions of packages elpa-lua-mode depends on:
ii  dh-elpa-helper  2.0.8
ii  emacsen-common  3.0.4

elpa-lua-mode recommends no packages.

elpa-lua-mode suggests no packages.

-- no debconf information
local S = minetest.get_translator("mcl_structures")
mcl_structures ={}
local rotations = {
"0",
"90",
"180",
"270"
}

local function ecb_place(blockpos, action, calls_remaining, param)
if calls_remaining >= 1 then return end
minetest.place_schematic(param.pos, param.schematic, param.rotation, 
param.replacements, param.force_placement, param.flags)
if param.after_placement_callback and param.p1 and param.p2 then
param.after_placement_callback(param.p1, param.p2, param.size, 
param.rotation, param.pr)
end
end
mcl_structures.place_schematic = function(pos, schematic, rotation, 
replacements, force_placement, flags, after_placement_callback, pr)
local s = loadstring(minetest.serialize_schematic(schematic, "lua", 
{lua_use_comments = false, lua_num_indent_spaces = 0}) .. " 
return(schematic)")()
if s and s.size then
local x, z = s.size.x, s.size.z
if rotation then
if rotation == "random" and pr then
rotation = rotations[pr:next(1,#rotations)]
end
if rotation == "random" then
x = math.max(x, z)
z = x
elseif rotation == "90" or rotation == "270" then
x, z = z, x
end
end
local p1 = {x=pos.x, y=pos.y   , z=pos.z}
local p2 = {x=pos.x+x-1, y=pos.y+s.size.y-1, z=pos.z+z-1}
minetest.log("verbose","[mcl_structures] size=" 
..minetest.pos_to_string(s.size) .. ", rotation=" .. tostring(rotation) .. ", 
emerge from "..minetest.pos_to_string(p1) .. " to " .. 
minetest.pos_to_string(p2))
local param = {pos=vector.new(pos), schematic=s, 
rotation=rotation, replacements=replacements, force_placement=force_placement, 
flags=flags, p1=p1, p2=p2, after_placement_callback = after_placement_callback, 
size=vector.new(s.size), pr=pr}
minetest.emerge_area(p1, p2, ecb_place, param)
end
end

mcl_structures.get_struct = function(file)
local localfile = 
minetest.get_modpath("mcl_structures").."/schematics/"..file
local file, errorload = io.open(localfile, "rb")
if errorload ~= nil then
minetest.log("error", '[mcl_structures] Could not open this 
struct: ' .. localfile)
return nil
end

local allnode = file:read("*a")
file:close()

return allnode
end

-- Call on_construct on pos.
-- Useful to init chests from formspec.
local init_node_construct = function(pos)
local node = minetest.get_node(pos)
local def = minetest.registered_nodes[node.name]
if def and def.on_construct then
def.on_construct(pos)
return true
end
return false
end

-- The call of Struct
mcl_structures.call_struct = function(pos, struct_style, rotation, pr)
minetest.log("action","[mcl_structures] call_struct " .. 
struct_style.." at "..minetest.pos_to_string(pos))
if not rotation then
rotation = "random"
end
if struct_style == "desert_temple" then
return mcl_structures.generate_desert_temple(pos, rotation, pr)
elseif struct_style == "desert_well" then
return mcl_structures.generate_desert_well(pos, rotation)
elseif struct_style == "igloo" then
return mcl_structures.generate_igloo(pos, rotation, pr)
elseif struct_style == "witch_hut" then
return mcl_structures.generate_witch_hut(pos, rotation)
elseif struct_style == "ice_spike_small" then
return mcl_structures.generate_ice_spike_small(pos, rotation)
elseif struct_style == "ice_spike_large" 

Bug#1003860: RFS: makemkv-oss/1.16.5-1 [ITP] -- Convert video that you own into free format that can be played everywhere

[Mathias Gibbens]

Hi Ben,

  I spent some time reviewing the packaging for makemkv-{bin,oss}
today. Here are some thoughts/comments.

  General notes:

  * The typical pattern for new source packages in Debian is to have an
ITP filed, which is then closed on the first upload. Right now you have
an ITP that's covering both source packages. I'd suggest modifying the
existing ITP you have to be specific to makemkv-oss or makemkv-bin, and
then creating a new ITP for the other. Then you can cleanly close an
ITP for each new source package.

  * The changelog entry for a new package should consist solely of a
line similar to "Initial release (Closes: #)". All the
work and changes prior to upload aren't specifically called out in the
package's changelog. Also, the version number should always end in "-
1".

  * You may want to consider having two separate git repos for the two
different source packages. I realize that they are released in
lockstep, but having different repos may make life easier.

  * You may want to look into setting up/using git-buildpackage(1)
(`gbp`), which can help make building packages much easier. Of course,
the trade-off is a bit of a learning curve, but I think it's worth it
in the long run.

  makemkv-oss specific notes:

  * d/control: Consider setting the Architecture field for the various
lib* binary packages to match that of the makemkv binary package.

  * d/copyright: Double-check the listed copyright holders. For
example, the headers in libebml don't match what is listed in
d/copyright. I realize crafting d/copyright can be the most tedious
part of creating a package, but it's important to get it right. Two
things that I do are a case-insensitive grep through the code for
"copyright" and pay special attention to any LICENSE/COPYING/README
files that may have author copyright information. (Note that those
files don't always live at the root of the source, and may have
variations in how they are named.)

  * d/makemkv.lintian-overrides: Can probably be deleted. Binaries
should have a manpage; sometimes if one doesn't exist as a packager you
have to write a basic one. Also, this is one of the things noted in the
Reject FAQ for NEW [1], which lists several things that may cause
ftpmaster to reject a package. The other override is desktop-entry-
lacks-keywords-entry; that can easily be fixed with a simple patch to
add some keywords to the .desktop file.

  * d/README.source: Add this file to describe the issue(s) requiring
the shipping of bundled copies of libraries. Right off hand I know
about libebml and libmatroska, but there may be others. This informs
others who may review/work on the package in the future.

  * d/source/metadata: Add this file; see [2] for more information.

  * d/watch: Is incorrectly looking at the makemkv-bin source file.
Also, add a comment that the URL doesn't change, even though it looks
like it might.

  makemkv-bin specific notes:

  * d/copyright: There is an important difference between code that is
licensed as "GPL-2" and "GPL-2+" (for example). If a license doesn't
have "or any later version" (or similar phrasing), it's incorrect to
describe it with a "+" (or vise-versa). Admittedly, this is an issue in
my original packaging not getting that correct, but it should be fixed
in your packaging work. :)

  * d/makemkvcon.lintian-overrides: Same comment as before with
binaries needing a manpage to be provided.

  * d/rules: No need to have empty override_* targets.

  * d/source/metadata: Add this file.

  * d/watch: Similar to before, add a comment about the URL being
correct.

  * debconf: I added a simple debconf message that's displayed to the
user to ensure they are aware of the licensing terms when they first
install makemkv-bin. I have pretty much no experience with debconf
hooks; there may be better/more correct ways to handle this.

  Phew! That got kind of long, but I hope you find it useful. If you
have any questions or a comment doesn't make sense, please let me know.
Thanks for working on this!

Mathias

[1] -- https://ftp-master.debian.org/REJECT-FAQ.html
[2] -- https://wiki.debian.org/UpstreamMetadata


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

Bug#1005047: pipewire daemon starting even in non-graphical sessions

[Martin Mares]

Package: pipewire
Version: 0.3.44-1
Severity: minor

(I am running pipewire from Bookworm re-compiled for Bullseye, but I am
confident that the problem occurs in plain Bookworm, too.)

Is it intentional that the systemd user services for pipewire and pipewire-pulse
(and the related socket services) are WantedBy default.target? This causes
them to be started even for users logged in via SSH.

I would expect WantedBy graphical-session.target instead.


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.44-1~ucw11+1
ii  pipewire-bin 0.3.44-1~ucw11+1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1005033: biber breaks rubber autopkgtest: There were errors running biber.

[Hilmar Preuße]

Control: tags -1 + pending

Am 05.02.2022 um 21:29 teilte Paul Gevers mit:

Hi,


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

Today I uploaded the biblatex release, which corresponds to the biber 
package. Hence the issue should be already solved. We just have to wait 
for another round of test results.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005044: python3-subnettree: package completely broken, module won't load

[Michael Stone]

It seems to be some kind of incompatibility in swig. Upstream .cc files 
are built with swig 3, debian has swig 4. If the package is built with 
the upstream .cc files (ditching the associated lines in debian/rules) 
it seems to work fine.

Bug#992478: autopkgtest logs, pass and fail

[Kip Warner]

On Sat, 2022-02-05 at 08:44 +0100, Paul Gevers wrote:
> Sorry, that was not what I meant. I spotted rw-build-tree and noticed
> in the description that *you* have to take care of things if you use
> this restriction. Did you do that?

Hey Paul,

This is all the aforementioned DEP-8 test does. It's a trivial two-
liner:

   # Bail on any errors...
   set -e
   
   # Perform all in-tree unit tests or show log on failure...
   make -j check || { find . -iname "test-suite.log" -exec cat {} \; ; exit 99; 
}

All build artifacts are automatically cleaned up when debian/rules
clean is invoked. Nothing in these unit tests should affect any other
DEP-8 test, nor affect any binary packages produced by the build tree
in the future as far as I am aware.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#1005046: lintian: [false positive] very-long-line-length-in-source-file for pictures and sounds

[Daniele Forsi]

Package: lintian
Version: 2.114.161
Severity: normal
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

for package js8call, Lintian warns about very long lines for PNG, ICO and WAV 
files.
I think that in these caseethe warning should be suppressed because they aren't 
source files for a programming language.

Here is the list of warnings from https://lintian.debian.org/sources/js8call 
which contains also valid warnings about COPYING and README:

 very-long-line-length-in-source-file 1243 > 512 
[icons/Darwin/JS8Call.iconset/icon_128x...@2x.png:65]
 very-long-line-length-in-source-file 1243 > 512 
[icons/Darwin/JS8Call.iconset/icon_256x256.png:65]
 very-long-line-length-in-source-file 1243 > 512 
[icons/Darwin/wsjt.iconset/icon_128x...@2x.png:65]
 very-long-line-length-in-source-file 1243 > 512 
[icons/Darwin/wsjt.iconset/icon_256x256.png:65]
 very-long-line-length-in-source-file 1322 > 512 [Configuration.ui:2912]
 very-long-line-length-in-source-file 13389 > 512 
[icons/windows-icons/installer_logo.bmp:16]
 very-long-line-length-in-source-file 1404 > 512 
[icons/Darwin/JS8Call.iconset/icon_256x...@2x.png:85]
 very-long-line-length-in-source-file 1404 > 512 
[icons/Darwin/JS8Call.iconset/icon_512x512.png:85]
 very-long-line-length-in-source-file 1404 > 512 
[icons/Darwin/wsjt.iconset/icon_256x...@2x.png:85]
 very-long-line-length-in-source-file 1404 > 512 
[icons/Darwin/wsjt.iconset/icon_512x512.png:85]
 very-long-line-length-in-source-file 1828 > 512 [artwork/js8call_icon.png:270]
 very-long-line-length-in-source-file 1828 > 512 
[icons/Darwin/JS8Call.iconset/icon_512x...@2x.png:270]
 very-long-line-length-in-source-file 1828 > 512 
[icons/Darwin/wsjt.iconset/icon_512x...@2x.png:270]
 very-long-line-length-in-source-file 1844 > 512 [artwork/splash.png:448]
 very-long-line-length-in-source-file 1869 > 512 [contrib/Commander TCPIP 
Mesages.pdf:538]
 very-long-line-length-in-source-file 2122 > 512 
[artwork/installer_logo.svg.png:111]
 very-long-line-length-in-source-file 21517 > 512 [media/tests/A_2_3.wav:607]
 very-long-line-length-in-source-file 21517 > 512 [media/tests/A_3_3.wav:607]
 very-long-line-length-in-source-file 21655 > 512 [media/tests/A_1_4.wav:658]
 very-long-line-length-in-source-file 21655 > 512 [media/tests/A_2_5.wav:658]
 very-long-line-length-in-source-file 21793 > 512 [media/tests/A_2_6.wav:3276]
 very-long-line-length-in-source-file 23065 > 512 [media/tests/A_2_1.wav:677]
 very-long-line-length-in-source-file 2348 > 512 [COPYING:75]
 very-long-line-length-in-source-file 2770 > 512 [icons/Darwin/DragNDrop 
Background.png:46]
 very-long-line-length-in-source-file 2932 > 512 [media/tests/A_2_9.wav:4399]
 very-long-line-length-in-source-file 521 > 512 [README:14]
 very-long-line-length-in-source-file 525 > 512 
[icons/Darwin/JS8Call.iconset/icon_16...@2x.png:7]
 very-long-line-length-in-source-file 525 > 512 
[icons/Darwin/JS8Call.iconset/icon_32x32.png:7]
 very-long-line-length-in-source-file 525 > 512 
[icons/Darwin/wsjt.iconset/icon_16...@2x.png:7]
 very-long-line-length-in-source-file 525 > 512 
[icons/Darwin/wsjt.iconset/icon_32x32.png:7]
 very-long-line-length-in-source-file 557 > 512 [js8.mod:1]
 very-long-line-length-in-source-file 659 > 512 [js8params.mod:1]
 very-long-line-length-in-source-file 678 > 512 
[icons/Darwin/JS8Call.iconset/icon_128x128.png:5]
 very-long-line-length-in-source-file 678 > 512 
[icons/Darwin/wsjt.iconset/icon_128x128.png:5]
 very-long-line-length-in-source-file 678 > 512 [icons/Unix/js8call_icon.png:5]
 very-long-line-length-in-source-file 68143 > 512 
[icons/windows-icons/js8call.ico:1]
 very-long-line-length-in-source-file 900 > 512 
[contrib/LDPC/peg-128-80-reg3.pchk:3]
 very-long-line-length-in-source-file 99895 > 512 [media/tests/E_1_1.wav:1513]
 very-long-line-length-in-source-file 99895 > 512 [media/tests/E_2_1.wav:1513]


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

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

Versions of packages lintian depends on:
ii  binutils2.37.90.20220130-2
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-3
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-1.1
ii  

Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface

[Santiago Garcia Mantinan]

> This is NOT about addresses on bridge ports (and I agree those are not
> needed or desirable), but the case where the bridge port is a VLAN

Ok.

> interface. Then the current code prevents you from using not just the
> VLAN interface (e.g. eth0.3), but also the underlying physical interface
> (i.e. eth0). I see no reason why you should not use both of these
> simultaneously.

Well, having IPv6 addresses attached to those ports can also be undesirable,
I really think that those addresses should be allowed with an explicit
config not by default.

> The patch I sent does not change anything about disabling ipv6 on the
> bridge port interface, only for the underlying physical interface for a
> VLAN bridge port.

I know, but I don't think that is the behaviour change we need.

I think we should find a way to say we should not disable them, or a way to
enable them if we want, but not by default.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#1003567: Please make a separate package for mistune 2.x

[Sandro Tosi]

> I'd like other python team member's opinion on this, and I'm not eager
> to maintain that legacy package, as I tend to not want to maintain
> obsolete software. Still, I can do the initial work of creating it.

i wouldnt expect much maintenance needed tho: 0.8.4 is essentially
dead upstream, so it will only need to be kept around until its rdeps
are ported to mistune 2.x

the proposal is "okay", it has the downside of requiring the current
rdeps to be updated to point to the new binary package name for the
old mistune, but it leaves the namespace open for mistune 2 to take
over python3-mistune bin pkg

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1003567: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Nilesh Patra  wrote on 05/02/2022 at 20:23:44+0100:

> [[PGP Signed Part:No public key for 00BAE74B343369F1 created at 
> 2022-02-05T20:23:44+0100 using RSA]]
> On 2/6/22 12:20 AM, Julian Gilbey wrote:
>> On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
>>> On 2/4/22 9:18 PM, Julian Gilbey wrote:
 [...]
 _mistune.py within the Debian package,
 and have nbconvert do "import nbconvert.filters._mistune as mistune"
 (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
 That seems like an eminently sensible solution to this problem.
>>>
>>> But that'd lead to a number of mistune's embedded copies in a huge number 
>>> of packages; since majority of
>>> the rev-deps (when I last checked) haven't adapted to this new version. 
>>> When they do,
>>> and it becomes a overhead to fix each one later.
>>> Even worse, if we discover a security problem sometime later, then all such 
>>> packages would be
>>> effected, and that honestly does not look like a good idea to me.
>> I have just had another idea, which might solve all of the problems:
>> create a new Debian package called mistune0 (or mistune1), which
>> contains the legacy version of mistune, but with the Python module
>> called "mistune0" instead of "mistune".  Then it will be
>> co-installable with mistune 2.x, and the packages which still depend
>> on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
>> until they are updated upstream.  This will also avoid having multiple
>> copies of the legacy code in the archive, which addresses the security
>> issue, and allow those packages which have migrated to mistune 2.x to
>> still say "import mistune".
>
> Ah, looks like we just had to think in the reverse direction from the initial 
> proposal (mistune-{0,1} instead of mistune-{1,2}).
> Indeed, that sounds like a much better plan.
> I hope PEB agrees with this as well, would like to hear from them :)
>
> Thanks for the discussion, Julian :)
>
> Regards,
> Nilesh

I'd like other python team member's opinion on this, and I'm not eager
to maintain that legacy package, as I tend to not want to maintain
obsolete software. Still, I can do the initial work of creating it.

-- 
PEB


signature.asc
Description: PGP signature

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Sandro Tosi]

> The test for this bug (and it should probably be recorded as an error,
> not just a warning, as no Python package should have a version number
> of 0.0.0)

what exactly is the problem that would make it an 'error'?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1005044: python3-subnettree: package completely broken, module won't load

[Michael Stone]

Package: python3-subnettree
Version: 0.33-1+b3
Severity: grave
Justification: renders package unusable

Documentation says:

A simple example which associates CIDR prefixes with strings::

>>> import SubnetTree
>>> t = SubnetTree.SubnetTree()
>>> t["10.1.0.0/16"] = "Network 1"
>>> t["10.1.42.0/24"] = "Network 1, Subnet 42"
>>> print("10.1.42.1" in t)
True


But the version in bullseye (and 0.35 currently in unstable) produce:

Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import SubnetTree
>>> t = SubnetTree.SubnetTree()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/SubnetTree.py", line 82, in __init__
_SubnetTree.SubnetTree_swiginit(self, 
_SubnetTree.new_SubnetTree(binary_lookup_mode))
AttributeError: module '_SubnetTree' has no attribute 'SubnetTree_swiginit'
>>> 


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

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

Versions of packages python3-subnettree depends on:
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  python3 3.9.2-3

python3-subnettree recommends no packages.

python3-subnettree suggests no packages.

-- no debconf information

Bug#1005011: lots of missing entries in debian/copyright

[Tom Lee]

Tony, without commenting on severity and policy concerns I'm happy to have
a first stab at this if you like.

And seconding Tony, thank you for the detailed review Thorsten!

On Sat, Feb 5, 2022 at 8:51 AM tony mancill  wrote:

> On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote:
> > Package: capnproto
> > please rework your debian/copyright. Especially
>
> Hi Thorsten,
>
> In my previous response, I neglected to say thank you for the thorough
> review of the package and its debian/copyright.  Thank you for the
> effort and detail you put into these reviews!
>
> Regards,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

[Julian Gilbey]

Package: lintian
Version: 2.111.0
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

I just ran into several Python packages that install modules with
version number 0.0.0 because of some issue with their setup.py
scripts.  I just did the following on my testing system:

lz4cat 
/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | 
grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info/PKG-INFO' | wc -l
24

lz4cat 
/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | 
grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info ' | wc -l
6

So there are at least about 30 packages with this problem.

The test for this bug (and it should probably be recorded as an error,
not just a warning, as no Python package should have a version number
of 0.0.0) is simple: if the binary package contains has a file or
directory with the name as in the above regex, then the package has
this error.

Best wishes,

   Julian

Bug#1005042: python3-lazy-object-proxy: advertises itself to Python as version 0.0.0

[Julian Gilbey]

Package: python3-lazy-object-proxy
Version: 1.7.1-1
Severity: normal

The patch dont-use-setuptools-scm.patch removes not only the attempt
by setup.py to read the SCM to determine the version number, but also
the backup version number information, and does not replace it with a
static version number.

This patch should be updated to *replace* the use_scm_version argument
to setup with:
version='1.7.1',
so that the
/usr/lib/python3/dist-packages/lazy_object_proxy-*.egg-info directory
gets the correct version information.

(And I also noticed that with the scm clause being removed from
setup.py setup.cfg, there is probably no longer any need to
Build-Depends on python3-setuptools-scm.)

Best wishes,

   Julian

Bug#906752: sudo, pam_keyinit, what to do?

[Steve Langasek]

On Wed, Feb 02, 2022 at 12:44:44PM +0100, Marc Haber wrote:
> X-Debbugs-CC: vor...@debian.org
> thanks
> 
> On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:
> > The pam_keyring(8) manpage advises against adding pam_keyinit 

I guess this is supposed to be pam_keyinit(8) since I do find the text
there.

> > ,
> > | This module should not, generally, be invoked by programs like su,
> > | since it is usually desirable for the key set to percolate through to
> > | the alternate context. The keys have their own permissions system to
> > | manage this.
> > `

> > However, there's no mentioning of the issue described here.

> > For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
> > contains a line.

> > ,
> > | sessionoptional pam_keyinit.so revoke
> > `

> > and they also seem to have different intended behavior for interactive
> > usage – there's a separate /etc/pam.d/sudo-i which contains

> > ,
> > | sessionoptional pam_keyinit.so force revoke
> > `

> So we need to make up our minds whether to follow up the pam_keyinit
> maintainers or Red Hat. Maybe the PAM maintainer can comment here?

I would suggest consulting the maintainers of other packages that currently
ship references to pam_keyinit and try to get a consensus with them.  For
example, /etc/pam.d/su-l does reference pam_keyinit in Debian, which seems
like it directly contradicts the above manpage but addresses this exact
issue.  I believe debian-devel is the appropriate for venue for such a
discussion.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1005041: python-treq: CVE-2022-23607

[Salvatore Bonaccorso]

Source: python-treq
Version: 18.6.0-0.2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 18.6.0-0.1

Hi,

The following vulnerability was published for python-treq.

CVE-2022-23607[0]:
| treq is an HTTP library inspired by requests but written on top of
| Twisted's Agents. Treq's request methods (`treq.get`, `treq.post`,
| etc.) and `treq.client.HTTPClient` constructor accept cookies as a
| dictionary. Such cookies are not bound to a single domain, and are
| therefore sent to *every* domain ("supercookies"). This can
| potentially cause sensitive information to leak upon an HTTP redirect
| to a different domain., e.g. should `https://example.com` redirect to
| `http://cloudstorageprovider.com` the latter will receive the cookie
| `session`. Treq 2021.1.0 and later bind cookies given to request
| methods (`treq.request`, `treq.get`, `HTTPClient.request`,
| `HTTPClient.get`, etc.) to the origin of the *url* parameter. Users
| are advised to upgrade. For users unable to upgrade Instead of passing
| a dictionary as the *cookies* argument, pass a
| `http.cookiejar.CookieJar` instance with properly domain- and scheme-
| scoped cookies in it.


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-23607
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23607
[1] https://github.com/twisted/treq/security/advisories/GHSA-fhpf-pp6p-55qc
[2] 
https://github.com/twisted/treq/commit/1da6022cc880bbcff59321abe02bf8498b89efb2 

Regards,
Salvatore

Bug#1005040: tortoize: Remove wrong hard-coded dependency on libcifpp1

[Steve Langasek]

Package: tortoize
Version: 2.0.5-1
Severity: serious
Tags: patch
Justification: uninstallable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Maarten,

The tortoize package has a hard-coded dependency on libcifpp1 listed in
debian/control.  It is always wrong to hard-code specific runtime libraries
in debian/control, and this now makes tortoize uninstallable with current
libcifpp, which has bumped its soname to libcifpp.so.2.

Please drop the reference to libcifpp1 as in the attached patch.

The hard-coded reference to libzeep5.1 is almost certainly also incorrect
but I have not verified this.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru tortoize-2.0.5/debian/control tortoize-2.0.5/debian/control
--- tortoize-2.0.5/debian/control   2022-02-04 22:41:14.0 -0800
+++ tortoize-2.0.5/debian/control   2022-02-05 12:32:24.0 -0800
@@ -22,7 +22,7 @@
 
 Package: tortoize
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libcifpp1, libzeep5.1
+Depends: ${shlibs:Depends}, ${misc:Depends}, libzeep5.1
 Description: Application to calculate ramachandran z-scores
  Tortoize validates protein structure models by checking the
  Ramachandran plot and side-chain rotamer distributions. Quality

Bug#1005039: python3-iniconfig: advertises itself to Python as version 0.0.0

[Julian Gilbey]

Package: python3-iniconfig
Version: 1.1.1-1
Severity: normal
Tags: patch

The setup.py in this package looks to Git to determine the package
version, but that obviously doesn't work in Debian builds.  This patch
fixes this by hard-coding the version number in setup.py.  It is not
ideal, as the patch will need updating every time the package is
updated.  An alternative would be to have a script which reads the
version number from debian/changelog, but that is probably overkill.

Best wishes,

   Julian
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,5 +1,2 @@
 [build-system]
-requires = ["setuptools>=41.2.0", "wheel", "setuptools_scm>3"]
-
-
-[tool.setuptools_scm]
\ No newline at end of file
+requires = ["setuptools>=41.2.0"]
--- a/setup.py
+++ b/setup.py
@@ -18,7 +18,7 @@
 package_dir={'': 'src'},
 description='iniconfig: brain-dead simple config-ini parsing',
 long_description=readme,
-use_scm_version=True,
+version='1.1.1',
 url='http://github.com/RonnyPfannschmidt/iniconfig',
 license='MIT License',
 platforms=['unix', 'linux', 'osx', 'cygwin', 'win32'],

Bug#1005038: oidc-agent: Backport for bullseye

[Peter Wienemann]

Source: oidc-agent
Version: 4.2.6-1
Severity: wishlist

Dear maintainer,

it would be nice if you could provide a backport of oidc-agent for bullseye.

Many thanks,

Peter

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

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

Bug#1005037: ITP: golang-gitlab-golang-commonmark-puny -- Functions for encoding/decoding to/from punycode

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Owner: Mathias Gibbens 

* Package name: golang-gitlab-golang-commonmark-puny
  Version : 0.0~git20191124.9f83538-1
  Upstream Author : opennota
* URL : https://gitlab.com/golang-commonmark/puny
* License : BSD 2-Clause
  Programming Lang: Go
  Description : Functions for encoding/decoding to/from punycode

 Package puny provides functions for encoding/decoding to/from
punycode.

This is a dependency for packaging golang-github-mdlayher-ndp (ITP
#1005035), and will be team-maintained within the Debian Go Packaging
Team.


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

Bug#1005036: deepdiff: autopkgtest failure on armhf and i386

[Paul Gevers]

Source: deepdiff
Version: 5.6.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package deepdiff, great. 
However, it fails on armhf and i386. Currently this failure is blocking 
the migration to testing [1]. Can you please investigate the situation 
and fix it?


I copied some of the output at the bottom of this report. It seems that 
the reference in the test is expecting the test to run on a 64 bit system.


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=deepdiff

https://ci.debian.net/data/autopkgtest/testing/i386/d/deepdiff/18967210/log.gz

=== python3.9 ===
= test session starts 
==

platform linux -- Python 3.9.10, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.9n6crap7/downtmp/autopkgtest_tmp
collected 645 items

tests/test_anyset.py . 
 [  0%]
tests/test_cache.py ss 
 [  1%]
tests/test_command.py ... 
 [  5%]
tests/test_delta.py  
[ 13%]
F 
 [ 18%]
tests/test_diff_math.py  
 [ 19%]
tests/test_diff_numpy.py  
 [ 20%]
tests/test_diff_other.py . 
 [ 22%]
tests/test_diff_text.py  
[ 29%]
sss. 
[ 40%]
... 
 [ 43%]
tests/test_diff_tree.py .s 
 [ 45%]
tests/test_distance.py .. 
 [ 51%]
tests/test_hash.py . 
[ 59%]
... 
 [ 63%]
tests/test_helper.py ... 
 [ 69%]
tests/test_ignore_order.py . 
[ 76%]
.. 
 [ 78%]
tests/test_lfucache.py  
 [ 79%]
tests/test_model.py . 
 [ 82%]
tests/test_operators.py  
 [ 83%]
tests/test_path.py  
 [ 85%]
tests/test_search.py ... 
[ 93%]
.. 
 [ 94%]
tests/test_serialization.py .. 
 [100%]


=== FAILURES 
===
_ 
TestNumpyDelta.test_numpy_delta_cases[delta_numpy7_arrays_of_different_sizes] 
_


self = 
t1 = array([1, 2, 3, 4]), t2 = array([ 5,  6,  7,  8,  9, 10])
deepdiff_kwargs = {}, to_delta_kwargs = {}
expected_delta_dict = {'_numpy_paths': {'root': 'int64'}, 
'iterable_item_added': {'root[4]': 9, 'root[5]': 10}, 'values_changed': 
{'root[0]': {'new_value': 5}, 'root[1]': {'new_value': 6}, 'root[2]': 
{'new_value': 7}, 'root[3]': {'new_value': 8}}}

expected_result = 't2'

@pytest.mark.parametrize(**DELTA_NUMPY_TEST_PARAMS)
def test_numpy_delta_cases(self, t1, t2, deepdiff_kwargs, 
to_delta_kwargs, expected_delta_dict, expected_result):

diff = DeepDiff(t1, t2, **deepdiff_kwargs)
delta_dict = diff._to_delta_dict(**to_delta_kwargs)
if expected_delta_dict:

  assert expected_delta_dict == delta_dict
E   AssertionError: assert {'_numpy_path...w_value': 8}}} == 
{'_numpy_path...w_value': 8}}}

E Omitting 2 identical items, use -vv to show
E Differing items:
E {'_numpy_paths': {'root': 'int64'}} != {'_numpy_paths': 
{'root': 'int32'}}

E Use -v to get the full diff

tests/test_delta.py:991: AssertionError
=== short test summary info 

FAILED 
tests/test_delta.py::TestNumpyDelta::test_numpy_delta_cases[delta_numpy7_arrays_of_different_sizes]
=== 1 failed, 638 passed, 6 skipped in 5.08s 
===

autopkgtest [09:10:54]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005035: ITP: golang-github-mdlayher-ndp -- Golang implementation of the Neighbor Discovery Protocol

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Owner: Mathias Gibbens 

* Package name: golang-github-mdlayher-ndp
  Version : 0.0~git20210831.f982b87-1
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/ndp
* License : Expat
  Programming Lang: Go
  Description : Golang implementation of the Neighbor Discovery Protocol

 Package ndp implements the Neighbor Discovery Protocol, as described
 in RFC 4861 (https://tools.ietf.org/html/rfc4861).
 .
 To learn more about NDP, and how to use this package, please visit
 https://mdlayher.com/blog/network-protocol-breakdown-ndp-and-go/.

This is a dependency for packaging LXD (ITP #768073), and will be team-
maintained within the Debian Go Packaging Team.


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

Bug#1005034: sensible-utils: sensible-editor treats spaces differently in VISUAL and EDITOR

[Julian Gilbey]

Package: sensible-utils
Version: 0.0.17
Severity: normal
Tags: patch

If I set:
VISUAL="emacs -nw"
then sensible-editor complains:
/usr/bin/sensible-editor: 20: emacs -nw: not found
but if I set:
EDITOR="emacs -nw"
instead, then sensible-editor is fine.

I think the correct behaviour should be to allow "emacs -nw", as in
the EDITOR version.  This behaviour can be replicated by removing the
quote marks around "$VISUAL" on line 36 of /usr/bin/sensible-editor

Best wishes,

   Julian

Bug#1005033: biber breaks rubber autopkgtest: There were errors running biber.

[Paul Gevers]

Source: biber, rubber
Control: found -1 biber/2.17-1
Control: found -1 rubber/1.6.0-2
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 biber the autopkgtest of rubber fails in testing 
when that autopkgtest is run with the binary packages of biber from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
biber  from testing2.17-1
rubber from testing1.6.0-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of biber 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=biber

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rubber/18968283/log.gz

(cd tests && ./run.sh *)
When a test fails, please remove the /var/tmp/rubber-20220205-nb7OCD 
directory manually.

Test: asymptote-aux-overwritten
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.pre
removing doc-1.asy
removing doc-1.eps
Test: asymptote-dvi
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.pre
removing doc-1.asy
removing doc-1.eps
Test: asymptote-dvipdfm
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
executing: dvipdfm doc.dvi
doc.dvi -> doc.pdf
[1]
3016 bytes written
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.pdf
removing doc.pre
removing doc-1.asy
removing doc-1.eps
Test: asymptote-dvips
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
executing: dvips doc.dvi
This is dvips(k) 2021.1 (TeX Live 2022/dev)  Copyright 2021 Radical Eye 
Software (www.radicaleye.com)

' TeX output 2022.02.05:1012' -> doc.ps



. 
[1

<./doc-1.eps>] nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.ps
removing doc.pre
removing doc-1.asy
removing doc-1.eps
Test: asymptote-dvips-ps2pdf
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
executing: dvips doc.dvi
This is dvips(k) 2021.1 (TeX Live 2022/dev)  Copyright 2021 Radical Eye 
Software (www.radicaleye.com)

' TeX output 2022.02.05:1012' -> doc.ps



. 
[1

<./doc-1.eps>] running: ps2pdf doc.ps doc.pdf
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.ps
removing doc.pdf
removing doc.pre
removing doc-1.asy
removing doc-1.eps
Test: asymptote-inline-dvi
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.pre
removing doc-1.asy
removing doc-1.tex
removing doc-1_0.eps
removing doc-1.pre
Test: asymptote-inline-dvipdfm
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
executing: dvipdfm doc.dvi
doc.dvi -> doc.pdf
[1]
3016 bytes written
nothing to be done for doc.tex
removing doc.dvi
removing doc.log
removing doc.aux
removing doc.pdf
removing doc.pre
removing doc-1.asy
removing doc-1.tex
removing doc-1_0.eps
removing doc-1.pre
Test: asymptote-inline-dvips
Running python3 -W error -X dev ../rubber.py   doc ...
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
running: asy doc-1.asy
compiling doc.tex
executing: latex \nonstopmode \input{doc.tex}
executing: dvips doc.dvi
This is dvips(k) 2021.

Bug#1000616: upstream bug url

[Kai Lüke]

I opened a kernel bugzilla issue where I also pasted a similar trace 
from an arm64 device:


https://bugzilla.kernel.org/show_bug.cgi?id=215571

Bug#1005032: ruby-hamster: autopkgtest regression: output differ

[Paul Gevers]

Source: ruby-hamster
Version: 3.0.0-4
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-hamster the autopkgtest of ruby-hamster 
fails in testing when that autopkgtest is run with the binary packages 
of ruby-hamster from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
ruby-hamster   from testing3.0.0-4
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-hamster

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-hamster/18964952/log.gz


Failures:

  1) Hamster.to_ruby with Hamster::SortedSet[] as input should return 
::SortedSet.new
 Failure/Error: Hamster.to_ruby(Hamster::SortedSet[]).should == 
::SortedSet.new


   expected: #
got: # (using ==)
 # ./spec/lib/hamster/nested/construction_spec.rb:85:in `block (4 
levels) in '


Finished in 13.72 seconds (files took 1.56 seconds to load)
4593 examples, 1 failure, 10 pending

Failed examples:

rspec ./spec/lib/hamster/nested/construction_spec.rb:84 # 
Hamster.to_ruby with Hamster::SortedSet[] as input should return 
::SortedSet.new


/usr/bin/ruby2.7 
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib 
/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
--pattern ./spec/\*\*/\*_spec.rb --format documentation failed

mv ./.gem2deb.lib lib
autopkgtest [07:11:17]: test gem2deb-test-runner



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

HI Dominique,

On Sat, Feb 05, 2022 at 11:33:33AM +0100, Dominique Dumont wrote:
> Package: src:linux
> Version: 5.15.15-2
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> 
> Since upgrade to linux-image-5.15.0-3-amd6, suspending my machine no
> longer works correctly: the screen goes blank as usual, but comes back
> after 10s or so.
> 
> The most relevant kernel logs are:
> 
> [  257.531771] PM: suspend entry (s2idle)
> [  257.610570] Filesystems sync: 0.078 seconds
> [  257.610723] (NULL device *): firmware: direct-loading firmware 
> regulatory.db
> [  257.610726] (NULL device *): firmware: direct-loading firmware 
> regulatory.db.p7s
> [  257.610745] (NULL device *): firmware: direct-loading firmware 
> intel/ibt-17-16-1.ddc
> [  257.610954] (NULL device *): firmware: direct-loading firmware 
> intel/ibt-17-16-1.sfi
> [  257.610986] (NULL device *): firmware: direct-loading firmware 
> iwlwifi-9000-pu-b0-jf-b0-46.ucode
> [  257.611211] (NULL device *): firmware: direct-loading firmware 
> i915/kbl_dmc_ver1_04.bin
> [  257.726247] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [  257.728699] OOM killer disabled.
> [  257.728700] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [  257.730085] printk: Suspending console(s) (use no_console_suspend to debug)
> [  257.839817] amdgpu: 
> last message was failed ret is 65535
> [  257.839842] amdgpu: 
> failed to send message 261 ret is 65535 
> 
> [ ... lots of failed message ...]
> 
> [  257.840748] [ cut here ]
> [  257.840751] WARNING: CPU: 4 PID: 58 at 
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2014 
> dm_suspend+0x19e/0x1c0 [amdgpu]
> [  257.841665] Modules linked in: rfcomm xt_conntrack nft_chain_nat 
> xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 
> nf_defrag_ipv4 nft_counter xt_addrtype nft_compat nf_tables libcrc32c 
> nfnetlink br_netfilter bridge stp llc xfrm_user xfrm_algo nvme_fabrics 
> typec_displayport cmac algif_hash algif_skcipher af_alg overlay bnep 
> binfmt_misc nls_ascii nls_cp437 squashfs vfat fat loop x86_pkg_temp_thermal 
> intel_powerclamp mei_hdcp snd_sof_pci_intel_cnl coretemp dell_rbtn 
> intel_rapl_msr snd_sof_intel_hda_common soundwire_intel 
> soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci 
> kvm_intel snd_sof_xtensa_dsp snd_hda_codec_hdmi snd_sof soundwire_bus btusb 
> btrtl kvm snd_ctl_led snd_soc_skl btbcm btintel dell_laptop irqbypass iwlmvm 
> snd_soc_hdac_hda rapl bluetooth snd_hda_ext_core snd_soc_sst_ipc 
> snd_soc_sst_dsp snd_hda_codec_realtek snd_soc_acpi_intel_match snd_soc_acpi 
> dell_smm_hwmon snd_hda_codec_generic intel_cstate ledtrig_audio mac80211 
> snd_soc_core
> [  257.841816]  dell_wmi intel_uncore snd_compress dell_smbios 
> jitterentropy_rng dcdbas snd_hda_intel sha512_ssse3 serio_raw pcspkr libarc4 
> snd_intel_dspcfg sha512_generic efi_pstore dell_wmi_descriptor uvcvideo 
> snd_intel_sdw_acpi iwlwifi snd_usb_audio snd_hda_codec dell_wmi_sysman 
> videobuf2_vmalloc videobuf2_memops firmware_attributes_class iTCO_wdt 
> videobuf2_v4l2 intel_pmc_bxt snd_hda_core drbg iTCO_vendor_support 
> snd_usbmidi_lib videobuf2_common intel_wmi_thunderbolt wmi_bmof ee1004 
> watchdog snd_hwdep ansi_cprng joydev snd_rawmidi hid_multitouch videodev 
> cfg80211 snd_seq_device mc snd_pcm processor_thermal_device_pci_legacy 
> processor_thermal_device snd_timer processor_thermal_rfim 
> processor_thermal_mbox ucsi_acpi processor_thermal_rapl snd mei_me typec_ucsi 
> intel_rapl_common ecdh_generic roles soundcore mei ecc rfkill 
> intel_soc_dts_iosf intel_pch_thermal typec int3403_thermal evdev 
> int340x_thermal_zone dell_smo8800 intel_hid int3400_thermal intel_pmc_core 
> acpi_thermal_rel acpi_pad
> [  257.841935]  sparse_keymap ac parport_pc ppdev sunrpc lp parport fuse 
> configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic dm_crypt dm_mod hid_jabra usbhid r8152 mii hid_generic amdgpu 
> i915 rtsx_pci_sdmmc mmc_core crc32_pclmul crc32c_intel ghash_clmulni_intel 
> gpu_sched nvme aesni_intel e1000e crypto_simd cryptd nvme_core i2c_algo_bit 
> drm_ttm_helper ptp t10_pi ttm psmouse pps_core xhci_pci i2c_i801 
> drm_kms_helper thunderbolt crc_t10dif xhci_hcd cec i2c_smbus rc_core 
> crct10dif_generic crct10dif_pclmul crct10dif_common rtsx_pci drm usbcore 
> i2c_hid_acpi intel_lpss_pci i2c_hid intel_lpss idma64 usb_common hid wmi 
> battery button video
> [  257.842049] CPU: 4 PID: 58 Comm: kworker/u16:7 Not tainted 5.15.0-3-amd64 
> #1  Debian 5.15.15-2
> [  257.842057] Hardware name: Dell Inc. Precision 3540/0M14W7, BIOS 1.9.1 
> 07/06/2020
> [  257.842062] Workqueue: events_unbound async_run_entry_fn
> [  257.842075] RIP: 0010:dm_suspend+0x19e/0x1c0 [amdgpu]
> [  257.842795] Code: ff 31 d2 4c 89 e6 4c 89 ef e8 4e d7 15 00 83 f8 01 74 1e 
> 89 c2 48 c7 c6 40 36 f5 c0 48 c7 c7 

Bug#993515: catch: FTBFS with glibc 2.34

[Drew Parsons]

Source: catch
Followup-For: Bug #993515

Actually upsteam catch (catch2) had some criticisms of the PR#2317
patch that I referenced.

Among other things it should still use SIGSTKSZ not MINSIGSTKSZ.

The actual patch to catch2 was commit c0d0a50bd
https://github.com/catchorg/Catch2/commit/c0d0a50bdb2ae2f749443c0386c2b25379bdbf76

I adapted my dolfin patch to align with commit c0d0a50bd to use SIGSTKSZ
not MINSIGSTKSZ (and use 32 * 1024 as the backup default value).

I'm attaching the updated dolfin patch here for reference.
Index: dolfin/test/unit/cpp/catch/catch.hpp
===
--- dolfin.orig/test/unit/cpp/catch/catch.hpp   2022-02-04 17:07:26.964175029 
+0100
+++ dolfin/test/unit/cpp/catch/catch.hpp2022-02-04 17:08:30.528792625 
+0100
@@ -6472,6 +6472,17 @@
 int id;
 const char* name;
 };
+
+// 32kb for the alternate stack seems to be sufficient. However, this value
+// is experimentally determined, so that's not guaranteed.
+#if defined(_SC_SIGSTKSZ_SOURCE) || defined(_GNU_SOURCE)
+// on glibc > 2.33 this is no longer constant, see
+// 
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=85e84fe53699fe9e392edffa993612ce08b2954a;hb=HEAD
+static constexpr std::size_t altStackSize = 32 * 1024;
+#else
+static constexpr std::size_t altStackSize = 
std::max(static_cast(SIGSTKSZ), 32 * 1024)
+#endif
+
 extern SignalDefs signalDefs[];
 SignalDefs signalDefs[] = {
 { SIGINT,  "SIGINT - Terminal interrupt signal" },
@@ -6487,7 +6498,7 @@
 static bool isSet;
 static struct sigaction oldSigActions 
[sizeof(signalDefs)/sizeof(SignalDefs)];
 static stack_t oldSigStack;
-static char altStackMem[SIGSTKSZ];
+static char altStackMem[altStackSize];
 
 static void handleSignal( int sig ) {
 std::string name = "";
@@ -6507,7 +6518,7 @@
 isSet = true;
 stack_t sigStack;
 sigStack.ss_sp = altStackMem;
-sigStack.ss_size = SIGSTKSZ;
+sigStack.ss_size = altStackSize;
 sigStack.ss_flags = 0;
 sigaltstack(, );
 struct sigaction sa = { 0 };
@@ -6538,7 +6549,7 @@
 bool FatalConditionHandler::isSet = false;
 struct sigaction 
FatalConditionHandler::oldSigActions[sizeof(signalDefs)/sizeof(SignalDefs)] = 
{};
 stack_t FatalConditionHandler::oldSigStack = {};
-char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
+char FatalConditionHandler::altStackMem[altStackSize] = {};
 
 } // namespace Catch
 

Bug#1000616: linked bug fix commit is not relevant

[Kai Lüke]

I just checked again and the linked bug fix commit is not relevant 
because it addresses a problem introduced in v5.16-rc1

Bug#993515: catch: FTBFS with glibc 2.34

[Drew Parsons]

forwarded 993515 https://github.com/catchorg/Catch2/issues/2178
thanks

Discussion of the upstream bug fixed by commit c0d0a50bd (not PR#2317)
was in issue #2178

Bug#1005030:

[Andreas Hasenack]

Salsa PR at https://salsa.debian.org/med-team/resfinder/-/merge_requests/2

Bug#1005031: binaryornot: advertises itself to Python as version 0.4.3 rather than 0.4.4

[Julian Gilbey]

Package: python3-binaryornot
Version: 0.4.4+dfsg-4
Severity: normal

Hi,

Upstream seems to have made a mistake and somehow tagged the wrong git
commit with the 0.4.4 tag.  (It was reported as an issue in 2020.)
The version tagged on GitHub as 0.4.4 still says "0.4.3" as the
version number in setup.py and __init__.py, so Python still thinks
it's version 0.4.3.  The following commit (on the same day) set the
version numbers correctly, and that is the version that was uploaded
to PyPI.  There have also been a few commits since then, but it looks
like there will never be a version 0.4.5.

One way of addressing this bug would be to upload a new version
0.4.4+dfsg2-1 with the corrected source package.  An alternative could
be to have a version 0.4.4+git+dfsg-1 incorporating more recent
commits.

Best wishes,

   Julian

Bug#995420: bt-full with debug symbols

[Kai Lüke]

Here the paste for running gdb bt and bt full with debug symbols:

https://paste.debian.net/1229712

Bug#1005030: resfinder: tests fail under python 3.10: collections import

[Andreas Hasenack]

Package: resfinder
Version: 4.1.5-2
Severity: normal

Dear Maintainer,

with python 3.10, the DEP8 tests of this package fail:

Running tests
Done
Traceback (most recent call last):
  File "/usr/bin/run_resfinder.py", line 8, in 
from cge.resfinder import ResFinder
  File "/usr/share/resfinder/cge/resfinder.py", line 14, in 
from .output.table import TableResults
  File "/usr/share/resfinder/cge/output/table.py", line 2, in 
from .orderedset import OrderedSet
  File "/usr/share/resfinder/cge/output/orderedset.py", line 20, in 
class OrderedSet(collections.MutableSet):
AttributeError: module 'collections' has no attribute 'MutableSet'

In python 3.10[1] deprecated aliases to Collections Abstract Base
Classes from the collections module have been removed. These imports
must be done from collections.abc.

Here is a trivial patch:
--- a/cge/output/orderedset.py
+++ b/cge/output/orderedset.py
@@ -17,7 +17,7 @@
 # SOFTWARE.
 import collections

-class OrderedSet(collections.MutableSet):
+class OrderedSet(collections.abc.MutableSet):

 def __init__(self, iterable=None):
 self.end = end = []



1. https://docs.python.org/3/whatsnew/3.10.html

Bug#933096: libsane-common: Not possible to scan from remote clients

[Jörg Frings-Fürst]

Hello,

many thanks for your info. I close this bug.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


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

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


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


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



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

Bug#1003567: Please make a separate package for mistune 2.x

[Nilesh Patra]

On 2/6/22 12:20 AM, Julian Gilbey wrote:

On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:

On 2/4/22 9:18 PM, Julian Gilbey wrote:

[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.


I have just had another idea, which might solve all of the problems:
create a new Debian package called mistune0 (or mistune1), which
contains the legacy version of mistune, but with the Python module
called "mistune0" instead of "mistune".  Then it will be
co-installable with mistune 2.x, and the packages which still depend
on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
until they are updated upstream.  This will also avoid having multiple
copies of the legacy code in the archive, which addresses the security
issue, and allow those packages which have migrated to mistune 2.x to
still say "import mistune".


Ah, looks like we just had to think in the reverse direction from the initial 
proposal (mistune-{0,1} instead of mistune-{1,2}).
Indeed, that sounds like a much better plan.
I hope PEB agrees with this as well, would like to hear from them :)

Thanks for the discussion, Julian :)

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005029: ltsp: please make the build reproducible

[Chris Lamb]

forwarded 1005029 https://github.com/ltsp/ltsp/pull/660
thanks

I've forwarded this upstream here:

  https://github.com/ltsp/ltsp/pull/660


Regards,

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

Bug#979375: backuppc: Version 4 doesn't manage accents correctly.

[Ghent]

Hello,

    Yes, I'm use rsync.

    My variables :

RsyncBackupPCPath 
 
: /usr/libexec/backuppc-rsync/rsync_bpc


RsyncClientPath 
 
: /usr/bin/rsync


    The backup PC and client PC are a single PC.

    I'm not on a new installation. I was on Backuppc 3 before.

Regards,

Ghent


Le 19/01/2022 à 18:39, J. Fernando LAGRANGE a écrit :

Hello,

Do you use rsync as Xfer method ?


I tried to reproduce with a fresh backuppc 4.4.0-3 installation on a 
Debian Bullseye installation and rsync backup went smoothly with 
"Vid\x{e9}os" in the config file !



(I am sorry, I do not know how to get all "System Information" from my 
BackupPC server to tell bts.)


Regards,
Fernando


On 05/01/2021 22:25, Ghent wrote:

Package: backuppc
Version: 4.4.0-2
Severity: important
Tags: upstream

Dear Maintainer,

The web interface doesn't correctly manage accents in BackupFilesOnly 
or BackupFilesExclude.
If I put the word "Vidéos", it saves "Vid\x{e9}os" in the config file 
and doesn't detect the folder during backup.
If I write "Vidéos" directly in the config file, the web interface 
displays "Vidéos" but it detects correctly the folder during backup.


-- System Information:
Debian Release: bullseye/sid
   APT prefers stable-updates
   APT policy: (950, 'stable-updates'), (950, 'testing'), (950, 
'stable'), (180, 'unstable'), (60, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages backuppc depends on:
ii  adduser    3.118
ii  apache2 [httpd]    2.4.46-2
ii  apache2-utils  2.4.46-2
ii  backuppc-rsync 3.1.3.0-1
ii  bzip2  1.0.8-4
ii  debconf [debconf-2.0]  1.5.74
ii  exim4  4.94-9
ii  exim4-daemon-light [mail-transport-agent]  4.94-9+b1
ii  init-system-helpers    1.60
ii  iputils-ping   3:20200821-2
ii  libarchive-zip-perl    1.68-1
ii  libbackuppc-xs-perl    0.62-1+b1
ii  libc6  2.31-6
ii  libcgi-pm-perl 4.51-1
pn  libdigest-md5-perl 
ii  libfile-listing-perl   6.14-1
ii  libtime-parsedate-perl 2015.103-3
ii  lsb-base   11.1.0
ii  perl [libio-compress-perl] 5.32.0-6
ii  ucf    3.0043

Versions of packages backuppc recommends:
ii  libio-dirent-perl    0.05-1+b9
ii  openssh-client [ssh-client]  1:8.4p1-3
ii  rrdtool  1.7.2-3+b7
ii  samba-common-bin 2:4.13.2+dfsg-3
ii  smbclient    2:4.13.2+dfsg-3

Versions of packages backuppc suggests:
pn  certbot | acme-tiny | acmetool | dehydrated | lacme | lecm |   


ii  elinks [www-browser] 0.13.2-1+b1
ii  epiphany-browser [www-browser] 
3.38.2-1
ii  firefox [www-browser]  
84.0-3

pn libscgi-perl 
ii  links [www-browser]    
2.21-1
ii  links2 [www-browser]   
2.21-1

ii  lynx [www-browser] 2.9.0dev.6-1
ii  midori [www-browser]   
7.0-2.1

ii par2 0.8.1-1
ii rsync 3.2.3-3
ii  w3m [www-browser] 0.5.3-38+b1

-- Configuration Files:
/etc/backuppc/apache.conf changed [not included]
/etc/backuppc/config.pl [Errno 13] Permission non accordée: 
'/etc/backuppc/config.pl'
/etc/backuppc/hosts [Errno 13] Permission non accordée: 
'/etc/backuppc/hosts'

/etc/default/backuppc changed [not included]

-- debconf information excluded

Bug#1005029: ltsp: please make the build reproducible

[Chris Lamb]

Source: ltsp
Version: 22.01-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

Whilst ltsp does use the date provided by SOURCE_DATE_EPOCH, when
converting this to a text string it takes into account the current
timezone. A patch is therefore attached that simply passes --utc to
date(1) so that the date in the generated manpages is timezone
agnostic.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2022-02-05 11:05:15.577723278 
-0800
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-02-05
+
+--- ltsp-22.01.orig/docs/Makefile.sh
 ltsp-22.01/docs/Makefile.sh
+@@ -212,7 +212,7 @@ main() {
+ _VERSION=$(. ../ltsp/common/ltsp/55-ltsp.sh && echo "$_VERSION")
+ fi
+ if [ -n "$SOURCE_DATE_EPOCH" ]; then
+-_DATE=$(date -d"@$SOURCE_DATE_EPOCH" "+%Y-%m-%d")
++_DATE=$(date -u -d"@$SOURCE_DATE_EPOCH" "+%Y-%m-%d")
+ else
+ _DATE=$(date "+%Y-%m-%d")
+ fi
--- a/debian/patches/series 2022-02-05 10:55:53.098635739 -0800
--- b/debian/patches/series 2022-02-05 11:05:14.469724095 -0800
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1003567: Please make a separate package for mistune 2.x

[Julian Gilbey]

On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
> On 2/4/22 9:18 PM, Julian Gilbey wrote:
> > [...]
> > _mistune.py within the Debian package,
> > and have nbconvert do "import nbconvert.filters._mistune as mistune"
> > (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
> > That seems like an eminently sensible solution to this problem.
> 
> But that'd lead to a number of mistune's embedded copies in a huge number of 
> packages; since majority of
> the rev-deps (when I last checked) haven't adapted to this new version. When 
> they do,
> and it becomes a overhead to fix each one later.
> Even worse, if we discover a security problem sometime later, then all such 
> packages would be
> effected, and that honestly does not look like a good idea to me.

I have just had another idea, which might solve all of the problems:
create a new Debian package called mistune0 (or mistune1), which
contains the legacy version of mistune, but with the Python module
called "mistune0" instead of "mistune".  Then it will be
co-installable with mistune 2.x, and the packages which still depend
on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
until they are updated upstream.  This will also avoid having multiple
copies of the legacy code in the archive, which addresses the security
issue, and allow those packages which have migrated to mistune 2.x to
still say "import mistune".

Best wishes,

   Julian

Bug#1005024: tin: Hangs, disconnects reproducible on specific article

[Christoph Biedl]

Andreas Metzler wrote...

> ..O~..O~220 543 <1643229...@msgid.manchmal.in-ulm.de> article retrieved - 
> text follows

FWIW, this article was composed using the bullseye version of mutt, and
it seems I had managed to press some buttons I should stay away from.
However, I have no idea which one.

Still it might be worth an idea to tell the mutt maintainers about this.

Christoph


signature.asc
Description: PGP signature

Bug#1005028:

[Andreas Hasenack]

Salsa PR at https://salsa.debian.org/debian/pyx3/-/merge_requests/3

Bug#1005028: pyx3: fix t1 extension with Python 3.10

[Andreas Hasenack]

Package: pyx3
Version: 0.15-5
Severity: normal

Dear Maintainer,

building pyx3 with python 3.10 is failing:

Traceback (most recent call last):
  File "/tmp/autopkgtest.UtTakl/autopkgtest_tmp/examples/text/marker.py",
line 10, in 
c.writeEPSfile("marker")
  File "/usr/lib/python3/dist-packages/pyx/canvas.py", line 50, in
wrappedindocument
return method(d, file, **write_kwargs)
  File "/usr/lib/python3/dist-packages/pyx/document.py", line 185, in
writeEPSfile
pswriter.EPSwriter(self, f, **kwargs)
  File "/usr/lib/python3/dist-packages/pyx/pswriter.py", line 169, in __init__
registry.output(file, self)
  File "/usr/lib/python3/dist-packages/pyx/pswriter.py", line 52, in output
resource.output(file, writer, self)
  File "/usr/lib/python3/dist-packages/pyx/font/font.py", line 57, in output
self.t1file.getstrippedfont(self.glyphnames,
self.charcodes).outputPS(file, writer)
  File "/usr/lib/python3/dist-packages/pyx/font/t1file.py", line 1019,
in getstrippedfont
self.gatherglyphcalls(glyph, seacglyphs, subrs, T1context(self))
  File "/usr/lib/python3/dist-packages/pyx/font/t1file.py", line 900,
in gatherglyphcalls
self.gathercalls(self.getglyphcmds(glyph), seacglyphs, subrs, context)
  File "/usr/lib/python3/dist-packages/pyx/font/t1file.py", line 859,
in getglyphcmds
self._data2decode()
  File "/usr/lib/python3/dist-packages/pyx/font/t1file.py", line 721,
in _data2decode
self._data2 = self._eexecdecode(self._data2eexec)
  File "/usr/lib/python3/dist-packages/pyx/font/t1file.py", line 670,
in _eexecdecode
return decoder(code, self.eexecr, 4)
SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats

Python 3.10 is now enforcing https://www.python.org/dev/peps/pep-0353/

Upstream has a fix in commit
https://github.com/pyx-project/pyx/commit/0f2834330f7c86dbb5de9f75f9c7c8b7ab4ebabf
via PR https://github.com/pyx-project/pyx/pull/35

Bug#1005026: ITP: node-ampproject-remapping -- nodejs module to remap sequential sourcemaps through transformations

[Yadd]

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

* Package name: node-ampproject-remapping
  Version : 2.0.4
  Upstream Author : Justin Ridgewell 
* URL : https://github.com/ampproject/remapping
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : nodejs module to remap sequential sourcemaps through 
transformations

Remapping allows one to take the sourcemaps generated through transforming
code and "remap" them to the original source locations. Think "my minified
code, transformed with babel and bundled with webpack", all pointing to the
correct location in your original source code.

With remapping, none of the source code transformations need to be aware of
the input's sourcemap, they only need to generate an output sourcemap. This
greatly simplifies building custom transformations (think a find-and-replace).

node-ampproject-remapping is a dependency of next node-babel. Will be
maintained under JS Team umbrella.

Bug#1005025: libdvd-pkg fails reporting that the dpkg database is locked

[Martin Strauss]

Package: libdvd-pkg
Version: 1.4.2-1-1
Severity: important
X-Debbugs-Cc: mar...@clan-strauss.de

Dear Maintainer,

I upgraded from debian buster to bullseye. Afterwards libdvd-pkg reported the
following error:

libdvd-pkg: dpkg database is locked. You may need to use command "sudo dpkg-
reconfigure libdvd-pkg".
libdvd-pkg: Building and installation of package(s) [libdvdcss2 libdvdcss-dev]
postponed till after next APT operation.

This repeats for each "apt update". I spotted the same message on two different
computers, guess more people might be affected.
The package should download libdvdcss2 build and install it, which it doesn't
because of the failed check.

I tried the proposed "dpkg-reconfigure libdvd-pkg" which just produces the same
message. After some internet search I found the debian bug report #824093.
There someone reported that the check had been broken and provided a patch.
The patch is applied in the current version, however it seems that
the check for the lock is once again broken.

Basiclly it boils down to the following lines in the script:
/usr/lib/libdvd-pkg/b-i_libdvdcss.sh line 20

dpkg -P non-existent-package 2>/dev/null
if [ "$?" -eq 2 ]; then

It seems the with dpkg in version 1.20.9 the return code is always 2
independent of whether a package manager like aptitude is running or not.
Same is true for "dpkg -i /dev/zero" which was the previous version.
I checked this on the command line, the return code does not reflect
the lock status.
No idea how to fix this, the returned message is translated, so no good
to use that one. Maybe there is an official way how to do it, searching the
internet didn't help there. Maybe ask the dpkg maintainer?

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 libdvd-pkg depends on:
ii  build-essential12.9
ii  debconf [debconf-2.0]  1.5.77
ii  debhelper  13.3.4
ii  dh-autoreconf  20
ii  wget   1.21-1+deb11u1

Versions of packages libdvd-pkg recommends:
ii  libcap2-bin  1:2.44-1

libdvd-pkg suggests no packages.

-- debconf information:
  libdvd-pkg/title_u:
* libdvd-pkg/first-install:
* libdvd-pkg/post-invoke_hook-install: true
  libdvd-pkg/post-invoke_hook-remove: false
  libdvd-pkg/title_b-i:
  libdvd-pkg/upgrade:

Bug#1004471: [Pkg-javascript-devel] Bug#1004471: Pending patch for terser-webpack-plugin in webpack 5 till a new upstream for node-terser is uploaded

[Jonas Smedegaard]

Quoting Caleb Adepitan (2022-02-05 17:32:29)
> Sorry for the confusion I've caused. I was hoping mentioning that 
> "terser-webpack-plugin embedded in webpack package" in the initial 
> wishlist bug report 
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004471) stays 
> relevant in subsequent discussions under the report.
> 
> I probably shouldn't have shared a patch intended for node-webpack 
> (terser-webpack-plugin) under a bug filed for node-terser. I only 
> thought since the report mentioned that the bug affects webpack it 
> would be fine to add some additional info about a pending patch to 
> affected packages till the node-terser package is updated. It might 
> help to later know that when node-terser gets updated and the wishlist 
> bug is closed, the patch should become irrelevant and be removed from 
> the affected package.

Interesting reflection.

I cannot say for sure how you might have avoided confusing me - or if 
that is even your responsibility.

I think if you had written less - i.e. left out the patch - then I might 
still have been confused but I might have then simply ignored your post 
as incomprehensible noise, with the result that you would not know that 
I was confused and you would not know that I could be helped if you 
tried clarify.

I think what might have been better was if you had a) filed a separated 
bugreport against webpack, with the patch and a note on how a patch for 
terser-webpack-plugin was relevant to webpack (read: because webpack 
package silently embeds terser-webpack-plugin), and then b) and posted a 
note to this bugreport _about_ the patch (but without including the 
patch itself), mentioning the bugnumber for that other bugreport for 
those curious about the details of that patch.  That way you had shared 
full details but only relevant parts here.

But that is speculation - I might have been confused anyway, for 
whatever reason.  Important is that we figured it out - thanks!  Even 
more important is the work that you do in improving Debian packaging of 
NodeJS modules - regardless if I understand your work - so big thanks 
for that!!


> The patch intended no changes to node-terser, only the packages 
> affected by an incompatible version of node-terser which as I 
> mentioned was terser-webpack-plugin embedded in webpack 5.
> 
> The only changes intended for node-terser package as mentioned by the 
> wishlist bug is to update node-terser to latest upstream, terser 5.

Thanks for clarifying.  Much appreciated!


 - 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#1004118: E1187: Failed to source defaults.vim

[James McCoy]

On Tue, Feb 01, 2022 at 06:19:43PM +0100, Diederik de Haas wrote:
> On Fri, 21 Jan 2022 08:37:52 -0500 James McCoy  wrote:
> > On Fri, Jan 21, 2022 at 03:58:58AM +0100, Robert Siemer wrote:
> > > vim-tiny should come with defaults.vim, I believe.
> > 
> > No, vim-tiny exists purely to provide a vi binary in the base system and
> > therefore is geared towards a vi-like experience more so than a vim-like
> > experience.
> > 
> > This is why vim-tiny does not register itself as an option for the vim
> > alternative.
> 
> I don't know if it was the trigger for this bug report, but on a freshly 
> installed (very) minimal bookworm (arm64) system with vim-tiny, using it 
> produces the error as mentioned in the bug subject:
> 
> $ vim.tiny .ssh/authorized_keys 
> E1187: Failed to source defaults.vim
> Press ENTER or type command to continue

The binary vim.tiny is an implementation detail.  I tried to move
them under /usr/libexec, but that caused the alternatives to reset their
priorities for existing installs, so it had to be reverted.

The intended use is to invoke the binary through the named alternatives
(vi, view, ex, editor).

> After pressing ENTER, I can use it.
> While I understand that vim-tiny won't give me the full vim experience, it 
> currently does give the above error on every invocation.
> I don't recall it gave that/a error before.

When invoked as vi it doesn't, because that triggers Debian's patch to
only use the tiny config.  I'll talk with upstream about whether an
error should really be emitted when defaults.vim isn't available.

I'll also look into whether there's anything that should be adjusted for
the aforementioned patch.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1004888: inn2: libinn2-dev ships list.3, conflicting with man-pages

[Julien ÉLIE]

Hi all,


As of now, libinn2-dev ships list.3 with an inn2-specific list
implementation. However, Linux man-pages ships list.3 that documents
sys/queue.h, a popular, if obscure, double-linked list implementation
available on all modern BSDs.

See patch below, which just re-names the file to list-inn2.3

[...]

The consistency here is much nicer than my minimum-viable solution,
yeah :)


I'm sorry for the work you have done to provide a patch to the Debian 
package :-/


FYI, I've just committed the patches upstream:

https://github.com/InterNetNews/inn/commit/9a0597bcab17e43b8678732d7c22811e227bb085 
(for INN 2.6.5)



https://github.com/InterNetNews/inn/commit/50e097d3a7557eba6d6b0f93484d4ba9ec2d81f7 
(for INN 2.7.0 only)


--
Julien ÉLIE

« Il buvait toutes mes paroles, et comme je parlais beaucoup, à un
  moment, je le vois qui titubait… » (Raymond Devos)

Bug#1005024: tin: Hangs, disconnects reproducible on specific article

[Andreas Metzler]

Package: tin
Version: 1:2.6.1-1
Severity: normal

Hello,

I using rtin against a local loeafnode instance. Trying to read (or
save) a specific article in gmane.linux.debian.alioth.pkg-gnupg.general
makes tin hang. Watching tcpdump, tin sends ARTICLE 543 but at some
point seems to stop accepting data from the server:
8X--
..O~..3.ARTICLE 543

17:57:59.085223 IP 127.0.0.1.119 > 127.0.0.1.45134: Flags [P.], seq 
7013825:7017921, ack 2470, win 512, options [nop,nop,TS val 2717208446 ecr 
2717208446], length 4096
E..4=.@.@w.N.)...).
..O~..O~220 543 <1643229...@msgid.manchmal.in-ulm.de> article retrieved - text 
follows
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
[...]
Archived-At: 

Xref: argenau.bebt.de gmane.linux.debian.alioth.pkg-gnupg.general:543


--===7390444919550706840==
Content-Type: multipart
8X--
It hangs there and a couple of minutes later exits and throws
| NNTP connection error. Exiting...

The article is not very useful there seem to be problems with MIME, the
signature does not verify. I have attached a copy from the local
newsspool.

cu Andreas


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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 tin depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.33-5
ii  libcanlock33.3.0-1
ii  libicu67   67.1-7
ii  libncursesw6   6.3-2
ii  libpcre3   2:8.39-13
ii  libtinfo6  6.3-2
ii  libuu0 0.5.20-13

Versions of packages tin recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.95-3

Versions of packages tin suggests:
ii  gnupg   2.2.27-3
pn  ispell  

-- debconf-show failed
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


tin.hangs.article.gz
Description: application/gzip

Bug#1005011: lots of missing entries in debian/copyright

[tony mancill]

On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote:
> Package: capnproto
> please rework your debian/copyright. Especially

Hi Thorsten,

In my previous response, I neglected to say thank you for the thorough
review of the package and its debian/copyright.  Thank you for the
effort and detail you put into these reviews!

Regards,
tony


signature.asc
Description: PGP signature

Bug#1004471: [Pkg-javascript-devel] Bug#1004471: Pending patch for terser-webpack-plugin in webpack 5 till a new upstream for node-terser is uploaded

[Caleb Adepitan]

Sorry for the confusion I've caused. I was hoping mentioning that 
"terser-webpack-plugin embedded in webpack package" in the initial 
wishlist bug report 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004471) stays 
relevant in subsequent discussions under the report.


I probably shouldn't have shared a patch intended for node-webpack 
(terser-webpack-plugin) under a bug filed for node-terser. I only 
thought since the report mentioned that the bug affects webpack it would 
be fine to add some additional info about a pending patch to affected 
packages till the node-terser package is updated. It might help to later 
 know that when node-terser gets updated and the wishlist bug is 
closed, the patch should become irrelevant and be removed from the 
affected package.


The patch intended no changes to node-terser, only the packages affected 
by an incompatible version of node-terser which as I mentioned was 
terser-webpack-plugin embedded in webpack 5.


The only changes intended for node-terser package as mentioned by the 
wishlist bug is to update node-terser to latest upstream, terser 5.


Thanks for taking the time,

Caleb


On 2/5/22 4:04 PM, Jonas Smedegaard wrote:

Quoting Caleb Adepitan (2022-02-05 11:42:51)



On 2/4/22 3:45 PM, Jonas Smedegaard wrote:

Quoting Caleb Adepitan (2022-02-04 08:46:29)

I just arrived at a working patch for terser-webpack-plugin to
circumvent breaking changes in node-terser 5 which is required by
the package. The available version of node-terser in debian is 4
which is behind the terser package upstream.

This patch is an ad-hoc fix for the bug pending the node-terser
package is updated to a compatible version.


This _relates_ to NodeJS module terser, but is it most specifically
tied to terser, webpack, or terser-webpack-plugin?

You post the above to bug#1004471 which is tied to Debian package
node-terser, but your presented patch seems not for terser but for
something else - webpack or terser-webpack-plugin.

Helpful if you can clarify further what fixes what (not only for
what end goal).

[...]

This affects terser-webpack-plugin which affects webpack 5. This patch
relates to *terser-webpack-plugin* (not terser itself) to circumvent
breaking changes in terser 5. The current terser-webpack-plugin has
been adapted to use terser 5 while the version available to it is
terser 4.

The patch makes sure terser 4 continues to work with the package while
not preventing terser 5 also.


You continue to talk about some mysterious "terser-webpack-plugin" which
I fail to locate in Debian, and you do that in a bugreport targeted
"terser".  Do you see how that is confusing?

After some investigation (which I had hoped you would have avoided by
clarifying for me), I discovered that "terser-webpack-plugin" is
embedded in the Debian package "webpackage".

I have now filed bug#1005017 regarding the lack of proper hinting about
that embedded project.  Not your fault that webpack is a mess, but would
have helped regardless if you had mentioned from a *Debian* viewpoint
what you were working on (not only from an NPM viewpoint).

Please, if you want some changes done to the Debian package "terser"
then clarify what that action is (I don't recognize from the previously
attached patch what action for the **ter** package is requested).

Please, if instead you intent no changes for the "terser" package, just
want to notify about progress elsewhere in the stack, then clarify that.


Kind regards, and thanks for your work,

  - Jonas



OpenPGP_0x8A1B2CC96775D2D7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005011: lots of missing entries in debian/copyright

[tony mancill]

Hi Thorsten,

On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote:
> Package: capnproto
> Severity: serious
> Usertags: ftp
> thanks
> 
> Hi,
> 
> please rework your debian/copyright. Especially
> 
>  Kenton Varda
>  Cloudflare, Inc.
>  Google Inc.
>  Nathan C. Myers 
>  Philip Quinn
>  Ian Denhardt
>  Alexander Peslyak
> 
> need to be mentioned.
> Please also check other releases.

Thanks for the bug report.  I will get the debian/copyright updated in
the next upload.  However, I do have a question about the severity of
the bug, which implies that the package is in violation of Debian
policy.

First the bug severity as per
https://www.debian.org/Bugs/Developer#severities:

> serious
>
> is a severe violation of Debian policy (roughly, it violates
> a must or required directive), or, in the package maintainer's or
> release manager's opinion, makes the package unsuitable for release.

And are the sections of Debian policy that pertain to copyright:

- 2.3: 
https://www.debian.org/doc/debian-policy/ch-archive.html#copyright-considerations
- 4.5: 
https://www.debian.org/doc/debian-policy/ch-source.html#copyright-debian-copyright
- 12.5: 
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information
- 12.5.1: 
https://www.debian.org/doc/debian-policy/ch-docs.html#machine-readable-copyright-information

In section 12.5, it states (emphasis on **should** added):

> In addition, the copyright file must say where the upstream sources
> (if any) were obtained, and **should** include a name or contact
> address for the upstream authors. This can be the name of an
> individual or an organization, an email address, a web forum or
> bugtracker, or any other means to unambiguously identify who to
> contact to participate in the development of the upstream source code.

I believe there is ambiguity here.  For this bug to be severity serious,
doesn't policy need to be revised to change "should" to "must" so that
it is clear that **every** upstream author **must** be enumerated in
debian/copyright?  If this is a requirement for software to be part of
Debian, policy should say so directly.

In my personal opinion, policy requiring an exhaustive debian/copyright
is less useful for our users than functioning free software that
correctly documents the provenance of the software, albeit perhaps not
down to the detail of every individual who has ever contributed a line
of code.  I expect that I could trivially find thousands of source
packages in the main archive for which such a requirement does not hold.
But that is beside the point.  The point is that I don't understand the
policy basis upon which this bug is severity serious.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1005006: [Debichem-devel] Bug#1005006: avogadro: manipulation tools do not work

[Andrius Merkys]

Hi Fulvio,

On Sat, 5 Feb 2022, 13:03 fulvio ciriaco,  wrote:

> Package: avogadro
> Version: 1.95.1-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
> past)
>
> clicking on bond centric manipulation or manipulation does nothing.
> the functionality of the mouse remains the same: rotate, translate,
> scale.


This seems to be a usability bug of successfully built and installed
package. Hence ftbfs tag and the justification you have provided do not
seem appropriate.

Andrius

Bug#993570: libvkd3d-doc is not installable besides libvkd3d-dev - still

[Sveinar Søpler]

I guess this package has low priority, as this is used - afaik - only 
for Wine. Since Debian are not able to build more recent Wine than 5.0 
either, it may not get too much attention perhaps?


Sveinar

On 04.02.2022 21:29, Andreas Beckmann wrote:

Followup-For: Bug #993570
Control: found -1 1.2-7

Hi,

the file conflict is still there, these 4 files are shipped in both
packages:

usr/share/doc/libvkd3d-dev/ANNOUNCE.gz
usr/share/doc/libvkd3d-dev/AUTHORS
usr/share/doc/libvkd3d-dev/README
usr/share/doc/libvkd3d-dev/README.debian

This is probably fallout from dh_installdocs in debhelper compat level 11+
where documentation is installed into the doc path of the "main package".

(README.debian is an unusual name, it's usually README.Debian)


Andreas

Bug#1005023: thunderbird subprocess (glxtest) dumps core on startup (with apparmor)

[Bertram Felgenhauer]

Package: thunderbird
Version: 1:91.5.1-1+b2
Severity: normal

Dear Maintainer,

on startup, thunderbird generates a core dump when apparmor is enabled. Apart 
from that, the program works fine.


*** To reproduce:

> thunderbird
[GFX1-]: No GPUs detected via PCI
[GFX1-]: glxtest: process failed (received signal 11)
[...]

> file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 
'/usr/lib/thunderbird/thunderbird', real uid: 1000, effective uid: 1000, real 
gid: 1000, effective gid: 1000, execfn: '/usr/lib/thunderbird/thunderbird', 
platform: 'x86_64'

[Note: in most installations the core dumps will be managed by 
`systemd-coredump`, and probably need to be accessed with `coredumpctl`]


*** Local fix:

# echo '/sys/devices/pci[0-9]*/**/class r,' >> 
/etc/apparmor.d/local/usr.bin.thunderbird
# systemctl restart apparmor.service

This augments the existing rules for /sys/devices/pci in 
/etc/apparmor.d/usr.bin.thunderbird,

  
/sys/devices/pci[0-9]*/**/{device,subsystem_device,subsystem_vendor,uevent,vendor}
 r,

to include the `class` file as well.


*** Supporting analysis:

I installed the -dbgsym packages for thunderbird and libpci to obtain a 
backtrace:

> gdb /usr/lib/thunderbird/thunderbird core
[...]
(gdb) bt
#0  UnexpectedExit() () at ./toolkit/xre/nsAppRunner.cpp:399
#1  0x7fa0be447f67 in __run_exit_handlers (status=status@entry=1, 
listp=0x7fa0be5c5738 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at 
exit.c:108
#2  0x7fa0be44810a in __GI_exit (status=status@entry=1) at exit.c:139
#3  0x7fa0b30998e1 in pci_generic_error (msg=0x7fa0b30a1415 "Cannot open 
%s: %s") at init.c:131
#4  0x7fa0b309ece2 in sysfs_get_string (d=d@entry=0x7fa0be2d2120, 
object=object@entry=0x7fa0b30a1bd2 "class", buf=buf@entry=0x7ffccff099a0 
"0x6fb5\n", mandatory=mandatory@entry=1) at sysfs.c:103
#5  0x7fa0b309f508 in sysfs_get_value (mandatory=1, object=0x7fa0b30a1bd2 
"class", d=0x7fa0be2d2120) at sysfs.c:145
#6  sysfs_fill_info (d=0x7fa0be2d2120, flags=33) at sysfs.c:311
#7  0x7fa0b309a27f in pci_fill_info_v35 (d=d@entry=0x7fa0be2d2120, 
flags=flags@entry=33) at access.c:201
#8  0x7fa0b7a477f6 in get_pci_status() () at ./toolkit/xre/glxtest.cpp:391
#9  childgltest() () at ./toolkit/xre/glxtest.cpp:1354
#10 0x7fa0b7a48136 in fire_glxtest_process() () at 
./toolkit/xre/glxtest.cpp:1403
#11 0x7fa0b7a3d90b in XREMain::XRE_mainInit(bool*) (this=, 
this@entry=0x7ffccff0a920, aExitFlag=aExitFlag@entry=0x7ffccff0a8af) at 
./toolkit/xre/nsAppRunner.cpp:3623
#12 0x7fa0b7a44588 in XREMain::XRE_main(int, char**, 
mozilla::BootstrapConfig const&) (this=this@entry=0x7ffccff0a920, 
argc=argc@entry=1, argv=argv@entry=0x7ffccff0bb98, aConfig=...) at 
./toolkit/xre/nsAppRunner.cpp:5408
#13 0x7fa0b7a44970 in XRE_main(int, char**, mozilla::BootstrapConfig 
const&) (argc=1, argv=0x7fa0b7a3e5c0 , aConfig=...) at 
./toolkit/xre/nsAppRunner.cpp:5493
#14 0x559272bf7198 in do_main(int, char**, char**) (argc=1, 
argv=0x7ffccff0bb98, envp=) at ./comm/mail/app/nsMailApp.cpp:229
#15 main(int, char**, char**) (argc=, argv=, 
envp=) at ./comm/mail/app/nsMailApp.cpp:368
(gdb) frame 4
(gdb) print mandatory
$1 = 1
(gdb) print (char *)namebuf
$2 = 0x7ffccff09100 "/sys/bus/pci/devices/:ff:15.1/class"
(gdb) q

So we're hitting this code in libpci,

  https://github.com/pciutils/pciutils/blob/v3.7.0/lib/sysfs.c#L103

and because `mandatory` is set this is treated as an error by libpci.

dmesg points to apparmour as the cause:

# dmesg
[...]
[21096.091105] audit: type=1400 audit(1644074114.165:64): apparmor="DENIED" 
operation="open" profile="thunderbird" 
name="/sys/devices/pci:ff/:ff:15.1/class" pid=118142 comm="thunderbird" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[21096.091119] thunderbird[118142]: segfault at 0 ip 7fa0b7a3e5e7 sp 
7ffccff08fa0 error 6 in libxul.so[7fa0b47d5000+4e9b000]
[...]


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.1
ii  fontconfig   2.13.1-4.4
ii  libatk1.0-0  2.36.0-3
ii  libbotan-2-192.19.1+dfsg-2
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-5
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-1
ii  libgcc-s1 

Bug#1005022: RFS: lebiniou/3.65.0-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.65.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.65.0-1.dsc

Changes since the last upload:

  * New upstream release 3.65.0.
  * src/Makefile.am: Fix dh_shlibdeps issues.
  * debian/copyright: Update copyright years.
  * plugins/main/video/video.c: Fix FTBFS with ffmpeg 5.0 (Closes: 
#1004722)


Regards,

--
Olivier Girondel

Bug#1005021: RFS: lebiniou-data/3.65.0-1 -- datafiles for Le Biniou

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.65.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.65.0-1.dsc

Changes since the last upload:

  * New upstream release 3.65.0.

Regards,

--
Olivier Girondel

Bug#1005020: RM: rust-rand-os -- ROM; obsolete and uninstallable/unbuildable

[plugwash]

Package: ftp.debian.org
Severity: normal

Upstream incorportated functionality in the rand_os crate into the
rand_core crate and deprecated the rand_os crate over two years ago.
There have been no further releases since the release announcing the
deprecation and the crate no longer appears in the master branch of the upstream
git repository.

The dependencies and build-dependencies of rust-rand-os are no longer
satisfiable with the new version of the rand_core crate that I have just
uploaded to Debian.

All the former reverse dependencies of the crate in Debian have now moved
away from it, so I think it's time for the crate to go. I filed a "should this
package be remove" bug a fortnight ago in case any other rust team members had
an opinion on the issue and received no responses.

Bug#1005019: rust-nitrocli fails to build with debhelper compat 12.

[peter green]

Package: rust-nitrocli
Version: 0.2.4-1

I was preparing a "no-change" reupload of rust-nitrocli, so it would no longer
be built against the obsolete rust-rand-os package (for which I plan to file
a removal request). Since I prepared this with debcargo, it picked up an 
increase
in debcargos default debheper compat level from 11 to 12. This resulted in a 
build
failure.


   dh_dwz -O--buildsystem=cargo
dwz: debian/nitrocli/usr/bin/nitrocli: Couldn't find DIE at [c13b] referenced 
by DW_AT_abstract_origin from DIE at [1d11a]
dh_dwz: error: dwz -- debian/nitrocli/usr/bin/nitrocli returned exit code 1
dh_dwz: error: Aborting due to earlier error
make: *** [debian/rules:3: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


I have set the debhelper compat level for the package back to 11 for now, but
I feel this is something that should be documented in a bug report.

Bug#1005018: [procps] snice: does not work anymore in 3.3.15

[Roman Mamedov]

Hello,

I guess this is a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903540

But Buster currently has the broken version. In that case please consider this
as a request to update the version there.

-- 
With respect,
Roman

Bug#1004471: [Pkg-javascript-devel] Bug#1004471: Pending patch for terser-webpack-plugin in webpack 5 till a new upstream for node-terser is uploaded

[Jonas Smedegaard]

Quoting Caleb Adepitan (2022-02-05 11:42:51)
> 
> 
> On 2/4/22 3:45 PM, Jonas Smedegaard wrote:
> > Quoting Caleb Adepitan (2022-02-04 08:46:29)
> >> I just arrived at a working patch for terser-webpack-plugin to 
> >> circumvent breaking changes in node-terser 5 which is required by 
> >> the package. The available version of node-terser in debian is 4 
> >> which is behind the terser package upstream.
> >>
> >> This patch is an ad-hoc fix for the bug pending the node-terser 
> >> package is updated to a compatible version.
> > 
> > This _relates_ to NodeJS module terser, but is it most specifically 
> > tied to terser, webpack, or terser-webpack-plugin?
> > 
> > You post the above to bug#1004471 which is tied to Debian package 
> > node-terser, but your presented patch seems not for terser but for 
> > something else - webpack or terser-webpack-plugin.
> > 
> > Helpful if you can clarify further what fixes what (not only for 
> > what end goal).
[...]
> This affects terser-webpack-plugin which affects webpack 5. This patch 
> relates to *terser-webpack-plugin* (not terser itself) to circumvent 
> breaking changes in terser 5. The current terser-webpack-plugin has 
> been adapted to use terser 5 while the version available to it is 
> terser 4.
> 
> The patch makes sure terser 4 continues to work with the package while 
> not preventing terser 5 also.

You continue to talk about some mysterious "terser-webpack-plugin" which 
I fail to locate in Debian, and you do that in a bugreport targeted 
"terser".  Do you see how that is confusing?

After some investigation (which I had hoped you would have avoided by 
clarifying for me), I discovered that "terser-webpack-plugin" is 
embedded in the Debian package "webpackage".

I have now filed bug#1005017 regarding the lack of proper hinting about 
that embedded project.  Not your fault that webpack is a mess, but would 
have helped regardless if you had mentioned from a *Debian* viewpoint 
what you were working on (not only from an NPM viewpoint).

Please, if you want some changes done to the Debian package "terser" 
then clarify what that action is (I don't recognize from the previously 
attached patch what action for the **ter** package is requested).

Please, if instead you intent no changes for the "terser" package, just 
want to notify about progress elsewhere in the stack, then clarify that.


Kind regards, and thanks for your work,

 - 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#1005017: webpack: embeds NodeJS module terser-webpack-plugin without corresponding Provides: hint

[Jonas Smedegaard]

Package: webpack
Version: 4.43.0-7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binary package webpack embeds NodeJS module terser-webpack-plugin, but
lack declaring corresponding hint "Provides: node-terser-webpack-plugin".

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmH+jzYACgkQLHwxRsGg
ASGkxA/7BFVmGSQN73wpQKPA2jL6advedSD22jKTzyc8YGFNLALAGq78dqHxxmGq
8yhyu8RN1UzEEiA3vVjvJeC6Dej86Qo3WwdO9nEJD0KuHeBFp0BA35+VRBB8/72I
0+eVJ1VSw7UG87OXVA3fmXJoElajG9O1s/Jx2SuRYZRgTGNmJrI+d9p/5RUxUwmu
S5M915uo70OArhLkaKTb55UkmuXZRuLQoSxSOxGys1sX19fTodmiAAdvK+KLPBGF
2w8P6SmRSE+5UMCkiBTjtx0NnOYVmOKCDi3+mDX+yszW7xyeGLtHD0hBwaIApYod
xnWWQZ+dOWHapdT+MD6WoaifVu0UP5nKluM41mDOyrJu6Op55LWhTq5bcwld5nlD
WhUKN5HV237M8PTxaV6+WSi8Iclh3MFQKOHFfcfRrnHXGmLBPQX+O4VnuoSJZUYj
xcgLoboDbG9LvsWj9LW8kLiTLCj+Wuj52Sj0bu5tRMwtFBXWXiTyf9fOefA1RTRc
bgKawNeInvJ2qLYa+FepRaity/FXOR9YcDgrJlgs5TYTOYGdIZerIsNtcqb9AOoW
SEpkuYzYc8ZpAsrj0zo+wYQFKRptkAFJPIHQ4mQssMaFt2FCG2Vhbu+s2xUzEcWn
zGVY/GH0AV/TIL67T6vIgFcRXX24kkeo1NlE00JkGHyXIXYEc9M=
=nz81
-END PGP SIGNATURE-

Bug#1005018: [procps] snice: does not work anymore in 3.3.15

[Roman Mamedov]

Package: procps
Version: 2:3.3.15-2
Severity: normal

snice has no effect on process priority anymore, neither when invoked with the 
process
name, nor with a user name.

With version 3.3.9 it worked fine. I did not test versions in-between.

Running a process of:

  sleep 3600

And doing:

  snice +20 sleep

Results in the following strace snippet for 3.3.15:

  openat(AT_FDCWD, "/proc/7135/stat", O_RDONLY) = 4
  fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
  read(4, "7135 (sleep) S 6836 7135 6836 34"..., 128) = 128
  close(4)

Downgrading to 3.3.9 and repeating:

  openat(AT_FDCWD, "/proc/7135/stat", O_RDONLY) = 4
  fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
  read(4, "7135 (sleep) S 6836 7135 6836 34"..., 128) = 128
  openat(AT_FDCWD, "/proc/tty/drivers", O_RDONLY) = 5
  read(5, "/dev/tty /dev/tty   "..., ) = 465
  close(5)= 0
  stat("/dev/pts2", 0x7fff202e0460)   = -1 ENOENT (No such file or 
directory)
  stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  readlink("/proc/7135/fd/2", "/dev/pts/2", 127) = 10
  stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x2), ...}) = 0
  setpriority(PRIO_PROCESS, 7135, 20) = 0
  close(4)

-- 
With respect,
Roman

Bug#1005016: libobject-pad-slotattr-final-perl: Object::Pad::SlotAttr::Final is replaced by Object::Pad::FieldAttr::Final

[gregor herrmann]

Source: libobject-pad-slotattr-final-perl
Version: 0.04-2
Severity: normal
X-Debbugs-Cc: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I noticed that libobject-pad-slotattr-final-perl fails its
autopkgtests because of a deprecation warning:

autopkgtest [15:14:29]: test autodep8-perl: 
/usr/share/pkg-perl-autopkgtest/runner runtime-deps
autopkgtest [15:14:29]: test autodep8-perl: [---

#   Failed test ' /usr/bin/perl -w -M"Object::Pad::SlotAttr::Final" -e 1 2>&1 
produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 107.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Object::Pad::SlotAttr::Final" -e 1 2>&1 produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 107.
# Looks like you failed 2 tests of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
1..4
# register_slot_attribute() is now deprecated; use register_field_attribute() 
instead at /usr/lib/x86_64-linux-gnu/perl-base/XSLoader.pm line 111.
ok 1 -  /usr/bin/perl -w -M"Object::Pad::SlotAttr::Final" -e 1 2>&1 exited 
successfully
not ok 2 -  /usr/bin/perl -w -M"Object::Pad::SlotAttr::Final" -e 1 2>&1 
produced no (non-whitelisted) output
# register_slot_attribute() is now deprecated; use register_field_attribute() 
instead at /usr/lib/x86_64-linux-gnu/perl-base/XSLoader.pm line 111.
ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Object::Pad::SlotAttr::Final" 
-e 1 2>&1 exited successfully
not ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Object::Pad::SlotAttr::Final" -e 1 2>&1 produced no (non-whitelisted) output
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/4 subtests 

Test Summary Report
- ---
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t (Wstat: 512 Tests: 4 
Failed: 2)
  Failed tests:  2, 4
  Non-zero exit status: 2
Files=1, Tests=4,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.09 cusr  0.02 
csys =  0.13 CPU)
Result: FAIL
autopkgtest [15:14:29]: test autodep8-perl: ---]
autopkgtest [15:14:30]: test autodep8-perl:  - - - - - - - - - - results - - - 
- - - - - - -


This warning comes from Object::Pad 0.60 which renamed 'slots' to
'fields'.

Now in libobject-pad-slotattr-final-perl we could silence the
autopkgtest warnings or we could patch the code but still the module
and the package would be called *slot* …

So I looked at the MetaCPAN, and indeed, there is a renamed
distribution available: https://metacpan.org/dist/Object-Pad-FieldAttr-Final

I guess we should replace libobject-pad-slotattr-final-perl with
libobject-pad-fieldattr-final-perl …


Well, and this is not the only package with 'slot':

% apt-cache --names-only search libobject-pad-slot | grep -v dbgsym
libobject-pad-slotattr-final-perl - declare Object::Pad slots readonly after 
construction
libobject-pad-slotattr-isa-perl - apply class type constraints to Object::Pad 
slots
libobject-pad-slotattr-lazyinit-perl - lazily initialise Object::Pad slots at 
first read
libobject-pad-slotattr-trigger-perl - invoke an instance method after a :writer 
accessor

 
Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmH+iWJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbCnA/8C/FumDm2bljlUNhzbbrj00nUSB1BMjE254opiGGF+jqHVvoPjbcRoIbg
APPkugDOgyDOa+3MeEnwPN1jpxROiJHDrKgrtY0mLmP14BDk+SbMO6S9MDzq8QV3
xNuQs0Gvmy+ZF7rJLkt3jkE31SDKl16UytHG/1KmNMieaKJj44zhaptv1mACHr4E
Bvy/avAS/vzrnqY+2g7KGno0pdxNj8tFMFdqf0FviXuUFcEqM5fgbJN/wBMDgKr5
qpmZnlXXVcgOPMRH/QF85byrll5FPcGf67Uy6t44cU9DLVM6JSsRtlctU8mzE6Ry
I3iloE2ly2Mb8dUYPRPs1dvAUlfs6N814kQrHEZ3f0AQLw1vPMRXYXFRS6Qzg6iD
CMtQt/7ql5wKfnJ5Cl2Ja5v6LOSmC+3GyPCIVkuRknXdZw0xFuF39f+nsjuRCvLp
ZBjp2/ANFI5iCYCqlS3xkOEH/f2hHA+UCnKoIAmQLQthOqByOaWFiMibT8t+8G/5
uLi1CTdRTqO+v5zyGlrWsnx8CtNlxuLkt0aZbi3glpWSbdpUYgVtumAqYtVMRUDe
aN4l0GI1qIvG6n4BnXk+caczR7jkxqP78+DwiT9utMOxsd1jJKqedQSwh9mISoPy
ttyVJuXZrvtS4gom5rZOMfmL4yEqtkAmEIE8CIk9p4vT+QU9Q2g=
=eSHN
-END PGP SIGNATURE-

Bug#1005015:

[Andreas Hasenack]

Salsa PR at 
https://salsa.debian.org/python-team/packages/mando/-/merge_requests/2

Bug#1005015: mando: ftbfs (test failures) with python 3.10

[Andreas Hasenack]

Package: mando
Version:
Severity: normal

Dear Maintainer,

current mando package fails to build whith python 3.10 due to test
failures. There are two cases:

a) collections import, fixed in upstream 0.7.0:
...
 File "/home/ubuntu/git/packages/mando/mando/mando/core.py", line 107,
in _generate_command
doc = str(GoogleDocstring(doc, config))
  File "/home/ubuntu/git/packages/mando/mando/mando/napoleon/docstring.py",
line 115, in __init__
elif isinstance(obj, collections.Callable): # type: ignore
AttributeError: module 'collections' has no attribute 'Callable'

Patch:
--- mando/mando/napoleon/docstring.py   2022-02-05 13:54:55.001545246 +
+++ mando-0.7.0/mando/napoleon/docstring.py 2020-03-16
11:01:40.0 +
@@ -11,7 +11,10 @@
 :license: BSD, see LICENSE for details.
 """

-import collections
+try:
+from collections.abc import Callable
+except ImportError:
+from collections import Callable
 import inspect
 import re

@@ -112,7 +115,7 @@
 what = 'class'
 elif inspect.ismodule(obj):
 what = 'module'
-elif isinstance(obj, collections.Callable):  # type: ignore
+elif isinstance(obj, Callable):  # type: ignore
 what = 'function'
 else:
 what = 'object'


b) help output, with a patch in https://github.com/rubik/mando/pull/54
=== FAILURES ===
_ test_google_docstring_help[simple_google_docstring --help 2
--arg2=test-usage: example.py simple_google_docstring [-h] [--arg2
ARG2] arg1\n\nExtended description.\n\npositional arguments:\n arg1
Description of `arg1`\n\noptional arguments:\n -h, --help show this
help message and exit\n --arg2 ARG2 Description of `arg2`\n] _

args = ['simple_google_docstring', '--help', '2', '--arg2=test']
result = 'usage: example.py simple_google_docstring [-h] [--arg2 ARG2]
arg1\n\nExtended description.\n\npositional arguments:\n...
`arg1`\n\noptional arguments:\n -h, --help show this help message and
exit\n --arg2 ARG2 Description of `arg2`\n'

@pytest.mark.parametrize('args,result', GOOGLE_DOCSTRING_HELP_CASES)
def test_google_docstring_help(args, result):
args = args.split()
with pytest.raises(SystemExit):
with capture.capture_sys_output() as (stdout, stderr):
program.execute(args)
> assert result == stdout.getvalue()
E AssertionError: assert 'usage: examp...n of `arg2`\n' == 'usage:
examp...n of `arg2`\n'
E Skipping 146 identical leading characters in diff, use -v to show
E 1`
E
E - options:
E + optional arguments:
E -h, --help show this help message and exit
E --arg2 ARG2 Description of `arg2`

mando/tests/test_google.py:57: AssertionError
_ test_numpy_docstring_help[simple_numpy_docstring --help 2
--arg2=test-usage: example.py simple_numpy_docstring [-h] [--arg2
ARG2] arg1\n\nExtended description.\n\npositional arguments:\n arg1
Description of `arg1`\n\noptional arguments:\n -h, --help show this
help message and exit\n --arg2 ARG2 Description of `arg2`\n] _

args = ['simple_numpy_docstring', '--help', '2', '--arg2=test']
result = 'usage: example.py simple_numpy_docstring [-h] [--arg2 ARG2]
arg1\n\nExtended description.\n\npositional arguments:\n ...
`arg1`\n\noptional arguments:\n -h, --help show this help message and
exit\n --arg2 ARG2 Description of `arg2`\n'

@pytest.mark.parametrize('args,result', NUMPY_DOCSTRING_HELP_CASES)
def test_numpy_docstring_help(args, result):
args = args.split()
with pytest.raises(SystemExit):
with capture.capture_sys_output() as (stdout, stderr):
program.execute(args)
> assert result == stdout.getvalue()
E AssertionError: assert 'usage: examp...n of `arg2`\n' == 'usage:
examp...n of `arg2`\n'
E Skipping 145 identical leading characters in diff, use -v to show
E 1`
E
E - options:
E + optional arguments:
E -h, --help show this help message and exit
E --arg2 ARG2 Description of `arg2`

mando/tests/test_numpy.py:62: AssertionError
=== short test summary info 
FAILED 
mando/tests/test_google.py::test_google_docstring_help[simple_google_docstring
--help 2 --arg2=test-usage: example.py simple_google_docstring [-h]
[--arg2 ARG2] arg1\n\nExtended description.\n\npositional arguments:\n
arg1 Description of `arg1`\n\noptional arguments:\n -h, --help show
this help message and exit\n --arg2 ARG2 Description of `arg2`\n]
FAILED 
mando/tests/test_numpy.py::test_numpy_docstring_help[simple_numpy_docstring
--help 2 --arg2=test-usage: example.py simple_numpy_docstring [-h]
[--arg2 ARG2] arg1\n\nExtended description.\n\npositional arguments:\n
arg1 Description of `arg1`\n\noptional arguments:\n -h, --help show
this help message and exit\n --arg2 ARG2 Description of `arg2`\n]
= 2 failed, 77 passed in 0.20s =

Bug#1003176: transition: perl 5.34

[Niko Tyni]

On Sat, Feb 05, 2022 at 12:40:53PM +0200, Niko Tyni wrote:

> Uploading this afternoon.

perl_5.34.0-3 uploaded and accepted.
-- 
Niko

Bug#1005014: dwarves: autopkgtest fails on ppc64el

[Domenico Andreoli]

Package: src:dwarves
Version: 1.22-5

Starting with 1.22-5, a minimal kernel is built as part of the
autopkgtest tests suite.

Such test fails on ppc64el with the following error:

...
  AR  fs/notify/fanotify/built-in.a
  AR  fs/notify/built-in.a
  AR  fs/iomap/built-in.a
  AR  fs/quota/built-in.a
  AR  fs/devpts/built-in.a
  CC  fs/ramfs/inode.o
  CC  mm/mmap.o
  CC  kernel/notifier.o
  CC  fs/ramfs/file-mmu.o
  CC  kernel/ksysfs.o
  AR  fs/ramfs/built-in.a
  CC  fs/open.o
{standard input}: Assembler messages:
{standard input}:4494: Error: unrecognized opcode: `ptesync'
make[2]: *** [scripts/Makefile.build:282: arch/powerpc/lib/sstep.o] Error 1
make[1]: *** [scripts/Makefile.build:545: arch/powerpc/lib] Error 2
make: *** [Makefile:1892: arch/powerpc] Error 2
make: *** Waiting for unfinished jobs
...

Bug #885245 [0] is related although does not suggest a solution. 

Full log is attached [1].

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885245
[1] 
https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dwarves/18953887/log.gz

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


log.gz
Description: application/gzip

Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)

[Emmanuel Kasper]

On 2/3/22 22:58, Hans-Christoph Steiner wrote:

 > - you add to your pull request a change of the virtualized disk
 > controller from virtio-blk to virtio-scsi and to the default libvirt
 > vagrantfile the "unmap" option so that deletion of blocks in the guest
 > are propagated om host storage

I looked into this a bit more.  These feature weren't added to 
vagrant-libvirt until 0.4.0, so no stable Debian package of 
vagrant-libvirt could support this yet.  Debian/testing has 0.7.0, and a 
backport to stable would be possible.  I guess a lot of people just use 
`vagrant plugin install ...`. It might be possible to make it work with 
older vagrant-libvirt versions by using a hack like this:


https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692#issuecomment-922329049 




There is a little more info here:
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/999#issuecomment-487728207 




```
ENV['VAGRANT_EXPERIMENTAL'] = 'typed_triggers'

require 'open3'

Vagrant.configure('2') do |config|
   ...
   config.vm.provider :libvirt do |lv, config|
     lv.storage :file, :size => '3G', :device => 'sda', :bus => 'scsi', 
:discard => 'unmap', :cache => 'unsafe'
     config.trigger.before 
:'VagrantPlugins::ProviderLibvirt::Action::StartDomain', type: :action 
do |trigger|

   trigger.ruby do |env, machine|
     stdout, stderr, status = Open3.capture3(
   'virt-xml', machine.id,
   '--edit', 'type=scsi',
   '--controller', 'model=virtio-scsi')
     if status.exitstatus != 0
   raise "failed to run virt-xml to modify the controller model. 
status=#{status.exitstatus} stdout=#{stdout} stderr=#{stderr}"

     end
   end
     end
     ...
   end
end
```


Hi Hans-Christoph

I had a look at this and it looks like although we can now set via the 
`disk_driver` options to use `discard` when a SCSI controller is 
choosed, it is still not possible to set the SCSI controller `model` to 
virtio-scsci via a vagrant-libvirt option. Without a virtio-scsi SCSI 
controller I/O will be 10 times slower.


We could actually force the controller model and the discard option 
manually in the Vagrantfile shipped by the box using the hack/workaround 
you pasted above. But the :action trigger used there is an experimental 
feature, requiring VAGRANT_EXPERIMENTAL="typed_triggers" to be set.

So this is too much of an over stretch here at the momment.

When time allows, I will now try to use a box with virtio-fs and see how 
it works against NFS as this seem to be way the way forward (maybe use 
virtio-fs instead of NFS too by default for libvirt too)


Emmanuel




--
You know an upstream is nice when they even accept m68k patches.
  - John Paul Adrian Glaubitz, Debian OpenJDK maintainer

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

[Guillem Jover]

Hi!

On Fri, 2022-02-04 at 19:35:10 -0800, Noah Meyerhans wrote:
> Control: reassign -1 src:dpkg
> Control: severity -1 wishlist
> 
> > root@debian:~# ls -l `which ping`
> > -rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping
> > root@debian:~# getcap `which ping`
> > /usr/bin/ping cap_net_raw=ep
> > root@debian:~#
> > 
> > 
> > This looks like a limitation that would only be possible to solve by
> > dpkg and extending tar / cpio probably.
> > 
> > >From what I found it is possible to do this with tar and
> > --xattrs-include='security.capability'  when packing and unpacking.
> > 
> > There is some hacky non-standard patches for cpio,
> > https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef
> > , but afaik not upstreamed.
> > And even more hacky support in kernel for initramfs uses:
> > https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg1.html
> > 
> > I didn't see any real updates on this topic, last one is from middle of 
> > 2019.
> 
> I'm reassigning this to dpkg as a wishlist item.  If the problem is
> going to be fixed, it's going to happen at a layer more fundamental to
> package management.
> 
> Context for the dpkg maintainers:

[ Thanks! Only thing missing was an explicit Cc to
  d...@packages.debian.org or similar, as the BTS does not do that. :/ ]

> Ping requires elevated privileges in order to open its ICMP network
> sockets.  The postinst script attempts to set a file-based cap_net_raw
> capability on the binary after installation, and falls back to setuid in
> case that fails (usually due to missing filesystem support for file
> capabilities).  This workflow is racy, however, as there's a period of
> time when the file exists on disk but has not had any privilege
> acquisition mechanism applied to it.  During this period of time,
> unprivileged users cannot run this program, when otherwise they could.
> Elimination of this race situation would likely require the ability for
> dpkg to initially create files with additional file-based capabilities.

So, implementing this in dpkg, would require at least the upcoming
metadata tracking support
, which is
currently blocked. Another approach to get similar results would be
just having support in dpkg-statoverride (tracked in #502580).

But a way to implement this more reliably already in iputils would be
to ship the file in the .deb as set-UID-root (so that it always can
work), and apply the POSIX capabilities and remove the set-UID-root
bit in the maintscript if the system supports the former.

Thanks,
Guillem

Bug#1005013: bullseye-pu: package cinnamon/4.8.6-2+deb11u1

[Fabio Fantoni]

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

[ Reason ]
When an user attempts to add an online account that requires logging in 
through

a web component, such as, Google, Facebook, Microsoft and/or Foursquare,
cinnamon-settings crashes and quits without any further prompt or message.

[ Impact ]
As reported in #1001536 for now is not possible add online account for 
many services in Bullseye


[ Tests ]
With the fix add online account that require login account that before 
was impossible set it correctly and works, I tried the google one on my 
test, also the user that reported it have tested and reported that with 
the fix is working: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001536#36
I don't saw regression, other user that tested it also didn't reported 
regression and I don't saw regression upstream about it.


[ Risks ]
The patch is small and already tested for long time upstream and other 
distros who have been using cinnamon 5.2.1 just released, even more than 
2 months; on debian has instead delayed a lot due to 
inability/difficulty to upload packages for a period, the version 
including the fix has been in experimental since 2021-12-31 and unstable 
since 2022-01-27


[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Changes to /usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py

[ Other info ]
n/a
diff -Nru cinnamon-4.8.6/debian/changelog cinnamon-4.8.6/debian/changelog
--- cinnamon-4.8.6/debian/changelog 2021-02-15 01:12:15.0 +0100
+++ cinnamon-4.8.6/debian/changelog 2022-02-05 13:16:03.0 +0100
@@ -1,3 +1,11 @@
+cinnamon (4.8.6-2+deb11u1) bullseye; urgency=medium
+
+  * d/patches: add upstream patch that solves a crash adding
+an online account with login on web component (Closes: #1001536)
+  * change vcs-git, CI and gbp to bullseye
+
+ -- Fabio Fantoni   Sat, 05 Feb 2022 13:16:03 +0100
+
 cinnamon (4.8.6-2) unstable; urgency=medium
 
   [ Fabio Fantoni ]
diff -Nru cinnamon-4.8.6/debian/control cinnamon-4.8.6/debian/control
--- cinnamon-4.8.6/debian/control   2021-02-15 01:12:15.0 +0100
+++ cinnamon-4.8.6/debian/control   2022-02-05 13:16:03.0 +0100
@@ -40,7 +40,7 @@
 Standards-Version: 4.5.0
 Homepage: http://cinnamon.linuxmint.com
 Vcs-Browser: https://salsa.debian.org/cinnamon-team/cinnamon
-Vcs-Git: https://salsa.debian.org/cinnamon-team/cinnamon.git
+Vcs-Git: https://salsa.debian.org/cinnamon-team/cinnamon.git -b bullseye
 
 Package: cinnamon
 Architecture: any
diff -Nru cinnamon-4.8.6/debian/gbp.conf cinnamon-4.8.6/debian/gbp.conf
--- cinnamon-4.8.6/debian/gbp.conf  2021-02-15 01:12:15.0 +0100
+++ cinnamon-4.8.6/debian/gbp.conf  2022-02-05 13:16:03.0 +0100
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = bullseye
diff -Nru cinnamon-4.8.6/debian/patches/fix-crash-online-account.patch 
cinnamon-4.8.6/debian/patches/fix-crash-online-account.patch
--- cinnamon-4.8.6/debian/patches/fix-crash-online-account.patch
1970-01-01 01:00:00.0 +0100
+++ cinnamon-4.8.6/debian/patches/fix-crash-online-account.patch
2022-02-05 13:16:03.0 +0100
@@ -0,0 +1,77 @@
+Author: Michael Webster 
+Date: Fri, 19 Nov 2021 21:33:02 -0500
+Description: [PATCH] Make cinnamon-settings a minimal GApplication to 
accomodate
+ webkit.
+
+GApplication is required for xdg-desktop-portal access in the WebKit sandbox.
+
+https://forums.fedoraforum.org/showthread.php?327343-Gnome-Online-Accounts-Unusable-In-F35-Cinnamon-GUI-Consistently-Crashes-Vanishes
+
+Origin: 
https://github.com/linuxmint/cinnamon/commit/77ed66050f7df889fcb7a10b702c7b8bcdeaa130
+---
+ .../cinnamon-settings/cinnamon-settings.py| 21 +--
+ 1 file changed, 15 insertions(+), 6 deletions(-)
+
+--- a/files/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py
 b/files/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py
+@@ -163,7 +163,7 @@
+ os.utime(fname, times)
+ 
+ 
+-class MainWindow:
++class MainWindow(Gio.Application):
+ # Change pages
+ def side_view_nav(self, side_view, path, cat):
+ selected_items = side_view.get_selected_items()
+@@ -257,6 +257,9 @@
+ 
+ # Create the UI
+ def __init__(self):
++Gio.Application.__init__(self,
++ application_id="org.cinnamon.Settings_%d" % 
os.getpid(),
++ flags=Gio.ApplicationFlags.NON_UNIQUE | 
Gio.ApplicationFlags.HANDLES_OPEN)
+ self.builder = Gtk.Builder()
+ self.builder.set_translation_domain('cinnamon')  # let it translate!
+ self.builder.add_from_file(config.currentPath + 
"/cinnamon-settings.ui")
+@@ -294,7 +297,7 @@
+ 

Bug#1005012: ITP: mptcpd -- Multipath TCP Daemon

[Matthieu Baerts]

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

* Package name: mptcpd
  Version : 0.9
  Upstream Author : Ossama Othman 
* URL : https://github.com/intel/mptcpd
* License : BSD-3-Clause
  Programming Lang: C
  Description : Multipath TCP Daemon

The Multipath TCP Daemon - mptcpd - is a daemon for Linux based
operating systems that performs Multipath TCP path management related
operations in the user space.
It interacts with the Linux kernel through a generic Netlink
connection to track per-connection information (e.g. available remote
addresses), available network interfaces, request new MPTCP subflows,
handle requests for subflows, etc.

Why is this package useful/relevant?

  MPTCP support is available in the Linux kernel since v5.6. The work
  on the kernel side is still in progress:

  https://github.com/multipath-tcp/mptcp_net-next/wiki

  This userspace daemon is useful to configure a host to support
  Multipath TCP: it interacts with the kernel to track and request
  MPTCP-related features.

How do you plan to maintain it?

  I'm part of the Linux MPTCP Upstream Project team, mostly working
  on the kernel side. But here, I'm also helping to package this
  software. We have regular meetings to follow up on different aspects
  linked to this project. We then keep track of mptcpd development as
  well which should help to maintain it. I don't know if this package
  would fit into an existing team. mptcpd is fairly standard and is
  not really complex to package.

Do you need a sponsor?

  I will need a mentor as even if it is not the first time I'm
  packaging softwares for Debian/Ubuntu, it is the first time I'm
  going to send the initial version of a package for Debian.

Bug#1004883: intel-graphics-compiler: switch to llvm-toolchain-13

[Andreas Beckmann]

On 03/02/2022 18.46, Andreas Beckmann wrote:
In order to build intel-graphics-compiler against llvm-11 we would need 
to reintroduce spirv-llvm-translator and intel-opencl-clang built 
against llvm-11. These are tightly coupled to the llvm version being 
used and will change the soname accordingly. I would therefore 
reintroduce them as new source packages with '-11' appended.

Would adding two more source packages depending on llvm-11 be OK?
That's the only solution I see for making intel-compute-runtime 
buildable again on a short time frame.


I've now managed to do the same with llvm-12, so I'd rather introduce 
src:spirv-llvm-translator-12 and src:opencl-clang-12 and leave llvm-11 
alone ;-)



Andreas

PS: Looking ahead into the future: If llvm continues to do two major 
releases per year (Mar/Apr, Sept/Oct), which llvm versions are likely 
available at the time we freeze bookworm (guessing early 2023, so 
llvm-15 should be out) and which llvm versions (and which default) would 
you like to release with bookworm?

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

On 05/02/2022 06:35, nick black wrote:

Victor Westerhuis left as an exercise for the reader:

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


i've also forked this, and have been working on it a bit over
the past year:

  https://github.com/dankamongmen/kmscon

if the other fork is more active, i'm happy to fold my changes
into it, but they definitely ought go in there. the most
important thing i recall doing was fixing the cursor location
report to use the proper order for coordinates.



Thanks for bringing your fork to my attention. I can see you have an 
open issue for the cursor location coordinates, but I don't see any 
commits related to that in the history of the master branch.


The two fixes I can see, for the removal of SIGUNUSED and adding an 
include for sys/sysmacros.h have also been implemented in Aetf's branch.


Aetf's fork has some additional functionality, so I would prefer to use 
that. However, in the course of packaging kmscon I've also opened some 
PRs on Github and they've responded very quickly. If you have a fix, I'm 
sure they'll happily take it as well.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005011: lots of missing entries in debian/copyright

[Thorsten Alteholz]

Package: capnproto
Severity: serious
Usertags: ftp
thanks

Hi,

please rework your debian/copyright. Especially

 Kenton Varda
 Cloudflare, Inc.
 Google Inc.
 Nathan C. Myers 
 Philip Quinn
 Ian Denhardt
 Alexander Peslyak

need to be mentioned.
Please also check other releases.

Thanks!
  Thorsten

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

On 05/02/2022 13:05, nick black wrote:
> indeed, the cursor location report fix is only on a branch. i'll
> go ahead and submit it to this other fork, and rebase mine off
> of theirs. thank you likewise for bringing this to my attention!
> i'm glad to see kmscon getting some love.

That would be great. I'd like to ask Aetf for a versioned release as 
well, but first I'd like to get composing working. There's an open issue 
for that and I independently had a patch for that as well, so I'll see 
if I can get that upstreamed.


> i'm the maintainer and upstream author of Notcurses, and kmscon
> is very much a target of mine. if you'd like to integrate any
> Notcurses stuff into your testing, just hit me up; i'd be happy
> to help!

I would like something a bit more formal to test kmscon. So far I've 
just been testing out different modes and see if aptitude draws 
everything correctly, but that's hardly a decent compliance test.


On 05/02/2022 13:08, nick black wrote:
> also, there is a kmscon repo under the auspices of the
> freedesktop.org organization. i talked to the original author
> about removing that if he wasn't going to be taking the project
> forward, but it didn't go anywhere. if someone's really picking
> kmscon up, they might want to go talk to the fdo people.

On 05/02/2022 13:11, nick black wrote:
> ahh, rereading your original ITP, i see you know all about the
> fdo situation. good deal =]. i just killed my fork, and am going
> to submit a PR to Aetf's fork.

It would be great if it could be moved back under FDO auspices, but I 
haven't tried to contact them, yet. Going by your experiences that might 
not be worth the effort then.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005004: lots of missing entries in debian/copyright

[Martin Pitt]

tag -1 moreinfo

Hallo Thorsten,

Thorsten Alteholz [2022-02-05  9:40 +]:
> please rework your debian/copyright. Especially everything from node_modules
> seems to be missing. Please also check other releases.

The webpack bits in dist/ are autogenerated, and we have spent quite some
effort to make sure that this is correct and up to date. Over the last year it
shrank significantly, as we were able to drop a lot of npm modules (such as
jquery, mustache, or PatternFly 3).

Indeed copyright for the three node_modules/ are missing (these are test
dependencies for the integration test); they are not shipped in debs, but in
the source package, so they should be mentioned. That part is clear.

However, your report sounds like you found other problems apart from
node_modules/ -- what are they? Do you have an example?

Thanks,

Martin

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[nick black]

ahh, rereading your original ITP, i see you know all about the
fdo situation. good deal =]. i just killed my fork, and am going
to submit a PR to Aetf's fork.


signature.asc
Description: PGP signature

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[nick black]

also, there is a kmscon repo under the auspices of the
freedesktop.org organization. i talked to the original author
about removing that if he wasn't going to be taking the project
forward, but it didn't go anywhere. if someone's really picking
kmscon up, they might want to go talk to the fdo people.


signature.asc
Description: PGP signature

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[nick black]

indeed, the cursor location report fix is only on a branch. i'll
go ahead and submit it to this other fork, and rebase mine off
of theirs. thank you likewise for bringing this to my attention!
i'm glad to see kmscon getting some love.

i'm the maintainer and upstream author of Notcurses, and kmscon
is very much a target of mine. if you'd like to integrate any
Notcurses stuff into your testing, just hit me up; i'd be happy
to help!


signature.asc
Description: PGP signature

Bug#1004994: src:ibm-3270: fails to migrate to testing for too long: uploader built arch:all binaries

[Philipp Kern]

Hi Paul,

On 05.02.22 08:50, Paul Gevers wrote:
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.


Feel free to accelerate this upload. Thanks!

Kind regards
Philipp Kern

Bug#1005010: bullseye-pu: package node-nth-check/2.0.0-1+deb11u1

[Yadd]

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

[ Reason ]
Regex Denial of Service (CVE-2021-3803)

[ Impact ]
Medium vulnerability

[ Tests ]
Test passed

[ Risks ]
Low risk, patch isn't so complicated and test passed

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Replace regex with hand-rolled parser

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index b80a144..e2e201b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-nth-check (2.0.0-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Replace regex with hand-rolled parser (Closes: CVE-2021-3803)
+
+ -- Yadd   Sat, 05 Feb 2022 12:42:20 +0100
+
 node-nth-check (2.0.0-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-3803.patch 
b/debian/patches/CVE-2021-3803.patch
new file mode 100644
index 000..da4870c
--- /dev/null
+++ b/debian/patches/CVE-2021-3803.patch
@@ -0,0 +1,107 @@
+Description: Replace regex with hand-rolled parser
+Author: Felix Böhm <188768+f...@users.noreply.github.com>
+Origin: upstream, 
https://patch-diff.githubusercontent.com/raw/fb55/nth-check/pull/9.patch
+Bug: https://github.com/advisories/GHSA-rp65-9cf3-cjxr
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-02-05
+
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -1,7 +1,9 @@
+ // Following http://www.w3.org/TR/css3-selectors/#nth-child-pseudo
+ 
+-// [ ['-'|'+']? INTEGER? {N} [ S* ['-'|'+'] S* INTEGER ]?
+-const RE_NTH_ELEMENT = /^([+-]?\d*n)?\s*(?:([+-]?)\s*(\d+))?$/;
++// Whitespace as per https://www.w3.org/TR/selectors-3/#lex is " \t\r\n\f"
++const whitespace = new Set([9, 10, 12, 13, 32]);
++const ZERO = "0".charCodeAt(0);
++const NINE = "9".charCodeAt(0);
+ 
+ /**
+  * Parses an expression.
+@@ -19,24 +21,72 @@
+ return [2, 1];
+ }
+ 
+-const parsed = formula.match(RE_NTH_ELEMENT);
++// Parse [ ['-'|'+']? INTEGER? {N} [ S* ['-'|'+'] S* INTEGER ]?
+ 
+-if (!parsed) {
++let idx = 0;
++
++let a = 0;
++let sign = readSign();
++let number = readNumber();
++
++if (idx < formula.length && formula.charAt(idx) === "n") {
++idx++;
++a = sign * (number ?? 1);
++
++skipWhitespace();
++
++if (idx < formula.length) {
++sign = readSign();
++skipWhitespace();
++number = readNumber();
++} else {
++sign = number = 0;
++}
++}
++
++// Throw if there is anything else
++if (number === null || idx < formula.length) {
+ throw new Error(`n-th rule couldn't be parsed ('${formula}')`);
+ }
+ 
+-let a;
++return [a, sign * number];
+ 
+-if (parsed[1]) {
+-a = parseInt(parsed[1], 10);
+-if (isNaN(a)) {
+-a = parsed[1].startsWith("-") ? -1 : 1;
++function readSign() {
++if (formula.charAt(idx) === "-") {
++idx++;
++return -1;
+ }
+-} else a = 0;
+ 
+-const b =
+-(parsed[2] === "-" ? -1 : 1) *
+-(parsed[3] ? parseInt(parsed[3], 10) : 0);
++if (formula.charAt(idx) === "+") {
++idx++;
++}
++
++return 1;
++}
+ 
+-return [a, b];
++function readNumber() {
++const start = idx;
++let value = 0;
++
++while (
++idx < formula.length &&
++formula.charCodeAt(idx) >= ZERO &&
++formula.charCodeAt(idx) <= NINE
++) {
++value = value * 10 + (formula.charCodeAt(idx) - ZERO);
++idx++;
++}
++
++// Return `null` if we didn't read anything.
++return idx === start ? null : value;
++}
++
++function skipWhitespace() {
++while (
++idx < formula.length &&
++whitespace.has(formula.charCodeAt(idx))
++) {
++idx++;
++}
++}
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..4ac3e54
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-3803.patch

Bug#1005009: sent: please include example and related images

[Jonas Smedegaard]

Package: sent
Version: 1-4
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Source project includes an example slideshow, demonstrating its
features.

Please include that, installed as examples - including the referenced
png and ff image files.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmH+Y4UACgkQLHwxRsGg
ASGd4Q/+JTKthdOGGjtGDiF/qiA9zdtoyfsGh/TPIa29buIGPfioafyj+O47Bo81
CPh2i8Xc1AoYIpsynbmTnqCj3v/MVkrMQ/PqUpn+CsXpQH4L3rrCuHkyXb7dtcM5
0/Ay7/R4PT420N4eqbHwjMenRtWcy4xdelbOEsJ2iqVQxACNzz9I/Ot24N+6b8rI
kz6voAoL5N3ndkFrvX8jPnENDBCHkNY/eJGDL2RIoLEva2MnQKUFTqEwUQKKhak1
RfB9eu8kQrUAzu8CFf6H2a2MUhrvKt/yEbqufTWeInyjVUi+J0kTJUlyfzAu9Z8s
dWqXxtPXf+SSKhLY6026eO19XKMAh0Ij3r0PzbynMue9G+BfwYPWvBXdJv3GXg/8
kVZqVG91CDHwXet3BLVQwyhLbue0vGNnUsV8xSkEWoMenL2FPM26EWyT7tKgwj9f
JXozsTKYI9/oxtGgDX+K6xOxOG9ENeLy4SSWwh7uyHX6N83F+sZuFqJ/jQIH+MHw
yDWaxou2S8BTEypPMGPdkE2HdqqK0huWqtk0+Z0KKP6E1/szk4nRegJ6zjuxn2BA
i3YSfnNCQJWNoj3eYv/3Rh/8AQ/RS5lqolsRMBJHRIdcZ9AEgzi/+UPBErK3zuza
zZqlfeGgYv/qk+NPO+Ra8H+ryz8LnYGi02Fq4z5lxeTZvQLOZ4c=
=8Q28
-END PGP SIGNATURE-

Bug#1004901: ncurses-bin: issues with the infocmp(1) man page and databases

[Thomas Dickey]

On Thu, Feb 03, 2022 at 11:10:50AM +0100, Vincent Lefevre wrote:
> Package: ncurses-bin
> Version: 6.3-2
> Severity: minor
> 
> In the infocmp(1) man page:
> 
>Changing Databases [-A directory] [-B directory]
>Like  other  ncurses  utilities, infocmp looks for the terminal
>descriptions in several places.  You can use the  TERMINFO  and
>TERMINFO_DIRS environment variables to override the compiled-in
>default list of places to search (see curses(3X) for details).
> 
> The curses(3X) man page does not exist. It is curses(3ncurses).

yes... ncurses has a data-file which I developed along with configure/build
scripting to install the manpages renamed for Debian's special case
(man_db.renames).  That data (along with manhtml.aliases) could be used in some
as-yet-unwritten script to modify the manual pages as they are installed.

Because Debian is the only organization that uses this feature (and looking
at the change history, it's been more than 15 years since Debian reported
minor errors in the data-file), it hasn't been worth generalizing further.

If someone wants to spend (at least) a few days developing the script and
contributes it (same license, etc), I can integrate it.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature