Bug#1006009: fixed in libwebp 1.2.2-1

[Jeff Breidenbach]

Yes, I made a mistake with respect to 1.2.2. Upstream's official patch is
here. I am going to attempt a high urgency upload during the next houw with
1.2.2 + this patch. If that fails for any reason, NMU welcome without
delay.

https://chromium.googlesource.com/webm/libwebp/+/4f1839957115fa4713ed745ceb898657361a1195

>

Bug#1007228: grads no symbol error

[Nobuhiko ENDO]

Package: grads
Version: 3:2.2.1-2build3


When I invoke 'grads' in terminal, I got following error.

-
Grid Analysis and Display System (GrADS) Version 2.2.1
Copyright (C) 1988-2018 by George Mason University
GrADS comes with ABSOLUTELY NO WARRANTY
See file COPYRIGHT for more information

Config: v2.2.1 little-endian readline grib2 netcdf hdf4-sds hdf5 opendap-grids,
stn geotiff shapefile
Issue 'q config' and 'q gxconfig' commands for more detailed configuration 
information
Landscape mode? ('n' for portrait):
GX Package Initialization: Size = 11 8.5
grads: symbol lookup error: /usr/lib/aarch64-linux-gnu/libgxdCairo.so: 
undefined 
symbol: gxdbkq
-

I used 'nm' to find "gxdbkq".
$ nm -D /usr/bin/grads

In my X86-64 Ubuntu PC, "gxdbkq" is found in '/usr/bin/grads' and 
'/usr/lib/x86_64-linux-gnu/libgradspy.so'.

Unfortunately, I cannot find "gxdbkq" in 'grads' in my arm64 environment.
"gxdbkq" is only found in '/usr/lib/aarch64-linux-gnu/libgradspy.so'.
Furthermore, I cannot find any symbol names which comes from GrADS source 
code (such like, gabarb, gabufr_open, gxdbkq, etc) in '/usr/bin/grads' 
installed in arm64 environment.


I use Canonical's multipass environment on MacOS Monterey.
OS is Ubuntu 20.04 LTS with kernel 5.4.0-104-generic and libc6 2.31-0ubuntu9.7.
grads_2.2.1-2build3_arm64.deb were installed.


---
Nobuhiko ENDO
ick45...@nifty.com

Bug#1007227: ITP: apertium-regtest -- Regression test suite for Apertium languages and pairs

[Kartik Mistry]

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

  Package name: apertium-regtest
  Version : 0.9.0
  Upstream Author : Daniel Swanson 
  URL : https://apertium.org/
  License : GPL-3+
  Programming Lang: Python
  Description : Regression test suite for Apertium languages and pairs

Suite to run regression tests for Apertium languages and pairs.

 Q Why is this package useful/relevant?

 A Useful for testing 100s of language pairs of Apertium Machine Translation
   service.

 Q How do you plan to maintain it?

 A Package will be maintained under debian-science project at Salsa.

Bug#1006784: automake: fixes for python3.10 distutils changes

[Stefano Rivera]

Hi 1006784 (2022.03.12_16:32:30_-0400)
> Hi Gianfranco (2022.03.04_18:19:35_-0400)
> > With this patch, automake will install to /usr for locally built code
> > and debian-packaged code. This probably isn't desired. Maybe check
> > prefix and select the appropriate scheme from that?
> 
> I take this back. Of course it is combining posix_prefix with the
> specified prefix, which will do the right thing.

Confirmed that this patch does the right thing.
As things stand: with automake 1:1.16.5-1.1:
python3.9:
--prefix=/usr installs to   /usr/lib/python3.9/site-packages
--prefix=/usr/local installs to /usr/local/lib/python3.9/site-packages

python3.10:
--prefix=/usr installs to   /usr/local/lib/python3.10/dist-packages
--prefix=/usr/local installs to /usr/local/local/lib/python3.10/dist-packages

That's an excess /local/ in the path. dh_python3 can fix it up, but
it'll break existing dh_install configs. And the /local/local thing
definitely won't work.

with this patch:
python3.9:
--prefix=/usr installs to   /usr/lib/python3.9/site-packages
--prefix=/usr/local installs to /usr/local/lib/python3.9/site-packages

python3.10:
--prefix=/usr installs to   /usr/lib/python3.10/site-packages
--prefix=/usr/local installs to /usr/local/lib/python3.10/site-packages

The site-packages, directory isn't on sys.path, but dh_python3 will fix
that up, and it matches previous behaviour, so no changes needed in
other packages.

SR

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

Bug#994245: nodejs: improve bootstraping nodejs

[vimer]

On Mon, Mar 14, 2022 at 02:25:14AM +0100, Jérémy Lal wrote:

Package: nodejs
Followup-For: Bug #994245
X-Debbugs-Cc: Bo YU 

Hi,

recently Bo YU has worked on building nodejs 14 for riscv64.

Bo, you can tell us here what you achieved, and what's blocking you right now ?

hi,

I try to build the pkg-js-tools package firstly as you suggested to solve
dependency of nodejs. But I was blocked by fowllow error:

1. DEB_BUILD_PROFILES="nocheck"
2. sudo sbuild --arch=riscv64 -d sid-riscv64-sbuild 
--extra-package=/home/vimer/nodejs_riscv64_debs/
the ` --extra-package`  argument is path the point to  riscv64 nodejs-* deb 
packages last time build. It seem like to start build, but at last get:
···
dh_auto_configure: error: unable to load build system class 'nodejs': Can't locate JSON.pm in @INC (you may need to 
install the JSON module) (@INC contains: /<>/blib/lib 
/<>/blib/arch /etc/perl /usr/local/lib/riscv64-linux-gnu/perl/5.34.0 
/usr/local/share/perl/5.34.0 /usr/lib/riscv64-linux-gnu/perl5/5.34 /usr/share/perl5 
/usr/lib/riscv64-linux-gnu/perl-base /usr/lib/riscv64-linux-gnu/perl/5.34 /usr/share/perl/5.34 
/usr/local/lib/site_perl .) at /<>/blib/lib/Debian/Debhelper/Buildsystem/nodejs.pm line 12.
BEGIN failed--compilation aborted at 
/<>/blib/lib/Debian/Debhelper/Buildsystem/nodejs.pm line 12.
Compilation failed in require at (eval 2) line 1.
BEGIN failed--compilation aborted at (eval 2) line 1.

dh_additional.t: error: dh_auto_configure --buildsystem=nodejs subprocess 
returned exit status 25
# Looks like your test exited with 25 before it could output anything.
t/dh_additional.t ..
1..19
Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 19/19 subtests
...

I'm wondering if I should try this solution:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=939521;filename=openjdk-11_11.0.5%2B6-1.1.debdiff;msg=5
BTW, I have replyed the another mail thread to send help solve above issue :-)

thanks,

Bo



Thanks,

Jérémy


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  14.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   14.19.0~dfsg-1

Versions of packages nodejs suggests:
ii  npm  8.5.4~ds1-1

-- no debconf information

Bug#1007226: GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion failed: (tz != NULL)

[Robbie Harwood (frozencemetery)]

Package: libglib2.0-0
Version: 2.71.3-1
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

When running `notmuch new`, I get this error:

**
GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion 
failed: (tz != NULL)
Bail out! GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: 
assertion failed: (tz != NULL)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
Download failed: Invalid argument.  Continuing without source file 
./signal/../sysdeps/unix/sysv/linux/raise.c.
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77b70546 in __GI_abort () at abort.c:79
#2  0x77d72dcc in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77dd26cb in g_assertion_message_expr () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77dd8da6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x77f32a1c in g_mime_utils_header_decode_date () at 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0
#6  0x77f1887e in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#7  0x77f189d2 in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#8  0x77f0ca2e in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#9  0x77f16f31 in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#10 0x77f25164 in g_mime_parser_construct_message () at 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0
#11 0x77f7dd78 in _notmuch_message_file_parse (message=0x5561aef0) 
at lib/message-file.c:161
#12 0x77f7e3ad in _notmuch_message_file_parse (message=0x5561aef0) 
at lib/message-file.c:373
#13 _notmuch_message_file_get_headers (message_file=0x5561aef0, 
from_out=0x7fffdb88, subject_out=0x7fffdb98, to_out=0x7fffdb90, 
date_out=0x7fffdb80, message_id_out=0x7fffdba0) at 
lib/message-file.c:338
#14 0x77f8bc24 in notmuch_database_index_file(notmuch_database_t*, char 
const*, notmuch_indexopts_t*, notmuch_message_t**)
(notmuch=notmuch@entry=0x555a8ba0, 
filename=filename@entry=0x55619f30 
"/home/frozencemetery/Mail/local/new/1647044095.M257021P4675Q1.akroma", 
indexopts=0x555de400, message_ret=message_ret@entry=0x7fffdcc8)
at lib/add-message.cc:497
#15 0x55564d12 in add_file (state=0x7fffe090, 
filename=0x55619f30 
"/home/frozencemetery/Mail/local/new/1647044095.M257021P4675Q1.akroma", 
notmuch=0x555a8ba0) at ./notmuch-new.c:380
#16 add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x567c3d70 "/home/frozencemetery/Mail/local/new", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:726
#17 0x55564a49 in add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x556123a0 "/home/frozencemetery/Mail/local", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:613
#18 0x55564a49 in add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x555dceb0 "/home/frozencemetery/Mail", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:613
#19 0x5556596d in notmuch_new_command (notmuch=0x555a8ba0, 
argc=, argv=) at ./notmuch-new.c:1252
#20 0xe9b7 in main (argc=2, argv=0x7fffe848) at ./notmuch.c:604
(gdb) 

(I don't know what's going on with the missing symbols - debuginfod fetched
the rest, but not those.)

This happens on both the version in unstable and experimental.  Possibly
related is that my timezone switched to daylight savings today.

Be well,
--Robbie

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

Kernel: Linux 5.16.0-3-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libglib2.0-0 depends on:
ii  libc62.33-7
ii  libffi8  3.4.2-4
ii  libmount12.37.3-1+b1
ii  libpcre3 2:8.39-13
ii  libselinux1  3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.70.4-1
ii  shared-mime-info  2.1-2
ii  xdg-user-dirs 0.17-2

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#1000493: [Pkg-javascript-devel] Bug#1000493: libnode93 breaks with libnode72 but not installed

[vimer]

On Mon, Mar 14, 2022 at 01:39:26AM +0100, Jérémy Lal wrote:

Package: nodejs
Version: 14.19.0~dfsg-1
Followup-For: Bug #1000493

I just got the same trouble, and now i really don't remember
the rationale behind:


When building nodejs on Debian arch, I remember encounter the issue.

Hope this help.

Bo,



Breaks:
libnode64,
libnode72

Besides both libnode64 and libnode72 having a file in common:
usr/share/systemtap/tapset/node.stp
which could better be shipped by nodejs package instead.

Jérémy

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  14.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   14.19.0~dfsg-1

Versions of packages nodejs suggests:
ii  npm  8.5.4~ds1-1

-- no debconf information
--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#1007222: transition: onetbb

[Matthias Klose]

On 13.03.22 21:59, M. Zhou wrote:

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

Hi release team,

This involves an upstream source name change (from tbb to onetbb),
as well as SOVERSION bump (from 2 to 12), along with a major API
change including some changes in the core API.

I should have submitted this after my local build test for the
reverse dependencies of libtbb-dev, but fellow developers from
debian-science are eager to see this in unstable to unblock
their works.

I have not tested by myself, but I heard from an archlinux
developer that this API bump breaks a lot packages. And
some upstreams decided to disable or drop tbb support as
a result. I guess we can take similar measures for short
term workaround.


"I heard from archlinux" is not good enough.  I sent you email about this 
without getting a reply, then filed #1006920, without getting a reply, now this 
incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev 
in Ubuntu to get an overview what at least breaks:


$ reverse-depends -b libtbb2-dev

Reverse-Testsuite-Triggers

* intel-mkl



Reverse-Build-Depends

* casparcg-server

* flexbar

* gazebo

* opencascade

* opensubdiv

* r-cran-rcppparallel
 (plus implicit dependencies)



Ben file:

title = "tbb";
is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
is_good = .depends ~ "libtbb12";
is_bad = .depends ~ "libtbb2";


this breaks everything immediately because of the conflicting libtbb2 and 
libtbb12. Please fix this first.


Matthias

Bug#994705: MA: same libnode-dev

[Jérémy Lal]

Package: libnode-dev
Version: 14.19.0~dfsg-1
Followup-For: Bug #994705

Hi,

I'd like to understand the reason why, if the package contains
the same files on all archs, should it install them on arch-dependent paths ?

Jérémy


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 libnode-dev depends on:
ii  libnode83   14.19.0~dfsg-1
ii  libssl-dev  1.1.1m-1
ii  libuv1-dev  1.44.1-1

libnode-dev recommends no packages.

libnode-dev suggests no packages.

-- no debconf information

Bug#994245: nodejs: improve bootstraping nodejs

[Jérémy Lal]

Package: nodejs
Followup-For: Bug #994245
X-Debbugs-Cc: Bo YU 

Hi,

recently Bo YU has worked on building nodejs 14 for riscv64.

Bo, you can tell us here what you achieved, and what's blocking you right now ?

Thanks,

Jérémy


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  14.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   14.19.0~dfsg-1

Versions of packages nodejs suggests:
ii  npm  8.5.4~ds1-1

-- no debconf information

Bug#994613: nodejs salsa ci fail

[Jérémy Lal]

Package: nodejs
Followup-For: Bug #994613


Hi,

in master-14.x branch the two tests are allowed to fail now.

I also noticed some problem with too big artifacts, so i disabled
the generation of dbgsym package for ci.

Also i'm not in favor of uncontrolled rebuilding of nodejs for each commit.
It would take a lot of resources.
I've tried to setup debian/salsa-ci.yml on master-14.x branch to skip untagged 
commits.

Jérémy

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  14.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   14.19.0~dfsg-1

Versions of packages nodejs suggests:
ii  npm  8.5.4~ds1-1

-- no debconf information

Bug#1006257: Sigwinch window resizes

[blake]

I'm not sure if it's totally the correct fix or not, but setting the 
option below seems to resolve the issue.


apt_pkg.config.set('Dpkg::Use-Pty', "0")

Thanks,
Blake

Bug#1000493: libnode93 breaks with libnode72 but not installed

[Jérémy Lal]

Package: nodejs
Version: 14.19.0~dfsg-1
Followup-For: Bug #1000493

I just got the same trouble, and now i really don't remember
the rationale behind:

Breaks:
 libnode64,
 libnode72

Besides both libnode64 and libnode72 having a file in common:
usr/share/systemtap/tapset/node.stp
which could better be shipped by nodejs package instead.

Jérémy

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  14.19.0~dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   14.19.0~dfsg-1

Versions of packages nodejs suggests:
ii  npm  8.5.4~ds1-1

-- no debconf information

Bug#1006702: [debian-mysql] Bug#1006702: mariadb-10.6: Baseline violation on at least i386 via CXXFLAGS

[Otto Kekäläinen]

Control: Severity -1 wishlist

Based on replies from Daniel and Marko this code section is indeed
correct. Also, based on git blame the section you suggest to be
removed was not added in a MariaDB version. However, instead of
closing this bug report as invalid, I leave it open as a wishlist item
in case somebody would have a suggestion / upstream Pull Request /
downstream Merge Request on how to rewrite it in a better way or at
least how to properly document it with inline comments to avoid
confusion about how it works.

Current build status and FTBFS bugs filed for mariadb-10.6 are listed
at https://buildd.debian.org/status/package.php?p=mariadb-10.6
Currently PowerPC and PowerPC 64 are failing, but ppc64el is passing.
Any contributions to further debug or even fix the remaining issues
are naturally welcome!

Bug#1000336: Upgrading tbb

[Torrance, Douglas]

On Sun 13 Mar 2022 04:50:32 PM EDT, M. Zhou  wrote:

Recently I'm not able to test the build of libtbb-dev's reverse dependencies
as my build machine was out of access. That blocks my submission of the
transition bug and hence I'm stalled at this point.
According to some archlinux developers, this transition breaks a lot of
reverse dependencies since some of the core APIs have been changed.
Please expect a relatively negative rebuild result.

Help is welcome.


I've built both mathicgb and macaulay2 in unstable against TBB 2021 from
experimental and they're both ready to go for the transition.

Doug


signature.asc
Description: PGP signature

Bug#1007205: Please consider (re)including my start-stop-daemon.runit script

[Andras Korn]

Sorry, naturally I found a typo in the script just after sending it:

Index: start-stop-daemon.runit
===
--- start-stop-daemon.runit (revision 1347)
+++ start-stop-daemon.runit (working copy)
@@ -71,7 +71,7 @@
 read -A cmdline 

Bug#1007185: btrfsmaintenance: reproducible builds: Timestamp embedded in manpage

[Nicholas D Steeves]

Vagrant Cascadian  writes:

> On 2022-03-12, Nicholas D. Steeves wrote:
>> Vagrant Cascadian  writes:
>
>> Wow!  Thank you for catching this so quickly, and for submitting a
>> patch, and sorry I missed this.
>
> Just happened to look at it shortly after you had apparently
> uploaded. heh. :)
>

Haha!

>> By the way, are ISO 8601 dates in man pages a goal in Debian?
>
> I'm not aware of any goal, it just seems like the most consistent format
> to use, works well for reproducible builds, and isn't "wrong". :)
>

ACK, applied, and uploaded.

>> I noted GNU man pages use "%B %d, %Y", and
>> chose the more international little endian long-form.  There's no
>> problem changing to ISO 8601 as you suggest, I'm just curious.
>
> Maybe it'd be worth exploring getting GNU to move towards ISO 8601
> instead... I'll plant that seed in the back of my mind and see where it
> goes!
>

Cool, feel free to CC me if you go through with it, I'm curious how the
conversation will go

>> On a tangential topic, what would you recommend for making shell scripts
>> such as btrfsmaintenance aware of plug/unplug (alternatively off battery
>> vs on battery) state, to suspend and resume CPU and IO intensive
>> operations, and without falling back to polling?  UPower, to cover both
>> laptops and servers that have a UPS?
>
> No opinions on that, good luck!
>

Thanks!  I hope there won't be many tricky blockers or pitfalls when I
finally get around to it (users seem to want to want it, but my backlog
is still huge).

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1007106: reportbug: please make the meaning of the a11y tag clearer

[Samuel Thibault]

Hello,

Simon McVittie wrote:
> For instance, the bug that prompted me to open this one is a deadlock (or
> something) in interacting with Pipewire's PulseAudio-compatible server,
> which makes the game Minetest (among others) take a long time to start
> and have no sound. That certainly makes it hard to access normal
> functionality of minetest, but it doesn't seem like a bug that needs
> particular attention from accessibility experts...

Oops, indeed!

> Can anyone suggest a wording that makes the intention of the tag clearer,
> without "othering" the people who particularly need bugs with this tag to
> be fixed? I've cc'd debian-accessibility in the hope that someone on that
> list has a better idea.

Thanks for the notice!

> 1 a11y  This bug is relevant to the accessibility of the package.

Perhaps simply adding

1 a11y  This bug is relevant to the accessibility of the package for 
disabled users.

?

Or rephrasing to make it shorter:

1 a11y  This bug affects disabled users.

?

Samuel

Bug#1006579:

[Michael Hudson-Doyle]

FWIW upstream just made a release that claims to fix this bug.

Bug#1007007: closed by James McCoy (Re: Bug#1007007: vim: defaults.vim items should not override those in vimrc.local and home/.vimrc)

[Shelling, Otheus]

Hello James,

I am disappointed in your dismissal of these two tickets. Allow me to make the 
case why you should reconsider. I will point out that firstly, it actually is 
the responsibility of Debian's package-maintainer to make this change, and 
secondly, that my proposed solution will not interfere with most of the user 
base, while certainly enhancing the experience for a small but significant 
minority. If done right, and upstream makes a reasonable modification, say in 
vim 8.2, you simply do not need to include the proposed addition and everything 
should work fine. Together these arguments should effectively undermine your 
stated response as to why no action will be taken. 

First, a distribution packager's primary responsibility is to ensure that 
upstream software is compatible with the other components compiled and 
installed for that distribution. Of close secondary consideration is to ensure 
that newer versions are configured or customized in a way that does not disrupt 
the user experience, and if possible, enhances it. After all, we hope software 
upgrades also upgrade stability, user-experience, etc.  There are also 
prerequisites of course, such as the software being open-source, and that the 
build process itself is open.  If your view of what packages is at significance 
variance with the above, then please point out to me some document or blog 
which you follow as your guiding principles.

Second point is that software vendors provide software configured for what they 
consider are typical use-cases, but by no means do they expect downstream 
packagers to keep the settings as-is. Indeed, they often expect packagers and 
site-administrators to fine-tune the settings for their audience. It is the 
**domain of configuring defaults and system configuration files is that of the 
packager and not the software provider**. This is true, whether it be Apache 
httpd, the gnu compiler, the dhcp daemon, the linux kernel. Vim provides 
software to all platforms, and it is up to each distribution to individualize 
and configure the package for their users' best interests.  Sometime, such 
settings are incorporated into the original distribution. Is Debian.vim one of 
those or are these customized by the packager? Either way, the case is clear 
that a Debian installation of vim is not the same as the general distribution 
of vim. 

Therefore, it is clear, that the Debian packagers are to set and configure 
vim's settings so that its users have a satisfying user-experience with those 
default settings. And it is this very point that you have two complainants 
saying very clearly, this is not the status quo, and are therefore begging you 
to change it. Believe me, there are many more of us, but you won't notice them 
as much for reasons I will point out below.

It is further the case that at least some settings in debian.vim are overridden 
by those in defaults.vim. This is clearly against the design and wishes of 
prior packagers! 

So before I re-present the solution, let's talk about the use cases.  Your 
dismissal of our tickets suggests you know only one or typical use-cases of the 
vim package. I suspect the most  common use-case for this Debian-vim package is 
to be installed as an upgrade an existing, Debian installation, for which the 
user is already familiar with vim and has already created their own .vimrc for 
customization. For such a user, an X-based interface is almost a given, which 
means vim might very well run not in a terminal but in an X Window. Most of 
these users are unaffected by the very annoying "mouse" setting because either 
they have their own .vimrc or they are using vim within X-Windows.  And in 
these vast majority of such cases, there will be very little need to override 
system-wide defaults in something like a /etc/vimrc or /etc/vimrc.local file. 
From that point of view, I understand your dismissal.  

However, quite a few of us need to install and support Debian workstations 
across an organization, or multi-user servers, For us and for the sake of our 
users, we need the ability to make a system-wide setting. We would naturally 
put those changes in either /etc/vim/vimrc or as suggested in that file 
/etc/vim/vimrc.local. In fact, we may already have put those settings there. 
And expect them to work. Or as is often my case, I must modify a Docker 
container which runs Debian but has been stripped of all but essential 
packages, and which I must try out a few ad hoc changes before updating the 
Dockerfile.  For that case, I must install vim, and then I must make some 
setting changes in /etc/vim/vimrc and lo and behold, those changes don't work. 
Well,  some of them might, others not, who knows? And it will take tons of 
digging around as I and many others have done to fix that.

Thus, the provided /usr/share/vim/vimrc  is *plainly incorrect* in one of two 
ways. First the opening comment, it suggests that "all system-wide defaults" 
are set in the Debian.vim 

Bug#1007212: python3-defcon: multiple circular dependencies

[Jeremy Bicha]

Control: tags -1 +upstream
Control: severity -1 normal

On Sun, Mar 13, 2022 at 12:30 PM Bill Allombert  wrote:
> There is a circular dependency between python3-defcon, python3-fonttools and 
> python3-ufolib2:
>
> python3-defcon  :Depends: python3-fonttools (>= 4.26.2)
> python3-fonttools   :Depends: python3-ufolib2 (>= 0.12.1), python3-defcon 
> (>= 0.6.0)
> python3-ufolib2 :Depends: python3-fonttools (>= 4.29.1)
>
> Complex circular dependencies are known to cause problems during upgrade, so 
> we
> should try to avoid them.

This is an upstream issue. These python libraries do have code
dependencies on each other.

Thank you,
Jeremy

Bug#990534: arduino: Arduino-IDE not starting

[Marco Bodrato]

Package: arduino
Version: 2:1.8.19+dfsg1-1
Followup-For: Bug #990534

Dear Maintainer,

I'trying to run the arduino-ide. Launching it from the menu did not 
work,
I had version 2:1.8.13+dfsg1-2 . Now I updated to version 
2:1.8.19+dfsg1-1,

but nothing changed.

Reading the conversation, I did the following:
# apt install openjdk-11-jre
# apt install openjdk-11-jdk

But I keep on receiving:

$ arduino
Picked up JAVA_TOOL_OPTIONS:
java.lang.UnsatisfiedLinkError: no splashscreen in system library path: 
/usr/lib/jvm/java-17-openjdk-amd64/lib
at 
java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2397)

at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:808)
at java.base/java.lang.System.loadLibrary(System.java:1893)
at 
java.desktop/java.awt.SplashScreen$1.run(SplashScreen.java:134)
at 
java.desktop/java.awt.SplashScreen$1.run(SplashScreen.java:132)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
at 
java.desktop/java.awt.SplashScreen.getSplashScreen(SplashScreen.java:131)

at processing.app.Base.(Base.java:231)
at processing.app.Base.main(Base.java:141)

I did check the following:
$ which -a java
/usr/bin/java
/bin/java
$ ls -la /usr/bin/java
lrwxrwxrwx 1 root root 22 Jul 17  2021 /usr/bin/java -> 
/etc/alternatives/java

$ ls -la /bin/java
lrwxrwxrwx 1 root root 22 Jul 17  2021 /bin/java -> 
/etc/alternatives/java

$ ls -la /etc/alternatives/java
lrwxrwxrwx 1 root root 43 Feb  4 09:28 /etc/alternatives/java -> 
/usr/lib/jvm/java-17-openjdk-amd64/bin/java

$ echo "Using JAVA_OPTIONS: ${JAVA_OPTIONS[*]}"
Using JAVA_OPTIONS:

Somewhere on the net I found some hints suggeting to avoid using 
"-headless" java,

but I do not know how I can choose...

Regards,
mb


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=eo, LC_CTYPE=eo (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 arduino depends on:
ii  arduino-builder   1.3.25-2+b5
ii  arduino-core-avr  1.8.5+dfsg-1
ii  avrdude   6.3-20171130+svn1429-2+b1
ii  default-jre   2:1.11-72
ii  dpkg-dev  1.20.9
ii  libastylej-jni3.1-2+b1
ii  libbatik-java 1.12-4
ii  libbcpg-java  1.68-2
ii  libbcprov-java1.68-2
ii  libcommons-codec-java 1.15-1
ii  libcommons-compress-java  1.20-1
ii  libcommons-exec-java  1.3-2
ii  libcommons-io-java2.8.0-1
ii  libcommons-lang3-java 3.11-1
ii  libcommons-logging-java   1.2-2
ii  libcommons-net-java   3.6-1
ii  libhttpclient-java4.5.13-2
ii  libjackson2-annotations-java  2.12.1-1
ii  libjackson2-core-java 2.12.1-1
ii  libjackson2-databind-java 2.12.1-1
ii  libjaxp1.3-java   1.3.05-6
ii  libjmdns-java 3.5.5-1
ii  libjna-java   5.6.0-1
ii  libjna-platform-java  5.6.0-1
ii  libjsch-java  0.1.55-1
ii  libjssc-java  2.8.0-3
ii  liblistserialsj-dev   1.4.0-1+b1
ii  liblog4j2-java2.16.0-1~deb11u1
ii  librsyntaxtextarea-java   2.5.8-1
ii  librxtx-java  2.2pre2+dfsg1-2
ii  libsemver-java0.9.0-4
ii  libslf4j-java 1.7.30-1
ii  libxml-commons-external-java  1.4.01-5
ii  libxmlgraphics-commons-java   2.4-2~deb11u1
ii  openjdk-11-jre11.0.14+9-1

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-5
ii  policykit-1  0.105-31

arduino suggests no packages.

-- no debconf information


Ĝis,
m

--
http://bodrato.it/

Bug#1006912: is it time to have account deletion in policy?

[Sean Whitton]

Hello,

On Sat 12 Mar 2022 at 03:01PM +01, Marc Haber wrote:

> On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote:
>> Roland Clobus has put a lot of work & thoughts into reproducible images, so 
>> I've
>> added him to cc: now, so he can comment on this aspect of #1006912.
>
> Policy editors, I think we can now choose between taking care of the
> needs of reproducible images right with this policy change or do
> de-scope this temporarily until we have settled on the new wording
> (which also includes some definitions) and then handle this in a second
> change. I think the second change also needs the base-passwd people in
> the loop.

The latter, please, assuming I'm not misunderstanding and the first
change makes things worse on the reproducibility front.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1004330: makes the package useless with PHP 8

[Axel Beckert]

Hi Francesco,

Francesco Potortì wrote:
> >> The necessary change was
> >> 
> >> -$conf['savedir'] = '/var/lib/dokuwiki/data'; //where to store all the 
> >> files
> >> +$conf['savedir'] = './data';  //where to store all the files
> >
> >Do you remember why this was necessary, i.e. what didn't work without it?
> 
> Dokuwiki cannot find the .data directory and says so in the web
> browser.  I suppose that an alternative is creating a data link to
> /var/lib/dokuwiki/data.  Maybe such link existed and I removed it in
> the past and an upgrade does not restore it?

Hrm, this is something which might be related to running multiple
instances of DokuWiki on the same host. The non-default data directory
should be created by the dokuwiki-addsite.

That's also why that "./data" is relative and not absolute.

Maybe this should go into a separate bug report.

> >> I know nothing about how php is managed on Debian.  However, I had to add 
> >> these links:
> >> 
> >> /usr/share/dokuwiki/vendor/paragonie/random_compat/lib -> 
> >> /usr/share/php/random_compat
> >> /usr/share/dokuwiki/vendor/phpseclib/phpseclib/phpseclib -> 
> >> /usr/share/php/phpseclib
> >
> >Good catch! This indeed could be something that I oversaw.
> 
> By the way, those files are in the php-phpseclib and
> php-random-compat packages.

Dependencies for those libraries are already there, yes. Worked fine
for me without these links. Maybe because I didn't use any function
which needs them. Or because I just haven't noticed the corresponding
glitches.

Added them. Shouldn't cause any harm.

> >> # /usr/share/dokuwiki/vendor/marcusschwarz/lesserphp/
> >> 
> >> I replaced all {0} with [0]
> >
> >That's one of the common changes I had to do. I though thought I had a
> >patch for that already in the package on Salsa:
> >
> >https://salsa.debian.org/abe/dokuwiki/-/blob/master/debian/patches/cherrypick_6b6d27d9.patch
> 
> I had just downloaded your package, so apparently you missed that one...

Can't reproduce that anymore. Maybe your testing and my fix above overlapped.

> >> Additionally, I get this in the Apache log:
> >> 
> >> PHP Warning:  Undefined array key "fperm" in 
> >> /usr/share/dokuwiki/inc/Search/Indexer.php on line 1070, referer: 
> >> http://wiki.potorti.it/egc2018/bilancio
> >
> >Yes. These are IIRC fixed upstream in git, but not in a release yet. I
> >might add them to avoid the warning, but for now I just want to do the
> >minimal thing to get it working again.

Should probably tracked in a separate bug report as well and being
tagged as fixed-upstream.

> >> And unfortunately email sending still does not work: emails are sent
> >> with an empty From: field, so they fail at the sendmail level.
> >
> >Funnily for me it's opposite: I get more mails than before, and also
> >for changes I don't see via web interface. Still unclear why.

Found the cause. Those changes are indeed seen in the webinterface. It
were crawlers triggering restoration of old pages whose ACL was set to
world-writable (on purpose back then, now only for authenticated users).

> I get one email per edit, as expected, but they bounce (and I see
> the bounce) because the To: header is empty.  This has happened with
> php8.  After I had patched all the places generating an error in the
> Apache log, I had this behaviour, which undortunately does not
> generate an error, so I could not catch it...

Hrm, leaving that out for now. Maybe file a bug report for this, too,
after I've uploaded the new version.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1007225: ruby-image-processing: CVE-2022-24720

[Salvatore Bonaccorso]

Source: ruby-image-processing
Version: 1.10.3-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-image-processing.

CVE-2022-24720[0]:
| image_processing is an image processing wrapper for libvips and
| ImageMagick/GraphicsMagick. Prior to version 1.12.2, using the
| `#apply` method from image_processing to apply a series of operations
| that are coming from unsanitized user input allows the attacker to
| execute shell commands. This method is called internally by Active
| Storage variants, so Active Storage is vulnerable as well. The
| vulnerability has been fixed in version 1.12.2 of image_processing. As
| a workaround, users who process based on user input should always
| sanitize the user input by allowing only a constrained set of
| operations.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24720
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24720
[1] 
https://github.com/janko/image_processing/security/advisories/GHSA-cxf7-qrc5-9446
[2] 
https://github.com/janko/image_processing/commit/038e4574e8f4f4b636a62394e09983c71980dada

Regards,
Salvatore

Bug#1007224: gpac: CVE-2022-26967

[Salvatore Bonaccorso]

Source: gpac
Version: 2.0.0+dfsg1-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/2138
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2022-26967[0]:
| GPAC 2.0 allows a heap-based buffer overflow in gf_base64_encode. It
| can be triggered via MP4Box.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-26967
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26967
[1] https://github.com/gpac/gpac/issues/2138
[2] https://github.com/gpac/gpac/commit/ea1eca00fd92fa17f0e25ac25652622924a9a6a0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1007223: RM: gnome-twitch -- RoQA; unmaintained; no longer works

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gnome-twi...@packages.debian.org

gnome-twitch currently fails to build with the latest meson. That's a simple fix
but I noticed that the app doesn't work at all now.

I tried updating to the latest release from 2018 but that didn't fix the issue.

It looks like the app stopped working in 2020 because of Twitch API
changes and there hasn't been any work upstream to switch to the newer
API.

Therefore, please remove gnome-twitch from Debian unstable.

https://github.com/vinszent/gnome-twitch/issues/402#issuecomment-678449783

Thank you,
Jeremy Bicha

Bug#1006978: Plz update

[Peter Mueller]

… the developer apparently has a new version with a fix. Could you please test 
it yourself and put it into experimental?  Thanks!
Peter

Bug#1007222: transition: onetbb

[Sebastian Ramacher]

Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html
Control: tags -1 moreinfo

On 2022-03-13 16:59:48 -0400, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> This involves an upstream source name change (from tbb to onetbb),
> as well as SOVERSION bump (from 2 to 12), along with a major API
> change including some changes in the core API.
> 
> I should have submitted this after my local build test for the
> reverse dependencies of libtbb-dev, but fellow developers from
> debian-science are eager to see this in unstable to unblock
> their works.
> 
> I have not tested by myself, but I heard from an archlinux
> developer that this API bump breaks a lot packages. And
> some upstreams decided to disable or drop tbb support as
> a result. I guess we can take similar measures for short
> term workaround.

Please remove the moreinfo tag once these issues have been investigated
and bugs have been filed.

Cheers

> 
> Ben file:
> 
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";
> Thank you for using reportbug
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#854978: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#854978: fixed in netpbm-free 2:10.97.00-1)

[Salvatore Bonaccorso]

Hi Andreas,

Thanks for your promt reply!

On Sun, Mar 13, 2022 at 10:02:15PM +0100, Andreas Tille wrote:
> Hi Salvatore,
> 
> Am Sun, Mar 13, 2022 at 09:33:01PM +0100 schrieb Salvatore Bonaccorso:
> > > On Sun, Mar 13, 2022 at 10:24:16AM +, Debian Bug Tracking System 
> > > wrote:
> > > >  CVE-2017-2579, CVE-2017-2580 and CVE-2017-2581 before 10.61 thus
> > > >   - Closes: #854978
> > > 
> > > The before 10.61 is just because of the CVE description right? Note we
> > > cannot rely on the CVE description, because they might reflect a
> > > specific writing up in time and other aspects.
> > > 
> > > Do we have an upstream revision indicating that those issues are
> > > really fixed?
> > 
> > For example, CVE-2017-2581 is probably
> > https://sourceforge.net/p/netpbm/code/2989/ ? (which would only be in
> > 10.78.05). So one really needs to be careful with description
> > information and verify if those are true. If following the SuSE triage
> > then *possibly* for two issues the fix is revision 2821 upstream,
> > while for CVE-2017-2581 it would be the above.
> 
> I admit I just trusted the description without checking the code in
> detail.  If you think this is wrong I'm perfectly fine if you reopen the
> bug.

I will try to check the above and see if we can be confident enough
that it's fixed in both r2821 for two CVEs and r2989 for
CVE-2017-2581. I do not know yet if this is wrong or still true, so
maybe if we want to play on safe side it might be wise to reopen the
bug until confirmed. But I defintively won't go wasting your time as
well. We did keept the issues actually as "undetermined" in the
security-tracker because it was hard enough to track down the status
back on triage time.

> > Thanks for looking into the update!
> 
> It was obviously very long overdue and I did my best in the limited
> time span I was able to spent on this package.

Ack! 

Regards,
Salvatore

Bug#854978: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#854978: fixed in netpbm-free 2:10.97.00-1)

[Andreas Tille]

Hi Salvatore,

Am Sun, Mar 13, 2022 at 09:33:01PM +0100 schrieb Salvatore Bonaccorso:
> > On Sun, Mar 13, 2022 at 10:24:16AM +, Debian Bug Tracking System wrote:
> > >  CVE-2017-2579, CVE-2017-2580 and CVE-2017-2581 before 10.61 thus
> > >   - Closes: #854978
> > 
> > The before 10.61 is just because of the CVE description right? Note we
> > cannot rely on the CVE description, because they might reflect a
> > specific writing up in time and other aspects.
> > 
> > Do we have an upstream revision indicating that those issues are
> > really fixed?
> 
> For example, CVE-2017-2581 is probably
> https://sourceforge.net/p/netpbm/code/2989/ ? (which would only be in
> 10.78.05). So one really needs to be careful with description
> information and verify if those are true. If following the SuSE triage
> then *possibly* for two issues the fix is revision 2821 upstream,
> while for CVE-2017-2581 it would be the above.

I admit I just trusted the description without checking the code in
detail.  If you think this is wrong I'm perfectly fine if you reopen the
bug.
 
> Thanks for looking into the update!

It was obviously very long overdue and I did my best in the limited
time span I was able to spent on this package.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#1007185: btrfsmaintenance: reproducible builds: Timestamp embedded in manpage

[Vagrant Cascadian]

On 2022-03-12, Nicholas D. Steeves wrote:
> Vagrant Cascadian  writes:
>> The build timestamp is embedded in
>> /usr/share/man/man8/btrfsmaintenance.8.gz:
>>
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/btrfsmaintenance.html
>>
>>   .TH·BTRFSMAINTENANCE·8·"12·March,·2022"·v0.5
>>   vs.
>>   .TH·BTRFSMAINTENANCE·8·"13·March,·2022"·v0.5
>>
>> The attached patch fixes this by passing the --utc argument to date in
>> debian/create-man-page.sh and by using a locale-independent date format.
>>
>>
>> With this patch applied, btrfsmaintenance should build reproducibly on
>> tests.reproducible-builds.org!

> Wow!  Thank you for catching this so quickly, and for submitting a
> patch, and sorry I missed this.

Just happened to look at it shortly after you had apparently
uploaded. heh. :)


> By the way, are ISO 8601 dates in man pages a goal in Debian?

I'm not aware of any goal, it just seems like the most consistent format
to use, works well for reproducible builds, and isn't "wrong". :)


> I noted GNU man pages use "%B %d, %Y", and
> chose the more international little endian long-form.  There's no
> problem changing to ISO 8601 as you suggest, I'm just curious.

Maybe it'd be worth exploring getting GNU to move towards ISO 8601
instead... I'll plant that seed in the back of my mind and see where it
goes!


>> Thanks for maintaining btrfsmaintenance!
>
> You're welcome :-)
>
> On a tangential topic, what would you recommend for making shell scripts
> such as btrfsmaintenance aware of plug/unplug (alternatively off battery
> vs on battery) state, to suspend and resume CPU and IO intensive
> operations, and without falling back to polling?  UPower, to cover both
> laptops and servers that have a UPS?

No opinions on that, good luck!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1006383: mercurial: autopkgtest needs update for new version of pygments: output changed

[Paul Gevers]

Source: mercurial
Followup-For: Bug #1006383
Control: tags -1 patch

Dear maintainer,

This issue is blocking pygments from migrating to testing. I tried to
prepare an NMU, but with the attached patch for the original issue,
autopkgtest fails locally for me on 4 other tests, so I'm unsure if
it's enough.

Paul
diff --git a/debian/patches/series b/debian/patches/series
index b639c36..7ff5f74 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ deb_specific__optional-dependencies
 deb_specific__disable_libdir_replacement.patch
 0005-Tolerate-SIGINT-getting-the-kill-in-test-stdio.py.patch
 deb_specific__which_silence_warning.patch
+tests-update-for-latest-pygments.patch
diff --git a/debian/patches/tests-update-for-latest-pygments.patch 
b/debian/patches/tests-update-for-latest-pygments.patch
new file mode 100644
index 000..a2477c8
--- /dev/null
+++ b/debian/patches/tests-update-for-latest-pygments.patch
@@ -0,0 +1,31 @@
+From: Paul Gevers 
+Date: Sun, 13 Mar 2022 20:42:58 +0100
+X-Dgit-Generated: 6.0.2-1.1 1565c552b0b79a69eea8b1ac12e2c211d01c3df1
+Subject: tests: update for latest pygments
+
+Closes: #1006383
+
+---
+
+--- mercurial-6.0.2.orig/tests/test-run-tests.t
 mercurial-6.0.2/tests/test-run-tests.t
+@@ -176,14 +176,14 @@ test diff colorisation
+   running 1 tests using 1 parallel processes 
+   
+   \x1b[38;5;124m--- $TESTTMP/test-failure.t\x1b[39m (esc)
+-  \x1b[38;5;34m+++ $TESTTMP/test-failure.t.err\x1b[39m (esc)
++  \x1b[38;5;28m+++ $TESTTMP/test-failure.t.err\x1b[39m (esc)
+   \x1b[38;5;90;01m@@ -1,4 +1,4 @@\x1b[39;00m (esc)
+- $ echo "bar-baz"; echo "bar-bad"; echo foo
+-  \x1b[38;5;34m+  bar*baz (glob)\x1b[39m (esc)
+- bar*bad (glob)
++  \x1b[38;5;250m \x1b[39m  $ echo "bar-baz"; echo "bar-bad"; echo foo (esc)
++  \x1b[38;5;28m+  bar*baz (glob)\x1b[39m (esc)
++  \x1b[38;5;250m \x1b[39m  bar*bad (glob) (esc)
+   \x1b[38;5;124m-  bar*baz (glob)\x1b[39m (esc)
+   \x1b[38;5;124m-  | fo (re)\x1b[39m (esc)
+-  \x1b[38;5;34m+  foo\x1b[39m (esc)
++  \x1b[38;5;28m+  foo\x1b[39m (esc)
+   
+   \x1b[38;5;88mERROR: \x1b[39m\x1b[38;5;9mtest-failure.t\x1b[39m\x1b[38;5;88m 
output changed\x1b[39m (esc)
+   !

Bug#1007222: transition: onetbb

[M. Zhou]

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

Hi release team,

This involves an upstream source name change (from tbb to onetbb),
as well as SOVERSION bump (from 2 to 12), along with a major API
change including some changes in the core API.

I should have submitted this after my local build test for the
reverse dependencies of libtbb-dev, but fellow developers from
debian-science are eager to see this in unstable to unblock
their works.

I have not tested by myself, but I heard from an archlinux
developer that this API bump breaks a lot packages. And
some upstreams decided to disable or drop tbb support as
a result. I guess we can take similar measures for short
term workaround.

Ben file:

title = "tbb";
is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
is_good = .depends ~ "libtbb12";
is_bad = .depends ~ "libtbb2";
Thank you for using reportbug

Bug#1000336: Upgrading tbb

[M. Zhou]

Hi,

Recently I'm not able to test the build of libtbb-dev's reverse dependencies
as my build machine was out of access. That blocks my submission of the
transition bug and hence I'm stalled at this point.
According to some archlinux developers, this transition breaks a lot of
reverse dependencies since some of the core APIs have been changed.
Please expect a relatively negative rebuild result.

Help is welcome.

On Mon, 2022-03-14 at 01:30 +0530, Nilesh Patra wrote:
> Hi Mo,
> 
> On 2/23/22 11:01 AM, M. Zhou wrote:
> > Hello guys. Finally it's all green on our release architectures
> > https://buildd.debian.org/status/package.php?p=onetbb=experimental
> > 
> > I shall request the slot for transition once finished the rebuild
> > of its reverse dependencies and filed FTBFS bugs if any.
> 
> Did you get a chance to do this yet?
> As we _really_ need numba at this point.
> 
> Regards,
> Nilesh
> 
> 

Bug#938987: Hit this as well on sid

[Paul Tagliamonte]

Hey folks,

I hit this on sid. nsd is failing to start with a sensible config,
done within the bounds of allowed NSD configuration, and fails to
start. This has taken me a huge amount of time to track down.

What is the NSD maintainer's opinion of the correct way to get nsd to
behave with a sensible config, here? I'm reluctant to trim caps, since
tightening them seems good, but they're too tight, it appears.

  paultag

-- 
:wq

Bug#854978: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#854978: fixed in netpbm-free 2:10.97.00-1)

[Salvatore Bonaccorso]

Hi Andreas,

On Sun, Mar 13, 2022 at 09:07:20PM +0100, Salvatore Bonaccorso wrote:
> Hi Andreas,
> 
> On Sun, Mar 13, 2022 at 10:24:16AM +, Debian Bug Tracking System wrote:
> >  netpbm-free (2:10.97.00-1) unstable; urgency=medium
> >  .
> >* Team upload.
> >* New upstream version
> >   - Closes: #977007, #386388, #847241
> >  CVE-2017-2579, CVE-2017-2580 and CVE-2017-2581 before 10.61 thus
> >   - Closes: #854978
> 
> The before 10.61 is just because of the CVE description right? Note we
> cannot rely on the CVE description, because they might reflect a
> specific writing up in time and other aspects.
> 
> Do we have an upstream revision indicating that those issues are
> really fixed?

For example, CVE-2017-2581 is probably
https://sourceforge.net/p/netpbm/code/2989/ ? (which would only be in
10.78.05). So one really needs to be careful with description
information and verify if those are true. If following the SuSE triage
then *possibly* for two issues the fix is revision 2821 upstream,
while for CVE-2017-2581 it would be the above.

Thanks for looking into the update!

Regards,
Salvatore

Bug#1007221: RM: libnfsidmap -- RoQA; merged into nfs-utils

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sramac...@debian.org

Please remove libnfsidmap from the archive. It was merged into
nfs-utils. See #925022

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1007220: digikam: Failed to update the database schema from version 10 to version 11 with mysql database

[Vincent Danjean]

Package: digikam
Version: 4:7.5.0-5
Severity: important

When using digikam with an external (mysql/mariadb) database, the upgrade
can fail leading to digikam refusing to start.
This is due to a permission problems.

It can be workarounded/fixed by issuing the following mysql command:
set global log_bin_trust_function_creators=1;
I'm not sure of all the security implication (it does not matter for
me: I'm alone on the machine).

At minimal, a notice in /usr/share/doc/digikam/NEWS.Debian.gz would
be appreciated (and/or a better/more precise error message from digikam).

Details of this can be found in
https://bugs.kde.org/show_bug.cgi?id=451460
and
https://bugs.kde.org/show_bug.cgi?id=435065

  Regards,
Vincent


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

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

Versions of packages digikam depends on:
ii  digikam-data  4:7.5.0-5
ii  digikam-private-libs  4:7.5.0-5
ii  libc6 2.33-7
ii  libgcc-s1 12-20220222-1
ii  libkf5configcore5 5.90.0-1
ii  libkf5coreaddons5 5.90.0-1
ii  libkf5i18n5   5.90.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3+b2
ii  libqt5core5a  5.15.2+dfsg-15
ii  libqt5gui55.15.2+dfsg-15
ii  libqt5sql55.15.2+dfsg-15
ii  libqt5sql5-mysql  5.15.2+dfsg-15
ii  libqt5sql5-sqlite 5.15.2+dfsg-15
ii  libqt5widgets55.15.2+dfsg-15
ii  libstdc++612-20220222-1
ii  perl  5.34.0-3

Versions of packages digikam recommends:
ii  chromium [www-browser] 98.0.4758.102-1+b1
ii  ffmpegthumbs   4:21.08.0-1
ii  firefox [www-browser]  96.0.3-1
ii  firefox-esr [www-browser]  91.6.0esr-1
ii  konqueror [www-browser]4:21.08.2-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  w3m [www-browser]  0.5.3+git20210102-6

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.90.0-1
pn  digikam-doc
ii  systemsettings 4:5.24.2-1

-- no debconf information

Bug#854978: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#854978: fixed in netpbm-free 2:10.97.00-1)

[Salvatore Bonaccorso]

Hi Andreas,

On Sun, Mar 13, 2022 at 10:24:16AM +, Debian Bug Tracking System wrote:
>  netpbm-free (2:10.97.00-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream version
>   - Closes: #977007, #386388, #847241
>  CVE-2017-2579, CVE-2017-2580 and CVE-2017-2581 before 10.61 thus
>   - Closes: #854978

The before 10.61 is just because of the CVE description right? Note we
cannot rely on the CVE description, because they might reflect a
specific writing up in time and other aspects.

Do we have an upstream revision indicating that those issues are
really fixed?

Regards,
Salvatore

Bug#1007219: mariadb-10.6: FTBFS on sparc64:

[John Paul Adrian Glaubitz]

Hello!

On 3/13/22 21:00, Otto Kekäläinen wrote:
> This might be related to:
> - uring on sparc64? log has warning about anon_inode:[io_uring]
> - slow builder? value might be to small for
> innodb_fatal_semaphore_wait_threshold
> - something else in sparc64, e.g. MDEV-27954

FWIW, there are sparc64 porterboxes available in the GCC compile farm:

> https://cfarm.tetaneutral.net/machines/list/

Accounts can be obtained by applying here:

> https://gcc.gnu.org/wiki/CompileFarm

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1006456: transition: openldap

[Ryan Tandy]

On Sun, Mar 13, 2022 at 02:26:20PM +0100, Sebastian Ramacher wrote:

Please take a look at golang-openldap. It's an arch: all package and
hardcodes a dependency on libldap-2.4-2


Thanks. I hadn't noticed it was hard-coded. Filed #1006456.

Also examining some of the "unknown" rows in the tracker, looks like 
several might legitimately be unused/unneeded build-depends. Will 
probably file some sev:minor bugs for those later.


Otherwise looks like things are going smoothly so far?

Bug#1007219: mariadb-10.6: FTBFS on sparc64:

[Otto Kekäläinen]

Source: mariadb-10.6
Version: 1:10.6.7-3
Tags: upstream, confirmed, ftbfs
User: debian-sp...@lists.debian.org
Usertags: sparc64
Forwarded: https://jira.mariadb.org/browse/MDEV-28052
X-Debbugs-CC: debian-sp...@lists.debian.org


After upload of mariadb-10.6 1:10.6.7-3 I noticed that sparc64 builds
at https://buildd.debian.org/status/package.php?p=mariadb-10.6 were
failing:


main.implicit_commit 'innodb'w9 [ fail ]
Test ended at 2022-03-11 18:18:39

CURRENT_TEST: main.implicit_commit
mysqltest: In included file "./include/implicit_commit_helper.inc":
included from /<>/mysql-test/main/implicit_commit.test at line 361:
At line 3: query '$statement' failed:  (2013): Lost
connection to server during query

The result from queries just before the failure was:
< snip >
# SQLCOM_ALTER_VIEW
#
INSERT INTO db1.trans (a) VALUES (1);
alter view v1 as select 2;
CALL db1.test_if_commit();
IMPLICIT COMMIT
YES
#
# SQLCOM_DROP_VIEW
#
INSERT INTO db1.trans (a) VALUES (1);
drop view v1;
CALL db1.test_if_commit();
IMPLICIT COMMIT
YES
#
# SQLCOM_CREATE_INDEX
#
INSERT INTO db1.trans (a) VALUES (1);
create index idx1 on t1(a);

More results from queries before failure can be found in
/<>/builddir/mysql-test/var/9/log/implicit_commit.log


Server [mysqld.1 - pid: 3925230, winpid: 3925230, exit: 256] failed
during test run
Server log from this test:
--SERVER LOG START---
2022-03-11 18:18:36 0 [ERROR] [FATAL] InnoDB:
innodb_fatal_semaphore_wait_threshold was exceeded for dict_sys.latch.
Please refer to
https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/
220311 18:18:36 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.6.7-MariaDB-3-log
key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
63733 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
/<>/builddir/sql/mariadbd(my_print_stacktrace+0x14)[0x1e98a1c]
The manual page at
https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/
contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /<>/builddir/mysql-test/var/9/mysqld.1/data
Resource Limits:
Limit Soft Limit   Hard Limit   Units
Max cpu time  unlimitedunlimitedseconds
Max file size unlimitedunlimitedbytes
Max data size unlimitedunlimitedbytes
Max stack size8388608  unlimitedbytes
Max core file sizeunlimitedunlimitedbytes
Max resident set  unlimitedunlimitedbytes
Max open files1024 1024 files
Max processes 128960   128960   processes
Max locked memory 4229464064   4229464064   bytes
Max address space unlimitedunlimitedbytes
Max file locksunlimitedunlimitedlocks
Max pending signals   128960   128960   signals
Max msgqueue size 819200   819200   bytes
Max nice priority 00
Max realtime priority 00
Max realtime timeout  unlimitedunlimitedus
Core pattern: core

--SERVER LOG END-


 - found 'core' (0/5)

Trying 'dbx' to get a backtrace

Trying 'gdb' to get a backtrace from coredump
/<>/builddir/mysql-test/var/9/log/main.implicit_commit-innodb/mysqld.1/data/core
Core generated by '/<>/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--

warning: Can't open file anon_inode:[io_uring] which was expanded to
anon_inode:[io_uring] during file-backed mapping note processing

warning: Can't open file anon_inode:[io_uring] which was 

Bug#1000336: Upgrading tbb

[Nilesh Patra]

Hi Mo,

On 2/23/22 11:01 AM, M. Zhou wrote:

Hello guys. Finally it's all green on our release architectures
https://buildd.debian.org/status/package.php?p=onetbb=experimental

I shall request the slot for transition once finished the rebuild
of its reverse dependencies and filed FTBFS bugs if any.


Did you get a chance to do this yet?
As we _really_ need numba at this point.

Regards,
Nilesh




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors

[John Paul Adrian Glaubitz]

Hi Daniel!

On 3/2/22 23:17, Daniel Black wrote:
> The selective CFLAGS on specific files are there to enable
> optimizations in certain functions. Elsewhere in the
> code there is runtime detection made of the VSX/vpmsum to actually use the 
> code.

So, it turns out that doesn't work, see [1]:

/<>/extra/mariabackup/xbstream.cc
/tmp/ccwobTGg.s: Assembler messages:
/tmp/ccwobTGg.s:48: Error: unrecognized opcode: `tbegin.'
/tmp/ccwobTGg.s:106: Error: unrecognized opcode: `tabort.'
/tmp/ccwobTGg.s:151: Error: unrecognized opcode: `tend.'

Can't you just change the code to check for the compiler baseline in use before
emitting any POWER8 instructions? Upstream code really shouldn't use POWER8
instructions unconditionally.

Debian's ppc64 big-endian port uses the POWER5 baseline, not POWER8.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007216

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1007216: mariadb-10.6: FTBFS on ppc64: unrecognized opcode tbegin/tabort/tend

[John Paul Adrian Glaubitz]

Hello Otto!

On 3/13/22 20:36, Otto Kekäläinen wrote:
> CMakeFiles/mbstream.dir/xbstream.cc.o.d -o
> CMakeFiles/mbstream.dir/xbstream.cc.o -c
> /<>/extra/mariabackup/xbstream.cc
> /tmp/ccwobTGg.s: Assembler messages:
> /tmp/ccwobTGg.s:48: Error: unrecognized opcode: `tbegin.'
> /tmp/ccwobTGg.s:106: Error: unrecognized opcode: `tabort.'
> /tmp/ccwobTGg.s:151: Error: unrecognized opcode: `tend.'
> 
> Full log at 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=ppc64=1%3A10.6.7-3=1647018395=0
> 
> Builds of powerpc and ppc64el work, this failure is only on ppc64.
> This arch failed previously on Debian#1006527 but it was fixed on the
> latest upload, and thus this second failure got uncovered.

Looks like unconditional use of POWER8 transactional instructions [1].

The code should check for the availability of POWER8 or _CALL_ELF 2 before
trying to use POWER8 instructions:

(sid_ppc64el-dchroot)glaubitz@plummer:~$ echo | gcc -E -dM -|grep POWER
#define __POWER8_VECTOR__ 1
(sid_ppc64el-dchroot)glaubitz@plummer:~$ 
(sid_ppc64el-dchroot)glaubitz@plummer:~$ echo | gcc -E -dM -|grep ELF
#define __ELF__ 1
#define _CALL_ELF 2
(sid_ppc64el-dchroot)glaubitz@plummer:~$

Adrian

> [1] 
> https://www.ibm.com/docs/en/aix/7.2?topic=concepts-aix-transactional-memory-programming

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1007218: mariadb-10.6: FTBFS on powerpc: test main.grant_kill: Result length mismatch

[Otto Kekäläinen]

Source: mariadb-10.6
Version: 1:10.6.7-3
Tags: upstream, confirmed, ftbfs
User: debian-powe...@lists.debian.org
Usertags: powerpc
Forwarded: https://jira.mariadb.org/browse/MDEV-23915
X-Debbugs-CC: debian-powe...@lists.debian.org

Filing this bug for tracking purposes. No help needed from Debian
porters, the root cause seems more or less evident and should be fixed
by upstream in a later version.

Latest mariadb-10.6 1:10.6.7-3 does build, but test suite fails with:

main.grant_kill  w10 [ fail ]
Test ended at 2022-03-11 17:19:58
CURRENT_TEST: main.grant_kill
--- /<>/mysql-test/main/grant_kill.result 2022-02-10
20:07:03.0 +
+++ /<>/mysql-test/main/grant_kill.reject 2022-03-11
17:19:58.158444112 +
@@ -20,7 +20,7 @@
 foo
 root
 KILL ID;
-ERROR HY000: You are not owner of thread ID
+ERROR HY000: You are not owner of thread 0
 disconnect foo;
 disconnect bar;
 connection default;
mysqltest: Result length mismatch

Full log:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=powerpc=1%3A10.6.7-3=1647019335=0

Related:
https://github.com/MariaDB/server/pull/2028
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d8b6f1399697c701ae769c8055c57d762f44e50a

Bug#1007217: golang-openldap: openldap 2.5 transition

[Ryan Tandy]

Source: golang-openldap
Version: 0.2-2
Severity: important
Control: block 1006456 by -1

Dear Maintainer,

golang-openldap-dev has a hard-coded dependency on libldap-2.4-2. For 
the openldap 2.5 transition which is currently underway, the dependency 
should be updated to libldap-2.5-0.

I'm sorry for the late notice. I didn't notice the hard-coded 
dependency; the release team brought it to my attention after the 
transition started.

I also noticed the package seems to embed old copies of some libldap 
headers; these are now out-of-date. I feel like there should be some 
better solution than embedding them? If golang-openldap-dev needs them 
in /usr/share/gocode for building, maybe they could be symlinks to 
/usr/include? Happy to create a separate bug for this, if you want.

The package builds fine for me with the new version of libldap-dev, but 
I don't know any Go and I don't know how to test it. It also doesn't 
seem to have any rdepends in the archive.

A couple of more minor things:

golang-openldap-dev depends on libldap2-dev which depends on the runtime 
library, so maybe the direct dependency on libldap isn't strictly 
necessary? Just thinking of future transitions.

I'm asking maintainers to depend on libldap-dev instead of libldap2-dev 
going forward. libldap2-dev is now a transitional package and I'd like 
to drop it at some point.

Thank you,
Ryan

Bug#1007216: mariadb-10.6: FTBFS on ppc64: unrecognized opcode tbegin/tabort/tend

[Otto Kekäläinen]

Source: mariadb-10.6
Version: 1:10.6.7-1
Tags: upstream, confirmed, help, ftbfs
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-CC: debian-powe...@lists.debian.org

Builds on ppc64 failed with:

[ 48%] Building CXX object
extra/mariabackup/CMakeFiles/mbstream.dir/xbstream.cc.o
cd /<>/builddir/extra/mariabackup && /usr/bin/c++
-DBTR_CUR_ADAPT -DBTR_CUR_HASH_ADAPT -DCOMPILER_HINTS -DDBUG_TRACE
-DHAVE_CONFIG_H -DHAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE=1
-DHAVE_LIBNUMA=1 -DHAVE_LZ4=1 -DHAVE_LZ4_COMPRESS_DEFAULT=1
-DHAVE_OPENSSL -DHAVE_SCHED_GETCPU=1 -DHAVE_SNAPPY=1
-DHAVE_SYSTEM_REGEX -DHAVE_URING -DPCRE_STATIC=1
-DWITH_INNODB_DISALLOW_WRITES -D_FILE_OFFSET_BITS=64
-I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/storage/innobase/include
-I/<>/storage/innobase/handler
-I/<>/libbinlogevents/include -I/<>/tpool
-I/<>/include -I/<>/sql
-I/<>/extra/mariabackup/quicklz
-I/<>/extra/mariabackup -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
--param=ssp-buffer-size=4 -Wconversion -Wno-sign-conversion -O2 -g
-static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
-Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
-DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
-Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings
-Wdate-time -D_FORTIFY_SOURCE=2 -DUNIV_LINUX -D_GNU_SOURCE=1
-UMYSQL_SERVER -std=gnu++11 -MD -MT
extra/mariabackup/CMakeFiles/mbstream.dir/xbstream.cc.o -MF
CMakeFiles/mbstream.dir/xbstream.cc.o.d -o
CMakeFiles/mbstream.dir/xbstream.cc.o -c
/<>/extra/mariabackup/xbstream.cc
/tmp/ccwobTGg.s: Assembler messages:
/tmp/ccwobTGg.s:48: Error: unrecognized opcode: `tbegin.'
/tmp/ccwobTGg.s:106: Error: unrecognized opcode: `tabort.'
/tmp/ccwobTGg.s:151: Error: unrecognized opcode: `tend.'

Full log at 
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=ppc64=1%3A10.6.7-3=1647018395=0

Builds of powerpc and ppc64el work, this failure is only on ppc64.
This arch failed previously on Debian#1006527 but it was fixed on the
latest upload, and thus this second failure got uncovered.

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

[...]

> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

There are users who depend on GTK's non-CUPS behaviour? Heaven help
them! They are expecting an experience divorced from what the the
printing system provides. They will possibly be shocked when using
bookworm.

The one thing GTK did correctly on buster and bullseye was handle
the shared queues of remote CUPS servers. On bookworm these are are
now inaccessible. A regression in its so-called "fallback" status?
I do not think I will lose much sleep over this :).

Regards,

Brian.

Bug#762939: nfs-common: /etc/init.d/nfs-common starts #!/bin/bash

[Ben Hutchings]

Control: tag -1 wontfix

On Fri, 26 Sep 2014 14:50:01 +0200 John Hughes  wrote:
> Package: nfs-common
> Version: 1:1.2.8-9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> /etc/init.d/nfs-common starts #!/bin/bash, but doesn't seem to contain
> any bashisms.  It'd be nice to use /bin/sh.
[...]

This is true, but it sources /etc/default/nfs-common which could
contain bashisms.  I don't think this is worth the risk.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1006610: gnucash: Crash with std::bad_alloc when trying to create any report

[Maximilian Stein]

Dear Yuta,

Thanks for your suggestion. Indeed, both 2.34.5-1 and 2.34.6-1 worked 
fine for me!


Should wo forward this report to the maintainers of libwebkit2gtk-4.0-37 
then?


Best,
Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006009: fixed in libwebp 1.2.2-1

[Andres Salomon]

Hi Jeff,

I'm planning to a NMU of libwebp in 2 days (Tues Mar 15th) to fix this 
bug, if you lack the time to fix it before then.


Thanks,

Andres


On 3/13/22 01:22, Jeremy Bicha wrote:

Please set the urgency to high when you do the upload to fix the new 
regression. That will automatically reduce the time to migrate to 
testing to 2 days since this transition has been open for several 
weeks now.


Thank you,
Jeremy Bicha

Bug#944661: nfs-kernel-server: Please support specifying ionice-ness

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 13 Nov 2019 14:41:13 +0100 Diederik de Haas
 wrote:
> Package: nfs-kernel-server
> Version: 1:1.3.4-2.5
> Severity: wishlist
> 
> Once can already specify nice-ness through RPCNFSDPRIORITY which sets
> the --nicelevel parameter of start-stop-daemon.
> But I want to also specify the ionice-ness and start-stop-daemon already
> supports that through the --iosched parameter.
> It would be great if that was enacted through /etc/init.d/nfs-kernel-server 
> invocation and preferably set via /etc/default/nfs-kernel-server file.
[...]

I/O scheduling priority can already be set through systemd service
configuration.  I don't anticipate adding any new features to the
Debian-specific init scripts.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1007214: monit: The rsyslog PID file monit wants to use is not created anymore

[Florian Lutz]

Package: monit
Version: 1:5.27.2-1
Severity: normal
Tags: patch

The system unit for rsyslog now explicitly specifies -iNONE and thus
/var/run/rsyslogd.pid ist not create anymore, but the package default
configuration still references this PID file.

Solution in /etc/monit/conf-available/rsyslog was:

check process rsyslogd matching /usr/sbin/rsyslogd


-- Package-specific info:

Contents of /etc/monit/ directory:
/etc/monit:
total 40
drwxr-xr-x 2 root root  4096 Mar 12 22:38 conf-available
drwxr-xr-x 2 root root  4096 Mar 13 18:57 conf-enabled
drwxr-xr-x 2 root root  4096 Dec 27  2018 conf.d
drwxr-xr-x 2 root root  4096 Mar 13 13:19 custom
-rw--- 1 root root   691 Oct 21  2017 monitrc
-rw--- 1 root root 13110 Jan 25  2021 monitrc.orig
drwxr-xr-x 2 root root  4096 Mar 12 22:39 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 Nov 28  2016 acpid
-rw-r--r-- 1 root root  640 Nov 28  2016 apache2
-rw-r--r-- 1 root root  455 Nov 28  2016 at
-rw-r--r-- 1 root root  691 Nov 28  2016 cron
-rw-r--r-- 1 root root  602 Nov 28  2016 mdadm
-rw-r--r-- 1 root root  669 Nov 28  2016 memcached
-rw-r--r-- 1 root root  703 Nov 28  2016 mysql
-rw-r--r-- 1 root root  521 Nov 28  2016 nginx
-rw-r--r-- 1 root root  471 Nov 28  2016 openntpd
-rw-r--r-- 1 root root 1200 Jan 25  2021 openssh-server
-rw-r--r-- 1 root root  683 Nov 28  2016 pdns-recursor
-rw-r--r-- 1 root root 1426 Jan 25  2021 postfix
-rw-r--r-- 1 root root  862 Mar 13 18:57 rsyslog
-rw-r--r-- 1 root root  501 Nov 28  2016 smartmontools
-rw-r--r-- 1 root root  307 Oct 21  2017 snmpd

/etc/monit/conf-enabled:
total 0
lrwxrwxrwx 1 root root 23 Oct 21  2017 acpid -> ../conf-available/acpid
lrwxrwxrwx 1 root root 20 Oct 21  2017 at -> ../conf-available/at
lrwxrwxrwx 1 root root 22 Oct 21  2017 cron -> ../conf-available/cron
lrwxrwxrwx 1 root root 23 Oct 21  2017 mysql -> ../conf-available/mysql
lrwxrwxrwx 1 root root 32 Oct 21  2017 openssh-server -> 
../conf-available/openssh-server
lrwxrwxrwx 1 root root 25 Oct 21  2017 postfix -> ../conf-available/postfix
lrwxrwxrwx 1 root root 25 Oct 21  2017 rsyslog -> ../conf-available/rsyslog
lrwxrwxrwx 1 root root 23 Oct 21  2017 snmpd -> ../conf-available/snmpd

/etc/monit/conf.d:
total 0
lrwxrwxrwx 1 root root 20 Dec 27  2018 imapproxyd -> ../custom/imapproxyd
lrwxrwxrwx 1 root root 14 Oct 21  2017 nscd -> ../custom/nscd
lrwxrwxrwx 1 root root 13 Oct 21  2017 ntp -> ../custom/ntp
lrwxrwxrwx 1 root root 16 Oct 21  2017 rsyncd -> ../custom/rsyncd
lrwxrwxrwx 1 root root 16 Oct 21  2017 thttpd -> ../custom/thttpd

/etc/monit/custom:
total 44
-rw-r--r-- 1 root root  596 Oct 21  2017 dhcpd
-rw-r--r-- 1 root root  328 Oct 16  2019 fitsys
-rw-r--r-- 1 root root  514 Dec 27  2018 imapproxyd
-rw-r--r-- 1 root root 1055 Oct 21  2017 named
-rw-r--r-- 1 root root   78 Oct 21  2017 nightly-maintenance.inc
-rw-r--r-- 1 root root  484 Oct 21  2017 nscd
-rw-r--r-- 1 root root  438 Oct 21  2017 ntp
-rw-r--r-- 1 root root  341 Oct 21  2017 rsyncd
-rw-r--r-- 1 root root  958 Oct 21  2017 squid3
-rw-r--r-- 1 root root  903 Oct 21  2017 thttpd
-rw-r--r-- 1 root root  908 Oct 21  2017 tinc

/etc/monit/templates:
total 12
-rw-r--r-- 1 root root 164 Sep 30  2014 rootbin
-rw-r--r-- 1 root root 160 Sep 30  2014 rootrc
-rw-r--r-- 1 root root 164 Sep 30  2014 rootstrict


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

Kernel: Linux 5.15.0-0.bpo.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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monit depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u2
ii  libcrypt11:4.4.18-4
ii  libpam0g 1.4.0-9+deb11u1
ii  libssl1.11.1.1k-1+deb11u1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/conf-available/rsyslog changed:
 check process rsyslogd matching /usr/sbin/rsyslogd
   group system
   group rsyslogd
   start program = "/etc/init.d/rsyslog start"
   stop  program = "/etc/init.d/rsyslog stop"
   if 5 restarts with 5 cycles then timeout
   depend on rsyslogd_bin
   depend on rsyslogd_rc
   depend on rsyslog_file
 check file rsyslogd_bin with path /usr/sbin/rsyslogd
   group rsyslogd
   include /etc/monit/templates/rootbin
 check file rsyslogd_rc with path "/etc/init.d/rsyslog"
   group rsyslogd
   include /etc/monit/templates/rootbin
 check file rsyslog_file with path /var/log/syslog
   group rsyslogd
   # Note: activate the immark plugin for 

Bug#1005779: djangorestframework: autopkgtest needs update for new version of pygments

[Paul Gevers]

Source: djangorestframework
Version: 3.12.4-2
Followup-For: Bug #1005779

Dear maintainer,

I prepared an NMU to fix this issue, as it's blocking the migration of
pygments to testing.

I uploaded to DELAYED/5. Please cancel it or tell me to cancel it if
you'd rather fix the issue yourself.

Paul
diff --git a/debian/changelog b/debian/changelog
index 4c6bd9e..b2cd026 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+djangorestframework (3.12.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * tests: update for newer pygments (Closes: #1005779)
+
+ -- Paul Gevers   Sun, 13 Mar 2022 19:19:52 +0100
+
 djangorestframework (3.12.4-2) unstable; urgency=medium
 
   * debian/rules
diff --git a/debian/patches/series b/debian/patches/series
index 67355cd..0a97bd1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0002-Clean-all-privacy-breaches-in-the-package.patch
 0002-Fix-asset-names-to-match-symlinks-to-packaged-files.patch
 0003-Fix-tests-with-mock-timezone-7911.patch
+tests-update-for-newer-pygments.patch
diff --git a/debian/patches/tests-update-for-newer-pygments.patch 
b/debian/patches/tests-update-for-newer-pygments.patch
new file mode 100644
index 000..b55900e
--- /dev/null
+++ b/debian/patches/tests-update-for-newer-pygments.patch
@@ -0,0 +1,38 @@
+From: Paul Gevers 
+Date: Sun, 13 Mar 2022 17:12:30 +0100
+X-Dgit-Generated: 3.12.4-2.1 3e10ec7e98630c1f46952ca1d9b26237187c6c52
+Subject: tests: update for newer pygments
+
+Closes: #1005779
+
+---
+
+--- djangorestframework-3.12.4.orig/tests/test_description.py
 djangorestframework-3.12.4/tests/test_description.py
+@@ -45,12 +45,20 @@ MARKDOWN_BASE = """hash style header%s"""
+ 
+ MARKDOWN_gte_33 = """
+-[{\
+-alpha:\
+- 1,\
+-beta: this\
+- is a \
+-string}]\
++[{\
++\
++alpha:\
++ \
++1,\
++\
++beta: \
++this\
++ is\
++ a\
++ \
++stri\
++ng\
++}]\
+ 
+ """
+ 

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 17:07:19 +0100, d...@darkboxed.org wrote:

> On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> > Printing via a GTK destination to an IPP printer has never worked for
> > me. Even if printer information could be obtained, a Cairo-produced PDF
> > would go to the printer and PDF is not a PDL understood by it. In what
> > circumstances does such a destination work?
> 
> Believe it or not, some printers will actually accept straight up PDFs
> being piped into them without a PDL wrapper.

Hello Daniel,

I am unfamiliar with the term "PDL wrapper". Your input would be
welcome to clarify this.

I fully accept that a PDF sent *directly* to a printer with a PDF
interpreter should be printed. Are you saying the GTK dialog is
using this technique? Is this from obervation with your IPP printer?

Regards,

Brian.

Bug#974220: libreoffice-writer: Double paste in Writer

[João Luis Meloni Assirati]

I recently upgraded a system from debian 10 to 11 and stumbled on this
bug.  I purged all packages that remained in state rc from the
previous debian version and this solved the problem.

JLMA.

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Guillem Jover]

Hi!

Thanks for the updated patches! I've gone over these and merged
several of them, the others I've left out for now, as I wanted to
get the current release out, which has been dragging for too long
already while I was finalizing it.

On Sun, 2022-02-13 at 18:38:19 +0100, Nicolas Boulenguez wrote:

> >From 5852b310ea8cdd519a0f7d6e1099c3c54db026ed Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Mon, 29 Jul 2019 14:38:32 +0200
> Subject: [PATCH 01/10] scripts/mk: stop hard-coding dpkg_datadir
> 
> The Makefile snippets include each other from their common directory,
> but the path differ during tests and after installation.  Instead of
> rewriting the file with a hardcoded path, compute it within Make.

Ah, nice, I think I like the dynamically computed path, yes. Although
to avoid changing all pathname concatenation I changed dpkg_datadir to
«$(patsubst %/,%,$(dir $(lastword $(MAKEFILE_LIST». But given that
I think we might still need to substitute other things I've left this
one out for now.

> >From 94c84d34ff28d81f2fceef797fa8314d7b03fb23 Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 11 Feb 2021 15:36:15 +0100
> Subject: [PATCH 02/10] scripts/t: test SOURCE_DATE_EPOCH
> 
> Set SOURCE_DATE_EPOCH either from the environment or the Debian changelog.
> Check that the value is (re)exported.

Merged. Changed from calling date(1) into hardcoding the timestamp
though.

> >From 32c2fad6ef96479afcffc38b40f8b2e82d3c46c4 Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 11 Feb 2021 15:45:03 +0100
> Subject: [PATCH 03/10] scripts/t: slightly optimize hash traversals
> 
> Iterate on key/value pairs instead of iterating on keys then search
> for each value.

Merged. Changed the tools variable names as they were originally not a
very good fit.

> >From cb0d31dc92f61144150ad2b042a01987540e0ddf Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 11 Feb 2021 16:09:48 +0100
> Subject: [PATCH 04/10] scripts/t: use loops instead of repetitions, check
>  exports and overrides
> 
> Replace copied lines with Make loops.
> 
> Add tests: architecture variable override, buildflags set and export,
> buildtool override and export.

I've left this one out for now.

> >From d27c9abc9d88a76c98597ee872adefd7c2dedd6a Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 11 Feb 2021 16:34:23 +0100
> Subject: [PATCH 05/10] scripts/buildtools.mk: remove unneeded conditionals
> 
> The ?= had no effect when the previous test was succeeding.  Make that
> explicit with an 'else'.
> 
> The 'ifdef' was always succeeding because previous stanza sets $1.

Merged.

> >From 26df5b04bb981bf9f1a23bf2341f5de1854e5daa Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Sat, 13 Feb 2021 09:58:27 +0100
> Subject: [PATCH 06/10] scripts/buildtools.mk: indent for readability

Merged.

> >From cb1a48beaa613b7f55dee0842afbd5ba51495b74 Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Mon, 1 Nov 2021 10:08:08 +0100
> Subject: [PATCH 07/10] scripts/mk/buildopts.mk: small optimisations
> 
> Assign DEB_BUILD_OPTION_PARALLEL with := so that the value is computed
> only once instead of every time the variable is used.
> The maintainer is not supposed to modify DEB_BUILD_OPTIONS.
> 
> Always define DEB_BUILD_OPTION_PARALLEL, even if empty when
> DEB_BUILD_OPTIONS does not contain parallel=%.
> The distinction between DEB_BUILD_OPTIONS= and
> DEB_BUILD_OPTIONS=parallel= does probably not deserve a test.

I've left this one out as it is kind of an API change. I think it
might perhaps make more sense to fallback to setting it to 1 if it's
missing, but I need to ponder about possible consequences/fallout, etc.

> >From 4d63491c8dc9c6df85f0472d00f34c82e91ec05e Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 11 Feb 2021 16:26:50 +0100
> Subject: [PATCH 08/10] scripts/mk: reduce the number of subprocesses
> 
> architecture.mk and buildflags.mk spawn less subshells, improving the
> overall speed (the tests run twice faster according to bash time
> builtin).
> 
> pkg-info.mk uses the same trick than buildflags.mk in order to spawn
> at most one subshell. The performance gain is visible, but minor
> because there are way less variables.

I've left this one out for now. I'm not entirely satisfied with the
sed usage here. If we keep using sed, then I think it needs to be set
via a SED variable, substituted from the value found at configure
time. But then, I've been pondering whether we can have better export
formats, that might make the sed usage not necessary. I started with a
make-eval export mode for buildflags, but perhaps it would be better a
more generic formatting mode where the caller can specify how the
output should look like, akin «dpkg-query --showformat». Will ponder
about this.

> >From c92fd3aac8703475913db041c0bea53221757b5f Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Sun, 13 Feb 2022 14:17:20 +0100
> Subject: [PATCH 09/10] 

Bug#1007213: please upgrade to Xpra 4

[Thomas Koch]

Package: xpra
Version: 3.0.13+dfsg1-1
Severity: normal
X-Debbugs-Cc: tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The Debian Xpra package is very slow on my machine. So I checked whether it is
the last version.

Is there any reason beside lack of time why the Debian version has not yet
upgraded to version 4? The debian/watch file explicitly only checks for
versions starting with "3".

Do you need help with the package?

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIuLOsACgkQB/xIkQQr
plqqIxAAhr1JyB/xv1j1VyRGmSEJaPY14NXdfTwHqrJWJSI9+W7Ks4+vU577UTkq
zal8qVyFPY29anULMhi/3OvIP7pPQUMNUH2xkxBUyfaQYPXigRR4/vvcjka6IFBm
XrhSkQNKApUW2emwUm6dRQm0qWeRQqwfrn0VPVNHeXXaUViX5RnbESYVgbic9dsx
Is8AZRgW1hj/I/emwgKaaDWRR2PsQOTUphM0o/8J52bbZzEnMlZFt17mbt5y1628
5zzLoOqql4nPBG4Mh21V515ER+Gm69KoM9VdZTrmyCkWaQlBsPGCXfaOFqj2yFhz
JzcH5irRZjEizMDqJipmpZE4DoX+RVqBBspfosHuj1ZlYox9GmAEwdtntkYqwhvL
1NxloP0mrf8DsoD7PdeJPyrUCCsDYLdTCMMtzvCY0zEw9GZ5SpzS/lGomtgPSV84
uKMsur/N7zQF0BT36Ub94efSKPVCeTVzALGLHWrVk3N/tSpl3Y8+/J7LtToPgrA3
L8KrKcFPKQITfntByMOvCKQIeu35+b8IWTHswXTtbWCeqG/L6nNs4yz/5kvMKJsm
Ps6QpmVxnoODq/ovU9XfrraamCkIID2gMv49kj8i/i3YRYo3JBKkCKDPAfY7svMN
SwtpkdyitiuZpo67G5iXTKd020a2qiQArmLnFDLDfWzOSdylL34=
=HITa
-END PGP SIGNATURE-

Bug#1007210: [Pkg-javascript-devel] Bug#1007210: node-deep-equal has circular Depends on node-es-abstract

[Yadd]

On 13/03/2022 17:22, Bill Allombert wrote:

Package: node-deep-equal
Version: 2.0.5+~cs32.11.68-2
Severity: important

Hello Debian Javascript Maintainers,

There is a circular dependency between node-deep-equal and node-es-abstract:

node-deep-equal :Depends: node-es-abstract
node-es-abstract:Depends: node-deep-equal

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,


Hi,

this is a test dependency, library can be built with "nocheck" without 
any nodejs dependency except nodejs itself (via pkg-js-tools).
There are many circular dependencies in node-* packages when building 
with test.


To avoid this, we can move test dependencies into 
debian/tests/autopkgtest-pkg-nodejs.conf and add an empty 
override_dh_auto_test.


I'm going to do that here.

Bug#1004982: lazarus-src-2.2: Unable to remove the package under ru_RU.UTF-8 locale

[Abou Al Montacir]

Hi Alexander,

Thank you reporting this issue.
> Note that "diversion of" is translated as "отклонение", with different amount
> of spaces. So, postrm script uses wrong field as a filename.
The script should enforce LANG=C when running such a command. I'll try to
prepare a patch for that.

Can you please check that hte following commands work correctly?
DIVERTIONS_LIST=`LANG=C dpkg-divert --list "/usr/lib/lazarus/2.2.0/*" | cut -d 
' ' -f 3`
echo ${DIVERTIONS_LIST}

If this is OK, please let me know so I can upload a fix.
-- 
Cheers,
Abou Al Montacir


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

Bug#1006171: Make internal-sftp the default

[dirdi]

I understand and support Colin's stance that the default configuration 
shipped with Debian should follow upstream.


The nasty thing about subsystem directives is that they cannot be 
overridden by a .conf file placed inside the /etc/ssh/sshd_config.d/ 
folder, due to this bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998834


So if one wants to use e.g. the internal sftp server, one MUST modify 
the /etc/ssh/sshd_config file. This in turn interferes with automatic 
upgrade scripts like cron-apt, unattended-upgrades etc.


I thought about moving the subsystem directive into a new file inside 
the /etc/ssh/sshd_config.d/ folder. However, this would result in broken 
configurations on machines where the administrator keeps a modified 
/etc/ssh/sshd_config file during an upgrade.

Bug#1007116: dpkg: po: Update Swedish translation

[Guillem Jover]

Hi!

On Fri, 2022-03-11 at 14:20:51 +0100, Peter Krefting wrote:
> Package: dpkg
> Severity: wishlist
> Tags: l10n patch

> I have now completed my update of the Swedish translation of the stable dpkg
> version (bookworm branch). Both the patch from #1003799 (which I could not
> see in the git.dpkg.org repository) and an update of the manual pages
> translation can be downloaded from this repository:
> 
>   - git fetch https://github.com/nafmo/dpkg-l10n-sv.git bullseye
>   - https://github.com/nafmo/dpkg-l10n-sv/tree/bullseye

Thanks, I've merged this into the 1.20.x (bullseye) branch. And
merged the changes also into the current main branch where the changes
for sid are cooking. I fixed a couple of markup typos that made the
build fail, so you might want to rebase on top of that. :)

> Once this has been integrated, I can start translation of the unstable
> branch, please let me know when and where to find that.

That'd be the «main» branch.

Thanks,
Guillem

Bug#1007207: budgie-control-center has circular Depends on budgie-desktop

[Bill Allombert]

On Sun, Mar 13, 2022 at 04:33:54PM +, David Mohammed wrote:
> Hi Bill,
> 
> If I make budgie-desktop recommend budgie-control-center rather than a
> depends, will the package manager be a little happier?

Hi David,

Yes this is fine, since Recommends are not mandatory.
However, I would probably do the converse instead
(budgie-control-center Recommends budgie-desktop)
since budgie-desktop is a meta-package.

Cheers,
Bill

Bug#1007149: texmaker 5.1.2+dfsg-1 has file that is also in texmaker-data

[Nicolas Haller]

Package: texmaker
Followup-For: Bug #1007149

Dear Maintainer,

I can confirm the bug while trying to upgrade texmaker.
As you'll see below, texmaker-data is already upgraded to 5.1.2.

For what I see, texmaker 5.0.3 was providing /usr/share/pixmaps/texmaker.xpm.
texmaker 5.1.2 has replaced that by the png version, which is also distributed 
by texmaker-data.

nicolas@bunker:~%sudo apt --fix-broken install texmaker-data texmaker
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
texmaker-data is already the newest version (5.1.2+dfsg-1).
texmaker-data set to manually installed.
The following packages were automatically installed and are no longer required:
  libgeos3.10.1 libgnutls-dane0 libllvm11 libofa0 libperl5.32 libunbound8 
libwireplumber-0.4-0 linux-compiler-gcc-10-x86 linux-kbuild-5.14 
perl-modules-5.32 postgresql-13 postgresql-client-13
Use 'sudo apt autoremove' to remove them.
Suggested packages:
  texlive-lang-all
The following packages will be upgraded:
  texmaker
1 upgraded, 0 newly installed, 0 to remove and 255 not upgraded.
1 not fully installed or removed.
Need to get 0 B/4,440 kB of archives.
After this operation, 476 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 363626 files and directories currently installed.)
Preparing to unpack .../texmaker_5.1.2+dfsg-1_amd64.deb ...
Unpacking texmaker (5.1.2+dfsg-1) over (5.0.3-1+b4) ...
dpkg: error processing archive 
/var/cache/apt/archives/texmaker_5.1.2+dfsg-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/pixmaps/texmaker.png', which is also in 
package texmaker-data 5.1.2+dfsg-1
Errors were encountered while processing:
 /var/cache/apt/archives/texmaker_5.1.2+dfsg-1_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)



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

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

Versions of packages texmaker depends on:
ii  libc6 2.33-7
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-15
ii  libqt5gui55.15.2+dfsg-15
ii  libqt5network55.15.2+dfsg-15
ii  libqt5printsupport5   5.15.2+dfsg-15
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-15
ii  libqt5xml55.15.2+dfsg-15
ii  libstdc++612-20220302-1
ii  libsynctex2   2021.20210626.59705-1
iu  texmaker-data 5.1.2+dfsg-1

Versions of packages texmaker recommends:
ii  aspell0.60.8-4
ii  asymptote 2.70+ds-2+b1
ii  ghostscript   9.55.0~dfsg-3
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
pn  latex-beamer  
ii  netpbm2:10.0-15.4
ii  psutils   1.17.dfsg-4
ii  texlive-lang-english  2021.20220204-1
ii  texlive-latex-extra   2021.20220204-1

Versions of packages texmaker suggests:
pn  texlive-lang-all  

-- no debconf information

Bug#1007207: budgie-control-center has circular Depends on budgie-desktop

[David Mohammed]

Hi Bill,

If I make budgie-desktop recommend budgie-control-center rather than a
depends, will the package manager be a little happier?

David

On Sun, 13 Mar 2022, 16:18 Bill Allombert,  wrote:

> Package: budgie-control-center
> Version: 1.0.0-1
> Severity: important
>
> Hello David,
>
> There is a circular dependency between budgie-control-center and
> budgie-desktop:
>
> budgie-control-center   :Depends: budgie-desktop
> budgie-desktop  :Depends: budgie-control-center
>
> Circular dependencies involving shared libraries are known to cause
> problems
> during upgrade between stable releases, so we should try to avoid them.
>
> Cheers,
> --
> Bill. 
>
> Imagine a large red swirl here.
>

Bug#1007212: python3-defcon: multiple circular dependencies

[Bill Allombert]

Package: python3-defcon
Version: 0.9.0-1
Severity: important

Hello Debian Fonts Task Force,

There is a circular dependency between python3-defcon, python3-fonttools and 
python3-ufolib2:

python3-defcon  :Depends: python3-fonttools (>= 4.26.2)
python3-fonttools   :Depends: python3-ufolib2 (>= 0.12.1), python3-defcon 
(>= 0.6.0)
python3-ufolib2 :Depends: python3-fonttools (>= 4.29.1)

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007211: libmlt++7 has circular Depends on libmlt7

[Bill Allombert]

Package: libmlt++7
Version: 7.4.0-1
Severity: important

Hello Patrick,

There is a circular dependency between libmlt++7 and libmlt7:

libmlt++7   :Depends: libmlt7 (>= 7.4.0)
libmlt7 :Depends: libmlt++7 (>= 7.4.0)

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007210: node-deep-equal has circular Depends on node-es-abstract

[Bill Allombert]

Package: node-deep-equal
Version: 2.0.5+~cs32.11.68-2
Severity: important

Hello Debian Javascript Maintainers,

There is a circular dependency between node-deep-equal and node-es-abstract:

node-deep-equal :Depends: node-es-abstract
node-es-abstract:Depends: node-deep-equal

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007209: php-symfony-messenger: multiple circular dependencies

[Bill Allombert]

Package: php-symfony-messenger
Version: 5.4.6+dfsg-1
Severity: important

Hello Debian PHP PEAR Maintainers,

There is a circular dependency between php-symfony-amqp-messenger, 
php-symfony-doctrine-messenger, php-symfony-messenger and 
php-symfony-redis-messenger:

php-symfony-amqp-messenger  :Depends: php-symfony-messenger
php-symfony-doctrine-messenger  :Depends: php-symfony-messenger
php-symfony-messenger   :Depends: php-symfony-amqp-messenger, 
php-symfony-doctrine-messenger, php-symfony-redis-messenger
php-symfony-redis-messenger :Depends: php-symfony-messenger

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007208: libdart-external-convhull-3d-dev has circular Depends on libdart-dev

[Bill Allombert]

Package: libdart-external-convhull-3d-dev
Version: 6.12.1+dfsg4-11
Severity: important

Hello Debian Science Maintainers,

There is a circular dependency between libdart-external-convhull-3d-dev and 
libdart-dev:

libdart-external-convhull-3d-dev:Depends: libdart-dev
libdart-dev :Depends: libdart-external-convhull-3d-dev

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007207: budgie-control-center has circular Depends on budgie-desktop

[Bill Allombert]

Package: budgie-control-center
Version: 1.0.0-1
Severity: important

Hello David,

There is a circular dependency between budgie-control-center and budgie-desktop:

budgie-control-center   :Depends: budgie-desktop
budgie-desktop  :Depends: budgie-control-center

Circular dependencies involving shared libraries are known to cause problems
during upgrade between stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1007206: After moving page, wrong page is selected

[martin f krafft]

Package: gscan2pdf
Version: 2.12.5-1
Severity: minor

If I move a page with drag-drop, gscan2pdf then selects the page 
that "falls into place" at the source location, rather than keeping 
the page that is being moved selected.

Example:

Imagine the following sequence of pages, wherein [x] is used to 
denote the selected one: 1 2 [3] 4. If I move page 3 before page 2, 
I get 1 3 2 [4], but I'd expect 1 [3] 2 4. It's quite confusing to 
regain the bearing, especially when a page is being moved mroe than 
10 pages forward or backwards, and scroll comes into play.

Thanks for your consideration,

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1.3+b2
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.3+b2
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b7
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 10-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.76-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1.3
ii  libimage-sane-perl 5-1+b2
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.70-1
ii  liblocale-gettext-perl 1.07-4+b2
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b10
ii  libpdf-builder-perl3.023-1
ii  libproc-processtable-perl  0.634-1+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.52.5+dfsg-3+b1
ii  libset-intspan-perl1.19-2
ii  libtiff-tools  4.3.0-5
ii  libtry-tiny-perl   0.31-1
ii  sane-utils 1.1.1-4

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-2
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4.1

gscan2pdf suggests no packages.

-- no debconf information


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

Bug#982925: libgtk: print dialog lists autodetected printer twice

[dxld]

On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> Printing via a GTK destination to an IPP printer has never worked for
> me. Even if printer information could be obtained, a Cairo-produced PDF
> would go to the printer and PDF is not a PDL understood by it. In what
> circumstances does such a destination work?

Believe it or not, some printers will actually accept straight up PDFs
being piped into them without a PDL wrapper.

--Daniel


signature.asc
Description: PGP signature

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

> Hi Brian and Simon,
> 
> On Sat, Mar 12, 2022 at 08:56:38PM +, Brian Potkin wrote:
> > You have just confirmed that the printing system (CUPS + cups-filters
> > + (optionally) cups-browsed) works effieiently and as designed.
> > 
> > > Resultion: printing is still hell on earth :]
> > 
> > libgtk is not part of the printing system; 
> 
> Erm, sorry but it is part of the printing experience from a user's POV.

True.
 
> I wasn't trying to imply cups is the problem in fact if you read the
> backlog much of my frustration is with libgtk, but hell at least I'm here
> proposing patches so I feel I get to poke som fun at it. No offence
> intended Simon :)
> 
> Besides in the end it turned out libgtk with the right patch does work so
> *shrug*.

Having the GTK dialog on bullseye as a good citizen would be gratifying.
 
> > > - Printing via libgtk's fallback entry always fails
> > 
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> > On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
> > little wonder users (like the bug submitter) experience consternation.
> 
> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

I cannot provide code but can supply information. Perhaps there is some
enlightenment at

  https://bugzilla.gnome.org/show_bug.cgi?id=688956

This is what began the process. Comments 5 and 6 look interesting.

Printing via a GTK destination to an IPP printer has never worked for
me. Even if printer information could be obtained, a Cairo-produced PDF
would go to the printer and PDF is not a PDL understood by it. In what
circumstances does such a destination work?

Regards,

Brian.

Bug#980284: Update from original submitter

[Martin King]

Hello,

I just re-visited this bug. In my current kernel;

linux-image 5.10.0-11-amd64, 5.10.92-1

the problem is fixed. Receiving timeout restored to previous working 
value, no duplication of key presses. I don't know when this change 
occurred. My reason for submitting bug has been resolved, although I see 
it is not shown as "Fixed".

Bug#1007205: Please consider (re)including my start-stop-daemon.runit script

[Andras Korn]

Package: runit
Version: 2.1.2-45
Severity: wishlist

Hi,

Back in 2012 I sent Gerrit a start-stop-daemon.runit script (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678985) that could be used
as a drop-in replacement for the real start-stop-daemon. It's a fairly
feature complete wrapper around the real start-stop-daemon that manages
runit services if they are present and passes calls to the real
start-stop-daemon if they are not.

I dpkg-divert /sbin/start-stop-daemon to /sbin/start-stop-daemon.real on all
my systems and install this script as /sbin/start-stop-daemon.

This way, initscript work transparently whether a service is managed by
runit or not. Without this script, care must be taken to avoid the real
start-stop-daemon starting daemons like e.g. ntpd or smartd alongside a
runit-managed instance.

The script used to be included in runit under /usr/share/doc until Dmitry
removed in 2016 because it was "unused".

I think it can be useful even if the package doesn't use it explicitly, but
a case could be made for runit to perform this diversion on install and ship
my script as /sbin/start-stop-daemon.

The only drawback (that I can see) is that this would introduce a dependency
on zsh, because that's what I wrote the script in. Maybe Suggests: zsh, make
installing my script both optional and contingent on zsh being present? (Of
course, people could still shoot themselves in the foot by removing zsh
afterwards. Can dpkg run a trigger when zsh is uninstalled?)

I'm attaching the current version of the script, which contains some
improvements over the 2012 version.

András

-- 
  Government corruption is always reported in the past tense.
#!/bin/zsh
#
# This script is intended to wrap start-stop-daemon. It will call the
# original start-stop-daemon with the supplied arguments unless the daemon
# to be started appears to exist as a runit service, in which case it will
# map the start-stop-daemon call to an sv(8) call.
#
# Copyright 2012-2022 András Korn.
#
# Licensed under the GPL v3, or, at your option, under the same license as
# the runit package.

# If called by non-root user, fall back to original start-stop-daemon
# unconditionally
[[ $UID -gt 0 ]] && exec /sbin/start-stop-daemon.real $@

set -A args $@

SVDIR=${SVDIR:-/etc/service}

unset mode signal exec timeout startas testmode oknodo quiet verbose command 
svstat candidates
oknodo=0
quiet=0

typeset -U candidates

while [[ -n "$1" ]]; do
case "$1" in
-S|--start) mode=start;;
-K|--stop)  mode=stop;;
-T|--status)mode=status;;
-H|--help|-V|--version) exec /sbin/start-stop-daemon.real 
$args;;
-x|--exec)  shift; exec="$1";   
candidates=($candidates ${1:t});;
-s|--signal)shift; signal=$1;;
--signal=*) signal="${1/--signal=/}";;
-R|--retry) shift; timeout="$1";;
--retry=*)  timeout="${1/--retry=/}";;
-a|--startas)   shift; startas="$1" 
candidates=($acndidates ${1:t});;
-t|--test)  testmode=1;;
-o|--oknodo)oknodo=1;;
-q|--quiet) quiet=1; exec >/dev/null;;
-v|--verbose)   verbose=1;;
-m|--make-pidfile)  make_pidfile=1;;
--remove-pidfile)   remove_pidfile=1;;
-n|--name)  shift;  
candidates=($candidates $1);;
-p|--pidfile)   shift; pidfile="$1";
candidates=($candidates ${1:t:r});;
--pidfile=*)pidfile="${1#--pidfile=}";  
candidates=($candidates ${1:t:r});;

-u|--user|-g|--group|--pid|--ppid|-c|--chuid|-r|--chroot|-d|--chdir|-O|--output|-N|--nicelevel|-P|--procsched|-I|--iosched|-k|--umask)
 shift;; # ignored

-b|--background|--nicelevel=*|--procsched=*|--iosched=*|--umask=*|-C|--no-close)
:;; # ignored
--notify-wait)  echo "Warning: this version of 
start-stop-daemon.runit ignores --notify-wait." >&2;;
--notify-timeout)   echo "Warning: this version of 
start-stop-daemon.runit ignores --notify-timeout." >&2;;
--) break;; # What follows is args to the 
daemon. Avoid parsing those accidentally.
*)  command="$1"; break;; # Assume the 
previous was the last option; the rest is the name of the daemon plus args, of 
which we only care about the daemon.
esac
shift
done

# returns success if $1 appears to be the name of a runit service
function issvname() {
[[ -d "$SVDIR/$1/supervise/." ]] && return 0
# 'supervise' could still be a symlink to a directory that doesn't 
exist yet
[[ -L 

Bug#1006333: Relaxed fix in expat for CVE-2022-25236 released

[Salvatore Bonaccorso]

Hi all,

An update for expat (landed in unstable earlier) and now as DSA 5085-2
for buster and bullseye as well is released which relaxes the fix for
CVE-2022-25236 with regard to RFC 3986 URI characters.

So there is no immediate action for updating the affected packages
from regressions ins buster and bulleye. For unstable (and bookworm)
given the API docs of function XML_ParserCreateNS do advise against
using URI characters in namespace searators and expat might be
stricter in future about their use, it's still recomended to address
these isses (I see biboumi in fact did already in #1006333, thanks
Jonas, Slavko and Diane).

Regards,
Salvatore

Bug#1007204: /usr/bin/make-kpkg: Please add riscv architecture

[Rémi Denis-Courmont]

Package: kernel-package
Version: 13.018+nmu2
Severity: wishlist
File: /usr/bin/make-kpkg

Dear Maintainer,

At this time, make-kpkg refuses to (cross-)build RISC-V kernel images:

debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel 
image goes to [kimagedest undefined] The usual case for this is that I could 
not determine which arch or subarch this machine belongs to. Please specify a 
subarch, and try again..

Though this is not currently an officially supported Debian architecture,
please consider adding the necessary platform support.

Br,

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kernel-package depends on:
ii  bc   1.07.1-3+b1
ii  binutils 2.38-2
ii  build-essential  12.9
ii  bzip21.0.8-5
ii  dpkg-dev 1.21.1
ii  file 1:5.41-2
ii  gettext  0.21-4
ii  kmod 29-1
ii  po-debconf   1.0.21+nmu1
ii  xmlto0.0.28-2.1
ii  xz-utils [lzma]  5.2.5-2

Versions of packages kernel-package recommends:
ii  cpio   2.13+dfsg-7
pn  docbook-utils  
pn  kernel-common  
pn  uboot-mkimage  

Versions of packages kernel-package suggests:
ii  libncurses-dev  6.3-2
pn  linux-source

-- Configuration Files:
/etc/kernel-pkg.conf changed [not included]

-- no debconf information

Bug#1007203: php-symfony-polyfill: Package FTBFS with libicu70

[Athos Ribeiro]

Package: php-symfony-polyfill
Severity: normal

Dear Maintainer,

As per [1], the Q and q quarter patterns are supposed to convert
quarter into numbers (1, 2, 3, or 4). Until vertion 70.1, ICU carried a
bug [2] which would make those patterns to convert into the wrong string,
mimicking the behavior of the  pattern. The issue has been fixed
upstream [3] and released in ICU 70.1.

Currently, php-symfony-polyfill will FTBFS if built with a version of
php-intl linked against libicu70 because the upstream test suite relies
on libicu's buggy behavior.

I submitted [4] to fix the issue upstream and filed a salsa MR to apply
the proposed patch in Debian [5].

[1] 
https://unicode-org.github.io/icu/userguide/format_parse/datetime/#date-field-symbol-table
[2] https://unicode-org.atlassian.net/browse/ICU-21647
[3] 
https://github.com/unicode-org/icu/commit/dcfdaca46c1e3cc08764ad1d85f321ad0c27ae16
[4] https://github.com/symfony/polyfill/pull/399
[5] 
https://salsa.debian.org/php-team/pear/php-symfony-polyfill/-/merge_requests/1

-- 
Athos Ribeiro

Bug#1007141: BUG Report - OCFS2 Hangs when mount volume in second node

[Valentin Vidic]

On Fri, Mar 11, 2022 at 06:45:32PM -0300, Dayvison wrote:
> Package: ocfs2-tools
> Version: 8.7.1 and 8.6.6
> 
> Hi, I'm sending this email to report a problem:
> 
> OCFS2 filesystem with more than 1 node is not working with Debian 11
> with 5.13, 5.15 and newer kernels.
> 
> OK, what's the problem behavior? Answer: When you mount ocfs2 on the
> second node with the "mount" command, the second node is stuck and
> unresponsive at the prompt, when viewing /var/log/syslog, there are
> several error messages in /var/log/syslog and no mounting the ocfs
> volume on the second node.

Thanks for the report, I will try to reproduce the problem with the
versions in unstable, but it would be good if you could share the errors
that are being reported and perhaps also the cluster configuration for
reproducing this problem.

Also I assume you mean ocfs2-tools versions 1.8.6-6 and 1.8.7-1 that
are available in stable and testing, since the versions you listed 
(8.7.1 and 8.6.6) do not exist in Debian?

-- 
Valentin

Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices

[Domenico Andreoli]

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

* Package name: solo1
  Version : 0.1.1
  Upstream Author : he...@solokeys.com
* URL : https://github.com/solokeys/solo1-cli
* License : Apache 2.0 and MIT
  Programming Lang: Python
  Description : Python module and CLI for SoloKeys Solo 1 devices

With this package you get a command-line interface to manage your
SoloKeys and a Python module to interface them with your applications.

Some of the operations you can do:

- set or change the PIN
- read the firmware version
- update the firmware
- wipe all your credentials
- verify whether your device is a Solo Secure or Solo Hacker

Bug#1007201: RM: shovill [alpha arm64 armel armhf hppa i386 ia64 m68k ppc64 ppc64el risc64 sh4 sparc64 x32] -- ROM; Please remove for certain architectures

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Nilesh Patra 

Hi,

due to some accident in packaging for shovill version 1.1.0-7 was done
for several architectures.  However, this package has dependencies that
are only available on amd64 and thus should be built only on this
architecture.  Thus please remove shovill on all architectures except
amd64.

Sorry for this trouble and thanks a lot for your patience as ftpmaster

 Andreas.

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Ana Guerrero Lopez]

On Sat, Oct 09, 2021 at 04:43:37PM +0200, Guillem Jover wrote:
> 
> I think the attached patch is the correct fix. I think I can push to
> the repo, so if no one has any concerns I might do that during the
> weekend.

Thanks Guillem!
The issue seems fixed now, I'm closing this bug.

Ana

Bug#1007200: pytorch: FTBFS with glog 0.6.0+

[GCS]

Source: pytorch
Version: 1.8.1-4
Severity: normal
Tags: ftbfs sid patch

Hi,

I've already uploaded the new google-glog 0.6.0 release candidate
version to experimental. It makes IsGoogleLoggingInitialized() a
public function. Your package needs to be updated to use it instead of
its hack. Patch is attached.
Please test your package and report back. I would like to start the
transition soon, but not break your package.

Regards,
Laszlo/GCS
Description: move IsGoogleLoggingInitialized() to public API
 It was an internal function and project used hacks to reach it. Now it's part
 of the public API.
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-03-08

---

--- pytorch-1.8.1.orig/c10/util/Logging.cpp
+++ pytorch-1.8.1/c10/util/Logging.cpp
@@ -170,23 +170,13 @@ C10_DEFINE_int(
 google::GLOG_WARNING,
 "The minimum log level that caffe2 will output.");
 
-// Google glog's api does not have an external function that allows one to check
-// if glog is initialized or not. It does have an internal function - so we are
-// declaring it here. This is a hack but has been used by a bunch of others too
-// (e.g. Torch).
-namespace google {
-namespace glog_internal_namespace_ {
-bool IsGoogleLoggingInitialized();
-} // namespace glog_internal_namespace_
-} // namespace google
-
 namespace c10 {
 bool InitCaffeLogging(int* argc, char** argv) {
   if (*argc == 0)
 return true;
 #if !defined(_MSC_VER)
   // This trick can only be used on UNIX platforms
-  if (!::google::glog_internal_namespace_::IsGoogleLoggingInitialized())
+  if (!::google::IsGoogleLoggingInitialized())
 #endif
   {
 ::google::InitGoogleLogging(argv[0]);

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Daniel Gröber]

Hi Brian and Simon,

On Sat, Mar 12, 2022 at 08:56:38PM +, Brian Potkin wrote:
> You have just confirmed that the printing system (CUPS + cups-filters
> + (optionally) cups-browsed) works effieiently and as designed.
> 
> > Resultion: printing is still hell on earth :]
> 
> libgtk is not part of the printing system; 

Erm, sorry but it is part of the printing experience from a user's POV.

I wasn't trying to imply cups is the problem in fact if you read the
backlog much of my frustration is with libgtk, but hell at least I'm here
proposing patches so I feel I get to poke som fun at it. No offence
intended Simon :)

Besides in the end it turned out libgtk with the right patch does work so
*shrug*.

> > - Printing via libgtk's fallback entry always fails
> 
> I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> needed when the printing system does the jobi, as you have demonstrated?
> On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
> little wonder users (like the bug submitter) experience consternation.

Here I also don't quite understand libgtk upstream. I assume the intention
for the fallback is to have printing to at least work with some printers
when cups isn't running/installed. While I think that's a terrible idea we
still didn't want to break that behaviour since some users might now be
depending on it.

--Daniel


signature.asc
Description: PGP signature

Bug#1007199: ipxe: fails to boot on Geode LX

[Martin-Éric Racine]

Package: ipxe
Version: 1.0.0+git-20190125.36a4c85-5.1
Severity: important

The version of iPXE currently in Bookworm fails to launch on a Geode LX host. 
The screen remains blank for ages. The binary seemingly freezes the host. 
Pressing the power button has no effect. The power cord must be pulled out for 
the host to recover and be bootable again.

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

Kernel: Linux 5.16.0-4-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#985047: ipxe: New upstream release v1.21.1 available

[Martin-Éric Racine]

Package: ipxe
Version: 1.0.0+git-20190125.36a4c85-5.1
Followup-For: Bug #985047

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howdy!

I'm just wondering if there's any ETA on iPXE 1.21.1 packaging?

FWIW, there's also been plenty of activity on the upstream Git even after that 
was released on Dec.31 2020.  The most recent commits are dated from Feb.2022.

Cheers!
Martin-Éric

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

Kernel: Linux 5.16.0-4-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIt8FIACgkQrh+Cd8S0
17ZWfQ/+Mdtc5EFRPUDa25z8uX8QmcGTNTJKLsbsoHb6nVMDA5h2/6F0r/0Jsc2S
4XTpTeuGQhUVX6tH1Xunh9tZwGuVkt/t32zpHIybi4WjjvVHoX6KZ6YUBWoDCM4x
wywcVZBlzHczzArpPssR/0D76teq01x8h57CsHkIGxE4/E3kDlGiZq3mAvQ/7J7K
GzKc1KMycouwrPODSMIbvcDQplSELZXpjFryYevrIWVoSq/n/jwInQw1lyqozuaW
z25x0gFVayW9zqwOXmyAqgDuYt8LHFt2SjdW4deQ3UR42hCof8LWjMDKF9XIxy6g
d6cLtsrAiGA9f7Xp6tQ9IcYhiBtsgJlaCgZZ70JXwJesmbIxveGeLPWPla4QFFAf
xP5C1dGLovpGEEO9GcslutptH8xdlFFJhGn0nzcmsYqeJhLGznD7rb/rZ+FaJoR/
lTExj6MT4SllyZ2mGmwTt2wC5kDHAjLmp/OdDGQhotDvfM+c9mO0Upueteb3s6DJ
c8TVL2s4s3WvU+9cL8DatrTAs2wlSpE18BpbFP8QGKLp9CisyuvxEkCY9kHbNXGK
T9Mrc581rTzPy8YJ7keseTHQQVZkkDkjOaKCEF655zkCIHlA9Xzn+hULS/n6gqmm
t7QvAWY6bcvVAAzL2GDgIybgiCt/9C8LrBPdo5ZKrH10s8cwaJc=
=nWLh
-END PGP SIGNATURE-

Bug#1006456: transition: openldap

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/openldap-2.5.html

On 2022-03-12 11:26:19 -0800, Ryan Tandy wrote:
> On Fri, Mar 11, 2022 at 10:15:31PM +0100, Sebastian Ramacher wrote:
> > Please go ahead
> 
> Thank you. openldap/2.5.11+dfsg-1 has just been accepted into unstable.
> 
> Should I bump the remaining autopkgtest issues to RC severity at this time?
> 
> Could you please update the ben file for the transition? The auto-generated
> one is not ideal. I think it should look something like:
> 
> is_affected = .build-depends ~ /\b(libldap(2)?\-dev|libslapi\-dev)\b/;
> is_bad = .depends ~ /\b(libldap\-2\.4\-2|libslapi\-2\.4\-2)\b/;
> is_good = .depends ~ /\b(libldap\-2\.5\-0|libslapi\-2\.5\-0)\b/;

The tracker is now available at
https://release.debian.org/transitions/html/openldap-2.5.html

Please take a look at golang-openldap. It's an arch: all package and
hardcodes a dependency on libldap-2.4-2

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1007198: ITP: librist -- Reliable Internet Stream Transport for reliable transmission of video over lossy networks

[Florian Ernst]

Package: wnpp
Severity: wishlist
Owner: Florian Ernst 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Multimedia Maintainers 


* Package name: librist
  Version : v0.2.6
  Upstream Author : VideoLAN and librist authors
* URL : https://code.videolan.org/rist/librist
* License : BSD 2-Clause "Simplified"
  Programming Lang: C (+ asm)
  Description : Reliable Internet Stream Transport for reliable 
transmission of video over lossy networks

Reliable Internet Stream Transport (RIST) is a transport protocol
designed for reliable transmission of video over lossy networks
(including the Internet) with low latency and high quality.
.
RIST is intended as a more reliable successor to Secure Reliable
Transport (SRT), and as an open alternative to proprietary commercial
options such as Zixi, VideoFlow, QVidium, and DVEO (Dozer).


The second paragraph also describes my motivation for packaging this,
with my newly-acquired SRT maintainer hat on. Further information about
RIST (and most of the description above) can be found at
, and
further language wrappers and application integration can be found at
.

FFmpeg as present in Bookworm or newer already allows building against
librist, hence a heads-up to the Debian Multimedia Maintainers. I will
send a patch for evaluating librist linking once the package hits the
archives.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1007197: Option to save to temporary file and invoke a postprocessor

[martin f krafft]

Package: gscan2pdf
Version: 2.12.4-1
Severity: wishlist

gscan2pdf covers the majority of my scan→file workflow, but I still 
generally need to postprocess the generated PDF files, be it the 
addition of watermarks, my preference for using the shell to put the 
file into the target directory, the need to assign tags to the file, 
or just attaching the scanned document to an email.

Right now, I save the file to a temporary path, which means I need 
to face the save-as dialog, ensure I am in a temporary directory, 
and hit save, and then invoke the postprocessing tool, or find the 
file on disk. Which is quite a lot of extra work that I don't really 
want to do.

gscan2pdf already allows me to invoke my email programme from the 
File menu. In the Preferences dialog, I can also specify 
user-defined tools to be invoked, either on the PNG files 
(accessible by menu), or on the PDF with the save-hook.

Would it be possible to generalise the "Email a PDF" functionality, 
such that I could provide a different command to be run, or ideally 
provide an additional menu item for each additional command I need 
to be able to access?

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.3
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b7
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 10-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.76-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1.3
ii  libimage-sane-perl 5-1+b2
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.69-1
ii  liblocale-gettext-perl 1.07-4+b2
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b10
ii  libpdf-builder-perl3.023-1
ii  libproc-processtable-perl  0.634-1+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.52.5+dfsg-3+b1
ii  libset-intspan-perl1.19-2
ii  libtiff-tools  4.3.0-3
ii  libtry-tiny-perl   0.31-1
ii  sane-utils 1.0.32-4

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-2
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4.1

gscan2pdf suggests no packages.

-- no debconf information


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

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sat 12 Mar 2022 at 23:35:25 +, Simon McVittie wrote:

> On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> 
> cups upstream's medium to long term plan seems to be that toolkits like
> GTK and Qt should browse for mDNS printers themselves, and cups-browsed
> will eventually disappear, so that the only print queues shown are the
> ones manually configured in cups and the ones auto-discovered by the
> toolkits' print dialogs:
> 
> The intention of CUPS upstream is that the application's print dialogs
> browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
> but it will take its time until all toolkit developers add the needed
> functionality, and programs using old toolkits or no toolkits at all,
> or the command line stay uncovered.
> — https://github.com/OpenPrinting/cups-filters

The github text is in /usr/share/doc/cups-filters/README.gz. Note that
it dates from the time of CUPS 1.6 when CUPS could not browse DND-SD
multicasts of CUPS servers and printers, and therefore would not make
queues and printers available locally. cups-browsed became essential
to do this. Without it, printing to a metwork queue would have been
tortuous, if not impossibel.
 
> In bullseye, cups-browsed is usually installed on desktop systems. The
> intention seems to be that the printers discovered by cups-browsed take
> precedence over the ones discovered by GTK, but in current bullseye this
> doesn't work reliably, and instead both sets appear as near-duplicates
> (see below).

Since CUPS 1.6 the need for cups-browsed has effectively disappeared.
Its major use now is to provide auto-setup of a local queue.

However, on bullseye, the GTK dialog  is not using the correct CUPS APIs
and queues have to be manually created or auto-setup by cups-browsed.

 
> In bullseye, if you print to the entries generated by GTK from mDNS,
> then GTK will submits a PDF via IPP directly to the printer, bypassing
> cups (and that doesn't always work, as seen here). In the implementation
> in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
> their names, GTK's fallback entries are implemented by asking the local
> instance of cups to set up a temporary print queue, and then submitting
> the job via IPP to that temporary queue, which seems to be more reliable
> in practice.

bookworm's libgtk does a much better job than buster's or bulleye's. On
bullseye the dialog displays "getting printer information" and never
does.

> So, if you think cups is always going to be better at IPP than GTK is,
> I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
> use of cups than the version currently in bullseye, are a better answer
> than what GTK in bullseye is currently doing?

I do agree with that.
 
> If the response to asking for testing of possible improvements is going
> to be people characterizing GTK as irretrievably inept, then that is
> not going to help me to find the time and motivation to work on making
> things better (the opposite, in fact).

I did not say or imply the situation was "irretrievable". I did use
"inept"; "suboptimal" might have been better :).

> In particular, if the changes I'm proposing are bringing GTK closer to
> what you want, which I think they are, then it seems counterproductive to
> discourage me from making them. Conversely, if you think these changes are
> wrong, please focus on proposing solutions rather than ascribing blame:
> that's a much more effective way to motivate volunteers to do as you ask.
> 
> > If I set up a manual destination, I would be extremely annoyed if it was
> > interfered with.
> 
> I believe the intention is that if there is a manually-configured queue,
> then any automatically-discovered entries that can be identified as being
> the same printer are ignored.

If you are referring to cups-browsed, that is correct.

> Also, if there is no manually-configured queue, but there is an
> automatically-discovered entry from cups-browsed, then the intention
> is that GTK uses that one, and any entries discovered by GTK that can
> be identified as the same printer are ignored. So as far as I can
> tell, it's aiming to do what you want: manual configuration "wins"
> vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
> so in each case, GTK is aiming to prioritize the cups printing system
> higher than its own code path.

cups-browsed is not required with the GTK dialog in bookworm. #908500.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908500

> The reason we're seeing duplicates seems to be that they are not always
> identified as being the same printer in the way that was intended. In
> the implementation of that deduplication in bullseye's GTK, entries for
> the same printer are not always identified as such, so you're offered
> the result of 

Bug#1007189: searx: Searx will not run, gives a python related error

[Johannes Schauer Marin Rodrigues]

Hi Anonymousellama21,

Quoting Anonymousellama21 (2022-03-13 04:36:19)
> Dear Maintainer,
> 
> I've just installed searx and ran "searx-run" and got the following error:
> anon@anon:/$ searx-run
> Traceback (most recent call last):
>   File "/usr/bin/searx-run", line 33, in 
> sys.exit(load_entry_point('searx==1.0.0', 'console_scripts', 
> 'searx-run')())
>   File "/usr/bin/searx-run", line 25, in importlib_load_entry_point
> return next(matches).load()
>   File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
> module = import_module(match.group('module'))
>   File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 972, in _find_and_load_unlocked
>   File "", line 228, in _call_with_frames_removed
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File "/usr/lib/python3/dist-packages/searx/__init__.py", line 27, in 
> 
> settings, settings_load_message = searx.settings_loader.load_settings()
>   File "/usr/lib/python3/dist-packages/searx/settings_loader.py", line 117, 
> in load_settings
> return (load_yaml(default_settings_path),
>   File "/usr/lib/python3/dist-packages/searx/settings_loader.py", line 24, in 
> load_yaml
> with open(file_name, 'r', encoding='utf-8') as settings_yaml:
> TypeError: expected str, bytes or os.PathLike object, not NoneType

this looks like you don't have a /etc/searx/settings.yml. The problem should be
fixed after you copy /usr/share/doc/searx/examples/settings.yml to
/etc/searx/settings.yml and adapt the configuration to your needs.

I also brought up the issue with upstream:
https://github.com/searx/searx/issues/3184

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006047: ruby-pygments.rb: FTBFS: ERROR: Test "ruby3.0" failed.

[Paul Gevers]

Source: ruby-pygments.rb
Version: 2.3.0+ds-2
Followup-For: Bug #1006047
Control: tags -1 pending

Dear maintainers,

I prepared an NMU to fix this issue. It's blocking the migration of
pygments to testing.

I uploaded to DELAYED/5, please cancel or tell me to cancel if you
want to handle this yourself.

Paul
diff --git a/debian/changelog b/debian/changelog
index 34cf687..0045c1a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-pygments.rb (2.3.0+ds-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * test: update for latest pygments (Closes: #1006047)
+
+ -- Paul Gevers   Sun, 13 Mar 2022 12:31:00 +0100
+
 ruby-pygments.rb (2.3.0+ds-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/series b/debian/patches/series
index ea926c8..5ce9448 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 0010-Disable-the-test-expecting-a-timeout.patch
 0013-test-drop-test-that-depends-on-Python-internals.patch
 0014-no-relative-path-to-mentos-py.patch
+test-update-for-latest-pygments.patch
diff --git a/debian/patches/test-update-for-latest-pygments.patch 
b/debian/patches/test-update-for-latest-pygments.patch
new file mode 100644
index 000..51dd7a4
--- /dev/null
+++ b/debian/patches/test-update-for-latest-pygments.patch
@@ -0,0 +1,38 @@
+From: Paul Gevers 
+Date: Sun, 13 Mar 2022 12:29:11 +0100
+X-Dgit-Generated: 2.3.0+ds-2.1 5528a716afc2e62e4fc630c623c238e02259
+Subject: test: update for latest pygments
+
+Closes: #1006047
+
+---
+
+--- ruby-pygments.rb-2.3.0+ds.orig/test/test_pygments.rb
 ruby-pygments.rb-2.3.0+ds/test/test_pygments.rb
+@@ -71,7 +71,7 @@ class PygmentsHighlightTest < Test::Unit
+ 
+   def test_highlight_formatter_bbcode
+ code = P.highlight(RUBY_CODE, formatter: 'bbcode')
+-assert_match 'color=#408080][i]#!/usr/bin/ruby[/i]', code
++assert_match 'color=#3D7B7B][i]#!/usr/bin/ruby[/i]', code
+   end
+ 
+   def test_highlight_formatter_terminal
+@@ -181,7 +181,7 @@ class PygmentsLexerClassTest < Test::Uni
+ assert_equal P::Lexer['PHP'], P::Lexer.find_by_extname('.php4')
+ assert_equal P::Lexer['PHP'], P::Lexer.find_by_extname('.php5')
+ assert_equal P::Lexer['Groff'], P::Lexer.find_by_extname('.1')
+-assert_equal P::Lexer['Groff'], P::Lexer.find_by_extname('.3')
++#assert_equal P::Lexer['Groff'], P::Lexer.find_by_extname('.3')
+ assert_equal P::Lexer['C'], P::Lexer.find_by_extname('.c')
+ assert_equal P::Lexer['Python'], P::Lexer.find_by_extname('.py')
+ assert_equal P::Lexer['Java'], P::Lexer.find_by_extname('.java')
+@@ -213,7 +213,7 @@ class PygmentsCssTest < Test::Unit::Test
+   end
+ 
+   def test_css_default
+-assert_match '.c { color: #408080; font-style: italic }', P.css
++assert_match '.c { color: #3D7B7B; font-style: italic }', P.css
+   end
+ 
+   def test_css_colorful

Bug#1005800: sundials: FTBFS in sid (test failures)

[Drew Parsons]

Source: sundials
Followup-For: Bug #1005800

This build failure doesn't seem to be reproducible.  Reproducibility
builds are still successful (tests passed), most recently 2022-03-12,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sundials.html

We'll have a new rebuild shortly, against hypre 2.23.

Bug#1007196: ITP: fishui -- Cutefish Desktop Environment UIKit

[Arun Kumar Pariyar]

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

* Package name : fishui
Version : 0.8
Upstream Author : Arun Kumar Pariyar 
* URL : https://github.com/cutefishos/fishui
* License : GPL-3+
Programming Lang: C++
Description : Cutefish Desktop Environment UIKit

FishUI is a GUI library based on QQC2 (Qt Quick Controls 2).
.
This package is a part of Cutefish DE.



OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007195: Dock dialogs to not obscure preview

[martin f krafft]

Package: gscan2pdf
Version: 2.12.5-1
Severity: wishlist

When I save a page or multiple, a dialog pops up, allowing me to 
control the file format. Then, another dialog pops up wherein I 
choose the destination file.

Both these dialogs are placed by the window manager, and often end 
up obscuring the content that was just scanned. Which is a shame, 
because sometime I need to look something up (like a date) when 
making the filename. Hence, I find myself quite regularly first 
moving both dialogs out of my view.

Wouldn't it be possible to replace the dialogs with a persistently 
docked pane, maybe even including a file browser. Then, the window 
manager wouldn't need to attempt to do magic, because gscan2pdf 
knows how not to obscure the content.

Thanks for your consideration.

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.3
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b7
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 10-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.76-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1.3
ii  libimage-sane-perl 5-1+b2
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.69-1
ii  liblocale-gettext-perl 1.07-4+b2
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b10
ii  libpdf-builder-perl3.023-1
ii  libproc-processtable-perl  0.634-1+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.52.5+dfsg-3+b1
ii  libset-intspan-perl1.19-2
ii  libtiff-tools  4.3.0-3
ii  libtry-tiny-perl   0.31-1
ii  sane-utils 1.0.32-4

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-2
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4.1

gscan2pdf suggests no packages.

-- no debconf information


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

Bug#959488: qbittorrent logo on the systemtray looks odd

[Christian Marillat]

Hi,

Works fine for me under XFCE.

Which desktop are you using ?

Christian

Bug#1005297: gcc-12-12-20220302-1: FTBFS on hurd-i386

[Svante Signell]

found 1005297 gcc-12-12-20220302-1
retitle 1005297 gcc-12-12-20220302-1: FTBFS on hurd-i386
tags 1005297 + patch
thanks

Hi again,

Unfortunately the Debian patch Makefile.in.diff is needed to for a
successful build. Attached again here for completeness, and should be
applied after gm2.diff.

For more information about this problem, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104660

In the reply from Richard Biener to this bug the writes:
https://gcc.gnu.org/pipermail/gcc-bugs/2022-February/778542.html

> Well, that's because of
> 
> dependencies = { module=all-target-libgo; on=all-target-libbacktrace;
> };
> dependencies = { module=all-target-libgo; on=all-target-libffi; };
> dependencies = { module=all-target-libgo; on=all-target-libatomic; };
> 
> the reason the dependency is conditional is that libgo is not
> bootstrapped (and so is libffi) but libbacktrace and libatomic are.

Thanks!

--- a/src/Makefile.in	2022-02-15 00:20:00.0 +0100
+++ b/src/Makefile.in	2022-02-15 00:25:27.0 +0100
@@ -66351,6 +66351,8 @@
 all-m4: maybe-all-build-texinfo
 configure-target-libgo: maybe-configure-target-libffi
 all-target-libgo: maybe-all-target-libffi
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
 configure-target-libphobos: maybe-configure-target-libbacktrace
 configure-stage1-target-libphobos: maybe-configure-stage1-target-libbacktrace
 configure-stage2-target-libphobos: maybe-configure-stage2-target-libbacktrace
@@ -66516,8 +66518,6 @@
 configure-target-fastjar: maybe-configure-target-zlib
 all-target-fastjar: maybe-all-target-zlib
 configure-target-libgo: maybe-all-target-libstdc++-v3
-all-target-libgo: maybe-all-target-libbacktrace
-all-target-libgo: maybe-all-target-libatomic
 configure-target-libgm2: maybe-all-target-libstdc++-v3
 all-target-libgm2: maybe-all-target-libatomic
 configure-target-liboffloadmic: maybe-configure-target-libgomp