date:20230327


Source: ruby-mongo
Version: 2.5.1-1.1
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression
Control: found -1 2.4.1-1

Dear maintainer(s),

Your package has an autopkgtest, great. However, the test depends on 
mongodb-server which was removed from testing in 2019 and from unstable 
in 2020. Hence your test fails.


[Release Team hat on] Because of the timing of this bug (during the hard 
freeze) and because it doesn't indicate functionality failure of this 
package, I have marked it as bookworm-ignore.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033589: python3-theano: module 'numpy' has no attribute 'bool'.


Package: python3-theano
Version: 1.0.5+dfsg-8
Severity: serious
Control: affects -1 deepnano
Control: found -1 1.1.2+dfsg-3

Dear maintainer(s),

I think the autopkgtest of deepnano points out that theano is using what 
I believe are removed attibutes from numpy.


Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/d/deepnano/32446139/log.gz

autopkgtest [19:57:01]: test run-test.sh: [---

#1 - deepnano_basecall
/usr/lib/python3/dist-packages/theano/scalar/basic.py:2412: 
FutureWarning: In the future `np.bool` will be defined as the 
corresponding NumPy scalar.

  self.ctor = getattr(np, o_type.dtype)
Traceback (most recent call last):
  File "/usr/share/deepnano/basecall.py", line 4, in 
from rnn_fin import RnnPredictor
  File "/usr/share/deepnano/rnn_fin.py", line 1, in 
import theano as th
  File "/usr/lib/python3/dist-packages/theano/__init__.py", line 83, in 


from theano import scalar, tensor
  File "/usr/lib/python3/dist-packages/theano/scalar/__init__.py", line 
1, in 

from .basic import *
  File "/usr/lib/python3/dist-packages/theano/scalar/basic.py", line 
2460, in 

convert_to_bool = Cast(bool, name="convert_to_bool")
  ^^
  File "/usr/lib/python3/dist-packages/theano/scalar/basic.py", line 
2412, in __init__

self.ctor = getattr(np, o_type.dtype)
^
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 305, in 
__getattr__

raise AttributeError(__former_attrs__[attr])
AttributeError: module 'numpy' has no attribute 'bool'.
`np.bool` was a deprecated alias for the builtin `bool`. To avoid this 
error in existing code, use `bool` by itself. Doing this will not modify 
any behavior and is safe. If you specifically wanted the numpy scalar 
type, use `np.bool_` here.
The aliases was originally deprecated in NumPy 1.20; for more details 
and guidance see the original release note at:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. 
Did you mean: 'bool_'?

autopkgtest [19:57:01]: test run-test.sh: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033587: debtree: autopkgtest fails: output on stderr


Source: debtree
Version: 1.1.1
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always
Control: found -1 1.0.11

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report. The test itself succeeds, but the 
autopkgtest fails because there is output to stderr and without the 
allow-stderr restriction that is considered a failure.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. Because of the timing in the hard 
freeze, I have marked this bug as bookworm-ignore.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debtree/32153485/log.gz

autopkgtest [17:19:33]: test command1: [---

Reading package lists... 0%

Reading package lists... 0%

Reading package lists... 52%

Reading package lists... Done

Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree... Done

Reading state information... 0%

Reading state information... 4%

Reading state information... Done
I: The following dependencies have been excluded from the graph (skipped):
I: libc6 libstdc++6 zlib1g
digraph "debtree" {
rankdir=LR;
node [shape=box];
"debtree" -> "perl:any" [color=blue];
"perl:any" -> "perl" [dir=back,arrowtail=inv,color=green];
"perl:any" [shape=octagon];
"debtree" -> "libapt-pkg-perl" [color=blue];
"libapt-pkg-perl" -> "perl" [color=blue,label="(>= 5.36.0-4)"];
"libapt-pkg-perl" -> "perlapi-5.36.0" [color=blue];
"perlapi-5.36.0" -> "perl-base" [dir=back,arrowtail=inv,color=green];
"perl-base" -> "libcrypt1" [color=purple,style=bold,label="(>= 
1:4.1.0)"];
"perl-base" -> "dpkg" [color=purple,style=bold,label="(>= 1.17.17)"];
"perlapi-5.36.0" [shape=octagon];
"libapt-pkg-perl" -> "libapt-pkg6.0" [color=blue,label="(>= 2.1.20)"];
"libapt-pkg6.0" -> "libbz2-1.0" [color=blue];
"libapt-pkg6.0" -> "libgcc-s1" [color=blue,label="(>= 3.0)"];
"libgcc-s1" -> "gcc-12-base" [color=blue,label="(= 12.2.0-14)"];
"libapt-pkg6.0" -> "libgcrypt20" [color=blue,label="(>= 1.10.0)"];
"libgcrypt20" -> "libgpg-error0" [color=blue,label="(>= 1.27)"];
"libgpg-error0" -> "libgpg-error-l10n";
"libapt-pkg6.0" -> "liblz4-1" [color=blue,label="(>= 0.0~r127)"];
	"libapt-pkg6.0" -> "liblzma5" [color=blue,label="(>= 
5.1.1alpha+20120614)"];

"libapt-pkg6.0" -> "libsystemd0" [color=blue,label="(>= 221)"];
"libsystemd0" -> "libcap2" [color=blue,label="(>= 1:2.10)"];
"libsystemd0" -> "libgcrypt20" [color=blue,label="(>= 1.10.0)"];
"libsystemd0" -> "liblz4-1" [color=blue,label="(>= 0.0~r122)"];
"libsystemd0" -> "liblzma5" [color=blue,label="(>= 
5.1.1alpha+20120614)"];
"libsystemd0" -> "libzstd1" [color=blue,label="(>= 1.5.2)"];
"libapt-pkg6.0" -> "libudev1" [color=blue,label="(>= 183)"];
"libapt-pkg6.0" -> "libxxhash0" [color=blue,label="(>= 0.7.1)"];
"libapt-pkg6.0" -> "libzstd1" [color=blue,label="(>= 1.5.2)"];
"libapt-pkg6.0" -> "apt" [label="(>= 2.5.6)"];
"libapt-pkg-perl" -> "libgcc-s1" [color=blue,label="(>= 3.0)"];
"debtree" -> "ucf" [color=blue];
"debtree" -> "dctrl-tools" [color=blue];
"dctrl-tools" -> "grep-dctrl" [color=red];
"debtree" -> "graphviz";
"debtree" [style="setlinewidth(2)"]
"grep-dctrl" -> "dctrl-tools" [dir=back,arrowtail=inv,color=green];
"grep-dctrl" [shape=octagon];
"apt" [shape=diamond];
"dpkg" [shape=diamond];
"graphviz" [shape=diamond];
"perl" [shape=diamond];
"ucf" [shape=diamond];
}
// Excluded dependencies:
// libc6 libstdc++6 zlib1g
// total size of all shown packages: 17665024
// download size of all shown packages: 4859744
autopkgtest [17:19:34]: test command1: ---]
autopkgtest [17:19:34]: test command1:  - - - - - - - - - - results - - 
- - - - - - - -

command1 FAIL stderr:
autopkgtest [17:19:34]: test command1:  - - - - - - - - - - stderr - - - 
- - - - - - -


Reading package lists... 0%

Reading package lists... 0%

Reading package lists... 52%

Reading package lists... Done

Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree... Done

Reading state information... 0%

Reading state information... 4%

Reading state information... Done
I: The following dependencies have

Bug#1033586: cunit: autopkgtest regression: libncurses.so.6 [...] not found


Source: cunit
Version: 2.1-3-dfsg-2.4
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently (December 
2022) started to fail in testing.


Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cunit/32147692/log.gz

autopkgtest [12:20:37]: test test.sh: [---


 CUnit - A unit testing framework for C - Version 2.1-3
 http://cunit.sourceforge.net/

Suite initialized!

Suite: cunit_test
  Test: Verify 1 == 1... ...passed

Suite cleaned!


Run Summary:Type  TotalRan Passed Failed Inactive
  suites  1  1n/a  00
   tests  1  1  1  00
 asserts  1  1  1  0  n/a

Elapsed time =0.000 seconds

Done!
/usr/bin/ld: warning: libncurses.so.6, needed by 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so, 
not found (try using -rpath or -rpath-link)
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wattr_on@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `endwin@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `scrollok@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `newpad@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `mvwprintw@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wborder@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `init_pair@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `echo@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wmove@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `start_color@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `newwin@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `waddnstr@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wgetch@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wgetnstr@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `werase@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wrefresh@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `initscr@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `noecho@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `delwin@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wattr_off@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wattrset@NCURSES6_5.0.19991023'
/usr/bin/ld: 
/tmp/autopkgtest-lxc.6_783s7i/downtmp/build.8Z5/src/debian/tmp-ncurses/usr/lib/x86_64-linux-gnu/libcunit.so: 
undefined reference to `wclear@NCURSES6_5.0.19991023'

Bug#1033585: "smbios-token-ctl -d" yields "RuntimeError: generator raised StopIteration"

2023-03-27 Thread Robert Mavrinac

Package: smbios-utils

Any dependency in the smbios-tools python scripts on 
/usr/lib/python3/dist-packages/libsmbios_c/smbios_token.py imporperly raises a 
StopIteration exception with newer versions of Python 3 and terminates.

# smbios-token-ctl -d

  Token: 0x0005 - Serial Port 1 (COM2)
  value: bool = false
   Desc: Configure the system's first/only built-in serial port to respond as CO
 M2.
...
...
...

  Token: 0xf654 - unknown (unknown)
  value: bool = false
   Desc: unknown
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/libsmbios_c/smbios_token.py", line 134, 
in __iter__
raise StopIteration
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/sbin/smbios-token-ctl", line 475, in 
sys.exit( main() )
  ^^
  File "/usr/sbin/smbios-token-ctl", line 380, in main
dumpTokens(tokenTable, tokenXlator, options)
  File "/usr/sbin/smbios-token-ctl", line 214, in dumpTokens
for token in tokenTable:
RuntimeError: generator raised StopIteration


This patch corrects the problem, allowing iterations to continue as expected:

--- smbios_token.py 2023-03-27 13:47:02.135215225 -0400
+++ smbios_token.py.new 2023-03-27 13:47:32.275214757 -0400
@@ -129,9 +129,12 @@
 while 1:
 cur =DLL.token_table_get_next( self._tableobj, cur )
 if bool(cur):
-yield cur.contents
+try:
+yield cur.contents
+except StopIteration:
+return
 else:
-raise StopIteration
+return

 @traceLog()
 def __getitem__(self, id):


I am running Debian Bookworm

# uname -a
Linux lt3107-1 6.1.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 
(2023-03-05) x86_64 GNU/Linux



--


Robert Mavrinac

Systems Analyst

School of Computer Science

Room 3103B Lambton Tower

University of Windsor

401 Sunset Avenue, Windsor, ON N9B 3P4

519-253-3000 (4410)

Email: mavri...@uwindsor.ca

Bug#1033584: brial: autopkgtest fails: cannot import name 'getargspec' from 'inspect'


Source: brial
Version: 1.2.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. In this case it seems to point out 
that the python package is close to useless. (If I am reading the signs 
wrong, feel free to mark this bug as bookworm-ignore (Release Team 
member hat on).)


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/32215813/log.gz

autopkgtest [18:27:16]: test autodep8-python3: [---
Testing with python3.11:
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:72: DeprecationWarning:
Importing order_dict from here is deprecated. If you need to use it, 
please import it directly from sage.rings.polynomial.pbori.pbori

See https://trac.sagemath.org/30332 for details.
  OrderCode = type('OrderCode', (object,), dict(order_dict))
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:91: DeprecationWarning:
Importing MonomialFactory from here is deprecated. If you need to use 
it, please import it directly from sage.rings.polynomial.pbori.pbori

See https://trac.sagemath.org/30332 for details.
  Monomial = MonomialFactory()
/usr/lib/python3/dist-packages/brial/PyPolyBoRi.py:92: DeprecationWarning:
Importing PolynomialFactory from here is deprecated. If you need to use 
it, please import it directly from sage.rings.polynomial.pbori.pbori

See https://trac.sagemath.org/30332 for details.
  Polynomial = PolynomialFactory()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/brial/__init__.py", line 34, in 


from .gbcore import groebner_basis
  File "/usr/lib/python3/dist-packages/brial/gbcore.py", line 10, in 


from inspect import getargspec
ImportError: cannot import name 'getargspec' from 'inspect' 
(/usr/lib/python3.11/inspect.py)

autopkgtest [18:27:17]: test autodep8-python3: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033583: icingaweb2-module-graphite: /etc/icingaweb2/enabledModules has wrong owner/permissions

2023-03-27 Thread Andreas B. Mundt

Package: icingaweb2-module-graphite
Version: 1.2.2-1
Severity: normal
X-Debbugs-Cc: a...@debian.org

Dear Maintainer,

when installing an icinga monitoring host, I run into the problem that
/etc/icingaweb2/enabledModules is not writable by the web application.
Finishing the web based setup complained about missing permissions.

After modifying ownership and permissions like (comparable to the other 
files/directories there):

   drwxrws--- 2 www-data icingaweb2 4096 Mar 26 15:23 enabledModules 

it worked fine.

Thanks for maintaining icingaweb2-module-graphite,
best regards,

  Andi


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

Kernel: Linux 6.1.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

Versions of packages icingaweb2-module-graphite depends on:
ii  icinga-php-library 0.10.1-1
ii  icinga-php-thirdparty  0.11.0-2
ii  icingaweb2 2.11.4-2

icingaweb2-module-graphite recommends no packages.

icingaweb2-module-graphite suggests no packages.

-- no debconf information

Bug#1033582: bonnie++: autopkgtest fails: Syntax error: "then" unexpected


Source: bonnie++
Version: 2.00a+nmu1
Severity: serious
Tags: bookworm-ignore
User: debian...@lists.debian.org
Usertags: fails-always
Control: found -1 1.98

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. However, (Release Team member hat 
on) due to the current hard freeze I have marked this bug as 
bookworm-ignore. Please, if you fix this bug, also mark the test as 
superficial (the name "smoke" suggests it's not more than superficial).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/b/bonnie++/32118781/log.gz

autopkgtest [11:21:53]: test smoke: [---
/tmp/autopkgtest-lxc.6wrumbe1/downtmp/build.HhF/src/debian/tests/smoke: 
9: Syntax error: "then" unexpected

autopkgtest [11:21:53]: test smoke: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027439: elementpath breaks python-xmlschema autopkgtest: 'XMLSchemaContext' object has no attribute 'iter'

2023-03-27 Thread Emmanuel Arias

Hi Jochen,

On Mon, Mar 27, 2023 at 06:59:50PM +0200, Jochen Sprickerhof wrote:
> Hi Emmanuel,
> 
> note that the new upstream version of python-xmlschema fixes this and other
> errors but Debian unstable is frozen and the change would be too big. On the
> other hand this currently keeps the new upstream version of elementpath from
> transition to testing which is a viable outcome at the current release state
> as well. So there is not really something to do for this bug till the
> release of bookworm and afterwards an upload of the new upstream version
> should fix it.

Thanks for reply me. Ah ok, I downloaded the patch and iirc only change the
tests. But if this bug doesn't affect to elementpath, I will wait after
freeze end

Cheers,
Emmanuel

> 
> Cheers Jochen
> 
> * Emmanuel Arias  [2023-03-27 07:35]:
> > Hello,
> > 
> > Applying the patch all the tests are fixed except one:
> > 
> > ==
> > FAIL: test_xml_document_validation 
> > (xmlschema.testing._builders.TestValidator004.test_xml_document_validation)
> > --
> > Traceback (most recent call last):
> >  File 
> > "/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
> >  line 623, in test_xml_document_validation
> >self.check_data_conversion_with_lxml()
> >  File 
> > "/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
> >  line 507, in check_data_conversion_with_lxml
> >self.assertEqual(len(lxml_errors), len(self.errors), msg=xml_file)
> > AssertionError: 2 != 1 : 
> > tests/test_cases/examples/collection/collection3bis.xml
> > 
> > -
> > 
> > I will investigate a little bit today.
> > 
> > Cheers,
> > eamanu
> 
> 




signature.asc
Description: PGP signature

Bug#1033579: debcrossgen: wrong cpu family for ppc64el

Hi Jussi,

On Mon, Mar 27, 2023 at 09:33:35PM +0300, Jussi Pakkanen wrote:
> On Mon, 27 Mar 2023 at 20:45, Helmut Grohne  wrote:
> 
> > dpdk fails to cross build from source for ppc64el, because its matching
> > on the host cpu family breaks. As it turns out, debcrossgen (yes, we are
> > still using this) does not map it to the correct value. I'm attaching a
> > patch for your convenience. Please port it to env2mfile if necessary.
> 
> I assume this is serious enough to warrant a freeze exception to
> upload a new version?

If this was serious, the severity of this bug was serious. Quite to the
contrary. The fact that it took us so long to even discover this issue
serves as a testament of how few packages are affected by this. If you
happen to require an unblock for other reasons, you may piggy back this
change, but I don't think it justifies an upload on its own.

Helmut

Bug#1033581: xmpp-dns: Don't use CNAME look up for SRV look up.

2023-03-27 Thread Martin Dosch

Package: xmpp-dns
Version: 0.3.4-1+b3
Severity: normal

Dear Maintainer,

`xmpp-dns example.org` is performing a CNAME look up and performs the 
SRV look up on the result of the CNAME look up.
This is wrong as a CNAME for example.org is not a CNAME for 
_xmpp-client._tcp.example.org.

Best regards,
Martin

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

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

Versions of packages xmpp-dns depends on:
ii  libc6  2.36-8

xmpp-dns recommends no packages.

xmpp-dns suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1033579: debcrossgen: wrong cpu family for ppc64el

2023-03-27 Thread Jussi Pakkanen

On Mon, 27 Mar 2023 at 20:45, Helmut Grohne  wrote:

> dpdk fails to cross build from source for ppc64el, because its matching
> on the host cpu family breaks. As it turns out, debcrossgen (yes, we are
> still using this) does not map it to the correct value. I'm attaching a
> patch for your convenience. Please port it to env2mfile if necessary.

I assume this is serious enough to warrant a freeze exception to
upload a new version?

Bug#1033538: chkrootkit: Chkrootkit reports a false positive?

2023-03-27 Thread Antonio

Because every morning I receive an email from 
"/etc/cron.daily/chkrootkit" that informs me of this.


Of course I can deactivate the check but I would not like to lose other 
useful information for the security of the system.


Il 27/03/23 19:41, Richard Lewis ha scritto:

control: tags -1 + moreinfo

overall this looks like the intended behaviour, based on the 
information provided, rather than something that needs fixing. Or is 
there another reason you considered this a bug?


On Mon, 27 Mar 2023, 07:51 antonio wrote:


It seems that chkrootkit returns a false positive... or not?


$ /usr/lib/chkrootkit/ifpromisc
lo: not promisc and no packet sniffer sockets
eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1056])
eth2: PACKET SNIFFER(/usr/sbin/NetworkManager[1056])


If you run ifpromisc directly im not sure quite what output you 
expected, but the above looks correct, based on the information provided.


Network manager can be reasonably classed as a 'packet sniffer' as it 
has the ability to read network traffic.


If network manager was not started intentionally (standard for a 
server) you would want to know about it.


If it was started by you because you are running a standard gnome 
desktop then it is indeed a false positive


...but there is no way software can reliably tell which of these 
circumstances apply.


See the document about false positives in /usr/share/doc/chkrootkit 
for more information on how to filter out such messages from the daily 
report.

Bug#1033538: chkrootkit: Chkrootkit reports a false positive?

2023-03-27 Thread Richard Lewis

control: tags -1 + moreinfo

overall this looks like the intended behaviour, based on the information
provided, rather than something that needs fixing. Or is there another
reason you considered this a bug?

On Mon, 27 Mar 2023, 07:51 antonio wrote:

>
> It seems that chkrootkit returns a false positive... or not?
>

$ /usr/lib/chkrootkit/ifpromisc
> lo: not promisc and no packet sniffer sockets
> eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1056])
> eth2: PACKET SNIFFER(/usr/sbin/NetworkManager[1056])
>

If you run ifpromisc directly im not sure quite what output you expected,
but the above looks correct, based on the information provided.

Network manager can be reasonably classed as a 'packet sniffer' as it has
the ability to read network traffic.

If network manager was not started intentionally (standard for a server)
you would want to know about it.

If it was started by you because you are running a standard gnome desktop
then it is indeed a false positive

...but there is no way software can reliably tell which of these
circumstances apply.

See the document about false positives in /usr/share/doc/chkrootkit for
more information on how to filter out such messages from the daily report.

Bug#1033580: fabulous FTCBFS: multiple reasons

Source: fabulous
Version: 0.4.0+dfsg1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

fabulous cannot be cross built from source as is. The initial problem is
failure to satisfy cross Build-Depends. The immediate offender (sphinx)
is well known and we know that it cannot be marked Multi-Arch: foreign,
because it is sometimes used in architecture-dependent ways. As a
result, client packages must make the decision of which architecture
they need it for. So we annotate sphinx dependencies :native. While that
gets it a bit further, now we see an architecture conflict on python3.
Same problem, same solution: We annotate the interpreter with :native.
This finally lets us build except that xtermspeedup.so is built with the
wrong compiler. dpkg's buildtools.mk can fix that. And finally,
something inside dh-python explodes when the hosts' sysconfig data is
missing due to missing libpython3-all-dev. So here we go with a patch
that fixes everything.

A couple of final remarks. I opted dropping python3-minimal, because it
is implied in python3-all. I also think that you don't actually need
python3-all and that python3 should be sufficient. Even though fabulous
builds a shared object, this object is not dependent on the Python
version, so we only need it once for all versions. Moving fro
python3-all to python3 should remove the need to rebuild fabulous for
Python transitions. I leave this up to you.

Helmut
diff --minimal -Nru fabulous-0.4.0+dfsg1/debian/changelog 
fabulous-0.4.0+dfsg1/debian/changelog
--- fabulous-0.4.0+dfsg1/debian/changelog   2021-09-02 08:09:04.0 
+0200
+++ fabulous-0.4.0+dfsg1/debian/changelog   2023-03-27 11:47:44.0 
+0200
@@ -1,3 +1,15 @@
+fabulous (0.4.0+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop B-D: python3-minimal implied in python3-all.
++ Annotate B-D that cannot be marked M-A:foreign but are used natively
+  with :native.
++ Add missing libpython3-all-dev for sysconfig data.
++ Let dpkg's buildtools.mk initialize CC.
+
+ -- Helmut Grohne   Mon, 27 Mar 2023 11:47:44 +0200
+
 fabulous (0.4.0+dfsg1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru fabulous-0.4.0+dfsg1/debian/control 
fabulous-0.4.0+dfsg1/debian/control
--- fabulous-0.4.0+dfsg1/debian/control 2021-09-02 08:09:02.0 +0200
+++ fabulous-0.4.0+dfsg1/debian/control 2023-03-27 11:47:44.0 +0200
@@ -5,13 +5,13 @@
 Uploaders: Jonathan Carter 
 Build-Depends: debhelper-compat (= 13),
dh-python,
-   python3-all,
+   libpython3-all-dev,
+   python3-all:native,
python3-doc,
-   python3-minimal,
-   python3-pil,
+   python3-pil:native,
python3-setuptools,
-   python3-sphinx,
-   python3-sphinxcontrib.programoutput
+   python3-sphinx:native,
+   python3-sphinxcontrib.programoutput:native,
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://jart.github.io/fabulous/
diff --minimal -Nru fabulous-0.4.0+dfsg1/debian/rules 
fabulous-0.4.0+dfsg1/debian/rules
--- fabulous-0.4.0+dfsg1/debian/rules   2020-10-22 12:17:59.0 +0200
+++ fabulous-0.4.0+dfsg1/debian/rules   2023-03-27 11:47:44.0 +0200
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+include /usr/share/dpkg/buildtools.mk
 CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
 CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)

Bug#1033579: debcrossgen: wrong cpu family for ppc64el

Package: meson
Version: 1.0.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:dpdk

Hi Jussi,

dpdk fails to cross build from source for ppc64el, because its matching
on the host cpu family breaks. As it turns out, debcrossgen (yes, we are
still using this) does not map it to the correct value. I'm attaching a
patch for your convenience. Please port it to env2mfile if necessary.

Helmut
diff --minimal -Nru meson-1.0.1/debian/changelog meson-1.0.1/debian/changelog
--- meson-1.0.1/debian/changelog2023-03-11 22:06:44.0 +0100
+++ meson-1.0.1/debian/changelog2023-03-27 11:38:05.0 +0200
@@ -1,3 +1,10 @@
+meson (1.0.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debcrossgen: fix cpu family on ppc64el. Closes: #-1.
+
+ -- Helmut Grohne   Mon, 27 Mar 2023 11:38:05 +0200
+
 meson (1.0.1-5) unstable; urgency=medium
 
   * Fix incorrect usage of fgetc/fputc. Closes: #1032168.
diff --minimal -Nru meson-1.0.1/debian/debcrossgen 
meson-1.0.1/debian/debcrossgen
--- meson-1.0.1/debian/debcrossgen  2023-02-27 00:45:36.0 +0100
+++ meson-1.0.1/debian/debcrossgen  2023-03-27 11:38:01.0 +0200
@@ -71,7 +71,9 @@
 write_args_line(ofile, 'cpp_link_args', cpp_link_args)
 
 cpu_family_map = dict(mips64el="mips64",
-  i686='x86')
+  i686='x86',
+  powerpc64le="ppc64",
+  )
 cpu_map = dict(armhf="arm7hlf",
mips64el="mips64",
powerpc64le="ppc64",

Bug#1033578: bullseye-pu: package joblib/0.17.0-4+deb11u1

Package: release.debian.org
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: job...@packages.debian.org, Chiara Marmo 
, Graham Inggs 
Control: affects -1 + src:joblib

[ Reason ]

Fix no-dsa security vulnerability CVE-2022-21797.

[ Impact ]

The n_jobs parameter of the parallel_backend, which used to be a string
containing a Python expression, becomes restricted to fairly basic
arithmetic expressions. Using it in another way was not intended.

[ Tests ]

Upstream test suite is extended and run during build.

[ Risks ]

Someone may have used n_jobs in ways not intended by upstream.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

I cherry-picked the relevant upstream commit and updated the hunk
context.

[ Other info ]

The security team tagged this vulnerability no-dsa.

Upstream had multiple attempts at fixing this and buster includes a
vulnerable patch. This cherry-pick skips the vulnerable patch and goes
to the real fix directly.

I am not interested in refining the updated (unless it also affects
buster). This is a drive-by contribution as part of an LTS upload.

Helmut
diff --minimal -Nru joblib-0.17.0/debian/changelog 
joblib-0.17.0/debian/changelog
--- joblib-0.17.0/debian/changelog  2021-06-12 10:19:09.0 +0200
+++ joblib-0.17.0/debian/changelog  2023-03-27 15:25:19.0 +0200
@@ -1,3 +1,10 @@
+joblib (0.17.0-4+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2022-21797 (Closes: #1020820)
+
+ -- Helmut Grohne   Mon, 27 Mar 2023 15:25:19 +0200
+
 joblib (0.17.0-4) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru joblib-0.17.0/debian/patches/CVE-2022-21797.patch 
joblib-0.17.0/debian/patches/CVE-2022-21797.patch
--- joblib-0.17.0/debian/patches/CVE-2022-21797.patch   1970-01-01 
01:00:00.0 +0100
+++ joblib-0.17.0/debian/patches/CVE-2022-21797.patch   2023-03-27 
15:25:08.0 +0200
@@ -0,0 +1,121 @@
+From 54f4d21f098591c77b48c9acfffaa4cf0a45282b Mon Sep 17 00:00:00 2001
+From: Adrin Jalali 
+Date: Mon, 12 Sep 2022 17:17:28 +0200
+Subject: [PATCH] FIX parse pre-dispatch with AST instead of calling eval
+ (#1327)
+
+---
+ CHANGES.rst   |  2 +-
+ joblib/_utils.py  | 44 +++
+ joblib/parallel.py|  7 +++
+ joblib/test/test_utils.py | 27 
+ 4 files changed, 75 insertions(+), 5 deletions(-)
+ create mode 100644 joblib/_utils.py
+ create mode 100644 joblib/test/test_utils.py
+
+diff --git a/joblib/_utils.py b/joblib/_utils.py
+new file mode 100644
+index 0..2dbd4f636
+--- /dev/null
 b/joblib/_utils.py
+@@ -0,0 +1,44 @@
++# Adapted from https://stackoverflow.com/a/9558001/2536294
++
++import ast
++import operator as op
++
++# supported operators
++operators = {
++ast.Add: op.add,
++ast.Sub: op.sub,
++ast.Mult: op.mul,
++ast.Div: op.truediv,
++ast.FloorDiv: op.floordiv,
++ast.Mod: op.mod,
++ast.Pow: op.pow,
++ast.USub: op.neg,
++}
++
++
++def eval_expr(expr):
++"""
++>>> eval_expr('2*6')
++12
++>>> eval_expr('2**6')
++64
++>>> eval_expr('1 + 2*3**(4) / (6 + -7)')
++-161.0
++"""
++try:
++return eval_(ast.parse(expr, mode="eval").body)
++except (TypeError, SyntaxError, KeyError) as e:
++raise ValueError(
++f"{expr!r} is not a valid or supported arithmetic expression."
++) from e
++
++
++def eval_(node):
++if isinstance(node, ast.Num):  # 
++return node.n
++elif isinstance(node, ast.BinOp):  #   
++return operators[type(node.op)](eval_(node.left), eval_(node.right))
++elif isinstance(node, ast.UnaryOp):  #   e.g., -1
++return operators[type(node.op)](eval_(node.operand))
++else:
++raise TypeError(node)
+diff --git a/joblib/parallel.py b/joblib/parallel.py
+index 1c2fe18f7..6e7b1b19a 100644
+--- a/joblib/parallel.py
 b/joblib/parallel.py
+@@ -27,6 +27,7 @@
+  LokyBackend)
+ from .externals.cloudpickle import dumps, loads
+ from .externals import loky
++from ._utils import eval_expr
+ 
+ # Make sure that those two classes are part of the public joblib.parallel API
+ # so that 3rd party backend implementers can import them from here.
+@@ -1051,7 +1052,9 @@ def _batched_calls_reducer_callback():
+ else:
+ self._original_iterator = iterator
+ if hasattr(pre_dispatch, 'endswith'):
+-pre_dispatch = eval(pre_dispatch)
++pre_dispatch = eval_expr(
++pre_dispatch.replace("n_jobs", str(n_jobs))
++)
+ self._pre_dispatch_amount = pre_dispatch = int(pre_dispatch)
+ 
+ # The main thread will consume the first pre_dispatch

Bug#1033577: ncftp FTCBFS: does not pass --host to configure

Source: ncftp
Version: 2:3.2.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ncftp fails to cross build from source, because it does not pass --host
to configure. Beyond that it also needs to export a suitable CC. I'm
attaching a patch for your convenience.

Helmut
diff --minimal -Nru ncftp-3.2.6/debian/changelog ncftp-3.2.6/debian/changelog
--- ncftp-3.2.6/debian/changelog2022-07-17 20:24:42.0 +0200
+++ ncftp-3.2.6/debian/changelog2023-03-27 08:11:06.0 +0200
@@ -1,3 +1,10 @@
+ncftp (2:3.2.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass cross tools and --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 27 Mar 2023 08:11:06 +0200
+
 ncftp (2:3.2.6-1) unstable; urgency=medium
 
   * new upstream release from 2016-11-27 ;)
diff --minimal -Nru ncftp-3.2.6/debian/rules ncftp-3.2.6/debian/rules
--- ncftp-3.2.6/debian/rules2022-07-17 20:24:42.0 +0200
+++ ncftp-3.2.6/debian/rules2023-03-27 08:11:06.0 +0200
@@ -5,6 +5,9 @@
 
 include /usr/share/dpkg/architecture.mk
 
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
@@ -16,6 +19,7 @@
# Add here commands to configure the package.
TAR=/bin/tar \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" 
./configure \
+   --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--sysconfdir=/etc \

Bug#1033576: RFP: crqt-ng -- cross-platform open source e-book reader using crengine-ng

2023-03-27 Thread программист некто

Package: wnpp
Severity: wishlist

Package name : crqt-ng
Version : 1.0.10 
URL : https://gitlab.com/coolreader-ng/crqt-ng
 
crqt-ng - cross-platform open source e-book reader using crengine-ng. It is a 
fork of the CoolReader project.
In fact, it is a Qt frontend for the crengine-ng library.
Supported platforms: Windows, Linux, MacOS. Basically all platforms that are 
supported by crengine-ng, Qt and cmake.
Supported e-book formats through the use of the crengine-ng library: fb2, fb3 
(incomplete), epub (non-DRM), doc, docx, odt, rtf, pdb, mobi (non-DRM), txt, 
html, Markdown, chm, tcr.

Main functions:
- Ability to display 2 pages at the same time
- Displaying and Navigating Book Contents
- Text search
- Text selection
- Copy the selected text to the clipboard
- Word hyphenation using hyphenation dictionaries
- Most complete support for FB2 - styles, tables, footnotes at the bottom of 
the page
- Extensive font rendering capabilities: use of ligatures, kerning, hinting 
option selection, floating punctuation, simultaneous use of several fonts, 
including fallback fonts
- Detection of the main font incompatible with the language of the book
- Reading books directly from a ZIP archive
- TXT auto reformat, automatic encoding recognition
- Flexible styling with CSS files
- Background pictures, textures, or solid background
- HiDPI support
- Multi-tabbed interface

Bug#1024237: drop meaningless EMails

2023-03-27 Thread Christian Franke


What is the idea behind these emails?


The drive reports bad sectors pending for reallocation (HDD) or retirement 
(SSD).


What is the recommended way to turn them off?


Run a long self-test (smartctl -t long ...). Also check Device Statistics and 
Pending Defects log (smartctl -l devstat -l pending ...).
If no bad LBA is reported, disable the emails by '-C 197+ -U 198+' in smartd.conf. See 
"man smartd.conf" for details.
Otherwise fix the bad sectors by overwriting.

--
Regards,
Christian
smartmontools.org

Bug#1033575: digikam: bookworm build: No 16-bit color in jpeg2000 and heif, missing gmic-qt

2023-03-27 Thread J. Pfennig

Package: digikam
Version: 4:7.9.0-1+b2
Severity: important

Dear Maintainer,

Thanks for building digikam for bookworm. As you shurely know this build
is quite important as recent appimage upstream builds crash on bookworm
(I believe that's a know problem).

The latest usable appimage for bookworm was 7.7 (7.8 loads too slow, 7.9
and 7.10 crash).

The 7.7 appimage (and earlier) correctly load jpeg2000 images with more
than 8-bits per color-channel (I use 10-bits for my purposes). 

Anyhow, the 7.9 build for bookworm loads jpeg2000 and heif only with
8-bit per color-channel (implied down-conversion). Tiffs with 16-bit per
channel load correctly (unfortunately only 8/16-bit tiffs work with
kde's libtiff). Needless to say that imagemagick 7.1.0 works fine with
8/10/16-bit tiff/jpeg2000/heif.

Also gmic-qt is missing in the debian build (it works fine if the plugin
is copied from the app-immage). gmic-qt for digikam did never support
16-bit color, but that's an upstream-bug.

Yours
Jürgen

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

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

Versions of packages digikam depends on:
ii  digikam-data  4:7.9.0-1
ii  digikam-private-libs  4:7.9.0-1+b2
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libkf5configcore5 5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.6
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5sql55.15.8+dfsg-3
ii  libqt5sql5-mysql  5.15.8+dfsg-3
ii  libqt5sql5-sqlite 5.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  perl  5.36.0-7

Versions of packages digikam recommends:
pn  ffmpegthumbs   
ii  firefox-esr [www-browser]  102.9.0esr-2
ii  konqueror [www-browser]4:22.12.3-1

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

-- no debconf information

Bug#1033574: RFS: ghostscript/10.0.0~dfsg-10 [QA] -- interpreter for the PostScript language and for PDF

2023-03-27 Thread Håvard F . Aasen

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : ghostscript
   Version  : 10.0.0~dfsg-10
   Upstream contact : Ghostscript development and discussion 

 * URL  : https://www.ghostscript.com/
 * License  : X11, GPL-3+ with Autoconf exception, GAP~configure, 
BSD-3-Clause~Adobe, LGPL-2.1, Expat~Ghostgum, GPL-2+, AGPL-3+ with font 
exception, public-domain, none, Apache-2.0, Expat, ISC, GPL-1+, AGPL-3+ and 
custom, Expat~SunSoft with SunSoft exception, ZLIB, MIT-Open-Group, NTP~Lucent, 
AGPL-3+, BSD-3-Clause, NTP~WSU, AGPL-3+ and FTL
 * Vcs  : https://salsa.debian.org/debian/ghostscript
   Section  : text

The source builds the following binary packages:

  ghostscript - interpreter for the PostScript language and for PDF
  ghostscript-doc - interpreter for the PostScript language and for PDF - 
Documentation
  libgs10 - interpreter for the PostScript language and for PDF - Library
  libgs-common - interpreter for the PostScript language and for PDF - ICC 
profiles
  libgs10-common - interpreter for the PostScript language and for PDF - common 
files
  libgs-dev - interpreter for the PostScript language and for PDF - Development 
Files
  ghostscript-x - transitional package for ghostscript
  libgs9-common - transitional package for libgs-common

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/ghostscript/ghostscript_10.0.0~dfsg-10.dsc

Changes since the last upload:

 ghostscript (10.0.0~dfsg-10) unstable; urgency=medium
 .
   * QA upload.
   * Add patch from upstream to fix cross build. Closes: #717825


This upload has been approved for Bookworm [1], and the changes has been
committed to a private fork [2]. There are some commits that hasn't been
released yet, this made my commits a bit messy. If there is any cleaner
way to do this, I would like to hear about them.

Regards,
Håvard


[1] https://bugs.debian.org/1033219
[2] https://salsa.debian.org/haava/ghostscript

Bug#1033489: sudo lecture is missing

2023-03-27 Thread Sven Joachim

On 2023-03-27 11:59 +0200, Marc Haber wrote:

> On Mon, Mar 27, 2023 at 08:59:25AM +1000, Thom wrote:
>> But I can't find a reason to drop lecture after so many years.
>
> Indeed, upstream didn't comment about that. Please talk to upstream
> regarding this, I am not sure whether it is a wise idea to deviat from
> upstream here.

Ahem, this has nothing to do with upstream, but is a Debian-specific
change which you made a year ago:

,
| sudo (1.9.10-1) experimental; urgency=medium
|
|   * adopt configure changes from Ubuntu
| --without-lecture --with-tty-tickets --enable-admin-flag (Closes: 
#1006273)
| ^
|  -- Marc Haber   Fri, 18 Mar 2022 14:31:30 
+0100
`

Cheers,
   Sven

Bug#1027439: elementpath breaks python-xmlschema autopkgtest: 'XMLSchemaContext' object has no attribute 'iter'

2023-03-27 Thread Jochen Sprickerhof


Hi Emmanuel,

note that the new upstream version of python-xmlschema fixes this and 
other errors but Debian unstable is frozen and the change would be too 
big. On the other hand this currently keeps the new upstream version of 
elementpath from transition to testing which is a viable outcome at the 
current release state as well. So there is not really something to do 
for this bug till the release of bookworm and afterwards an upload of 
the new upstream version should fix it.


Cheers Jochen

* Emmanuel Arias  [2023-03-27 07:35]:

Hello,

Applying the patch all the tests are fixed except one:

==
FAIL: test_xml_document_validation 
(xmlschema.testing._builders.TestValidator004.test_xml_document_validation)
--
Traceback (most recent call last):
 File 
"/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
 line 623, in test_xml_document_validation
   self.check_data_conversion_with_lxml()
 File 
"/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
 line 507, in check_data_conversion_with_lxml
   self.assertEqual(len(lxml_errors), len(self.errors), msg=xml_file)
AssertionError: 2 != 1 : tests/test_cases/examples/collection/collection3bis.xml

-

I will investigate a little bit today.

Cheers,
eamanu





signature.asc
Description: PGP signature

Bug#1033573: unblock: ruby3.1/3.1.2-7

2023-03-27 Thread Antonio Terceiro

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby...@packages.debian.org
Control: affects -1 + src:ruby3.1

Please unblock package ruby3.1

[ Reason ]
This release updates the openssl bindings, fixing a few regressions that
have been identified.

[ Impact ]
Without these changes, at least gitlab doesn't work correctly.

[ Tests ]
I had uploaded this to experimental some time ago, and the pseudo
excuses against unstable showed no regressions.

[ Risks ]
The changes are contained to the implementatin of a few openssl methods.
I think the risk is low. I had also tried updating to the new upstream
release 3.1.3, which includes this change, but thought that contained
too many non-critical changes.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I'm also attaching the actual patch included in this upload as it is
easier to read than the diff-in-diff in the debdiff.

unblock ruby3.1/3.1.2-7
diff --git a/debian/changelog b/debian/changelog
index c6bd035fc..54e474d21 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+ruby3.1 (3.1.2-7) unstable; urgency=medium
+
+  * Upload to unstable
+
+ -- Antonio Terceiro   Sat, 25 Mar 2023 14:20:34 -0300
+
+ruby3.1 (3.1.2-7~exp) experimental; urgency=medium
+
+  * Update openssl extension to to 3.0.1 (Closes: #1032070)
+
+ -- Antonio Terceiro   Sun, 05 Mar 2023 17:13:36 -0300
+
 ruby3.1 (3.1.2-6) unstable; urgency=medium
 
   * Add missing dependencies for pkg-config test
diff --git a/debian/patches/openssl-3.0.1.patch b/debian/patches/openssl-3.0.1.patch
new file mode 100644
index 0..0762cb65e
--- /dev/null
+++ b/debian/patches/openssl-3.0.1.patch
@@ -0,0 +1,495 @@
+From: Antonio Terceiro 
+Date: Sun, 5 Mar 2023 17:09:05 -0300
+Subject: openssl 3.0.1
+
+This is a combination of several patches for openssl extension that fix
+bugs in its version 3.0.0.
+
+Forwarded: not-needed
+---
+ ext/openssl/History.md | 40 +
+ ext/openssl/extconf.rb |  5 +++--
+ ext/openssl/lib/openssl/pkey.rb|  8 +++
+ ext/openssl/lib/openssl/version.rb |  2 +-
+ ext/openssl/openssl.gemspec|  2 +-
+ ext/openssl/ossl_hmac.c|  8 +++
+ ext/openssl/ossl_pkey.c| 46 +++---
+ ext/openssl/ossl_pkey_ec.c |  4 
+ ext/openssl/ossl_x509cert.c|  6 ++---
+ ext/openssl/ossl_x509crl.c |  6 ++---
+ ext/openssl/ossl_x509req.c |  6 ++---
+ ext/openssl/ossl_x509revoked.c |  6 ++---
+ test/openssl/test_hmac.rb  |  8 +++
+ test/openssl/test_pkey_dsa.rb  | 19 
+ test/openssl/test_pkey_ec.rb   | 25 +
+ test/openssl/test_pkey_rsa.rb  |  5 +
+ test/openssl/test_ssl.rb   |  6 +
+ 17 files changed, 183 insertions(+), 19 deletions(-)
+
+diff --git a/ext/openssl/History.md b/ext/openssl/History.md
+index 479ec3b..a4f6bd7 100644
+--- a/ext/openssl/History.md
 b/ext/openssl/History.md
+@@ -1,3 +1,27 @@
++Version 3.0.1
++=
++
++Merged changes in 2.1.4 and 2.2.2. Additionally, the following issues are fixed
++by this release.
++
++Bug fixes
++-
++
++* Add missing type check in OpenSSL::PKey::PKey#sign's optional parameters.
++  [[GitHub #531]](https://github.com/ruby/openssl/pull/531)
++* Work around OpenSSL 3.0's HMAC issues with a zero-length key.
++  [[GitHub #538]](https://github.com/ruby/openssl/pull/538)
++* Fix a regression in OpenSSL::PKey::DSA.generate's default of 'q' size.
++  [[GitHub #483]](https://github.com/ruby/openssl/issues/483)
++  [[GitHub #539]](https://github.com/ruby/openssl/pull/539)
++* Restore OpenSSL::PKey.read's ability to decode "openssl ecparam -genkey"
++  output when linked against OpenSSL 3.0.
++  [[GitHub #535]](https://github.com/ruby/openssl/pull/535)
++  [[GitHub #540]](https://github.com/ruby/openssl/pull/540)
++* Restore error checks in OpenSSL::PKey::EC#{to_der,to_pem}.
++  [[GitHub #541]](https://github.com/ruby/openssl/pull/541)
++
++
+ Version 3.0.0
+ =
+ 
+@@ -100,6 +124,12 @@ Notable changes
+ [[GitHub #342]](https://github.com/ruby/openssl/issues/342)
+ 
+ 
++Version 2.2.2
++=
++
++Merged changes in 2.1.4.
++
++
+ Version 2.2.1
+ =
+ 
+@@ -194,6 +224,16 @@ Notable changes
+   [[GitHub #297]](https://github.com/ruby/openssl/pull/297)
+ 
+ 
++Version 2.1.4
++=
++
++Bug fixes
++-
++
++* Do not use pkg-config if --with-openssl-dir option is specified.
++ [[GitHub #486]](https://github.com/ruby/openssl/pull/486)
++
++
+ Version 2.1.3
+ =
+ 
+diff --git a/ext/openssl/extconf.rb b/ext/openssl/extconf.rb
+index fedcb93..d2d7893 100644
+--- a/ext/openssl/extconf.rb
 b/ext/openssl/extconf.rb
+@@ -13,7 +13,7 @@
+ 
+ require

Bug#1033572: samba: 2:4.17.6+dfsg-1 has not reached testing after more than 10 days

2023-03-27 Thread Alban Browaeys

Package: samba
Version: 2:4.17.5+dfsg-2
Severity: normal

Dear Maintainer,

I have noticed that even though 2:4.17.6+dfsg-1 has reached stable backports 
(bullseye-backports)
it has not reached bookworm testing from more than 10 days.

This, even though it has build in unstable for all architecture that are
already in testing and I see no new RC critical bug to samba (maybe one
if its child packages?).

Is there a known issue which prevent the transitition?
Having a version in bullseye-backports newer than testing spam me with upgrade 
available
while I cannot upgrade to bullseye-backports per it depends on older
python than my current 4.17.5 bookworm samba. This is minor but if could
be fixed would help lower maintainence burden.

Cheers,
Alban

-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf not present

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

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

Versions of packages samba depends on:
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.36-8
ii  libcups2 2.4.2-2
ii  libgnutls30  3.7.9-1
ii  libldap-2.5-02.5.13+dfsg-2~bpo11+1
ii  libldb2  2:2.6.1+samba4.17.5+dfsg-2
ii  libpam-modules   1.4.0-9+deb11u1
ii  libpam-runtime   1.4.0-9+deb11u1
ii  libpopt0 1.18-2
ii  libtalloc2   2.4.0-f2
ii  libtasn1-6   4.16.0-2+deb11u1
ii  libtdb1  1.4.8-2
ii  libtevent0   0.14.1-1
ii  passwd   1:4.13+dfsg1-1+b1
ii  procps   2:3.3.17-5
ii  python3  3.11.2-1
ii  python3-dnspython2.3.0-1
ii  python3-samba2:4.17.5+dfsg-2
ii  samba-common 2:4.17.5+dfsg-2
ii  samba-common-bin 2:4.17.5+dfsg-2
ii  samba-libs   2:4.17.5+dfsg-2
ii  tdb-tools1.4.7-2~bpo11+1

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.18.0-2+deb11u1
ii  python3-markdown3.4.1-2
pn  samba-ad-provision  
pn  samba-dsdb-modules  
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9 
pn  bind9utils
pn  ctdb  
pn  ldb-tools 
pn  ntp | chrony  
pn  ufw   
ii  winbind   2:4.17.5+dfsg-2

-- no debconf information
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which 
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic 
# errors. 

#=== Global Settings ===

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = ILIADE

 Networking 

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
;   interfaces = 127.0.0.0/8 eth0

# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself.  However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
;   bind interfaces only = yes



 Debugging/Accounting 

# This tells Samba to use a separate log file for each machine
# that connects
   log file = /var/log/samba/log.%m

# Cap the size of the individual log files (in KiB).
   max log size = 1000

# We want Samba to only log to /var/log/samba/log.{smbd,nmbd}.
# Append syslog@1 if you want important messages to be sent to syslog too.
   logging = file

# Do something sensible when Samba crashes: mail the admin a backtrace
   panic action = /usr/share/samba/panic-action %d


### Authentication ###

#

Bug#942433: samba: Cannot mount share on samba3 server from samba4 client: protocol negotiation failed

2023-03-27 Thread Alban Browaeys

On Mon, 31 Oct 2022 10:43:49 +0300 Michael Tokarev 
wrote:
> Control: tag -1 + moreinfo
> 
> Hi!
> 
> This bug appears to be about an old samba version (4.11).
> There were a few corner cases with old protocols negotiation
> fixed meanwhile, including some bugs reported in the Debian BTS.
> 
> Current 4.16 client can mount shares from older servers, including
> old samba and windows XP, provided there's a way to enable older
> protocols.
> 
> It looks like what's left is a way for qemu slirp (usermode)
> networking to be able to add an option to enable old protocols
> when running smbd. And this is definitely a qemu job to do.
> 
> What do you think?
> 
> Thanks,
> 
> /mjt
> 
> 

mjt, it looks like you forgot to send your email to the two bug
reporter, or did you send this email to the initial reporter Igor and
the qemu user Jordi that hijacked this bug in another batch?

Cheers,
Alban

Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section

2023-03-27 Thread Michael Biebl


Control: tags -1 + upstream

Thanks for the bug report.

Please consider raising this issue upstream at
https://github.com/systemd/systemd/issues





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033567: systemd: move /usr/bin/kernel-install to package systemd-boot

2023-03-27 Thread Michael Biebl


Control: tags -1 + moreinfo

Am 27.03.23 um 16:29 schrieb Emanuele Rocca:


the systemd binary package currently ships the following files:

  /usr/bin/kernel-install
  /usr/share/bash-completion/completions/kernel-install
  /usr/share/man/man8/kernel-install.8.gz
  /usr/share/zsh/vendor-completions/_kernel-install

Given that AFAIU kernel-install is not particularly useful without
systemd-boot, please consider moving the files mentioned above to the
systemd-boot binary package.



See
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138#note_292202


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033571: unblock: keyman/16.0.139-4

2023-03-27 Thread Eberhard Beilharz


Package: release.debian.org
Severity: normal
User:release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc:debian-input-met...@lists.debian.org,e...@sil.org

Please unblock package keyman.

[ Reason ]

While keyman has autopkgtests and so would qualify for automatic migration, the 
tests are skipped on s390x.
The reason is that Keyman doesn't yet support big endian architecture and so 
can't run on s390x (even though it's
possible to build it on that platform it won't work). See upstream 
bughttps://github.com/keymanapp/keyman/issues/5111.

Included are only small changes: one is a small fix in the postinst script, the 
other is an update of a timestamp in a
locale. It also excludes s390x from building since that makes more sense than 
building an unusable library.

Another reason why I'd like to get this version approved is that it brings the 
version in Debian on par with the upstream
version which simplifies user help requests.

[ Impact ]

The user won't notice any difference, but it would be helpful for the support 
team if the users would use the same version
that is used on the other platforms.

[ Tests ]

Manually installed the binaries and verified that things work as expected.

[ Risks ]

Changes are minimal. I can't think of any negative side effects.

[ Checklist ]

  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock keyman/16.0.139-4

diff -Nru keyman-16.0.138/core/VERSION.md keyman-16.0.139/core/VERSION.md
--- keyman-16.0.138/core/VERSION.md 2023-02-01 04:55:31.0 +0100
+++ keyman-16.0.139/core/VERSION.md 2023-03-16 08:24:24.0 +0100
@@ -1 +1 @@
-16.0.138
\ No newline at end of file
+16.0.139
\ No newline at end of file
diff -Nru keyman-16.0.138/crowdin.yml keyman-16.0.139/crowdin.yml
--- keyman-16.0.138/crowdin.yml 2023-01-31 19:04:42.0 +0100
+++ keyman-16.0.139/crowdin.yml 2023-03-16 08:22:51.0 +0100
@@ -59,6 +59,7 @@
   locale:
 de: de
 fr: fr
+kn: kn
 
   - source: /windows/src/desktop/setup/locale/en/strings.xml
 dest: /windows/setup/strings.xml
@@ -68,6 +69,7 @@
   locale:
 de: de
 fr: fr
+kn: kn
 
   # iOS files
 
diff -Nru keyman-16.0.138/debian/changelog keyman-16.0.139/debian/changelog
--- keyman-16.0.138/debian/changelog2023-02-11 18:39:13.0 +0100
+++ keyman-16.0.139/debian/changelog2023-03-24 16:05:07.0 +0100
@@ -1,3 +1,29 @@
+keyman (16.0.139-4) unstable; urgency=medium
+
+  * debian/tests: Revert previous change and ignore s390x from autopkgtests
+
+ -- Eberhard Beilharz   Fri, 24 Mar 2023 16:05:07 +0100
+
+keyman (16.0.139-3) unstable; urgency=medium
+
+  * debian/tests: Run autopkgtests on s390x but immediately return
+
+ -- Eberhard Beilharz   Wed, 22 Mar 2023 19:25:02 +0100
+
+keyman (16.0.139-2) unstable; urgency=medium
+
+  * Don't build on s390x because Keyman doesn't work on big-endian 
architectures
+(upstream bug https://github.com/keymanapp/keyman/issues/5111)
+
+ -- Eberhard Beilharz   Mon, 20 Mar 2023 19:54:44 +0100
+
+keyman (16.0.139-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Re-release to Debian
+
+ -- Eberhard Beilharz   Thu, 16 Mar 2023 08:59:04 +0100
+
 keyman (16.0.138-4) unstable; urgency=medium
 
   * Team upload
diff -Nru keyman-16.0.138/debian/control keyman-16.0.139/debian/control
--- keyman-16.0.138/debian/control  2023-02-09 12:17:16.0 +0100
+++ keyman-16.0.139/debian/control  2023-03-20 20:02:09.0 +0100
@@ -105,7 +105,7 @@
  information about Keyman keyboard packages.
 
 Package: libkmnkbp-dev
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
 Section: libdevel
 Depends:
  libkmnkbp0-0 (= ${binary:Version}),
@@ -129,7 +129,7 @@
  This package contains development headers and libraries.
 
 Package: libkmnkbp0-0
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
 Section: libs
 Pre-Depends:
  ${misc:Pre-Depends},
@@ -155,7 +155,7 @@
  and applies rules from compiled Keyman keyboard files.
 
 Package: ibus-keyman
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
 Depends:
  ibus (>= 1.3.7),
  sudo,
diff -Nru keyman-16.0.138/debian/ibus-keyman.postinst 
keyman-16.0.139/debian/ibus-keyman.postinst
--- keyman-16.0.138/debian/ibus-keyman.postinst 2023-02-09 12:17:16.0 
+0100
+++ keyman-16.0.139/debian/ibus-keyman.postinst 2023-03-16 08:57:27.0 
+0100
@@ -1,10 +1,13 @@
 #!/bin/sh
 
-set -e
+# Don't call `set -e`. Even if some commands should fail, it's still
+# worth running the rest of the commands.
 
 case "$1" in
 
   configure)
+# (Re-)Start IBus
+
 # if don't have sudo and ps then don't attempt to restart ibus
 if which sudo > /dev/null && which ps > /dev/null; then
 
@@ -37,20 +40,20 @@
   fi
 
   #

Bug#1033498: installation-reports: Missing FW files not detected on USB stick

2023-03-27 Thread Rainer Dorsch

Am Montag, 27. März 2023, 08:02:30 CEST schrieben Sie:
> How could the installer report any directories if it cannot mount the
> filesystem ?

If the list of inspected directories is empty (or any apparent USB connected 
device is not included if there are directories which are part of the 
installer already) this should give an indication that the problem is that the 
media cannot be read and not that the files on the media are not detected or 
matching.

You could try to go further: By doing a diff between the directories before and 
after the retry of the installer, you might be able to print out a message 
like "No new media detected in the system".

I think everything is better than the current behavior which is just telling: 
"something went wrong".

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1033566: module MPI3MR not enabled

2023-03-27 Thread Diederik de Haas

On Monday, 27 March 2023 15:59:37 CEST Marcel Camijn wrote:
> We recently got new hardware with a new raid controller but noticed that the
> required module MPI3MR is not enabled. The latest uploaded kernel image has
> "#CONFIG_SCSI_MPI3MR is not set" in the config.
> 
> The module seems to be included upstream since 5.14.
> 
> For current stable we can work around this, but for bookworm is would be
> nice to have it enabled.

I have created a branch to enable it and when Salsa's CI succeeds (enough) I 
can turn that into a MR.

While looking into it, I did find some troubling aspects though.
I noticed that in upstream's master branch there were quite some commits 
*after* 6.1 of which a reasonable amount has been backported to 6.1.
For example, in 6.1.21 there are FIVE commits which fix a memory leak.

Those got backported because the original commits contained 
"Fixes: "

There are however also some commits which do NOT have the "Fixes:" tag, like:
https://lore.kernel.org/all/20230228140835.4075-7-ranjan.ku...@broadcom.com/
titled: "mpi3mr: Bad drive in topology results kernel crash"

There are some more and for that compare upstream's master branch with 6.1 and 
look for the ones which do not have the "Fixes:" tag.
Unless explicit action is taken to request a backport, f.e. the above 
mentioned commit will not get backported to 6.1 ... which could lead to a 
kernel crash.

I will propose the MR, but I also think the Debian kernel maintainers should 
be aware of this which could result in the decision to NOT merge the MR.

Keeping an eye on and involving with upstream wrt those (potential) issues 
seems like a good strategy.

HTH,
  Diederik

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

Bug#1033534:

2023-03-27 Thread Timothy Pearson

Merge request to fix this bug here:

https://salsa.debian.org/mozilla-team/thunderbird/-/merge_requests/7

Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section

2023-03-27 Thread Emanuele Rocca

Package: systemd-boot-efi
Version: 252.6-1

Hi,

booting in Secure Boot mode with a self-signed systemd-bootaa64.efi
works well on arm64. However, trying to boot via shimaa64.efi fails with
the following error:

  shim.c:866:load_image() attempting to load \EFI\BOOT\grubaa64.efi
  pe.c:844:verify_sbat_section() No .sbat section data
  Verification failed: Security Policy Violation

Looking for the SBAT section in systemd-bootaa64.efi confirms that
indeed it is missing:

 objdump -x /usr/lib/systemd/boot/efi/systemd-bootaa64.efi | grep .sbat # <- no 
output

Instead, on amd64:

 $ objdump -x /usr/lib/systemd/boot/efi/systemd-bootx64.efi | grep .sbat
   7 .sbat 00d9  00028040  00028040  0001dc00 2**2
 [136](sec  8)(fl 0x00)(ty0)(scl   3) (nx 0) 0x sbat

Note that .sbat is not the only section missing. On arm64 there's only
.text and .data:

  Sections:
  Idx Name  Size  VMA   LMA   File off  Algn
0 .text 0001a000  1000  1000  1000  2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 2000  0001b000  0001b000  0001b000  2**2
CONTENTS, ALLOC, LOAD, DATA

While amd64 has:

  Sections:
  Idx Name  Size  VMA   LMA   File off  Algn
0 .text 00015710  5000  5000  0400  2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .reloc000c  0001b000  0001b000  00015c00  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 64b8  0001c000  0001c000  00015e00  2**4
CONTENTS, ALLOC, LOAD, DATA
3 .dynamic  0100  00023000  00023000  0001c400  2**2
CONTENTS, ALLOC, LOAD, DATA
4 .rela 1038  00024000  00024000  0001c600  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynsym   0018  00026000  00026000  0001d800  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .sdmagic  002b  00028000  00028000  0001da00  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .sbat 00d9  00028040  00028040  0001dc00  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .osrel003f  00028120  00028120  0001de00  2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA

Bug#774647: can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage

2023-03-27 Thread Christoph Anton Mitterer

Hey.

I rather think now that even my hack with the swapfile isn't really
save.
The idea with that was that it's just the file, but not activated as
swap of course. But who knows for sure that in this case the file is
never moved.


Anyway, @Guilhem, would you agree to close this as wontfix and add a
README.x entry that describes why - with hibernation/resume - the key
file cannot safely be loaded from a filesystem that is hibernated, too?

Not sure whether to better put it in README.initramfs (yes it happens
in that phase) or README.Debian (in principle a user could just hack
something together on his own with the same issue and not even install
cryptsetup-initramfs).


Cheers,
Chris.

Bug#1033568: unblock: gnome-calendar/43.1-2

2023-03-27 Thread Alberto Garcia

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

Please unblock package gnome-calendar

[ Reason ]
If the user tries to add a new calendar manually, the version of
gnome-calendar currently in testing crashes while the user is typing
the URI.

This happens while the URI is incomplete because it is not validated
before proceeding.

[ Impact ]
The application crashes suddenly and must be restarted with no clue
about why the crash happened.

[ Tests ]
Tested manually, the bug is very easy to reproduce, simply typing
'https://' on the URL entry is enough. The new package also provides a
test case.

[ Risks ]
Very low, this is the upstream patch for this bug and is very
straightforward.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock gnome-calendar/43.1-2
diff -Nru gnome-calendar-43.1/debian/changelog 
gnome-calendar-43.1/debian/changelog
--- gnome-calendar-43.1/debian/changelog2022-10-18 16:09:27.0 
+0200
+++ gnome-calendar-43.1/debian/changelog2023-03-20 18:25:22.0 
+0100
@@ -1,3 +1,14 @@
+gnome-calendar (43.1-2) unstable; urgency=high
+
+  [ Alberto Garcia ]
+  * debian/patches/validate-uri.patch:
+- Fix crash when adding an url manually (Closes: #1033239)
+
+  [ Jeremy Bicha ]
+  * Branch for bookworm
+
+ -- Alberto Garcia   Mon, 20 Mar 2023 18:25:22 +0100
+
 gnome-calendar (43.1-1) unstable; urgency=high
 
   * New upstream release (LP: #1993308)
diff -Nru gnome-calendar-43.1/debian/control gnome-calendar-43.1/debian/control
--- gnome-calendar-43.1/debian/control  2022-10-18 16:09:27.0 +0200
+++ gnome-calendar-43.1/debian/control  2023-03-20 18:25:22.0 +0100
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Iain Lane , Jeremy Bicha , 
Laurent Bigonville 
+Uploaders: Jeremy Bicha 
 Build-Depends: appstream-util,
debhelper-compat (= 13),
dh-sequence-gnome,
@@ -29,8 +29,8 @@
xvfb ,
 Standards-Version: 4.6.0
 Rules-Requires-Root: no
-Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git
+Vcs-Browser: 
https://salsa.debian.org/gnome-team/gnome-calendar/tree/debian/bookworm
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git -b 
debian/bookworm
 Homepage: https://wiki.gnome.org/Apps/Calendar
 
 Package: gnome-calendar
diff -Nru gnome-calendar-43.1/debian/control.in 
gnome-calendar-43.1/debian/control.in
--- gnome-calendar-43.1/debian/control.in   2022-10-18 16:09:27.0 
+0200
+++ gnome-calendar-43.1/debian/control.in   2023-03-20 18:25:22.0 
+0100
@@ -25,8 +25,8 @@
xvfb ,
 Standards-Version: 4.6.0
 Rules-Requires-Root: no
-Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git
+Vcs-Browser: 
https://salsa.debian.org/gnome-team/gnome-calendar/tree/debian/bookworm
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git -b 
debian/bookworm
 Homepage: https://wiki.gnome.org/Apps/Calendar
 
 Package: gnome-calendar
diff -Nru gnome-calendar-43.1/debian/gbp.conf 
gnome-calendar-43.1/debian/gbp.conf
--- gnome-calendar-43.1/debian/gbp.conf 2022-10-18 16:09:27.0 +0200
+++ gnome-calendar-43.1/debian/gbp.conf 2023-03-20 18:25:22.0 +0100
@@ -1,6 +1,6 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/bookworm
 upstream-branch = upstream/latest
 
 [buildpackage]
diff -Nru gnome-calendar-43.1/debian/patches/series 
gnome-calendar-43.1/debian/patches/series
--- gnome-calendar-43.1/debian/patches/series   2022-10-18 16:09:27.0 
+0200
+++ gnome-calendar-43.1/debian/patches/series   2023-03-20 18:25:22.0 
+0100
@@ -0,0 +1 @@
+validate-uri.patch
diff -Nru gnome-calendar-43.1/debian/patches/validate-uri.patch 
gnome-calendar-43.1/debian/patches/validate-uri.patch
--- gnome-calendar-43.1/debian/patches/validate-uri.patch   1970-01-01 
01:00:00.0 +0100
+++ gnome-calendar-43.1/debian/patches/validate-uri.patch   2023-03-20 
18:25:22.0 +0100
@@ -0,0 +1,121 @@
+From: Georges Basile Stavracas Neto 
+Subject: Test URI before discovery
+Bug: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/794
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033239
+Origin: 
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/0322bcf54cf1fc37ff74b87fd36e282dc1cf7863
+Index: gnome-calendar-43.1/src/utils/gcal-source-discoverer.c
+===
+--- gnome-calendar-43.1.orig/src/utils/gcal-source-discoverer.c
 gnome-calendar-43.1/src/utils/gcal-source-discoverer.c
+@@ -183,6 +183,26 @@ is_authentication_error (gint code)
+   return FALSE;
+ }
+

Bug#1033567: systemd: move /usr/bin/kernel-install to package systemd-boot

2023-03-27 Thread Emanuele Rocca

Package: systemd
Version: 252.6-1

Hi,

the systemd binary package currently ships the following files:

 /usr/bin/kernel-install
 /usr/share/bash-completion/completions/kernel-install
 /usr/share/man/man8/kernel-install.8.gz
 /usr/share/zsh/vendor-completions/_kernel-install

Given that AFAIU kernel-install is not particularly useful without
systemd-boot, please consider moving the files mentioned above to the
systemd-boot binary package.

Bug#1033561: Arch list for removal in bug title is the correct one


Hi,

the archictures to remove are armhf hppa m68k as the title suggests. Not the 
ones listed in the body.

Best,

Markus

Bug#1033439: pre-unblock: monitoring-plugins/2.3.3-5

2023-03-27 Thread Jan Wagner


Hi,

Am 27.03.23 um 08:28 schrieb Jan Wagner:

here are the upstream fixes, related upstream CI pipelines and issues:


while we are at fixing bugs.

I'd also like to include 
https://patch-diff.githubusercontent.com/raw/monitoring-plugins/monitoring-plugins/pull/1850.patch, 
which fixes 
https://github.com/monitoring-plugins/monitoring-plugins/issues/1849 
(check_snmp: unit removed from check result)
https://github.com/monitoring-plugins/monitoring-plugins/actions/runs/4531646296/jobs/7982048943?pr=1850 
has a successfull upstream CI test run.


Thanks Jan

Bug#1033566: module MPI3MR not enabled

2023-03-27 Thread Marcel Camijn

Package: linux-image-amd64
Version: 6.1.0-7

We recently got new hardware with a new raid controller but noticed that the 
required module MPI3MR is not enabled. The latest uploaded kernel image has 
"#CONFIG_SCSI_MPI3MR is not set" in the config.

The module seems to be included upstream since 5.14.

For current stable we can work around this, but for bookworm is would be nice 
to have it enabled.

Kind regards,

Marcel








T +31 10 453 6524
E mar...@transtrend.com




















Disclaimer

Bug#1033564: pip install changes should be documented

2023-03-27 Thread Antoine Beaupre

Package: release-notes
Severity: important

Starting in bookworm, the seemingly innocuous command:

pip3 install foo

... will not work anymore. It will fail with this rather distressing
error:

$ pip install rsendmail
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python 
installation or OS distribution provider. You can override this, at the risk of 
breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

... and while the error is somewhat self-documented, it would probably
help our users to flag this issue *before* they run the upgrade, and I
believe the release notes are a good place for this.

I am not sure *what* to say exactly. I think I'd give a heads up that
this is happening and show an example of `--break-system-packages` or
preferably how to do this in a virtual env.

It's basically a redux of the above error message, but that can't
assume (say) `/usr/share/doc/python3.11` is available because we
haven't done the upgrade yet.

Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars

2023-03-27 Thread Alberto Garcia

On Mon, Mar 27, 2023 at 08:02:39AM -0400, Jeremy Bícha wrote:
> > I confirm that this patch fixes the problem.
> 
> Thanks for preparing this patch. I'm uploading it to Unstable now.
> Could you handle the unblock request?

Yes, I can do it.

Berto

Bug#913431: Debian Installer Bullseye RC 2 release

2023-03-27 Thread Vincent Danjean

Hi Philip,

Le 27/03/2023 à 02:07, Philip Hands a écrit :

Hi Vincent,

I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.

So I've changed that code, and added a couple of other tweaks, as you
can see here:

https://salsa.debian.org/philh/partman-base/-/commits/bug/913431

Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.

There were a problem: "expr substr" requires the 'length' argument
(it is optional for the ${s:..} construct)
So, I restarted from my previous work (as said in the bug report just
before your message, I already saw that ${X:...} and ${X/...} do not
work), switch from "cut -c ..." to "expr substr ..." [with all arguments]
and applied some of your tweaks.
The resulting state can be seen here:
https://salsa.debian.org/vdanjean/partman-base/-/tree/bug/913431-tested

BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:

https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso

I made my tests as suggested by Emanuele Rocca, i.e. by overwriting
the modified file (base.sh) during the installation before running the
partition step.
I confirm I successfully created partition and LVM LV with power-of-two
units.

I noticed that "human2longint" is ready to handle numbers with spaces in it
(such as 30 000 kB), but "valid_human" does not accept them (no spaces but
before the unit). I not sure if this is intended or not.

Thanks you very much for your feedback
Vincent

HTH

Cheers, Phil.

Bug#1033563: RM: opm-models [armhf, hppa, m68k] -- ROM; FTBS & package useless on these archs

Package: opm-models
Severity: serious built successfully in the past)

Dear FTP team,

the package fails to build from source for the architectures armhf, hppa and
m68k since a few versions. For armhf this situation is new as opm-common now
fails to build reliably from source for this architecture.

The main reason for having opm-models is to be able to build opm-simulators. As
that is not built for these architectures, having those in Debian is of little
use even if they would build from source.

Note that the architecture list of the latest version is already adapted to
only build for the needed architectures (excluding those to be removed).

Best regards,

Markus Blatt

Bug#1033562: RM: opm-common [alpha armhf hppa x32] -- ROM; FTBS and/or ANAIS

Package: ftp.debian.org
Severity: normal

Dear FTP team,

the package fails to build from source for the architectures alpha, armhf, hppa
and x32 since a few versions. For armhf this situation is new as opm-common now
fails to build reliably from source for this architecture. For the others these
problems that appeared with more checks introduces with 2022.10

The main reason for having opm-common is to be able to build opm-simulators. As
that is not built for these architectures, having those in Debian is of little
use even if they would build from source.

Note that the architecture list of the latest version is already adapted to
only build successfully for the needed architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).

Best regards,

Markus Blatt

Bug#1033560: kup-backup: not translated while upstream translation exists

2023-03-27 Thread Yvan

Package: kup-backup
Version: 0.9.1-1+b3
Severity: normal
Tags: l10n
X-Debbugs-Cc: y...@masson-informatique.fr

Dear Maintainer,

Kup Backup is not translated on my system, while I have seen that it is 
translated upstream: is it something wrong on my system or is it a build issue?

Do not hesitate to ask if you need more information.

Regards,
Yvan

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

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

Versions of packages kup-backup depends on:
ii  kio5.103.0-1
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libgit2-1.51.5.1+ds-1
ii  libkf5completion5  5.103.0-1
ii  libkf5configcore5  5.103.0-1
ii  libkf5configwidgets5   5.103.0-1
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5dbusaddons5  5.103.0-1
ii  libkf5i18n55.103.0-1
ii  libkf5idletime55.103.0-2
ii  libkf5jobwidgets5  5.103.0-1
ii  libkf5kiocore5 5.103.0-1
ii  libkf5kiofilewidgets5  5.103.0-1
ii  libkf5kiowidgets5  5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5plasma5  5.103.0-1
ii  libkf5solid5   5.103.0-1
ii  libkf5widgetsaddons5   5.103.0-1
ii  libkf5xmlgui5  5.103.0-1
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5dbus55.15.8+dfsg-3
ii  libqt5gui5 5.15.8+dfsg-3
ii  libqt5network5 5.15.8+dfsg-3
ii  libqt5widgets5 5.15.8+dfsg-3
ii  libstdc++6 12.2.0-14

Versions of packages kup-backup recommends:
ii  bup0.33-2+b1
ii  rsync  3.2.7-1

kup-backup suggests no packages.

-- no debconf information

Bug#1033561: RM: opm-models [armhf hppa m68k] -- ROM; FTBS and/or ANAIS

Package: ftp.debian.org
Severity: normal

Dear FTP team,

the package fails to build from source for the architectures armhf, hppa and
appha since a few versions. For armhf this situation is new as opm-common now
fails to build reliably from source for this architecture.

The main reason for having opm-material is to be able to build opm-simulators.
As that is not built for these architectures, having those in Debian is of
little use even if they would build from source.

Note that the architecture list of the latest version is already adapted to
only build successfully for the needed architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).

Best regards,

Markus Blatt

Bug#1033559: RM: opm-material [alpha armhf hppa] -- ROM; FTBS and/or ANAIS

Package: ftp.debian.org
Severity: normal

Dear FTP team,

the package fails to build from source for the architectures armhf, hppa and
appha since a few versions. For armhf this situation is new as opm-common now
fails to build reliably from source for this architecture.

The main reason for having opm-material is to be able to build opm-simulators.
As that is not built for these architectures, having those in Debian is of
little use even if they would build from source.

Note that the architecture list of the latest version is already adapted to
only build successfully for the needed architectures (i.e. Architecture: amd64
arm64 armel ia64 m68k mips64el mipsel ppc64el riscv64).

Best regards,

Markus Blatt

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

2023-03-27 Thread James Addison

Package: rustc
Followup-For: Bug #973414

> Today I plan to rebuild rustc on Debian i386 with RUSTC_FLAGS (different to
> RUSTFLAGS) configured for i686 during the build.  That's inspired by a comment
> here: https://github.com/rust-lang/rust/pull/31110#issuecomment-174327810
> 
> To implement that, I've temporarily added RUSTC_FLAGS to the list of
> per-architecture buildflags accepted by dpkg-buildflags on my system.  I don't
> know whether that's the best place to put that configuration, but it would
> allow it to be configured on a per-architecture basis in Debian.

That didn't work; the resulting libraries continue to contain NOPL opcodes,
indicating that their C components were not compiled to the correct baseline.

The environment variable was definitely exported to the build process, so
it seems likely that I chose an incorrect environment variable name and/or
value.

Bug#960339: ITP: adios2 -- Adaptable IO system for simulations

2023-03-27 Thread Drew Parsons

Looks like adios2 has a formidable number of dependencies through 
libevpath.

We should push it through this year. Thanks for the preliminary work.

Drew

Bug#1033551: cryptsetup-bin: cryptsetup -v isLuks: doesn't work as documented

2023-03-27 Thread Guilhem Moulin

Control: tag -1 - moreinfo unreproducible
Control: tag -1 + upstream
Control: retitle -1 cryptsetup-bin: `cryptsetup -v isLuks` produces misleading 
output when the device isn't LUKS

On Mon, 27 Mar 2023 at 14:06:32 +0200, Alexis Huxley wrote:
> testaroli# cryptsetup isLuks /dev/loop0; echo "\`cryptsetup isLuks\` exited 
> with status $?"
> `cryptsetup isLuks` exited with status 1
> testaroli# cryptsetup isLuks -v /dev/loop0
> Command failed with code -1 (wrong or missing parameters).
> testaroli#
>
> It should say "not Luks" or perhaps "invalid device", but
> "wrong or missing parameters" is wrong.

Ah I see, it works as documented then.  The error message could arguably
be improved, but I guess the return status can't be changed anymore, and
show_status() maps it as follows:

if (errcode == 1)
crypt_error = _("wrong or missing parameters");
else if (errcode == 2)
crypt_error = _("no permission or bad passphrase");
else if (errcode == 3)
crypt_error = _("out of memory");
else if (errcode == 4)
crypt_error = _("wrong device or file specified");
else if (errcode == 5)
crypt_error = _("device already exists or device is busy");
else
crypt_error = _("unknown error");

FWIW error code 1 (wrong or missing parameters) is also returned when
trying to format/open a device using an unsupported cipher.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1032440: closed by Laura Arjona Reina (Bug#1032440 fixed in www.debian.org)

2023-03-27 Thread Holger Levsen

On Mon, Mar 27, 2023 at 12:09:07PM +, Debian Bug Tracking System wrote:
> Bug #1032440 in www.debian.org reported by you has been fixed in the Git 
> repository.
> You can see the commit message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/webmaster-team/webwml/-/commit/12361160cfce820d5cd0de4c1cfdb6feaa2bfb02
> 
> 
> Add logic to show developers reference manual in single page HTML (Closes: 
> #1032440)
> 

yay & thank you!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This is the year of gpg on the desktop! (Gunnar Wolf)


signature.asc
Description: PGP signature

Bug#1033551: cryptsetup-bin: cryptsetup -v isLuks: doesn't work as documented

2023-03-27 Thread Alexis Huxley

> All 3 work for me in a bookworm VM, please try with `--debug` (with and
> without `-v`).

and it works for me *if* - as you did - I format the device.
But if I *don't* format it then I still get the same result,
even with newer packages:

testaroli# dpkg -l | grep cryptsetup
ii  cryptsetup-bin  2:2.6.1-3  amd64  disk encryption support - command 
line tools
ii  libcryptsetup12:amd64   2:2.6.1-3  amd64  disk encryption support - shared 
library
testaroli# 
testaroli# dd if=/dev/zero bs=1M count=64 of=/tmp/disk.img
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 0.0806509 s, 832 MB/s
testaroli# cryptsetup isLuks /dev/loop0; echo "\`cryptsetup isLuks\` exited 
with status $?"
`cryptsetup isLuks` exited with status 1
testaroli# cryptsetup isLuks -v /dev/loop0
Command failed with code -1 (wrong or missing parameters).
testaroli# 

It should say "not Luks" or perhaps "invalid device", but 
"wrong or missing parameters" is wrong.

With --debug:

testaroli# cryptsetup isLuks --debug -v /dev/loop0
# cryptsetup 2.6.1 processing "cryptsetup isLuks --debug -v /dev/loop0"
# Verifying parameters for command isLuks.
# Running command isLuks.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/loop0.
# Trying to open and read device /dev/loop0 with direct-io.
# Trying to open device /dev/loop0 without direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/loop0.
# Crypto backend (OpenSSL 3.0.8 7 Feb 2023 [default][legacy]) initialized in 
cryptsetup library version 2.6.1.
# Detected kernel Linux 6.1.0-6-amd64 x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/loop0.
# Opening lock resource file /run/cryptsetup/L_7:0
# Verifying lock handle for /dev/loop0.
# Device /dev/loop0 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/loop0
# Verifying locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x8000.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x1.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x2.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x4.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x8.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x10.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x20.
# Reusing open ro fd on device /dev/loop0
# Trying to read secondary LUKS2 header at offset 0x40.
# Reusing open ro fd on device /dev/loop0
# LUKS2 header read failed (-5).
# Device /dev/loop0 READ lock released.
# Releasing crypt device /dev/loop0 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/loop0.
Command failed with code -1 (wrong or missing parameters).
testaroli# 

Alexis

Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars

2023-03-27 Thread Jeremy Bícha

On Mon, Mar 20, 2023 at 2:39 PM Alberto Garcia  wrote:
> Control: tags -1 patch
>
> I confirm that this patch fixes the problem.

Thanks for preparing this patch. I'm uploading it to Unstable now.
Could you handle the unblock request?

Thank you,
Jeremy Bícha

Bug#1033459: wxmaxima: INTERNAL-SIMPLE-TYPE-ERROR assoc_legendre_p(...) is not of type LIST

2023-03-27 Thread Gunter Königsmann


Thanks for your bug report.

In the git main branch of wxMaxima this just has been resolved via 
https://github.com/wxMaxima-developers/wxmaxima/commit/b98385cc0892548645c00648db7a1488806093a2.


Kind regards,

  Gunter.

Bug#1032834: freecad: Segmentation fault while redoing

2023-03-27 Thread Bernhard Übelacker


Why isn't there a symbol package, just for some ports?


Hello Patrick,
there are symbol packages for nearly all Debian packages nowadays.
You can add the debug component [1] to be able to install the dbgsym packages,
or if you like you can just use the DEBUGINFOD_URLS environment variable [2].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2] 
https://wiki.debian.org/HowToGetABacktrace#Automatically_loading_debugging_symbol_from_the_Internet

Bug#1033558: aptitude-common: aptitude-curses.8.gz man page: unclear/wrong text for Example 12

2023-03-27 Thread Vincent Lefevre

Package: aptitude-common
Version: 0.8.13-5
Severity: minor

When searching for "Example" in the aptitude-curses(8) man page,
I get:

Example 12. Usage of --show-summary --show-summary used with -v to
display all the reasons a package is installed:

There are several issues.

1. Why "12" while this is the only example in this man page?

2. There is a duplicate of "--show-summary".

3. The sentence is not well formed.

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, 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

aptitude-common depends on no packages.

Versions of packages aptitude-common recommends:
ii  aptitude  0.8.13-5

aptitude-common suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1033556: aptitude: "aptitude --show-summary=all-packages why ..." outputs the wrong package for Provides

2023-03-27 Thread Vincent Lefevre

Package: aptitude
Version: 0.8.13-5
Severity: normal

Consider for instance:

$ aptitude why mailutils
i   muttprint Recommends mutt | sylpheed | gnus | xfmail | exmh | mail-reader
i A mailutils Provides   mail-reader

Here, one can see that mailutils provides mail-reader.

$ aptitude --show-summary=all-packages why mailutils
Packages requiring mailutils:
  muttprint R: mail-reader P<- mail-reader

But here one has mail-reader on both sides of "P<-". I suppose that
this should have been

  muttprint R: mail-reader P<- mailutils

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff29f63000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f1a978c8000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f1a97205000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f1a9788e000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f1a9785c000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f1a97853000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f1a97113000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f1a96fb4000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7f1a97839000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f1a96c0)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f1a97834000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f1a9680)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f1a96ed5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f1a96eb5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a96a1f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1a9782d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1a96e96000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f1a9781a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f1a96e65000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f1a96e3f000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f1a96744000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7f1a96717000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f1a96648000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f1a96501000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f1a964ec000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a978f5000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7f1a96e33000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f1a964e)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f1a964b8000)

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, 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 aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.0
ii  libboost-iostreams1.74.0  1.74.0+ds1-20
ii  libc6 2.36-8
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-14
ii  libncursesw6  6.4-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.40.1-2
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.21
ii  sensible-utils  0.0.17+nmu1

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.13-5
pn  debtags 
ii  tasksel 3.72

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated

Bug#1033555: unblock: fraqtive/0.4.8.1-1

2023-03-27 Thread Patrick Matthäi

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

Please unblock package fraqtive

This is just a short maintainance release from upstream after many
years, mainly just merged already in Debian applied patches, so that
fraqtive still builds in modern environments.

As described in my mlt unblock request I thought it will migrate after
20 days and it looks cleaner for me to have the new upstream release, why
I had done this upload for targeting bookworm

[ Reason ]
New upstream release, which just covers already applied patches.

[ Impact ]
No impact here

[ Tests ]
Tested if it still starts, manual

[ Risks ]
I do not see any risk

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock fraqtive/0.4.8.1-1
diff -Nru fraqtive-0.4.8/configure fraqtive-0.4.8.1/configure
--- fraqtive-0.4.8/configure2008-03-21 11:49:25.78354 +0100
+++ fraqtive-0.4.8.1/configure  2023-03-06 09:30:22.0 +0100
@@ -81,7 +81,7 @@
   if test "$version" != "**Unknown**"; then
 major=`echo $version | sed -e "s/\([0-9][0-9]*\).*/\1/"`
 minor=`echo $version | sed -e "s/[0-9][0-9]*\.\([0-9][0-9]*\).*/\1/"`
-if test $major -eq 4 -a $minor -ge 3; then
+if test $major -eq 5; then
   QMAKE=$i
   break
 fi
@@ -89,7 +89,7 @@
 done
 
 if test -z "$QMAKE"; then
-echo "*** ERROR: Cannot find 'qmake' from Qt 4.3 or newer." >&2
+echo "*** ERROR: Cannot find 'qmake' from Qt 5." >&2
 exit 1
 fi
 
diff -Nru fraqtive-0.4.8/debian/changelog fraqtive-0.4.8.1/debian/changelog
--- fraqtive-0.4.8/debian/changelog 2023-01-12 11:07:55.0 +0100
+++ fraqtive-0.4.8.1/debian/changelog   2023-03-13 12:00:59.0 +0100
@@ -1,3 +1,11 @@
+fraqtive (0.4.8.1-1) unstable; urgency=medium
+
+  * New upstream release.
+- Remove merged patch 03-use-qt5.
+- Remove merged patch 04-fix-includes.
+
+ -- Patrick Matthäi   Mon, 13 Mar 2023 12:00:59 +0100
+
 fraqtive (0.4.8-17) unstable; urgency=medium
 
   * Adjust debian/watch to work again with GitHub.
diff -Nru fraqtive-0.4.8/debian/patches/03-use-qt5.diff 
fraqtive-0.4.8.1/debian/patches/03-use-qt5.diff
--- fraqtive-0.4.8/debian/patches/03-use-qt5.diff   2023-01-12 
11:07:55.0 +0100
+++ fraqtive-0.4.8.1/debian/patches/03-use-qt5.diff 1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-Description: Fix build system to use Qt5 instead of Qt4
-Author: Sune Vuorela 
-Forwarded: yes
-

-Origin: other
-Last-Update: 2018-08-15
-
 fraqtive-0.4.8.orig/configure
-+++ fraqtive-0.4.8/configure
-@@ -81,7 +81,7 @@ for i in $paths; do
-   if test "$version" != "**Unknown**"; then
- major=`echo $version | sed -e "s/\([0-9][0-9]*\).*/\1/"`
- minor=`echo $version | sed -e "s/[0-9][0-9]*\.\([0-9][0-9]*\).*/\1/"`
--if test $major -eq 4 -a $minor -ge 3; then
-+if test $major -eq 5 -a $minor -ge 3; then
-   QMAKE=$i
-   break
- fi
diff -Nru fraqtive-0.4.8/debian/patches/04-fix-includes.diff 
fraqtive-0.4.8.1/debian/patches/04-fix-includes.diff
--- fraqtive-0.4.8/debian/patches/04-fix-includes.diff  2023-01-12 
11:07:55.0 +0100
+++ fraqtive-0.4.8.1/debian/patches/04-fix-includes.diff1970-01-01 
01:00:00.0 +0100
@@ -1,30 +0,0 @@
-Description: Add missing includes
- Qt5 has had a bit of includes cleanups. Apply those.
-Author: Sune Vuorela 
-Forwarded: yes
-

-Origin: other
-Forwarded: no
-Last-Update: 2018-08-15
-
 fraqtive-0.4.8.orig/src/configurationdata.cpp
-+++ fraqtive-0.4.8/src/configurationdata.cpp
-@@ -27,6 +27,7 @@
- 
- #include 
- #include 
-+#include 
- 
- ConfigurationData::ConfigurationData()
- {
 fraqtive-0.4.8.orig/src/fractalgenerator.h
-+++ fraqtive-0.4.8/src/fractalgenerator.h
-@@ -22,6 +22,7 @@
- #include 
- #include 
- #include 
-+#include 
- 
- #include "abstractjobprovider.h"
- #include "datastructures.h"
diff -Nru fraqtive-0.4.8/debian/patches/series 
fraqtive-0.4.8.1/debian/patches/series
--- fraqtive-0.4.8/debian/patches/series2023-01-12 11:07:55.0 
+0100
+++ fraqtive-0.4.8.1/debian/patches/series  2023-03-13 12:00:59.0 
+0100
@@ -1,5 +1,3 @@
 01-desktop-keywords.diff
 02-spelling-error.diff
-03-use-qt5.diff
-04-fix-includes.diff
 05-fix-ftbfs.diff
diff -Nru fraqtive-0.4.8/.gitignore fraqtive-0.4.8.1/.gitignore
--- fraqtive-0.4.8/.gitignore   1970-01-01 01:00:00.0 +0100
+++ fraqtive-0.4.8.1/.gitignore 2023-03-06 09:30:22.0 +0100
@@ -0,0 +1,12 @@
+debug
+release
+src/fraqtive_pch.h.cpp
+src/fraqtive.vcxproj
+src/fraqtive.vcxproj.filters
+src/fraqtive.vcxproj.user
+tmp
+.qmake.stash
+config.pri
+configure-msvc.bat
+fraqtive.sln
+fraqtive.v12.suo
diff -Nru fraqtive-0.4.8/src/configurationdata.cpp 
fraqtive-0.4.8.1/src/configurationdata.cpp
--- fraqtive-0.4.8/src/configurationdata.cpp2015-01-24 15:43:13.643143000 
+0100
+++

Bug#1033554: unblock: mlt/7.14.0-1

2023-03-27 Thread Patrick Matthäi

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

Please unblock package mlt

First I am very sorry for this mess! I missunderstood the text in the time of
the soft freeze and thought key packages with autopkgtests only and that non
key-packages will still migrate after 20 days.. After I have done those uploads
I still wanted to see in bookworm it was already too late.. My fault and also a
good hint for me to indroduce autopkgtests in my packages

So the problem is now, mlt 7.14 about 7.12 has some fixed bugs and improvided
ffmpeg support for further releases. And now it is already in unstable.. Sorry..
I have done this update along with kdenlive (unblock for it follows), because 
it has a
bugfix release. Which is not complicated, but if you dont see a chance to let 
7.14 to
bookworm I had for example to do a upload of kdenlive directly to testing?

[ Reason ]
Several fixed bugs.

[ Impact ]
It is uploaded to unstable, could be problematic for the release
process (dependencies) if updates are required.

[ Tests ]
I have tested mlt on my system along with kdenlive.

[ Risks ]
It is a new upstream release, which also introduces new features, compability
with ffmpeg 6.0 (which would be nice for later backports in bookworm), risk that
something new could break something else. But it looks good from my view

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [y] I reviewed all changes and I approve them (as possible for myself with 
the upstream code)
  [x] attach debdiff against the package in testing

unblock mlt/7.14.0-1


mlt.debdiff.gz
Description: application/gzip

Bug#1033219: unblock: ghostscript/10.0.0~dfsg-10

2023-03-27 Thread Graham Inggs

Control: tags -1 + confirmed

Hi Håvard

On Sun, 26 Mar 2023 at 22:18, Håvard F. Aasen  wrote:
> The fix is for making the package cross-buildable, not sure what more
> to tell you.

I was hoping for some motivation as to why we needed this fix now
during the freeze, but not to worry, Helmut has already convinced me.

I have confirmed that building ghostscript with and without your patch
produces identical binary packages.

Regards
Graham

Bug#1033553: libprelude failing to build from source on bookworm with python 3.11

2023-03-27 Thread Mayer, Dirk

Source: libprelude

Version: 5.2.0-5

Tags: bookworm ftbfs

Severity: serious


When I build this package from source, the build fails. Please see log output 
at the end.

My build environment is a container image based on Debian testing bookworm, 
which already includes python3.11



After some research I guess it may be related to the upgrade to pyhton3.11 and 
the new behavior which enforces pip install packages only in venv.

There is also a separation of user und system packages which may be the problem 
in an isolated buildroot.

There maybe a new PEP668 involved: https://peps.python.org/pep-0668/ 
https://peps.python.org/pep-0668/#keep-the-marker-file-in-container-images

https://discuss.python.org/t/python3-m-pip-install-user-broken-in-debian-testing/24268

And a long discussion about distros:

https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/10302/72







apt-get source --only-source libprelude=5.2.0-5

Reading package lists...

NOTICE: 'libprelude' packaging is maintained in the 'Git' version control 
system at:

https://salsa.debian.org/totol-guest/libprelude.git

Please use:

git clone https://salsa.debian.org/totol-guest/libprelude.git

to retrieve the latest (possibly unreleased) updates to the package.

Need to get 2,934 kB of source archives.

Get:1 https://snapshot.debian.org/archive/debian/20230325T212848Z bookworm/main 
libprelude 5.2.0-5 (dsc) [3,121 B]

Get:2 https://snapshot.debian.org/archive/debian/20230325T212848Z bookworm/main 
libprelude 5.2.0-5 (tar) [2,902 kB]

Get:3 https://snapshot.debian.org/archive/debian/20230325T212848Z bookworm/main 
libprelude 5.2.0-5 (asc) [163 B]

Get:4 https://snapshot.debian.org/archive/debian/20230325T212848Z bookworm/main 
libprelude 5.2.0-5 (diff) [28.6 kB]

dpkg-source: info: extracting libprelude in libprelude-5.2.0

dpkg-source: info: unpacking libprelude_5.2.0.orig.tar.gz

dpkg-source: info: unpacking libprelude_5.2.0-5.debian.tar.xz

dpkg-source: info: using patch list from debian/patches/series

dpkg-source: info: applying 001-ruby-m4.patch

dpkg-source: info: applying 004-fix_prelude_tests_timer.patch

dpkg-source: info: applying 005-fix_pthread_atfork.patch

dpkg-source: info: applying 006-fix_timegm.patch

dpkg-source: info: applying 007-fix_libprelude-error_hurd.patch

dpkg-source: info: applying 008-disable_test-poll_on_kfreebsd.patch

dpkg-source: info: applying 013-fix-test_rwlock1.patch

dpkg-source: info: applying 018-fix_gtkdoc_1.32.patch

dpkg-source: info: applying 020-ruby27.patch

dpkg-source: info: applying 021-Update_libprelude.m4.patch

dpkg-source: info: applying 022-Fix_libprelude_pkg-config-file.patch

dpkg-source: info: applying 023-Disable_GnuLib_Tests_perror2_strerror.patch

dpkg-source: info: applying 024-Fix_Config_H.patch

dpkg-source: info: applying 025-Fix-PyIOBase_Type.patch

Fetched 2,934 kB in 1min 24s (35.0 kB/s)

++ find . -maxdepth 1 -type d

++ tail -n1

+ UNPACKED_FOLDER=./libprelude-5.2.0

+ pushd ./libprelude-5.2.0

/work/tmp/libprelude_5.2.0-5/libprelude-5.2.0 /work/tmp/libprelude_5.2.0-5 ~

+ [[ -d /git/customization/bookworm/libprelude ]]

+ popd

+ tar cJf /work/libprelude_5.2.0-5.combined.tar.xz ./libprelude-5.2.0

/work/tmp/libprelude_5.2.0-5 ~

/work/tmp/libprelude_5.2.0-5/libprelude-5.2.0 /work/tmp/libprelude_5.2.0-5 ~

--- BUILDING libprelude 5.2.0-5+ pushd ./libprelude-5.2.0

+ echo -n '--- BUILDING libprelude 5.2.0-5'

+ sudo -E apt-get build-dep --only-source -y libprelude=5.2.0-5

Reading package lists...

Building dependency tree...

Reading state information...

The following NEW packages will be installed:

  dh-python docbook docbook-to-man docbook-xml docbook-xsl gawk gem2deb

  gem2deb-test-runner gtk-doc-tools libblkid-dev libevent-2.1-7 libffi-dev

  libgcrypt20-dev libglib2.0-dev libglib2.0-dev-bin libgmp-dev libgmpxx4ldbl

  libgnutls-dane0 libgnutls-openssl27 libgnutls28-dev libgnutlsxx30

  libgpg-error-dev libidn2-dev libltdl-dev libltdl7 liblua5.1-0

  liblua5.1-0-dev libmount-dev libncurses-dev libncurses6 libosp5

  libp11-kit-dev libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix3

  libperl-dev libpkgconf3 libpython3-all-dev libreadline-dev libruby

  libruby3.1 libselinux1-dev libsepol-dev libsigsegv2 libtasn1-6-dev

  libunbound8 libxslt1.1 lua5.1 nettle-dev opensp pkg-config pkgconf

  pkgconf-bin python3-all python3-all-dev python3-lxml python3-pygments rake

  ruby ruby-all-dev ruby-net-telnet ruby-rubygems ruby-sdbm ruby-webrick

  ruby-xmlrpc ruby3.1 ruby3.1-dev rubygems-integration sgml-data swig swig4.0

  uuid-dev xsltproc

…

…

..

…

..



Making install in tests

make[4]: Entering directory 
'/work/tmp/libprelude_5.2.0-5/libprelude-5.2.0/tests'

make[5]: Entering directory 
'/work/tmp/libprelude_5.2.0-5/libprelude-5.2.0/tests'

make[5]: Nothing to be done for 'install-exec-am'.

make[5]: Nothing to be done for 'install-data-am'.

make[5]: Leaving directory '/work/tmp/libprelude_5.2.0-5/libprelude-5.2.0/tests'

Bug#1033551: cryptsetup-bin: cryptsetup -v isLuks: doesn't work as documented

2023-03-27 Thread Guilhem Moulin

Control: tag -1 unreproducible moreinfo

Hi,

On Mon, 27 Mar 2023 at 12:35:39 +0200, Alexis Huxley wrote:
>   testaroli# cryptsetup isLuks -v /dev/zvol/zpool0/test 
>   Command failed with code -1 (wrong or missing parameters).
>   testaroli# cryptsetup -v isLuks /dev/zvol/zpool0/test 
>   Command failed with code -1 (wrong or missing parameters).
>   testaroli# cryptsetup isLuks /dev/zvol/zpool0/test -v
>   Command failed with code -1 (wrong or missing parameters).
>   testaroli#
>
> All fail.

All 3 work for me in a bookworm VM, please try with `--debug` (with and
without `-v`).

~# dpkg -l | grep cryptsetup
ii  cryptsetup-bin   2:2.6.1-3~deb12u1  amd64disk 
encryption support - command line tools
ii  libcryptsetup12:amd642:2.6.1-3~deb12u1  amd64disk 
encryption support - shared library
~# dd if=/dev/zero bs=1M count=64 of=/tmp/disk.img
~# losetup -f /tmp/disk.img
~# cryptsetup luksFormat -q /dev/loop0 <<

signature.asc
Description: PGP signature

Bug#1033552: Valid transaction: Error: Divide by zero

2023-03-27 Thread Martin Michlmayr

Package: ledger
Version: 3.2.1-7
Severity: important

This valid transaction leads to an error:

2012-07-01 * Test
   A  (1/9 FOO) @ 200.00 EUR
   B  -22.22 EUR

While parsing file "/home/tbm/tmp/src/ledger/d", line 3:
Error: Divide by zero

This was reported more than 10 years ago:
https://github.com/ledger/ledger/issues/777
and more recently:
https://github.com/ledger/ledger/issues/2207

This issue was recently fixed by this comment:
https://github.com/ledger/ledger/commit/49cf3323ae2079b7ce1be101dc43780ce8e4296e

If you want, you could apply this fix to 3.3.0... but it's been there
for a long time so maybe it doesn't affect that many people.  You can
close this bug report if you prefer.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1033551: cryptsetup-bin: cryptsetup -v isLuks: doesn't work as documented

2023-03-27 Thread Alexis Huxley

Package: cryptsetup-bin
Version: 2:2.6.1-1
Severity: minor
X-Debbugs-Cc: alexishux...@gmail.com

Dear Maintainer,

Allocate a volume (in my case my only Debian 12 system uses
ZFS, but the result is the same with Debian 11 on LVM):

testaroli# zfs create -V 100m zpool0/test
testaroli# 

Check if it is Luks device, which of course it is not
as it's only just been created:

testaroli# cryptsetup isLuks /dev/zvol/zpool0/test 
testaroli# echo $?
1
testaroli# 

The cryptsetup-isLuks man page says regarding isLuks that 
the synopsis is:

cryptsetup isLuks [] 

and states:

Use option -v to get human-readable feedback.

So here's are three calls with the '-v' first in the documented
position relative to other args and then in every other conceivable 
place:

testaroli# cryptsetup isLuks -v /dev/zvol/zpool0/test 
Command failed with code -1 (wrong or missing parameters).
testaroli# cryptsetup -v isLuks /dev/zvol/zpool0/test 
Command failed with code -1 (wrong or missing parameters).
testaroli# cryptsetup isLuks /dev/zvol/zpool0/test -v
Command failed with code -1 (wrong or missing parameters).
testaroli#

All fail.

I'm happy to test new versions, etc.

Alexis

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-6-amd64 root=ZFS=zpool0/root ro console=tty1 
console=ttyS0,115200 ipv6.disable=1

-- /etc/fstab
UUID=0b968fd6-951e-43b3-a0af-7b5e37f25d90  /boot
ext4   defaults,noatime,nodiratime  0 2
ZFS=zpool0/root/
ext4   errors=remount-ro,noatime,nodiratime 0 1
tmpfs  /tmp 
tmpfs  nodev,nosuid 0 0
/dev/vda3  swap 
swap   defaults 0 0
zpool0/local   /vol/local   zfs 
   auto,noatime,nodiratime  0 2
/dev/vda1  /boot/efi
vfat   umask=0077   0 1

-- lsmod
Module  Size  Used by
tls   126976  0
nft_masq   16384  0
nft_chain_nat  16384  0
nf_nat 57344  2 nft_masq,nft_chain_nat
nf_conntrack  188416  2 nf_nat,nft_masq
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
nf_tables 286720  2 nft_masq,nft_chain_nat
libcrc32c  16384  3 nf_conntrack,nf_nat,nf_tables
nfnetlink  20480  1 nf_tables
rfkill 36864  1
qrtr   49152  4
bridge311296  0
stp16384  1 bridge
llc16384  2 bridge,stp
binfmt_misc24576  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   24576  1
fat90112  1 vfat
ext4  983040  1
kvm_amd   155648  0
ccp   118784  1 kvm_amd
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2  167936  1 ext4
kvm  1138688  1 kvm_amd
crc32c_generic 16384  0
irqbypass  16384  1 kvm
ghash_clmulni_intel16384  0
sha512_ssse3   49152  0
sha512_generic 16384  1 sha512_ssse3
iTCO_wdt   16384  1
virtio_gpu 77824  0
intel_pmc_bxt  16384  1 iTCO_wdt
virtio_dma_buf 16384  1 virtio_gpu
iTCO_vendor_support16384  1 iTCO_wdt
drm_shmem_helper   20480  1 virtio_gpu
watchdog   45056  1 iTCO_wdt
aesni_intel   393216  0
virtio_rng 16384  0
rng_core   20480  2 virtio_rng,ccp
virtio_balloon 24576  0
drm_kms_helper204800  3 virtio_gpu
sg 40960  0
virtio_console 40960  0
button 24576  0
crypto_simd16384  1 aesni_intel
evdev  28672  2
cryptd 28672  2 crypto_simd,ghash_clmulni_intel
serio_raw  20480  0
pcspkr 16384  0
drm   614400  4 drm_kms_helper,drm_shmem_helper,virtio_gpu
dm_mod184320  0
fuse  176128  1
loop   32768  0
efi_pstore 16384  0
configfs   57344  1
efivarfs   24576  1
qemu_fw_cfg20480  0
ip_tables  36864  0
x_tables   61440  1 ip_tables
autofs453248  2
zfs  4005888  8
zunicode  335872  1 zfs
zzstd 589824  1 zfs
zlua  192512  1 zfs
zavl   20480  1 zfs
icp   327680  1 zfs
zcommon   110592  2 zfs,icp
znvpair   118784  2 zfs,zcommon
spl

Bug#1027439: elementpath breaks python-xmlschema autopkgtest: 'XMLSchemaContext' object has no attribute 'iter'

2023-03-27 Thread Emmanuel Arias

Hello, 

Applying the patch all the tests are fixed except one:

==
FAIL: test_xml_document_validation 
(xmlschema.testing._builders.TestValidator004.test_xml_document_validation)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
 line 623, in test_xml_document_validation
self.check_data_conversion_with_lxml()
  File 
"/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py",
 line 507, in check_data_conversion_with_lxml
self.assertEqual(len(lxml_errors), len(self.errors), msg=xml_file)
AssertionError: 2 != 1 : tests/test_cases/examples/collection/collection3bis.xml

-

I will investigate a little bit today.

Cheers,
eamanu


signature.asc
Description: PGP signature

Bug#1021292: dpkg-buildflags: Please add support for pointer authentication on arm64

2023-03-27 Thread James Addison

Package: dpkg-dev
Followup-For: Bug #1021292
X-Debbugs-Cc: woo...@wookware.org, debian-de...@lists.debian.org

> We decided that the best thing to do was create a new hardening flags
> feature called 'branch' to add to the existing set. This enables
> -mbranch-protection=standard on arm64, and
> -fcf-protection on amd64

After reading various threads (such as this[1] Xen thread, and from there a
related[2] Linux kernel thread) about fcf-protection:

Could we consider ensuring NOTRACK_EN=0 and -fno-jump-tables if-and-when making
this change?

(I'm not sure yet, but the CET 'notrack' instruction seems unusual to me, and
although I hope to find out and become convinced that it's safe and worthwhile,
it seems like a potential loophole in the safety that CET could offer.  my
understanding is that it's intended to allow certain limited callsites to
invoke functions that do not begin with branch-target (endbr64) instructions)

[1] - https://lists.xenproject.org/archives/html/xen-devel/2022-03/msg00522.html

[2] - https://lkml.org/lkml/2022/3/7/1068

Bug#1031716: Generating stricter dependencies on python3-protobuf rdeps

2023-03-27 Thread Pirate Praveen

On Tue, 7 Mar 2023 12:09:35 +0200 Adrian Bunk  wrote:
> 2. packages using python3-protobuf (e.g. python3-bernhard) ship files
>that were generated with protobuf-compiler during their build
>(e.g. /usr/lib/python3/dist-packages/bernhard/pb.py )

Can this generation be moved to postinst and use a dpkg trigger to 
regenerate it when protobuf is updated?

An example is 
https://sources.debian.org/src/node-constants-browserify/1.0.0%2Bdfsg-8/debian/postinst/

Though it would mean runtime dependency on protobuf-compiler.

Bug#1033489: sudo lecture is missing

On Mon, Mar 27, 2023 at 08:59:25AM +1000, Thom wrote:
> But I can't find a reason to drop lecture after so many years.

Indeed, upstream didn't comment about that. Please talk to upstream
regarding this, I am not sure whether it is a wise idea to deviat from
upstream here.

This is not going to make it into bookworm anyway.

Greetings
Marc

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

Bug#1033550: dailyaidecheck doesn't run in DST transition night

Package: aide-common
Version: 0.18.1-2
Severity: important

Hi,

the dailyaidecheck.timer is set to run at 02:00. That time doesn't exist
in EU daylight saving time transition nights, causing the aide check to
not run in those nights.

A workaround, which will be implemented in the next versions of the
package, will be to run the check at 01:50 instead, hoping that all
daylight saving time countries are doing their transitions at 02:00.
Should this stay unfixed in bookworm, editing
/lib/systemd/system/dailyaidecheck.timer is a valid fix.

Greetings
Marc


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

Kernel: Linux 6.2.8-zgsrv20080 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aide-common depends on:
ii  aide   0.18.1-2
ii  debconf [debconf-2.0]  1.5.82
ii  liblockfile1   1.17-1+b1
ii  ucf3.0043+nmu1

Versions of packages aide-common recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
pn  cron   
ii  s-nail 14.9.24-2

aide-common suggests no packages.

-- debconf information excluded

Bug#1033549: mirror submission for mirror.gsl.icu

2023-03-27 Thread Daniel

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.gsl.icu
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
s390x
Archive-http: /debian/
Maintainer: Daniel 
Country: AU Australia
Location: Sydney
Sponsor: GSL Networks https://globalsecurelayer.com




Trace Url: http://mirror.gsl.icu/debian/project/trace/
Trace Url: http://mirror.gsl.icu/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.gsl.icu/debian/project/trace/mirror.gsl.icu

Bug#1033548: 02:00 timers dont run in DST transition night

Package: systemd
Version: 252.6-1
Severity: minor

Hi,

aide-common ships the following timer:

[Unit]
Description=Daily AIDE check

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=2h
Persistent=true

[Install]
WantedBy=timers.target

This didn't run in DST transition night. I think this might be caused by
the clock jumping from 01:59 to 03:00, with 02:00 not existing.

Is there a notation to have a systemd timer run even if the exact time
the timer is supposed to run doesn't happen? I guess this might also be
the case in case of a grossly misticking clock and a timesync daemon
stepping the time, for example, from 01:59:50 to 02:02:00?

Or would be probably be a better idea to trigger a timer if systemd
finds the trigger time in the past without the timer having been
triggered?

Not running at all came as kind of surprise for me.

I might be holding things wrong but I'd like your opinion.

Greetings
Marc


-- Package-specific info:

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

Kernel: Linux 6.2.8-zgsrv20080 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-8
ii  libcap21:2.66-3
ii  libcryptsetup122:2.6.1-3
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b5
ii  libssl33.0.8-1
ii  libsystemd-shared  252.6-1
ii  libsystemd0252.6-1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  ntpsec [time-daemon]1.2.2+dfsg1-1

Versions of packages systemd suggests:
ii  libfido2-1 1.12.0-2+b1
pn  libqrencode4   
pn  libtss2-esys-3.0.2-0   
pn  libtss2-mu0
pn  libtss2-rc0
pn  polkitd | policykit-1  
pn  systemd-boot   
pn  systemd-container  
pn  systemd-homed  
ii  systemd-resolved   252.6-1
pn  systemd-userdbd

Versions of packages systemd is related to:
pn  dbus-user-session  
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 252.6-1
ii  udev   252.6-1

-- no debconf information

Bug#1028149: bookworm: ntp has been replaced by ntpsec

2023-03-27 Thread Miroslav Lichvar

On Thu, 23 Mar 2023 12:12:04 + Richard Lewis 
 wrote:
> Presumably the release notes should also say that most people should
> consider systemd-timesyncd as this is priority:standard (since at
> least buster, but i dont remember seeing this in release notes then)?
> - i assume the idea is that if you dont have any special needs beyond
> "set the clock" should use systemd-timesyncd, And people who need
> extra features (like running their own ntp server) should install
> ntpsec / chrony / opennntpd ?

Recommending timesyncd as an NTP client to replace ntpd would not be a
good idea, especially if you consider the default configuration using
servers from pool.ntp.org.

The pool is very robust as a whole, but individual servers cannot be
relied on. They are run by volunteers. Some are well maintained, some
are not. Occasionally, servers drift away or step to a distant past or
future, e.g. due to GPS firmware bugs. The pool monitoring system
detects such servers and quickly removes them from the pool DNS, but
simple clients like timesyncd cannot recover from that. Once they got
the address from DNS, they will follow the server for as long as it
claims to be synchronized, no matter how wrong it is. A full-featured
NTP client is needed to detect and replace falsetickers. With
timesyncd the only option is to restart the service when you notice
the clock is wrong. I've seen many times users complaining about that
and getting this advice over the years.

timesyncd needs to be configured with a reliable server to work well.
Canonical maintains their own NTP servers and uses them by default in
Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
recommend a proper NTP client for a reliable service.

Bug#1033537: aide-common: More configurable MTA command when run as non-root