Bug#1027455: Unsupported hwdec: vaapi-egl

[Johannes Schauer Marin Rodrigues]

Control: forwarded -1 https://github.com/mpv-player/mpv/issues/11073

Hi,

Quoting Johannes Schauer Marin Rodrigues (2022-12-31 22:56:12)
> Reverting this commit in 0.35.0-4 (a clean revert without conflicts is
> possible) makes mpv work fine for me again.

there is a more minimal patch to make things work again:

--- a/video/out/opengl/ra_gl.c
+++ b/video/out/opengl/ra_gl.c
@@ -590,7 +590,7 @@ static struct ra_buf *gl_buf_create(struct ra *ra,
 {
 GL *gl = ra_gl_get(ra);
 
-if (params->host_mapped && !gl->BufferStorage)
+if (params->host_mapped && gl->version < 440)
 return NULL;
 
 struct ra_buf *buf = talloc_zero(NULL, struct ra_buf);

> I am not familiar with mpv internals. Do you want to file an upstream bug
> about this or should I?

I filed it now as https://github.com/mpv-player/mpv/issues/11073.

Thanks!

cheers, josch

Bug#1027353: (no subject)

[dai]

Control: reassign -1 src:ruby-specinfra
Control: forcemerge #1027347 -1
Control: affects #1027347 src:ruby-serverspec

This is caused by ruby-specinfra.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1019416: transition: wxwidgets3.2

[Scott Talbert]

On Sat, 31 Dec 2022, Sebastian Ramacher wrote:


Hi Scott

On 2022-12-30 16:03:40 -0500, Scott Talbert wrote:

On Fri, 9 Sep 2022, Sebastian Ramacher wrote:


The tracker is at
https://release.debian.org/transitions/html/wxwidgets-3.2.html. I have
changed the is_good and is_bad to check for dependencies of the binary
packges as .build-depends are not check for binary packages. Let me know
if that misses anything.


This tracker needs to be updated because of the other wxwidgets transition,
I sent a merge request with what I think is required:

https://salsa.debian.org/release-team/transition-data/-/merge_requests/35/diffs


Merged, thanks.

The only remaining package is libalien-wxwidgets-perl. From [1] I
understand that updating it and libwx-perl is somewhat more involved.
Are there any news?


I've continued to make slow progress on it.  I'll try to make a more 
concerted effort on it over the next week or two.  Too much task switching 
in my Debian work.  :)


Happy New Year,
Scott

Bug#1027465: RFS: streamlink/5.1.2-1~bpo11+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bullseye-backports repository.

  * Package name: streamlink
Version : 5.1.2-1~bpo11+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
Section : python

It builds those binary packages:

   python3-streamlink - Python module for extracting video streams from various 
websites
   python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
   streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
   https://mentors.debian.net/package/streamlink


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

   dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_5.1.2-1~bpo11+1.dsc

Changes since the last upload to bullseye-backports:
streamlink (5.1.2-1~bpo11+1) bullseye-backports; urgency=medium

   * Rebuild for bullseye-backports.
   * d/patches: update patches to use pytest and pytest-asyncio from stable
   * Revert "d/streamlink.{install,manpages}: update completion scripts 
location"
 This is required with stable distribution.

  -- Alexis Murzeau   Sun, 01 Jan 2023 03:45:47 +0100

streamlink (5.1.2-1) unstable; urgency=medium

   * New upstream version 5.1.2
   * d/README.source: update packaging instructions
   * d/streamlink.{install,manpages}: update completion scripts location
 (Closes: #1026714)
   * Bump Standards-Version to 4.6.2 (no changes)

  -- Alexis Murzeau   Thu, 22 Dec 2022 15:35:53 +0100

streamlink (5.1.1-1) unstable; urgency=medium

   * New upstream version 5.1.1
   * Control: add build-dep on python3-certifi.

  -- Alexis Murzeau   Tue, 29 Nov 2022 08:51:03 +

streamlink (5.1.0-1) unstable; urgency=medium

   [ Debian Janitor ]
   * Remove constraints unnecessary since buster (oldstable)

   [ Alexis Murzeau ]
   * New upstream version 5.1.0
   * d/patches: update patches
   * d/control: update build dependencies
   * d/tests/control: update test dependencies

  -- Alexis Murzeau   Wed, 16 Nov 2022 23:29:10 +0100



Differences from testing package (5.1.2-1):
   * d/patches,d/control: fix build with older dependencies

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









OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027361: e2tools: FTBFS in bullseye (missing build-depends on e2fsprogs)

[Santiago Vila]

El 1/1/23 a las 2:34, xiao sheng wen(肖盛文) escribió:

Hi,

     I'd ran wrap-and-sort -t -a -s, it's a nice tool.

Uploaded the package to mentors again, please help to review and upload.


Ok, this one is good enough for me. Uploaded.


(Also: Remember that we also wan to fix this in stable afterwards).


Is this fix need to in Bullseye? Should I report bug to release.debian.org for 
proposed-updates?


Yes, please. Packages in stable must build in stable. I'm trying to keep 
bullseye
free from all kind of FTBFS bugs, which includes this one.

(I can also sponsor the bullseye upload if required, once you get approval
from Release Managers).

Thanks.

Bug#1027361: e2tools: FTBFS in bullseye (missing build-depends on e2fsprogs)

[肖盛文]

Hi,

    I'd ran wrap-and-sort -t -a -s, it's a nice tool.

Uploaded the package to mentors again, please help to review and upload.


在 2022/12/31 17:09, Santiago Vila 写道:

El 31/12/22 a las 3:52, xiao sheng wen(肖盛文) escribió:

Hi Santiago,

 Thanks for your report. I'd fix this bug and uploaded the new 
package to mentors.


Would you help to upload it ?

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


Yes, I can.

While we are at it: Can we "wrap-and-sort -t"?

(Currently, there are two build-depends in their own line
and the others are still joined, which seems a little bit
inconsistent to me).

(Also: Remember that we also wan to fix this in stable afterwards).


Is this fix need to in Bullseye? Should I report bug to 
release.debian.org for proposed-updates?



Thanks!
Happy New Year!

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023251: pdf-redact-tools: Unusable since imagemagick disabled PDF support by default, unmaintained upstream

[Kunal Mehta]

Hi,

On 11/1/22 01:36, intrigeri wrote:

So I think this package should not be included in Bookworm,
hence the RC severity.


I didn't realize it wasn't working anymore, but agreed even without that 
solely because it's unmaintained upstream and I personally no longer use 
it. Will file an RM shortly.


-- Kunal

Bug#1027464: RM: pdf-redact-tools -- ROM; broken, unmaintained

[Kunal Mehta]

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

Hi,

Please remove src:pdf-redact-tools, it's broken (see #1023251) and unmaintained 
upstream.

Thanks,
-- Kunal

Bug#1027463: transition: clamav

[Scott Kitterman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-clamav-devel.alioth-lists.debian.net

As discussed in a separate email to the release team list yesterday, we,
unfortunately have a need to do a late clamav transition.

The clamav project now maintains specified releases with long term
support.  Currently we have 0.103 in stable/testing/unstable.  We should
be able to maintain clamav for the expected life of bullseye with 0.103.

For bookworm we will need to transition to clamav 1.0/libclamav11 at
some point and we believe it's better to do it now that during the
freeze or even potentially after release.  The move from 0.103 to 1.0 is
more complicated that usual due to upstream switching from autorools to
CMake and the introduction of Rust code into libclamav.

The package is availalbe in experimental, but still needs some cleanup
before it's ready for release.  We will be working on this over then
next couple of days and anticipate being ready for the transition
mid-week.

There are three reverse build-depends for libclamav-dev:

* c-icap-modules
* cyrus-imapd
* pg-snakeoil

I've test built all three with the clamav 1.0 packages in experimental
with no issue.

Additionally, there is libclamunrar in non-free that will also need to
be updated.  The clamav team will address that after the transition is
done.

Scott K

Ben file:

title = "clamav";
is_affected = .depends ~ "libclamav9" | .depends ~ "libclamav11";
is_good = .depends ~ "libclamav11";
is_bad = .depends ~ "libclamav9";

Bug#1027411: rednotebook: en_GB translation uses German word "Zurück" for "Back"

[Ash Joubert]

Thanks, Phil. Confirmed fixed in 2.29+ds-1.

One oddity is that /usr/share/locale/en_GB/LC_MESSAGES/rednotebook.mo is 
now only 28 bytes, but I guess that this makes sense because en_GB is 
the original language and there is nothing to translate. The size 
reduction is an improvement.


Happy New Year!

Kind regards,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Bug#1016285: mupdf-gl error segmentation

[Сергей Фёдоров]

Package: mupdf
Version: 1.21.1+ds1-1
Followup-For: Bug #1016285
X-Debbugs-Cc: serfyod...@yandex.ru

Dear Maintainer,

GeForce Graphics Card ASUS EN7300GT SILENT / HTD / 256M

Debian 11.6.0 64 installs:

Source: mesa  24 packets  v.20.3.5-1
Source: libglvnd  13 packets  v.1.3.2-1
Source: 9.0.2-1.1: libglu  2 packets  v.9.0.1-1

With this version of packages, any version of mupdf is compiled from source 
texts (from git too) and works fine. And the binary package mupdf 1.21.1+dd1-1 
is installed and works fine.

But if you install:

Source: mesa  24 packets  22.3.1-1
Source: libglvnd  14 packets  v.1.5.0-1
Source: libglu  2 packets  v.9.0.2-1.1

then when mupdf-gl is started, the message "Error segmentation" is displayed 
and its execution is terminated. This happens with both the Linux kernel 
5.10.20 and 6.0.0.6.


xserver-xorg-video-nouveau 1:1.0.17-1  X.org X-сервер — VideoDriver Nouveau

Source: mesa  24 packets  v.20.3.5-1:
libxatracker-dev
libxatracker2
libd3dadapter9-mesa
libd3dadapter9-mesa-dev
libegl-mesa0
libegl1-mesa
libegl1-mesa-dev
libgbm-dev
libgbm1
libgl1-mesa-dev
libgl1-mesa-dri
libgl1-mesa-glx
libglapi-mesa
libgles2-mesa
libgles2-mesa-dev
libglx-mesa0
libosmesa6
libosmesa6-dev
libwayland-egl1-mesa
mesa-common-dev
mesa-opencl-icd
mesa-va-drivers
mesa-vdpau-drivers
mesa-vulkan-drivers


Source: libglvnd:  14 packets  v.1.3.2-1:
libegl-dev
libegl1
libgl-dev
libgl1
libgles-dev
libgles1
libgles2
libglvnd-core-dev
libglvnd-dev
libglvnd0
libglx-dev
libglx0
libopengl-dev
libopengl0


Source: libglu  2 packets  v.9.0.1-1
libglu1-mesa
libglu1-mesa-dev


xserver-xorg-video-nouveau 1:1.0.17-1  X.org X-сервер — видеодрайвер Nouveau

Source: mesa:  22.3.1-1:
libxatracker-dev
libxatracker2
libd3dadapter9-mesa
libd3dadapter9-mesa-dev
libegl-mesa0
libegl1-mesa
libegl1-mesa-dev
libgbm-dev
libgbm1
libgl1-mesa-dev
libgl1-mesa-dri
libgl1-mesa-glx
libglapi-mesa
libgles2-mesa
libgles2-mesa-dev
libglx-mesa0
libosmesa6
libosmesa6-dev
libwayland-egl1-mesa
mesa-common-dev
mesa-opencl-icd
mesa-va-drivers
mesa-vdpau-drivers
mesa-vulkan-drivers


Source: libglvnd:  14 packets  v.1.5.0-1:
libegl-dev
libegl1
libgl-dev
libgl1
libgles-dev
libgles1
libgles2
libglvnd-core-dev
libglvnd-dev
libglvnd0
libglx-dev
libglx0
libopengl-dev
libopengl0


Source: libglu  2 packets  v.9.0.2-1.1:
libglu1-mesa
libglu1-mesa-dev





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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 mupdf depends on:
ii  libc62.36-7
ii  libfreetype6 2.12.1+dfsg-3
ii  libgl1   1.3.2-1
ii  libglut3.12  3.4.0-1
ii  libgumbo10.10.1+dfsg-4
ii  libharfbuzz0b6.0.0-1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libmujs2 1.3.2-1
ii  libopenjp2-7 2.5.0-1
ii  libssl3  3.0.7-1
ii  libx11-6 2:1.8.3-3
ii  libxext6 2:1.3.4-1+b1
ii  zlib1g   1:1.2.13.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
pn  mupdf-tools  

-- no debconf information

Bug#1027321: lxd init run as non-root fails to find LVM thin provisioning tools

[Mathias Gibbens]

Hi,

  I think the root of this problem is the difference in $PATH between
root and a normal user -- root includes /usr/sbin/, which is where the
`thin_check` binary is installed. LXD attempts to find it in the
current $PATH when deciding whether or not to enable LVM thin
provisioning [1].

  If you include /usr/sbin/ in your $PATH, can you successfully run
`lxd init`?

>$ PATH=$PATH:/usr/sbin lxd init

  I don't have LVM setup on my test machine at the moment, but the LXD
init process appeared was successful (except for actually creating the
storage pool in LVM) when I replicated this bug.

  I suspect this will have to be forwarded upstream, but would
appreciate hearing from you if this fixes the problem you've
experienced.

Mathias

[1] -- https://github.com/lxc/lxd/blob/master/lxd/main_init_interactive.go#L913


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

Bug#1027342: itamae: FTBFS: ERROR: Test "ruby3.1" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in activate_dependencies': Could not find 'net-telnet' (= 0.1.1)

[Antonio Terceiro]

Control: reassign -1 src:ruby-specinfra
Control: forcemerge #1027347 -1
Control: affects #1027347 src:itamae

On Fri, Dec 30, 2022 at 05:20:58PM +0100, Lucas Nussbaum wrote:
> Source: itamae
> Version: 1.14.1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221230 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This is caused by ruby-specinfra.


signature.asc
Description: PGP signature

Bug#1027462: multiplex: autopkgtest failure on s390x: AssertionError: AssertionError: assert ['12'] == ['1', '2']assert ['12'] == ['1', '2']

[Paul Gevers]

Source: multiplex
Version: 0.6.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package multiplex, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report. I'd like to 
remark that s390x is our only big-endian release architecture, maybe 
that's related here?


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

Paul

[1] https://qa.debian.org/excuses.php?package=multiplex

https://ci.debian.net/data/autopkgtest/testing/s390x/m/multiplex/29540144/log.gz

=== FAILURES 
===
___ test_async_stream_reader 
___


async def test_async_stream_reader():
p = await asyncio.subprocess.create_subprocess_shell(
cmd="printf 1; sleep 0.01; printf 2",
stdout=asyncio.subprocess.PIPE,
)
iterator = await to_iterator(p.stdout)
assert iterator.title == "StreamReader"
assert iterator.inner_type == "stream_reader"

  await assert_aiter(iterator.iterator, ["1", "2"])


tests/test_iterator.py:121: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

source = 
values = ['1', '2'], exception = None

async def assert_aiter(source, values, exception=None):
"""Check the results of a stream using a streamcontext."""
results = []
exception_type = type(exception) if exception else ()
try:
async with streamcontext(source) as streamer:
async for item in streamer:
results.append(item)
except exception_type as exc:
assert compare_exceptions(exc, exception)
else:
assert exception is None

  assert results == values

E   AssertionError: assert ['12'] == ['1', '2']
E At index 0 diff: '12' != '1'
E Right contains one more item: '2'
E Use -v to get more diff

/usr/lib/python3/dist-packages/aiostream/test_utils.py:48: AssertionError
=== warnings summary 
===

tests/test_iterator.py::test_async_generator_input
  /usr/lib/python3/dist-packages/pytest_asyncio/plugin.py:380: 
DeprecationWarning: There is no current event loop

old_loop = policy.get_event_loop()

tests/test_multiplex.py::test_exports
  tests/test_multiplex.py:12: PytestWarning: The test test_exports> is marked with '@pytest.mark.asyncio' but it is not an 
async function. Please remove asyncio marker. If the test is not marked 
explicitly, check for global markers applied via 'pytestmark'.

def test_exports():

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info 

FAILED tests/test_iterator.py::test_async_stream_reader - 
AssertionError: ass...
= 1 failed, 47 passed, 1 skipped, 2 warnings in 0.42s 
==
E: pybuild pybuild:386: test: plugin autopkgtest failed with: exit 
code=1: cd /tmp/autopkgtest-lxc._5q8_u_d/downtmp/autopkgtest_tmp/build; 
python3.10 -m pytest tests

make: *** [/tmp/6hcGjG9vf4/run:4: pybuild-autopkgtest] Error 13
pybuild-autopkgtest: error: /tmp/6hcGjG9vf4/run pybuild-autopkgtest 
returned exit code 2

autopkgtest [04:46:44]: test pybuild-autopkgtest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027337: Update

[Xan Charbonnet]

Some memory statistics.  Uptime, resident memory size, and % of memory 
in the system for mariadbd:


30 hours -- 1.0g -- 26.7%
36 hours -- 1.2g -- 30.3%
54 hours -- 1.6g -- 41.5%

Looks like a pretty linear progression of ~33MB/hour being leaked.  This 
is on a system that previously had 512MB of total RAM.  Now with 4GB it 
appears it'll be able to stay up about 5 days total.  There were no 
configuration changes other than upgrading the packages.

Bug#1027461: python-mediafile breaks beets autopkgtest: object of type 'NoneType' has no len()

[Paul Gevers]

Source: python-mediafile, beets
Control: found -1 python-mediafile/0.11.0-1
Control: found -1 beets/1.6.0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-mediafile the autopkgtest of beets fails 
in testing when that autopkgtest is run with the binary packages of 
python-mediafile from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python-mediafile   from testing0.11.0-1
beets  from testing1.6.0-3
all others from testingfrom testing

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

Currently this regression is blocking the migration of python-mediafile 
to testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=python-mediafile

https://ci.debian.net/data/autopkgtest/testing/amd64/b/beets/29792888/log.gz

=== FAILURES 
===
 EmbedartCliTest.test_clear_art_with_yes_input 
_


self = testMethod=test_clear_art_with_yes_input>


def test_clear_art_with_yes_input(self):
self._setup_data()
album = self.add_album_fixture()
item = album.items()[0]
self.io.addinput('y')
self.run_command('embedart', '-f', self.small_artpath)
self.io.addinput('y')
self.run_command('clearart')
mediafile = MediaFile(syspath(item.path))

  self.assertEqual(len(mediafile.images), 0)

E   TypeError: object of type 'NoneType' has no len()

test/test_embedart.py:205: TypeError
- Captured stderr call 
-

Sending event: database_change
Sending event: database_change
Sending event: item_copied
Sending event: database_change
Sending event: database_change
Sending event: database_change
Sending event: database_change
Sending event: database_change
no user configuration found at /tmp/tmppz0v9_v1/config.yaml
data directory: /tmp/tmppz0v9_v1
plugin paths: Sending event: pluginload
embedart: embedding 
/tmp/autopkgtest-lxc.36cnu39s/downtmp/autopkgtest_tmp/test/rsrc/image-2x3.jpg

Sending event: write
Sending event: after_write
Sending event: cli_exit
no user configuration found at /tmp/tmppz0v9_v1/config.yaml
data directory: /tmp/tmppz0v9_v1
plugin paths: Sending event: pluginload
embedart: Clearing album art from 1 items
embedart: Clearing art for the artist - älbum - tïtle 0
Sending event: write
Sending event: after_write
Sending event: cli_exit
-- Captured log call 
---

DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: item_copied
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:plugins.py:485 Sending event: database_change
DEBUGbeets:__init__.py:1202 no user configuration found at 
/tmp/tmppz0v9_v1/config.yaml

DEBUGbeets:__init__.py:1205 data directory: /tmp/tmppz0v9_v1
DEBUGbeets:__init__.py: plugin paths: DEBUG 
beets:plugins.py:485 Sending event: pluginload
DEBUGbeets.embedart:art.py:69 embedart: embedding 
/tmp/autopkgtest-lxc.36cnu39s/downtmp/autopkgtest_tmp/test/rsrc/image-2x3.jpg

DEBUGbeets:plugins.py:485 Sending event: write
DEBUGbeets:plugins.py:485 Sending event: after_write
DEBUGbeets:plugins.py:485 Sending event: cli_exit
DEBUGbeets:__init__.py:1202 no user configuration found at 
/tmp/tmppz0v9_v1/config.yaml

DEBUGbeets:__init__.py:1205 data directory: /tmp/tmppz0v9_v1
DEBUGbeets:__init__.py: plugin paths: DEBUG 
beets:plugins.py:485 Sending event: pluginload

INFO beets.embedart:art.py:221 embedart: Clearing album art from 1 items
DEBUGbeets.embedart:art.py:223 embedart: Clearing art for the artist 
- älbum - tïtle 0

DEBUGbeets:plugins.py:485 Sending event: write
DEBUGbeets:plugins.py:485 Sending event: after_write
DEBUGbeets:plugins.py:485 Sending event: cli_exit
 EmbedartCliTest.test_embed_art_from_file_with_no_input 



self = testMethod=test_embed_art_from_file_with_no_input>


def test_embed_art_from_file_with_no_input(self):
self._setup_data()
album = self.add_album_fixture()
item = album.items()[0]
self.io.addinput('n')

Bug#1027455: Unsupported hwdec: vaapi-egl

[Johannes Schauer Marin Rodrigues]

Control: retitle -1 regression introduced by "vo_gpu: opengl: fix OpenGL ES 
version and extension handling"

Hi,

Quoting Johannes Schauer Marin Rodrigues (2022-12-31 20:29:53)
> Is this a red herring?

yes. I bisected upstream git and found that the following commit is responsible
for the slowdown on my platform:

commit 2fc327f2fdd48f0cd58a4d4382a7aa57f3fabd77
Author: Philip Langdale 
Date:   Sat Dec 4 11:42:16 2021 -0800

vo_gpu: opengl: fix OpenGL ES version and extension handling

Some of the extension declarations did not include the ES version where
they became core functionality, and in some of these cases, there was
never actually an ES extension - it first appeared in core. We also had
a number of buggy version checks where ES versions were compared
against required desktop GL versions.


Reverting this commit in 0.35.0-4 (a clean revert without conflicts is
possible) makes mpv work fine for me again.

I am not familiar with mpv internals. Do you want to file an upstream bug
about this or should I?

Thanks!

cheers, josch

Bug#1027460: scipy breaks scikit-learn autopkgtest: Segmentation fault

[Paul Gevers]

Source: scipy, scikit-learn
Control: found -1 scipy/1.8.1-18
Control: found -1 scikit-learn/1.1.2+dfsg-91
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of scipy the autopkgtest of scikit-learn fails in 
testing when that autopkgtest is run with the binary packages of scipy 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
scipy  from testing1.8.1-18
scikit-learn   from testing1.1.2+dfsg-91
all others from testingfrom testing

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

Currently this regression is blocking the migration of scipy to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=scipy

https://ci.debian.net/data/autopkgtest/testing/amd64/s/scikit-learn/29794749/log.gz

../../../../usr/lib/python3/dist-packages/sklearn/decomposition/tests/test_kernel_pca.py::test_kernel_pca_raise_not_fitted_error 
PASSED
../../../../usr/lib/python3/dist-packages/sklearn/decomposition/tests/test_kernel_pca.py::test_32_64_decomposition_shape 
PASSEDFatal Python error: Segmentation fault


Current thread 0x7ff05b47d040 (most recent call first):
  File "", line 685 in __setitem__
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 195 in 
_update_current_test_var
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 178 in 
pytest_runtest_teardown
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in 

  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in 
from_call
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in 
call_runtest_hook
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in 
call_and_report
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 131 in 
runtestprotocol
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in 
pytest_runtest_protocol
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in 
pytest_runtestloop
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__

  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in 
wrap_session
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in 
pytest_cmdline_main
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in 
__call__
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", 
line 164 in main
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", 
line 187 in console_main
  File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5 in 


  File "", line 88 in _run_code
  File "", line 198 in _run_module_as_main

Extension modules: sklearn.__check_build._check_build, 
numpy.core._multiarray_umath, numpy.core._multiarray_tests, 
numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, 
numpy.random._common, numpy.random.bit_generator, 
numpy.random._bounded_integers, numpy.random._mt19937, 
numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, 
numpy.random._sfc64, numpy.random._generator, scipy._lib._ccallback_c, 
scipy.sparse._sparsetools, scipy.sparse._csparsetools, 
scipy.sparse.csgraph._tools, scipy.sparse.csgraph._shortest_path, 
scipy.sparse.csgraph._traversal, 
scipy.sparse.csgraph._min_spanning_tree, scipy.sparse.csgraph._flow, 
scipy.sparse.csgraph._matching, scipy.sparse.csgraph._reordering, 
sklearn.utils.murmurhash, lz4._version, lz4.frame._frame, 
scipy.spatial._ckdtree, scipy._lib.messagestream, scipy.spatial._qhull, 
scipy.spatial._voronoi, scipy.linalg._fblas, scipy.linalg._flapack, 
scipy.linalg._cythonized_array_utils, scipy.linalg._flinalg, 

Bug#983303: imagemagick: reproducible builds: Embeds different paths on usrmerge system

[Paul Gevers]

Control: tags -1 pending

Hi,

On Mon, 22 Feb 2021 00:19:22 -0800 Vagrant Cascadian 
 wrote:

Various files embed the full path to the "mv" and "rm" binaries, which
are different on usrmerge systems:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/imagemagick.html

  /etc/ImageMagick-6/delegates.xml

  

  vs.
  



The attached patch fixes this in debian/rules by passing arguments to
configure to use the paths in the non-usrmerge paths, as usrmerge
systems typically have compatibility symlinks, while non-usrmerge
systems do not.


I am building with the patch right now, I will upload when that succeeds.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027295: test-network-panel times out on riscv64

[Andreas Henriksson]

Hello,

On Fri, Dec 30, 2022 at 12:17:48AM +0100, Gunnar Hjalmarsson wrote:
> Package: src:gnome-control-center
> Version: 1:43.2-1
> Severity: important
> Tags: ftbfs
> X-Debbugs-CC: gunna...@debian.org
> 
> g-c-c 1:43.2-1 fails to build on riscv64:
> 
> https://buildd.debian.org/status/logs.php?pkg=gnome-control-center=riscv64
> 
> It's some kind of test timeout for test-network-panel.
[...]

Please also note that we're already carrying a patch to ignore
the result of this apparently flaky test:
  debian/patches/debian/Ignore-result-of-test-network-panel.patch

The upstream bug report has more discussion:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1768

Possibly this test should be completely disabled instead of just
ignoring the result. It would probably be a good idea if someone first
figures out what causes the hang though

Regards,
Andreas Henriksson

Bug#1027308: chezdav: should probably depend on or recommend avahi-daemon

[Andreas Henriksson]

Hello Andres Salomon,

Thanks for your bug report! comments below.

On Thu, Dec 29, 2022 at 11:55:25PM -0500, Andres Salomon wrote:
> Package: chezdav
> Version: 2.5-1
> Severity: normal
> 
> I installed chezdav on a bullseye server, and here's what got installed:
[...]
> Note that avahi-daemon was not already installed on the server. When I
> attemped to run it:
> 
> 
> dilinger@hm90:~$ chezdav -P /srv/shared/
> phodav: mDNS failed: Failed to create avahi client: Daemon not running

Relevant code:
https://gitlab.gnome.org/GNOME/phodav/-/blob/a31d890d4805291d9f4af82bf43279ad4fb76059/bin/chezdav.c#L201-205

We're enabling the AVAHI build option in the debian package build
(by having the required build-dependencies for it and also specifying
the `-Dauto_features=enabled` in debian/rules).

So apparently when built with avahi support, failures to contact
the daemon is considered a fatal error (which spontaneously I thought
would be better as just a warning, since this is an optional feature in
the first place?!) unless the user explicitly passes the --no-mdns
option to disable mdns usage (so I guess it makes sense after all).

> After installing avahi-daemon, the command worked successfully. It should
> probably either depend upon or recommend avahi-daemon.

Since there's a runtime switch to override mdns I'll add it as a
Recommends.

Regards,
Andreas Henriksson

Bug#1012226: unattended-upgrades: flaky autopkgtest: kernel-patterns seems to regularly get confused

[Paul Gevers]

Control: tags -1 pending

On 13-11-2022 20:54, Paul Gevers wrote:
Attached is a patch that fixes that part of the issue. I must confess 
that I don't fully grasp why this isn't always a problem (e.g. now on 
arm64/stable), but on my current bookworm amd64 system the test fails 
without this patch and passes with the patch.


I have uploaded that patch to DELAYED/5. Please let me know if I should 
delay further or cancel the upload.


Paul

debdiff attached.
diff -Nru unattended-upgrades-2.9.1+nmu2/debian/changelog 
unattended-upgrades-2.9.1+nmu3/debian/changelog
--- unattended-upgrades-2.9.1+nmu2/debian/changelog 2022-10-23 
03:28:14.0 +0200
+++ unattended-upgrades-2.9.1+nmu3/debian/changelog 2022-12-31 
21:59:00.0 +0100
@@ -1,3 +1,10 @@
+unattended-upgrades (2.9.1+nmu3) unstable; urgency=medium
+
+  * test: don't confuse -dbg and -unsigned with current running kernel
+(Closes: #983363, #1012226)
+
+ -- Paul Gevers   Sat, 31 Dec 2022 21:59:00 +0100
+
 unattended-upgrades (2.9.1+nmu2) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru unattended-upgrades-2.9.1+nmu2/test/autopkgtest_kernel_patterns.py 
unattended-upgrades-2.9.1+nmu3/test/autopkgtest_kernel_patterns.py
--- unattended-upgrades-2.9.1+nmu2/test/autopkgtest_kernel_patterns.py  
2022-10-23 03:28:14.0 +0200
+++ unattended-upgrades-2.9.1+nmu3/test/autopkgtest_kernel_patterns.py  
2022-12-31 21:59:00.0 +0100
@@ -18,7 +18,7 @@
 running_regexp = running_kernel_pkgs_regexp()
 running_kernel_version = subprocess.check_output(
 ["uname", "-r"], universal_newlines=True).rstrip()
-running_escaped_regexp = ".*" + re.escape(running_kernel_version)
+running_escaped_regexp = ".*" + re.escape(running_kernel_version) + '$'
 try:
 running_noflavor_regexp = "linux.*-" + re.escape(
 re.match("[1-9][0-9]*\\.[0-9]+\\.[0-9]+-[0-9]+",


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026976: Upcoming test suite regression due to changes in file/libmagic

[Christos Zoulas]

Committed, thanks!

christos

> On Dec 30, 2022, at 7:17 PM, FC Stegerman  wrote:
> 
> * Christoph Biedl  [2022-12-29 16:39]:
>> Chris Lamb wrote...
>>> However, this "extra data prepended" doesn't fit well under the rubric
>>> of "data". Yes, this "#!/usr/bin/python3\n" shebang is definitely
>>> "data" of a kind, but a shebang isn't really data in that way given
>>> the special-treatment afforded to it by UNIX systems. Even if this
>>> noun was replaced by the more general "bytes", the magic nature of the
>>> shebang would still remain… as would the desire to discriminate
>>> between pyzip files and other ZIP files with prepended data.
>>> 
>>> Could another — different — string be emitted in the case that these
>>> prepended bytes are a shebang? We could potentially look for the file
>>> starting with #! and for that to take precedence over this new case.
>> 
>> After some more thinking: I suggest you do nothing for the time being
>> while I take this to upstream. If all else fails, I'll revert the change
>> for the next upload. By the way, that will be 1:5.44-1, but the changes
>> to 1:5.43-3 are minimal.
> 
> FWIW I've attached a patch that makes it discriminate between ZIP
> files with prepended data with or without a shebang:
> 
>  $ file -b zipfile-with-data-prepended
>  Zip archive, with extra data prepended
>  $ file -b pyzip
>  a /usr/bin/python3 script executable (Zip archive)
> 
> I'm not sure that completely solves the issue, because there could be
> other (executable) file formats affected, not just pyzip and other
> formats using a shebang.  So perhaps reverting the change completely
> is better after all.  We probably need upstream to figure that out.
> 
> - FC
> ___
> Reproducible-builds mailing list
> reproducible-bui...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds



signature.asc
Description: Message signed with OpenPGP

Bug#1027459: RFS: shaderc/2022.4-1 -- Library API for accessing glslc functionality

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : shaderc
   Version  : 2022.4-1
   Upstream contact : David Neto 
 * URL  : https://github.com/google/shaderc/
 * License  : BSD-3-clause, Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/shaderc
   Section  : libs

The source builds the following binary packages:

  glslc - Command line compiler for GLSL/HLSL to SPIR-V
  libshaderc-dev - Library API for accessing glslc functionality - static 
libraries and headers
  libshaderc1 - Library API for accessing glslc functionality - shared libraries

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2022.4-1.dsc

Changes since the last upload:

 shaderc (2022.4-1) unstable; urgency=medium
 .
   * New upstream release
 - Closes: #1027045
 - Refresh debian/patches/rename-libshaderc.patch
 - Fix test glslc to ignore version-specific content

Regards,
-- 
  Philippe

Bug#1027458: MODULES=dep unbootable on Raspberry Pi 4 booting from USB

[JustArchi]

Package: initramfs-tools
Version: 0.142
Severity: important

Dear Maintainer,

If MODULES=dep is used to trim generated initramfs on Raspberry Pi 4, it 
results in unbootable initramfs generated if user boots from USB-connected 
external drive (rather than microSD).

In particular, system is unable to find rootfs and after a brief delay bails 
out to shell prompt.

In order to make it work, reset_raspberrypi module has to be included. This is 
the case with MODULES=most, and precise reason why only MODULES=dep is 
affected. For MODULES=dep scenarios, reset_raspberrypi has to be manually added 
to /etc/initramfs-tools/modules.

I'd like to request a bugfix in this regard to always include reset_raspberrypi 
module in generated initramfs if it's loaded at the time of generation or it's 
otherwise determined that initramfs is generated for a machine is Raspberry Pi 
4.

If it helps, reset_raspberrypi module is loaded anyway during later stage of 
the boot process, so it doesn't hurt to load it earlier right in the initramfs 
even for setups that would work correctly with it being loaded later on.

I'm not familiar with all internals of how initramfs-tools works, so I 
apologize in advance if I mixed something up. This is also I think my first or 
second bug report ever done, so please bear with me.

Thank you in advance for considering this enhancement/bugfix,

Archi.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 8.8M Dec 31 19:38 /boot/initrd.img-6.0.0-6-arm64
-- /proc/cmdline
 dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x31554c49 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:D3:C1:0F 
vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0  console=tty0 
root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0  rootwait

-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
tls   114688  114
ip6t_REJECT16384  1
nf_reject_ipv6 24576  1 ip6t_REJECT
nft_compat 20480  1
nf_tables 212992  10 nft_compat
libcrc32c  16384  1 nf_tables
nfnetlink  24576  2 nft_compat,nf_tables
hci_uart  135168  0
btqca  24576  1 hci_uart
btrtl  24576  1 hci_uart
btbcm  28672  1 hci_uart
btintel40960  1 hci_uart
btsdio 20480  0
bluetooth 757760  7 btrtl,btqca,btsdio,btintel,hci_uart,btbcm
binfmt_misc24576  1
jitterentropy_rng  24576  1
sha512_generic 16384  0
sha512_arm64   20480  1
evdev  32768  2
nls_ascii  16384  1
bcm2835_v4l2   40960  0
nls_cp437  20480  1
brcmfmac  294912  0
bcm2835_mmal_vchiq 32768  1 bcm2835_v4l2
vfat   28672  1
videobuf2_vmalloc  20480  1 bcm2835_v4l2
fat81920  1 vfat
brcmutil   16384  1 brcmfmac
vc4   274432  4
videobuf2_memops   20480  1 videobuf2_vmalloc
videobuf2_v4l2 24576  1 bcm2835_v4l2
aes_neon_bs24576  0
videobuf2_common   53248  4 
videobuf2_vmalloc,videobuf2_v4l2,bcm2835_v4l2,videobuf2_memops
broadcom   28672  1
snd_soc_hdmi_codec 24576  2
videodev  225280  3 videobuf2_v4l2,bcm2835_v4l2,videobuf2_common
bcm_phy_ptp24576  1 broadcom
cfg80211  770048  1 brcmfmac
bcm_phy_lib20480  2 bcm_phy_ptp,broadcom
aes_neon_blk   28672  1 aes_neon_bs
mc 53248  3 videodev,videobuf2_v4l2,videobuf2_common
snd_soc_core  208896  2 vc4,snd_soc_hdmi_codec
ptp32768  1 bcm_phy_ptp
snd_bcm283528672  0
cpufreq_dt 20480  0
snd_pcm_dmaengine  20480  1 snd_soc_core
pps_core   24576  1 ptp
snd_pcm   118784  4 
snd_bcm2835,snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine
drbg   40960  1
snd_timer  40960  1 snd_pcm
ansi_cprng 20480  0
snd98304  5 
snd_bcm2835,snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm
soundcore  20480  1 snd
cec53248  1 vc4
rc_core53248  3 cec
ecdh_generic   16384  1 bluetooth
drm_display_helper122880  1 vc4
raspberrypi_cpufreq16384  0
dwc2  237568  0
genet  69632  0
drm_cma_helper 20480  1 vc4
mdio_bcm_unimac20480  0
v3d73728  0
rfkill 32768  3 bluetooth,cfg80211
of_mdio20480  3 mdio_bcm_unimac,genet
gpu_sched  36864  1 v3d
udc_core   53248  1 dwc2
fixed_phy  16384  2 genet,of_mdio
iproc_rng200   16384  0
fwnode_mdio20480  1 of_mdio
ecc32768  1 ecdh_generic
roles  16384  

Bug#1027457: ITP: mesact -- Mesa Configuration Tools for LinuxCNC

[Steffen Moeller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: mesact -- Mesa Configuration Tools for LinuxCNC
Package: wnpp
Owner:  
Severity: wishlist

* Package name: mesact
  Version : 1.2.0
  Upstream Author : , J. E. Thornton
* URL : 
* License : Expat
  Programming Lang: Python
  Description : Mesa Configuration Tools for LinuxCNC
 Between the program controling the execution of a CNC mill, CNC lathe
 or a robot, and the powerful drivers that know how to turn a motor,
 is some glue-hardware required that can trigger the drivers to step
 or spin. 
 .
 It is not uncommon to see the parallel printer port being that trigger.
 For higher frequencies, and with the confidence of a perfect clock without
 the involvement of the computer's CPU, a small card may come to the assistance.
 This may be microcontroller, or as it is for the Mesa cards, an FPGA.
 .
 This software knows how to configure LinuxCNC for using one of the 
 5i25/6i25, 7i76e, 7i80, 7i92, 7i95, 7i96, 7i97 Mesa LinuxCNC motion control
 boards and daughter cards.

Remark: This package is maintained by John Thornton at
   https://github.com/jethornton/mesact/

Bug#1026633: Info received (Grig)

[Black Michael]

Current github master plus one small patch fixes the compilation.


https://github.com/fillods/grig

Needed patch (hopefully integrated soon into master)

https://github.com/fillods/grig/pull/6/commits/ec877a5cd0adfaee8439f9dde04b425e6f48c6de

Mike W9MDB



On Saturday, December 31, 2022 at 01:03:04 PM CST, Debian Bug Tracking System 
 wrote: 





Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Debian Hamradio Maintainers 

If you wish to submit further information on this problem, please
send it to 1026...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1026633: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026633
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1027455: Unsupported hwdec: vaapi-egl

[Johannes Schauer Marin Rodrigues]

Package: mpv
Version: 0.35.0-4
Severity: normal

Hi,

I'm running mpv on the IMX8MQ under wayland. The problem was introduced
in 0.35. I can restore mpv to a working state by downloading 0.34.1-1+b5
from snapshot.debian.org. Essentially, the problem is, that with 0.35, I
cannot anymore watch 1080p h264 video on this platform. I diffed the
output of `mpv -v` with 0.34.1-1+b5 as well as with 0.35.0-4 and
attached the diff. If I'm reading the log correctly, then with
0.34.1-1+b5, vaapi-egl is used and with 0.35.0-4 it is not? Indeed, if I
run 0.35.0-4 with --hwdec=vaapi-egl, I get:

Unsupported hwdec: vaapi-egl

And when I run 0.34.1-1+b5 with the same option, the message does not appear
and playback is smooth.

Is this a red herring?

Please advice what other debugging info I can post to get to the bottom of
this.

Thanks!

cheers, josch



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

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

Versions of packages mpv depends on:
ii  libarchive13  3.6.2-1
ii  libasound21.2.8-1
ii  libass9   1:0.17.0-2
ii  libavcodec59  7:5.1.2-1
ii  libavdevice59 7:5.1.2-1
ii  libavfilter8  7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libbluray21:1.3.4-1
ii  libc6 2.36-7
ii  libcaca0  0.99.beta20-3
ii  libcdio-cdda2 10.2+2.0.1-1
ii  libcdio-paranoia2 10.2+2.0.1-1
ii  libcdio19 2.1.0-4
ii  libdrm2   2.4.114-1
ii  libdvdnav46.1.1-1
ii  libegl1   1.5.0-1
ii  libgbm1   22.3.1-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  liblcms2-22.13.1-1+b1
ii  liblua5.2-0   5.2.4-3
ii  libmujs2  1.3.2-1
ii  libpipewire-0.3-0 0.3.63-1
ii  libplacebo208 4.208.0-3
ii  libpulse0 16.1+dfsg1-2+b1
ii  librubberband23.1.2+dfsg0-1
ii  libsdl2-2.0-0 2.26.1+dfsg-1
ii  libsixel1 1.10.3-3
ii  libswresample47:5.1.2-1
ii  libswscale6   7:5.1.2-1
ii  libuchardet0  0.0.7-1
ii  libva-drm22.17.0-1
ii  libva-wayland22.17.0-1
ii  libva-x11-2   2.17.0-1
ii  libva22.17.0-1
ii  libvdpau1 1.5-1
ii  libvulkan11.3.231.1-1
ii  libwayland-client01.21.0-1
ii  libwayland-cursor01.21.0-1
ii  libwayland-egl1   1.21.0-1
ii  libx11-6  2:1.8.3-3
ii  libxext6  2:1.3.4-1+b1
ii  libxinerama1  2:1.1.4-3
ii  libxkbcommon0 1.4.1-1
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.2-2+b1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1.1
ii  libzimg2  3.0.4+ds1-1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 2022.11.11-1

Versions of packages mpv suggests:
pn  libcuda1  

-- no debconf information
--- log.old 2022-12-31 20:09:40.429554316 +0100
+++ log.new 2022-12-31 20:09:04.854354442 +0100
@@ -1,5 +1,5 @@
 [cplayer] Command line options: '-v' '/home/josch/Desktop/[Erai-raws] Neon 
Genesis Evangelion - 01 ~ 26 (v2) [1080p][Multiple Subtitle]/[Erai-raws] Neon 
Genesis Evangelion - 05 [1080p][Multiple Subtitle].mkv'
-[cplayer] mpv 0.34.1 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
+[cplayer] mpv 0.35.0 Copyright © 2000-2022 mpv/MPlayer/mplayer2 projects
 [cplayer]  built on UNKNOWN
 [cplayer] FFmpeg library versions:
 [cplayer]libavutil   57.28.100
@@ -10,8 +10,8 @@
 [cplayer]libswresample   4.7.100
 [cplayer] FFmpeg version: 5.1.2-1
 [cplayer] 
-[cplayer] Configuration: ./waf configure --prefix=/usr 
--libdir=/usr/lib/aarch64-linux-gnu --confdir=/etc/mpv 
--zshdir=/usr/share/zsh/vendor-completions --enable-cdda --enable-dvdnav 
--enable-libmpv-shared --enable-sdl2 --disable-build-date --enable-dvbin
-[cplayer] List of enabled features: alsa asm caca cdda cplayer cplugins 
cuda-hwaccel 

Bug#1027443: python3-pyqt6: Package cannot be installed. It depends on 'qt6-base-abi =6.3.1' which does not exist.

[Tim Magee]

Hi Dmitry,

Wow that's great news, thanks!

Tim


On Sat, 31 Dec 2022 20:59:57 +0300 Dmitry Shachnev 
wrote:
> Hi Tim!
> 
> On Sat, Dec 31, 2022 at 03:10:10PM +, Tim Magee wrote:
> > Package: python3-pyqt6
> > Version: 6.4.0-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > I'm using SID, so I realise that I've brought this on myself, but
> > the package probably still needs fixing before it gets assimilated
> > into a release.
> >
> > I wanted to install python3-pyqt6 using synaptic.
> >
> > I first tried using synaptic: select the package, mark for
> > installation, apply -- the usual.
> >
> > When I saw that qt6-base-abi was missing I reloaded package
> > information. qt6-base-abi was still missing but in an access of
> > optimism I retried the install anyway, without success, same reason.
> 
> We are in process of upgrading Qt from 6.3 to 6.4 [1], so some
> packages are temporarily uninstallable.
> 
> It will be resolved in a few days.
> 
> [1]: https://release.debian.org/transitions/html/qt6baseabi-6.4.2.html
> 
> --
> Dmitry Shachnev



-- 
Tim Magee

Bug#1027453: aufs-dkms: Breaks update to kernel versions >= 6.0

[smheidrich]

Package: aufs-dkms
Version: 5.2+20190909-1.1
Severity: normal
X-Debbugs-Cc: smheidr...@weltenfunktion.de

Dear Maintainer,

I'm using Debian testing (bookworm) and have aufs-dkms installed because it's
required by Docker. When I performed an `apt dist-upgrade` today, I got this
error, presumably stemming from aufs-dkms being incompatible with the current
latest kernel version (6.0):

```
Setting up linux-headers-6.0.0-6-amd64 (6.0.12-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-6-amd64:Sign command:
/usr/lib/linux-kbuild-6.0/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/aufs/5.2+20190909/6.0.0-6-amd64/x86_64/dkms.conf for
module aufs includes a BUILD_EXCLUSIVE directive which does not match this
kernel/arch/config.
This indicates that it should not be built.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-
headers-6.0.0-6-amd64.postinst line 11.
```

Is there any way to mark aufs-dkms as being incompatible with kernels >= 6.0
for the time being so that newer kernel versions are held back?

Thank you in advance!


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

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

Versions of packages aufs-dkms depends on:
ii  dkms  3.0.9-1

Versions of packages aufs-dkms recommends:
ii  aufs-tools  1:4.14+20190211-1

Versions of packages aufs-dkms suggests:
pn  aufs-dev  

-- no debconf information

Bug#1027454: ITP: arjun -- HTTP parameter discovery suite

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com, 
debian-security-to...@lists.debian.org, s0m...@gmail.com

* Package name: arjun
  Version : 2.2.1
  Upstream Contact: Somdev Sangwan 
* URL : https://github.com/s0md3v/Arjun
* License : AGPL-3
  Programming Lang: Python
  Description : HTTP parameter discovery suite

 This package can find query parameters for URL endpoints. If you don't get
 what that means, it's okay, read along.
 .
 Web applications use parameters (or queries) to accept user input, take the
 following example into consideration:
 http://api.example.com/v1/userinfo?id=751634589
 .
 This URL seems to load user information for a specific user id, but what if
 there exists a parameter named admin which when set to True makes the
 endpoint provide more information about the user?
 This is what Arjun does, it finds valid HTTP parameters with a huge default
 dictionary of 25,890 parameter names.

Bug#1026633: Grig

[Black Michael]

I fixed Grig to work with the current hamlib.

I'm calling it 0.8.2

https://www.dropbox.com/s/stxbn22sj45ssor/grig-0.8.2.tar.gz?dl=0

Mike W9MDB

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

[Nilesh Patra]

Hi Etienne,

On Fri, 30 Dec 2022 16:01:00 +0100 =?utf-8?Q?=C3=89tienne?= Mollier 
 wrote: 
> Nilesh Patra, on 2022-12-30:
> >   File "/<>/setup.py", line 130, in 
> > ext_modules=get_ext_modules(),
> > ^
> >   File "/<>/setup.py", line 81, in get_ext_modules
> > extra_link_args=pysam.get_libraries(),
> > ^
> >   File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in 
> > get_libraries
> > return [os.path.join(dirname, x + so) for x in pysam_libs]
> >^^^
> >   File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in 
> > 
> > return [os.path.join(dirname, x + so) for x in pysam_libs]
> >   ~~^~~~
> > TypeError: can only concatenate str (not "NoneType") to str
> 
> Thanks for catching this, I confirm I can reproduce the error
> without pairtools in the loop.  Given the reproducer.py below:
> 
>   import pysam
>   for lib in pysam.get_libraries():
>   print(lib)
> 
> I do get the error with python3.11:
> 
>   $ python3.11 reproducer.py
>   Traceback (most recent call last):
> File "/home/emollier/tmp/reproducer.py", line 2, in 
>   for lib in pysam.get_libraries():
>  ^
> File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in 
> get_libraries
>   return [os.path.join(dirname, x + so) for x in pysam_libs]
>  ^^^
> File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 100, in 
> 
>   return [os.path.join(dirname, x + so) for x in pysam_libs]
> ~~^~~~
>   TypeError: can only concatenate str (not "NoneType") to str
> 
> Besides, the error looks genuine since in python3.10, the output
> seems to return the expected result:

I believe I have fixed this particular problem in next pysam upload. However, 
the issue
with bam_dup1 and a bunch of other functions in pysam still remains.
I had to hack around by applying this patch in pairtools


https://salsa.debian.org/med-team/pairtools/-/blob/master/debian/patches/fix-pysam-ftbfs.patch

IMHO this really is un-called for, as pysam should resolve these things. In 
particular,
pysam declared in pysam/libchtslib.pxd and there are also a bunch of htslib 
imports in
htslib_util.h but probably those function defs have been removed in those 
htslib headers.

In particular we are likely bitten by htslib vers moving async with what pysam 
is expecting.
These should be fixed prior to release I guess :)

>   $ python3.10 reproducer.py

Curious -- what script is this? :)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Samuel Thibault]

control: block 1027446 by 1027450
control: merge 1027448 1027450

Hello,

Παύλος Γκέσος, le sam. 31 déc. 2022 20:38:23 +0200, a ecrit:
> unifont issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027450

I should have be explicit about it: the few "control:" lines at the top
of my mail had already created a report there. Now merging the two to
avoid a duplicate.

Samuel

Bug#1027452: libmutter-11-0: ffmpeg kmsgrab stopped working after update from 43.2-2 to 43.2-4

[Alexandr Podgorniy]

Package: libmutter-11-0
Version: 43.2-4
Severity: normal
X-Debbugs-Cc: sca...@scaledteam.ru

Dear Maintainer, i used to capture my screen with ffmpeg kmsgrab feature, it
really simple and very effective. But after update from 43.2-2 to 43.2-4 it
captures very distorted images. My own programs for capturing based in same
principle stopped working too, for example, my fork of OBS Studio with this
feature. (https://github.com/scaledteam/obs-studio)

It appears in Gnome Wayland, but Gnome X11 works fine.

To test this, run this command:
sudo ffmpeg -framerate 30  -device /dev/dri/card0 -f kmsgrab -i - -vf
'hwmap=derive_device=vaapi,scale_vaapi=format=nv12' -c:v h264_vaapi output.mp4

This is zero-copy capture, which means very low CPU load and ability to capture
giant resolutions with almost 0% cpu usage.


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

Kernel: Linux 6.1.0-0-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libmutter-11-0 depends on:
ii  adwaita-icon-theme 43-1
ii  gsettings-desktop-schemas  43.0-1
ii  libatk1.0-02.46.0-4
ii  libc6  2.36-7
ii  libcairo-gobject2  1.16.0-7
ii  libcairo2  1.16.0-7
ii  libcanberra0   0.30-10
ii  libcolord2 1.4.6-2.1
ii  libdrm22.4.114-1
ii  libegl11.5.0-1
ii  libfontconfig1 2.13.1-4.5
ii  libfribidi01.0.8-2.1
ii  libgbm122.2.4-1
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1
ii  libgl1 1.5.0-1
ii  libglib2.0-0   2.74.4-1
ii  libgnome-desktop-3-20  43-2
ii  libgraphene-1.0-0  1.10.8-1
ii  libgtk-3-0 3.24.35-3
ii  libgudev-1.0-0 237-2
ii  libice62:1.0.10-1
ii  libinput10 1.22.0-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblcms2-2 2.13.1-1+b1
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpipewire-0.3-0  0.3.63-1
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0252.4-1
ii  libudev1   252.4-1
ii  libwacom9  2.5.0-1
ii  libwayland-server0 1.21.0-1
ii  libx11-6   2:1.8.3-3
ii  libx11-xcb12:1.8.3-3
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.15-1
ii  libxcb-res01.15-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxkbcommon-x11-0 1.4.1-1
ii  libxkbcommon0  1.4.1-1
ii  libxkbfile11:1.1.0-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxtst6   2:1.2.3-1.1
ii  mutter-common  43.2-4

libmutter-11-0 recommends no packages.

libmutter-11-0 suggests no packages.

Versions of packages libmutter-11-0 is related to:
ii  libegl-mesa0 [libegl-vendor]  22.2.4-1
ii  libgl1-mesa-dri   22.2.4-1
ii  libglx-mesa0 [libglx-vendor]  22.2.4-1

-- no debconf information

Bug#1019416: transition: wxwidgets3.2

[Sebastian Ramacher]

Hi Scott

On 2022-12-30 16:03:40 -0500, Scott Talbert wrote:
> On Fri, 9 Sep 2022, Sebastian Ramacher wrote:
> 
> > The tracker is at
> > https://release.debian.org/transitions/html/wxwidgets-3.2.html. I have
> > changed the is_good and is_bad to check for dependencies of the binary
> > packges as .build-depends are not check for binary packages. Let me know
> > if that misses anything.
> 
> This tracker needs to be updated because of the other wxwidgets transition,
> I sent a merge request with what I think is required:
> 
> https://salsa.debian.org/release-team/transition-data/-/merge_requests/35/diffs

Merged, thanks.

The only remaining package is libalien-wxwidgets-perl. From [1] I
understand that updating it and libwx-perl is somewhat more involved.
Are there any news?

Cheers

[1] https://lists.debian.org/debian-perl/2022/11/msg0.html
-- 
Sebastian Ramacher

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Παύλος Γκέσος]

unifont issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027450

Bug#1027450: unifont: Glyphs for greek characters γ μ ζ ξ appear UGLY

[Παύλος Γκέσος]

γζξμ.png < USE THIS!
The fixed character glyphs.

console_original.png
How they appear in the tty right now.

console_fixed.png
How they appear in the tty after my design.

LibreOffice.png
How they appear in LibreOffice Windows (for optical comparison)

Microsoft console.png
How they appear in Microsoft Windows console (for optical comparison)

Bug#1026392: transition: gnat-12

[Sebastian Ramacher]

On 2022-12-31 16:33:12 +0100, Nicolas Boulenguez wrote:
> Package: release.debian.org
> Followup-For: Bug #1026392
> X-Debbugs-Cc: Calum McConnell , Andreas Bombe 
> 
> 
> Hello.
> 
> Here are the remaining blockers as far as I understand
> https://release.debian.org/transitions/html/gnat-12.html.
> 
> libxmlada (orange line):
> I fail to understand the problem.
> 
> libgmpada (red on i386):
> I have uploaded a patch transforming the error into a warning.
> The original bug remains but does not break the build anymore.
> I have downgraded the severity of #1026828 accordingly.
> Case closed.
> 
> whitakers-words (red line)
> is removed from testing and should not block the transition.
> The version in unstable depends on gnat-10 (none in experimental).
> What do you recommend?
> - avoid risking an interference with other packages
> - source-only bin-NMU by you (nmu line in the initial mail)

Scheduled now.

Cheers

> - normal upload to unstable
> - ?
> 
> ghdl (red line):
> is removed from testing and should not block the transition.
> The version in unstable depends on gnat-10 (lots of RC bugs).
> The version in experimental depends on gcc-12 (a few RC bugs).
> What do you recommend?
> - avoid risking an interferenc with other packages
> - reupload from experimental to unstable
> - ?
> 

-- 
Sebastian Ramacher

Bug#1026729: RC Bug #1026729: Forwarded to upstream PR

[s3v]

forwarded 1026729 https://github.com/opentracing/opentracing-python/pull/159
thanks

Bug#1027447: qemu: path to qemu-bridge-helper broken in qemu-system-* manuals

[Michael Tokarev]

Control: severity -1 minor
Control: tag -1 + confirmed upstream

31.12.2022 19:42, наб пишет:

Source: qemu
Version: 1:5.2+dfsg-11+deb11u2
Severity: normal

Dear Maintainer,

Quoth qemu-system-x86_64 (and -s390x):
  ... The default network helper executable is /path/to/qemu-bridge-helper ...


Indeed it is. No one bothered to fix that in the doc so far.
It's easy to find it though (in recent qemu it is in /usr/libexec/qemu/).

/mjt

Bug#1027451: libunwind-14-dev: spurious "Provides: libunwind-dev"

[Jakub Wilk]

Package: libunwind-14-dev
Version: 1:14.0.6-9+b1

This package has "libunwind-dev" in Provides, but it's not fully 
compatible with the real libunwind-dev package. Notably, it lacks the 
pkg-config file, and there are quite a few users of that:


https://codesearch.debian.net/search?q=%5CbPKG_CHECK_MODULES%5Cb.%2A%5Cblibunwind%5Cb


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

--
Jakub Wilk

Bug#1027450: unifont: Glyphs for greek characters γ μ ζ ξ appear UGLY

[Pavlos Gkesos]

Package: unifont
Severity: normal
X-Debbugs-Cc: gessos.p...@gmail.com

Dear Maintainer,

After a bug report in console-setup-linux Bug#1027446, the maintainers asked me 
to address here, because file Greek-Fixed16.psf.gz of their package, is 
produced by the unifont package.

The glyphs of greek letters γ μ ζ ξ appear UGLY in tty.
I re-design them (I am not a graphic designer, so I spent a lot of my time - 
please respect him)
γ = 0x3b3
μ = 0x3bc
ζ = 0x3b6 (higher that capitals)
ξ = 0x3be (higher that capitals)

(bug report created with `bugreport`. I will send a follow-up email with files)


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.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 unifont depends on:
pn  fonts-unifont  
pn  psf-unifont

Versions of packages unifont recommends:
pn  xfonts-unifont  

Versions of packages unifont suggests:
pn  unifont-bin  

Bug#1026392: transition: gnat-12

[Adrian Bunk]

[ I am not a member of the release team ]

On Sat, Dec 31, 2022 at 04:33:12PM +0100, Nicolas Boulenguez wrote:
>...
> Here are the remaining blockers as far as I understand
> https://release.debian.org/transitions/html/gnat-12.html.

Everything "sid only" is not a problem for the transition,
since the transition is about getting the change completed
in testing.

> libxmlada (orange line):
> I fail to understand the problem.

There is are cruft packages depending on old gnat, e.g.
libxmlada-dom7 | 22.0.0-3  | unstable   | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

These cruft packages are supposed to get autoremoved when nothing is 
left in unstable depending on them.

This is not a problem for the transition, but that's what makes the 
tracker orange.

>...
> whitakers-words (red line)
> is removed from testing and should not block the transition.
> The version in unstable depends on gnat-10 (none in experimental).
> What do you recommend?
>...
> - source-only bin-NMU by you (nmu line in the initial mail)
>...

That's IMHO the correct action.

> ghdl (red line):
> is removed from testing and should not block the transition.
> The version in unstable depends on gnat-10 (lots of RC bugs).
> The version in experimental depends on gcc-12 (a few RC bugs).
> What do you recommend?
> - avoid risking an interferenc with other packages
> - reupload from experimental to unstable
> - ?

The package in experimental is still broken on some architectures:
https://buildd.debian.org/status/package.php?p=ghdl=experimental

This is something the maintainer (or someone else) should fix,
bit due to "sid only" not a problem for the transition.

cu
Adrian

Bug#1027443: python3-pyqt6: Package cannot be installed. It depends on 'qt6-base-abi =6.3.1' which does not exist.

[Dmitry Shachnev]

Hi Tim!

On Sat, Dec 31, 2022 at 03:10:10PM +, Tim Magee wrote:
> Package: python3-pyqt6
> Version: 6.4.0-1
> Severity: important
>
> Dear Maintainer,
>
> I'm using SID, so I realise that I've brought this on myself, but the package
> probably still needs fixing before it gets assimilated into a release.
>
> I wanted to install python3-pyqt6 using synaptic.
>
> I first tried using synaptic: select the package, mark for installation, apply
> -- the usual.
>
> When I saw that qt6-base-abi was missing I reloaded package information.
> qt6-base-abi was still missing but in an access of optimism I retried the
> install anyway, without success, same reason.

We are in process of upgrading Qt from 6.3 to 6.4 [1], so some packages are
temporarily uninstallable.

It will be resolved in a few days.

[1]: https://release.debian.org/transitions/html/qt6baseabi-6.4.2.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1026828: downgrade the severity

[Nicolas Boulenguez]

Control: severity 1026828 normal
Control: tags 1026828 - ftbfs
Control: retitle 1026828 random print error for floats on i386

Version 1.5-3 transforms the error into a warning (with more debugging
info).
The original bug does not deserve a 'serious' severity.

Bug#1026392: transition: gnat-12

[Nicolas Boulenguez]

Package: release.debian.org
Followup-For: Bug #1026392
X-Debbugs-Cc: Calum McConnell , Andreas Bombe 


Hello.

Here are the remaining blockers as far as I understand
https://release.debian.org/transitions/html/gnat-12.html.

libxmlada (orange line):
I fail to understand the problem.

libgmpada (red on i386):
I have uploaded a patch transforming the error into a warning.
The original bug remains but does not break the build anymore.
I have downgraded the severity of #1026828 accordingly.
Case closed.

whitakers-words (red line)
is removed from testing and should not block the transition.
The version in unstable depends on gnat-10 (none in experimental).
What do you recommend?
- avoid risking an interference with other packages
- source-only bin-NMU by you (nmu line in the initial mail)
- normal upload to unstable
- ?

ghdl (red line):
is removed from testing and should not block the transition.
The version in unstable depends on gnat-10 (lots of RC bugs).
The version in experimental depends on gcc-12 (a few RC bugs).
What do you recommend?
- avoid risking an interferenc with other packages
- reupload from experimental to unstable
- ?

Bug#1027449: d/copyright is wrong

[Paul Tagliamonte]

Package: ruby-dbm
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

I've filed the bug since I wasn't sure if my email made it through due
to SMTP issues. Since I didn't see anything in git or any other acks,
I'll file the bug to help with tracking the issue.

I've marked this package for ACCEPT last night.

The debian/coypright file describes source files, not binaries. It looks
like ruby-dbm's copyright file added GPL-3+ because of the GDBM
implementation we link to, which is a welcome degree of diligence I do
appreciate, but it may change without the involvement of this source
package (if the implementation were to change, or how a downstream
changes the way the deb is built). If we had to list all the licensing
information of all our build-deps / links, things would get very messy
indeed! I'd expect someone to look through the dependency tree iff they
need to determine the binary distribution terms.

  paultag (on behalf of the ftpteam)


signature.asc
Description: PGP signature

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Samuel Thibault]

Παύλος Γκέσος, le sam. 31 déc. 2022 18:49:04 +0200, a ecrit:
> > These are coming from unifont, so that's where we should be fixing it.
> 
> I tried `dpkg -S filename` and it gives me console-setup-linux

Yes, but the psf file in the console-setup-linux package is generated
from the unifont package.

(actually, not yet, but that's the long-term plan).

Samuel

Bug#1025056: transition: numerical library transition: hypre / petsc / slepc / sundials

[Anton Gladky]

Hi Sebastian,

thanks for noting it! #1027402 is fixed now in unstable (that was wrong version
in Breaks+Replaces).

Regards

Anton

Am Sa., 31. Dez. 2022 um 14:20 Uhr schrieb Sebastian Ramacher
:
>
> Hi Anton
>
> On 2022-12-28 09:30:00 +0100, Anton Gladky wrote:
> > Hi Sebastian,
> >
> > sundials is already in NEW, fixing two RC bugs.
> > Dyssol will be uploaded shortly.
>
> It's now in unstable. Please also fix #1027402.
>
> Cheers
>
> >
> > Regards
> >
> > Anton
> >
> > Am Di., 27. Dez. 2022 um 12:23 Uhr schrieb Sebastian Ramacher
> > :
> > >
> > > Hi Drew, hi Anton
> > >
> > > On 2022-12-19 21:52:10 +0100, Sebastian Ramacher wrote:
> > > > Hi Drew
> > > >
> > > > On 2022-12-19 18:14:53 +0100, Drew Parsons wrote:
> > > > > The hypre/petsc part of this transition is complete.
> > > > >
> > > > > The sundials part is waiting for dyssol to be patched.  Anton is 
> > > > > preparing
> > > > > this.
> > > >
> > > > sundials will also need fixes for #1026330 and #1026352.
> > >
> > > Any news regarding sundials?
> > >
> > > Cheers
> > >
> > > >
> > > > Cheers
> > > >
> > > > >
> > > > > Drew
> > > > >
> > > > >
> > > > > On 2022-11-29 23:34, Sebastian Ramacher wrote:
> > > > > > Control: tags -1 confirmed
> > > > > >
> > > > > > Hi Drew
> > > > > >
> > > > > > On 2022-11-29 12:16:55 +0100, Drew Parsons wrote:
> > > > > > > Package: release.debian.org
> > > > > > > Severity: normal
> > > > > > > User: release.debian@packages.debian.org
> > > > > > > Usertags: transition
> > > > > > > X-Debbugs-Cc: Anton Gladky 
> > > > > > >
> > > > > > > We'd like to update the numerical library stack in time for the 
> > > > > > > new
> > > > > > > stable release.
> > > > > > >
> > > > > > > Affected libraries are
> > > > > > >
> > > > > > > hypre2.25.0 -> 2.26.0
> > > > > > > petsc/slepc3.17 -> 3.18
> > > > > > > sundials  5.8.0 -> 6.4.1
> > > > > > >
> > > > > > > Autotransitions are already generated:
> > > > > > > https://release.debian.org/transitions/html/auto-hypre.html
> > > > > > > https://release.debian.org/transitions/html/auto-petsc.html
> > > > > > > https://release.debian.org/transitions/html/auto-slepc.html
> > > > > > > https://release.debian.org/transitions/html/auto-sundials.html
> > > > > > >
> > > > > > > Most of the dependent packages are under our control
> > > > > > > (Debian Science Team), octave is the main one outside our team.
> > > > > > >
> > > > > > > Updates have built fine in experimental and dependent
> > > > > > > packages are building successfully against them.
> > > > > > >
> > > > > > > Anton Gladky will upload the sundials update.
> > > > > >
> > > > > > Please go ahead
> > > > > >
> > > > > > Cheers
> > > > >
> > > >
> > > > --
> > > > Sebastian Ramacher
> > > >
> > >
> > > --
> > > Sebastian Ramacher
> >
>
> --
> Sebastian Ramacher

Bug#1027442: coreutils: stty: soft-wrapping broken, wraps to cols+1

[Pádraig Brady]

On 31/12/2022 15:12, наб wrote:

Package: coreutils
Version: 8.30-3
Severity: normal

Dear Maintainer,

On all three versions, at my usual teletype size, I get:



$ COLUMNS=172 stty -a | wc -L
173


good catch!

This off by one bug was introduced in v5.3 (2005)

I'll apply the following upstream:

index b4c2cbecd..f3c7915e1 100644
--- a/src/stty.c
+++ b/src/stty.c
@@ -519,7 +519,7 @@ wrapf (char const *message,...)

   if (0 < current_col)
 {
-  if (max_col - current_col < buflen)
+  if (max_col - current_col <= buflen)
 {
   putchar ('\n');
   current_col = 0;

thanks,
Pádraig

Bug#1016963: Please test u-boot for a64-olinuxino-emmc

[Philip Rinn]

On 29.12.22 at 01:14, Vagrant Cascadian wrote:

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to 1016...@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.


a64-olinuxino-emmc


I tested all four versions and they work on my A64-Olinuxino-eMMC board. [Tested 
from and updated unstable installation.]


Best,
Philip

Bug#1027436: emacs-gtk: "systemd --user start emacs" fails to start and timeout

[Marc Kleine-Budde]

On 31.12.2022 14:53:03, Marc Kleine-Budde wrote:
> Package: emacs-gtk
> Version: 1:28.2+1-9
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>  update to emacs-gtk 28.x (probably from 27.x)

After downgrading to 27.x the problem persisted. Completely removing
Emacs and all elpa components and then reinstalling them fixed the
problem.

Sorry for the noise,
Marc


signature.asc
Description: PGP signature

Bug#1027429: mmdebstrap: unshare backend not working

[Johannes Schauer Marin Rodrigues]

Quoting Andrea Pappacoda (2022-12-31 16:29:00)
> Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer 
> Marin Rodrigues  ha scritto:
> > Do you have a valid /etc/subuid? Mine says (josch is my username):
> > 
> > josch:10:65536
> 
> Nope, both /etc/subuid and subgid are empty on my system. They aren't 
> on my other one that doesn't use systemd-homed, so maybe these are 
> populated by useradd(8)?

That is correct.

> It seems that systemd's issue tracker has a relevant RFE still unresolved,
> ;

"Uh. The concept of subuids/subgids is just wrong, i am sorry. Static files in
/etc is even worse."

Sounds like that issue will remain open.

> maybe it makes sense to somewhat mention it in sbuild's manual page, it might
> not be obvious for users that don't know much about unshare and user
> namespaces.

But is a user not consciously making the choice for systemd-homed instead of
using the Debian defaults and should thus be prepared for the consequences of
that non-default choice? Recommending to add stuff to /etc/subuid and
/etc/subgid also doesn't sound like the correct choice if the upstream
maintainer of systemd-homed doesn't think it a good idea.

> In any case, manually putting tachi:10:65536 in subuid and subgid solved
> the issue. Thanks!

Nice!

> > How could the error message be improved?
> I'm not sure, I really don't know much about this subject :/

In your case, since the files were empty, the line you put in was the correct
solution. In other cases, where there is already content in these files, adding
a new entry is a bit more involved, as the offsets have to be computed
correctly. The reliable way to do it, is to use useradd but that is obviously
not a solution for systemd-homed users.

> > The error message in sbuild could certainly be improved. Could you try out
> > the following patch:
> Thanks, but I really don't have time know to apply it. Guess I'll let you
> know next year ;)

In my timezone this year only has six hours left, so fair enough. ;)

Thanks!

cheers, josch

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Samuel Thibault]

control: clone -1 -2
control: block -1 by -2
control: reassign -2 unifont
control: retitle -2 unifont: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for 
characters γ μ ζ ξ (with solution)

Hello,

Pavlos Gkesos, le sam. 31 déc. 2022 18:06:20 +0200, a ecrit:
> Greek characters μ ξ ζ γ appears UGLY.
> I fix them and I provide the new Greek-Fixed16.psf.gz

These are coming from unifont, so that's where we should be fixing it.

Samuel

Bug#1027447: qemu: path to qemu-bridge-helper broken in qemu-system-* manuals

[наб]

Source: qemu
Version: 1:5.2+dfsg-11+deb11u2
Severity: normal

Dear Maintainer,

Quoth qemu-system-x86_64 (and -s390x):
   -netdev 
tap,id=id[,fd=h][,ifname=name][,script=file][,downscript=dfile][,br=bridge][,helper=helper]
  Configure a host TAP network backend with ID id.

  Use  the  network script file to configure it and the network 
script dfile to deconfigure it. If name is not provided, the OS automatically 
provides one.
  The default network configure script is /etc/qemu-ifup and the 
default network deconfigure script is /etc/qemu-ifdown. Use script=no or 
downscript=no  to
  disable script execution.

  If  running  QEMU as an unprivileged user, use the network helper 
to configure the TAP interface and attach it to the bridge.  The default 
network helper
  executable is /path/to/qemu-bridge-helper and the default bridge 
device is br0.

  fd=h can be used to specify the handle of an already opened host 
TAP interface.

  Examples:

 #launch a QEMU instance with the default network script
 qemu-system-x86_64 linux.img -nic tap

 #launch a QEMU instance with two NICs, each one connected
 #to a TAP device
 qemu-system-x86_64 linux.img \
 -netdev tap,id=nd0,ifname=tap0 -device 
e1000,netdev=nd0 \
 -netdev tap,id=nd1,ifname=tap1 -device 
rtl8139,netdev=nd1

 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge br0
 qemu-system-x86_64 linux.img -device virtio-net-pci,netdev=n1 \
 -netdev tap,id=n1,"helper=/path/to/qemu-bridge-helper"

   -netdev bridge,id=id[,br=bridge][,helper=helper]
  Connect a host TAP network interface to a host bridge device.

  Use  the  network  helper  helper  to  configure  the  TAP  
interface  and  attach  it  to  the  bridge.  The  default  network  helper   
executable   is
  /path/to/qemu-bridge-helper and the default bridge device is br0.

  Examples:

 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge br0
 qemu-system-x86_64 linux.img -netdev bridge,id=n1 -device 
virtio-net,netdev=n1

 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge qemubr0
 qemu-system-x86_64 linux.img -netdev bridge,br=qemubr0,id=n1 
-device virtio-net,netdev=n1

And, well, if the default executable is /path/to/qemu-bridge-helper then
it's broken, because that's /usr/lib/qemu/qemu-bridge-helper,
according to dpkg -S.

If it's not then the manual's broken, because it doesn't match the
actual path.

Best,
наб

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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


signature.asc
Description: PGP signature

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Παύλος Γκέσος]

I provide the following files:

Greek-Fixed16_original.psf
It is the current console font.

Greek-Fixed16.psf
It is the new-corrected console font

Greek-Fixed16.psf.gz
It is the new-corrected console font compressed

console_original.png
How the current glyphs appear in Debian tty.

console_fixed.png
How the new-corrected glyphs appear in Debian tty.

LibreOffice.png
How the glyphs appear in LibreOffce (just to have a visual compare)

Microsoft console.png
How the glyphs appear in Microsoft Windows console (just to have a
visual compare)


Greek-Fixed16_original.psf
Description: Binary data


Greek-Fixed16.psf
Description: Binary data


Greek-Fixed16.psf.gz
Description: application/gzip

Bug#1027446: console-setup-linux: Super-Ugly glyphs inside Greek-Fixed16.psf.gz for characters γ μ ζ ξ (with solution)

[Pavlos Gkesos]

Package: console-setup-linux
Version: 1.215
Severity: normal
X-Debbugs-Cc: gessos.p...@gmail.com

Dear Maintainer,

Greek characters μ ξ ζ γ appears UGLY.
I fix them and I provide the new Greek-Fixed16.psf.gz
Please do not ignore because I am not a graphist and I spend a lot of time for 
just 4 chars.

(This message created from `reportbug`. I will send images and files with a 
follow-up email).



*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.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 console-setup-linux depends on:
ii  init-system-helpers 1.65.2
ii  kbd 2.5.1-1
ii  keyboard-configuration  1.215

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
ii  console-setup  1.215

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.80
ii  liblocale-gettext-perl  1.07-5
ii  xkb-data2.35.1-1

Versions of packages console-setup depends on:
ii  debconf [debconf-2.0]   1.5.80
ii  keyboard-configuration  1.215
ii  xkb-data2.35.1-1

Versions of packages console-setup suggests:
ii  locales2.36-7
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages console-setup-linux is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.5.1-1
ii  systemd   252.4-1

-- debconf information:
  console-setup/framebuffer_only:
* keyboard-configuration/compose: No compose key
* keyboard-configuration/variant: Ελληνικό
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/xkb-keymap: gr
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/modelcode: pc105
  console-setup/use_system_font:
* keyboard-configuration/layoutcode: us,gr
* keyboard-configuration/model: Generic 105-key PC
* console-setup/fontface47: Fixed
  keyboard-configuration/unsupported_config_layout: true
* console-setup/codeset47: # Greek
* console-setup/charmap47: UTF-8
* console-setup/fontsize-fb47: 8x16
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/toggle: Alt+Shift
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/other:
  console-setup/codesetcode: Greek
  keyboard-configuration/unsupported_layout: true
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/layout:
* keyboard-configuration/optionscode: 
grp:alt_shift_toggle,lv3:ralt_alt,grp_led:scroll
  console-setup/fontsize: 8x16
  console-setup/guess_font:
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/switch: No temporary switch
* keyboard-configuration/altgr: No AltGr key
* keyboard-configuration/variantcode: ,

Bug#1027445: ITP: mpv.el -- control a mpv via its IPC interface from Emacs

[Martin]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: mpv.el
  Version : 0.2.0
  Upstream Author : Johann Klähn 
* URL or Web page : https://github.com/kljohann/mpv.el/
* License : GPL3+
  Programming Lang: Elisp
  Description : control a mpv via its IPC interface from Emacs

This package is a potpourri of helper functions to control a mpv process
via its IPC interface.

To start playback, have a look at mpv-play (for single files) and
mpv-start (for passing arbitrary arguments to mpv, e.g., URLs). Among
others, mpv.el provides

 - mpv-pause
 - mpv-kill
 - mpv-seek-forward / mpv-seek-backward
 - mpv-speed-increase / mpv-speed-decrease
 - mpv-volume-increase / mpv-volume-decrease
 - mpv-insert-playback-position
 - mpv-seek-to-position-at-point
 - mpv-playlist-next / mpv-playlist-prev

Bug#1027444: linux-signed-amd64: system crash after loading radeon module

[Giuseppe Sacco]

Source: linux-signed-amd64
Version: 6.0.12-1
Severity: important

Dear Maintainer,
I am using Debian testing on a DELL Precision M4700. After today upgrade, while 
the system
was running but the screen was blanked, the system become unusable: the fans 
were spinning
at maximum speed, the screen was black, no SSH login was possible, nothing 
could be done
for unlocking it.

I powered off the laptop using the power botton and started it again. After the 
grub screen and
normal kernel output, the system blocked again. I tried a few times getting the 
same
result. Booting without the default option "quiet", I saw that the last printed 
line was:

[drm] radeon kernel modesetting enabled.

The only way to boot the system again was adding parameter 
"module.blacklist=radeon" on the
grub parameters for the linux kernel.

The same behaviour happena with both kernel 6.0.0-5 and 6.0.0-6. I do not have 
tried with
older kernel.

All details follows:

The video adapter PCI:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Chelsea XT GL [FirePro M4000] (prog-if 00 [VGA controller])
Subsystem: Dell Chelsea XT GL [FirePro M4000]
Flags: bus master, fast devsel, latency 0, IRQ 11, IOMMU group 1
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f7e0 (64-bit, non-prefetchable) [size=256K]
I/O ports at e000 [size=256]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities: 
Kernel modules: radeon, amdgpu

The list of updated packages, today:

-rw-r--r-- 1 root root4199 31 dic 06.31 
/var/lib/dpkg/info/python3-pkg-resources.list
-rw-r--r-- 1 root root 314 31 dic 06.31 
/var/lib/dpkg/info/python3-setuptools-whl.list
-rw-r--r-- 1 root root 234 31 dic 06.31 
/var/lib/dpkg/info/gcc-12-base:amd64.list
-rw-r--r-- 1 root root 233 31 dic 06.31 
/var/lib/dpkg/info/gcc-12-base:i386.list
-rw-r--r-- 1 root root 700 31 dic 06.31 
/var/lib/dpkg/info/libstdc++6:amd64.list
-rw-r--r-- 1 root root 690 31 dic 06.31 
/var/lib/dpkg/info/libstdc++6:i386.list
-rw-r--r-- 1 root root 187 31 dic 06.31 
/var/lib/dpkg/info/libquadmath0:amd64.list
-rw-r--r-- 1 root root 181 31 dic 06.31 
/var/lib/dpkg/info/libquadmath0:i386.list
-rw-r--r-- 1 root root 175 31 dic 06.31 
/var/lib/dpkg/info/libgomp1:amd64.list
-rw-r--r-- 1 root root 169 31 dic 06.31 
/var/lib/dpkg/info/libgomp1:i386.list
-rw-r--r-- 1 root root 187 31 dic 06.31 
/var/lib/dpkg/info/libgfortran5:amd64.list
-rw-r--r-- 1 root root 181 31 dic 06.31 
/var/lib/dpkg/info/libgfortran5:i386.list
-rw-r--r-- 1 root root 181 31 dic 06.31 
/var/lib/dpkg/info/libatomic1:amd64.list
-rw-r--r-- 1 root root 175 31 dic 06.31 
/var/lib/dpkg/info/libatomic1:i386.list
-rw-r--r-- 1 root root 173 31 dic 06.31 
/var/lib/dpkg/info/libcc1-0:amd64.list
-rw-r--r-- 1 root root 172 31 dic 06.31 
/var/lib/dpkg/info/libitm1:amd64.list
-rw-r--r-- 1 root root 175 31 dic 06.31 
/var/lib/dpkg/info/libasan8:amd64.list
-rw-r--r-- 1 root root 175 31 dic 06.31 
/var/lib/dpkg/info/liblsan0:amd64.list
-rw-r--r-- 1 root root 175 31 dic 06.31 
/var/lib/dpkg/info/libtsan2:amd64.list
-rw-r--r-- 1 root root 178 31 dic 06.31 
/var/lib/dpkg/info/libubsan1:amd64.list
-rw-r--r-- 1 root root 519 31 dic 06.31 /var/lib/dpkg/info/g++-12.list
-rw-r--r-- 1 root root   41909 31 dic 06.31 
/var/lib/dpkg/info/libstdc++-12-dev:amd64.list
-rw-r--r-- 1 root root 263 31 dic 06.31 
/var/lib/dpkg/info/libobjc4:amd64.list
-rw-r--r-- 1 root root 984 31 dic 06.31 
/var/lib/dpkg/info/libobjc-12-dev:amd64.list
-rw-r--r-- 1 root root1171 31 dic 06.31 /var/lib/dpkg/info/gfortran-12.list
-rw-r--r-- 1 root root 401 31 dic 06.31 
/var/lib/dpkg/info/libgfortran-12-dev:amd64.list
-rw-r--r-- 1 root root8899 31 dic 06.31 
/var/lib/dpkg/info/libgcc-12-dev:amd64.list
-rw-r--r-- 1 root root2359 31 dic 06.31 /var/lib/dpkg/info/gcc-12.list
-rw-r--r-- 1 root root 320 31 dic 06.31 /var/lib/dpkg/info/cpp-12.list
-rw-r--r-- 1 root root 130 31 dic 06.31 /var/lib/dpkg/info/libx32ubsan1.list
-rw-r--r-- 1 root root 100 31 dic 06.31 /var/lib/dpkg/info/libx32gcc-s1.list
-rw-r--r-- 1 root root 302 31 dic 06.31 
/var/lib/dpkg/info/libx32stdc++6.list
-rw-r--r-- 1 root root 139 31 dic 06.31 
/var/lib/dpkg/info/libx32quadmath0.list
-rw-r--r-- 1 root root 124 31 dic 06.31 /var/lib/dpkg/info/libx32itm1.list
-rw-r--r-- 1 root root 127 31 dic 06.31 /var/lib/dpkg/info/libx32gomp1.list
-rw-r--r-- 1 root root 133 31 dic 06.31 
/var/lib/dpkg/info/libx32atomic1.list
-rw-r--r-- 1 root root 181 31 dic 06.31 
/var/lib/dpkg/info/libgccjit0:amd64.list
-rw-r--r-- 1 root root 126 31 dic 06.31 /var/lib/dpkg/info/lib32ubsan1.list
-rw-r--r-- 1 root root  97 31 dic 06.31 /var/lib/dpkg/info/lib32gcc-s1.list
-rw-r--r-- 1 root root 296 31 dic 06.31 /var/lib/dpkg/info/lib32stdc++6.list
-rw-r--r-- 1 root root 135 31 dic 06.31 

Bug#1027443: python3-pyqt6: Package cannot be installed. It depends on 'qt6-base-abi =6.3.1' which does not exist.

[Tim Magee]

Package: python3-pyqt6
Version: 6.4.0-1
Severity: important

Dear Maintainer,

I'm using SID, so I realise that I've brought this on myself, but the package
probably still needs fixing before it gets assimilated into a release.

I wanted to install python3-pyqt6 using synaptic.

I first tried using synaptic: select the package, mark for installation, apply
-- the usual.

When I saw that qt6-base-abi was missing I reloaded package information.
qt6-base-abi was still missing but in an access of optimism I retried the
install anyway, without success, same reason.

Desperation move: I dropped to CLI and tried 'sudo apt install python3-qt6',
without much hope of success. My lack of hope was justified ;)

My expected outcome: python3-pyqt6 to be installed, and perhaps some
dependencies.

I've marked this 'important' because it fits the description in reportbug: it's
prevented the package from being installed, although probably only for my
fellow SIDianites.

Thanks!
Tim


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

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

Versions of packages python3-pyqt6 depends on:
ii  libc6   2.36-7
ii  libqt6core6 [qt6-base-abi]  6.4.2+dfsg~rc1-3
ii  libqt6dbus6 6.4.2+dfsg~rc1-3
ii  libqt6gui6  6.4.2+dfsg~rc1-3
ii  libqt6network6  6.4.2+dfsg~rc1-3
ii  libqt6opengl6   6.4.2+dfsg~rc1-3
ii  libqt6openglwidgets66.4.2+dfsg~rc1-3
ii  libqt6printsupport6 6.4.2+dfsg~rc1-3
ii  libqt6sql6  6.4.2+dfsg~rc1-3
ii  libqt6test6 6.4.2+dfsg~rc1-3
ii  libqt6widgets6  6.4.2+dfsg~rc1-3
ii  libqt6xml6  6.4.2+dfsg~rc1-3
ii  libstdc++6  12.2.0-11
ii  python3 3.10.6-3+b1
ii  python3-pyqt6.sip   13.4.0-2+b1

python3-pyqt6 recommends no packages.

python3-pyqt6 suggests no packages.

Bug#1027410: u-boot: Please add support for Asus TF101

[Diederik de Haas]

On Saturday, 31 December 2022 01:41:52 CET Vagrant Cascadian wrote:
> On 2022-12-31, Diederik de Haas wrote:
> > Does this mean that u-boot upstream supports the Asus TF101?
> > If so, what is needed to get it enabled in Debian?
> 
> It does not look like it is supported upstream...

Ok. Thanks for checking.

> > I haven't tried it yet, but apparently postmarketos supports it:
> > https://wiki.postmarketos.org/wiki/ASUS_Eee_Pad_Transformer_(asus-tf101)
> 
> I would guess postmarketos is more willing to support vendor forks to
> get specific boards enabled...
> 
> Reading some of the links referenced, sounds like the closest board
> supported in upstream u-boot might be configs/ventana_defconfig:
> 
>   https://github.com/grate-driver/linux/pull/23
> 
> The post was a little old (~2021), but referenced some things that might
> be useful in an upstream porting effort...

Because of a defective wall plug, the device was unused for some years, but 
recently got a working one from a friend. Charged it and it just worked :-D

I found that link too ... and then some :-O
Amongst other things, it looks like the device is supported in the upstream 
Linux kernel \o/
And only a few days ago, people were actively working on improving things for 
the TF101!

> So, in short, get it supported in upstream u-boot and then we can enable it
> in Debian. :)

I got quite a few things to learn, so it may take a while.
But what I found these last few days has got me super-charged :-)
So I'm going to try to help out too and will let you know when there are some 
results which are also usable for Debian.

> live well,
>   vagrant

You too,
  Diederik

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

Bug#1027429: mmdebstrap: unshare backend not working

[Andrea Pappacoda]

Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer 
Marin Rodrigues  ha scritto:

Do you have a valid /etc/subuid? Mine says (josch is my username):

josch:10:65536


Nope, both /etc/subuid and subgid are empty on my system. They aren't 
on my other one that doesn't use systemd-homed, so maybe these are 
populated by useradd(8)?


It seems that systemd's issue tracker has a relevant RFE still 
unresolved, ; maybe it 
makes sense to somewhat mention it in sbuild's manual page, it might 
not be obvious for users that don't know much about unshare and user 
namespaces.


In any case, manually putting tachi:10:65536 in subuid and subgid 
solved the issue. Thanks!



How could the error message be improved?


I'm not sure, I really don't know much about this subject :/

The error message in sbuild could certainly be improved. Could you 
try out the

following patch:


Thanks, but I really don't have time know to apply it. Guess I'll let 
you know next year ;)


Thanks again!

Bug#1027442: coreutils: stty: soft-wrapping broken, wraps to cols+1

[наб]

Package: coreutils
Version: 8.30-3
Severity: normal

Dear Maintainer,

On all three versions, at my usual teletype size, I get:
-- >8 --
$ stty -a
speed 38400 baud; rows 54; columns 172; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase 
= ^W; lnext = ^V;
discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff 
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
-- >8 --

Or, more to the point:
-- >8 --
$ COLUMNS=172 stty -a | wc -L
173
-- >8 --

Cf. screenshot.

stty -g for easy repro:
  
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Best,
наб

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-2
ii  libattr1 1:2.5.1-3
ii  libc62.36-6
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b4

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1026421: Bug #1026421 rclone should have a build dependency on golang >= 1.17

[Drew Parsons]

severity 1026421 important
thanks

The version of rclone in testing is not directly intended to be built on 
stable, hence this bug is not Severity: serious (it builds fine in 
unstable and testing).


Severity: serious is intended to mark packages which are not fit for 
release in testing (the future stable release).

Bug#1027289: transition: libcamera

[Dylan Aïssi]

Hi Sebastian,

Le sam. 31 déc. 2022 à 13:19, Sebastian Ramacher  a
écrit :
>
> On 2022-12-29 23:01:28 +0100, Dylan Aïssi wrote:
> > Dear Release Team,
> >
> > Please schedule a transition slot for libcamera.
> >
>
> Please go ahead

Thanks. Uploaded!

Best,
Dylan

Bug#1027441: cups-client: prints on one side, even when the default is two-sided-long-edge or an explicit option is passed to lpr

[Francesco Poli (wintermute)]

Package: cups-client
Version: 2.4.2-1+b2
Severity: important

Hello Debian Printing Team (and Season's Greetings!).

I am experiencing a bug with CUPS: at some point in time in the past
(unfortunately I do not remember exactly with which version, sorry,
I do not print stuff on a daily basis...) CUPS began ignoring the
sides= option value and began printing on one side only.

I remember seeing this issue on other Debian testing boxes with
other printers, but let's focus on the box I am writing this bug
report from.
The printer is an HP LaserJet 1320 printer connected via USB cable,
but I don't think the make and model makes too much of a difference...

The following options are set as default:

  $ lpoptions -p lj
  copies=1 device-uri=usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9 
finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 
job-sheets=none,none marker-change-time=0 media=A4 number-up=1 
pdftops-renderer=pdftops pdftops-renderer-default=pdftops 
print-color-mode=monochrome 
printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='HP 
LaserJet 1320' printer-is-accepting-jobs=true printer-is-shared=true 
printer-is-temporary=false printer-location=local printer-make-and-model='HP 
LaserJet 1320 Foomatic/pxlmono (recommended)' printer-state=3 
printer-state-change-time=1569079565 printer-state-reasons=none 
printer-type=8564756 printer-uri-supported=ipp://localhost:631/printers/lj 
sides=two-sided-long-edge

Please note that the default is 'sides=two-sided-long-edge'.
However, if I print any multi-page document:

  $ lpr -P lj foo.pdf

I obtain one document page per sheet of paper, that is to say, a one-sided
print, which is almost always *not* what I want (in order to reduce the
waste of paper, the environmental impact, and so forth...).

Even passing explicit options changes nothing:

  $ lpr -P lj -o sides=two-sided-long-edge foo.pdf
  $ lpr -P lj -o fit-to-page -o sides=two-sided-long-edge foo.pdf

It seems that the sides= option is completely ignored.

I have browsed the Debian BTS and found other bug reports that seem
to be related.
Bug [#994395] is similar, but the bug report submitter sees a
'sides=one-sided' default with lpoptions, which is different from
the behavior I am experiencing.
Bug [#1008175] looks much more similar, but was closed as due to
a printer firmware bug. This sounds very awkward to me, but anyway,
in the case of my printer, I am sure I haven't updated its firmware
for ages (and it's not connected to the network, so it cannot even
have auto-updated its own firmware without asking me). This means
that, if the firmware is buggy, it has been buggy for a long time,
and it was buggy even when CUPS was perfectly able to print two-sided.
In other words, if a buggy firmware is to be blamed, CUPS used to
be able to work around this firmware bug and is now no longer able
to do so. So, in any case, there's something that needs to be fixed
in CUPS...

[#994395]: 
[#1008175]: 

Please investigate and fix this bug and/or forward my bug report
upstream, as appropriate.

Thanks for your time and patience!



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

Kernel: Linux 6.0.0-6-686 (SMP w/1 CPU thread; 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

Versions of packages cups-client depends on:
ii  adduser  3.129
ii  cups-common  2.4.2-1
ii  libc62.36-7
ii  libcups2 2.4.2-1+b2

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.4.2-1+b2
ii  cups-bsd   2.4.2-1+b2
pn  smbclient  

-- no debconf information

Bug#1027359: [Pkg-electronics-devel] Bug#1027359: arduino-builder: FTBFS in bullseye (missing build-depends on tzdata)

[Rock Storm]

On Sat, 2022-12-31 at 15:15 +0100, Santiago Vila wrote:
> El 31/12/22 a las 14:33, Rock Storm escribió:
> > This is interesting because that test didn't fail before and we
> > didn't
> > need the tzdata package installed.
> 
> The tests always failed (in bullseye) in a chroot not containing
> tzdata.
>  From my own autobuilders:
> 
> Status: failed  arduino-builder_1.3.25-2_amd64-
> 20210129T121615.663Z
> Status: failed  arduino-builder_1.3.25-2_amd64-
> 20210129T132227.024Z
> 
> Part of the problem is that debootstrap installs tzdata by default
> even
> if it's not build-essential, but that's a bug in debootstrap:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060
> 
> The other part of the problem is that people use debootstrap "as is",
> without asking it not to install tzdata, which produces non-minimal
> chroots in which packages which build ok are still not guaranteed
> to have their build-dependencies right.

This makes perfect sense. Thanks for the explanation.

Happy new year!

-- 
⢀⣤⣀⣼⣧⣀⣤⡀  Rock Storm
⣀⣿⣿⠟⠻⣿⣿⣀  Open Source Advocate
⠛⣿⣿⡄⢠⣿⣿⠛  https://github.com/rockstorm101
⠰⡿⠿⠁⠈⠿⢿⠆  C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#1027411: rednotebook: en_GB translation uses German word "Zurück" for "Back"

[Philip Wyett]

On Sat, 2022-12-31 at 06:07 +, Philip Wyett wrote:
> On Sat, 2022-12-31 at 13:59 +1300, Ash Joubert wrote:
> > There are more: the navigation dropdown has Vorwärts (Forwards), and the 
> > Help menu has a German entry (with German tooltip) for "Give Feedback". 
> > Everything else is in English. I do not speak German and have never used 
> > a German locale on any computer.
> > 
> > Kind regards,
> > 
> 
> Hi,
> 
> Thanks for the bug report.
> 
> I have reproduced and filed a bug upstream. See link below.
> 
> https://github.com/jendrikseipp/rednotebook/issues/659
> 
> Regards
> 
> Phil
> 

Fixed version 2.29 has been uploaded to unstable/sid and will appear in due 
course.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1027440: kamailio: FTBFS with Python 3.11 as default version

[Graham Inggs]

Source: kamailio
Version: 5.6.2-1
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

Kamailio's python extension fails to build with Python 3.11 as the
default version, and kamailio-python3-modules misses
/usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so, although
the build doesn't fail outright, due to the for loops in the
override_dh_auto_build target of debian/rules not exiting on error.

I've copied what I hope is the relevant part of the log below.

Regards
Graham


apy_kemi.c:1846:107: error: invalid use of incomplete typedef
‘PyFrameObject’ {aka ‘struct _frame’}
 1846 | (pframe &&
pframe->f_code)?PyCode_Addr2Line(pframe->f_code, pframe->f_lasti):0);
  |
   ^~
../../core/dprint.h:337:99: note: in definition of macro ‘LOG_FX’
  337 |
 LOGV_FUNCSUFFIX_STR(funcname), ## args); \
  |
   ^~~~
../../core/dprint.h:351:25: note: in expansion of macro ‘LOG_FL’
  351 | LOG_FL(facility, level, NULL, prefix,
fmt, ## args)
  | ^~
../../core/dprint.h:354:25: note: in expansion of macro ‘LOG_FP’
  354 | LOG_FP(DEFAULT_FACILITY, (level),
LOC_INFO, fmt, ## args)
  | ^~
apy_kemi.c:1839:25: note: in expansion of macro ‘LOG’
 1839 | LOG(cfg_get(core, core_cfg, latency_log),
  | ^~~
make[4]: *** [../../Makefile.rules:100: apy_kemi.o] Error 1
make[4]: *** Waiting for unfinished jobs
python_msgobj.c: In function ‘python_msgobj_init’:
python_msgobj.c:510:27: error: lvalue required as left operand of assignment
  510 | Py_TYPE() = _Type;
  |   ^
make[4]: *** [../../Makefile.rules:100: python_msgobj.o] Error 1
make[3]: *** [Makefile:513: install-modules] Error 1

Bug#1016963: Please test u-boot for orangepi_zero

[Mateusz Łukasik]

On 29.12.2022 at 01:59, Vagrant Cascadian wrote:

On 2022-12-28, Vagrant Cascadian wrote:

On 2022-12-22, Vagrant Cascadian wrote:

On 2022-08-20, Vagrant Cascadian wrote:

On 2022-08-10, Vagrant Cascadian wrote:

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
reporting the status:

   https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.

As the bookworm freeze approaches, this is getting to be... worrysome!

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to 1016...@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.

orangepi_zero

live well,
   vagrant



Mine orangepi_zero is dead, I can't tested it.

--
.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

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

[Paul Gevers]

Source: elementpath, python-xmlschema
Control: found -1 elementpath/3.0.2-1
Control: found -1 python-xmlschema/1.10.0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of elementpath the autopkgtest of python-xmlschema 
fails in testing when that autopkgtest is run with the binary packages 
of elementpath from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
elementpathfrom testing3.0.2-1
python-xmlschema   from testing1.10.0-3
all others from testingfrom testing

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

Currently this regression is blocking the migration of elementpath to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=elementpath

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

==
ERROR: test_xsd_file 
(xmlschema.testing._builders.TestSchema004.test_xsd_file)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 212, in test_xsd_file

self.check_xsd_file()
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 128, in check_xsd_file
xpath_context_elements = [x for x in context.iter() if 
isinstance(x, XsdValidator)]

 
AttributeError: 'XMLSchemaContext' object has no attribute 'iter'

==
ERROR: test_xsd_file 
(xmlschema.testing._builders.TestSchema005.test_xsd_file)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 212, in test_xsd_file

self.check_xsd_file()
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 128, in check_xsd_file
xpath_context_elements = [x for x in context.iter() if 
isinstance(x, XsdValidator)]

 
AttributeError: 'XMLSchemaContext' object has no attribute 'iter'

==
ERROR: test_xsd_file 
(xmlschema.testing._builders.TestSchema009.test_xsd_file)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 212, in test_xsd_file

self.check_xsd_file()
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 128, in check_xsd_file
xpath_context_elements = [x for x in context.iter() if 
isinstance(x, XsdValidator)]

 
AttributeError: 'XMLSchemaContext' object has no attribute 'iter'

==
ERROR: test_xsd_file 
(xmlschema.testing._builders.TestSchema011.test_xsd_file)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 212, in test_xsd_file

self.check_xsd_file()
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 128, in check_xsd_file
xpath_context_elements = [x for x in context.iter() if 
isinstance(x, XsdValidator)]

 
AttributeError: 'XMLSchemaContext' object has no attribute 'iter'

==
ERROR: test_xsd_file 
(xmlschema.testing._builders.TestSchema012.test_xsd_file)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 212, in test_xsd_file

self.check_xsd_file()
  File 
"/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py", 
line 128, in check_xsd_file
xpath_context_elements = [x for x in context.iter() if 
isinstance(x, XsdValidator)]

 
AttributeError: 'XMLSchemaContext' object has no attribute 

Bug#1005434: ruby-typhoeus: FTBFS: ERROR: Test "ruby3.0" failed: Timeout::Error:

[Paul Gevers]

Hi,

On Thu, 3 Nov 2022 09:46:43 +0100 s3v  wrote:

Dear Maintainer,

After applying the attached patch, I was able to build your package
in a sid chroot environment.
Please see [1] for more context.

Kind Regards

[1] https://bugs.ruby-lang.org/issues/14183

I have applied the patch and just uploaded it. @s3v: thanks for the patch.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027438: rrdtool: Please release version 1.8.0 to Debian

[Diederik de Haas]

Package: rrdtool
Version: 1.7.2-4+b7
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I saw on salsa that version 1.8.0 is already there (since 9 months), but
it looks like it never got uploaded to the Debian archive?
Could you do that? In time for the freeze?

TIA,
  Diederik

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 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

Versions of packages rrdtool depends on:
ii  libc6 2.36-7
ii  libglib2.0-0  2.74.4-1
ii  librrd8   1.7.2-4+b7

rrdtool recommends no packages.

Versions of packages rrdtool suggests:
pn  librrds-perl  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY7BFTAAKCRDXblvOeH7b
brgYAQD1Jk0ULIV6e4BDgL0nWIrTndhEzpEPZZlUDDPZoFyLnwEA1u0dKVxM3FlJ
x+cAzkP4vm7ED5Ou90mT5kBs0w6Fegc=
=caxy
-END PGP SIGNATURE-

Bug#1027359: [Pkg-electronics-devel] Bug#1027359: arduino-builder: FTBFS in bullseye (missing build-depends on tzdata)

[Santiago Vila]

El 31/12/22 a las 14:33, Rock Storm escribió:

This is interesting because that test didn't fail before and we didn't
need the tzdata package installed.


The tests always failed (in bullseye) in a chroot not containing tzdata.
From my own autobuilders:

Status: failed  arduino-builder_1.3.25-2_amd64-20210129T121615.663Z
Status: failed  arduino-builder_1.3.25-2_amd64-20210129T132227.024Z

Part of the problem is that debootstrap installs tzdata by default even
if it's not build-essential, but that's a bug in debootstrap:

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

The other part of the problem is that people use debootstrap "as is",
without asking it not to install tzdata, which produces non-minimal
chroots in which packages which build ok are still not guaranteed
to have their build-dependencies right.

(Fortunately I only found 25 packages in bullseye with this kind of
missing build-dependency, so I believe it's still feasible to make
bullseye policy compliant before it becomes oldstable).

Thanks.

Bug#1026298: datalad: FTBFS without network access

[Graham Inggs]

Control: found -1 0.17.8-1

Now that chardet 5.1.0+dfsg-2 migrated to testing, datalad FTBFS there too.

Bug#1027437: keepassxc: autofill ignores xkeyboard layout

[pdormeau]

Package: keepassxc
Version: 2.7.4+dfsg.1-2
Severity: normal

Dear Maintainer,

After upgrading to 2.7.4 version, the autofill is no more usable as 
keepassxc ignores the xkeyboard layout.

My /etc/default/keyboard:
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="oss_latin9"
XKBOPTIONS="compose:lwin,ctrl:nocaps"
BACKSPACE="guess"

>From the /var/log/Xorg.0.log
[11.995] (II) XINPUT: Adding extended input device "AT Translated Set 2 
keyboard" (type: KEYBOARD, id 14)
[11.995] (**) Option "xkb_model" "pc105"
[11.995] (**) Option "xkb_layout" "fr"
[11.995] (**) Option "xkb_variant" "oss_latin9"
[11.995] (**) Option "xkb_options" "compose:lwin,ctrl:nocaps"

but for example "azerty" is typed as "qwerty" by the autofill function.

2.6.6 version works as expected.

Best regards


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 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 keepassxc depends on:
ii  libargon2-10~20171227-0.3
ii  libbotan-2-19  2.19.3+dfsg-1
ii  libc6  2.36-7
ii  libgcc-s1  12.2.0-11
ii  libminizip11.1-8+b1
ii  libpcsclite1   1.9.9-1
ii  libqrencode4   4.1.1-1
ii  libqt5concurrent5  5.15.7+dfsg-2
ii  libqt5core5a   5.15.7+dfsg-2
ii  libqt5dbus55.15.7+dfsg-2
ii  libqt5gui5 5.15.7+dfsg-2
ii  libqt5network5 5.15.7+dfsg-2
ii  libqt5svg5 5.15.7-2
ii  libqt5widgets5 5.15.7+dfsg-2
ii  libqt5x11extras5   5.15.7-2
ii  libreadline8   8.2-1.2
ii  libstdc++6 12.2.0-11
ii  libusb-1.0-0   2:1.0.26-1
ii  libx11-6   2:1.8.3-3
ii  libxtst6   2:1.2.3-1.1
ii  libzxcvbn0 2.5+dfsg-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages keepassxc recommends:
pn  fonts-font-awesome  

Versions of packages keepassxc suggests:
pn  webext-keepassxc-browser  
pn  xclip 

-- no debconf information

Bug#855931: ruby-eventmachine: flaky tests under some buildd conditions

[Paul Gevers]

retitle 855931 ruby-eventmachine: FTBFS due to hanging flaky tests
found 855931 1.3~pre20220315-df4ab006-3
retitle 998097 ruby-eventmachine: FTBFS on IPV6-only buildds
thanks

Hi,

On Wed, 8 Mar 2017 09:46:50 +0100 Antonio Terceiro  
wrote:

ruby-eventmachine is one the packages whose tests will go crazy on EC2,
probably due to some weirdness in how exactly EC2 VM's are configured.
Most likely something kernel-related.


This happens on the buildds too (3 times on release archs), see below.

Also, this package has had it's share of FTBFS bugs due to failing 
tests, so I wonder if this should be fixed with wack-a-mole or if it's 
better to disable the test suite. I tried to make sense of the different 
failures to fix bug 998097, but there have been so many tries to fix or 
disable several tests that I couldn't make sense of it in the time I 
spent on it. I have the feeling that some of the timeout issues are due 
to the test suite not properly cleaning up if one test fails and than 
hanging later on.


For documentation purposes, at least I got this from archeology (all but 
test_kb.rb pass on my system):

 disabled_tests= [
+  # has a tast that (sometimes?) seems to hang
   'tests/test_exc.rb',
+  # some tests requiring network access
   'tests/test_get_sock_opt.rb',
+  # several tests need internet (google.com)
   'tests/test_httpclient2.rb',
+  # several tests need internet (google.com)
   'tests/test_httpclient.rb',
+  # some tests requiring network access
   'tests/test_idle_connection.rb',
+  # mips sometimes too slow
   'tests/test_inactivity_timeout.rb',
+  # error: terminate called after throwing an instance of 
'std::runtime_error' what(): unable to add new descriptor: Operation not 
permitted

   'tests/test_kb.rb',
+  # one test needs internet (192.0.2.0)
   'tests/test_pending_connect_timeout.rb',
+  # several tests need internet
   'tests/test_resolver.rb',
+  # some tests requiring network access
   'tests/test_set_sock_opt.rb',
+  # one test needs internet (192.0.2.0)
   'tests/test_unbind_reason.rb',
 ]

https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine=amd64=1.3%7Epre20220315-df4ab006-3=1665953644=0

TestConnectionCount:
  test_idle_connection_count:   .: (0.000488)
  test_idle_connection_count_epoll: .: (0.000377)
  test_idle_connection_count_kqueue:.: (0.000320)
  test_num_close_scheduled: .: (0.000794)
  test_with_some_connections:   .: (0.001581)
TestConnectionWrite:
  test_with_naughty_callback:   .: (0.000710)
TestDefer:
  test_defers:  
E: Build killed with signal TERM after 150 minutes of inactivity


https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine=i386=1.3%7Epre20201020-b50c135-4%2Bb1=1635553347=0

TestConnectionCount:
  test_idle_connection_count:   .: (0.000292)
  test_idle_connection_count_epoll: .: (0.000344)
  test_idle_connection_count_kqueue:.: (0.000234)
  test_num_close_scheduled: .: (0.000539)
  test_with_some_connections:   .: (0.001199)
TestConnectionWrite:
  test_with_naughty_callback:   .: (0.000396)
TestDefer:
  test_defers:  
E: Build killed with signal TERM after 150 minutes of inactivity


https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine=s390x=1.2.7-1%7Eexp1=1546537666=0

TestSockOpt:
  test_get_sock_opt:.: (0.000343)
  test_set_sock_opt:.: (0.000254)
TestSomeExceptions:
  test_a:   .: (0.000130)
  test_b:   .: (0.72)
  test_exception_on_unbind: 
E: Build killed with signal TERM after 150 minutes of inactivity


Non release architectures:
alpha seems to suffer a lot from this, one example

https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine=alpha=1.0.7-4.2=1544037015=0 



TestConnectionCount:
  test_idle_connection_count:   .: (0.000977)
  test_num_close_scheduled: .: (15.075295)
  test_with_some_connections:   
E: Build killed with signal TERM after 150 minutes of inactivity


https://buildd.debian.org/status/fetch.php?pkg=ruby-eventmachine=hppa=1.3%7Epre20220315-df4ab006-3=1666020944=0

  test_attach_pipe: E
===
Error: test_attach_pipe(TestAttach): Errno::E111: Unknown error 111 - 
connect(2) for "127.0.0.1" port 486688568

/<>/tests/em_test_helper.rb:51:in `initialize'
/<>/tests/em_test_helper.rb:51:in `new'
/<>/tests/em_test_helper.rb:51:in `port_in_use?'

Bug#1027436: emacs-gtk: "systemd --user start emacs" fails to start and timeout

[Marc Kleine-Budde]

Package: emacs-gtk
Version: 1:28.2+1-9
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 update to emacs-gtk 28.x (probably from 27.x)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I'm running a systemd --user emacs daemon, with the update to emacs 28.x
 it fails to start.

   * What was the outcome of this action?

 An emacs server should be started as a systemd --user service.

   * What outcome did you expect instead?

 emacs fails to start and the systemd service unit timesout:

$ systemctl --user start emacs.service
Job for emacs.service failed because a timeout was exceeded.
See "systemctl --user status emacs.service" and "journalctl --user -xeu 
emacs.service" for details.

Dez 31 14:48:13 hardanger systemd[1453]: Starting Emacs text editor...
Dez 31 14:48:13 hardanger emacs[34959]: Warning: due to a long standing Gtk+ bug
Dez 31 14:48:13 hardanger emacs[34959]: 
https://gitlab.gnome.org/GNOME/gtk/issues/221
Dez 31 14:48:13 hardanger emacs[34959]: Emacs might crash when run in daemon 
mode and the X11 connection is unexpectedly lost.
Dez 31 14:48:13 hardanger emacs[34959]: Using an Emacs configured with 
--with-x-toolkit=lucid does not have this problem.
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/00debian.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/00debian.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50autoconf.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50autoconf.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50dictionaries-common.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading debian-ispell (native compiled 
elisp)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/var/cache/dictionaries-common/emacsen-ispell-default.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading debian-ispell (native compiled 
elisp)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50global.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50global.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50latexmk.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50latexmk.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50systemtap-common.el (source)...
Dez 31 14:48:13 hardanger emacs[34959]: Loading 
/etc/emacs/site-start.d/50systemtap-common.el (source)...done
Dez 31 14:48:13 hardanger emacs[34959]: Starting Emacs daemon.
Dez 31 14:51:13 hardanger systemd[1453]: emacs.service: start operation timed 
out. Terminating.
Dez 31 14:51:13 hardanger systemd[1453]: emacs.service: Failed with result 
'timeout'.
Dez 31 14:51:13 hardanger systemd[1453]: Failed to start Emacs text editor.
Dez 31 14:51:14 hardanger systemd[1453]: emacs.service: Scheduled restart job, 
restart counter is at 2.

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:28.2+1-9
ii  emacs-common 1:28.2+1-9
ii  libacl1  2.3.1-2
ii  libasound2   1.2.8-1
ii  libc62.36-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.4-1
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgccjit0   12.2.0-11
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.74.4-1
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libgnutls30  3.7.8-4
ii  libgpm2  1.20.7-10+b1
ii  libgtk-3-0   3.24.35-3
ii  libharfbuzz0b5.2.0-2+b1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  

Bug#1027002: vim-runtime: please add syntax highlighting and indentation support for the Nim language

[Francesco Poli]

On Fri, 30 Dec 2022 19:26:39 -0500 James McCoy wrote:

> On Fri, Dec 30, 2022 at 12:26:06PM +0100, Francesco Poli wrote:
[...]
> > Maybe nim.vim could be packaged as a Vim addon, as documented in the
> > Debian Packaging [Policy for Vim]. Is this possible?
> > 
> > [Policy for Vim]: 
> 
> Yes, if someone wanted to create a new package for the files in that
> repo, they could do that and package it as an addon.

OK, thanks for confirming.
I have just filed a RFP bug [#1027431] for nim.vim...

[#1027431]: 

Bye.


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


pgpFOGFMtXcSY.pgp
Description: PGP signature

Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

[Thomas Dickey]

On Sat, Dec 31, 2022 at 02:18:49PM +0100, Antoine Le Gonidec wrote:
> Package: ncurses-base
> Version: 6.3+20221224-2
> Severity: important

that's probably this - which will be in today's update/release:

--- ncurses-6.3-20221224+/misc/terminfo.src 2022-12-24 18:18:58.0 
+
+++ ncurses-6.4-20221231/misc/terminfo.src  2022-12-29 20:11:56.0 
+
@@ -6,8 +6,8 @@
 # Report bugs and new terminal descriptions to
 #  bug-ncur...@gnu.org
 #
-#  $Revision: 1.1039 $
-#  $Date: 2022/12/24 18:18:58 $
+#  $Revision: 1.1041 $
+#  $Date: 2022/12/29 20:11:56 $
 #
 # The original header is preserved below for reference.  It is noted that there
 # is a "newer" version which differs in some cosmetic details (but actually
@@ -5768,7 +5768,7 @@
 # detail.  The names for the extended capabilities here were introduced by vim
 # in January 2017.
 bracketed+paste|xterm bracketed paste,
-   BD=\E[?2004l, BE=\E[?2004h, PD=\E[201~, PE=\E[200~,
+   BD=\E[?2004l, BE=\E[?2004h, PE=\E[201~, PS=\E[200~,
 
  XTERM Mouse
 # The xterm mouse protocol is used by other terminal emulators.
@@ -8210,7 +8210,7 @@
use=screen4,
 
 no+brackets|cancel bracketed paste,
-   BD@, BE@, PD@, PE@,
+   BD@, BE@, PE@, PS@,
 
 # The bce and status-line entries are from screen 3.9.13 (and require some
 # changes to .screenrc).
@@ -25508,8 +25508,8 @@
 #
 # BE enables bracketed paste
 # BD disables bracketed paste
-# PE is sent before the pasted text
-# PD is sent after the pasted text
+# PS is sent before the pasted text
+# PE is sent after the pasted text
 #
 # Here are the other xterm-related extensions which are used in this file:
 #
@@ -27713,4 +27713,8 @@
 #  + add/use bracketed+paste to help identify terminals supporting this
 #xterm feature (prompted by discussion with Bram Moolenaar) -TD
 #
+# 2022-12-29
+#  + correct PS vs PE names in bracketed+paste (report by Bram Moolenaar)
+#-TD
+#
  SHANTIH!  SHANTIH!  SHANTIH!

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1027359: [Pkg-electronics-devel] Bug#1027359: arduino-builder: FTBFS in bullseye (missing build-depends on tzdata)

[Rock Storm]

On Fri, 2022-12-30 at 19:00 +0100, Santiago Vila wrote:
> Note: I'm using the "patch" tag because there is an obvious fix
> (indicated in the subject).
> 
> [...]
> 
> If this is really a bug in one of the build-depends, please use
> reassign and affects, so that this is still visible in the BTS web
> page for this package.
> 

This is interesting because that test didn't fail before and we didn't
need the tzdata package installed. Which makes me think something has
changed in the archive that wasn't there before. I know the fix seems
simple but I wonder if there is something else going on. Something out
of the scope of arduino-builder?


Regards,

-- 
⢀⣤⣀⣼⣧⣀⣤⡀  Rock Storm
⣀⣿⣿⠟⠻⣿⣿⣀  Open Source Advocate
⠛⣿⣿⡄⢠⣿⣿⠛  https://github.com/rockstorm101
⠰⡿⠿⠁⠈⠿⢿⠆  C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD

Bug#1018029: idesk: FTBFS with imlib2 1.9.1

[Andreas Metzler]

On 2022-08-24 Markus Koschany  wrote:
> Package: idesk
> Version: 0.7.5-6
> Severity: important
> Tags: ftbfs sid bookwork
> User: a...@debian.org
> Usertags: imlib2-1.9.1
> X-Debbugs-Cc: a...@debian.org

> Dear maintainer,

> your package fails to build from source with imlib2 1.9.1 in
> experimental. imlib2-config has been dropped by upstream in favor of
> pkg-config. Please adjust your build system accordingly. I intend to
> upload imlib2 1.9.1 to unstable in one or two months. Feel free to
> reply to this bug report if you have any questions.

I will take look.
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

[Antoine Le Gonidec]

Package: ncurses-base
Version: 6.3+20221224-2
Severity: important

Since the 6.3+20221224-2 update, vim pasting behaviour is broken when
TERM is set to "tmux" or "tmux-256color".

To reproduce it, open vim, type a few word, then try to copy/paste them
using selection then middle mouse clic, or Ctrl + Shift + C then Ctrl +
Shift + V. The pasting then has a strange behaviour, it looks like vim
automatically goes back to edition mode (instead of insertion mode) at
the beginning of the paste process, then treat the following characters
as commands (so it will go back to insertion mode at the first "i", "a"
or "s").

This issue does not happen outside of tmux, or if TERM is set to "xterm"
instead of "tmux". Reverting to ncurses-base 6.3+20220423-2 is another
way to work around this unexpected behaviour.

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

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

-- no debconf information

Bug#1025056: transition: numerical library transition: hypre / petsc / slepc / sundials

[Sebastian Ramacher]

Hi Anton

On 2022-12-28 09:30:00 +0100, Anton Gladky wrote:
> Hi Sebastian,
> 
> sundials is already in NEW, fixing two RC bugs.
> Dyssol will be uploaded shortly.

It's now in unstable. Please also fix #1027402.

Cheers

> 
> Regards
> 
> Anton
> 
> Am Di., 27. Dez. 2022 um 12:23 Uhr schrieb Sebastian Ramacher
> :
> >
> > Hi Drew, hi Anton
> >
> > On 2022-12-19 21:52:10 +0100, Sebastian Ramacher wrote:
> > > Hi Drew
> > >
> > > On 2022-12-19 18:14:53 +0100, Drew Parsons wrote:
> > > > The hypre/petsc part of this transition is complete.
> > > >
> > > > The sundials part is waiting for dyssol to be patched.  Anton is 
> > > > preparing
> > > > this.
> > >
> > > sundials will also need fixes for #1026330 and #1026352.
> >
> > Any news regarding sundials?
> >
> > Cheers
> >
> > >
> > > Cheers
> > >
> > > >
> > > > Drew
> > > >
> > > >
> > > > On 2022-11-29 23:34, Sebastian Ramacher wrote:
> > > > > Control: tags -1 confirmed
> > > > >
> > > > > Hi Drew
> > > > >
> > > > > On 2022-11-29 12:16:55 +0100, Drew Parsons wrote:
> > > > > > Package: release.debian.org
> > > > > > Severity: normal
> > > > > > User: release.debian@packages.debian.org
> > > > > > Usertags: transition
> > > > > > X-Debbugs-Cc: Anton Gladky 
> > > > > >
> > > > > > We'd like to update the numerical library stack in time for the new
> > > > > > stable release.
> > > > > >
> > > > > > Affected libraries are
> > > > > >
> > > > > > hypre2.25.0 -> 2.26.0
> > > > > > petsc/slepc3.17 -> 3.18
> > > > > > sundials  5.8.0 -> 6.4.1
> > > > > >
> > > > > > Autotransitions are already generated:
> > > > > > https://release.debian.org/transitions/html/auto-hypre.html
> > > > > > https://release.debian.org/transitions/html/auto-petsc.html
> > > > > > https://release.debian.org/transitions/html/auto-slepc.html
> > > > > > https://release.debian.org/transitions/html/auto-sundials.html
> > > > > >
> > > > > > Most of the dependent packages are under our control
> > > > > > (Debian Science Team), octave is the main one outside our team.
> > > > > >
> > > > > > Updates have built fine in experimental and dependent
> > > > > > packages are building successfully against them.
> > > > > >
> > > > > > Anton Gladky will upload the sundials update.
> > > > >
> > > > > Please go ahead
> > > > >
> > > > > Cheers
> > > >
> > >
> > > --
> > > Sebastian Ramacher
> > >
> >
> > --
> > Sebastian Ramacher
> 

-- 
Sebastian Ramacher

Bug#1027434: RFS: posixsignalmanager/0.3-1 [ITP] -- posix signal handling for qt - headers

[Christoph Hueffelmann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : posixsignalmanager
   Version  : 0.3-1
   Upstream contact : Martin Hostettler 
 * URL  : https://github.com/textshell/posixsignalmanager
 * License  : BSL-1.0
 * Vcs  : https://salsa.debian.org/chr/posixsignalmanager.git
   Section  : libs

The source builds the following binary packages:

  libposixsignalmanager0a - posix signal handling for qt - shared library
  libposixsignalmanager-dev - posix signal handling for qt - headers

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/posixsignalmanager/posixsignalmanager_0.3-1.dsc


Changes for the initial release:

 posixsignalmanager (0.3-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1027294)


I am packageing this as dependency of TuiWidgets #1027293.

Regards,
--
  Christoph Hueffelmann

Bug#1006179: [Pkg-clamav-devel] Bug#1006179: ClamAV 1.0.0 release candidate now available

[Sebastian Andrzej Siewior]

On 2022-12-31 01:09:46 [-0500], Scott Kitterman wrote:
> I looked at it some and the testfiles appear to be gone.  Let's drop the 
> binary 
> and move on.

I references them from the build-directory. So we have some of them. I
don't know if new files are there (in the build directory) but the .rar
files are gone for now.

> I pushed some changes to the experimental branch to help it build using dpkg-
> buildpackage:
> 
>  - added build-depends
>  - added my rust compilation requirements patch that I had emailed you (it's 
> not applied, just in d/patches and listed in d/patches/series)
>  - added the target directory for the unit files in configure in d/rules
> 
> With those changes, it gets through to install, where it failes for multiple 
> reasons:
> 
> 1.  There's a typo in the libclamav11.install file (fixed in git).
> 2.  Missing testfiles (I say nuke the binary and move on, but I didn't do it).
> 3.  Missing html docs.  This just needs the proper doxygen invocation (but 
> it's late and I'm tired here, so I didn't make and changes for this).  I did 
> manually build the docs and once those were present it got all the way to 
> symbols files.

The symbol files are a huge mess now due to the c++/rust symbols that we
got now. I guess that those should be not exported as part of the lib.
The docs are missing. The manual invocation brings something but it is
not the "documentation" but the clamav.h annotation. Which is not
helpfull I guess…

> Back over to you.  I'm going to bed.  Good luck.

I uploaded it to experimental. Need to shower, vacuum clean, have ppl
over later…

> Scott K

Sebastian

Bug#1027429: mmdebstrap: unshare backend not working

[Johannes Schauer Marin Rodrigues]

Hi Andrea,

Quoting Andrea Pappacoda (2022-12-31 12:54:35)
> Hi, for some reason I'm unable to get the unshare backend working on one of
> my machines.
> 
> When I try to create an unstable-amd64 tarball to use with sbuild I get this
> strange error:
> 
> mmdebstrap --variant=apt --include=build-essential unstable unstable-
> amd64.tar
> I: automatically chosen mode: unshare
> I: chroot architecture amd64 is equal to the host's architecture
> I: automatically chosen format: tar
> I: using /tmp/mmdebstrap.panqVhWsFm as tempdir
> W: /etc/subuid is empty
> E: invalid idmap

Do you have a valid /etc/subuid? Mine says (josch is my username):

josch:10:65536

How could the error message be improved?

> If I force the creation of the above tarball with root mode

A tarball created in root mode will be bit-by-bit identical to one created in
unshare mode (if SOURCE_DATE_EPOCH was set to the same value).

> and I then try to
> use it in sbuild, I get this even bigger error:
> 
> Package: yuzu
> Version: 0-1284+ds-1
> Source Version: 0-1284+ds-1
> Distribution: unstable
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: binary
> 
> Use of uninitialized value $nsid in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 401.
> Use of uninitialized value $range in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 401.
> Use of uninitialized value $nsid in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 404.
> Use of uninitialized value $range in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 404.
> Use of uninitialized value $nsid in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 401.
> Use of uninitialized value $nsid in concatenation (.) or string at
> /usr/share/perl5/Sbuild/Utility.pm line 404.
> ranges: 2 argc: 5
> newuidmap: Not enough arguments to form 2 mappings
> usage: newuidmap [   
> ] ...
> newuidmap failed:  at -e line 1.
> child had a non-zero exit status: 256 at -e line 1.
> bad exit status (29): perl -e require 'syscall.ph';pipe my $rfh, my 
> $wfh;my
> $ppid = $$;my $cpid = fork() // die "fork() failed: $!";if ($cpid == 0) {close
> $wfh;0 == sysread $rfh, my $c, 1 or die "read() did not receive EOF";0 ==
> system "newuidmap $ppid  0 60092 1 1  1" or die "newuidmap failed: $!";0 ==
> system "newgidmap $ppid  0 60092 1 1  1" or die "newgidmap failed: $!";exit
> 0;}0 == syscall _unshare, 268435456 or die "unshare() failed: $!";close
> $wfh;$cpid == waitpid $cpid, 0 or die "waitpid() failed: $!";if ($? != 0) {die
> "child had a non-zero exit status: $?";}0 == syscall _setgid, 0 or die
> "setgid failed: $!";0 == syscall _setuid, 0 or die "setuid failed: $!";0 
> ==
> syscall _setgroups, 0, 0 or die "setgroups failed: $!";exec { $ARGV[0] }
> @ARGV or die "exec() failed: $!"; chown 1:1 /tmp/tmp.sbuild.LKlB9A2jh_
> E: Error creating chroot session: skipping yuzu
> 
> I've installed this system fairly recently (after the bullseye release), and I
> don't have messed with it that much. One thing that comes to my mind that 
> could
> be messing with UIDs and GIDs is that I'm using systemd-homed to manage my 
> user
> and home directory.
> 
> Under systemd-homed, users aren't saved to /etc/passwd, but are retrievable
> with glibc's NSS API, i.e. with getent(1) and the various getpwuid(3) C
> functions. For instance,
> 
> $ diff /etc/passwd <(getent passwd)
> 42a43
> > tachi:x:60092:60092:Andrea Pappacoda:/home/tachi:/usr/bin/zsh
> 
> How could I debug and/or solve this issue? I'm a bit lost.

The error message in sbuild could certainly be improved. Could you try out the
following patch:

diff --git a/lib/Sbuild/ChrootUnshare.pm b/lib/Sbuild/ChrootUnshare.pm
index 9734293a..d48de32d 100644
--- a/lib/Sbuild/ChrootUnshare.pm
+++ b/lib/Sbuild/ChrootUnshare.pm
@@ -105,9 +105,16 @@ sub begin_session {
 my @idmap = read_subuid_subgid;
 
 # sanity check
-if (scalar(@idmap) != 2 || $idmap[0][0] ne 'u' || $idmap[1][0] ne 'g') {
-   printf STDERR "invalid idmap\n";
-   return 0;
+if (   scalar(@idmap) != 2
+|| $idmap[0][0] ne 'u'
+|| $idmap[1][0] ne 'g'
+|| length $idmap[0][1] == 0
+|| length $idmap[0][2] == 0
+|| length $idmap[1][1] == 0
+|| length $idmap[1][2] == 0)
+{
+printf STDERR "invalid idmap\n";
+return 0;
 }
 
 $self->set('Uid Gid Map', \@idmap);
diff --git a/lib/Sbuild/Utility.pm b/lib/Sbuild/Utility.pm
index 7405055e..5a59b28a 100644
--- a/lib/Sbuild/Utility.pm
+++ b/lib/Sbuild/Utility.pm
@@ -546,34 +546,28 @@ sub read_subuid_subgid() {
last if ($n eq $username);
 }
 close $fh;
+
+if ($n ne $username) {
+   printf STDERR "No entry for $username in /etc/subuid";
+   return;
+}
+
 push 

Bug#501456: dpkg: parallel compression and decompression

[Sebastian Andrzej Siewior]

On 2020-04-09 19:43:34 [+0800], Paul Wise wrote:
> On Thu, 9 Apr 2020 11:45:49 +0200 Sebastian Andrzej Siewior wrote:
> 
> > Can this be closed?
> 
> Since the patch and feature hasn't been merged, I don't think so.

What about now given that #956452 has been closed?

Sebastian

Bug#1006179: [Pkg-clamav-devel] Bug#1006179: ClamAV 1.0.0 release candidate now available

[Scott Kitterman]

On December 31, 2022 10:00:13 AM UTC, Sebastian Andrzej Siewior 
 wrote:
>On 2022-12-31 01:09:46 [-0500], Scott Kitterman wrote:
>> I discovered that the experimental (and upstream-experimental) branches 
>> still 
>> have the crates that are now excluded when the tarball is created.  I made a 
>> new branch called upstream-experimental-fixup and pushed it.  You ought to 
>> be 
>> able to merge that to upstream-experimental and then merge that to 
>> experimental and get an unpacked directory that dpkg-buildpackage things 
>> goes 
>> with the tarball.  We (I volunteer) will also need to fixup the pristine-tar 
>> branch, but that can be later.
>
>I recreated these things while recreating the tar file. I parse the
>remaining parts of the email while moving forward. This just a diff
>between the new upstream-exp branch and your's:
>
>| $ git diff salsa/upstream-experimental-fixup -w --stat
>|  .gitattributes |  16 +
>|  .github/ISSUE_TEMPLATE/bug_report.md   |  41 
>++
>|  .github/ISSUE_TEMPLATE/config.yml  |   5 +++
>|  .github/workflows/clang-format.yml |  65 
>++
>|  .github/workflows/cmake.yml| 185 
>+
>|  .github/workflows/codeql.yml   |  86 
>+
>|  .github/workflows/docker-db-update.yml |  17 +
>|  .gitignore | 236 
>
>|  libclamav_rust/.cargo/vendor/libloading/tests/nagisa32.dll | Bin 3072 -> 0 
>bytes
>|  libclamav_rust/.cargo/vendor/libloading/tests/nagisa64.dll | Bin 2560 -> 0 
>bytes
>|  10 files changed, 651 insertions(+)
>
>The additional .git* files should be okay and the copyright file dropped
>two dlls. Good. I don't know *why* but the cargo files have a larger
>CR/LF vs LF so that is why the `-w' option is there.
>
>Other than that, I need to teach mk-origtargz to compress xz with -T
>(multiple blocks) now that xz-utils supports threaded decompression.
>dpkg-deb (during installation) can handle it already and the dpkg-source
>bits are on its way ;)
>
>Sebastian

Great.  I'm looking at this on my phone, so the diff is hard to parse.  I may 
have made a mistake somewhere. 

libclamav_rust/.cargo/vendor/libloading/tests/nagisa* have prebuilt Windows 
artifacts in them and need to not be in the tarball.

Scott K

Bug#1027433: Change upstream away from Aegisub/Aegisub

[Oneric]

Source: aegisub
Version: 3.2.2+dfsg-7
Severity: wishlist

Hi!

As you know, upstream Aegisub/Aegisub has been inactive for years now
except for one batch of fixes being merged in 2019 (and iirc even breaking
the build for then-newest-stable wxWidgets 3.0 in the process).
Imho it would be a god idea to switch this package’s upstream
to a maintained Aegisub fork. I noticed you already considered this
in 2019: https://github.com/wangqr/Aegisub/issues/13.

As mentioned in the above GH issue, TypesettingTools/Aegisub was/is
supposed to take over Aegisub/Aegisub eventually, but now even
TypesettingTools/Aegisub has been inactive for half a year and doesn't
build anymore with newest meson (see its #162).

Actually maintained forks currently are
wangqr/Aegisub and arch1t3cht/Aegisub.

The former is one of the oldest forks of Aegisub/Aegisub and was already
considered as a new upstream in 2019 and is now also used as the upstream
for Void Linux’ and Arch’s aegisub packages. Maintenance is currently
mostly focused on fixing bugs and commits occur every couple of months
and ime bug reports tend to get a response within a few weeks.
Releases continue Aegisub/Aegisub’s numbering.
One can choose to build with CMake or a continuation of Aegisub/Aegisub’s
custom Makefiles and autoconf configuration.

The latter is rather new and based on TypesettingTools/Aegisub.
It also backported some fixes and changes from wangqr/Aegisub and focuses
on new features and improvements for advanced usecases. It explicitly
mentions *not* being concerned with stability and itself writes
  „Don't use this version if you're just looking for
   any version of Aegisub“.
It is quite active and issues are ime responded to within days.
Releases are tagged as "feature_xx" starting with 01 and do not use
Aegisub/Aegisub’s version numbering scheme.
It is built with meson.

Both intend to merge back their changes to Aegisub/Aegisub
when/if it becomes active again.

Personally, I have been using personal wangqr/Aegisub builds for years
now, since Aegisub/Aegisub is basically unusable for my setup. But I might
either switch to or backported some changes from arch1t3cht in the future,
though as a package upstream arch1t3cht/Aegisub might be too fast moving.
Of course ideally TypesettingTools/Aegisub would reactivate and finally
take over Aegisub/Aegisub, allowing others to upstream their changes,
but I’m afraid this won’t happen anytime soon.

Cheers
Oneric


signature.asc
Description: PGP signature

Bug#1027432: nvme-cli: systemd service & target files wronly placed

[Peter Marschall]

Package: nvme-cli
Version: 2.2.1-2
Severity: important

Hi,

in addition to the wrong placement of udev rules files (already reported in
#1026054), nvme-cli also seems to place the systemd service & target files
into the wrong directory.

Affected files are:
* nvmefc-boot-connections.service
* nvmf-autoconnect.service
* nvmf-connect@.service
* nvmf-connect.target

It places them into ´/lib/systemd/´ instead of the correct directory for
system-wide systemd files: ´/lib/systemd/system/'.

Thanks for maintaining nvme-cli in Debian
Peter


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

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

Versions of packages nvme-cli depends on:
ii  libc6 2.36-7
ii  libjson-c50.16-2
ii  libnvme1  1.2-2
ii  uuid-runtime  2.38.1-4
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages nvme-cli recommends:
ii  pci.ids  0.0~2022.12.19-1

nvme-cli suggests no packages.

-- no debconf information

Bug#1027431: RFP: vim-nim -- Nim language support for Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-nim
  Version : 1.1.2+git2021.a15714f (or persuade upstream to
   tag releases more often...)
  Upstream Contact: Zahary Karadjov 
* URL : https://github.com/zah/nim.vim
* License : Expat (MIT)
  Programming Lang: Vim (+ Python)
  Description : Nim language support for Vim

nim.vim provides:
 * Syntax highlighting
 * Auto-indent
 * Build/jump to errors within Vim
 * Project navigation and Jump to Definition (cgats or
   compiler-assisted idetools)
for the Nim programming language.



I think this package may be useful, since there is currently
no Vim support for the Nim language in Debian, see bug [#1027002],
not even for syntax highlighting.

[#1027002]: 

I hope someone is willing to package this addon soon.
Thanks to anyone volunteering to do so and maintain it in Debian!

Bug#1027289: transition: libcamera

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Dylan

On 2022-12-29 23:01:28 +0100, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for libcamera.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-libcamera.html
> 
> The unique reverse dep (pipewire 0.3.63-1) builds fine with the
> new libcamera in experimental.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1027430: linux-image-5.10.0-20-amd64: No sound on Lenovo IdeaPad 3

[Martin Furlanič]

Package: src:linux
Version: 5.10.158-2
Severity: normal
X-Debbugs-Cc: martin.furla...@gmail.com



-- Package-specific info:
** Version:
Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.158-2 (2022-12-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 
root=UUID=87df20a8-1d34-4d1a-a72f-a638f3903070 ro quiet

** Not tainted

** Kernel log:
[5.440482] audit: type=1400 audit(1672488471.944:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=497 
comm="apparmor_parser"
[5.445266] audit: type=1400 audit(1672488471.948:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/akonadiserver" 
pid=498 comm="apparmor_parser"
[5.451349] audit: type=1400 audit(1672488471.956:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=505 
comm="apparmor_parser"
[5.452211] audit: type=1400 audit(1672488471.956:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine" pid=500 comm="apparmor_parser"
[5.452213] audit: type=1400 audit(1672488471.956:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=500 
comm="apparmor_parser"
[5.454140] audit: type=1400 audit(1672488471.956:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=503 
comm="apparmor_parser"
[5.454755] audit: type=1400 audit(1672488471.960:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="postgresql_akonadi" pid=504 
comm="apparmor_parser"
[5.457653] audit: type=1400 audit(1672488471.960:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/libexec/ibus-engine-hangul" pid=508 comm="apparmor_parser"
[5.465292] audit: type=1400 audit(1672488471.968:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libvirtd" pid=509 
comm="apparmor_parser"
[5.479178] rtw_8822ce :01:00.0: enabling device ( -> 0003)
[5.482956] rtw_8822ce :01:00.0: firmware: direct-loading firmware 
rtw88/rtw8822c_wow_fw.bin
[5.482961] rtw_8822ce :01:00.0: Firmware version 9.9.4, H2C version 15
[5.484112] rtw_8822ce :01:00.0: firmware: direct-loading firmware 
rtw88/rtw8822c_fw.bin
[5.484120] rtw_8822ce :01:00.0: Firmware version 9.9.6, H2C version 15
[5.657215] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[5.657234] sof-audio-pci :00:1f.3: Digital mics found on Skylake+ 
platform, using SOF driver
[5.657249] sof-audio-pci :00:1f.3: enabling device ( -> 0002)
[5.657475] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040100
[5.657577] sof-audio-pci :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.665146] sof-audio-pci :00:1f.3: use msi interrupt mode
[5.708490] intel_rapl_msr: PL4 support detected.
[5.708519] intel_rapl_common: Found RAPL domain package
[5.708521] intel_rapl_common: Found RAPL domain core
[5.708522] intel_rapl_common: Found RAPL domain uncore
[5.783997] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[5.789421] rtw_8822ce :01:00.0 wlp1s0: renamed from wlan0
[5.789808] Bluetooth: Core ver 2.22
[5.789896] NET: Registered protocol family 31
[5.789896] Bluetooth: HCI device and connection manager initialized
[5.789900] Bluetooth: HCI socket layer initialized
[5.789901] Bluetooth: L2CAP socket layer initialized
[5.789904] Bluetooth: SCO socket layer initialized
[5.809119] usbcore: registered new interface driver btusb
[5.810049] sof-audio-pci :00:1f.3: hda codecs found, mask 5
[5.810051] sof-audio-pci :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[5.810056] sof-audio-pci :00:1f.3: DMICs detected in NHLT tables: 2
[5.812606] sof-audio-pci :00:1f.3: firmware: direct-loading firmware 
intel/sof/sof-tgl.ri
[5.812614] sof-audio-pci :00:1f.3: warning: unknown sof_ext_man header 
type 6 size 0x20
[5.812615] sof-audio-pci :00:1f.3: Firmware info: version 1:7:0-47d07
[5.812616] sof-audio-pci :00:1f.3: Firmware: ABI 3:18:1 Kernel ABI 
3:17:0
[5.812617] sof-audio-pci :00:1f.3: warn: FW ABI is more recent than 
kernel
[5.812621] sof-audio-pci :00:1f.3: warning: unknown sof_ext_man header 
type 3 size 0x30
[5.812622] sof-audio-pci :00:1f.3: warning: unknown sof_ext_man header 
type 5 size 0x20
[5.816606] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=099a 
lmp_ver=0a lmp_subver=7253
[5.816609] Bluetooth: hci0: RTL: unknown IC info, lmp subver 7253, hci rev 
099a, hci 

Bug#1026114: RFS: ruby-mdl/0.12.0-1 [ITP] -- Markdown lint tool

[Norwid Behrnd]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ruby-mdl":

 * Package name : ruby-mdl
   Version  : 0.12.0-1
   Upstream contact : ["p...@ipom.com"]
 * URL  : https://github.com/markdownlint/markdownlint
 * License  : MIT
 * Vcs  : https://salsa.debian.org/nbehrnd/ruby-mdl
   Section  : ruby

The source builds the following binary packages:

  ruby-mdl - Markdown lint tool

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

  https://mentors.debian.net/package/ruby-mdl/

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-1.dsc

Changes for the initial release:

 ruby-mdl (0.12.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1026114)

Regards,
-- 
  Norwid Behrnd

Bug#1027283: transition: tiff

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi László

On 2022-12-29 18:19:58 +0100, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> Unplanned transition of tiff as its new release is just recently out.
> The API seems to be the same, but the ABI is changed. Basic reason is
> that its behaviour is changed and returns quicker from processing
> invalid images.
> While it's a big transition, nine levels deep, test rebuilds show in
> the first five levels only two package self-testing breaks. I've
> already patched one of them. Currently it only hard breaks hylafax
> which seems to be a dead project since 2012; a memory corruption and a
> security fix was committed to it, but even those happened in 2018 or
> earlier. Anyway, I've notified tiff upstream and will act accordingly.
> 
> As tiff is used commonly and has security issues from time to time it
> would be good to have its latest release in Debian. I don't know if
> the old version will get any fixes or not.

Understood. Please let us know once you're done with the test rebuilds
and have filed all bugs.

Cheers
-- 
Sebastian Ramacher

Bug#1027429: mmdebstrap: unshare backend not working

[Andrea Pappacoda]

Package: mmdebstrap
Version: 1.2.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, for some reason I'm unable to get the unshare backend working on one of my
machines.

When I try to create an unstable-amd64 tarball to use with sbuild I get this
strange error:

mmdebstrap --variant=apt --include=build-essential unstable unstable-
amd64.tar
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.panqVhWsFm as tempdir
W: /etc/subuid is empty
E: invalid idmap

If I force the creation of the above tarball with root mode and I then try to
use it in sbuild, I get this even bigger error:

Package: yuzu
Version: 0-1284+ds-1
Source Version: 0-1284+ds-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
ranges: 2 argc: 5
newuidmap: Not enough arguments to form 2 mappings
usage: newuidmap [   
] ...
newuidmap failed:  at -e line 1.
child had a non-zero exit status: 256 at -e line 1.
bad exit status (29): perl -e require 'syscall.ph';pipe my $rfh, my $wfh;my
$ppid = $$;my $cpid = fork() // die "fork() failed: $!";if ($cpid == 0) {close
$wfh;0 == sysread $rfh, my $c, 1 or die "read() did not receive EOF";0 ==
system "newuidmap $ppid  0 60092 1 1  1" or die "newuidmap failed: $!";0 ==
system "newgidmap $ppid  0 60092 1 1  1" or die "newgidmap failed: $!";exit
0;}0 == syscall _unshare, 268435456 or die "unshare() failed: $!";close
$wfh;$cpid == waitpid $cpid, 0 or die "waitpid() failed: $!";if ($? != 0) {die
"child had a non-zero exit status: $?";}0 == syscall _setgid, 0 or die
"setgid failed: $!";0 == syscall _setuid, 0 or die "setuid failed: $!";0 ==
syscall _setgroups, 0, 0 or die "setgroups failed: $!";exec { $ARGV[0] }
@ARGV or die "exec() failed: $!"; chown 1:1 /tmp/tmp.sbuild.LKlB9A2jh_
E: Error creating chroot session: skipping yuzu

I've installed this system fairly recently (after the bullseye release), and I
don't have messed with it that much. One thing that comes to my mind that could
be messing with UIDs and GIDs is that I'm using systemd-homed to manage my user
and home directory.

Under systemd-homed, users aren't saved to /etc/passwd, but are retrievable
with glibc's NSS API, i.e. with getent(1) and the various getpwuid(3) C
functions. For instance,

$ diff /etc/passwd <(getent passwd)
42a43
> tachi:x:60092:60092:Andrea Pappacoda:/home/tachi:/usr/bin/zsh

How could I debug and/or solve this issue? I'm a bit lost.

Thank you for your awesome work on mmdebstrap :)


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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.5.4
ii  perl 5.36.0-6
ii  python3  3.10.6-3+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.19-1
ii  fakechroot   2.20.1+ds-8
ii  fakeroot 1.29-1
ii  gpg  2.2.40-1
ii  libdistro-info-perl  1.2
ii  libdpkg-perl 1.21.13
ii  mount2.38.1-4
ii  uidmap   1:4.13+dfsg1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.5.4
pn  apt-transport-tor  
ii  apt-utils  2.5.4
pn  binfmt-support 
ii  ca-certificates20211016
ii  debootstrap1.0.128+nmu2
ii  distro-info-data   0.56
ii  dpkg-dev   1.21.13
pn  genext2fs  
pn  perl-doc   
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY7Ai9BQcYW5kcmVhQHBh

Bug#1027424: transition: libppd

[Sebastian Ramacher]

On 2022-12-31 10:29:48 +0100, Paul Gevers wrote:
> Control: tag -1 moreinfo
> 
> Hi Christoph,
> 
> On 31-12-2022 10:06, Christoph Biedl wrote:
> > possible this is not a regular transition, but in exchange I guess it
> > should be pretty smooth and simple ...
> 
> Inside the Debian archive maybe, but ...
> 
> > So src:libppd has been renamed to src:libppd-legacy, and has entered
> > experimental yesterday. While doing so, I've fixed a longstanding
> > mismatch in the soname version, hence the new number libppd-legacy*1*.

We have libppd0 with an incorrect SONAME already in oldoldstable
(maybe also oldoldoldstable). We are not doing transition for such
cases. That's gonna stick until we can properly remove libppd.so.1
from the archive.

> I'm wondering what this means for users of the library that don't have
> packages in the Debian archive. If some downstream (including the non
> publicly published ones) (build) depend on the old library, they suddenly
> get weird failures, right?

That's why we are not doing those kind of transitions.

Technically, the new libppd can start using libppd.so.2, but this sounds
less than optimal. Can't the new one be named something else if it's not
a successor to the old libppd?

Cheers
-- 
Sebastian Ramacher

Bug#1026856: [3dprinter-general] Bug#1026856: cura-engine: FTBFS: 14 tests segfault

[Christoph Berg]

Re: Gregor Riepl
> It will be fixed in libarcus 5.0.0-2, which is waiting for release:
> https://salsa.debian.org/3dprinting-team/libarcus/-/commit/c2dfe6eacb2213195619b50f1d1efc7cd519c8f8
> 
> @myon: Can you take care of pushing this version, please?

Hi Gregor,

I just uploaded that version.

I also gave updating to 5.2.2 a try, but the whole buildsystem has
changed and it seems to require a whole new set of patches. Alpine has
this:

https://git.alpinelinux.org/aports/tree/community/libarcus

which seems like a good starting point, but it's likely not doing the
right thing wrt to Debian's Pythons versions handling.

If someone with more clue than me about sip (is that still needed?),
cmake, and pybuild could pick that up, that would be nice.

Christoph