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

[Petter Reinholdtsen]

Control: severity -1 wishlist

It is clear that there is no concensus on this issue.  It is not a
technical problem with the code, but a question of opinions.  Because of
this, I set severity to wishlist.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1010001: libbiosig3: incorrect sample rate when reading IBW files

[Andreas Tille]

Control: tags -1 wontfix

As mentioned in my previous response we can not fix issues in stable.
Leaving this bug open anyway to document the issue.
There was no request for an upload to backports yet.

Kind regards, Andreas.

-- 
http://fam-tille.de

Bug#1022469: python-pint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Stuart Prescott]

Hi Michael


On 04/12/2022 03:50, Michael Banck wrote:
[...]

Looks like they got a work-around here in (since closed) PR #1401:
https://github.com/hgrecco/pint/commit/eb4e13428a3ede09148b76c71bc5b8cddb169176.patch


I was somewhat concerned that upstream abandoned that work rather than 
merging it. I have a feeling all it does is fix the test failure without 
actually fixing the underlying problems.



If I stick this (also attached) patch in, the testsuite passes fine.


I don't think it's enough for users of pint like superqt, however. The 
superqt test suite's failures seem to need a newer pin to pick up other 
compatibility changes with babel.


 8<  8< 

_ ERROR collecting 
.pybuild/cpython3_3.11_superqt/build/tests/test_quantity.py _

/usr/lib/python3/dist-packages/pint/registry.py:575: in load_definitions
rbytes = importlib.resources.read_binary(__package__, file)
/usr/lib/python3.11/importlib/resources/_legacy.py:18: in wrapper
warnings.warn(
E   DeprecationWarning: read_binary is deprecated. Use files() instead. 
Refer to https://importlib-resource
s.readthedocs.io/en/latest/using.html#migrating-from-legacy for 
migration advice.


During handling of the above exception, another exception occurred:
tests/test_quantity.py:3: in 
from superqt import QQuantity
:1231: in _handle_fromlist
???
superqt/__init__.py:51: in __getattr__
from .spinbox._quantity import QQuantity
superqt/spinbox/_quantity.py:21: in 
UREG = UnitRegistry()
/usr/lib/python3/dist-packages/pint/registry.py:143: in __call__
obj._after_init()
/usr/lib/python3/dist-packages/pint/registry.py:1976: in _after_init
super()._after_init()
/usr/lib/python3/dist-packages/pint/registry.py:305: in _after_init
self.load_definitions("default_en.txt", True)
/usr/lib/python3/dist-packages/pint/registry.py:588: in load_definitions
raise ValueError("While opening {}\n{}".format(file, msg))
E   ValueError: While opening default_en.txt
E   read_binary is deprecated. Use files() instead. Refer to 
https://importlib-resources.readthedocs.io/en/

latest/using.html#migrating-from-legacy for migration advice.

 8<  8< 

cheers
Stuart

--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1025405: UDD: how-can-i-help.json.gz - kbtin testing-autorm also lists colorized-logs binary but kbtin in testing has no colorized-logs binary

[Paul Wise]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

The listing of the kbtin testing-autorm also lists the colorized-logs
binary package but kbtin in testing has no colorized-logs binary since
it was split out of the kbtin source between stretch and buster.

Looking at the code, I am guessing this is because the script extracts
all binary packages from the database regardless of source version.

So the solution is probably to query just the binary packages in
testing for the testing-autorm check and just the binary packages in
unstable for the no-testing check and similar for other checks.

$ curl -s https://udd.debian.org/how-can-i-help.json.gz | zcat | jq '.[] | 
select(.source=="kbtin")'
{
  "type": "testing-autorm",
  "hash": "33c26617f7b9ebd82a87625b33bfa9de",
  "source": "kbtin",
  "packages": [
"kbtin",
"colorized-logs"
  ],
  "removal_time": 1672164726,
  "bugs": []
}

$ rmadison -a source,amd64 kbtin colorized-logs | grep -E ' (old)?oldstable'
colorized-logs | 1.0.17-1  | oldoldstable| amd64
colorized-logs | 2.4-1 | oldstable   | source, amd64
kbtin  | 1.0.17-1  | oldoldstable| source, amd64
kbtin  | 1.0.19-2  | oldstable   | source, amd64

$ apt-get changelog kbtin | grep -C4 colorized-logs

kbtin (1.0.18-1) unstable; urgency=medium

  * New upstream release.
  * Drop colorized-logs, it's a separate source now.
  * Check the tarball's signature.

 -- Adam Borowski   Sun, 22 Oct 2017 02:15:20 +0200

kbtin (1.0.17-1) unstable; urgency=medium

  * New upstream release.
  * Split out ansi2html, ansi2txt, ttyrec2ansi, (new) pipetty to a new
package "colorized-logs".

 -- Adam Borowski   Mon, 29 Aug 2016 17:12:51 +0200

kbtin (1.0.16-2) unstable; urgency=medium

$ grep -A4 'srcs =' scripts/generate-how-can-i-help 
srcs = {}
dbget("select distinct package, source from packages_summary").each do |r|
  srcs[r['source']] ||= []
  srcs[r['source']] << r['package']
end

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1025213:

[wh]

I was able to build a copy of the libgl1-mesa-dri with the Gallium i915
driver enabled, and that fixed the flickering problem on my netbook from
that era.

Here's a copy if anyone would like to try
https://github.com/wh0/debian-mesa-i915g/releases/tag/22.3.0-1-1

I saw that Fedora had enabled it too:
https://bugzilla.redhat.com/show_bug.cgi?id=2100212

Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules

[Mathias Gibbens]

  I also would like to see this bug fixed, as a server I've got running
bookworm is spamming log events due to the default date format having
changed in rsyslog.

  Jose -- I'd be happy to help out by co-maintaining the logcheck
package. The logcheck repo is in the debian group on salsa, so by
convention technically it's open for any DD to contribute to, but I
don't want to just start doing uploads without first seeing if you
would have any objections.

  Stefan and Richard -- Hopefully we'll be able to get this bug
resolved pretty quickly. If you have patches for a suggested change or
(even better) a script to automate changing all the rule files, please
feel free to add it to this bug report, or open a pull request on
salsa.

Mathias

  PS -- There might be an email loop, so I've specifically CC'ed Jose
on this email. The current Maintainer email address for logcheck is the
"magic" logch...@packages.debian.org address that will forward messages
to the package's maintainer, but because that's the exact same address
it might be looping/dropping messages. I'm not sure if there's logic in
place to also email "real" addresses listed as Uploaders for a package
or not


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

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

I created an MR:

https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5[1]

Please review and make sure I haven’t missed anything or misrepresented the 
consensus.

On Thursday, November 17, 2022 2:25:17 PM MST Soren Stoutner wrote:
> At this point, the only question left is where this should be documented and
> who should write the documentation.  I am assuming that /usr/share/doc/
> dictionaries-common-dev/dsdt-policy.html is the correct place for
> documentation.  I am willing to submit a PR if nobody else prefers to do so
> instead.


-- 
Soren Stoutner
so...@stoutner.com


[1] https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5


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

Bug#1017977: Fails to load intel/ibt-20-1-3.sfi

[Olaf Meeuwissen]

Upgrading the firmware-iwlwifi package last week (2022-11-27) from
20221012-1 to 20221109-2 fixed the issue for linux-image-6.0.0-4-amd64
6.0.8-1.  The changelog for 20221109-1 mentioned

  * iwlwifi: update firmware files for Intel Bluetooth AX2*
  * iwlwifi: Add Intel Wireless AX211 Bluethooth firmware and
configuration (Closes: #1023245)

which may be related to fixing it for my

  Intel Corporation Wi-Fi 6 AX200 (rev 1a)

However, upgrading today (2022-12-04) to linux-image-6.0.0-5-amd64
6.0.10-1 reintroduced it.

Cold booting into 6.0.0-4 I have a working Bluetooth-only keyboard.
Rebooting from that into 6.0.0-5 my keyboard remains functional.
Cold booting into 6.0.0-5 my Bluetooth-only keyboard is unresponsive.

For both 6.0.0-5 boot scenarios, dmesg --level=err includes

  bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2)

Twice, actually, about 10 microseconds apart.

For 6.0.0-4 there is no such error message.

Hope this helps,
--
Olaf Meeuwissen

Bug#1024326: [Pkg-zfsonlinux-devel] Bug#1024326: bullseye to bookworm upgrade failure: Could not locate dkms.conf file

[M. Zhou]

Control: severity -1 important
Control: tags -1 +moreinfo

I'm still not sure about why the upgrade failed, and I could not
reproduce the problem in a clean chroot using the following script:

https://salsa.debian.org/zfsonlinux-team/zfs/-/blob/master/debian/tests/sbuild-shell-bullseye-to-bookworm.sh

So I'm downgrading the bug's severity to unblock migration.

On Thu, 2022-11-17 at 10:31 -0500, Antoine Beaupre wrote:
> Package: zfs-dkms
> Version: 2.1.6-3
> Severity: serious
> 
> I have tried to upgrade to bookworm today and kernel builds fail on
> zfs-dkms. It fails with:
> 
> dkms: running auto installation service for kernel 6.0.0-4-
> amd64:Error! Could not locate dkms.conf file.
> File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
> 
> It's odd because zfs 2.0.3 is gone now... The package has been
> upgraded at this point... Yet the /var/lib/dkms/zfs/2.0.3 directory
> was still around. Removing it fixes the problem:
> 
>     rm -rf /var/lib/dkms/zfs/2.0.3
> 
> Note that I am doing batch upgrades with a special procedure, with
> this command:
> 
>     env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none
> APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \
>     apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o
> Dpkg::Options::='--force-confold' &&
> 
> ... which might have cause the old directory to not be removed.
> 
> See this for my upgrade procedure:
> 
> https://anarc.at/services/upgrades/bookworm/
> 
> More of the error log:
> 
> Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ...
> /etc/kernel/postinst.d/dkms:
> dkms: running auto installation service for kernel 6.0.0-4-
> amd64:Error! Could not locate dkms.conf file.
> File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
>  failed!
> run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
> dpkg: error processing package linux-image-6.0.0-4-amd64 (--
> configure):
>  installed linux-image-6.0.0-4-amd64 package post-installation script
> subprocess returned error exit status 1
> dpkg: dependency problems prevent configuration of linux-image-amd64:
>  linux-image-amd64 depends on linux-image-6.0.0-4-amd64 (= 6.0.8-1);
> however:
>   Package linux-image-6.0.0-4-amd64 is not configured yet.
> 
> dpkg: error processing package linux-image-amd64 (--configure):
>  dependency problems - leaving unconfigured
> Setting up linux-headers-6.0.0-4-amd64 (6.0.8-1) ...
> /etc/kernel/header_postinst.d/dkms:
> dkms: running auto installation service for kernel 6.0.0-4-
> amd64:Error! Could not locate dkms.conf file.
> File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
>  failed!
> run-parts: /etc/kernel/header_postinst.d/dkms exited with return code
> 4
> Failed to process /etc/kernel/header_postinst.d at
> /var/lib/dpkg/info/linux-headers-6.0.0-4-amd64.postinst line 11.
> dpkg: error processing package linux-headers-6.0.0-4-amd64 (--
> configure):
>  installed linux-headers-6.0.0-4-amd64 package post-installation
> script subprocess returned error exit status 1
> dpkg: dependency problems prevent configuration of linux-headers-
> amd64:
>  linux-headers-amd64 depends on linux-headers-6.0.0-4-amd64 (= 6.0.8-
> 1); however:
>   Package linux-headers-6.0.0-4-amd64 is not configured yet.
> 
> dpkg: error processing package linux-headers-amd64 (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  linux-image-6.0.0-4-amd64
>  linux-image-amd64
>  linux-headers-6.0.0-4-amd64
>  linux-headers-amd64

Bug#1025404: python-libais: Stop calling python3 setup.py test

[Emmanuel Arias]

Source: python-libais
Version: 0.17+git.20190917.master.e464cf8-3
Severity: normal
X-Debbugs-Cc: eam...@yaerobi.com

Dear Maintainer,

Calling "python3 setup.py test" has been deprecated since setuptools
28.5.

Please, fix the tests execution to stop use "setup.py tests". For more
information please see [0].

Cheers,
Emmanuel


[0] https://lists.debian.org/debian-python/2022/08/msg00046.html

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

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

Bug#1025403: libgtk-4-1: Segmentation fault when trying to open any gtk4 app

[Thiago Bellini Ribeiro]

Package: libgtk-4-1
Version: 4.8.2+ds-3
Severity: important
X-Debbugs-Cc: hackedbell...@gmail.com

I'm currently not able to open any gtk4 app as they all will segfault. Trying
to run nautilus/gnome-text-editor/etc for example will all result in this:

$ gnome-text-editor
libEGL warning: DRI3: Screen seems not DRI3 capable
libEGL warning: DRI2: failed to authenticate
[1]6998 segmentation fault  gnome-text-editor

Note that I'm running Debian Sid with all of my packages up to date, in a
Nvidia Optimus laptop and using the Nvidia GPU as the primary one
(https://wiki.debian.org/NVIDIA%20Optimus#Using_NVIDIA_GPU_as_the_primary_GPU),
and in a X11 session (I can't even use wayland because it gets disabled for me
(there's a udev rule that disables it for hybrid graphics laptops)


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

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

Versions of packages libgtk-4-1 depends on:
ii  adwaita-icon-theme43-1
ii  hicolor-icon-theme0.17-2
ii  libc6 2.36-6
ii  libcairo-gobject2 1.16.0-6
ii  libcairo-script-interpreter2  1.16.0-6
ii  libcairo2 1.16.0-6
ii  libcloudproviders00.3.1-2
ii  libcolord21.4.6-2.1
ii  libcups2  2.4.2-1+b2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.5
ii  libfribidi0   1.0.8-2.1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1
ii  libglib2.0-0  2.74.2-1
ii  libgraphene-1.0-0 1.10.8-1
ii  libgtk-4-common   4.8.2+ds-3
ii  libharfbuzz0b 5.2.0-2+b1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libpangoft2-1.0-0 1.50.10+ds-1
ii  libpng16-16   1.6.39-2
ii  libtiff5  4.4.0-6
ii  libwayland-client01.21.0-1
ii  libwayland-egl1   1.21.0-1
ii  libx11-6  2:1.8.1-2
ii  libxcursor1   1:1.2.1-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  libxinerama1  2:1.1.4-3
ii  libxkbcommon0 1.4.1-1
ii  libxrandr22:1.5.2-2+b1
ii  shared-mime-info  2.2-1

Versions of packages libgtk-4-1 recommends:
ii  iso-codes4.12.0-1
ii  libgtk-4-bin 4.8.2+ds-3
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages libgtk-4-1 suggests:
ii  gvfs  1.50.2-2
pn  libgtk-4-media-gstreamer | libgtk-4-media-ffmpeg  

-- no debconf information

Bug#1025402: python3-pyvmomi: pyVmomi/Version.py:26: SyntaxWarning: "is" with a literal. Did you mean "=="?

[Paul Wise]

Package: python3-pyvmomi
Version: 6.7.1-4
Severity: normal
Usertags: warnings
File: /usr/lib/python3/dist-packages/pyVmomi/Version.py

When installing python3-pyvmomi I get a syntax warning:

   Setting up python3-pyvmomi (6.7.1-4) ...
   /usr/lib/python3/dist-packages/pyVmomi/Version.py:26: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
 if isLegacy or ns is "":

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages python3-pyvmomi depends on:
ii  dpkg  1.21.9+b1
ii  python3   3.10.6-1
ii  python3-requests  2.28.1+dfsg-1
ii  python3-six   1.16.0-4

python3-pyvmomi recommends no packages.

Versions of packages python3-pyvmomi suggests:
ii  python-pyvmomi-doc  6.7.1-4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1003002: some more information - possible solution

[Christian Kastner]

On 2022-12-03 11:14, Christian Kastner wrote:
> I'm also leaning towards a race, but the question is whether this is
> really a potential bug, or whether determinism is assumed where none is
> guaranteed (similar to the issue of storage devices like sda and sdb
> being non-deterministic).

I may have stumbled over a trivial solution.

Looking at Maximilian's test cases, I noticed that -device virtio-serial
was being specified multiple times. From other docs, I gather it's only
needed once, even with multiple devices.

The attached patch reduces this to one instance, and this fixes the
issue for me.

I ran a series of tests with armhf/arm64, various CPU counts, and all
went well. armhf with 4 CPUs initially failed but from using the
--show-boot option, it was evident that the boot process was just slower
(long time spent in GRUB), and with increasing --timeout=120, that
worked, too.

With Maximilian's experiments showing that the console count was
shifted, I guess that multiple -device virtio-serial somehow confuses
internal QEMU ordering, although I don't know why this would be an issue
only with kernels > 5.10.

Can anyone else give this patch a try before I submit an MR?

Best,
ChristianIndex: autopkgtest-5.27/lib/autopkgtest_qemu.py
===
--- autopkgtest-5.27.orig/lib/autopkgtest_qemu.py
+++ autopkgtest-5.27/lib/autopkgtest_qemu.py
@@ -368,12 +368,15 @@ class Qemu:
 'unix:%s,server=on,wait=off' % self.get_socket_path('hvc0'),
 ])
 else:
+if hvc == 'hvc0' or self.qemu_architecture == 'ppc64le':
+argv.extend([
+'-device', 'virtio-serial',
+])
 argv.extend([
 '-chardev',
 'socket,path=%s,server=on,wait=off,id=%s' % (
 self.get_socket_path(hvc), hvc,
 ),
-'-device', 'virtio-serial',
 '-device', 'virtconsole,chardev=%s' % hvc,
 ])
 

Bug#995670: Zig package status

[Bastian Germann]

Am 04.12.22 um 00:55 schrieb Nick Hastings:

Without a sponsor the package can't enter Debian so I don't want to
spend the many tedious hours required to manually produce a correct
copyright file if it will not be used. If/when there is indication that
someone may sponsor this package I can look to put more time/effort into
the d/copyright.


With the copyright in place I will sponsor it. Please notify me when you think you have represented the applicable 
licenses completely and I will review it.

Bug#951902: duktape: python2 is required to regenerate some source files

[Bastian Germann]

Control: unblock 937695 by -1

On Sat, 22 Feb 2020 13:19:04 -0700 Sean Whitton  
wrote:

Thus, I believe that conversion of these scripts to python3 blocks
python2 removal in Debian.  I'm attempting to file this bug with the
right metadata; please excuse me if I didn't get it right, as I'm not
really involved in the python2 removal efforts.


I do not think that python2 removal should be blocked by a package that has never depended on it but would have to do 
that to conform with the Policy. Upstream has partly converted the scripts to python3 and apparently some of them to nodejs.

Bug#1025401: unblock: libpod/4.3.1+ds1-5

[Reinhard Tartler]

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

Please unblock package libpod

libpod needs to migrate together with:

golang-github-containers-common_0.50.1+ds1-2
golang-github-containers-buildah_1.28.0+ds1-3

[ Reason ]

There have been API changes that prevent the new libpod from building with old
versions. Also, the old libpod doesn't build with new versions of -common and
buildah. This was all successfully detected by autopkgtest.


[ Tests ]

I've manually scheduled autopkgtests on ci.debian.net to show that autopkgtests
passes with these three packages in combination.


hint libpod/4.3.1+ds1-5 golang-github-containers-common/0.50.1+ds1-2 
golang-github-containers-buildah/1.28.0+ds1-3

Bug#995670: Zig package status

[Nick Hastings]

Hi Bastian,

* Bastian Germann  [221203 02:45]:
> The package got removed from mentors.

Yes, no one sponsored it.

> Nick, do you still have time to work on it? If not please make this a
> RFP.

I think I have time. Zig 0.10.0 was just released and I'm updating the
package for it. Hope to upload to mentors soon.

I think the biggest problem is still the copyright file. I tried using
scancode but it seems that d/copyright output option is still a work in
progress.

Without a sponsor the package can't enter Debian so I don't want to
spend the many tedious hours required to manually produce a correct
copyright file if it will not be used. If/when there is indication that
someone may sponsor this package I can look to put more time/effort into
the d/copyright.

Regards,

Nick.

Bug#938322: fixed in qtwebengine-opensource-src 5.15.11+dfsg-1

[Bastian Germann]

On Sun, 27 Nov 2022 10:00:56 + Debian FTP Masters 
 wrote:

   * Use Python 3 instead of Python 2 for building (closes: #938322).
 - Update build-dependency.
 - Add python3.patch, inspired by Arch Linux but using versioned python3.
 - Add chromium-python3.patch, copied from Arch Linux.


This is now literally the last package that has build depends on python2 in 
bookworm.
Is there a chance to move the experimental package to sid soon?

Bug#945665: dump1090-mutability: Python2 removal in sid/bullseye

[Bastian Germann]

Uploading a NMU to fix this. debdiff attached.diff -Nru dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/changelog 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/changelog
--- dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/changelog 
2021-01-27 05:16:35.0 +0100
+++ dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/changelog 
2022-12-03 23:38:23.0 +0100
@@ -1,3 +1,10 @@
+dump1090-mutability (1.15~20180310.4a16df3+dfsg-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Recommends: python (Closes: #945665).
+
+ -- Bastian Germann   Sat, 03 Dec 2022 23:38:23 +0100
+
 dump1090-mutability (1.15~20180310.4a16df3+dfsg-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/control 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/control
--- dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/control   
2021-01-27 05:16:35.0 +0100
+++ dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/control   
2022-12-03 23:38:23.0 +0100
@@ -29,7 +29,6 @@
  ${shlibs:Depends}
 Recommends:
  lighttpd,
- python (>= 2.5)
 Provides:
  fatsv-data-source
 Description: ADS-B Ground Station System for RTL-SDR

Bug#1019147: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Bernhard Übelacker]

(Resent after subscription, as non-subscribers get rejected.)



Hello,
I opened the initial Debian bug report, but did took the time to
ask at systemd-devel and found this thread was already asked,
so I am trying to provide further information.




> Do you have any MACs in effect?
No SELinux or Apparmor active


As far as I see in my test VM with minimal Debian Buster there is no SELinux.
"aa-status" returns "apparmor module is loaded.", but I did not intentionally
configure anything to it.




> Does the host use cgroupsv2 or cgroupsv2 or hybrid? The host system uses 
systemd v241, compiled with default-hierarchy=hybrid

> Was the container configured to use either?
The container uses systemd v251 with default-hierarchy=unified


At the host:
   # systemd --version
   systemd 241 (241)
   +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS \
   +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid

In the container:
   # systemd --version
   systemd 252 (252.2-1)
   +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL 
+ACL +BLKID \
   +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK 
+PCRE2 -PWQUALITY \
   -P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK 
-XKBCOMMON +UTMP \
   +SYSVINIT default-hierarchy=unified




> What is mounted to /sys/fs/cgroup and below?


At the host:
   # mount | grep /sys/fs/cgroup
   tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
   cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
   cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
   cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
   cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
   cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
   cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
   cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
   cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
   cgroup on /sys/fs/cgroup/rdma type cgroup 
(rw,nosuid,nodev,noexec,relatime,rdma)
   cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
   cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
   cgroup on /sys/fs/cgroup/pids type cgroup 
(rw,nosuid,nodev,noexec,relatime,pids)




> This is new payload on old host?


Yes, it is an test to use on an older Debian Buster with kernel 4.19.260-1
a quite recent Debian Bookworm/testing system.




> if you force container into cgroupsv1 mode as the host (by adding
> systemd.unified_cgroup_hierarchy=no to the nspawn cmdline, does that
> work?


I am not sure if I am using it right, but as far as I see
"systemd.unified_cgroup_hierarchy=no" does not help.
I added "debug" too, see below in [1].





> Also, please provide the relevant output from "strace -f -s 500 -y -o
> /tmp/log.strace" (put on some pastebin)


Following pastebin contains the last quarter of the log.strace
file recorded by the command in [1]:

  https://paste.debian.net/1262752/




I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set follow-fork-mode child'
and gdb from inside the container via plain chroot seems working well.

So it looks like the failing "syscall_0x1b7" from strace is "faccessat2" [2].

And it seems "faccessat2" got added just in kernel 5.8 [3],
therefore it might fail with the kernel 4.19.
So I fear this needs a newer kernel, and/or this is more a glibc issue then?


Kind regards,
Bernhard






[1]# strace -f -s 500 -y -o /tmp/log.strace systemd-nspawn 
--directory=/var/lib/machines/test-bookworm --boot 
systemd.unified_cgroup_hierarchy=no debug
Spawning container test-bookworm on /var/lib/machines/test-bookworm.
Press ^] three times within 1s to kill container.
systemd 252.2-1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA 
+SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 
+IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT 
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP 
+SYSVINIT default-hierarchy=unified)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.
Detected initialized system, this is not the first boot.
Kernel version 4.19.0-22-amd64, our baseline is 4.15

Welcome to Debian GNU/Linux bookworm/sid!

Hostname set to .
sd-netlink: Failed to enable NETLINK_GET_STRICT_CHK option, ignoring: 
Protocol not available
Failed to add address 127.0.0.1 to loopback interface: Operation not 
permitted

Bug#955208: rustup was published to crates.io; I'd be great to have it packaged in Debian

[Martin Quinson]

Hello there,

two years ago, Ximin stated that rustup cannot enter Debian until either 

- https://github.com/rust-lang/rustup/issues/835 OR
- https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

is fixed. The thing is that the first issue was closed in between. Is there any
hope that we could get rustup as a package, please?

My motivation is that I want to hack on a project that won't compile if rustup
is not installed, and I don't like installing anything out of dpkg.


Thanks in advance and kudos for all the good work here.
Mt 




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

Bug#1025307: yosys mips64el build failure (fix)

[Daniel Gröber]

Hi Scott,

On Sat, Dec 03, 2022 at 01:47:25PM +, Scott Ashcroft wrote:
> > Got any ideas?
> 
> That last sucessful armhf build was on 14/11/2022 which was just before
> you added the following changes to berkeley-abc:
> 
> Maybe that armhf patch needs to be reverted?

I totally forgot about that. Indeed it looks like this messes things up on
armhf, but only on real hardware, not qemu.

The patch removed -DABC_MEMALIGN=4 since the way the Makefile was checking
for the current arch being arm was completely broken and only triggering on
some buildds. Having that defined basically aligns the size (not address)
of some allocations. Turns out however that this will also cause the next
allocation to not be aligned, which I'd failed to anticipate.

After some more playing around with gdb on a porterbox I can confirm that
just reinstating that rounding will stop it from crashing.

Let's hope yosys_0.23-6, which should rebuild against a fixed berkeley-abc
takes care of this.

Thanks,
--Daniel

Bug#1019147: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Bernhard Übelacker]

Hello,
I opened the initial Debian bug report, but did took the time to
ask at systemd-devel and found this thread was already asked,
so I am trying to provide further information.




> Do you have any MACs in effect?
No SELinux or Apparmor active


As far as I see in my test VM with minimal Debian Buster there is no SELinux.
"aa-status" returns "apparmor module is loaded.", but I did not intentionally
configure anything to it.



> Does the host use cgroupsv2 or cgroupsv2 or hybrid? 
The host system uses systemd v241, compiled with default-hierarchy=hybrid


> Was the container configured to use either?
The container uses systemd v251 with default-hierarchy=unified


At the host:
   # systemd --version
   systemd 241 (241)
   +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS \
   +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid

In the container:
   # systemd --version
   systemd 252 (252.2-1)
   +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL 
+ACL +BLKID \
   +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK 
+PCRE2 -PWQUALITY \
   -P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK 
-XKBCOMMON +UTMP \
   +SYSVINIT default-hierarchy=unified




> What is mounted to /sys/fs/cgroup and below?


At the host:
   # mount | grep /sys/fs/cgroup
   tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
   cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
   cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
   cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
   cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
   cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
   cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
   cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
   cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
   cgroup on /sys/fs/cgroup/rdma type cgroup 
(rw,nosuid,nodev,noexec,relatime,rdma)
   cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
   cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
   cgroup on /sys/fs/cgroup/pids type cgroup 
(rw,nosuid,nodev,noexec,relatime,pids)




> This is new payload on old host?


Yes, it is an test to use on an older Debian Buster with kernel 4.19.260-1
a quite recent Debian Bookworm/testing system.




> if you force container into cgroupsv1 mode as the host (by adding
> systemd.unified_cgroup_hierarchy=no to the nspawn cmdline, does that
> work?


I am not sure if I am using it right, but as far as I see
"systemd.unified_cgroup_hierarchy=no" does not help.
I added "debug" too, see below in [1].





> Also, please provide the relevant output from "strace -f -s 500 -y -o
> /tmp/log.strace" (put on some pastebin)


Following pastebin contains the last quarter of the log.strace
file recorded by the command in [1]:

  https://paste.debian.net/1262752/




I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set follow-fork-mode child'
and gdb from inside the container via plain chroot seems working well.

So it looks like the failing "syscall_0x1b7" from strace is "faccessat2" [2].

And it seems "faccessat2" got added just in kernel 5.8 [3],
therefore it might fail with the kernel 4.19.
So I fear this needs a newer kernel, and/or this is more a glibc issue then?


Kind regards,
Bernhard






[1]# strace -f -s 500 -y -o /tmp/log.strace systemd-nspawn 
--directory=/var/lib/machines/test-bookworm --boot 
systemd.unified_cgroup_hierarchy=no debug
Spawning container test-bookworm on /var/lib/machines/test-bookworm.
Press ^] three times within 1s to kill container.
systemd 252.2-1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA 
+SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 
+IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT 
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP 
+SYSVINIT default-hierarchy=unified)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.
Detected initialized system, this is not the first boot.
Kernel version 4.19.0-22-amd64, our baseline is 4.15

Welcome to Debian GNU/Linux bookworm/sid!

Hostname set to .
sd-netlink: Failed to enable NETLINK_GET_STRICT_CHK option, ignoring: 
Protocol not available
Failed to add address 127.0.0.1 to loopback interface: Operation not 
permitted
Failed to add address ::1 to loopback interface: Operation not 

Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)

[Andreas Tille]

Am Sat, Dec 03, 2022 at 10:53:58PM +0100 schrieb Sebastian Ramacher:
> And there are many more. r-bioc-biocparallel is another one. This smells
> like many insufficient dependencies.

Sorry, this all seems to be the same britney failure Paul was reporting.
The tests are all against the versions in testing which makes no sense
at all.  These tests are not fixable since the old versions of BioC 3.15
are bound to fail with packages from 3.16.

If this might help and is easily to realise removing all r-bioc-*
packages from testing could enable the migration of the packages in
unstable.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#945742: urjtag: Python2 removal in sid/bullseye

[Bastian Germann]

Control: tags -1 - bookworm bullseye sid
Control: unblock 937569 by -1
Control: unblock 937695 by -1

This affects only experimental.

Bug#970276: New upstream version: 2020-07-27

[Bastian Germann]

Control: retitle -1 urjtag: New upstream version 2021.03

On Mon, 14 Sep 2020 09:14:00 + Domenico Andreoli  wrote:

Package: urjtag
Severity: wishlist

Please update to the latest release at https://sourceforge.net/projects/urjtag


Release 2021.03 has Python 3 support. You should import that.

Bug#1025400: aioprocessing: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: aioprocessing
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025399: sphinx-autobuild: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: sphinx-autobuild
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025396: python-aiosqlite: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: python-aiosqlite
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025398: sphinx: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: sphinx
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025397: pydyf: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: pydyf
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025395: poliastro: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

[Louis-Philippe Véronneau]

Source: poliastro
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024906: apparently fixed Re: dask autopkgtest fail with python 3.11

[Rebecca N. Palmer]

This combination stopped failing on 2022-11-22/23 (without a dask 
upload, suggesting it was fixed somewhere other than dask itself).


Hence, I suggest closing this bug.

Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)

[Sebastian Ramacher]

On 2022-12-03 21:51:55 +0100, Andreas Tille wrote:
> Hi Paul,
> 
> Am Sat, Dec 03, 2022 at 09:34:09PM +0100 schrieb Paul Gevers:
> > On 29-11-2022 10:26, Andreas Tille wrote:
> > > Now there is only one remaining one which is a real
> > > problem which I have reported upstream (see bug #1025045).  If
> > > r-bioc-structuralvariantannotation would be removed from testing I
> > > do not see any blocker for the transition any more.
> > 
> > I removed r-bioc-structuralvariantannotation
> 
> Thanks a lot.
> 
> > but the transition is blocked
> > on an autopkgtest regressions caused by r-bioc-iranges.
> 
> This is also a false positive since for sure the test against
> r-bioc-fishpond 2.2.0+ds-2 fails since this belongs to BioConductor
> 3.15.

And there are many more. r-bioc-biocparallel is another one. This smells
like many insufficient dependencies.

Cheers
-- 
Sebastian Ramacher

Bug#1025394: clang-14: undefined symbol errors on chromium with basic_string

[Andres Salomon]

Source: llvm-toolchain-14
Version: 1:14.0.6-8
Severity: serious
Tags: ftbfs fixed-upstream patch sid
Justification: fails to build from source

When building chromium, I hit the following:

ld.lld: error: undefined symbol: void 
std::__cxx11::basic_string, 
std::allocator >::_M_construct(char16_t 
const*, char16_t const*, std::forward_iterator_tag)

   >>> referenced by http_handler.cc
   >>>   
obj/chrome/test/chromedriver/lib/http_handler.o:(internal::MatchesCommand(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, CommandMapping const&, 
std::__cxx11::basic_string, 
std::allocator >*, base::DictionaryValue*))



Even fixing that one implicit cast from std::u16string to 
base::StringPiece16, there's many more of those types of errors. The 
errors were trigged by chromium upstream switching from --std=c++17 to 
--std=c++20, so I figured I could work around it with this patch:




Unfortunately, even with that it still happens on some architectures:



Upstream claimed to have fixed this bug in clang 14.0.5, however it 
then popped up again in 14.0.6:




There's now a fix from 2 days ago:



It would be great to get this fixed in sid, and it's also an issue in 
bullseye with clang-13. It's probably also in clang-15, I'm guessing, 
although I haven't tested it and will likely get fixed automatically in 
the next clang point release.


Thanks,
Andres

Bug#1025393: dask: autopkgtest fail with pandas 1.5

[Rebecca N. Palmer]

Package: python3-dask
Version: 2022.02.0+dfsg-2
Tags: fixed-upstream
Control: block 1022571 by -1

With pandas 1.5 (currently in experimental), the dask autopkgtest fails:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dask/28842796/log.gz

This appears to be fixed upstream, but I haven't tested this:
https://github.com/dask/dask/pull/8961

Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i915_dri.so

[Felix Miata]

Same for i915_dri.so on Bookworm:

# xdriinfo
libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so: cannot 
open shared object file: No such file or directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: i915
Screen 0: swrast

Intel 82945G/GZ Integrated Graphics 8086:2772


File list of package libgl1-mesa-dri in bookworm of architecture amd64:

/usr/lib/x86_64-linux-gnu/dri/crocus_dri.so
/usr/lib/x86_64-linux-gnu/dri/d3d12_dri.so
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
/usr/lib/x86_64-linux-gnu/dri/kms_swrast_dri.so
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
/usr/lib/x86_64-linux-gnu/dri/r300_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
/usr/lib/x86_64-linux-gnu/dri/virtio_gpu_dri.so
/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so
/usr/lib/x86_64-linux-gnu/dri/zink_dri.so
/usr/share/bug/libgl1-mesa-dri/control
/usr/share/bug/libgl1-mesa-dri/script
/usr/share/doc/libgl1-mesa-dri/changelog.Debian.gz
/usr/share/doc/libgl1-mesa-dri/changelog.gz
/usr/share/doc/libgl1-mesa-dri/copyright
/usr/share/drirc.d/00-mesa-defaults.conf

>From libgl1-mesa-dri:amd64 changelog:
mesa (22.0.0~rc2-1) experimental; urgency=medium

  * New upstream release candidate.
  * path_max.diff: Refreshed.
  * rules: Drop classic drivers (r100, r200, nouveau_vieux, i915, i965).

 -- Timo Aaltonen   Thu, 17 Feb 2022 22:04:03 +0200

Where and what are the replacements for pre-Haswell GPUs like 945G?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)

[Andreas Tille]

Hi Paul,

Am Sat, Dec 03, 2022 at 09:34:09PM +0100 schrieb Paul Gevers:
> On 29-11-2022 10:26, Andreas Tille wrote:
> > Now there is only one remaining one which is a real
> > problem which I have reported upstream (see bug #1025045).  If
> > r-bioc-structuralvariantannotation would be removed from testing I
> > do not see any blocker for the transition any more.
> 
> I removed r-bioc-structuralvariantannotation

Thanks a lot.

> but the transition is blocked
> on an autopkgtest regressions caused by r-bioc-iranges.

This is also a false positive since for sure the test against
r-bioc-fishpond 2.2.0+ds-2 fails since this belongs to BioConductor
3.15.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1025392: Is the dependency on xfonts-utils needed?

[Frank]

Package: fonts-terminus-otb
Severity: wishlist

Hi,

I was wondering whether the dependency on xfonts-utils is needed for this font?
(Isn't this leftover from the original bitmap terminus font?)

Bye,
Frank

Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)

[Paul Gevers]

Hi Andreas,

On 29-11-2022 10:26, Andreas Tille wrote:

Now there is only one remaining one which is a real
problem which I have reported upstream (see bug #1025045).  If
r-bioc-structuralvariantannotation would be removed from testing I
do not see any blocker for the transition any more.


I removed r-bioc-structuralvariantannotation but the transition is 
blocked on an autopkgtest regressions caused by r-bioc-iranges.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023787: transition: liblxqt

[Paul Gevers]

Hi ChangZhuo,

On 03-12-2022 17:19, ChangZhuo Chen (陳昌倬) wrote:

On Tue, Nov 29, 2022 at 07:33:11PM +0100, Paul Gevers wrote:
Do we need to submit transition for lxqt-globalkeys [0], which is
totally covered by liblxqt transition?


What we need is coordination, which is why transition bugs need to be 
filed before the transition starts in unstable. We don't need a 
transition bug report per source package if they are combined anyways 
provided that the information about that is in the bug report.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025391: hdf5-filter-plugin: missing Breaks+Replaces: bitshuffle

[Andreas Beckmann]

Package: hdf5-filter-plugin
Version: 0.0~git2022.49e3b65-2
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...):

  Preparing to unpack 
.../hdf5-filter-plugin_0.0~git2022.49e3b65-2_amd64.deb ...
  Unpacking hdf5-filter-plugin (0.0~git2022.49e3b65-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/hdf5-filter-plugin_0.0~git2022.49e3b65-2_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/hdf5/serial/plugins/libh5bshuf.so', which is also in 
package bitshuffle 0.3.5-4+b1
  Errors were encountered while processing:
   
/var/cache/apt/archives/hdf5-filter-plugin_0.0~git2022.49e3b65-2_amd64.deb


Is my understanding right that src:hdf5-filter-plugin supersedes src:bitshuffle?
Then please RM the obsolete bitshuffle package.

If bitshuffle is to be removed, the B+R against it can be unversioned (unless
you have a virtual bitshuffle package provided somewhere).


cheers,

Andreas


bitshuffle=0.3.5-4+b1_hdf5-filter-plugin=0.0~git2022.49e3b65-2.log.gz
Description: application/gzip

Bug#1025390: python3-prody-tests: missing Breaks+Replaces: python3-prody (<< 2.3.1)

[Andreas Beckmann]

Package: python3-prody-tests
Version: 2.3.1+dfsg-1
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...):

  Preparing to unpack .../python3-prody-tests_2.3.1+dfsg-1_all.deb ...
  Unpacking python3-prody-tests (2.3.1+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-prody-tests_2.3.1+dfsg-1_all.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/prody/tests/__init__.py', which is also in 
package python3-prody 2.2.0+dfsg-3+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-prody-tests_2.3.1+dfsg-1_all.deb


cheers,

Andreas


python3-prody=2.2.0+dfsg-3+b1_python3-prody-tests=2.3.1+dfsg-1.log.gz
Description: application/gzip

Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

[Jeremiah Mahler]

Package: libgl1-mesa-dri
Version: 22.3.0-1
Severity: normal

Dear Maintainer,

When attemtpting to start X it fails.  And looking through the
.local/share/xorg/Xorg.0.log finds a segfault like below (Xorg.0.log.bad).

One workaround I found is to comment out the entire Intel Graphics
config.  Not sure why this works.  Is it picking better defaults
or not enabling features which introduce the problem?

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
#Section "Device"
#  Identifier   "Intel Graphics"
#  Driver   "intel"
#
#  #Option  "AccelMethod" "uxa"
#  Option   "AccelMethod" "sna"
#  #Option  "NoAccel" "True"
#  Option   "DRI" "True"
#EndSection

Interestingly, it looks like this missing i965_dri.so has indeed gone
missing.

https://packages.debian.org/buster/amd64/libgl1-mesa-dri/filelist
https://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist

Xorg.0.log.bad
--
[14.004] (II) SELinux: Disabled on system
[14.004] (II) Initializing extension GLX
[14.005] (EE) AIGLX error: dlopen of 
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so failed 
(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so: cannot open shared object file: No 
such file or directory)
[14.005] (EE) AIGLX error: unable to load driver i965
[14.027] (EE)
[14.027] (EE) Backtrace:
[14.028] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x562070f40c59]
[14.028] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
[0x7f12c3a5af90]
[14.029] (EE) unw_get_proc_name failed: no unwind info found [-10]
[14.029] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7f12c4713029]
[14.029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) 
[0x7f12c3b6de9a]
[14.029] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) 
[0x7f12c3b6df4f]
[14.030] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) 
[0x7f12c3aa3dc7]
[14.030] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) 
[0x7f12c3aa3b26]
[14.032] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(nouveau_drm_screen_create+0x1d50f4) [0x7f12c1ae7f44]
[14.032] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(nouveau_drm_screen_create+0x1d4340) [0x7f12c1ae7190]
[14.033] (EE) unw_get_proc_name failed: no unwind info found [-10]
[14.033] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) 
[0x7f12c10aa179]
[14.034] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x60ae16) [0x7f12c16b5156]
[14.034] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x60ad84) [0x7f12c16b50c4]
[14.034] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x6f4) [0x7f12c10aaa34]
[14.034] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0xa175) [0x7f12c10b44b5]
[14.035] (EE) unw_get_proc_name failed: no unwind info found [-10]
[14.035] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) 
[0x7f12c37ecd77]
[14.035] (EE) unw_get_proc_name failed: no unwind info found [-10]
[14.035] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) 
[0x7f12c37ebb7f]
[14.035] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x562070dd2a24]
[14.035] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) 
[0x562070efea9f]
[14.036] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x562070e3e2a9]
[14.036] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x562070dd14e8]
[14.036] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7f12c3a4618a]
[14.036] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7f12c3a46245]
[14.036] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x562070dbab61]
[14.036] (EE)
[14.037] (EE) Segmentation fault at address 0x337
[14.037] (EE)
Fatal server error:
[14.037] (EE) Caught signal 11 (Segmentation fault). Server aborting
[14.037] (EE)
[14.037] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[14.037] (EE) Please also check the log file at 
"/home/jeri/.local/share/xorg/Xorg.0.log" for additional information.
[14.037] (EE)
[14.073] (EE) Server terminated with error (1). Closing log file.


-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD 
Graphics 520] [8086:1916] (rev 07)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 194 Dec  3 10:30 20-intel.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 

Bug#1025388: urlview: New upstream location with most Debian changes applied

[Bastian Germann]

Source: urlview
Version: 0.9-23.1
Severity: wishlist

See https://github.com/sigpipe/urlview where the author was developing the 
program.
Development is stalled but it would be good to import the last commit as new 
upstream version
to get rid of Debian's patches.

Bug#1025055: transition: qtwebengine-opensource-src

[Sebastian Ramacher]

On 2022-12-03 19:37:31 +0300, Dmitry Shachnev wrote:
> Control: tags -1 -moreinfo
> 
> Hi Sebastian!
> 
> On Sat, Dec 03, 2022 at 03:46:59PM +0100, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> >
> > Thanks for working on this. Please let us know once you think it's
> > ready.
> 
> It is ready. Tested by me and by Lisandro.

Great, please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1025387: bullseye-pu: package node-qs/6.9.4+ds-1+deb11u1

[Yadd]

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

[ Reason ]
node-qs is vulnerable to prototype pollution, this affects web
applications using node-express (CVE-2022-24999)

[ Impact ]
Medium security issue

[ Tests ]
Patch adds a test to verify that bug is fixed

[ Risks ]
No risk, patch is trivial

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

[ Changes ]
Just verity that key isn't __proto__ before updating object keys

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 3734d04..774ba07 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-qs (6.9.4+ds-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Fix prototype pollution (Closes: CVE-2022-24999)
+
+ -- Yadd   Sat, 03 Dec 2022 20:22:12 +0100
+
 node-qs (6.9.4+ds-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-24999.patch 
b/debian/patches/CVE-2022-24999.patch
new file mode 100644
index 000..45c26ca
--- /dev/null
+++ b/debian/patches/CVE-2022-24999.patch
@@ -0,0 +1,87 @@
+Description: `parse`: ignore `__proto__` keys
+Author: Jordan Harband 
+Origin: upstream, https://github.com/ljharb/qs/pull/428
+Bug: https://security-tracker.debian.org/tracker/CVE-2022-24999
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-12-03
+
+--- a/lib/parse.js
 b/lib/parse.js
+@@ -135,7 +135,7 @@
+ ) {
+ obj = [];
+ obj[index] = leaf;
+-} else {
++} else if (cleanRoot !== '__proto__') {
+ obj[cleanRoot] = leaf;
+ }
+ }
+--- a/test/parse.js
 b/test/parse.js
+@@ -768,5 +768,65 @@
+ st.end();
+ });
+ 
++t.test('dunder proto is ignored', function (st) {
++var payload = 
'categories[__proto__]=login[__proto__][length]=42';
++var result = qs.parse(payload, { allowPrototypes: true });
++
++st.deepEqual(
++result,
++{
++categories: {
++length: '42'
++}
++},
++'silent [[Prototype]] payload'
++);
++
++var plainResult = qs.parse(payload, { allowPrototypes: true, 
plainObjects: true });
++
++st.deepEqual(
++plainResult,
++{
++__proto__: null,
++categories: {
++__proto__: null,
++length: '42'
++}
++},
++'silent [[Prototype]] payload: plain objects'
++);
++
++var query = 
qs.parse('categories[__proto__]=cats[__proto__]=dogs[some][json]=toInject',
 { allowPrototypes: true });
++
++st.notOk(Array.isArray(query.categories), 'is not an array');
++st.notOk(query.categories instanceof Array, 'is not instanceof an 
array');
++st.deepEqual(query.categories, { some: { json: 'toInject' } });
++st.equal(JSON.stringify(query.categories), 
'{"some":{"json":"toInject"}}', 'stringifies as a non-array');
++
++st.deepEqual(
++qs.parse('foo[__proto__][hidden]=value[bar]=stuffs', { 
allowPrototypes: true }),
++{
++foo: {
++bar: 'stuffs'
++}
++},
++'hidden values'
++);
++
++st.deepEqual(
++qs.parse('foo[__proto__][hidden]=value[bar]=stuffs', { 
allowPrototypes: true, plainObjects: true }),
++{
++__proto__: null,
++foo: {
++__proto__: null,
++bar: 'stuffs'
++}
++},
++'hidden values: plain objects'
++);
++
++st.end();
++});
++
+ t.end();
+ });
diff --git a/debian/patches/series b/debian/patches/series
index aa71f6e..d1bf800 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 use-lodash-forEach-in-test.diff
+CVE-2022-24999.patch

Bug#1005840: claws-mail-themes: includes non-free content (CC-by-nc-sa-v3.0)

[Ricardo Mones]

On Sat, 3 Dec 2022 18:38:20 +0100
Francesco Poli  wrote:

> Control: fixed -1 claws-mail-themes/20221017+dfsg.1-1
> 
> 
> [it seems to me that control directives in messages sent to -done
> addresses are not processed... I am repeating the directive for this
> reason]

Umm, how inconvenient, but thanks anyway! :)

> 
> On Sat, 3 Dec 2022 18:08:55 +0100 Ricardo Mones wrote:
> 
> > control: fixed -1 claws-mail-themes/20221017+dfsg.1-1
> > 
> > On Sun, 27 Feb 2022 17:55:23 +0100
> > Francesco Poli  wrote:
> > […]  
> > > > Yeah, agreed, but given I doubt that can be possible at this
> > > > point to make upstream release a new tarball just to fix those
> > > > bits, specially without a contact address. Will try to ask
> > > > upstream if somebody has his contact, otherwise I'm afraid the
> > > > only solution will be the removal.
> > > 
> > > Thanks for willing to attempt this.
> > > Let's see how it goes...  
> > 
> > Despite the time passed, efforts were worth it and it went well :-)
> >  
> [...]
> 
> This is great news, indeed!
> Thanks for your efforts.
> 
> 
> Now, if only the licensing status of Fugue/* were also ironed out...
> See the original bug report!  ;-)

Oh, the joys of reporting two problems on one bug… had lost track of
this one! The original web from where the theme icons are being reused
(http://www.pinvoke.com/) still works and points to the licence so I
tend to agree this is CC-BY-3.0, furthermore the theme includes the full
text in the LICENSE.txt, so I've updated the copyright file¹.

Presumably this can be improved if #884224 is fixed at some point ;-)

Regarding persuading authors to switch licenses, well, my feeling is
that you have the same power than me to do that. As you rightly said,
the license is accepted by Debian currently, and that, very likely,
outweighs any other argument you can give to them.

best regards, 

¹ 
https://salsa.debian.org/claws-mail-team/claws-mail-themes/-/commit/84ce4ff4d7141d5a95c57fec67556d8350f9ad81
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Alimony and bribes will engage a large share of your wealth.»

Bug#1024395: CONFIG_INTEGRITY_PLATFORM_KEYRING was missing for mokutil --list-enrolled to work

[Steve McIntyre]

On Sat, Dec 03, 2022 at 05:49:11PM +0100, Éric Valette wrote:
>The error and font issue. The fact that shim-signed has a différent version 
>than the helper part also.
>
>The CONFIG_INTEGRITY_PLATFORM_KEYRING
>
>Fixes my mokutil --list-enrolled problem

Cool, thanks for confirming that.

I'm hoping to get the font thing fixed soon.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Bug#1025386: firejail: cannot use gdb with --allow-debuggers --profile=firefox

[Vincent Lefevre]

Package: firejail
Version: 0.9.70-2
Severity: normal

I get the following error:

zira:~> firejail --allow-debuggers --profile=firefox gdb
Reading profile /etc/firejail/firefox.profile
Reading profile /home/vinc17/.config/firejail/firefox.local
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/firefox-common.profile
Reading profile /home/vinc17/.config/firejail/firefox-common.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-proc.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Warning: networking feature is disabled in Firejail configuration file
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Parent pid 1626894, child pid 1626897
Warning: cannot open source file 
/usr/lib/x86_64-linux-gnu/firejail/seccomp.debug32, file not copied
Warning: An abstract unix socket for session D-BUS might still be available. 
Use --net or remove unix from --protocol set.
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Child process initialized in 130.58 ms
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = '/usr/bin/python'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = '/usr/bin/python'
  sys.base_prefix = '/usr'
  sys.base_exec_prefix = '/usr'
  sys.platlibdir = 'lib'
  sys.executable = '/usr/bin/python'
  sys.prefix = '/usr'
  sys.exec_prefix = '/usr'
  sys.path = [
'/usr/lib/python310.zip',
'/usr/lib/python3.10',
'/usr/lib/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the 
filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f32e84a9640 (most recent call first):
  

Parent is shutting down, bye...

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 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 firejail depends on:
ii  libapparmor1  3.0.7-1+b2
ii  libc6 2.36-6
ii  libselinux1   3.4-1+b3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.70-2
ii  iproute2   6.0.0-1+b1
ii  iptables   1.8.8-1
ii  xauth  1:1.1.1-1
ii  xdg-dbus-proxy 0.1.4-2
ii  xserver-xephyr 2:21.1.4-3
ii  xvfb   2:21.1.4-3

firejail 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#1022168: Review

[Kyle Robbertze]

Control: tags -1 moreinfo

Hi Robin,

Here is my review of this package:

* Remove debian/patches directory - you do not have any patches to apply
* debian/changelog: Remove all changelog entries and just have 1 with 
Initial packaging, closing the ITP bug. This is the first time this 
package has been uploaded to Debian, so there are no changes to report.
* debian/control: Standards version can drop the .1 at the end - just 
need to track up to the patch version. Also update to 4.6.1

* debian/rules: DEB_CFLAGS_MAINT_APPEND has a double space after it
* debian/copyright:
- m4/ax_check_compile_flag.m4 - this licence text is not listed in 
d/copyright. The file is listed, but the licence text in the file does 
not match the licence text in d/copyright

- The comment should be removed (xml and html files)

There is currently a false-positive lintian error that should be added 
to debian/source/lintian-overrides:



E: odr-audioenc source: source-is-missing [libtoolame-dab/html/psycho.html] 
   │

Cheers
Kyle
--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1025385: nheko would crash if home server does not have a .well-known served

[Boris Shtrasman]

Package: nheko
Version: 0.8.0+really0.7.2-4
Severity: normal
X-Debbugs-Cc: borissh1983+b...@gmail.com

Dear Maintainer,

I was connecting to an in-house matrix-synapse server,
  the server was setup behind a revese proxy (apache2) but did not have a 
.well-known served,
  the server did not have an SRV record declared.

I entered @user:subdomain.example.com , and nheko ... crashed.

Example:

[2022-12-03 20:22:28.132] [qml] [warning] QVariant::load: unable to load type 
1025. (:0, )
ssl3 ext invalid servername
ssl3 ext invalid servername
[2022-12-03 20:22:28.284] [qml] [warning] Cyclic dependency detected between 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
 and 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
 (:0, )
[2022-12-03 20:22:29.088] [ui] [info] jdenticon plugin not found.
[2022-12-03 20:22:29.108] [ui] [info] starting nheko 0.7.2
[2022-12-03 20:22:32.887] [qml] [warning] failed to create compose table (:0, )
[2022-12-03 20:22:56.203] [net] [info] Autodiscovery: No .well-known.
terminate called after throwing an instance of 'std::invalid_argument'
  what():  v1.1: invalid version
Aborted

I expected nheko to try to connect to fallback to https://subdomain.example.com 
as the matrix server.

Having a well-known folder with server that return the same values work as a 
workaround:

cat /var/www/html/.well-known/matrix/server 
{ "m.server": "subdomain.example.com:443" }


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

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

Versions of packages nheko depends on:
ii  libboost-iostreams1.74.0   1.74.0-9
ii  libboost-thread1.74.0  1.74.0-9
ii  libc6  2.31-13+deb11u4
ii  libcmark0.29.0 0.29.0-4
ii  libfmt77.1.3+ds1-5
ii  libgcc-s1  10.2.1-6
ii  liblmdb0   0.9.24-1
ii  libolm33.2.1~dfsg-7
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickwidgets55.15.2+dfsg-6
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libsodium231.0.18-1
ii  libspdlog1 [libspdlog1-fmt7]   1:1.8.1+ds-2.1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libstdc++6 10.2.1-6
ii  qml-module-qt-labs-settings5.15.2+dfsg-6
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtmultimedia5.15.2-3
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nheko recommends:
ii  ca-certificates 20210119
ii  fonts-noto-color-emoji  0~20200916-1

nheko suggests no packages.

-- no debconf information

Bug#1023977: linux-image-5.10.0-19-amd64: Ethernet disconnects randomly

[bdewit]

I have just tried to see if the bug is also in latest Linux kernel 
(6.0.11), and here I have no problems with Ethernet, so from this 
information it can be concluded that the bug is in the kernel of Debian 
itself, I do not know yet where the problem is, but I have a suspicion 
that it is in the at1lc driver from Atheros, which my network card uses.

Bug#1025374: firefox: reproducible crashes on various websites

[Vincent Lefevre]

On 2022-12-03 12:49:39 +0100, Vincent Lefevre wrote:
> Since FF 107, I've noticed crashes on several websites, including
> Facebook (even just after a restart).

It seems that it got worse in the last few days, though FF 107 got
last upgraded on 2022-11-16.

Note: Nightly also crashes on Facebook (with a new profile).

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

Bug#1024431: gcc-12: diff for NMU version 12.2.0-9.1

[Sean Whitton]

Control: tags 1024431 + patch
Control: tags 1024431 + pending


Dear maintainer,

I've prepared an NMU for gcc-12 (versioned as 12.2.0-9.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
Sean Whitton
diff -Nru gcc-12-12.2.0/debian/changelog gcc-12-12.2.0/debian/changelog
--- gcc-12-12.2.0/debian/changelog  2022-11-03 01:40:42.0 -0700
+++ gcc-12-12.2.0/debian/changelog  2022-12-02 18:28:07.0 -0700
@@ -1,3 +1,10 @@
+gcc-12 (12.2.0-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libgccjit0: Depend on libc6-dev (Closes: #1024431).
+
+ -- Sean Whitton   Fri, 02 Dec 2022 18:28:07 -0700
+
 gcc-12 (12.2.0-9) unstable; urgency=medium
 
   * Update to git 20221103 from the gcc-12 branch.
diff -Nru gcc-12-12.2.0/debian/control gcc-12-12.2.0/debian/control
--- gcc-12-12.2.0/debian/control2022-11-02 09:19:52.0 -0700
+++ gcc-12-12.2.0/debian/control2022-12-02 18:28:07.0 -0700
@@ -783,7 +783,7 @@
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Priority: optional
-Depends: gcc-12-base (= ${gcc:Version}), libgcc-12-dev, binutils, 
${shlibs:Depends}, ${misc:Depends}
+Depends: gcc-12-base (= ${gcc:Version}), libgcc-12-dev, binutils, 
${dep:libcdev}, ${shlibs:Depends}, ${misc:Depends}
 Breaks: python-gccjit (<< 0.4-4), python3-gccjit (<< 0.4-4)
 Description: GCC just-in-time compilation (shared library)
  libgccjit provides an embeddable shared library with an API for adding
diff -Nru gcc-12-12.2.0/debian/control.m4 gcc-12-12.2.0/debian/control.m4
--- gcc-12-12.2.0/debian/control.m4 2022-11-02 09:19:37.0 -0700
+++ gcc-12-12.2.0/debian/control.m4 2022-12-02 18:28:07.0 -0700
@@ -3263,7 +3263,7 @@
 Pre-Depends: ${misc:Pre-Depends}
 ')`'dnl
 Priority: optional
-Depends: BASEDEP, libgcc`'PV-dev, binutils, ${shlibs:Depends}, ${misc:Depends}
+Depends: BASEDEP, libgcc`'PV-dev, binutils, ${dep:libcdev}, ${shlibs:Depends}, 
${misc:Depends}
 Breaks: python-gccjit (<< 0.4-4), python3-gccjit (<< 0.4-4)
 BUILT_USING`'dnl
 Description: GCC just-in-time compilation (shared library)


signature.asc
Description: PGP signature

Bug#752998: Re: Bug#752998: zfs dump magic

[王昊然]

> Now I'm confused. Your attached file is virtually identical to
> magic/Magic/zfs in the file(1) sources, and is present since 5.11
> which is in wheezy.

ZFS stream (dump) format is not ZFS on-disk format.

Bug#1024639: Patch

[王昊然]

Control: tags 1024639 + patch


$ truncate --size 1GiB /tmp/test-hfs+
$ mkfs.hfsplus /tmp/test-hfs+
Initialized /tmp/test-hfs+ as a 1024 MB HFS Plus volume
$ file --magic-file magic/Magdir/ /tmp/test-hfs+
/tmp/test-hfs+: Apple HFS Plus version 4 data (mounted) last mounted
by: '10.0', created: Sun Dec  4 01:56:42 2022, last modified: Sat Dec
3 17:56:42 2022, last checked: Sat Dec  3 17:56:42 2022, block size:
4096, number of blocks: 262144, free blocks: 259062
$ truncate --size 1GiB /tmp/test-hfsx
$ mkfs.hfsplus -s /tmp/test-hfsx
Initialized /tmp/test-hfsx as a 1024 MB HFS Plus volume
$ file --magic-file magic/Magdir/ /tmp/test-hfsx
/tmp/test-hfsx: Apple HFS Plus Extended version 5 data (mounted) last
mounted by: '10.0', created: Sun Dec  4 01:56:54 2022, last modified:
Sat Dec  3 17:56:54 2022, last checked: Sat Dec  3 17:56:54 2022,
block size: 4096, number of blocks: 262144, free blocks: 259062
--- magic/Magdir/macintosh.orig 2021-05-13 00:30:24.0 +0800
+++ magic/Magdir/macintosh  2022-12-04 01:46:25.546650030 +0800
@@ -447,7 +447,7 @@
 >>>0x412   beshort x   number of blocks: %d,
 >>>0x424   pstring x   volume name: %s
 
-0x400  beshort 0x482B  Macintosh HFS Extended
+0  namehfsplus
 >&0beshort x   version %d data
 >0 beshort 0x4C4B  (bootable)
 >0x404 belong  ^0x0100 (mounted)
@@ -466,6 +466,11 @@
 >&42   belong  x   number of blocks: %d,
 >&46   belong  x   free blocks: %d
 
+0x400  beshort 0x482B  Apple HFS Plus
+>&0use hfsplus
+0x400  beshort 0x4858  Apple HFS Plus Extended
+>&0use hfsplus
+
 ## AFAIK, only the signature is different
 # same as Apple Partition Map
 # GRR: This magic is too weak, it is just "TS"

Bug#1025384: USERGROUPS and users as supplementary group

[Marc Haber]

Package: adduser
Version: 3.129
Severity: minor

Hi,

this might be a corollary bug for #678615, where we settled on new
non-system users getting users as a group unless adduser is differently
configured. That was when USERGROUPS was still "no" in the default.

Now, we have USERGROUPS=yes, and an adduser coming in default
configuration will give a new non-system user its usergroup AND users as
supplementary group even if ADD_EXTRA_GROUPS is 0.

To make things more interesting: set EXTRA_GROUPS="plugdev" and a newly
created non-system user will still get "users" as supplementary group.
Se ADD_EXTRA_GROUPS=1 in addition and see "users" and "plugdev" as
supplementary group.

It looks like "users" is somehow specialcased even in the case of
USERGROUPS=yes which is probably not what we want.

But, what DO we want?

Greetings
Marc

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

[Steve McIntyre]

Hi Daniel!

On Sat, Dec 03, 2022 at 01:41:51AM +1100, Daniel Axtens wrote:
>Steve McIntyre  writes:
>>
>> программист некто (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! :-)
>
>Ergh, apologies for the regression.
>
>[somewhat off-topic: The fix came from a crash derived from fuzzing. I
>am not really knowledgeable about f2fs either - I was just trying to do
>my best based on what we could derive from the existing driver. In
>general, filesystems are a nightmare for fuzzing fixes because testing
>beyond the (quite decent!) tests that the grub test-suite runs is very
>challenging. There is usually no-one who is both involved in grub
>security and an expert on any given file system either. We do the best
>we can. Sadly our regression rate has been climbing, so we may need to
>come up with some other way to secure file systems or get access to
>sufficient expertise in the future.]

ACK. I used to develop amd maintain filesystems as a day job, I
understand the issue! Writing good and comprehensive tests is hard,
and therefore quite rare!

>I had a massive, massive work-in-progress spiel where I looked at this
>code and compared the linux code and counted sizes and so on and so
>forth. I was getting nowhere. But eventually I realised I had just made
>an off-by-one error in the test. You're allowed to have up to n =
>NAT_JOURNAL_ENTRIES entries _inclusive_, because the loop below uses i <
>n, not i <= n. D'oh.

Doh indeed! :-)

>Please try the following:
>
>diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
>index df6beb544cbd..855e24618c2b 100644
>--- a/grub-core/fs/f2fs.c
>+++ b/grub-core/fs/f2fs.c
>@@ -650,7 +650,7 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, 
>grub_uint32_t nid,
>   grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats);
>   grub_uint16_t i;
> 
>-  if (n >= NAT_JOURNAL_ENTRIES)
>+  if (n > NAT_JOURNAL_ENTRIES)
> return grub_error (GRUB_ERR_BAD_FS,
>"invalid number of nat journal entries");
>
>
>If for some reason that doesn't work, please add the following debug
>code and report the results:
>
>diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
>index 855e24618c2b..6e49a6d17b7a 100644
>--- a/grub-core/fs/f2fs.c
>+++ b/grub-core/fs/f2fs.c
>@@ -643,6 +643,10 @@ get_nat_journal (struct grub_f2fs_data *data)
>   return err;
> }
> 
>+#ifdef GRUB_UTIL
>+#include 
>+#endif
>+
> static grub_err_t
> get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, grub_uint32_t nid,
>   grub_uint32_t *blkaddr)
>@@ -650,6 +654,10 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data 
>*data, grub_uint32_t nid,
>   grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats);
>   grub_uint16_t i;
> 
>+#ifdef GRUB_UTIL
>+  fprintf(stderr, "%s: n = %hu\n", __func__, n);
>+#endif
>+
>   if (n > NAT_JOURNAL_ENTRIES)
> return grub_error (GRUB_ERR_BAD_FS,
>"invalid number of nat journal entries");
>

программист некто: could you please try these changes and report back?

>Amusingly the debug code shows that the grub-fs-tester tests always have
>n = 0, which makes sense for a test that doesn't really stress the
>file-system, and also explains why we didn't catch the bug when it was
>introduced.

Right.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#1024626: Blender removal for 32-bit architectures

[John Scott]

Hi,

I see from previous mails that Blender upstream has decided not to support 
32-bit architectures anymore. This is a friendly ping that the maintainer will 
request its removal so it may migrate into Bookworm.

Thanks,
John


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

Bug#1005840: claws-mail-themes: includes non-free content (CC-by-nc-sa-v3.0)

[Francesco Poli]

Control: fixed -1 claws-mail-themes/20221017+dfsg.1-1


[it seems to me that control directives in messages sent to -done
addresses are not processed... I am repeating the directive for this
reason]


On Sat, 3 Dec 2022 18:08:55 +0100 Ricardo Mones wrote:

> control: fixed -1 claws-mail-themes/20221017+dfsg.1-1
> 
> On Sun, 27 Feb 2022 17:55:23 +0100
> Francesco Poli  wrote:
> […]
> > > Yeah, agreed, but given I doubt that can be possible at this point
> > > to make upstream release a new tarball just to fix those bits,
> > > specially without a contact address. Will try to ask upstream if
> > > somebody has his contact, otherwise I'm afraid the only solution
> > > will be the removal.  
> > 
> > Thanks for willing to attempt this.
> > Let's see how it goes...
> 
> Despite the time passed, efforts were worth it and it went well :-)
[...]

This is great news, indeed!
Thanks for your efforts.


Now, if only the licensing status of Fugue/* were also ironed out...
See the original bug report!  ;-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1WtcqfWOFA.pgp
Description: PGP signature

Bug#1025383: starfighter-data: Starfighter segfaults after the last battle

[Michael Krylov]

Package: starfighter-data
Version: 2.3.3-1
Severity: normal

Dear Maintainer,

First of all, thanks for making a debian package of this game, it was
really fun and nice to play.

But the very end of the game turned out to be quite anticlimatic. The
game segfaults after beating the last boss.

I took my time to investigate the cause of this segfault and apparently
it happens because game fails to open its credits file:

/usr/share/starfighter/data/credits.txt

I found that file in /usr/share/doc/starfighter/ and I don't think it
belongs there as it is not just a text file with credits, but more like
a game asset. But maybe it does, so in that case could you please add a
symlink like you did with TakaoPGothic.ttf?  I think it will only
require adding the following line into debian/starfighter.links file:

/usr/share/doc/starfighter/credits.txt usr/share/starfighter/data/credits.txt

Thanks in advance!

-- System Information:
Debian Release: 11.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-18-686 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1022469: python-pint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Michael Banck]

tags 1022469 +patch
thanks

Hi,

On Wed, Nov 23, 2022 at 07:48:47PM +1100, Stuart Prescott wrote:
> pint is incompatible with babel > 2.8; unfortunately, Debian now has babel
> 2.10.
> 
> So far, upstream has only noted the compatibility with version pinning.
> 
> https://github.com/hgrecco/pint/issues/1219
> 
> Upstream tests for newer releases of pint also now fail due to this same
> reason.

Looks like they got a work-around here in (since closed) PR #1401:
https://github.com/hgrecco/pint/commit/eb4e13428a3ede09148b76c71bc5b8cddb169176.patch
 
If I stick this (also attached) patch in, the testsuite passes fine.

> (and we should enable autopkgtest tests for pint and then this would have
> been caught as soon as babel > 2.8 was uploaded)

Yeah.


Michael
>From eb4e13428a3ede09148b76c71bc5b8cddb169176 Mon Sep 17 00:00:00 2001
From: Hernan 
Date: Wed, 27 Oct 2021 20:36:40 -0300
Subject: [PATCH] Support for babel > 2.8

Close #1400, #1219 and #1296.
---
 pint/formatting.py| 11 ---
 pint/testsuite/test_issues.py |  8 
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/pint/formatting.py b/pint/formatting.py
index a04205dd9..528f4e03e 100644
--- a/pint/formatting.py
+++ b/pint/formatting.py
@@ -333,9 +333,14 @@ def formatter(
 # Don't remove this positional! This is the format used in Babel
 key = pat.replace("{0}", "").strip()
 break
-division_fmt = compound_unit_patterns.get("per", {}).get(
-babel_length, division_fmt
-)
+
+tmp = compound_unit_patterns.get("per", {}).get(babel_length, division_fmt)
+
+try:
+division_fmt = tmp.get("compound", division_fmt)
+except AttributeError:
+division_fmt = tmp
+
 power_fmt = "{}{}"
 exp_call = _pretty_fmt_exponent
 if value == 1:
diff --git a/pint/testsuite/test_issues.py b/pint/testsuite/test_issues.py
index ed781b72f..9d4167c02 100644
--- a/pint/testsuite/test_issues.py
+++ b/pint/testsuite/test_issues.py
@@ -824,6 +824,14 @@ def test_issue_1300(self):
 m = ureg.Measurement(1, 0.1, "meter")
 assert m.default_format == "~P"
 
+def test_issue_1400(self, sess_registry):
+q1 = 3 * sess_registry.W
+q2 = 3 * sess_registry.W / sess_registry.cm
+assert q1.format_babel("~", locale="es_Ar") == "3 W"
+assert q1.format_babel("", locale="es_Ar") == "3 vatios"
+assert q2.format_babel("~", locale="es_Ar") == "3.0 W / cm"
+assert q2.format_babel("", locale="es_Ar") == "3.0 vatios por centímetros"
+
 
 if np is not None:
 

Bug#1024395: CONFIG_INTEGRITY_PLATFORM_KEYRING was missing for mokutil --list-enrolled to work

[Éric Valette]

The error and font issue. The fact that shim-signed has a différent version 
than the helper part also.

The CONFIG_INTEGRITY_PLATFORM_KEYRING

Fixes my mokutil --list-enrolled problem

3 déc. 2022 17:24:10 Steve McIntyre :

> On Sat, Nov 26, 2022 at 05:38:58PM +0100, Eric Valette wrote:
>> CONFIG_INTEGRITY_PLATFORM_KEYRING=y
>> 
>> But the bug is still there
> 
> *which* bug - the missing key, or the font issue?
> 
> -- 
> Steve McIntyre, Cambridge, UK.    st...@einval.com
> < liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#1025055: transition: qtwebengine-opensource-src

[Dmitry Shachnev]

Control: tags -1 -moreinfo

Hi Sebastian!

On Sat, Dec 03, 2022 at 03:46:59PM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
>
> Thanks for working on this. Please let us know once you think it's
> ready.

It is ready. Tested by me and by Lisandro.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1025381: malcontent: switch from transitional policykit-1 to polkitd

[Patrice Duroux]

Package: malcontent
Version: 0.11.0-3
Severity: wishlist

Dear Maintainer,

I think that malcontent does not require pkexec, so depending on polkitd in
place of policykit-1 should be enough.

Regards,
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 malcontent depends on:
ii  accountsservice  22.08.8-1+b1
ii  gir1.2-glib-2.0  1.74.0-2
ii  gir1.2-malcontent-0  0.11.0-3
pn  policykit-1  
ii  python3  3.10.6-3
ii  python3-gi   3.42.2-3

malcontent recommends no packages.

malcontent suggests no packages.

-- no debconf information

Bug#1024395: CONFIG_INTEGRITY_PLATFORM_KEYRING was missing for mokutil --list-enrolled to work

[Steve McIntyre]

On Sat, Nov 26, 2022 at 05:38:58PM +0100, Eric Valette wrote:
>CONFIG_INTEGRITY_PLATFORM_KEYRING=y
>
>But the bug is still there

*which* bug - the missing key, or the font issue?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#1024395: grub-efi-amd64-signed: after upgrade to 1+2.06+5 I get errors when booting (although I manage to boot)

[Steve McIntyre]

Control: severity -1 important

Hi Eric,

On Fri, Nov 18, 2022 at 07:24:32PM +0100, Eric Valette wrote:
>Package: grub-efi-amd64-bin
>Version: 1+2.06+5
>Severity: grave
>Tags: security
>Justification: user security hole
>X-Debbugs-Cc: Debian Security Team 
>
>After upgrade to 2.06-5, I get an error message "prohibited by secure boot 
>policy" and it boot
>with a strange look with \xe7caracaters instead of lines.

Right. Those are both part of the security fixes that went into the
latest grub upload. It's trying to load fonts from /usr, but that's
now blocked when doing Secure Boot. It's basically cosmetic, but
obviously we don't want to leave it like this. We're talking upstream
about the best way to fix this up now.

>I build my own kernel and enrolled my owns keys, sign the linux
>kernel binarry and the mdoules with the keys. Everythong was working
>fine with 2.06-3.
>
>I also noticed that my enrolled keys is no more listed via "mokutil
>--list-enrolled". Although no key were cleared.

OK. I believe that is more likely an unrelated issue.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#1023787: transition: liblxqt

[陳昌倬]

On Tue, Nov 29, 2022 at 07:33:11PM +0100, Paul Gevers wrote:
> Hi ChangZhuo,
> 
> On 29-11-2022 06:29, ChangZhuo Chen (陳昌倬) wrote:
> > Please help to
> > migrate libfm-qt in new queue [0] so that we can prepare the migration.
> 
> That's not under our control. You'll need to talk to ftp-master (typically a
> note with explanation on IRC helps).

Hi Paul,

Do we need to submit transition for lxqt-globalkeys [0], which is
totally covered by liblxqt transition?


[0] https://release.debian.org/transitions/html/auto-lxqt-globalkeys.html


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1025380: python3-fissix: SyntaxError: Missing parentheses in call to 'print'

[Jakub Wilk]

Package: python3-fissix
Version: 21.6.6-2
Severity: serious

python3-fissix fails to install:

   Setting up python3-fissix (21.6.6-2) ...
 File "/usr/lib/python3/dist-packages/fissix/fissix/tests/data/bom.py", 
line 2
   print "BOM BOOM!"
   ^
   SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
   dpkg: error processing package python3-fissix (--configure):
installed python3-fissix package post-installation script subprocess 
returned error exit status 1
   Processing triggers for libc-bin (2.36-6) ...
   Errors were encountered while processing:
python3-fissix
   E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Architecture: i386

Versions of packages python3-fissix depends on:
ii  python3-appdirs  1.4.4-3
ii  python3  3.10.6-3

--
Jakub Wilk

Bug#1025379: colord: replace deps to the transtional policykit-1

[Patrice Duroux]

Package: colord
Version: 1.4.6-2.1
Severity: wishlist

Dear Maintainer,

I checked using Debian Code Search and I think that pkexec is not needed by
colord so deps on polkitd should be enough then.

Regards,
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 colord depends on:
ii  acl  2.3.1-2
ii  adduser  3.129
ii  colord-data  1.4.6-2.1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.36-6
ii  libcolord2   1.4.6-2.1
ii  libcolorhug2 1.4.6-2.1
ii  libdbus-1-3  1.14.4-1
ii  libglib2.0-0 2.74.2-1
ii  libgudev-1.0-0   237-2
ii  libgusb2 0.3.10-1
ii  liblcms2-2   2.13.1-1+b1
ii  libpolkit-gobject-1-0122-1
ii  libsane1 1.1.1-6+b1
ii  libsqlite3-0 3.40.0-1
ii  libsystemd0  252.2-1
ii  policykit-1  122-1

colord recommends no packages.

Versions of packages colord suggests:
pn  colord-sensor-argyll  

-- no debconf information

Bug#1025378: dracut FTBFS

[Helge Deller]

Package: dracut
Version: 057+157-4
Tags: hppa, patch, ftbfs

I wondered why dracut failed to build on hppa. You can
see the various log builds here:
https://buildd.debian.org/status/logs.php?pkg=dracut=hppa

Interestingly, dracut builds sucessfully on the build servers
atlas, panama, sap and physik, which all are physical machines.
pacific, pasta and paq are VMs running qemu-user (on x86 machines),
which all failed.

On the failing servers the log file shows:
...
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- --systemdsystemunitdir=/lib/systemd/system 
--libdir=/usr/lib
./configure --build=hppa-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/hppa-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--systemdsystemunitdir=/lib/systemd/system --libdir=/usr/lib
Ignoring unknown option '--build=hppa-linux-gnu'
Ignoring unknown option '--disable-option-checking'
Ignoring unknown option '--disable-silent-rules'
Ignoring unknown option '--runstatedir=/run'
Ignoring unknown option '--disable-maintainer-mode'
Ignoring unknown option '--disable-dependency-tracking'
debian/fix-revdate
make[1]: *** [debian/rules:12: override_dh_auto_configure] Error 127

The interesting part is the file "debian/fix-revdate".
This file is basically an ASCII file, although it contains shell script
commands. Note that it's missing the "#!/bin/bash" or "!/bin/sh" header!

So, when make calls "debian/fix-revdate" you can see with strace (on amd64 !):
[pid 17219] getuid()= 1000
[pid 17219] setresuid(-1, 1000, -1) = 0
[pid 17219] getgid()= 1000
[pid 17219] setresgid(-1, 1000, -1) = 0
[pid 17219] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 17219] execve("debian/fix-revdate", ["debian/fix-revdate"], 0x5620f68be870 
/* 102 vars */) = -1 ENOEXEC (Exec format error)
[pid 17219] exit_group(127) = ?
[pid 17188] <... clone resumed>)= 17219

As you can see, even on amd64 it reports back errorcode 127 (like on hppa).
Nevertheless, on amd64 the build continues while it stops on hppa.
I don't know (yet) why this happens, but this bug report here is about the
fact that you try to run "debian/fix-revdate" without it being an executable

There are two ways to fix it,
a) either add "!/bin/bash" to the top of the generated file debian/fix-revdate, 
or
b) add $(SHELL) in front of calling debian/fix-revdate in the rules file, like 
this:

diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org  2022-12-03 12:28:19.235988795 +
+++ ./debian/rules  2022-12-03 12:28:38.104169319 +
@@ -9,7 +9,7 @@ DPKG_EXPORT_BUILDTOOLS=1

 override_dh_auto_configure:
dh_auto_configure -- --systemdsystemunitdir=/lib/systemd/system 
--libdir=/usr/lib
-   debian/fix-revdate
+   $(SHELL) debian/fix-revdate

I suggest option b, which is to change the rules file

Helge

Bug#1025376: libcds: FTBFS on mips64el, s390x, riscv64

[Bo YU]

Hi,
On Sat, Dec 03, 2022 at 02:30:14PM +0100, John Paul Adrian Glaubitz wrote:

Hello Bo!

On 12/3/22 14:12, Bo YU wrote:

The patch I have tested it on my local machines, please consider to
apply it in next upload. thanks.


Could you please extend your patch to add support for alpha as well?

For alpha, we need:

#elif defined(__alpha__)
#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_ALPHA
#define CDS_BUILD_BITS64
#define CDS_PROCESSOR__NICK   "alpha"



I have added support for alpha as your input and tested it on qemu.
Thanks.

--
Regards,
--
  Bo YU

diff -Nru libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch 
libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch
--- libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch1970-01-01 
07:30:00.0 +0730
+++ libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch2019-08-12 
01:23:22.0 +0800
@@ -0,0 +1,29 @@
+Description: add support for riscv64, mips64el, s390x, alpha
+Last-Update: 2022-12-03 
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/cds/compiler/gcc/compiler_macro.h
 b/cds/compiler/gcc/compiler_macro.h
+@@ -122,6 +122,22 @@
+ #   else
+ #   define CDS_BUILD_BITS32
+ #   endif
++#elif defined(__alpha__)
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_ALPHA
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "alpha"
++#elif defined(__mips__) && defined(_MIPSEL) && _MIPS_SIM == _ABI64
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_MIPS64EL
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "mips64el"
++#elif defined(__riscv) && __riscv_xlen == 64
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_RISCV64
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "riscv64"
++#elif defined(__s390x__)
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_S390X
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "s390x"
+ #else
+ #   if defined(CDS_USE_LIBCDS_ATOMIC)
+ #   error "Libcds does not support atomic implementation for the 
processor architecture. Try to use C++11-compatible compiler and remove 
CDS_USE_LIBCDS_ATOMIC flag from compiler command line"
diff -Nru libcds-2.3.3/debian/patches/series libcds-2.3.3/debian/patches/series
--- libcds-2.3.3/debian/patches/series  1970-01-01 07:30:00.0 +0730
+++ libcds-2.3.3/debian/patches/series  2019-08-12 01:23:22.0 +0800
@@ -0,0 +1 @@
+fix-ftbfs-on-some-arch.patch


signature.asc
Description: PGP signature

Bug#1025377: texstudio: Switch to libqtermwidget5-1-dev

[Sebastian Ramacher]

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

Unfortunately, qtermwidget bumpbed SONAME and also changed the name of
the -dev package. The new -dev package is called libqtermwidget5-1-dev.
Please adopt the package accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1025055: transition: qtwebengine-opensource-src

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-11-29 14:26:21 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release team,
> 
> This is a mini-transition that requires binNMU of just two packages:
> angelfish and qtwebview-opensource-src.
> 
> It is a new Qt WebEngine patch release with security fixes, and additionally
> I switched it to build with Python 3. The updated package is currently
> available in experimental. I want to wait a couple more days to collect
> feedback, and then I will be able to upload it to unstable.

Thanks for working on this. Please let us know once you think it's
ready.

Cheers

> 
> Ben file:
> 
> title = "qtwebengine-opensource-src";
> is_affected = .depends ~ "qtwebengine-abi-5-15-10" | .depends ~ 
> "qtwebengine-abi-5-15-11";
> is_good = .depends ~ "qtwebengine-abi-5-15-11";
> is_bad = .depends ~ "qtwebengine-abi-5-15-10";
> 
> --
> Dmitry Shachnev



-- 
Sebastian Ramacher

Bug#1024093: The problem is still present in 0.3.61-1

[James Bottomley]

I just tested this out with the same results as previously reported

James

Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

[Salvatore Bonaccorso]

Hi Louis,

On Tue, Nov 29, 2022 at 09:05:48AM +0100, Louis Bouchard wrote:
> Hello Salvatore,
> 
> Le 28/11/2022 à 19:22, Salvatore Bonaccorso a écrit :
> > Hi Louis,
> > 
> > The rough plan would be to have it included in the next bullseye point
> > release. That is scheduled to be on 17th of december[1]. It would be
> > great to recieve testing feedback actually on the change.
> > 
> >   [1] https://lists.debian.org/debian-live/2022/11/msg6.html
> > 
> > Regards,
> > Salvatore
> 
> Thank you for your quick & precise answer. I really appreciate.

One concern to enable CONFIG_AMD_MEM_ENCRYPT would be what earlier
resulted in #994453. But the good thing is at least that 711885906b5c
("x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
automatically") was backported to 5.10.y as well to 5.10.75, and this
has not changed since.

So as long we do not enable it by default it might still be sensible
to make the change for the next point release.

Regards,
Salvatore

Bug#1025216: setuptools: diff for NMU version 65.5.0-1.1

[Stefano Rivera]

Control: tags 1025216 + patch
Control: tags 1025216 + pending

Dear maintainer,

I've prepared an NMU for setuptools (versioned as 65.5.0-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru setuptools-65.5.0/debian/changelog setuptools-65.5.0/debian/changelog
--- setuptools-65.5.0/debian/changelog	2022-10-21 10:45:14.0 -0400
+++ setuptools-65.5.0/debian/changelog	2022-12-03 10:16:50.0 -0400
@@ -1,3 +1,11 @@
+setuptools (65.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install distutils-precedence.pth, to avoid packages need to hack import
+order in setup.py. Closes: #1025216
+
+ -- Stefano Rivera   Sat, 03 Dec 2022 10:16:50 -0400
+
 setuptools (65.5.0-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru setuptools-65.5.0/debian/python3-setuptools.install setuptools-65.5.0/debian/python3-setuptools.install
--- setuptools-65.5.0/debian/python3-setuptools.install	2022-01-18 08:56:42.0 -0400
+++ setuptools-65.5.0/debian/python3-setuptools.install	2022-12-03 10:14:56.0 -0400
@@ -1,2 +1,3 @@
 /usr/lib/python3.*/*-packages/setuptools*
 /usr/lib/python3.*/*-packages/_distutils_hack
+/usr/lib/python3.*/*-packages/distutils-precedence.pth

Bug#1022496: pulsemixer: FTBFS: error: Multiple top-level packages discovered in a flat-layout: ['snap', 'debian'].

[Diederik de Haas]

Control: tag -1 upstream patch
Control: forwarded -1 https://github.com/GeorgeFilipkin/pulsemixer/pull/71

On Sun, 23 Oct 2022 15:41:02 +0200 Lucas Nussbaum  wrote:
> Source: pulsemixer
> Version: 1.5.1-1
> Severity: serious
> Justification: FTBFS

I submitted a patch upstream, but upstream seems kind of dead.

So I also created a MR on salsa with the same fix:
https://salsa.debian.org/debian/pulsemixer/-/merge_requests/1

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

Bug#1025307: yosys mips64el build failure (fix)

[Scott Ashcroft]

On Sat, 2022-12-03 at 14:35 +0100, Daniel Gröber wrote:
> Hi Scott,
> 
> While mips64el was indeed fix it looks like now we have failures on
> armhf
> instead, which was working before the patch.
> 
> I've patched the test driver to print some more debug output and it
> looks
> like berkeley-abc is failing with SIGBUS on a number of tests. I
> tried to
> reproduce this in an armhf VM but it doesn't seem to reproduce there.
> I
> don't think it's a transient issue on the buildds either since -4 and
> -5
> both failed the same way on different hosts.
> 
> Got any ideas?

That last sucessful armhf build was on 14/11/2022 which was just before
you added the following changes to berkeley-abc:

Date: Wed, 16 Nov 2022 22:10:46 +0100
Source: berkeley-abc
Architecture: source
Version: 1.01+20221019git70cb339+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers

Changed-By: Daniel Gröber 
Changes:
 berkeley-abc (1.01+20221019git70cb339+dfsg-2) unstable; urgency=medium
 .
   * Add myself to Uploaders
   * Try to fix reproducibility on armhf

Maybe that armhf patch needs to be reverted?

Cheers,
Scott

Bug#1025307: yosys mips64el build failure (fix)

[Daniel Gröber]

Hi Scott,

While mips64el was indeed fix it looks like now we have failures on armhf
instead, which was working before the patch.

I've patched the test driver to print some more debug output and it looks
like berkeley-abc is failing with SIGBUS on a number of tests. I tried to
reproduce this in an armhf VM but it doesn't seem to reproduce there. I
don't think it's a transient issue on the buildds either since -4 and -5
both failed the same way on different hosts.

Got any ideas?

--Daniel

Bug#1025376: libcds: FTBFS on mips64el, s390x, riscv64

[John Paul Adrian Glaubitz]

Hello Bo!

On 12/3/22 14:12, Bo YU wrote:

The patch I have tested it on my local machines, please consider to
apply it in next upload. thanks.


Could you please extend your patch to add support for alpha as well?

For alpha, we need:

#elif defined(__alpha__)
#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_ALPHA
#define CDS_BUILD_BITS64
#define CDS_PROCESSOR__NICK   "alpha"

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1025376: libcds: FTBFS on mips64el, s390x, riscv64

[Bo YU]

Source: libcds
Version: 2.3.3-2
Severity: important
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org,
debian-m...@lists.debian.org, debian-s...@lists.debian.org

Dear Maintainer,

The package has a ftbfs issue on misp64el, s390x, riscv64 arch. like:
```
/<>/cds/algo/int_algo.h:80:28: error: redefinition of ‘uint64_t 
cds::beans::log2floor(uint64_t)’
 static inline uint64_t log2floor( uint64_t n )
^
In file included from /<>/cds/os/alloc_aligned.h:31,
 from /<>/cds/os/topology.h:14,
 ...
 from /<>/cds/init.h:10,
 from /<>/src/init.cpp:6:
/<>/cds/algo/int_algo.h:80:28: error: redefinition of ‘uint64_t 
cds::beans::log2floor(uint64_t)’
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=libcds=riscv64=2.3.3-2=1565549535=0
https://buildd.debian.org/status/fetch.php?pkg=libcds=mips64el=2.3.3-2=1565604703=0
https://buildd.debian.org/status/fetch.php?pkg=libcds=s390x=2.3.3-2=1569778976=0


The patch I have tested it on my local machines, please consider to
apply it in next upload. thanks.

There is a PR to support s390x[0] and I will forward this patch to
upstream also.

[0]: https://github.com/khizmax/libcds

-- 
Regards,
--
  Bo YU

diff -Nru libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch 
libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch
--- libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch1970-01-01 
07:30:00.0 +0730
+++ libcds-2.3.3/debian/patches/fix-ftbfs-on-some-arch.patch2019-08-12 
01:23:22.0 +0800
@@ -0,0 +1,25 @@
+Description: add support for riscv64, mips64el, s390x 
+Last-Update: 2022-12-03 
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/cds/compiler/gcc/compiler_macro.h
 b/cds/compiler/gcc/compiler_macro.h
+@@ -122,6 +122,18 @@
+ #   else
+ #   define CDS_BUILD_BITS32
+ #   endif
++#elif defined(__mips__) && defined(_MIPSEL) && _MIPS_SIM == _ABI64
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_MIPS64EL
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "mips64el"
++#elif defined(__riscv) && __riscv_xlen == 64
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_RISCV64
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "riscv64"
++#elif defined(__s390x__)
++#define CDS_PROCESSOR_ARCHCDS_PROCESSOR_S390X
++#define CDS_BUILD_BITS64
++#define CDS_PROCESSOR__NICK   "s390x"
+ #else
+ #   if defined(CDS_USE_LIBCDS_ATOMIC)
+ #   error "Libcds does not support atomic implementation for the 
processor architecture. Try to use C++11-compatible compiler and remove 
CDS_USE_LIBCDS_ATOMIC flag from compiler command line"
diff -Nru libcds-2.3.3/debian/patches/series libcds-2.3.3/debian/patches/series
--- libcds-2.3.3/debian/patches/series  1970-01-01 07:30:00.0 +0730
+++ libcds-2.3.3/debian/patches/series  2019-08-12 01:23:22.0 +0800
@@ -0,0 +1 @@
+fix-ftbfs-on-some-arch.patch


signature.asc
Description: PGP signature

Bug#1025375: hydrogen-doc: documentation binary package is almost empty, should it be dropped entirely?

[Francesco Poli (wintermute)]

Package: hydrogen-doc
Version: 1.2.0~beta1+dfsg-1
Severity: important

Hello and thanks for maintaining Hydrogen in Debian!

I noticed that the hydrogen-doc binary package is now almost empty:

  $ dpkg -L hydrogen-doc
  /.
  /usr
  /usr/share
  /usr/share/doc
  /usr/share/doc/hydrogen-doc
  /usr/share/doc/hydrogen-doc/changelog.Debian.gz
  /usr/share/doc/hydrogen-doc/changelog.gz
  /usr/share/doc/hydrogen-doc/copyright
  /usr/share/hydrogen
  /usr/share/hydrogen/data
  /usr/share/hydrogen/data/new_tutorial
  /usr/share/hydrogen/data/new_tutorial/img_tutorial
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Bridge1_4th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Bridge3_3a_hh.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/C3_6+7.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Intro4th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/PatternBase1.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/PatternBase2.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1b.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1c.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1d.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Verse8th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseAll.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseBridge.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseBridge_hh.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/warn.png
  /usr/share/lintian
  /usr/share/lintian/overrides
  /usr/share/lintian/overrides/hydrogen-doc
  /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  /usr/share/doc/hydrogen-doc/new_tutorial
  $ ls -l /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  lrwxrwxrwx 1 root root 23 Nov 27 20:22 
/usr/share/doc/hydrogen-doc/manual_and_old_tutorial -> ../../hydrogen/data/doc
  $ readlink -f /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  /usr/share/hydrogen/data/doc
  $ ls /usr/share/hydrogen/data/doc
  ls: cannot access '/usr/share/hydrogen/data/doc': No such file or directory


Basically a bunch of screenshots and a dangling symlink...

Then I took a look at the 'changelog.Debian.gz' file, which says:

[...]
  * Clean Hydrogen of currently non-DFSG new documentation
- Use Files-Excluded to exclude tutorial_en.html, which has no source.
[...]

OK, I totally agree with excluding non-free documentation (while in
the meanwhile contacting upstream and persuading them to properly
release source for the documentation and license it under DFSG-free
terms[^NOTE], something which I hope you have already done or are going
to do very soon!).

[^NOTE]: the best option would to license documentation under the same terms
 as the documented program (GPL-2+ in this case)...

But, if, after excluding non-free documentation, almost nothing remains
in the -doc binary package, I wonder what's the point in keeping this
binary package around...

Is there a reasonable hope that the documentation will be re-licensed
in a DFSG-free manner (with source available) real soon now?
If not, I would say that binary package 'hydrogen-doc' could be
dropped entirely...

Please let me know what you think.
Thanks for your time!   :-)


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

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

-- no debconf information

Bug#1025350: qt6ct: changing font has no effect

[Peter B]

One further thought.

I assume you are using TrueType fonts.
Which specific font(s) are you having the issue with?

I'm using liberation fonts here.  {fonts-liberation2}

Bug#1025350: qt6ct: changing font has no effect

[Peter B]

On 03/12/2022 00:08, Christopher Cramer wrote:

Package: qt6ct
Version: 0.7-2
Severity: normal
X-Debbugs-Cc: tsuyo...@yumegakanau.org

I use GNOME. I was trying out qtcreater. I do not regularly use any
Qt applications.  The font size in qtcreator's interface is too small
for me. I read that qt6ct can be used to configure the font size, if
you are not using KDE. So I installed it and ran it, went to the font
dialog in qt6ct, and set the fonts to what I want. However, this has no
effect on qtcreator's interface font size. Incidentally, it also appears
to have no effect on qt6ct's interface font size. When I rerun qt6ct,
the font that I selected is still there, so it is getting saved.

I also tried the "Create fonts.conf" button in qt6ct. This did change
the fonts in the qtcreator (and qt6ct) interface. But it only made the
same too-small fonts look pixellated. I was, luckily, able to revert
this by using the "Remove fonts.conf" button.

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.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 qt6ct depends on:
ii  libc6   2.36-6
ii  libgcc-s1   12.2.0-9
ii  libqt6core6 [qt6-base-abi]  6.3.1+dfsg-10+b1
ii  libqt6gui6  6.3.1+dfsg-10+b1
ii  libqt6svg6  6.3.1-2
ii  libqt6widgets6  6.3.1+dfsg-10+b1
ii  libstdc++6  12.2.0-9
ii  qt6-qpa-plugins 6.3.1+dfsg-10+b1

qt6ct recommends no packages.

qt6ct suggests no packages.

-- no debconf information


Just tested font changing for qt6ct itself and qtcreator, and fonts are 
changing just fine,
so I can't reproduce this problem.

However, I'm using Xfce, so maybe this is a Gnome issue?
Fonts do take a little while to change though.

Is qt5ct working for you?

Bug#921461: homepage of tuxtype is no longer available

[Bastian Germann]

I am handing in a NMU based on 
https://salsa.debian.org/tux4kids-pkg-team/tuxtype/-/merge_requests/2.
debdiff attached.diff -Nru tuxtype-1.8.3/debian/changelog tuxtype-1.8.3/debian/changelog
--- tuxtype-1.8.3/debian/changelog  2022-12-03 13:06:06.0 +0100
+++ tuxtype-1.8.3/debian/changelog  2022-12-03 12:55:55.0 +0100
@@ -1,3 +1,15 @@
+tuxtype (1.8.3-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/copyright: Fix source (Closes: #921461).
+
+  [ Debian Janitor ]
+  * Upgrade to newer source format.
+  * Update standards version to 4.4.1, no changes needed.
+  * Add missing colon in closes line.
+
+ -- Bastian Germann   Sat, 03 Dec 2022 12:55:55 +0100
+
 tuxtype (1.8.3-5) unstable; urgency=medium
 
   * d/control:
@@ -398,7 +410,7 @@
 
 tuxtype (0.5.2-3) unstable; urgency=low
 
-  * tuxtype/images/Makefile.am fix, closes #84446
+  * tuxtype/images/Makefile.am fix, closes: #84446
 
  -- Laurence J. Lane   Fri,  2 Feb 2001 20:11:09 -0500
 
diff -Nru tuxtype-1.8.3/debian/control tuxtype-1.8.3/debian/control
--- tuxtype-1.8.3/debian/control2022-12-03 13:06:06.0 +0100
+++ tuxtype-1.8.3/debian/control2022-12-03 12:54:46.0 +0100
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Holger Levsen 
-Standards-Version: 4.4.0
+Standards-Version: 4.4.1
 Build-Depends: debhelper-compat (=12),
  libsdl-mixer1.2-dev,
  libsdl-image1.2-dev,
diff -Nru tuxtype-1.8.3/debian/copyright tuxtype-1.8.3/debian/copyright
--- tuxtype-1.8.3/debian/copyright  2022-12-03 13:06:06.0 +0100
+++ tuxtype-1.8.3/debian/copyright  2022-12-03 12:55:55.0 +0100
@@ -5,13 +5,9 @@
 
 

 
-The upstream GIT is available here:
-http://anonscm.debian.org/gitweb/?p=tux4kids/tuxtype.git
+Source: https://github.com/tux4kids/tuxtype/tags
 
-Releases are available here:
-http://tux4kids.alioth.debian.org
-
-Upstream Authors: Sam Hart , Jesse D. Andrews 
,
+Upstream-Contact: Sam Hart , Jesse D. Andrews 
,
  David Bruce  and others
 
 
diff -Nru tuxtype-1.8.3/debian/patches/debian-changes 
tuxtype-1.8.3/debian/patches/debian-changes
--- tuxtype-1.8.3/debian/patches/debian-changes 1970-01-01 01:00:00.0 
+0100
+++ tuxtype-1.8.3/debian/patches/debian-changes 2022-12-03 12:55:55.0 
+0100
@@ -0,0 +1,188 @@
+This is an autogenerated patch header for a single-debian-patch file. The
+delta against upstream is either kept as a single patch, or maintained
+in some VCS, and exported as a single patch instead of more manageable
+atomic patches.
+
+--- tuxtype-1.8.3.orig/po/nl.po
 tuxtype-1.8.3/po/nl.po
+@@ -1,21 +1,22 @@
+ # Translation of tuxtype.po to Dutch.
+ # This file is distributed under the same license as the PACKAGE package.
+-# FIRST AUTHOR , YEAR.
+-# Mobin M , 2008
+ #
+-#, fuzzy
++# Mobin M , 2008.
++# Simon Oosthoek , 2015.
+ msgid ""
+ msgstr ""
+ "Project-Id-Version: Tuxtype\n"
+ "Report-Msgid-Bugs-To: tux4kids-tuxtype-...@lists.alioth.debian.org\n"
+ "POT-Creation-Date: 2012-02-02 20:16-0600\n"
+-"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+-"Last-Translator: FULL NAME \n"
++"PO-Revision-Date: 2015-01-06 16:45+0100\n"
++"Last-Translator: Simon Oosthoek \n"
+ "Language-Team: LANGUAGE \n"
+ "Language: nl\n"
+ "MIME-Version: 1.0\n"
+ "Content-Type: text/plain; charset=UTF-8\n"
+ "Content-Transfer-Encoding: 8bit\n"
++"Plural-Forms: nplurals=2; plural=(n != 1);\n"
++"X-Generator: Lokalize 1.5\n"
+ 
+ #: src/loaders.c:98 src/main.c:161 src/playgame.c:654
+ msgid "Fish"
+@@ -38,12 +39,10 @@ msgid "Paused!"
+ msgstr "Pauze!"
+ 
+ #: src/pause.c:328
+-#, fuzzy
+ msgid "Press escape again to return to menu"
+ msgstr "terug naar het menu? druk op escape"
+ 
+ #: src/pause.c:337
+-#, fuzzy
+ msgid "Press space bar to return to game"
+ msgstr "terug naar het spel? druk op spatiebalk"
+ 
+@@ -71,11 +70,11 @@ msgstr "Echt Moeilijk"
+ # general stuff
+ #: src/playgame.c:659
+ msgid "Practice"
+-msgstr "Vingeroefeningen"
++msgstr "Oefenen"
+ 
+ #: src/playgame.c:670
+ msgid "Congratulations"
+-msgstr "Gefeliciteerd !"
++msgstr "Gefeliciteerd!"
+ 
+ #: src/playgame.c:674
+ msgid "Oh No!"
+@@ -83,31 +82,31 @@ msgstr "Oh Nee!"
+ 
+ #: src/practice.c:626
+ msgid "sec"
+-msgstr ""
++msgstr "sec"
+ 
+ #: src/practice.c:1440
+ msgid "Time"
+-msgstr ""
++msgstr "Tijd"
+ 
+ #: src/practice.c:1444
+ msgid "Chars"
+-msgstr ""
++msgstr "Tekens"
+ 
+ #: src/practice.c:1448
+ msgid "CPM"
+-msgstr ""
++msgstr "TPM"
+ 
+ #: src/practice.c:1452
+ msgid "WPM"
+-msgstr ""
++msgstr "WPM"
+ 
+ #: src/practice.c:1456
+ msgid "Errors"
+-msgstr ""
++msgstr "Fouten"
+ 
+ #: src/practice.c:1460
+ msgid "Accuracy"
+-msgstr ""
++msgstr "Precisie"
+ 
+ #: src/titlescreen.c:99
+ msgid "Fish Cascade"
+@@ -116,7 +115,7 @@ msgstr "Vallende Vissen"
+ # "Space Cadet" is level 1 in comet zap
+ #: src/titlescreen.c:99
+ msgid "Space Cadet"
+-msgstr 

Bug#1025001: gitlab: Some UI elements, including buttons, are replaced with "undefined"

[Maximilian Stein]

Dear Maintainer,

I am indeed experiencing the same issues since the last upgrade. I 
noticed, however, that some buttons are still there and useable, but 
they are simply invisible unless hovered or clicked (i.e., they only 
lack text). Especially modal dialogs are entirely unusable, though.


Best,
Max

Bug#1025374: firefox: reproducible crashes on various websites

[Vincent Lefevre]

Package: firefox
Version: 107.0-1
Severity: grave
Justification: renders package unusable
Tags: upstream
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1803899

Since FF 107, I've noticed crashes on several websites, including
Facebook (even just after a restart).

In particular, I can reproduce the crash on http://www.sylvainshunt.com
(where I don't expect the contents to change, so this should be a good
testcase) with a new profile. Upstream's Firefox Nightly is also
affected.

I don't know whether all these crashes are due to the same bug, though.
But I had never had any such crash with FF in the previous months, and
even years, IIRC.

-- Package-specific info:


-- Addons package information

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 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 firefox depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.13.1-4.5
ii  libasound2   1.2.8-1
ii  libatk1.0-0  2.46.0-4
ii  libc62.36-6
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.4-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgtk-3-0   3.24.35-1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.85-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libstdc++6   12.2.0-9
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.1-2
ii  libx11-xcb1  2:1.8.1-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:3.3.17-7.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec59  7:5.1.2-1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

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

Bug#1025272: RM: python-descartes -- ROM; Dead upstream

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

osmnx (1.2.2+ds-2) no longer depends on python3-descartes.

Kind Regards,

Bas

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

Bug#1007646: tinycdb: please consider upgrading to 3.0 source format

[Bastian Germann]

On Tue, 15 Mar 2022 08:52:00 +0100 Lucas Nussbaum  wrote:

This package is a native package, so the likely target is 3.0 (native), not
3.0 (quilt).


It actually has an upstream, so the package should be converted to 3.0 (quilt).

Bug#1025324: libc6: Xserver with nouveau not workiing.

[Santiago José López Borrazás]

El 3/12/22 a las 12:07, Aurelien Jarno escribió:

control: reassign -1 libgl1-mesa-dri
control: forcemerge 1025312 -1
control: affects 1025312 src:glibc

Hi,

On 2022-12-03 07:25, Agustin Martin wrote:

Hi all,

Also hit by this problem (intel i5 box).

Noticed that Xorg log showing the error is very similar to what is seen in

#1025312 [libgl1-mesa-dri: multiple packages FTBFS and have
autopkgtest regressions running test programs under Xvfb]

Thanks for the pointer, it indeed looks the real issue. Basically mesa
calls dlclose(NULL), that's why libc6 appears in the backtrace.

I am therefore reassigning the bug.

Regards
Aurelien


Yes. Is correct. Thanks.

--
Enviando desde Mozilla Thunderbird.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015607: qemu: ftbfs with LTO (link time optimization) enabled

[Michael Tokarev]

Control: tag -1 + confirmed upstream

On Tue, 19 Jul 2022 16:58:57 + Matthias Klose  wrote:
..

This package currently fails to build (at least on the amd64
architecture) with link time optimizations enabled.

...

This is qboot code.  To reproduce, either

  ./debian/rules build-qboot

or

  cd roms/qboot
  meson build && ninja -C build

(this does not require whole rebuild; and this only happens
with arch-indep part).

/mjt

Bug#1025373: libjogl2-java: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: libjogl2-java
Version: 2.3.2+dfsg-9
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine with the patch riscv64-port.diff.
Also attached the whole debdiff.

The particular string with its upper and lowercases ("Riscv64") comes from
#1014852, trying to use other combinations doesn't work.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru libjogl2-java-2.3.2+dfsg/debian/changelog 
libjogl2-java-2.3.2+dfsg/debian/changelog
--- libjogl2-java-2.3.2+dfsg/debian/changelog   2019-03-02 13:56:52.0 
+
+++ libjogl2-java-2.3.2+dfsg/debian/changelog   2022-12-02 21:24:38.0 
+
@@ -1,3 +1,12 @@
+libjogl2-java (2.3.2+dfsg-9+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64:
+- enable in d/control
+- add debian/patches/riscv64-port.diff
+
+ -- Manuel A. Fernandez Montecelo   Fri, 02 Dec 2022 21:24:38 
+
+
 libjogl2-java (2.3.2+dfsg-9) unstable; urgency=medium
 
   * Team upload.
diff -Nru libjogl2-java-2.3.2+dfsg/debian/control 
libjogl2-java-2.3.2+dfsg/debian/control
--- libjogl2-java-2.3.2+dfsg/debian/control 2019-03-02 13:56:52.0 
+
+++ libjogl2-java-2.3.2+dfsg/debian/control 2022-12-02 21:24:38.0 
+
@@ -53,7 +53,7 @@
 
 Package: libjogl2-jni
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Architecture: amd64 i386 arm64 armhf ppc64el s390x powerpc ppc64
+Architecture: amd64 i386 arm64 armhf ppc64el s390x powerpc ppc64 riscv64
 Description: Java bindings for OpenGL API (JNI lib)
  The JOGL project hosts the development version of the Java Bindings for
  OpenGL (JSR-231), and is designed to provide hardware-supported 3D graphics
diff -Nru libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff 
libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff
--- libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff   1970-01-01 
00:00:00.0 +
+++ libjogl2-java-2.3.2+dfsg/debian/patches/riscv64-port.diff   2022-12-02 
21:24:38.0 +
@@ -0,0 +1,82 @@
+Index: libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-jogl.xml
 libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
+@@ -1395,6 +1395,12 @@
+   
+ 
+ 
++
++  
++  
++  
++
++
+ 
+   
+   
+@@ -1413,7 +1419,7 @@
+   
+ 
+ 
+-
++
+ 
+ 
+   
+Index: libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-nativewindow.xml
 libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
+@@ -574,6 +574,12 @@
+   
+ 
+ 
++
++  
++  
++  
++
++
+ 
+   
+   
+@@ -592,7 +598,7 @@
+   
+ 
+ 
+-
++
+ 
+ 
+   
+Index: libjogl2-java-2.3.2+dfsg/make/build-newt.xml
+===
+--- libjogl2-java-2.3.2+dfsg.orig/make/build-newt.xml
 libjogl2-java-2.3.2+dfsg/make/build-newt.xml
+@@ -546,6 +546,16 @@
+   
+ 
+ 
++
++  
++  
++  
++  
++  
++  
++
++
+ 
+   
+   
+@@ -582,7 +592,7 @@
+   
+ 
+ 
+-
++
+ 
+ 
+   
diff -Nru libjogl2-java-2.3.2+dfsg/debian/patches/series 
libjogl2-java-2.3.2+dfsg/debian/patches/series
--- libjogl2-java-2.3.2+dfsg/debian/patches/series  2019-03-02 
13:56:52.0 +
+++ libjogl2-java-2.3.2+dfsg/debian/patches/series  2022-12-02 
21:24:38.0 +
@@ -20,3 +20,4 @@
 disable-test-compilation.patch
 fix-mesa-detection.diff
 java11.patch
+riscv64-port.diff
Index: libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-jogl.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-jogl.xml
@@ -1395,6 +1395,12 @@
   
 
 
+
+  
+  
+  
+
+
 
   
   
@@ -1413,7 +1419,7 @@
   
 
 
-
+
 
 
   
Index: libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-nativewindow.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-nativewindow.xml
@@ -574,6 +574,12 @@
   
 
 
+
+  
+  
+  
+
+
 
   
   
@@ -592,7 +598,7 @@
   
 
 
-
+
 
 
   
Index: libjogl2-java-2.3.2+dfsg/make/build-newt.xml
===
--- libjogl2-java-2.3.2+dfsg.orig/make/build-newt.xml
+++ libjogl2-java-2.3.2+dfsg/make/build-newt.xml
@@ -546,6 +546,16 @@
   
 
 
+
+  
+  

Bug#1025324: libc6: Xserver with nouveau not workiing.

[Aurelien Jarno]

control: reassign -1 libgl1-mesa-dri
control: forcemerge 1025312 -1
control: affects 1025312 src:glibc

Hi,

On 2022-12-03 07:25, Agustin Martin wrote:
> Hi all,
> 
> Also hit by this problem (intel i5 box).
> 
> Noticed that Xorg log showing the error is very similar to what is seen in
> 
> #1025312 [libgl1-mesa-dri: multiple packages FTBFS and have
> autopkgtest regressions running test programs under Xvfb]

Thanks for the pointer, it indeed looks the real issue. Basically mesa
calls dlclose(NULL), that's why libc6 appears in the backtrace.

I am therefore reassigning the bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1025183: silx: (autopkgtest) needs update for python3.11: Segmentation fault

[Stuart Prescott]

It appears that src:silx FTBFS at present too. The failure is during 
building the docs with python3.10, meaning that this failure predates 
python3.11.


The failing line is:

# build the documentation
pybuild --build -s custom -p 3.10 --build-args="cd doc && env 
PYTHONPATH={build_dir} http_proxy='127.0.0.1:9' xvfb-run -a 
--server-args=\"-screen 0 1024x768x24\" {interpreter} -m sphinx -N 
-bhtml source build/html"
I: pybuild base:240: cd doc && env 
PYTHONPATH=/build/silx-pvssnu/silx-1.1.0+dfsg/.pybuild/cpython3_3.10_silx/build 
http_proxy='127.0.0.1:9' xvfb-run -a --server-args="-screen 0 
1024x768x24" python3.10 -m sphinx -N -bhtml source build/html

Running Sphinx v4.5.0
[...snip...]
reading sources... [ 92%] modules/sx
qt.qpa.xcb: could not connect to display :109
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even 
though it was found.
This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.


Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, 
offscreen, vnc, xcb.


Aborted (core dumped)



--
Stuart Prescott   http://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer  http://www.debian.org/ stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1013384: petsc4py: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:77: override_dh_sphinxdoc-indep] Error 255

[Dmitry Shachnev]

On Thu, Jun 23, 2022 at 08:43:40AM +0200, Lucas Nussbaum wrote:
> petsc4py fails to build with Sphinx 5.0 and docutils 0.18, both of which
> are currently available in experimental.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_installdocs -i
> > dh_installdocs: warning: Cannot auto-detect main package for 
> > python-petsc4py-doc.  If the default is wrong, please use --doc-main-package
> > rm 
> > debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/jquery*.js
> > ln -sf /usr/share/javascript/jquery/jquery.js 
> > debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/jquery.js
> > rm 
> > debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/underscore*.js
> > ln -sf /usr/share/javascript/underscore/underscore.js 
> > debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/underscore.js
> > make[1]: Leaving directory '/<>'
> >dh_installdocs -O--buildsystem=pybuild -Npython3-petsc4py 
> > -Npython3-petsc4py-real -Npython3-petsc4py-complex 
> > -Npython3-petsc4py-64-real -Npython3-petsc4py-64-complex 
> > -Npython-petsc4py-doc
> >debian/rules override_dh_sphinxdoc-indep
> > make[1]: Entering directory '/<>'
> > dh_sphinxdoc -i --exclude=searchtools.js --exclude=doctools.js
> > unexpected end of string while parsing JSON string, at character offset 2 
> > (before "ocnames:["citing","i...") at /usr/bin/dh_sphinxdoc line 245.
> > make[1]: *** [debian/rules:77: override_dh_sphinxdoc-indep] Error 255

This happens because petsc4py does not rebuild documentation from source,
but installs pre-built files provided by upstream.

dh_sphinxdoc only supports the current Sphinx version, not the old version
used by upstream. I recommend to rebuild the documentation from source.

If you do this you also won't need to symlink JS files and also won't need
to pass --exclude options.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1013398: petsc: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:591: override_dh_sphinxdoc-indep] Error 255

[Dmitry Shachnev]

On Thu, Jun 23, 2022 at 08:43:43AM +0200, Lucas Nussbaum wrote:
> petsc fails to build with Sphinx 5.0 and docutils 0.18, both of which
> are currently available in experimental.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # various js scripts provided with upstream source were built with a 
> > different sphinx version not recognized by dh_sphinxdoc
> > dh_sphinxdoc -i -Xjquery -Xsearchtools -Xunderscore -Xdoctools
> > unexpected end of string while parsing JSON string, at character offset 2 
> > (before "ocnames:["community/...") at /usr/bin/dh_sphinxdoc line 245.
> > make[1]: *** [debian/rules:591: override_dh_sphinxdoc-indep] Error 255

This happens because petsc does not rebuild documentation from source,
but installs pre-built files provided by upstream.

dh_sphinxdoc only supports the current Sphinx version, not the old version
used by upstream. I recommend to rebuild the documentation from source.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1013395: mpdecimal: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:60: override_dh_sphinxdoc] Error 255

[Dmitry Shachnev]

On Thu, Jun 23, 2022 at 08:43:09AM +0200, Lucas Nussbaum wrote:
> mpdecimal fails to build with Sphinx 5.0 and docutils 0.18, both of which
> are currently available in experimental.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > rm -rf debian/tmp/usr/share/doc/mpdecimal/libmpdec++/_static
> > ln -sf ../libmpdec/_static 
> > debian/tmp/usr/share/doc/mpdecimal/libmpdec++/_static
> > rm -f 
> > debian/tmp/usr/share/doc/mpdecimal/libmpdec/_static/{doctools,jquery,searchtools,sidebar,underscore}.js
> > cp -p 
> > /usr/share/javascript/sphinxdoc/1.0/{doctools,jquery,searchtools,sidebar,underscore}.js
> >  \
> > debian/tmp/usr/share/doc/mpdecimal/libmpdec/_static/.
> > cp -a debian/tmp/usr/share/doc/mpdecimal/* \
> > debian/libmpdec-doc/usr/share/doc/libmpdec-doc
> > rm -f debian/libmpdec-doc/usr/share/doc/libmpdec-doc/LICENSE*
> > rm -f debian/libmpdec-doc/usr/share/doc/libmpdec-doc/INSTALL*
> > dh_sphinxdoc
> > unexpected end of string while parsing JSON string, at character offset 2 
> > (before "ocnames:["arithmetic...") at /usr/bin/dh_sphinxdoc line 245.
> > make[1]: *** [debian/rules:60: override_dh_sphinxdoc] Error 255

This happens because mpdecimal does not rebuild documentation from source,
but installs pre-built files provided by upstream.

dh_sphinxdoc only supports the current Sphinx version, not the old version
used by upstream. I recommend to rebuild the documentation from source.

If you do this you also won't need to manually copy JS files.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1025372: RFS: nss-tls/1.1-1.1 [NMU] -- utility like nslookup(1), but uses libnss_tls.so instead of DNS

[Gioele Barabucci]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a NMU of the package "nss-tls":

 * Package name : nss-tls
   Version  : 1.1-1.1
   Upstream contact : Dima Krasner 
 * URL  : https://github.com/dimkr/nss-tls
 * License  : LGPL-2.1+
 * Vcs  : https://salsa.debian.org/debian/nss-tls
   Section  : net

The source builds the following binary packages:

  nss-tlsd - encrypted DNS name resolution daemon
  libnss-tls - NSS module for encrypted DNS name resolution
  tlslookup - utility like nslookup(1), but uses libnss_tls.so instead 
of DNS


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


  https://mentors.debian.net/package/nss-tls/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nss-tls/nss-tls_1.1-1.1.dsc


Changes since the last upload:

 nss-tls (1.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * d/libnss-tls.nss: Install NSS service `tls` via dh_installnss
 (Closes: #1024688)

Regards,

--
Gioele Barabucci