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

[Håvard F . Aasen]

On 27.03.2023 13:17, Graham Inggs wrote:
> Control: tags -1 + confirmed
> 
> Hi Håvard
> 
> On Sun, 26 Mar 2023 at 22:18, Håvard F. Aasen  wrote:
>> The fix is for making the package cross-buildable, not sure what more
>> to tell you.
> 
> I was hoping for some motivation as to why we needed this fix now
> during the freeze, but not to worry, Helmut has already convinced me.
> 
> I have confirmed that building ghostscript with and without your patch
> produces identical binary packages.
> 

Thanks.
The package has been uploaded.

Regards,
Håvard

Bug#1033672: otf2: FTBFS on riscv64 because it needs libatomic

[Steve Langasek]

Package: otf2
Followup-For: Bug #1033672
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Listen, I swear to you, I build-tested an earlier version of the patch
injecting -latomic into LDFLAGS in a riscv64 qemu instance and I saw it
work; but now that just fails to build on Launchpad and in my qemu for the
logical reason that ldflags come before source files on the commandline and
therefore -latomic is being discarded by the linker before it has a chance
to know it needs it.

So I'm touching m4 after all.  Here's a minimal patch which I've
build-tested locally and is expected to work on riscv64 autobuilds too.  You
can see build results at:

  https://launchpad.net/ubuntu/+source/otf2/3.0.2-1ubuntu3
diff -Nru otf2-3.0.2/debian/patches/series otf2-3.0.2/debian/patches/series
--- otf2-3.0.2/debian/patches/series2022-12-18 10:24:27.0 -0800
+++ otf2-3.0.2/debian/patches/series2023-03-29 19:26:32.0 -0700
@@ -1,3 +1,4 @@
 rename
 reproducible
 instruction_set
+use-libatomic.patch
diff -Nru otf2-3.0.2/debian/patches/use-libatomic.patch 
otf2-3.0.2/debian/patches/use-libatomic.patch
--- otf2-3.0.2/debian/patches/use-libatomic.patch   1969-12-31 
16:00:00.0 -0800
+++ otf2-3.0.2/debian/patches/use-libatomic.patch   2023-03-29 
19:32:07.0 -0700
@@ -0,0 +1,23 @@
+Description: check for libatomic and if present, pass it to the linker
+ gcc atomics detection fails on riscv64 because on this arch, they are
+ provided by libatomic which must be explicitly passed to the linker.
+ Check for libatomic, and unconditionally add it to libs if present.
+ This is safe on all Debian archs because our linker will discard the
+ dependency automatically if it's unneeded.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1033672
+Last-Update: 2023-03-29
+Forwarded: no
+
+Index: otf2-3.0.2/build-config/common/m4/afs_gcc_atomic_builtins.m4
+===
+--- otf2-3.0.2.orig/build-config/common/m4/afs_gcc_atomic_builtins.m4
 otf2-3.0.2/build-config/common/m4/afs_gcc_atomic_builtins.m4
+@@ -67,6 +67,7 @@
+ AC_REQUIRE([AX_ASM_INLINE])
+ AC_MSG_CHECKING([for gcc atomic builtins])
+ AC_LANG_PUSH([C])
++AC_CHECK_LIB([atomic], [exit])
+ AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM(
+ [[#include "${srcdir}/../common/utils/src/atomic/UTILS_Atomic.inc.c"]],

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Dima Kogan]

Hi. Thank you both for replying.


Tim Bell  writes:

> Just to confirm - you were not able to configure the USB Drive for EFI
> boot?

Correct. For whatever reason this wasn't possible in this BIOS, at least
not in any way I could figure out. Possibly I created the install media
incorrectly? I downloaded this:

  debian-bookworm-DI-alpha2-amd64-netinst.iso

from here:

  https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/

and I wrote that .iso to /dev/sde. There was no obvious "usb image", but
just using the CD image appeared to work. I could boot and run the
installer, at least with UEFI turned off.



Cyril Brulebois  writes:

> For the avoidance of doubt: which one? Alpha 1 or Alpha 2.
> Also, which image did you use?

Alpha 2. The link is above.


>> This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA.
>
> You have not given a single detail about that machine.

I'm trying to give relevant detail. This is a Dell Latitude 5420 rugged.
What else do you want to know?


>> I'm installing from a USB drive. To make this work, I had to turn off
>> secure-boot and UEFI in the BIOS.
>
> Why did you need that in the first place? How did you put the
> installation image onto that USB drive?

See above. Even if I didn't do this properly, installing an unbootable
OS is not very nice.


> In a nutshell, BIOS means MBR, UEFI means GPT. (This is a very gross
> oversimplification though.)

OK. Sorry, I managed to be blissfully ignorant for decades, and this is
the first time I'm touching GPT or UEFI. So I'm not well-versed in this
at all.


> I'm not sure why the firmware would allow running an installer in BIOS
> mode and not boot off from the installed system… in BIOS mode too.

You would expect the Debian installer to write an MBR partition and then
you would expect the machine (running with UEFI disabled) to be able to
use this MBR partition? I would expect this too, I think.

I'm reading Dell's notes a bit. This suggests that PICe SSD devices are
UEFI-only:

  
https://www.dell.com/support/kbdoc/en-us/000132410/what-are-pcie-ssds-and-how-to-use-them-as-a-boot-drive-for-a-dell-pc

This makes me think that installing to an MBR on the SSD on this machine
is never correct. It also makes me think that creating my install media
in a way that would make UEFI boot with it would have avoided this. But
this failure mode isn't great. Can we detect these UEFI-only drives in
any way? Can I ask the installer create a GPT instead of an MBR somehow?

Thanks

Bug#1031188: linux: synaptics speed/sensitivity messed up with 6.1.0-4

[Salvatore Bonaccorso]

Hi Christoph,

On Sat, Feb 18, 2023 at 01:35:07AM +0100, Christoph Anton Mitterer wrote:
> Hey Salvatore.
> 
> On Wed, 2023-02-15 at 07:12 +0100, Salvatore Bonaccorso wrote:
> > Just to be sure, that I understood you correctly. That is if on the
> > current system with the issue you roll back just only the kernel back
> > to 6.1.8-1, then the issue dissaper? 
> 
> Exactly, and the roll back even only in the sense of just booting the
> previous one (I do not even reinstall packages or so).
> 
> 
> > If this is the case, would you be testing as well directly 6.1.8 and
> > 6.1.11 upstream (please do as well 6.1.12, 6.1.12-1 though just
> > uploaded to unstable earlier today), and if reproducible, bisect the
> > changes between the two versions to find the introducing bad commit?
> 
> I've tested 6.1.12 in the meantime, ... still has the problem.
> 
> In fact it seems as if any changes I make with the synclient tool to
> the relevant settings e.g.:
> $ synclient MinSpeed=0.5 MaxSpeed=1.5 AccelFactor=0.5
> have no longer any effect at all.
> 
> Even if I set extreme values, nothing seems to change.
> 
> 
> I've also taken the src:linux package (as of 6.1.12) recompiled it just
> with:
> 6816478c0db15ad0dbe7f9b6ffaff9ad6db5e74d
> reverted.
> That seemed the most promising one, despite me NOT having an HP
> notebook (which that commit is allegedly about, but rather a Fujitsu).
> 
> But no change with that.

May you with 6.1.20-1 which should soon reach testing as well? Is the
issue still present?

> If you want me to test 6.1.8/12 upstream... is it enough to simply take
> the Debian source packages and unapply any Debian patches?
> I'm always quite reluctant of taking any code which I cannot properly
> verify myself (and I don't trust github or https enough ;-) )

Well if at some point we need to bisect, you have to go to upstream
git. The tags are signed by Greg, and you find a copy of his key as
well in the Debian source in debian/upstream/signing-key.asc . 

So if 6.1.20 ist still affected, if this is possible for you,
bisecting it between the versions can help us pin point the
introducing commit and report it upstream.

Regards,
Salvatore

Bug#1033684: File /usr/lib/x86_64-linux-gnu/libltdl.la is missing from libltdl-dev package in Bullseye

[Djun Kim]

Package: libltdl-dev
Version: 2.4.6-15

The file /usr/lib/x86_64-linux-gnu/libltdl.la is not present in the Bullseye 
version of this package, although it can be found in version 2.4.6-9 (Buster).
Is there a reason this file is omitted in the newer package?

Bug#1033683: unblock: libitext-java/2.1.7-14

[tony mancill]

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

Please unblock package libitext-java

[ Reason ]
src:libitext-java 2.1.7-14 no longer builds binary libitext-rups-java,
which resolves Debian 1033170. The package is low-popcon, completely
nonfunctional and severely out of date.  Upstream is on version 7.

libitext-java is a relatively high-popcon package.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033170
https://tracker.debian.org/pkg/libitext-java

[ Impact ]
bookworm will release with a broken, albeit very low popcon package.
Otherwise, there is no impact.

[ Tests ]
Not applicable - no changes to libitext-java or libitext-rtf-java.

[ Risks ]
libitext-rups-java is a leaf.  There are no r-deps or build r-deps.

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

[ Other info ]
I am assuming that the unblock should be granted before filing the rm
bug.  Let me know if it should be the other way around.

Thank you!
tony

unblock libitext-java/2.1.7-14
diff -Nru libitext-java-2.1.7/debian/changelog 
libitext-java-2.1.7/debian/changelog
--- libitext-java-2.1.7/debian/changelog2022-05-03 13:18:43.0 
-0700
+++ libitext-java-2.1.7/debian/changelog2023-03-22 19:59:21.0 
-0700
@@ -1,3 +1,10 @@
+libitext-java (2.1.7-14) unstable; urgency=medium
+
+  * Team upload.
+  * Remove libitext-rups-java binary package (Closes: #1033170)
+
+ -- tony mancill   Wed, 22 Mar 2023 19:59:21 -0700
+
 libitext-java (2.1.7-13) unstable; urgency=medium
 
   * Replaced the calls to the deprecated constructors of the primitive wrappers
diff -Nru libitext-java-2.1.7/debian/control libitext-java-2.1.7/debian/control
--- libitext-java-2.1.7/debian/control  2022-05-03 13:18:43.0 -0700
+++ libitext-java-2.1.7/debian/control  2023-03-22 19:59:21.0 -0700
@@ -38,10 +38,3 @@
 Description: Java Library to create and manipulate RTF files on the fly
  iText RTF is a library that allows you to generate RTF files on the fly in
  a similar fashion to iText itself.
-
-Package: libitext-rups-java
-Architecture: all
-Depends: libitext-java (= ${binary:Version}), ${misc:Depends}, ${java:Depends}
-Description: graphical tool for Reading and Updating PDF Syntax (RUPS)
- iText RUPS provides a GUI for visualizing PDF files and investigating their
- internal structure.
diff -Nru libitext-java-2.1.7/debian/libitext-java.poms 
libitext-java-2.1.7/debian/libitext-java.poms
--- libitext-java-2.1.7/debian/libitext-java.poms   2022-05-03 
13:18:43.0 -0700
+++ libitext-java-2.1.7/debian/libitext-java.poms   2023-03-22 
19:59:21.0 -0700
@@ -27,4 +27,3 @@
 #
 ant/pom.xml --has-package-version --java-lib -e2.1.7 
--package=libitext-java  --artifact=lib/iText.jar
 debian/pom-rtf.xml  --has-package-version --java-lib -e2.1.7 
--package=libitext-rtf-java  --artifact=lib/iText-rtf.jar
-debian/pom-rups.xml --has-package-version --java-lib -e2.1.7 
--package=libitext-rups-java --artifact=lib/iText-rups.jar
diff -Nru libitext-java-2.1.7/debian/libitext-rups-java.classpath 
libitext-java-2.1.7/debian/libitext-rups-java.classpath
--- libitext-java-2.1.7/debian/libitext-rups-java.classpath 2022-05-03 
13:18:43.0 -0700
+++ libitext-java-2.1.7/debian/libitext-rups-java.classpath 1969-12-31 
16:00:00.0 -0800
@@ -1 +0,0 @@
-usr/share/java/itext-rups.jar /usr/share/java/itext.jar
diff -Nru libitext-java-2.1.7/debian/pom-rups.xml 
libitext-java-2.1.7/debian/pom-rups.xml
--- libitext-java-2.1.7/debian/pom-rups.xml 2022-05-03 13:18:43.0 
-0700
+++ libitext-java-2.1.7/debian/pom-rups.xml 1969-12-31 16:00:00.0 
-0800
@@ -1,102 +0,0 @@
-
-http://maven.apache.org/POM/4.0.0;
-   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
-   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;>
-   4.0.0
-   com.lowagie
-   itext-rups
-   jar
-   iText, a Free Java-PDF library (rups package)
-   2.1.7
-   iText, a free Java-PDF library (rups package)
-   http://www.lowagie.com/iText/
-   
-   
-   iText Questions
-   
-   
http://lists.sourceforge.net/lists/listinfo/itext-questions
-   
-   itext-questi...@lists.sourceforge.net
-   
-   
http://news.gmane.org/gmane.comp.java.lib.itext.general
-   
-   
-   
http://www.nabble.com/iText---General-f2701.html
-   
http://www.junlu.com/2.html
-   

Bug#1033682: unblock tomboy-ng: 0.36a

[David Bannon]

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


Please unblock package tomboy-ng v0.36a

[ Reason ]
Poor testing on my part lead to the use of bad colors for dark
themes with version 0.36 currently in Bookworm. This relates to
tomboy-ng's recent move to using Qt5 instead of gtk2 and,
perhaps, my own person preference to not use dark themes.
V0.36a is now uploaded and my sponsor requested I apply for an
unblock.

[ Impact ]
As several users of the version currently in Testing have advised
me, with some dark themes, the existing version might display
some text with the same color as the background. Not good.

[ Tests ]
I have personally tested the proposed new version, 0.36a extensively.
Similarly, some testing by end users has also taken place.

[ Risks ]
All changes relate to text colors. No other application logic
has changed.
As no package depends on tomboy-ng, effects beyond tomboy-ng approach
zero. In every case identified, the 0.36a delivers the same or better
user experience.

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

[ Other info ]
Attached is a debdiff between 0.36 and 0.36a, quite a lot of its
content relates to the Lazarus IDE's making inconsequential of
changes to po and form files. Of significance is changes to
man pages (better description of how to manage it's Qt5 colors)
and editbox.pas where the means of determining appropriate
colors has been changed. Changes to settings.pas to inform user
of non-standard colors and save preferences.
Some related minor change to loadnote.pas and mainform.pas

Thanks for your consideration, David Bannon

unblock tomboy-ng 0.36a


diff -Nru tomboy-ng-0.36/debian/changelog tomboy-ng-0.36a/debian/changelog
--- tomboy-ng-0.36/debian/changelog 2023-02-22 20:45:26.0 +1100
+++ tomboy-ng-0.36a/debian/changelog2023-03-19 10:08:23.0 +1100
@@ -1,19 +1,12 @@
-tomboy-ng (0.36-1) unstable; urgency=medium
+tomboy-ng (0.36a-1) unstable; urgency=medium
 
-  *  Release of new version
-  * From 0.35 to 0.36 -
-  * New Feature export as PDF.
-  * New Feature insert a symbol or accented character.
-  * Bug fix in column mode of calculator.
-  * Warn user about setting non mono font.
-  * All Tomdroid functionality removed.
-  * A fix for SWYT not finding some text in a brand new note.
-  * Can set colour of a link, more suitable default.
-  * Use of TextHint to better indicate EditSearch role.
-  * Revised note button colors for better dark theme use.
-  * Please see github for further change details
+  *  Release of new version.
+  * More uniform colors when used with qt5ct.
+  * Man page added info re colors.
+  * Indicator that custom colors being used.
+  * Please see github for further change details.
 
- -- David Bannon   Wed, 22 Feb 2023 20:45:26 +1100
+ -- David Bannon   Sun, 19 Mar 2023 10:08:23 +1100
 
 tomboy-ng (0.35-2) unstable; urgency=medium
 
diff -Nru tomboy-ng-0.36/doc/tomboy-ng.1 tomboy-ng-0.36a/doc/tomboy-ng.1
--- tomboy-ng-0.36/doc/tomboy-ng.1  2023-02-22 20:42:59.0 +1100
+++ tomboy-ng-0.36a/doc/tomboy-ng.1 2023-03-19 10:01:36.0 +1100
@@ -11,7 +11,7 @@
 tomboy\-ng \- manage a collection of notes using a simple GUI markup
 
 .SH SYNOPSIS
-tomboy\-ng  [\-h \-\-help] [\-\-debug\-sync]  [\-\-debug\-index] 
[\-\-debug\-log=LOGFILE] [\-l \-\-lang=CC] [\-\-config\-dir=PATH_to_DIR] [\-o 
PATH_to_NOTE] [\-\-open\-note=PATH_to_NOTE] [PATH_to_NOTE] [\-t 
\-\-import\-txt=PATH_to_FILE] [\-m \-\-import\-md=PATH_to_FILE] [\-n 
\-\-import\-note=PATH_to_NOTE] [\-\-title\-fname]
+tomboy\-ng  [\-h \-\-help] [\-\-dark\-theme] [\-\-debug\-sync]  
[\-\-debug\-index] [\-\-debug\-log=LOGFILE] [\-l \-\-lang=CC] 
[\-\-config\-dir=PATH_to_DIR] [\-o PATH_to_NOTE] [\-\-open\-note=PATH_to_NOTE] 
[PATH_to_NOTE] [\-t \-\-import\-txt=PATH_to_FILE] [\-m 
\-\-import\-md=PATH_to_FILE] [\-n \-\-import\-note=PATH_to_NOTE] 
[\-\-title\-fname]
 
 .SH DESCRIPTION
 tomboy\-ng is a rewrite of the much loved Tomboy Notes. It runs on Linux, 
Windows and MacOS.  It  is  file  compatible  with  Tomdroid  and  GNote 
(>=v0.30).  Tomboy\-ng notes support Bold, Italic, Strikethrough, Highlight and 
Underline in four sizes. It will sync notes with other systems using Tomboy's 
File Sync model and to remote servers using sshfs. It will Sync with a Github 
account, either all your notes or just ones in the SyncGithub notebook. You can 
edit notes, from almost any device with a browser in markdown format.
@@ -24,6 +24,20 @@
 
 While options below are familiar to Linux users, Mac and Windows users may 
like to look at some examples further down to see how to use them.
 
+.SH DARK THEME
+The GTK2 version follows the system colour theme. However, the Qt5 version (eg 
Bookworm and later) requires some instruction from the user. Using the 
\-\-dark\-theme is simplest 

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Antoine Beaupré]

On 2023-03-28 00:13:46, Francesco Poli wrote:
> On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:
[...]
>> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
>> is a workaround for the aforementioned throttling, to revert would mean to 
>> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
>> utilize yt-dlp with the default quality option.
>> 
>> If we weren't so close to the freeze I'd say the right option would be to 
>> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
>> an option anymore either.
>
> Why not?
>
> The [freeze policy] states that, even in full freeze, fixes for
> important bugs are appropriate, as long as they can be done via unstable
> (as it is currently the case for mpv).
>
> [freeze policy]: 
>
> I have just filed bug [#1033595], in order to request that the patches
> you cited are applied to mpv.
>
> [#1033595]: 
>
> I hope this can be the way to go.

Considering that a bug was filed against mpv, shouldn't this one be
downgraded? I don't quite see why yt-dlp should be kicked out of
bookworm because mpv didn't catchup...

a.
-- 
Never believe that a few caring people can't change the world. For,
indeed, that's all who ever have.
- Margaret Mead

Bug#1033681: ffmpeg: All executables fail to start with "Bus Error"

[Shai Berger]

Package: ffmpeg
Version: 7:5.1.2-3
Severity: important

Dear Maintainer,

I have not used ffmpeg in a while, so I cannot say how new this is,
but, as the title says, today, if I try to run ffmpgeg, ffprobe or
ffplay, even with just the '-version' flag, I get the same response:

$ ffmpeg -version
Bus error

This happens only on this one system. I have another system which
is also a Debian Testing, and there things do work.

I have tried to debug this, but to no avail:

$ gdb /usr/bin/ffmpeg 
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
[...]
This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from 
/home/shai/.cache/debuginfod_client/7215fbfbcdbd6cfa01fc6d11f68e6cd32e232637/debuginfo...

 
(gdb) r -version

   
Starting program: /usr/bin/ffmpeg -version
Downloading separate debug info for /lib64/ld-linux-x86-64.so.2
Downloading separate debug info for system-supplied DSO at 0x77fc9000   

   


   
Program received signal SIGBUS, Bus error.
0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) where
#0  0x77fd93c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x77fe8c09 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x77fe519f in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x77fe6b1c in ?? () from /lib64/ld-linux-x86-64.so.2
#4  0x77fe59c8 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x0002 in ?? ()
#6  0x7fffe16d in ?? ()
#7  0x7fffe17d in ?? ()
#8  0x in ?? ()
(gdb) 


I've also tried running the same with a user which never used
ffmpeg before, to account for some settings if relevant. Same.

I am at a loss on how to debug this further.

Thanks in advance for your attention and help,

   Shai.
   

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

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

Versions of packages ffmpeg depends on:
ii  libavcodec597:5.1.2-3
ii  libavdevice59   7:5.1.2-3
ii  libavfilter87:5.1.2-3
ii  libavformat59   7:5.1.2-3
ii  libavutil57 7:5.1.2-3
ii  libc6   2.36-8
ii  libpostproc56   7:5.1.2-3
ii  libsdl2-2.0-0   2.26.4+dfsg-1
ii  libswresample4  7:5.1.2-3
ii  libswscale6 7:5.1.2-3

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Dominic Hargreaves]

On Mon, Mar 20, 2023 at 11:06:49PM +0100, Sebastian Ramacher wrote:
> Hi Dominic
> 
> On 2023-02-27 15:50:05 +, Dominic Hargreaves wrote:
> > On Thu, Feb 23, 2023 at 04:54:33PM +0100, Paul Gevers wrote:
> > > Control: tags -1 moreinfo
> > > 
> > > Hi,
> > > 
> > > On 20-02-2023 13:09, Dominic Hargreaves wrote:
> > > > If the release team would be willing to grant an exception to the policy
> > > > to get this done, we can get this wrapped up inside a week I expect.
> > > 
> > > Can you please confirm that everything is ready to do this? I.e. there is 
> > > no
> > > "this should work but we haven't tested it" cases. If yes, then please
> > > upload the packages that involve new binaries to experimental and when 
> > > those
> > > are passed NEW, ping this bug. If no surprises pop up, we'll grant an
> > > exception, but we want everything fully ready before doing so.
> > 
> > Thanks, yep. We had planned out this transition and I feel confident
> > the rest of it will work out (worst case we need to drop a barely
> > used extension package somewhere).
> > 
> > Andrew and I are working on this at the moment and will ping this bug
> > when it's fully staged.
> 
> What's the status of this transition?

Hi Sebastian

Sorry for the long delay. Myself and, I think, Andrew have been short on time.

The transition is basically ready to go, but I've been rethinking the need
to drop request-tracker4, given it will all be quite tight. It turns out that
request-tracker4 is still supported upstream 
(https://bestpractical.com/release-policy)
and there's no specific EoL set. When we first started the plan to
deprecate request-tracker4 in Debian, I think we were assuming otherwise.
The package is in good shape and I believe otherwise ready to be released.

If Andrew is in agreement, I therefore think we should let request-tracker4
be released with the next release. We can reconsider whether to drop it from
the release + 1 at a more leisurely pace. The work we've done to date will not
be wasted effort.

I've tentatively downgraded #1030749 to signal this intent.

Cheers
Dominic

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Cyril Brulebois]

Control: severity -1 normal

Hi Dima,

Dima Kogan  (2023-03-29):
> Hi. I just installed a bookworm candidate. This worked OK through
> partitioning and reboot, but I cannot boot into the system.

For the avoidance of doubt: which one? Alpha 1 or Alpha 2.

Also, which image did you use?

> This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA.

You have not given a single detail about that machine.

> I'm installing from a USB drive. To make this work, I had to turn off
> secure-boot and UEFI in the BIOS.

Why did you need that in the first place? How did you put the
installation image onto that USB drive?

> I believe that the result of this is the Debian partitioner defaulted
> to an MBR partition, not a GPT partition.
> 
> The BIOS of this laptop only allows booting from the PCIe SSD in UEFI
> mode (so I need to change the BIOS setting before even trying). But
> even after that, the machine doesn't let me boot off that disk. Some
> searching tells me this is because GPT partitions are required for
> UEFI booting, but Debian made an MBR partition.

In a nutshell, BIOS means MBR, UEFI means GPT. (This is a very gross
oversimplification though.)

I'm not sure why the firmware would allow running an installer in BIOS
mode and not boot off from the installed system… in BIOS mode too.


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


signature.asc
Description: PGP signature

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Tim Bell]

On 3/29/2023 6:21 PM, Dima Kogan wrote:

Package: installation-reports
Severity: grave

Hi. I just installed a bookworm candidate. This worked OK through
partitioning and reboot, but I cannot boot into the system.

This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA.

I'm installing from a USB drive. To make this work, I had to turn off
secure-boot and UEFI in the BIOS. I believe that the result of this is
the Debian partitioner defaulted to an MBR partition, not a GPT
partition.

The BIOS of this laptop only allows booting from the PCIe SSD in UEFI
mode (so I need to change the BIOS setting before even trying). But even
after that, the machine doesn't let me boot off that disk. Some
searching tells me this is because GPT partitions are required for UEFI
booting, but Debian made an MBR partition.

I'm not 100% sure of the exact cause. But I suspect strongly is that
booting the install media without UEFI broke installing to an UEFI-only
disk.

Thanks.

Just to confirm - you were not able to configure the USB Drive for EFI boot?

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Bug#1033680: linux: Consider enabling CONFIG_ANON_VMA_NAME=y

[Mike Gerow]

Source: linux
Version: 6.1.15-1
Severity: wishlist
X-Debbugs-Cc: ge...@google.com
X-Debbugs-Cc: jko...@google.com

Recent Ubuntu kernels support this. It's useful for analyzing memory
usage for applications in addition to other things.

Bug#1033679: hw-detect/check-missing-firmware: add fallback module lookup by modalias and firmware

[Pascal Hambourg]

Package: src:hw-detect
Version: 1.155
Tags: patch

Dear maintainer,
Please find attached 3 patches adding fallback module detection when 
dmesg does not provide the actual module name and device driver symlink 
is missing. I tried to keep them as clear, short and little invasive as 
possible in order to ease review and avoid regressions.
Tested with p54usb (follow-up to bug #1032377). Tested for non 
regression with b43.


===

* 0001 check-missing-firmware: add function get_module_by_bus_address

Call this function for bus types other than usb and mhi. It looks up:
- module name
- driver name
- sysfs modalias
- udevadm modalias
in order and returns whichever exists or matches first.

===

* 0002 check-missing-firmware: call get_module_by_bus_address for usb 
devices too


So modalias lookup can be used with usb devices when no driver is found
(e.g. p54usb).

===

* 0003 check-missing-firmware: add module lookup by firmware file

Scan all loaded modules for the requested firmware file as fallback if 
the detected module is a bus name or is not a loaded driver or module name.From dba86861a56abfbca0f6c760262326ce2c511707 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Thu, 30 Mar 2023 00:19:42 +0200
Subject: [PATCH 1/3] check-missing-firmware: add function
 get_module_by_bus_address

Call this function for bus types other than usb and mhi. It looks up:
- /driver/module
- /driver
- /modalias
- udevadm  modalias
in order, and returns whichever exists or matches first.
---
 check-missing-firmware.sh | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 5db0e180..c5356f27 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -21,6 +21,44 @@ log_output() {
 	log-output -t check-missing-firmware "$@"
 }
 
+get_module_by_bus_address () {
+	local bus=$1
+	local address=$2
+	local device="/sys/bus/$bus/devices/$address"
+	local modalias=
+
+	# return associated module name if it exists
+	if [ -e "$device"/driver/module ]; then
+		basename $(readlink "$device"/driver/module)
+		return
+	fi
+	# else return associated driver name if it exists
+	log "no module found for $bus $address, looking up driver"
+	if [ -e "$device"/driver ]; then
+		basename $(readlink "$device"/driver)
+		return
+	fi
+	log "no driver found for $bus $address, looking up modalias"
+	# else lookup module by modalias if it exists
+	# warning: requires kmod, busybox modprobe does not support --resolve-alias
+	if [ -e "$device"/modalias ]; then
+		modalias="$(cat "$device"/modalias)"
+	else
+		# modalias may not exist in sysfs but only in udev, so also query udevadm
+		log "no modalias found for $bus $address in sysfs, looking up udevadm"
+		modalias="$(udevadm info --query=property $device | grep "^MODALIAS=" | sed 's/^MODALIAS=//')"
+	fi
+	if [ -n "$modalias" ]; then
+		modprobe --resolve-alias "$modalias" 2>/dev/null && return
+		log "no module matching modalias found for $bus $address"
+	else
+		log "no modalias found for $bus $address"
+	fi
+	log "failed to perform $bus $address lookup"
+	log "=> sticking with the $bus module"
+	echo "$bus"
+}
+
 # USB is special, and we don't want to take it all done:
 get_usb_module() {
 	address="$1"
@@ -166,6 +204,13 @@ check_missing () {
 		module=$(get_mhi_holders)
 		log "using $module instead of mhi"
 		;;
+		*)
+		# other bus types
+		if [ -e /sys/bus/"$module" ]; then
+			bus="$module"
+			module=$(get_module_by_bus_address "$bus" "$address")
+		fi
+		;;
 	esac
 
 	# ignore specific files:
-- 
2.30.2

From b2b56617e9008a74c97d0576bb75a6e5857c800c Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Thu, 30 Mar 2023 00:36:01 +0200
Subject: [PATCH 2/3] check-missing-firmware: call get_module_by_bus_address
 for usb devices too

So modalias lookup can be tried with usb devices when no driver is found
(e.g. p54usb).
---
 check-missing-firmware.sh | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index c5356f27..2d2414d8 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -77,9 +77,7 @@ get_usb_module() {
 	# Make sure driver resolution returns something:
 	driver=$(basename $(readlink "$subdirs/driver") 2>/dev/null)
 	if [ "$driver" = "" ]; then
-		log "failed to perform usb $address lookup (no driver found)"
-		log "=> sticking with the usb module"
-		echo 'usb'
+		get_module_by_bus_address "usb" "$(basename $subdirs)"
 		return
 	fi
 	echo $driver
-- 
2.30.2

From e4b6a9061061c638d6169562dece6f151901353c Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Thu, 30 Mar 2023 00:51:37 +0200
Subject: [PATCH 3/3] check-missing-firmware: add module lookup by firmware
 file

Scan all loaded modules for the requested firmware file as fallback if the detected
module is a bus name or is not a loaded driver nor module name.
---
 

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

[Dima Kogan]

Package: installation-reports
Severity: grave

Hi. I just installed a bookworm candidate. This worked OK through
partitioning and reboot, but I cannot boot into the system.

This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA.

I'm installing from a USB drive. To make this work, I had to turn off
secure-boot and UEFI in the BIOS. I believe that the result of this is
the Debian partitioner defaulted to an MBR partition, not a GPT
partition.

The BIOS of this laptop only allows booting from the PCIe SSD in UEFI
mode (so I need to change the BIOS setting before even trying). But even
after that, the machine doesn't let me boot off that disk. Some
searching tells me this is because GPT partitions are required for UEFI
booting, but Debian made an MBR partition.

I'm not 100% sure of the exact cause. But I suspect strongly is that
booting the install media without UEFI broke installing to an UEFI-only
disk.

Thanks.

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2023-03-29 14:25:23 -0300, Antonio Terceiro wrote:
> From what I can tell, the only dependency of apt-listbugs that calls
> \.default on anything is ruby-soap4r:
> 
> /usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/factory.rb
> 344-  return nil
> 345-end
> 346:if !obj.default.nil? or
> 347-(obj.respond_to?(:default_proc) and obj.default_proc)
> 348-  return nil
> 
> /usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/rubytypeFactory.rb
> 114-param.add("item", elem)
> 115-  end
> 116:  param.add('default', Mapping._obj2soap(obj.default, map))
> 117-  addiv2soapattr(param, obj, map)
> 118-when ::Regexp
> --
> 300-  end
> 301-  if node.key?('default')
> 302:obj.default = Mapping._soap2obj(node['default'], map)
> 303-  end
> 304-when TYPE_REGEXP
> 
> One think that could be happening is that soap4r is being fooled into
> opening local files and that is triggered by some (corrupt?) response
> from the server.

But
* How could it get the filenames?
* Would that yield an error message prepended with "E: "?

> If anyone can still see this bug, it would be nice to configure
> apt-listbugs in debug mode, e.g. setting
> 
> DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};
> 
> in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option), so
> that when it happens we have a trace of the requests/reponses.

Is it possible to redirect (only) the debug data to a file?
Otherwise that's too invasive.

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

Bug#934813: gajim: GPG agent option cannot be enabled

[Martin]

Control: close -1 1.1.3-1

Fixed by upstream.

Bug#1033176: linux: Future Android/Waydroid support

[Diederik de Haas]

On Wednesday, 29 March 2023 22:59:13 CEST Diederik de Haas wrote:
> Control: reopen -1
> 
> On Tuesday, 21 March 2023 14:21:05 CEST Debian Bug Tracking System wrote:
> > > In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream'
> > > for recommendations on which/how/what kernel modules to enable.
> > 
> > In https://git.kernel.org/linus/9e18d0c82f0c07f2a41898d4adbb698a953403ee
> > the default value of BINDER_DEVICES was changed to
> > "binder,hwbinder,vndbinder" whereas the Debian kernel only has "binder".
> > Also in other places they use the 3 values, but I haven't been able to
> > find out *why*.
> > As I wouldn't be able to make the argument to change it to something else
> > and the most important thing is to enable ANDROID_BINDER_IPC, which is
> > already the case, there's no need to keep this bug open.
> > 
> > If someone *can* substantiate why and how things should be changed, they
> > should file a bug report (themselves) making the case.
> 
> Just received an (unexpected) extra response, which DOES answer the Q I had:
> 
> "BINDER_DEVICES defines which binder device names should appear in /dev.
> Different android versions required different devices to be available: the
> latest android version uses "binder,hwbinder,vndbinder" meaning /dev/binder,
> / dev/hwbinder, /dev/vndbinder.
> At some point Google realized that it's inconvenient to have this change at
> compile time, so they introduced BINDERFS: you can mount a filesystem of
> type binder somewhere and use IOCTLs on it to allocate new device names.
> 
> So if you use BINDERFS it doesn't matter which value of BINDER_DEVICES you
> set because you can add (or remove) devices at runtime. In this case
> BINDER_DEVICES is just the set of initial devices present in the root of a
> binderfs.
> 
> For mainline linux, BINDERFS is heavily recomended. Waydroid will use it to
> create all the binder devices it needs. You can leave BINDER_DEVICES empty
> or unchanged or whatever you prefer."
> 
> I don't really understand how or what `ioctl`s are, but I'm pretty sure
> others do and can now make an informed choice if and how things could be
> improved. I'm pretty sure that'll be for Trixie, which has the nice benefit
> that it can be extensively tested.

Possibly unintentional, but another reply came in with a valid point AFAICT:

"That caught me by surprise because I knew Waydroid worked on bullseye 
already, and it has the same CONFIGs.
Then I finally realized... When you compile binder as a module (rather than 
built-in), when inserting the module you can provide the binder device names 
you want in the module parameters! So in this case 
`CONFIG_BINDER_DEVICES="binder"` is not a limitation."

Is this an intended feature or a security concern?

The patch description which turned the module from a `bool` into a `tristate` 
explicitly mentioned security as a reason so that the module would ONLY be 
loaded when needed, instead of always for everyone ... for security reasons.


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

Bug#1033524: Simplify the instructions for making bootable media

[Holger Wansing]

Hi,

Steve McIntyre  wrote (Sun, 26 Mar 2023 23:54:37 +0100):
> On Mon, Mar 27, 2023 at 12:52:41AM +0200, Chris Hofstaedtler wrote:
> >* Steve McIntyre :
> >> We should definitely also kill section 4.4.2: Loadlin is *dead* -
> >> *nobody* has DOS any more.
> >
> >Section 5.1.4. "Booting from DOS using loadlin" should also go, I
> >guess.
> 
> Yup, good call.

A patch is attached to:
- simplify instructions for making bootable USB media
- remove mentions of mini.iso
- remove mentions of loadlin


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/build/entities/installation-images.ent b/build/entities/installation-images.ent
index 02c102845..b23590d4f 100644
--- a/build/entities/installation-images.ent
+++ b/build/entities/installation-images.ent
@@ -13,6 +13,7 @@ url="images/hd-media/initrd.gz">hd-media/initrd.gz
   hd-media/vmlinuz'>
 
+
   mini.iso'>
 
diff --git a/build/templates/docstruct.ent b/build/templates/docstruct.ent
index 8ef8fb2af..1a434e588 100644
--- a/build/templates/docstruct.ent
+++ b/build/templates/docstruct.ent
@@ -55,8 +55,6 @@
 
 
   
-   
-   
 
   
 
diff --git a/en/boot-installer/graphical.xml b/en/boot-installer/graphical.xml
index 2d0987c42..d71cd6185 100644
--- a/en/boot-installer/graphical.xml
+++ b/en/boot-installer/graphical.xml
@@ -33,16 +33,7 @@ still be used from the boot prompt which is shown after selecting the
 
 
 
-There is also a graphical installer image that can be netbooted. And there
-is a special mini ISO image
-
-
-The mini ISO image can be downloaded from a  mirror as described
-in .
-Look for netboot/gtk/mini.iso.
-
-
-, which is mainly useful for testing.
+There is also a graphical installer image that can be netbooted.
 
 
 
diff --git a/en/boot-installer/x86.xml b/en/boot-installer/x86.xml
index 9761ebbc0..fbc2b0275 100644
--- a/en/boot-installer/x86.xml
+++ b/en/boot-installer/x86.xml
@@ -51,46 +51,6 @@ After the program has been started, a few preliminary questions will be
 asked and the system will be prepared to reboot into the 
 installer.
 
-
-  
-
-  
-  Booting from DOS using loadlin
-
-
-Boot into DOS (not Windows).  To do this, you can for instance boot from a
-recovery or diagnostic disk.
-
-
-
-If you can access the installation CD, change the current drive to the CD-ROM
-drive, e.g.
-
-
-d:
-
-
-else make sure you have first prepared your hard disk as explained in
-, and change the current drive to it if needed.
-
-
-
-Enter the subdirectory for the flavor you chose, e.g.,
-
-
-cd \
-
-
-If you prefer using the graphical installer, enter the gtk
-sub-directory.
-
-
-cd gtk
-
-
-Next, execute install.bat.
-The kernel will load and launch the installer system.
-
 
   
 
diff --git a/en/install-methods/boot-drive-files.xml b/en/install-methods/boot-drive-files.xml
index 59741e5a6..8d5242a26 100644
--- a/en/install-methods/boot-drive-files.xml
+++ b/en/install-methods/boot-drive-files.xml
@@ -96,35 +96,6 @@ and install from the installation image, without needing the network.
 Finally, to configure the bootloader proceed to
 .
 
-
-  
-
-
-  
-  Hard disk installer booting from DOS using loadlin
-
-
-This section explains how to prepare your hard drive for booting the installer
-from DOS using loadlin.
-
-
-
-Copy the following directories from a  installation image to c:\.
-
-
-
-
-/ (kernel binary and ramdisk image)
-
-
-
-
-/tools (loadlin tool)
-
-
-
-
-
 
   
 
diff --git a/en/install-methods/boot-usb-files.xml b/en/install-methods/boot-usb-files.xml
index 9815ac2eb..c9bc8e986 100644
--- a/en/install-methods/boot-usb-files.xml
+++ b/en/install-methods/boot-usb-files.xml
@@ -42,13 +42,6 @@ on your USB stick. See
 
 
 
-Alternatively, 
-for very small USB sticks, only a few megabytes in size, you can download
-the  image from the netboot
-directory (at the location mentioned in ).
-
-
-
 The installation image you choose should be written directly to the USB stick,
 overwriting its current contents. For example, when using an existing
 GNU/Linux system, the image file can be written to a USB stick
@@ -59,6 +52,11 @@ as follows, after having made sure that the stick is unmounted:
 # sync
 
 
+Simply writing the installation image to USB like this should work fine
+for most users.
+
+
+
 Information about how to do this on other operating systems can be found in
 the Debian CD FAQ.
 
@@ -68,145 +66,8 @@ The image must be written to the whole-disk device and not a
 partition, e.g. /dev/sdb and not /dev/sdb1.
 Do not use tools like unetbootin which alter the image.
 
-
-
-Simply writing the installation image to USB like this should work fine
-for most users. The other options below are more complex, mainly for
-people with specialised needs.
-
 
 
-
-
-The hybrid image on the stick does not occupy all the storage space, so
-it may be worth considering using the free space to hold firmware files
-or packages or any other files of your choice. This could be useful if
-you have only one 

Bug#988948: CVE-2019-11939

[Moritz Mühlenhoff]

Am Tue, Mar 28, 2023 at 09:29:57PM +0200 schrieb Salvatore Bonaccorso:
> Hi László,
> 
> On Sun, Mar 26, 2023 at 04:13:01PM +0200, László Böszörményi wrote:
> > Hi,
> > 
> > On Fri, Mar 17, 2023 at 7:54 PM László Böszörményi (GCS)  
> > wrote:
> > > On Thu, Mar 16, 2023 at 11:15 PM Moritz Mühlenhoff  
> > > wrote:
> > > > Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff:
> > > > > CVE-2019-11939:
> > > > > https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757
> > > > is this fixed in Bookworm?
> > >  I let the Security Team decide how this should be treated. I will try
> > > to describe it in full and short.
> >  Friendly ping, how the Security Team sees this issue. I've provided
> > insights [1] and tend to think it's safe for Bullseye and later.

Sorry for the late reply, currently mostly offline.

> Strictly speaking if the code base diverged, CVE-2019-11939 would be
> for facebook's fbthrift only. If Apache thrift has a similar issue,
> which is my understanding of the THRIFT-5322 then it would need a own
> CVE, which does not seem to exist (In some cases a CVE might be used
> by multiple projects even if the code base is not the same).
> 
> I'm leaning to mark CVE-2019-11939 as NFU for facebook fbthrift
> specifically, and let alone the Apache Thrift issues for similar case.
> Given the issue would be no-dsa for bullseye and fixed in bookworm I
> would not do anything particular unless a CVE get assigned.
> 
> Moritz, do you agree?

I agree, let's mark it as NFU: Facebook fbthrift and not track Apache
Thrift/src:thrift specifically here.

Cheers,
Moritz

Bug#863603: bluez: a2dp not working

[Flávio Amieiro]

Package: bluez
Version: 5.66-1
Followup-For: Bug #863603
X-Debbugs-Cc: flavio.amie...@gmail.com

Dear Maintainer,

After an update in testing a few weeks ago (I'm sorry, I can't remember
exaclty the date) A2DP stopped working completely on my system. All my
bluetooth speakers/headsets connect properly, but a2dp audio profiles are
not available (for example, blueman's "audio profile" context menu doesn't
even show submenu).

I tried both workarounds described in [1] for the previously mentioned
#805414, but none of them worked. Also, this worked fine up until a couple
of weeks ago.

The only way I am able to send audio to the speakers is if I explicitly set
the profile with aplay (`aplay -D bluealsa:PROFILE=a2dp 
/usr/share/sounds/alsa/Front_Left.wav`),
which switches the audio output to the speakers after some time.  This does
not work for speaker-tests, though (`speaker-test -D bluealsa:PROFILE=a2dp`).


If you need any more information, please let me know and I will post it.


Thank you very much.

Best regards,
Flávio Amieiro



[1]: 
https://wiki.debian.org/BluetoothUser/a2dp#Refused_to_switch_profile_to_a2dp_sink:_Not_connected


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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 bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  init-system-helpers 1.65.2
ii  kmod30+20221128-1
ii  libasound2  1.2.8-1+b1
ii  libc6   2.36-8
ii  libdbus-1-3 1.14.6-1
ii  libdw1  0.188-2.1
ii  libglib2.0-02.74.6-1
ii  libreadline88.2-1.3
ii  libudev1252.6-1
ii  lsb-base11.6
ii  sysvinit-utils [lsb-base]   3.06-2
ii  udev252.6-1

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- no debconf information

Bug#1033674: unblock: linux/6.1.20-1

[Cyril Brulebois]

Salvatore Bonaccorso  (2023-03-29):
> Thus please unblock the current version to testing (and age it
> accordingly).
> 
> unblock linux/6.1.20-1

ACK on the unblock/age-days 10 request for the d-i team, happy to build
the installer against it. :)
 

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


signature.asc
Description: PGP signature

Bug#1033676: unblock: xen/4.17.0+74-g3eac216e6e-1 (pre-approval)

[Maximilian Engelhardt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: x...@packages.debian.org, m...@daemonizer.de, 
t...@security.debian.org
Control: affects -1 + src:xen

Please approve an upload of xen to unstable and later unblock package
xen. See the "Other info" section below on why this is a pre-approval
request.

[ Reason ]
Xen in bookworm (and unstable) is currently affected by CVE-2022-42331,
CVE-2022-42332, CVE-2022-42333 and CVE-2022-42334 (see #1033297).

[ Impact ]
The above mentioned CVEs are not fixed.

[ Tests ]
The Debian package is based only on upstream commits that have passed
the upstream automated tests.
The Debian package has been successfully tested by the xen packaging
team on their test machines.

[ Risks ]
There could be upstream changes unrelated to the above mentioned
security fixes that cause regressions. However upstream has an automated
testing machinery (osstest) that only allows a commit in the upstream
stable branch if all test pass.

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

[ Other info ]
This security fix is based on the latest upstream stable-4.17 branch.
The branch in general only accepts bug fixes and does not allow new
features, so the changes there are mainly security and other bug fixes.
This does not exactly follow the "only targeted fixes" release policy,
so we are asking for a pre-approval.
The package we have prepared is exactly what we would have done as a
security update in a stable release, what we have historically done
together with the security team and are planning to continue to do.
As upstream does extensive automated testing on their stable branches
chances for unnoticed regressions are low. We believe this way the risk
for bugs is lower than trying to manually pick and adjust patches
without all the deep knowledge that upstream has. This approach is
similar to what the linux package is doing.

unblock xen/4.17.0+74-g3eac216e6e-1

Thanksdiff -Nru xen-4.17.0+46-gaaf74a532c/debian/changelog xen-4.17.0+74-g3eac216e6e/debian/changelog
--- xen-4.17.0+46-gaaf74a532c/debian/changelog	2023-02-24 18:06:42.0 +0100
+++ xen-4.17.0+74-g3eac216e6e/debian/changelog	2023-03-23 22:22:48.0 +0100
@@ -1,3 +1,16 @@
+xen (4.17.0+74-g3eac216e6e-1) unstable; urgency=medium
+
+  * Update to new upstream version 4.17.0+74-g3eac216e6e, which also contains
+security fixes for the following issues: (Closes: #1033297)
+- x86 shadow plus log-dirty mode use-after-free
+  XSA-427 CVE-2022-42332
+- x86/HVM pinned cache attributes mis-handling
+  XSA-428 CVE-2022-42333 CVE-2022-42334
+- x86: speculative vulnerability in 32bit SYSCALL path
+  XSA-429 CVE-2022-42331
+
+ -- Maximilian Engelhardt   Thu, 23 Mar 2023 22:22:48 +0100
+
 xen (4.17.0+46-gaaf74a532c-1) unstable; urgency=medium
 
   * Update to new upstream version 4.17.0+46-gaaf74a532c, which also contains
diff -Nru xen-4.17.0+46-gaaf74a532c/docs/misc/xen-command-line.pandoc xen-4.17.0+74-g3eac216e6e/docs/misc/xen-command-line.pandoc
--- xen-4.17.0+46-gaaf74a532c/docs/misc/xen-command-line.pandoc	2023-02-22 15:14:33.0 +0100
+++ xen-4.17.0+74-g3eac216e6e/docs/misc/xen-command-line.pandoc	2023-03-21 13:47:52.0 +0100
@@ -287,10 +287,15 @@
 protection.
 
 The option is available when `CONFIG_XEN_SHSTK` is compiled in, and
-defaults to `true` on hardware supporting CET-SS.  Specifying
+generally defaults to `true` on hardware supporting CET-SS.  Specifying
 `cet=no-shstk` will cause Xen not to use Shadow Stacks even when support
 is available in hardware.
 
+Some hardware suffers from an issue known as Supervisor Shadow Stack
+Fracturing.  On such hardware, Xen will default to not using Shadow Stacks
+when virtualised.  Specifying `cet=shstk` will override this heuristic and
+enable Shadow Stacks unilaterally.
+
 *   The `ibt=` boolean controls whether Xen uses Indirect Branch Tracking for
 its own protection.
 
@@ -721,6 +726,11 @@
 * `all`: just one runqueue shared by all the logical pCPUs of
  the host
 
+Regardless of the above choice, Xen attempts to respect
+`sched_credit2_max_cpus_runqueue` limit, which may mean more than one runqueue
+for the `all` value. If that isn't intended, raise
+the `sched_credit2_max_cpus_runqueue` value.
+
 ### dbgp
 > `= ehci[  | @pci:. ]`
 > `= xhci[  | @pci:. ][,share=|hwdom]`
@@ -2624,6 +2634,17 @@
 ,  and  must be integers. The values will be
 encoded in guest CPUID 0x4002 if viridian enlightenments are enabled.
 
+### vm-notify-window (Intel)
+> `= `
+
+> Default: `0`
+
+Specify the value of the VM Notify window used to detect locked VMs. Set to -1
+to disable the feature.  Value is in units of crystal clock cycles.
+
+Note the hardware might add a threshold to the provided value in order to make
+it 

Bug#1033176: marked as done (linux: Future Android/Waydroid support)

[Diederik de Haas]

Control: reopen -1

On Tuesday, 21 March 2023 14:21:05 CEST Debian Bug Tracking System wrote:
> > In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream'
> > for recommendations on which/how/what kernel modules to enable.
> 
> In https://git.kernel.org/linus/9e18d0c82f0c07f2a41898d4adbb698a953403ee the
> default value of BINDER_DEVICES was changed to "binder,hwbinder,vndbinder"
> whereas the Debian kernel only has "binder". Also in other places they use
> the 3 values, but I haven't been able to find out *why*.
> As I wouldn't be able to make the argument to change it to something else
> and the most important thing is to enable ANDROID_BINDER_IPC, which is
> already the case, there's no need to keep this bug open.
> 
> If someone *can* substantiate why and how things should be changed, they
> should file a bug report (themselves) making the case.

Just received an (unexpected) extra response, which DOES answer the Q I had:

"BINDER_DEVICES defines which binder device names should appear in /dev. 
Different android versions required different devices to be available: the 
latest android version uses "binder,hwbinder,vndbinder" meaning /dev/binder, /
dev/hwbinder, /dev/vndbinder.
At some point Google realized that it's inconvenient to have this change at 
compile time, so they introduced BINDERFS: you can mount a filesystem of type 
binder somewhere and use IOCTLs on it to allocate new device names.

So if you use BINDERFS it doesn't matter which value of BINDER_DEVICES you set 
because you can add (or remove) devices at runtime. In this case 
BINDER_DEVICES is just the set of initial devices present in the root of a 
binderfs.

For mainline linux, BINDERFS is heavily recomended. Waydroid will use it to 
create all the binder devices it needs. You can leave BINDER_DEVICES empty or 
unchanged or whatever you prefer."

I don't really understand how or what `ioctl`s are, but I'm pretty sure others 
do and can now make an informed choice if and how things could be improved.
I'm pretty sure that'll be for Trixie, which has the nice benefit that it can 
be extensively tested.

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

Bug#1033639:

[Andreas Hasenack]

Thanks for filing this. The inet6 inclusion should be handled by the
same fix for #1033640 (the nameservice abstraction).

About the other problem you hit, did you make changes to the kea-dhcp6
configuration file, or are you getting these errors right after
install? I see you have a valid IPv6 address on the system.

If you made changes to /etc/kea/kea-dhcp6.conf, would you mind to
share them, so I can more easily reproduce the problem?

Bug#1033675: release-notes: apt-key improves system security with 3rd party sources

[Rainer Dorsch]

Package: release-notes
Severity: normal

Dear Maintainer,

according to
https://linuxnews.de/2021/04/10/debian-11-repositories-aus-3-hand-ohne-apt-key-einbinden/
Debian 12 supports and requires a safer way to import keys for 3rd
party repos. If that is the case, I suggest to add this to the release notes, 
since it is a nice security enhancement feature.

Thanks
Rainer

Bug#1033674: unblock: linux/6.1.20-1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: li...@packages.debian.org, k...@debian.org, car...@debian.org
Control: affects -1 + src:linux

Hi release team,

Please unblock package linux

The last update of src:linux did import stable versions from 6.1.16 up
to 6.1.20:

https://lists.debian.org/debian-release/2023/03/msg00500.html

The update did include some CVE fixes, as listed there CVE-2023-1032,
CVE-2023-1076, CVE-2023-1077, CVE-2023-1079, CVE-2023-1118,
CVE-2023-25012 and CVE-2023-28466. #1022126 was addressed upstream.
The packaging changes were to mainly add hardare support further and
bugfixes, I will not replicate the entries here again.

The update is in unstable for 10 days. Given there should be a d-i
release soon, it would benefit from beeing built with 6.1.20-1. 

Two issues are explicitly mentioned by Cyril, but they do affect as
well already the previous version in testing, so are no new
regressions: #1033301 for the amr64 kernel size increase; #1033058 an
issue in the reported for the installation for ppc6el in graphical
mode triggered by a kernel change 6.1.12.

Thus please unblock the current version to testing (and age it
accordingly).

unblock linux/6.1.20-1

Regards,
Salvatore

Bug#1033515: NMU: wit: autopkgtest regression: [[: not found

[Bastian Germann]

I have just uploaded a NMU to fix this. debdiff is attached.diff -Nru wit-3.01a/debian/changelog wit-3.01a/debian/changelog
--- wit-3.01a/debian/changelog  2021-11-11 13:57:57.0 +0100
+++ wit-3.01a/debian/changelog  2023-03-29 22:34:46.0 +0200
@@ -1,3 +1,10 @@
+wit (3.01a-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Eliminate bashisms in autopkgtest. (Closes: #1033515)
+
+ -- Bastian Germann   Wed, 29 Mar 2023 22:34:46 +0200
+
 wit (3.01a-4) unstable; urgency=medium
 
   * Add autopkgtests. (Closes: #999455)
diff -Nru wit-3.01a/debian/tests/wdf-cat-test 
wit-3.01a/debian/tests/wdf-cat-test
--- wit-3.01a/debian/tests/wdf-cat-test 2021-11-11 13:52:13.0 +0100
+++ wit-3.01a/debian/tests/wdf-cat-test 2023-03-29 21:51:58.0 +0200
@@ -4,6 +4,6 @@
 
 res=$(wdf-cat "$AUTOPKGTEST_TMP/content")
 
-if [[ "$res" != "Hello, world" ]]; then
+if [ "$res" != "Hello, world" ]; then
  exit 1
 fi
diff -Nru wit-3.01a/debian/tests/wdf-test wit-3.01a/debian/tests/wdf-test
--- wit-3.01a/debian/tests/wdf-test 2021-11-11 13:52:27.0 +0100
+++ wit-3.01a/debian/tests/wdf-test 2023-03-29 21:51:15.0 +0200
@@ -4,6 +4,6 @@
 
 res=$(wdf +CAT "$AUTOPKGTEST_TMP/content")
 
-if [[ "$res" != "Hello, world" ]]; then
+if [ "$res" != "Hello, world" ]; then
  exit 1
 fi

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

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-27 16:13:50 +0200, Jan Wagner wrote:
> Hi,
> 
> Am 27.03.23 um 08:28 schrieb Jan Wagner:
> > here are the upstream fixes, related upstream CI pipelines and issues:
> 
> while we are at fixing bugs.
> 
> I'd also like to include 
> https://patch-diff.githubusercontent.com/raw/monitoring-plugins/monitoring-plugins/pull/1850.patch,
> which fixes
> https://github.com/monitoring-plugins/monitoring-plugins/issues/1849
> (check_snmp: unit removed from check result)
> https://github.com/monitoring-plugins/monitoring-plugins/actions/runs/4531646296/jobs/7982048943?pr=1850
> has a successfull upstream CI test run.

Please go aheah and remove the moreinfo tag once the package is
available in unstable.

Cheers
-- 
Sebastian Ramacher

Bug#1033640:

[Andreas Hasenack]

I pushed this MR to salsa:
https://salsa.debian.org/debian/isc-kea/-/merge_requests/27

It's against experimental for now.

Bug#1033655: elpa-flycheck: Emacs28 / flycheck is spawning wild running shellcheck processes eating up the system memory (oom-kill)

[David Bremner]

Control: tag -1 unreproducible
Control: severity -1 important

H.-Dirk Schmitt  writes:

> Package: elpa-flycheck
> Version: 32~git.20200527.9c435db3-3
> Severity: grave
> X-Debbugs-Cc: none, H.-Dirk Schmitt 
>
>
> The combination of Emacs28 + elpa-flycheck + shellcheck in *bookworm*
> spawn never terminating shellcheck processes.  These are eating up the
> memory and trigger oom-kill.
>
> **This renders my system unstable.** It appears to be blocked minutes
> till the oem-kill cleans up some memory.

I can't duplicate this on a bookworm system. Does it happen for any
shell script, or some particular ones?

d

Bug#1033673: buildah: Not build with libsubid

[Sam Morris]

Package: buildah
Followup-For: Bug #1033673

Here's a merge request:
https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/-/merge_requests/2/


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

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

Versions of packages buildah depends on:
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages buildah recommends:
ii  crun1.8.1-1
ii  fuse-overlayfs  1.10-1

Versions of packages buildah suggests:
ii  containers-storage  1.43.0+ds1-7+b2

-- no debconf information

Bug#1032412: Plymouth changed

[Gert van de Kraats]

At plymouth the computation of Window.GetWidth() and Window.GetHeight()
has changed 2 years ago. It now contains the sizes of the
largest screen i.s.o. the smallest screen.
See merge-request
https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/121 :
"use resolution of higher res monitor for window size" .

Bug#1033672: otf2: FTBFS on riscv64 because it needs libatomic

[Steve Langasek]

Package: otf2
Followup-For: Bug #1033672
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Sorry, missed an 'export' in the previous patch.  Fixed patch attached.
diff -Nru otf2-3.0.2/debian/rules otf2-3.0.2/debian/rules
--- otf2-3.0.2/debian/rules 2022-09-18 13:51:45.0 -0700
+++ otf2-3.0.2/debian/rules 2023-03-29 11:41:33.0 -0700
@@ -5,6 +5,11 @@
 
 export DEB_HOST_MULTIARCH
 
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+ifeq ($(DEB_HOST_ARCH),riscv64)
+  export DEB_LDFLAGS_MAINT_APPEND = -latomic
+endif
+
 %:
dh $@
 

Bug#1031345: kicad: Please update

[Carsten Schoenert]

Hello Marius,

Am 29.03.23 um 20:23 schrieb Marius Paul Isken:

Please upgrade the package to 7.0.1, upstream was released six weeks ago.


did you noticed you writing to an already closed bug report?

This issue was closed due an uploaded version 7.0.1.
The reason why KiCad 7.x will not get included within the bookworm 
release was written in my first answer to the bugreport.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031345#10

If you are using unstable/testing you can still install the relevant 
packages from experimental mostly to get the most recent version of KiCad.


--
Regards
Carsten

Bug#1026118: thunderbird: please add support for riscv64

[Carsten Schoenert]

Hello Bo,

Am 29.03.23 um 01:23 schrieb Bo YU:

Source: thunderbird
Version: 1:110.0~b4-1
Followup-For: Bug #1026118

FYI, I just can build the thunderbird package on qemu-user with the
patch. Once it can be built on Unmatched, I will update it here.

The riscv64 binary packages here:
https://drive.google.com/drive/folders/1klWvrjq-geMFAWIXTas6lPz8e8_7Eavo


will give the patch a try together with the next major version 113 probably.

--
Regrads
Carsten

Bug#990560: Some questions regarding Inodes

[Helge Deller]

Hello Bernhard,

On 3/29/23 17:17, Bernhard wrote:

The limiting factor is how many inodes a filesystem allows.
This depends on the "inode size" and can be specified when formatting the 
filessystem.
32-bit applications can only address 2^32-1 inodes, which is ~ 4 million.
<

2^32 is ~4 billion.


:-)
To be specific:
Citing from: https://en.m.wikipedia.org/wiki/4,294,967,295
In computing, 4,294,967,295 is the highest unsigned (that is, not negative) 
32-bit integer,
which makes it the highest possible number a 32-bit system can store in memory.


Why is ~4 million a limiting factor?


The errors you see:
Can't read directory '/storage/subversion/svn/db/transactions/2337-1sx.txn': 
Value too large for defined data type

can have (at least) 2 reasons:
a) The inode number of that directory is bigger than 4,294,967,295 and as such 
doesn't fit into glibc's 32-bit ino_t struct,
b) The date of the directory is beyond year ~2038 and doesn't fit into glibc's 
32-bit time_t struct.

glibc tests in various functions if a value is bigger than what can be handled 
by it's 32-bit variable.
see e.g. sysdeps/unix/sysv/linux/getdents64.c:
ssize_t
__old_getdents64 (int fd, char *buf, size_t nbytes)
{
...
 /* Copy out the fixed-size data.  */
  __ino_t ino = source->d_ino;
  __off64_t offset = source->d_off;
  unsigned int reclen = source->d_reclen;
  unsigned char type = source->d_type;

  /* Check for ino_t overflow.  */
  if (__glibc_unlikely (ino != source->d_ino))
return handle_overflow (fd, previous_offset, p - buf);

Here ino (ino_t) is 32-bit while source->d_ino is a 64-bit variable.
If it doesn't fit your application will receive EOVERFLOW error for the
function you called.
It's done similiar for the time_t type.


Another option is to use xfs filesystem, which tries to work around that
problem
<

I use the XFS file system at the 4TB hard drive, which is formatted with the 
32Bit OS.
This is the output for the used XFS filesystem with size ~4TB:


FilesystemInodes IUsed IFree IUse% Mounted on
/dev/sda1  390701632  9608 3906920241% /storage


I mixed up inodes and blocks in my last mail.
https://adil.medium.com/ext4-filesystem-data-blocks-super-blocks-inode-structure-1afb95c8e4ab
What I wanted to express is, that the inode number can be
bigger than 4,294,967,295, in which case the application will receive an 
overflow error code.
This can happen more easily on bigger drives with many files.
Filesystems are different, I think XFS has some workarounds to cope better
with 32-bit apps than ext3/ext4.

Helge

Bug#1033673: buildah: Not build with libsubid

[Sam Morris]

Package: buildah
Version: 1.28.2+ds1-1+b2
Severity: normal
Tags: patch

Similar to podman's #1019929, buildah is not built with libsubid
support.

So users with subordinate UID/GIDs stored in an LDAP directory can't use
buildah without being root.

Merge request with patch on the way...

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

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

Versions of packages buildah depends on:
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages buildah recommends:
ii  crun1.8.1-1
ii  fuse-overlayfs  1.10-1

Versions of packages buildah suggests:
ii  containers-storage  1.43.0+ds1-7+b2

-- no debconf information

Bug#1032096: Additional information

[Vladimir Petko]

Dear Maintainer,

 The patch was merged upstream. Would it be possible to update the package?
 Thank you very much!

Best Regards,
  Vladimir.

Bug#1027100: coreutils: wc: total overflows unchecked

[Pádraig Brady]

On 28/12/2022 13:38, Pádraig Brady wrote:

On 27/12/2022 19:31, наб wrote:

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

-- >8 --
$ truncate -s 2E a
$ wc -c a a a a a a a | uniq -c
 7  2305843009213693952 a
 1 16140901064495857664 total
$ wc -c a a a a a a a a | uniq -c
 8 2305843009213693952 a
 1   0 total
$ wc -c a a a a a a a a a | uniq -c
 9 2305843009213693952 a
 1 2305843009213693952 total
$ wc -c a a a a a a a a a a | uniq -c
10 2305843009213693952 a
 1 4611686018427387904 total
-- >8 --

Which is obviously wrong. One of the sensible solutions would be to just
saturate the totals


Proposed solution for upstream 9.3 is at:
https://lists.gnu.org/archive/html/coreutils/2023-03/msg00091.html

Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64

[Arnd Bergmann]

On Wed, Mar 29, 2023, at 18:55, Helmut Grohne wrote:

> -cpu max
> Startup finished in 23.590s (kernel) + 18.210s (userspace) = 41.800s
> -cpu cortex-a57
> Startup finished in 6.090s (kernel) + 8.460s (userspace) = 14.551s
> -cpu max,pauth=off
> Startup finished in 4.756s (kernel) + 5.678s (userspace) = 10.435s
> -cpu max,pauth-impdef=on
> Startup finished in 6.077s (kernel) + 7.241s (userspace) = 13.319s

Ok, so max,pauth-impdef=on no slower than cortex-a57, but
it's slower than cpu=max was with an old kernel or an old
qemu before the addition of pauth.

> So choosing pauth-impdef over pauth should mostly fix performance. So
> given that for kvm we choose cpu=host, I think going higher than
> cortex-something would still be sensible. At this point, my preference
> is max,pauth-impdef=on. Does anyone disagree?

I think the two most sensible options are max,pauth-impdef=on
or max,pauth=off, which is a tradeoff between performance
and features. With pauth-impdef, it becomes a lot safer
to run untrusted userspace code in the guest, as well
as catching buggy code that triggers the pauth checks
by accident, but 30% slowdown is also quite significant.

Between the two, it depends on which use case you want to optimize for.

 Arnd

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Gunnar Hjalmarsson]

On 2023-03-29 20:15, Hammer Attila wrote:

I surprised default ibus-daemon not running in X session for example
the Mate session?


I had the same thought. Can you please run this command:

dpkg-query -W ibus im-config

If both those packages are installed, ibus-daemon ought to be started 
automatically at login.


--
Cheers,
Gunnar Hjalmarsson

Bug#1033672: otf2: FTBFS on riscv64 because it needs libatomic

[Steve Langasek]

Package: otf2
Version: 3.0.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Samuel,

The current otf2 fails to build on riscv64 due to failing to detect gcc
atomics support:

[...]
checking for gcc atomic builtins... no, using precompiled unknown version
[...]
config.status: error: cannot find input file: 
`../common/utils/src/atomic/UTILS_Atomic.inc.unknown.s.in'
[...]

  (https://launchpad.net/ubuntu/+source/otf2/3.0.2-1/+build/25411521)

This is because on riscv64, using gcc atomics requires linking to libatomic,
so detection fails.

The attached patch is sufficient to fix the build failure.  Maybe it should
be fixed upstream, but I'm not messing with m4 for that ;)

I have uploaded this patch to Ubuntu.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru otf2-3.0.2/debian/rules otf2-3.0.2/debian/rules
--- otf2-3.0.2/debian/rules 2022-09-18 13:51:45.0 -0700
+++ otf2-3.0.2/debian/rules 2023-03-29 11:34:21.0 -0700
@@ -5,6 +5,11 @@
 
 export DEB_HOST_MULTIARCH
 
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+ifeq ($(DEB_HOST_ARCH),riscv64)
+  DEB_LDFLAGS_MAINT_APPEND = -latomic
+endif
+
 %:
dh $@
 

Bug#1033671: MD5File() goes into an unconditional infinite loop on bullseye

[Guillaume Morin]

Package: libbsd0
Version: 0.11.3-1
Tags: patch,upstream,fixed-upstream,bullseye

MD5File in bullseye is essentially an infinite loop. It just calls
itself.

The simplest fix is

--- a/src/md5.c
+++ b/src/md5.c
@@ -105,7 +105,7 @@
 MD5File(const char *filename, char *buf)
 {
libmd_wrapper(MD5File);
-   return MD5File(filename, buf);
+   return libmd_MD5File(filename, buf);
 }
 
 char *

This was fixed upstream by 
https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888

-- 
Guillaume Morin 

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Hammer Attila]

Hi Samuel,


Many thanks the upstream report.

I readed this terminal command launch way with following pdf file:

http://www.cocofrix.com/includes/pdf/6%20IBus-Braille.pdf


If I understand previous right when I readed the manual, this manual not 
describe ibus-daemon launching before ibus-braille command. I will try 
it, because interesting me with hungarian Liblouis Braille input under 
keyboard.



A question:

I surprised default ibus-daemon not running in X session for example the 
Mate session?


I not remember now:

This daemon need running always after for example Mate session login, or 
applications launch dinamically this daemon if need this?



Attila

Bug#1033670: unblock: xwayland/2:22.1.9-1

[Julien Cristau]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jcris...@debian.org

Please unblock package xwayland

[ Reason ]
CVE-2023-1393

[ Risks ]
Arguably we could have cherry-picked just the CVE fix but the rest seems
reasonably low-risk too, so might as well throw in the extra fixes.

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

[ Other info ]

Upstream changelog from 22.1.8 (currently in testing) follows.  All
changes are reasonably straightforward and self-contained.

> commit f44cdcf4660ff70ee0dc9dc1f07ea31f8548837e
> Author: Olivier Fourdan 
> Date:   Wed Mar 29 14:00:14 2023 +0200
> 
> Bump version to 22.1.9
> 
> Signed-off-by: Olivier Fourdan 
> 
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> commit b3d05255dd1e8ece1636fb07b9461122273785ee
> Author: Olivier Fourdan 
> Date:   Mon Mar 13 11:08:47 2023 +0100
> 
> composite: Fix use-after-free of the COW
> 
> ZDI-CAN-19866/CVE-2023-1393
> 
> If a client explicitly destroys the compositor overlay window (aka COW),
> we would leave a dangling pointer to that window in the CompScreen
> structure, which will trigger a use-after-free later.
> 
> Make sure to clear the CompScreen pointer to the COW when the latter gets
> destroyed explicitly by the client.
> 
> This vulnerability was discovered by:
> Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
> 
> Signed-off-by: Olivier Fourdan 
> Reviewed-by: Adam Jackson 
> (cherry picked from commit 26ef545b3502f61ca722a7a3373507e88ef64110)
> 
>  composite/compwindow.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> commit 809cbedb969f10754ef866f71395c7b89968b2d5
> Author: Benno Schulenberg 
> Date:   Mon Mar 27 20:03:56 2023 +0200
> 
> xkbUtils: use existing symbol names instead of deleted deprecated ones
> 
> Symbols `XK_Cyrillic_DZHE` and `XK_Serbian_DZE` were pure synonyms.
> 
> (cherry picked from commit 6153c71cfb4698f1a416266564ecc748e4a25f2c)
> 
>  xkb/xkbUtils.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> commit 9e52a28be8aa763e1005f05affc7cef3c4219989
> Author: Olivier Fourdan 
> Date:   Wed Mar 22 11:31:03 2023 +0100
> 
> test: Use either wayland-info or weston-info
> 
> weston-info has been deprecated for quite some time, whereas wayland-info
> may not be available yet.
> 
> So we use either, depending on what's actually available.
> 
> Signed-off-by: Olivier Fourdan 
> Reviewed-by: Michel Dänzer 
> (cherry picked from commit fc625fe172d9f6a149a594b5214364bedf680239)
> 
>  test/scripts/xwayland-piglit.sh | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> commit d2e27b0a8c05efe56a4179d053c0258f95d3772f
> Author: Joshua Ashton 
> Date:   Fri Mar 17 12:31:44 2023 +
> 
> glamor: Don't glFlush/ctx switch unless any work has been performed
> 
> `glamor_make_current` is always called before any calls to GL.
> 
> Apply some dirty-tracking to whenever we call `glamor_make_current` so
> that we can avoid a decent amount of redundant GL work on each
> Dispatch cycle.
> 
> Gamescope previously was waking up an empty Xwayland server with an
> XQueryPointer and I noticed a significant amount of churn doing
> redundant GL work.
> 
> This has been addressed on the Gamescope side as well, but avoiding any
> useless GL context switches and flushes when glamor is doing nothing
> is still beneficial for CPU and power usage on portable devices.
> 
> Signed-off-by: Joshua Ashton 
> Reviewed-by: Emma Anholt 
> Acked-by: Olivier Fourdan  (cherry picked from commit 89163917e1976db4ae4863ad5337fa14bf348081)
> 
>  glamor/glamor.c   |  7 ++-
>  glamor/glamor_priv.h  |  1 +
>  glamor/glamor_sync.c  |  3 +--
>  glamor/glamor_utils.h | 11 +++
>  4 files changed, 15 insertions(+), 7 deletions(-)
> 
> commit 667afc6f8db59b1da6af5afe74709978496eebf0
> Author: Adam Jackson 
> Date:   Thu Feb 2 12:26:27 2023 -0500
> 
> present: Send a PresentConfigureNotify event for destroyed windows
> 
> This enables fixing a deadlock case on the client side, where the client
> ends up blocked waiting for a Present event that will never come because
> the window was destroyed. The new PresentWindowDestroyed flag allows the
> client to avoid blocking indefinitely.
> 
> Signed-off-by: Adam Jackson 
> See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116
> See-also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6685
> Reviewed-by: Michel Dänzer 
> (cherry picked from commit 462b06033e66a32308d940eb5fc47f5e4c914dc0)
> 
>  present/present_event.c  |  5 +++--
>  present/present_priv.h   |  7 

Bug#1033666: [Pkg-nagios-devel] Bug#1033666: icinga2-common: wrong executable in /usr/share/icinga2/include/plugins-contrib.d/systemd.conf

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 3/29/23 20:07, Andreas B. Mundt wrote:

the configuration in '/usr/share/icinga2/include/plugins-contrib.d/systemd.conf'
contains a wrong executable in line 4:

 command = [ PluginContribDir + "/check_systemd.py" ]

The plugin's path is '/usr/lib/nagios/plugins/check_systemd' (no .py) [1].


That's a divergence from upstream in the Debian package:


https://salsa.debian.org/python-team/packages/monitoring-plugins-systemd/-/blob/debian/master/debian/monitoring-plugins-systemd.install

We'll have to patch the CheckCommand like check_postgres:


https://salsa.debian.org/nagios-team/icinga2/-/blob/master/debian/patches/postgres-checkcommand.patch

Kind Regards,

Bas

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

Bug#1031345: (no subject)

[Marius Paul Isken]

Please upgrade the package to 7.0.1, upstream was released six weeks ago.

Thanks for your work and maintenance!

Bug#1033669: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2023c

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org, 
debian-p...@lists.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

New week, new tzdata release!

I've uploaded libdatetime-timezone-perl/1:2.47-1+2023c to bullseye.
It includes data from the tzdata 2023c release as a quilt patch. The
only change wrt. {1:2.47-1+,}2023b is that the DST postponement for
Lebanon is undone, so the patch effectively changes only
lib/DateTime/TimeZone/Asia/Beirut.pm.

Manually stripped down debdiff attached (the rest are just version
numbers).


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmQkhC9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbyJg/+JEiLIfZc9fsOl5vzlFvT2wetL/XT0LsW6QTUmaouwY410OxZ1MB0KrIm
JgpCt2G6hPUzZdLOv+T6wyqB7cU3OXTJQQ0q1laPM1wIL9BgbF2MAsXbQVuR2q2+
h/JGLn8AG9d35kn/GD06B3IY8VyGl+YNAHlsvetIo7UX53onrb0iE9cb47Qqv+uM
kSYe47Ms9+UCchZX54cLFO8q/ZIv92RZnX3SwuWCgzWpNsMYxz9cTMYZcGYgur+9
MEMm3A7ods5A+XP7okP++iVVuK/BbCZ+mgHQoxzLEHamB0YXR4IO5XCZtAQ5jfcH
iX8UfIjPV8wNFAJEtbUAsGeTX/G9VnaUznBPFUX3eFMdjMANNEWaLNLr5gR5fhZS
bdnfbgEF+4QavZodnnuGGru1S2t0jPw4Bs1hJu63OkmveLy58WmpHDPmS3DSZIz3
mVy1gGmZuagxnU1Y8XpQckQvi2VbHriPZmNUPPkKeOvdD/n8Is0i1nmK25rgRnRi
4rIHgNEb2123/dOywUWqjGsD1gfSwU+bfc3SRIeDrFKyBLXF9O1BVHiEO/qLBDek
xeu9QTean7Ipe5on5x5r+Xf9Pdx62DYdY4sUxqYMNWGbVCOEWSUBkP8qIyeU4H8Q
a7JTT+0a73Ic4SUIE+W7TkMWPj+WBDozPHzPyIqX9i7NrH9F1Zo=
=p1Lh
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2023-03-24 
16:58:22.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/changelog 2023-03-29 
20:21:49.0 +0200
@@ -1,3 +1,11 @@
+libdatetime-timezone-perl (1:2.47-1+2023c) bullseye; urgency=medium
+
+  * Update data to Olson database version 2023c.
+This update has the same zone data as 2023a, undoing the changes for
+Lebanon from the 2023b release past week.
+
+ -- gregor herrmann   Wed, 29 Mar 2023 20:21:49 +0200
+
 libdatetime-timezone-perl (1:2.47-1+2023b) bullseye; urgency=medium
 
   * Update data to Olson database version 2023b.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2023c 
libdatetime-timezone-perl-2.47/debian/patches/olson-2023c
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2023c   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2023c   2023-03-29 
20:21:49.0 +0200
@@ -0,0 +1,6513 @@
+Description: Update to Olson DB 2023c
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2023-03-29
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2023b
++# Generated from debian/tzdata/africa.  Olson data version 2023c
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023b'}
++sub olson_version {'2023c'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Asia/Beirut.pm
 b/lib/DateTime/TimeZone/Asia/Beirut.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2023b
++# Generated from debian/tzdata/asia.  Olson data version 2023c
+ #
+ # Do not edit this file directly.
+ #
+@@ -1024,17 +1024,17 @@
+ ],
+ [
+ 63802760400, #utc_start 2022-10-29 21:00:00 (Sat)
+-63817711200, #  utc_end 2023-04-20 22:00:00 (Thu)
++63815464800, #  utc_end 2023-03-25 22:00:00 (Sat)
+ 63802767600, #  local_start 2022-10-29 23:00:00 (Sat)
+-63817718400, #local_end 2023-04-21 00:00:00 (Fri)
++63815472000, #local_end 2023-03-26 00:00:00 (Sun)
+ 7200,
+ 0,
+ 'EET',
+ ],
+ [
+-63817711200, #utc_start 2023-04-20 22:00:00 (Thu)
++63815464800, #utc_start 2023-03-25 22:00:00 (Sat)
+ 6383421, #  utc_end 2023-10-28 21:00:00 (Sat)
+-63817722000, #  local_start 2023-04-21 01:00:00 (Fri)
++63815475600, #  local_start 2023-03-26 01:00:00 (Sun)
+ 63834220800, #local_end 2023-10-29 00:00:00 (Sun)
+ 10800,
+ 1,
+@@ -1240,7 +1240,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023b'}
++sub olson_version {'2023c'}
+ 
+ sub has_dst_changes {67}
+ 
+@@ -1293,24 +1293,24 @@
+ my $rules = [
+   bless( {
+ 'at' => '0:00',
+-'from' => '1999',
+-'in' => 'Oct',
+-'letter' => '',
++'from' => '1993',
++'in' => 'Mar',
++'letter' => 'S',
+ 'name' => 'Lebanon',
+-'offset_from_std' => 0,
++'offset_from_std' => 3600,
+ 'on' => 'lastSun',
+-'save' => '0',
++

Bug#1033665: libsigc++-3.0: .symbols file mismatch with template exposure under LTO

[Steve Langasek]

Package: libsigc++-3.0
Followup-For: Bug #1033665
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Sorry, the previous patch missed a symbol.  See the fixed patch attached
here.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols 
libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols
--- libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols  2022-06-26 
16:54:22.0 -0700
+++ libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols  2023-03-29 
10:40:49.0 -0700
@@ -45,8 +45,8 @@
  _ZN4sigc8internal11signal_implD1Ev@Base 3.2.0
  _ZN4sigc8internal11signal_implD2Ev@Base 3.2.0
  
_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEE25notify_object_invalidatedEPNS_10notifiableE@Base
 3.2.0
- _ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED1Ev@Base 3.2.0
- _ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED2Ev@Base 3.2.0
+ (optional=templist)_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED1Ev@Base 
3.2.0
+ (optional=templist)_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED2Ev@Base 
3.2.0
  
_ZN4sigc8internal12weak_raw_ptrINS_9slot_baseEE25notify_object_invalidatedEPNS_10notifiableE@Base
 3.2.0
  
_ZN4sigc8internal23trackable_callback_list12add_callbackEPNS_10notifiableEPFvS3_E@Base
 3.2.0
  
_ZN4sigc8internal23trackable_callback_list15remove_callbackEPNS_10notifiableE@Base
 3.2.0
@@ -108,23 +108,22 @@
  _ZNK4sigc9trackable30remove_destroy_notify_callbackEPNS_10notifiableE@Base 
3.2.0
  (optional=templist|arch=armel 
riscv64)_ZNK9__gnu_cxx24__concurrence_lock_error4whatEv@Base 3.2.0
  (optional=templist|arch=armel 
riscv64)_ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv@Base 3.2.0
- _ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD1Ev@Base 3.2.0
- _ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD2Ev@Base 3.2.0
- (optional=templinst|arch=armel 
riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base 
3.2.0
+ 
(optional=templist)_ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD1Ev@Base
 3.2.0
+ 
(optional=templist)_ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD2Ev@Base
 3.2.0
+ 
(optional=templist)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 3.2.0
- _ZSt20__throw_bad_weak_ptrv@Base 3.2.0
+ 
(optional=templist)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 3.2.0
+ 
(optional=templist)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 3.2.0
+ 

Bug#1033668: unblock: xorg-server/2:21.1.7-2

[Julien Cristau]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jcris...@debian.org

Please unblock package xorg-server

[ Reason ]
CVE-2023-1393

[ Risks ]
Simple patch to reset a pointer to freed memory.

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

unblock xorg-server/2:21.1.7-2

diff --git a/composite/compwindow.c b/composite/compwindow.c
index 73a1871a0b..9a651636e3 100644
--- a/composite/compwindow.c
+++ b/composite/compwindow.c
@@ -620,6 +620,11 @@ compDestroyWindow(WindowPtr pWin)
 ret = (*pScreen->DestroyWindow) (pWin);
 cs->DestroyWindow = pScreen->DestroyWindow;
 pScreen->DestroyWindow = compDestroyWindow;
+
+/* Did we just destroy the overlay window? */
+if (pWin == cs->pOverlayWin)
+cs->pOverlayWin = NULL;
+
 /*compCheckTree (pWin->drawable.pScreen); can't check -- tree isn't good*/
 return ret;
 }
diff --git a/debian/changelog b/debian/changelog
index 0949487831..f7e8a40cb5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xorg-server (2:21.1.7-2) unstable; urgency=high
+
+  * composite: Fix use-after-free of the COW
+ZDI-CAN-19866/CVE-2023-1393
+
+ -- Julien Cristau   Wed, 29 Mar 2023 15:11:07 +0200
+
 xorg-server (2:21.1.7-1) unstable; urgency=medium
 
   * New upstream release

Bug#1033667: verilator: Uninstallable in sid because of ${sphinxdoc:Built-Using} dependency

[Dmitry Shachnev]

Package: verilator
Version: 5.006-2
Severity: serious
Tags: patch

Dear Maintainer,

In a clean sid chroot, verilator is not installable:

  # apt install verilator
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   verilator : Depends: sphinx (= 5.3.0-3)
  E: Unable to correct problems, you have held broken packages.

This is because that package has ${sphinxdoc:Built-Using} among its
dependencies.

That substitution variable is intended to be used in Built-Using field of
architecture-dependent packages, NOT in Depends field.

I have created a merge request [1] on salsa to fix this.

[1]: https://salsa.debian.org/electronics-team/verilator/-/merge_requests/3

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1033666: icinga2-common: wrong executable in /usr/share/icinga2/include/plugins-contrib.d/systemd.conf

[Andreas B. Mundt]

Package: icinga2-common
Version: 2.13.6-2
Severity: normal
Tags: patch
X-Debbugs-Cc: a...@debian.org

Hi,

the configuration in '/usr/share/icinga2/include/plugins-contrib.d/systemd.conf'
contains a wrong executable in line 4:

command = [ PluginContribDir + "/check_systemd.py" ]

The plugin's path is '/usr/lib/nagios/plugins/check_systemd' (no .py) [1].

Thanks and best regards,

  Andi


[1] https://packages.debian.org/sid/all/monitoring-plugins-systemd/filelist
>From a807766be0459b0ac69afcb9584485bc43594d55 Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt" 
Date: Wed, 29 Mar 2023 19:59:15 +0200
Subject: [PATCH] Fix wrong executable name.

---
 itl/plugins-contrib.d/systemd.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/itl/plugins-contrib.d/systemd.conf 
b/itl/plugins-contrib.d/systemd.conf
index 4c0bbca1..236499bc 100644
--- a/itl/plugins-contrib.d/systemd.conf
+++ b/itl/plugins-contrib.d/systemd.conf
@@ -1,7 +1,7 @@
 /* Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+ */
 
 object CheckCommand "systemd" {
-   command = [ PluginContribDir + "/check_systemd.py" ]
+   command = [ PluginContribDir + "/check_systemd" ]
 
arguments = {
"--unit" = {
-- 
2.39.2

Bug#1033665: libsigc++-3.0: .symbols file mismatch with template exposure under LTO

[Steve Langasek]

Package: libsigc++-3.0
Version: 3.4.0-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

libsigc++-3.0 3.4.0-1 fails to build from source on architectures in Ubuntu
where LTO is enabled, because its .symbols file doesn't match up with the
set of instantiated templates being exposed in the ABI.

The attached patch suffices to let the package build both with and without
LTO.

In general it is counterproductive to have templated C++ symbols listed as
non-optional in a .symbols file; you might want to also consider cleaning up
this list:

   c++filt < debian/libsigc++-3.0-0.symbols  | grep '<' | grep -v 'optional'

It is also pointless to list architectures associated with an optional
template symbol, as these change over time and are sensitive to changes in
the toolchain, having nothing to do with the properties of the architecture.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols 
libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols
--- libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols  2022-06-26 
16:54:22.0 -0700
+++ libsigc++-3.0-3.4.0/debian/libsigc++-3.0-0.symbols  2023-03-29 
10:40:49.0 -0700
@@ -45,8 +45,8 @@
  _ZN4sigc8internal11signal_implD1Ev@Base 3.2.0
  _ZN4sigc8internal11signal_implD2Ev@Base 3.2.0
  
_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEE25notify_object_invalidatedEPNS_10notifiableE@Base
 3.2.0
- _ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED1Ev@Base 3.2.0
- _ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED2Ev@Base 3.2.0
+ (optional=templist)_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED1Ev@Base 
3.2.0
+ (optional=templist)_ZN4sigc8internal12weak_raw_ptrINS0_8slot_repEED2Ev@Base 
3.2.0
  
_ZN4sigc8internal12weak_raw_ptrINS_9slot_baseEE25notify_object_invalidatedEPNS_10notifiableE@Base
 3.2.0
  
_ZN4sigc8internal23trackable_callback_list12add_callbackEPNS_10notifiableEPFvS3_E@Base
 3.2.0
  
_ZN4sigc8internal23trackable_callback_list15remove_callbackEPNS_10notifiableE@Base
 3.2.0
@@ -108,22 +108,21 @@
  _ZNK4sigc9trackable30remove_destroy_notify_callbackEPNS_10notifiableE@Base 
3.2.0
  (optional=templist|arch=armel 
riscv64)_ZNK9__gnu_cxx24__concurrence_lock_error4whatEv@Base 3.2.0
  (optional=templist|arch=armel 
riscv64)_ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv@Base 3.2.0
- _ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD1Ev@Base 3.2.0
- _ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD2Ev@Base 3.2.0
- (optional=templinst|arch=armel 
riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base 
3.2.0
+ 
(optional=templist)_ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD1Ev@Base
 3.2.0
+ 
(optional=templist)_ZNSt15__allocated_ptrISaISt10_List_nodeIN4sigc9slot_baseD2Ev@Base
 3.2.0
+ 
(optional=templist)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base
 3.2.0
  (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 3.2.0
- (optional=templist|arch=amd64 
armhf)_ZNSt23_Sp_counted_ptr_inplaceIN4sigc8internal11signal_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 3.2.0
- (optional=templist|arch=amd64 

Bug#1033664: unblock: libdatetime-timezone-perl/1:2.60-1+2023c

[gregor herrmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org, 
debian-p...@lists.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

New week, new tzdata release!

I've uploaded libdatetime-timezone-perl 1:2.60-1+2023c to unstable.
This is the new 2.60 upstream release, which incorporates the tzdata
changes from 2023c.

The only change is in the lib/DateTime/TimeZone/Asia/Beirut.pm,
mirroring the tzdata change (reverting the data back to 2023a /
undoing the changes for Lebanon in 2023b after the decision to not
postpone DST any longer).

I'm attaching a manually stripped down debdiff against the last
upload (1:2.59-1+2023b) which was already unblocked; the exlcuded
files only contain changes in the versions (2.59 -> 2.60 and 2023b ->
2023c).


unblock libdatetime-timezone-perl/1:2.60-1+2023c


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmQkfE9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbMpBAAse3vS6BgkfNXvrN9iC7yr4QzG4pYdhyM7keMIapecfIhU68i74lwDKH/
XOpgFbrqB+al1pYqu+Dx4WGYjJhQX4cSARApKHNWfocfK6nvwEpB5C/C+CuFGME/
XFRQ7aSMERXE7x3w6he3Aco36jRuAd9MyzURtXAPShvxc+tYskbfy4ET+5SQBrxL
meBOvDHtcUQVuiTJneU0niMT4X5Fdu1pS83I+oZdqPLs4KZZoBsXnHQZBUr74Lph
5RKGKw8q85ANB3u7/PZiwhLDg21HOmZvlVNomjUbR7Zcb2bsoofJcnQiRej+MhDF
qV7n3BQzphnkiBPSjjj61uxG0gxRKFQc6SUmGWMC7SSuwsCKpBLDrjAs0npF0JK7
4+VoN56gZv/Zgw36FwsgrQP9dJpCvtGTu1QT9mkvXhTNhjBZSRe6Ci8I7l5kz2wL
Bcp00yvj3A3sdLz+sjVmKDmxgH9TzVEKApGthokHm2zWA1geaoaG0ycOj5w9i3gs
axoAGgqMh8KCmcyjxzuRIHyxBBs6Ac22l9VSpdcU3JbBw9MrUuT7vDuOdD2v4UPu
Ky8CvI/Hm2vC6U3ApTDixFYOfmsGD1yPaqol27tb3yErbrouq+n21l6B9i4XR8dy
Qz8iXiNI05TJAT4Bq8tPMJeDeYdh4x8Qp9sQ4Q+w/5HB6MFBkoA=
=ld/4
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.59/Changes 
libdatetime-timezone-perl-2.60/Changes
--- libdatetime-timezone-perl-2.59/Changes  2023-03-24 05:36:13.0 
+0100
+++ libdatetime-timezone-perl-2.60/Changes  2023-03-29 04:44:55.0 
+0200
@@ -1,3 +1,10 @@
+2.602023-03-28
+
+- This release is based on version 2023c of the Olson database. The 2023c
+  release has the same zone data as 2023a, undoing the changes for Lebanon
+  from the past week.
+
+
 2.592023-03-23
 
 - This release is based on version 2023b of the Olson database. This release
diff -Nru libdatetime-timezone-perl-2.59/META.json 
libdatetime-timezone-perl-2.60/META.json
diff -Nru libdatetime-timezone-perl-2.59/debian/changelog 
libdatetime-timezone-perl-2.60/debian/changelog
--- libdatetime-timezone-perl-2.59/debian/changelog 2023-03-24 
16:38:06.0 +0100
+++ libdatetime-timezone-perl-2.60/debian/changelog 2023-03-29 
19:46:25.0 +0200
@@ -1,3 +1,12 @@
+libdatetime-timezone-perl (1:2.60-1+2023c) unstable; urgency=medium
+
+  * Import upstream version 2.60.
+This release is based on version 2023c of the Olson database. It has the
+same zone data as 2023a, undoing the changes for Lebanon from the past
+week.
+
+ -- gregor herrmann   Wed, 29 Mar 2023 19:46:25 +0200
+
 libdatetime-timezone-perl (1:2.59-1+2023b) unstable; urgency=medium
 
   * Import upstream version 2.59.
diff -Nru 
libdatetime-timezone-perl-2.59/lib/DateTime/TimeZone/Africa/Abidjan.pm 
libdatetime-timezone-perl-2.60/lib/DateTime/TimeZone/Africa/Abidjan.pm
--- libdatetime-timezone-perl-2.59/lib/DateTime/TimeZone/Africa/Abidjan.pm  
2023-03-24 05:36:13.0 +0100
+++ libdatetime-timezone-perl-2.60/lib/DateTime/TimeZone/Africa/Abidjan.pm  
2023-03-29 04:44:55.0 +0200
@@ -3,7 +3,7 @@
 # DateTime::TimeZone module distribution in the tools/ directory
 
 #
-# Generated from /tmp/D3ET7029pk/africa.  Olson data version 2023b
+# Generated from /tmp/DzE_ngvtVe/africa.  Olson data version 2023c
 #
 # Do not edit this file directly.
 #
@@ -13,7 +13,7 @@
 use warnings;
 use namespace::autoclean;
 
-our $VERSION = '2.59';
+our $VERSION = '2.60';
 
 use Class::Singleton 1.03;
 use DateTime::TimeZone;
@@ -43,7 +43,7 @@
 ],
 ];
 
-sub olson_version {'2023b'}
+sub olson_version {'2023c'}
 
 sub has_dst_changes {0}
 
diff -Nru libdatetime-timezone-perl-2.59/lib/DateTime/TimeZone/Asia/Beirut.pm 
libdatetime-timezone-perl-2.60/lib/DateTime/TimeZone/Asia/Beirut.pm
--- libdatetime-timezone-perl-2.59/lib/DateTime/TimeZone/Asia/Beirut.pm 
2023-03-24 05:36:13.0 +0100
+++ libdatetime-timezone-perl-2.60/lib/DateTime/TimeZone/Asia/Beirut.pm 
2023-03-29 04:44:55.0 +0200
@@ -3,7 +3,7 @@
 # DateTime::TimeZone module distribution in the tools/ directory
 
 #
-# Generated from /tmp/D3ET7029pk/asia.  Olson data version 2023b
+# Generated from /tmp/DzE_ngvtVe/asia.  Olson data version 2023c
 #
 # Do not edit this file directly.
 #
@@ -13,7 +13,7 @@
 use warnings;
 use namespace::autoclean;

Bug#1020470: Ready to Implement

[Soren Stoutner]

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual package 
and an 
unversioned path for the conversion tool so that dictionary packagers don’t 
have to make 
modifications to their packages when the versions of Qt change in Debian.

All you should need to do is the following:

1.  Build-depend on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager documentation 
at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Thanks,

Soren

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


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

Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64

[Emanuele Rocca]

On 2023-03-29 06:55, Helmut Grohne wrote:
> At this point, my preference is max,pauth-impdef=on.

Agreed.

> Would someone confirm that this also speeds up on arm64?

Confirmed.

Thanks!
  ema

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

[James Addison]

Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: debian-toolch...@lists.debian.org, martin-eric.rac...@iki.fi, 
fierel...@gmail.com
Control: severity -1 serious
Control: tags -1 patch

A caution: there's a good chance I'm wasting everyone's time with this patch
and much of the preceding commentary about it.

However, I'd feel more comfortable raising this commotion about it and then
being talked down reasonably than I would if I didn't attempt to apply what I
feel is a fix.

Worth noting: it could still be an incorrect fix; this area is somewhat beyond
my expertise.  That's a reasonable reason to reject it too, because I don't
think anyone would want it to be applied and cause long-term problems.

Anyhow: Dear Maintainer, please find attached a patch that may address this
issue that I feel may be release critical for bookworm, per Debian's
architecture policy guidelines.
Description: match rustc i686 specification to Debian 9 i386 baseline
 Since Debian 9 (stretch), the baseline architecture specification for
 i386 package has been the i686 (Pentium P6), with neither MMX nor SSE
 instruction set extensions.
 .
 This is a lower baseline than the Pentium 4 default in Rust 1.63,
 and also lower than the Pentium Pro default previously specified in
 Debian's packaging for that version.
 .
 Upstream's definition of i686 appears to have converged on a
 different meaning, so this patch doesn't currently seem to be worth
 offering upstream (author's opinion here).
 .
 There are some downsides to this patch; performance of the Rust
 tooling and code built with it on Debian i386 will be suboptimal
 when using the defaults.  Again, author's opinion: I think it's
 worthwhile so that Debian is viable on baseline hardware.
 .
 Ref: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
Author: James Addison 
Last-Update: Wed 29 Mar 18:24:38 BST 2023
Bug: https://bugs.debian.org/973414
Forwarded: not-needed
X-Not-Forwarded-Because: upstream consensus on i686 differs

---

--- 
rustc-1.63.0+dfsg1.orig/compiler/rustc_target/src/spec/i686_unknown_linux_gnu.rs
+++ rustc-1.63.0+dfsg1/compiler/rustc_target/src/spec/i686_unknown_linux_gnu.rs
@@ -2,7 +2,7 @@ use crate::spec::{LinkerFlavor, StackPro
 
 pub fn target() -> Target {
 let mut base = super::linux_gnu_base::opts();
-base.cpu = "pentium4".into();
+base.cpu = "i686".into();
 base.max_atomic_width = Some(64);
 
base.pre_link_args.entry(LinkerFlavor::Gcc).or_default().push("-m32".into());
 // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are 
resolved

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Wed, Mar 29, 2023 at 03:40:21AM +0200, Vincent Lefevre wrote:
> On 2023-03-28 20:37:56 -0300, Antonio Terceiro wrote:
> > Still, I see no evidence that this is caused by the Ruby interpreter.
> > For example apt-listbugs uses a SOAP library that is severely
> > unmaintained upstream and has been on life support for some time now. It
> > could be that library that is doing crazy things when the server does
> > not reply in exactly the way it expects.
> 
> Note that in both failures, a line of the source, e.g.
> 
>   /usr/lib/ruby/3.0.0/uri/generic.rb
> 
> or
> 
>   /usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb
> 
> for "  # returns password\n" in my case in 2022, and
> 
>   /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb
> 
> for "if /proxy_detect='(.*)'/ =~ `apt-config \#{@apt_conf} shell 
> proxy_detect acquire::http::proxy-auto-detect`\n"
> in the other case a few days ago, is regarded by the Ruby interpreter
> as a String. Has any .rb library, even if severely buggy, the power
> to do that?

From what I can tell, the only dependency of apt-listbugs that calls
\.default on anything is ruby-soap4r:

/usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/factory.rb
344-  return nil
345-end
346:if !obj.default.nil? or
347-(obj.respond_to?(:default_proc) and obj.default_proc)
348-  return nil

/usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/rubytypeFactory.rb
114-param.add("item", elem)
115-  end
116:  param.add('default', Mapping._obj2soap(obj.default, map))
117-  addiv2soapattr(param, obj, map)
118-when ::Regexp
--
300-  end
301-  if node.key?('default')
302:obj.default = Mapping._soap2obj(node['default'], map)
303-  end
304-when TYPE_REGEXP

One think that could be happening is that soap4r is being fooled into
opening local files and that is triggered by some (corrupt?) response
from the server.

If anyone can still see this bug, it would be nice to configure
apt-listbugs in debug mode, e.g. setting

DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};

in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option), so
that when it happens we have a trace of the requests/reponses.

> Otherwise, could it be that apt-listbugs invokes the `default' method
> of some object obtained by SOAP, but this would mean that the server
> sends some part of .rb code as a String object in some cases? (This
> seems rather unlikely, and that could imply a security issue on the
> client side, if the client doesn't check what it receives.)

This is unlikely since debbugs is written in Perl. There is probably not
even Ruby installed in the server.

> IMHO, this looks like some kind of pointer corruption.

Could be this as well.


signature.asc
Description: PGP signature

Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev

[Andreas Metzler]

On 2023-03-28 Felix Stupp  wrote:
> Package: libopenexr-dev
> Version: 3.1.5-4
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: me+debian-b...@banananet.work

> Dear Maintainer,

> I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4
> due to a file conflict with the package libilmbase-dev on version
> 2.5.4-1. I tried with apt & aptitude as well. Both want to replace
> libilmbase-dev with libopenexr-dev in a single execution of them, but
> fail to do that in a way that dpkg allows that (tries first to install
> the new package and then uninstall the old one).
> Currently I see no other solution than removing the old one first aside
> with all packages depending it on it, and then installing the new one
> with all packages which were removed before.
[...]

Hello,

I cannot reporoduce this from your description because the original
setup you started with

libopenexr-dev +  libopenexr25 2.5.7-1
libilmbase-dev + libilmbase25 2.5.4-1

is not installable, libopenexr25 2.5.7-1 depends on libilmbase25 (>= 2.5.7).

cu Andreas

Bug#1033663: linux: reproducible-builds: Embedded build path in various binaries

[Vagrant Cascadian]

Source: linux
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/linux.html

  /usr/sbin/bpftool

  /build/1st/linux-6.1.20/tools/lib/bpf/libbpf.c:805
  vs.
  /build/2/linux-6.1.20/2nd/tools/lib/bpf/libbpf.c:805  

This *seems* like a regression from earlier versions, though I have not
tracked down when the tools started embedding the build paths...

The attached patches fix this for some of the binary packages and
corresponding dbgsym packages (bpftool, hyperv-daemons, *cpupower*) by
explicitly passing the -ffile-prefix-map argument (to avoid embedding
the build path) in the CFLAGS or EXTRA_CFLAGS variables in
debian/rules.d/.

I unsuccessfully tried applying similar patches for other tools packages
(rtla, perf, usbip) but was not able to convince the tools to take the
passed flags...

It would, of course, be better to figure out a way to get the various
tools to respect the default CFLAGS, as -ffile-prefix-map is included in
the default CFLAGS.

Unfortunately, these patches do not fix all reproducibility issues, but
applying these patches could reduce some of the noise and make it easier
to debug the remaining issues.

Thanks for maintaining linux!

live well,
  vagrant
From 7dcacfb3415c5ec4caea8933dd2c12fb401bea52 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 14:49:01 -0700
Subject: [PATCH 1/4] debian/rules.d/tools/bpf/bpftool/Makefile: Pass
 -ffile-prefix-map via EXTRA_CFLAGS.

---
 debian/rules.d/tools/bpf/bpftool/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules.d/tools/bpf/bpftool/Makefile b/debian/rules.d/tools/bpf/bpftool/Makefile
index 17c27c104..9d3017e42 100644
--- a/debian/rules.d/tools/bpf/bpftool/Makefile
+++ b/debian/rules.d/tools/bpf/bpftool/Makefile
@@ -5,7 +5,7 @@ MAKE_BPFTOOL += prefix=/usr
 MAKE_BPFTOOL += mandir=/usr/share/man
 MAKE_BPFTOOL += V=1
 MAKE_BPFTOOL += ARCH=$(KERNEL_ARCH)
-MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)'
+MAKE_BPFTOOL += EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS) -ffile-prefix-map=$(top_srcdir)=.'
 MAKE_BPFTOOL += EXTRA_LDFLAGS='$(LDFLAGS)'
 
 # dynamically linking with libbfd is not allowed in Debian
-- 
2.39.2

From cb11c490a41a0afbdeb00f272fa8a71cc3c69be1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 15:48:05 -0700
Subject: [PATCH 2/4] debian/rules.d/tools/power/cpupower/Makefile: Pass
 -ffile-prefix-map via MAKE_CPUPOWER CFLAGS.

---
 debian/rules.d/tools/power/cpupower/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules.d/tools/power/cpupower/Makefile b/debian/rules.d/tools/power/cpupower/Makefile
index e4bd5202d..28ccf7004 100644
--- a/debian/rules.d/tools/power/cpupower/Makefile
+++ b/debian/rules.d/tools/power/cpupower/Makefile
@@ -1,6 +1,6 @@
 include $(top_rulesdir)/Makefile.inc
 
-MAKE_CPUPOWER := CFLAGS='$(CFLAGS) $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) O=$(CURDIR) CPUFREQ_BENCH=false V=true mandir=/usr/share/man
+MAKE_CPUPOWER := CFLAGS='$(CFLAGS) -ffile-prefix-map=$(top_srcdir)=. $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) O=$(CURDIR) CPUFREQ_BENCH=false V=true mandir=/usr/share/man
 
 MAKE_CPUPOWER += DEBUG=$(if $(filter noopt,$(DEB_BUILD_OPTIONS)),true,)
 
-- 
2.39.2

From 2cf67982526879524548e37df0efac5f8b37e0d3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 28 Mar 2023 16:57:01 -0700
Subject: [PATCH 3/4] debian/rules.d/tools/power/x86/*/Makefile: Add
 -ffile-prefix-map to CFLAGS.

---
 debian/rules.d/tools/power/x86/turbostat/Makefile  | 2 ++
 debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/debian/rules.d/tools/power/x86/turbostat/Makefile b/debian/rules.d/tools/power/x86/turbostat/Makefile
index eb5124d3a..019fcbde6 100644
--- a/debian/rules.d/tools/power/x86/turbostat/Makefile
+++ b/debian/rules.d/tools/power/x86/turbostat/Makefile
@@ -7,3 +7,5 @@ include $(top_rulesdir)/Makefile.inc
 CPPFLAGS += -I"$(top_srcdir)/tools/include" -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h"' -DINTEL_FAMILY_HEADER='"$(top_srcdir)/arch/x86/include/asm/intel-family.h"'
 
 LDLIBS += -lcap -lrt
+
+CFLAGS += -ffile-prefix-map=$(top_srcdir)=.
diff --git a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
index b9ec56c89..a86da0f1e 100644
--- a/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
+++ b/debian/rules.d/tools/power/x86/x86_energy_perf_policy/Makefile
@@ -5,3 +5,5 @@ installdir = /usr/sbin
 include $(top_rulesdir)/Makefile.inc
 
 CPPFLAGS += -I"$(top_srcdir)/tools/include" -DMSRHEADER='"$(top_srcdir)/arch/x86/include/asm/msr-index.h"'
+
+CFLAGS += -ffile-prefix-map=$(top_srcdir)=.
-- 

Bug#1033662: wmsysmon FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: wmsysmon
Version: 0.8.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmsysmon fails to cross build from source, because the upstream makefile
hard codes the build architecture pkg-config. I'm attaching a patch that
makes it substitutable for your convenience.

Helmut
--- wmsysmon-0.8.0.orig/src/Makefile
+++ wmsysmon-0.8.0/src/Makefile
@@ -1,18 +1,19 @@
 # CFLAGS = -g #-DMONDEBUG
 
+PKG_CONFIG ?= pkg-config
 #
 # undefine HI_INTS if not on x86 SMP or alpha
 #
 CFLAGS	+= -W -Wall -pedantic -DHI_INTS \
-	   $(shell pkg-config dockapp --cflags) \
-	   $(shell pkg-config x11 --cflags) \
-	   $(shell pkg-config xext--cflags) \
-	   $(shell pkg-config xpm --cflags)
+	   $(shell $(PKG_CONFIG) dockapp --cflags) \
+	   $(shell $(PKG_CONFIG) x11 --cflags) \
+	   $(shell $(PKG_CONFIG) xext--cflags) \
+	   $(shell $(PKG_CONFIG) xpm --cflags)
 
-LIBS	+= $(shell pkg-config dockapp --libs) \
-	   $(shell pkg-config x11 --libs) \
-	   $(shell pkg-config xext--libs) \
-	   $(shell pkg-config xpm --libs) \
+LIBS	+= $(shell $(PKG_CONFIG) dockapp --libs) \
+	   $(shell $(PKG_CONFIG) x11 --libs) \
+	   $(shell $(PKG_CONFIG) xext--libs) \
+	   $(shell $(PKG_CONFIG) xpm --libs) \
 	   -lm
 
 PREFIX	= /usr

Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64

[Helmut Grohne]

Hi Arnd,

On Wed, Mar 29, 2023 at 01:12:45PM +0200, Arnd Bergmann wrote:
> The machine I use has KVM support for 64-bit guests, so
> I think you have this the wrong way around: If you run
> the arm64 guest with TCG, I would expect to see the
> same effect on an arm64 host and an x86 host.

Thanks for correcting me.

> It will be a very long time before Debian/arm64 can
> consider bumping the baseline, as the oldest Cortex-A53
> and Cortex-A57 cores are only ten years old at this point,
> and the Cortex-A53 is still the most popular core in
> currently shipping SoCs, by a wide margin.

This also is a useful bit. Johannes mentioned that autopkgtest uses
cortex-a53.

> The maintenance argument goes both ways I think: Having
> the A57 or A53 as the baseline makes it easier when
> a package accidentally relies on a feature of a later
> core without doing a runtime feature check, so that
> would favor using A57 over cpu=max. The advantage
> of using cpu=max is normally that this enables additional
> features to be used in the guest that may provide
> better performance or security, and allow testing those
> features.

At this time, I am convinced that -cpu max is a suboptimal choice.

> I don't know why the system performs poorly with cpu=max,
> this may be a known issue with one of the features this
> enables, or it may be a bug in the kernel or in qemu
> that we should fix.
> 
> I have no objections to changing the default to
> cpu=cortex-a57 for non-KVM runs, but I think more
> importantly we should
> 
> a) try to reproduce the behavior on an x86-64 host, and

Yes, it is fully reproducible there. I ran some tests with suggestions
from Arnd:

-cpu max
Startup finished in 23.590s (kernel) + 18.210s (userspace) = 41.800s
-cpu cortex-a53
Startup finished in 6.080s (kernel) + 9.808s (userspace) = 15.889s
-cpu cortex-a57
Startup finished in 6.090s (kernel) + 8.460s (userspace) = 14.551s
-cpu cortex-a76
Startup finished in 6.415s (kernel) + 8.300s (userspace) = 14.715s
-cpu a64fx
Startup finished in 6.373s (kernel) + 9.048s (userspace) = 15.422s
-cpu neoverse-n1
Startup finished in 6.078s (kernel) + 8.367s (userspace) = 14.446s
-cpu max,sve=off,sme=off,pmu=off,lpa2=off,pauth=off
Startup finished in 4.357s (kernel) + 5.405s (userspace) = 9.763s
-cpu max,lpa2=off
Startup finished in 20.854s (kernel) + 18.848s (userspace) = 39.703s
-cpu max,pauth=off
Startup finished in 4.756s (kernel) + 5.678s (userspace) = 10.435s
-cpu max,sme=off
Startup finished in 22.018s (kernel) + 18.335s (userspace) = 40.353s
-cpu max,pmu=off
Startup finished in 21.032s (kernel) + 17.974s (userspace) = 39.007s
-cpu max,pauth-impdef=on
Startup finished in 6.077s (kernel) + 7.241s (userspace) = 13.319s

So pauth seems to be the culprit. This is kinda known, see:
https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html#tcg-vcpu-features

> b) figure out the underlying issue.

I think we did.

So choosing pauth-impdef over pauth should mostly fix performance. So
given that for kvm we choose cpu=host, I think going higher than
cortex-something would still be sensible. At this point, my preference
is max,pauth-impdef=on. Does anyone disagree? Would someone confirm that
this also speeds up on arm64?

Helmut

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Dominique Dumont]

Hello

Turns out that Perl module Net::SMTP supports SSL since 2014 [1], but bts still 
use Net::SMTPS which is an old wrapper around Net::SMTP.

I've patched bts to use Net::SMTP instead of Net::STMPS and I can connect to 
Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
Net::SMTP::_SSL>>> Net::SMTP::_SSL
Net::SMTP::_SSL>>>   IO::Socket::SSL(2.081)
Net::SMTP::_SSL>>> IO::Socket::IP(0.41)
Net::SMTP::_SSL>>>   IO::Socket(1.49)
Net::SMTP::_SSL>>> IO::Handle(1.48)
Net::SMTP::_SSL>>>   Exporter(5.77)
Net::SMTP::_SSL>>>   Net::SMTP(3.14)
Net::SMTP::_SSL>>> Net::Cmd(3.14)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 220 mail.wgdd.de ESMTP Postfix 
(Debian/GNU)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> EHLO free.fr
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-mail.wgdd.de
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-PIPELINING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SIZE
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ETRN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH=PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-8BITMIME
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-DSN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SMTPUTF8
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 CHUNKING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> MAIL FROM:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 2.1.0 Ok
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> RCPT TO:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 554 5.7.1 
<91-175-103-119.subs.proxad.net[91.175.103.119]>: Client host rejected: Access 
denied
bts.pl: failed to set SMTP recipient cont...@bugs.debian.org
()
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2848)
at main::(scripts/bts.pl:834)

bts fails later probably because of my mail config (proxad system is free.fr 
mail server).

Anyhow, the failure occurs after bts is connected to Daniel's server.

Could you test bts with the patch below ? (feel free to remove the Debug 
argument)

All the best

[1] https://metacpan.org/dist/libnet/changes#L256


diff --git a/scripts/bts.pl b/scripts/bts.pl
index 7449c7ca..6ed35437 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -106,7 +106,7 @@ sub have_lwp() {
 
 sub have_smtps() {
 return ($smtps_broken ? 0 : 1) if defined $smtps_broken;
-eval { require Net::SMTPS; };
+eval { require Net::SMTP; };
 
 if ($@) {
 if ($@ =~ m%^Can\'t locate Net/SMTPS%) {
@@ -2703,11 +2703,12 @@ sub send_mail {
 $port ||= '465';
 
 if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
 $host,
 Port  => $port,
 Hello => $smtphelo,
-doSSL => 'ssl'
+SSL => 1,
+Debug => 1,
   )
   or die
 "$progname: failed to open SMTPS connection to $smtphost\n($@)\n";
@@ -2720,11 +2721,10 @@ sub send_mail {
 $port ||= '25';
 
 if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
 $host,
 Port  => $port,
 Hello => $smtphelo,
-doSSL => 'starttls'
   )
   or die
 "$progname: failed to open SMTP connection to $smtphost\n($@)\n";

Bug#1033660: unblock: pydle/0.9.4-4

[Bastian Germann]

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

Please unblock package pydle

[ Reason ]
Fixes FTBFS #1031974.

[ Impact ]
pydle will be auto-removed from bookworm without an unblock.

[ Tests ]
Building or running pydle with python3.11 result in Python exceptions.

[ Risks ]
None; all applied changes stem from upstream.

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

unblock pydle/0.9.4-4diff -Nru pydle-0.9.4/debian/changelog pydle-0.9.4/debian/changelog
--- pydle-0.9.4/debian/changelog2022-06-14 22:45:53.0 +0200
+++ pydle-0.9.4/debian/changelog2023-03-22 11:57:39.0 +0100
@@ -1,3 +1,12 @@
+pydle (0.9.4-4) unstable; urgency=medium
+
+  * Team upload.
+  * Patch: Remove Deprecated Marker from WHOIS. (Closes: #1031974)
+  * Patch: Remove not used coroutine import.
+  * Patch: Fixup irccat.py example.
+
+ -- Bastian Germann   Wed, 22 Mar 2023 11:57:39 +0100
+
 pydle (0.9.4-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru pydle-0.9.4/debian/patches/Fixup-irccat.py-example.patch 
pydle-0.9.4/debian/patches/Fixup-irccat.py-example.patch
--- pydle-0.9.4/debian/patches/Fixup-irccat.py-example.patch1970-01-01 
01:00:00.0 +0100
+++ pydle-0.9.4/debian/patches/Fixup-irccat.py-example.patch2023-03-22 
11:57:39.0 +0100
@@ -0,0 +1,97 @@
+Origin: upstream, b747ce1bd1e46038bc5e4c3eff1a64175f0908dd
+From: Joshua Salzedo 
+Date: Sat, 21 Nov 2020 20:45:44 -0800
+Subject: [#151] Fixup irccat.py example
+
+---
+ pydle/utils/irccat.py | 50 ++-
+ 1 file changed, 26 insertions(+), 24 deletions(-)
+
+diff --git a/pydle/utils/irccat.py b/pydle/utils/irccat.py
+index 47a857c..495018d 100644
+--- a/pydle/utils/irccat.py
 b/pydle/utils/irccat.py
+@@ -8,57 +8,59 @@
+ import asyncio
+ from asyncio.streams import FlowControlMixin
+ 
+-from .. import  Client, __version__
++from .. import Client, __version__
+ from . import _args
+ import asyncio
+ 
++
+ class IRCCat(Client):
+ """ irccat. Takes raw messages on stdin, dumps raw messages to stdout. 
Life has never been easier. """
++
+ def __init__(self, *args, **kwargs):
+ super().__init__(*args, **kwargs)
+ self.async_stdin = None
+ 
+-@asyncio.coroutine
+-def _send(self, data):
+-sys.stdout.write(data)
+-yield from super()._send(data)
++async def _send(self, data):
++await super(IRCCat, self)._send(data)
+ 
+-@asyncio.coroutine
+-def process_stdin(self):
++async def process_stdin(self):
+ """ Yes. """
+-loop = self.eventloop.loop
++loop = asyncio.get_event_loop()
+ 
+ self.async_stdin = asyncio.StreamReader()
+ reader_protocol = asyncio.StreamReaderProtocol(self.async_stdin)
+-yield from loop.connect_read_pipe(lambda: reader_protocol, sys.stdin)
++await loop.connect_read_pipe(lambda: reader_protocol, sys.stdin)
+ 
+ while True:
+-line = yield from self.async_stdin.readline()
++line = await self.async_stdin.readline()
+ if not line:
+ break
+-yield from self.raw(line.decode('utf-8'))
++await self.raw(line.decode('utf-8'))
+ 
+-yield from self.quit('EOF')
++await self.quit('EOF')
+ 
+-@asyncio.coroutine
+-def on_raw(self, message):
++async def on_raw(self, message):
+ print(message._raw)
+-yield from super().on_raw(message)
++await super().on_raw(message)
++
++async def on_ctcp_version(self, source, target, contents):
++await self.ctcp_reply(source, 'VERSION', 'pydle-irccat 
v{}'.format(__version__))
++
+ 
+-@asyncio.coroutine
+-def on_ctcp_version(self, source, target, contents):
+-self.ctcp_reply(source, 'VERSION', 'pydle-irccat 
v{}'.format(__version__))
++async def _main():
++# Create client.
++irccat, connect = _args.client_from_args('irccat', default_nick='irccat',
++ description='Process raw IRC 
messages from stdin, dump received IRC messages to stdout.',
++ cls=IRCCat)
++await connect()
++while True:
++await irccat.process_stdin()
+ 
+ 
+ def main():
+ # Setup logging.
+ logging.basicConfig(format='!! %(levelname)s: %(message)s')
+-
+-# Create client.
+-irccat, connect = _args.client_from_args('irccat', default_nick='irccat', 
description='Process raw IRC messages from stdin, dump received IRC messages to 
stdout.', cls=IRCCat)
+-
+-irccat.eventloop.schedule_async(connect())
+-irccat.eventloop.run_with(irccat.process_stdin())
++asyncio.get_event_loop().run_until_complete(_main())
+ 
+ 
+ if __name__ 

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Samuel Thibault]

Control: tags -1 + upstream
Control: forwarded -1 https://gitlab.com/smc/ibus-braille/-/issues/3

Hello,

Attila Hammer, le mer. 29 mars 2023 17:14:34 +0200, a ecrit:
> Ibus-braille after I launched in mate-terminal produce following traceback
> error message:
> self.__factory = IBus.Factory.new(self.__bus.get_connection())
>  ^
> TypeError: Argument 0 does not allow None as a value"

Ok, it means it didn't get the ibus bus.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Simple launch mate-terminal, and launch ibus-braille command.

You need to start ibus-daemon before ibus-braille. I have forwarded the
issue (make ibus-braille explain what is happening) to upstream.

Samuel

Bug#1033636: swi-prolog ships shared libraries, breaks partial upgrades

[Steve Langasek]

On Wed, Mar 29, 2023 at 03:45:26PM +0500, Lev Lamberov wrote:
> Thanks for reporting!

> I've tagged this bug report with 'help'. I'm a bit overwhelmed at the
> moment and don't think I will have time for it or any other Debian stuff
> in the coming weeks. NMU is most welcome.

Afraid I don't have capacity to help with this either.  I've applied a
quick-stop fix to Ubuntu to have swi-prolog-core declare Breaks: against
older incompatible versions of logol - and also libppl-swi, which turns out
to also be affected.  Doing the same in Debian may be enough for the current
release, but it's good to not lose sight of a long-term fix since there are
bound to be other SONAME changes in the future.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

[Mark Hindley]

This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me
when invoked as 

 pidof $(which vi)

Markus, can you confirm that works for you?

Since it is a regression since bullseye, it seems a suitable targeted fix to
attempt for bookworm.

Thanks to everybody.

Mark
>From 93da64d13380b29fd330608493615f8877525494 Mon Sep 17 00:00:00 2001
From: Jesse 
Date: Wed, 29 Mar 2023 10:34:45 -0300
Subject: [PATCH] Accepted patch from Mark Hindle which avoids clearing
 realpath information in pidof when trying to find matching executables.

---
 src/killall5.c | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/killall5.c b/src/killall5.c
index 9ab0782a..6f7528ad 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -740,8 +740,8 @@ PIDQ_HEAD *pidof(char *prog)
 		return NULL;
 
 	/* Try to stat the executable. */
+	memset(real_path, 0, sizeof(real_path));
 	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
-		memset(_path[0], 0, sizeof(real_path));
 		dostat++;
 	}
 
-- 
2.39.2

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Attila Hammer]

Package: ibus-braille
Version: 0.3-8
Severity: normal
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?
Ibus-braille after I launched in mate-terminal produce following traceback
error message:
"Traceback (most recent call last):
  File "/usr/share/ibus-braille/main.py", line 121, in 
main()
  File "/usr/share/ibus-braille/main.py", line 118, in main
launch_engine(exec_by_ibus)
  File "/usr/share/ibus-braille/main.py", line 78, in launch_engine
IMApp(exec_by_ibus).run()
^^^
  File "/usr/share/ibus-braille/main.py", line 60, in __init__
self.__factory = IBus.Factory.new(self.__bus.get_connection())
 ^
TypeError: Argument 0 does not allow None as a value"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Simple launch mate-terminal, and launch ibus-braille command.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages ibus-braille depends on:
ii  gir1.2-ibus-1.0   1.5.27-5
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  python3   3.11.2-1
ii  python3-espeak0.5-5+b1
ii  python3-gi3.42.2-3+b1
ii  python3-louis 3.24.0-1

Versions of packages ibus-braille recommends:
ii  python3-speechd  0.11.4-2

ibus-braille suggests no packages.

-- no debconf information

Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive

[Manuel A. Fernandez Montecelo]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: aure...@debian.org, m...@debian.org

Hello FTP team,

We had conversations requesting different teams (FTP, Release, DSA) their
opinion about adding riscv64 [1] as a new architecture in the main
infrastructure and all teams gave their provisional approval, so we are
submitting this to track progress on this task.

Could you please tells us if there's any blocker or something else that we
should do?


Cheers.


[1] https://wiki.debian.org/Ports/riscv64

--
Manuel A. Fernandez Montecelo 

Bug#1033566: module MPI3MR not enabled

[Diederik de Haas]

On Monday, 27 March 2023 17:35:25 CEST Diederik de Haas wrote:
> While looking into it, I did find some troubling aspects though.
> I noticed that in upstream's master branch there were quite some commits
> *after* 6.1 of which a reasonable amount has been backported to 6.1.
> For example, in 6.1.21 there are FIVE commits which fix a memory leak.
> 
> Those got backported because the original commits contained
> "Fixes: "
> 
> There are however also some commits which do NOT have the "Fixes:" tag,
> like:
> https://lore.kernel.org/all/20230228140835.4075-7-ranjan.ku...@broadcom.com
> / titled: "mpi3mr: Bad drive in topology results kernel crash"
> 
> There are some more and for that compare upstream's master branch with 6.1
> and look for the ones which do not have the "Fixes:" tag.
> Unless explicit action is taken to request a backport, f.e. the above
> mentioned commit will not get backported to 6.1 ... which could lead to a
> kernel crash.

I noticed that Salvatore responded to that thread and was a bit surprised that
I didn't see a quick follow-up from that.
But it looks like Sasha Levin has backported 4 out of 6 patches:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/queue-6.1?id=293e8033e127c25a74c680d61505f9f19b917ccf

Normally they would be included in the 6.1.22 release.

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

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[Alberto Garcia]

On Wed, Mar 29, 2023 at 05:01:00PM +0200, karogyoker999 wrote:
> For the others watching (if any): I have sent the core dump to Berto.

The stack trace, for reference:

Core was generated by `/usr/lib/i386-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 
12 18'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb59e2128 in WebCore::Font::Font () at 
./Source/WebCore/platform/graphics/Font.cpp:89
89  , m_allowsAntialiasing(true)
[Current thread is 1 (Thread 0xac0b3a00 (LWP 3370))]
(gdb) bt
#0  0xb59e2128 in WebCore::Font::Font () at 
./Source/WebCore/platform/graphics/Font.cpp:89
#1  0xd0015949 in ?? ()
#2  0x010159eb in ?? ()
#3  0x in ?? ()

Berto

Bug#990560: Some questions regarding Inodes

[Bernhard]

Hello Helge

You wrote:

>
The limiting factor is how many inodes a filesystem allows.
This depends on the "inode size" and can be specified when formatting the 
filessystem.
32-bit applications can only address 2^32-1 inodes, which is ~ 4 million.
<

2^32 is ~4 billion.
Why is ~4 million a limiting factor?
Mistake?

>
Another option is to use xfs filesystem, which tries to work around that
problem
<

I use the XFS file system at the 4TB hard drive, which is formatted with the 
32Bit OS.
This is the output for the used XFS filesystem with size ~4TB:

> FilesystemInodes IUsed IFree IUse% Mounted on
> /dev/sda1  390701632  9608 3906920241% /storage

Thank you for your support and answering my questions.
Bernhard



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

Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64

[Emanuele Rocca]

Hi,

On 2023-03-29 01:12, Arnd Bergmann wrote:
> a) try to reproduce the behavior on an x86-64 host

Good point. Also on a x86-64 host cpu=cortex-a57 is significantly
faster:

max:
[   30.086331] systemd[1]: Hostname set to .

cortex-a57:
[   13.870771] systemd[1]: Hostname set to .

Bug#1033616: cups prepends job number to job-name so job names near 255 characters may be too long

[Brian Potkin]

On Tue 28 Mar 2023 at 18:45:02 +0200, John Hughes wrote:

> Package: cups
> Version: 2.3.3op2-3+deb11u2
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I printed a page from firefox with a very, very long URL.  Firefox used the 
> first 255 bytes of the URL as the job name.
> 
>* What was the outcome of this action?
> 
> The job mysteriously didn't print.  Lookin in the cups log (with debug on) I 
> found the lines:
> 
> D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 - 
> https://xxx//xx
> 
> D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job: 
> client-error-request-value-too-long (client-error-request-value-too-long)
> 
> notice how the job name passed to cups ("https://xxx...;) is shorter than 255 
> characters, but when the job number "365 - " is prepended it is longer tnan 
> 255 characters and so overflows.
> 
>* What outcome did you expect instead?
> 
> That my print job be printed rather than just geting stuck in the print queue 
> forever.
> 
> How to reproduce:
> 
>   lp -o 
> 'job-name=https://xxx//xx'

Thank you for your report, John.

I think it would be better if you took this upstream:

  https://github.com/OpenPrinting/cups/issues

Regards,

Brian.

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[karogyoker999]

For the others watching (if any): I have sent the core dump to Berto.

Bug#1033640:

[Markus Viitamäki]

Hey,

Indeed, that seems to be the case. Can't recall that it would have been a
symlink in any bookworm systems I have installed or earlier version of
Debian.

/run/systemd/resolve doesn't exist on any of my systems.

Bug#709591: gajim: Gajim does not reconnect after resume from suspend

[Martin]

Control: close -1 1.0.0-1

This probably has been fixed since long.
Works for me.

Bug#1033654: akonadi broken with libmariadb from s-p-u

[Otto Kekäläinen]

You can +1 this and also the upstream PR:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/13

Bug#780508: [gajim] gajim reports wrongly: "Dies ist kein Chatraum"

[Martin]

Control: close -1 1.0.0-1

The error message has been improved at some point.
Probably before 1.0.0-1.

Bug#1033657: grub-efi-arm64-signed: Secure Boot not working on arm64

[Emanuele Rocca]

Package: grub-efi-arm64-signed
Version: 2.06-8

Hi,

Secure Boot does not work on arm64 using the shim signed by Microsoft [0] and
grub2 signed by Debian [1] currently in sid.

(a) SB not working with Debian's shim, grub and kernel:

 $ sbverify --list /mnt/efi/boot/bootaa64.efi | grep subject
 warning: data remaining[839096 vs 979672]: gaps between PE/COFF sections?
  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Windows UEFI Driver Publisher
  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft 
Corporation UEFI CA 2011
 
 $ sbverify --list /mnt/efi/boot/grubaa64.efi | grep subject
  - subject: /CN=Debian Secure Boot Signer 2022 - grub2
 
 $ sbverify --list /mnt/vmlinuz-6.1.0-7-arm64 | grep subject
  - subject: /CN=Debian Secure Boot Signer 2022 - linux

With the efi variables from qemu-efi-aarch64's AAVMF_VARS.ms.fd plus
SHIM_VERBOSE enabled `mokutil --set-verbosity true`, and the firmware
file AAVM_CODE.fd from edk2 rebuilt in debug mode - see
https://bugs.debian.org/1033613

 $ qemu-system-aarch64 -machine virt -cpu cortex-a57 \
-drive file=AAVMF_CODE.debug.fd,format=raw,if=pflash,readonly=true \
-drive file=AAVMF_VARS.ms.verbose.fd \
[...]

 grub> linux /vmlinuz-6.1.0-7-arm64
 [...]
 shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0:
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (db)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT)
 shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1
 grub> boot
 [Security] 3rd party image[0] can be loaded after EndOfDxe: 
MemoryMapped(0x2,0x6A03D000,0x6C72D7C0).
 DxeImageVerificationLib: Image is signed but signature is not allowed by DB 
and SHA256 hash of image is not found in DB/DBX.
 The image doesn't pass verification: MemoryMapped(0x2,0x6A03D000,0x6C72D7C0)
 error: cannot load image.

However:

(b) SB works with Ubuntu's shim, grub and kernel [2]
(c) SB works using a self-signed shim, grub, and kernel from unstable

The Ubuntu output (b) is:

 grub> linux /vmlinuz-6.2.0-18-generic
 shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0:
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 2 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 3 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 4 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 5 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 6 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 7 (dbx)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (db)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT)
 shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1
 grub> boot
 EFI stub: Booting Linux Kernel...
 EFI stub: EFI_RNG_PROTOCOL unavailable
 EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
 EFI stub: ERROR: FIRMWARE BUG: Image BSS overlaps adjacent EFI memory region
 EFI stub: Generating empty DTB
 EFI stub: Exiting boot services...
 EFI stub: UEFI Secure Boot is enabled.

And the Debian self-signed output (c) is:

 grub> linux /vmlinuz-6.1.0-7-arm64.selfsigned
 [...]
 shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0:
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db)
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT)
 shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1
 shim.c:665:verify_buffer_authenticode() Attempting to verify signature 1:
 shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db)
 shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1
 grub> boot
 [Security] 3rd party image[0] can be loaded after EndOfDxe: 
MemoryMapped(0x2,0x6A04,0x6C730E68).
 DxeImageVerificationLib: Image is signed but signature is not allowed by DB 
and SHA256 hash of image is not found in DB/DBX.
 DxeImageVerification: MeasureVariable (Pcr - 7, EventType - 80E0, 
VariableName - db, VendorGuid - D719B2CB-3D3A-4596-A3BC-DAD00E67656F)
 MeasureBootPolicyVariable - Not Found
 None of Tcg2Protocol/CcMeasurementProtocol is installed.
 [...]
 EFI stub: Booting Linux Kernel...
 EFI stub: EFI_RNG_PROTOCOL unavailable
 EFI stub: UEFI Secure Boot is enabled.

As per the way forward: the diff between Debian's grub and Ubuntu's is
non-trivial, so comparing the two may not be the best course of action. I see
that there is an old patchset at https://bugs.debian.org/836140 which could be
forward-ported though.

In any case there are two difficulties when it comes to testing a new grub
version:

- Secure Boot just works when self-signing (c), and I'm not sure why that is
  

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.

[H.-Dirk Schmitt]

For myself I have deinstalled elpa-org for the moment.

But this mitigation – or the suggested changing of the load-path –
introducing unnecessary modifications, which will – Murphy's Law – become 
persistent.

A „clean solution“ should avoid duplicated distribution of the same 
functionality – especially if one „shadows“ the other.

I suggest strongly to drop the duplicated parts from the main emacs-el and 
either only distribute as 'elpa' or move to distinct packages setting conflicts 
against the elpa version (and vice versa!) .

The problem of the duplicated 'elpa-org' distribution applies also to – on my 
system – to 'elpa-seq' and 'elpa-let-alist'.

Bug#1033656: bt full with dbgsym

[Mathieu Malaterre]

% gdb cjxl
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cjxl...
Reading symbols from
/usr/lib/debug/.build-id/ab/48fb952e2934f68e4c2a25c9f41febf3647a3a.debug...
(gdb) r
Starting program: /usr/bin/cjxl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
hwy::(anonymous namespace)::robust_statistics::CountingSort (values=0xbeffeda8, num_values=256) at
./hwy/nanobenchmark.cc:214
214   std::vector unique;
(gdb) bt full
#0  hwy::(anonymous
namespace)::robust_statistics::CountingSort
(values=0xbeffeda8, num_values=256) at ./hwy/nanobenchmark.cc:214
unique = std::vector of length 0, capacity 200277594
p = 
#1  0xb6e32256 in hwy::(anonymous
namespace)::robust_statistics::Mode
(num_values=256, values=0xbeffeda8) at ./hwy/nanobenchmark.cc:286
No locals.
#2  hwy::(anonymous namespace)::robust_statistics::Mode (values=...) at ./hwy/nanobenchmark.cc:292
No locals.
#3  hwy::platform::TimerResolution () at ./hwy/nanobenchmark.cc:480
samples = {1760, 680, 760, 720, 720, 760, 720, 640, 600, 680,
720, 720, 720, 720, 720, 640, 600, 680, 720, 720, 720, 720, 720, 640,
600, 680, 760, 720, 720, 720, 720, 680, 640, 680, 720, 760, 720,
  760, 720, 680, 640, 639, 720, 720, 720, 760, 720, 680, 600,
680, 720, 720, 760, 720, 720, 680, 640, 680, 720, 760, 720, 760, 720,
680, 600, 640, 720, 720, 720, 760, 720, 640, 600, 680, 760, 720,
  720, 720, 760, 680, 640, 680, 720, 720, 720, 720, 720, 680,
640, 680, 720, 720, 720, 760, 720, 680, 600, 680, 720, 720, 720, 760,
720, 680, 600, 640, 720, 760, 720, 720, 720, 680, 600, 640, 720,
  720, 760, 720, 720, 680, 600, 640, 720, 720, 720, 720, 720,
680, 640, 680, 720, 720, 760, 720, 720, 680, 600, 680, 760, 760, 720,
720, 720, 680, 600, 680, 760, 720, 720, 720, 720, 680, 600, 640,
  720, 760, 720, 720, 760, 680, 640, 680, 760, 720, 720, 720,
760, 680, 640, 680, 720, 720, 720, 720, 720, 680, 640, 680, 720, 720,
720, 760, 720, 680, 600, 680, 720, 720, 720, 760, 720, 680, 600,
  640, 720, 760, 720, 720, 720, 680...}
i = 
t0 = 
t1 = 
rep = 
can_use_stop = true
repetitions = {0 , 13186041144842129408, 1,
17592186044416, 15272538, 142541998690477, 17592186048511, 0, 1,
142541374619648, 5777693, 132592, 264, 2164, 1680014893, 15272538,
  1680014820, 620070873, 1680014820, 624070829, 1675175164, 0,
0, 4294967550, 0, 13762973729367785472, 13186241022805295247,
13185760231415605028, 545357767376899, 0, 0, 0, 0, 562949953421312,
  550391469175956, 4096, 562949953421317, 580748298035200,
17592186179636, 12885028864, 0, 204933623896, 13185811011904471040,
214748364800, 13186241019735179264, 13155823755177423432, 16089343920,
  13762973007813279746, 13185765720249593216, 0,
13185765720249593216, 0, 13185765720249593216, 0, 17595256270208,
16089343880, 13186532544935362560, 0, 13762975155296927744,
8309530817697147188,
  25769934848, 17595254339061, 580765477765120, 8589934595,
580768540979252, 65025, 5777693, 65025, 5777693, 4295000484, 0, 0,
132592, 4096, 264, 1680014893, 15272538, 1675175164, 0, 1680014820,
  13155827655007724148, 13186223049592012800,
13155827651937566720, 13185775014558756952, 13762975106961762556,
13185776139974469871, 13186226454276272160, 1, 3204442356, 1, 0,
4294967317,
  7365196392, 4294967306, 13762989606637072416, 2199023255566,
282579962709375, 0, 4297588739, 223338299392, 360292368236282336,
11259024840327220, 4296605722, 0, 550391469047808, 21474964628,
  4294971392, 578600814378556, 2147483782716, 25769804280,
8589938688, 579545707183896, 996432547608, 25769804008, 17179869188,
1047972020468, 154618822900, 17179869220, 7238662637146341380, 0, 0,
  25769803776, 7238662641441308688, 578600814378556,
1941325352508, 17179869636, 17179869185, 12884901908,
4116180958662970951, 6298471032490531664, 11912611826552620581,
38654705667, 25769803778,
  9799869300677419416, 42949672969, 17050484449554202637,
14311808551372633164, 16948032204727468581, 2814546232200178528,
215689415, 0, 0, 1136, 589827, 135212, 300649021443, 0, 68719476770,
0,
  100072738, 0, 876173328402, 0, 

Bug#1033656: HWY_CMAKE_ARM7:BOOL=ON vs Dynamic Dispatch

[Mathieu Malaterre]

Control: forwarded -1 https://github.com/google/highway/issues/1271

Technically we could just do a source upload with
HWY_CMAKE_ARM7:BOOL=OFF. HWY_CMAKE_ARM7:BOOL=ON is a hack for an old
clang version, if I understand correctly.

Bug#1033656: illegal hardware instruction cjxl

[Mathieu Malaterre]

Package: libjxl-tools
Version: 0.7.0-10
Severity: important

cjxl/djxl cannot be used on armhf neon-less system. They fails with:

% djxl
zsh: illegal hardware instruction  djxl

Full ref:

% gdb /usr/bin/cjxl
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/cjxl...
(No debugging symbols found in /usr/bin/cjxl)
(gdb) r
Starting program: /usr/bin/cjxl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0xb6e31fbe in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
(gdb) x/i $pc
=> 0xb6e31fbe:  vmov.i32d16, #0 @ 0x
(gdb) bt full
#0  0xb6e31fbe in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
#1  0xb6e32256 in hwy::platform::TimerResolution() () from
/usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
#2  0xb6e30e0e in ?? () from /usr/lib/arm-linux-gnueabihf/libhwy.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

On Wed, 2023-03-29 at 15:46 +0200, Cyril Brulebois wrote:
> Closing as not a bug. If you want an actual bug to get fixed, please
> file a specific bug report, describing what's not working correctly.

Well you could call usage of a non-documented option a bug, but if
improvement is apparently not desired, fine for me.

Cheers,
Chris.

Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

[Jesse Smith]

> 
> I think I have found the offending commit:
> 0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which 
> wipes
> the canonical resolved path.
> 
> I suggest this fix as a starting point.
> 

I'd agree. I was running into some situations where a symlink wasn't
recognized and this corrects the behaviour for me. Committed this patch
upstream.

- Jesse

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

On Wed, 2023-03-29 at 03:38 +, David wrote:
> I think the formal specification of the fstab format would be
> 'man 3 getfsent' because that is the canonical method to
> parse /etc/fstab.

Uhm, but that doesn't really describe which fields are necessary
either. So it would be the actual code which would be the definition...
but that's typically a bad idea to use as a standard.

Nevertheless, getfsent(3) still mentions "sw" and even "xx" and "rq".


> Perhaps 'sw' in field 4 became obsolete. What does it achieve?
> 
> It does seem redundant to have to specify both 'swap' and 'sw'
> for every swap partition. And if we have to specify 'sw' in field 4,
> how is it an "option"?

Well I guess it's an indication for the 4th field *not* being optional
and "defaults" not being considered (or even present back in BSD) for
swap.


> Anyway, just to be clear, I'm not the person advocating change here.

Sure, me neither. :-)

Just trying to find out what would be the "best" value (from a cosmetic
PoV).

For that purpose I posted at util-linux mailing list, asking for their
opinion and whether fstab(5) could be clarified accordingly:
https://lore.kernel.org/util-linux/45fc7a385b006d734011a11487fbfdda4333644e.ca...@christoph.anton.mitterer.name/T/#u


I think this issue here can be put on hold, until things have been
clarified there.


> I am simply sharing the fact that I have configured swap in
> /etc/fstab
> with blank field 4,5 and 6, as I showed previously, for as long as I
> can
> remember, without experiencing any problem. And I have explained
> my reasoning about that, when requested.

Sure,.. but for that purpose, "sw" could be simply kept either (it also
works). :-)

This issue was really just from the cosmetic PoV, about what is
considered to be the "canonical" way of doing it (if there's any).


Thanks,
Chris.

Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

[Mark Hindley]

On Wed, Mar 29, 2023 at 08:37:00AM -0300, Jesse Smith wrote:
> > Given subsequent discussion, could we instead use canonicalize_file_name
> > or realpath here instead? That would give us the "correct" path without
> > pidof having to think hard about symlinks et al.
> 
> I'm open to the possibility. I'm curious as to what you see as the pros
> vs cons of changing the approach used by pidof?

Markus' orginal report suggested this was a regression since Bullseye

 sysvinit-utils | 2.96-7+deb11u1 | stable | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

rather than a proposal to change behaviour.

I think I have found the offending commit:
0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which 
wipes
the canonical resolved path.

I suggest this fix as a starting point.

Mark

>From 346cc4a8a91f908c8a57a16fb041c44809517183 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 29 Mar 2023 13:57:24 +0100
Subject: [PATCH] Fix following of executable symlinks.

Fixes regression introduced in 0b695c7e0b1cac60ed77c56f224e296f023b652e
---
 src/killall5.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/killall5.c b/src/killall5.c
index b0728fab..787c4226 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -739,10 +739,8 @@ PIDQ_HEAD *pidof(char *prog)
 		return NULL;
 
 	/* Try to stat the executable. */
-	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
-		memset(_path[0], 0, sizeof(real_path));
+	if ( (prog[0] == '/') && ( realpath(prog, real_path) ) )
 		dostat++;
-	}
 
 	/* Get basename of program. */
 	if ((s = strrchr(prog, '/')) == NULL)
-- 
2.39.2

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[Alberto Garcia]

On Wed, Mar 29, 2023 at 02:33:14PM +0200, karogyoker999 wrote:
> Yes, it is still crashing by running it that way.

Do you think you would be able to obtain a core dump from one of those
crashes?

Berto

Bug#1033655: Also reported to flycheck project

[H.-Dirk Schmitt]

I also reported the Issue to the upstream project: 
https://github.com/flycheck/flycheck/issues/2014

Bug#1033655: elpa-flycheck: Emacs28 / flycheck is spawning wild running shellcheck processes eating up the system memory (oom-kill)

[H . -Dirk Schmitt]

Package: elpa-flycheck
Version: 32~git.20200527.9c435db3-3
Severity: grave
X-Debbugs-Cc: none, H.-Dirk Schmitt 


The combination of Emacs28 + elpa-flycheck + shellcheck in *bookworm* spawn 
never terminating shellcheck processes.
These are eating up the memory and trigger oom-kill.

**This renders my system unstable.**  It appears to be blocked minutes till the 
oem-kill cleans up some memory.


Analysis:
I have temporarly downgraded elpa-flycheck and shellcheck. The wild processes 
are still spawned.
So I assume that Emacs28 introduce a different behaviour here that is 
probematic for flycheck or shellcheck.


Mitigation:
As a mitigation I exclude the invocation of shellcheck in my Emacs setup:
`(customize-set-variable 'flycheck-disabled-checkers '(sh-shellcheck))`


Suggestion:
I suggest to add this mitigation temporarily to the elpa-flycheck package to 
avoid degraded systems untill a real
solution is found.


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

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

Versions of packages elpa-flycheck depends on:
ii  dh-elpa-helper 2.0.16
ii  elpa-dash  2.19.1+git20220608.1.0ac1ecf+dfsg-1
ii  elpa-let-alist 1.0.6-2
ii  elpa-pkg-info  0.6-6
ii  elpa-seq   2.23-1
ii  emacs  1:28.2+1-13
ii  emacs-gtk [emacs]  1:28.2+1-13
ii  emacsen-common 3.0.5

Versions of packages elpa-flycheck recommends:
ii  emacs  1:28.2+1-13
ii  emacs-gtk [emacs]  1:28.2+1-13

Versions of packages elpa-flycheck suggests:
pn  flycheck-doc  

-- no debconf information

Bug#1033654: akonadi broken with libmariadb from s-p-u

[Adi Kriegisch]

Package: libmariadb3
Version: 1:10.5.19-0+deb11u1

Dear maintainers,

when trying to use libmariadb3 from stable-proposed-updates, akonadi (the
backend service for kde's pim tools) does not work any more and shows the
following error messages on the console:
  | org.kde.pim.akonadiserver: New notification connection
  | (registered as Akonadi::Server::NotificationSubscriber(0x7effcc0840e0) )
  | org.kde.pim.akonadiserver: DATABASE ERROR:
  | org.kde.pim.akonadiserver:   Error code: "1292"
  | org.kde.pim.akonadiserver:   DB error:  "Incorrect datetime value:
  | '2023-03-29T12:31:24Z' for column `akonadi`.`pimitemtable`.`atime` at 
row 1"
  | org.kde.pim.akonadiserver:   Error text: "Incorrect datetime value:
  | '2023-03-29T12:31:24Z' for column `akonadi`.`pimitemtable`.`atime` at 
row 1
  | QMYSQL: Unable to execute query"
  | org.kde.pim.akonadiserver:   Values: QMap((":0", QVariant(QDateTime,
  | QDateTime(2023-03-29 12:31:24.551 UTC Qt::UTC)))(":1", 
QVariant(qlonglong, 18)))
  | org.kde.pim.akonadiserver:   Query: "UPDATE PimItemTable SET atime = :0 
WHERE
  | ( PimItemTable.collectionId = :1 )"
  | org.kde.pim.akonadiserver: Unable to update item access time

Downgrading to 1:10.5.18-0+deb11u1 immediately fixes the issue. It would be
great if it was possible to tackle down this issue before the broken
package enters stable for the next point release. Please let me know if
there is anything I can do to help!

all the best,
Adi


signature.asc
Description: PGP signature

Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting

[karogyoker999]

Yes, it is still crashing by running it that way.

Alberto Garcia  ezt írta (időpont: 2023. márc. 29.,
Sze, 12:58):
>
> On Wed, Mar 29, 2023 at 06:22:25AM -0400, Karo Gyoker wrote:
>
> > If I try to open any page in epiphany-browser, nothing happens. The CPU is 
> > at 100%.
> > I can see it in dmesg that WebKitWebProcess is constantly segfaulting.
> >
>
> > cat /proc/cpuinfo
> > processor : 0
> > vendor_id : AuthenticAMD
> > cpu family: 6
> > model : 10
> > model name: AMD Athlon(tm)
>
> Can you try to set JavaScriptCoreUseJIT=0 in the environment and try
> again? Does it still crash?
>
> $ export JavaScriptCoreUseJIT=0
> $ epiphany-browser
>
> Berto

Bug#1033640: kea-lfc missing read access to /etc/resolv.conf

[Andreas Hasenack]

Hi,

On Wed, Mar 29, 2023 at 5:12 AM Markus Viitamäki  wrote:
>
> Package: kea-common
> Version: 2.2.0-5
>
> System:
> Debian 12 (Bookworm)
> Linux dhcp 6.1.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05) 
> x86_64 GNU/Linux
>
> Error (syslog):
> [Wed Mar 29 08:05:59 2023] audit: type=1400 audit(1680069960.544:88): 
> apparmor="DENIED" operation="open" profile="kea-lfc" name="/etc/resolv.conf" 
> pid=6641 comm="kea-lfc" requested_mask="r" denied_mask="r" fsuid=102 ouid=0
>
> The problem can be solved by doing this (but not sure if that's intended):
>
> diff /tmp/usr.sbin.kea-lfc.orig /etc/apparmor.d/usr.sbin.kea-lfc
> 13a14
> >   /etc/resolv.conf r,

So your /etc/resolv.conf is not a symlink to
/run/systemd/resolve/stub-resolv.conf?

Bug#1033653: bullseye-pu: package lemonldap-ng/2.0.11+ds-4+deb11u

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lemonldap...@packages.debian.org, secur...@debian.org
Control: affects -1 + src:lemonldap-ng

[ Reason ]
lemonldap-ng is vulnarable to a second factor bypass when used with an
"AuthBasic handler" (generally used for non-browser apps).

[ Impact ]
Medium security issue.

[ Tests ]
New test proves that issue is fixed

[ Risks ]
Low risk, patch isn't so big and test coverage looks good

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

[ Changes ]
No more allow to accept basic authentication in AuthBasic handler when a
second factor is required, add also an environment variable to restore
previous behavior.

[ Other info ]
I didn't pushed yet the already accepted patch for deb11u3 (#1030598).
Maybe we could join and push directly deb11u4 into Bullseye.

Cheers,
Yadd
diff --git a/debian/NEWS b/debian/NEWS
index b8955920b..c4d7ee951 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,15 @@
+lemonldap-ng (2.0.11+ds-4+deb11u4) bullseye; urgency=medium
+
+  AuthBasic now enforces 2FA activation (CVE-2023-28862):
+  In previous versions of LemonLDAP::NG, a 2FA protected account didn't need
+  to use their second factor when authenticating to an AuthBasic handler.
+  If you want 2FA protected accounts to access AuthBasic handlers, which are
+  password only, you can add the following test in your 2FA activation rules:
+
+and not $ENV{AuthBasic}
+
+ -- Yadd   Wed, 29 Mar 2023 15:24:20 +0400
+
 lemonldap-ng (2.0.9+ds-1) unstable; urgency=medium
 
   CVE-2020-24660
diff --git a/debian/changelog b/debian/changelog
index b6f666f69..5d2c62ac0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+lemonldap-ng (2.0.11+ds-4+deb11u4) bullseye; urgency=medium
+
+  * Fix 2FA issue when using AuthBasic handler (CVE-2023-28862)
+
+ -- Yadd   Wed, 29 Mar 2023 15:50:40 +0400
+
 lemonldap-ng (2.0.11+ds-4+deb11u3) bullseye; urgency=medium
 
   * Fix URL validation bypass
diff --git a/debian/patches/CVE-2023-28862.patch 
b/debian/patches/CVE-2023-28862.patch
new file mode 100644
index 0..9fb5d9d23
--- /dev/null
+++ b/debian/patches/CVE-2023-28862.patch
@@ -0,0 +1,401 @@
+Description: fix AuthBasic security issue when used with second factor
+ To simplify, AuthBasic accepted connections even if 2FA failed
+Author: Yadd 
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2896
+Forwarded: not-needed
+Applied-Upstream: 2.16.1, 
(https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/merge_requests/334)
+Last-Update: 2023-03-29
+
+--- a/doc/sources/admin/upgrade_2_0_x.rst
 b/doc/sources/admin/upgrade_2_0_x.rst
+@@ -26,6 +26,19 @@
+ 
+ None
+ 
++2.16.1
++
++
++AuthBasic now enforces 2FA activation
++~
++
++In previous versions of LemonLDAP::NG, a 2FA protected account didn't need to 
use their second factor when authenticating to an :doc:`AuthBasic handler 
`.
++
++If you are *absolutely sure* that you want 2FA protected accounts to access 
AuthBasic handlers, which are password only, you can add the following test in 
your 2FA activation rules ::
+++
+++and not $ENV{AuthBasic}
+++
+++
+ 2.0.11
+ --
+ 
+--- a/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Lib/AuthBasic.pm
 b/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Lib/AuthBasic.pm
+@@ -28,9 +28,8 @@
+ my ( $class, $req ) = @_;
+ if ( my $creds = $req->env->{'HTTP_AUTHORIZATION'} ) {
+ $creds =~ s/^Basic\s+//;
+-my @date = localtime;
+-my $day  = $date[5] * 366 + $date[7];
+-return Digest::SHA::sha256_hex( $creds . $day );
++my $pepper = int( time / $class->tsv->{timeout} ) . 
$class->tsv->{keyH};
++return sha256_hex( $creds . $pepper );
+ }
+ else {
+ return 0;
+--- a/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Main/Reload.pm
 b/lemonldap-ng-handler/lib/Lemonldap/NG/Handler/Main/Reload.pm
+@@ -5,6 +5,7 @@
+ package Lemonldap::NG::Handler::Main;
+ 
+ use strict;
++use Digest::SHA qw(sha256_hex);
+ use Lemonldap::NG::Common::Conf::Constants;#inherits
+ use Lemonldap::NG::Common::Crypto;
+ use Lemonldap::NG::Common::Safelib;#link protected safe Safe 
object
+@@ -208,6 +209,7 @@
+ );
+ 
+ $class->tsv->{cipher} = Lemonldap::NG::Common::Crypto->new( $conf->{key} 
);
++$class->tsv->{keyH}   = sha256_hex( $conf->{key} );
+ 
+ foreach my $opt (qw(https port maintenance)) {
+ 
+--- a/lemonldap-ng-portal/MANIFEST
 b/lemonldap-ng-portal/MANIFEST
+@@ -579,6 +579,7 @@
+ t/35-My-session.t
+ t/35-REST-config-backend.t
+ t/35-REST-export-password.t
++t/35-REST-sessions-with-AuthBasic-handler-with-2FA.t
+ t/35-REST-sessions-with-AuthBasic-handler.t
+ t/35-REST-sessions-with-REST-server.t
+ 

Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

[Matthew Vernon]

On 29/03/2023 12:37, Jesse Smith wrote:

Given subsequent discussion, could we instead use canonicalize_file_name
or realpath here instead? That would give us the "correct" path without
pidof having to think hard about symlinks et al.



I'm open to the possibility. I'm curious as to what you see as the pros
vs cons of changing the approach used by pidof?


Broadly, I think there is an expectation that
pidof $(which emacs)

works on Debian (et al) systems where alternatives are in use (or other 
setups with >1 symlink), regardless of which user is running the emacs 
(WLOG).


I think using realpath or canonicalize_file_name might simplify matters? 
But I've not gone poking through the code in detail, just this talk of 
more than one symlink confusing things made me think of these library 
functions.


Perhaps as an aside, on my system with 3.06-2, I see different behaviour 
depending on the user running the binary:


matthew@aragorn:~/junk$ ps waux | grep emacs
root  3905  0.0  0.0 165344  3976 tty1 TMar06   0:00 emacs 
/etc/mumble-server.ini
matthew   5149  0.0  1.0 453684 169224 ?   Ss   Feb11  61:26 emacs 
--daemon
matthew  13119  0.0  0.3 214776 50076 pts/19   SFeb27   0:37 emacs 
accparse.py

matthew@aragorn:~/junk$ pidof emacs
13119 5149 3905
matthew@aragorn:~/junk$ pidof $(which emacs)
3905
matthew@aragorn:~/junk$ pidof $(readlink -f $(which emacs))
13119 5149

Here $(which emacs) -> /usr/bin/emacs -> /etc/alternatives/emacs -> 
/usr/bin/emacs-lucid


So the root process is picked up with pidof /usr/bin/emacs and the user 
processes by pidof /usr/bin/emacs-lucid.

pidof emacs picks up all three.

In each case /proc/pid/exe is (a deleted version of) /usr/bin/emacs-lucid

HTH,

Matthew

Bug#1033650: sddm: InputMethod=qtvirtualkeyboard not working

[noleak . debianreportbug]

I installed qtvirtualkeyboard-plugin and now it's working, which is 
slightly embarrassing.

thanks

On 29/03/2023 12:01, dieselnutjob wrote:

Package: sddm
Version: 0.19.0-5
Severity: normal
X-Debbugs-Cc: noleak.debianreport...@pscan.uk

Dear Maintainer,
Hi. I am using plasma-mobile on a tablet (PineTab2)
therefore using the device without a keyboard is important.
I created /etc/sddm.conf

[General]
InputMethod=qtvirtualkeyboard

but I don't get a virtual keyboard.

thanks

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

Kernel: Linux 6.2.0-1-danctnix (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 sddm depends on:
ii  adduser 3.131
ii  debconf [debconf-2.0]   1.5.82
ii  libc6   2.36-8
ii  libgcc-s1   12.2.0-14
ii  libpam0g1.5.2-6
ii  libqt5core5a5.15.8+dfsg-3
ii  libqt5dbus5 5.15.8+dfsg-3
ii  libqt5gui5  5.15.8+dfsg-3
ii  libqt5network5  5.15.8+dfsg-3
ii  libqt5qml5  5.15.8+dfsg-3
ii  libqt5quick55.15.8+dfsg-3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1
ii  libxcb-xkb1 1.15-1
ii  libxcb1 1.15-1
ii  qml-module-qtquick2 5.15.8+dfsg-3
ii  x11-common  1:7.7+23
ii  xauth   1:1.1.2-1
ii  xserver-xorg [xserver]  1:7.7+23

Versions of packages sddm recommends:
ii  libpam-systemd 252.6-1
ii  sddm-theme-breeze [sddm-theme] 4:5.27.2-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.27.2-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.27.2-1
pn  qtvirtualkeyboard-plugin  

-- debconf information:
   sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#1033625:

[Brian Potkin]

On Wed 29 Mar 2023 at 11:36:50 +0200, Johan Kröckel wrote:

> root@stockholm:~#  lpstat -l -e
> Kyocera_ECOSYS_M5526cdw network none
> ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/

Printiing should take place with

  lp -d Kyocera_ECOSYS_M5526cdw /etc/nsswitch.conf

Does it?

> root@stockholm:~# driverless
> ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/

A print queue can also be manually set up by

  lpadmin -p M5526cdw -v "ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/" 
-E -m everywhere

Test printing with

  lp -d M5526cdw /etc/nsswitch.conf

Cheers,

Brian.

Bug#1033652: Instead of saying "it" say the actual package name

[Dan Jacobson]

Package: aptitude
Version: 0.8.13-5
Severity: minor

$ aptitude purge -s debian-archive-keyring
The following packages will be REMOVED:
  debian-archive-keyring{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 276 kB will be freed.
The following packages have unmet dependencies:
 apt : Depends: debian-archive-keyring but it is not going to be installed

Not going to be installed? it is already installed:
$ apt-show-versions apt
apt:amd64/unstable 2.6.0 uptodate

Oh, the problem is that "it" isn't clear.

So, instead of saying "it", say the actual package name you mean!