Bug#1024744: grpc: fail to build on riscv64

[Gianfranco Costamagna]

Source: grpc
Version: 1.30.2-4

Hello, looks like grpc is failing due to tests underlinked (missing atomic 
flag).

Would it be possible to have a look and add the link to them, or ignore on 
riscv64?
I'm currently trying to bootstrap llvm-toolchain-15 on that architecture and 
I'm failing due to missing
grpc rebuild.

thanks

Gianfranco

dh_auto_build -O--buildsystem=ruby
dh_ruby --build
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11_grpcio/build; 
python3.11 -m unittest discover -v
grpc (unittest.loader._FailedTest.grpc) ... ERROR

==
ERROR: grpc (unittest.loader._FailedTest.grpc)
--
ImportError: Failed to import test module: grpc
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path
package = self._get_module_from_name(name)
  
  File "/usr/lib/python3.11/unittest/loader.py", line 350, in 
_get_module_from_name
__import__(name)
  File "/<>/.pybuild/cpython3_3.11_grpcio/build/grpc/__init__.py", line 
23, in 
from grpc._cython import cygrpc as _cygrpc
ImportError: 
/<>/.pybuild/cpython3_3.11_grpcio/build/grpc/_cython/cygrpc.cpython-311-riscv64-linux-gnu.so:
 undefined symbol: __atomic_compare_exchange_1


--
Ran 1 test in 0.011s

FAILED (errors=1)
E: pybuild pybuild:379: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11_grpcio/build; python3.11 -m unittest 
discover -v
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.10_grpcio/build; 
python3.10 -m unittest discover -v
grpc (unittest.loader._FailedTest) ... ERROR

==
ERROR: grpc (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: grpc
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File "/<>/.pybuild/cpython3_3.10_grpcio/build/grpc/__init__.py", line 
23, in 
from grpc._cython import cygrpc as _cygrpc
ImportError: 
/<>/.pybuild/cpython3_3.10_grpcio/build/grpc/_cython/cygrpc.cpython-310-riscv64-linux-gnu.so:
 undefined symbol: __atomic_compare_exchange_1


--
Ran 1 test in 0.011s

FAILED (errors=1)
E: pybuild pybuild:379: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.10_grpcio/build; python3.10 -m unittest 
discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.11 3.10" returned 
exit code 13
make[1]: *** [debian/rules:68: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:92: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024417: [pkg-gnupg-maint] Bug#1024417: kgpg FTBFS: Did not find GPGME

[Sune Stolborg Vuorela]

On Wed, 23 Nov 2022 15:42:31 -0500 Daniel Kahn Gillmor 
 wrote:

> On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote:
> > Unless kgpg maintainers/upstream has a strong opinion against using
> > pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake
> > and simply use FindPkgConfig. - Attached patch seems to work for me,
> > i.e. build including dh_auto_test works.
>
> Thanks for this, Andreas.
>
> I've proposed this change upstream as well at
> https://invent.kde.org/utilities/kgpg/-/merge_requests/18


I think that this is a great debian stop gap measure, but due to 
upstream also supporting windows, the Good Fix[tm] should go into 
FindGpgme.cmake instead,


but could be derived from pkgconfig there.


/Sune

Bug#1024744: grpc: fail to build on riscv64

[Gianfranco Costamagna]

Hello again

ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc))
  export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed
endif

I didn't check but maybe adding some port architectures to this list is 
sufficient to fix this issue.

G.

On Thu, 24 Nov 2022 09:08:47 +0100 Gianfranco Costamagna 
 wrote:

Source: grpc
Version: 1.30.2-4

Hello, looks like grpc is failing due to tests underlinked (missing atomic 
flag).

Would it be possible to have a look and add the link to them, or ignore on 
riscv64?
I'm currently trying to bootstrap llvm-toolchain-15 on that architecture and 
I'm failing due to missing
grpc rebuild.

thanks

Gianfranco

dh_auto_build -O--buildsystem=ruby
dh_ruby --build
make[1]: Leaving directory '/<>'
debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11_grpcio/build; 
python3.11 -m unittest discover -v
grpc (unittest.loader._FailedTest.grpc) ... ERROR

==
ERROR: grpc (unittest.loader._FailedTest.grpc)
--
ImportError: Failed to import test module: grpc
Traceback (most recent call last):
   File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path
 package = self._get_module_from_name(name)
   
   File "/usr/lib/python3.11/unittest/loader.py", line 350, in 
_get_module_from_name
 __import__(name)
   File "/<>/.pybuild/cpython3_3.11_grpcio/build/grpc/__init__.py", line 
23, in 
 from grpc._cython import cygrpc as _cygrpc
ImportError: 
/<>/.pybuild/cpython3_3.11_grpcio/build/grpc/_cython/cygrpc.cpython-311-riscv64-linux-gnu.so:
 undefined symbol: __atomic_compare_exchange_1


--
Ran 1 test in 0.011s

FAILED (errors=1)
E: pybuild pybuild:379: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11_grpcio/build; python3.11 -m unittest 
discover -v
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.10_grpcio/build; 
python3.10 -m unittest discover -v
grpc (unittest.loader._FailedTest) ... ERROR

==
ERROR: grpc (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: grpc
Traceback (most recent call last):
   File "/usr/lib/python3.10/unittest/loader.py", line 470, in _find_test_path
 package = self._get_module_from_name(name)
   File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
_get_module_from_name
 __import__(name)
   File "/<>/.pybuild/cpython3_3.10_grpcio/build/grpc/__init__.py", line 
23, in 
 from grpc._cython import cygrpc as _cygrpc
ImportError: 
/<>/.pybuild/cpython3_3.10_grpcio/build/grpc/_cython/cygrpc.cpython-310-riscv64-linux-gnu.so:
 undefined symbol: __atomic_compare_exchange_1


--


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1

[Adrian Bunk]

On Wed, Nov 23, 2022 at 09:00:41PM -0500, Scott Talbert wrote:
> On Sat, 19 Nov 2022, Adrian Bunk wrote:
> 
> > Control: tags 1023149 + patch
> > Control: tags 1023149 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded
> > it to DELAYED/15. Please feel free to tell me if I should cancel it.
> 
> Can this NMU be accepted ASAP?
> 
> Assuming I'm reading excuses correctly, I believe this is preventing a
> massive number of haskell packages from migrating to testing.

I assume this is approval from a member of the maintainer team,
and have rescheduled pandoc for immediate upload.

> Thanks,
> Scott

cu
Adrian

Bug#1024745: bullseye-pu: package node-xmldom/0.5.0-1+deb11u2

[Yadd]

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

[ Reason ]
node-xmldom is vulnerable: it doesn't verify that root element is uniq
(#1024736, CVE-2022-39353)

[ Impact ]
Medium vulnerability

[ Tests ]
Test still pass

[ Risks ]
Moderate risk: test still pass and patch isn't too big

[ 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 ]
Verify XML document before change it

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e486812..50d0288 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-xmldom (0.5.0-1+deb11u2) bullseye; urgency=medium
+
+  * Team upload
+  * Prevent inserting DOM nodes when they are not well-formed
+(Closes: #1024736, CVE-2022-39353)
+
+ -- Yadd   Thu, 24 Nov 2022 09:22:10 +0100
+
 node-xmldom (0.5.0-1+deb11u1) bullseye; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-39353.patch 
b/debian/patches/CVE-2022-39353.patch
new file mode 100644
index 000..b15040a
--- /dev/null
+++ b/debian/patches/CVE-2022-39353.patch
@@ -0,0 +1,270 @@
+Description: Prevent inserting DOM nodes when they are not well-formed
+Author: Christian Bewernitz 
+Origin: upstream, https://github.com/xmldom/xmldom/commit/7ff7c10a
+Bug: https://github.com/xmldom/xmldom/security/advisories/GHSA-crh6-fp67-6883
+Bug-Debian: https://bugs.debian.org/1024736
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-11-24
+
+--- a/lib/dom.js
 b/lib/dom.js
+@@ -111,7 +111,31 @@
+   serializeToString(this[i],buf,isHTML,nodeFilter);
+   }
+   return buf.join('');
+-  }
++  },
++  /**
++   * @private
++   * @param {function (Node):boolean} predicate
++   * @returns {Node | undefined}
++   */
++  find: function (predicate) {
++  return Array.prototype.find.call(this, predicate);
++  },
++  /**
++   * @private
++   * @param {function (Node):boolean} predicate
++   * @returns {Node[]}
++   */
++  filter: function (predicate) {
++  return Array.prototype.filter.call(this, predicate);
++  },
++  /**
++   * @private
++   * @param {Node} item
++   * @returns {number}
++   */
++  indexOf: function (item) {
++  return Array.prototype.indexOf.call(this, item);
++  },
+ };
+ function LiveNodeList(node,refresh){
+   this._node = node;
+@@ -182,7 +206,7 @@
+   }
+   }
+   }else{
+-  throw DOMException(NOT_FOUND_ERR,new Error(el.tagName+'@'+attr))
++  throw new DOMException(NOT_FOUND_ERR,new 
Error(el.tagName+'@'+attr))
+   }
+ }
+ NamedNodeMap.prototype = {
+@@ -496,48 +520,177 @@
+   _onUpdateChild(parentNode.ownerDocument,parentNode);
+   return child;
+ }
++
+ /**
+- * preformance key(refChild == null)
++ * Returns `true` if `node` can be a parent for insertion.
++ * @param {Node} node
++ * @returns {boolean}
+  */
+-function _insertBefore(parentNode,newChild,nextChild){
+-  var cp = newChild.parentNode;
++function hasValidParentNodeType(node) {
++  return (
++  node &&
++  (node.nodeType === Node.DOCUMENT_NODE || node.nodeType === 
Node.DOCUMENT_FRAGMENT_NODE || node.nodeType === Node.ELEMENT_NODE)
++  );
++}
++
++/**
++ * Returns `true` if `node` can be inserted according to it's `nodeType`.
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function hasInsertableNodeType(node) {
++  return (
++  node &&
++  (isElementNode(node) ||
++  isTextNode(node) ||
++  isDocTypeNode(node) ||
++  node.nodeType === Node.DOCUMENT_FRAGMENT_NODE ||
++  node.nodeType === Node.COMMENT_NODE ||
++  node.nodeType === Node.PROCESSING_INSTRUCTION_NODE)
++  );
++}
++
++/**
++ * Returns true if `node` is a DOCTYPE node
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isDocTypeNode(node) {
++  return node && node.nodeType === Node.DOCUMENT_TYPE_NODE;
++}
++
++/**
++ * Returns true if the node is an element
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isElementNode(node) {
++  return node && node.nodeType === Node.ELEMENT_NODE;
++}
++/**
++ * Returns true if `node` is a text node
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isTextNode(node) {
++  return node && node.nodeType === Node.TEXT_NODE;
++}
++
++/**
++ * Check if en element node can be inserted before `child`, or at the end if 
child is falsy,
++ * according to the presence and position of a doctype node on the same level.
++ *
++ * @param {Document} doc The document node
++ * @param {Node} child the 

Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1

[Jonas Smedegaard]

Quoting Scott Talbert (2022-11-24 03:00:41)
> On Sat, 19 Nov 2022, Adrian Bunk wrote:
> 
> > Control: tags 1023149 + patch
> > Control: tags 1023149 + pending
> >
> > Dear maintainer,
> >
> > I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded
> > it to DELAYED/15. Please feel free to tell me if I should cancel it.
> 
> Can this NMU be accepted ASAP?
> 
> Assuming I'm reading excuses correctly, I believe this is preventing a 
> massive number of haskell packages from migrating to testing.

I welcome this bugfix and agree: @Adrian, please release it without
further delay.

Unfortunately I cannot take over and release now myself, as my GPG key
has expired so I cannot do package uploads until the next batch update
of the keyring data (which was estimated to happen two days ago, so will
probably happen soonish).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1024732: Acknowledgement (python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character)

[Wojciech Zabołotny]

Dear Maintainer,

This is a duplicate of bug number 1024731 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024731).
It seemed that my University server refused to forward the bug message, 
and therefore I've resubmitted it via another account.


Please join 1024731 and 1024732.

I'm sorry for confusion,
With best regards,
Wojciech Zabolotny

Bug#1024746: ITP: muscle3 -- multiple alignment program of protein sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-med

Subject: ITP: muscle3 -- multiple alignment program of protein sequences
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: muscle3
  Version : 3.8.1551
  Upstream Author : Copyright: © Robert C. Edgar "Bob" 
* URL : https://www.drive5.com/muscle/
* License : PD-dedication
  Programming Lang: C
  Description : multiple alignment program of protein sequences
 MUSCLE is a multiple alignment program for protein sequences. MUSCLE
 stands for multiple sequence comparison by log-expectation. In the
 authors tests, MUSCLE achieved the highest scores of all tested
 programs on several alignment accuracy benchmarks, and is also one of
 the fastest programs out there.
 .
 This is version 3 of the muscle program.  It is a different program
 than muscle version 5 which is packaged as muscle in Debian.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/muscle3

Bug#1009118: Bug#1009118: python3-biopython: incompatible with muscle >= 5

[Andreas Tille]

Hi Charles,

thank you for the hint.

Am Thu, Nov 24, 2022 at 10:28:43AM +0900 schrieb Charles Plessy:
> I have read the Muscle5 paper and it is a totally different program than
> Muscle3.
> 
> https://pubmed.ncbi.nlm.nih.gov/36379955/
> 
> Reintroducing muscle3 as a separate package might be useful not only to
> Biopython, but also to the people who need it in pipelines, etc.

I've created a new git repository[1] and filed an ITP bug report.  Will
upload to new soon.

Kind regards

  Andreas.

[1] https://salsa.debian.org/med-team/muscle3 

-- 
http://fam-tille.de

Bug#1024747: rust-env-logger: please update to v0.9.3

[Jonas Smedegaard]

Source: rust-env-logger
Version: 0.9.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v0.9.3.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmN/L0MACgkQLHwxRsGg
ASF4+xAAi3aZLmE1MC+sTciedsgTffiQ+88OWtVh8fyp/LOf0qxU6sCOcah8+vEG
HVVb/6BA/sR9Sf1lBl4IMQ4Bb3Ky7biByFhFriW0gUFnnNuyVEQtGKNYjUANgF5V
x62ejQ+u9qeUfxs+jQuiWjDhwY78raC8y+S/AZ5yq99G70qQm3dDXpvdqGtXBhRi
Qd6ZYeZM/RJACJbuSwfjHBRZfURfSfjCD6x0x6c1jCd8ns87cczJAMlvozyqD18C
uzdgZF5BEZG+oz0Cf8OOmcJyfllg+UxOJH0ww26hjjeiRlqD8gc8qIFYSDt2q0vY
gJxowA5SEaJwOUnZOU729iK7gZ6ierTpaRWjD1Zzti0h62Dz+UTeDfzkBc2+Tl3v
4xTacNFf/iTwXfHamhEiTXMKW2ltPiLTvGghYaajXHQXRdb7ex9ymP6guOJN1PSm
+dKxUn1KLrI2Nkt2sP3vjlT1YDtLzfKYK1irF9tKO1ETAnjQ96nLgdbZfmk6rt38
MpBDNjsbsAA9EdBJFlBPrEpKGAWs3g7E6130GW5W3hrHkT2T1E/rhsLL1PqQONYS
dxe0FA9QDbWoOQAJ88ObgLa98TVIx1ZQXAemleekfz88i69H/jj07obcFgEsE4R4
N9szY86LwBR5FOEegWY85XhPzVZuR0MTbqWfJ01kNl9SaASk5B8=
=bucR
-END PGP SIGNATURE-

Bug#1023746: Fwd: gdal | Enable JPEGXL driver on supported arches (!5)

[Mathieu Malaterre]

For later reference.

-- Forwarded message -

Architecture conditionals in the gdal package are not acceptable,
that's why we also don't use the packaged lerc (likewise unavailable
on s390x).

jpeg-xl support will be enabled once its available on all release architectures.

Bug#1024748: r-bioc-multiassayexperiment: Should not block BioC 3.16 transition

[Andreas Tille]

Source: r-bioc-multiassayexperiment
Version: 1.22.0+dfsg-1
Severity: critical
Tags: ftbfs
Justification: breaks unrelated software
X-Debbugs-Cc: 1023...@bugs.debian.org

Since r-bioc-multiassayexperiment needs a new dependency
r-bioc-biocbaseutils (ITP #1024567) it is blocking the BioC 3.16
transition[1] for an undetermined time.  To not create any
blocker for other packages r-bioc-multiassayexperiment should be
removed from testing which is the purpose of this bug.

Kind regards
Andreas.

[1] https://release.debian.org/transitions/html/r-api-bioc-3.16.html

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#1024749: rust-pretty-assertions: please update to v1.3.0

[Jonas Smedegaard]

Source: rust-pretty-assertions
Version: 1.2.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v1.3.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmN/MggACgkQLHwxRsGg
ASF/nRAAjwj+X9I9AILU1ndSDzRpQN/hIwE/IMDPWxqJZJEsvmeVo4aoXkChTa0n
tSNCoe3hVFk/meOdPBWdrPZdoGVY3QouroPJKwHPCCGXoDiQG8xxnzu+gbcvZ7lc
eekPzhvjtX0Yl1FJAP+KsKhXd0n10w5wzbLFPCSI4IUHMhmiyU0jZrhNPArceDnQ
wT9JEMilaV1KbML7WfWg9Jq+Sz9iXPHNwtSQJAM2M56Yw881i0tnYtC6LThC3KWi
nYCJeVo5jIXdr5599KxCxBxdIyCDXyJxXkTt7Obv3kEOEU5aZ2plXM3LbRGtgQeE
tiq9vkeko0Jv3oPxptpgkKZXS+9b78fUu7zXfQBfV8JpcJ0T/g02mHgppa14/ojK
8SF1EEdQZcDg9ifxRK8RB6zI5epaCtTUAE9tH7+mOiCmYTfWS0sWZCpYqkcLavH4
bNJVOXpgV0Dbzl06Ii6jLDFd9RlScCPxI3XQS0KQ9KgtGyTPwVpLi4bC8JmhwwH1
qrHFECwyrbXvc/3b9Mlqrx0w2DH8ACD/zdmFM8Ksryv8hrmA5Th+MZYHHpJkBzHI
IjAf8TkfrR/UbdJsWsv2X6AkOvflS5nhZsUNOjZ2uruMh94WY8dLTbi8YxxwsXsu
X7vaIQNMJ5ylhak84ojDmbw3QlV+sm/x6mo0PcJFngjV0WXPhOc=
=B8xj
-END PGP SIGNATURE-

Bug#1024750: rust-serde: please update to v1.0.147

[Jonas Smedegaard]

Source: rust-serde
Version: 1.0.145-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v1.0.147.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmN/MqUACgkQLHwxRsGg
ASGyFA/8D4t7bAa7NYGLIQ/ZPbFx9Hzqj9u9fY+ByrsbAEXyt9V2wv6/VEJD439P
WLQaRqCdFNohYFMKWZy08FTFK8GaIqRYZuK2u5SMTQzTqPvP/f//jAVe7M7KgFNV
25FppY+nBSyD2sCZ4QmQpT6lC86qlCETQX6oHTe+xYjlQpVHusU05uxo+KSsvK0U
DMEwWaHoU4mQWNIOnKsPg+/ZPbLykMOEsxJurfRLiTUiVtsMhEuzopAx4JJeaLAd
nYYh+OKWZamCSHrVD40YVi3OQeCrNl2MibKbkIcsh751PukeWK3roulLBVFXwcK5
juigshIGlKRx2AqNWcNeSn7wdFSp1NHYdk100lVmP0oRckY4Np6LlBR/JaA43MT/
e9V0pvSTgt+0TQx+xYEdOBDh+9yHtOwRLMZIAwLlnz32SSAQQywn8n32GU8t0QPM
LJbue2M58DOMR7k4d64BTaBojE9EaUHQ2PNLaOyg8fzYzGEyyUWoguSB+4QjOCH/
yQY4pPyu2YwoesZPw0hZDtuzg7xABXJi8Ytw/De5ejIdAmHCpx8G+BsPwsby9yv0
kq3TjZc7B5y8vXgzX9Gisl5LbAQPthuDiho4XQWRakfHwG22+PX9KFxlRjtXv5qc
07j0DunNMkG/9+DZEt4ETMLBlfqJVbI2QtuO3GJamhK7zPEYl/Q=
=Qwzi
-END PGP SIGNATURE-

Bug#1024751: r-bioc-scater: Should not block BioC 3.16 transition

[Andreas Tille]

Source: r-bioc-scater
Version: 1.24.0+ds-1
Severity: critical
Tags: ftbfs
Justification: breaks unrelated software
X-Debbugs-Cc: 1023...@bugs.debian.org


Since r-bioc-scater needs a new dependency r-cran-ggrastr (ITP #1024582)
it is blocking the BioC 3.16 transition[1] for an undetermined time.  To
not create any blocker for other packages r-bioc-scater should be
removed from testing which is the purpose of this bug.

Kind regards
 Andreas.

[1] https://release.debian.org/transitions/html/r-api-bioc-3.16.html


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#1023873: rygel: fixed

[Leonardo Canducci]

Package: rygel
Followup-For: Bug #1023873

Dear Maintainer,
gnome media share is working again. rygel package was not updated so I
really don't know what caused the problem. Anyway since its fixed now
this bug shuld be closed.

Thanks,
Leonardo


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 rygel depends on:
ii  init-system-helpers 1.65.2
ii  libc6   2.36-5
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1
ii  libgee-0.8-20.20.6-1
ii  libges-1.0-01.20.3-1
ii  libglib2.0-02.74.1-2
ii  libgssdp-1.6-0  1.6.2-2
ii  libgstreamer-plugins-base1.0-0  1.20.4-1
ii  libgstreamer1.0-0   1.20.4-1
ii  libgupnp-1.6-0  1.6.2-1
ii  libgupnp-av-1.0-3   0.14.1-1
ii  libgupnp-dlna-2.0-4 0.12.0-3
ii  libmediaart-2.0-0   1.9.6-1
ii  librygel-core-2.8-0 0.42.0-2
ii  librygel-db-2.8-0   0.42.0-2
ii  librygel-renderer-2.8-0 0.42.0-2
ii  librygel-server-2.8-0   0.42.0-2
ii  libsoup-3.0-0   3.2.1-2
ii  libsqlite3-03.40.0-1
ii  libx11-62:1.8.1-2
ii  libxml2 2.9.14+dfsg-1.1+b2

Versions of packages rygel recommends:
ii  dbus-user-session  1.14.4-1
ii  gstreamer1.0-libav 1.20.3-1+b1
ii  gstreamer1.0-plugins-base  1.20.4-1
ii  gstreamer1.0-plugins-good  1.20.3-1+b1
ii  gstreamer1.0-plugins-ugly  1.20.3-1

Versions of packages rygel suggests:
ii  rygel-playbin  0.42.0-2
ii  rygel-preferences  0.42.0-2
ii  rygel-ruih 0.42.0-2
ii  rygel-tracker  0.42.0-2
ii  tumbler4.16.1-1

-- no debconf information

Bug#1011921:

[王昊然]

Not all non-unicode text streams can be reliably detected, as they could be
ambiguous to eachother.

And the attached file is actually in UTF-8, not Big5, confirmed by file(1)
as well as manual reading:

$ file 111D2012841-01.txt
111D2012841-01.txt: Unicode text, UTF-8 text
$ iconv -f utf-8 -t big-5 111D2012841-01.txt | file -
/dev/stdin: ISO-8859 text
$ iconv -f utf-8 -t gb18030 111D2012841-01.txt | file -
/dev/stdin: Non-ISO extended-ASCII text, with LF, NEL line terminators

Though the GB18030 result appears more correct than Big5.

Bug#1024752: qt6-websockets FTCBFS: does not pass QT_HOST_PATH

[Helmut Grohne]

Source: qt6-websockets
Version: 6.3.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qt6-websockets fails to cross build from source, because it does not
pass QT_HOST_PATH. I'm attaching the usual patch.

Helmut
diff --minimal -Nru qt6-websockets-6.3.1/debian/changelog 
qt6-websockets-6.3.1/debian/changelog
--- qt6-websockets-6.3.1/debian/changelog   2022-08-15 19:24:16.0 
+0200
+++ qt6-websockets-6.3.1/debian/changelog   2022-11-23 21:18:22.0 
+0100
@@ -1,3 +1,10 @@
+qt6-websockets (6.3.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass -DQT_HOST_PATH. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 23 Nov 2022 21:18:22 +0100
+
 qt6-websockets (6.3.1-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --minimal -Nru qt6-websockets-6.3.1/debian/rules 
qt6-websockets-6.3.1/debian/rules
--- qt6-websockets-6.3.1/debian/rules   2021-11-24 14:07:16.0 +0100
+++ qt6-websockets-6.3.1/debian/rules   2022-11-23 21:18:18.0 +0100
@@ -3,12 +3,18 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+cmake_extra_args :=
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+cmake_extra_args += -DQT_HOST_PATH=/usr
+endif
+
 %:
dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)
+   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
+   $(cmake_extra_args)
 
 execute_after_dh_auto_install:
# Reproducible builds: remove build paths from .prl files

Bug#1024753: libvirtd doesn't run: "SCHED_CORE not supported by kernel"

[Philipp Marek]

Package: src:linux
Version: 6.0.8-1
Severity: important
X-Debbugs-Cc: phil...@marek.priv.at


Sorry about the German messages.

libvirt version: 8.9.0, package: 1 (Andrea Bolognani 
 Sat, 19 Nov 2022 23:00:34 +0100)


Nicht unterstützte Konfiguration: SCHED_CORE not supported by kernel
Initialisierung des QEMU Status-Treibers fehlgeschlagen: Nicht 
unterstützte Konfiguration: SCHED_CORE not supported by kernel

Treiber Status Initialisierung fehlgeschlagen

My libvirt-daemon is 8.9.0-1; downgrading to 8.5.0-1 makes it work
again, should the error be reported against that one,
or does it make sense to recompile the kernel with that config?


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11)


** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-4-amd64 root=/dev/mapper/rs232-root ro quiet

** Not tainted

Bug#1024754: r-bioc-mofa: Should not block BioC 3.16 transition

[Andreas Tille]

Source: r-bioc-mofa
Version: 1.6.1+dfsg-7
Severity: critical
Tags: ftbfs
Justification: breaks unrelated software
X-Debbugs-Cc: 1023...@bugs.debian.org


Since r-bioc-mofa depends r-bioc-multiassayexperiment with RC bug
#1024748 and thus it is blocking the BioC 3.16 transition[1] for an
undetermined time.  To not create any blocker for other packages
r-bioc-mofa should be removed from testing which is the purpose of this
bug.

Kind regards
   Andreas.

[1] https://release.debian.org/transitions/html/r-api-bioc-3.16.html


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#1024755: r-bioc-bluster: Autopkgtest fails since r-bioc-scater is not yet updated to latest version matching BioC 3.16

[Andreas Tille]

Source: r-bioc-bluster
Version: 1.8.0+dfsg-1
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: 1023...@bugs.debian.org


Since autopkgtest of r-bioc-bluster depends from r-bioc-scater which
needs a new dependency r-cran-ggrastr (ITP #1024582) it is blocking the
BioC 3.16 transition[1] due to debci failures for an undetermined time.
To not create any blocker for other packages r-bioc-bluster should be
removed from testing which is the purpose of this bug.

[1] https://release.debian.org/transitions/html/r-api-bioc-3.16.html


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#1023731: BioC Transition blocked by new dependencies

[Andreas Tille]

Am Thu, Nov 24, 2022 at 08:46:31AM +0100 schrieb Sebastian Ramacher:
> > >r-bioc-bitseq - should be removed from testing immediately bug just 
> > > filed)

Bug #1024661

> > >r-bioc-multiassayexperiment

#1024748

> > >r-bioc-demixt (bug #1024597 was just filed)
> > >r-bioc-scater

#1024751

> > >r-bioc-mofa (just due dependencies)

Bug filed as well even if redundant since removal of
r-bioc-multiassayexperiment should also remove this.

> > > Do you want me to file RC bugs against r-bioc-multiassayexperiment,
> > > r-bioc-scater and r-bioc-mofa.
> > 
> > Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and
> > r-bioc-singler[2] probably also these two packages need a RC bug to not
> > block the transition.

Bugs will be filed against r-bioc-bluster and r-bioc-singler once my
'only 5 reports per hour for submission' period is over (I'm frequently
wondering whether this is a bit harsh constraint - I'm beaten by it
two to four times per year by it)

> > The test suite issue of r-bioc-structuralvariantannotation is discussed
> > with upstream[4].  I'm fine to remove it from testing for the moment as
> > well.
> >  
> > Just let me know whether I should file the according bugs.
> 
> Please do.

Done (or about to do) - transition bug in CC. 

Thanks a lot for your patience
Andreas.

-- 
http://fam-tille.de

Bug#1024756: transition: libktorrent

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Dear Release Team,

I’d like to request a transition slot for libktorrent.

It has 2 reverse dependencies:
- kget
- ktorrent

Both rebuild successfully with the new version of the library.

I’ve uploaded libktorrent 22.08.3-3 with the new ABI to experimental and
it builds successfully on the same architectures as previously. [0]


Ben file:

title = "libktorrent";
is_affected = .depends ~ "libkf5torrent6abi2" | .depends ~ "libkf5torrent6abi3";
is_good = .depends ~ "libkf5torrent6abi3";
is_bad = .depends ~ "libkf5torrent6abi2";

[0] 
https://buildd.debian.org/status/package.php?p=libktorrent&suite=experimental


Thanks,
--
Aurélien

Bug#1024344: precious - new version of rust-serial-test.

[Jonas Smedegaard]

Quoting Peter Green (2022-11-17 22:13:44)
> Package: precious
> Version: 0.3.0-1
> Severity: serious
> 
> I've just uploaded version 0.9 of rust-serial-test, the dependencies in 
> precious
> need updating to match. A debdiff is attatched.
> 
> If I get no response i'll probablly NMU this in a week or so.

Thanks!

I expect to update precious in a few days - preferably to newer upstream
release, if bugs #1024747, #1024749 and #1024750 can be easily fixed,
otherwise without that version change.  I.e. no need for an NMU here -
thanks for the offer.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1024731: Acknowledgement (python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character)

[Wojciech Zabołotny]

Of course in my workaround.py there was a mistake. Instead of:

    img.save("code.png")

there should be:

   ic.save("code.png")

--

Regards,
Wojtek

W dniu 24.11.2022 o 11:14, Wojciech Zabołotny pisze:
Based on the fact that dmtxread correctly handles decoding of data 
containing null bytes I have created a temporary workaround.
The result of decoding in Python is used only to identify the 
rectangle containing the code.


That rectangle is then saved to the file and os.system is used to 
decode it with dmtxread.


It is a "quick & dirty" solution, but at least works...
#!/usr/bin/python
from pylibdmtx.pylibdmtx import decode
from PIL import Image
import os
# Read the scanned test
img = Image.open("demo.png")
if img.mode != 'RGB':
   img = img.convert('RGB')
# The timeout value (and other options) below may need adjustment
# If you know any better way how to reasonable control
# precision of the dmtx decoding, please let me know
dm_read=decode(img)
for i in range(0,len(dm_read)):
fout="demo_out_"+str(i)+".bin"
r=dm_read[i].rect
b=(r.left,r.top,r.left+r.width,r.top+r.height)
ic=img.crop(b)
ic.save("code.png")
os.system("dmtxread code.png > "+fout)

Bug#1024731: Acknowledgement (python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character)

[Wojciech Zabołotny]

Based on the fact that dmtxread correctly handles decoding of data 
containing null bytes I have created a temporary workaround.
The result of decoding in Python is used only to identify the rectangle 
containing the code.


That rectangle is then saved to the file and os.system is used to decode 
it with dmtxread.


It is a "quick & dirty" solution, but at least works...

--

Regards,
Wojtek
#!/usr/bin/python
from pylibdmtx.pylibdmtx import decode
from PIL import Image
import os
# Read the scanned test
img = Image.open("demo.png")
if img.mode != 'RGB':
   img = img.convert('RGB')
# The timeout value (and other options) below may need adjustment
# If you know any better way how to reasonable control
# precision of the dmtx decoding, please let me know
dm_read=decode(img)
for i in range(0,len(dm_read)):
fout="demo_out_"+str(i)+".bin"
r=dm_read[i].rect
b=(r.left,r.top,r.left+r.width,r.top+r.height)
ic=img.crop(b)
img.save("code.png")
os.system("dmtxread code.png > "+fout)

Bug#1024757: Editor: -key ignored

[Dr. Nikolaus Klepp]

Package: openscad
Version: 2021.01-5+b2
Severity: important
X-Debbugs-Cc: off...@klepp.biz

Dear Maintainer,

After yesterdays upgrade openscad ignores the -key

Expected: 
- press  --> editor performs linebreak.

Observed:
- press  --> nothing happen, the key is ignored.
- press + --> editor performs linebreak.

-key is working everywhere else. 
The openscad 2021.01 Appimage also works as expected.

Regards,
Nik

-- Package-specific info:
Output of /usr/share/bug/openscad:
$ glxinfo |grep 'OpenGL .* string:'
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 6600 (navi23, LLVM 15.0.5, DRM 3.48, 
6.0.0-4-amd64)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.2.4
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.2.4
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openscad depends on:
ii  lib3mf11.8.1+ds-4
ii  libboost-filesystem1.74.0  1.74.0-17+b2
ii  libboost-program-options1.74.0 1.74.0-17+b2
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu72]  1.74.0-17+b2
ii  libc6  2.36-5
ii  libcairo2  1.16.0-6
ii  libdouble-conversion3  3.2.1-1
ii  libfontconfig1 2.13.1-4.5
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.2.0-9
ii  libgl1 1.5.0-1
ii  libglew2.2 2.2.0-4+b1
ii  libglib2.0-0   2.74.1-2
ii  libglu1-mesa [libglu1] 9.0.2-1.1
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libharfbuzz0b  5.2.0-2+b1
ii  libmpfr6   4.1.0-3
ii  libopencsg11.5.0-1+b1
ii  libqscintilla2-qt5-15  2.11.6+dfsg-4+b1
ii  libqt5core5a   5.15.6+dfsg-2+b1
ii  libqt5dbus55.15.6+dfsg-2+b1
ii  libqt5gamepad5 5.15.6-2
ii  libqt5gui5 5.15.6+dfsg-2+b1
ii  libqt5multimedia5  5.15.6-2
ii  libqt5network5 5.15.6+dfsg-2+b1
ii  libqt5widgets5 5.15.6+dfsg-2+b1
ii  libspnav0  1.0-1
ii  libstdc++6 12.2.0-9
ii  libx11-6   2:1.8.1-2
ii  libxml22.9.14+dfsg-1.1+b2
ii  libzip41.7.3-1+b1

Versions of packages openscad recommends:
ii  openscad-mcad  2019.05-1

Versions of packages openscad suggests:
pn  geomview  
pn  librecad  
pn  meshlab   
pn  openscad-testing  

-- no debconf information

Bug#1024626: blender FTBFS on 32bit

[Bo YU]

Source: blender
Followup-For: Bug #1024626


Hi,

Just FYI, I have reported the bug to upstream and will NMU if find a
workround.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1024626: blender FTBFS on 32bit

[Bo YU]

Source: blender
Followup-For: Bug #1024626

I am not sure why I am always to forget something when sumbit
reportbug:(

The issue for upstream: https://developer.blender.org/T102742 

Sorry for the noisy.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1024018: python-cleo: CVE-2022-42966

[Emmanuel Arias]

Hi,

I'm introducing python-cleo 1.0.0a5 that has this vulnerability. I need 
it for new upstream release of poetry (1.2.2). But I applied a patch 
from upstream to fix this issue [0].


There's a new upstream release from cleo 2.0.1 but this break poetry 
[1]. So, we need to wait a new upstream release of poetry before package 
version 2.*.* of cleo.



[0] 
https://salsa.debian.org/python-team/packages/python-cleo/-/blob/debian/master/debian/patches/0001-change_regex_string_to_less_permissive_one.patch


[1] https://github.com/python-poetry/cleo/blob/main/CHANGELOG.md

Cheers,

Emmanuel



OpenPGP_0xFA9DEC5DE11C63F1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024625: cmake-data: FindPython.cmake points to newest Python version, not the default

[Andrius Merkys]

Control: reopen -1
Control: found -1 3.25.0-2

Hello,

The bug still remains in 3.25.0-2. I am attempting to build promod3 
3.2.1+ds-6 which has:


find_package(Python 3.6 REQUIRED COMPONENTS Interpreter Development)

However, CMake output is the following:

-- Found Python: /usr/bin/python3.11 (found suitable version "3.11.0", 
minimum required is "3.6") found components: Interpreter Development 
Development.Module Development.Embed


Andrius

Bug#1024674: Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1

[Jochen Sprickerhof]

* Jeremy Bicha  [2022-11-23 16:33]:

Please schedule this rebuild to fix evolution-data-server
compatibility with libphonenumber which was rebuilt for the ongoing
protobuf transition. This rebuild wasn't on the auto tracker which
suggests that there is a bigger dependency issue somewhere. I don't
know if other packages are also affected. See
https://bugs.debian.org/1024674


The problem is/was that libphonenumber8 exposes the protobuf ABI. I've 
just uploaded a -2 to declare this dependency through a 
libphonenumber8-protobuf32 virtual package, similar how it is done in 
ignition-msgs.


I've just did a test build and evolution-data-server picks up the new 
dependency now. so I think the request should be:


dw evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m "libphonenumber8 (>= 
8.12.57+ds-2)"

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1024759: grub2 over pxe attemps to load weird config files

[Thomas Goirand]

Source: grub-efi-amd64
Version: 2.06-3~deb11u2
Severity: normal

Hi,

When booting under UEFI+Secure boot using Grub, I can see in my TFTP
server logs:

RRQ from 10.x.x.75 filename /grub/x86_64-efi/command.lst
sending NAK (1, File not found) to 10.x.x.75
RRQ from 10.x.x.75 filename /grub/x86_64-efi/fs.lst
sending NAK (1, File not found) to 10.x.x.75
RRQ from 10.x.x.75 filename /grub/x86_64-efi/crypto.lst
sending NAK (1, File not found) to 10.x.x.75
RRQ from 10.x.x.75 filename /grub/x86_64-efi/terminal.lst
sending NAK (1, File not found) to 10.x.x.75

Sledge on IRC told me to report this, as it shouldn't be doing this.

FYI, after the above, I'm getting the more normal:

RRQ from 10.x.x.75 filename /grub/grub.cfg

and then grub simply loads itself...

Cheers,

Thomas Goirand (zigo)

Bug#1024731: Acknowledgement (python3-pylibdmtx: The decode procedure truncates the decoded byte-string at null character)

[Wojciech Zabołotny]

I have tested my workaround on a bigger image with the code and found 
that pydmtx reverses the coordinates.

Calculation of the box used to export the code must be more complicated:

    # We need to introduce certain margin when exporting the rectangle 
with the code

    margin = 10
b=(r.left-margin,img.size[1]-r.top-r.height-margin,r.left+r.width+margin,img.size[1]-r.top+margin)

--

Regards,
Wojtek

#!/usr/bin/python
from pylibdmtx.pylibdmtx import decode
from PIL import Image
import os
# Read the scanned test
img = Image.open("demo.png")
if img.mode != 'RGB':
   img = img.convert('RGB')
# The timeout value (and other options) below may need adjustment
# If you know any better way how to reasonable control
# precision of the dmtx decoding, please let me know
dm_read=decode(img)
for i in range(0,len(dm_read)):
fout="demo_out_"+str(i)+".bin"
r=dm_read[i].rect
#b=(r.left,r.top,r.left+r.width,r.top+r.height)
# We need to introduce certain margin when exporting the rectangle with the code
margin = 10
b=(r.left-margin,img.size[1]-r.top-r.height-margin,r.left+r.width+margin,img.size[1]-r.top+margin)
ic=img.crop(b)
ic.save("code.png")
os.system("dmtxread code.png > "+fout)

Bug#1024761: Please include all utils

[Wolfgang Kroener]

Package: wsjtx
Version: 2.6.0~rc4+repack-2
Severity: wishlist

Dear Maintainers,

in CMakeLists.txt the variable WSJT_BUILD_UTILS (ON during Debian build)
builds following utils, that are not included in the package, because they are
not installed in CMakeLists.txt:1580 (search for WSJT_BUILD_UTILS in
CMakeLists.txt):

encode77
ft4code
ft4sim
ft4sim_mult
ft8sim
jt49sim
jt4sim
jt65sim
ldpcsim240_101
ldpcsim240_74
msk144sim
q65_ftn_test
rtty_spec
sumsim
test_q65
test_snr
wsprcode
wsprsim

E. g. ft8sim creates audio files from strings via the commandline.

Is it possible to include all built utils?

Greetings,
Wolfgang

Bug#849400: (no subject)

[Niklas Sombert]

This affects me, too.

And it's really weird that it doesn't work, because the live installer 
(calamares) manages this setup just fine. It's the recommended setup 
there, actually.


-- Niklas

(see also bug #858009)

Bug#1024762: mesa 22.2.4 & 22.3.0-rc3 break OpenGL applications on panfrost

[Arnaud Ferraris]

Source: mesa
Version: 22.2.4-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: aferra...@debian.org
Control: found -1 mesa/22.3.0~rc3-1

Dear Maintainer,

The latest mesa updates, affecting both 22.2.4-1 and 22.3.0~rc3-1, breaks (at
least) GTK4 and Qt apps on arm64 devices using the panfrost driver (tested to
affect the PinePhone Pro which includes a Mali-T860, but not the PinePhone
which has a Mali-400 GPU handled by the lima driver)

  [3022204.252]  -> zwp_linux_dmabuf_v1@30.create_params(new id
zwp_linux_buffer_params_v1@39)
  [3022204.322]  -> zwp_linux_buffer_params...@39.add(fd 12, 0, 0, 2880,
134217728, 81)
  [3022204.347]  -> zwp_linux_buffer_params_v1@39.create_immed(new id
wl_buffer@40, 720, 1296, 875713089, 0)
  [3022204.366]  -> zwp_linux_buffer_params_v1@39.destroy()
  [3022204.378]  -> wl_surface@27.attach(wl_buffer@40, 0, 0)
  [3022204.394]  -> wl_surface@27.damage_buffer(0, 0, 720, 1296)
  [3022204.658]  -> wl_surface@27.commit()
  [3022214.101] wl_display@1.delete_id(37)
  [3022214.152] wl_display@1.error(nil, 7, "importing the supplied dmabufs
failed")
  Gdk-Message: 11:16:51.477: Error 71 (Protocol error) dispatching to Wayland
display.

This seems to be an occurrence of
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7731, and I can confirm
reverting the offending commit fixes it.

Thanks,
Arnaud


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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
>From 813c0147d2fe169bcce69abea58656f38933f41a Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris 
Date: Thu, 24 Nov 2022 11:48:01 +0100
Subject: d/patches: fix breaking change in panfrost

---
 ...Require-64-byte-alignment-on-imports.patch | 154 ++
 debian/patches/series |   1 +
 2 files changed, 155 insertions(+)
 create mode 100644 
debian/patches/Revert-panfrost-Require-64-byte-alignment-on-imports.patch

diff --git 
a/debian/patches/Revert-panfrost-Require-64-byte-alignment-on-imports.patch 
b/debian/patches/Revert-panfrost-Require-64-byte-alignment-on-imports.patch
new file mode 100644
index 000..cb16591dd3b
--- /dev/null
+++ b/debian/patches/Revert-panfrost-Require-64-byte-alignment-on-imports.patch
@@ -0,0 +1,154 @@
+From: Arnaud Ferraris 
+Date: Thu, 24 Nov 2022 11:46:01 +0100
+Subject: Revert "panfrost: Require 64-byte alignment on imports"
+
+This reverts commit e1fe4a64d3f319731152bb48e6cb15e899452b15.
+---
+ .pick_status.json  |  2 +-
+ src/panfrost/lib/pan_layout.c  | 54 +++---
+ src/panfrost/lib/pan_texture.c |  8 ---
+ src/panfrost/lib/pan_texture.h |  6 -
+ 4 files changed, 4 insertions(+), 66 deletions(-)
+
+diff --git a/.pick_status.json b/.pick_status.json
+index c17161c..bedb90f 100644
+--- a/.pick_status.json
 b/.pick_status.json
+@@ -2479,7 +2479,7 @@
+ "description": "panfrost: Require 64-byte alignment on imports",
+ "nominated": true,
+ "nomination_type": 0,
+-"resolution": 1,
++"resolution": 0,
+ "main_sha": null,
+ "because_sha": null
+ },
+diff --git a/src/panfrost/lib/pan_layout.c b/src/panfrost/lib/pan_layout.c
+index 51b511a..127ad6c 100644
+--- a/src/panfrost/lib/pan_layout.c
 b/src/panfrost/lib/pan_layout.c
+@@ -275,34 +275,6 @@ panfrost_texture_offset(const struct pan_image_layout 
*layout,
+(surface_idx * layout->slices[level].surface_stride);
+ }
+ 
+-/*
+- * Return the minimum stride alignment in bytes for a given texture format.
+- *
+- * There is no format on any supported Mali with a minimum alignment greater
+- * than 64 bytes, but 64 bytes is the required alignment of all regular 
formats
+- * in v7 and newer. If this alignment is not met, imprecise faults may be
+- * raised.
+- *
+- * This may not be necessary on older hardware but we enforce it there too for
+- * uniformity. If this poses a problem there, we'll need a solution that can
+- * handle v7 as well.
+- *
+- * Certain non-regular formats require smaller power-of-two alignments.
+- * This requirement could be loosened in the future if there is a compelling
+- * reason, by making this query more precise.
+- */
+-uint32_t
+-pan_stride_align_B(UNUSED enum pipe_format format)
+-{
+-return 64;
+-}
+-
+-bool
+-pan_is_stride_aligned(enum pipe_format format, uint32_t stride_B)
+-{
+-return (stride_B % pan_stride_align_B(format)) == 0;
+-}
+-
+ bool
+ pan_image_layout_init(struct pan_image_layout *layout,
+   const struct pan_image_explicit_layout *explicit_layout)
+@@ -316,15 +288,8 @@ pan_image_layout_init(struct pan_image_layout *layout,
+  la

Bug#1024215: libqt5opengl5 depends on: libqt5gui5, libqt5gui5 | libqt5gui5-gles

[Dmitry Shachnev]

Hi Oliver!

On Wed, Nov 16, 2022 at 04:53:15PM +1100, Oliver Borm wrote:
> Package: libqt5opengl5
> Version: 5.15.6+dfsg-2+b1
>
> Source: qtbase-opensource-src (5.15.6+dfsg-2)
> Architecture: arm64
> Installed-Size: 582
> Depends: libc6 (>= 2.17), libqt5core5a (>= 5.15.1), libqt5gui5 (>= 5.1.0),
> libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0),
> libqt5widgets5 (>= 5.9.0~beta), libstdc++6 (>= 5), qtbase-abi-5-15-6
>
> libqt5opengl5 depends on libqt5gui5 and on libqt5gui5 or
> libqt5gui5-gles. Thus, it will never be possible to have libqt5gui5-gles
> installed as dependency, as libqt5gui5 is always pulled in.

I intentionally did not include libqt5opengl5 library in the -gles
packages, because that library is deprecated.

Quoting the official documentation [1]:

> Warning: This module should not be used anymore for new code.
> Please use the corresponding OpenGL classes in Qt GUI.

[1]: https://doc.qt.io/qt-5/qtopengl-index.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1021677: bugs.debian.org: Video fails to play in any web browser

[Jack Lucas]

It appears to be working now by doing:

Comment out this in /etc/pulse/default.pa

#load-module module-suspend-on-idle

apt install pipewire-pulse

killall pulseaudio

Jack

Bug#1024763: Supermicro AOC-STGN-I1S (Intel 82599EN based 10G adapter) - poor network perfomance after moving to Debian 11.5

[Bartek Kois]

Package: linux-image
Version: 5.10.0-19-amd64

After moving from Debian 9.7 to 11.5 as soon as I perform "ip link set 
enp1s0 up" for my 10G adapter (AOC-STGN-I1S - Intel 82599EN based 10G 
adapter) I am experiencing high cpu load (even if no traffic is passing 
through the adapter) and network performance is low (when network is 
connected). The cpu load is oscilationg between 0.1 and 0.3 on vanilla 
system with no network attached. The problem can be observed on the 
following platforms: Supermicro X9SCL (Intel C202 PCH) and Supermicro 
X10SLL+-F (Intel C222 Express PCH), but for the Supermicro X11SSL-F 
(Intel® C232 chipset) everyting is working well.


Tested enviroments:
Debian 9.7 - Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 
(2018-05-07) x86_64 GNU/Linux [all platforms working well with no 
problems: Supermicro X9SCL (Intel C202 PCH), Supermicro X10SLL+-F (Intel 
C222 Express PCH), Supermicro X11SSL-F (Intel® C232 chipset)]
Debian 11.5 - Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 
(2022-10-21) x86_64 GNU/Linux  [older platforms: Supermicro X9SCL (Intel 
C202 PCH), Supermicro X10SLL+-F (Intel C222 Express PCH) behave 
problematic as described above | newer platform: Supermicro X11SSL-F 
(Intel® C232 chipset) working well with no problems]


So far to solve the problem I was trying to upgrade system to the newest 
stable version, upgrade kernel to version 6.x, upgrade ixgbe driver to 
the newest version but with no luck.


Supermicro support suggested as follows:
it might be kernel releted debian 11.5 has kernel 5.10 whihch is a 
recent kernel it might not properly support the chipsets for X9 
therefore i suggest to use RHEL or CentOS as they use much older kernel 
versions. I expect that with ubuntu 20.04 you see the same problem it 
uses kernel 5.4

Bug#977739: progress of golang-github-texttheater-golang-levenshtein packaging

[Cyril Brulebois]

Control: owner -1 !
Control: retitle -1 ITP: golang-github-texttheater-golang-levenshtein -- Go 
implementation of the Levenshtein algorithm (library)

Cyril Brulebois  (2022-11-24):
> This ITP has been opened close to two years ago, and we haven't heard
> back in the last 5 months about possible progress. Since the packaging
> is rather straightforward, I'm tempted to “steal” this ITP and just
> upload the package I've prepared locally (required for crowdsec 1.4.2).

Let's do that…

> ChangZhuo Chen, I see you have created a repository on Salsa[1], but the
> debian/sid branch doesn't contain any debian/ directory at this point,
> do I have your permission to push my work in this repository, force
> pushing if required?
> 
>  1. 
> https://salsa.debian.org/go-team/packages/golang-github-texttheater-golang-levenshtein/-/tree/debian/sid/

… and since we have a disconnected debian/sid branch (no upstream
history) with a single commit, along with a pristine-tar branch, it
looks like old-style repository layout; additionally, there are no
packaging-related commits, so I'll just push upstream and debian/sid
branches, removing the pristine-tar one (that's no longer used in
pkg-go).

As usual for golang-* packages, I'm happy to have other people join the
maintenance!


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


signature.asc
Description: PGP signature

Bug#1024764: ITP: python-hdf5plugin -- Python library to make HDF5 compression filters usable from h5py

[Enrico Zini]

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

* Package name: python-hdf5plugin
  Version : 3.3.1
  Upstream Author : "ESRF - Data Analysis Unit" 
* URL : https://github.com/silx-kit/hdf5plugin
* License : MIT
  Programming Lang: C/Python
  Description : Python library to make HDF5 compression filters usable from 
h5py

hdf5plugin provides HDF5 compression filters (namely: blosc, bitshuffle,
lz4, FCIDECOMP, ZFP, zstd) and makes them usable from h5py.


I am going to maintain this in the Debian Science Team group.

Bug#1023738: orthanc-dicomweb FTBFS with node-axios 1.1

[Nilesh Patra]

On Fri, 18 Nov 2022 22:48:42 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
 wrote:
> Control: tags -1 + patch
> 
> Hi Sébastien,
> 
> orthanc-dicomweb is currently affected by a failure to build
> from source (Bug#1023738).  I took the liberty to have a look,
> and it seems that since axios 1.0 the dist/axios.map file is not
> provided anymore. 

I just did an upload for node-axios that provides the sourcemap file
again with a minor change (/usr/share/nodejs/axios/dist/axios.min.js.map instead
of min.map)

However axios code has changed a bit since last version and so has the 
sourcemap file.
This needs to be tested with orthanc-dicomweb (if it is even compatible)

> This is causing the following cmake error:
> 
>   CMake Error at debian/ThirdPartyDownloads/JavaScriptLibraries.cmake:29 
> (file):
> file COPY_FILE failed to copy
>   
>   /usr/share/nodejs/axios/dist/axios.map
>   
> to
>   
>   /<>/Build/javascript-libs/js/axios.min.map
> 
> Scanning through the source code, I noticed that axios.min.map
> file was not used anywhere (only mention is in a cmake file
> which is patched out in Debian context).  When removing the
> reference this way, I got the package to build again:

Looking at the description of node-axios:

Description: Promise based HTTP client for the browser and node.js
 Features:
  - Make XMLHttpRequests from the browser
  - Make http requests from node.js
  - Supports the Promise API
  - Intercept request and response
  - Transform request and response data
  - Cancel requests
  - Automatic transforms for JSON data
  - Client side support for protecting against XSRF
 .
 Node.js is an event-based server-side JavaScript engine.

Looks like axios might be used for an http client which the dicomweb _probably_
aims at doing. So removing that file via your patch _might_ not be correct.

But Sebastian is the best judge. Please let us know.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1023722: qrenderdoc crashes immediately

[Bernhard Übelacker]

Dear Maintainer,
this issue was also discussed upstream in [1] [2].

There the reason was given, that running the application
inside a KDE plasma session makes Qt pick up some KDE
shared libraries (KDEPlasmaPlatformTheme.so),
which does its own GL interactions, which is
not expected by qrenderdoc at that time.

A package built with upstream patch [3] makes qrenderdoc
not crash at startup inside a KDE plasma session.

Kind regards,
Bernhard

[1] https://github.com/baldurk/renderdoc/issues/2772
[2] https://github.com/baldurk/renderdoc/issues/2752
[3] 
https://github.com/baldurk/renderdoc/commit/101dbda8c34888bf2051c3c257da3a1702705ef9


(rr) bt
#0  0x7f1d2b62cfd2 in glGetString_renderdoc_hooked (name=eGL_VERSION) at 
./renderdoc/driver/gl/gl_hooks.cpp:158
#1  glGetString (name=eGL_VERSION) at ./renderdoc/driver/gl/gl_hooks.cpp:158
#2  0x7f1d285f4359 in getGlString (param=7938) at 
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:144
#3  updateFormatFromContext (format=...) at 
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:174
#4  0x7f1d285f5b7e in QGLXContext::init (this=0x56133bffce60, screen=, share=) at 
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp:416
#5  0x7f1d285f31b7 in QXcbGlxIntegration::createPlatformOpenGLContext 
(this=, context=0x7ffebfee1400) at 
./src/plugins/platforms/xcb/gl_integrations/xcb_glx/qxcbglxintegration.cpp:197
#6  0x7f1d2a3827bd in QOpenGLContext::create 
(this=this@entry=0x7ffebfee1400) at kernel/qopenglcontext.cpp:612
#7  0x7f1d2513603c in checkBackend (checkContext=...) at 
./src/platformtheme/qtquickrenderersettings.cpp:43
#8  initializeRendererSessions () at 
./src/platformtheme/qtquickrenderersettings.cpp:79
#9  initializeRendererSessions () at 
./src/platformtheme/qtquickrenderersettings.cpp:52
#10 0x7f1d29cb7aaf in qt_call_pre_routines () at 
kernel/qcoreapplication.cpp:317
#11 QCoreApplicationPrivate::init (this=this@entry=0x56133be84620) at 
kernel/qcoreapplication.cpp:849
#12 0x7f1d2a337b8c in QGuiApplicationPrivate::init 
(this=this@entry=0x56133be84620) at kernel/qguiapplication.cpp:1530
#13 0x7f1d2ab684c9 in QApplicationPrivate::init (this=0x56133be84620) at 
kernel/qapplication.cpp:513
#14 0x56133a722884 in main ()
(rr)

https://invent.kde.org/plasma/plasma-integration/-/blob/97a2a802948d7ff91be6db564472d2c82286bd2f/src/platformtheme/qtquickrenderersettings.cpp#L103
https://github.com/qt/qtbase/blob/ca254a0937d58e573a0e2b210590de2a02326e5f/src/corelib/kernel/qcoreapplication.cpp#L291

Bug#1024765: apt-show-versions is confused when versions from different architectures disagree

[Vincent Lefevre]

Package: apt-show-versions
Version: 0.22.13+nmu1
Severity: normal

I get

cventin:~> apt-show-versions -a clang-14-doc
clang-14-doc:all 1:14.0.6-8 install ok installed
No stable version
No stable-updates version
clang-14-doc:all 1:14.0.6-2   testing  ftp.debian.org
clang-14-doc:all 1:14.0.6-6   unstable ftp.debian.org
clang-14-doc:all 1:14.0.6-10~exp1 experimental ftp.debian.org
clang-14-doc:all/experimental *manually* upgradeable from 1:14.0.6-8 to 
1:14.0.6-10~exp1

but the current unstable version is 1:14.0.6-8, not 1:14.0.6-6!

On https://tracker.debian.org/pkg/llvm-toolchain-14 one has

  [2022-11-12] Accepted llvm-toolchain-14 1:14.0.6-8 (source) into unstable
  (Sylvestre Ledru)

and on my machine, /usr/share/doc/clang-14-doc/changelog.Debian.gz
starts with

llvm-toolchain-14 (1:14.0.6-8) unstable; urgency=medium
   ^^  

Moreover,
/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-amd64_Packages
contains

Package: clang-14-doc
Source: llvm-toolchain-14
Version: 1:14.0.6-8
[...]

I suspect that apt-show-versions is confused by
/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-i386_Packages,
which contains

Package: clang-14-doc
Source: llvm-toolchain-14
Version: 1:14.0.6-6
[...]

i.e. the unstable version given by apt-show-versions.

I suppose that apt-show-versions should follow the behavior of apt
and aptitude.

Concerning apt:

cventin:~> apt install -s clang-14-doc/unstable
[...]
Selected version '1:14.0.6-8' (Debian:unstable [all]) for 'clang-14-doc'

so it takes the amd64 version, probably because this is the main
architecture on this machine (i386 being a foreign one).

And in /var/log/aptitude, I can see

[UPGRADE] clang-14-doc:amd64 1:14.0.6-7 -> 1:14.0.6-8

mentioning amd64 explicitly.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (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.0.0-4-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 apt-show-versions depends on:
ii  apt  2.5.4
ii  libapt-pkg-perl  0.1.40+b2
ii  perl [libstorable-perl]  5.36.0-4

apt-show-versions recommends no packages.

apt-show-versions 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#1024765: apt-show-versions is confused when versions from different architectures disagree

[Vincent Lefevre]

Control: forcemerge 855428 -1

After a closer look, this seems to be the same bug as 855428,
where there is the same behavior and same explanation.

There seems to be a difference: for bug 855428, there was apparently
no foreign architecture; it just says "apt-show-versions is looking
into different architectures' archives which happen to be on the same
disk" and the "apt-cache policy" doesn't show a foreign architecture
there, while I get:

cventin:~> apt-cache policy clang-14-doc
clang-14-doc:
  Installed: 1:14.0.6-8
  Candidate: 1:14.0.6-8
  Version table:
 1:14.0.6-10~exp1 1
  1 https://ftp.debian.org/debian experimental/main amd64 Packages
  1 https://ftp.debian.org/debian experimental/main i386 Packages
 *** 1:14.0.6-8 500
500 https://ftp.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 1:14.0.6-6 500
500 https://ftp.debian.org/debian unstable/main i386 Packages
 1:14.0.6-2 500
500 https://ftp.debian.org/debian testing/main amd64 Packages
500 https://ftp.debian.org/debian testing/main i386 Packages

So I'm not sure of the exact rules to select the package version.
Anyway, this is inconsistent with apt and aptitude.

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

Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content

[Nilesh Patra]

On Mon, 21 Nov 2022 13:53:43 +0100 Leon van Kammen  
wrote:
> my few cents: the problem with censorship is, once you start, the
> rabbithole is infinite.
> Whatever shitty homepage or comment it is, eventually it's just a homepage
> or comment.
> I think debian-devs should not be going down the rabbithole of scanning all
> code for 'bad' words, bad images, suspicious logos etc, as the creativity
> of humans in infinite too..
> The reactive path also plays in the hands of those activists (expect
> "debian turns out to be ran by X" youtube vids).

Cat't agree more. The offensive content has been patched out already there
is no merit to keep digging down on it more and more.
This package is actually useful as Petter already stated clearly, so removing
it just on the basis of a homepage does not seem good.

A sensible compromise maybe to remove the homepage field from d/control if that
serves the purpose. Debian was always about technology and shall always be about
that (let's not forget that at the end of the day it is an operating system).
Imposing debian values over each line of code over each package makes it no 
longer
fully focussed about technology. We can't and shouldn't expect each upstream's 
ideologies
to be same as ours, that's literally impossible.


I personally value inclusiveness, being excellent to people a lot but those 
things
should be applied to developers/contributors engaging in debian. Not for each 
and every
package's contributors that lands in debian.
I doubt if a user is going to migrate all the way through the source code,
and visit upstream homepage and get offended because _we_ vendor the software. 
In the
end it's our and the user's loss because a useful software would be dropped out 
of the bag for
reasons not related to technical aspect.

In the end, you will do what you want (i.e. maybe removing the package and I 
know that) but I just
wanted to speak up.
(And I see this as a different case as compared to the fortunes-off thing as 
this does not spit
that kind of virtiol onto user's terminal after the patch)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1024734: pipewire-pulse: please enable auto switch on connect in pipewire-pulse.conf by default

[Dylan Aïssi]

Control: tag -1 wontfix

Le jeu. 24 nov. 2022 à 03:27, Jason Lewis  a écrit :
>
> Fix involves adding "{ path = "pactl" args = "load-module 
> module-switch-on-connect" }"
>

The switch-on-connect module is disabled by default because too much
agressive in its way to handle switches. I won't enable it by default.

The switch is managed by wireplumber, and it works properly in
general. But, you are
probably facing a similar issue to https://bugs.debian.org/998073

BTW, are you using wireplumber? If so, can you report your issue to
the wireplumber
bug tracker?
> https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues

Best,
Dylan

Bug#981484: webext-exteditor: not compatible with current thunderbird

[Paride Legovini]

On Sun, 31 Jan 2021 20:56:35 +0100 Ivo De Decker  wrote:
> package: webext-exteditor
> version: 2.0.4-1
> severity: serious
> 
> Hi,
> 
> Thunderbird 1:78.7.0-1 has 'Breaks: webext-exteditor (<= 2.0.4-1)', which
> means webext-exteditor doesn't work with it.

Upstream isn't active anymore. I suggest switching to:

https://github.com/Frederick888/external-editor-revived

--
Paride

Bug#1024766: python-cassandra-driver: FTBFS on python3.11-dbg on powerpc and ppc64

[Stefano Rivera]

Source: python-cassandra-driver
Version: 3.25.0-1
Severity: normal

I've been investigating the build-failures on python3.11-dbg on the big
endian PPCs. My notes so far:

This is reproduceable, but only when the __pycache__ directories don't
exist:

$ python3.11-dbg setup.py build
$ cd build/lib.linux-ppc64-cpython-311-pydebug
# Repeat this as necessary after running nose:
$ find . -name __pycache__ | xargs rm -r
$ python3.11-dbg -X tracemalloc -m nose -v  
--ignore-files="test_eventletreactor\.py"
/usr/lib/python3/dist-packages/nose/importer.py:12: DeprecationWarning: the imp 
module is deprecated in favour of importlib and slated for removal in Python 
3.12; see the module's documentation for alternative uses
  from imp import find_module, load_module, acquire_lock, release_lock
gc:0: ResourceWarning: Object of type _cffi_backend.__CDataGCP is not untracked 
before destruction
gc:0: ResourceWarning: Object of type _cffi_backend.__CDataGCP is not untracked 
before destruction
gc:0: ResourceWarning: Object of type _cffi_backend.__CDataGCP is not untracked 
before destruction
../Modules/gcmodule.c:442: update_refs: Assertion "gc_get_refs(gc) != 0" failed
Memory block allocated at (most recent call first):
  File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 1542

object address  : 0x7fff95097690
object refcount : 0
object type : 0x7fff958f2250
object type name: _cffi_backend.__CDataGCP
object repr : 

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0x7fff98874820 (most recent call first):
  Garbage-collecting
  File "/usr/lib/python3.11/linecache.py", line 93 in updatecache
  File "/usr/lib/python3.11/linecache.py", line 46 in getlines
  File "/usr/lib/python3.11/linecache.py", line 30 in getline
  File "/usr/lib/python3.11/warnings.py", line 42 in _formatwarnmsg_impl
  File "/usr/lib/python3.11/warnings.py", line 128 in _formatwarnmsg
  File "/usr/lib/python3.11/warnings.py", line 28 in _showwarnmsg_impl
  File "/usr/lib/python3.11/warnings.py", line 112 in _showwarnmsg
  File "/usr/lib/python3/dist-packages/twisted/internet/_sslverify.py", line 
1811 in fromOpenSSLCipherString
  File "/usr/lib/python3/dist-packages/twisted/internet/_sslverify.py", line 
1834 in 
  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "/usr/lib/python3/dist-packages/twisted/protocols/tls.py", line 59 in 

  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "/usr/lib/python3/dist-packages/twisted/internet/_newtls.py", line 18 in 

  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "/usr/lib/python3/dist-packages/twisted/internet/tcp.py", line 38 in 

  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "", line 241 in _call_with_frames_removed
  File "", line 1234 in _handle_fromlist
  File "/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 19 
in 
  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "", line 241 in _call_with_frames_removed
  File "", line 1234 in _handle_fromlist
  File "/usr/lib/python3/dist-packages/twisted/internet/epollreactor.py", line 
19 in 
  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "/usr/lib/python3/dist-packages/twisted/internet/default.py", line 43 in 
_getInstallFunction
  File "/usr/lib/python3/dist-packages/twisted/internet/default.py", line 55 in 

  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "", line 241 in _call_with_frames_removed
  File "", line 1234 in _handle_fromlist
  File "/usr/lib/python3/dist-packages/twisted/internet/reactor.py", line 38 in 

  File "", line 241 in _call_with_frames_removed
  File "", line 940 in exec_module
  File "", line 690 in _load_unlocked
  File "", line 1149 in _find_and_load_unlocked
  File "", line 1178 in _find_and_load
  File "", line 241 in _call_with_frames_removed
  File "", line 1234 in _handle_fromlist
 

Bug#1024766: python-cassandra-driver: FTBFS on python3.11-dbg on powerpc and ppc64

[stefanor]

Control: clone -1 -2
Control: reassign -2 python3-cffi-backend
Control: found -2 python3-cffi-backend/1.15.1-3+b1

> I simplified that down even further to this in python-cffi:
> 
> from cffi import FFI
> ffi = FFI()
> p = ffi.new("int *", 123)
> ffi.gc(p, lambda x: None)

Let's track this separately

SR

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

Bug#1024768: libphonenumber: FTBFS after switch to debhelper

[tony mancill]

Source: libphonenumber
Version: 8.12.57+ds-2
Severity: serious

Creating this for tracking and coordination purposes.  After this [1]
upload, libphonenumber is FTBFS.  Please refer to the buildd logs [2].

[1] 
https://tracker.debian.org/news/1389357/accepted-libphonenumber-81257ds-2-source-into-unstable/
[2] https://buildd.debian.org/status/package.php?p=libphonenumber

Bug#1024769: mujs: CVE-2022-44789

[Salvatore Bonaccorso]

Source: mujs
Version: 1.3.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for mujs.

CVE-2022-44789[0]:
| A logical issue in O_getOwnPropertyDescriptor() in Artifex MuJS 1.0.0
| through 1.3.1 allows an attacker to achieve Remote Code Execution
| through memory corruption, via the loading of a crafted JavaScript
| file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-44789
https://www.cve.org/CVERecord?id=CVE-2022-44789
[1] 
https://github.com/ccxvii/mujs/commit/edb50ad66f7601ca9a3544a0e9045e8a8c60561f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1024770: libpcsclite1: multi-arch installation not possible

[Stephan Brunner]

Package: libpcsclite1
Version: 1.9.1-1
Severity: minor

When trying to install libpcsclite-dev, and therefore libpcsclite1, via 
multi-arch (host is x86-64), e.g.
apt install libpcsclite-dev libpcsclite-dev:arm64
, the installation would break the system. See the output below.

I wanted to install this package to my build host, which does cross compilation 
for some architectures in an CI environment.
I am using Debian 11 on x86-64.
Latest updates installed as of 2022-11-24.

Example output of the apt install example above:
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
distro-info-data iso-codes libffi-dev libmpdec3 libncurses-dev libpfm4 
libpython3-stdlib libpython3.9-minimal libpython3.9-stdlib libtinfo-dev 
libz3-dev llvm-11 llvm-11-runtime lsb-release
  python-apt-common python3-certifi
python3-chardet python3-debconf python3-debian python3-httplib2 
python3-idna python3-pkg-resources python3-pygments python3-requests 
python3-six python3-urllib3
  Use 'apt autoremove' to remove them.
  The following additional packages will be installed:
libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 
libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 
libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9-
  minimal:arm64 libpython3.9-stdlib:arm64
libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 
libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 
python3.9-minimal:arm64 uuid-runtime zlib1g:arm64
  Suggested packages:
gpm:arm64 pcscd:arm64 python3-doc:arm64 python3-tk:arm64 
python3-venv:arm64 python3.9-venv:arm64 python3.9-doc:arm64 binutils:arm64
  The following packages will be REMOVED:
apt-listchanges llvm-11-dev llvm-11-tools python3 python3-apt 
python3-debianbts python3-minimal python3-pycurl python3-pysimplesoap 
python3-reportbug python3-yaml python3.9 python3.9-minimal
  reportbug
  The following NEW packages will be installed:
libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 
libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 
libpcsclite-dev:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64
  libpython3.9-minimal:arm64
libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 
libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 
python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64
  uuid-runtime zlib1g:arm64
  0 upgraded, 24 newly installed, 14 to remove and 0 not upgraded.
  Need to get 8,185 kB of archives.
  After this operation, 202 MB disk space will be freed.
  Do you want to continue? [Y/n] ^C



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

Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[Daniel Kiper]

Adding Daniel Axtens...

On Tue, Nov 15, 2022 at 06:31:45PM +, Steve McIntyre wrote:
> Hi all!
>
> программист некто (in CC) reported this bug a few weeks back in
> Debian. Since I applied the bundle of filesystem bounds-checking fixes
> a few months back, he can't run grub-install. He's done the work to
> determine that the patch that breaks things for him is
>
> 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of 
> nat journal entries
>
> The full thread of our discussion is at https://bugs.debian.org/1021846
>
> I don't have any knowledge of f2fs to go any further here. Help please! :-)
>
> - Forwarded message from программист некто 
>  -
>
> From: программист некто 
> To: sub...@bugs.debian.org
> Date: Sat, 15 Oct 2022 23:54:36 +0300
> Subject: Bug#1021846: grub-install is broken since 2.06-3: error: unknown 
> filesystem
> Message-Id: <3168731665867...@wf4nrjvtssjecb53.iva.yp-c.yandex.net>
>
> Package: grub-pc
> Version: 2.06-3~deb11u1
> Severity: critical
>
> Hello. Since version 2.06-3, grub-install is broken: it fails with "error: 
> unknown filesystem".
> I test command /usr/sbin/grub-install -v /dev/sda
> in some versions. Results in mail attachments.
> Versions older than 2.06-3 works without error (2.06-2 and lower).
> Tested versions: 2.04-20, 2.06-1, 2.06-2, 2.06-3~deb10u1, 2.06-3~deb11u1, 
> 2.06-4.
>
> Disk partitions:
>
> # fdisk --list-details
> Disk /dev/sda: 29,82 GiB, 32017047552 bytes, 62533296 sectors
> Disk model: TS32GSSD370S
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0xc7177f7e
>
> Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs
> /dev/sda1 2048 22763519 22761472 83 Linux 4/4/1 1023/254/2
> /dev/sda2 * 25866240 62531583 36665344 7 HPFS/ 1023/254/2 1023/254/2 80
>
> $ disktype /dev/sda1
> --- /dev/sda1
> Block device, size 10.85 GiB (11653873664 bytes)
> F2FS file system (version 1.14)
>
> $ disktype /dev/sda2
> --- /dev/sda2
> Block device, size 17.48 GiB (18772656128 bytes)
> NTFS file system
> Volume size 17.48 GiB (18772652032 bytes, 36665336 sectors)
>
> - End forwarded message -
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
>   Mature Sporty Personal
>   More Innovation More Adult
>   A Man in Dandism
>   Powered Midship Specialty

Bug#1024771: RFP: libnet-dns-resolver-unbound-perl -- Net::DNS resolver based on libunbound

[Thomas Uhle]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Perl Group , 
Unbound Packagers 

* Package name: libnet-dns-resolver-unbound-perl
  Version : 1.20
  Upstream Author : Dick Francks 
* URL or Web page : https://metacpan.org/release/Net-DNS-Resolver-Unbound
* License : MIT
  Description : Net::DNS resolver based on libunbound

Net::DNS::Resolver::Unbound is designed as an extension to an existing 
Net::DNS installation which facilitates DNS(SEC) name resolution using 
the libunbound library.  Net::DNS::Resolver::Unbound replaces the 
resolver's send() and bgsend() functionality in the 
Net::DNS::Resolver::Base implementation.

Bug#1024772: libcpuinfo-dev: cpuinfo-targets.cmake

[Dylan Aïssi]

Package: libcpuinfo-dev
Version: 0.0~git20220617.082deff-1

Dear maintainer,

While packaging tensorflowlite [1], I face an issue with cpuinfo-targets.cmake.
The find_package(cpuinfo REQUIRED) step fails:

 Make Error at /usr/lib/cmake/cpuinfo/cpuinfo-targets.cmake:86 (message):
   The imported target "cpuinfo::clog" references the file

  "/usr/lib/lib/x86_64-linux-gnu/libclog.a"

   but this file does not exist.  Possible reasons include:

   * The file was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and contained

  "/usr/lib/cmake/cpuinfo/cpuinfo-targets.cmake"

   but not all the files it references.


Note the repeated path segment "/lib/lib/", the path should be
 /usr/lib/x86_64-linux-gnu/libclog.a instead.

Best,
Dylan

[1] https://salsa.debian.org/deeplearning-team/tensorflowlite

Bug#1023738: orthanc-dicomweb FTBFS with node-axios 1.1

[Étienne Mollier]

Control: tags -1 - patch

Hi Nilesh,

Nilesh Patra, on 2022-11-24:
> On Fri, 18 Nov 2022 22:48:42 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
>  wrote:
> > orthanc-dicomweb is currently affected by a failure to build
> > from source (Bug#1023738).  I took the liberty to have a look,
> > and it seems that since axios 1.0 the dist/axios.map file is not
> > provided anymore. 
> 
> I just did an upload for node-axios that provides the sourcemap file
> again with a minor change (/usr/share/nodejs/axios/dist/axios.min.js.map 
> instead
> of min.map)
> 
> However axios code has changed a bit since last version and so has the 
> sourcemap file.
> This needs to be tested with orthanc-dicomweb (if it is even compatible)

Thanks for your work on the node-axios front, with some luck,
bringing back a map file will be helpful.

> > This is causing the following cmake error:
> > 
> > CMake Error at debian/ThirdPartyDownloads/JavaScriptLibraries.cmake:29 
> > (file):
> >   file COPY_FILE failed to copy
> > 
> > /usr/share/nodejs/axios/dist/axios.map
> > 
> >   to
> > 
> > /<>/Build/javascript-libs/js/axios.min.map
> > 
> > Scanning through the source code, I noticed that axios.min.map
> > file was not used anywhere (only mention is in a cmake file
> > which is patched out in Debian context).  When removing the
> > reference this way, I got the package to build again:
> 
> Looking at the description of node-axios:
> 
> Description: Promise based HTTP client for the browser and node.js
>  Features:
>   - Make XMLHttpRequests from the browser
>   - Make http requests from node.js
>   - Supports the Promise API
>   - Intercept request and response
>   - Transform request and response data
>   - Cancel requests
>   - Automatic transforms for JSON data
>   - Client side support for protecting against XSRF
>  .
>  Node.js is an event-based server-side JavaScript engine.
> 
> Looks like axios might be used for an http client which the dicomweb 
> _probably_
> aims at doing. So removing that file via your patch _might_ not be correct.

Thanks for checking in depth, I remove the "patch" tag for now.

> But Sebastian is the best judge. Please let us know.

Definitely

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Manticora - 1963. Creator of Failure


signature.asc
Description: PGP signature

Bug#1024773: libpresage-doc: missing Breaks+Replaces: libpresage-dev (<< 0.9.1-2.4)

[Andreas Beckmann]

Package: libpresage-doc
Version: 0.9.1-2.4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libpresage-dev:amd64.
  Preparing to unpack .../libpresage-dev_0.9.1-2.3_amd64.deb ...
  Unpacking libpresage-dev:amd64 (0.9.1-2.3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libpresage-dev_0.9.1-2.3_amd64.deb (--unpack):
   trying to overwrite '/usr/share/doc/libpresage-dev/getting_started.txt.gz', 
which is also in package libpresage-doc 0.9.1-2.4
  Errors were encountered while processing:
   /var/cache/apt/archives/libpresage-dev_0.9.1-2.3_amd64.deb


cheers,

Andreas


libpresage-doc=0.9.1-2.4_libpresage-dev=0.9.1-2.3.log.gz
Description: application/gzip

Bug#1024774: cpuinfo: FTBFS: dh_auto_test: init-test (Failed)

[Dylan Aïssi]

Package: cpuinfo
Version: 0.0~git20220617.082deff-1
Severity: important
Tags: ftbfs

Dear maintainer,

While trying to rebuild cpuinfo in a clean sid pbuilder environment, it fails
to build or more precisely it fails during the dh_auto_test step due to a
failure with init-test:

 [ RUN  ] CORE.known_uarch
 ./test/init.cc:313: Failure
 Expected: (cpuinfo_uarch_unknown) != (core->uarch), actual: 0 vs 0
 ./test/init.cc:313: Failure
 Expected: (cpuinfo_uarch_unknown) != (core->uarch), actual: 0 vs 0
 ./test/init.cc:313: Failure
 Expected: (cpuinfo_uarch_unknown) != (core->uarch), actual: 0 vs 0
 ./test/init.cc:313: Failure
 Expected: (cpuinfo_uarch_unknown) != (core->uarch), actual: 0 vs 0
 [  FAILED  ] CORE.known_uarch (0 ms)

Looks like it is a CPU specific issue as it doesn't fail on
reproducible-builds [1]. I can reproduce this issue with two
different intel i7 (i7-1185G7 and i7-1165G7). I don't have other
CPU to test.

Best,
Dylan

[1] https://tests.reproducible-builds.org/debian/rb-pkg/cpuinfo.html

Bug#1023738: orthanc-dicomweb FTBFS with node-axios 1.1

[Sébastien Jodogne]

Dear Étienne and Nilesh,

On 24/11/22 17:25, Étienne Mollier wrote:

Control: tags -1 - patch

Hi Nilesh,

Nilesh Patra, on 2022-11-24:

On Fri, 18 Nov 2022 22:48:42 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
 wrote:

orthanc-dicomweb is currently affected by a failure to build
from source (Bug#1023738).  I took the liberty to have a look,
and it seems that since axios 1.0 the dist/axios.map file is not
provided anymore.

[...]
However axios code has changed a bit since last version and so has the 
sourcemap file.
This needs to be tested with orthanc-dicomweb (if it is even compatible)

[...]
Thanks for checking in depth, I remove the "patch" tag for now.


But Sebastian is the best judge. Please let us know.


Many thanks for your great help with this issue!

Sorry for not answering earlier, but I'm still in the process of 
finalizing the GNU Health / Orthanc conference, and I'm extremely busy 
with my academic activities.


I'll have a look by Wednesday 30th November.

Kind Regards,
Sébastien-

Bug#1024775: systemd-cryptenroll --pkcs11-token-uri=list PKCS#11 tokens not supported on this build.

[Jean-Michel Pouré]

Package: systemd
Version: 252.1-1

Dear all,

I am trying to use an OpenSC compatible PKCS#11 token to enroll an RSA
keypair to unlock a LUKS partition.

systemd-cryptenroll --pkcs11-token-uri=list
PKCS#11 tokens not supported on this build

Could you please build systemd with PKCS#11 support.
PKCS#11 is the standard way to enroll security tokens and is very
mature.

Hardware: any libccid smartcard reader
https://ccid.apdu.fr/

Token: smartcard-hsm but it could also be the Yubikey
https://www.smartcard-hsm.com/

For testing : apt install opensc libccid pcscd opensc-pkcs11

Everything is in Debian and should work.
Please allow pkcs11-token and I will test both smartcard-hsm and
yubikey.

Kind regards,

Bug#1024774: cpuinfo: FTBFS: dh_auto_test: init-test (Failed)

[Étienne Mollier]

Hi Dylan,

Dylan Aïssi, on 2022-11-24:
> Looks like it is a CPU specific issue as it doesn't fail on
> reproducible-builds [1]. I can reproduce this issue with two
> different intel i7 (i7-1185G7 and i7-1165G7). I don't have other
> CPU to test.

Data point: I don't reproduce any problem on CPU model name:
AMD Ryzen 5 3600 6-Core Processor.

Hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1021838: bullseye-pu: package binfmt-support/2.2.1-1+deb11u1

[Colin Watson]

On Wed, Nov 23, 2022 at 08:43:37PM +, Adam D. Barratt wrote:
> On Sat, 2022-10-15 at 18:11 +0100, Colin Watson wrote:
> > https://bugs.debian.org/1012154 reported a startup issue due to a
> > race
> > between systemd-binfmt.service and binfmt-support.service (which has
> > probably been around for a long time).  
> > https://bugs.debian.org/1021822
> > mentions that it would be helpful to have the fix for this in stable
> > as
> > well, which I agree with.
> 
> Please go ahead.

Thanks, uploaded.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1009118: python3-biopython: incompatible with muscle >= 5

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2022-11-24:
> Am Thu, Nov 24, 2022 at 10:28:43AM +0900 schrieb Charles Plessy:
> > I have read the Muscle5 paper and it is a totally different program than
> > Muscle3.
> > 
> > https://pubmed.ncbi.nlm.nih.gov/36379955/
> > 
> > Reintroducing muscle3 as a separate package might be useful not only to
> > Biopython, but also to the people who need it in pipelines, etc.
> 
> I've created a new git repository[1] and filed an ITP bug report.  Will
> upload to new soon.

Thanks for the upload, I further adjusted the muscle wrapper so
it would catch the muscle3 binary if it finds it in the path, as
I see your new package provides the executable /usr/bin/muscle3.
If no such executable is available, the default switches to
plain muscle.  In any case it is possible for a user of the
biopython wrapper to enforce a given executable name by setting
the cmd argument of the constructor.  Changes are available in
the muscle3 patch[2] on salsa.  I'm hopeful to upload biopython
1.80 to experimental this evening.

> [1] https://salsa.debian.org/med-team/muscle3 
[2]: 
https://salsa.debian.org/med-team/python-biopython/-/blob/master/debian/patches/muscle3.patch

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


signature.asc
Description: PGP signature

Bug#1024699: [Pkg-utopia-maintainers] Bug#1024699: volume-key: Testsuite error on local rebuild

[Michael Biebl]

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

Am 23.11.22 um 13:18 schrieb Andreas Metzler:

Source: volume-key
Version: 0.3.12-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

volume-key FTBFS on current sid:
FAIL: packet_roundtrips.sh


Please provide instructions how this issue can be reproduced


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024776: ITP: golang-github-slackhq-nebula -- scalable overlay networking (Go library)

[Peymaneh]

Package: wnpp
Severity: wishlist
Owner: Peymaneh 

* Package name: golang-github-slackhq-nebula
  Version : 1.6.1-1
  Upstream Author : Slack
* URL : https://github.com/slackhq/nebula
* License : Expat
  Programming Lang: Go
  Description : scalable overlay networking tool (Go library)

 Nebula is a scalable overlay networking tool with a focus on
 performance, simplicity and security.

The library files are needed as a builddependency for updating
golang-github-smallstep-certificates and caddy

Bug#1024671: poke: SEGFAULT when writing array of arrays to buffer

[Sergio Durigan Junior]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28380

On Tuesday, November 22 2022, Agathe Porte wrote:

> Dear Maintainer,
>
> When "poking" with the tutorial of GNU poke and its SBM image format,
> the program fails to write arrays of arrays into ios and fails:
>
>
>_
>---'   __\___
>   __)  GNU poke 2.4
>   __)
>  __)
>---.___)
>
>   Copyright (C) 2019-2022 The poke authors.
>   License GPLv3+: GNU GPL version 3 or later.
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.
>
>   Powered by Jitter 0.9.284.
>   Perpetrated by Jose E. Marchesi.
>
>   For help, type ".help".
>   Type ".exit" to leave the program.
>   (poke) .mem img
>   The current IOS is now `*img*'.
>   (poke) dump
>   76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
>   :          
>   0010:          
>   0020:          
>   0030:          
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   (poke) string @ 0#B = "SBM"
>   (poke) dump
>   76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
>   : 5342 4d00        SBM.
>   0010:          
>   0020:          
>   0030:          
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   (poke) byte @ 3#B = 5
>   (poke) byte @ 4#B = 7
>   (poke) dump
>   76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
>   : 5342 4d05 0700       SBM.
>   0010:          
>   0020:          
>   0030:          
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   (poke) var c = [0xffUB,0x42UB,0x13UB]
>   (poke) var l = [c,c,c,c,c]
>   (poke) var i = [l,l,l,l,l,l,l]
>   (poke) byte[3][5][7] @ 5#B = i
>   (poke) dump
>   76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
>   : 5342 4d05 0700       SBM.
>   0010:          
>   0020:          
>   0030:          
>   0040:          
>   0050:          
>   0060:      00ff 4213   B...
>   0070:          
>   (poke) c
>   [1]11989 segmentation fault  poke
>
> As you can see, the memory is not correctly written, and attempting to
> print a value after attempting to write to the memory results in a
> SEGFAULT.
>
> I suspect that the error starts when the request to write the array of
> arrays is initiated, but does not result in the memory buffer being
> modified. I guess the interpreter is writing the content somewhere else
> than in the buffer.
>
> This issue was already reported upstream by another user in 2021:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28380
>
> However I am not able to know if this bug is from upstream, or if the
> user that reported the upstream bug was also using the Debian package.
>
> If one can reproduce this error, eventually on another distro, we should
> notify upstream that the error is still happening.

Hello Agathe,

Thank you very much for taking the time to report this bug.

I see that in the meantime you have been able to reproduce it with git
HEAD from

Bug#1024777: nnn: improve d/watch file

[Patrice Duroux]

Package: nnn
Version: 4.5-1
Severity: wishlist

Dear Maintainer,

Here is a patch regarding trouble with Releases page (see
https://wiki.debian.org/debian/watch#GitHub)

Thanks,
patrice


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

Kernel: Linux 6.1.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
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 nnn depends on:
ii  libc62.36-5
ii  libncursesw6 6.3+20220423-2
ii  libreadline8 8.2-1.2
ii  libtinfo66.3+20220423-2
ii  readline-common  8.2-1.2

nnn recommends no packages.

Versions of packages nnn suggests:
pn  atool | patool 
ii  file   1:5.41-4
pn  lftp   
ii  libimage-exiftool-perl [exiftool]  12.51+dfsg-1
ii  mediainfo  22.09-1
ii  sshfs  3.7.2-1
pn  vlock  
ii  xdg-utils  1.1.3-4.1

-- no debconf information
diff --git a/debian/watch b/debian/watch
index 01fa5f9..fc30e00 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
 opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/nnn-$1\.tar\.gz/ \
-   https://github.com/jarun/nnn/releases \
-   (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
+   https://github.com/jarun/nnn/tags \
+   (?:.*?/)?v?(\d[\d.]*)\.tar\.gz

Bug#1024778: libdmtx0b: Decoding takes very long time and fails on scanned DMTX code

[Wojciech M. Zabolotny]

Package: libdmtx0b
Version: 0.7.5-3+b1
Severity: important
X-Debbugs-Cc: w...@ise.pw.edu.pl

Dear Maintainer,

I have found a DMTX code which after printing and scanning causes dmtxread to 
freeze for a long time and finally fail.
I attach three PNG files:
1. PNG extracted from PDF with the original code (without printing and 
scanning) - dmtx_orig.png
2. PNG printed and scanned with one resolution which decodes correctly - 
dmtx_scan_ok.png
3. PNG printed and scanned with another resolution - dmtx_scan_bad.png 

I have tested those codes with the Python scripts based on the pylibdmtx module.
The results are the same, so I suppose that the problem is related to the 
underlying libdmtx0b library.

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 libdmtx0b depends on:
ii  libc6  2.36-5

libdmtx0b recommends no packages.

libdmtx0b suggests no packages.

-- no debconf information

Bug#1024779: libjs-bootstrap4: scss not available on pkgjs-ln

[Bastian Germann]

Package: libjs-bootstrap4
Version: 4.6.1+dfsg1-3
Severity: normal

When I `pkgjs-ln bootstrap`, the resulting node_modules/bootstrap link points to /usr/share/nodejs/bootstrap which does 
not contain the sass part of the module. package.json will still have {"sass": "scss/bootstrap.scss"}.

Please install /usr/share/sass to /usr/share/nodejs/bootstrap/scss or create a 
link.
If the sass-less installation is common please reassign this to the right place.

Bug#1023067: Bookworm netinstall CD: X-Server crashing on virtio-gpu

[Bernhard Übelacker]

Dear Maintainer,
it seems less a crash, instead it fails to find the
right drivers to use, therefore exits.

Looking at the Xorg.0.log from a bullseye netinst it looks
like it uses the /usr/lib/xorg/modules/drivers/modesetting_drv.so
driver inside a virtio equipped qemu VM,
which seems missing in the bookworm daily netinst.

Kind regards,
Bernhard

Bug#475249: Bug has been fixed a long time ago

[Rob Pearce]

Hi,

I found this bug report when looking for things I needed to fix in the 
revived / forked version of slim.


The fix listed in the bug report was applied upstream in June 2011, for 
v1.3.6, and Debian has been using the corrected version for quite some time.


Surely this bug should be closed?

Thanks,

Rob

--
Maintainer of the https://sourceforge.net/projects/slim-fork/";>SLiM Login 
Manager fork

Bug#1023535: transition: protobuf

[Sebastian Ramacher]

Hi László

On 2022-11-21 20:42:41 +0100, Sebastian Ramacher wrote:
> Control: tags -1 = confirmed
> 
> On 2022-11-10 23:10:29 +0100, Sebastian Ramacher wrote:
> > Control: block -1 by 1022248 1018945
> > 
> > On 2022-11-06 09:08:57 +0100, László Böszörményi wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Hi RMs,
> > > 
> > > There's a long awaited transition of Protobuf. It clashes with the
> > > ruby3.1-default transition, but as I know its rebuilds are just
> > > starting[1].
> > > On the other hand I'm done with the rebuilds and patched all issues,
> > > this transition may start immediately at your decision. The only
> > > downside is that the Sid version of cura-engine is FTBFS and to fix
> > > it, the libarcus transition (only affecting this package) will need to
> > > be done.
> > > 
> > > Failing packages and fixes in detail.
> > > Level 2:
> > > android-platform-frameworks-base has my patch already applied [2] for
> > > experimental (not Sid!).
> > > libarcus builds in Sid, but not the version in experimental for which
> > > I provided a fix [3].
> > > target-factory changed library symbols [4], maintainer will need to 
> > > update that.
> > > 
> > > Level 3:
> > > cura-engine fails with the Sid version [5], with the libarcus
> > > transition done it compiles fine.
> > > grpc-java for which I provided the fix [6], the maintainer noted he
> > > will be ready to update the package.
> > > llvm-toolchain-13 for which I provided the fix [7], other problems
> > > seem to be fixed with the upload just happened.
> > > llvm-toolchain-14 for which I also provided the fix [8], its other
> > > problem [9] might be wrongly closed by cross referenced
> > > llvm-toolchain-15 package - but Sylvestre Ledru seems to be aware of
> > > issues anyway.
> > 
> > Let's wait until icu and libbpf are done.
> 
> Please go ahead

protobuf's autopkgtests are failing. Could you please take a look at
them? Thanks

Cheers
-- 
Sebastian Ramacher

Bug#1023550: transition: qcustomplot

[Sebastian Ramacher]

Hi Filippo

On 2022-11-22 21:41:15 +0100, Filippo Rusconi wrote:
> Greetings Sebastian,
> 
> On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote:
> > Hi Filippo
> > 
> > On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote:
> > > Greetings Sebastian,
> > > 
> > > Thank your for your message.
> > > 
> > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote:
> > > > Control: tags -1 moreinfo
> > > > Control: forwarded -1 
> > > > https://release.debian.org/transitions/html/auto-qcustomplot.html
> > > >
> > > > Hi Filippo
> > > >
> > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
> > > > > debian-science-maintain...@lists.alioth.debian.org
> > > > >
> > > > > (please explain about the transition: impacted packages, reason, ...
> > > > >  for more info see: 
> > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
> > > > >
> > > > > Greetings,
> > > > >
> > > > > Fundamental reason: Qt5 and Qt6 are in the archive.
> > > > >
> > > > > I am requesting a transition from package libqcustomplot2.0 to
> > > > > libqcustomplot2.1. Source package is qcustomplot. The change involves 
> > > > > a change
> > > > > in the library name itself, from libqcustomplot2.0 to both 
> > > > > libQCustomPlot2.1 and
> > > > > libQCustomPlotQt6.so.2.1.0 (see below).
> > > > >
> > > > > I have prepared the packaging in the following git repos branch:
> > > > >
> > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6
> > > 
> > > [...]
> > > 
> > > > > For the libs under my control, the transition is already prepared and 
> > > > > these
> > > > > projects are going to be linking against the Qt6-built library, 
> > > > > contrary to all
> > > > > the other packages detailed below.
> > > > >
> > > > > For the other libs listed above, I have already checked that they 
> > > > > would build if
> > > > > some modifications were performed. I have already git branches ready 
> > > > > for the
> > > > > packages under git VCS. For the others (source deb), I have patches 
> > > > > available.
> > > > >
> > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for 
> > > > > many and
> > > > > also sometimes use the CMake-based configuration involving first
> > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot 
> > > > > formalism for
> > > > > the linker.
> > > > >
> > > > > That is: almost one- or two-liner patches.
> > > >
> > > > Could you please file bugs for those so that maintainers are aware?
> > > 
> > > Yes, I'll do that. I have already informed them individually of the 
> > > process and
> > > provided them with the relevant patch.
> > 
> > Thanks! Please go ahead with the transition.
> 
> I just uploaded the package to unstable. I have not closed the bug yet, 
> waiting
> to check that everything goes fine.

qcustomplot's autopkgtests are failing. Could you please take a look at
them? Thanks

Cheers
-- 
Sebastian Ramacher

Bug#1024780: msxpertsuite: FTBFS with new qcustomplot

[Sebastian Ramacher]

Source: msxpertsuite
Version: 5.8.9-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=msxpertsuite&arch=amd64&ver=5.8.9-1%2Bb1&stamp=1669196043&raw=0

[ 70%] Building CXX object 
massxpert/CMakeFiles/massxpert.dir/qrc_application.cpp.o
[ 70%] Linking CXX executable massxpert
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -Wl,-z,relro 
-rdynamic CMakeFiles/massxpert.dir/massxpert_autogen/mocs_compilation.cpp.o 
CMakeFiles/massxpert.dir/nongui/CalcOptions.cpp.o 
CMakeFiles/massxpert.dir/nongui/ChemEntVignette.cpp.o 
CMakeFiles/massxpert.dir/nongui/ChemEntVignetteRenderer.cpp.o 
CMakeFiles/massxpert.dir/nongui/ChemicalGroup.cpp.o 
CMakeFiles/massxpert.dir/nongui/ChemicalGroupRule.cpp.o 
CMakeFiles/massxpert.dir/nongui/CleaveMotif.cpp.o 
CMakeFiles/massxpert.dir/nongui/CleaveOligomer.cpp.o 
CMakeFiles/massxpert.dir/nongui/CleaveOptions.cpp.o 
CMakeFiles/massxpert.dir/nongui/CleaveRule.cpp.o 
CMakeFiles/massxpert.dir/nongui/CleaveSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/Cleaver.cpp.o 
CMakeFiles/massxpert.dir/nongui/ConfigSetting.cpp.o 
CMakeFiles/massxpert.dir/nongui/ConfigSettings.cpp.o 
CMakeFiles/massxpert.dir/nongui/Coordinates.cpp.o 
CMakeFiles/massxpert.dir/nongui/CrossLink.cpp.o 
CMakeFiles/massxpert.dir/nongui/CrossLinkList.cpp.o 
CMakeFiles/massxpert.dir/nongui/CrossLinkedRegion.cpp.o 
CMakeFiles/massxpert.dir/nongui/CrossLinker.cpp.o 
CMakeFiles/massxpert.dir/nongui/CrossLinkerSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/FragOptions.cpp.o 
CMakeFiles/massxpert.dir/nongui/FragRule.cpp.o 
CMakeFiles/massxpert.dir/nongui/FragSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/Fragmenter.cpp.o 
CMakeFiles/massxpert.dir/nongui/Ionizable.cpp.o 
CMakeFiles/massxpert.dir/nongui/Modif.cpp.o 
CMakeFiles/massxpert.dir/nongui/ModifSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/Monomer.cpp.o 
CMakeFiles/massxpert.dir/nongui/MonomerDictionary.cpp.o 
CMakeFiles/massxpert.dir/nongui/MonomerSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/Oligomer.cpp.o 
CMakeFiles/massxpert.dir/nongui/OligomerList.cpp.o 
CMakeFiles/massxpert.dir/nongui/OligomerPair.cpp.o 
CMakeFiles/massxpert.dir/nongui/PkaPhPi.cpp.o 
CMakeFiles/massxpert.dir/nongui/PkaPhPiDataParser.cpp.o 
CMakeFiles/massxpert.dir/nongui/PolChemDef.cpp.o 
CMakeFiles/massxpert.dir/nongui/PolChemDefCatParser.cpp.o 
CMakeFiles/massxpert.dir/nongui/PolChemDefEntity.cpp.o 
CMakeFiles/massxpert.dir/nongui/PolChemDefSpec.cpp.o 
CMakeFiles/massxpert.dir/nongui/Polymer.cpp.o 
CMakeFiles/massxpert.dir/nongui/Prop.cpp.o 
CMakeFiles/massxpert.dir/nongui/PropListHolder.cpp.o 
CMakeFiles/massxpert.dir/nongui/Sequence.cpp.o 
CMakeFiles/massxpert.dir/nongui/globals.cpp.o 
CMakeFiles/massxpert.dir/gui/AboutMassXpertDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/AbstractMainTaskWindow.cpp.o 
CMakeFiles/massxpert.dir/gui/AbstractPolChemDefDependentDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/AbstractSeqEdWndDependentDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/Application.cpp.o 
CMakeFiles/massxpert.dir/gui/AtomDefDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CalculatorChemPadDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CalculatorChemPadGroupBox.cpp.o 
CMakeFiles/massxpert.dir/gui/CalculatorRecorderDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CalculatorWnd.cpp.o 
CMakeFiles/massxpert.dir/gui/ChemPadButton.cpp.o 
CMakeFiles/massxpert.dir/gui/CleavageDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CleaveOligomerTableView.cpp.o 
CMakeFiles/massxpert.dir/gui/CleaveOligomerTableViewMimeData.cpp.o 
CMakeFiles/massxpert.dir/gui/CleaveOligomerTableViewModel.cpp.o 
CMakeFiles/massxpert.dir/gui/CleaveOligomerTableViewSortProxyModel.cpp.o 
CMakeFiles/massxpert.dir/gui/CleaveSpecDefDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CompositionTreeView.cpp.o 
CMakeFiles/massxpert.dir/gui/CompositionTreeViewItem.cpp.o 
CMakeFiles/massxpert.dir/gui/CompositionTreeViewModel.cpp.o 
CMakeFiles/massxpert.dir/gui/CompositionTreeViewSortProxyModel.cpp.o 
CMakeFiles/massxpert.dir/gui/CompositionsDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/ConfigSettingsDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/CrossLinkerDefDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/DecimalPlacesOptionsDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/FragSpecDefDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/FragmentOligomerTableView.cpp.o 
CMakeFiles/massxpert.dir/gui/FragmentOligomerTableViewMimeData.cpp.o 
CMakeFiles/massxpert.dir/gui/FragmentOligomerTableViewModel.cpp.o 
CMakeFiles/massxpert.dir/gui/FragmentOligomerTableViewSortProxyModel.cpp.o 
CMakeFiles/massxpert.dir/gui/FragmentationDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/MainWindow.cpp.o 
CMakeFiles/massxpert.dir/gui/MassListSorterDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/MassSearchDlg.cpp.o 
CMakeFiles/massxpert.dir/gui/MassSearchOligomerTableView.cpp.o 
CMakeFiles/massxpert.dir/gui/MassSearchOligomerTableViewMimeData.cpp.o 
CMakeFiles/massxpert.dir/gui/MassS

Bug#1024753: libvirtd doesn't run: "SCHED_CORE not supported by kernel"

[Salvatore Bonaccorso]

Control: reassign -1 src:libvirt 8.9.0-1

On Thu, Nov 24, 2022 at 10:10:49AM +0100, Philipp Marek wrote:
> Package: src:linux
> Version: 6.0.8-1
> Severity: important
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> 
> Sorry about the German messages.
> 
> libvirt version: 8.9.0, package: 1 (Andrea Bolognani 
> Sat, 19 Nov 2022 23:00:34 +0100)
> 
> Nicht unterstützte Konfiguration: SCHED_CORE not supported by kernel
> Initialisierung des QEMU Status-Treibers fehlgeschlagen: Nicht
> unterstützte Konfiguration: SCHED_CORE not supported by kernel
> Treiber Status Initialisierung fehlgeschlagen
> 
> My libvirt-daemon is 8.9.0-1; downgrading to 8.5.0-1 makes it work
> again, should the error be reported against that one,
> or does it make sense to recompile the kernel with that config?

Doing for now the reassignment to src:libvirt. In fact SCHED_CORE has
been disabled by default with upstream commit, d2343cb8d154
("sched/core: Disable CONFIG_SCHED_CORE by default"), in v5.14-rc1:

| commit d2343cb8d154fe20c4499711bb3a9af2095b2b4b
| Author: Ingo Molnar 
| Date:   Mon Jun 28 21:55:16 2021 +0200
| 
| sched/core: Disable CONFIG_SCHED_CORE by default
| 
| This option at minimum adds extra code to the scheduler - even if
| it's default unused - and most users wouldn't want it.
| 
| Reported-by: Linus Torvalds 
| Signed-off-by: Ingo Molnar 
| 
| diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
| index bd7c4147b9a8..5876e30c5740 100644
| --- a/kernel/Kconfig.preempt
| +++ b/kernel/Kconfig.preempt
| @@ -102,7 +102,6 @@ config PREEMPT_DYNAMIC
| 
|  config SCHED_CORE
|   bool "Core Scheduling for SMT"
| -   default y
|   depends on SCHED_SMT
|   help
| This option permits Core Scheduling, a means of coordinated task
| @@ -115,7 +114,8 @@ config SCHED_CORE
|  - mitigation of some (not all) SMT side channels;
|  - limiting SMT interference to improve determinism and/or 
performance.
| 
| - SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
| - unused there should be no impact on performance.
| + SCHED_CORE is default disabled. When it is enabled and unused,
| + which is the likely usage by Linux distributions, there should
| + be no measurable impact on performance.

I have not checked what other distributions do, but given the above it
looks to me that we are doing already the okayish thing for
distributions. Libvirt-maintainers, what is your take on it?

How is your /etc/libvirt/qemu.conf configured with respect to the
"sched_core" setting?

Regards,
Salvatore

Bug#1023550: transition: qcustomplot

[Sebastian Ramacher]

On 2022-11-24 21:05:07 +0100, Sebastian Ramacher wrote:
> Hi Filippo
> 
> On 2022-11-22 21:41:15 +0100, Filippo Rusconi wrote:
> > Greetings Sebastian,
> > 
> > On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote:
> > > Hi Filippo
> > > 
> > > On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote:
> > > > Greetings Sebastian,
> > > > 
> > > > Thank your for your message.
> > > > 
> > > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote:
> > > > > Control: tags -1 moreinfo
> > > > > Control: forwarded -1 
> > > > > https://release.debian.org/transitions/html/auto-qcustomplot.html
> > > > >
> > > > > Hi Filippo
> > > > >
> > > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote:
> > > > > > Package: release.debian.org
> > > > > > Severity: normal
> > > > > > User: release.debian@packages.debian.org
> > > > > > Usertags: transition
> > > > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
> > > > > > debian-science-maintain...@lists.alioth.debian.org
> > > > > >
> > > > > > (please explain about the transition: impacted packages, reason, ...
> > > > > >  for more info see: 
> > > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
> > > > > >
> > > > > > Greetings,
> > > > > >
> > > > > > Fundamental reason: Qt5 and Qt6 are in the archive.
> > > > > >
> > > > > > I am requesting a transition from package libqcustomplot2.0 to
> > > > > > libqcustomplot2.1. Source package is qcustomplot. The change 
> > > > > > involves a change
> > > > > > in the library name itself, from libqcustomplot2.0 to both 
> > > > > > libQCustomPlot2.1 and
> > > > > > libQCustomPlotQt6.so.2.1.0 (see below).
> > > > > >
> > > > > > I have prepared the packaging in the following git repos branch:
> > > > > >
> > > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6
> > > > 
> > > > [...]
> > > > 
> > > > > > For the libs under my control, the transition is already prepared 
> > > > > > and these
> > > > > > projects are going to be linking against the Qt6-built library, 
> > > > > > contrary to all
> > > > > > the other packages detailed below.
> > > > > >
> > > > > > For the other libs listed above, I have already checked that they 
> > > > > > would build if
> > > > > > some modifications were performed. I have already git branches 
> > > > > > ready for the
> > > > > > packages under git VCS. For the others (source deb), I have patches 
> > > > > > available.
> > > > > >
> > > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot 
> > > > > > for many and
> > > > > > also sometimes use the CMake-based configuration involving first
> > > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot 
> > > > > > formalism for
> > > > > > the linker.
> > > > > >
> > > > > > That is: almost one- or two-liner patches.
> > > > >
> > > > > Could you please file bugs for those so that maintainers are aware?
> > > > 
> > > > Yes, I'll do that. I have already informed them individually of the 
> > > > process and
> > > > provided them with the relevant patch.
> > > 
> > > Thanks! Please go ahead with the transition.
> > 
> > I just uploaded the package to unstable. I have not closed the bug yet, 
> > waiting
> > to check that everything goes fine.
> 
> qcustomplot's autopkgtests are failing. Could you please take a look at
> them? Thanks

And from
https://buildd.debian.org/status/fetch.php?pkg=libpappsomspp&arch=amd64&ver=0.8.60-1%2Bb1&stamp=1669195336&raw=0
it looks like libqcustomplot-dev is missing a dependency on qtbase5-dev.

Cheers
-- 
Sebastian Ramacher

Bug#1023535: transition: protobuf

[Sebastiaan Couwenberg]

On 11/24/22 21:03, Sebastian Ramacher wrote:

protobuf's autopkgtests are failing. Could you please take a look at
them? Thanks


Patch available in: https://bugs.debian.org/1024677

Kind Regards,

Bas

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

Bug#1024756: transition: libktorrent

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Aurélien

On 2022-11-24 11:05:08 +0100, Aurélien COUDERC wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: Debian Qt/KDE Maintainers 
> 
> Dear Release Team,
> 
> I’d like to request a transition slot for libktorrent.
> 
> It has 2 reverse dependencies:
> - kget
> - ktorrent
> 
> Both rebuild successfully with the new version of the library.
> 
> I’ve uploaded libktorrent 22.08.3-3 with the new ABI to experimental and
> it builds successfully on the same architectures as previously. [0]

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1024781: python-molotov: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: python-molotov
Version: 2.1-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-molotov fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-molotov from testing2.1-4
all others from testingfrom testing

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

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be 
updated. E.g.:

"""
Removed the @asyncio.coroutine() decorator enabling legacy 
generator-based coroutines to be compatible with async / await code. The 
function has been deprecated since Python 3.8 and the removal was 
initially scheduled for Python 3.10. Use async def instead. (Contributed 
by Illia Volochii in bpo-43216.)

"""

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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-molotov/28600688/log.gz

=== FAILURES 
===
 TestUtil.test_can_call 



args = (,), kw 
= {}


@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
 TestFmwk.test_aworker 
_


args = (,), kw 
= {}


@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
_ TestFmwk.test_aworker_noexc 
__


args = (,)
kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
__ TestFmwk.test_failing_step 
__


args = (,)
kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
 TestFmwk.test_failure 
_


args = (,), kw 
= {}


@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
_ TestFmwk.test_picker 
_


args = (,), kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
___ TestFmwk.test_session_shutdown_exception 
___


args = (testMethod=test_session_shutdown_exception>,)

kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
 TestFmwk.test_setup_session_fresh_loop 



args = (testMethod=test_setup_session_fresh_loop>,)

kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
__ TestFmwk.test_step 
__


args = (,), kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

  cofunc = asyncio.coroutine(func)

E   AttributeError: module 'asyncio' has no attribute 'coroutine'

molotov/tests/support.py:242: AttributeError
___ TestListeners.test_add_listener 



args = (testMethod=test_add_listener>,)

kw = {}

@functools.wraps(func)
def _async_test(*args, **kw):

Bug#1024782: Doesn't run tests as part of of the build

[Sebastien Bacher]

Package: libcamera
Version: 0.0.1-4

I'm working on getting libcamera promoted to main in Ubuntu, one of the 
requirements is to have tests (build and autopkgtest). The package 
currently override the dh_auto_test target to ignore those, it seems an 
old change and isn't really documented and I'm wondering if the rational 
still stands? Having tests as part of the build (and as autopkgtests) 
would also benefit Debian.


I'm attaching a trivial patch to enable the tests as part of the build. 
Doing that on Ubuntu is leading to 3 failures (seems to be due to the 
env, it fails on the builders or in a pbuilder env but not in a lxc 
container) so that's an issue to sort out before uploading.


I've reported the issue upstream on 
https://bugs.libcamera.org/show_bug.cgi?id=173 as a start point. I will 
update the report once there is a fix (or maybe skip those 3 tests to 
start?)


Cheers,

diff -Nru libcamera-0.0.1/debian/changelog libcamera-0.0.1/debian/changelog
--- libcamera-0.0.1/debian/changelog	2022-10-26 18:44:01.0 +0200
+++ libcamera-0.0.1/debian/changelog	2022-11-24 21:33:29.0 +0100
@@ -1,3 +1,9 @@
+libcamera (0.0.1-5) UNRELEASED; urgency=medium
+
+  * debian/rules: enable the upstream tests as part of the build
+
+ -- Sebastien Bacher   Thu, 24 Nov 2022 21:33:29 +0100
+
 libcamera (0.0.1-4) unstable; urgency=medium
 
   * Mark liblttng-ust-dev and libudev-dev as linux-only, add more optional
diff -Nru libcamera-0.0.1/debian/.gitignore libcamera-0.0.1/debian/.gitignore
--- libcamera-0.0.1/debian/.gitignore	2022-10-26 18:44:01.0 +0200
+++ libcamera-0.0.1/debian/.gitignore	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-!patches/
-!*.patch
diff -Nru libcamera-0.0.1/debian/rules libcamera-0.0.1/debian/rules
--- libcamera-0.0.1/debian/rules	2022-10-26 18:44:01.0 +0200
+++ libcamera-0.0.1/debian/rules	2022-11-24 21:33:13.0 +0100
@@ -13,16 +13,13 @@
 	dh_auto_configure -- \
 		--libexecdir=lib/${DEB_HOST_MULTIARCH} \
 		-Dv4l2=true \
+		-Dtest=true \
 		$(empty)
 
 override_dh_install:
 	mv debian/tmp/usr/share/doc/libcamera-0.* debian/tmp/usr/share/doc/libcamera-doc
 	dh_install -X/.doctrees/
 
-.PHONY: override_dh_auto_test
-override_dh_auto_test:
-
-
 .PHONY: licensecheck
 licensecheck:
 	licensecheck --deb-machine -r * \

Bug#1024783: ironic: (autopkgtest) needs update for python3.11: Cannot spec a Mock object

[Paul Gevers]

Source: ironic
Version: 1:21.1.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
ironic fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
ironic from testing1:21.1.0-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/s390x/i/ironic/28630776/log.gz

==
FAIL: 
ironic.tests.unit.drivers.modules.irmc.test_inspect.IRMCInspectTestCase.test_inspect_hardware

ironic.tests.unit.drivers.modules.irmc.test_inspect.IRMCInspectTestCase.test_inspect_hardware
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):

  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.xfyi6n2m/downtmp/build.Dl6/src/ironic/tests/unit/drivers/modules/irmc/test_inspect.py", 
line 207, in test_inspect_hardware

new_port_mock1 = mock.MagicMock(spec=objects.Port)
 ^
  File "/usr/lib/python3.11/unittest/mock.py", line 2082, in __init__
_safe_super(MagicMixin, self).__init__(*args, **kw)
  File "/usr/lib/python3.11/unittest/mock.py", line 1100, in __init__
_safe_super(CallableMixin, self).__init__(
  File "/usr/lib/python3.11/unittest/mock.py", line 451, in __init__
self._mock_add_spec(spec, spec_set, _spec_as_instance, _eat_self)
  File "/usr/lib/python3.11/unittest/mock.py", line 502, in _mock_add_spec
raise InvalidSpecError(f'Cannot spec a Mock object. [object={spec!r}]')
unittest.mock.InvalidSpecError: Cannot spec a Mock object. 
[object=]



==
FAIL: 
ironic.tests.unit.drivers.modules.irmc.test_inspect.IRMCInspectTestCase.test_inspect_hardware_with_power_off

ironic.tests.unit.drivers.modules.irmc.test_inspect.IRMCInspectTestCase.test_inspect_hardware_with_power_off
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):

  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.xfyi6n2m/downtmp/build.Dl6/src/ironic/tests/unit/drivers/modules/irmc/test_inspect.py", 
line 262, in test_inspect_hardware_with_power_off

new_port_mock1 = mock.MagicMock(spec=objects.Port)
 ^
  File "/usr/lib/python3.11/unittest/mock.py", line 2082, in __init__
_safe_super(MagicMixin, self).__init__(*args, **kw)
  File "/usr/lib/python3.11/unittest/mock.py", line 1100, in __init__
_safe_super(CallableMixin, self).__init__(
  File "/usr/lib/python3.11/unittest/mock.py", line 451, in __init__
self._mock_add_spec(spec, spec_set, _spec_as_instance, _eat_self)
  File "/usr/lib/python3.11/unittest/mock.py", line 502, in _mock_add_spec
raise InvalidSpecError(f'Cannot spec a Mock object. [object={spec!r}]')
unittest.mock.InvalidSpecError: Cannot spec a Mock object. 
[object=]



--
Ran 8768 tests in 240.038s

FAILED (failures=2, skipped=44)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024784: swift: (autopkgtest) needs update for python3.11: Segmentation fault

[Paul Gevers]

Source: swift
Version: 2.30.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
swift fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
swift  from testing2.30.0-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/s390x/s/swift/28606516/log.gz

+ py3versions -vr
+ python3.11 -m nose test/unit -v 
--exclude-test=test.unit.common.test_utils.TestUtils.test_get_logger_sysloghandler_plumbing 
--exclude-test=test.unit.common.middleware.test_cname_lookup.TestCNAMELookup 
--exclude-test=test.unit.common.test_db.TestDatabaseBroker.test_get 
--exclude-test=test.unit.container.test_sync.TestContainerSync.test_init 
--exclude-test=test.unit.common.test_utils.TestPunchHoleReally.test_punch_a_hole 
--exclude-test=test.unit.common.test_utils.Test_LibcWrapper.test_argument_plumbing

nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$']
nose.plugins.xcover: INFO: Coverage report will include only packages: 
['swift']
nose.plugins.cover: INFO: Coverage report will include only packages: 
['swift']

Unable to read test config /etc/swift/test.conf - file not found
test_db_validate_fails 
(test.unit.account.test_auditor.TestAuditorRealBroker.test_db_validate_fails) 
... Segmentation fault

autopkgtest [14:04:13]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024625: cmake-data: FindPython.cmake points to newest Python version, not the default

[Timo Röhling]

Hi Andrius,

* Andrius Merkys  [2022-11-24 13:25]:

find_package(Python 3.6 REQUIRED COMPONENTS Interpreter Development)

However, CMake output is the following:

-- Found Python: /usr/bin/python3.11 (found suitable version "3.11.0", 
minimum required is "3.6") found components: Interpreter Development 
Development.Module Development.Embed

It took me a while, but I found the problem: starting with version
3.15, CMake introduced a new search strategy, so my tests with

cmake_minimum_required(VERSION 3.25)

worked fine, but as soon as you go below 3.15 it breaks again.
I'll upload a fix shortly.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1024785: supysonic: (autopkgtest) needs update for python3.11: DecompileError: Unsupported operation

[Paul Gevers]

Source: supysonic
Version: 0.7.2+ds-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
supysonic fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
supysonic  from testing0.7.2+ds-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/armel/s/supysonic/28609595/log.gz

==
ERROR: test_get_album_list 
(tests.api.test_album_songs.AlbumSongsTestCase.test_get_album_list)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.umijt0w4/downtmp/autopkgtest_tmp/tests/api/test_album_songs.py", 
line 61, in test_get_album_list

self._make_request("getAlbumList", {"type": "kraken"}, error=0)
  File 
"/tmp/autopkgtest-lxc.umijt0w4/downtmp/autopkgtest_tmp/tests/api/apitestbase.py", 
line 74, in _make_request

rg = self.client.get(uri, query_string=args)
 ^^^
  File "/usr/lib/python3/dist-packages/werkzeug/test.py", line 1129, in get
return self.open(*args, **kw)
   ^^
  File "/usr/lib/python3/dist-packages/flask/testing.py", line 235, in open
return super().open(
   ^
  File "/usr/lib/python3/dist-packages/werkzeug/test.py", line 1074, in 
open

response = self.run_wsgi_app(request.environ, buffered=buffered)
   ^
  File "/usr/lib/python3/dist-packages/werkzeug/test.py", line 945, in 
run_wsgi_app

rv = run_wsgi_app(self.application, environ, buffered=buffered)
 ^^
  File "/usr/lib/python3/dist-packages/werkzeug/test.py", line 1231, in 
run_wsgi_app

app_rv = app(environ, start_response)
 
  File "/usr/lib/python3/dist-packages/flask/app.py", line 2091, in 
__call__

return self.wsgi_app(environ, start_response)
   ^^
  File "/usr/lib/python3/dist-packages/pony/utils/utils.py", line 35, 
in pony_wrapper

return caller(func, *args, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/pony/orm/core.py", line 519, in 
new_func

result = func(*args, **kwargs)
 ^
  File "/usr/lib/python3/dist-packages/flask/app.py", line 2076, in 
wsgi_app

response = self.handle_exception(e)
   
  File "/usr/lib/python3/dist-packages/flask/app.py", line 2073, in 
wsgi_app

response = self.full_dispatch_request()
   
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1518, in 
full_dispatch_request

rv = self.handle_user_exception(e)
 ^
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1516, in 
full_dispatch_request

rv = self.dispatch_request()
 ^^^
  File "/usr/lib/python3/dist-packages/flask/app.py", line 1502, in 
dispatch_request
return 
self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)


^
  File "/usr/lib/python3/dist-packages/supysonic/api/albums_songs.py", 
line 77, in album_list

query = select(t.folder for t in Track)
^^^
  File "/usr/lib/python3/dist-packages/pony/orm/core.py", line 5560, in 
select

return make_query(args, frame_depth=cut_traceback_depth+1)
   ^^^
  File "/usr/lib/python3/dist-packages/pony/orm/core.py", line 5546, in 
make_query

tree, external_names, cells = decompile(gen)
  ^^
  File "/usr/lib/python3/dist-packages/pony/orm/decompiling.py", l

Bug#1024786: aionotify: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: aionotify
Version: 0.2.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
aionotify fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
aionotify  from testing0.2.0-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be 
updated. E.g.:

"""
Removed the @asyncio.coroutine() decorator enabling legacy 
generator-based coroutines to be compatible with async / await code. The 
function has been deprecated since Python 3.8 and the removal was 
initially scheduled for Python 3.10. Use async def instead. (Contributed 
by Illia Volochii in bpo-43216.)

"""

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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/a/aionotify/28628638/log.gz

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/aionotify/__init__.py", line 5, 
in 

from .base import Watcher
  File "/usr/lib/python3/dist-packages/aionotify/base.py", line 10, in 


from . import aioutils
  File "/usr/lib/python3/dist-packages/aionotify/aioutils.py", line 
122, in 

@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you 
mean: 'coroutines'?

autopkgtest [12:13:03]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023550: transition: qcustomplot

[Filippo Rusconi]

Greetings Sebastian,

On Thu, Nov 24, 2022 at 09:05:07PM +0100, Sebastian Ramacher wrote:

Hi Filippo


[...]


> Thanks! Please go ahead with the transition.

I just uploaded the package to unstable. I have not closed the bug yet, waiting
to check that everything goes fine.


qcustomplot's autopkgtests are failing. Could you please take a look at
them? Thanks


It is weeks that I monitor the salsa stuff, but I do not understand what these
tests mean. One example (bear with me):

CMake Error at CMakeLists.txt:5 (FIND_PACKAGE):
  By not providing "FindQt5PrintSupport.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "Qt5PrintSupport", but CMake did not find one.
  Could not find a package configuration file provided by "Qt5PrintSupport"
  with any of the following names:
Qt5PrintSupportConfig.cmake
qt5printsupport-config.cmake

debian/control
--

Build-Depends: 
 debhelper (>= 13),

 cmake (>= 3.18),
 qtbase5-dev (>= 5.12),
 qt6-base-dev (>= 6.2.0)

% apt-file search Qt5PrintSupportConfig.cmake
qtbase5-dev: 
/usr/lib/x86_64-linux-gnu/cmake/Qt5PrintSupport/Qt5PrintSupportConfig.cmake

So, I do not understand why the autopkgtest does not do the right thing: install
the packages I have listed in Build-Depends...

I always build my packages with cowbuilder (gbp buildpackage) in a pristine
enviroment...  Further, how can that be that the build passes and then the build
of autopkgtest fails?

I'd be happy to learn more about all this, but for the moment these 
inconsistencies make me dubitative...

Sincerely,
Filippo 


--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#1024770: libpcsclite1: multi-arch installation not possible

[Ludovic Rousseau]

Hello,

Le 24/11/2022 à 16:07, Stephan Brunner a écrit :

Package: libpcsclite1
Version: 1.9.1-1
Severity: minor

When trying to install libpcsclite-dev, and therefore libpcsclite1, via 
multi-arch (host is x86-64), e.g.
apt install libpcsclite-dev libpcsclite-dev:arm64
, the installation would break the system. See the output below.

I wanted to install this package to my build host, which does cross compilation 
for some architectures in an CI environment.
I am using Debian 11 on x86-64.
Latest updates installed as of 2022-11-24.

Example output of the apt install example above:
   Reading package lists... Done
   Building dependency tree... Done
   Reading state information... Done
   The following packages were automatically installed and are no longer 
required:
 distro-info-data iso-codes libffi-dev libmpdec3 libncurses-dev libpfm4 
libpython3-stdlib libpython3.9-minimal libpython3.9-stdlib libtinfo-dev 
libz3-dev llvm-11 llvm-11-runtime lsb-release
   python-apt-common python3-certifi
 python3-chardet python3-debconf python3-debian python3-httplib2 
python3-idna python3-pkg-resources python3-pygments python3-requests 
python3-six python3-urllib3
   Use 'apt autoremove' to remove them.
   The following additional packages will be installed:
 libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 
libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 
libpcsclite1:arm64 libpython3-stdlib:arm64 libpython3.9-
   minimal:arm64 libpython3.9-stdlib:arm64
 libreadline8:arm64 libsqlite3-0:arm64 libstdc++6:arm64 libtinfo6:arm64 
libuuid1:arm64 python3:arm64 python3-minimal:arm64 python3.9:arm64 
python3.9-minimal:arm64 uuid-runtime zlib1g:arm64
   Suggested packages:
 gpm:arm64 pcscd:arm64 python3-doc:arm64 python3-tk:arm64 
python3-venv:arm64 python3.9-venv:arm64 python3.9-doc:arm64 binutils:arm64
   The following packages will be REMOVED:
 apt-listchanges llvm-11-dev llvm-11-tools python3 python3-apt 
python3-debianbts python3-minimal python3-pycurl python3-pysimplesoap 
python3-reportbug python3-yaml python3.9 python3.9-minimal
   reportbug
   The following NEW packages will be installed:
 libbz2-1.0:arm64 libdb5.3:arm64 libexpat1:arm64 libffi7:arm64 
libgpm2:arm64 liblzma5:arm64 libmpdec3:arm64 libncursesw6:arm64 
libpcsclite-dev:arm64 libpcsclite1:arm64 libpython3-stdlib:arm64
   libpython3.9-minimal:arm64
 libpython3.9-stdlib:arm64 libreadline8:arm64 libsqlite3-0:arm64 
libstdc++6:arm64 libtinfo6:arm64 libuuid1:arm64 python3:arm64 
python3-minimal:arm64 python3.9:arm64 python3.9-minimal:arm64
   uuid-runtime zlib1g:arm64
   0 upgraded, 24 newly installed, 14 to remove and 0 not upgraded.
   Need to get 8,185 kB of archives.
   After this operation, 202 MB disk space will be freed.
   Do you want to continue? [Y/n] ^C



libpcsclite-dev includes a Python 3 script: pcsc-spy. Hence the dependency on 
python3.
Since it is a Recommends: and not a Depends: you should be able to install 
libpcsclite-dev:arm64 even if the dependency is not satisfied.

But you will then have another problem since libpcsclite-dev and 
libpcsclite-dev:arm64 will both try to install the same files:
/usr/bin/pcsc-spy
/usr/include/PCSC/debuglog.h
/usr/include/PCSC/ifdhandler.h
/usr/include/PCSC/pcsclite.h
/usr/include/PCSC/reader.h
/usr/include/PCSC/winscard.h
/usr/include/PCSC/wintypes.h
/usr/share/man/man1/pcsc-spy.1.gz

How do you propose to fix that?

Bye

--
Dr. Ludovic Rousseau

Bug#1024787: python3-setuptools-gettext: error in package description

[Daniele Forsi]

Package: python3-setuptools-gettext
Severity: normal
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the package description says that this program "compiles them to .po files and 
installs them."
but actually it compiles to .mo files.

thanks,
Daniele

Bug#1012950: itk-4.y buildability status

[Étienne Mollier]

Control: severity 1012950 important
Control: tags 1012950 - pending

Hi, I reduce the severity of ITK4 ftbfs with introduction of
gcc-12, since the package in its current form now uses gcc-11
only, and thus builds through.  I also remove the tag pending
upload since the initial problem is still unresolved.

If I made a mistake by reducing the severity, feel free to
re-raise it.  I don't expect to push much further for ITK4.

In hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Genesis - White Mountain


signature.asc
Description: PGP signature

Bug#1024788: ITP: setuptools-protobuf -- protocol buffer compilation for setuptools

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: setuptools-protobuf
  Version : 0.1.3
  Upstream Author : Jelmer Vernooij 
* URL : https://github.com/jelmer/setuptools-protobuf
* License : Apachev2
  Programming Lang: Python
  Description : protocol buffer compilation for setuptools

 Plugin for setuptools that adds support for compiling protobuf files.
 .
 It can optionally also generate mypy interface files if mypy-protobuf is
 present.

Bug#1022307: status on t_coffee causing biopython ftbfs

[Étienne Mollier]

Hi Nilesh,

Nilesh Patra, on 2022-11-23:
> On Wed, 23 Nov 2022 15:07:32 +0200 Andrius Merkys  wrote:
> > On Tue, 22 Nov 2022 23:54:48 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
> >  wrote:
> > > Hi, mostly retitling the open entry against biopython for the
> > > sake of clarity, and also pinging both bugs to reset auto-
> > > removal counters.  We don't have much news from t_coffee
> > > upstream to day unfortunately.  Maybe it will be necessary to
> > > revert the t-coffee version bump for the upcoming Debian release
> > > or do people see other options?
> > 
> > This issue is blocking Python 3.11-add transition, but we surely do not 
> > want biopython to be dropped from testing. However, the problem is not 
> > with biopython, but with t-coffee which biopython merely uses for tests. 
> > Would it be acceptable to skip t-coffee tests for now thus unblocking 
> > Python 3.11-add transition?
> > This bug report should remain open to remind 
> > us bring t-coffee tests back once #1022570 is solved.
> 
> That sounds quite a reasonable thing to do, but we probably should also
> decrese the severity of this bug to "important" to let biopython be in testing
> once the corresponding tests are skipped.
> 
> Étienne, what do you think?

I removed the build-dependency on t-coffee for the experimental
upload of biopython 1.80 in order to get tests to go through.
This skips the faulty test in biopython.  t-coffee merely
enhances biopython, and I don't believe it would impede the
overall usability of the module.

It will be possible to reduce the severity of the bug once one
migrates python-biopython to sid.  If in the meantime t-coffee
gets fixed or reverted, then we could even restore the tests and
close the bug.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Supertramp - Even in the Quietest Moments


signature.asc
Description: PGP signature

Bug#1023005: A recent Bookworm upgrade broke video playback in the VLC player

[Bernhard Übelacker]

Hello Everyone,
I guess I see a similar same issue here.

First, for me works as a workaround if I click the slider somewhere
in the middle of the video and do pause it, then close vlc completely.
The next attempt to start the video with vlc works for me.
(Like after a reboot the very first video does also play correctly.)

Does someone seeing this issue can confirm this?


While writing this mail I saw some mails got also sent to bug 1023580,
which got some more information, and got a new Qt build.
So I guess I will wait when that drops into testing
and how it works then.

Kind regards,
Bernhard


$ inxi
CPU: 8-core AMD Ryzen 7 1700 (-MT MCP-) speed/min/max: 1442/1550/3000 MHz
Kernel: 6.0.0-4-amd64 x86_64 Up: 1d 6h 3m
$ inxi -G
Graphics:
  Device-1: AMD Baffin [Radeon RX 460/560D / Pro
450/455/460/555/555X/560/560X] driver: amdgpu v: kernel
  Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
resolution: 1: 1280x1024 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.2.4 renderer: AMD Radeon RX 460 Graphics
(polaris11 LLVM 15.0.5 DRM 3.48 6.0.0-4-amd64)

Bug#1023005: A recent Bookworm upgrade broke video playback in the VLC player

[Alexis Murzeau]

Hi,

On 24/11/2022 23:13, Bernhard Übelacker wrote:

Hello Everyone,
I guess I see a similar same issue here.

First, for me works as a workaround if I click the slider somewhere
in the middle of the video and do pause it, then close vlc completely.
The next attempt to start the video with vlc works for me.
(Like after a reboot the very first video does also play correctly.)

Does someone seeing this issue can confirm this?


While writing this mail I saw some mails got also sent to bug 1023580,
which got some more information, and got a new Qt build.
So I guess I will wait when that drops into testing
and how it works then.

Kind regards,
Bernhard


For me, opening a video with a double click that would open VLC and start
playback was working. The problem appeared once I stopped the player, or
when opening VLC directly.


But yes, a Qt package upload was done by Dmitry Shachnev on unstable today
and I can confirm that Qt5 5.15.6+dfsg-4 fixes the VLC black screen issue for
me. No more video playback issues.

So this bug is possibly fixed with Qt5 5.15.6+dfsg-4, to be confirmed by
you and others when you have the opportunity to upgrade Qt (libqt5*
packages).

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1024789: xdg-utils: xdg-screensaver does not work on recent GNOME, and I have a fix

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.3-4.1ubuntu3~22.04.1
Severity: important
Tags: patch upstream

I’m the upstream maintainer of Caffeine, and noticed that it was no longer
working on my GNOME 42 system.

Of course, the actual bug was in xdg-screensaver: until recently,
gnome-screensaver ran on GNOME systems, and xdg-screensaver used that. Now,
it needs to use the freedesktop DBus API.

Unfortunately, the freedesktop-related code in xdg-screensaver was also
buggy (at least, it didn’t match the DBus API spec).

Fortunately, the fix was easy, as the code used to handle gnome-screensaver
can. with small modifications, be used for a correct implementation.

I have provided the fix as a Merge Request to xdg-utils:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/62

I am filing this bug report because I know that xdg-utils upstream is slow
(Debian already has a patch of mine in its packaging from 2016).

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=GNOME

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.31-1
ii  libnet-dbus-perl   1.2.0-1build3
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5build2
ii  x11-xserver-utils  7.7+9build1

xdg-utils suggests no packages.

-- no debconf information

Bug#1024782: Doesn't run tests as part of of the build

[Kieran Bingham]

Hi Sebastien,

Quoting Sebastien Bacher (2022-11-24 20:41:37)
> Package: libcamera
> Version: 0.0.1-4
> 
> I'm working on getting libcamera promoted to main in Ubuntu, one of the 
> requirements is to have tests (build and autopkgtest). The package 
> currently override the dh_auto_test target to ignore those, it seems an 
> old change and isn't really documented and I'm wondering if the rational 
> still stands? Having tests as part of the build (and as autopkgtests) 
> would also benefit Debian.
> 
> I'm attaching a trivial patch to enable the tests as part of the build. 
> Doing that on Ubuntu is leading to 3 failures (seems to be due to the 
> env, it fails on the builders or in a pbuilder env but not in a lxc 
> container) so that's an issue to sort out before uploading.

I expect it was related to this

  https://patchwork.libcamera.org/patch/9330/

--
Kieran


> I've reported the issue upstream on 
> https://bugs.libcamera.org/show_bug.cgi?id=173 as a start point. I will 
> update the report once there is a fix (or maybe skip those 3 tests to 
> start?)
> 
> Cheers,
>

Bug#1024790: ortools: FTBFS everywhere

[Sebastian Ramacher]

Source: ortools
Version: 8.2+ds-6
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ortools&arch=amd64&ver=8.2%2Bds-6%2Bb2&stamp=1669159851&raw=0

make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make  -f 
ortools/sat/python/CMakeFiles/pywrapsat_swig_compilation.dir/build.make 
ortools/sat/python/CMakeFiles/pywrapsat_swig_compilation.dir/build
[  4%] Generate C++ protocol buffer for ortools/sat/cp_model.proto
/usr/bin/protoc --proto_path=/<> --proto_path=/usr/include 
--cpp_out=/<>/obj-x86_64-linux-gnu ortools/sat/cp_model.proto
make[4]: Entering directory '/<>/obj-x86_64-linux-gnu'
[  5%] Swig compile sat.i for python
cd /<>/obj-x86_64-linux-gnu/ortools/sat/python && /usr/bin/cmake 
-E make_directory 
/<>/obj-x86_64-linux-gnu/ortools/sat/python/CMakeFiles/pywrapsat.dir
 /<>/obj-x86_64-linux-gnu/python/ortools/sat 
/<>/obj-x86_64-linux-gnu/python/ortools/sat
cd /<>/obj-x86_64-linux-gnu/ortools/sat/python && /usr/bin/cmake 
-E touch 
/<>/obj-x86_64-linux-gnu/ortools/sat/python/CMakeFiles/pywrapsat.dir/satPYTHON.stamp
/<>/ortools/linear_solver/linear_solver.h:766: Error: Syntax error 
in input(3).
make[4]: *** 
[ortools/linear_solver/python/CMakeFiles/pywraplp_swig_compilation.dir/build.make:79:
 
ortools/linear_solver/python/CMakeFiles/pywraplp.dir/linear_solverPYTHON.stamp] 
Error 1
make[4]: *** Deleting file 
'ortools/linear_solver/python/CMakeFiles/pywraplp.dir/linear_solverPYTHON.stamp'
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[3]: *** [CMakeFiles/Makefile2:1400: 
ortools/linear_solver/python/CMakeFiles/pywraplp_swig_compilation.dir/all] 
Error 2
make[3]: *** Waiting for unfinished jobs

Cheers
-- 
Sebastian Ramacher

Bug#1024791: libhsa-runtime64-1: libhsa-amd-aqlprofile64.so warning

[Cordell Bloor]

Package: libhsa-runtime64-1
Version: 5.2.3-1
Severity: minor
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

During the initialization of libhsa-runtime64, the library will attempt
to load libhsa-amd-aqlprofile64.so. The aqlprofile library is an
optional proprietary extension for profiling and is therefore not
available in the Debian repos. The failure to find this library results
in the warning:

LoadLib(libhsa-amd-aqlprofile64.so) failed: libhsa-amd-aqlprofile64.so: 
cannot open shared object file: No such file or directory

There is not actually anything wrong or unexpected with this file being
missing, so this warning is not appropriate.

I would suggest that the attempt to load the aqlprofile extension be
removed until there is an open-source package available. This can be
done by deleting some code in src/core/runtime/amd_gpu_agent.cpp:

https://salsa.debian.org/rocm-team/rocr-runtime/-/blob/debian%2F5.2.3-1/src/core/runtime/amd_gpu_agent.cpp#L887-891

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libhsa-runtime64-1 depends on:
ii  libc6   2.36-5
ii  libelf1 0.188-1
ii  libgcc-s1   12.2.0-9
ii  libhsakmt1  5.2.3+dfsg-1
ii  libstdc++6  12.2.0-9

libhsa-runtime64-1 recommends no packages.

libhsa-runtime64-1 suggests no packages.

-- no debconf information

Bug#1024536: git-crecord: fails on committing/stagin

[Christoph Anton Mitterer]

Hey Andrej

On Mon, 2022-11-21 at 08:42 +0100, Andrej Shadura wrote:
> Can you try these things please:
> 1) Try the latest Git version

That's a bit difficult right now in my setup.

> 2) If it still fails, run with --debug, it’s going to print the patch
> 3) If possible, send me your working tree so that I can try it out


Could you possibly try this:

$ git init foo
Initialized empty Git repository in /home/calestyo/foo/.git/
$ cd foo/

$ touch bar
$ git add bar 
$ git commit -m 'foo'
[master (root-commit) 157defb] foo
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar
$ printf 'a\nb\nc\n' >| bar

$ git crecord

Now here, I first unselect all, and then select only one single line,
e.g. the "b" line, like so:
[~]diff --git a/bar b/bar
   index e69de29..de98044 100644
   1 hunks, 3 lines changed

   [~] @@ -0,0 +1,3 @@
  [ ]  +a
  [x]  +b
  [ ]  +c

if I now "c" or "s", I get:
error: corrupt patch at line 9
On branch master
nothing to commit, working tree clean
abort: commit failed: git exited with status 1


In principle it's the same as what I did with the other repo, but maybe
that's another issue, though... cause the error message is different.


Thanks,
Chris.