Bug#958895: libevhtp-dev: libtool arguments failure

[Vincent Bernat]

On 2023-01-27 08:48, Alexandre Rossi wrote:


Now that the blocking bug is fixed, I thing the patch should be uploaded to 
unstable.
Do you want me to prepare a build for you to upload?


Yes, please do.


An updated package is available on mentors.
https://mentors.debian.net/package/libevhtp/


Thanks, it's uploaded!

Bug#1029076: closed by Jonas Smedegaard (reply to 1029...@bugs.debian.org) (Re: Bug#1029076: uwsgi-plugin-python3: built against non-default libpython3.11 / should always build agains

[Alexandre Rossi]

Hi,

> > Sorry, but I fail to see any problem here.
> >
> > uwsgi _does_ build against the default Python.
> 
> Yes, but the default Python it builds against in unstable is not necessarily 
> the default Python in testing.
> 
> Right now, it is built against Python 3.11, while the default Python in 
> testing is 3.10. Hence, it does not work in testing (have you actually tried 
> that after my bug report?).

What should be the correct fix for this? I see only :
- hardcode the python version uwsgi builds against and follow testing

Are their facilities providing the default python version that is in testing 
and available
in sid? Or is this discrepancy between the default python in testing and in sid 
an rare event
that we should workaround this time only?

Thanks,

Alex

Bug#958895: libevhtp-dev: libtool arguments failure

[Alexandre Rossi]

Hi,

> > Now that the blocking bug is fixed, I thing the patch should be uploaded to 
> > unstable.
> > Do you want me to prepare a build for you to upload?
> 
> Yes, please do.

An updated package is available on mentors.
https://mentors.debian.net/package/libevhtp/

My commits are published at:
https://sml.zincube.net/~niol/repositories.git/libevhtp/

Thanks,

Alex

Bug#1027851: pytorch FTBFS with Python 3.11 as default version

[Andreas Tille]

Hi Aron,

Am Fri, Jan 27, 2023 at 02:09:05AM +0800 schrieb Aron Xu:
> 
> The packaging work of 1.13.1[1] has started on salsa. We still have a
> failure related to fmtlib before making the package build successfully
> [5/1781]. Both Mo and I have limited bandwidth here and help is always
> appreciated.

I've just checked the changelog and noticed:

   Bump SOVERSION to 1.13

but we are in transition freeze.  So this needs to be coordinated with
release team.  I guess if we argue that 1.13 will support Python3.11
this could be some argument after the decision that this should be the
supported Python3 version for the next release.

Kind regards
Andreas.
 
> [1]https://salsa.debian.org/deeplearning-team/pytorch

-- 
http://fam-tille.de

Bug#1029755: "sh: 1: xed: not found" when listing samples with assembler

[Philipp Marek]

Package: linux-perf
Version: 6.1.7-1
Severity: minor
File: /usr/bin/perf
X-Debbugs-Cc: phil...@marek.priv.at

I've written a trace with "perf record"; when viewing via "perf report"
it I zoom into a function and choose
Show individual samples with assembler

But that gives me just an error message:

sh: 1: xed: not found
(END)

Sadly https://packages.debian.org/search?searchon=contents=xed
doesn't show any package with a binary of that name...



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

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-perf depends on:
ii  libbabeltrace1  1.5.11-1+b1
ii  libc6   2.36-8
ii  libcap2 1:2.66-3
ii  libdw1  0.188-2.1
ii  libelf1 0.188-2.1
ii  liblzma55.4.1-0.0
ii  libnuma12.0.16-1
ii  libopencsd1 1.3.3-1
ii  libperl5.36 5.36.0-7
ii  libpython3.11   3.11.1-2
ii  libslang2   2.3.3-2
ii  libunwind8  1.6.2-3
ii  libzstd11.5.2+dfsg2-3
ii  perl5.36.0-7
ii  python3 3.10.6-3+b1
ii  zlib1g  1:1.2.13.dfsg-1

linux-perf recommends no packages.

Versions of packages linux-perf suggests:
pn  linux-doc-6.1  

-- no debconf information

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-17
Followup-For: Bug #1029681
X-Debbugs-Cc: pitsior...@outlook.com

Goodmorning. Before I start, I would like to say that yesterday I completely
missed message #27 above and that I am really sorry for that useless wall of
text that reportbug adds to whatever I post.

So, I tested -16 and dkms simply fails to build the modules for 6.1 with it. I
have attached the make.log in case someone wants to have a look. This means
that the -17 version is mandatory for 6.1.
I respect the effort that you put in keeping this package in the repo, but
allow me to say that there is a big difference between something that compiles
successfully with a patch and something that works on all conditions. And right
now, it does not work for qt5 and kodi. And there is no workaround for kodi!
How about adding that 0042 patch to nvidia 340?

As for the debug packages for kodi and libc6, I can not find the packages you
suggested. The closest ones I can find are libc6-dbg and kodi-bin-dbgsym.
Kodi's only shows up in packages.debian.org and not in apt's search. Likewise,
I can not find any debug packages for qt5. Also, the LIBGL_DEBUG=verbose
parameter that woud supposedly give more info on gl stuff does not seem to do
anything on my end.


-- Package-specific info:
uname -a:
Linux mitsos 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 12.2.0 (Debian 12.2.0-13) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C [GeForce 9500 
GT] [10de:0640] (rev a1) (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. G96C [GeForce 9500 GT] [1682:2412]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.187186] Console: colour VGA+ 80x25
[0.418756] pci :01:00.0: vgaarb: setting as boot VGA device
[0.418756] pci :01:00.0: vgaarb: bridge control possible
[0.418756] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.420726] vgaarb: loaded
[0.582766] Linux agpgart interface v0.103
[3.643051] nvidia: loading out-of-tree module taints kernel.
[3.643115] nvidia: module license 'NVIDIA' taints kernel.
[3.667623] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.717886] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.724814] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.724897] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[6.387154] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Jan 27 06:35 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Jan 27 06:35 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Jan 27 06:35 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jan 27 06:35 pci-:01:00.0-card -> ../card0
video:*:44:jim

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/legacy-340xx
  link currently points to /usr/lib/nvidia/legacy-340xx
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--20-nvidia-legacy-340xx.conf is 
/etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf
  slave nvidia--libEGL.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
  slave nvidia--libGL.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
  slave nvidia--libGLESv1_CM.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
  slave nvidia--libGLESv2.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
  slave nvidia--libglx.so is /usr/lib/nvidia/libglx.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--monitoring.conf is /usr/share/nvidia/monitoring.conf
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave 

Bug#1026766: sweethome3d: Crashes with "Assertion `!xcb_xlib_threads_sequence_lost' failed"

[Lluís Gras]

Hi,

It seems somehow related to VGA in use.

Same setup (cloned boxes) works with

00:02.0 VGA compatible controller [0300]: Intel Corporation GeminiLake [UHD
Graphics 600] [8086:3185] (rev 06)
DeviceName: Onboard - Video
Subsystem: Hewlett-Packard Company GeminiLake [UHD Graphics 600] [103c:87f9]
Kernel driver in use: i915
Kernel modules: i915

and crashes with

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev e2)
Subsystem: Hewlett-Packard Company Stoney [Radeon R2/R3/R4/R5 Graphics]
[103c:8381]
Kernel driver in use: amdgpu
Kernel modules: amdgpu

Bug#1029661: Cannot authenticate with Google

[Unit 193]

Howdy,



Google no longer allows gcalcli to authenticate. Upstream recommends
manually creating a developer account and registering gcalcli as your
own app. This is a *much* more cumbersome setup process, and the simple
oauth2 workflow that gcalcli uses by default doesn't work with no
indication of why.


While it's certainly more complicated than it used to be, I switched 
auth methods back when gcalcli ran into API quota issues and it's been 
working fine ever since.


I've seen others have issues where they have to re-authenticate after 7 
days, but I haven't personally run into that problem.  Then again I also 
have gcalcli run in conky so it may be run often enough to refresh the 
key.



At a minimum, this should be documented and the flow for not having
authenticated yet should give better guidance to the user and not try an
authentication that won't work.


Sure, I can nab the upstream commit[0] that documents the changes.  This 
close to freeze I don't think upstream is going to find an ideal solution 
to the problem.



[0]: 
https://github.com/insanum/gcalcli/commit/8c812e3da68ae6cbd220182517a64939df0c1b38


https://github.com/insanum/gcalcli/issues/580


~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#930578: #930578: ITP: txi2p -> RFP: txi2p

[Andrius Merkys]

Control: retitle -1 RFP: txi2p -- I2P bindings for Twisted
Control: noowner !

On Wed, 13 Oct 2021 09:28:28 +0300 Andrius Merkys  wrote:

Control: retitle -1 ITP: txi2p -- I2P bindings for Twisted
Control: owner -1 !
Control: tags -1 + patch


Since tahoe-lafs does not need this anymore (replaced with txi2p-tahoe), 
I am changing this ITP back to RFP.


Andrius

Bug#1029754: please support telling the architecture of a vmlinuz image

[Helmut Grohne]

Package: arch-test
Version: 0.20-1
Severity: wishlist
Control: affects -1 + debvm

Hi Adam,

arch-test already is great, but maybe it can do even more. I would like
to know which architecture corresponds to a given vmlinuz image.

A vmlinuz image tends to consist of a boot stub followed by a compressed
ELF image. The compression scheme varies and we don't exactly know where
the compressed image starts. A relatively hacky way to do this is runnig
linux.git/scripts/extract-vmlinux and then feeding the output to
elf-arch. Maybe we can pull part of this functionality into arch-test?

The context of this is usage of arch-test in debvm. Given a root
filesystem, I already use elf-arch on the contained /bin/true to guess
its architecture. However the kernel image may correspond to a bigger
architecture (i386 -> amd64, armel -> armhf, armhf -> arm64, etc.) and I
would like to determine such cases automatically. As such, this
functionality is only really relevant for architectures with sibling
32bit / 64bit architectures.

There is not much ugrency to this. It just feels like arch-test would be
the right place to own this functionality. Thanks for considering. If
you end up considering this out-of-scope (e.g. due to the need for
various decompressors), don't hesitate to close this as wontfix.

Helmut

Bug#1029753: perl: build-depend on libcrypt-dev explicitly

[Helmut Grohne]

Source: perl
Version: 5.36.0-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

perl uses -lcrypt without depending on libcrypt-dev. This used to be ok,
but we split libcrypt to src:libxcrypt and now libc6-dev has a
transitional dependency on libcrypt-dev.  So while libcrypt-dev still is
build-essential, it no longer is in a bootstrap setting (in order to
solve dependency cycles) and given that so few packages actually need
libcrypt-dev, we want to remove it from build-essential in the long
term. As such there is no urgency to adding it right now, it also
doesn't hurt. I'm attaching the obvious patch for your convenience.

Helmut
diff --minimal -Nru perl-5.36.0/debian/changelog perl-5.36.0/debian/changelog
--- perl-5.36.0/debian/changelog2023-01-08 22:28:47.0 +0100
+++ perl-5.36.0/debian/changelog2023-01-27 07:59:10.0 +0100
@@ -1,3 +1,10 @@
+perl (5.36.0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on libcrypt-dev explicitly. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 27 Jan 2023 07:59:10 +0100
+
 perl (5.36.0-7) unstable; urgency=medium
 
   * Break backuppc (<< 4.4.0-7~) due to Data::Dumper changes in 5.36
diff --minimal -Nru perl-5.36.0/debian/control perl-5.36.0/debian/control
--- perl-5.36.0/debian/control  2023-01-08 22:28:47.0 +0100
+++ perl-5.36.0/debian/control  2023-01-27 07:59:09.0 +0100
@@ -8,6 +8,7 @@
 Rules-Requires-Root: no
 Build-Depends: file,
  cpio,
+ libcrypt-dev,
  libdb-dev,
  libgdbm-dev (>= 1.18-3),
  libgdbm-compat-dev,

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Richard

It is a different email I'm referring to. When a script, run by
cron, prints something on standard output that will be sent to the root
user as an email. At least in standard configuration.
You should therefore have received two emails. One from cron-apt itself. We
know that will not arrive due to this problem. The other email should also
be sent by cron itself, but that do not seem to arrive either. Strange.

Can you change the line in cron so it outputs stdout and stderr to a file
instead?

// Ola

On Fri, 27 Jan 2023 at 07:20, Richard Rosner 
wrote:

> They are supposed to be sent to the mail address defined in the cron-apt
> config. It didn't arrive there. Or did the change of executing cron-apt
> change anything about that?
>
> Richard
>
>
> On January 27, 2023 12:18:13 AM GMT+01:00, Ola Lundqvist 
> wrote:
>
>> Hi Richard
>>
>> I thought you would get the cron output from bash -x in an email so I
>> could see more what happens. It should be sent to the root user. Or have
>> you redirected those emails so you do not get them?
>>
>> Sorry for not being clear on that.
>>
>> Best regards
>>
>> // Ola
>>
>> On Thu, 26 Jan 2023 at 15:15, Richard Rosner <
>> rros...@fsmuw.rwth-aachen.de> wrote:
>>
>>> With RUNSLEEP disabled, I get
>>> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x
>>> test -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
>>> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
>>> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>>>
>>> No kernel errors. I didn't receive a mail about updates, though, but I
>>> also don't know the time the server I get the updates from updates its
>>> repository the last time.
>>>
>>> With RUNSLEEP set to 3600 I get the same (running with no delay). And
>>> even though I did run apt update between these two runs (28 updates
>>> available) I didn't receive the mail.
>>> ​​
>>> Richard
>>>
>>>
>>> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
>>> o...@inguza.com>:
>>>
>>>
>>> Argh!
>>>
>>> Can you run it with bash -x from cron? Hopefully it tells where it
>>> breaks
>>>
>>> Den tis 24 jan. 2023 17:06Richard Rosner 
>>> skrev:
>>>
 No, and it did send a mail.

 --
 Richard Rosner

 Studierendenschaft der RWTH Aachen University
 Fachschaft Materialwissenschaft und Werkstofftechnik
 Intzestraße 1
 52072 Aachen
 Tel.: +49 241 80-95781
 rros...@fsmuw.rwth-aachen.de
 www.fsmuw.rwth-aachen.de

 Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
 o...@inguza.com>:


 Did you get that kernel error?

 Den tis 24 jan. 2023 14:12Richard Rosner 
 skrev:

> This is the output (not sure if attachments are possible here, so I
> put it into the body):
>
> + export
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
> + UMASK_TIGHT=077
> + UMASK_APT=022
> + umask 077
> + STDOUT=
> + ALLCONFIGS=
> + '[' -n '' ']'
> + '[' -z '' ']'
> + CONFIG=/etc/cron-apt/config
> + ALLCONFIGS=/etc/cron-apt/config
> + LIBDIR=/var/lib/cron-apt
> + SHAREDIR=/usr/share/cron-apt
> ++ echo /etc/cron-apt/config
> ++ sed 's|/|_-_|g'
> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
> ++ mktemp -d -t cron-apt.XX
> + TMPDIR=/tmp/cron-apt.X5DFeL
> + '[' 0 -ne 0 ']'
> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
> + TEMP=/tmp/cron-apt.X5DFeL/temp
> + MAIL=/tmp/cron-apt.X5DFeL/mail
> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
> + STATUS=/tmp/cron-apt.X5DFeL/status
> + LOCKFILE=/var/lib/cron-apt/lockfile
> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
> + ACTIONDIR=/etc/cron-apt/action.d
> + ACTIONCONFDIR=/etc/cron-apt/config.d
> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
> + REFRAINFILE=/etc/cron-apt/refrain
> + NOLOCKWARN=
> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
> + LOGMSGDIR=/etc/cron-apt/logmsg.d
> + LOGDIR=/var/log/cron-apt
> + LOG=/var/log/cron-apt/log
> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
> + DIFFONCHANGES=prepend
> + SUBJECTPREFIX=CRON-APT
> + MAILTO=root
> + MAILWIDTH=900
> + SYSLOGON=upgrade
> + MAILON=error
> + EXITON=error

Bug#1028116: linux-image-6.0.0-4-amd64: Bluetooth no longer working with Mediatek MT7921K chipset

[Matthew McAllister]

Hi again,

I found the time to tinker on my computer the past week. I installed 6.1.4-1 
and 5.19.11-1 and neither kernel them worked; eventually I came to the 
conclusion my hardware is faulty. There's a thread in debian-user about it.

Thank you for your help; you should close this report as I no longer have 
reason to believe this is a software issue.

Matthew

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Richard Rosner]

They are supposed to be sent to the mail address defined in the cron-apt 
config. It didn't arrive there. Or did the change of executing cron-apt change 
anything about that?

Richard

On January 27, 2023 12:18:13 AM GMT+01:00, Ola Lundqvist  
wrote:
>Hi Richard
>
>I thought you would get the cron output from bash -x in an email so I could
>see more what happens. It should be sent to the root user. Or have
>you redirected those emails so you do not get them?
>
>Sorry for not being clear on that.
>
>Best regards
>
>// Ola
>
>On Thu, 26 Jan 2023 at 15:15, Richard Rosner 
>wrote:
>
>> With RUNSLEEP disabled, I get
>> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x test
>> -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
>> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
>> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>>
>> No kernel errors. I didn't receive a mail about updates, though, but I
>> also don't know the time the server I get the updates from updates its
>> repository the last time.
>>
>> With RUNSLEEP set to 3600 I get the same (running with no delay). And even
>> though I did run apt update between these two runs (28 updates available) I
>> didn't receive the mail.
>> ​​
>> Richard
>>
>>
>> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
>> o...@inguza.com>:
>>
>>
>> Argh!
>>
>> Can you run it with bash -x from cron? Hopefully it tells where it breaks
>>
>> Den tis 24 jan. 2023 17:06Richard Rosner 
>> skrev:
>>
>>> No, and it did send a mail.
>>>
>>> --
>>> Richard Rosner
>>>
>>> Studierendenschaft der RWTH Aachen University
>>> Fachschaft Materialwissenschaft und Werkstofftechnik
>>> Intzestraße 1
>>> 52072 Aachen
>>> Tel.: +49 241 80-95781
>>> rros...@fsmuw.rwth-aachen.de
>>> www.fsmuw.rwth-aachen.de
>>>
>>> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
>>> o...@inguza.com>:
>>>
>>>
>>> Did you get that kernel error?
>>>
>>> Den tis 24 jan. 2023 14:12Richard Rosner 
>>> skrev:
>>>
 This is the output (not sure if attachments are possible here, so I put
 it into the body):

 + export
 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
 + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
 + UMASK_TIGHT=077
 + UMASK_APT=022
 + umask 077
 + STDOUT=
 + ALLCONFIGS=
 + '[' -n '' ']'
 + '[' -z '' ']'
 + CONFIG=/etc/cron-apt/config
 + ALLCONFIGS=/etc/cron-apt/config
 + LIBDIR=/var/lib/cron-apt
 + SHAREDIR=/usr/share/cron-apt
 ++ echo /etc/cron-apt/config
 ++ sed 's|/|_-_|g'
 + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
 ++ mktemp -d -t cron-apt.XX
 + TMPDIR=/tmp/cron-apt.X5DFeL
 + '[' 0 -ne 0 ']'
 + INITLOG=/tmp/cron-apt.X5DFeL/initlog
 + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
 + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
 + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
 + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
 + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
 + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
 + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
 + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
 + TEMP=/tmp/cron-apt.X5DFeL/temp
 + MAIL=/tmp/cron-apt.X5DFeL/mail
 + DIFF=/tmp/cron-apt.X5DFeL/difftemp
 + STATUS=/tmp/cron-apt.X5DFeL/status
 + LOCKFILE=/var/lib/cron-apt/lockfile
 + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
 + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
 + ACTIONDIR=/etc/cron-apt/action.d
 + ACTIONCONFDIR=/etc/cron-apt/config.d
 + MAILMSGDIR=/etc/cron-apt/mailmsg.d
 + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
 + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
 + REFRAINFILE=/etc/cron-apt/refrain
 + NOLOCKWARN=
 + ERRORMSGDIR=/etc/cron-apt/errormsg.d
 + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
 + LOGMSGDIR=/etc/cron-apt/logmsg.d
 + LOGDIR=/var/log/cron-apt
 + LOG=/var/log/cron-apt/log
 + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
 + DIFFONCHANGES=prepend
 + SUBJECTPREFIX=CRON-APT
 + MAILTO=root
 + MAILWIDTH=900
 + SYSLOGON=upgrade
 + MAILON=error
 + EXITON=error
 + DEBUG=verbose
 + OPTIONS='-o quiet=1'
 + DONTRUN=
 + RUNSLEEP=3600
 + MINTMPDIRSIZE=10
 + APTCOMMAND=/usr/bin/apt-get
 + HOSTNAME=
 + DIFFIGNORE=
 + DIFFONCHANGES=prepend
 + export DEBIAN_FRONTEND=noninteractive
 + DEBIAN_FRONTEND=noninteractive
 + export LANG=C
 + LANG=C
 + export LC_ALL=C
 + LC_ALL=C
 + for cfg in $ALLCONFIGS
 + '[' -f /etc/cron-apt/config ']'
 + . /etc/cron-apt/config
 ++ APTCOMMAND=/usr/bin/apt-get
 ++ MAILTO=administra...@fsmuw.rwth-aachen.de
 ++ MAILON=upgrade
 ++ SYSLOGON=always
 + test '' = yes
 + . /usr/share/cron-apt/functions
 + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
 + '[' -d 

Bug#1029622: tuxguitar-alsa fails to install

[tony mancill]

On Wed, Jan 25, 2023 at 08:45:55PM +0100, Helmar Gerloni wrote:
> Hi Tony,
> 
> sorry for causing so much work with tuxguitar, and thanks for your efforts!
> 
> Do you think it would make sense to merge all the tuxguitar* packages into 
> one package tuxguitar with arch-any? Maybe this would solve these build 
> problems.
> 
> I could try this out and put a new package on mentors; just let me know.

Hi Helmar,

I think a patch like the one below is going to take care of the conflicting
files.  I need to do some piuparts testing and then I will upload again.

Also, I'm considering of excluding mipsel and mips64el from the build
architectures in the next upload.  Any concerns?

Thank you,
tony

--
diff --git a/debian/rules b/debian/rules
index 9482c1d..d6c3076 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,3 +21,7 @@ override_dh_auto_configure:
 override_dh_auto_build:
dh_auto_build --sourcedirectory=build-scripts/tuxguitar-linux-x86_64 -- 
-e clean verify -Dnative-modules=true
docbook-to-man misc/tuxguitar.sgml > debian/tuxguitar.1
+
+override_dh_install-arch:
+   dh_auto_install
+   -rf -rfv ./debian/tuxguitar-alsa/usr/share/maven-repo


signature.asc
Description: PGP signature

Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64

[tony mancill]

Hi Alex,

On Thu, Jan 26, 2023 at 10:55:09PM +0100, Alexandre Rossi wrote:
> Hi,
> 
> I prepared an updated package with the new upstream version.
> 
> https://mentors.debian.net/package/libjna-java/
> 
> My commits are available at: https://salsa.debian.org/niol/libjna-java/

I will take a look.  Thank you for contribution to Debian!

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1029752: tests fail with nmh 1.8~RC-2, blocking nmh from entering testing

[Alexander Zangerl]

Package: xlbiff
Version: 4.6.3-1
Severity: important

xlbiff's autopkgtests fail (silently) with nmh 1.8, which means that
version of nmh cannot enter testing. the autopkgtest
"regression" log files are devoid of any useful information, so i
cannot pinpoint *what* in xlbiff fails, but something is broken.

Bug#1029751: apt: please add support for non-free-firmware

[Cyril Brulebois]

Package: apt
Version: 2.5.5
Severity: important

Hi,

While working on debian-installer and debian-cd, I had a look around
in apt-cdrom's source, which led me to file this MR:
  https://salsa.debian.org/apt-team/apt/-/merge_requests/278

It's probably not very useful, or even needed apparently, for the
installer's needs… but looking around a little more, I spotted that
components are hardcoded at least in debian/apt.conf.autoremove and
it would make sense to add support for non-free-firmware there:
 - firmware-linux → non-free-firmware/metapackages
 - firmware-linux-nonfree → non-free-firmware/metapackages
 - firmware-qcom-media→ non-free-firmware/oldlibs

At least once those changes reach the archive:
 - https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/48
 - https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/49

I haven't checked anything below doc/, but some update there might
make sense too.


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

Bug#1029750: python3-upstream-ontologist: should depend on python3-ruamel.yaml and python3-breezy

[Lev Lamberov]

Package: python3-upstream-ontologist
Version: 0.1.30-2
Severity: important
Tags: newcomer

Dear Maintainer,

I decided to give upstream-ontologist a try and installed it on my
machine for testing. It was a fresh install. But on the first run I
got the following:

$ guess-upstream-metadata
Traceback (most recent call last):
  File "/usr/bin/guess-upstream-metadata", line 33, in 
sys.exit(load_entry_point('upstream-ontologist==0.1.30', 'console_scripts', 
'guess-upstream-metadata')())
  File "/usr/lib/python3/dist-packages/upstream_ontologist/__main__.py", line 
37, in main
import ruamel.yaml
ModuleNotFoundError: No module named 'ruamel'

And then after manually installing python3-ruamel.yaml I've got the
following:

$ guess-upstream-metadata
Traceback (most recent call last):
  File "/usr/bin/guess-upstream-metadata", line 33, in 
sys.exit(load_entry_point('upstream-ontologist==0.1.30', 'console_scripts', 
'guess-upstream-metadata')())
  File "/usr/lib/python3/dist-packages/upstream_ontologist/__main__.py", line 
104, in main
metadata = guess_upstream_metadata(
  File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line 
2337, in guess_upstream_metadata
return summarize_upstream_metadata(
  File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line 
2315, in summarize_upstream_metadata
fix_upstream_metadata(upstream_metadata)
  File "/usr/lib/python3/dist-packages/upstream_ontologist/guess.py", line 
3580, in fix_upstream_metadata
url = sanitize_vcs_url(url)
  File "/usr/lib/python3/dist-packages/upstream_ontologist/vcs.py", line 528, 
in sanitize_url
url = sanitizer(url)
  File "/usr/lib/python3/dist-packages/upstream_ontologist/vcs.py", line 328, 
in fixup_rcp_style_git_repo_url
from breezy.location import rcp_location_to_url
ModuleNotFoundError: No module named 'breezy'

So, I manually installed python3-breezy and now it works as expected.

Cheers!
Lev

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 python3-upstream-ontologist depends on:
ii  python33.10.6-3+b1
ii  python3-debian 0.1.49
ii  python3-debmutate  0.63

Versions of packages python3-upstream-ontologist recommends:
ii  perl-doc 5.36.0-7
ii  python3-bs4  4.11.1-3
ii  python3-distro-info  1.3
ii  python3-docutils 0.19+dfsg-6
ii  python3-dulwich  0.21.2-1
ii  python3-lxml 4.9.2-1
ii  python3-markdown 3.4.1-2
ii  python3-setuptools   65.6.3-1
ii  python3-toml 0.10.2-1
ii  python3-tomlkit  0.11.6-1

Versions of packages python3-upstream-ontologist suggests:
pn  python3-breezy   
pn  python3-ruamel.yaml  

-- no debconf information

Bug#695835:

[Official Firm]

Good day to you.
How are you doing? Did you see the previous mail i sent to you?

Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)

[Stuart Prescott]

Hi Diederik!

On 27/01/2023 09:17, Diederik de Haas wrote:

Package: svn-all-fast-export
Version: 1.0.18+git20200501-1
Severity: wishlist

It would be great if the latest version could be packaged for Debian.
I recently had the need to retrieve a repo from the alioth archive and
convert it to git. And this sounds like a great tool for that where
upstream has even worked on the code in the last couple of years ;-)

Anything that could make that task easier would be appreciated and a
newer version of svn-all-fast-export may just help.


Upstream doesn't often make releases and so the "new upstream" 
notification from the watch file is only about new commits being made to 
the upstream repo, not a new version being available. Most of the recent 
upstream activity has been about CI on GitHub and not actual changes to 
the package.


Is there anything in the recent commits that would help you? I hadn't 
seen anything to justify updating the package but if there's something 
specific, please say and we can do it.


regards
Stuart

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

Bug#1028372: ncat: Please lower alternative priority below nc.traditional

[Arnaud Rebillout]

On Wed, 18 Jan 2023 23:04:54 +0100 Hilko Bengen  wrote:
> > We have users in Kali Linux who have been beaten by this. They use nc,
> > they also need ncat for the extra options it provides, they install it,
> > and then are very surprised that nc is now ncat. From their background
> > (I'm talking about professional pentesters), nc and ncat are different
> > tools, they really don't expect ncat to replace nc.
>
> I'd like to see in what way people have been irritateed. Can you link to
> specific bug reports or mailing list/form discussions?

From my understanding, one big difference between nc and ncat is the 
output. ncat's output is very different from nc, much more verbose 
apparently. This is not always suitable, for example some folks have 
teaching material with nc, where they demonstrate nc's commands and 
output. They also need to use ncat in those courses, but from the moment 
ncat is installed, nc's output become ncat, the output is much more 
verbose. It's kind of confusing, and even though they *could* update 
their courses to show ncat's output (instead of nc), and explain that 
"after installing ncat, nc is now ncat", it's just not what they want, 
because ncat's output is too verbose, while nc output is just right (for 
the purpose of teaching material).


Another point, as I understand it, is just that ncat and nc have always 
been two different tools (although they clearly have some big overlap), 
at least in Debian & Kali, since before April 2018, they have always 
been distributed as two different tools. So users have been used to 
install & use nc when needed, install & use ncat when needed, and 
sometimes install & use both, each for a specific purpose. While the 
use-case of having ncat == nc exists, I have the impression that it's 
maybe not the main use-case.


I will reach out to the folks who reported this issue, and try to get 
them to provide more details on this bug report.


Also, for transparency: those folks are from Offensive Security, which 
is also my employer (Kali Linux is developed by Offensive Security). 
Apologizes for not stating that in my initial message.


Cheers,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1029749: pypi2deb: crashes with Python 3.11: AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you mean: 'coroutines'?

[Paul Wise]

Package: pypi2deb
Version: 3.20220721
Severity: serious
Usertags: crash
User: debian-pyt...@lists.debian.org
Usertags: python3.11

With Python 3.11 in a clean sid chroot, both py2dsp and pypi2debian
crash with an error about the asyncio module attributes. This can also
be seen on a mixed bookworm/sid system when forcing python3.11 usage.

   $ py2dsp 
   Traceback (most recent call last):
 File "/usr/bin/py2dsp", line 32, in 
   from pypi2deb.debianize import debianize
 File "/usr/share/pypi2deb/pypi2deb/debianize.py", line 29, in 
   from pypi2deb.tools import execute
 File "/usr/share/pypi2deb/pypi2deb/tools.py", line 92, in 
   @asyncio.coroutine
^
   AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you mean: 
'coroutines'?
   
   $ pypi2debian 
   Traceback (most recent call last):
 File "/usr/bin/pypi2debian", line 35, in 
   from pypi2deb.debianize import debianize
 File "/usr/share/pypi2deb/pypi2deb/debianize.py", line 29, in 
   from pypi2deb.tools import execute
 File "/usr/share/pypi2deb/pypi2deb/tools.py", line 92, in 
   @asyncio.coroutine
^

   $ python3.11 /usr/bin/py2dsp 
   Traceback (most recent call last):
 File "/usr/bin/py2dsp", line 32, in 
   from pypi2deb.debianize import debianize
 File "/usr/share/pypi2deb/pypi2deb/debianize.py", line 29, in 
   from pypi2deb.tools import execute
 File "/usr/share/pypi2deb/pypi2deb/tools.py", line 92, in 
   @asyncio.coroutine
^
   AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you mean: 
'coroutines'?

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.22.2
ii  dh-python5.20230109
ii  python3  3.11.1-1
ii  python3-aiohttp  3.8.3-1+b1
ii  python3-debian   0.1.49
ii  python3-github   1.55-3
ii  python3-jinja2   3.0.3-2
ii  python3-redis4.3.4-3

Versions of packages pypi2deb recommends:
pn  python3-msgpack  

Versions of packages pypi2deb suggests:
pn  cython  
pn  cython3 
pn  pypy
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
pn  python-setuptools   
pn  python3-all-dev 
pn  python3-nose
pn  python3-pytest  
pn  python3-setuptools  
pn  python3-sphinx  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1029076: closed by Jonas Smedegaard (reply to 1029...@bugs.debian.org) (Re: [pkg-uWSGI-devel] Bug#1029076: uwsgi-plugin-python3: built against non-default libpython3.11 / should a

[Dominik George]

Control: reopen -1

> Sorry, but I fail to see any problem here.
>
> uwsgi _does_ build against the default Python.

Yes, but the default Python it builds against in unstable is not necessarily 
the default Python in testing.

Right now, it is built against Python 3.11, while the default Python in testing 
is 3.10. Hence, it does not work in testing (have you actually tried that after 
my bug report?).

Bug#1029748: All bugs with submitter=... package=all, latest first, limit 30

[Dan Jacobson]

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

I wish there was a way to use the
https://wiki.debian.org/UltimateDebianDatabase/
to find all the bugs I have submitted, for all packages in Debian,
latest first, limit=30.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?=jida...@jidanni.org
finds too many, and no way to make latest first.

Bug#1029667: downgrading heif-gdk-pixbuf:amd64 from 1.14.2-1 to 1.13.0-1 to work

[Dan Jacobson]

See also #1029668.
But gpicview shouldn't segfault anyway.

Bug#1029668: downgrading heif-gdk-pixbuf:amd64 from 1.14.2-1 to 1.13.0-1 to work

[Dan Jacobson]

severity 1029668 grave
thanks

I had to do
dpkg -i /var/cache/apt/archives/*1.13.0-*
dpkg: warning: downgrading heif-gdk-pixbuf:amd64 from 1.14.2-1 to 1.13.0-1
dpkg: warning: downgrading libheif-examples from 1.14.2-1 to 1.13.0-1
dpkg: warning: downgrading libheif1:amd64 from 1.14.2-1 to 1.13.0-1
to make viewnior and gpicview work again.

Bug#1029747: Empty "Categorize using"

[Dan Jacobson]

Package:www.debian.org

On https://www.debian.org/Bugs/ there is an empty
Categorize using

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

On 2023-01-27 00:55, Jeremy Bicha wrote:

On Thu, Jan 26, 2023 at 5:39 PM Gunnar Hjalmarsson
 wrote:

That detail made me curious. I suppose it's related to this
commit:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

Which is not only about monospace, but affects most Debian users, >> also for 
sans-serif and serif, and also for web browsing, since
fonts-noto-core is installed by default (probably due to the meta
package libreoffice).

That's a pretty radical change to come from fontconfig upstream.
Hello Noto, goodbye DejaVu. Was it even discussed anywhere?


The individual who made the change upstream started this discussion:
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts


Not much of discussion, though. ;) But thanks for the link with the 
rationale from a Fedora POV.


Again, I support the change, and my question about a possible discussion 
was merely out of curiosity.


--
Gunnar

Bug#1029746: want: querybts --submitter= ... --limit=...

[Dan Jacobson]

Package: reportbug
Version: 11.6.0
Severity: wishlist
File: /usr/bin/querybts

I want to use querybts to find the latest 30 bugs that I have submitted,
for all packages.

Currently
https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=jida...@jidanni.org
finds thousands... too many, and no way to change the order.

--latest-first looks good, but wish also to have --limit= so one doesn't
need head -n ...

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 5:39 PM Gunnar Hjalmarsson  wrote:
> That detail made me curious. I suppose it's related to this commit:
>
> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785
>
> Which is not only about monospace, but affects most Debian users, also
> for sans-serif and serif, and also for web browsing, since
> fonts-noto-core is installed by default (probably due to the meta
> package libreoffice).
>
> That's a pretty radical change to come from fontconfig upstream. Hello
> Noto, goodbye DejaVu. Was it even discussed anywhere?

The individual who made the change upstream started this discussion:
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts

Thank you,
Jeremy Bicha

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jelmer Vernooij]

reassign 1029722 python3-upstream-ontologist
thanks

On Thu, Jan 26, 2023 at 07:48:18PM +, Jelmer Vernooij wrote:
> On Thu, Jan 26, 2023 at 02:43:04PM -0500, Jeremy Bicha wrote:
> > On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij  wrote:
> > > It does actally support setting the Repository field, but it will verify
> > > that the upstream repository looks plausible - i.e. that it has at least
> > > some tags matching upstream versions. That verification is probably
> > > broken for some reason.
> > 
> > It isn't adding the Repository field most of the time that I've been
> > running it this month.
> 
> Do you happen to have a few examples handy?

Actually, I've reproduced this - assuming you're just seeing this for GitHub 
repositories.

Jelmer

Bug#1029731: libglapi-mesa: Also with 23.0.0

[John Sullivan]

Package: libglapi-mesa
Version: 23.0.0~rc1-1
Followup-For: Bug #1029731
X-Debbugs-Cc: jo...@debian.org

I tested with 

mesa-va-drivers_23.0.0~rc1-1_arm64.deb
mesa-vdpau-drivers_23.0.0~rc1-1_arm64.deb
libegl-mesa0_23.0.0~rc1-1_arm64.deb
libgbm1_23.0.0~rc1-1_arm64.deb
libgl1-mesa-dri_23.0.0~rc1-1_arm64.deb
libglapi-mesa_23.0.0~rc1-1_arm64.deb
libglx-mesa0_23.0.0~rc1-1_arm64.deb

and see the same error under the same circumstances as the OP.


-- Package-specific info:
glxinfo:

DISPLAY is not set.

/usr/share/bug/xserver-xorg-core/script not available

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

Kernel: Linux 6.1-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
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)

Versions of packages libglapi-mesa depends on:
ii  libc6  2.36-8

libglapi-mesa recommends no packages.

libglapi-mesa suggests no packages.

-- no debconf information

Bug#1028345: Bug#1028433: sagemath package currently absent from bookworm

[Eric Towers]

Successfully built Sagemath 9.6 on Bookworm ("apt dist-upgrade"-ed as
of 25 January 2023) using the following script.  (It seems to have
partially built 9.7, and that build might be fixable by an interested
someone.)  The important piece seems to be

./configure --without-system-gcc --without-system-pari
--without-system-singular

to avoid the version conflicts reported in Debian Bug report #1028345.
This script redirects output to log files.  These are not small.
9.5: 3.77 MB
9.6: 27.5 MB
9.7: 5.37 GB
One might consider removing the 9.7 target below if one is space constrained.

The script is a little sloppy.  (It's intended to build a much broader
range of Sagemath versions for regression testing.)  For example, it
installs pari and singular, then tells the Sagemath build to ignore
them.  I've edited it down to post here and I *think* this editing
hasn't introduced errors.  (A likely error is newlines appearing in
the "sudo apt install" lines as a result of passing through a mail
system.  This is noted in the script.)

--- begin script ---

#!/bin/bash

# Downloads source code for several versions of Sagemath, then attempts to
# build the sources.  If an argument is given, only that Sagemath
version is acted
# upon.  Each resulting sagemath-[version] directory that contains a
# successful build is a SAGE_ROOT.
#
# TODO: Need to handle [version] argument.  Currently, just downloads
and rebuilds
# everything -- which is the right thing to do when you're still figuring
# out how to get the builds to work.

# Extracted from
https://doc.sagemath.org/html/en/installation/source.html#sec-installation-from-sources
# The following two lines (both "sudo apt install ...") likely have
picked up internal newlines passing through intermediary systems.  If
there's a problem, check for inserted newlines.
sudo apt install bc binutils bzip2 ca-certificates cliquer cmake curl
ecl eclib-tools fflas-ffpack flintqs g++ gcc gengetopt gfan gfortran
glpk-utils gmp-ecm lcalc libatomic-ops-dev libboost-dev
libbraiding-dev libbrial-dev libbrial-groebner-dev libbz2-dev
libcdd-dev libcdd-tools libcliquer-dev libcurl4-openssl-dev libec-dev
libecm-dev libffi-dev libflint-arb-dev libflint-dev libfontconfig1-dev
libfplll-dev libfreetype6-dev libgc-dev libgd-dev libgf2x-dev
libgiac-dev libgivaro-dev libglpk-dev libgmp-dev libgsl-dev
libhomfly-dev libiml-dev liblfunction-dev liblinbox-dev liblrcalc-dev
liblzma-dev libm4ri-dev libm4rie-dev libmpc-dev libmpfi-dev
libmpfr-dev libncurses5-dev libntl-dev libopenblas-dev libpari-dev
libpcre3-dev libplanarity-dev libppl-dev libprimesieve-dev
libpython3-dev libqhull-dev libreadline-dev librw-dev libsingular4-dev
libsqlite3-dev libssl-dev libsuitesparse-dev libsymmetrica2-dev
libz-dev libzmq3-dev libzn-poly-dev m4 make nauty ninja-build openssl
palp pari-doc pari-elldata pari-galdata pari-galpol pari-gp2c
pari-seadata patch perl pkg-config planarity ppl-dev python3
python3-distutils python3-venv r-base-dev r-cran-lattice singular
singular-doc sqlite3 sympow tachyon tar tox xcas xz-utils default-jdk
dvipng ffmpeg imagemagick latexmk libavdevice-dev pandoc tex-gyre
texlive-fonts-recommended texlive-lang-cyrillic texlive-lang-english
texlive-lang-european texlive-lang-french texlive-lang-german
texlive-lang-italian texlive-lang-japanese texlive-lang-polish
texlive-lang-portuguese texlive-lang-spanish texlive-latex-extra
texlive-xetex xclip 4ti2 clang coinor-cbc coinor-libcbc-dev graphviz
libfile-slurp-perl libgraphviz-dev libigraph-dev libisl-dev
libjson-perl libmongodb-perl libnauty-dev libperl-dev libpolymake-dev
libsvg-perl libterm-readkey-perl libterm-readline-gnu-perl
libxml-libxslt-perl libxml-writer-perl libxml2-dev lrslib pari-gp2c
pdf2svg polymake texinfo dvipng ffmpeg imagemagick texlive-full
texlive-extra-utils texlive-science texlive-xetex latexmk pandoc
default-jdk libavdevice-dev tk tk-dev
sudo apt install libflint-arb-dev libbrial-dev libbrial-groebner-dev
ecl libec-dev eclib-tools fflas-ffpack libflint-dev libfreetype6-dev
gcc g++ libgiac-dev xcas libgivaro-dev libgd-dev libntl-dev libppl-dev
ppl-dev libqhull-dev singular libsingular4-dev libzmq3-dev 4ti2
texlive-latex-extra texlive-xetex latexmk dvipng default-jdk
libavdevice-dev lrslib

# Let's simplify the list of versions for building on Bookworm.
# for i in 6.5 6.6 6.7 6.8 6.9 6.10 7.0 7.1 7.2 7.3 7.4 7.5.1 7.6 8.0
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 9.0 9.1 9.2 9.3 9.4 9.5 9.6 9.7 ;
do
for i in 9.5 9.6 9.7 ; do
if [ ! -d "sagemath-$i" ]; then
git clone --depth 1 --branch $i
https://github.com/sagemath/sage.git sagemath-$i
fi
mkdir -p log-build-sagemath
cd sagemath-$i

( ( make clean ; make dist-clean ; make configure ; ./configure
--without-system-gcc --without-system-pari --without-system-singular ;
make -j build ; make -j doc ) && ( ./sage -pip install pytest ; make
ptestlong ) ) &> ../log-build-sagemath/sagemath-$i &
done

echo """All git downloads completed.  Various builds will download
some 

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

[Simon Quigley]

Hello,

While I can't confirm the original error in the bug report, I can confirm that the autopkgtests fail with Python 3.11, 
and require some fixes.


I have uploaded a fix for this to Ubuntu, the delta is attached. I also uploaded this to DELAYED/2 (the fix is 
non-intrusive and only affects the test suite, so it should be safe). Please let me know if you would like this delayed 
further, cancelled, or expedited.


Thanks,
--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
diff -Nru silx-1.1.0+dfsg/debian/changelog silx-1.1.0+dfsg/debian/changelog
--- silx-1.1.0+dfsg/debian/changelog	2022-11-04 15:54:24.0 +
+++ silx-1.1.0+dfsg/debian/changelog	2023-01-26 22:56:43.0 +
@@ -1,3 +1,9 @@
+silx (1.1.0+dfsg-3ubuntu1) lunar; urgency=medium
+
+  * Add a patch fixing the build with Python 3.11.
+
+ -- Simon Quigley   Thu, 26 Jan 2023 16:56:43 -0600
+
 silx (1.1.0+dfsg-3) unstable; urgency=medium
 
   * do not run test which use lot's of memory
diff -Nru silx-1.1.0+dfsg/debian/control silx-1.1.0+dfsg/debian/control
--- silx-1.1.0+dfsg/debian/control	2022-11-04 15:54:24.0 +
+++ silx-1.1.0+dfsg/debian/control	2023-01-26 22:56:43.0 +
@@ -1,5 +1,6 @@
 Source: silx
-Maintainer: Debian Science Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Science Maintainers 
 Uploaders:
  Jerome Kieffer ,
  Picca Frédéric-Emmanuel ,
diff -Nru silx-1.1.0+dfsg/debian/patches/0008-python3.11-fix.patch silx-1.1.0+dfsg/debian/patches/0008-python3.11-fix.patch
--- silx-1.1.0+dfsg/debian/patches/0008-python3.11-fix.patch	1970-01-01 00:00:00.0 +
+++ silx-1.1.0+dfsg/debian/patches/0008-python3.11-fix.patch	2023-01-26 22:56:38.0 +
@@ -0,0 +1,27 @@
+Description: Remove special-case for Python 3.11
+Author: Simon Quigley 
+Origin: vendor
+Last-Update: 2023-01-26
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/silx/gui/utils/testutils.py
 b/src/silx/gui/utils/testutils.py
+@@ -141,14 +141,10 @@ class TestCaseQt(unittest.TestCase):
+ 
+ def _currentTestSucceeded(self):
+ if hasattr(self, '_outcome'):
+-if hasattr(self, '_feedErrorsToResult'):
+-# For Python 3.4 -3.10
+-result = self.defaultTestResult()  # these 2 methods have no side effects
+-if hasattr(self._outcome, 'errors'):
+-self._feedErrorsToResult(result, self._outcome.errors)
+-else:
+-# Python 3.11+
+-result = self._outcome.result
++# For Python 3.4 -3.10
++result = self.defaultTestResult()  # these 2 methods have no side effects
++if hasattr(self._outcome, 'errors'):
++self._feedErrorsToResult(result, self._outcome.errors)
+ else:
+ # For Python < 3.4
+ result = getattr(self, '_outcomeForDoCleanups', self._resultForDoCleanups)
diff -Nru silx-1.1.0+dfsg/debian/patches/series silx-1.1.0+dfsg/debian/patches/series
--- silx-1.1.0+dfsg/debian/patches/series	2022-11-04 15:54:24.0 +
+++ silx-1.1.0+dfsg/debian/patches/series	2023-01-26 22:54:36.0 +
@@ -5,3 +5,4 @@
 0005-removed-hdf5plugin-from-full-dependencies.patch
 0007-python3.10-fix.patch
 0007-do-not-install-scipy_spatial-COPYING.txt.patch
+0008-python3.11-fix.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Hi Richard

I thought you would get the cron output from bash -x in an email so I could
see more what happens. It should be sent to the root user. Or have
you redirected those emails so you do not get them?

Sorry for not being clear on that.

Best regards

// Ola

On Thu, 26 Jan 2023 at 15:15, Richard Rosner 
wrote:

> With RUNSLEEP disabled, I get
> 2023-01-26T04:00:01.178308+01:00 ts CRON[60845]: (root) CMD (bash -x test
> -x /usr/sbin/cron-apt && bash -x /usr/sbin/cron-apt)
> 2023-01-26T04:00:02.235676+01:00 ts sSMTP[60847]: Sent mail for
> r...@ts.domain.de (221 mailserver.de) uid=0 username=root outbytes=672
>
> No kernel errors. I didn't receive a mail about updates, though, but I
> also don't know the time the server I get the updates from updates its
> repository the last time.
>
> With RUNSLEEP set to 3600 I get the same (running with no delay). And even
> though I did run apt update between these two runs (28 updates available) I
> didn't receive the mail.
> ​​
> Richard
>
>
> Am Dienstag, 24. Januar 2023 19:00 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Argh!
>
> Can you run it with bash -x from cron? Hopefully it tells where it breaks
>
> Den tis 24 jan. 2023 17:06Richard Rosner 
> skrev:
>
>> No, and it did send a mail.
>>
>> --
>> Richard Rosner
>>
>> Studierendenschaft der RWTH Aachen University
>> Fachschaft Materialwissenschaft und Werkstofftechnik
>> Intzestraße 1
>> 52072 Aachen
>> Tel.: +49 241 80-95781
>> rros...@fsmuw.rwth-aachen.de
>> www.fsmuw.rwth-aachen.de
>>
>> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
>> o...@inguza.com>:
>>
>>
>> Did you get that kernel error?
>>
>> Den tis 24 jan. 2023 14:12Richard Rosner 
>> skrev:
>>
>>> This is the output (not sure if attachments are possible here, so I put
>>> it into the body):
>>>
>>> + export
>>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>>> + UMASK_TIGHT=077
>>> + UMASK_APT=022
>>> + umask 077
>>> + STDOUT=
>>> + ALLCONFIGS=
>>> + '[' -n '' ']'
>>> + '[' -z '' ']'
>>> + CONFIG=/etc/cron-apt/config
>>> + ALLCONFIGS=/etc/cron-apt/config
>>> + LIBDIR=/var/lib/cron-apt
>>> + SHAREDIR=/usr/share/cron-apt
>>> ++ echo /etc/cron-apt/config
>>> ++ sed 's|/|_-_|g'
>>> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
>>> ++ mktemp -d -t cron-apt.XX
>>> + TMPDIR=/tmp/cron-apt.X5DFeL
>>> + '[' 0 -ne 0 ']'
>>> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
>>> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
>>> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
>>> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
>>> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
>>> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
>>> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
>>> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
>>> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
>>> + TEMP=/tmp/cron-apt.X5DFeL/temp
>>> + MAIL=/tmp/cron-apt.X5DFeL/mail
>>> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
>>> + STATUS=/tmp/cron-apt.X5DFeL/status
>>> + LOCKFILE=/var/lib/cron-apt/lockfile
>>> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
>>> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
>>> + ACTIONDIR=/etc/cron-apt/action.d
>>> + ACTIONCONFDIR=/etc/cron-apt/config.d
>>> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
>>> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
>>> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
>>> + REFRAINFILE=/etc/cron-apt/refrain
>>> + NOLOCKWARN=
>>> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
>>> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
>>> + LOGMSGDIR=/etc/cron-apt/logmsg.d
>>> + LOGDIR=/var/log/cron-apt
>>> + LOG=/var/log/cron-apt/log
>>> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
>>> + DIFFONCHANGES=prepend
>>> + SUBJECTPREFIX=CRON-APT
>>> + MAILTO=root
>>> + MAILWIDTH=900
>>> + SYSLOGON=upgrade
>>> + MAILON=error
>>> + EXITON=error
>>> + DEBUG=verbose
>>> + OPTIONS='-o quiet=1'
>>> + DONTRUN=
>>> + RUNSLEEP=3600
>>> + MINTMPDIRSIZE=10
>>> + APTCOMMAND=/usr/bin/apt-get
>>> + HOSTNAME=
>>> + DIFFIGNORE=
>>> + DIFFONCHANGES=prepend
>>> + export DEBIAN_FRONTEND=noninteractive
>>> + DEBIAN_FRONTEND=noninteractive
>>> + export LANG=C
>>> + LANG=C
>>> + export LC_ALL=C
>>> + LC_ALL=C
>>> + for cfg in $ALLCONFIGS
>>> + '[' -f /etc/cron-apt/config ']'
>>> + . /etc/cron-apt/config
>>> ++ APTCOMMAND=/usr/bin/apt-get
>>> ++ MAILTO=administra...@fsmuw.rwth-aachen.de
>>> ++ MAILON=upgrade
>>> ++ SYSLOGON=always
>>> + test '' = yes
>>> + . /usr/share/cron-apt/functions
>>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
>>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges ']'
>>> + '[' -e /etc/cron-apt/refrain ']'
>>> + checktmpsize
>>> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
>>> + SSIZE=4096
>>> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
>>> + FSCOUNT=1021394
>>> + '[' 1021394 -lt 33554432 ']'
>>> + '[' 4085576 -lt 10 ']'
>>> ++ date
>>> + echo 'CRON-APT RUN [/etc/cron-apt/config]: Tue Jan 24 

Bug#1029745: ITP: rust-tree-sitter-cli -- command-line for Tree-sitter parsers

[James McCoy]

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

* Package name: rust-tree-sitter-cli
  Version : 0.20.7
  Upstream Contact: Max Brunsfeld 
* URL : https://github.com/tree-sitter/tree-sitter
* License : MIT
  Programming Lang: Rust, Javascript
  Description : command-line for Tree-sitter parsers

tree-sitter-cli is the tool used to create, test, and use tree-sitter
parsers.

* why is this package useful/relevant?

Neovim 0.8+ include support for using Tree-sitter parsers.  This is
needed to build the packages to provide the parsers.

* how do you plan to maintain it?

I'll be maintaining it within the Debian Rust team.

Bug#1028961: dpkg: reverts to using insecure cryptographic algorithms by default

[Guillem Jover]

On Wed, 2023-01-25 at 21:44:27 +, James Addison wrote:
> Package: dpkg
> Version: 1.21.18
> Followup-For: Bug #1028961
> 
> Are SHA224 and SHA384 used widely by dpkg and/or Debian?

I'd expect all (?) signatures for packaging artifacts in Debian to be
SHA512. This change sets an explicit preference list, so that in case
more secure digest algorithms are unavailable for whatever reason, we
do not end up falling back directly into worse ones.

Thanks,
Guillem

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

On 2023-01-26 15:50, Simon McVittie wrote:

* "Monospace" is a fontconfig alias intended to point to a generic monospace
   font, which until recently was resolved to DejaVu Sans Mono by
   fontconfig. Since the recent upgrade to fontconfig 2.14, "Monospace"
   now prefers Noto Sans Mono instead, if available.


That detail made me curious. I suppose it's related to this commit:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

Which is not only about monospace, but affects most Debian users, also 
for sans-serif and serif, and also for web browsing, since 
fonts-noto-core is installed by default (probably due to the meta 
package libreoffice).


That's a pretty radical change to come from fontconfig upstream. Hello 
Noto, goodbye DejaVu. Was it even discussed anywhere?


Ubuntu does not install the libreoffice meta package and fonts-noto-core 
by default, at least not yet. But the new version of 60-latin.conf will 
be noticed also in Ubuntu: As soon as you install fonts-noto-core for 
some reason, your main font for web browsing will be switched from 
DejaVu to Noto.


Personally I think it's a step in the right direction. Using Noto as 
default font opens doors to much easier handling of font configuration 
for several non-latin languages. And that would be even easier if the 
packaging of fonts-noto-core could be split, so we at least separate the 
basic latin fonts from the rest. (But this gnome-terminal bug is really 
the wrong place to talk about that.)


--
Gunnar

Bug#1028930: php-horde-crypt: (autopkgtest) needs update for php8.2: deprecation warnings on stderr

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.7.12-9

Hi Paul,

On  So 15 Jan 2023 07:18:43 CET, Paul Gevers wrote:


Source: php-horde-crypt
Version: 2.7.12-7
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

We are in the transition of replacing php8.1 with php8.2 [0]. With a  
recent upload of php-defaults the autopkgtest of php-horde-crypt  
fails in testing when that autopkgtest is run with the binary  
packages of php-defaults from unstable. It passes when run with only  
packages from testing. In tabular form:


   passfail
php-defaults   from testing93
php-horde-cryptfrom testing2.7.12-7
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 php-defaults  
to testing [1]. https://www.php.net/ChangeLog-8.php lists the  
changes since 7.4 and may help to identify what needs to be updated.


The test itself passes, but the autopkgtest fails because of  
deprecation warnings on stderr. Output on stderr makes autopkgtest  
fail by default, unless `allow-stderr` is added to the set of  
restrictions. As a flood of deprecation warnings in server logs may  
be very unwanted, I'm not saying that adding the restriction to  
autopkgtest is the right answer to this issue, but because of the  
php transition, it needs to be resolved one way or the other.


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-crypt/30356851/log.gz

PHPUnit 9.5.27 by Sebastian Bergmann and contributors.

Runtime:   PHP 8.2.1
Configuration:  
/tmp/autopkgtest-lxc.waqynnpp/downtmp/build.Xxl/src/Horde_Crypt-2.7.12/test/Horde/Crypt/phpunit.xml


PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
.PHP Deprecated:  Function utf8_encode() is deprecated in  
/usr/share/php/Horde/String.php on line 119
.PHP Deprecated:  Function utf8_encode() is deprecated in  
/usr/share/php/Horde/String.php on line 119
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function utf8_decode() is deprecated in  
/usr/share/php/Horde/String.php on line 384
PHP Deprecated:  Function 

Bug#1027753: Re: Bug#1027753 closed by Andreas Rönnquist (Re: Bug#1027753: geeqie crashes on ssh-forwared remote X)

[Andreas Rönnquist]

On Wed, 18 Jan 2023 08:47:27 +0100 Lars Rohwedder  wrote:
> The bug itself is _not_ fixed. The command-line option is just a
> workaround, so geeqie is usable again, but it (or one of the used
> libraries) still contains the bug.
> 
> So the severity might be lower and might be moved to the causing
> library, but a segfault is still a thing that should be fixed. Don't you
> think so?

As you might have seen I have posted a suggested fix to the release
team - which means it is now in the release teams hands, and up to them
if they allow the fix in Bullseye or not.

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

for the details.

-- Andreas Rönnquist
gus...@debian.org

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 2:48 PM Jelmer Vernooij  wrote:
> Do you happen to have a few examples handy?

First one is Github, second is https://gitlab.gnome.org

https://salsa.debian.org/werdahias/trompeloeil/ as of January 22
https://salsa.debian.org/gnome-team/gnome-weather

Thank you,
Jeremy Bicha

Bug#1029744: snapshot.debian.org: recent imports from debian-ports missing

[Thorsten Glaser]

Package: snapshot.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Packages from dpo used to show up¹ but now don’t²; I did check the
corresponding buildd status page to verify that there are Installed
build results, e.g. for riscv64 (and others).

① https://snapshot.debian.org/package/mksh/59c-20/ ca. 2022-12-09
② https://snapshot.debian.org/package/mksh/59c-21/ ca. 2023-01-03

Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)

[Diederik de Haas]

Package: svn-all-fast-export
Version: 1.0.18+git20200501-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It would be great if the latest version could be packaged for Debian.
I recently had the need to retrieve a repo from the alioth archive and
convert it to git. And this sounds like a great tool for that where
upstream has even worked on the code in the last couple of years ;-)

Anything that could make that task easier would be appreciated and a
newer version of svn-all-fast-export may just help.

Cheers,
  Diederik

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

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

Versions of packages svn-all-fast-export depends on:
ii  git   1:2.39.0-1
ii  libapr1   1.7.0-8
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libqt5core5a  5.15.8+dfsg-2
ii  libstdc++612.2.0-14
ii  libsvn1   1.14.2-4+b1

svn-all-fast-export recommends no packages.

svn-all-fast-export suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY9L73QAKCRDXblvOeH7b
btM6AQC8bi1gBYJt05Yr2ktw2pBmv7H2ppBPFcfR9VsFSmzKRAEAp+BgjVQLPkMq
yY5WjM1b0inaVc2s1SeKHWZVPp1hsQk=
=GJht
-END PGP SIGNATURE-

Bug#935175: ITP: python-pypdf4 -- PDF manipulation library

[Martin]

On 2023-01-12 10:06, Daniel Kahn Gillmor wrote:
> There was also PyPDF2, which was active up until the end of 2022, but
> its maintainer is now transitioning it to the python module name
> "pypdf", which itself is under active development.

This seems to be the most active fork, by far.
Is it already in Debian?
Or are you going to package it?

Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64

[Alexandre Rossi]

Hi,

I prepared an updated package with the new upstream version.

https://mentors.debian.net/package/libjna-java/

My commits are available at: https://salsa.debian.org/niol/libjna-java/

Thanks,

Alex

Bug#1029732: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Daniel Kahn Gillmor]

Package: src:pypdf2
Severity: wishlist
Control: affects -1 src:pypdf
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
Control: reassign -2 bookletimposer
Control: reassign -3 kraft
Control: reassign -4 krop
Control: reassign -5 odoo-14
Control: reassign -6 orangeassassin
Control: reassign -7 pdfposter
Control: reassign -8 python3-xhtml2pdf
Control: reassign -9 tryton-modules-stock-package-shipping-dpd
Control: reassign -10 diffoscope
Control: reassign -11 diffoscope-minimal
Control: block -1 by -2 -3 -4 -5 -6 -7 -8 -9 -10 -11

As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
Python module has moved to the "pypdf" namespace.

Correspondingly, there is a new python3-pypdf package in debian
unstable.

The packages listed above all currently depend on (or recommend) PyPDF2,
but probably should move to the updated version.  When all these bug
reports are closed, we can consider removing the pypdf2 source package
and python3-pypdf2 from debian.

The migration should be relatively straightforward; much of the API
remains the same, just under the "pypdf" module name instead of the
"PyPDF2" module name.  Where the API differs, the version of PyPDF2
currently in debian testing/unstable (2.12.1-3) emits a
PendingDeprecationWarning wherever a piece of the API will break.

For example:

   foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.

(PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
as it is an API break from 2.x, and pypdf 3.x supercedes it)

To transition a given package:

 - run tests with as complete coverage as possible and note the
   PendingDeprecation warnings

 - for each warning, patch the upstream line as recommended

 - ensure that the tests pass without PendingDeprecationWarnings

 - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
   python

 - update dependency indicators in upstream metadata annotations
   (e.g. pyproject.toml, setup.cfg, etc)

 - update dependency indicators in debian packaging (from python3-pypdf2
   to python3-pypdf).

 - run the tests again

Please send any upstream fixes back upstream as well, of course!

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#1029399: ncurses-bin: tic crashes on very long tc/use clauses

[Salvatore Bonaccorso]

On Sun, Jan 22, 2023 at 01:16:21PM +0100, Sven Joachim wrote:
> Package: ncurses-bin
> Version: 6.4-1
> Tags: security fixed-upstream
> Forwarded: 
> https://lists.gnu.org/archive/html/bug-ncurses/2023-01/msg00035.html
> X-Debbugs-CC: t...@security.debian.org
> 
> Running tic on the attached file triggers a stack buffer overflow:
> 
> ,
> | $ tic -I minimized-crash1
> | "minimized-crash1", line 1, col 606, terminal '0': Very long string found.  
> Missing separator?
> | "minimized-crash1", line 1, col 4098, terminal '0': Missing separator
> | *** buffer overflow detected ***: terminated
> | [1]485807 IOT instruction  tic -I minimized-crash1
> `
> 
> This has been reported upstream yesterday and was promptly addressed in
> this weekend's patchlevel.  I intend to cherry-pick the patch for
> Bookworm, maybe it could also be included in a Bullseye point release if
> older versions are affected.
> 
> The impact seems to be rather low, as the attacker needs to persuade the
> victim to run tic on crafted input, and thanks to the stack protection
> nothing worse than a crash should happen.

FWIW, this sounds good. If bullseye is affected, then a potential fix
can go in via an upcoming bullseye point release.

Regards,
Salvatore

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

El 26/01/23 a las 19:29, Cyril Brulebois escribió:
> Hi Oleg,
> 
> Oleg A. Arkhangelsky  (2023-01-26):
> > After some digging I think that there is more elegant way to stop
> > ifup@*.service when stopping (or restarting) networking.serivce, we just
> > need to add PartOf to /lib/systemd/system/ifup@.service:
> > 
> >   [Unit]
> >   ...
> >   PartOf=networking.service
> > 
> > And this ExecStart to /lib/systemd/system/networking.service, to make
> > networking.service restart workable for "allow-hotplug" interfaces (as
> > per your suggestion):
> > 
> >   [Service]
> >   ...
> >   ExecStart=/usr/bin/udevadm trigger --action=add --subsystem-match=net
> >   ...
> > 
> > This changes should be on top of *.service files, before any Bug#1029352
> > modifications, of course.
> > 
> > Seems like more clearer way, than to use /bin/sh invocation and flag file
> > for the non-first run condition check.
> > 
> > Any pitfalls for this approach?
> 
> Just to clarify: I was mostly interested in getting the initial regression
> fixed, as it was in the way of finally fixing wireless support (via /e/n/i
> rather than NM) in the installer. I tried to keep the proposed enhancement
> while making sure the regression wouldn't come back, hence the “convoluted”
> approach.
> 
> I'm happy if you folks keep digging into this to find a better solution by
> tweaking systemd units. I'll just mention that the freeze is underway, that
> a simple enhancement (making restart work) totally broke a much more
> important use case (keeping start working), and someone probably needs to
> weigh pros (getting things better, in a clean way) versus cons (not a lot of
> time to discover and track down possible side effects, be them positive or
> negative).
> 
> If things break for the installer again:
> 
> (in a deep voice) I'll be back!
> 
> ;)
> 

:-)

Just to add: I am also happy for more clean, elegant, robust, etc.
better approaches. But life is keeping me more busy than expected these
days.
Please, feel free to propose MRs that enhance also debian/tests/hotplug,
or create any other autopkgtest that could help to identify and prevent
regressions. (No guarantee that those MR could be included in bookworm.)

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1029656: Unexpected transition: libkscreen

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-01-25 23:37:33 +0100, Aurélien COUDERC wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: libkscr...@packages.debian.org, 
> pkg-kde-t...@alioth-lists.debian.net
> Control: affects -1 + src:libkscreen
> 
> Dear Release Team,
> 
> it has been raised to my attention that the libkscreen soname bump I
> recently asked to accept has caused issues with packages outside the
> Plasma package set… :-(
> This was obviously not intentional and our team members with whom I
> discussed the topic before uploading weren’t aware either.
> And the timing to discover this is particularly bad.
> 
> Of course I should have checked more thoroughly myself, but here we are.
> 
> 
> So moving forward, the following packages are affected :
> - kylin-display-switch (kylin team) => rebuilds OK
> - lxqt-config (lxqt team)   => FTBFS due to new libkscreen (#1029611)
> - ukui-control-center (kylin team)  => FTBFS due to new libkscreen (#1029612)
> - ukui-settings-daemon (kylin team) => FTBFS due to new libkscreen (#1029613)

I have added a block hint for libkscreen until the situation is resolved.
Please either revert libkscreen in unstable or help with fixing these
bugs.

Cheers
> 
> 1. LXQt
> We’ve worked with the LXQt people and could fix #1029611 with
> workarounds in libkscreen 4:5.26.90-3.
> They will also have a new upstream release right away that would let us
> drop these workarounds.
> 
> 2. Kylin
> I’ve not heard back from the Kylin maintainers yet.
> The same workarounds fixed an initial set of issues, but there are more
> code changes required to adapt to the new libkscreen API in order to fix
> #1029612 and #1029613.
> 
> 
> So again please accept my apologies and thanks in advance for your help.
> 
> 
> Ben file:
> 
> title = "libkscreen";
> is_affected = .depends ~ "libkf5screen7" | .depends ~ "libkf5screen8";
> is_good = .depends ~ "libkf5screen8";
> is_bad = .depends ~ "libkf5screen7";
> 
> 
> --
> Aurélien

-- 
Sebastian Ramacher

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Andrey Skvortsov]

Package: libglapi-mesa
Version: 22.3.3-1
Severity: important

Dear Maintainer,


after upgrade from 22.3.2-1 to 22.3.3-1 applications starts to crash
with following error

```
янв 26 23:41:00 mobian-dev dbus-daemon[1018]: [session uid=1000 pid=1018] 
Activating service name='org.gnome.Console' requested by ':1.34' (uid=1000 
pid=1250 comm="/usr/libexec/phosh")
янв 26 23:41:01 mobian-dev dbus-daemon[1018]: [session uid=1000 pid=1018] 
Successfully activated service 'org.gnome.Console'
янв 26 23:41:04 mobian-dev org.gnome.Console[6004]: DRM_IOCTL_MODE_CREATE_DUMB 
failed: Cannot allocate memory
янв 26 23:41:04 mobian-dev org.gnome.Console[6004]: DRM_IOCTL_MODE_CREATE_DUMB 
failed: Cannot allocate memory
```

The system is aarch64 (arm64) Original PinePhone running Phosh. To
trigger this problem I start and close different applications (mostly
gtk3 and gtk4) after some time (~3-5 minutes) no application can start.

Downgrade to 22.3.2-1 fixes this problem.

```
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/mesa-vdpau-drivers_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libegl-mesa0_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/mesa-va-drivers_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libglx-mesa0_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libglapi-mesa_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libgl1-mesa-dri_22.3.2-1_arm64.deb
wget 
https://snapshot.debian.org/archive/debian/20230104T030543Z/pool/main/m/mesa/libgbm1_22.3.2-1_arm64.deb
```


-- Package-specific info:
glxinfo:

DISPLAY is not set.

/usr/share/bug/xserver-xorg-core/script not available

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

Kernel: Linux 6.1-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_UNSIGNED_MODULE
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 libglapi-mesa depends on:
ii  libc6  2.36-8

libglapi-mesa recommends no packages.

libglapi-mesa suggests no packages.

-- no debconf information

Bug#1029730: src:pycryptodome: new upstream version 3.16.0 available

[Daniel Kahn Gillmor]

Package: src:pycryptodome
Version: 3.11.0+dfsg1-4
Severity: wishlist

According to
https://github.com/Legrandin/pycryptodome/blob/master/Changelog.rst,
version 3.16.0 of Cryptodome was released in November of 2022.

It would be good to have the new version in debian.

thanks for maintaining the Cryptodome module in debian!

--dkg



signature.asc
Description: PGP signature

Bug#1015888: pypi2deb: py2dsp fails with "KeyError: 'releases'"

[Antoine Beaupre]

Package: pypi2deb
Version: 3.20220721
Followup-For: Bug #1015888

This is still a problem in bookworm, and makes me wonder if this bug
should not be release-critical, as it makes the whole thing here
pretty useless...

... although if you can fetch the sdist yourself, you can still use
this to build a package, so not all is lost I guess... if anything, it
forces you to make that extra verification step. ;)

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, '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_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.22.2
ii  dh-python5.20230109
ii  python3  3.10.6-3+b1
ii  python3-aiohttp  3.8.3-1+b1
ii  python3-debian   0.1.49
ii  python3-github   1.55-3
ii  python3-jinja2   3.0.3-2
ii  python3-redis4.3.4-3

Versions of packages pypi2deb recommends:
ii  python3-msgpack  1.0.3-2

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.29.32-2
ii  pypy7.3.9+dfsg-1+b1
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
pn  python-setuptools   
ii  python3-all-dev 3.10.6-3+b1
ii  python3-nose1.3.7-9
ii  python3-pytest  7.2.1-1
ii  python3-setuptools  65.6.3-1
ii  python3-sphinx  5.3.0-3

-- debconf-show failed

Bug#1029729: texlive-lang: Should not migrate to testing for now.

[Hilmar Preusse]

Source: texlive-lang
Version: 2022.20230122-1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

TL-base & TL-extra won't migrate to testing for now, cause they break
other packages (latexml & pycirkuit). Therefore I block TL-lang too
until the other issues are sorted out.

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

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

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1029709: linux-image-6.1.0-1-amd64: failed to start Load Kernel Modules

[Rex Abert]

Might be the same issue.  I simply did an upgrade in bookworm, kernel 
was upgraded from 6.0 ->6.1.  On reboot, nvidia driver was not working.  
Noticed the message during boot:


failed to start Load Kernel Modules




On 1/26/23 12:20, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

On Thu, Jan 26, 2023 at 09:12:44AM -0500, Rex Abert wrote:

Package: src:linux
Version: 6.1.4-1
Severity: normal

Dear Maintainer,

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

* What led up to the situation?
did apt-get dist-upgrade
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
kernel modules fail to load
* What outcome did you expect instead?
loaded modules
*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-1-amd64 
root=UUID=3c762dd1-13f5-421a-b367-803c2b3028bb ro quiet

** Tainted: OE (12288)
  * externally-built ("out-of-tree") module was loaded
  * unsigned module was loaded

It's not entiely clear to me what you mean. Do you have dkms built
modules which did not get build? Which one? What are the error
messages you get? Is it the same as #1029063?

Regards,
Salvatore


--
Rex Abert
Professor of Mathematics
Tallahassee Community College

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[Andreas Beckmann]

On 26/01/2023 19.30, jim_p wrote:

As for the patches, there is no 0042 patch, neither as a file from nvidia-


Yep, 0042 is for Linux 6.2 and currently only in sid.


As for getting the -16 version from snapshot.d.o. I think it will be hard to
get all the correct packages that are derived from its source because they are
way too many! For instance, I now have 17 packages that are built from nvidia
340 sources!
Compare that to the kernels... 4 packages (image, headers, headers-common and
one more) and you will understand.


You should only need the -dkms package in version -16, everything else 
can stay at -17. Sorry I wasn't clear about that.



Andreas

Bug#986152: Offer of help

[Jeremy Sowden]

On 2023-01-26, at 20:42:16 +0100, Romain Francoise wrote:
> Now finally uploaded! (And it didn't go through NEW.)

Cool. :)

J.


signature.asc
Description: PGP signature

Bug#1027244: scikit-learn Re: Are we still trying to do scipy 1.10, given transition freeze?

[Rebecca N. Palmer]

Control: tags 1029701 fixed-upstream

Full log: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/30693526/log.gz


There appear to be at least 2 separate failures here, both known and 
probably fixed upstream.  So yes, 'new upstream version' is the first 
thing to try, but we'll need to check what _that_ breaks.


https://github.com/scikit-learn/scikit-learn/issues/23626
https://github.com/scikit-learn/scikit-learn/issues/24424

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

[Vincas Dargis]

On Thu, 26 Jan 2023 19:44:27 +0100 Romain Francoise  
wrote:

Hi,

Isn't this already tracked as #973990?


Wait a minute, why there's two bug reports? Yes, I believe the core issue 
should be in xtables.

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jelmer Vernooij]

On Thu, Jan 26, 2023 at 02:43:04PM -0500, Jeremy Bicha wrote:
> On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij  wrote:
> > It does actally support setting the Repository field, but it will verify
> > that the upstream repository looks plausible - i.e. that it has at least
> > some tags matching upstream versions. That verification is probably
> > broken for some reason.
> 
> It isn't adding the Repository field most of the time that I've been
> running it this month.

Do you happen to have a few examples handy?

Jelmer

Bug#986152: Offer of help

[Romain Francoise]

Now finally uploaded! (And it didn't go through NEW.)

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij  wrote:
> It does actally support setting the Repository field, but it will verify
> that the upstream repository looks plausible - i.e. that it has at least
> some tags matching upstream versions. That verification is probably
> broken for some reason.

It isn't adding the Repository field most of the time that I've been
running it this month.

Thank you,
Jeremy Bicha

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jelmer Vernooij]

tags 1029722 +confirmed
severity 1029722 normal
thanks

On Thu, Jan 26, 2023 at 12:32:39PM -0500, Jeremy Bicha wrote:
> The upstream-metadata-file fixer creates the Repository-Browse line
> but not the Repository line.
> 
> Recent versions of git-buildpackage support use that field. For instance:
> 
> gbp clone https://salsa.debian.org/gnome-team/gnome-console --add-upstream-vcs
> 
> For Github and Gitlab, the Repository field is the same as
> Repository-Browse but with a .git suffix.

It does actally support setting the Repository field, but it will verify
that the upstream repository looks plausible - i.e. that it has at least
some tags matching upstream versions. That verification is probably
broken for some reason.

Cheers,

Jelmer

Bug#1029727: python-debian: please depend on zstd

[Jelmer Vernooij]

On Thu, Jan 26, 2023 at 07:49:28PM +0100, Gianfranco Costamagna wrote:
> Hello, I see dh-cmake FTBFS in Ubuntu due to this:
> 
> test_run_debian_rules 
> (dhcmake.tests.cmake.DHCMakeTestCase.test_run_debian_rules) ... ok
> test_autopep8 (dhcmake.tests.source_check.SourceCheckTestCase.test_autopep8) 
> ... ok
> test_pyflakes (dhcmake.tests.source_check.SourceCheckTestCase.test_pyflakes) 
> ... ok
> 
> ==
> ERROR: test_run_debian_rules 
> (dhcmake.tests.cpack.DHCPackTestCase.test_run_debian_rules)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 121, in 
> _custom_decompress
> proc = subprocess.Popen(
>^
>   File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
> self._execute_child(args, executable, preexec_fn, close_fds,
>   File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] No such file or directory: 'unzstd'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/<>/dhcmake/tests/cpack.py", line 200, in 
> test_run_debian_rules
> packages = deb822.Packages(f.debcontrol())
>^^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 493, in 
> debcontrol
> return self.control.debcontrol()
>^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 367, in 
> debcontrol
> return Deb822(self.get_content(CONTROL_FILE))
>   ^^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 308, in 
> get_content
> f = self.get_file(
> ^^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 260, in 
> get_file
> fobj = self.tgz().extractfile(fname)
>^^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 146, in tgz
> buffer = _custom_decompress(['unzstd', '--stdout'])
>  ^^
>   File "/usr/lib/python3/dist-packages/debian/debfile.py", line 129, in 
> _custom_decompress
> raise DebError("error while running command '%s' as subprocess: '%s'" %
> debian.debfile.DebError: error while running command 'unzstd --stdout' as 
> subprocess: '[Errno 2] No such file or directory: 'unzstd''

python3-debian has zstd as a Recommends since it work fine without it
and with any package found in Debian. The ch-cmake tests pass fine here without 
zstd installed.

On Ubuntu, I believe zstd compression is the default, so it might make
sense for Ubuntu to move zstd from Recommends to Depends.

Cheers,

Jelmer

Bug#1029727: python-debian: please depend on zstd

[Gianfranco Costamagna]

Source: python-debian
Version: 0.1.49


Hello, I see dh-cmake FTBFS in Ubuntu due to this:

test_run_debian_rules 
(dhcmake.tests.cmake.DHCMakeTestCase.test_run_debian_rules) ... ok
test_autopep8 (dhcmake.tests.source_check.SourceCheckTestCase.test_autopep8) 
... ok
test_pyflakes (dhcmake.tests.source_check.SourceCheckTestCase.test_pyflakes) 
... ok

==
ERROR: test_run_debian_rules 
(dhcmake.tests.cpack.DHCPackTestCase.test_run_debian_rules)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 121, in 
_custom_decompress
proc = subprocess.Popen(
   ^
  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'unzstd'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/dhcmake/tests/cpack.py", line 200, in 
test_run_debian_rules
packages = deb822.Packages(f.debcontrol())
   ^^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 493, in 
debcontrol
return self.control.debcontrol()
   ^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 367, in 
debcontrol
return Deb822(self.get_content(CONTROL_FILE))
  ^^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 308, in 
get_content
f = self.get_file(
^^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 260, in get_file
fobj = self.tgz().extractfile(fname)
   ^^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 146, in tgz
buffer = _custom_decompress(['unzstd', '--stdout'])
 ^^
  File "/usr/lib/python3/dist-packages/debian/debfile.py", line 129, in 
_custom_decompress
raise DebError("error while running command '%s' as subprocess: '%s'" %
debian.debfile.DebError: error while running command 'unzstd --stdout' as 
subprocess: '[Errno 2] No such file or directory: 'unzstd''

--
Ran 106 tests in 53.421s

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



I think this can be fixed by depending instead of recommending zstd.

What do you think?

thanks,

Gianfranco


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

[Romain Francoise]

Hi,

Isn't this already tracked as #973990?

There is something specific to your setup because I can assure you that
Shorewall generally works in sid. Please provide more information.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1027867: (no subject)

[William Desportes]

Control: notfound 1027867 mesa/22.2.4-1


As said on 
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8007#note_1727512


Just tried 22.3.3-1 with the same backtrace & error logs. I rolled back 
to 22.2.4-1


I also rolled back to 22.2.4-1 (just the package libgl1-mesa-dri) and it 
works.


diff:

-libgl1-mesa-dri/testing,now 22.3.3-1 amd64 [installed,automatic]
+libgl1-mesa-dri/now 22.2.4-1 amd64 [installed,upgradable to: 22.3.3-1]

Bug#1029726: ruby-cfpropertylist: Injects Enumerable::Enumerator into global namespace, breaks unrelated software

[Jakob Haufe]

Package: ruby-cfpropertylist
Version: 2.2.8-1.1
Severity: serious
Tags: patch upstream
Justification: Breaks unrelated software

While the infamous "Showing diffs returns 500" problem on Debian
packaged gitlab, it was noticed that the current version of
ruby-cfpropertylist in Debian injects an Enumerable::Enumerator class
into the global namespace, thus breaking unrelated software.

It can be reproduced by:

require 'cfpropertylist'
class FakeParser
  include Enumerable
  def parse()
Enumerator.new { |x| x << :hi }
  end
end
FakeParser.new.parse.to_a

This has been fixed upstream in [1].

I would like to prepare an NMU containing:
- the unreleased changes available on salsa
- cherry-picking the fix from upstream

[1] 
https://github.com/ckruse/CFPropertyList/commit/c450984de42ded990a9edd30ce9d7ee0e5e0b103


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.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)

Versions of packages ruby-cfpropertylist depends on:
ii  ruby  1:3.1

ruby-cfpropertylist recommends no packages.

ruby-cfpropertylist suggests no packages.

-- no debconf information

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-17
Followup-For: Bug #1029681
X-Debbugs-Cc: pitsior...@outlook.com

Thank you for all that info.
Please allow me to check the -dbgsym packages and post a new strace the
following days. It is something new for me and I will probably make a mess when
trying for the first time.
As for the patches, there is no 0042 patch, neither as a file from nvidia-
legacy-340xx-kernel-dkms, nor as text inside /usr/src/nvidia-
legacy-340xx-340.108/dkms.conf, they both stop at 0041.

As for getting the -16 version from snapshot.d.o. I think it will be hard to
get all the correct packages that are derived from its source because they are
way too many! For instance, I now have 17 packages that are built from nvidia
340 sources!
Compare that to the kernels... 4 packages (image, headers, headers-common and
one more) and you will understand.


-- Package-specific info:
uname -a:
Linux mitsos 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 12.2.0 (Debian 12.2.0-13) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C [GeForce 9500 
GT] [10de:0640] (rev a1) (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. G96C [GeForce 9500 GT] [1682:2412]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.189673] Console: colour VGA+ 80x25
[0.421289] pci :01:00.0: vgaarb: setting as boot VGA device
[0.421289] pci :01:00.0: vgaarb: bridge control possible
[0.421289] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.421289] vgaarb: loaded
[0.605637] Linux agpgart interface v0.103
[3.651150] nvidia: loading out-of-tree module taints kernel.
[3.651272] nvidia: module license 'NVIDIA' taints kernel.
[3.677313] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.723917] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.725067] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.725144] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[6.414073] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Jan 26 18:15 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Jan 26 18:15 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Jan 26 18:15 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jan 26 18:15 pci-:01:00.0-card -> ../card0
video:*:44:jim

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/legacy-340xx
  link currently points to /usr/lib/nvidia/legacy-340xx
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--20-nvidia-legacy-340xx.conf is 
/etc/X11/xorg.conf.d/20-nvidia-legacy-340xx.conf
  slave nvidia--libEGL.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
  slave nvidia--libGL.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
  slave nvidia--libGLESv1_CM.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
  slave nvidia--libGLESv2.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
  slave nvidia--libglx.so is /usr/lib/nvidia/libglx.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--monitoring.conf is /usr/share/nvidia/monitoring.conf
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf
  slave nvidia--nvidia-settings is /usr/bin/nvidia-settings
  slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz
  slave nvidia--nvidia-settings.desktop is 

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Cyril Brulebois]

Hi Oleg,

Oleg A. Arkhangelsky  (2023-01-26):
> After some digging I think that there is more elegant way to stop
> ifup@*.service when stopping (or restarting) networking.serivce, we just
> need to add PartOf to /lib/systemd/system/ifup@.service:
> 
>   [Unit]
>   ...
>   PartOf=networking.service
> 
> And this ExecStart to /lib/systemd/system/networking.service, to make
> networking.service restart workable for "allow-hotplug" interfaces (as
> per your suggestion):
> 
>   [Service]
>   ...
>   ExecStart=/usr/bin/udevadm trigger --action=add --subsystem-match=net
>   ...
> 
> This changes should be on top of *.service files, before any Bug#1029352
> modifications, of course.
> 
> Seems like more clearer way, than to use /bin/sh invocation and flag file
> for the non-first run condition check.
> 
> Any pitfalls for this approach?

Just to clarify: I was mostly interested in getting the initial regression
fixed, as it was in the way of finally fixing wireless support (via /e/n/i
rather than NM) in the installer. I tried to keep the proposed enhancement
while making sure the regression wouldn't come back, hence the “convoluted”
approach.

I'm happy if you folks keep digging into this to find a better solution by
tweaking systemd units. I'll just mention that the freeze is underway, that
a simple enhancement (making restart work) totally broke a much more
important use case (keeping start working), and someone probably needs to
weigh pros (getting things better, in a clean way) versus cons (not a lot of
time to discover and track down possible side effects, be them positive or
negative).

If things break for the installer again:

(in a deep voice) I'll be back!

;)


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


signature.asc
Description: PGP signature

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[Andreas Beckmann]

On 26/01/2023 18.50, Andreas Beckmann wrote:

On 26/01/2023 18.24, jim_p wrote:
And all that happened after the upgrade to 6.1 AND the driver's update 
to the
-17 version, which the one that made it compatible with 6.1. There 
were ZERO


No patches are needed for 6.1, only for 6.2.


Nonsense, I was already a bit ahead in time...
The 6.2 patch is so far only in git. -17 *does* bring fixes for 6.1.

A significant change in -17 over -16 was the replacement of various 
(actually 8) acpi related patches backported from multiple versions with 
one backported from the last 390xx release.



list. Or just get -16 from snapshot.d.o.


You could try -16 and replace use-nv-kernel-ARCH.o_binary.patch with the 
version from -17 to get support for 6.1



Andreas

PS: I can only check that the module builds, I cannot test it.

Bug#1027851: pytorch FTBFS with Python 3.11 as default version

[Aron Xu]

Hi


On Fri, Jan 27, 2023 at 1:27 AM Andreas Tille  wrote:
>
> Hi,
>
> I was checking this bug log and realised, that the "Forwarded" field
> links to an old PR[1] that was merged long before this bug was filed.
> Checking upstream I realised that the Debian package is lagging behind
> upstream releases.
>
> Could someone please give a status update what might be the plan to get
> pytorch back into testing (either be applying the PR patch to the old
> version or upgrading to latest upstream which will most probably support
> Python 3.11).
>

The packaging work of 1.13.1[1] has started on salsa. We still have a
failure related to fmtlib before making the package build successfully
[5/1781]. Both Mo and I have limited bandwidth here and help is always
appreciated.

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

Regards,
Aron

Bug#1029725: ITP: python-pantomime -- MIME type normalisation and labels

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-pantomime
  Version : 0.5.3
  Upstream Author : Journalism Development Network, Inc. 
* URL : https://github.com/alephdata/pantomime
* License : MIT
  Programming Lang: Python
  Description : MIME type normalisation and labels

  Library that handles the parsing and normalisation of internet MIME types
  in Python. This can be useful to normalise invalid, or misformatted MIME
  types emitted by remote web servers.
 
I plan to maintain this package as part of the Python team.

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Oleg A. Arkhangelsky]

On Wed Jan 25, 2023 at 11:31 PM UTC, Pascal Hambourg wrote:

> Maybe there is a more elegant way to stop ifup@*.service, e.g. using 
> systemd unit dependencies but I am not familiar enough with this topic.
>
> This setup causes no delay when (re)starting networking.service by hand 
> at boot time or by hand. However if an interface marked "allow-hotplug" 
> was manually stopped with ifdown without stopping the associated 
> ifup@.service, it is not restarted when restarting networking.service.
>
> Any thoughts ?
>

Pascal, thank you for ideas!

After some digging I think that there is more elegant way to stop
ifup@*.service when stopping (or restarting) networking.serivce, we just
need to add PartOf to /lib/systemd/system/ifup@.service:

  [Unit]
  ...
  PartOf=networking.service

And this ExecStart to /lib/systemd/system/networking.service, to make
networking.service restart workable for "allow-hotplug" interfaces (as
per your suggestion):

  [Service]
  ...
  ExecStart=/usr/bin/udevadm trigger --action=add --subsystem-match=net
  ...

This changes should be on top of *.service files, before any Bug#1029352
modifications, of course.

Seems like more clearer way, than to use /bin/sh invocation and flag file
for the non-first run condition check.

Any pitfalls for this approach?

Bug#1029724: steam-installer: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: steam-installer
Version: 1:1.0.0.75+ds-4
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for steam-installer
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Copyright 2013 Michael Gilbert
# Copyright 2022 Simon McVittie
# Copyright 2023 Helge Kreutzmann
# SPDX-License-Identifier: MIT
#
msgid ""
msgstr ""
"Project-Id-Version: steam-installer 1:1.0.0.75+ds-4\n"
"Report-Msgid-Bugs-To: steam-instal...@packages.debian.org\n"
"POT-Creation-Date: 2022-09-16 17:15+0100\n"
"PO-Revision-Date: 2023-01-26 18:14+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../steam-installer.templates:1001
msgid "32-bit Nvidia driver (nvidia-driver-libs-i386) required"
msgstr "32-bit-Nvidia-Treiber benötigt (nvidia-driver-libs-i386)"

#. Type: note
#. Description
#: ../steam-installer.templates:1001
msgid ""
"This computer appears to be using the Nvidia binary graphics driver (the "
"nvidia-driver package)."
msgstr ""
"Dieser Rechner verwendet anscheinend den proprietären Nvidia-Graphiktreiber "
"(das Paket nvidia-driver)."

#. Type: note
#. Description
#: ../steam-installer.templates:1001
msgid ""
"Steam is a 32-bit program, so running it on this computer requires the 32-"
"bit versions of the Nvidia libraries, even if all the games you will run via "
"Steam are 64-bit. Please install the nvidia-driver-libs-i386 package."
msgstr ""
"Steam ist ein 32-bit-Programm. daher benötigt die Ausführung auf diesem "
"Computer die 32-bit-Version der Nvidia-Bibliotheken, selbst wenn alle "
"Spiele, die Sie mit Steam ausführen werden, 64 bit sind. Bitte installieren "
"Sie das Paket nvidia-driver-libs-i386."

#. Type: note
#. Description
#: ../steam-installer.templates:1001
msgid ""
"For full functionality (including Vulkan), also install the libraries listed "
"as Recommends in the nvidia-driver-libs-i386 package."
msgstr ""
"Um vollständige Funktionalität (einschließlich Vulkan) zu erhalten, "
"installieren Sie auch die als »Recommends« (Empfehlungen) im Paket nvidia-"
"driver-libs-i386 aufgeführten Bibliotheken."

#. Type: note
#. Description
#: ../steam-installer.templates:1001
msgid ""
"If you are using a legacy version of the Nvidia driver such as nvidia-"
"legacy-340xx-driver, please install the corresponding 32-bit legacy package, "
"for example nvidia-legacy-340xx-driver-libs-i386."
msgstr ""
"Falls Sie die veraltete Version des Nvidia-Treibers wie beispielsweise "
"nvidia-legacy-340xx-driver verwenden, installieren Sie bitte das "
"entsprechende veraltete 32-bit-Paket, beispielsweise nvidia-legacy-340xx-"
"driver-libs-i386."

#. Type: note
#. Description
#: ../steam-installer.templates:2001
msgid "STEAM PURGE NOTE"
msgstr "HINWEIS ZUM VOLLSTÄNDIGEN LÖSCHEN VON STEAM"

#. Type: note
#. Description
#: ../steam-installer.templates:2001
msgid ""
"Purging is not entirely complete.  Steam's working files are still located "
"in your home directories at ~/.steam.  If you intended to remove the entire "
"application, you will need to remove those directories manually."
msgstr ""
"Das vollständige Löschen ist nicht komplett. Die Arbeitsdateien von Steam "
"befinden sich weiterhin in ihrem persönlichen Verzeichnissen unter ~/.steam. "
"Falls Sie planen, die gesamte Anwendung zu entfernen, müssen Sie diese "
"Verzeichnisse manuell entfernen."

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[Andreas Beckmann]

On 26/01/2023 18.24, jim_p wrote:

we all know it is related to some gl lib not loading. Here is a coredump debug
if you want to check
https://paste.debian.net/1268410/


libc6-dbgsym, kodi-dbgsym might make the backtrace more informative.


And all that happened after the upgrade to 6.1 AND the driver's update to the
-17 version, which the one that made it compatible with 6.1. There were ZERO


No patches are needed for 6.1, only for 6.2.

The patch should have zero impact on versions before, but then again 
it's only compile tested ... The patch is made by me and not backported 
from an existing upstream release since there is no release yet 
containing corresponding fixes. (IIRC, the problematic code path is only 
present up to version 470, and there were only new 525 releases so far 
where I took the second part of the 6.2 support from - not needed for 340xx)



issues 1 month ago with 6.0, so I reinstalled 6.0 from snapshot.debian.org, but
since the driver dkms builds gets the same patches, the issues remained. If I
knew how to disable that last patch, I would give it a try, but I don't know.


In dkms.conf there is a list of patches, remove the 0042 patch from that 
list. Or just get -16 from snapshot.d.o.



Andreas

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

Thanks for your reply, Simon. It helped me realize a significant 
difference between Ubuntu and Debian with respect to desktop configuration:


While Ubuntu sets a *specific* font (Ubuntu Mono) as the default 
monospace font, Debian just sets "Monospace" and with that defers to 
fontconfig.


To summarize: I no longer think that the issue affects Debian. It seems 
to be an Ubuntu specific thing.


On 2023-01-26 15:50, Simon McVittie wrote:

Is this the patch you mean?
https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/8/diffs


Yes.


I notice that it overrules the desktop-wide user preference for the font
and font size, and sets 12pt DejaVu Sans Mono unconditionally. That
doesn't seem ideal, and in particular I could see it being an
accessibility problem for users who have difficulty reading monospaced
text at 12pt size and have configured a larger font desktop-wide.


It does so for Arabic users only. And the primary problem for those 
users is not the font size, but other gnome-terminal rendering issues.


At the same time, please note that all users of gnome-terminal, 
including the Arabic ones, can set a custom font in Preferences, and 
there also determine a font size specific for gnome-terminal.



I don't think this patch would be upstreamable,


Neither do I.


So that we can get the requirements right, is this a fair summary of the
situation?

* gnome-terminal uses the equivalent of
   `gsettings get org.gnome.desktop.interface monospace-font-name`
   as its default font.

* Upstream, GNOME has "Source Code Pro 10" as the default for that
   settings key.

* Downstream, neither Debian nor Ubuntu has Source Code Pro available, so
   we both override it. Ubuntu uses "Ubuntu Mono" at some suitable size
   (I don't know what size). Debian uses "Monospace 11".

* "Monospace" is a fontconfig alias intended to point to a generic monospace
   font, which until recently was resolved to DejaVu Sans Mono by
   fontconfig. Since the recent upgrade to fontconfig 2.14, "Monospace"
   now prefers Noto Sans Mono instead, if available.

* Both Ubuntu Mono and Noto Sans Mono are perfectly acceptable fonts for
   most uses of both Arabic and non-Arabic monospace text (e.g. in
   gedit) and are generally considered preferable to DejaVu, but as
   a result of some special properties of terminal emulation, vte-based
   terminals specifically (like gnome-terminal and gnome-console) cannot
   produce good Arabic text rendering with Ubuntu Mono or Noto Sans Mono.


Well, I no longer think that Noto Sans Mono has so much to do with it 
for monospace rendering of Arabic. See more below.



* Therefore, you want to continue to use Ubuntu Mono (on Ubuntu)
   or Noto Sans Mono (on Debian) as the default monospace font for ordinary
   text (such as in web browsers, devhelp and gedit), but you also want to
   replace those fonts with DejaVu Sans Mono for the specific use-case of
   vte-based terminal emulators running in an Arabic locale.


The Ubuntu and Ubuntu Mono fonts are not used by default for web 
browsing, but only for the Ubuntu desktop.


Besides those comments, your bullet points summarize my understanding of 
the situation.



Looking at codesearch, I see that gedit-plugins, pluma, eog-plugins,
anjuta, gnome-console, xfce4-terminal, tilix, guake and terminator also
have approximately the same behaviour as gnome-terminal for something
that looks at a glance as though it might be a vte-based terminal
emulator. Presumably we don't want to apply non-upstreamable patches to
all of those...?


That's a good point, but probably an Ubuntu only problem. At least we 
have now addressed the terminal which is currently shipped by default.



One option for avoiding this issue in Debian would be to revert the
fontconfig change that made fontconfig prefer Noto Sans Mono, which
would take it back to resolving Monospace to DejaVu Sans Mono by default,
as it did until shortly before the bookworm freeze. That wouldn't solve
anything in Ubuntu, though.


Actually I'm not sure that would be needed in Debian either. If you run:

fc-list :lang=ar | grep -i mono

you'll find that Noto fonts are absent in the resulting list. And that 
is reflected in the fontconfig behavior for an Arabic user:


$ LC_CTYPE=ar_EG.UTF-8 fc-match -s monospace | head -2
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"

So the issue may not be present in Debian at all. (Any Arabic speaking 
user who can confirm that?)



Or does the fontconfig configuration language allow locale-sensitive
font choices to be made, so that we could prefer DejaVu Sans Mono over
Noto Sans Mono, but only for Arabic locales?


Yes, indeed it does, but that would probably not be necessary either.


Another option would be to change the gnome-terminal patch so that if the
locale is Arabic *and* the default font is either "Monospace" or "Ubuntu
Mono", we replace it with "DejaVu Sans Mono" of the same size. That would

Bug#1029704: v2.2.7 from pypi works

[Andreas Pflug]

Uninstalling python3-pymssql and installing 
https://files.pythonhosted.org/packages/60/53/66a17b63555d2f6bd8734defcd017f762c5b427e4b56958eae4ad897dd74/pymssql-2.2.7-cp39-cp39-manylinux_2_24_x86_64.whl 
instead fixes the problem.

Bug#1029723: ITP: bats-file -- Helper library providing filesystem-related assertions for Bats

[Gioele Barabucci]

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

* Package name: bats-file
  Version : 0.3.0
* URL : https://github.com/bats-core/bats-file
* License : CC0
  Programming Lang: Bash
  Description : Helper library providing filesystem-related 
assertions for Bats


bats-file provides various assertions and helpers to simplify writing 
Bats tests that deal with files and filesystems.


For example:

* assert_file_contains: Check if the file content matches a regex.
* assert_file_owner: Check if a specific user owns the file.
* assert_symlink_to: Check if the file is a symlink to the target.
* temp_make: Create a temp directory for the current test in BATS_TMPDIR.

--
Gioele Barabucci

Bug#1029722: lintian-brush: upstream-metadata should add Repository line

[Jeremy Bicha]

Source: lintian-brush
Version: 0.146

The upstream-metadata-file fixer creates the Repository-Browse line
but not the Repository line.

Recent versions of git-buildpackage support use that field. For instance:

gbp clone https://salsa.debian.org/gnome-team/gnome-console --add-upstream-vcs

For Github and Gitlab, the Repository field is the same as
Repository-Browse but with a .git suffix.

Thank you,
Jeremy Bicha

Bug#854209: Interest in a patch

[Soren Stoutner]

Would you be interested in a patch to fix the false positives in this Lintian 
check?

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

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

Bug#1027851: pytorch FTBFS with Python 3.11 as default version

[Andreas Tille]

Hi,

I was checking this bug log and realised, that the "Forwarded" field
links to an old PR[1] that was merged long before this bug was filed.
Checking upstream I realised that the Debian package is lagging behind
upstream releases.

Could someone please give a status update what might be the plan to get
pytorch back into testing (either be applying the PR patch to the old
version or upgrading to latest upstream which will most probably support
Python 3.11).

I admit I do not feel good to build pytorch on my limited machines
neither do I know the potential consequences of a version upgrade.

Kind regards
   Andreas.

[1]  https://github.com/pytorch/pytorch/pull/81242

-- 
http://fam-tille.de

Bug#1008684: openvswitch-switch update leaves interfaces down

[Michael Prokop]

Hi,

with the latest upload of openvswitch v2.15.0+ds1-2+deb11u2 to
bullseye-security[1] a customer of mine, using a Proxmox Ceph cluster
(PVE 7.3) with openvswitch, got hit by a serious networking issue,
which matches this bug report.

It turned out that a service restart of the openvswitch-switch
service (actually its ovs-vswitchd.service startup underneath)
breaks the corresponding network interface by leaving it in state
DOWN and without IP address. Given that during package
installation/upgrade of the openvswitch-switch package the debhelper
magic in postinst automatically kicks in, such a package upgrade can
break a whole cluster network.

The problem was perfectly reproducible on our AMD CPU powered
cluster itself (the "fix" after the openvswitch-switch/
ovs-vswitchd.service restart was a manual startup up `ifup vmbr1`,
though still breaking the Ceph networking for some time therefore,
so not really pleasant to debug there).

At first the issue was *not* yet reproducible inside VirtualBox VMs
running on top of a Intel CPU (hosts running 5.10 kernels and
VirtualBox 6.x). On a VirtualBox VM running on top of a AMD CPU
(host running kernel 6.1.7 with VirtualBox 7.0.4) the problem could
be reproduced though. But the problem was present iff the VM used
more than one CPU.

We then could also reproduce the problem inside a VM running on top
of our PVE cluster (with CPU types "host" as well as "kvm64" but
even "qemu64"), iff more than one CPU core was assigned. But we
could *not* reproduce the problem on a PVE cluster running on top of
Intel CPUs. Anyways, the bug clearly didn't show up on *any*
single-CPU machine, though could easily be reproduced on systems
with host AMD CPU and if the VM used >=2 CPUs.

With a joint debugging effort of Florian Apolloner, Darshaka Pathirana
and myself we managed to track down the bug to
https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86

This commit was part of the v2.15.1 release and hides itself behind the
"Bug fixes" entry of https://www.openvswitch.org/releases/NEWS-2.15.1.txt

It looks like the connection state machine which got introduced by
the IDL split into two layers (see upstream git commit
1c337c43ac1c876) seems to have a concurrency/race condition that can
show up on certain multi-CPU systems.

Good news is, that with aforesaid commit applied this problem no
longer shows up. Attached is the ready-for-use patch in DEB-3 format
(fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch)
for usage via debian/patches/series on top of the current openvswitch
packaging of v2.15.0+ds1-2+deb11u2.

IMO this is a serious bug of the package present in
bullseye/bullseye-security which should be fixed through a package
update in proposed-updates and therefore the next Debian point
release of bullseye.

Therefore I'm also attaching a debdiff
(openvswitch_v2.15.0+ds1-2+deb11u3.debdiff) between
2.15.0+ds1-2+deb11u2 (current version in bullseye-security) and a
new package version meant for inclusion in bullseye (feel free to
adjust the package version if needed).

Thomas, could you please take care of the corresponding upload
towards bullseye?

[1] 
https://tracker.debian.org/news/1408998/accepted-openvswitch-2150ds1-2deb11u2-source-into-stable-security/

regards
-mika-
From: Ilya Maximets 
Subject: ovsdb-idl: Fix the database update signaling if it has never been connected
  The symptom of this issue is that OVS bridge looses its IP address on
  restart.
  .
  Simple reproducer:
   0. start ovsdb-server and ovs-vswitchd
   1. ovs-vsctl add-br br0
   2. ifconfig br0 10.0.0.1 up
   3. ovs-appctl -t ovs-vswitchd exit
   4. start ovs-vswitchd back.
  .
  After step #3 ovs-vswitchd is down, but br0 interface exists and
  has configured IP address.  After step #4 there is no IP address
  on the port br0.
  .
  What happened:
  1. ovsdb-cs connects to the database via ovsdb-idl and requests
 database lock.
 --> get_schema for _Server database
 --> lock request
  .
  2. ovsdb-cs receives schema for the _Server database.  And sends
 monitor request.
 <-- schema for _Server
 --> monitor_cond for _Server
  .
  3. ovsdb-cs receives lock reply.
 <-- locked
 At this point ovsdb-cs generates OVSDB_CS_EVENT_TYPE_LOCKED
 event and passes it to ovsdb-idl.  ovsdb-idl increases change_seqno.
  .
  4. ovsdb_idl_has_ever_connected() is 'true' now, because change_seqno
 is not zero.
  .
  5. ovs-vswitchd decides that it has connection with database and
 all the initial data, therefore initiates configuration of bridges.
 bridge_run():ovsdb_idl_has_ever_connected() --> true
  .
  6. Since monitor request for the Open_vSwitch database is not even
 sent yet, the database is empty.  This leads to removal of all the
 ports and all other resources.
  .
  7. When data finally received, ovs-vswitchd re-creates bridges and
 ports, but IP addresses can not be restored.
  .
  While 

Bug#1029709: linux-image-6.1.0-1-amd64: failed to start Load Kernel Modules

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Thu, Jan 26, 2023 at 09:12:44AM -0500, Rex Abert wrote:
> Package: src:linux
> Version: 6.1.4-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> did apt-get dist-upgrade
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> kernel modules fail to load
>* What outcome did you expect instead?
> loaded modules
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
> 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
> PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-6.1.0-1-amd64 
> root=UUID=3c762dd1-13f5-421a-b367-803c2b3028bb ro quiet
> 
> ** Tainted: OE (12288)
>  * externally-built ("out-of-tree") module was loaded
>  * unsigned module was loaded

It's not entiely clear to me what you mean. Do you have dkms built
modules which did not get build? Which one? What are the error
messages you get? Is it the same as #1029063?

Regards,
Salvatore

Bug#1029721: ITP: golang-github-nrdcg-namesilo -- Go library for accessing the Namesilo API

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-nrdcg-namesilo
  Version : 0.2.1-1
  Upstream Author : The Natural Reserve of DNS Clients in Go.
* URL : https://github.com/nrdcg/namesilo
* License : MPL-2.0
  Programming Lang: Go
  Description : Go library for accessing the Namesilo API

 namesilo is a Go client library for accessing the Namesilo API.
 .
 Example
 .
   package main
 .
   import (
"fmt"
"log"
 .
"github.com/nrdcg/namesilo"
   )
 .
   func main() {
transport, err := namesilo.NewTokenTransport("1234")
if err != nil {
log.Fatal(err)
}
 .
client := namesilo.NewClient(transport.Client())
 .
params := {
Amount:"100",
PaymentID: "acbd",
}
 .
funds, err := client.AddAccountFunds(params)
if err != nil {
log.Fatal(err)
}
 .
fmt.Println(funds)
   }


Reason for packaging:

  golang-github-nrdcg-namesilo-dev is an unpackaged dependency
  of golang-github-xenolf-lego, a Let's Encrypt client written in Go.

Bug#1027867: segfault

[William Desportes]

Control: severity -1 important


Hi,


I have the same segfault with a fresh install of Debian 12 installer.

Only checked XFCE and desktop env. No non-free drivers installed.

It segfaults Xorg. I attached the Xorg log and the installed packages list.

On a Lenovo Thinkpad P73.


Here is the backtrace:

[    23.616] (EE) Backtrace:
[    23.616] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55d2d611fcc9]
[    23.617] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
[0x7f620145af90]
[    23.617] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(nouveau_drm_screen_create+0x4406c) [0x7f61ff75999c]
[    23.617] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(nouveau_drm_screen_create+0x1e4c9) [0x7f61ff733df9]
[    23.617] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(nouveau_drm_screen_create+0x266) [0x7f61ff715b96]
[    23.617] (EE) unw_get_proc_name failed: no unwind info found [-10]
[    23.617] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) 
[0x7f61feeaaf56]
[    23.617] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(__driDriverGetExtensions_d3d12+0x60b284) [0x7f61ff4b67a4]
[    23.618] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(__driDriverGetExtensions_d3d12+0x1a93) [0x7f61feeacfb3]
[    23.618] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so 
(__driDriverGetExtensions_d3d12+0xa175) [0x7f61feeb5695]
[    23.618] (EE) 9: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_format_get_name+0xf2e) [0x7f6200ac7eae]
[    23.618] (EE) 10: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_format_get_name+0x16f8) [0x7f6200ac8678]
[    23.618] (EE) unw_get_proc_name failed: no unwind info found [-10]
[    23.618] (EE) 11: /lib/x86_64-linux-gnu/libgbm.so.1 (?+0x0) [0x7f6200ac674c]
[    23.619] (EE) 12: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_create_device+0x44) [0x7f6200ac6884]
[    23.619] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_egl_init+0x61) [0x7f6200aec3c1]
[    23.619] (EE) unw_get_proc_name failed: no unwind info found [-10]
[    23.619] (EE) 14: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) 
[0x7f6200b2c733]
[    23.619] (EE) 15: /usr/lib/xorg/Xorg (InitOutput+0xa2a) [0x55d2d5fef57a]
[    23.619] (EE) 16: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x55d2d5fb04de]
[    23.620] (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7f620144618a]
[    23.620] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7f6201446245]
[    23.620] (EE) 19: /usr/lib/xorg/Xorg (_start+0x21) [0x55d2d5f99b71]


--

William Desportes
[23.458] 
X.Org X Server 1.21.1.6
X Protocol Version 11, Revision 0
[23.458] Current Operating System: Linux williamdes 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64
[23.458] Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=UUID=6bb89b1d-4b43-4a90-b4ce-797c56ee68ad ro quiet
[23.458] xorg-server 2:21.1.6-1 (https://www.debian.org/support) 
[23.458] Current version of pixman: 0.42.2
[23.458] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[23.458] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[23.458] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 26 17:49:37 2023
[23.459] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[23.459] (==) No Layout section.  Using the first Screen section.
[23.459] (==) No screen section available. Using defaults.
[23.459] (**) |-->Screen "Default Screen Section" (0)
[23.459] (**) |   |-->Monitor ""
[23.459] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[23.459] (==) Automatically adding devices
[23.459] (==) Automatically enabling devices
[23.459] (==) Automatically adding GPU devices
[23.459] (==) Automatically binding GPU devices
[23.459] (==) Max clients allowed: 256, resource mask: 0x1f
[23.459] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[23.459] 	Entry deleted from font path.
[23.459] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[23.459] (==) ModulePath set to "/usr/lib/xorg/modules"
[23.459] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[23.459] (II) Loader magic: 0x55d2d61abf00
[23.459] (II) Module ABI versions:
[23.459] 	X.Org ANSI C Emulation: 0.4
[23.459] 	X.Org Video Driver: 25.2
[23.459] 	X.Org XInput driver : 24.4
[23.459] 	X.Org Server Extension : 10.0
[23.459] (--) using VT number 2

[23.459] (II) systemd-logind: logind integration 

Bug#1029704: Test result with docker images

[Andreas Pflug]

Testing against docker images gives the same error. Tested:

python:3.9.1-slim-bullseye
python:3.10.9-slim-bullseye
python:3.11.1-slim-bullseye

Bug#1027244: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Thu, Jan 26, 2023 at 05:45:58PM +0100 schrieb Drew Parsons:
> > Any solution for this one?
> 
> Probably just needs updating to the latest release.  They fixed some things.
 
Latest release is building in my local git.  I'll report about issues
if I might meet some.  Otherwise I'll also upload to experimental.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Bug#1024361: lintian: complains about bpo version when package built with salsa-CI/pipeline (+salsaci)

[Andreas Beckmann]

Followup-For: Bug #1024361
Control: found -1 2.116.0

salsa has worked around your fix ;-)

https://salsa.debian.org/salsa-ci-team/pipeline/-/commit/b0d375957e4a24cd67675baaecfcc79b45549fff
changed the suffix from +salsaci to +salsaci+${DATESTAMP}+${CI_PIPELINE_IID}
e.g. https://salsa.debian.org/nvidia-team/bbswitch/-/jobs/3856494
E: bbswitch changes: backports-upload-has-incorrect-version-number 
0.8-13~bpo11+1+salsaci+20221228+6 bullseye-backports

Please update the regex in lintian to e.g.
  if ($version=~ /~bpo(\d+)\+(\d+)(\+salsaci(\+\d+)*)?$/)


Andreas

Bug#803633: britney-tests-live-data/live-2012-05-09 fails randomly

[Paul Gevers]

Hi,

On Sun, 01 Nov 2015 10:42:49 +0100 Emilio Pozuelo Monfort 
 wrote:

If run in a loop, live-2012-05-09 will eventually fail with:

AssertionError: NUNINST OUT OF SYNC

The problem is with hurd-i386 (fucked/break arch in this test) and I've
seen problems such as:

E: [Sun Nov  1 10:31:41 2015] -  hurd-i386 - invalid nuninst: {'tar'}

and:

E: [Sun Nov  1 09:41:45 2015] -  hurd-i386 - unnoticed nuninst: {'libtinfo5', 
'libtinfo-dev'}


Currently I'm seeing it also/instead being unreproducible.

With updated references I have in two different runs:

Added binary packages:
  debianutils 4.3+b1 hurd-i386
  tar 1.26-4 hurd-i386
Removed binary packages:
  dash 0.5.7-3+b1 hurd-i386
  diffutils 1:3.2-6 hurd-i386
  gzip 1.4-5 hurd-i386

And:

Added binary packages:
  debianutils 4.3+b1 hurd-i386
  tar 1.26-4 hurd-i386
Removed binary packages:
  diffutils 1:3.2-6 hurd-i386

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027244: Are we still trying to do scipy 1.10, given transition freeze?

[Drew Parsons]

On 2023-01-26 16:56, Andreas Tille wrote:

Am Thu, Jan 26, 2023 at 04:51:25PM +0100 schrieb Drew Parsons:


Thanks Andrea.  armel has revealed which tests it needs skipped, so 
I'll

push scipy 1.10 to unstable after scipy 1.8.1-22 is done migrating to
testing


I just notice that bug #1029701 of scikit-learn might be a show stoper.

Any solution for this one?


Probably just needs updating to the latest release.  They fixed some 
things.

Bug#1028608: evdi-dkms: EVDI module does not build with linux-headers-6.0.0-6-amd64

[Miroslav Maiksnar]

Dne čtvrtek 26. ledna 2023 16:18:33 CET, Miroslav Maiksnar napsal(a):
> Dne pátek 20. ledna 2023 18:50:26 CET jste napsal(a):
> > Control: tag -1 unreproducible
> > Control: severity -1 normal
> > 
> > Hi,
> > 
> > On Fri, 13 Jan 2023 16:16:12 +0100 Miroslav Maiksnar
> > 
> >  wrote:
> > > Error! Bad return status for module build on kernel: 6.0.0-6-amd64
> > > (x86_64)
> > 
> > I cannot reproduce that with the Linux 6.1 kernel currently in sid.
> 
> I had same problem even with 6.1 kernel. Probably some dependencies, I'll
> try to investigate this more. I have trouble installing virtualbox right
> now though, so it may take bit more time.

I investigated this more and I noticed some weird behavior (at least for me, as 
I don't have much knowledge regarding DKMS).

Problem is, that evdi module is actually build twice in different ways which I 
didn't notice before.

First time it is built when setting up kernel image and it works just fine:


/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-1-amd64:Sign command: 
/usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 -C /lib/modules/6.1.0-1-amd64/build 
M=/var/lib/dkms/evdi/1.12.0+dfsg/build DKMS_BUILD=1
Signing module /var/lib/dkms/evdi/1.12.0+dfsg/build/evdi.ko
Cleaning build area...

evdi.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/6.1.0-1-amd64/updates/dkms/
depmod...


Second time it is built when setting up kernel headers and it fails:


/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-1-amd64:Sign command: 
/usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all 
INCLUDEDIR=/lib/modules/6.1.0-1-amd64/build/include KVERSION=6.1.0-1-amd64 
DKMS_BUILD=1...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
Consult /var/lib/dkms/evdi/1.12.0/build/make.log for more information.
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.1.0-1-amd64.postinst line 11.
dpkg: chyba při zpracovávání balíku linux-headers-6.1.0-1-amd64 (--configure):
 installed linux-headers-6.1.0-1-amd64 package post-installation script 
subprocess returned error exit status 1


What did seem weird to me is different make command for building the module:

make -j8 KERNELRELEASE=6.1.0-1-amd64 -C /lib/modules/6.1.0-1-amd64/build 
M=/var/lib/dkms/evdi/1.12.0+dfsg/build DKMS_BUILD=1

vs. failed:

make -j8 KERNELRELEASE=6.1.0-1-amd64 all 
INCLUDEDIR=/lib/modules/6.1.0-1-amd64/build/include KVERSION=6.1.0-1-amd64 
DKMS_BUILD=1


I tested it on clean Debian Bookworm installation and upgrading to sid kernel 
went just fine. Module was compiled only first time and during kernel headers 
setup dkms printed only message about auto installation service.
So I guess some time during occasional bookworm updating my system got broken.

I'll close this bug now, as it is apparently relevant only to my (broken) setup.
Mixi

Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'

[Holger Levsen]

Package: monitoring-plugins-contrib
Version: 37.20211217
Severity: normal
x-debbugs-cc: mat...@debian.org

Dear Maintainer,

on a system running bookworm and the latest amd64 kernel 
/usr/lib/nagios/plugins/check_running_kernel warns me that the running kernel 
doesnt
match the on-disk kernel, while it *is* running the latest kernel.
(line breaks added for better readability.)

holger@osuosl168-amd64:~ $ uname -a
Linux osuosl168-amd64 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 
(2023-01-07) x86_64 GNU/Linux

holger@osuosl168-amd64:~ $ /usr/lib/nagios/plugins/check_running_kernel 
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) != Linux version 6.1.0-1-amd64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.39.90.20221231) # SMP PREEMPT_DYNAMIC Debian 6.1.4-1 
(2023-01-07)]

holger@osuosl168-amd64:~ 2s 1 $ dpkg -l linux-image*|grep ^ii
ii  linux-image-6.0.0-6-amd646.0.12-1 amd64Linux 6.0 
for 64-bit PCs (signed)
ii  linux-image-6.1.0-1-amd646.1.4-1  amd64Linux 6.1 
for 64-bit PCs (signed)
ii  linux-image-amd646.1.4-1  amd64Linux for 
64-bit PCs (meta-package)

holger@osuosl168-amd64:~ $ dpkg -l monitoring-plugins-contrib
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---
ii  monitoring-plugins-contrib 37.20211217  amd64Plugins for nagios 
compatible monitoring systems

holger@osuosl168-amd64:~ $ 


-- 
cheers,
Holger

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

»Sieh, dass du Mensch bleibst. Mensch sein ist von allem die Hauptsache.
Und das heißt fest und klar und heiter sein, ja heiter, trotz alledem.«
(Rosa Luxemburg)


signature.asc
Description: PGP signature

Bug#1029719: ITP: libwfa2 -- exact gap-affine algorithm

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libwfa2 -- exact gap-affine algorithm
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libwfa2
  Version : 2.3.1
  Upstream Author : Santiago Marco-Sola 
* URL : https://github.com/smarco/WFA2-lib
* License : MIT
  Programming Lang: C
  Description : exact gap-affine algorithm
 The wavefront alignment (WFA) algorithm is an exact gap-affine algorithm
 that takes advantage of homologous regions between the sequences to
 accelerate the alignment process. Unlike to traditional dynamic
 programming algorithms that run in quadratic time, the WFA runs in time
 O(ns+s^2), proportional to the sequence length n and the alignment score
 s, using O(s^2) memory (or O(s) using the ultralow/BiWFA mode).
 Moreover, the WFA algorithm exhibits simple computational patterns that
 the modern compilers can automatically vectorize for different
 architectures without adapting the code. To intuitively illustrate why
 the WFA algorithm is so interesting, look at the following figure. The
 left panel shows the cells computed by a classical dynamic programming
 based algorithm (like Smith-Waterman or Needleman Wunsch). In contrast,
 the right panel shows the cells computed by the WFA algorithm to obtain
 the same result (i.e., the optimal alignment).

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

Bug#1029622: tuxguitar-alsa fails to install

[Adrian Bunk]

On Thu, Jan 26, 2023 at 07:14:50AM -0800, tony mancill wrote:
>...
> This is similar to my original proposal for 1029476, except I was merely
> switching all of the arch-all packages to arch-any.  I can confirm that
> that approach builds correctly and the package installs and can be
> upgraded.  It has the disadvantage of using more space on the mirrors
> and also a bit more time on the buildd machines, since the arch-all bits
> are duplicated.

Mirror space should not be a worry anymore (that was different in the 1990s),
I remember that something needed fixing when we had the first file > 2 GB
(some .orig.gz) in our archive a few years ago.

Regarding buildd time, you might never have heard about the acl2 
package - except if you are looking at buildd.debian.org a lot since
this is a package that takes literally a week to build on some buildds.

Developer time is usually the most scarce resource in Debian.

> The advantage to your proposal of a single package is that it would also
> resolve the build issue, be be a bit simpler for users, and also make it
> easier for us to add new modules, since the package wouldn't have to go
> back through the NEW queue.  The disadvantage would be the same in terms
> of space, but more importantly that installing tuxguitar would require
> installing the transitive dependencies of all of the plugins.  I assume
> they are all co-installable, but I can imagine bug reports from ALSA or
> OSS users not wanting to have to install jack libraries.
>...

I would be worried if a plugin does weird things by default if installed.

FFmpeg already pulls in jack libraries, Debian is not a distribution 
that tries hard to reduce the number of unused libraries on a system.

> Cheers,
> tony

cu
Adrian

Bug#993612: [PATCH] of/address: Return an error when no valid dma-ranges are found

[Mark Brown]

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
---
 drivers/of/address.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c34ac33b7338..21342223b8e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -975,10 +975,12 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
+   ret = -EINVAL;
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
@@ -992,6 +994,7 @@ int of_dma_get_range(struct device_node *np, const struct 
bus_dma_region **map)
r->size = range.size;
r->offset = range.cpu_addr - range.bus_addr;
r++;
+   ret = 0;
}
 out:
of_node_put(node);

---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230126-synquacer-boot-243bd1b87f64

Best regards,
-- 
Mark Brown 

Bug#1028434: kodi: FTBFS in bullseye (fatal error: date/tz.h: No such file or directory)

[Santiago Vila]

Hello.

Thanks for taking care of this.

I'd like to emphasize that this is most probably a Makefile bug (or whatever
is the proper name when using cmake), maybe a missing dependency somewhere.

I discovered it by building all packages in bullseye using virtual
machines with a single CPU, and the fact that the build seems to
work with 2 CPUs is what makes me think that it's a Makefile bug.

If you need to reproduce it, you can use GRUB_CMDLINE_LINUX="nr_cpus=1"
in /etc/default/grub and most probably the build failure will happen.
(And, in case it would not, my offer to provide a virtual machine where it
happens still holds).

Thanks.

Bug#1029718: pydevd: Please update test exclusions for big-endian targets

[John Paul Adrian Glaubitz]

Source: pydevd
Version: 2.9.5+ds-2
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

The attached patch updates the exclusion lists for 32-bit and 64-bit
big-endian targets. For example, on ppc64 and sparc64, the test failures
are exactly the same as on s390x which is also 64-bit big-endian.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- pydevd2/pydevd-2.9.5+ds/debian/get_test_exclusions  2023-01-03 
10:28:48.0 -0800
+++ pydevd/pydevd-2.9.5+ds/debian/get_test_exclusions   2023-01-26 
08:15:12.142579087 -0800
@@ -91,8 +91,24 @@
 tests_python/test_debugger_json.py::test_function_breakpoints_async
 )
 
-# s390x fails even more disastrously
-if [ $arch = s390x ]
+# 32-bit big-endian targets test exclusion list
+if [ $arch = hppa -o $arch = m68k -o $arch = powerpc ]
+then
+   EXCLUDES+=(
+   tests_python/test_debugger.py::test_gevent
+   tests_python/test_debugger.py::test_gevent_remote
+   tests_python/test_debugger_json.py::test_wait_for_attach_gevent
+   
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[True]
+   
tests_python/test_debugger_json.py::test_gevent_show_paused_greenlets[False]
+   
tests_python/test_debugger_json.py::test_gevent_subprocess_not_python
+   tests_python/test_debugger_json.py::test_gevent_subprocess_python
+   tests_python/test_debugger_json.py::test_notify_gevent
+   tests_python/test_utilities.py::test_gevent_notify
+   )
+fi
+
+# 64-bit big-endian targets test exclusion list
+if [ $arch = ppc64 -o $arch = s390x -o $arch = sparc64 ]
 then
EXCLUDES+=(
 tests_python/test_debugger.py::test_case_13

Bug#1029717: calcoo: segmentation error - XPM not supported

[Nicola]

Package: calcoo
Version: 1.3.18-8
Severity: important

Dear Maintainer,

Calcoo doesn't load.

nicola@lenovo:~$ calcoo

(calcoo:512775): GdkPixbuf-WARNING **: 17:19:55.965: Error loading XPM image
loader: Il tipo di immagine «xpm» non è supportato

(calcoo:512775): GdkPixbuf-WARNING **: 17:19:55.966: Error loading XPM image
loader: Il tipo di immagine «xpm» non è supportato
Errore di segmentazione


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 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 calcoo depends on:
ii  libc6   2.36-8
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.74.4-1
ii  libgtk2.0-0 2.24.33-2

calcoo recommends no packages.

calcoo suggests no packages.

-- no debconf information

Bug#1011121: Ubuntu has a patch

[Nathan Teodosio]

Just a heads up that Ubuntu has had the patch (attached for convenience) 
for some months already[1].


[1]: https://launchpad.net/bugs/1958267OpenSSL: Drop security level to 0 with OpenSSL 3.0 when using TLS 1.0/1.1

Commit 9afb68b03976 ("OpenSSL: Allow systemwide secpolicy overrides for
TLS version") with commit 58bbcfa31b18 ("OpenSSL: Update security level
drop for TLS 1.0/1.1 with OpenSSL 3.0") allow this workaround to be
enabled with an explicit network configuration parameter. However, the
default settings are still allowing TLS 1.0 and 1.1 to be negotiated
just to see them fail immediately when using OpenSSL 3.0. This is not
exactly helpful especially when the OpenSSL error message for this
particular case is "internal error" which does not really say anything
about the reason for the error.

It is is a bit inconvenient to update the security policy for this
particular issue based on the negotiated TLS version since that happens
in the middle of processing for the first message from the server.
However, this can be done by using the debug callback for printing out
the received TLS messages during processing.

Drop the OpenSSL security level to 0 if that is the only option to
continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed
in wpa_supplicant default configuration and OpenSSL 3.0 with the
constraint on MD5-SHA1 use.

Signed-off-by: Jouni Malinen 
---
 src/crypto/tls_openssl.c | 9 +
 1 file changed, 9 insertions(+)

Index: wpa-2.10/src/crypto/tls_openssl.c
===
--- wpa-2.10.orig/src/crypto/tls_openssl.c
+++ wpa-2.10/src/crypto/tls_openssl.c
@@ -1516,6 +1516,15 @@ static void tls_msg_cb(int write_p, int
 	struct tls_connection *conn = arg;
 	const u8 *pos = buf;
 
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+	if ((SSL_version(ssl) == TLS1_VERSION ||
+	 SSL_version(ssl) == TLS1_1_VERSION) &&
+	SSL_get_security_level(ssl) > 0) {
+		wpa_printf(MSG_DEBUG,
+			   "OpenSSL: Drop security level to 0 to allow TLS 1.0/1.1 use of MD5-SHA1 signature algorithm");
+		SSL_set_security_level(ssl, 0);
+	}
+#endif /* OpenSSL version >= 3.0 */
 	if (write_p == 2) {
 		wpa_printf(MSG_DEBUG,
 			   "OpenSSL: session ver=0x%x content_type=%d",