Bug#1004415: libassimp-dev: assimpTargets.cmake generates an invalid INTERFACE_INCLUDE_DIRECTORIES

[Debian GNU|Linux]

On 1/27/22 05:14, David Fries wrote:

It would be great if the Debian stable version of assimpTargets.cmake
be released with the fix.


in general, the "Debian stable version" is releasED.
the release date for the current Debian/stable version was 2021-08-14, 
that is: in the past.

i cannot really do anything about the past.

i'm not fully decided whether i would want to provide a package for 
"bullseye-update" for this issue (i'm leaning towards "no", but haven't 
actually assessed the amount of work that needs to be done for that),


gfmasd
IOhannes


OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004417: -o docs is nonexistent and should be removed from code and manual page

[Alexander Zangerl]

Package: foomatic-filters
Version: 4.0.17-11
Severity: normal

the logic for PPD documentation extraction and presentation that was
present in foomatic 3.x was never migrated to the new codebase of versions 4.x.

however, the foomatic-rip manual page still states that you can get
a printout of the PPD options with "-o docs". this is misleading and incorrect
and should be removed.

the code in foomaticrip.c that is supposed to "Print documentation page
when asked for" (line 1460 or thereaboutes) doesn't and cannot, because
two lines down the track it just says 

/* Start the documentation page generator */
/* TODO tbd */

ie. there IS no documentation page generator - and the rest of the code then
builds up a really broken environment with a call out to a2ps & co (as per
bug 776315) and no input to those.

as upstream is clearly not inclined to do any work on stuff they left by the
wayside when the rewrote foomatic-rip multiple years ago, the '-o docs' option
should be rejected and not be allowed to cause this misleading mess.

however, if anybody does want that nice PPD option listing that the old
foomatic-rip gave us, here you are: i just recreated a cut down minimal version
of said PPD documentation extractor and presenter, which you find attached.
feel free to ship it in docs/contrib, it's under GPL 2.
#!/usr/bin/perl
#   $Id$
#
#   File:   ppd-doc-extractor
#   Date:   27 Jan 2022 16:28:17
#   Author:   Alexander Zangerl 
#
#   Abstract:
#very minimal recreation of the PPD documentation extractor
#of foomatic-rip 3.x (which you got with foomatic-rip -o docs), which
#is not part of the rewritten 4.x versions despite the documentation's
#claims and the broken option code that doesn't reject what it cannot
#handle.
#
#   copyright (c) 2022 Alexander Zangerl 
#
#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License version 2
#   as published by the Free Software Foundation.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
use strict;
use File::Slurp;
use Data::Dumper;

my ($ppdfile,@a2ps) = @ARGV;
die "usage: $0  [a2ps args]\n
no a2ps args: print to stdout
automatically added: --center-title, --footer\n\n" if (!-f $ppdfile);

my @stuff = read_file($ppdfile);

# parse everything but massage and handle just the relevant parts
my (%x, $curopengroup);
for (my $i = 0; $i <= $#stuff; ++$i)
{
  my $line = $stuff[$i];
  $line =~ s/\r\n$//;   # de-dos
  chomp $line;

  my ($key, $value, $option, $xlatoption);

  next if ($line =~ /^(\*%.*)?$/ or $line eq "*End");
  if ($line =~ /^\*([^:]+):\s*(.+)\s*$/)
  {
($key, $value) = ($1,$2);
if ($key  =~ /^(\S+)\s+(.+)$/)
{
  $key = $1;
  $option = $2;

  if ($option =~ m!^([^/]+)/(.+)$!)
  {
($option,$xlatoption) = ($1,$2);
undef $xlatoption if ($xlatoption eq $option); # unnecessary ones
  }
}
# invocationvalue and quotedvalue allow continuation
if ($value =~ /^"([^"]+)"\s*$/)
{
  $value = $1;
}
elsif ($value =~ /^"([^"]*)*$/)
{
  $value = $1;
  while ((my $nextline = $stuff[++$i]) !~ /"/)
  {
$value .= $nextline;
  }
  if ($stuff[$i] =~ /^([^"]+)"\s*$/)
  {
$value .= $1;
  }
}

# orderdependency is laid out extraspecially stupidly
if ($key =~ /^(NonUI)?OrderDependency$/)
{
  $key = "OrderDependency"; # we lump these together
  my ($num,$dontcare,$appliesto) = split(/\s+/,$value);
  ($option = $appliesto) =~ s/^\*//;
  $value = $num;
}
# want the options under openui w/o fluff
elsif ($key eq "OpenUI")
{
  $option =~ s/^\*//;
}
# another instance of shitty structural layout
elsif ($key eq "OpenGroup")
{
  if ($value =~ m!^\s*(\S+)/(.+)$!)
  {
($option,$xlatoption) = ($1,$2);
  }
  else
  {
$xlatoption = $option = $value;
  }
  $curopengroup = $value = $option;
}
elsif ($key eq "CloseGroup")
{
  undef $curopengroup;
}

if (defined $option)
{
  # for option entries add a sequence number for sorting - simply use the 
line number
  $x{$key}->{$option} = { xlat => $xlatoption,
  value => $value,
  sequence => $i,
  ingroup => $curopengroup, };

}
else
{
  $x{$key} = $value;
}
  }
  else
  {
die "unrecognized line nr. $i\n";
  }
}

# print Dumper(\%x);

if (@a2ps)
{
  push @a2ps, ("--center-title=Documentation 

Bug#776315: foomatic-filters: foomatic-rip can't properly execute text filters

[Alexander Zangerl]

On Mon, 26 Jan 2015 18:34:44 +, Martín Ferrari writes:
>Following with strace, I see that foomatic-rip is incorrectly executing
>commands in the shell:
>
>[pid 13859] execve("/bin/bash", ["/bin/bash", "-c", "mpage -o -1 -b Letter -H
>-h Documentation for the Lexmark X792 Foomatic/Postscript -m36l36b36t36r -f -P-
>-"], [/* 38 vars */]) = 0

this can be fixed by changing just one line in fileconverters.c;
if the @@JOBTITLE@@ placeholder is prefixed by '\"' (and only prefixed),
then the argument prep logic wraps it suitably. (it's still a
pretty ugly mess, what with unnecessary detours via a shell but
that's a separate story.)

the attached patch makes that change, and a quick check with strace confirms
that a2ps is now called correctly:

25389 execve("/bin/bash", ["/bin/bash", "-c", "a2ps -1 --medium=A4dj 
--center-title=\"Documentation for the Ricoh SP C250DN PS\" -o -"], 
0x7fffc24477b8 /* 38 vars */ 
...
25389 execve("/usr/bin/a2ps", ["a2ps", "-1", "--medium=A4dj", 
"--center-title=Documentation for the Ricoh SP C250DN PS", "-o", "-"], 
0x55f407b0f1b0 /* 37 vars */) = 0

>At the same time, I don't see any code generating the docs I am looking for, it
>seems commented out. So maybe that is also broken?

yes, it's nonexistent: they never migrated the documentation extraction code
from version 3.x's perl (where it was very simple to do) to version 4.x's c
codebase (where it's a bit more work) - but the did leave the
broken/incomplete '-o docs' in the code and the documentation :-(

i recreated something not entirely unlike that doc extractor earlier today
and will submit it in a separate bug regarding the misleading docs and
code leftovers.

--- a/fileconverter.c
+++ b/fileconverter.c
@@ -37,9 +37,9 @@
  * is not set. (Except if the spooler is CUPS, then 'texttops' is used
  */
 const char *fileconverters[][2] = {
-{ "a2ps", "a2ps -1 @@--medium=@@PAGESIZE@@ @@--center-title=@@JOBTITLE@@ -o -" },
+{ "a2ps", "a2ps -1 @@--medium=@@PAGESIZE@@ @@--center-title=\"@@JOBTITLE@@ -o -" },
 { "enscript", "enscript -G @@-M @@PAGESIZE@@ @@-b \"Page $%|@@JOBTITLE@@ --margins=36:36:36:36 --mark-wrapped-lines=arrow --word-wrap -p-" },
-{ "mpage", "mpage -o -1 @@-b @@PAGESIZE@@ @@-H -h @@JOBTITLE@@ -m36l36b36t36r -f -P- -" },
+{ "mpage", "mpage -o -1 @@-b @@PAGESIZE@@ @@-H -h \"@@JOBTITLE@@ -m36l36b36t36r -f -P- -" },
 { "paps", "paps @@--paper @@PAGESIZE@@ --header --font=11.5" },
 { NULL, NULL }
 };
-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, GNU: GNU is Not Useful, ohne Windows 
oder Linux darunter. -- Uwe Ohse


signature.asc
Description: Digital Signature

Bug#1004378: dh_python3: does not correctly handle some cases of os-versioned dependencies

[Julian Gilbey]

On Wed, Jan 26, 2022 at 07:24:23PM +, stefa...@debian.org wrote:
> Hi Julian (2022.01.26_10:00:17_+)
> > I'm in the process of packaging the latest version of send2trash, and
> > have stumbled upon an interesting bug.
> > 
> > During the build, I get the warnings:
> > 
> >dh_python3 -O--buildsystem=pybuild
> > I: dh_python3 pydist:293: Cannot find package that provides 
> > pyobjc_framework_cocoa. Please add package that provides it to 
> > Build-Depends or add "pyobjc_framework_cocoa 
> > python3-pyobjc-framework-cocoa" line to debian/py3dist-overrides or add 
> > proper dependency to Depends by hand and ignore this info.
> > I: dh_python3 pydist:293: Cannot find package that provides pywin32. Please 
> > add package that provides it to Build-Depends or add "pywin32 
> > python3-pywin32" line to debian/py3dist-overrides or add proper dependency 
> > to Depends by hand and ignore this info.
> 
> Can you push this to git so I can reproduce it?
> I tried parsing the METADATA you provided, and can't reproduce on that.
> 
> SR

Hi Stefano,

Oops, have just done so!

https://salsa.debian.org/python-team/packages/send2trash

Best wishes,

   Julian

Bug#1004416: link-grammar: FTBFS with Python 3.10 as default

[Graham Inggs]

Source: link-grammar
Version: 5.10.2~dfsg-2
Severity: important
Tags: ftbfs patch

Hi Jonas

link-grammar will FTBFS with Python 3.10 as default, due to a broken
version check in ax_python_devel.m4.  This is actually a bug in
autoconf-archive, but seeing that link-grammar seems to be the only
package in the archive affected by it, it may be quickest just to work
around it here for now.  The attached patch worked for me.

Regards
Graham
Description: Avoid broken version check in ax_python_devel.m4
Author: Graham Inggs 
Last-Update: 2022-01-26

--- a/configure.ac
+++ b/configure.ac
@@ -304,7 +304,7 @@
 	[enable_java_bindings=yes])
 
 # Python is now enabled by default
-define([PYTHON3_REQUIRED], [3.4])
+define([PYTHON3_REQUIRED])
 AC_ARG_ENABLE( python-bindings,
 	[  --disable-python-bindings
 	  disable build of python bindings (default is enabled)],

Bug#1003972: libphonenumber: New upstream release - please update

[tony mancill]

Hi Neil,

On Tue, Jan 18, 2022 at 06:54:58PM +, Neil Mayhew wrote:
> Package: libphonenumber-dev
> Version: 8.12.16-4
> Severity: important
> File: libphonenumber
> 
> There are a number of bug fixes in this release, including one for handling
> invalid UTF-8 sequences correctly.
> 
> See:
> 
> * https://issuetracker.google.com/issues/206677455
> * https://github.com/google/libphonenumber/pull/2698
> * https://github.com/google/libphonenumber/releases/tag/v8.12.41

I have an update to 8.12.41 that should be ready for upload soon.  I'm
building the reverse dependencies now to make sure it's not going to
introduce regressions (or to at least know what they are).

I expect to be able to upload in the next few days.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1004415: libassimp-dev: assimpTargets.cmake generates an invalid INTERFACE_INCLUDE_DIRECTORIES

[David Fries]

Package: libassimp-dev
Version: 5.0.1~ds0-2
Severity: normal

Dear Maintainer,

CMake configure of qt6.2 failed because libassimp-dev generated a path
/usr/lib/include in INTERFACE_INCLUDE_DIRECTORIES which doesn't exit
and cmake aborted.

/usr/lib/x86_64-linux-gnu/cmake/assimp-5.0/assimpTargets.cmake
When building the _IMPORT_PREFIX it removes one too few path elements.
When the _IMPORT_PREFIX section is replaced with the version from
5.1.6_ds0-1 it does generate a valid path and Qt is able to finish the
configure.

It would be great if the Debian stable version of assimpTargets.cmake
be released with the fix.


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

Kernel: Linux 5.16.0+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15), LANGUAGE not 
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libassimp-dev depends on:
ii  libassimp5  5.0.1~ds0-2

libassimp-dev recommends no packages.

libassimp-dev suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/x86_64-linux-gnu/cmake/assimp-5.0/assimpTargets.cmake (from 
libassimp-dev:amd64 package)

Bug#1004414: systemd-cron: generator turns crontabs public readable

[Robert Siemer]

Package: systemd-cron
Version: 1.15.18-1
Severity: normal
Tags: security
X-Debbugs-Cc: robert.siemer-report...@backsla.sh, Debian Security Team 


Crontabs, especially in /var/spool/cron are not readable to all users. 
Translated command lines in unit files in 
/run/systemd/generator on the other hand are.

Shell variable assignments, written before a command would turn 
readable to everyone, which they are otherwise never.

Further: the changed situation improves the opportunities for 
snooping around. On purpose?

Regards,
Robert


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

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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 systemd-cron depends on:
ii  libc6   2.33-3
ii  python3 3.9.8-1
ii  systemd [systemd-sysusers]  250.3-1
ii  systemd-sysv250.3-1

Versions of packages systemd-cron recommends:
ii  postfix [mail-transport-agent]  3.6.4-1

systemd-cron suggests no packages.

-- no debconf information

Bug#985424: please confirm if 0.8.2 is affected

[Nicholas D Steeves]

tag 987074 moreinfo
tag 985424 moreinfo
tag 987073 moreinfo
thanks
Please confirm if 0.8.2 (just uploaded) is affected.  Sorry about the
noise in the last email.

Bug#1004413: breezy: autopkgtest regression

[Adrian Bunk]

Source: breezy
Version: 3.2.1+bzr7581-1
Severity: serious

https://ci.debian.net/packages/b/breezy/testing/amd64/

...
==
ERROR: 
breezy.tests.per_workingtree.test_get_file_mtime.TestGetFileMTime.test_get_file_mtime_nested(GitWorkingTreeFormat)
--
testtools.testresult.real._StringException: log: {{{
709.353  preparing to commit
INFO  Committing to: 
/tmp/testbzr-l60a69ix.tmp/breezy.tests.per_workingtree.test_get_file_mtime.TestGetFileMTime.test_get_file_mtime_nested(GitWorkingTreeFormat)/work/tree/sub/
709.355  Selecting files for commit with filter None
INFO  added one
INFO  Committed revision 1.
709.359  Committed revid b'git-v1:224ad6defd64ea12b377b19bbd479da34028b846' as 
revno 1.
709.361  preparing to commit
INFO  Committing to: 
/tmp/testbzr-l60a69ix.tmp/breezy.tests.per_workingtree.test_get_file_mtime.TestGetFileMTime.test_get_file_mtime_nested(GitWorkingTreeFormat)/work/tree/
709.364  Selecting files for commit with filter None
INFO  added one
709.370  preparing to commit
INFO  Committing to: 
/tmp/testbzr-l60a69ix.tmp/breezy.tests.per_workingtree.test_get_file_mtime.TestGetFileMTime.test_get_file_mtime_nested(GitWorkingTreeFormat)/work/tree/sub/
709.375  Selecting files for commit with filter None
INFO  Committed revision 2.
709.379  Committed revid b'git-v1:71d4b60ca022a684e8ad5d9e29895f3c8e1daed4' as 
revno 2.
INFO  added sub
INFO  Committed revision 1.
709.384  Committed revid b'git-v1:6f1968cb6ccb852225ca9469735e1a1428d554c5' as 
revno 1.
}}}

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 380, in 
get_file_mtime
(store, unused_path, commit_id) = change_scanner.find_last_change_revision(
  File "/usr/lib/python3/dist-packages/breezy/git/filegraph.py", line 57, in 
find_last_change_revision
target_mode, target_sha = tree_lookup_path(
  File "/usr/lib/python3/dist-packages/dulwich/object_store.py", line 1175, in 
tree_lookup_path
return tree.lookup_path(lookup_obj, path)
  File "/usr/lib/python3/dist-packages/dulwich/objects.py", line 1188, in 
lookup_path
obj = lookup_obj(sha)
  File "/usr/lib/python3/dist-packages/dulwich/object_store.py", line 138, in 
__getitem__
type_num, uncomp = self.get_raw(sha)
  File "/usr/lib/python3/dist-packages/dulwich/object_store.py", line 584, in 
get_raw
raise KeyError(hexsha)
KeyError: b'71d4b60ca022a684e8ad5d9e29895f3c8e1daed4'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/breezy/tests/per_workingtree/test_get_file_mtime.py",
 line 57, in test_get_file_mtime_nested
tree.basis_tree().get_file_mtime('sub/one'),
  File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 383, in 
get_file_mtime
raise errors.NoSuchFile(path)
breezy.errors.NoSuchFile: No such file: 'sub/one'

--
Ran 32863 tests in 916.376s

FAILED (errors=1, known_failure_count=46)
4780 tests skipped
autopkgtest [09:25:42]: test testsuite3: ---]
autopkgtest [09:25:42]: test testsuite3:  - - - - - - - - - - results - - - - - 
- - - - -
testsuite3   FAIL non-zero exit status 1

Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2

[Le Déchaîné]

$ echo $LD_LIBRARY_PATH
(not set)

$ locate libdrm.so
/opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2
/opt/amdgpu/lib/i386-linux-gnu/libdrm.so.2.4.0
/opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2
/opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2.4.0
/usr/lib/i386-linux-gnu/libdrm.so.2
/usr/lib/i386-linux-gnu/libdrm.so.2.4.0
/usr/lib/x86_64-linux-gnu/libdrm.so
/usr/lib/x86_64-linux-gnu/libdrm.so.2
/usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
(except /var/lib/flatpaks (augh!) and some steamapps/SteamLinuxRuntime
files)

Le mer. 26 janv. 2022 à 18:28, Sebastian Ramacher  a
écrit :

> Control: tags -1 moreinfo
>
> On 2022-01-26 18:08:00 -0500, Jimmy K. wrote:
> > Package: ffmpeg
> > Version: 7:4.4.1-3
> > Severity: important
> > X-Debbugs-Cc: ledecha...@gmail.com
> >
> > Dear Maintainer,
> > this version of ffmpeg has been useless on my system, for many months.
> >
> > $ ffmpeg
> > ffmpeg: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libavdevice.so.58: undefined symbol: drmModeGetFB2
> >
> > -Downgrading with sudo apt-get install ffmpeg=7:4.3.3-0+deb11u1 fixes
> it, but
> > it's too late for that, apparently.
> > -BUT getting the source from github and "configure, make, sudo make
> install",
> > worked. I don't know what's different.
>
> Since libavdevice58 depends on a recent enough version of libdrm2, I
> suppose that you have an old version of libdrm.so.2 somewhere in
> /usr/local/lib or your LD_LIBRARY_PATH. Can you confirm that?
>
> Cheers
>
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_CA:fr
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages ffmpeg depends on:
> > ii  libavcodec587:4.4.1-3
> > ii  libavdevice58   7:4.4.1-3
> > ii  libavfilter77:4.4.1-3
> > ii  libavformat58   7:4.4.1-3
> > ii  libavutil56 7:4.4.1-3
> > ii  libc6   2.33-3
> > ii  libpostproc55   7:4.4.1-3
> > ii  libsdl2-2.0-0   2.0.20+dfsg-2
> > ii  libswresample3  7:4.4.1-3
> > ii  libswscale5 7:4.4.1-3
> >
> > ffmpeg recommends no packages.
> >
> > Versions of packages ffmpeg suggests:
> > pn  ffmpeg-doc  
> >
> > -- no debconf information
> >
>
> --
> Sebastian Ramacher
>

Bug#985424: please confirm if 0.7.8 is affected

[Nicholas D Steeves]

tag moreinfo 987074
tag moreinfo 985424
tag moreinfo 987073
thanks

Please confirm if 0.8.2 (just uploaded) is affected.

Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2

[Le Déchaîné]

Oh damn, I answered straight to their mailboxes by mistake without
responding to 1004...@bugs.debian.org (facepalm). Copying here. Apologies.

Hello!
Apparently it could be a bug with the amd-gpu drivers?

$ neofetch --off
ledechaine@symphony
---
OS: Debian GNU/Linux bookworm/sid x86_64
Host: SX2380
Kernel: 5.15.0-2-amd64
Uptime: 44 mins
Packages: 4738 (dpkg)
Shell: bash 5.1.16
Resolution: 1920x1080
DE: MATE
WM: Metacity (Marco)
WM Theme: Menta
Theme: TraditionalOk [GTK2/3]
Icons: gnome [GTK2/3]
Terminal: guake
CPU: AMD A8-5500 APU (4) @ 3.200GHz
GPU: AMD ATI Radeon RX 550 640SP / RX 560/560X
Memory: 3629MiB / 9903MiB

As requested:

$ ffmpeg
ffmpeg: symbol lookup error: /usr/lib/x86_64-linux-gnu/libavdevice.so.58:
undefined symbol: drmModeGetFB2
$ /usr/bin/ffmpeg
/usr/bin/ffmpeg: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libavdevice.so.58: undefined symbol: drmModeGetFB2
$ /usr/local/bin/ffmpeg
bash: /usr/local/bin/ffmpeg: No such file

$ ldd /usr/bin/ffmpeg
linux-vdso.so.1 (0x7ffef89ec000)
libavdevice.so.58 => /usr/lib/x86_64-linux-gnu/libavdevice.so.58
(0x7f595e1f)
libavfilter.so.7 => /usr/lib/x86_64-linux-gnu/libavfilter.so.7
(0x7f595dd58000)
libavformat.so.58 => /usr/lib/x86_64-linux-gnu/libavformat.so.58
(0x7f595dac)
libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58
(0x7f595c6c)
libpostproc.so.55 => /usr/lib/x86_64-linux-gnu/libpostproc.so.55
(0x7f595c698000)
libswresample.so.3 => /usr/lib/x86_64-linux-gnu/libswresample.so.3
(0x7f595c67)
libswscale.so.5 => /usr/lib/x86_64-linux-gnu/libswscale.so.5
(0x7f595c5d)
libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56
(0x7f595c318000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f595c1d)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f595c1a8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f595bfd8000)
libraw1394.so.11 => /usr/lib/x86_64-linux-gnu/libraw1394.so.11
(0x7f595bfc)
libavc1394.so.0 => /usr/lib/x86_64-linux-gnu/libavc1394.so.0
(0x7f595bdb8000)
librom1394.so.0 => /usr/lib/x86_64-linux-gnu/librom1394.so.0
(0x7f595bbb)
libiec61883.so.0 => /usr/lib/x86_64-linux-gnu/libiec61883.so.0
(0x7f595bba)
libjack.so.0 => /usr/lib/x86_64-linux-gnu/libjack.so.0 (0x7f595bb48000)
libdrm.so.2 => /opt/amdgpu/lib/x86_64-linux-gnu/libdrm.so.2
(0x7f595bb3)
libopenal.so.1 => /usr/lib/x86_64-linux-gnu/libopenal.so.1
(0x7f595ba4)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f595ba1)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
(0x7f595ba08000)
libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0
(0x7f595ba0)
libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0
(0x7f595b9f)
libcdio_paranoia.so.2 => /usr/lib/x86_64-linux-gnu/libcdio_paranoia.so.2
(0x7f595b9e)
libcdio_cdda.so.2 => /usr/lib/x86_64-linux-gnu/libcdio_cdda.so.2
(0x7f595b9d)
libdc1394.so.25 => /usr/lib/x86_64-linux-gnu/libdc1394.so.25
(0x7f595b95)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2
(0x7f595b848000)
libcaca.so.0 => /usr/lib/x86_64-linux-gnu/libcaca.so.0 (0x7f595b778000)
libGL.so.1 => /opt/amdgpu/lib/x86_64-linux-gnu/libGL.so.1
(0x7f595b6f)
libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0
(0x7f595b698000)
libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
(0x7f595b4f8000)
libsndio.so.7.0 => /usr/lib/x86_64-linux-gnu/libsndio.so.7.0
(0x7f595b4e)
libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7f595b2d8000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f595b19)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f595b178000)
libpocketsphinx.so.3 => /usr/lib/x86_64-linux-gnu/libpocketsphinx.so.3
(0x7f595b128000)
libsphinxbase.so.3 => /usr/lib/x86_64-linux-gnu/libsphinxbase.so.3
(0x7f595b0e)
libbs2b.so.0 => /usr/lib/x86_64-linux-gnu/libbs2b.so.0 (0x7f595b0d8000)
liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0
(0x7f595b0b8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f595b0b)
librubberband.so.2 => /usr/lib/x86_64-linux-gnu/librubberband.so.2
(0x7f595b07)
libmysofa.so.1 => /usr/lib/x86_64-linux-gnu/libmysofa.so.1
(0x7f595b058000)
libflite_cmu_us_awb.so.1 =>
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_awb.so.1 (0x7f595ac6)
libflite_cmu_us_kal.so.1 =>
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_kal.so.1 (0x7f595aaf8000)
libflite_cmu_us_kal16.so.1 =>
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_kal16.so.1 (0x7f595a718000)
libflite_cmu_us_rms.so.1 =>
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_rms.so.1 (0x7f595a278000)
libflite_cmu_us_slt.so.1 =>
/usr/lib/x86_64-linux-gnu/libflite_cmu_us_slt.so.1 (0x7f5959e78000)
libflite.so.1 => /usr/lib/x86_64-linux-gnu/libflite.so.1
(0x7f5959e38000)
libfribidi.so.0 => /usr/lib/x86_64-linux-gnu/libfribidi.so.0

Bug#1004363: ibus: pops up window with accent mark

[Gunnar Hjalmarsson]

Control: tags -1 - moreinfo

On 2022-01-26 23:33, brian m. carlson wrote:

I use MATE with Xorg and have never used GNOME or Wayland on this
system.  I do not need or want ibus, but I do use the video software
Zoom, and it requires it to be installed (it's in Depends).


Oh no, not Zoom again. :( Saying that because zoom depending on ibus was 
the reason why the reporter of  run into 
problems.


I think you can fix it for yourself by running this command:

im-config -n none

and reboot. That would prevent ibus from being started and configured at 
login.


With that said, and as you rightly point out, this is still a valid bug. 
So let's keep it open and see if others run into the same issue and are 
able to shed some light on the root cause.


--
Cheers,
Gunnar Hjalmarsson

Bug#1004411: asl FTBFA with vtk 9.1

[Adrian Bunk]

Source: asl
Version: 0.1.7-3
Severity: serious
Tags: ftbfs
Forwarded: https://github.com/AvtechScientific/ASL/issues/48

https://buildd.debian.org/status/logs.php?pkg=asl=0.1.7-3%2Bb1

...
   debian/rules override_dh_auto_configure-arch
make[1]: Entering directory '/<>'
dh_auto_configure -- -DBUILD_SHARED_LIBS=ON 
-DCMAKE_LIBRARY_ARCHITECTURE="x86_64-linux-gnu" -DWITH_EXAMPLES=OFF 
-DWITH_MATIO=ON -DWITH_TESTS=OFF -DWITH_API_DOC=OFF
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DBUILD_SHARED_LIBS=ON -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu 
-DWITH_EXAMPLES=OFF -DWITH_MATIO=ON -DWITH_TESTS=OFF -DWITH_API_DOC=OFF ..
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for CL_VERSION_2_0
-- Looking for CL_VERSION_2_0 - found
-- Found OpenCL: /usr/lib/x86_64-linux-gnu/libOpenCL.so (found suitable version 
"2.0", minimum required is "1.1") 
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake  
found components: program_options filesystem system 
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/vtkDetectLibraryType.cmake:23 (message):
  The `PATH` argument is required.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/patches/99/FindHDF5.cmake:1066 
(vtk_detect_library_type)
  
/usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:444 
(find_package)
  /usr/lib/x86_64-linux-gnu/cmake/vtk-9.1/vtk-config.cmake:150 (include)
  CMakeLists.txt:56 (find_package)


-- Configuring incomplete, errors occurred!

Bug#1004407: ITS: dfu-util

[Tormod Volden]

Of course, if current maintainers want to continue, feel free to use
or pick from the attached debdiff (only of debian/ folder) for a
0.11-1 package.

Tormod


debian_dfu-util_0.11-1.debdiff
Description: Binary data

Bug#1004410: RFS: utfcheck/1.2-3 [QA] -- check validity of UTF-8 and ASCII files

[Lourisvaldo Figueredo Junior]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: utfcheck
   Version : 1.2-3
   Upstream Author : Paul Hardy 
 * URL : https://unifoundry.com/utfcheck/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/utfcheck
   Section : text

It builds those binary packages:

  utfcheck - check validity of UTF-8 and ASCII files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/utfcheck/utfcheck_1.2-3.dsc

Changes since the last upload:

 utfcheck (1.2-3) unstable; urgency=medium
 .
   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped to 13.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Added Vcs-* fields.
   - Bumped Standards-Version to 4.6.0.1.
   - Using a secure URI in Homepage field.
   * debian/copyright:
   - Using a secure URI in Source field.
   - Removed duplicate license.
   - Separated packaging license from upstream license.
   * debian/salsa-ci.yml: created to provide CI tests for salsa.
   * debian/tests/control: updated.
   * debian/watch: cleaned and using a secure URI.

The git repository is on my account[1]. Please, send this to debian repository.
Any tips or suggestions given will be welcome.

[1] https://salsa.debian.org/figueredo/utfcheck


Regards,
-- 
  Lourisvaldo Figueredo Junior

Bug#1004409: libslurm-dev: slurm/slurm_version.h is missing

[Adrian Bunk]

Package: libslurm-dev
Version: 21.08.5-1.1
Severity: serious
Tags: ftbfs
Control: affects -1 src:mpich

$ cat test.c
#include 
$ gcc -c test.c
In file included from test.c:1:
/usr/include/slurm/slurm.h:55:10: fatal error: slurm/slurm_version.h: No such 
file or directory
   55 | #include 
  |  ^~~
compilation terminated.
$

Bug#1004408: odpic: binary-any FTBFS

[Adrian Bunk]

Source: odpic
Version: 4.3.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=odpic=4.3.0-1

...
 debian/rules clean
dh clean --with sphinxdoc
dh: error: unable to load addon sphinxdoc: Can't locate 
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: /etc/perl 
/usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 12) line 1.
BEGIN failed--compilation aborted at (eval 12) line 1.

make: *** [debian/rules:14: clean] Error 25

Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-01-26 18:08:00 -0500, Jimmy K. wrote:
> Package: ffmpeg
> Version: 7:4.4.1-3
> Severity: important
> X-Debbugs-Cc: ledecha...@gmail.com
> 
> Dear Maintainer,
> this version of ffmpeg has been useless on my system, for many months.
> 
> $ ffmpeg
> ffmpeg: symbol lookup error: /usr/lib/x86_64-linux-gnu/libavdevice.so.58: 
> undefined symbol: drmModeGetFB2
> 
> -Downgrading with sudo apt-get install ffmpeg=7:4.3.3-0+deb11u1 fixes it, but
> it's too late for that, apparently.
> -BUT getting the source from github and "configure, make, sudo make install",
> worked. I don't know what's different.

Since libavdevice58 depends on a recent enough version of libdrm2, I
suppose that you have an old version of libdrm.so.2 somewhere in
/usr/local/lib or your LD_LIBRARY_PATH. Can you confirm that?

Cheers

> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA:fr
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ffmpeg depends on:
> ii  libavcodec587:4.4.1-3
> ii  libavdevice58   7:4.4.1-3
> ii  libavfilter77:4.4.1-3
> ii  libavformat58   7:4.4.1-3
> ii  libavutil56 7:4.4.1-3
> ii  libc6   2.33-3
> ii  libpostproc55   7:4.4.1-3
> ii  libsdl2-2.0-0   2.0.20+dfsg-2
> ii  libswresample3  7:4.4.1-3
> ii  libswscale5 7:4.4.1-3
> 
> ffmpeg recommends no packages.
> 
> Versions of packages ffmpeg suggests:
> pn  ffmpeg-doc  
> 
> -- no debconf information
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2

[Reinhard Tartler]

Can you please run the command "ldd /usr/bin/ffmpeg" and share the output
with us?

Also, are you sure you are executing /usr/bin/ffmpeg and not accidentally
/usr/local/bin/ffmpeg?

Thanks,
-rt

Bug#1004250: contents of syslinux binary package don't match syslinux-common

[Lukas Schwaighofer]

Hi Vangelis,

thanks for your report!

On Sun, 23 Jan 2022 17:32:34 +0200
Vangelis Koukis  wrote:

> After installing syslinux on a FAT32 fs:
> (...)
> I see the md5sum of ldlinux.c32 doesn't match the md5sum of
> /usr/lib/syslinux/modules/bios/ldlinux.c32:
> (...)
> 
> I don't know where syslinux/ldlinux.c32 comes from, I assume it's
> embedded in /usr/bin/syslinux, but
> /usr/lib/syslinux/modules/bios/syslinux.c32 comes from the
> syslinux-common binary package.

Your assumption is correct: ldlinux.c32 is embedded into the syslinux
installer binary and the embedded copy is copied into the target folder
during the installation.

syslinux.c32 does not get copied automatically by the installer. It
must have been copied either manually or by some other script from
/usr/lib/syslinux/modules/bios/syslinux.c32 (and thus the files are the
same).

> I understand there was a recent binary-only upload, which means the
> contents of the syslinux package no longer match the contents of
> the syslinux-common package.
> (...)
> The problem is that syslinux-common *also* contains binaries [the
> syslinux modules], and they no longer match.

I looked into this and found two more things that will cause the
ldlinux.c32 embedded into the installer to be different from the copy
shipped in the syslinux-common package even without the binary-only
non-maintainer upload (binNMU) you mentioned:

* Currently the debug symbols are stripped from the .c32 files after
  the build (dh_strip).  However the ldlinux.c32 copy that's
  embedded into the installer binaries gets included before the
  stripping and still includes the debug symbols.  This is arguably a
  bug.

* The syslinux-common package is an Architecture: all package. That
  means on both amd64 and i386 the same syslinux-common package is
  installed.  I don't believe the toolchains on both systems yield
  exactly the same .c32 files, and currently the Architecture: all
  packages seem to always get built on amd64.

> I think it makes sense to upload all syslinux binary packages from the
> same build to the repository, so everything aligns.

I hope to be able to make a new upload fairly soon (recently picked up
working on https://bugs.debian.org/994274 again), but for the reasons
above there will still be a mismatch between the files.

My understanding so far is that this is a cosmetic issue:  Both the
files built into the installer as well as the c32 module in
syslinux-common work.  Is there something more to this problem that I'm
missing?

Thanks and kind regards
Lukas


pgpZVS85X2Hkr.pgp
Description: OpenPGP digital signature

Bug#1004407: ITS: dfu-util

[Tormod Volden]

Package: dfu-util
Version: 0.9-1
Severity: Important
X-Debbugs-CC: Uwe Hermann , m...@qa.debian.org

I have the intention to take over maintainership, or if interest,
co-maintenance of the dfu-util package.

Bugs against dfu-util hasn't seen maintainer activity since March 2016
(last Debian release). Example bug #840390.

Upstream has released several version, that hasn't been packaged (#952905).

Best regards,
Tormod

Bug#1004406: ffmpeg: symbol lookup error undefined symbol drmModeGetFB2

[Jimmy K.]

Package: ffmpeg
Version: 7:4.4.1-3
Severity: important
X-Debbugs-Cc: ledecha...@gmail.com

Dear Maintainer,
this version of ffmpeg has been useless on my system, for many months.

$ ffmpeg
ffmpeg: symbol lookup error: /usr/lib/x86_64-linux-gnu/libavdevice.so.58: 
undefined symbol: drmModeGetFB2

-Downgrading with sudo apt-get install ffmpeg=7:4.3.3-0+deb11u1 fixes it, but
it's too late for that, apparently.
-BUT getting the source from github and "configure, make, sudo make install",
worked. I don't know what's different.

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

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

Versions of packages ffmpeg depends on:
ii  libavcodec587:4.4.1-3
ii  libavdevice58   7:4.4.1-3
ii  libavfilter77:4.4.1-3
ii  libavformat58   7:4.4.1-3
ii  libavutil56 7:4.4.1-3
ii  libc6   2.33-3
ii  libpostproc55   7:4.4.1-3
ii  libsdl2-2.0-0   2.0.20+dfsg-2
ii  libswresample3  7:4.4.1-3
ii  libswscale5 7:4.4.1-3

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Alberto Garcia wrote:
> Two WebKit ports are actively maintained, available in Debian and have
> security support: WPE WebKit and WebKitGTK (the package is called
> webkit2gtk for technical / historical reasons).
> 
> Other WebKit ports available in Debian are not covered by security
> support. I know there's at least QtWebKit, I don't know if there are
> more.

OK, so as I asked upthread:

Am I misreading the Release Notes?


https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support

browsers built upon e.g. the webkit and khtml engines^[6] are
included in bullseye, but not covered by security support.

Are you saying that webkit2gtk is supported, but anything that USES 
webkit2gtk is unsupported?

If the answer is "yes", then I guess instead of
security-support-limited including src:webkitgtk it should include all
browsers that USE src:webkitgtk?

e.g. epiphany-browser, evolution, yelp, and webkitgtk (due to MiniBrowser).

Or all this stuff *is* all fully supported by Debian Security team, then
should I instead file a bug against the Release Notes?

Bug#1004405: libqofono FTBFS on 32bit: missing symbol

[Adrian Bunk]

Source: libqofono
Version: 0.103-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=libqofono=0.103-1

...
   dh_makeshlibs -a
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libqofono-qt5-0/DEBIAN/symbols doesn't match 
completely debian/libqofono-qt5-0.symbols
--- debian/libqofono-qt5-0.symbols (libqofono-qt5-0_0.103-1_i386)
+++ dpkg-gensymbolsVlRsCY   2022-01-25 20:03:24.728759552 +
@@ -1428,7 +1428,7 @@
  
_ZN32OfonoAssistedSatelliteNavigation11qt_metacallEN11QMetaObject4CallEiPPv@Base
 0.103
  _ZN32OfonoAssistedSatelliteNavigation11qt_metacastEPKc@Base 0.103
  _ZN32OfonoAssistedSatelliteNavigation16staticMetaObjectE@Base 0.103
- 
_ZN32OfonoAssistedSatelliteNavigation31RegisterPositioningRequestAgentERK15QDBusObjectPath@Base
 0.103
+#MISSING: 0.103-1# 
_ZN32OfonoAssistedSatelliteNavigation31RegisterPositioningRequestAgentERK15QDBusObjectPath@Base
 0.103
  
_ZN32OfonoAssistedSatelliteNavigationC1ERK7QStringS2_RK15QDBusConnectionP7QObject@Base
 0.103
  
_ZN32OfonoAssistedSatelliteNavigationC2ERK7QStringS2_RK15QDBusConnectionP7QObject@Base
 0.103
  _ZN32OfonoAssistedSatelliteNavigationD0Ev@Base 0.103
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:21: binary-arch] Error 25

Bug#1004363: ibus: pops up window with accent mark

[brian m. carlson]

On 2022-01-26 at 20:34:09, Gunnar Hjalmarsson wrote:
> @Brian: Thanks for additional info.
> 
> I probably tested on Wayland. Now I have tested on Xorg too, and don't see
> it there either.
> 
> I have one idea (and this is a long shot): Do you possibly have an
> ~/.XCompose file? If you have, can you try to rename it (in order to disable
> it), relogin, and try again. The reason I ask is that I have
>  in mind. It shows that a mistake in
> ~/.XCompose might lead to unexpected behavior.

I don't have an ~/.XCompose file.  I use the standard X compose
sequences.  The only keyboard configuration I have at all is this in my
~/.Xsessionrc and an ~/.Xmodmap:


setxkbmap -option capslock:escape -option compose:lwin \
-option terminate:ctrl_alt_bksp


The .Xmodmap looks like this:


keycode 166 = Prior
keycode 167 = Next


I don't believe those do anything anymore; I had an old laptop where
those mapped keys to PgUp and PgDown, but the keys in those positions
on this laptop are PgUp and PgDown.

Otherwise, this is a totally standard, boring U.S. English
configuration with a standard U.S. English keyboard.

> @Osamu: Unloading ibus somehow would only be a workaround, right? I mean,
> you should be able to use a Compose key without issues also when the
> ibus-daemon is running.

This did previously work just fine.  I've had ibus installed for some
time and I know it's been running because one of the key mappings
changed unexpectedly, as I mentioned.  I don't mind if it's installed as
long as the behavior is as it used to be.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1004363: ibus: pops up window with accent mark

[brian m. carlson]

On 2022-01-26 at 07:29:34, Osamu Aoki wrote:
> Brian,
> 
> Are you using ibus module for "English (int., with AltGr dead key)".

The version I have has "English - English (US)".  (Actually, my system
is in French, so it says, "Anglais - Anglais (US)", but that's the
translation).  I definitely don't have dead keys enabled, nor do I have
an AltGr key.  Besides the standard Shift key, I have Fn (this is a
laptop), Ctrl, Windows, and Alt.

> Since I use GNOME/Wayland I can't be sure but all non-GNOME system configures 
> ibus
> with "ibus-setup".  There may be configuration option there.

I have that installed and I don't see an option for this.

> What was your intended system configuration.  If it is a good old Pure-X way 
> without
> ibus on non-GNOME, then you have to unload ibus.  GNOME pull in this if you 
> installed
> it previously.

I use MATE with Xorg and have never used GNOME or Wayland on this
system.  I do not need or want ibus, but I do use the video software
Zoom, and it requires it to be installed (it's in Depends).

I'm happy to switch to a different input method, but this bug remains
valid even if I do so.  ibus should refrain from popping up windows in
this way or at least provide a way to configure it which defaults to
off.  Upgrading a system should not result in any changes to the way
people input text because that's not expected nor wanted, and ibus has a
history of doing exactly that.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#864795: RFP: brave-browser -- web browser with privacy and micropayment features

[Ben Finney]

On 26-Jan-2022, Nilesh Patra wrote:

> Oops, looks like this was always an RFP

That's right :-)

> apologies for the noise :)

I hope you can find someone interested to package this.

-- 
 \“Are you pondering what I'm pondering, Pinky?” “Sure, Brain, |
  `\ but how are we going to find chaps our size?” —_Pinky and The |
_o__)   Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1004402: it's worse

[mh]

As you can't navigate to the folder you like to save your document to,
it's even worse. I'd like to0 raise the severity to important, because
this makes (under fluxbox) the file management somewhat pointless. You
have to dump you document to some available folder and the use a
working filemanger to move it where it belongs. Then you have lost it
in your libreoffice file history!

Greetings

MH

Bug#584726: rdiff-backup: preserve_atime option

[Pablo Mestre]

Several months have passed since the last check regarding the bug and no
response has been issued.

We will proceed to close this bug and then archived if any discrepancy
arises.

--
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#1004404: ITP: cvdupdate -- ClamAV Private Database Mirror Updater Tool

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: clamav-cvdupdate
  Version : 1.0.2
  Upstream Author : The Clamav Team 
* URL : https://github.com/Cisco-Talos/cvdupdate
* License : Apache 2.0
  Programming Lang: Python
  Description : ClamAV Private Database Mirror Updater Tool

 cvdupdate downloads the latest ClamAV databases along with the latest
 database patch files.
 .
 Run this tool as often as you like, but it will only download new content if
 there is new content to download. If you somehow manage to download too
 frequently (eg: by using cvd clean all and cvd update repeatedly), then the
 official database server may refuse your download request, and one or more
 databases may go on cool-down until it's safe to try again.
 .
 This replaces the clamdownloader.pl script formerly provided on clamav.net.

This is the upstream clamav official tool for maintaining a private
clamav data mirror, which users with a non-trivial number of
installations will need to do.  We should provide this in Debian.

Although implemented in Python, it's primary purpose is as an executable
tool, so I will maintain this in the ClamAV Team.

Bug#1004403: src:carbon-c-relay: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: carbon-c-relay
Version: 3.7.2-1
Severity: serious
Control: close -1 3.7.3-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:carbon-c-relay has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package fails to 
build from source on mipsel and mips64el while it built there in the past.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#864795: RFP: brave-browser -- web browser with privacy and micropayment features

[Nilesh Patra]

Hi Ben,

On Thu, 15 Jun 2017 09:41:40 +1000 Ben Finney  wrote:

Package: wnpp
Severity: wishlist

* Package name: brave-browser
  Version : 0.16.9
  Upstream Author : Brave Software
* URL : http://www.brave.com/
* License : Mozilla Public License v2
  Programming Lang: C, C++, JavaScript
  Description : web browser with privacy and micropayments

Brave is a web browser with privacy and micropayments features.


Long time since this ITP is open, just wanted to know if there's 
something blocking this, and/or if you're working on this anymore?


Regards,
Nilesh

Bug#1004402: libreoffice: "open file" menue partly out off screen. No grip available (fluxbox decoration!).

[Michael Hatzold]

Package: libreoffice
Version: 1:7.3.0~rc2-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

If you try to open a file using the libreoffice open menue a new window
appears. As it is too big all grips are out of screen (fluxbox). You can't even
navigate to your personal folder as the icon is out of screen.


   * What outcome did you expect instead?

I want the new window to fit into the screen



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

Kernel: Linux 5.15.15-1-siduction-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.3.0~rc2-3
ii  libreoffice-calc1:7.3.0~rc2-3
ii  libreoffice-core1:7.3.0~rc2-3
ii  libreoffice-draw1:7.3.0~rc2-3
ii  libreoffice-impress 1:7.3.0~rc2-3
ii  libreoffice-math1:7.3.0~rc2-3
ii  libreoffice-report-builder-bin  1:7.3.0~rc2-3
ii  libreoffice-writer  1:7.3.0~rc2-3
ii  python3-uno 1:7.3.0~rc2-3

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.5-1
ii  fonts-linuxlibertine5.3.0-6
ii  fonts-noto-core 20201225-1
ii  fonts-noto-extra20201225-1
ii  fonts-noto-mono 20201225-1
ii  fonts-noto-ui-core  20201225-1
ii  fonts-sil-gentium-basic 1.102-1.1
ii  libreoffice-java-common 1:7.3.0~rc2-3
ii  libreoffice-nlpsolver   0.9+LibO7.3.0~rc2-3
pn  libreoffice-report-builder  
ii  libreoffice-script-provider-bsh 1:7.3.0~rc2-3
ii  libreoffice-script-provider-js  1:7.3.0~rc2-3
ii  libreoffice-script-provider-python  1:7.3.0~rc2-3
ii  libreoffice-sdbc-mysql  1:7.3.0~rc2-3
ii  libreoffice-sdbc-postgresql 1:7.3.0~rc2-3
ii  libreoffice-wiki-publisher  1.2.0+LibO7.3.0~rc2-3

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.3op2-7
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox 96.0.1-1
ii  ghostscript 9.55.0~dfsg-3
ii  gnupg   2.2.27-3
pn  gpa 
ii  gstreamer1.0-libav  1.18.5-1
ii  gstreamer1.0-plugins-bad1.18.5-1+b4
ii  gstreamer1.0-plugins-base   1.18.5-1
ii  gstreamer1.0-plugins-good   1.18.5-2
ii  gstreamer1.0-plugins-ugly   1.18.5-1
ii  hunspell-de-de [hunspell-dictionary]20161207-9
ii  hunspell-en-gb [hunspell-dictionary]1:7.2.0-2
ii  hunspell-en-us [hunspell-dictionary]1:2020.12.07-2
ii  hunspell-it [hunspell-dictionary]   1:7.2.0-2
ii  hunspell-pl [hunspell-dictionary]   1:7.2.0-2
ii  hunspell-pt-br [hunspell-dictionary]1:7.2.0-2
ii  hyphen-pt-pt [hyphen-hyphenation-patterns]  1:7.2.0-2
ii  imagemagick 8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3
ii  libgl1  1.4.0-1
pn  libofficebean-java  
ii  libreoffice-gnome   1:7.3.0~rc2-3
pn  libreoffice-grammarcheck
pn  libreoffice-help
ii  libreoffice-l10n-de [libreoffice-l10n]  1:7.3.0~rc2-3
ii  libreoffice-librelogo   1:7.3.0~rc2-3
ii  libsane11.0.32-4
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart-libreoffice 
ii  openjdk-10-jre [java8-runtime]  10.0.2+13-2
ii  openjdk-11-jre [java8-runtime]  11.0.14+9-1
pn  pstoedit
ii  thunderbird 1:91.5.1-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.3
ii  fonts-opensymbol2:102.12+LibO7.3.0~rc2-3
ii  libabsl20200923 0~20200923.3-3
ii  libboost-locale1.74.0   

Bug#864795: RFP: brave-browser -- web browser with privacy and micropayment features

[Nilesh Patra]

On 1/26/22 1:29 PM, Nilesh Patra wrote:
Long time since this ITP is open, just wanted to know if there's 
something blocking this, and/or if you're working on this anymore?


Oops, looks like this was always an RFP, apologies for the noise :)

Regards,
Nilesh

Bug#588484: regex(7): incorrect semantics for backslash + ordinary character

[Florian Ernst]

On Thu, Jul 08, 2010 at 10:31:54PM +0200, Jakub Wilk wrote:
> According to regex(7) manpage, a backslash followed by any other character
> than ^.[$()|*+?{\ matches that character taken as an ordinary character, as
> if the backslash had not been present. However:
> 
> * According to POSIX[0], the interpretation of an ordinary character
> preceded by a backslash is undefined.

The current manpage (5.10-1 or 5.13 upstream) at least now annotates the
corresponding parts, including the one referenced to, with

| POSIX.2 leaves some aspects of RE syntax and semantics open; "(!)"
| marks decisions on these aspects that may not be fully portable to other
| POSIX.2 implementations.

So this improves the situation somewhat.

> * Worse still, the described behavior differs from what is actually
> implemented in the GNU libc:
> 
> $ gcc -Wall testre.c -o testre && ./testre
> \S matches foobar

This part still seems to hold true.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#909794: manpages-dev: res_nclose is not mentioned in the resolver man page

[Florian Ernst]

On Fri, Sep 28, 2018 at 04:52:34PM +0200, Michael Becker wrote:
> as res_nclose is not mentioned, programms developed according the
> documention loose some byte of memory with every call

man-pages-5.00 lists in its Changes

| resolver.3
| Michael Becker
| Add documentation of res_nclose()

and indeed that page now does mention res_nclose() in NAME, SYNOPSIS and
ATTRIBUTES, and in DESCRIPTION it states

| Every call to res_ninit() requires a corresponding call to res_nclose()
| to free memory allocated by res_ninit() and subsequent calls to res_nquery().

As such I'd consider this bug here resolved.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#989580: updated patch

[Florian Ernst]

On Thu, Jun 10, 2021 at 01:15:48PM -0600, dann frazier wrote:
> Both patches are now upstream. Here's an updated debdiff.

FWIW, the upstream Changes for man-pages-5.12 lists

| kernel_lockdown.7
| dann frazier  [Alejandro Colomar]
| Remove description of lifting via SysRq (not upstream)
| The patch that implemented lockdown lifting via SysRq ended up
| getting dropped[*] before the feature was merged upstream. Having
| the feature documented but unsupported has caused some confusion
| for our users.

And the updated manpage does not contain the parts anymore that the
updated debdiff mentioned above removes. As such I think this bug here
can simply be closed by packaging that upstream version.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#520571: manpages-dev: incorrect strtod documentation for NAN(...)

[Florian Ernst]

On Sat, Mar 21, 2009 at 01:22:57AM +0100, Vincent Lefevre wrote:
> The strtod(3) man page is incorrect concerning NAN(...). It says:
> 
>   A NAN is "NAN" (disregarding case) optionally followed by '(', a
>   sequence of characters, followed by ')'.
> 
> but doesn't require anything concerning the sequence of characters
> (one may think that any sequence is allowed up to the first closing
> parenthesis). However the glibc 2.9-6 package seems to strictly
> follow the ISO C99 standard, which says:
> 
> [Section 7.20.1.3]
>   NAN or NAN(n-char-sequence_opt), ignoring case in the NAN part,
>   where: 
> n-char-sequence: 
>   digit
>   nondigit
>   n-char-sequence digit
>   n-char-sequence nondigit
> 
> [Section 6.4.2.1]
>nondigit: one of
>_  a  b  c  d  e  f  g  h  i  j  k  l  m
>   n  o  p  q  r  s  t  u  v  w  x  y  z
>   A  B  C  D  E  F  G  H  I  J  K  L  M
>   N  O  P  Q  R  S  T  U  V  W  X  Y  Z
>digit: one of
>0  1  2  3  4  5  6  7  8  9
> 
> Also the man page should explicitly say that the sequence can be
> empty. So, I propose:
> 
>   A NAN is "NAN" (disregarding case) optionally followed by '(',
>   a possibly empty sequence of characters, followed by ')'.  Each
>   character of the sequence must be either the underscore '_' or
>   an alphanumeric character in the "C" locale.

The current manpage (5.10-1 as in Debian or 5.13 upstream) instead reads

| A NAN is "NAN" (disregarding case) optionally followed by a string,
| (n-char-sequence), where n-char-sequence specifies in an
| implementation-dependent way the type of NAN (see NOTES).
| [...]
| In the glibc implementation, the n-char-sequence that optionally follows
| "NAN" is interpreted as an integer number (with an optional '0' or '0x'
| prefix to select base 8 or 16) that is to be placed in the mantissa
| component of the returned value.

This elaborates on the sequence of characters, and the "optionally
followed by" IMO sufficiently clarifies that the sequence can indeed be
empty. As such I'd think this bug here could simply be closed.

The corresponding upstream changes seem to first have been part of
man-pages-3.71 (first packaged in 3.71-1) where the Changes list

| strtod.3
| Michael Kerrisk
| Explain NAN(n-char-sequence)

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

[Paul Gevers]

Hi all,

On 04-12-2021 22:44, Paul Gevers wrote:

On Thu, 02 Dec 2021 13:44:15 +0100 Paul Gevers  wrote:

The last couple of days, two of the ci.debian.net arm64 workers became
unresponsive. The systems were rebooted and I found the message in
the journal pasted below.


Of course the absence of these failures doesn't prove the bug is gone, 
but since upgrading our systems to 5.10.84-1 (on 20 December 2021), I 
have not seen this failure again. Maybe it's about time we close this 
bug and assume it's fixed in version 5.10.84-1?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998427: Fixed upstream

[Diederik de Haas]

Control: tag -1 fixed-upstream

In https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?
id=010b0e27f98442ad9366ecdcb09601f92334c293 the 'at_console' setting was 
removed and a setting for the netdev group was added.

Note that the recently released 1.22 contains a bug which can cause a segfault 
on some systems. That issue has been fixed since and will be included in 1.23.

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

Bug#1004401: ITP: nicotine -- graphical client for the SoulSeek peer-to-peer system

[Francois Mazen]

Package: wnpp
Severity: wishlist
Owner: Francois Mazen 
X-Debbugs-Cc: debian-de...@lists.debian.org, franc...@mzf.fr

* Package name: nicotine
  Version : 3.2.0
  Upstream Author : Nicotine+ Team 
* URL : https://nicotine-plus.org/
* License : GPL-3+
  Programming Lang: Python
  Description : graphical client for the SoulSeek peer-to-peer system

Nicotine+ is a graphical client for the Soulseek peer-to-peer network. It aims
to be a pleasant, free and open source (FOSS) alternative to the official
Soulseek client, providing additional functionality while keeping current with
the Soulseek protocol. Nicotine+ uses GTK for its graphical user interface, and
is written in Python.

I intent to reintroduce the nicotine package and maintain it. It has been
removed due to lack of upstream maintenance. Recently the project got revived
and now there is a python3 version and active upstream.

Someone already opened an RFP, see #966000.

Bug#725934:

[khimaros]

the scripts linked above were not working for me. i've modified them to work 
with the latest release of debsecan and included a bit more background, 
prerequisites, and detailed instructions in this gist: 
https://gist.github.com/khimaros/21db936fa7885360f7bfe7f116b78daf

Bug#964906: This is still an issue in 11.2

[Jason Michaelson]

After two years i did a dist-upgrade on one particular system and this is
still an issue. I have to wonder why it got moved to btrfs-progs. This
really seems like a sequencing matter because all of the btrfs devices
aren't found before the system attempts to mount /. That makes me think
that it is an issue with initamfs-tools, especially since those of us who
have submitted potential fixes for it in this bug did so against initramfs
scripts.

I'm glad I had my script changes elsewhere and could migrate them from one
system to another when i encountered this problem. It would just be nice to
have it incorporated at the source.

Bug#1004363: ibus: pops up window with accent mark

[Gunnar Hjalmarsson]

@Brian: Thanks for additional info.

I probably tested on Wayland. Now I have tested on Xorg too, and don't 
see it there either.


I have one idea (and this is a long shot): Do you possibly have an 
~/.XCompose file? If you have, can you try to rename it (in order to 
disable it), relogin, and try again. The reason I ask is that I have 
 in mind. It shows that a mistake in 
~/.XCompose might lead to unexpected behavior.


@Osamu: Unloading ibus somehow would only be a workaround, right? I 
mean, you should be able to use a Compose key without issues also when 
the ibus-daemon is running.


--
Gunnar

Bug#1004400: ITP: node-less-plugin-clean-css -- clean-css plugin for less.js

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: node-less-plugin-clean-css
 Version : 1.5.1
 Upstream Author : Luke Page 
* URL : https://github.com/less/less-plugin-clean-css
* License : Apache-2.0
 Programming Lang: JavaScript
 Description : clean-css plugin for less.js

Compresses the css output from less (a backwards-compatible language
extension for CSS) using clean-css.  Specify the plugin with the
--clean-css command line option to lessc.

Node.js is an event-based server-side JavaScript engine.

The presence of this plugin in Debian will fix #977974.

I plan on maintaining this package as a member of the Debian JavaScript Team.


signature.asc
Description: PGP signature

Bug#989604: [Pkg-openssl-devel] Bug#989604: libssl1.1: segfault on arm64 (M1) with some ciphers e.g. curl https://dl.yarnpkg.com

[Sebastian Andrzej Siewior]

On 2022-01-25 22:10:00 [-0500], Anders Kaseorg wrote:
> Control: fixed 989604 1.1.1i-1
> Control: tags 989604 + buster patch

Thanks.

> The fix is trivial, swapping two lines of assembly.  I’ve attached it as a 
> debdiff, and tested it in a Debian 10 container on an M1 MacBook.  Can it 
> be considered for oldstable?

Yes. My plan is to get m into o-stable and oo-stable. The o-stable
update is tracked in #1003484.

> Anders

Sebastian

Bug#995356: python-parameterized: autopkgtest regression: AssertionError in tearDownModule

[Paul Gevers]

Hi Sandro,

On 26-01-2022 05:24, Sandro Tosi wrote:

If nobody is going to fix this issue, I am going to upload the package
removing the autopkgtest soon.


I took your NMU diff and made it a team upload, thanks!


I regret my bold action a bit, so I'll try to figure out a proper patch 
if I find time the next days.



This issue is blocking migration to
testing for too long. The package can't be easily removed because it's a
key package.


is there a publicly available list of key packages?


Yes: https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004269: Linker segfault while building src:xen

[Maximilian Engelhardt]

Control: found -1 2.37.90.20220123-2
Control: affects -1 src:xen

Hi,

this bug is still present in my sbuild chroot (updated about an hour ago) when 
compiling xen 4.14.3+32-g9de3671772-1 from unstable. I managed to run 
x86_64-linux-gnu-ld inside gdb to catch the segmentation fault. Please see the 
output below. I hope this is helpful to somebody tracking down the problem.

Please note for the xen case:
in
https://sources.debian.org/src/xen/4.14.3+32-g9de3671772-1/xen/arch/x86/Makefile/?hl=185#L185
the linker is checked for PE support. If it segfaults during this check the 
build system will disable building some parts below in this Makefile. So in 
this case it might never try to call the command from my gdb output below.
In my sbuild this check command randomly completes with return code 0 or with 
a segmentation fault using the following command:
$ x86_64-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0x1 
--stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x20 
--file-alignment=0x20 --major-image-version=4 --minor-image-version=14 
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 -o efi/check.efi efi/check.o


$ gdb -batch -n -ex 'set pagination off' -ex 'run -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 --strip-debug 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=14 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp   
--build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/common/symbols-dummy.o -b 
pe-x86-64 efi/buildid.o -o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/.xen.efi.0x82d04000.0 
&&  x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d08000 --stack=0,0 --heap=0,0 --strip-debug 
--section-alignment=0x20 --file-alignment=0x20 --major-image-version=4 
--minor-image-version=14 --major-os-version=2 --minor-os-version=0 
--major-subsystem-version=2 --minor-subsystem-version=0 --no-insert-timestamp   
--build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/common/symbols-dummy.o -b 
pe-x86-64 efi/buildid.o -o 
/build/xen-Hf5EN0/xen-4.14.3+32-g9de3671772/xen/.xen.efi.0x82d08000.0' 
-ex bt -ex 'bt full' --args x86_64-linux-gnu-ld

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x77f6bbac in coff_write_auxent_fname.isra.0 (str=0x23527e , auxent=auxent@entry=0x7fffe208, 
string_size_p=string_size_p@entry=0x7fffe2d8, abfd=, 
abfd=) at ../../bfd/coffgen.c:856
#2  0x77f3806d in coff_write_symbol (abfd=0x55701b20, 
symbol=0x77973780, native=native@entry=0x7fffe1c0, 
written=0x7fffe2d0, string_size_p=0x7fffe2d8, 
debug_string_section_p=debug_string_section_p@entry=0x0, 
debug_string_size_p=0x0) at ../../bfd/coffgen.c:1043
#3  0x77f3834e in coff_write_alien_symbol (abfd=, 
symbol=, isym=0x7fffe310, iaux=0x7fffe2e0, 
written=, string_size_p=, 
debug_string_section_p=0x0, debug_string_size_p=0x0) at ../../bfd/coffgen.c:1154
#4  0x77f2e74a in _bfd_coff_final_link (abfd=, 
info=0x556fa3c0 ) at ../../bfd/cofflink.c:928
#5  0x5559b53f in ldwrite () at ../../ld/ldwrite.c:545
#6  main (argc=, argv=) at ../../ld/ldmain.c:513
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
No locals.
#1  0x77f6bbac in coff_write_auxent_fname.isra.0 (str=0x23527e , auxent=auxent@entry=0x7fffe208, 
string_size_p=string_size_p@entry=0x7fffe2d8, abfd=, 
abfd=) at ../../bfd/coffgen.c:856
str_length = 
filnmlen = 
#2  0x77f3806d in coff_write_symbol (abfd=0x55701b20, 
symbol=0x77973780, native=native@entry=0x7fffe1c0, 
written=0x7fffe2d0, string_size_p=0x7fffe2d8, 
debug_string_section_p=debug_string_section_p@entry=0x0, 
debug_string_size_p=0x0) at ../../bfd/coffgen.c:1043
auxesz = 18
j = 
numaux = 1
type = 
n_sclass = 
output_section = 
buf = 0x558abf00
symesz = 
#3  0x77f3834e in coff_write_alien_symbol (abfd=, 
symbol=, isym=0x7fffe310, iaux=0x7fffe2e0, 
written=, string_size_p=, 
debug_string_section_p=0x0, debug_string_size_p=0x0) at ../../bfd/coffgen.c:1154
native = 0x7fffe1c0
dummy = {{offset = 1, fix_value = 0, fix_tag = 0, fix_end = 0, 
fix_scnlen = 0, fix_line = 0, u = {auxent = {x_sym = {x_tagndx = {l = 
435610543662, p = 0x656c69662e}, x_misc = {x_lnsz = {x_lnno = 46240, x_size = 
63456}, x_fsize = 140737352086688}, x_fcnary = {x_fcn = {x_lnnoptr = 
140737350733261, 

Bug#1004378: dh_python3: does not correctly handle some cases of os-versioned dependencies

[stefanor]

Hi Julian (2022.01.26_10:00:17_+)
> I'm in the process of packaging the latest version of send2trash, and
> have stumbled upon an interesting bug.
> 
> During the build, I get the warnings:
> 
>dh_python3 -O--buildsystem=pybuild
> I: dh_python3 pydist:293: Cannot find package that provides 
> pyobjc_framework_cocoa. Please add package that provides it to Build-Depends 
> or add "pyobjc_framework_cocoa python3-pyobjc-framework-cocoa" line to 
> debian/py3dist-overrides or add proper dependency to Depends by hand and 
> ignore this info.
> I: dh_python3 pydist:293: Cannot find package that provides pywin32. Please 
> add package that provides it to Build-Depends or add "pywin32 
> python3-pywin32" line to debian/py3dist-overrides or add proper dependency to 
> Depends by hand and ignore this info.

Can you push this to git so I can reproduce it?
I tried parsing the METADATA you provided, and can't reproduce on that.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#768376: [Pkg-libvirt-maintainers] Bug#768376: [libvirt-daemon-system]

[devel]

Hello,

given the recent CVE-2021-4034 (gaining local root access via "policykit-1"), I
would like to raise this request again: it would be great, if the
libvirt-daemon-system package would reduce its hard dependency ("Depends") on
"policykit-1" to a soft dependency ("Recommends").

If I understand your previous comment correctly, then this is technically
feasible (i.e. "it just works"):

On Tue, 7 Jul 2015 07:15:06 +0200 Guido Günther  wrote:
> I do agree that being able to go without polkit would be nice but a
> similar situation with virt-manger showed that Recommends: are just not
> enough. Many people skip them and then report bugs if you use Recommends
> for a package that's needed in 95% of the installations. I'm just not up
> to handle these.


I understand, that such bug reports can take effort.
But I think, the circumstances changed meanwhile (since 2015): "apt" installs
"Recommends" by default (see `apt-config dump | grep -w Recommends`), thus there
should be only very few users who are manually overriding this setting.
And I think, there is a fair chance, that these users know what they are doing.

The Debian Policy [2] also advises to use "Recommends" in this case.

Please reduce the "Depends" relationship towards "policykit-1" down to
"Recommends".

Thank you for maintaining this package!

Cheers,
Lars


[1] https://www.debian.org/security/2022/dsa-5059
[2] https://www.debian.org/doc/debian-policy/ch-relationships.html

Bug#1004399: does not support booting mini.iso

[Peter Palfrader]

Package: virtinst
Version: 1:3.2.0-3
Severity: normal
Tags: patch

vrit-install appears to not support installing off a Debian mini.iso:

Starting install...
ERRORCouldn't find kernel for install tree.
Domain installation does not appear to have been successful.


The following patch makes that work:

--- ./urldetect.py  2022-01-26 19:25:19.835922099 +
+++ /usr/share/virt-manager/virtinst/install/urldetect.py   2022-01-26 
19:25:22.447863479 +
@@ -751,7 +751,7 @@
 kpair = ("boot/linux_vm", "boot/root.bin")
 else:
 kpair = ("install/vmlinuz", "install/initrd.gz")
-self._kernel_paths += [kpair]
+self._kernel_paths += [kpair, ('/linux', '/initrd.gz')]
 return True
 
 def _detect_version(self):

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#848231: bugs in scandir example program

[Florian Ernst]

On Thu, Dec 15, 2016 at 04:59:38PM +0100, Michael Kerrisk (man-pages) wrote:
> [...]
> All fixed now. This is the current code:
> 
>#define _DEFAULT_SOURCE
>#include 
>#include 
>#include 
> 
>int
>main(void)
>{
>struct dirent **namelist;
>int n;
> 
>n = scandir(".", , NULL, alphasort);
>if (n == -1) {
>perror("scandir");
>exit(EXIT_FAILURE);
>}
> 
>while (n--) {
>printf("%s\n", namelist[n]->d_name);
>free(namelist[n]);
>}
>free(namelist);
> 
>exit(EXIT_SUCCESS);
>}

Confirmed to be present in man-pages-4.10 (first packaged in Debian in
4.10-1) and also confirmed working, hence this bug could be closed
accordingly.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#909789: manpages-dev: stat(2) manpage on ENOENT for dangling symbolic links (broken links)

[Florian Ernst]

On Fri, Sep 28, 2018 at 10:14:21PM +0200, Michael Kerrisk (man-opages) wrote:
> [...]
> It's not merely a question of a broken symlink in the final pathname
> component, which lstat() could address. ENOENT can also occur if any
> component in the pathname is a dangling symbolic link. So I changed the
> ENOENT text to:
> 
>ENOENT A  component  of  pathname  does not exist or is a
>   dangling symbolic link.
> 
>ENOENT pathname is an empty string and AT_EMPTY_PATH  was
>   not specified in flags.

Confirmed to be present in man-pages-5.00 (first packaged in Debian in
5.01-1), hence this bug could be closed accordingly.

> > Besides, the 1st paragraph in the NOTES section says "AT_NO_AUTOMOUNT fag".
> > Please substitute "AT_NO_AUTOMOUNT flag" lest someone smokes their unmounted
> > devices...
> 
> :-)
> 
> In fact, that text was fixed about a year ago, so you don't have quite
> the most up-to-date pages :-).

Also confirmed to be fixed.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#992377: manpages-dev

[Florian Ernst]

On Wed, Aug 18, 2021 at 11:44:14AM +0200, Michael Kerrisk (man-pages) wrote:
> Upstream maintainer here. The keyutils pages in Section 2
> are an unusual case. The wrapper functions are provided in
> the libkeyutils library (instead of, as is conventional, 
> the C library), as noted in the add_key(2) page.
> The package that provides that library also provides
> the  header file. The manual page implies
> that, but doesn't make it completely clear. I've added 
> a sentence to the manual page to make this more explicit:
> 
>Glibc does not provide a wrapper for this system call.  A  wrapper
>is provided in the libkeyutils library.  **(The accompanying package
>provides the  header file.)**  When employing the  wrap‐
>per in that library, link with -lkeyutils.
> 
> Of course, the name of the relevant package depends on the distro.
> For Debian, I believe it is "libkeyutils-dev". (I run Fedora,
> where the package is the somewhat unconventionally named
> "keyutils-libs-devel".)

Confirmed to be present in man-pages-5.13, and IMO sufficiently
explained, hence this bug could be closed accordingly once that version
gets packaged.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#845172: manpages-dev: no function protypes in example from mbstowcs(3)

[Florian Ernst]

On Mon, Nov 21, 2016 at 01:05:24PM +0100, Michael Kerrisk (man-pages) wrote:
> Upstream maintainer here.
> 
> I added the missing include.

Confirmed to be present in man-pages-4.09 (first packaged in Debian in
4.09-1), hence this bug could be closed accordingly.

> But I am unsure what to do about the other point (regarding gcc
> -Wconversion). [...]

I share that feeling. However, IMO the actual bug was the missing
include which had been fixed, so I still think this bug could just be closed.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#995201: chrony: Custom UNIX socket?

[root]

Package: chrony
Version: 4.0-8+deb11u1
Followup-For: Bug #995201
X-Debbugs-Cc: s.egb...@sbcglobal.net


Also, the client-side 'chronyc' is NOT able to use a custom UNIX socket
path.

We can configure or change such UNIX socket path on the server side
using 'bindcmdaddress'

But we cannot lead the horse (chronyc) by the nose (UNIX socket path) to the 
watering hole (chronyd socket path).

Perhaps, remove support for UNIX socket path altogether (just kidding
there) or provide a command-line option for chronyc to select its 
own non-compiled-in/non-default UNIX socket pathway.

Real world example: I've got 3 separate instances of chronyd running
(using a custom chronyd@netdev.service instances). I can only view 
exactly and at most ONE instance of those three(3) chrony daemons by 
the virtue of its compiled in default (/run/chrony/chrony.sock).  
And none of those are viewable by chrony client if using 'bindaddress' 
directive non-default setting at each instance of the chrony servers.

General idea is to ensure that UDP packets go into a specific interface
as indicated by the 'ss' util:

  # ss -lu | grep ntp
  UNCONN 0  0  172.16.1.1%enp4s0:ntp 0.0.0.0:*
  UNCONN 0  0   172.17.2.1%vmbr0:ntp 0.0.0.0:*
  UNCONN 0  0 172.18.1.1%br0:ntp 0.0.0.0:*

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

Versions of packages chrony depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  iproute2 5.10.0-4
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libedit2 3.1-20191231-2+b1
ii  libgnutls30  3.7.1-5
ii  libnettle8   3.7.3-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  tzdata   2021a-1+deb11u2
ii  ucf  3.0043

chrony recommends no packages.

Versions of packages chrony suggests:
ii  bind9-dnsutils [dnsutils]  1:9.16.22-1~deb11u1   (Using latest ISC Bind9 
9.17+
pn  networkd-dispatcher  (this is a bare-boned appliance server)

-- Configuration Files:
/etc/chrony/conf.d/README [Errno 2] No such file or directory: 
'/etc/chrony/conf.d/README'
/etc/chrony/sources.d/README [Errno 2] No such file or directory: 
'/etc/chrony/sources.d/README'
/etc/default/chrony changed [not included] (not applicable)
/etc/dhcp/dhclient-exit-hooks.d/chrony changed [not included] (not
applicable)

-- no debconf information

Bug#1004077: node-pbkdf2: autopkgtest regression on s390x

[Yadd]

On 26/01/2022 16:20, Yadd wrote:

On 22/01/2022 10:28, Yadd wrote:

Hi,

I wrote a quick-and-dirty patch for UInt32, you just have to detect 
32/16/8 bits with thing.BYTES_PER_ELEMENT and fix the call of my new 
function.


Else I'll probably able to fix that next week.


Cheers,
Yadd


Hi,

fixed locally except ripemd160 test (probably node-ripemd160 bug). I'm 
going to fix that


False positive

I think I fixed all issues:
 * TypedArray conversions for big-endian architectures
 * test on armhf (tap+tape does something strange, I switched to
   tape only like upstream test)

Hope all is good now

Cheers,
Yadd

Bug#1004214: Acknowledgement (kodi: Segfaults on menu selection)

[Vasyl Gello]

Control: close -1

I am closing this bug because additional investigation revealed the issue with 
a banned Kodi addon.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1004397: ilorest: Fails to upgrade: Git merge conflict markers in /usr/lib/python3/dist-packages/ilorest/rdmc.py causing Python syntax error during postinst

[Axel Beckert]

Package: ilorest
Version: 3.3.0.0+ds1-1
Severity: serious

Upgrading ilorest to 3.3.0.0+ds1-1 fails for me as follows:

Setting up ilorest (3.3.0.0+ds1-1) ...
  File "/usr/lib/python3/dist-packages/ilorest/rdmc.py", line 995
<<< HEAD:ilorest/rdmc.py
^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/ilorest/rdmc.py", line 995
<<< HEAD:ilorest/rdmc.py
^^
SyntaxError: invalid syntax
dpkg: error processing package ilorest (--configure):
 installed ilorest package post-installation script subprocess returned error 
exit status 1

The offending lines are:

995 <<< HEAD:ilorest/rdmc.py
996 def ilorestcommand():
997 ===
998 
999 if __name__ == '__main__':
   1000 >>> v3.3.0.0:src/rdmc.py

And later on also:

   1034 <<< HEAD:ilorest/rdmc.py
   1035 return RDMC.retcode
   1036 
   1037 if __name__ == '__main__':
   1038 # Return code
   1039 sys.exit(ilorestcommand())
   1040 ===
   1041 # Return code
   1042 sys.exit(RDMC.retcode)
   1043 >>> v3.3.0.0:src/rdmc.py

Oh, and btw.,
https://salsa.debian.org/openstack-team/third-party/python-redfish-utility
(as mentioned in the Vcs-Browse header) gives a "404 Not Found".

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ilorest depends on:
ii  libjs-sphinxdoc 4.3.2-1
ii  python3 3.9.8-1
ii  python3-certifi 2020.6.20-1
ii  python3-colorama0.4.4-1
ii  python3-decorator   4.4.2-2
ii  python3-ilorest 3.3.0.0+ds-1
ii  python3-json-pointer2.1-3
ii  python3-jsondiff1.1.1-4
ii  python3-jsonpatch   1.32-2
ii  python3-jsonpath-rw 1.4.0-4
ii  python3-pbr 5.6.0-2
ii  python3-ply 3.11-5
ii  python3-prompt-toolkit  3.0.24-1
ii  python3-pyaes   1.6.1-4
ii  python3-pyudev  0.22.0-2
ii  python3-setproctitle1.2.2-2+b1
ii  python3-setuptools  59.6.0-1.2
ii  python3-six 1.16.0-3
ii  python3-tabulate0.8.9-1
ii  python3-urllib3 1.26.5-1~exp1
ii  python3-validictory 1.1.2-2
ii  python3-wcwidth 0.1.9+dfsg1-2

ilorest recommends no packages.

ilorest suggests no packages.

-- no debconf information

Bug#1004395: tigervnc-standalone-server: Gnome desktop does not start when using tigervncserver@.service

[joachim . falk]

Package: tigervnc-standalone-server
Version: 1.11.0+dfsg-2
Severity: important
Tags: patch
X-Debbugs-Cc: code0...@mailbox.org, joachim.f...@gmx.de

Den tors 20 jan. 2022 14:06code0815  skrev:
> Dear Maintainers,
>
> I'm using debian bullseye and facing a bug, that is present inside the
> tigervnc-standalone-server packages 1.11.0+dfsg-2, 1.11.0+dfsg-3. The
> bug does affect the Gnome environment, so that a gnome-session is not
> started properly, when started through tigervncserver@.service. So the
> bug makes tigervnc-standalone-server unuseable, if a user does want to
> use a Gnome-Session inside TigerVNC.
>
> This bug does not come up anymore, if I do install tigervnc-1.12 from
> the TigerVNC developers source packages. The bug does affect Ubuntu
> 21.10, too. It seems to me, that all 1.11 versions - not debian based
> only - are affected.

-- 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/16 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 tigervnc-standalone-server depends on:
ii  libaudit1   1:3.0-2
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+deb11u2
ii  libfile-readbackwards-perl  1.05-2
ii  libgcrypt20 1.8.7-6
ii  libgl1  1.3.2-1
ii  libgnutls30 3.7.1-5
ii  libjpeg62-turbo 1:2.0.6-4
ii  libpam0g1.4.0-9+deb11u1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  perl5.32.1-4+deb11u2
hi  tigervnc-common 1.11.0+dfsg-2
ii  x11-xkb-utils   7.7+5
ii  xauth   1:1.1-1
ii  xkb-data2.29-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri20.3.5-1
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.5

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

-- Configuration Files:
/etc/tigervnc/vncserver.users changed [not included]

-- no debconf information
diff --git a/debian/helpers/etc/pam.d/tigervnc 
b/debian/helpers/etc/pam.d/tigervnc
index 68c261a..3e42c5c 100644
--- a/debian/helpers/etc/pam.d/tigervnc
+++ b/debian/helpers/etc/pam.d/tigervnc
@@ -2,4 +2,4 @@

 @include common-auth
 @include common-account
-@include common-session-noninteractive
+@include common-session

Bug#1004256: messages to dispatch+aide_cont...@tracker.debian.org get multiplied

[Marc Haber]

Hi Raphael,

thank you for acting on this issue.

On Wed, Jan 26, 2022 at 03:19:12PM +0100, Raphael Hertzog wrote:
> On Sun, 23 Jan 2022, Marc Haber wrote:
> > I regularly use pack...@packages.debian.org as Maintainer address for my
> > packages. Having an implicit mailing list for package maintenance issues
> > is extremele helpful and I appreciate that features.
> > 
> > Since a few weeks, messages to those addresses get multiplied inside the
> > tracker, namely ticharich.debian.org, between five and ten times. I see
> > this, and other members of the teams I am on see it as well.
> 
> This was due to a subscriber of the aide package being known under two
> different emails varying only on the case. I don't know how this happened
> because all the code should identify emails case-insensitively and not
> create a second instance of the same email.

Interesting, I thoght I got those multiplied messages for other packages
as well. But that might just have been wrong perception.

> Let me know if the problem persists.

Will do!

Greetings
Marc

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

Bug#1003753: Acknowledgement (chromium: chromium --temp-profile window displays only as a white box)

[Karl O. Pinc]

Hello,

Looks like this is _not_ fixed.  It appears
to be a race condition.  Sometimes it happens,
sometimes not.

Let me know if you need a new bug report filed.

I notice that, although window borders and other controls are
not displayed, the cursor still seems to respond
to being over the window controls.  I.e., when
hovering over the edge of the "white box" the cursor
(in xfce4) changes to the "arrow with the bar at tip"
and I can grab the edge and resize the box.  Likewise,
I can move the box by "grabbing" where I would expect
the title bar to be.  And clicking where the close-box
for the window should be makes the application close.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1004242: [Pkg-shadow-devel] Bug#1004242: shadow:[INTL:fr] updated French man page translation

[Bálint Réczey]

Control: forwarded -1 https://github.com/shadow-maint/shadow/pull/499
Control: tags -1 upstream

Hi,

 ezt írta (időpont: 2022. jan. 23., V, 13:06):
>
> Package: shadow
> Version:4.0.18
> Severity: wishlist
> Tags: patch l10n
>
> Dear mainteners,
> Hello, please find the updated french translation for shadow attached,
> proofread by the debian-l10n-french mailing list contributors.
>
> This file should be put as debian/po/fr.po in your package build tree.

As I see this should be applied upstream, thus I've forwarded it with
a few fixes.

Cheers,
Balint

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Samuel Thibault]

Svante Signell, le mer. 26 janv. 2022 10:31:23 +0100, a ecrit:
> On Tue, 2022-01-25 at 23:42 +0100, Samuel Thibault wrote:
> > Svante Signell, le mar. 25 janv. 2022 23:40:17 +0100, a ecrit:
> > > On Tue, 2022-01-25 at 22:16 +0100, Samuel Thibault wrote:
> > > > > 
> > > > > Thanks!
> > > > > But on a third image I get:
> > > > > mkdir: cannot create directory ‘/home’: File exists
> > > > > 
> > > > > Something is fishy...
> > > > 
> > > > As I already wrote, first make sure exactly *what* is producing
> > > > this
> > > > call. That way you'll see where the fish comes from.
> > > 
> > > I'd really appreciate to know the difference of an old image upgraded
> > > to current and a new one??
> > 
> > No idea. As I've already written, I'm just using the
> > debian-hurd-20210812.img image, upgraded to current archive.
> 
> I did add set -x to mkinstalldirs:
> 
> make[3]: Entering directory '/home/.../hurd-0.9.git20211230/build-
> deb/libshouldbeinlibc'
> + errstatus=0
> + echo :/home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
> + sed -ne s/^:\//#/;s/^://;s/\// /g;s/^#/\//;p
> + set fnord /home srs DEBs hurd hurd-0.9.git20211230 debian tmp lib i386-gnu

Ah ok, that's what /home comes from, mkinstalldirs already splits the
path into separate components.

> + shift
> + pathcomp=
> + pathcomp=/home
> + test ! -d /home

> + echo mkdir /home
> mkdir /home
> + mkdir /home
> mkdir: cannot create directory ‘/home’: File exists

So here the problem is that

test ! -d /home

says that /home is not a directory. Is there anything special about your
/home path? Perhaps show the output of

stat /home

Samuel

Bug#1004391: python-fluids: please make the build reproducible

[Chris Lamb]

forwarded 1004391 https://github.com/CalebBell/fluids/pull/46
thanks

I've forwarded this upstream here:

  https://github.com/CalebBell/fluids/pull/46


Regards,

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

Bug#1002862: (no subject)

[Ayoyimika Ajibade]

Fixing previous prevalent error message affecting many revserse 
dependencies of webpack5 and thereafter enabling upstream test lead to 
this module babel-preset-react not found error.


A potential fix is for upstream to update its babel-preset-react from 
version 6.24.1 to version 7.10.1 where the name also changes from 
babel-preset-react to @babel/preset-react


important error log:

   dh_auto_test --buildsystem=nodejs
ln -s ../. node_modules/prop-types
/bin/sh -ex debian/tests/pkg-js/test
+ jest
 FAIL  __tests__/PropTypesProductionStandalone-test.js
  ● Test suite failed to run

Cannot find module 'babel-preset-react'
Require stack:
- /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
- /usr/share/nodejs/@babel/core/lib/config/files/index.js
- /usr/share/nodejs/@babel/core/lib/index.js
- /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
- /usr/share/nodejs/babel-jest/build/index.js
- /usr/share/nodejs/jest-util/build/requireOrImportModule.js
- /usr/share/nodejs/jest-util/build/index.js
- /usr/share/nodejs/jest-resolve/build/resolver.js
- /usr/share/nodejs/jest-resolve/build/index.js
- /usr/share/nodejs/jest-runtime/build/index.js
- /usr/share/nodejs/jest-runner/build/testWorker.js
- /usr/share/nodejs/jest-worker/build/workers/processChild.js
- If you want to resolve "react", use "module:react"
- Did you mean "@babel/react"?

  155 | f.code = "MODULE_NOT_FOUND";
  156 | throw f;
> 157 |   })(id, {
  | ^
  158 | paths: [dirname]
  159 |   })
  160 | };

  at tryRequireResolve 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:157:9)
  at resolveStandardizedNameForRequrie 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:195:17)
  at sync 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:229:12)

  at sync (../../../../../usr/share/nodejs/gensync/index.js:182:19)
  at ../../../../../usr/share/nodejs/gensync/index.js:210:24
  at resolvePreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:87:17)

  at resolvePreset.next ()

 FAIL  __tests__/PropTypesDevelopmentStandalone-test.js
  ● Test suite failed to run

Cannot find module 'babel-preset-react'
Require stack:
- /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
- /usr/share/nodejs/@babel/core/lib/config/files/index.js
- /usr/share/nodejs/@babel/core/lib/index.js
- /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
- /usr/share/nodejs/babel-jest/build/index.js
- /usr/share/nodejs/jest-util/build/requireOrImportModule.js
- /usr/share/nodejs/jest-util/build/index.js
- /usr/share/nodejs/jest-resolve/build/resolver.js
- /usr/share/nodejs/jest-resolve/build/index.js
- /usr/share/nodejs/jest-runtime/build/index.js
- /usr/share/nodejs/jest-runner/build/testWorker.js
- /usr/share/nodejs/jest-worker/build/workers/processChild.js
- If you want to resolve "react", use "module:react"
- Did you mean "@babel/react"?

  155 | f.code = "MODULE_NOT_FOUND";
  156 | throw f;
> 157 |   })(id, {
  | ^
  158 | paths: [dirname]
  159 |   })
  160 | };

  at tryRequireResolve 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:157:9)
  at resolveStandardizedNameForRequrie 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:195:17)
  at sync 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:229:12)

  at sync (../../../../../usr/share/nodejs/gensync/index.js:182:19)
  at ../../../../../usr/share/nodejs/gensync/index.js:210:24
  at resolvePreset 
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:87:17)

  at resolvePreset.next ()

 FAIL  __tests__/PropTypesDevelopmentReact15.js
  ● Test suite failed to run

Cannot find module 'babel-preset-react'
Require stack:
- /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
- /usr/share/nodejs/@babel/core/lib/config/files/index.js
- /usr/share/nodejs/@babel/core/lib/index.js
- /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
- /usr/share/nodejs/babel-jest/build/index.js
- /usr/share/nodejs/jest-util/build/requireOrImportModule.js
- /usr/share/nodejs/jest-util/build/index.js
- /usr/share/nodejs/jest-resolve/build/resolver.js
- /usr/share/nodejs/jest-resolve/build/index.js
- /usr/share/nodejs/jest-runtime/build/index.js
- /usr/share/nodejs/jest-runner/build/testWorker.js
- /usr/share/nodejs/jest-worker/build/workers/processChild.js
- If you want to resolve "react", use "module:react"
- Did you mean "@babel/react"?

  155 | f.code = "MODULE_NOT_FOUND";
  156 | throw f;
> 157 |

Bug#1004393: davical: Call to undefined function in Davical setup page

[Markus Krebs]

Package: davical
Version: 1.1.10-1
Severity: important
Tags: upstream
X-Debbugs-Cc: markus.kr...@web.de

Dear Maintainer,

on the Davical Setup Webpage, when choosing "Administration|Setup", the script 
ends with the error message "Exception [0] Call to undefined function 
get_magic_quotes_gpc()". As far as I know, this function is indeed no longer 
part of PHP8, but Davical is said to be PHP8-ready. Maybe not fully yet?

Sincerely,
Markus





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

Kernel: Linux 5.15.0-3-marvell
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)

Versions of packages davical depends on:
ii  libawl-php0.62-1
ii  libdbd-pg-perl3.15.0-2
ii  libyaml-perl  1.30-1
ii  perl  5.32.1-6
ii  php   2:8.1+92
ii  php-cli   2:8.1+92
ii  php-pgsql 2:8.1+92
ii  php-xml   2:8.1+92
ii  php8.1 [php]  8.1.1-4
ii  php8.1-cli [php-cli]  8.1.1-4
ii  php8.1-pgsql [php-pgsql]  8.1.1-4
ii  php8.1-xml [php-xml]  8.1.1-4
ii  postgresql-client-14 [postgresql-client]  14.1-5

Versions of packages davical recommends:
ii  php-curl2:8.1+92
ii  php8.1-curl [php-curl]  8.1.1-4
ii  postgresql  14+237

Versions of packages davical suggests:
ii  php-ldap2:8.1+92
ii  php8.1-ldap [php-ldap]  8.1.1-4

Bug#1004392: systemd: Incorrect location of configuration files

[Anton Ivanov]

Package: systemd
Version: 247.3-6
Severity: serious
Justification: Policy 10.7

Dear Maintainer,

/usr/lib/tmpfiles.d/x11.conf should be a configuration file. Entries in it must 
be disabled in order to run containers with accelerated X11 and DRI access. 

As it is under lib, changes to it are overwritten on every systemd update 
breaking all containers which run X apps with direct access to local X-server.

1. There is no way to disable it permanently.
2. There is no way to override it in a way which disables the defaults 

Actually, most of that directory does not belong in /usr - it should be under 
/etc as per Debian policy for configuration files and should be handled as 
config on
system upgrades and updates.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser3.118
ii  libacl12.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13+deb11u2
ii  libcap21:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup122:2.3.5-1
ii  libgcrypt201.8.7-6
ii  libgnutls303.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9+deb11u1
ii  libseccomp22.5.1-1+deb11u1
ii  libselinux13.1-3
ii  libsystemd0247.3-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
KillUserProcesses=yes
KillExcludeUsers=root


-- no debconf information

Bug#1004391: python-fluids: please make the build reproducible

[Chris Lamb]

Source: python-fluids
Version: 1.0.9-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
python-fluids could not be built reproducibly.

Patch attached.

 [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-01-26 07:56:28.105224591 
-0800
@@ -0,0 +1,21 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-01-26
+
+--- python-fluids-1.0.9.orig/docs/conf.py
 python-fluids-1.0.9/docs/conf.py
+@@ -77,8 +77,13 @@ master_doc = 'index'
+ 
+ # General information about the project.
+ project = u'Fluids'
++import os
++import time
+ import datetime
+-copyright = u'2016 - %s, Caleb Bell ' 
%datetime.datetime.now().year
++build_date = datetime.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++copyright = u'2016 - %s, Caleb Bell ' % 
build_date.year
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2022-01-26 07:44:49.337938744 -0800
--- b/debian/patches/series 2022-01-26 07:56:27.369225246 -0800
@@ -2,3 +2,4 @@
 remove-shields-dot-io-images.patch
 use-debian-mathjax.patch
 fix-online-tests.patch
+reproducible-build.patch

Bug#1004390: glibc: FTBFS on hppa - incorrect ctid argument in xclone.c

[John David Anglin]

Source: glibc
Version: 2.31-13+deb11u2
Severity: normal

Dear Maintainer,

Build fails here:

hppa-linux-gnu-gcc-10 xchmod.c -c -std=gnu11 -fgnu89-inline  -pipe -O2 -g 
-fdebug-prefix-map=/<>=. -Wall -Wwrite-strings -Wundef -Werror 
-fmerge-all-constants -frounding-math -fno-stack-protector -Wstrict-prototypes 
-Wold-style-definition -fmath-errno-fPIC-isystem 
/<>/debian/include  -I../include 
-I/<>/build-tree/hppa-libc/support  
-I/<>/build-tree/hppa-libc  -I../sysdeps/unix/sysv/linux/hppa  
-I../sysdeps/hppa/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/hppa/hppa1.1  
-I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/hppa/fpu  -I../sysdeps/hppa  
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc 
-isystem /usr/lib/gcc/hppa-linux-gnu/10/include -isystem 
/<>/debian/include -D_LIBC_REENTRANT -include 
/<>/build-tree/hppa-libc/libc-modules.h -DMODULE_NAME=libsupport 
-include ../include/libc-symbols.h   -DPIC -DLIBC_NONSHARED=1 
-DTOP_NAMESPACE=glibc -o 
/<>/build-tree/hppa-libc/support/xchmod.oS -MD -MP -MF 
/<>/build-tree/hppa-libc/support/xchmod.oS.dt -MT 
/<>/build-tree/hppa-libc/support/xchmod.oS
xclone.c: In function ‘xclone’:
xclone.c:41:8: error: ‘ctid’ undeclared (first use in this function)
   41 |   );
  |^~~~
xclone.c:41:8: note: each undeclared identifier is reported only once for each 
function it appears in

I believe this argument should be NULL.

Regards,
Dave Anglin


-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.16.2+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1004077: [Pkg-javascript-devel] Bug#1004077: Bug#1004077: node-pbkdf2: autopkgtest regression on s390x

[Yadd]

On 22/01/2022 10:28, Yadd wrote:

Hi,

I wrote a quick-and-dirty patch for UInt32, you just have to detect 
32/16/8 bits with thing.BYTES_PER_ELEMENT and fix the call of my new 
function.


Else I'll probably able to fix that next week.


Cheers,
Yadd


Hi,

fixed locally except ripemd160 test (probably node-ripemd160 bug). I'm 
going to fix that


Cheers,
Yadd

Bug#1004389: transition: botan

[GCS]

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

Hi RMs,

Straightforward transition of botan. Affected packages are biboumi,
rnp and thunderbird.
All builds fine with the botan 2.19.1+dfsg-1 version from experimental.

Regards,
Laszlo/GCS

Bug#1003536: Fwd: Re: Kernel related problem (randomly failing tests), where to discuss?

[Diederik de Haas]

I asked on the debian-kernel ML about this and got the following response:

--  Forwarded Message  --

Subject: Re: Kernel related problem (randomly failing tests), where to 
discuss?
Date: zondag 23 januari 2022, 16:40:11 CET
From: Ben Hutchings 
To: Diederik de Haas 
CC: Debian kernel maintainers 

On Sat, 2022-01-15 at 00:00 +0100, Diederik de Haas wrote:
> Hi,
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003536 I described the 
> problem in more detail, but I'll give the TL;DR here to determine the best 
> place/ML to discuss the issue further.
> 
> TL;DR: The iwd program deliberately/explicitly uses kernel features/modules 
> for some of its functionality. It also has a number of tests, but they fail 
> (or succeed) a bit (too) random, because whether a kernel module is loaded
> or  not depends on several factors:
[...]
> Has this problem been discussed before? If so, could someone point me to
> that? If not, where would the best place be to discuss this?

You shouldn't run any tests like this at build time.

For autopkgtests, if you set the needs-root and isolation-machine
restrictions then the tests will run as root on a VM.  But currently
neither salsa-ci nor ci.debian.net implements this, so those tests will
be skipped.

Another option in autopkgtests is to depend on qemu and start the VM
yourself.  This is not easy to do, but I implemented it for initramfs-
tools.

Ben.

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

Bug#1004387: Filed RFP #1004388

[Enrico Zini]

Hello,

I filed the RFP at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004388


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#1004386: [Pkg-javascript-devel] Bug#1004386: npm package installation error

[Yadd]

On 26/01/2022 15:50, Sakib Rahman wrote:


Package: npm

My OS release information is given below -

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/ "
SUPPORT_URL="https://www.debian.org/support 
"

BUG_REPORT_URL="https://bugs.debian.org/ "

I am getting following error while trying to install npm package

E: Failed to fetch 
http://deb.debian.org/debian/pool/main/g/gdk-pixbuf/libgdk-pixbuf2.0-common_2.42.2%2bdfsg-1_all.deb 
 
  Error reading from server - read (104: Connection reset by peer) [IP: 
151.101.158.132 80]


This is not a Debian package error, just a network error.

Bug#1004388: RFP: python3-inotify -- An adapter to Linux kernel support for inotify directory-watching

[Enrico Zini]

Package: wnpp
Severity: wishlist

* Package name: python3-inotify
  Version : 0.2.10
  Upstream Author : Dustin Oprea 
* URL : https://github.com/dsoprea/PyInotify
* License : GPL-2
  Programming Lang: Python
  Description : An adapter to Linux kernel support for inotify 
directory-watching

inotify functionality is available from the Linux kernel and allows you
to register one or more directories for watching, and to simply block
and wait for notification events. This is obviously far more efficient
than polling one or more directories to determine if anything has
changed. This is available in the Linux kernel as of version 2.6 .
. 
We've designed this library to act as a generator. All you have to do is
loop, and you'll see one event at a time and block in-between. After
each cycle (all notified events were processed, or no events were
received), you'll get a None. You may use this as an opportunity to
perform other tasks, if your application is being primarily driven by
inotify events. By default, we'll only block for one-second on queries
to the kernel. This may be set to something else by passing a
seconds-value into the constructor as block_duration_s.

There exist two upstream inotify libraries significant here:

https://github.com/dsoprea/PyInotify
Subject of this RFP: note that it contains a module called
'inotify', not 'pyinotify'
https://github.com/seb-m/pyinotify
Currently ppackaged as python3-pyinotify

Looking at https://github.com/dsoprea/PyInotify it says:

This project is unrelated to the *PyInotify* project that existed
prior to this one (this project began in 2015). That project is
defunct and no longer available.

and indeed, https://github.com/seb-m/pyinotify which is listed as
upstream of python3-pyinotify, seems to be stuck in 2015.

To the best that I could see, https://github.com/dsoprea/PyInotify is
not currently packaged in Debian.

If I understand correctly, the only way to access inotify functionality
in Python with libraries in Debian at the moment is via the old
pyinotify, and at least gunicorn is requiring the newer one for
inotify-based reloading to work:

   https://docs.gunicorn.org/en/stable/settings.html#reload
   "In order to use the inotify reloader, you must have the inotify
   package installed."

I reported an issue to python3-pyinotify to track the upstream
abandonment, and I'm filing this RFP for a replacement that would also
fulfill gunicorn requirements to activate inotify-based features


Enrico

Bug#1004387: Upstream seems abandoned

[Enrico Zini]

Package: python3-pyinotify
Version: 0.9.6-1.3
Severity: serious

Hello,

thank you for maintaining python3-pyinotify.

Looking at https://github.com/dsoprea/PyInotify it says:

   This project is unrelated to the *PyInotify* project that existed
   prior to this one (this project began in 2015). That project is
   defunct and no longer available.

and indeed, https://github.com/seb-m/pyinotify which is listed as
upstream of python3-pyinotify seems to be stuck in 2015.

To the best that I could see, https://github.com/dsoprea/PyInotify is
not packaged in Debian.

If I understand correctly, the only way to access inotify functionality
in Python with libraries in Debian at the moment is via the old
pyinotify, and at least gunicorn is requiring the newer one for
inotify-based reloading to work:

   https://docs.gunicorn.org/en/stable/settings.html#reload
   "In order to use the inotify reloader, you must have the inotify
   package installed."

I guess my next step could be filing an RFP for
https://github.com/dsoprea/PyInotify ?


Enrico

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

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

Versions of packages python3-pyinotify depends on:
ii  python3  3.9.2-3

python3-pyinotify recommends no packages.

Versions of packages python3-pyinotify suggests:
pn  python-pyinotify-doc  

-- no debconf information

Bug#1004386: npm package installation error

[Sakib Rahman]

Package: npm

My OS release information is given below -

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

I am getting following error while trying to install npm package

E: Failed to fetch
http://deb.debian.org/debian/pool/main/g/gdk-pixbuf/libgdk-pixbuf2.0-common_2.42.2%2bdfsg-1_all.deb
 Error reading from server - read (104: Connection reset by peer) [IP:
151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/libd/libdeflate/libdeflate0_1.7-1_amd64.deb
 403  Forbidden [IP: 151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/j/jbigkit/libjbig0_2.1-3.1%2bb2_amd64.deb
 Error reading from server - read (104: Connection reset by peer) [IP:
151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/libw/libwebp/libwebp6_0.6.1-2.1_amd64.deb
 403  Forbidden [IP: 151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/g/gdk-pixbuf/libgdk-pixbuf-2.0-0_2.42.2%2bdfsg-1_amd64.deb
 403  Forbidden [IP: 151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.38.0-1_all.deb
 403  Forbidden [IP: 151.101.158.132 80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/b/binutils/libbinutils_2.35.2-2_amd64.deb
 403  Forbidden [IP: 151.101.158.132 80]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?


$ sudo apt-get install npm -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  adwaita-icon-theme binutils binutils-common binutils-x86-64-linux-gnu
build-essential cpp cpp-10 dbus-user-session dconf-gsettings-backend
  dconf-service dirmngr dpkg-dev fakeroot fontconfig g++ g++-10 gcc gcc-10
glib-networking glib-networking-common glib-networking-services gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server
gpgconf gpgsm gsettings-desktop-schemas gtk-update-icon-cache gyp
  hicolor-icon-theme libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libasan6 libassuan0 libatomic1 libauthen-sasl-perl
  libbinutils libc-dev-bin libc-devtools libc6-dev libcairo-gobject2
libcairo2 libcc1-0 libclone-perl libcolord2 libcrypt-dev libctf-nobfd0
  libctf0 libdata-dump-perl libdatrie1 libdconf1 libdeflate0 libdpkg-perl
libencode-locale-perl libepoxy0 libfakeroot libfile-basedir-perl
  libfile-desktopentry-perl libfile-fcntllock-perl libfile-listing-perl
libfile-mimeinfo-perl libfont-afm-perl libfribidi0 libgcc-10-dev libgd3
  libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgomp1
libgtk-3-0 libgtk-3-bin libgtk-3-common libhtml-form-perl
  libhtml-format-perl libhtml-parser-perl libhtml-tagset-perl
libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl
  libhttp-message-perl libhttp-negotiate-perl libio-html-perl
libio-socket-ssl-perl libio-stringy-perl libipc-system-simple-perl libisl23
libitm1
  libjbig0 libjs-inherits libjs-is-typedarray libjs-psl
libjs-typedarray-to-buffer libjson-glib-1.0-0 libjson-glib-1.0-common
libksba8 liblsan0
  liblua5.3-0 liblwp-mediatypes-perl liblwp-protocol-https-perl
libmailtools-perl libmpc3 libmpfr6 libnet-dbus-perl libnet-http-perl
  libnet-smtp-ssl-perl libnet-ssleay-perl libnode-dev libnpth0 libnsl-dev
libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpixman-1-0
  libproxy1v5 libquadmath0 librest-0.7-0 librsvg2-2 librsvg2-common
libsoup-gnome2.4-1 libsoup2.4-1 libssl-dev libstdc++-10-dev libthai-data
  libthai0 libtie-ixhash-perl libtiff5 libtimedate-perl libtirpc-dev
libtry-tiny-perl libtsan0 libubsan1 liburi-perl libuv1-dev libvte-2.91-0
  libvte-2.91-common libwayland-cursor0 libwayland-egl1 libwebp6
libwww-perl libwww-robotrules-perl libx11-protocol-perl libxcb-render0
  libxcursor1 libxkbcommon0 libxml-parser-perl libxml-twig-perl
libxml-xpathengine-perl linux-libc-dev make manpages-dev node-abbrev
  node-agent-base node-ajv node-ansi node-ansi-regex node-ansi-styles
node-ansistyles node-aproba node-archy node-are-we-there-yet node-asap
  node-asn1 node-assert-plus node-asynckit node-aws-sign2 node-aws4
node-balanced-match node-bcrypt-pbkdf node-brace-expansion node-builtins
  node-cacache node-caseless node-chalk node-chownr node-clone
node-color-convert node-color-name node-colors node-columnify
node-combined-stream
  node-concat-map node-console-control-strings node-copy-concurrently
node-core-util-is node-dashdash node-debug node-defaults
  node-delayed-stream node-delegates node-depd node-ecc-jsbn node-encoding
node-err-code node-escape-string-regexp node-extend node-extsprintf
  node-fast-deep-equal node-forever-agent node-form-data
node-fs-write-stream-atomic node-fs.realpath node-function-bind 

Bug#1004385: wireplumber: VLC freezes 20+ seconds before starting

[Benno Overeinder]

Package: wireplumber
Version: 0.4.7-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: be...@overeinder.net

Dear Maintainer,

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

   * What led up to the situation?

After a recent upgrade of wireplumber, vlc freezes for about 20-30
seconds after launch before playing anything.  After some searching I
found this issue has been reported on other forums that after upgrading
from 0.4.5 to 0.4.7 the vlc application will freeze for 20-30 seconds
before playing anything.

Here are the URLs to the reported issue:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/63
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/178

Here a member of the forum reported the following: 

  I git bisected this problem down to wireplumber commit 6adccbe3
  ("policy-node: always use the default linkable if default nodes module
  is loaded").  Reverting that commit requires first reverting bee9827a
  and 23fc4d21.  With all 3 reverted, I no longer have any delays when
  running VLC.

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

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


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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.61
ii  libc6 2.33-3
ii  libglib2.0-0  2.70.2-1
ii  libpipewire-0.3-0 0.3.43-2
ii  libwireplumber-0.4-0  0.4.7-1
ii  pipewire  0.3.43-2

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.43-2

wireplumber suggests no packages.

-- no debconf information

Bug#1004256: messages to dispatch+aide_cont...@tracker.debian.org get multiplied

[Raphael Hertzog]

Hi,

On Sun, 23 Jan 2022, Marc Haber wrote:
> I regularly use pack...@packages.debian.org as Maintainer address for my
> packages. Having an implicit mailing list for package maintenance issues
> is extremele helpful and I appreciate that features.
> 
> Since a few weeks, messages to those addresses get multiplied inside the
> tracker, namely ticharich.debian.org, between five and ten times. I see
> this, and other members of the teams I am on see it as well.

This was due to a subscriber of the aide package being known under two
different emails varying only on the case. I don't know how this happened
because all the code should identify emails case-insensitively and not
create a second instance of the same email.

The email sending code assumes that we have a single UserEmail object
associated and it raises an exception when it tries to send the mail to
that address. Thus the email to forward was stuck in the "temporary failure"
case and was retried a few times until giving up, hence the multiple
copies for the the other subscribers.

Let me know if the problem persists. I will leave the ticket open to
remind me to improve the code to cope with the multiple unexpected
UserEmail objects for a single email...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1002115: bug in texlive?

[Cédric Boutillier]

I suspect this is caused by a change in texlive.
Here is the diff for the list of packages used in tests in ci.debian.net
between the last green and the (almost) first red:

--- kramdown-ok 2022-01-26 14:35:12.162946913 +0100
+++ kramdown-nok2022-01-26 14:35:21.802998157 +0100
@@ -1,7 +1,7 @@
 fontconfig-config  2.13.1-4.2
 fonts-dejavu-core  2.37-2
 fonts-lmodern  2.004.5-6.1
-gem2deb-test-runner1.7
+gem2deb-test-runner1.8
 kramdown   2.3.1-3
 libapache-pom-java 18-1
 libbrotli1 1.0.9-2+b3
@@ -11,7 +11,7 @@
 libfontbox-java1:1.8.16-2
 libfontconfig1 2.13.1-4.2
 libfreetype6   2.11.0+dfsg-1
-libglib2.0-0   2.70.1-1
+libglib2.0-0   2.70.2-1
 libgraphite2-3 1.3.14-1
 libharfbuzz0b  2.7.4-1
 libice62:1.0.10-1
@@ -70,13 +70,13 @@
 rubygems-integration   1.18
 t1utils1.41-4
 tex-common 6.17
-texlive-base   2021.20210921-1
+texlive-base   2021.20211127-1
 texlive-binaries   2021.20210626.59705-1
-texlive-fonts-recommended  2021.20210921-1
-texlive-latex-base 2021.20210921-1
-texlive-latex-extra2021.20210921-1
-texlive-latex-recommended  2021.20210921-1
-texlive-pictures   2021.20210921-1
+texlive-fonts-recommended  2021.20211127-1
+texlive-latex-base 2021.20211127-1
+texlive-latex-extra2021.20211127-1
+texlive-latex-recommended  2021.20211127-1
+texlive-pictures   2021.20211127-1
 tidy   2:5.6.0-11
 x11-common 1:7.7+23
 xdg-utils  1.1.3-4.1

 The test failure comes from the filtering of the latex output. Removing
 the 'scan and join' part works around the issue.

diff --git a/test/test_files.rb b/test/test_files.rb
index 7e2ccad..bc5523a 100644
--- a/test/test_files.rb
+++ b/test/test_files.rb
@@ -150,7 +150,7 @@ class TestFiles < Minitest::Test
 io.close_write
 io.read
   end
-  assert($?.exitstatus == 0, result.scan(/^!(.*\n.*)/).join("\n"))
+  assert($?.exitstatus == 0, result)
 end
   end
 end


signature.asc
Description: PGP signature

Bug#1004384: bullseye-pu: package node-cached-path-relative/1.0.2-1+deb11u1

[Yadd]

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

[ Reason ]
node-cached-path-relative is vulnerable to prototype pollution
(CVE-2021-23518)

[ Impact ]
Medium vulnerabilty

[ Tests ]
Test passed, no new check

[ Risks ]
Low risk, patch is trivial

[ 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

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 9f42f71..fb79e59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-cached-path-relative (1.0.2-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Fix prototype pollution (Closes: CVE-2021-23518)
+
+ -- Yadd   Wed, 26 Jan 2022 14:36:03 +0100
+
 node-cached-path-relative (1.0.2-1) unstable; urgency=medium
 
   * New upstream version: fix prototype pollution vulnerability
diff --git a/debian/patches/CVE-2021-23518.patch 
b/debian/patches/CVE-2021-23518.patch
new file mode 100644
index 000..99705bb
--- /dev/null
+++ b/debian/patches/CVE-2021-23518.patch
@@ -0,0 +1,28 @@
+Description: fix prototype pollution
+Origin: upstream, 
https://github.com/ashaffer/cached-path-relative/commit/40c73bf70
+Author: Andrew 
+Bug: https://security.snyk.io/vuln/SNYK-JS-CACHEDPATHRELATIVE-72573
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-01-26
+
+--- a/lib/index.js
 b/lib/index.js
+@@ -27,7 +27,7 @@
+   // to invalidate the cache
+   var cwd = process.cwd()
+   if (cwd !== lastCwd) {
+-cache = {}
++cache = Object.create(null)
+ lastCwd = cwd
+   }
+ 
+@@ -35,7 +35,7 @@
+ 
+   var result = relative.call(path, from, to)
+ 
+-  cache[from] = cache[from] || {}
++  cache[from] = cache[from] || Object.create(null)
+   cache[from][to] = result
+ 
+   return result
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..625c955
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-23518.patch

Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})

[Georg Faerber]

Hi Utkarsh,
 
Thanks for your upload.
 
Could you please push the changes you did to the git repo?
 
Thanks,
cheers,
Georg

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Alberto Garcia]

On Wed, Jan 26, 2022 at 07:30:23PM +1100, Trent W. Buck wrote:
> But maybe it only meant webkit (MacOS-only, not ever in Debian) or
> "webkitgtk" (not in Debian for about 8 years)?
> But then why even mention it in the *bullseye* release notes?

WebKit is an open source browser engine that works in different
platforms. A version of WebKit for a specific platform is called
"port", and there are several, some official, some unofficial, some
actively maintained and some deprecated or dead.

All ports "are" WebKit (they share the majority of the code base) and
you can specifiy which one you are referring to by calling it "the
GTK port", "the Mac port", etc. Some of them have their own names for
convenience ("WebKitGTK", "WebKitNIX", "QtWebKit", ...), but they're
still WebKit.

Two WebKit ports are actively maintained, available in Debian and have
security support: WPE WebKit and WebKitGTK (the package is called
webkit2gtk for technical / historical reasons).

Other WebKit ports available in Debian are not covered by security
support. I know there's at least QtWebKit, I don't know if there are
more.

Berto

Bug#1004383: Please backport v590 to bullseye

[Michael Biebl]

Source: less
Version: 590-1
Severity: wishlist

Hi Milan,

thanks for the update of less to v590 in unstable.

I'd like to revert [1] and build systemd with -Durlify=true now that we
have a new enough less in unstable/testing.

Since we typically ship backports of systemd for the current stable
release (and I plan to do that for bullseye as well), it would be great
to have a backport of less so we don't have to revert that change
(again).




Regards,
Michael



[1] 
https://salsa.debian.org/systemd-team/systemd/-/commit/e34e3b5b8a23b2dfc7fff057286184139465ecb2



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

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

Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)

[Thomas Goirand]

On 1/26/22 13:46, stefa...@debian.org wrote:

Hi Thomas (2022.01.26_10:34:13_+)

When building 3.0.7, I get:

I: pybuild base:237: pypy setup.py clean
Traceback (most recent call last):
   File "setup.py", line 8, in 
 from pyparsing import __version__ as pyparsing_version
   File "/<>/pyparsing/__init__.py", line 100
 major: int
  ^
SyntaxError: invalid syntax
E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1:
pypy setup.py clean

This feels like we need to drop pypy support for this package. Stefano, your
thoughts? How should this be handled?


It can be dropped, we don't need to keep much Python 2.7 stack alive any
more. I'm keeping the bare minimum for virtualenvs to function, and that
doesn't require this.

There is one reverse-dep, python-packaging, that should have it's 2.7
bits dropped, too.

SR


I saw it. The package has Matthias Klose as Maintainer, no VCS, and no 
team. Matthias, can I NMU "your" package to remove the pypy flavor 
before I fix pyparsing?


Cheers,

Thomas Goirand (zigo)

Bug#1003799: dpkg: [PATCH] po: Update Swedish programs translation

[Peter Krefting]

Hi!

FYI, I have now set up a mirror repo on Github that I will use to 
track my translation changes to. I will send updates to the Debian bug 
tracker as requested, but will also includes references to Github to 
allow pull/cherry-pick from there.


https://github.com/nafmo/dpkg-l10n-sv

--
\\// Peter - http://www.softwolves.pp.se/

Bug#1003260: leaflet-image: FTBFS with webpack5: Invalid configuration object

[Jonas Smedegaard]

Hi Caleb,

Quoting Caleb Adepitan (2022-01-26 12:27:10)
> Concerning the bug report where leaflet-image build with webpack 5 
> breaks due to an invalid configuration object, the major problem 
> wasn't from the configuration object, but the `-d` option passed in 
> build script in `debian/rules` which specifies a devtool option that 
> has become "more strict" in webpack 5. This option passed in the build 
> script overrides that in the config file.
> 
> The `node` option targeted to mock Node.js fs module with an empty 
> object is also no longer relevant. See 
> https://webpack.js.org/configuration/resolve/#resolvefallback
> 
> Here's a patch that shows my changes: 
> https://salsa.debian.org/calebpitan/leaflet-image/-/commit/ff6837954c29706d5154c9d9abb54f92ad0171b2.patch

Thanks, I did indeed not notice the relevancy of the -d option.

Unfortunately I cannot tell if your proposed patch is working or not, 
however - seems webpac5 is broken in experimental currently (undeclared 
dependency on node-import-local - which by the way horribly pulls in a 
pile of unneeded packages including babel - and even then webpack throws 
error - and horribly does not fail but continues with - I assume - 
broken code). :-(

Let's continue this when webpack5 in experimental works.


 - 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#1004379: dh-python: provide pytest wrapper to test all python versions

[stefanor]

Hi Drew (2022.01.26_09:56:25_+)

FYI, this is work in progress on providing something to help here:
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1004379: dh-python: provide pytest wrapper to test all python versions

[Drew Parsons]

On 2022-01-26 13:48, stefa...@debian.org wrote:

Hi Drew (2022.01.26_09:56:25_+)

FYI, this is work in progress on providing something to help here:
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27



Ah good, thanks Stefan.  This will go with Bug#837878 then.

I saw that bug but I wasn't sure it was the same issue since it requires 
the extra component, python3-pytest-runner.  Perhaps once it's working 
it will do the simple job that I'm requesting.


Drew

Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)

[stefanor]

Hi Thomas (2022.01.26_10:34:13_+)
> When building 3.0.7, I get:
> 
> I: pybuild base:237: pypy setup.py clean
> Traceback (most recent call last):
>   File "setup.py", line 8, in 
> from pyparsing import __version__ as pyparsing_version
>   File "/<>/pyparsing/__init__.py", line 100
> major: int
>  ^
> SyntaxError: invalid syntax
> E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1:
> pypy setup.py clean
> 
> This feels like we need to drop pypy support for this package. Stefano, your
> thoughts? How should this be handled?

It can be dropped, we don't need to keep much Python 2.7 stack alive any
more. I'm keeping the bare minimum for virtualenvs to function, and that
doesn't require this.

There is one reverse-dep, python-packaging, that should have it's 2.7
bits dropped, too.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1004272: binutils: missing RELRO header

[Matthias Klose]

Version: 2.37.90.20220123-2

Fixed.

Bug#1003952: chromium: Can't attach tab to window or move tab window horizontaly

[Florian Goth]

Package: chromium
Followup-For: Bug #1003952

Dear Maintainer,

Thanks for fixing, the bug is fixed and the user complaints have subseded




-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (500, 'stable-updates'), (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common 97.0.4692.99-1~deb11u2
ii  libasound2  1.2.4-1.1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  10.2.1-6
ii  libatspi2.0-0   2.38.0-4
ii  libc6   2.31-13+deb11u2
ii  libcairo2   1.16.0-5
ii  libcups22.3.3op2-3+deb11u1
ii  libdbus-1-3 1.12.20-2
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.2.10-2
ii  libflac81.3.3-2
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgbm1 20.3.5-1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libharfbuzz0b   2.7.4-1
ii  libicu6767.1-7
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp241.9.4-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.29-1
ii  libnss3 2:3.61-1+deb11u2
ii  libopenjp2-72.4.0-3
ii  libopus01.3.1-0.1
ii  libpango-1.0-0  1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libpulse0   14.2-2
ii  libre2-920210201+dfsg-1
ii  libsnappy1v51.1.8-1
ii  libstdc++6  10.2.1-6
ii  libwebp60.6.1-2.1
ii  libwebpdemux2   0.6.1-2.1
ii  libwebpmux3 0.6.1-2.1
ii  libx11-62:1.7.2-1
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1.1
ii  libxfixes3  1:5.0.3-2
ii  libxkbcommon0   1.0.3-2
ii  libxml2 2.9.10+dfsg-6.7
ii  libxrandr2  2:1.5.1-1
ii  libxslt1.1  1.1.34-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-13+deb11u2
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
pn  chromium-sandbox   
pn  fonts-liberation   
ii  libgl1-mesa-dri20.3.5-1
pn  libu2f-udev
pn  notification-daemon
pn  system-config-printer  
pn  upower 

-- no debconf information

Bug#1004381: (no subject)

[Clemens Haupt]

Am 26.01.22 um 12:15 schrieb y...@vienna.at:

Desktop

Also:
1) Nur die von X stammenden Teilfenster lassen sich feineinstellen und 
haargenau positionieren
2) Ganz übles Beispiel: Aterm unmd Rxrterm.
3) Teilfenster müssen nach jedem Start absolut neu positioniert werden, besser 
bei KDE
4) Teilfenster haben nicht mehr dieselbe Größe und rasten nie ein.
5) Die Startfester Eikohn können nicht an einer selbstbestimmsten Stelle 
positioniert wetden.
6) Sie verschwinden zwischen den Aufrufen.
7) Auf den offenen Fenstern sind alle, beim letzten Mal aufgerufenen Programme 
weg.
8) Es gibt kein händisches Einjustieren.
9) Beim nächsten Einschalten ist wieder alles neu einzurichten, ein zügiges 
Arbeiten  ist unmöglich.
A) Der sichtbare Teil ist ein einziger Sauhaufen.
B) Es gibt noch immer kein Fenster, aber schon wirklich mit allen Befehlen der 
,,bash",
C) pechschwarzem Untergrund, farbigen Symbolen in alle Größen und allen 
Programmen mit
D) curses Priogrammen in der gewohnen und beabsichtigten Darstellung wie auch 
der Consoke
E) wie z.B. gitfm, bmon, nmon, calcurses.

Für Arbeiter ist Xfce ungeeignet.
Aber vielleicht zum Spielen.
Es schadet dem Bild von Linux als verwendares Zeug.
Villeicht kann man sich an Windows96 oder XP halten, der Ramsch setze sich 
deswegen bei
Sekretärinnen und Kindern durch
Xfce?
Keine Chance.






















Subject: xfce: Placing windows of programs
Package: xfdesktop4
Version: 4.12.4-2
Severity: normal
File: xfce

Dear Maintainer,

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

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

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


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfdesktop4 depends on:
ii  exo-utils0.12.4-1
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libdbus-1-3  1.12.20-0+deb10u1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u3
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1+deb10u2
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.4-2

Versions of packages xfdesktop4 recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  librsvg2-common   2.44.10-2.1
ii  tumbler   0.2.3-1
ii  xdg-user-dirs 0.17-2

Versions of packages xfdesktop4 suggests:
pn  menu  

-- no debconf information

pn

Bug#1004382: /usr/bin/reportbug: Bogus "please wait to receive the bug tracking number" when not sending in paranoid mode

[Adam Dinwoodie]

Package: reportbug
Version: 11.3.0
Severity: minor
File: /usr/bin/reportbug

Dear Maintainer,

When using reportbug in paranoid mode (or at least with "ui urwid" and
"paranoid" specified in ~/.reportbugrc), reportbug correctly displays
the email to the user before sending it, and asks the user if the report
is satisfactory.  If the user objects to the message, as well as
accurately reporting that the message has been saved to a temporary
file, reportbug also tells the user:

> If you want to provide additional information, please wait to receive
> the bug tracking number via email; you may then send any extra
> information to ...

This implies -- incorrectly -- that the bug report has been sent and
that the user should expect to receive a bug tracking number.  In this
circumstance, reportbug should not show this message.

Kind regards,

Adam


-- Package-specific info:
** Environment settings:
EDITOR="vim"
VISUAL="vim"
INTERFACE="urwid"

** /home/adam/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui urwid
email "debian-report...@post.dinwoodie.org"
paranoid

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  11.3.0
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.77
ii  debsums3.0.2
ii  dlocate1.07+nmu1
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  file   1:5.39-3
pn  gnupg | pgp
ii  python3-urwid  2.1.2-1
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.43
ii  python3-debianbts  3.2.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1003260: leaflet-image: FTBFS with webpack5: Invalid configuration object

[Caleb Adepitan]

Hi Jonas,

Concerning the bug report where leaflet-image build with webpack 5 
breaks due to an invalid configuration object, the major problem wasn't 
from the configuration object, but the `-d` option passed in build 
script in `debian/rules` which specifies a devtool option that has 
become "more strict" in webpack 5. This option passed in the build 
script overrides that in the config file.


The `node` option targeted to mock Node.js fs module with an empty 
object is also no longer relevant. See 
https://webpack.js.org/configuration/resolve/#resolvefallback


Here's a patch that shows my changes: 
https://salsa.debian.org/calebpitan/leaflet-image/-/commit/ff6837954c29706d5154c9d9abb54f92ad0171b2.patch


OpenPGP_0x8A1B2CC96775D2D7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004381: (no subject)

[y...@vienna.at]

Subject: xfce: Placing windows of programs
Package: xfdesktop4
Version: 4.12.4-2
Severity: normal
File: xfce

Dear Maintainer,

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

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

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


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfdesktop4 depends on:
ii  exo-utils0.12.4-1
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libdbus-1-3  1.12.20-0+deb10u1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u3
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1+deb10u2
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.4-2

Versions of packages xfdesktop4 recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  librsvg2-common   2.44.10-2.1
ii  tumbler   0.2.3-1
ii  xdg-user-dirs 0.17-2

Versions of packages xfdesktop4 suggests:
pn  menu  

-- no debconf information

pn

Bug#981285: Please move fdk-aac to main

[Laurent Bigonville]

Le 26/01/22 à 11:42, Bastian Blank a écrit :

On Wed, Jan 26, 2022 at 10:51:34AM +0100, Laurent Bigonville wrote:

I would be really interested to see AAC support in pulseaudio/pipewire for
bluetooth devices

[1]https://www.gnu.org/licenses/license-list.html#fdk

This clearly states that the FDK license is incompatible with the GPL.

For pipewire that should be okay, because it is Expat, if nothing makes
the whole thing LGPL.  For gstreamer and pulseaudio it's pretty much not
okay, because they are some form of GPL.


Right, pulseaudio daemon is itself LGPL, but it is depending against GPL 
libraries making the resulting binary GPL


gstreamer itself seems to be LGPL though? Being plugins based makes it a 
bit difficult to see what's actually loaded at runtime