Bug#1027853: transition: muparserx

[Sebastiaan Couwenberg]

On 1/4/23 23:48, Sebastian Ramacher wrote:

On 2023-01-04 04:40:43 +0100, Andreas Bombe wrote:

This is still a package with a soname coupled to its release number, so
there isn't really anything significantly changed.

It has genomicsdb, otb and qiskit-aer as rdepds and I successfully built
all three against the new version. For both genomicsdb and qiskit-aer
the build time testsuite completed without failures. otb does not appear
to have a testsuite.

The auto-muparserx ben tracker appears correct.


Please go ahead


muparserx (4.0.11-2) is built & installed on all release architectures, 
the binNMUs can be scheduled.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1028252: tomlplusplus FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: cmark-gfm:native

[Andrea Pappacoda]

On Mon, 09 Jan 2023 00:23:21 +0200 Adrian Bunk  wrote:
> Source: tomlplusplus
> Version: 3.2.0+ds-1
> Severity: serious
> Tags: ftbfs
>
> cmark-gfm is not Multi-Arch: allowed

Hi Adrian, thanks for the report. When I tagged the 3.2.0+ds-1 release 
I had to mark cmark-gfm with :native to make cross-builds work. 
cmark-gfm (and cmark) have been marked as Multi-Arch: foreign since 
then, so the :native thing should be indeed removed now.


Bastian has already pushed the fix to Salsa, and I've now uploaded -2 
to Mentors.

Bug#1027895: conky-all: Conky window does not appear on second monitor

[Russell Belair]

Package: conky-all
Version: 1.17.0-1
Followup-For: Bug #1027895

Dear Maintainer,

   * What led up to the situation?
 Upgraded to 1.17.0-1

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I have a multipanel conky across 3 monitors. After upgrading, only the 
primary monitor was working. Seems conky is no longer getting correct xinerama 
area for my screens.
 I attempted to change the gap-x & gap-y parameters but to no avail.

   * What was the outcome of this action?
 See above.

   * What outcome did you expect instead?
 Expected to see my panels spread across all three monitors.



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

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages conky-all depends on:
ii  libaudclient23.5~rc2-1+b1
ii  libc62.36-7
ii  libcairo21.16.0-7
ii  libcurl3-gnutls  7.87.0-1
ii  libdbus-glib-1-2 0.112-3
ii  libfontconfig1   2.13.1-4.5
ii  libgcc-s112.2.0-13
ii  libglib2.0-0 2.74.4-1
ii  libical3 3.0.16-1+b1
ii  libimlib21.10.0-4
ii  libircclient11.9-1+b2
ii  libiw30  30~pre9-14
ii  liblua5.3-0  5.3.6-2
ii  libncurses6  6.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpangoft2-1.0-01.50.12+ds-1
ii  libpulse016.1+dfsg1-2+b1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-13
ii  libtinfo66.4-1
ii  libwayland-client0   1.21.0-1
ii  libx11-6 2:1.8.3-3
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxft2  2.3.6-1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  libxnvctrl0  510.85.02-2

conky-all recommends no packages.

Versions of packages conky-all suggests:
pn  apcupsd
pn  audacious  
pn  moc
pn  mpd

-- no debconf information

Bug#1028280: libapache2-mod-encoding: uses the build architecture compiler as a make default

[Helmut Grohne]

Source: libapache2-mod-encoding
Version: 20040616-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libapache2-mod-encoding fails to cross build from source, because
debian/rules uses the build architecture compiler as a make default. The
easiest way of fixing that - seeding it from dpkg's buildtools.mk -
makes libapache2-mod-encoding cross buildable. I'm attaching a patch for
your convenience.

Helmut
diff --minimal -Nru libapache2-mod-encoding-20040616/debian/changelog 
libapache2-mod-encoding-20040616/debian/changelog
--- libapache2-mod-encoding-20040616/debian/changelog   2021-12-19 
17:46:28.0 +0100
+++ libapache2-mod-encoding-20040616/debian/changelog   2023-01-09 
07:46:45.0 +0100
@@ -1,3 +1,10 @@
+libapache2-mod-encoding (20040616-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Seed $(CC) from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 09 Jan 2023 07:46:45 +0100
+
 libapache2-mod-encoding (20040616-7) unstable; urgency=medium
 
   * Take maintainership
diff --minimal -Nru libapache2-mod-encoding-20040616/debian/rules 
libapache2-mod-encoding-20040616/debian/rules
--- libapache2-mod-encoding-20040616/debian/rules   2021-12-19 
17:46:28.0 +0100
+++ libapache2-mod-encoding-20040616/debian/rules   2023-01-09 
07:46:44.0 +0100
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@ --with apache2

Bug#1012612: texinfo: Info documentation links to missing "pod2texi" manual

[Hilmar Preuße]

Am 10.06.2022 um 11:29 teilte Timothy Allen mit:

Dear Timothy,


As I'm sure you know, when the "texinfo" package is installed, it creates
`/usr/share/info/texinfo.info.gz`, and a metadata chunk from the preamble of
that file is merged into `/usr/share/info/dir`.


I've uploaded texinfo 7.0.1-3 to Debian experimental. Could you install
it and check if it solves the issue? Thanks!

Hilmar
--
sigfault

Bug#1028279: rbdoom3bfg FTCBFS: missing include ../../imgui/imgui.h

[Helmut Grohne]

Source: rbdoom3bfg
Version: 1.4.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rbdoom3bfg fails to cross build from source, because it fails to locate
../../imgui/imgui.h. This presumably is a side-effect from unvendoring
imgui and the parent directory specification should simply be dropped.
I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru rbdoom3bfg-1.4.0+dfsg/debian/changelog 
rbdoom3bfg-1.4.0+dfsg/debian/changelog
--- rbdoom3bfg-1.4.0+dfsg/debian/changelog  2022-03-28 11:15:37.0 
+0200
+++ rbdoom3bfg-1.4.0+dfsg/debian/changelog  2023-01-08 07:46:15.0 
+0100
@@ -1,3 +1,10 @@
+rbdoom3bfg (1.4.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Avoid including ../../imgui/imgui.h. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 08 Jan 2023 07:46:15 +0100
+
 rbdoom3bfg (1.4.0+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru 
rbdoom3bfg-1.4.0+dfsg/debian/patches/20-use-debian-imgui.patch 
rbdoom3bfg-1.4.0+dfsg/debian/patches/20-use-debian-imgui.patch
--- rbdoom3bfg-1.4.0+dfsg/debian/patches/20-use-debian-imgui.patch  
2022-03-28 10:25:10.0 +0200
+++ rbdoom3bfg-1.4.0+dfsg/debian/patches/20-use-debian-imgui.patch  
2023-01-08 07:46:14.0 +0100
@@ -146,3 +146,14 @@
g_haveNewFrame = false;
}
  }
+--- rbdoom3bfg-1.4.0+dfsg.orig/neo/renderer/OpenGL/RenderBackend_GL.cpp
 rbdoom3bfg-1.4.0+dfsg/neo/renderer/OpenGL/RenderBackend_GL.cpp
+@@ -48,7 +48,7 @@
+ #include "../RenderBackend.h"
+ #include "../../framework/Common_local.h"
+ 
+-#include "../../imgui/imgui.h"
++#include "imgui/imgui.h"
+ 
+ idCVar r_drawFlickerBox( "r_drawFlickerBox", "0", CVAR_RENDERER | CVAR_BOOL, 
"visual test for dropping frames" );
+ idCVar stereoRender_warp( "stereoRender_warp", "0", CVAR_RENDERER | 
CVAR_ARCHIVE | CVAR_BOOL, "use the optical warping renderprog instead of 
stereoDeGhost" );

Bug#1028181: runit-init makes the system unbootable

[Helmut Grohne]

Hi Lorenzo,

On Mon, Jan 09, 2023 at 02:39:25AM +0100, Lorenzo wrote:
> This need to be adjusted in the initcripts package, as a quick fix I'm
> going to add a dependency on e2fsprogs too.

Would you be able to go the longer route and make initscripts handle
this in a better way? Given that you can simply press ctrl-d, I think
this does qualify as non-rc severity.

When the next report with a btrfs comes along, will you add a dependency
on btrfs-progs?

> > 
> > So I went on to retry with e2fsprogs added and this is what I got:
> > 
> > | Begin: Running /scripts/local-bottom ... done.
> > | Begin: Running /scripts/init-bottom ... done.
> > | [1.484294] Not activating Mandatory Access Control as
>  [...]
> > | Cleaning up temporary files
> > | Cleaning up temporary files
> > | - runit: leave stage: /etc/runit/1
> > | - runit: enter stage: /etc/runit/2
> > | runsvchdir: default: current.
> > 
> > In particular, the user has no way to log into the system as no getty
> > is being spawned. I see that the autopkgtest has to do this manually
> > via "ln -s /etc/sv/getty-ttyS0 /etc/service/". Do you think there
> > could be a better way to achieve this such that at least the console=
> > kernel command line parameter is automatically issued a getty?
> 
> This one is a separate issue: true that a serial-getty is not
> automatically started (there are gettys on tty[1-6] for standard usage)
> but a getty-ttyS0 service that can be enabled and tuned to the right
> device exists, so I don't think that this last part is RC.. Sure there
> is no documentation on how to do it and anyway there is room for
> improvement. I've opened a separate (#1028270) bug for the "no way to
> login" issue above, if you disagree with the non-RC severity of
> #1028270 please change the severity of that one as I'm going to close
> this one by adding two dependency to runit-init.

I mostly agree. Let's turn this bug into just the mount dependency only
and handle the other issues at non-rc severity.

As for becoming an init alternative, I suggest going the same route that
systemd went: documenting a way to boot with runit by providing a
init=... kernel command line parameter and have it mature that way a
little longer. Keep in mind that the init package was not added to gain
choice, but it was a tool to ease the transition from sysvinit to
systemd. init is not essential and nothing depends on init (the
package), so runit-init can be used without being an alternative there.

Helmut

Bug#1028278: dh-cmake FTBFS with Python 3.11 as default version

[Adrian Bunk]

Source: dh-cmake
Version: 0.6.1
Severity: serious
Tags: ftbfs bookworm sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dh-cmake.html

...
==
FAIL: test_autopep8 
(dhcmake.tests.source_check.SourceCheckTestCase.test_autopep8)
--
Traceback (most recent call last):
  File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 25, in 
test_autopep8
self.foreach_py(lambda a, r, c: self.assertEqual(autopep8.fix_code(c), c,
  File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 22, in 
foreach_py
func(filename_abs, filename_rel, contents)
  File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 25, in 

self.foreach_py(lambda a, r, c: self.assertEqual(autopep8.fix_code(c), c,
^
AssertionError: '# Th[204 chars]\n\n# from unittest import skip\n\nimport 
os\n[9838 chars]e)\n' != '# Th[204 chars]\n\n#from unittest import 
skip\n\nimport os\nf[9837 chars]e)\n'
Diff is 10430 characters long. Set self.maxDiff to None to see it. : File 
dhcmake/tests/common.py is incorrectly formatted

--
Ran 106 tests in 429.833s

FAILED (failures=1)
Test failed: 
error: Test failed: 
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: 
python3.11 setup.py test 
dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.11" returned 
exit code 13
make: *** [debian/rules:6: binary] Error 25

Bug#1025717: cross-toolchain-base-mipsen FTBFS: install: cannot change owner and permissions

[Yunqiang Su]

On Thu, 08 Dec 2022 00:00:35 +0200 Adrian Bunk  wrote:
> Source: cross-toolchain-base-mipsen
> Version: 22
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=cross-toolchain-base-mipsen=all=22=1670437077=0

Fixed by version 23.

> 
> ...
> dh_installdirs -plinux-libc-dev-mips-cross \
>   usr/share/doc/linux-libc-dev-mips-cross \
>   usr/share/lintian/overrides \
>   usr/mips-linux-gnu
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross’: 
> Operation not permitted
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides’: Operation not 
> permitted
> install: cannot change owner and permissions of 
> ‘debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu’: Operation not permitted
> dh_installdirs: error: install -m0755 -o 0 -g 0 -d 
> debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross 
> debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides 
> debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu returned exit code 1
> make: *** [debian/rules:162: stamp-dir/install-linux.mips] Error 25

Bug#1028277: chromium: Chromium experiences constant audio and video desynchronizations when playing video media content

[Ryou]

Package: chromium
Version: 108.0.5359.124-1~deb11u1
Severity: important
X-Debbugs-Cc: redking...@gmail.com

Dear Maintainer,

Chromium experiences constant audio and video desynchronizations when playing
video media content. The image freezes or all the content is stagnant without
showing more than a static image and without audio, other times the entire
browser freezes and stops working for a while.

1) will it have a future and prompt solution?

2) What is recommended to mitigate this failure mentioned in my report?


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

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

Versions of packages chromium depends on:
ii  chromium-common108.0.5359.124-1~deb11u1
ii  libasound2 1.2.4-1.1
ii  libatk-bridge2.0-0 2.38.0-1
ii  libatk1.0-02.36.0-2
ii  libatomic1 10.2.1-6
ii  libatspi2.0-0  2.38.0-4
ii  libbrotli1 1.0.9-2+b2
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcups2   2.3.3op2-3+deb11u2
ii  libdbus-1-31.12.24-0+deb11u1
ii  libdouble-conversion3  3.1.5-6.1
ii  libdrm22.4.104-1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libexpat1  2.2.10-2+deb11u5
ii  libflac8   1.3.3-2+deb11u1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1+deb11u1
ii  libgbm120.3.5-1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  liblcms2-2 2.12~rc1-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.29-1
ii  libnss32:3.61-1+deb11u2
ii  libopenjp2-7   2.4.0-3
ii  libopus0   1.3.1-0.1
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  libpulse0  14.2-2
ii  libre2-9   20210201+dfsg-1
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10.2.1-6
ii  libwebp6   0.6.1-2.1
ii  libwebpdemux2  0.6.1-2.1
ii  libwebpmux30.6.1-2.1
ii  libwoff1   1.0.2-1+b1
ii  libx11-6   2:1.7.2-1
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxml22.9.10+dfsg-6.7+deb11u3
ii  libxnvctrl0470.141.03-1~deb11u1
ii  libxrandr2 2:1.5.1-1
ii  libxslt1.1 1.1.34-4+deb11u1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.8.0-1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages chromium recommends:
ii  chromium-sandbox  108.0.5359.124-1~deb11u1

Versions of packages chromium suggests:
ii  chromium-driver  108.0.5359.124-1~deb11u1
ii  chromium-l10n108.0.5359.124-1~deb11u1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6  2.31-13+deb11u5
ii  libdouble-conversion3  3.1.5-6.1
ii  libjsoncpp24   1.9.4-4
ii  

Bug#1028227: Blocked

[William Desportes]

It's going to be difficult because of #1019370 (maintainer email does not work)

I added a "block" on this bug. 

I sent an email to his Debian address and received back:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  d...@18xx.org
retry timeout exceeded

--
William

Bug#1028276: New upstream release available

[Michael Deegan]

Package: python3-pygtail
Version: 0.6.1-3
Severity: normal

I'm wondering if this package is semi-abandoned, as there's been a newer
upstream release for nearly five years, if 
https://github.com/bgreenlee/pygtail/tags
is to be believed. 


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'stable'), (500, 
'oldstable'), (490, 'testing'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-pygtail depends on:
ii  python3  3.10.6-3+b1

python3-pygtail recommends no packages.

python3-pygtail suggests no packages.

-- no debconf information

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#1028256: [Pkg-nagios-devel] Bug#1028256: nagvis: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 1/8/23 23:37, Paulo Henrique de Lima Santana wrote:

Could you please update this Brazilian Portuguese translation?


Thanks for the updated translation, it's commited in git and will be 
included in the next upload.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1028275: perl: Return value of system()

[David Christensen]

Package: perl
Version: 5.32.1-4+deb11u2
Severity: normal
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

I am working on some Perl code with child processes and signals.


'perldoc -f system' says:

The return value is the exit status of the program as returned
by the "wait" call.


Reading further, if the child died due to a signal, the signal number
is supposed to be in the bottom 7 bits of $? ($CHILD_ERROR).


Testing shows that system() returns the same value as the value of the
Perl global child error variable $? ($CHILD_ERROR) when the child dies
due to a signal.


Here is a test script:

2023-01-08 20:12:49 dpchrist@laalaa ~/sandbox/perl/signal-child_error
$ nl signal-child_error-system.t 
 1  #!/usr/bin/env perl
 2  # $Id: signal-child_error-system.t,v 1.4 2023/01/09 04:07:32 dpchrist 
Exp $
 3  # by David Paul Christensen dpchr...@holgerdanske.com
 4  # Public Domain
 5  #
 6  # Demonstrates Perl child SIGHUP and $? ($CHILD_ERROR) using system().
 7  
 8  use strict;
 9  use warnings;
10  use POSIX   qw( SIGHUP );
11  use Test::More;
12  
13  isnt $$, 0, join $", __FILE__, __LINE__,
14  sprintf '$$(%i) != 0', $$;
15  
16  isnt SIGHUP, 0, join $", __FILE__, __LINE__,
17  sprintf 'SIGHUP(%i) != 0', SIGHUP;
18  
19  my $system = system(q( perl -e 'kill "HUP", $$' ));
20  
21  is $system, $?, join $", __FILE__, __LINE__,
22  sprintf '$system(%i) == $?(%i)', $system, $?;
23  
24  is $?, SIGHUP, join $", __FILE__, __LINE__,
25  sprintf "\$?(%i) == SIGHUP(%i)", $?, SIGHUP;
26  
27  my $b15   = ($? >> 15) &   1;
28  my $b14_8 = ($? >>  8) & 127;
29  my $b7= ($? >>  7) &   1;
30  my $b6_0  =  $?& 127;
31  
32  is $b15,   0,  join $", __FILE__, __LINE__,
33  sprintf "\$b15(%i) == 0",   $b15;
34  
35  is $b14_8, 0,  join $", __FILE__, __LINE__,
36  sprintf "\$b14_8(%i) == 0", $b14_8;
37  
38  is $b7,0,  join $", __FILE__, __LINE__,
39  sprintf "\$b7(%i) == 0",$b7;
40  
41  is $b6_0,  SIGHUP, join $", __FILE__, __LINE__,
42  sprintf "\$b6_0(%i) == SIGHUP(%i)",  $b6_0, SIGHUP;
43  
44  done_testing;


If I run the test script on Debian:

2023-01-08 20:17:31 dpchrist@laalaa ~/sandbox/perl/signal-child_error
$ cat /etc/debian_version ; uname -a ; perl -v | head -n 2 | tail -n 1 
11.6
Linux laalaa 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 
GNU/Linux
This is perl 5, version 32, subversion 1 (v5.32.1) built for 
x86_64-linux-gnu-thread-multi

2023-01-08 20:17:41 dpchrist@laalaa ~/sandbox/perl/signal-child_error
$ perl signal-child_error-system.t 
ok 1 - signal-child_error-system.t 13 $$(17280) != 0
ok 2 - signal-child_error-system.t 16 SIGHUP(1) != 0
Hangup
ok 3 - signal-child_error-system.t 21 $system(33024) == $?(33024)
not ok 4 - signal-child_error-system.t 24 $?(33024) == SIGHUP(1)
#   Failed test 'signal-child_error-system.t 24 $?(33024) == SIGHUP(1)'
#   at signal-child_error-system.t line 24.
#  got: '33024'
# expected: '1'
not ok 5 - signal-child_error-system.t 32 $b15(1) == 0
#   Failed test 'signal-child_error-system.t 32 $b15(1) == 0'
#   at signal-child_error-system.t line 32.
#  got: '1'
# expected: '0'
not ok 6 - signal-child_error-system.t 35 $b14_8(1) == 0
#   Failed test 'signal-child_error-system.t 35 $b14_8(1) == 0'
#   at signal-child_error-system.t line 35.
#  got: '1'
# expected: '0'
ok 7 - signal-child_error-system.t 38 $b7(0) == 0
not ok 8 - signal-child_error-system.t 41 $b6_0(0) == SIGHUP(1)
#   Failed test 'signal-child_error-system.t 41 $b6_0(0) == SIGHUP(1)'
#   at signal-child_error-system.t line 41.
#  got: '0'
# expected: '1'
1..8
# Looks like you failed 4 tests of 8.


Please note:

- The return value of system() is identical to $? ($CHILD_ERROR)
 (line 21).

- This value does not correspond to the signal number (line 24).

- Bit 15 is 1, when it should be 0 (line 32)

- Bits 14-8 contain the signal number, when they should be 0 (line 35).

- Bits 6-0 are 0, when they should contain the signal number (line 41).


If I run the same script on FreeBSD with the same version of Perl:

2023-01-08 20:19:57 dpchrist@f3 ~/sandbox/perl/signal-child_error
$ freebsd-version ; uname -a ; perl -v | head -n 2 | tail -n 1
12.3-RELEASE-p10
FreeBSD f3.tracy.holgerdanske.com 12.3-RELEASE-p6 FreeBSD 12.3-RELEASE-p6 
GENERIC  amd64
This is perl 5, version 32, subversion 1 (v5.32.1) built for 
amd64-freebsd-thread-multi

2023-01-08 20:20:00 dpchrist@f3 ~/sandbox/perl/signal-child_error
$ grep Id signal-child_error-system.t 
# $Id: signal-child_error-system.t,v 1.4 2023/01/09 04:07:32 dpchrist Exp $

2023-01-08 20:20:26 dpchrist@f3 ~/sandbox/perl/signal-child_error
$ perl signal-child_error-system.t 
ok 1 - signal-child_error-system.t 13 $$(22264) != 0
ok 2 - 

Bug#1028274: lintian: Warning in processable […].dsc: Error open (<) on '[…].orig.tar.gz.asc': No such file or directory at /usr/share/perl5/Path/Tiny.pm line 2419.

[Axel Beckert]

Package: lintian
Version: 2.115.3-68-g091d167f6
Severity: important

This issue is slightly related to the issue which made me find #1027949
as it probably also only surfaced when libpath-tiny-perl got bumped from
0.124 to 0.144 which added more pedantic error checking:

When trying to run lintian against a package where it expects an
upstream signature (probably because debian/upstream/signing-key.asc
exists), it started to throw an error message instead of the relevant
tag:

$ lintian /var/cache/pbuilder/result/screen_4.9.0-4_amd64.changes
Warning in processable /var/cache/pbuilder/result/screen_4.9.0-4.dsc: Error 
open (<) on '/var/cache/pbuilder/result/screen_4.9.0.orig.tar.gz.asc': No such 
file or directory at /usr/share/perl5/Path/Tiny.pm line 2419.
Path::Tiny::Error::throw("Path::Tiny::Error", "open (<)", 
"/var/cache/pbuilder/result/screen_4.9.0.orig.tar.gz.asc", "No such file or 
directory") called at /usr/share/perl5/Path/Tiny.pm line 149
Path::Tiny::_throw(Path::Tiny=ARRAY(0x55c284f19458), "open (<)") called 
at /usr/share/perl5/Path/Tiny.pm line 1173
Path::Tiny::filehandle(Path::Tiny=ARRAY(0x55c284f19458), 
HASH(0x55c284f0af68), "<", undef) called at /usr/share/perl5/Path/Tiny.pm line 
2066
Path::Tiny::slurp(Path::Tiny=ARRAY(0x55c284f19458)) called at 
/usr/share/lintian/lib/Lintian/Check/UpstreamSignature.pm line 86

Lintian::Check::UpstreamSignature::source(Lintian::Check::UpstreamSignature=HASH(0x55c284ac1a18))
 called at /usr/share/lintian/bin/../lib/Lintian/Check.pm line 142

Lintian::Check::run(Lintian::Check::UpstreamSignature=HASH(0x55c284ac1a18)) 
called at /usr/share/lintian/bin/../lib/Lintian/Group.pm line 276
eval {...} called at /usr/share/lintian/bin/../lib/Lintian/Group.pm 
line 279
Lintian::Group::process(Lintian::Group=HASH(0x55c27e375b40), 
HASH(0x55c27e38e8d8), HASH(0x55c2808e1298)) called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 171
Lintian::Pool::process(Lintian::Pool=HASH(0x55c27e39f5b8), 
Lintian::Profile=HASH(0x55c280829c28), SCALAR(0x55c2808f8d40), 
HASH(0x55c2808e1298)) called at /usr/bin/lintian line 757
warning: cannot run upstream-signature check on package source:screen_4.9.0-4
skipping check of source:screen_4.9.0-4
[…]

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils 2.39.90.20230104-1
ii  bzip21.0.8-5+b1
ii  diffstat 1.65-1
ii  dpkg 1.21.17
ii  dpkg-dev 1.21.17
ii  file 1:5.41-4
ii  gettext  0.21-10
ii  gpg  2.2.40-1
ii  intltool-debian  0.35.0+20060710.6
ii  iso-codes4.12.0-1
ii  libapt-pkg-perl  0.1.40+b2
ii  libarchive-zip-perl  1.68-1
ii  libberkeleydb-perl   0.64-2+b1
ii  libcapture-tiny-perl 0.48-2
ii  libclass-xsaccessor-perl 1.19-4+b1
ii  libclone-perl0.46-1
ii  libconfig-tiny-perl  2.28-2
ii  libconst-fast-perl   0.014-2
ii  libcpanel-json-xs-perl   4.32-1+b1
ii  libdata-dpath-perl   0.58-2
ii  libdata-validate-domain-perl 0.10-1.1
ii  libdata-validate-uri-perl0.07-2
ii  libdevel-size-perl   0.83-2+b1
ii  libdigest-sha-perl   6.03-1+b1
ii  libdpkg-perl 1.21.17
ii  libemail-address-xs-perl 1.05-1+b1
ii  libencode-perl   3.19-1+b1
ii  libfile-basedir-perl 0.09-2
ii  libfile-find-rule-perl   0.34-3
ii  libfont-ttf-perl 1.06-2
ii  libhtml-html5-entities-perl  0.004-3
ii  libhtml-tokeparser-simple-perl   3.16-4
ii  libio-interactive-perl   1.023-2
ii  libipc-run3-perl 0.048-3
ii  libjson-maybexs-perl 1.004004-1
ii  liblist-compare-perl 0.55-2
ii  liblist-someutils-perl   0.59-1
ii  liblist-utilsby-perl 0.12-2
ii  libmldbm-perl2.05-4
ii  libmoo-perl  2.005005-1
ii  libmoox-aliases-perl 0.001006-2
ii  libnamespace-clean-perl  0.27-2
ii  libpath-tiny-perl0.144-1
ii  libperlio-gzip-perl  0.20-1+b1
ii  libperlio-utf8-strict-perl   0.010-1
ii  libproc-processtable-perl0.634-1+b2
ii  

Bug#1028273: MariaDB systemd: make multiple systemd files compatible with --build=all

[Otto Kekäläinen]

Package: mariadb-server
Severity: wishlist
Tags: newcomer

Upstream MariaDB ships with multiple systemd service files but we
don't have it enabled in MariaDB packaging in Debian[1].

This issue is tagged newcomer friendly as it only requires a minimal
knowledge[2] of existing MariaDB packaging in Debian.

We need help from somebody who can deep dive into both systemd to
understand how this feature is supposed to work correctly, and to read
up on what the Debian Policy says about systemd usage and what the
conventions are for this specifically in Debian.

The section in debian/rules currently looks like this, explaining the problem:

# Install mariadb.socket without enabling it, keep using
mariadb.service by default
# @TODO: Temporarily disable extra and socket systemd file installation until
# a '--build=all' compatible mechanism is found
override_dh_systemd_enable:
dh_systemd_enable --name=mariadb
dh_systemd_enable --no-enable --name=mariadb@ # mariadb@.service
# dh_systemd_enable --no-enable --name=mariadb mariadb.socket
# dh_systemd_enable --no-enable --name=mariadb-extra mariadb-extra.socket
# dh_systemd_enable --no-enable --name=mariadb@ mariadb.socket
# dh_systemd_enable --no-enable --name=mariadb-extra@ mariadb-extra.socket


If these lines are enabled, the build fails with error:

dh_systemd_enable: warning: Requested unit "mariadb.socket" but it was
not found in any package acted on.

See example of failing CI job at
https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/3763077



[1] https://salsa.debian.org/mariadb-team/mariadb-server
[2] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1028272: MariaDB systemd: start using tmpfiles.d

[Otto Kekäläinen]

Package: mariadb-server
Severity: wishlist
Tags: newcomer

Upstream MariaDB ships with usr/lib/tpmfiles.d/mariadb.conf but we
don't use it in MariaDB packaging in Debian[1].

This issue is tagged newcomer friendly as it only requires a minimal
knowledge[2] of existing MariaDB packaging in Debian.

We need help from somebody who can deep dive into both systemd to
understand how this feature is supposed to work correctly, and to read
up on what the Debian Policy says about systemd usage and what the
conventions are for this specifically in Debian.

With this information update the mariadb.service file to use this file
correctly, and include it the package mariadb-server (by adding a line
to debian/mariadb-server.install) and clean it away from
debian/not-installed list.

[1] https://salsa.debian.org/mariadb-team/mariadb-server
[2] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1028271: MariaDB systemd: start using sysusers.d

[Otto Kekäläinen]

Package: mariadb-server
Severity: wishlist
Tags: newcomer

Upstream MariaDB ships with usr/lib/sysusers.d/mariadb.conf but we
don't use it in MariaDB packaging in Debian[1].

This issue is tagged newcomer friendly as it only requires a minimal
knowledge[2] of existing MariaDB packaging in Debian.

We need help from somebody who can deep dive into both systemd to
understand how this feature is supposed to work correctly, and to read
up on what the Debian Policy says about systemd usage and what the
conventions are for this specifically in Debian.

With this information update the mariadb.service file to use this file
correctly, and include it the package mariadb-server (by adding a line
to debian/mariadb-server.install) and clean it away from
debian/not-installed list.

[1] https://salsa.debian.org/mariadb-team/mariadb-server
[2] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1019841: amule: Please transition to wxwidgets3.2

[Olly Betts]

Control: tags 1019841 + patch

> tags 1019841 - patch
> # there are no traces of a patch here

I added the patch tag because Scott's most recent comment linked to
patch in a github PR.

Anyway, I've taken that patch, simplified it a bit (since we only need
to support wx3.2 here and it's easier to inspect the patch without all
the version conditionalisation), and also made it suppress wxSizerFlags
runtime checks - the patch in the PR had fixes for some instances, but
I still managed to trigger one and it seems best for our purposes to
just suppress them (which restores the situation to how it is when
built with wx3.0).

I've attached nmudiff output.

I've only tested with with networking disabled - it ideally
needs a test from someone who actually uses the package.

Cheers,
Olly
diff -Nru amule-2.3.3/debian/changelog amule-2.3.3/debian/changelog
--- amule-2.3.3/debian/changelog	2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/changelog	2023-01-09 13:00:46.0 +1300
@@ -1,3 +1,10 @@
+amule (1:2.3.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update to use wxwidgets3.2 - new patch wx3.2.patch; Closes: #1019841
+
+ -- Olly Betts   Mon, 09 Jan 2023 13:00:46 +1300
+
 amule (1:2.3.3-2) unstable; urgency=medium
 
   * rebuild to pick up libcrypto++8; Closes: #995282, #995285
diff -Nru amule-2.3.3/debian/control amule-2.3.3/debian/control
--- amule-2.3.3/debian/control	2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/control	2023-01-09 08:59:01.0 +1300
@@ -16,8 +16,8 @@
libpng-dev,
libreadline-dev,
libupnp-dev (>= 1:1.6.24-4~),
-   libwxgtk3.0-gtk3-dev,
-   wx3.0-i18n,
+   libwxgtk3.2-dev,
+   wx3.2-i18n,
zlib1g-dev,
 Standards-Version: 4.5.1
 Homepage: http://www.amule.org
diff -Nru amule-2.3.3/debian/patches/series amule-2.3.3/debian/patches/series
--- amule-2.3.3/debian/patches/series	2021-10-01 16:26:49.0 +1300
+++ amule-2.3.3/debian/patches/series	2023-01-09 09:02:35.0 +1300
@@ -2,3 +2,4 @@
 use_xdg-open_as_preview_default.diff
 version_check.diff
 #libupnp1.8.patch
+wx3.2.patch
diff -Nru amule-2.3.3/debian/patches/wx3.2.patch amule-2.3.3/debian/patches/wx3.2.patch
--- amule-2.3.3/debian/patches/wx3.2.patch	1970-01-01 12:00:00.0 +1200
+++ amule-2.3.3/debian/patches/wx3.2.patch	2023-01-09 13:00:46.0 +1300
@@ -0,0 +1,461 @@
+Description: Fixes for wxWidgets 3.2 compatibility
+ Largely based on patch from Mr Hyde  in
+ https://github.com/amule-project/amule/pull/168
+Author: Olly Betts 
+Bug: https://github.com/amule-project/amule/issues/340
+Bug-Debian: https://bugs.debian.org/1019841
+Forwarded: no
+Last-Update: 2023-01-09
+
+--- a/src/ColorFrameCtrl.cpp
 b/src/ColorFrameCtrl.cpp
+@@ -61,7 +61,7 @@
+ /
+ void CColorFrameCtrl::SetFrameBrushColour(const wxColour& colour)
+ {
+-	m_brushFrame = *(wxTheBrushList->FindOrCreateBrush(colour, wxSOLID));
++	m_brushFrame = *(wxTheBrushList->FindOrCreateBrush(colour, wxBRUSHSTYLE_SOLID));
+ 
+ 	Refresh(FALSE);
+ }  // SetFrameColor
+@@ -70,7 +70,7 @@
+ /
+ void CColorFrameCtrl::SetBackgroundBrushColour(const wxColour& colour)
+ {
+-	m_brushBack = *(wxTheBrushList->FindOrCreateBrush(colour, wxSOLID));
++	m_brushBack = *(wxTheBrushList->FindOrCreateBrush(colour, wxBRUSHSTYLE_SOLID));
+ 
+ 	// clear out the existing garbage, re-start with a clean plot
+ 	Refresh(FALSE);
+--- a/src/DownloadListCtrl.cpp
 b/src/DownloadListCtrl.cpp
+@@ -850,7 +850,7 @@
+ 		dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_HIGHLIGHTTEXT));
+ 		dc->SetPen( colour.Blend(65).GetPen() );
+ 	} else {
+-		dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX), wxSOLID)));
++		dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX), wxBRUSHSTYLE_SOLID)));
+ 		dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT));
+ 		dc->SetPen(*wxTRANSPARENT_PEN);
+ 	}
+@@ -1413,7 +1413,7 @@
+ 		dc->DrawLine( rect.x, rect.y + 2, rect.x + width, rect.y + 2 );
+ 
+ 		// Draw the green line
+-		dc->SetPen( *(wxThePenList->FindOrCreatePen( crProgress , 1, wxSOLID ) ));
++		dc->SetPen( *(wxThePenList->FindOrCreatePen( crProgress , 1, wxPENSTYLE_SOLID ) ));
+ 		dc->DrawLine( rect.x, rect.y + 1, rect.x + width, rect.y + 1 );
+ 	}
+ }
+--- a/src/GenericClientListCtrl.cpp
 b/src/GenericClientListCtrl.cpp
+@@ -660,7 +660,7 @@
+ 		dc->SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_HIGHLIGHTTEXT));
+ 		dc->SetPen( colour.Blend(65).GetPen() );
+ 	} else {
+-		dc->SetBackground(*(wxTheBrushList->FindOrCreateBrush(wxSystemSettings::GetColour(wxSYS_COLOUR_LISTBOX), wxSOLID)));
++		

Bug#1028181: runit-init makes the system unbootable

[Lorenzo]

Hi Helmut,

thanks for taking the time to test runit

On Sun, 8 Jan 2023 07:08:36 +0100
Helmut Grohne  wrote:

> The biggest problem here is the lack of mount. mount is not essential
> and nothing depends on it, so it goes missing. Something in the runit
> ecosystem should definitely depend on mount.

right

> 
> It seems like runit requires checking the filesystem, but e2fsprogs is
> not essential anymore and it fails hard. Nowadays, checking ext4
> filesystems is optional and systemd skips doing it in the absence of
> e2fsprogs.

This need to be adjusted in the initcripts package, as a quick fix I'm
going to add a dependency on e2fsprogs too.

> 
> So I went on to retry with e2fsprogs added and this is what I got:
> 
> | Begin: Running /scripts/local-bottom ... done.
> | Begin: Running /scripts/init-bottom ... done.
> | [1.484294] Not activating Mandatory Access Control as
 [...]
> | Cleaning up temporary files
> | Cleaning up temporary files
> | - runit: leave stage: /etc/runit/1
> | - runit: enter stage: /etc/runit/2
> | runsvchdir: default: current.
> 
> In particular, the user has no way to log into the system as no getty
> is being spawned. I see that the autopkgtest has to do this manually
> via "ln -s /etc/sv/getty-ttyS0 /etc/service/". Do you think there
> could be a better way to achieve this such that at least the console=
> kernel command line parameter is automatically issued a getty?

This one is a separate issue: true that a serial-getty is not
automatically started (there are gettys on tty[1-6] for standard usage)
but a getty-ttyS0 service that can be enabled and tuned to the right
device exists, so I don't think that this last part is RC.. Sure there
is no documentation on how to do it and anyway there is room for
improvement. I've opened a separate (#1028270) bug for the "no way to
login" issue above, if you disagree with the non-RC severity of
#1028270 please change the severity of that one as I'm going to close
this one by adding two dependency to runit-init.

Best,
Lorenzo

> Helmut

Bug#1028250: Processed: found 1028250 in 20220917

[Cyril Brulebois]

Control: notfound -1 20220917

Debian Bug Tracking System  (2023-01-09):
> > # that version is nearest to "daily builds"
> > found 1028250 20220917

No, that bug isn't found in that version. We wouldn't have released d-i
with such an obvious issue.


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


signature.asc
Description: PGP signature

Bug#1028270: getty-run: enable a serial getty to increase testability of runit-init

[Lorenzo Puliti]

Package: getty-run
Version: 2.1.2-52
Severity: important
X-Debbugs-Cc: Helmut Grohne , plore...@disroot.org

Hi Helmut,

>From #1028181

> | Activating swapfile swap, if any...done.
> | Cleaning up temporary files
> | Cleaning up temporary files
> | - runit: leave stage: /etc/runit/1
> | - runit: enter stage: /etc/runit/2
> | runsvchdir: default: current.
> 
> In particular, the user has no way to log into the system as no getty
> is being spawned. I see that the autopkgtest has to do this manually
> via "ln -s /etc/sv/getty-ttyS0 /etc/service/".

Note that the "user has no way to log into the system" is true if the only
mean to login is a serial port; by default the user has 6 getty on tty[1-6]
enabled. Said that I agree that it's nice to provide a setup that works out
of the box;
the quick fix that hopefully can improve the situation is that getty-run
ship that service as enabled (it's disabled by default right now) so that
the manual creation of the link is no longer needed.
However I'm afraid that, since /dev/ttyS0 is hardcoded in the service,
it won't work in environments where the serial device has a different
name (let's say ttyS1)...

> Do you think there
> could be a better way to achieve this such that at least the console=
> kernel command line parameter is automatically issued a getty?

(just to be sure that I'm not misunderstanding the above)
are you suggesting that runit grep /proc/cmdline for `console=' and if
there is a match extract the device name and start a getty on that device?
Or there is another more obvious  way that I'm not considering?

Lorenzo

> 
> Helmut


Note to myself: 
* the command= parameter can take several forms and there are comma separated
   options [1]
* see also what systemd does with the getty-generator [2]

[1] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
[2] 
https://manpages.debian.org/testing/systemd/systemd-getty-generator.8.en.html

Bug#1028250: debian-installer: broken cryptsetup support

[Cyril Brulebois]

Control: severity -1 important

Cyril Brulebois  (2023-01-08):
> I'm seeing at least two problems with cryptsetup while testing daily
> builds:
>  - with 6.1.0-1 (currently getting into the archive), my very usual 1G
>RAM / 5G storage setup can no longer get an automated encrypted LVM
>setup created: cryptsetup triggers the OOMK while creating the
>encrypted storage; that doesn't happen with 6.0.0-6. Not sure
>cryptsetup itself is the culprit, it might just be more components or
>heavier components on the kernel side, pushing memory to the limit.
>  - with either kernel (and 1G RAM for 6.0.0-6, 2G RAM for 6.1.0-1 due
>to the first point), I cannot boot into the installed system: I'm not
>getting the LVM passphrase prompt, and the root device is therefore
>missing.
> 
> I haven't investigated either issue, and I'm not sure when I'll be able
> to. Help welcome.
> 
> The first point could be waved aside with an errata entry; the second
> point is going to be a blocker for the next release.

Trying to investigate the second one, I cannot replicate my earlier
results, with either a clean unstable daily build using 6.1.0-1 or with
D-I Bookworm Alpha 1; and besides cryptsetup uploads in early December,
I must admit a quick look around didn't suggest anything obvious that
could explain what I were getting… Bad luck, maybe; lowering severity
accordingly for the time being.


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


signature.asc
Description: PGP signature

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Daniel Swarbrick]

Hi Eric,

Thanks for the detailed bug report. As this is something which can 
theoretically affect _any_ apt-based distributed (i.e., derivatives of 
Debian), I feel that it should ideally be reported upstream.


I personally run this textfile collector on a Debian bookworm system, as 
well as apticron - so this is (I think) a similar scenario where two 
independent processes are periodically updating the apt cache, and I 
wondered whether that was wise or not. I have seen the textfile 
collector block only once so far.


The apt.sh script which apt_info.py replaces only executed "apt-get 
--just-print" - so even if executed as root, it never tried to update 
the apt cache. In fact, unless you had something else like apticron to 
periodically update the apt cache, apt.sh would return stale information.


I guess that a simple workaround would be to tweak the systemd service 
so that apt_info.py is executed as an unprivileged user, which would be 
unable to update the cache, and theoretically avoid any potential for a 
deadlock. Perhaps a recommendation to the upstream developer could be 
made, e.g. to add a command-line argument to the script so that it 
wouldn't try to update the cache even when executed as root.


Best,
Daniel



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028269: mender-connect FTBFS: test failures

[Adrian Bunk]

Source: mender-connect
Version: 2.1.0+ds1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=mender-connect=2.1.0%2Bds1-2

...
task-0: --- FAIL: TestPermit_DownloadFile (0.00s)
task-0: --- PASS: TestPermit_DownloadFile/not_a_regular_file (0.00s)
task-0: --- PASS: TestPermit_DownloadFile/not_in_a_chroot (0.00s)
task-0: --- PASS: TestPermit_DownloadFile/file_owner_mismatch (0.00s)
task-0: --- FAIL: TestPermit_DownloadFile/file_owner_match (0.00s)
task-0: --- PASS: TestPermit_DownloadFile/file_group_mismatch (0.00s)
task-0: --- PASS: TestPermit_DownloadFile/file_group_match (0.00s)
task-0: --- PASS: 
TestPermit_DownloadFile/over_the_max_file_size_limit_in_bytes (0.00s)
task-0: --- PASS: 
TestPermit_DownloadFile/below_the_max_file_size_limit_in_bytes (0.00s)
...
task-0: --- FAIL: TestPermit_UploadFile (0.00s)
task-0: --- PASS: 
TestPermit_UploadFile/over_the_max_file_size_limit_in_bytes (0.00s)
task-0: --- PASS: TestPermit_UploadFile/not_in_a_chroot (0.00s)
task-0: --- PASS: TestPermit_UploadFile/forbidden_to_follow_links (0.00s)
task-0: --- PASS: TestPermit_UploadFile/file_exists_forbidden_to_overwrite 
(0.00s)
task-0: --- PASS: TestPermit_UploadFile/file_exists_allowed_to_overwrite 
(0.00s)
task-0: --- PASS: 
TestPermit_UploadFile/file_exists_allowed_to_overwrite_owner_mismatch (0.00s)
task-0: --- FAIL: 
TestPermit_UploadFile/file_exists_allowed_to_overwrite_owner_match (0.00s)
task-0: --- PASS: 
TestPermit_UploadFile/file_exists_allowed_to_overwrite_group_mismatch (0.00s)
task-0: --- PASS: 
TestPermit_UploadFile/file_exists_allowed_to_overwrite_group_match (0.00s)
task-0: --- PASS: TestPermit_UploadFile/suid_bit_not_allowed_in_modes 
(0.00s)
task-0: --- PASS: TestPermit_UploadFile/suid_bit_allowed_in_modes (0.00s)
...

Bug#1028172: tiledarray: FTBFS in unstable

[Adrian Bunk]

Control: reassgn -1 libmpich-dev 4.0.2-2
Control: retitle -1 libmpich-dev lacks dependencies required by its pkgconfig 
file
Control: affects -1 src:tiledarray

On Sat, Jan 07, 2023 at 05:03:01PM -0800, Steve Langasek wrote:
> Source: tiledarray
> Version: 1.0.0-1
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu lunar
>...
> CMake Error at /usr/share/cmake-3.25/Modules/CMakeTestCXXCompiler.cmake:63 
> (message):
>   The C++ compiler
> 
> "/usr/bin/c++"
> 
>   is not able to compile a simple test program.
> 
>   It fails with the following output:
> 
> Change Dir: 
> /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98
> 
> Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_d2ec9/fast && 
> gmake[2]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98'
> /usr/bin/gmake  -f CMakeFiles/cmTC_d2ec9.dir/build.make 
> CMakeFiles/cmTC_d2ec9.dir/build
> gmake[3]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98'
> Building CXX object CMakeFiles/cmTC_d2ec9.dir/testCXXCompiler.cxx.o
> /usr/bin/c++   -I/usr/include/x86_64-linux-gnu/mpich  -o 
> CMakeFiles/cmTC_d2ec9.dir/testCXXCompiler.cxx.o -c 
> /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98/testCXXCompiler.cxx
> Linking CXX executable cmTC_d2ec9
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_d2ec9.dir/link.txt 
> --verbose=1
> /usr/bin/c++ -I/usr/include/x86_64-linux-gnu/mpich  -lmpich -lpthread 
> -lhwloc -lucp -lucs -lrt  CMakeFiles/cmTC_d2ec9.dir/testCXXCompiler.cxx.o -o 
> cmTC_d2ec9 
> /usr/bin/ld: cannot find -lhwloc: No such file or directory
> /usr/bin/ld: cannot find -lucp: No such file or directory
> /usr/bin/ld: cannot find -lucs: No such file or directory
> collect2: error: ld returned 1 exit status
> gmake[3]: *** [CMakeFiles/cmTC_d2ec9.dir/build.make:99: cmTC_d2ec9] Error 
> 1
> gmake[3]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98'
> gmake[2]: *** [Makefile:127: cmTC_d2ec9/fast] Error 2
> gmake[2]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-I8ie98'
> [...]
> 
>   
> (https://buildd.debian.org/status/fetch.php?pkg=tiledarray=amd64=1.0.0-1=1673126398=0)
> 
> 
> Possibly an issue in a build-dependency, I see that these library options
> come from the output of `pkg-config --libs-only-l mpi` but libmpich-dev
> apparently doesn't depend on the packages providing the libs in its output.

Thanks for the analysis.

I am reassigning this to libmpich-dev, which either needs to add 
package dependencies on
  libhwloc-dev, libucx-dev
or remove the libraries from Libs:

$ grep ^Libs /usr/lib/x86_64-linux-gnu/pkgconfig/mpich.pc
Libs:  -Wl,-z,relro -L${libdir} -lmpich   -lpthread  -lhwloc -lucp -lucs -lrt 
$

cu
Adrian

Bug#1024239: libequihash: baseline violation on i386 and FTBFS on !x86

[Adrian Bunk]

Hi Joost,

sorry for the late reply.

On Thu, Dec 29, 2022 at 03:43:18PM +0100, Joost van Baal-Ilić wrote:
> 
> 
> Thanks, after consulting with upstream this should be fixed in new upstream
> https://github.com/stef/equihash/archive/refs/tags/v1.0.3.tar.gz which has
> https://github.com/stef/equihash/commit/0806afadf99837519469449c55dc425763e8eef7
> .  I'll upload a new package soonishlish.

a second baseline violation I missed in my original bug report is
-march=native, which FTBFS on some architectures and where it builds
the package would only run on hardware compatible with whatever buildd
did build the package (on amd64 this also means either on AMD or on 
Intel hardware).

Regarding the binary-any FTBFS, this can be reproduced in a chroot
with "dpkg-buildpackage -B".

sbuild has a --no-arch-all option that might do the same (untested).

python3-equihash is the binary-all package, what seems to fail is 
debian/rules trying to build it in binary-any-only builds.

> Bye,
> 
> Joost

cu
Adrian

Bug#1028268: libequihash: binary-any FTBFS

[Adrian Bunk]

Source: libequihash
Version: 1.0.4-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libequihash=amd64=1.0.4-2=1673222447=0

...
   dh_install -a -O-ppython3-equihash -O--buildsystem=pybuild 
-O--sourcedirectory=python
Failed to copy 'usr/lib/libequihash.a': No such file or directory at 
/usr/share/dh-exec/dh-exec-install-rename line 68, <> line 3.
dh_install: error: debian/libequihash-dev.install (executable config) returned 
exit code 127
make: *** [debian/rules:18: binary-arch] Error 25

Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs

[Thorsten Glaser]

On Mon, 9 Jan 2023, Lorenzo Puliti wrote:

>This package "only" recommands e2fsprogs, so I think it should just

fsck is util-linux, not e2fsprogs.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs

[Lorenzo Puliti]

Package: initscripts
Version: 3.06-2
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Hi all,

there are 2 scripts that run fsck without testing if the command
is available in the system: checkroot.sh and checkfs.sh
This package "only" recommands e2fsprogs, so I think it should just
print a warning and go ahead if fsck is not available.
The current behaviour can fail to boot in some cases
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028181

Lorenzo



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

Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages initscripts depends on:
ii  sysv-rc 3.06-2
ii  sysvinit-utils  3.06-2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.6~rc1-1+b1
ii  psmisc 23.6-1

initscripts suggests no packages.

-- Configuration Files:
/etc/init.d/mountall.sh changed [not included]

-- no debconf information

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/8/23 12:36, Richard B. Kreckel wrote:

I am unfamiliar with GitLab. Sorry.


Well, then I thought that could give it a try...

Is there a simple walk-through what to do to create salsa MRs in a case 
like this package?


(I've spent the whole Sunday now and I'm giving up frustrated by the 
existing documentation now.)


  -richard.

Bug#1028251: Updated Patch (Was: xen: FTBFS when building xen binary packages for sid on x86_64)

[Chuck Zmudzinski]

Sorry, the patch I posted in the original message will not apply properly.
I forgot I also edited the comment:

Here is the correct patch:

--- rules    2022-12-21 16:34:51.0 -0500
+++ rules.new    2023-01-08 05:31:24.0 -0500
@@ -327,9 +327,9 @@
     | xargs -0r gzip -9vn
 
 # By default, files in debian/tmp which are not handled by anything
-# in rules are ignored.  This makes them into errors.
+# in rules are ignored.  This lists them.
 override_dh_missing:
-    dh_missing --fail-missing
+    dh_missing --list-missing
 
 
 # We are dropping the config file /etc/default/xen which appeared in
--snip--

Thanks for all your work. Apart from this little problem, it
appears Xen 4.17 will work well on Bookworm.

Kind regards,

Chuck

Bug#1028265: nvidia-graphics-drivers-tesla-450: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla-450
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028264: nvidia-graphics-drivers-tesla-418: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla-418
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028263: nvidia-graphics-drivers-tesla-510: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla-510
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028262: nvidia-graphics-drivers-tesla-460: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla-460
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028261: nvidia-graphics-drivers-tesla-470: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla-470
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028260: nvidia-graphics-drivers-tesla: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers-tesla
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028259: nvidia-graphics-drivers: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nvidia-graphics-drivers
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450

pt_BR.po.gz
Description: application/gzip

Bug#1028258: ddcci-dkms: Module fails to build for kernel 6.1

[Carl Suster]

Package: ddcci-dkms
Version: 0.4.2-3
Severity: important

Dear Maintainer,

The ddcci module failed to build with linux-headers-6.1.0-1-common:

DKMS make.log for ddcci-0.4.2 for kernel 6.1.0-1-amd64 (x86_64)
Mon 09 Jan 2023 09:26:34 AEDT
make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build'
make -C "ddcci"
make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make -C "/lib/modules/6.1.0-1-amd64/build" 
M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules
make[2]: Entering directory '/usr/src/linux-headers-6.1.0-1-amd64'
  CC [M]  /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: error: 
initialization of ‘void (*)(struct i2c_client *)’ from incompatible pointer 
type ‘int (*)(struct i2c_client *)’ [-Werror=inc>
 1813 | .remove = ddcci_remove,
  |   ^~~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: note: (near 
initialization for ‘ddcci_driver.remove’)
cc1: some warnings being treated as errors
make[3]: *** 
[/usr/src/linux-headers-6.1.0-1-common/scripts/Makefile.build:255: 
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o] Error 1
make[2]: *** [/usr/src/linux-headers-6.1.0-1-common/Makefile:2017: 
/var/lib/dkms/ddcci/0.4.2/build/ddcci] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-1-amd64'
make[1]: *** [Makefile:38: ddcci.ko] Error 2
make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make: *** [Makefile:28: ddcci] Error 2
make: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build'


It looks like this is not yet fixed upstream: 
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/issues/31


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 ddcci-dkms depends on:
ii  dkms  3.0.9-1

ddcci-dkms recommends no packages.

ddcci-dkms suggests no packages.

-- no debconf information

Bug#1027117: iem-plugin-suite: FTBFS: error: ‘class juce::AudioProcessorPlayer’ has no member named ‘audioDeviceIOCallback’; did you mean ‘AudioIODeviceCallback’?

[Debian/GNU]

On Wed, 28 Dec 2022 00:22:07 +0100 Sebastian Ramacher 
 wrote:

Source: iem-plugin-suite
Version: 1.13.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org



upstream is a aware of this and is currently preparing a new release 
that supports JUCE-7.0.3


i'm pretty confident we will make it in time for the freeze.

gfmdy
IOhannes

Bug#1028257: sympa: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: sympa
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028256: nagvis: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: nagvis
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#903999: RFC about DFSG-freeness of PHP license [Re: Bug#903999: ITP: php-doc -- Documentation for PHP]

[Nicholas D Steeves]

Hi Athos,

Thank you for working on this RFP, and for doing all the work involved
with reintroduction the package.

I'm CCing the debian-legal team who I hope will be able to help with
the stylesheet question and related issues; I've given it my
best-effort, but would appreciate someone else's perspective

My reply, in context, follow inline:

Athos Ribeiro  writes:

> On Wed, Sep 28, 2022 at 08:11:14AM +0800, Paul Wise wrote:
>>On Mon, 2022-09-26 at 16:23 -0300, Athos Ribeiro wrote:
>>
>>> As mentioned in the original report (RFP), this package was
>>> originally removed from the archive due to Bug #821695, when it was
>>> not updated during the PHP 7 transition.
>>
>>If you weren't already aware, please note the extra steps needed when
>>reintroducing packages that were removed from Debian (e.g. bug reopen):
>>
>>https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
>
> Hi Paul, Thanks for the pointers.
>
> While I am working on packaging details, I still want to make sure it is
> OK to re-introduce the package due to the PHP-3.0 issues I pointed
> before.
>

Do you mean the PHP-3.0[-only] issue:

  https://lintian.debian.org/tags/license-problem-php-license

which appears to be the same as the PHP-3.1[-or-greater?] issue?

  https://ftp-master.debian.org/php-license.html

Is the problem you're referring appears to be that this license places
limitations on the use of the term "PHP"?  Were this limitation on
endeavour, it would be non-DFSG, but honestly I'm a bit surprised that
php8.1 is in Debian main...eg: that it's DFSG-free.  I'm also not sure
why the Apache license isn't problematic for this same reason.

At any rate, as far as I can tell this is something for the ftpmasters
to worry about, so long as you follow the instructions at the above two
links as well as consulting the PHP package for examples.  Ie this means
is that the debian/ subdir must have a more permissive license than the
PHP one (eg: Expat).

> On top of that, I needed to change one of the build time internal
> dependencies so we wouldn't end up with (hundreds of) broken links. This
> led to the need of clarification on
> https://github.com/php/web-php/issues/711 by the upstream project.
> If the stylesheets provided are indeed proprietary, I will need to write
> our own.
>

Oh my!  Yes, after reading that issue (quoted below):

>> The following files are referred to and fetched from phd when
>> building with the PHP package (in
>> phpdotnet/phd/Package/PHP/ChunkedXHTML.php):
>>
>>   https://www.php.net/styles/theme-base.css (styles/theme-base.css)
>>   https://www.php.net/styles/theme-medium.css (styles/theme-medium.css)
>>

The copyright text on the PHP website is

Except as otherwise indicated elsewhere on this Site, you are free
to view, download and print the documents and information available
on this Site subject to the following conditions:

  * You may not remove any copyright or other proprietary notices contained
in the documents and information on this Site.

  * The rights granted to you constitute a license and not a
transfer of title.

  * The rights specified above to view, download and print the
documents and information available on this Site are not
applicable to the graphical elements, design or layout of this
Site. These elements of the Site are protected by trade dress
and other laws and may not be copied or imitated in whole or in
part.
(https://www.php.net/copyright)

To me it sounds like 1. No rights to redistribute the website (in whole
or in part) are granted, except where the part is a separate project
with its own license (php-docs).  2. No one has a license to view,
download, or print the stylesheets.

Were the second claim to be maintained, a consequence of this would
seems to be that only the copyright holder[s] could build the
unpatched documentation without committing copyright infringement.

>> While the phd project is shipped under MIT/BSD licenses, web-php and
>> its files
>> have no other license notices other than the notice on copyright.php
>> which says that the design and layout of php.net is protected by
>> trade dress and should not be copied nor imitated. Does this apply to
>> both files above? In special, styles/theme-base.css seems to be
>> derived from bootstrap, and the apache license disclaimer was
>> kept. Is it still ditributed through the apache license then?

Good point; however, the Apache license allows relicensing (so long as
various conditions are met).  Were the PHP project to not do this, they
would be in breach of the Apaache license, and we still wouldn't be able
to redistribute.

Given the copyright notice published to the PHP website, I think you're
right about how the only workaround is to replace their stylesheets!
Please note that network access is blocked during the builds of all
Debian packages (packages in non-free are not part of Debian).

I also 

Bug#1028255: wdm: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: wdm
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028254: hippotat build is not reproducible in compiled Rust

[Ian Jackson]

Package: hippotat
Verson: 1.1.3
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Unfortunately, the build is not reproducible.  I don't know why.
The build definitely captures the build path.

I'm filing this bug to record my investigations and what I have
found.  But I don't know what my next steps are.


diffoscope
--

I looked at the tests.reproducible-builds.org output (for 1.1.3):
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hippotat.html
There's a lot of differences in binary code there but that could just
be byte offsets.  The strings diff shows the build path being
captured
  /build/1st/hippot1.1.3/src/config.rs

That filename is in the hippotat tree so it doesn't seem like this
ought to be the fault of some dependency crate.  Many of the other
filenames in the hippotat source tree appear there too.

I grepped the source for uses of "file!", but there weren't any.
(I doubt I would have made such a mistake; this whole Rust codebase
postdates my awareness of the need for reproducibility.)

I ran "cargo expand" (using upstream dependencies and a nightly
compiler) with --lib and --bin hippotat.  The output does not contain
either (a) the build path (b) any invocztions of unexpanded ! macros.


grep for captured path
--

I ran the Debian package build (manually set up sid chroot,
dpkg-buildpackage -uc -b) and grepped the target/ directory:

$ grep --exclude={\*.d,root-output,output,stderr,\*.rmeta} -lR 
/volatile/rawcargo target/ 
target/x86_64-unknown-linux-gnu/release/hippotatd
target/x86_64-unknown-linux-gnu/release/libhippotat.rlib
target/x86_64-unknown-linux-gnu/release/hippotat
target/x86_64-unknown-linux-gnu/release/deps/libtypenum-35b30b82f1b581e3.rlib
target/x86_64-unknown-linux-gnu/release/deps/hippotatd-816f104fd34c8e22
target/x86_64-unknown-linux-gnu/release/deps/hippotat-217cbc019ba3f5c7
target/x86_64-unknown-linux-gnu/release/deps/libhippotat-4b0cf61fee6d94b1.rlib
target/release/libhippotat_macros.so
target/release/deps/libnum_bigint-9e9ff3efb7aa6776.rlib
target/release/deps/libhippotat_macros-eb0640ebce7c05b7.so
target/release/deps/libhippotat_macros-92a972e6f986fd5e.so
$

strings on libtypenum-35b30b82f1b581e3.rlib shows consts.rs.  I got
the source for typenum (from the Debian package) and found that
consts.rs is generated by a cargo build script.  The file consts.rs
itself doesn't capture the path, nor does it invoke any ! macros.

strings on libhippotat_macros.so shows it having captured some parent
of the build directory.  But I don't think anything in there ought to
matter since this io is a proc macro crate - it doesn't end up in the
.deb.


build runes
---

Because hippotat's build system is not like a standard Debian Rust
package, I suspected I might have missed something that the standard
Debian Rust tooling would do.

So I used another package as a comparator.  A contributor on
#debian-rust suggested ripgrep.  So I checked and the rust-ripgrep
source package is currently reported to build reproducibly.

So I looked at the build logs.  I compared:

* The diagnostic output from the Debian cargo wrapper.  This was
  completely identical, showing that my way of invoking thigns is
  indeed using the cargo wrapper.

* One of the rustc command lines.  I chose proc_macro2 arbitrarily.
  These wouldn't be expected to be identical but they were quite
  similar.  Here's a wdiff with the changed parts nicely highlighted:

 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=proc_macro2

[-CARGO_MANIFEST_DIR=/usr/share/cargo/registry/proc-macro2-1.0.47-]

{+CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/proc-macro2-1.0.47+}

CARGO_PKG_AUTHORS='David Tolnay :Alex
Crichton ' [many unchanged things elided] 
CARGO_PKG_VERSION_PRE='' 

[-LD_LIBRARY_PATH='/<>/target/release/deps:/usr/lib' 
OUT_DIR=/<>/target/release/build/proc-macro2-e08ec009b342643f/out-]
{+LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' 
OUT_DIR=/<>/target/debug/build/proc-macro2-9cccbb8dcf1ff8a7/out+}

rustc --crate-name proc_macro2 --edition=2018

[-/usr/share/cargo/registry/proc-macro2-1.0.47/src/lib.rs-]
{+/<>/debian/cargo_registry/proc-macro2-1.0.47/src/lib.rs+}

--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib 
--emit=dep-info,metadata,link -C embed-bitcode=no

-C [-debug-assertions=off-]
   {+debuginfo=2+}

--cfg 'feature="default"' --cfg 'feature="proc-macro"'

-C [-metadata=ab9fbb9c9680acee-]
   {+metadata=aa8ae3518bc48afa+}
-C [-extra-filename=-ab9fbb9c9680acee-]
   {+extra-filename=-aa8ae3518bc48afa+}
--out-dir [-/<>/target/release/deps-]
{+/<>/target/debug/deps+}
-L [-dependency=/<>/target/release/deps-]
   {+dependency=/<>/target/debug/deps+}
  

Bug#1028253: cryptsetup-nuke-password: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: cryptsetup-nuke-password
Version: 4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for cryptsetup-nuke-password's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


cryptsetup-nuke-password_4_pt.po.gz
Description: application/gzip

Bug#1015173: ITP: pwncat -- reverse shell handler with all netcat features

[Marcos Talau]

The issue [1] must be fixed to this package be introduced on Debian.

[1] https://github.com/cytopia/pwncat/issues/119


signature.asc
Description: PGP signature

Bug#1028252: tomlplusplus FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: cmark-gfm:native

[Adrian Bunk]

Source: tomlplusplus
Version: 3.2.0+ds-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: b...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=tomlplusplus=ppc64el=3.2.0%2Bds-1=1673204586=0

...
dpkg-checkbuilddeps: error: Unmet build dependencies: cmark-gfm:native
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)



cmark-gfm is not Multi-Arch: allowed

Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64

[Chuck Zmudzinski]

Source: xen
Version: 4.17.0-1
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

Hi,

I needed to test a patch to libxl so I started by trying to build
xen from source on an up-to-date sid installation.

The build failed:

   debian/rules override_dh_missing
make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0'
dh_missing --list-missing
dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in debian/tmp but 
is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in debian/tmp 
but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service 
exists in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xenconsoled.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xendomains.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service exists in 
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/systemd/system/xenstored.service exists in 
debian/tmp but is not installed to anywhere

Please note that this output is after editing the
line in debian/rules that is currently

dh_missing --fail-missing

with

dh_missing --list-missing

so the missing files only induce a warning instead of FTBFS.

So the workaround is this patch to debian/rules:

--- a/debian/rules  2023-01-08 16:36:01.605863417 -0500
+++ b/debian/rules  2023-01-08 05:31:24.0 -0500
@@ -329,7 +329,7 @@
 # By default, files in debian/tmp which are not handled by anything
 # in rules are ignored.  This lists them.
 override_dh_missing:
-   dh_missing --fail-missing
+   dh_missing --list-missing


 # We are dropping the config file /etc/default/xen which appeared in
---snip-

I presume you know about this and plan to fix it before the
next upload, but perhaps a recent systemd update is causing
this so I am reporting it here.

I also request that if the missing systemd files cannot be
installed properly before the next upload of a new version
you apply a workaround such as this patch or another workaround
until the missing systemd files are installed and configured
correctly.

Kind regards,

Chuck

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

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

AppArmor: enabled

Bug#1028250: debian-installer: broken cryptsetup support

[Cyril Brulebois]

Package: debian-installer
Severity: serious
Justification: not releasable

Hi,

I'm seeing at least two problems with cryptsetup while testing daily
builds:
 - with 6.1.0-1 (currently getting into the archive), my very usual 1G
   RAM / 5G storage setup can no longer get an automated encrypted LVM
   setup created: cryptsetup triggers the OOMK while creating the
   encrypted storage; that doesn't happen with 6.0.0-6. Not sure
   cryptsetup itself is the culprit, it might just be more components or
   heavier components on the kernel side, pushing memory to the limit.
 - with either kernel (and 1G RAM for 6.0.0-6, 2G RAM for 6.1.0-1 due
   to the first point), I cannot boot into the installed system: I'm not
   getting the LVM passphrase prompt, and the root device is therefore
   missing.

I haven't investigated either issue, and I'm not sure when I'll be able
to. Help welcome.

The first point could be waved aside with an errata entry; the second
point is going to be a blocker for the next release.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1028249: warzone2100: Missing build dependency on libopus-dev

[Adrian Bunk]

Source: warzone2100
Version: 4.3.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=warzone2100=ppc64el=4.3.3-1=1673202563=0

...
CMake Error at 
/usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Opus (missing: OPUS_LIBRARY OPUS_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/FindOpus.cmake:23 (find_package_handle_standard_args)
  lib/sound/CMakeLists.txt:25 (find_package)


-- Configuring incomplete, errors occurred!

Bug#1027044: transition: numpy 1.24.x

[Sandro Tosi]

> The last packages involved in the Python 3.11 rebuilds build-depending
> on numpy have now built on all architectures.
>
> Please go ahead.

thanks! numpy/1.24.1-2 has been accepted in unstable and the pending
bugs severity has been bumped to serious.

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

Bug#1022311: python-stdnum: FTBFS: AssertionError: Failed doctest test for test_no_fodselsnummer.doctest

[Santiago Vila]

reopen 1022311
found 1022311 1.16-1
found 1022311 1.17-1
fixed 1022311 1.18-1
thanks

El 13/11/22 a las 22:45, Arthur de Jong escribió:

If this ever needs to be backported for some reason the fix is trivial:
https://arthurdejong.org/git/python-stdnum/commit/?id=1003033fa0e97726d92f47231f96cf02fb35869a


Hi. I'm reopening this bug because it also happens in bullseye (exactly as 
described by Lucas),
and packages in stable must build in stable.

I attach a proposal to fix this in bullseye, in the form of debdiff against
version 1.16-1, the current version in bullseye.

(Fortunately, since you pointed at the exact commit fixing it, producing this
debdiff was trivial)

If you have never made an upload for stable, the procedure is explained here:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

Thanks.diff -Nru python-stdnum-1.16/debian/changelog 
python-stdnum-1.16/debian/changelog
--- python-stdnum-1.16/debian/changelog 2021-02-06 17:52:07.0 +0100
+++ python-stdnum-1.16/debian/changelog 2023-01-08 22:39:00.0 +0100
@@ -1,3 +1,9 @@
+python-stdnum (1.16-1+deb11u1) bullseye; urgency=medium
+
+  * Update Fødselsnummer test case for date in future. Closes: #1022311.
+
+ -- Arthur de Jong   Sun, 08 Jan 2023 22:39:00 +0100
+
 python-stdnum (1.16-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru python-stdnum-1.16/debian/patches/series 
python-stdnum-1.16/debian/patches/series
--- python-stdnum-1.16/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ python-stdnum-1.16/debian/patches/series2023-01-08 22:36:43.0 
+0100
@@ -0,0 +1 @@
+the-future-was-now.patch
diff -Nru python-stdnum-1.16/debian/patches/the-future-was-now.patch 
python-stdnum-1.16/debian/patches/the-future-was-now.patch
--- python-stdnum-1.16/debian/patches/the-future-was-now.patch  1970-01-01 
01:00:00.0 +0100
+++ python-stdnum-1.16/debian/patches/the-future-was-now.patch  2023-01-08 
22:36:43.0 +0100
@@ -0,0 +1,28 @@
+From 1003033fa0e97726d92f47231f96cf02fb35869a Mon Sep 17 00:00:00 2001
+From: Arthur de Jong 
+Date: Wed, 19 Oct 2022 21:06:27 +0200
+Subject: =?UTF-8?q?Update=20F=C3=B8dselsnummer=20test=20case=20for=20date?=
+ =?UTF-8?q?=20in=20future?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The future was now. This problem was pushed forwards to October 2039.
+---
+ tests/test_no_fodselsnummer.doctest | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tests/test_no_fodselsnummer.doctest
 b/tests/test_no_fodselsnummer.doctest
+@@ -91,9 +91,9 @@
+ Traceback (most recent call last):
+   ...
+ InvalidComponent: This number is an FH-number, and does not contain birth 
date information by design.
+->>> fodselsnummer.validate('19102270846')
++>>> fodselsnummer.validate('18103970861')
+ Traceback (most recent call last):
+-  ...
++  ...
+ InvalidComponent: The birth date information is valid, but this person has 
not been born yet.
+ 
+ 

Bug#986152: Offer of help

[Jeremy Sowden]

On 2023-01-08, at 14:35:17 +, Jeremy Sowden wrote:
> On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote:
> > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden  wrote:
> > > I've imported my fork of Roberto's SF repo to Salsa:
> > >
> > >   https://salsa.debian.org/azazel/shorewall
> > >
> > > I haven't touched it in 18 months, so I'll give it a polish when I have
> > > some time, and perhaps we can use it as a starting point.
> > 
> > Thanks. I created a Salsa team and repo here:
> > https://salsa.debian.org/shorewall-team/shorewall and added you both
> > as co-owners.
> 
> Thanks.  I've created a Shorewall team on tracker.d.o and added you both
> to it.
> 
> > I felt more comfortable using Roberto's original SF repo as a starting
> > point, and merging in your changes after review. I can do that in the
> > next few days, the freeze is coming up very soon and I would like to
> > have the new upstream in bookworm. If you have further changes please
> > push them to your repo.
> 
> Cool.  I've started making a few more changes to my repo.  I'll let you
> know when I've pushed everything to Salsa.  Should be later this week.

I've pushed the recent changes.  It's just mechanical updates and
Lintian fixes.  I haven't taken a proper look at bugs.debian.org yet.

> > I'll also configure the CI on Salsa to have all the usual QA tools run
> > automatically on each push.
> > 
> > Did you find a practical way to do changes across all seven source
> > packages at once?
> 
> Not yet.  Atm, I've just been updating the shorewall/master branch then
> cherry-picking those commits into the other branches.  Once 5.2.8-1 is
> ready to go, perhaps we can come up with a way to get everything into
> one source package with one master branch.

J.


signature.asc
Description: PGP signature

Bug#1004514: grub-common: background images don't work with luks encrypted lvm root partition

[Tuxicoman]

Package: grub2-common
Version: 2.06-7
Followup-For: Bug #1004514

Dear Maintainer,

I just made a fresh Debian install using testing installer and confirm the bug
is still here : no background in GRUB after install.

My setup is LUKS2/LVM2/BTRFS.

The problem is the background picture file is not copied in /boot whereas it
obviously can't access it due to encryption of /.

$ grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png
lvm

I used the partitioning assistant in the Debian installer to encrypt my
filesystem. The only thing I changed from the proposed setup is EXT4 -> BTRFS.

I think this is an important issue to not let users consider Debian is easy to
use.

Encryption is supposed to be widely used for laptops as they are likely to be
stolen/lost.

And starting you nice looking laptop with GRUB without background is not very
selling the Debian OS.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/mib--vg-root / btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@rootfs 0 0
/dev/sdc2 /boot ext2 rw,relatime 0 0
/dev/sdc1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod lvm
insmod btrfs
set 
root='lvmid/7AKu5o-EyeN-N8St-I649-OQcl-Bri3-W8OFoK/RMwWFW-eDh3-qpQV-2eeH-6fq7-F5Ne-eTOidI'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/7AKu5o-EyeN-N8St-I649-OQcl-Bri3-W8OFoK/RMwWFW-eDh3-qpQV-2eeH-6fq7-F5Ne-eTOidI'
  4b9d4135-8a81-4a81-b961-3b8954c9305f
else
  search --no-floppy --fs-uuid --set=root 4b9d4135-8a81-4a81-b961-3b8954c9305f
fi
font="/@rootfs/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=fr_BE
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd2,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 
--hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  
ced76384-4e5b-411c-a30c-c7f1f5344fb9
else
  search --no-floppy --fs-uuid --set=root ced76384-4e5b-411c-a30c-c7f1f5344fb9
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-4b9d4135-8a81-4a81-b961-3b8954c9305f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd2,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 
--hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  
ced76384-4e5b-411c-a30c-c7f1f5344fb9
else
  search --no-floppy --fs-uuid --set=root 
ced76384-4e5b-411c-a30c-c7f1f5344fb9
fi
echo'Loading Linux 6.0.0-6-amd64 ...'
linux   /vmlinuz-6.0.0-6-amd64 root=/dev/mapper/mib--vg-root ro 

Bug#1019799: Proposed MBF: wxwidgets3.2 transition

[Scott Talbert]

On Thu, 15 Sep 2022, gregor herrmann wrote:


On Thu, 15 Sep 2022 15:13:24 -0400, Scott Talbert wrote:


And we are getting further, configure passes, then the actual build
fails:

…

So, hm, yeah, I guess this needs some more fixes and some more
knowledge about wxWidegts …



Thanks for your work so far.  I'll try to take a stab at it...


Great, thank you!

(The preliminary patch is in git:
https://salsa.debian.org/perl-team/modules/packages/libwx-perl )


Hi,

I just submitted a PR [1] with a patch to move libwx-perl to wxWidgets 
3.2.  I tested with a few of libwx-perl's rdeps (kephra, unifont-bin, 
eekboek-gui [as much as I could understand it]), and I didn't notice any 
obvious problems.


Regards,
Scott

[1] 
https://salsa.debian.org/perl-team/modules/packages/libwx-perl/-/merge_requests/1

Bug#1028248: transition: bullet

[Markus Koschany]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: a...@debian.org

Hello,

I would like to request a transition slot for Bullet 3.24 which is
already available in experimental.

I have successfully rebuilt all reverse-dependencies except of
siconos (#1024864) and gazebo (#1004795,1011657) which fail for
different reasons.

dart is the only source package which fails to build from source
because of one failing test. Since the package builds otherwise fine,
I believe it should be as simple as updating the unittest. According
to dart's changelog test_SkelParser has been flaky in the past. I have
filed Debian bug #1028247 to discuss this problem with dart's
maintainer.

The complete list of reverse-dependencies:

dart
gazebo
hkl
ignition-physics
jskeus
openmw
ros-geometry
ros-geometry2
siconos

Ben file:

title = "bullet";
is_affected = .depends ~ "bullet3.06" | .depends ~ "bullet3.24";
is_good = .depends ~ "bullet3.24";
is_bad = .depends ~ "bullet3.06";


Regards,

Markus

Bug#1028246: transition: liquid-dsp

[Adrian Bunk]

On Sun, Jan 08, 2023 at 10:11:46PM +0100, Andreas Bombe wrote:
>...
> i386 only, where some
> floats don't match exactly, which I'm still investigating.
>...

That's "better" results due to x87 excess precison.

The patch below fixes the tests for me.

cu
Adrian

--- debian/rules.old2023-01-08 21:43:47.055686585 +
+++ debian/rules2023-01-08 21:44:09.335667591 +
@@ -2,6 +2,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifeq ($(DEB_HOST_ARCH_CPU),i386)
+  export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
+endif
+
 %:
dh ${@}
 

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi,

yes, I will take care of those, I’m just uploading them in batches as the 
dependencies require. I’ll check all the errors tomorrow. It was just Sunday, 
so I was not sitting by the computer. I expect to have everything solved next 
week.

The Breaks have been added there since the last transition - there was a 
tendency for the apt dependency solver to pick one package (say php-imagick) 
from old PHP version and other one from new PHP version (say php-mysql). The 
Breaks was the only solution we came with that worked. I can dig up some old 
issues from the last transition.

Ondrej 
--
Ondřej Surý  (He/Him)

> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
> 
> Control: severity 1023370 serious
> Control: severity 1023381 serious
> 
> Hi Ondřej,
> 
>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>>> On 12/15/22 20:15, Ondřej Surý wrote:
>>> I think everything is mostly ready in experimental. I'll try to sort out
>>> the rest of the missing extensions over the weekend (imagick, memcached,
>>> redis and maybe few others).
>> php-igbinary needs to be moved to unstable, php-apcu is built & installed on 
>> all release architectures.
>> php-raphf is also built & installed on all release architectures, but 
>> php-pecl-http was not staged in experimental and will need to pass NEW.
>> php-memcached and php-redis were not uploaded to experimental either.
> 
> I have a couple of questions:
> 
> I'm seeing that php-common has a Breaks on php8.1-common. Why is that? Is 
> that really needed? It makes the migration a bit more complicated as it means 
> that php8.1 has to be removed at the same time that php-common migrates.
> 
> Will you also take care of src:xdebug, next to php-pecl-http, php-memcached 
> and php-redis as Bas suggested?
> 
> Paul

Bug#1028243: dexdump: symbol lookup error: /.../libart.so.0: undefined symbol

[Jochen Sprickerhof]

Hi Philipp,

* Philipp Marek  [2023-01-08 20:46]:

ii  android-libart   11.0.0+r48-4
ii  android-libbacktrace 1:33.0.1-1~exp9
ii  android-libbase  1:33.0.1-1~exp9
ii  android-liblog   1:33.0.1-1~exp9
ii  android-libnativeloader  1:11.0.0+r48-4
ii  android-libziparchive1:33.0.1-1~exp9


Seems like you are mixing unstable and experimental. Please try with the 
packages from unstable (version 1:29.0.6-21).


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1028247: dart: FTBFS with Bullet 3.24 error in test_skelParser

[Markus Koschany]

Source: dart
Version: 6.12.1+dfsg4-11
Severity: important
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

I would like to release Bullet 3.24 with Bookworm. Your package fails
to build from source because one test fails, test_SkelParser.

Error [FCLCollisionDetector.cpp:1074]^[[0m 
[FCLCollisionDetector::createFCLCollisionGeometry] Attempting to create an 
unsupported shape type [CapsuleShape]. Creating a sphere with 0.1 radius 
instead.

test_SkelParser: ./dart/constraint/ContactConstraint.cpp:230: 
dart::constraint::ContactConstraint::ContactConstraint(dart::collision::Contact&,
 double): Assertion `std::abs(D.col(0).dot(D.col(1))) < DART_EPSILON' failed.

Is this a real problem or can we just disable/update the failing test?
Everything else seems to build fine.

Thanks in advance for checking. I would appreciate it if you could
take a look at it this week because the transition freeze is very
close.

Regards,

Markus

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Paul Gevers]

Control: severity 1023370 serious
Control: severity 1023381 serious

Hi Ondřej,

On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:

On 12/15/22 20:15, Ondřej Surý wrote:

I think everything is mostly ready in experimental. I'll try to sort out
the rest of the missing extensions over the weekend (imagick, memcached,
redis and maybe few others).


php-igbinary needs to be moved to unstable, php-apcu is built & 
installed on all release architectures.


php-raphf is also built & installed on all release architectures, but 
php-pecl-http was not staged in experimental and will need to pass NEW.


php-memcached and php-redis were not uploaded to experimental either.


I have a couple of questions:

I'm seeing that php-common has a Breaks on php8.1-common. Why is that? 
Is that really needed? It makes the migration a bit more complicated as 
it means that php8.1 has to be removed at the same time that php-common 
migrates.


Will you also take care of src:xdebug, next to php-pecl-http, 
php-memcached and php-redis as Bas suggested?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025437: AW: Bug#1025437 version 4.0.0 does not run with the current wtforms

[Krüger]

Hello Carsten,
thank you very much, the package seems to be OK.

It now seems to be compatible with wtforms (among other flask packages) again.

Sincerly Sebastian

Bug#1028246: transition: liquid-dsp

[Andreas Bombe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: liquid-...@packages.debian.org
Control: affects -1 + src:liquid-dsp

This is a new version of liquid-dsp where upstream now defined a
versioned soname. Reverse dependencies are cubicsdr and inspectrum, both
maintained in the ham radio team, that built and appear to work fine.

The autobuilders in experimental failed on i386 and mipsel during the
testsuite. I identified an array overrun which only causes trouble on
mipsel, apparently mangling a return address, which I can patch. The
other is one function getting wrongly optimized by gcc apparently, which
I can work around. And actually one more, also i386 only, where some
floats don't match exactly, which I'm still investigating.

The auto-liquid-dsp tracker appears correct.

Ben file:

title = "liquid-dsp";
is_affected = .depends ~ "libliquid3d" | .depends ~ "libliquid1";
is_good = .depends ~ "libliquid1";
is_bad = .depends ~ "libliquid3d";

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

On 22/05/22 11:47 PM, Adrian Bunk wrote:

> Looking at #942501 and #942502, the intention seems to be to not
> ship bind9-libs in bookworm.

I agree, Ccing Ondrej who has done the heavy lifting on this package.

AFAICT there is no binary reverse dependency in unstable, and #942501
"just" needs a NMU for the removed build-dep.

Ondrej, what do you think?

Bernhard

Bug#1000072: libapache2-mod-qos: depends on obsolete pcre3 library

[Pascal Buchbinder]

Hi
mod_qos 11.73 has been release. This release introduces support of the
PCRE2 (10.x) library in place of the now end-of-life PCRE version 1 (8.x)
API.

The module no longer has an explicit dependency to the PCRE library (but
uses ap_pregcomp(),  ap_regexec(), and ap_regexec_len() from ap_regex.h.)
Wrapping the PCRE (v1) and PCRE2 interface by the Apache httpd allows use
of the new API version (depends on locating pcre2-config). PCRE2
compatibility requires Apache httpd 2.4.53 or newer.

All the support utilities have been migrated to PCRE2 API (version 10.x).
Tested with PCRE version 10.41.

Best regards,
Pascal

Bug#1028245: nala: missing dependency

[dimitris]

Package: nala
Version: 0.12.0
Severity: important

happy new year!

seems that nala fails if python3-debian is not installed. error : 

$ doas nala update
Traceback (most recent call last):
  File "/usr/bin/nala", line 5, in 
from nala.__main__ import main
  File "/usr/lib/python3/dist-packages/nala/__main__.py", line 31, in 
import nala.fetch as _fetch  # pylint: disable=unused-import
  File "/usr/lib/python3/dist-packages/nala/fetch.py", line 66, in 
from debian.deb822 import Deb822  # isort:skip
ModuleNotFoundError: No module named 'debian'


installing python3-debian fixes this and nala runs as it should.. 
but package is not listed as nala dependency..

thanks,
d.

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

Kernel: Linux 5.10.142-antix.2-amd64-smp (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages nala depends on:
ii  apt2.5.4.0nosystemd1
ii  python33.10.6-3+b1
ii  python3-anyio  3.6.2-1
ii  python3-apt2.5.0
ii  python3-httpx  0.23.1-1
ii  python3-pexpect4.8.0-4
ii  python3-rich   13.0.0-1
ii  python3-tomli  2.0.1-2
ii  python3-typer  0.7.0-1
ii  python3-typing-extensions  4.3.0-2

Versions of packages nala recommends:
ii  python3-socksio  1.0.0-2

nala suggests no packages.

-- no debconf information

Bug#1015817: firejail: Calibre doesn't start Evince

[John Wick]

Hi Reiner,

Thank you for the solution.

Kind regards,
John


On 1/8/23 21:48, Reiner Herrmann wrote:

Hi John,

On Sun, Jan 08, 2023 at 09:28:25PM +0300, John Wick wrote:

It works well with 0.9.64.4-1~bpo10+1.

Yet Evince always opens a pdf book at page 1 while normally it opens where
you have stopped reading it.

 From 
https://superuser.com/questions/1724959/evince-in-wsl2-doesnt-remember-last-visited-page:
'You are absolutely right that Evince uses GVfs (the Gnome Virtual File
System) to store its bookmarks.'


thanks for the link. After installing gvfs my evince is now also
remembering the last page.
And I also saw that it was not working in a firejailed calibre.

I figured out that the following lines added to
/etc/firejail/calibre.local will allow evince started from firejailed
calibre to remember the page:


noblacklist ${HOME}/.local/share/gvfs-metadata
ignore private-tmp


You can try adding it to your calibre.local as well.
I'm not sure if this should get submitted upstream, as not every
calibre user is using evince as a PDF viewer, or wants to grant it
access to gvfs (which can also contain sensitive data of other
applications).

Kind regards,
   Reiner


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Bug#1028124: Bug#1028132: transition: hunspell

[Rene Engelhard]

[CCing hunspell-kos maintainer ]

Hi,

Am 08.01.23 um 19:24 schrieb Rene Engelhard:

Hi,

Am 07.01.23 um 16:45 schrieb Rene Engelhard:

r-cran-hunspell included a copy of those internal headers and thus
breaks when built against the newer ones. (And I assume will do so when
built against the new ones against the old one.)

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the
gory details.
I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local
to my proposed solution to #1028124


Given the R team and thus this package is in 
https://wiki.debian.org/LowThresholdNmu I can upload hunspell and 
r-cran-hunspell together in one go (the latter as a NMU if required).


Nevermind for now, even with the upstream fix for korean applied, some 
parts of hunspell-ko still fail...


(see 
https://ci.debian.net/data/autopkgtest/unstable/amd64/h/hunspell-dict-ko/30142014/log.gz 
and https://github.com/hunspell/hunspell/issues/903, the original patch 
is applied in 1.7.2+really1.7.2-4)



Will write again when this was sorted out somehow.

Rgards,


Rene

Bug#1019791: stimfit: diff for NMU version 0.16.0-1.2

[Olly Betts]

Dear maintainer,

I've prepared an NMU for stimfit (versioned as 0.16.0-1.2) and
uploaded it to unstable as per the NMU guidelines in the devref:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines

The package built with wxWidgets 3.2 without changes (the patch
suggested in #1019791 related to sip.h inclusion doesn't apply cleanly
to the version of the source in the package, but doesn't seem to be
required anyway).

Given I'm NMUing, it seemed best to make the minimal changes required
rather than updating to the suggested tag, but maybe a maintainer should
look into that.

Cheers,
Olly
diff -Nru stimfit-0.16.0/debian/changelog stimfit-0.16.0/debian/changelog
--- stimfit-0.16.0/debian/changelog	2022-03-25 08:29:58.0 +1300
+++ stimfit-0.16.0/debian/changelog	2023-01-05 10:56:35.0 +1300
@@ -1,3 +1,10 @@
+stimfit (0.16.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update to wxwidgets3.2. (Closes: #1019791)
+
+ -- Olly Betts   Thu, 05 Jan 2023 10:56:35 +1300
+
 stimfit (0.16.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru stimfit-0.16.0/debian/control stimfit-0.16.0/debian/control
--- stimfit-0.16.0/debian/control	2022-03-25 08:29:25.0 +1300
+++ stimfit-0.16.0/debian/control	2023-01-05 10:55:47.0 +1300
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Christoph Schmidt-Hieber 
 Uploaders: Yaroslav Halchenko 
-Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config
+Build-Depends: debhelper (>= 9), dh-python, libboost-dev (>= 1.40.0), python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.2-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libsuitesparse-dev, zlib1g-dev, dh-autoreconf, pkg-config
 Standards-Version: 3.9.8
 Homepage: http://www.stimfit.org
 

Bug#1028244: gavodachs: diff for NMU version 2.7+dfsg-1.1

[Stefano Rivera]

Package: gavodachs
Version: 2.7+dfsg-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for gavodachs (versioned as 2.7+dfsg-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru gavodachs-2.7+dfsg/debian/changelog gavodachs-2.7+dfsg/debian/changelog
--- gavodachs-2.7+dfsg/debian/changelog	2022-11-28 05:56:12.0 -0400
+++ gavodachs-2.7+dfsg/debian/changelog	2023-01-08 15:52:41.0 -0400
@@ -1,3 +1,11 @@
+gavodachs (2.7+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Support Python 3.11. (Closes: #1027398)
+  * Patch: Support numpy 1.24 (Closes: #1027213)
+
+ -- Stefano Rivera   Sun, 08 Jan 2023 15:52:41 -0400
+
 gavodachs (2.7+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2.7+dfsg
diff -Nru gavodachs-2.7+dfsg/debian/patches/numpy-1.24.patch gavodachs-2.7+dfsg/debian/patches/numpy-1.24.patch
--- gavodachs-2.7+dfsg/debian/patches/numpy-1.24.patch	1969-12-31 20:00:00.0 -0400
+++ gavodachs-2.7+dfsg/debian/patches/numpy-1.24.patch	2023-01-08 15:52:41.0 -0400
@@ -0,0 +1,68 @@
+From: Stefano Rivera 
+Date: Sun, 8 Jan 2023 15:29:25 -0400
+Subject: Replace numpy types with builtin types where appropriate
+
+Supports Numpy > 1.24
+
+Bug-Debian: https://bugs.debian.org/1027213
+---
+ gavo/base/typesystems.py  | 10 +-
+ gavo/formats/fitstable.py |  2 +-
+ gavo/votable/simple.py|  2 +-
+ 3 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/gavo/base/typesystems.py b/gavo/base/typesystems.py
+index 0e4223e..33b4827 100644
+--- a/gavo/base/typesystems.py
 b/gavo/base/typesystems.py
+@@ -139,11 +139,11 @@ class ToNumpyConverter(FromSQLConverter):
+ 		"integer": numpy.int32,
+ 		"bigint": numpy.int64,
+ 		"real": numpy.float32,
+-		"boolean": numpy.bool,
++		"boolean": bool,
+ 		"double precision": numpy.float64,
+-		"text": numpy.str,
+-		"unicode": numpy.str,
+-		"char": numpy.str,
++		"text": str,
++		"unicode": str,
++		"char": str,
+ 		"date": numpy.float32,
+ 		"timestamp": numpy.float64,
+ 		"time": numpy.float32,
+@@ -151,7 +151,7 @@ class ToNumpyConverter(FromSQLConverter):
+ 
+ 	def mapComplex(self, type, length):
+ 		if type in self._charTypes:
+-			return numpy.str
++			return str
+ 
+ 
+ class ToPythonBase(FromSQLConverter):
+diff --git a/gavo/formats/fitstable.py b/gavo/formats/fitstable.py
+index b30c740..0de05bb 100644
+--- a/gavo/formats/fitstable.py
 b/gavo/formats/fitstable.py
+@@ -128,7 +128,7 @@ def _makeValueArray(values, colInd, colDesc):
+ 		# That's a variable-length array that we'll fill from a 
+ 		# numpy object array
+ 		return typecode, numpy.array([list(v[colInd]) for v in values], 
+-			dtype=numpy.object)
++			dtype=object)
+ 
+ 	elif length>1:
+ 		# numpy 1:1.12.1-3 and pyfits from astropy 1.3-8 apparently
+diff --git a/gavo/votable/simple.py b/gavo/votable/simple.py
+index 1ff2ac7..acaf6fc 100644
+--- a/gavo/votable/simple.py
 b/gavo/votable/simple.py
+@@ -24,7 +24,7 @@ try:
+ 		"long": numpy.int64,
+ 		"float": numpy.float32,
+ 		"double": numpy.float64,
+-		"boolean": numpy.bool,
++		"boolean": bool,
+ 		"char": numpy.str_,
+ 		"floatComplex": numpy.complex64,
+ 		"doubleComplex": numpy.complex128,
diff -Nru gavodachs-2.7+dfsg/debian/patches/python3.11.patch gavodachs-2.7+dfsg/debian/patches/python3.11.patch
--- gavodachs-2.7+dfsg/debian/patches/python3.11.patch	1969-12-31 20:00:00.0 -0400
+++ gavodachs-2.7+dfsg/debian/patches/python3.11.patch	2023-01-08 15:52:41.0 -0400
@@ -0,0 +1,35 @@
+From: Stefano Rivera 
+Date: Sun, 8 Jan 2023 15:18:21 -0400
+Subject: Don't repeat global inline flags in the middle of a regex
+
+[bpo-47066]: As of Python 3.11, global inline flags (e.g. (?i)) can now
+only be used at the start of regular expressions. Using them elsewhere
+has been deprecated since Python 3.6.
+
+Bug-Debian: https://bugs.debian.org/1027398
+---
+ gavo/stc/tapstc.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gavo/stc/tapstc.py b/gavo/stc/tapstc.py
+index 0e3c206..e744508 100644
+--- a/gavo/stc/tapstc.py
 b/gavo/stc/tapstc.py
+@@ -225,7 +225,7 @@ def getSimpleSTCSParser():
+ 		frameRE = _makeRE(TAP_SYSTEMS)
+ 		refposRE = _makeRE(TAP_REFPOS)
+ 		flavorRE = _makeRE(TAP_FLAVORS)
+-		systemRE = (r"(?i)\s*"
++		systemRE = (r"\s*"
+ 			r"(?P%s)?\s*"
+ 			r"(?P%s)?\s*"
+ 			r"(?P%s)?\s*")%(
+@@ -238,7 +238,7 @@ def getSimpleSTCSParser():
+ 			+coordsRE)
+ 		simpleStatement.setName("STC-S geometry")
+ 		simpleStatement.addParseAction(lambda s,p,t: _makePgSphereInstance(t))
+-		system = Regex(systemRE)
++		system = Regex("(?i)" + systemRE)
+ 		system.setName("STC-S system spec")
+ 		region = Forward()
+ 		notExpr = CaselessKeyword("NOT") + Suppress('(') + region + Suppress(')')
diff -Nru gavodachs-2.7+dfsg/debian/patches/series gavodachs-2.7+dfsg/debian/patches/series
--- gavodachs-2.7+dfsg/debian/patches/series	2022-02-23 16:08:41.0 

Bug#1027398: gavodachs: autopkgtest needs update for new version of python-cryptography: fails to install

[Stefano Rivera]

Control: reassign -1 src:gavodachs
Control: tag -1 + patch

> On Fri, Dec 30, 2022 at 10:13:45PM +0100, Paul Gevers wrote:
> > *** Error: Oops.  Unhandled exception AttributeError.
> > 
> > Exception payload: module 'lib' has no attribute
> > 'SSL_CTX_set_ecdh_auto'
> 
> While DaCHS doesn't do a good job of communicating this, the
> regression is actually within python3-openssl and python3-twisted.
> There's a test case in python3-twisted that looks like it is
> exercising the failing code.  I have tried to locate a corresponding
> bug against twisted, but I have not been able to locate it.  Is there
> any action I should take to alert the maintainers of the two packages?

I think that was a misdiagnosis. I found that too, when looking for the
source. But, of course, those test cases aren't being run at import
time.

The real issue was in pyopenssl, which was also updated around the same
time, to include this patch:
https://github.com/pyca/pyopenssl/commit/c8fe4dd5e91b00a5817db283c6198ef7031da825

However, there is also a Python 3.11 incompatibility breaking the
autopkgtests. Patch attached.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
From: Stefano Rivera 
Date: Sun, 8 Jan 2023 15:18:21 -0400
Subject: Don't repeat global inline flags in the middle of a regex

[bpo-47066]: As of Python 3.11, global inline flags (e.g. (?i)) can now
only be used at the start of regular expressions. Using them elsewhere
has been deprecated since Python 3.6.

Bug-Debian: https://bugs.debian.org/1027398
---
 gavo/stc/tapstc.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gavo/stc/tapstc.py b/gavo/stc/tapstc.py
index 0e3c206..e744508 100644
--- a/gavo/stc/tapstc.py
+++ b/gavo/stc/tapstc.py
@@ -225,7 +225,7 @@ def getSimpleSTCSParser():
 		frameRE = _makeRE(TAP_SYSTEMS)
 		refposRE = _makeRE(TAP_REFPOS)
 		flavorRE = _makeRE(TAP_FLAVORS)
-		systemRE = (r"(?i)\s*"
+		systemRE = (r"\s*"
 			r"(?P%s)?\s*"
 			r"(?P%s)?\s*"
 			r"(?P%s)?\s*")%(
@@ -238,7 +238,7 @@ def getSimpleSTCSParser():
 			+coordsRE)
 		simpleStatement.setName("STC-S geometry")
 		simpleStatement.addParseAction(lambda s,p,t: _makePgSphereInstance(t))
-		system = Regex(systemRE)
+		system = Regex("(?i)" + systemRE)
 		system.setName("STC-S system spec")
 		region = Forward()
 		notExpr = CaselessKeyword("NOT") + Suppress('(') + region + Suppress(')')

Bug#1027213: gavodachs: autopkgtest fail with numpy/1.24.1

[Stefano Rivera]

Control: tag -1 + patch

I haven't tested this beyond the autopkgtest, but it seems to work, so
I'll NMU it.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
From: Stefano Rivera 
Date: Sun, 8 Jan 2023 15:29:25 -0400
Subject: Replace numpy types with builtin types where appropriate

Supports Numpy > 1.24

Bug-Debian: https://bugs.debian.org/1027213
---
 gavo/base/typesystems.py  | 10 +-
 gavo/formats/fitstable.py |  2 +-
 gavo/votable/simple.py|  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gavo/base/typesystems.py b/gavo/base/typesystems.py
index 0e4223e..33b4827 100644
--- a/gavo/base/typesystems.py
+++ b/gavo/base/typesystems.py
@@ -139,11 +139,11 @@ class ToNumpyConverter(FromSQLConverter):
 		"integer": numpy.int32,
 		"bigint": numpy.int64,
 		"real": numpy.float32,
-		"boolean": numpy.bool,
+		"boolean": bool,
 		"double precision": numpy.float64,
-		"text": numpy.str,
-		"unicode": numpy.str,
-		"char": numpy.str,
+		"text": str,
+		"unicode": str,
+		"char": str,
 		"date": numpy.float32,
 		"timestamp": numpy.float64,
 		"time": numpy.float32,
@@ -151,7 +151,7 @@ class ToNumpyConverter(FromSQLConverter):
 
 	def mapComplex(self, type, length):
 		if type in self._charTypes:
-			return numpy.str
+			return str
 
 
 class ToPythonBase(FromSQLConverter):
diff --git a/gavo/formats/fitstable.py b/gavo/formats/fitstable.py
index b30c740..0de05bb 100644
--- a/gavo/formats/fitstable.py
+++ b/gavo/formats/fitstable.py
@@ -128,7 +128,7 @@ def _makeValueArray(values, colInd, colDesc):
 		# That's a variable-length array that we'll fill from a 
 		# numpy object array
 		return typecode, numpy.array([list(v[colInd]) for v in values], 
-			dtype=numpy.object)
+			dtype=object)
 
 	elif length>1:
 		# numpy 1:1.12.1-3 and pyfits from astropy 1.3-8 apparently
diff --git a/gavo/votable/simple.py b/gavo/votable/simple.py
index 1ff2ac7..acaf6fc 100644
--- a/gavo/votable/simple.py
+++ b/gavo/votable/simple.py
@@ -24,7 +24,7 @@ try:
 		"long": numpy.int64,
 		"float": numpy.float32,
 		"double": numpy.float64,
-		"boolean": numpy.bool,
+		"boolean": bool,
 		"char": numpy.str_,
 		"floatComplex": numpy.complex64,
 		"doubleComplex": numpy.complex128,

Bug#1028243: dexdump: symbol lookup error: /.../libart.so.0: undefined symbol

[Philipp Marek]

Package: dexdump
Version: 11.0.0+r48-4
Severity: grave
X-Debbugs-Cc: phil...@marek.priv.at

dexdump won't run:

$ dexdump   
 
dexdump: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/android/libart.so.0: undefined symbol: 
_Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi


But installed packages seem consistent:

$ apt-cache policy dexdump
dexdump:
  Installiert:   11.0.0+r48-4   
   
  Installationskandidat: 11.0.0+r48-4   
   
  Versionstabelle:  


   
 *** 11.0.0+r48-4 990   
   
990 http://deb.debian.org/debian testing/main amd64 Packages
   
500 http://deb.debian.org/debian unstable/main amd64 Packages   
100 /var/lib/dpkg/status  
 10.0.0+r36-3 500
500 http://deb.debian.org/debian stable/main amd64 Packages

$ dpkg-query -S /usr/lib/x86_64-linux-gnu/android/libart.so.0 
android-libart:amd64: /usr/lib/x86_64-linux-gnu/android/libart.so.0

$ apt-cache policy android-libart 
android-libart:
  Installiert:   11.0.0+r48-4
  Installationskandidat: 11.0.0+r48-4
  Versionstabelle:
 *** 11.0.0+r48-4 990
990 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 10.0.0+r36-3 500
500 http://deb.debian.org/debian stable/main amd64 Packages



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

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

Versions of packages dexdump depends on:
ii  android-libart   11.0.0+r48-4
ii  android-libbacktrace 1:33.0.1-1~exp9
ii  android-libbase  1:33.0.1-1~exp9
ii  android-liblog   1:33.0.1-1~exp9
ii  android-libnativeloader  1:11.0.0+r48-4
ii  android-libziparchive1:33.0.1-1~exp9
ii  libatomic1   12.2.0-10
ii  libc62.36-6
ii  libgcc-s112.2.0-10
ii  liblz4-1 1.9.4-1
ii  libstdc++6   12.2.0-10
ii  zlib1g   1:1.2.13.dfsg-1

dexdump recommends no packages.

dexdump suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: can't check dexdump file /usr/share/doc/dexdump/NOTICE.gz (Wide 
character in subroutine entry)
debsums: can't check dexdump file /usr/share/doc/dexdump/changelog.Debian.gz 
(Wide character in subroutine entry)
debsums: can't check dexdump file /usr/share/man/man1/dexdump.1.gz (Wide 
character in subroutine entry)

Bug#1028242: zfs-linux: open with O_TMPFILE flag fails on Linux 6.1

[Antonio Russo]

Package: src:zfs-linux
Version: 2.1.7-1
X-Debbugs-Cc: aeru...@aerusso.net
Severity: important
Tags: patch

Dear Maintainer,

This bug is reported upstream at [1], resolved in [2], and backported to 2.1.7
in (the last patch of) [3] ([3] has not yet been accepted or reviewed).  I've
put this at important severity since it is a regression and could conceivable
lead to difficult to debug problems.

Briefly, the interface to tmpfile() interface in the kernel was adjusted to use
a struct file rather than a struct dentry.  The adjustment is relatively
straightforward.

Best,
Antonio Russo

[1] https://github.com/openzfs/zfs/issues/14301
[2] 
https://github.com/openzfs/zfs/commit/d27c81847b43584483b5509ff352e7e727b0ce87
[3] https://github.com/openzfs/zfs/pull/14357

Bug#1028241: mini-buildd: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: mini-buildd
Version: 1.9.115
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for mini-buildd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


mini-buildd_1.9.115_pt.po.gz
Description: application/gzip

Bug#944139: debmirror archive.debian.org fails due to missing binary-all

[Martin Dorey]

The introducing commit suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944139#15 doesn't look
right to me.  I had success reverting the active part of
https://salsa.debian.org/debian/debmirror/-/commit/82bf56b2246bdf22470fd2751b359c82932c3833#81f3803dd9887f397ffdeebc8973c6de39a38df9
instead of that one.  I didn't try the more constructive suggestion from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944139#20, sorry, because
it was easier for me if the arguments remain compatible with older
versions.  I could be persuaded to try it.

There's clearly something amiss with archive.debian.org.
https://archive.kernel.org/debian-archive/debian/dists/wheezy/Release
mentions eg:

 1a5452264b2c147411a53afd4a13b311 12683375 main/binary-all/Packages

... but there is no binary-all directory in
https://archive.kernel.org/debian-archive/debian/dists/wheezy/main/.
Perhaps getting that fixed would be too hard?  Making debmirror cope
doesn't seem to be too difficult.

Bug#1025902: tlp: Battery charge thresholds are ignored

[Raphaël Halimi]

Hi again,

I contacted the upstream developer and he'd like you to open an issue 
there directly.


The project page is at https://github.com/linrunner/TLP

For starters he needs the output of :

$ tlp-stat --cdiff -s -b

Once you've done that, please reply here with the address of the issue 
report, I'll link them in the BTS.


Regards,

--
Raphaël Halimi

Bug#1028240: poetry: FTBFS (requires internet access)

[Gianfranco Costamagna]

Source: poetry
Version: 1.3.1+dfsg-1
Severity: Serious

Hello, looks like the package is using internet during build.
No changing rebuilding with disabled internet results in tests failures

dpkg-source: info: building poetry in poetry_1.3.1+dfsg-1.dsc
 debian/rules binary
dh binary --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:107: Building wheel for python3.10 with "build" 
module
I: pybuild base:240: python3.10 -m build --skip-dependency-check --no-isolation 
--wheel --outdir /poetry-1.3.1+dfsg/.pybuild/cpython3_3.10_poetry
* Building wheel...
Successfully built poetry-1.3.1-py3-none-any.whl
I: pybuild plugin_pyproject:119: Unpacking wheel built for python3.10 with 
"installer" module
I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build" 
module
I: pybuild base:240: python3.11 -m build --skip-dependency-check --no-isolation 
--wheel --outdir /poetry-1.3.1+dfsg/.pybuild/cpython3_3.11_poetry
* Building wheel...
Successfully built poetry-1.3.1-py3-none-any.whl
I: pybuild plugin_pyproject:119: Unpacking wheel built for python3.11 with 
"installer" module
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:240: cd /poetry-1.3.1+dfsg/.pybuild/cpython3_3.10_poetry/build; 
python3.10 -m pytest --ignore=tests/console/commands/env/test_list.py 
--ignore=tests/console/commands/env/test_remove.py 
--ignore=tests/console/commands/env/test_use.py 
--ignore=tests/utils/test_env.py --ignore=tests/config/test_config.py 
--ignore=tests/utils/test_helpers.py -k 'not 
test_self_update_should_install_all_necessary_elements and not 
test_add_file_constraint_sdist and not 
test_add_file_constraint_sdist_old_installer and not test_publish_dry_run and 
not test_info_from_sdist and not 
test_installer_can_install_dependencies_from_forced_source and not 
test_search_for_file_sdist and not test_search_for_file_sdist_with_extras and 
not test_solver_can_resolve_sdist_dependencies and not 
test_solver_can_resolve_sdist_dependencies_with_extras and not 
test_solver_chooses_from_correct_repository_if_forced and not 
test_solver_chooses_from_correct_repository_if_forced_and_transitive_dependency 
and not test_solver_does_not_choose_from_secondary_repository_by_default and 
not test_solver_chooses_from_secondary_if_explicit and not 
test_get_package_information_fallback_read_setup and not 
test_get_package_information_skips_dependencies_with_invalid_constraints and 
not test_get_package_retrieves_packages_with_no_hashes and not 
test_fallback_can_read_setup_to_get_dependencies and not 
test_exporter_can_export_requirements_txt_with_file_packages and not 
test_exporter_can_export_requirements_txt_with_file_packages_and_markers and 
not test_lock_no_update and not 
test_locker_dumps_dependency_information_correctly and not 
test_package_partial_yank and not test_run_installs_with_same_version_url_files 
and not test_env_info_displays_complete_info and not test_skip_existing_output 
and not 
test_installer_should_use_the_locked_version_of_git_dependencies_with_extras 
and not 
test_installer_should_use_the_locked_version_of_git_dependencies_without_reference
 and not test_installer_uses_prereleases_if_they_are_compatible and not 
test_requirement_git_subdirectory and not test_check_valid and not 
test_check_invalid and not test_packages_property_returns_empty_list and not 
test_parse_dependency_specification and not 
test_info_setup_missing_mandatory_should_trigger_pep517'
===
 test session starts 
===
platform linux -- Python 3.10.9, pytest-7.2.0, pluggy-1.0.0+repack
rootdir: /poetry-1.3.1+dfsg, configfile: pyproject.toml
plugins: mock-3.8.2, xdist-3.1.0
gw0 [1056] / gw1 [1056] / gw2 [1056] / gw3 [1056] / gw4 [1056] / gw5 [1056] / 
gw6 [1056] / gw7 [1056]
s..
 [ 18%]
...
 [ 36%]
..s
 [ 55%]
.s.
 [ 73%]

Bug#1028239: osk-sdl: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: osk-sdl
Version: 0.67.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for osk-sdl's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


osk-sdl_0.67.1-1_pt.po.gz
Description: application/gzip

Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging

[Antonio Russo]

On 1/8/23 09:22, Eduard Bloch wrote:
> 
> Thanks. Regarding the second patch, I am not sure. Looks like my C++
> also has become rusty in the last months. It would be good to have an
> explicit description of the problem cases, since I don't know exactly
> what you mean with "streaming". I.e. it seems like you want the generic
> parser implementation to be changed to a specialized local one but how
> am I supposed to write a unit test for this?
> 
> To be checked in the next days, stay tuned.
> 
> Best regards,
> Eduard.

Sorry, I was in a bit of a hurry when I wrote that email.

The purpose of the second patch is to properly parse the list of packages
sources, e.g. [1].  Those files are concatenations of RFC822 blocks,
separated by blank lines.  The previous implementation did not work,
because it did not account for the fact that all of these separate blocks
are of importance to us.

In particular, ParseDebianRfc822Index, line 1995 of src/cacheman.cc:

// we don't merge

justifies the next statement:

pLastVal->clear();  

That serves to remove the last block's information (rather than merge it
with the last package).  The symptom of this error in parsing is that
all Sources blocks (except the last one, which is not clobbered by any
subsequent blocks) are not identified as referencing data in the cache.
Therefore most of the, e.g., .tar{,.gz,.xz,.bzip2} and .dsc files are
marked for expiration from the cache.

I have added a new implementation in the same spirit as the one used for
Packages parsing, (see src/cacheman.cc:1707).  In that branch of the
switch statement (EIDX_PACKAGES), each RFC822 block is parsed.  I used
the word "streaming" to indicate that the whole index does not need to
be loaded into memory before the first call to ret(info) begins returning
data to the rest of the service.

While good for the overall performance of apt-cacher-ng, this streaming
behavior is not the primary purpose of the patch (and I apologize for
overemphasizing that in the title).  Indeed, it is the correctness of
the result that is my main objective here.

As for writing a unit test, I would suggest grabbing some subset of [1],
and ensuring that all of the entries are properly accounted for. Without
this patch, such a unit test would fail.

Best,
Antonio

[1] http://ftp.us.debian.org/debian/dists/bookworm/main/source/Sources.gz

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027386: [Debian-med-packaging] Bug#1027335: pairtools -- FTBFS in unstable

[Étienne Mollier]

Hi Nilesh,

[I noticed this answer in my drafts quite late, sorry for the
 delay answering.]

Nilesh Patra, on 2023-01-01:
> On Fri, 30 Dec 2022 16:01:00 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
>  wrote: 
> > $ python3.10 reproducer.py
> 
> Curious -- what script is this? :)

This one, sorry my wording made it confusing:

$ cat reproducer.py 
import pysam
for lib in pysam.get_libraries():
print(lib)

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1028102: marked as done (secnet FTBFS: eax-aes-test failure)

[Ian Jackson]

Control: retitle -1 secnet FTBFS: ADNS test failure

The tests are quite highly concurrent.  The "eax-aes-test" in the
transcript is unrelated.  Fixing the title for this bug for posterity
and future searches.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028238: Please update auctex to 13.1

[Amr Ibrahim]

Package: fonts-sil-alkalami

Hallo,

Please update auctex to 13.1.

https://git.savannah.gnu.org/cgit/auctex.git/

Best,
Amr

Bug#1015817: firejail: Calibre doesn't start Evince

[Reiner Herrmann]

Hi John,

On Sun, Jan 08, 2023 at 09:28:25PM +0300, John Wick wrote:
> It works well with 0.9.64.4-1~bpo10+1.
> 
> Yet Evince always opens a pdf book at page 1 while normally it opens where
> you have stopped reading it.
> 
> From 
> https://superuser.com/questions/1724959/evince-in-wsl2-doesnt-remember-last-visited-page:
> 'You are absolutely right that Evince uses GVfs (the Gnome Virtual File
> System) to store its bookmarks.'

thanks for the link. After installing gvfs my evince is now also
remembering the last page.
And I also saw that it was not working in a firejailed calibre.

I figured out that the following lines added to
/etc/firejail/calibre.local will allow evince started from firejailed
calibre to remember the page:

> noblacklist ${HOME}/.local/share/gvfs-metadata
> ignore private-tmp

You can try adding it to your calibre.local as well.
I'm not sure if this should get submitted upstream, as not every
calibre user is using evince as a PDF viewer, or wants to grant it
access to gvfs (which can also contain sensitive data of other
applications).

Kind regards,
  Reiner

Bug#1028226: RM: grr-client-templates/3.1.0.2-4

[Sebastian Ramacher]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: grr-client-templates -- RoM; unmaintained upstream

On 2023-01-08 17:14:07 +0100, Hilko Bengen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Please rm grr-client-templates from the archive. The package has been
> unmaintained for a few years.

Removals from unstable are handled by FTP masters. Removal from testing
happens automatically after the unstable removal. Reassigning
accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1028237: Please update dvipng to 1.17

[Amr Ibrahim]

Package: dvipng

Hallo,

Please update dvipng to 1.17.

https://git.savannah.nongnu.org/cgit/dvipng.git/

Best,
Amr

Bug#1015817: firejail: Calibre doesn't start Evince

[John Wick]

Hi Reiner,

It works well with 0.9.64.4-1~bpo10+1.

Yet Evince always opens a pdf book at page 1 while normally it opens 
where you have stopped reading it.


From 
https://superuser.com/questions/1724959/evince-in-wsl2-doesnt-remember-last-visited-page:
'You are absolutely right that Evince uses GVfs (the Gnome Virtual File 
System) to store its bookmarks.'


Kind regards,
John

On 1/7/23 21:48, Reiner Herrmann wrote:

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

Hi John,

On Thu, Jul 21, 2022 at 09:43:13PM +0300, John wrote:

When trying to read a pdf book from Calibre, Calibre doesn't open it.

My terminal shows this:
evince: util.c:927: create_empty_file_as_root: Assertion `s.st_uid == 0'
failed.

When run /usr/bin/calibre as have been written at
https://github.com/netblue30/firejail/issues/5222 it opens it.


I just tried to reproduce your problem, but for me running calibre with
evince as PDF viewer is working fine.
Can you please try to run a newer firejail version?
E.g. 0.9.64.4-1~bpo10+1 from the oldstable backports, or if you are
meanwhile running stable 0.9.70-2~bpo11+1 from the stable backports?


Also Evince doesn't save metadata - the last read page as an example.


I think Evince doesn't support this in general. Also when running Evince
without Calibre and outside of firejail, it does not save the last page.
Or am I missing some setting to turn that on?

Kind regards,
   Reiner


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Bug#994540: transition: imagemagick

[Sebastian Ramacher]

Control: tags -1 = moreinfo

On 2022-11-10 23:08:27 +0100, Sebastian Ramacher wrote:
> On 2022-09-03 15:59:44 +0200, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > 
> > On 2022-07-15 14:03:24 +0200, Johannes Schauer Marin Rodrigues wrote:
> > > Hi Sebastian,
> > > 
> > > Quoting Sebastian Ramacher (2022-07-13 22:52:52)
> > > > On 2021-09-29 10:38:07 +0200, jo...@mister-muffin.de wrote:
> > > > > > Do all reverse dependencies build fine with the new Imagemagick 
> > > > > > version?
> > > > > > If not, have bugs been filed?
> > > > > 
> > > > > I have rebuilt all 399 source packages that have at least one binary 
> > > > > produced
> > > > > by src:imagemagick in their build dependency installation closure. Of 
> > > > > those, 16
> > > > > packages FTBFS with the imagemagick version form experimental but 
> > > > > succeed with
> > > > > the version from unstable. Of those, only one package (src:wand) is 
> > > > > in the list
> > > > > from 
> > > > > https://release.debian.org/transitions/html/auto-imagemagick.html I 
> > > > > filed
> > > > > this failure as #995290 and will investigate the other 15 instances 
> > > > > as well.
> > > > > But since those source packages are not part of the transition, they 
> > > > > should
> > > > > probably not block this bug.
> > > > 
> > > > This transition completly dropped off my radar, sorry!
> > > > 
> > > > What's the current status of the preparations? Have the bugs been filed?
> > > 
> > > we had one build failure in src:wand which I fixed in imagemagick upload 
> > > of
> > > 8:6.9.12.20+dfsg1-1.2 to experimental. See also #995290
> > 
> > Please go ahead
> 
> This upload did not happen. Was the status here?

Let's postpone this transition to trixie. Please remove the moreinfo tag
once you are ready to start the transition after the release of
bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#1028124: Bug#1028132: transition: hunspell

[Rene Engelhard]

Hi,

Am 07.01.23 um 16:45 schrieb Rene Engelhard:

r-cran-hunspell included a copy of those internal headers and thus
breaks when built against the newer ones. (And I assume will do so when
built against the new ones against the old one.)

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the
gory details.
I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local
to my proposed solution to #1028124


Given the R team and thus this package is in 
https://wiki.debian.org/LowThresholdNmu I can upload hunspell and 
r-cran-hunspell together in one go (the latter as a NMU if required).


Regards,

Rene

Bug#1028236: cura: Please package Cura 5.1+

[Gregor Riepl]

Package: cura
Version: 5.0.0-1
Severity: wishlist
X-Debbugs-Cc: onit...@gmail.com
Control: block -1 by 845463

This is a placeholder bug to track activity towards packaging Cura 5.1 and
later versions.

With Cura 5.1, upstream has switched to a new build and dependency management
system that is based on Conan[1], which is not yet packaged for Debian. CMake
is still used, and there are also some requirements on other build tools, such
as Ninja[2]. Ninja is available in Debian as "ninja-build".

The work done by the Alpine package maintainer may serve as a starting point:
https://git.alpinelinux.org/aports/tree/community/libarcus
https://git.alpinelinux.org/aports/tree/community/curaengine

However, it would be better if we didn't have to maintain a large set of
compatibility patches to make building Cura possible again.

Be aware that upstream states there may still be changes to the build system
coming[3].

[1] https://conan.io/
[2] https://ninja-build.org/
[3]
https://github.com/Ultimaker/libArcus/tree/6b70728da6149232dd8c7b20d23a31103468b3ba#how-
to-build


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

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

Versions of packages cura depends on:
ii  cura-engine  1:5.0.0-1
ii  fdm-materials5.0.0-1
ii  fonts-open-sans  1.11-2
ii  python3  3.10.6-3+b1
ii  python3-certifi  2022.9.24-1
ii  python3-charon   4.13.0-1
ii  python3-cryptography 3.4.8-2
ii  python3-keyring  23.9.3-2
ii  python3-pynest2d 5.0.0-1
ii  python3-pyqt66.4.0-1+b2
ii  python3-requests 2.28.1+dfsg-1
ii  python3-savitar  5.0.0-1
ii  python3-sentry-sdk   1.9.10-2
ii  python3-serial   3.5-1.1
ii  python3-shapely  1.8.5-2
ii  python3-uranium  5.0.0-1
ii  qml6-module-qt-labs-folderlistmodel  6.4.2+dfsg~rc1-2
ii  qml6-module-qtqml-workerscript   6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-controls 6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-dialogs  6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-layouts  6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-templates6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-window   6.4.2+dfsg~rc1-2
ii  qt6-qpa-plugins  6.4.2+dfsg~rc1-3
ii  uranium-plugins  5.0.0-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.47.1-1

cura suggests no packages.

-- no debconf information

Bug#1028202: ncurses-base: move terminfo files to /usr/share/terminfo

[Sven Joachim]

On 2023-01-08 14:27 +0100, Sven Joachim wrote:

> Package: ncurses-base
> Version: 6.4-1
> Severity: wishlist
>
> With late mount of /usr not being supported since Debian 9[1] and a
> merged /usr layout likely to become mandatory after Debian 12, it does
> not really make sense to have the terminfo files in ncurses-base in a
> different directory than the ones from ncurses-term.  After the Bookworm
> release we should move them from /lib/terminfo to /usr/share/terminfo as
> most other distributions have already done.
>
> Searching for "lib/terminfo" on codesearch.debian.net gives hits for
> some 60 packages that need to be investigated for possible breakage in
> code that expects terminfo files in a specific place.

Did a research this afternoon and found two problems: #1028231, an
autopkgtest in unibilium that will stop doing anything useful (but still
succeed IIUC, so not a blocker), and #1028234, an initramfs hook script
in cryptsetup-initramfs that will fail.  Which is a blocker, since it
affects nearly 7% of all installations according to popcon.  Both bugs
should be fairly simple to fix.

Bug#1017435: debian-installer: georgian text mode fails to render all characters

[Holger Wansing]

Hi,

Roland Clobus  wrote (Sat, 7 Jan 2023 11:31:29 +0100):
> I agree. But the work for the translators can be reduced by 
> automatically parsing the work they have already done (i.e. the 
> translations).
> That would leave only some characters that have not been used in any 
> translated text, but might be present i.e. on the keyboard.
> @Translators: It that something you might want to use?

For a translator, it's just a matter of 1 minute, to write down the 
alphabet for his language, I guess.

But anyway, we can still use your script, if we cannot get such info from
translator (if there is no active translator, for example).

> Attached:
> 1) chars_v2.py: The updated script
> 2) sample.summary: Its output to the console
> 3) ka.utf: Automatically generated Georgian list of use characters

The ka.utf you attached is conspicuously (nearly) identical to what I grabbed
from Wikipedia, so: good work!!!


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1028235: magnus: resize is broken

[David Christensen]

Package: magnus
Version: 1:1.0.3-3
Severity: important
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

I use the Xfce desktop.

When I attempt to resize the Magnus window, the resize mouse pointer is
visible, I can drag an edge or corner of the Magnus window, the window
size follows the pointer if I make the window larger, but the window
size does not follow the pointer if I try to make the window smaller.

If you can provide me with the name of a Debian screen capture package
that makes videos and a URL for a public upload site, I can make a
demonstration video and upload it.

Another issue is that the Magnus window is visible whenever I log in.

I do not know if the two issues are related.

Do you want me to file another bug report for the second issue?

David



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

Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 magnus depends on:
ii  gir1.2-gdkpixbuf-2.0   2.42.2+dfsg-1+deb11u1
ii  gir1.2-glib-2.01.66.1-1+b1
ii  gir1.2-gtk-3.0 3.24.24-4+deb11u2
ii  gir1.2-keybinder-3.0   0.3.2-1.1
ii  python33.9.2-3
ii  python3-gi 3.38.0-2
ii  python3-pkg-resources  52.0.0-4
ii  python3-setproctitle   1.2.1-1+b1

magnus recommends no packages.

magnus suggests no packages.

-- no debconf information

Bug#1028234: cryptsetup-initramfs: hardclodes path to the linux terminfo entry

[Sven Joachim]

Package: cryptsetup-initramfs
Version: 2:2.6.0-2
File: /usr/share/initramfs-tools/hooks/cryptgnupg-sc
Control: block 1028202 by -1

The file /usr/share/initramfs-tools/hooks/cryptgnupg-sc copies the
terminfo entry for linux to the initramfs at the end:

[ -f "$DESTDIR/lib/terminfo/l/linux" ] || copy_file terminfo 
/lib/terminfo/l/linux || RV=$?

After the Bookworm release I intend to relocate the files in
ncurses-base to /usr/share/terminfo, see
https://bugs.debian.org/1028202.  To prepare for that, could you please
look for the "linux" terminfo entry in /usr/share/terminfo/l as well as
in /lib/terminfo/l ?

Bug#1013213: gftools: version outdated, blocking build of cascadia code

[Agathe Porte]

Hi Fabian,

On 06/01/2023 21:44, Fabian Greffrath wrote:

Now both python-gflanguages and python-glyphsets have fond their way
into Debian.


According to the other attached bugs, we are still waiting for a number 
of packages. See the attached dependencies rendered as a SVG graph. 
Transitively, here is the list of (known) ITPs we are waiting on:


- python-hyperglot

- python-babelfont

- python-orjson

- maturin

- python-axisregistry

I have a few of them to package myself, but will not advance the work as 
long as maturin and python-orjson are not packaged. If one can help 
"ITP: maturin" and "ITP: python-orjson" happen, then I think it would be 
welcome to finally update gftools.


Bests,

Agathe.

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Raphaël Halimi]

Package: xz-utils
Version: 5.4.0-0.1

Dear developer,

I'm not sure if it's the right place to report the bug since it involves 
a conflict with a backport.


Today I tried to upgrade a Bullseye laptop to Bookworm.

The upgrade crashed with xz-utils trying to overwrite 
/usr/share/man/fr/man1/xz.1.gz which belonged to manpages-fr from 
backports (4.16.0-3~bpo11+1).


After running dpkg --force-overwrite (it's the only way I know of in 
such situations), a whole bunch of manual pages were overwritten :


/usr/share/man/fr/man1/xz.1.gz
/usr/share/man/fr/man1/xzdiff.1.gz
/usr/share/man/fr/man1/xzless.1.gz
/usr/share/man/fr/man1/xzmore.1.gz
/usr/share/man/fr/man1/lzcat.1.gz
/usr/share/man/fr/man1/lzcmp.1.gz
/usr/share/man/fr/man1/lzdiff.1.gz
/usr/share/man/fr/man1/lzless.1.gz
/usr/share/man/fr/man1/lzma.1.gz
/usr/share/man/fr/man1/lzmore.1.gz
/usr/share/man/fr/man1/unlzma.1.gz
/usr/share/man/fr/man1/unxz.1.gz
/usr/share/man/fr/man1/xzcat.1.gz
/usr/share/man/fr/man1/xzcmp.1.gz

I don't see a clean solution to ensure a smooth upgrade for people who 
have installed this backport. Maybe coordinate with manpages-fr 
maintainer and release updated backports for both packages, before 
Bookworm is released ?


Regards,

--
Raphaël Halimi

Bug#1028232: libmaven-javadoc-plugin-java: runtime failure with doxia 1.11.1

[tony mancill]

Package: libmaven-javadoc-plugin-java
Version: 3.0.1-4
Severity: important

Since the recent update of doxia [1], we are seeing build failures in
unstable of packages that depend on libmaven-javadoc-plugin-java.  The
error signature is:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:aggregate (default-cli) on 
project esapi: Execution default-cli of goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:aggregate failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:aggregate: 
java.lang.NoSuchMethodError: 'void 
org.apache.maven.doxia.siterenderer.sink.SiteRendererSink.(org.apache.maven.doxia.sink.render.RenderingContext)'

I believe we need to patch/upgrade maven-javadoc-plugin or restore the
missing method to doxia.

[1] 
https://tracker.debian.org/news/1405908/accepted-doxia-17-3-source-into-unstable/

Bug#1028231: unibilium: parse-terminfo test uses wrong terminfo directory

[Sven Joachim]

Source: unibilium
Version: 2.1.0-1

The parse-terminfo autopkgtest uses a wrong directory for terminfo files
below /usr:

,
| for term in ansi xterm screen rxvt-unicode; do
|   libterm=/lib/terminfo/${term%${term#?}}/${term}
|   usrterm=/usr/${libterm}
`

The (bulk of the) terminfo database is located below /usr/share/terminfo
rather than /usr/lib/terminfo.  For now this does not matter as we
install the basic terminfo files in ncurses-base under /lib/terminfo,
but after the Bookworm release I plan to relocate them to
/usr/share/terminfo, see https://bugs.debian.org/1028202.  Once that
happens, your test will still succeed but not do anything, if I read it
correctly.

There is also a flawed logic in the parse-terminfo script, it expects
that any foo-256color terminfo entry is located at the same place as its
foo counterpart.  For the terminfo entries tested this currently holds
true, but it is not guaranteed as long as the terminfo files are split
among multiple directories.