Bug#1064810: transition: mpi-defaults

[Alastair McKinstry]

On 05/05/2024 16:59, Sebastiaan Couwenberg wrote:

On 2/26/24 7:40 AM, Alastair McKinstry wrote:
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to 
MPICH.


This transition is blocking many of the remaining packages rebuilt for 
64-bit time_t.


The autopkgtest for slurm-wlm on i386 is blocking testing migration of 
mpich:


 https://qa.debian.org/excuses.php?package=mpich

Testing migration of openmpi is likewise blocked by autopkgtest 
failures on i386 of several rdeps:


 https://qa.debian.org/excuses.php?package=openmpi

I'm starting to think that it'd be better to drop support for 32bit 
architectures from all these rdeps so they can just use openmpi 
everywhere and not have i386 autopkgtest failures able to block 
testing migration.


Should we advocate this to the maintainer of these packages or is 
there something else we can do to improve this situation?


Dropping 32-bit support for so many packages is a bit more radical than 
I had considered, but I'd go with it.


Regards

Alastair



Kind Regards,

Bas


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: mckins...@debian.org, im: @alastair:mckinstry.ie

Bug#1069600: Fwd: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

[Paul Gevers]

Hi,

On 05-05-2024 8:04 p.m., Andreas Beckmann wrote:
167s autopkgtest [09:50:25]: test test-dm-writeboost.sh: 
[---

168s II: Checking for 14G available disk space...SKIP


How much disk space is used already by the time you get to this test? 
The root of the testbed has 25 GB total (starting off with 990 MB used), 
so your test has 24 GB to use (including installing test dependencies).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070476: openjdk-21: autopkgtest on i386: /usr/bin/ld: /usr/lib/jvm/java-21-openjdk-i386/lib/server/libjvm.so: undefined reference to `_SafeFetch32_impl'

[Sebastian Ramacher]

Source: openjdk-21
Version: 21.0.3+9-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

openjdk-21 is unable to migrate since the version in unstable fails its
autopkgtests on i386.

https://ci.debian.net/packages/o/openjdk-21/testing/i386/46308616/#S21

9507s autopkgtest [09:27:46]: test jni-link.sh: [---
9507s /usr/lib/jvm/java-21-openjdk-i386/lib/server
9507s /usr/bin/ld: /usr/lib/jvm/java-21-openjdk-i386/lib/server/libjvm.so: 
undefined reference to `_SafeFetch32_impl'
9507s collect2: error: ld returned 1 exit status
9508s autopkgtest [09:27:47]: test jni-link.sh: ---]


Cheers
-- 
Sebastian Ramacher

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Paul Gevers]

Hi Luca,

On 05-05-2024 10:04 p.m., Luca Boccassi wrote:

> Hence, I intend to apply these changes in the next src:systemd upload
> to unstable, probably next week.


In case anybody is aware of packages/programs needing an update to cope
with these changes, or any other issue, please let me know and I will
file bugs.


You filed MR341 against autopkgtest, thanks for that. Can you please 
hold off a bit longer than only one week to get the infrastructure 
updated? I'm confident that every test that has the needs-reboot 
restriction will start failing (which are only 21 tests according to 
codesearch). However, I fear that every test is at risk under common 
circumstances.


I don't want to be rushed into an autopkgtest update and an 
infrastructure update for something that we can plan (there's always 
risk involved and I want to have the time and peace to cope with the 
process). Having said that, maybe we will be ready next week.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070475: xscreensaver frightens privacy-aware users without necessity

[Guenther Brunthaler]

Package: xscreensaver
Version: 6.06+dfsg1-3+deb12u1

### Issue description

Currently (2024-05), on a "stable" installation which is up-to-date,
xscreensaver displays a message that it is too old and should be
updated.

Security-aware users might think that xscreensaver contacted upstream's
servers without any permission, possibly transmitting private
information about the user account or the user's machine as part of the
update check.

Such fears are not totally unjustified, because in fact a lot of
widely-used commercial software actually spies on the users via frequent
"update checks". It is less common in open source software, but seeing
a warning like the one displayed by xscreensaver makes privacy-aware
users nervous.

At least that's what I thought initially: "What has the world come
to! Now even trusty old xscreensaver is spying on me, too."

However, a web search quickly found a patch which disables this
warning. And in the patch's unified diff context one could see that
the warning is triggered by a clock check, not by frequently
contacting some upstream server.

Instead, the warning goes off if the xscreensaver version is older than
17 months.

In other words, it is totally harmless.

The update check does not spy on anyone, and does not endanger one's
privacy.

As I read in bug #819703, the author does not wish this warning message
to be removed.

This is acceptable.

But then the warning message should be augmented by additional
information, making it clear that this warning message has only be
triggered by comparing the system time, and not by periodically
contacting some upstream server without permission and transmitting
data about the user or his system configuration to some upstream server.

### Expected behaviour

The actual warning should be displayed as the author demands.

It does not matter how stupid this is on a distro like Debian "stable",
where time-tested versions are preferred over less-tested but more
recent versions as long as no problems are discovered.

This is what the author wants, and his wishes should be honored.

But the warning message should be patched to display *additional* text
which makes it clear that this warning is benign and not the result of
periodically accessing the Internet without permission.

The author only demands that his warning shall not be removed. He has so
far not expressed any objections against clarifying it by augmentation.

### External links

None.

Bug#1069234: bcftools: gff2gff.py and guess-ploidy.py fails to run

[Giulio Genovese]

Dear Andreas,

I understand with commit a46c2e25

the bcftools debian package has acquired the new python3-gffutils and
python3-matplotlib dependencies. I used this debian package to build some
minimalistic dockers but this has now ballooned the size of my dockers from
~100MB to >600MB.

Would it be possible to have these required dependencies changed to
suggested dependencies? BCFtools is mostly software written in C with
minimal dependencies and to see it changed to a package with >10x as many
required dependencies kind of removes this minimalism philosophy.

Something similar was done with the bwa debian package where the perl
required dependency was moved to a suggested dependency. This seems to have
made all parties happy. It would be great if the same philosophy could be
applied to the bcftools debian package.

Giulio

Bug#1070473: debhelper: Run dh_installsysusers after dh_installtmpfiles

[Jeremy Bícha]

Source: debhelper
Version: 13.15.3
Control: affects -1 src:gnome-remote-desktop
X-Debbugs: syst...@packages.debian.org

gnome-remote-desktop 46 upstream has decided to implement both
tmpfiles.d and sysusers.d to create a system user and its home
directory. systemd-tmpfiles needs to run before systemd-sysusers. If
not, on a new install, this command hangs for about 90 seconds:

Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with UID
*** and GID ***.

Then this error:
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.

Then the installation completes successfully.

Therefore, I recommend that debhelper automatically runs
dh_installtmpfiles before running dh_installsysusers in case any other
projects want to do what gnome-remote-desktop does.

I was able to workaround this issue:
https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/8490919

Thank you,
Jeremy Bícha

Bug#1033012:

[Marco d'Itri]

On Jan 12, Yangfl  wrote:

> Please kindly check 2.3.4-1 to see if that fixed your problem.
It does not. The problem is that TasksMax in miniupnpd.service is set 
too low. Set it to something like 10, because it makes no sense to count 
every single process and it is hard anyway when spawning shell scripts.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1070472: Uses the obsolete /sbin/route without a dependency

[Marco d'Itri]

Package: miniupnpd
Version: 2.3.1-1
Severity: serious
Tags: patch

Pseudo-patch for miniupnpd.config:

-   MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C /sbin/route | grep -m 1 default 
| awk -- '{ print $8 }')
+   MiniUPnPd_EXTERNAL_INTERFACE=$(LC_ALL=C ip -o route show | sed -nre 
'/^default /s/^default .*dev ([^ ]+).*/\1/p')

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1070471: ITP: wayfire-shadows -- Window Shadows Plugin for Wayfire

[Boyuan Yang]

Package: wnpp
Owner: Boyuan Yang 
Severity: wishlist

* Package name: wayfire-shadows 
  Version : 0.0~git20240327.81699f6
  Upstream Contact: Tim Göttlicher
* URL : https://github.com/timgott/wayfire-shadows
* License : Expat
  Programming Lang: C
  Description : Window Shadows Plugin for Wayfire

 Wayfire is a 3D Wayland compositor, inspired by Compiz and based on
 wlroots. It aims to create a customizable, extendable and lightweight
 environment without sacrificing its appearance.
 .
 By default, the plugin will add fast and nice shadows around windows
 that use server side decorations. Additionally there is an option to
 make the focused window glow.


Thanks,
Boyuan Yang


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

Bug#1070300: pmix_psquash_base_select failed during MPI_INIT on 32bit architectures

[Samuel Thibault]

Samuel Thibault, le sam. 04 mai 2024 11:49:40 +0200, a ecrit:
> Samuel Thibault, le ven. 03 mai 2024 19:00:22 +0200, a ecrit:
> > This has been posing migration issues for quite some time, I have
> > uploaded the attached fix to delayed/0.
> 
> Some of the components depend on libmca_common_libdstore which also
> needs to be installed, otherwise openmpi emits some text on stderr,
> which some autopkgtest don't like, I have uploaded the attached changes
> to delayed/0

Sorry it seems my tests had gone bogus, I do remember testing the result
but apparently obviously failed to. I have double-checked my changes
this time, as attached and uploaded to delayed/0 (now that openmpi got a
bit force-migrated to testing)

Samuel
diff -Nru openmpi-4.1.6/debian/changelog openmpi-4.1.6/debian/changelog
--- openmpi-4.1.6/debian/changelog  2024-05-04 11:32:26.0 +0200
+++ openmpi-4.1.6/debian/changelog  2024-05-05 20:38:36.0 +0200
@@ -1,3 +1,10 @@
+openmpi (4.1.6-13.3) unstable; urgency=medium
+
+  * Non-maintainer Upload
+  * Really install libmca_common_dstore.
+
+ -- Samuel Thibault   Sun, 05 May 2024 20:38:36 +0200
+
 openmpi (4.1.6-13.2) unstable; urgency=medium
 
   * Non-maintainer Upload
diff -Nru openmpi-4.1.6/debian/rules openmpi-4.1.6/debian/rules
--- openmpi-4.1.6/debian/rules  2024-05-04 11:32:26.0 +0200
+++ openmpi-4.1.6/debian/rules  2024-05-05 20:38:36.0 +0200
@@ -289,10 +289,11 @@
dh_install -p libopenmpi3t64 
$(LIBDIR)/openmpi/lib/libpmix.so.2.2.35 $(LIBDIR) ; \
dh_install -p libopenmpi3t64 /usr/share/pmix ; \
dh_install -p libopenmpi3t64 
"/usr/lib/$(DEB_HOST_MULTIARCH)/openmpi/lib/pmix/*.so" ; \
-   if test -f 
$(DESTDIR)/$(LIBDIR)/openmpi/lib/libmca_common_libdstore.so.1.0.2 ; then \
-   dh_install -p libopenmpi3t64 
$(LIBDIR)/libmca_common_libdstore.so.1.0.2 ; \
-   dh_link -p libopenmpi3t64
$(LIBDIR)/libmca_common_libdstore.so.1.0.2 
$(LIBDIR)/libmca_common_libdstore.so.1 ; \
-   dh_link -p libopenmpi-dev 
$(LIBDIR)/libmca_common_libdstore.so.1  $(LIBDIR)/libmca_common_libdstore.so ; \
+   if test -f 
$(DESTDIR)/$(LIBDIR)/openmpi/lib/libmca_common_dstore.so.1.0.2 ; then \
+   dh_install -p libopenmpi3t64 
$(LIBDIR)/openmpi/lib/libmca_common_dstore.so.1.0.2 $(LIBDIR) ; \
+   dh_link -p libopenmpi3t64 
$(LIBDIR)/libmca_common_dstore.so.1.0.2 $(LIBDIR)/libmca_common_dstore.so.1 ; \
+   dh_link -p libopenmpi-dev 
$(LIBDIR)/libmca_common_dstore.so.1   
$(LIBDIR)/openmpi/lib/libmca_common_dstore.so ; \
+   dh_link -p libopenmpi-dev 
$(LIBDIR)/libmca_common_dstore.so.1   $(LIBDIR)/libmca_common_dstore.so ; \
fi ; \
dh_link -p libopenmpi3t64 $(LIBDIR)/libpmix.so.2.2.35 
$(LIBDIR)/libpmix.so.2  ; \
dh_link -p libopenmpi-dev $(LIBDIR)/libpmix.so.2
$(LIBDIR)/openmpi/lib/libpmix.so ; \

Bug#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[Bernhard Übelacker]

Hello,
this seems to be the same issue as here:

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

And the fix seems to be prepared here:
https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef

Kind regards,
Bernhard

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dixi quod…

>values). I’ll build it now so I don’t know if it even compiles yet…

font.hhea.ascender = TO_TTF(properties.ascent.toReal());
font.hhea.descender = TO_TTF(-properties.descent.toReal());
font.hhea.lineGap = TO_TTF(properties.leading.toReal());

Bug#1069432: mpi4py: FTBFS on armhf: ld: cannot find -llmpe: No such file or directory

[Drew Parsons]

Source: mpi4py
Followup-For: Bug #1069432

There have been ongoing issues with OpenMPI on 32-bit architectures,
partly related to drop of 32-bit support by pmix.

This bug is likely related to that i.e. not a bug in mpi4py itself.

Bug#947958: Re #947958: adns FTCBFS: help2man

[Ian Jackson]

Hi.  In 2020 you wrote:

> adns fails to cross build from source, because it uses help2man. In
> this case, we can simply rebuild adns for the build architecture to
> run help2man. Please consider applying the attached patch or stop
> using help2man.

I don't think I want to stop using help2man.  But, I would love to
have considered your patch today (finally!).  Unfortunately you seem
to have omitted to attach it.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED ./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0

[Ian Jackson]

Dan Bungert writes ("Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED 
./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0"):
> I took a look at this bug today.
> I found that the regress testsuite make use of some negative offsets, which
> seem to perplex the reader on 32 bit systems.
> 
> Please see the attached patch, which has allowed this to build for Ubuntu.

Thanks.  I fixed the problem a little differently, in an upstream
release.  (Your patch didn't work for me.)

I have just uploaded to Debian too.  You may wish to pick up upstream
1.6.1 via Debian's 1.6.1-1 (or wait for it to build and migrate, maybe).

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1057620: doomsday: Crashes on startup

[Bernhard Übelacker]

On Tue, 05 Dec 2023 23:39:39 + Witold Baryluk  
wrote:


Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault.
0x75419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x75419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6
#1  0x7541cb3d in _XGetRequest () at /lib/x86_64-linux-gnu/libX11.so.6
#2  0x7540fa57 in XQueryExtension () at 
/lib/x86_64-linux-gnu/libX11.so.6
#3  0x75402b16 in XInitExtension () at /lib/x86_64-linux-gnu/libX11.so.6
#4  0x753cdc9b in XextAddDisplay () at 
/lib/x86_64-linux-gnu/libXext.so.6
#5  0x7538a860 in  () at /lib/x86_64-linux-gnu/libXrandr.so.2
#6  0x7538afc0 in XRRQueryExtension () at 
/lib/x86_64-linux-gnu/libXrandr.so.2
#7  0x7798bae4 in de::internal::RRInfo::RRInfo() () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#8  0x7798b02d in DisplayMode_Native_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#9  0x7791fd11 in DisplayMode_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#10 0x5573eb1d in ClientApp::initialize() ()
#11 0x5572175d in main ()
(gdb) 



Running under gnome shell.

xwayland 2:23.2.2-1



Hello,
I am not maintainer of the doomsday package, just tried to collect some
more information.

Bug 1062969 / Bug 1065714 mentions a workaround
to be able to run doomsday with wayland:

SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday


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


It looks like upstream removed the relevant code and relies just
on SDL functions, but unfortunately did not release a new version yet.


https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861


Kind regards,
Bernhard
# 2024-05-05 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump task-gnome-desktop tmux git gdb rr doomsday 
doomsday-dbgsym doomsday-common-dbgsym libxrandr2-dbgsym libxext6-dbgsym 
libx11-6-dbgsym
apt build-dep libx11-6




mkdir /home/benutzer/source/libx11-6/orig -p
cd/home/benutzer/source/libx11-6/orig
apt source libx11-6




benutzer@debian:~$ doomsday
QSocketNotifier: Can only be used with threads started with QThread
Speicherzugriffsfehler (Speicherabzug geschrieben)


benutzer@debian:~$ coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
   SIZE
Sun 2024-05-05 16:04:00 CEST 2967 1000 1000 SIGSEGV present  
/usr/games/doomsday-2.3.1 2.7M


benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 2967
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 2967 (doomsday)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2024-05-05 16:04:00 CEST (1min 51s ago)
  Command Line: doomsday
Executable: /usr/games/doomsday-2.3.1
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
  Unit: user@1000.service
 User Unit: vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
 Slice: user-1000.slice
 Owner UID: 1000 (benutzer)
   Boot ID: 13ee1fcd8e5043bf91db85c4d1c72a51
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.doomsday.1000.13ee1fcd8e5043bf91db85c4d1c72a51.2967.171491784000.zst
 (present)
  Size on Disk: 2.7M
   Message: Process 2967 (doomsday) of user 1000 dumped core.

Module libblkid.so.1 from deb util-linux-2.40-8.amd64
Module libmount.so.1 from deb util-linux-2.40-8.amd64
Module libsystemd.so.0 from deb systemd-255.5-1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 2967:
#0  0x7effce83 _XFlush (libX11.so.6 + 0x44e83)
#1  0x7effc0003b3d _XGetRequest (libX11.so.6 + 0x47b3d)
#2  0x7effbfff6a57 XQueryExtension (libX11.so.6 + 0x3aa57)
#3  0x7effbffe9b16 XInitExtension (libX11.so.6 + 0x2db16)
#4  0x7effc1b9bc9b XextAddDisplay (libXext.so.6 + 0xdc9b)
#5  0x7effc0ce484f n/a (libXrandr.so.2 + 0x284f)
#6  0x7effc0ce4f88 XRRQueryExtension (libXrandr.so.2 + 
0x2f88)
#7  0x7effc25af3b1 _ZN2de8internal6RRInfoC1Ev 
(libdeng_gui.so.2.3 + 0xe03b1)
#8  0x7effc25ae7ef DisplayMode_Native_Init 
(libdeng_gui.so.2.3 + 0xdf7ef)
#9  0x7effc253e619 DisplayMode_Init (libdeng_gui.so.2.3 + 
0x6f619)
#10 0x560786a6520d _ZN9ClientApp10initializeEv 
(doomsday-2.3.1 + 0x1fc20d)
#11 0x560786a469d1 main 

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Jussi Pakkanen]

On Sun, 5 May 2024 at 04:33, Shmerl  wrote:

> May be for rustc? It's worth filing the bug if it's not clear what the
> root cause is. If it's not really rustc, developers will point that out.

Filed:

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

Bug#1070445: numpy: Proposal to bring back the python-numpy-doc package

[Timo Röhling]

Hi Michael,

* Michael R. Crusoe  [2024-05-05 15:30]:
I would like to bring back the python-numpy-doc binary package as 
part of my personal interest in seeing high quality -doc packages 
in the Python scientific/research computing area.

You beat me to the punch :) Thanks for your work!

Here are my proposed changes: 
https://salsa.debian.org/python-team/packages/numpy/-/tree/debian/experimental?ref_type=heads
Looks good to me, except for a few minor issues and personal 
preferences, which I pushed to the branch.


If you approve of re-introducing the python-numpy-doc binary 
package, then I'll make a team upload to the NEW queue in the 
'experimental' distribution. Once that is accepted by the FTP team, 
then I'll merge my changes into the 'debian/unstable' branch for 
the next upload of the numpy source package.
Yes, please go ahead, but note that the debian/unstable branch is 
stale and main development happens on the master branch at the 
moment.


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1070470: Rustc fails linking C code on some platforms

[Jussi Pakkanen]

Package: rustc
Version: 1.70.0+dfsg2-1

Attached is a simple program that combines Rust and C code with a
statically compiled version of zlib. The project also has a shell
script that compiles the code using only cc, ar and rustc, so there
are no build systems or anything else within to mix things up.

The project compiles and runs on x86_64 but fails on (at least) x86
and aarch64 complaining about some missing symbols with leading double
underscores.

I don't know what the correct behaviour here is but since the commands
are the same the outcome should at least be identical on all
platforms.

This issue is blocking Meson transition to testing as bug number
#1059223 but as shown by the project the underlying issue can be
replicated without Meson.

Thanks,


rustcmixbug.tar.gz
Description: application/gzip

Bug#1054420: RFS: js2-mode/0.0~git20230628.79bc78d-1 [RC] [Team] -- Emacs mode for editing Javascript programs

[Xiyue Deng]

Control: retitle -1 RFS: js2-mode/0.0~git20240418.9b90d31-1 [RC] [Team] -- 
Emacs mode for editing Javascript programs

Hi,

A new snapshot was available and I have updated the package according
with a few more improvements.  Please find the latest package on
mentors[1] and changes on salsa[2] (sans the finalizing commit.)

TIA!

[1] https://mentors.debian.net/package/js2-mode/
[2] https://salsa.debian.org/emacsen-team/js2-mode

-- 
Xiyue Deng

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dixi quod…

>>Now that you dug so deeply, maybe you can try to replace qRound in those
>>three lines that you mentioned with TO_TTF, and check if it fixes the bug
>
>That *and* figure out somehow how to fix the PDF /FontBBox, at

I’m trying this (attached). That does both (by letting toTruetype()
adjust the already-existing scaling factor in the caller) and
applies suitable rounding (normal for normal values, away from zero
for the bounding box so it’s guaranteed to encompass all possible
values). I’ll build it now so I don’t know if it even compiles yet…

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/changelog 
qtbase-opensource-src-5.15.2+dfsg/debian/changelog
--- qtbase-opensource-src-5.15.2+dfsg/debian/changelog  2021-07-02 
17:58:04.0 +0200
+++ qtbase-opensource-src-5.15.2+dfsg/debian/changelog  2024-05-05 
23:58:03.0 +0200
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.15.2+dfsg-9.0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/bug1070406.diff
+
+ -- Thorsten Glaser   Sun, 05 May 2024 23:58:03 +0200
+
 qtbase-opensource-src (5.15.2+dfsg-9) unstable; urgency=medium
 
   * Revert adding fix-misplacement-of-placeholder-text-in-QLineEdit.diff.
diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff 
qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
--- qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
1970-01-01 01:00:00.0 +0100
+++ qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff
2024-05-05 23:57:53.0 +0200
@@ -0,0 +1,107 @@
+Description: scale /FontBBox and hhea table when scaling fonts
+ for embedding (the OS/2 table needs handling XXX TODO)
+Author: mirabilos 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406
+
+--- a/src/gui/painting/qpdf.cpp
 b/src/gui/painting/qpdf.cpp
+@@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR
+ "endobj\n");
+ }
+ 
++static inline int roundForBbox(qreal v)
++{
++return (v < 0) ? floor(v) : ceil(v);
++}
++
+ void QPdfEnginePrivate::embedFont(QFontSubset *font)
+ {
++QFontEngine::Properties properties = font->fontEngine->properties();
++QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
++qreal scale = 1000/properties.emSquare.toReal();
++
+ //qDebug() << "embedFont" << font->object_id;
+ int fontObject = font->object_id;
+-QByteArray fontData = font->toTruetype();
++QByteArray fontData = font->toTruetype();
+ #ifdef FONT_DUMP
+ static int i = 0;
+ QString fileName("font%1.ttf");
+@@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS
+ int toUnicode = requestObject();
+ int cidset = requestObject();
+ 
+-QFontEngine::Properties properties = font->fontEngine->properties();
+-QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
+-
+ {
+-qreal scale = 1000/properties.emSquare.toReal();
+ addXrefEntry(fontDescriptor);
+ QByteArray descriptor;
+ QPdf::ByteStream s();
+@@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS
+ s <<  '+' << postscriptName << "\n"
+ "/Flags " << 4 << "\n"
+ "/FontBBox ["
+-  << properties.boundingBox.x()*scale
+-  << -(properties.boundingBox.y() + 
properties.boundingBox.height())*scale
+-  << (properties.boundingBox.x() + 
properties.boundingBox.width())*scale
+-  << -properties.boundingBox.y()*scale  << "]\n"
++  << roundForBbox(properties.boundingBox.x()*scale)
++  << roundForBbox(-(properties.boundingBox.y() + 
properties.boundingBox.height())*scale)
++  << roundForBbox((properties.boundingBox.x() + 
properties.boundingBox.width())*scale)
++  << roundForBbox(-properties.boundingBox.y()*scale)  << "]\n"
+ "/ItalicAngle " << properties.italicAngle.toReal() << "\n"
+-"/Ascent " << properties.ascent.toReal()*scale << "\n"
+-"/Descent " << -properties.descent.toReal()*scale << "\n"
+-"/CapHeight " << properties.capHeight.toReal()*scale << "\n"
+-"/StemV " << properties.lineWidth.toReal()*scale << "\n"
++"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n"
++"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n"
++"/CapHeight " << qRound(properties.capHeight.toReal()*scale) << 
"\n"
++"/StemV " << qRound(properties.lineWidth.toReal()*scale) << "\n"
+ "/FontFile2 " << fontstream << "0 R\n"
+ "/CIDSet " << cidset << "0 R\n"
+ ">>\nendobj\n";
+--- a/src/gui/text/qfontsubset.cpp
 b/src/gui/text/qfontsubset.cpp
+@@ -1162,13 +1162,14 @@ static QByteArray bindFont(const QVector
+   if really required.
+ */
+ 
+-QByteArray QFontSubset::toTruetype() const
++QByteArray 

Bug#1053866: transition: jpeg-xl

[Jeremy Bícha]

Control: block -1 by 1061627

I was able to build all the reverse dependencies in Ubuntu 24.04 LTS
against jpeg-xl from experimental. But jpeg-xl won't be able to
migrate to Testing until its autopkgtests are fixed.

https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

See the blocking bug.

Thank you,
Jeremy Bícha

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Sun, 5 May 2024 at 22:22, Salvo Tomaselli  wrote:
>
> > In case anybody is aware of packages/programs needing an update to cope
> > with these changes, or any other issue, please let me know and I will
> > file bugs.
>
> in localslackirc@.service
>
> ReadWritePaths=/var/tmp
>
> It uses /var/tmp because it needs a directory with 1777 permissions that is
> permanent, to keep some status.
>
> The user it ends up using is configured by a seting, and is intended to be a
> non-system user (and could be different users for the various instances).
>
> I guess the solution would be to create such a directory when installing, in /
> var/lib/localslackirc instead of using /var/tmp and have the purge script
> remove it.

Services can use StateDirectory= and StateDirectoryMode= which should
provide the same functionality, and is more appropriate for persistent
state. /tmp/ and /var/tmp/ are meant to be scratch areas, rather than
state storage.

Bug#1060019: transition: poppler 24.02

[Jeremy Bícha]

Control: retitle -1 transition: poppler 24.02
Control: affects -1 src:poppler

Since originally requesting this transition, I have updated the
version to 24.02. I believe all reverse dependencies can be binNMU'd
for this.

Thank you,
Jeremy Bícha

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Hi Dmitry,

(you use Googlemail, which is problematic, I picked your reply
from the BTS; perhaps send to 1070406-submitter@b.d.o instead
which should arrive)

>I checked Qt 4 history [1] and there this code dates back to “Long live Qt!”
>commit from 2009. So it’s unlikely that we can find the original developer

Thanks for checking.

>and ask why it is like that and whether we actually need the OS/2 table.

Yeah. Some renderers might benefit from it in some cases probably.
It contains about 17 or so values that need to be scaled, and it
has multiple versions… I could probably write something…

>(and does not break anything else)?

Chances are extremely slim that fixing the metrics will break
anything ;-)

>Now that you dug so deeply, maybe you can try to replace qRound in those
>three lines that you mentioned with TO_TTF, and check if it fixes the bug

That *and* figure out somehow how to fix the PDF /FontBBox, at
least… (though I binary-patched the hhea ascender in the PDF and
it made Atril happy, so it “should”, despite the still-wrong OS/2
table values some of which are notably used in clipping by some
softwares…)

I think I can try that, though my weekend’s about up by now. I’d
try it with one of the versions (most likely bullseye’s) if that
is okay for you.

For the Mu͒seScore side, things get trickier though as they likely
won’t be able to obtain fixed Qt builds for all platforms. I wonder
whether it would be possible to subclass and just override the
faulty code (or do post-fixups somehow) and patch it to just do
that (if the bug is still present in the used Qt version)… I’m not
even a C++ programmer… *sigh*

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

[Cordell Bloor]

Tags: patch

Hi Graham,

On 2024-05-05 07:31, Graham Inggs wrote:

As can be seen in reproducible builds [1], rocm-hipamd FTBFS on arm64
with glibc 2.38.  I've copied what I hope is the relevant part of the
log below.

A bug was filed against glibc [2], but it seems glibc upstream do not
consider it a bug in glibc.


There is nothing that can be done in rocm-hipamd to address this bug, 
aside from removing arm64 from the rocm-hipamd architecture list. The 
incompatibility is not with the HIP runtime, but with the HIP language. 
This is a disagreement that glibc and llvm will need to resolve between 
themselves.



[1]https://tests.reproducible-builds.org/debian/rb-pkg/rocm-hipamd.html
[2]https://sourceware.org/bugzilla/show_bug.cgi?id=30909


In file included from /tmp/hip_pch.724714/hip_pch.h:1:
In file included from
/build/reproducible-path/rocm-hipamd-5.7.1/hip/include/hip/hip_runtime.h:62:
In file included from
/build/reproducible-path/rocm-hipamd-5.7.1/hipamd/include/hip/amd_detail/amd_hip_runtime.h:76:
In file included from
/usr/lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/cmath:47:
In file included from /usr/include/math.h:40:
/usr/include/aarch64-linux-gnu/bits/math-vector.h:40:9: error: unknown
type name '__SVFloat32_t'
40 | typedef __SVFloat32_t __sv_f32_t;
   | ^
/usr/include/aarch64-linux-gnu/bits/math-vector.h:41:9: error: unknown
type name '__SVFloat64_t'
41 | typedef __SVFloat64_t __sv_f64_t;
   | ^
/usr/include/aarch64-linux-gnu/bits/math-vector.h:42:9: error: unknown
type name '__SVBool_t'
42 | typedef __SVBool_t __sv_bool_t;
   | ^


This compilation error is when building device code when the host 
architecture is aarch64. LLVM only defines __SVFloat32_t, __SVFloat64_t 
and __SVBool_t when building host code, but not when building device 
code. To me this seems reasonable because GPUs do not support SVE 
instructions.


However, the math.h header (on aarch64 at least) is not aware of the 
concept of the distinction between host code and device code. As such, 
it fails when compiling device code. The glibc argument is that GCC 
always supports these types, but I'm not convinced. I'm curious how GCC 
handles the math headers for OpenMP GPU offloading [3].


In any case, I've attached a patch for glibc that would fix this bug. 
Perhaps my suggestion would be more palatable to upstream than the 
previously rejected patch. If not, it's up to glibc or LLVM to find a 
solution. If they cannot, then we will have to drop arm64 support for 
the HIP language.


Sincerely,
Cory Bloor

[3]: https://gcc.gnu.org/wiki/Offloading
From: Cordell Bloor 
Date: Wed, 10 Apr 2024 16:49:24 -0600
Subject: [PATCH] arm64/math-vec.h: drop SVE vector types in device code

These headers get included when building HIP libraries on the aarch64
platform. The headers are used when building both CPU code and GPU
code, but the SVE vector types are not supported on the GPU.

The clang compiler sets __HIP_DEVICE_COMPILE__ when it is building
code for the GPU, so disable __SVE_VEC_MATH_SUPPORTED when that macro
is detected.

Bug-Debian: https://bugs.debian.org/1070446
Bug-Ubuntu: https://bugs.launchpad.net/glibc/+bug/2032624
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30909
Forwarded: No

Index: glibc/sysdeps/aarch64/fpu/bits/math-vector.h
===
--- glibc.orig/sysdeps/aarch64/fpu/bits/math-vector.h
+++ glibc/sysdeps/aarch64/fpu/bits/math-vector.h
@@ -101,7 +101,8 @@ typedef __attribute__ ((__neon_vector_ty
 typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
 #endif
 
-#if __GNUC_PREREQ(10, 0) || __glibc_clang_prereq(11, 0)
+#if (__GNUC_PREREQ(10, 0) || __glibc_clang_prereq(11, 0)) \
+  && !defined(__HIP_DEVICE_COMPILE__)
 #  define __SVE_VEC_MATH_SUPPORTED
 typedef __SVFloat32_t __sv_f32_t;
 typedef __SVFloat64_t __sv_f64_t;

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Dmitry Shachnev]

On Sun, May 05, 2024 at 08:45:25PM +, Thorsten Glaser wrote:
> Dixi quod…
> 
> >correct… but it only changes the metrics in the head table, not
> >in the OS/2 or hhea tables (as can be seen when loading the font
> >from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
> >is constructed from the values from the original font.
> 
> And Atril uses the values from the hhea table (found by hexediting).
> 
> #define TO_TTF(x) qRound(x * 2048. / ppem)
> 
> This is used in things like…
> 
> font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth());
> 
> … but not in…
> 
> font.hhea.ascender = qRound(properties.ascent);
> font.hhea.descender = -qRound(properties.descent);
> font.hhea.lineGap = qRound(properties.leading);
> 
> … and of course not when the OS/2 table is copied:
> 
> if (!noEmbed) {
> QTtfTable os2;
> os2.tag = MAKE_TAG('O', 'S', '/', '2');
> os2.data = fontEngine->getSfntTable(os2.tag);
> if (!os2.data.isEmpty())
> tables.append(os2);
> }
> 
> (all examples from stretch’s Qt, as the oldest I had at hand)

Actually, this code dates back to “Initial import from the monolithic Qt”
commit from 2011. The only thing that changed is that MAKE_TAG macro was
replaced with QFont::Tag class.

I checked Qt 4 history [1] and there this code dates back to “Long live Qt!”
commit from 2009. So it’s unlikely that we can find the original developer
and ask why it is like that and whether we actually need the OS/2 table.

Now that you dug so deeply, maybe you can try to replace qRound in those
three lines that you mentioned with TO_TTF, and check if it fixes the bug
(and does not break anything else)?

[1]: https://github.com/qt/qt/blame/4.8/src/gui/text/qfontsubset.cpp

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1070469: RM: python-pyppmd [s390x] -- ANAIS; big-endian architectures unsupported

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: python-pyp...@packages.debian.org
Control: affects -1 + src:python-pyppmd
User: ftp.debian@packages.debian.org
Usertags: remove

Hi ftpmaster,

While adding pybuild test support to python-pyppmd, we noticed
that some encoding and decoding cycles were failing to restore
compressed user data on big-endian architectures, for instance
on s390x[1]:

_ test_ppmd8_encode_decode[1048576-1] 
__

tmp_path = 
PosixPath('/tmp/pytest-of-buildd/pytest-1/test_ppmd8_encode_decode_104851')
mem_size = 1048576, restore_method = 1

@pytest.mark.parametrize(
"mem_size, restore_method",
[
(8 << 20, pyppmd.PPMD8_RESTORE_METHOD_RESTART),
(8 << 20, pyppmd.PPMD8_RESTORE_METHOD_CUT_OFF),
(1 << 20, pyppmd.PPMD8_RESTORE_METHOD_RESTART),
(1 << 20, pyppmd.PPMD8_RESTORE_METHOD_CUT_OFF),
],
)
@pytest.mark.timeout(20)
def test_ppmd8_encode_decode(tmp_path, mem_size, restore_method):
length = 0
m = hashlib.sha256()
with testdata_path.joinpath("1SalesRecords.csv").open("rb") 
as f:
with tmp_path.joinpath("target.ppmd").open("wb") as target:
enc = pyppmd.Ppmd8Encoder(6, mem_size, 
restore_method=restore_method)
data = f.read(READ_BLOCKSIZE)
while len(data) > 0:
m.update(data)
length += len(data)
target.write(enc.encode(data))
data = f.read(READ_BLOCKSIZE)
target.write(enc.flush(endmark=True))
shash = m.digest()
m2 = hashlib.sha256()
assert length == 1237262
length = 0
with tmp_path.joinpath("target.ppmd").open("rb") as target:
with tmp_path.joinpath("target.csv").open("wb") as out:
dec = pyppmd.Ppmd8Decoder(6, mem_size, 
restore_method=restore_method)
data = target.read(READ_BLOCKSIZE)
while not dec.eof:
res = dec.decode(data)
m2.update(res)
out.write(res)
length += len(res)
if len(data) == 0:
break
data = target.read(READ_BLOCKSIZE)
>   assert length == 1237262
E   assert 1237261 == 1237262

tests/test_ppmd8.py:91: AssertionError

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=python-pyppmd=s390x=1.1.0%2Bds-2=1714557172=0

If left as is, we suspect the package could corrupt user data
and is is not fit for release on big-endian systems.  It should
be removed from the archive until such configuration is properly
supported.

Please remove python-pyppmd from s390x release architecture.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dixi quod…

>correct… but it only changes the metrics in the head table, not
>in the OS/2 or hhea tables (as can be seen when loading the font
>from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
>is constructed from the values from the original font.

And Atril uses the values from the hhea table (found by hexediting).

#define TO_TTF(x) qRound(x * 2048. / ppem)

This is used in things like…

font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth());

… but not in…

font.hhea.ascender = qRound(properties.ascent);
font.hhea.descender = -qRound(properties.descent);
font.hhea.lineGap = qRound(properties.leading);

… and of course not when the OS/2 table is copied:

if (!noEmbed) {
QTtfTable os2;
os2.tag = MAKE_TAG('O', 'S', '/', '2');
os2.data = fontEngine->getSfntTable(os2.tag);
if (!os2.data.isEmpty())
tables.append(os2);
}

(all examples from stretch’s Qt, as the oldest I had at hand)

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#1070468: ITP: qtcontacts-sqlite -- SQLite-based plugin for QtPIM Contacts

[Mike Gabriel]

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

* Package name: qtcontacts-sqlite
  Version : 0.3.5
  Upstream Contact: Alberto Mardegan 
* URL : 
https://gitlab.com/ubports/development/core/qtcontacts-sqlite
* License : BSD-3-clause
  Programming Lang: C++
  Description : SQLite-based plugin for QtPIM Contacts

 Qt is a cross-platform C++ application framework. Qt's primary feature
 is its rich set of widgets that provide standard GUI functionality.
 .
 This package contains a backend for the QtContacts API which stores
 contact information to a local SQLite database.

Bug#1070467: ITP: tuxblocs -- program to display tens, hundreds, thousands as 3D blocks

[Georges Khaznadar]

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

* Package name: tuxblocs
  Version : 4.0
  Upstream Contact: Arnaud Champollion 
* URL : https://educajou.forge.apps.education.fr/tuxblocs/
* License : GPL2
  Programming Lang: Python
  Description : program to display tens, hundreds, thousands as 3D blocks

 Tuxblocs helps students in K-12 schools to understand the positional
 numeration system.
 .
 It is not an exerciser for students to use directly; it is rather a tool
 for presentations.

Packaging this program is a mean to foster the creations of association
Primtux (https://primtux.fr), by pushing their creations to Debian. The same
author already authored fracatux, another educational program which is now in
Debian.

The package will be maintained in https://salsa.debian.org/debian/tuxblocs

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Tue, 5 Jul 2022 19:42:37 +0200 Michael Biebl 
wrote:
> 
> Hi Eric
> 
> On Fri, 31 Jul 2020 15:12:48 + Eric Desrochers 
>  wrote:
> > Package: systemd
> > Version: 245.7-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Debian systemd implementation does not clean
> > /var/tmp by default.
> > 
> > * quilt patch:
> > d/p/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-
defaul.patch
> > 
> > * systemd-245.7/tmpfiles.d/tmp.conf:
> > #q /var/tmp 1777 root root 30d
> > 
> > The patch exist in Debian since 2012.
> > 
> > The topic has been discussed and a few suggestion has been put on
the
> > table in the following Ubuntu bug:
https://launchpad.net/bugs/1870585
> > 
> > I fill this bug today to start a conversation.
> 
> I haven't received any further input from your side.
> Are you still interested in this issue or not?
> I wonder where to go from here and what to do about this bug report.

I think it's been long enough, and for Trixie we should bring the
defaults in line with upstream and other distributions, which means:

- /tmp/ is a tmpfs
- /var/tmp/ is cleaned up on a timer

Hence, I intend to apply these changes in the next src:systemd upload
to unstable, probably next week.

This will be mentioned in NEWS (and I guess in the release notes when
the time comes), together with the instructions to override for anybody
wanting to keep the old behaviour, which is as trivial as:

systemctl mask tmp.mount (or touch /etc/systemd/system/tmp.mount)
touch /etc/tmpfiles.d/tmp.conf

for the former and the latter respectively.

In case anybody is aware of packages/programs needing an update to cope
with these changes, or any other issue, please let me know and I will
file bugs.

-- 
Kind regards,
Luca Boccassi


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

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dixi quod…

>$ atril moo.pdf

Further debugging reveals the cause:

When Qt5 embeds a font, it scales it to 2048 ppem, no matter if
it was 1000 ppem (PS/CFF) or 1024 ppem (TTF) before. I think this
is because [QTBUG-586] it cannot embed CFF fonts, so it always
converts to TTF (apparently even if it was TTF already).

The conversion is done not incompetently, the new metrics are
correct… but it only changes the metrics in the head table, not
in the OS/2 or hhea tables (as can be seen when loading the font
from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
is constructed from the values from the original font.

I can confirm that if I prescale the font to 2048 ppem, ceteris
paribus, the bug no longer appears.

QPdfEnginePrivate::embedFont calls font->toTruetype()
but later uses font->fontEngine->properties() for metrics.

QFontSubset::toTruetype does the conversion to 2048 ppem
and others, saying it does not need to add an OS/2 table,
only to later copy the one from the original font if present
without adjusting its values.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1070387: [Debian-med-packaging] Bug#1070387: gdcm: CVE-2024-25569 CVE-2024-22373 CVE-2024-22391

[Étienne Mollier]

Control: found -1 3.0.21-1
Control: found -1 3.0.8-2
Control: fixed -1 3.0.24-1

Hi Moritz,

Thanks for the tracking and the triaging of these issues!

Moritz Mühlenhoff, on 2024-05-04:
> Please adjust the affected versions in the BTS as needed.

Done with the present email; an upload of 3.0.24-1 is on the way
in unstable.  I'm afraid I'm not sure how to test those
vulnerabilities, but mitigations brought by Mathieu apply with
no fuzz, or just a little, to gdcm in stable and oldstable (and
possibly oldoldstable), so I'm inclined to assume they are
affected.  Hi Mathieu, don't hesitate to chime in if you have
some insights on applying the mitigations on older versions.

I'm still running extensive tests at the moment against (build)
reverse dependencies, but there were no issues directly induced
by the newer gdcm version so far.  I'm considering liaising with
Stable Release Managers to get gdcm fixed there too in upcoming
point releases, if that helps.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Alta Forma - Apocalyptus


signature.asc
Description: PGP signature

Bug#1070281: logcheck: becomes less and less usable because of user-level logs

[Richard Lewis]

On Fri, 3 May 2024, 12:44 Francesco Potortì,  wrote:

>
> > One cure would be to have logcheck ignore user-level messages, and only
> care about system-level ones.  Is that possible?
> >
> >maybe it is possible - how do you define "system-level message"?
>
> Those created by root-owned processes, that would be a good start.  I
> definitely care about Sshd messages, much less about Gvfsd ones, and even
> less by those generated by Telegram running over Snapd.  For some reason,
> the problem has vastly increased after the advent of systemctl.



The options seem to be

1.you make a local rule that ignores all messages from known culprets  --
so you might jusy want to do a version of
"^timestamp hostname (Telegram|gvfsd)". This works today, but does need you
to know what you want to ignore


2.you tell logcheck to.not check the journal at all - also possoble today:
simply remove "journal" from the file in /etc/logcheck/logcheck.logfiles.d
(i dont know if this is that helpful!)

3. i have work in progress to allow you to tell logcheck to only check a
subset of the journal by passif  arguments to journalctl. Looking at the
journalctl.man-page:
 --unit ssh.service will only show messages from ssh
eg --system might exclude things  like telegram (untested!)
eg --priority might also be helpful
eg _UID=0 might select only things run by root (but that would probably
exclude things run by special users like apache)
eg --priority might also help?

This needs a small change in logcheck to make JOURNALCTL_OPTS settable from
the config file - this is WiP already! (logcheck currently hardcoded this
to an empty array)

other thoughts:
- we could definitely make logcheck only report the first N lines. I can
broadly see how to implement this. you can almost do this today by making a
"syslog-summary" script!

Bug#761600: Still using deprecated pam_env.so user_readenv option

[Max Bowsher]

I just found my way to this bug nearly 10 years later whilst wanting to
report the same issue still persists.

PAM upstream changed the default of user_readenv from 1 to 0 in
https://github.com/linux-pam/linux-pam/commit/f83fb5f25263356391d71da595def409e8dd90f7
and subsequently added explicit deprecation of the feature in
https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784

Other default /etc/pam.d/ files in Debian that invoke pam_env.so, do not
include user_readenv=1 - SSH is an unexpected outlier in this regard.

One further surprise: whilst the nomenclature tends to lead people in the
direction of believing ~/.pam_environment is a user addition to
/etc/environment, it is not, it is actually a user addition to
/etc/security/pam_env.conf. I am uncertain if this was originally intended,
or was a historic coding error normalized by time. Previous versions of the
man page text hint at the latter -
https://github.com/linux-pam/linux-pam/issues/6.


In view of all these things, I believe there is an excellent case for
dropping "user_readenv=1" from debian/openssh-server.sshd.pam.in

Bug#1020217: S3-backed snapshot implementation

[Lucas Nussbaum]

Hi,

I made some minor progress on this, and I thought I'd report back (I'll
try to attend the meeting tomorrow, but I'm not sure I'll manage).


# What I did:

- I got the OK to host a S3-backed snapshot mirror using the Debian AWS
  account (see thread in #1020217)
- I got access to the account, and set up a VM with a Debian mirror.
- I could run the file-backed snapshot importer on it
- I modified the snapshot importer code to make it import to S3
  (basically it means creating an S3Backend class that inherits from
  StockageBackend), and tested it by importing the debian-security
  archive.


# What I plan to work on:

- Set up a real development environment. I plan to use Vagrant, which is
  not a perfect solution for many reasons, but anyway the provisioning
  scripts will likely be re-usable with something else.
- Change the web frontend to allow using S3.
- Improve (parallelize) the importer code, specifically the sha1-hashing
  (to process multiple files in parallel, one per core) and the file
  copying/uploading-to-S3 (this is especially important for S3 because,
  to achieve good throughput, you need many transfers in parallel).


# Open questions

## What to do with this?

Assuming all this works and we can have a S3-backed snapshot
service, there's the question of what to do with it.
We have several options I think:

### A. s3-snapshot as a mirror of snapshot.debian.org

The imports would continue to be done on snapshot.debian.org, but
everything would be mirrored on a regular basis to S3.
That would allow faster access to the data, but would not help with the
performance of imports.

### B. dual-stack snapshot.debian.org

The importer on snapshot.debian.org would import both to local stockage,
and to s3. The web app could proxy requests to both.
That would allow more resilience, but does not help with the performance
of imports (on the contrary).

### C. s3-snapshot as a fork of snapshot.debian.org

After an initial import of snapshot.debian.org data, s3-snapshot would
live its own independent life.
The main downside is that both databases will become out of sync
(not the same mirror runs; they might each miss some packages, but not
the same ones).

### D. do both at the same time

Do C, but also make sure that every file that ever gets stored in
snapshot.debian.org gets imported in the bucket used for s3-snapshot, to
be able to expose a full read-only mirror of the snapshot.debian.org DB.

### E. Nice experiment, but let's forget about it

(That should be mentioned as well)



In any case, it probably makes sense to keep at least two different
instances of the snapshot service (and data) on preferably different
implementations, to make sure that we don't lose everything in case of
catastrophic incident.

I plan to aim for C as a first step.


## How to do an initial import of snapshot.debian.org data?

That's more a technical question. The PostgreSQL DB should not be a
problem, as it's quite small (~ 20 GB). For the data itself, it could
probably be uploaded directly from local storage on the snapshot.d.o
hosts to a S3 bucket. I could upload from an EC2 VM to S3 at about 10
Gbps (limited by the bandwidth of local storage). I don't know about the
performance (storage, network) of snapshot.debian.org, but that probably
means that an import into S3 is doable in a couple of weeks in the worst
case.  In any case, that's a question to keep in mind, but that does not
need to be resolved now.

Lucas

Bug#1070455: ayatana-indicator-display: FTBFS: Errors while running CTest

[Mike Gabriel]

Control: forwarded -1  
https://github.com/AyatanaIndicators/ayatana-indicator-display/pull/96


Hi Santiago,

On  So 05 Mai 2024 18:50:27 CEST, Santiago Vila wrote:


Package: src:ayatana-indicator-display
Version: 24.1.1-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DENABLE_TESTS=ON -DENABLE_COVERAGE=OFF  
-DENABLE_LOMIRI_FEATURES=ON -DENABLE_COLOR_TEMP=ON
	cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake  
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None  
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var  
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON  
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF  
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON  
-DFETCHCONTENT_FULLY_DISCONNECTED=ON  
-DCMAKE_INSTALL_RUNSTATEDIR=/run  
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles"  
-DCMAKE_VERBOSE_MAKEFILE=ON  
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DENABLE_TESTS=ON  
-DENABLE_COVERAGE=OFF -DENABLE_LOMIRI_FEATURES=ON  
-DENABLE_COLOR_TEMP=ON ..

-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features

[... snipped ...]

2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body:  
("type='signal',sender='org.freedesktop.Accounts',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/freedesktop/Accounts/User924',arg0='org.freedesktop.DBus.Properties'",)

2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    RECEIVED D-Bus message (169 bytes)
2:   Type:signal
2:   Flags:   no-reply-expected
2:   Version: 0
2:   Serial:  2
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'NameAcquired'
2: destination -> ':1.0'
2: sender -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body: (':1.0',)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Signal:
2:   RECEIVED SIGNAL org.freedesktop.DBus.NameAcquired
2:   on object /org/freedesktop/DBus
2:   sent by name org.freedesktop.DBus
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (281 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  3
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body:  
("type='signal',sender='org.freedesktop.Accounts',interface='org.freedesktop.DBus.Properties',path='/org/freedesktop/Accounts/User924'",)

2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (312 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  4
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body:  
("type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.Accounts'",)

2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    RECEIVED D-Bus message (72 bytes)
2:   Type:method-return
2:   Flags:   no-reply-expected
2:   Version: 0
2:   Serial:  3
2:   Headers:
2: reply-serial -> uint32 2
2: destination -> ':1.0'
2: sender -> 'org.freedesktop.DBus'
2:   Body: ()
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (188 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  5
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'StartServiceByName'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 'su'
2:   Body: ('org.freedesktop.Accounts', uint32 0)
2:   UNIX File Descriptors:
2: (none)
2: 

Bug#1070457: dino-im: FTBFS: error: ‘struct _gpgme_key’ has no member named ‘subkeys_length1’

[Stefan Kropp]

I found this bug at upstream project:

Dino 0.4.3 fails to compile after Vala-c update to 0.56.17
https://github.com/dino/dino/issues/1576

-- 
Stefan

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

Turns out that backporting
https://github.com/moby/moby/commit/97921915a801dd82b1f5a70e0a69353539c1e3ae.patch
seems to actually make the test pass

I'm not sure why that worked before, but I've pushed a backport of that
patch to
https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737
to let the salsa pipeline work on it.

I plan to make a team-upload tomorrow or later in the week. Please let me
know if you have concerns or thoughts on this.

Thanks
-rt

On Sun, May 5, 2024 at 11:20 AM Reinhard Tartler  wrote:

> I've been looking at this test failure, but remain puzzled.
>
> Basically, the source for this test is here:
> https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
> This test is testing code in
> https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
> which has only two external dependencies
> (golang-github-docker-distribution-dev) and
> (golang-github-sirupsen-logrus-dev).
>
> I've checked the build log of the previous build at
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
> and note that the same test passes in that build. This also uses the same
> package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
> golang-github-sirupsen-logrus-dev==1.9.0-1
>
> I also note that the old build was using golang 1.21, and the FTBFS was
> introduced after upgrading unstable to golang 1.22.
>
> Shengjing, I believe you handled the recent update of the golang toolchain
> from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
> resulted from using a newer golang compiler?
>
> I am considering just disabling this test, as the rest of the testsuite
> seem to pass, but I'm getting nervous that this wouldn't just paper over a
> real issue.
>
> Thanks,
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1070466: bookworm-pu: package dm-writeboost/2.2.17-0.2~deb12u1

[Andreas Beckmann]

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

[ Reason ]
A change from Linux v6.9-rc1 got backported to v6.1.83 and breaks
building the dm-writeboost module (dm_io() got an extra parameter).

I'd like to update dm-writeboost to a new upstream release, the only
functional change is that fix (patch by me), everything else is
documentation and metadata updates.
On the Debian side there are some autopkgtest and metadata
improvements.
I'd prefer getting the full package from sid instead of just
cherry-picking the fix.

[ Impact ]
The module cannot be built for the kernel in bookworm-security (or any
future kernels in bookworm).

[ Tests ]
pkg-autopkgtest-dkms takes care of that ;-)

[ Risks ]
Low.

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

[ Changes ]
dm-writeboost (2.2.17-0.2~deb12u1) bookworm; urgency=medium

  * Non-maintainer upload.
  * Rebuild for bookworm.

 -- Andreas Beckmann   Sun, 05 May 2024 20:42:46 +0200

dm-writeboost (2.2.17-0.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix misspelled autopkgtest dependency.

 -- Andreas Beckmann   Sun, 05 May 2024 04:21:59 +0200

dm-writeboost (2.2.17-0.1) unstable; urgency=medium

  [ Andreas Beckmann ]
  * Non-maintainer upload.
  * New upstream release [May 2024]. (Closes: #1069878)
  * Update upstream metadata.
  * dkms.conf: Set BUILD_EXCLUSIVE_KERNEL_MIN="3.9".
  * Fix autopkgtest dependencies. (Closes: #1069600)

  [ Andrea Righi ]
  * Skip I/O-intensive autopkgtest on small systems (LP: #2012947)

 -- Andreas Beckmann   Sat, 04 May 2024 09:21:27 +0200

[ Other info ]
This is a rebuild of the package from sid with no further changes.

Andreas
diff --git a/ChangeLog b/ChangeLog
index e6f0c3c..53bcd7b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-01  Akira Hayakawa  
+
+   * v2.2.17
+   * Fix build error with 6.9 kernel and backports
+   * Improve dkms.conf
+
 2023-02-11  Akira Hayakawa  
 
* v2.2.16
diff --git a/Makefile b/Makefile
index 581d373..aa6b6ea 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-MODULE_VERSION ?= 2.2.15
+MODULE_VERSION ?= 2.2.17
 DKMS_DIR := /usr/src/dm-writeboost-$(MODULE_VERSION)
 DKMS_KEY := -m dm-writeboost -v $(MODULE_VERSION)
 
diff --git a/README.md b/README.md
index f5d280d..ddd1f88 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,5 @@
 # dm-writeboost 
 
-[![Tokei](https://tokei.rs/b1/github/akiradeveloper/dm-writeboost)](https://github.com/akiradeveloper/dm-writeboost)
-[![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://paypal.me/akiradeveloper)
-
 Log-structured Caching for Linux
 
 ## Overview
@@ -42,15 +39,11 @@ As a further extension, dm-writeboost supports read-caching 
which also writes da
 ## Distribution Packages
 - [Debian](https://packages.debian.org/search?keywords=dm-writeboost-dkms)  
 - [Ubuntu](https://packages.ubuntu.com/search?keywords=dm-writeboost-dkms)  
-- [CentOS/Fedora](https://copr.fedorainfracloud.org/coprs/khara/dm-writeboost/)
-- [Arch](https://aur.archlinux.org/packages/dm-writeboost/)  
-- Momonga
 
 ## Related Projects
 * https://github.com/akiradeveloper/dm-writeboost-tools: Tools to help users 
analyze the state of the cache device  
 * https://gitlab.com/onlyjob/writeboost: A management tool including init 
script  
 * https://github.com/akiradeveloper/device-mapper-tests: Testing framework 
written in Rust
-* https://github.com/kazuhisya/dm-writeboost-rpm: Providing RPM packages
 
 ## Related works
 * Y. Hu and Q. Yang -- DCD Disk Caching Disk: A New Approach for Boosting I/O 
Performance (1995)
@@ -65,7 +58,7 @@ Awarded by Japanese OSS Encouragement Award. Thanks!
 
 ## License
 ```
-Copyright (C) 2012-2023 Akira Hayakawa 
+Copyright (C) 2012-2024 Akira Hayakawa 
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/debian/changelog b/debian/changelog
index b27c491..5fa74b3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,31 @@
+dm-writeboost (2.2.17-0.2~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Sun, 05 May 2024 20:42:46 +0200
+
+dm-writeboost (2.2.17-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix misspelled autopkgtest dependency.
+
+ -- Andreas Beckmann   Sun, 05 May 2024 04:21:59 +0200
+
+dm-writeboost (2.2.17-0.1) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * New upstream release [May 2024]. (Closes: #1069878)
+  * Update upstream metadata.
+  * dkms.conf: Set BUILD_EXCLUSIVE_KERNEL_MIN="3.9".
+  * Fix autopkgtest dependencies. (Closes: #1069600)
+
+  [ Andrea Righi ]
+  * Skip I/O-intensive autopkgtest on 

Bug#620927: We could fix this by upstreaming the Ubuntu diff to include pam_env.so in sudo's PAM config

[Max Bowsher]

I found this bug when in the same circumstance of /etc/environment proxy
settings not applying to sudo sessions.

I understand the rationale for "wontfix"-ing the previously suggested fix
of changing /etc/sudoers.

However, Ubuntu have been carrying a patch for the past 12 years which
addresses the issue in a different, potentially more acceptable way, and I
haven't been able to find any evidence in bug trackers of forwarding that
diff back to Debian being discussed, so I'm bringing it up here:

```
diff --git a/debian/etc/pam.d/sudo b/debian/etc/pam.d/sudo
index 96e8906a..7819ab18 100644
--- a/debian/etc/pam.d/sudo
+++ b/debian/etc/pam.d/sudo
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 sessionrequired   pam_limits.so

+sessionrequired   pam_env.so readenv=1 user_readenv=0
+sessionrequired   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session-noninteractive
diff --git a/debian/etc/pam.d/sudo-i b/debian/etc/pam.d/sudo-i
index d6385222..584b2d8e 100644
--- a/debian/etc/pam.d/sudo-i
+++ b/debian/etc/pam.d/sudo-i
@@ -3,6 +3,9 @@
 # Set up user limits from /etc/security/limits.conf.
 sessionrequired   pam_limits.so

+sessionrequired   pam_env.so readenv=1 user_readenv=0
+sessionrequired   pam_env.so readenv=1 envfile=/etc/default/locale
user_readenv=0
+
 @include common-auth
 @include common-account
 @include common-session
```

Including pam_env.so in sudo's PAM configuration would apply system-wide
environment settings to sudo sessions, in a way which is generally
consistent with the existing Debian PAM configurations for cron, login,
sshd, and su.

The Ubuntu bug in which these changes were originally made 12 years ago was
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/982684, and proxy
settings are cited as motivation there as well.

Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this

[Richard Lewis]

control: close 1070436
thanks

On Sun, 5 May 2024, 19:10 Jochen Sprickerhof,  wrote:

> Hi Richard,
>
> * Richard Lewis  [2024-05-05 11:32]:
> >If i try and run tests that use 'unshare --net' with a
> >schroot backend they fail inside autopkgtest even though
> >this works in the schroot being used.
> >
> >This works fine in a 'plain schroot' (I expect i allowed
> >the calling user to run the schroot as root in the schroot
> >in /etc/schroot):
> >
> > $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user
> root -- unshare --net --map-root-user ls
> > bin  boot  build  dev  etc  home  lib  lib64  media  mnt  opt  proc
> root  run  sbin  srv  sys  tmp  usr  var
>
> I can't reproduce this. Testing in a fresh debvm:
>
> $ debvm-create --size=2G --release=stable -- \
>  --include=sbuild,schroot,debootstrap,autopkgtest \
>  --hook-dir=/usr/share/mmdebstrap/hooks/useradd
> $ debvm-run
> # echo "inside debvm"
> # sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild \
>  http://deb.debian.org/debian
> # sbuild-adduser user
> # su - user
> $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root
> -- unshare --net --map-root-user ls
> unshare: unshare failed: Operation not permitted
>
> Do you have any idea why it works for you?
>

im so sorry - this was just a complete user error by me.

 the issue is the --map-root-user, i thought absolutely sure i was using
that with plain schroot, but it turns out i was completely misreading what
i was running, and apparently copied the command and output from separate
places.


as you say, if i omit map-root-user then it works with both schroot and
autopkgtest. and if i include map-root-user then both fail.


Over all I think using unshare --map-root-user in
>
autopkgtest-virt-schroot is not supported and I don't think there is a
> way around that except using a different autopkgtest backend.


thanks - this is fair enough.

thanks for the response. and sorry for the noise

Bug#1064003: patch for c-t-b build

[Helmut Grohne]

Control: tags -1 + patch

Hi Matthias,

I'm attaching a patch for the c-t-b FTBFS. Note that due to the
glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
timely upload is appreciated. Due to linux-libc-dev currently providing
the -$arch-cross packages, we have to remove the Build-Conflicts or make
rename the Provides on linux-libc-dev. I'm ok with both approaches and
offer dropping the conflict here.

Helmut
diff --minimal -Nru cross-toolchain-base-68/debian/changelog 
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/changelog   2024-05-04 
09:23:39.0 +0200
@@ -1,3 +1,12 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using linux 6.7. Closes: #1064003, #1067370.
+  * Build using glibc 2.38.
+  * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ -- Helmut Grohne   Sat, 04 May 2024 09:23:39 +0200
+
 cross-toolchain-base (68) unstable; urgency=medium
 
   * Build using linux 6.5.8. Closes: #1042118.
diff --minimal -Nru cross-toolchain-base-68/debian/control 
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control  2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 09:23:39.0 
+0200
@@ -9,9 +9,9 @@
 Build-Depends: binutils-multiarch,
   dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
   binutils-source (>= 2.41-6~),
-  glibc-source (>= 2.37-3~),
+  glibc-source (>= 2.38),
   gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
-  linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+  linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
   autoconf (>= 2.69), autoconf2.69, autogen,
   automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
   dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
   libjansson-dev, pkg-config,
 Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
   binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386], 
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el], 
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf], 
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
-  libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross, 
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross, 
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross, 
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross, 
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross, 
linux-libc-dev-riscv64-cross,
+  libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross, 
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
   libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
 
 Package: linux-libc-dev-amd64-cross
diff --minimal -Nru cross-toolchain-base-68/debian/rules 
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 09:50:26.0 
+0100
+++ cross-toolchain-base-68+nmu1/debian/rules   2024-05-04 09:23:39.0 
+0200
@@ -61,8 +61,8 @@
 CROSS_GNU_TYPE   = $(call _gnu_type,${CROSS_ARCH})
 CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
 
-MIN_VER_GLIBC  := 2.37-3~
-MIN_VER_LINUX  := 6.5.8
+MIN_VER_GLIBC  := 2.38
+MIN_VER_LINUX  := 6.7.0
 MIN_VER_GCC:= 12.3.0-11~
 MIN_VER_BINUTILS   := 2.41-6~
 VER_GCC_BASE   := 12
@@ -110,7 +110,7 @@
 
 # FIXME: No conflict for the host == cross case ...
 BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst 
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,) 
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
 
 # taken from gcc packaging
 define unpack_tarball

Bug#1070465: nmu: libnginx-mod-http-modsecurity_1.0.3-2

[Ervin Hegedüs]

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

Hello,

the ABI has changed in Nginx package, and the maintainer asked
all 3rd party modules need to rebuild.

See bug #1070321.

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

Please rebuild libnginx-mod-http-modsecurity against nginx-abi-1.26.0-1

nmu libnginx-mod-http-modsecurity . ANY . unstable . -m "Rebuild with updated 
nginx"



Regards,


a.

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Jeremy Bícha]

On Sun, May 5, 2024 at 2:51 PM Jeremy Bícha  wrote:
> Where did you get gnome-remote-desktop 46.1-1_amd64.deb from? It has
> not been successfully built on Debian's buildds yet.

Oh, I guess it was mentioned in your bug title: you built it from Salsa.

Thank you,
Jeremy Bícha

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Jeremy Bícha]

Where did you get gnome-remote-desktop 46.1-1_amd64.deb from? It has
not been successfully built on Debian's buildds yet.

Thank you,
Jeremy Bícha

Bug#1067016: nvidia-settings 470.239.06-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067016 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-settings
Version: 470.239.06-1

Explanation: new upstrem bugfix release; build for ppc64el

Bug#1065053: nvidia-graphics-drivers-tesla-470 470.239.06-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1065053 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-470
Version: 470.239.06-1~deb11u1

Explanation: new upstream LTS release [CVE-2024-0074 CVE-2024-0078 
CVE-2022-42265]

Bug#1065013: nvidia-graphics-drivers 470.239.06-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1065013 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 470.239.06-1

Explanation: upstream security fixes [CVE-2022-42265 CVE-2024-0074 
CVE-2024-0078]

Bug#1067843: nvidia-open-gpu-kernel-modules 535.161.08-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067843 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-open-gpu-kernel-modules
Version: 535.161.08-1~deb12u1

Explanation: update to 535 series LTS drivers [CVE-2023-0180 CVE-2023-0183 
CVE-2023-0184 CVE-2023-0185 CVE-2023-0187 CVE-2023-0188 CVE-2023-0189 
CVE-2023-0190 CVE-2023-0191 CVE-2023-0194 CVE-2023-0195 CVE-2023-0198 
CVE-2023-0199 CVE-2023-25515 CVE-2023-25516 CVE-2023-31022 CVE-2024-0074 
CVE-2024-0075 CVE-2024-0078]

Bug#1067821: nvidia-graphics-drivers 535.161.08-2~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067821 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 535.161.08-2~deb12u1

Explanation: new upstream stable release [CVE-2023-0180 CVE-2023-0183 
CVE-2023-0184 CVE-2023-0185 CVE-2023-0187 CVE-2023-0188 CVE-2023-0189 
CVE-2023-0190 CVE-2023-0191 CVE-2023-0194 CVE-2023-0195 CVE-2023-0198 
CVE-2023-0199 CVE-2023-25515 CVE-2023-25516 CVE-2023-31022 CVE-2024-0074 
CVE-2024-0075 CVE-2024-0078]

Bug#1067745: nvidia-settings 535.171.04-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067745 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-settings
Version: 535.171.04-1~deb12u1

Explanation: new upstream LTS release

Bug#1067742: nvidia-xconfig 535.171.04-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067742 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-xconfig
Version: 535.171.04-1~deb12u1

Explanation: new upstream LTS release

Bug#1065653: nvidia-modprobe 535.161.07-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1065653 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-modprobe
Version: 535.161.07-1~deb12u1

Explanation: prepare to switch to 535 series LTS drivers

Bug#1067739: nvidia-persistenced 535.171.04-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1067739 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-persistenced
Version: 535.171.04-1~deb12u1

Explanation: switch to 535 series LTS drivers; update list of supported drivers

Bug#1070464: python3-astrometry: SyntaxWarning during package installation

[Andreas Beckmann]

Package: python3-astrometry
Version: 0.93+dfsg-1.1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-astrometry (0.93+dfsg-1.1+b1) ...
  /usr/lib/python3/dist-packages/astrometry/sdss/yanny.py:777: SyntaxWarning: 
invalid escape sequence '\`'
"""Converts text into tables that users can use.


Cheers,

Andreas

Bug#867548: Playback to HDMI monitor stutters / pauses (HDMI on Haswell)

[Jmkr]

I can confirm that this bug still affects my Debian 10 systems that have kernel 
from Debian 12 (currently 6.1.0-20-amd64) and use Haswell CPU (e.g. Intel Core 
i74800MQ, i74810MQ, etc.). I have "VT-d" enabled in the BIOS of these laptops 
and I tested that this bug occurs when I connect external monitor via:

- HDMI port on the laptop to HDMI port on the monitor
- DP or DVI port on the laptop docking station to DP or HDMI port on the monitor

and then I ensure PULSEAUDIO outputs sound to the monitor DP or HDMI port. I 
also tested that passing "intel_iommu=on,igfx_off" to the kernel command line 
(in GRUB config or command line) still works as a workaround.

Also on my systems I noticed that if I set PULSEAUDIO to output sound to the 
monitor DP or HDMI and then start a YOUTUBE playback the audio/video starts for 
a brief moment normally and then it starts to stutter and then it quickly fails 
completely. Basically it looks like the playback speed starts as normal, but 
then quickly increases until it is too fast for the system to handle. To test 
this I switched PULSEAUDIO (using PAVUCONTROL) to "Analog Stereo Duplex" and 
then back to the monitor DP or HDMI ("Digital Stereo (HDMI*)") after each 
YOUTUBE playback attempt failed.

After reading this bug and the related kernel bug 
(https://bugzilla.kernel.org/show_bug.cgi?id=60769) I thing that Bryan Cebuliak 
and me experienced that kernel IOMMU bug that affects systems with Haswell 
CPUs. However the initial reporter Daniel Pocock and Mike Fuller could had a 
slightly different issue with HDMI audio. But it is hard to tell as they did 
not describe the symptoms in much detail. So we may never know unless they 
report back whether they still have problems with HDMI audio and whether the 
"intel_iommu=on,igfx_off" kernel parameter works as a workaround for them too.

Anyway, I would like to thank Bryan Cebuliak as the information he provided 
helped me find the workaround faster.

Regards,
Jmkr

Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this

[Jochen Sprickerhof]

Hi Richard,

* Richard Lewis  [2024-05-05 11:32]:

If i try and run tests that use 'unshare --net' with a
schroot backend they fail inside autopkgtest even though
this works in the schroot being used.

This works fine in a 'plain schroot' (I expect i allowed
the calling user to run the schroot as root in the schroot
in /etc/schroot):

$ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- 
unshare --net --map-root-user ls
bin  boot  build  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  
sbin  srv  sys  tmp  usr  var


I can't reproduce this. Testing in a fresh debvm:

$ debvm-create --size=2G --release=stable -- \
--include=sbuild,schroot,debootstrap,autopkgtest \
--hook-dir=/usr/share/mmdebstrap/hooks/useradd
$ debvm-run
# echo "inside debvm"
# sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild \
http://deb.debian.org/debian
# sbuild-adduser user
# su - user
$ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- 
unshare --net --map-root-user ls
unshare: unshare failed: Operation not permitted

Do you have any idea why it works for you?


But if i have an autopkgtest with eg a debian/tests/control with

Test-Command: unshare --map-root-user --net ./debian/tests/foo
Depends: @
Features: test-name=foo
Restrictions: needs-root


This looks odd. If you only want to unshare the network, as stated in 
the bug title, you neither need --map-root-user nor needs-root. Indeed 
dropping both makes it work for me. Can you give some background what 
you actually want to do here?



then even adding '--user root' doesnt work:

$ /usr/bin/autopkgtest package.changes --user root -- schroot 
unstable-amd64-sbuild


I guess this is due to autopkgtest-virt-schroot starts an schroot 
session but I can't verify without reproducing your example without a 
session.



i get errors like

unshare: unshare failed: Operation not permitted


This maps to unshare(2) returning EPERM. From the manpage:

| CLONE_NEWUSER was specified in flags and the caller is in a chroot 
| environment (i.e., the caller's root directory does not match the root 
| directory of the mount namespace in which it resides).


I think this is what happens here.

Over all I think using unshare --map-root-user in 
autopkgtest-virt-schroot is not supported and I don't think there is a 
way around that except using a different autopkgtest backend.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1069600: Fwd: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

[Andreas Beckmann]

On 28/04/2024 11.35, Paul Gevers wrote:

Hi,

On 28-04-2024 9:34 a.m., Andreas Beckmann wrote:
What kernel is running inside the test environment and what is the 
best way to install its headers?


Can you help me find the answer? I guess you don't mean "the current 
kernel of the suite under test" but rather a flavor? We use 
autopkgtest-build-qemu, which uses vmdb2, to build the image. The kernel 
used is also logged in the autopkgtest log, so you can also look it up :).


That was too trivial. I expected you had done something fancy (and 
completely different from the normal test runs) to enable 
isolation-machine ;-) (And while reading the log I didn't spot anything 
interesting to answer my questions. But I didn't look outside the 
sections of that specific test.)



Would Depends: linux-headers-generic work?


I don't know.


It does. If its spelled correctly ;-)

The corresponding changes for the autopkgtest are now in sid. Including 
a change from Ubuntu to skip the test on low powered systems.
There has been migration test run on amd64 already and the new test got 
skipped:


167s autopkgtest [09:50:25]: test test-dm-writeboost.sh: 
[---

168s II: Checking for 14G available disk space...SKIP
168s autopkgtest [09:50:26]: test test-dm-writeboost.sh: 
---]


The next check would have been for 8+ cpu cores.

So, yes, isolation-machine works^Wdoesn't fail for dm-writeboost but it 
is not helpful for this package since it cannot provide the required 
resources.




Andreas

Bug#999922: xneur: diff for NMU version 0.20.0-3.3

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for xneur (versioned as 0.20.0-3.3). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru xneur-0.20.0/debian/changelog xneur-0.20.0/debian/changelog
--- xneur-0.20.0/debian/changelog	2024-05-05 15:23:15.0 +0200
+++ xneur-0.20.0/debian/changelog	2024-05-05 19:41:29.0 +0200
@@ -1,3 +1,11 @@
+xneur (0.20.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Really fix pkgconfig file after porting to PCRE2 (Closes:
+#22)
+
+ -- Sebastian Ramacher   Sun, 05 May 2024 19:41:29 +0200
+
 xneur (0.20.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xneur-0.20.0/debian/patches/0004-Port-to-PCRE2.patch xneur-0.20.0/debian/patches/0004-Port-to-PCRE2.patch
--- xneur-0.20.0/debian/patches/0004-Port-to-PCRE2.patch	2024-05-05 15:20:35.0 +0200
+++ xneur-0.20.0/debian/patches/0004-Port-to-PCRE2.patch	2024-05-05 19:41:07.0 +0200
@@ -115,7 +115,7 @@
  Name: xnconfig
  Description: XNeur config library
 -Requires: libpcre
-+Requires: libpcre2
++Requires: libpcre2-8
  Version: @VERSION@
  Libs: -L@libdir@ -lxnconfig @PCRE_LIBS@ @LDFLAGS@ @ADDITIONAL_LIBS@
  Cflags: -I@includedir@

Bug#1070463: gnome-remote-desktop: 46 has failing build tests

[Jeremy Bícha]

Source: gnome-remote-desktop
Version: 46.1-1
Severity: serious
Tags: ftbfs experimental
Control: block 1050237 by -1
X-Debbugs-CC: ma...@ubuntu.com

gnome-remote-desktop's build tests are failing. This is blocking the
GNOME Shell 46 transition since GNOME Shell & GNOME Remote Desktop
should have the same major version, at least while the projects are
under heavy development.

The build tests were passing with version 45. It is not clear to me
why the tests are failing in Debian Experimental but passing in Ubuntu
24.04 LTS.

Thank you,
Jeremy Bícha

Bug#1070462: transition: evolution-data-server 3.52

[Jeremy Bícha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: evolution-data-ser...@packages.debain.org

One of the evolution-data-server libraries had a soname bump. I
believe everything should be binNMUable without issue.

This tracker is good:
https://release.debian.org/transitions/html/auto-evolution-data-server.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#1070460: translate-toolkit: FTBFS: failing tests

[Santiago Vila]

Package: src:translate-toolkit
Version: 3.12.2-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary --with python3,sphinxdoc --buildsystem pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" 
module
I: pybuild base:311: python3.12 -m build --skip-dependency-check --no-isolation --wheel 
--outdir /<>/.pybuild/cpython3_3.12_translate
* Building wheel...
running bdist_wheel
running build
running build_py
creating build
creating build/lib

[... snipped ...]

unit.makeobsolete()

  assert str(unit) == ""

E   assert '#~ msgid "te...~ msgstr ""\n' == ''
E
E + #~ msgid "test"
E + #~ msgstr ""

tests/translate/storage/test_po.py:449: AssertionError
- Captured stdout call -
b'#. The automatic one\n#: test.c\nmsgid "test"\nmsgstr ""\n'
 TestXWikiFullPage.test_remove _

self = 

@mark.xfail(reason="removal not working in full page")
def test_remove(self):

  super().test_remove()


tests/translate/storage/test_properties.py:1614:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 

def test_remove(self):
"""Tests removing a unit with a source string."""
store = self.StoreClass()
unit = store.addsourceunit("Test String")
# Some storages (MO, OmegaT) serialize only translated units
unit.target = "Test target"
assert headerless_len(store.units) == 1
withunit = bytes(store)
print(withunit)
store.removeunit(unit)
assert headerless_len(store.units) == 0
withoutunit = bytes(store)
print(withoutunit)

  assert withoutunit != withunit

E   assert 

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Luca Boccassi]

On Mon, 22 Apr 2024 15:38:00 +0100 Luca Boccassi 
wrote:
> On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi 
> wrote:
> > On Mon, 15 Apr 2024 at 10:34, Peter Pentchev 
> wrote:
> > >
> > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote:
> > > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit :
> > > > >
> > > > > > I'm pretty sure that we can, at some point in the future,
> drop the
> > > > > offending
> > > > > > patch from the RPM package and all of this will be
redundant.
> It
> > > > > just requires a
> > > > > > bit of work to make sure that older use cases (mostly
alien)
> don't
> > > > > break due to
> > > > > > this, which might require a bit of development on RPM
itself.
> It's
> > > > > on my TODO
> > > > > > list for very rainy and boring days, but unfortunately
> there's
> > > > > almost always a
> > > > > > truckload of other things to do, so I keep dragging it out.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Mihai
> > > > > >
> > > > >
> > > > > I fully agree on removing the RPM patch that causes all of
our
> issues
> > > > > on packages depending on it. If needed, I'm willing to be
part
> of
> > > > > reviewing what would be the impact of returning to a standard
> RPM
> > > > > package on Debian and to help into solving those issues.
Don't
> > > > > hesitate to ping me for that.
> > > >
> > > > I think the time has come to drop the RPM Debian-specific
patches
> and
> > > > avoid these workarounds altogether.
> > > >
> > > > Once upon a time it made sense to redirect the RPM DB, and to
go
> out of
> > > > our way to stop users installing RPMs locally, when RPMs were
> popular
> > > > as a way to distribute upstream applications.
> > > >
> > > > Nowadays, the most common way to distribute upstream apps is
via
> > > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via
deb
> > > > repositories, so the chances someone tries to 'sudo rpm -i
> foo.rpm' are
> > > > very low.
> > > >
> > > > The main use of having rpm/dnf/zypper in Debian is not to
convert
> RPMs
> > > > with Alien or so, but it's to be able to do cross-distribution
> > > > bootstraps and image building using native tools, like we do in
> mkosi
> This is now in experimental, unless I hear something I'll upload to
> unstable during the weekend.

Uploaded to unstable.

-- 
Kind regards,
Luca Boccassi


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

Bug#1070461: uhttpmock0: FTBFS: Failed to load TLS database: System trust contains zero trusted certificates; please investigate your GnuTLS configuration

[Santiago Vila]

Package: src:uhttpmock0
Version: 0.5.5-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -Dauto_features=disabled -Dintrospection=false
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 
-Dauto_features=disabled -Dintrospection=false
The Meson build system
Version: 1.4.0
Source dir: /<>
Build dir: /<>/obj-x86_64-linux-gnu
Build type: native build
Project name: uhttpmock
Project version: 0.5.5
C compiler for the host machine: cc (gcc 13.2.0 "cc (Debian 13.2.0-24) 13.2.0")
C linker for the host machine: cc ld.bfd 2.42
Host machine cpu family: x86_64
Host machine cpu: x86_64
Configuring uhm-version.h using configuration
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency glib-2.0 found: YES 2.80.0
Run-time dependency gio-2.0 found: YES 2.80.0
Run-time dependency libsoup-2.4 found: YES 2.74.3
Compiler for C supports link arguments 
-Wl,--version-script,/<>/libuhttpmock/libuhttpmock.map: YES
Configuring version.xml using configuration
Program gtkdoc-scan found: YES (/usr/bin/gtkdoc-scan)
Program gtkdoc-scangobj found: YES (/usr/bin/gtkdoc-scangobj)
Program gtkdoc-mkdb found: YES (/usr/bin/gtkdoc-mkdb)
Program gtkdoc-mkhtml found: YES (/usr/bin/gtkdoc-mkhtml)
Program gtkdoc-fixxref found: YES (/usr/bin/gtkdoc-fixxref)
Build targets in project: 5

uhttpmock 0.5.5

  User defined options
auto_features : disabled
buildtype : plain
libdir: lib/x86_64-linux-gnu
localstatedir : /var
prefix: /usr
sysconfdir: /etc
wrap_mode : nodownload
python.bytecompile: -1
introspection : false

Found ninja-1.11.1 at /usr/bin/ninja
make[1]: Leaving directory '/<>'
   dh_auto_build
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v
[1/8] cc -Ilibuhttpmock/libuhttpmock-0.0.so.0.2.3.p -Ilibuhttpmock -I../libuhttpmock 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu99 
-Wno-unused-parameter -Wno-missing-field-initializers -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
'-DG_LOG_DOMAIN="libuhttpmock"' -MD -MQ 
libuhttpmock/libuhttpmock-0.0.so.0.2.3.p/uhm-resolver.c.o -MF 
libuhttpmock/libuhttpmock-0.0.so.0.2.3.p/uhm-resolver.c.o.d -o 
libuhttpmock/libuhttpmock-0.0.so.0.2.3.p/uhm-resolver.c.o -c ../libuhttpmock/uhm-resolver.c
[2/8] cc -Ilibuhttpmock/tests/server.p -Ilibuhttpmock/tests -I../libuhttpmock/tests -Ilibuhttpmock -I../libuhttpmock 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 
-Wall -Winvalid-pch -Wextra -std=gnu99 -Wno-unused-parameter -Wno-missing-field-initializers -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
'-DTEST_FILE_DIR="/<>/libuhttpmock/tests/"' 
'-DG_LOG_DOMAIN="libuhttpmock-tests"' -DLIBUHTTPMOCK_DISABLE_DEPRECATED -MD -MQ 
libuhttpmock/tests/server.p/server.c.o -MF libuhttpmock/tests/server.p/server.c.o.d -o 
libuhttpmock/tests/server.p/server.c.o -c ../libuhttpmock/tests/server.c
[3/8] cc -Ilibuhttpmock/libuhttpmock-0.0.so.0.2.3.p -Ilibuhttpmock -I../libuhttpmock 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu99 
-Wno-unused-parameter -Wno-missing-field-initializers -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
'-DG_LOG_DOMAIN="libuhttpmock"' -MD -MQ 
libuhttpmock/libuhttpmock-0.0.so.0.2.3.p/uhm-server.c.o -MF 
libuhttpmock/libuhttpmock-0.0.so.0.2.3.p/uhm-server.c.o.d -o 

Bug#1070459: psortb: FTBFS: binding.c:52:13: error: implicit declaration of function ‘free’

[Santiago Vila]

Package: src:psortb
Version: 3.0.6+dfsg-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cp -a psort/bin/psort psort/bin/psort.debsave
dh_auto_configure
/usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wl,-z,relro -Wl,-z,now"
External Module XML::RPC, XML Based RPC client, is not installed on this 
computer.
  The XML::RPC in PSortb needs it for making calls to remote PSortb servers, if 
you don't plan to do this, ignore this warning

We think we've found blastall, please enter the path if this isn't correct 
[/usr/bin/] /usr/bin/
We think we've found pfscan, please enter the path if this isn't correct 
[/usr/bin/] /usr/bin/
Where do you plan to install the psort configuration files? [/usr/local/psortb] 
/usr/local/psortb

Checking if your kit is complete...
Looks good

hmmer was not found in the dynamic linker path, is there somewhere else we 
should check?  [/usr/local/lib64] /usr/local/lib64

We're still not finding hmmer either in your dynamic linker path 
(/etc/ld.so.conf) or
in /usr/local/lib64.

Do you want to continue anyways? [Y/n] [Y] Y

squid was not found in the dynamic linker path, is there somewhere else we 
should check?  [/usr/local/lib64] /usr/local/lib64

We're still not finding squid either in your dynamic linker path 
(/etc/ld.so.conf) or
in /usr/local/lib64.

Do you want to continue anyways? [Y/n] [Y] Y
Checking if your kit is complete...
Looks good
Writing MYMETA.yml and MYMETA.json

svmloc was not found in the dynamic linker path, is there somewhere else we 
should check?  [/usr/local/lib64] /usr/local/lib64

We're still not finding svmloc either in your dynamic linker path 
(/etc/ld.so.conf) or
in /usr/local/lib64.

Do you want to continue anyways? [Y/n] [Y] Y
Checking if your kit is complete...
Looks good
Writing MYMETA.yml and MYMETA.json

modhmm was not found in the dynamic linker path, is there somewhere else we 
should check?  [/usr/local/lib64] /usr/local/lib64

We're still not finding modhmm either in your dynamic linker path 
(/etc/ld.so.conf) or
in /usr/local/lib64.

Do you want to continue anyways? [Y/n] [Y] Y
Writing MYMETA.yml and MYMETA.json
Generating a Unix-style Makefile
Writing Makefile for Bio::Tools::PSort
Writing MYMETA.yml and MYMETA.json
Updating psort/bin/psort with path hints
Making sclblast databases


Building a new DB, current time: 05/05/2024 12:55:03
New DB name:   /<>/psort/conf/analysis/sclblast/gramneg/sclblast
New DB title:  sclblast
Sequence type: Protein
Keep MBits: T
Maximum file size: 10B


Error: NCBI C++ Exception:
T0 "c++/include/corelib/ncbidiag.hpp", line 2490: Error: 
(CSeqIdException::eFormat) ncbi::objects::CSeq_id::Set() - Malformatted ID 
15596049[Extracellular]

Program failed, try executing the command manually.


Building a new DB, current time: 05/05/2024 12:55:04
New DB name:   /<>/psort/conf/analysis/sclblast/grampos/sclblast
New DB title:  sclblast
Sequence type: Protein
Keep MBits: T
Maximum file size: 10B


BLAST Database creation error: Error: Duplicate seq_ids are found:
LCL|145559529

Program failed, try executing the command manually.


Building a new DB, current time: 05/05/2024 12:55:04
New DB name:   /<>/psort/conf/analysis/sclblast/archaea/sclblast
New DB title:  sclblast
Sequence type: Protein
Keep MBits: T
Maximum file size: 10B
FASTA-Reader: Ignoring invalid residues at position(s): On line 46049: 38
FASTA-Reader: Ignoring invalid residues at position(s): On line 87237: 23
FASTA-Reader: Title ends with at least 50 valid amino acid characters.  Was the 
sequence accidentally put in the title line?
FASTA-Reader: Ignoring invalid residues at position(s): On line 87252: 4
FASTA-Reader: Ignoring invalid residues at position(s): On line 87263: 8


BLAST Database creation error: Error: Duplicate seq_ids are found:
LCL|15596641

Program failed, try executing the command manually.

Ready for make, next steps you must run:
$ make
$ make test
$ make install
RECOMMENDED:
cp -r psort /usr/local/psortb

PSortb will then be available at /usr/local/psortb/bin/psort or in your path 
depending on your configuration

make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
# hack around the issue that configure injects wrong root dir 

Bug#1070458: gxneur: FTBFS: Package 'libpcre', required by 'xnconfig', not found

[Santiago Vila]

Package: src:gxneur
Version: 0.20.0-2.2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules build
dh build --with autoreconf
   dh_update_autotools_config
cp -an --reflink=auto config.guess 
debian/.debhelper/bucket/files/8f48881bdc7f19036aeee45dd75b999aff372af0ac0c4b6a048e3d80d1162464.tmp
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
mv 
debian/.debhelper/bucket/files/8f48881bdc7f19036aeee45dd75b999aff372af0ac0c4b6a048e3d80d1162464.tmp
 
debian/.debhelper/bucket/files/8f48881bdc7f19036aeee45dd75b999aff372af0ac0c4b6a048e3d80d1162464
cp -f /usr/share/misc/config.guess ./config.guess
cp -an --reflink=auto config.sub 
debian/.debhelper/bucket/files/75d5d255a2a273b6e651f82eecfabf6cbcd8eaeae70e86b417384c8f4a58d8d3.tmp
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
mv 
debian/.debhelper/bucket/files/75d5d255a2a273b6e651f82eecfabf6cbcd8eaeae70e86b417384c8f4a58d8d3.tmp
 
debian/.debhelper/bucket/files/75d5d255a2a273b6e651f82eecfabf6cbcd8eaeae70e86b417384c8f4a58d8d3
cp -f /usr/share/misc/config.sub ./config.sub
   dh_autoreconf
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} + -o 
-type l -printf "symlink  %p
" > debian/autoreconf.before

[... snipped ...]

cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not 
for C
configure:11458: $? = 0
configure:11471: result: no
configure:11835: checking for gcc option to produce PIC
configure:11843: result: -fPIC -DPIC
configure:11851: checking if gcc PIC flag -fPIC -DPIC works
configure:11870: gcc -c -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPIC -DPIC 
conftest.c >&5
configure:11874: $? = 0
configure:11887: result: yes
configure:11916: checking if gcc static flag -static works
configure:11945: result: yes
configure:11960: checking if gcc supports -c -o file.o
configure:11982: gcc -c -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -o 
out/conftest2.o conftest.c >&5
configure:11986: $? = 0
configure:12008: result: yes
configure:12016: checking if gcc supports -c -o file.o
configure:12064: result: yes
configure:12097: checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) 
supports shared libraries
configure:13371: result: yes
configure:13408: checking whether -lc should be explicitly linked in
configure:13417: gcc -c -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 
>&5
configure:13420: $? = 0
configure:13435: gcc -shared  -fPIC -DPIC conftest.o  -v -Wl,-soname -Wl,conftest -o conftest 
2\>\&1 \| /usr/bin/grep  -lc  \>/dev/null 2\>\&1
configure:13438: $? = 0
configure:13452: result: no
configure:13612: checking dynamic linker characteristics
configure:14194: gcc -o conftest -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro 
-Wl,-rpath -Wl,/foo conftest.c  >&5
configure:14194: $? = 0
configure:14445: result: GNU/Linux ld.so
configure:14567: checking how to hardcode library paths into programs
configure:14592: result: immediate
configure:15144: checking whether stripping libraries is possible
configure:15153: result: yes
configure:15195: checking if libtool supports shared libraries
configure:15197: result: yes
configure:15200: checking whether to build shared libraries
configure:15225: result: yes
configure:15228: checking whether to build static libraries
configure:15232: result: yes
configure:15272: checking for XNEURCONF
configure:15280: $PKG_CONFIG --exists --print-errors "xnconfig = 0.20.0"
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpcre', required by 'xnconfig', not found
configure:15283: $? = 1
configure:15298: $PKG_CONFIG --exists --print-errors "xnconfig = 0.20.0"
Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpcre', required by 'xnconfig', not found
configure:15301: $? = 1
Package 'libpcre', 

Bug#1070456: crystal: FTBFS: failing tests

[Santiago Vila]

Package: src:crystal
Version: 1.11.2+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -- release=1 verbose=1 progress=1 threads=2 
CRYSTAL_CONFIG_PATH="lib:/usr/lib/crystal/lib" CRYSTAL_CACHE_DIR="/tmp/crystal" 
interpreter=1
make -j2 "INSTALL=install --strip-program=true" release=1 verbose=1 
progress=1 threads=2 CRYSTAL_CONFIG_PATH=lib:/usr/lib/crystal/lib 
CRYSTAL_CACHE_DIR=/tmp/crystal interpreter=1
make[2]: Entering directory '/<>'
Using /usr/bin/llvm-config-17 [version= 17.0.6]g++ -c -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection  -o 
src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc -I/usr/lib/llvm-17/include -std=c++17   
-fno-exceptions -funwind-tables -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
CRYSTAL_CONFIG_BUILD_COMMIT="" CRYSTAL_CONFIG_PATH=lib:/usr/lib/crystal/lib 
SOURCE_DATE_EPOCH="1709233884"  CRYSTAL_CONFIG_LIBRARY_PATH='$ORIGIN/../lib/crystal' ./bin/crystal 
build -D strict_multi_assign -D preview_overload_order --release --progress --threads 2 
--link-flags="-Wl,-z,relro"  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D 
without_zlib -D use_pcre2
[1/13] Parse
[1/13] Parse

[... snipped ...]

"out"
"out"
"%w"
"%w"
"1 /2"
"1 /2"
"foo"
"foo"
"then"
"then"
"def //"
"def //"
"1 || 2"
"1 || 2"
"def +"
"def +"
"1 ! 2"
"1 ! 2"
"def []="
"def []="
"def >"
"def >"
"foo bar"
"foo bar"
"1 &-= 2"
"1 &-= 2"
"1 != 2"
"1 != 2"
"%(foo)"
"%(foo)"
"$1"
"$1"
"1 [] 2"
"1 [] 2"
"def =="
"def =="
"def >="
"def >="
"a /b/"
"a /b/"
"# foo\n# bar\n"
"# foo\n# bar\n"
"1 &*= 2"
"1 &*= 2"
"def <=>"
"def <=>"
"1 <= 2"
"1 <= 2"
"# foo"
"# foo"
"while"
"while"
"asm"
"asm"
"uninitialized"
"uninitialized"
"require"
"require"
"1 * 2"
"1 * 2"
"'a'"
"'a'"
"include"
"include"
"foo\nbar"
"foo\nbar"
"break"
"break"
"foo, bar = <<-FOO, <<-BAR\n  foo\n  FOO\n  bar\n  BAR"
"foo, bar = <<-FOO, <<-BAR\n  foo\n  FOO\n  bar\n  BAR"
"instance_alignof"
"instance_alignof"
"false"
"false"
"offsetof"
"offsetof"
"3.14"
"3.14"
"def !="
"def !="
  #highlight!
"\"foo"
"\"foo"
"foo, bar = <<-FOO, <<-BAR\n  foo"
"foo, bar = <<-FOO, <<-BAR\n  foo"
"foo, bar = <<-FOO, <<-BAR\n  foo\n  FOO"
"foo, bar = <<-FOO, <<-BAR\n  foo\n  FOO"
"%i[foo"
"%i[foo"
"%w[foo"
"%w[foo"
"foo = bar(\"baz\#{PI + 1}\") # comment"
"foo = bar(\"baz\#{PI + 1}\") # comment"
Process::Status
  #normal_exit?
  #normal_exit?
  #exit_signal
  #exit_signal
  #exit_reason
returns Interrupted
returns Interrupted
returns BadMemoryAccess
returns BadMemoryAccess
returns Aborted
returns Aborted
returns AccessViolation
returns AccessViolation
returns Normal
returns Normal
returns Breakpoint
returns Breakpoint
returns FloatException
returns FloatException
returns BadInstruction
returns BadInstruction
  #signal_exit?
  #signal_exit?
  #exit_code
  #exit_code
  #success?
  #success?
  #inspect
with exit status
with exit status
with exit signal
with exit signal
  #signal_exit? with signal code
  #signal_exit? with signal code
  equality
  equality
  #normal_exit? with signal code
  #normal_exit? with signal code
  #to_s
with exit signal
with exit signal
with exit status
with exit status
IO::Hexdump
  read
prints hexdump
prints hexdump
  write
prints hexdump
prints hexdump
WeakRef(T)
  FinalizeState counts released objects
  FinalizeState counts released objects
  Referenced object should not be released
  Referenced object should not be released
Unhandled exception in spawn: SSL_read: I/O error (OpenSSL::SSL::Error)
  from src/io.cr:121:11 in 'unbuffered_read'
  from src/io/buffered.cr:264:5 in 'peek'
  from src/http/request.cr:180:15 in 'process'
  from src/http/server.cr:506:5 in '->'
  from src/fiber.cr:146:11 in 'run'
  from ???
Caused by: SSL_read: Resource temporarily unavailable (RuntimeError)
  should get dereferenced object
  should get dereferenced object
  Weak referenced object should be released if no other reference
  Weak referenced object should be released if no other reference
  should not crash with object in data section during GC
  should not crash with object in data section during GC
  should get 

Bug#1070455: ayatana-indicator-display: FTBFS: Errors while running CTest

[Santiago Vila]

Package: src:ayatana-indicator-display
Version: 24.1.1-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DENABLE_TESTS=ON -DENABLE_COVERAGE=OFF 
-DENABLE_LOMIRI_FEATURES=ON -DENABLE_COLOR_TEMP=ON
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DENABLE_TESTS=ON -DENABLE_COVERAGE=OFF 
-DENABLE_LOMIRI_FEATURES=ON -DENABLE_COLOR_TEMP=ON ..
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features

[... snipped ...]

2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body: 
("type='signal',sender='org.freedesktop.Accounts',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/freedesktop/Accounts/User924',arg0='org.freedesktop.DBus.Properties'",)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    RECEIVED D-Bus message (169 bytes)
2:   Type:signal
2:   Flags:   no-reply-expected
2:   Version: 0
2:   Serial:  2
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'NameAcquired'
2: destination -> ':1.0'
2: sender -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body: (':1.0',)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Signal:
2:   RECEIVED SIGNAL org.freedesktop.DBus.NameAcquired
2:   on object /org/freedesktop/DBus
2:   sent by name org.freedesktop.DBus
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (281 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  3
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body: 
("type='signal',sender='org.freedesktop.Accounts',interface='org.freedesktop.DBus.Properties',path='/org/freedesktop/Accounts/User924'",)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (312 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  4
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'AddMatch'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 's'
2:   Body: 
("type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.Accounts'",)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    RECEIVED D-Bus message (72 bytes)
2:   Type:method-return
2:   Flags:   no-reply-expected
2:   Version: 0
2:   Serial:  3
2:   Headers:
2: reply-serial -> uint32 2
2: destination -> ':1.0'
2: sender -> 'org.freedesktop.DBus'
2:   Body: ()
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    SENT D-Bus message (188 bytes)
2:   Type:method-call
2:   Flags:   none
2:   Version: 0
2:   Serial:  5
2:   Headers:
2: path -> objectpath '/org/freedesktop/DBus'
2: interface -> 'org.freedesktop.DBus'
2: member -> 'StartServiceByName'
2: destination -> 'org.freedesktop.DBus'
2: signature -> signature 'su'
2:   Body: ('org.freedesktop.Accounts', uint32 0)
2:   UNIX File Descriptors:
2: (none)
2: 
2: GDBus-debug:Message:
2:    RECEIVED D-Bus message (72 bytes)
2:   Type:method-return
2:   Flags:   no-reply-expected
2:   

Bug#1070321: transition: nginx ABI change: nginx-abi-1.24.0-1 -> nginx-abi-1.26.0-1

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-05-03 19:08:58 +0200, Jan Mojzis wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: ng...@packages.debian.org
> Control: affects -1 + src:nginx
> 
> Hi,
> 
> a new version 1.26.0 of nginx has been released.
> 
> I have uploaded version 1.26.0-1~exp1 to the experimental and
> would like to upload the new nginx 1.26.0-1 version to the unstable.
> 
> And with the upload of 1.26.0-1 nginx to unstable,
> the nginx ABI version changes at the same time. Previous ABI 
> nginx-abi-1.24.0-1, new ABI nginx-abi-1.26.0-1.
> 
> Therefore, we would also need to rebuild all 3rd party nginx modules 
> (libnginx-mod-* packages)
> which depends on nginx. Hence the transition request.
> 
> Furthermore, this upload/rebuild solves the problem that arises at time_t 64 
> transition:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069997

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1070043: transition: wireplumber 0.5

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-04-29 11:16:46 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: affects -1 + src:wireplumber
> 
> Dear Release Team,
> 
> Please schedule a transition slot for wireplumber 0.5.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1070348: pipewire: pipewire-pulse: warningin syslog every second for snap_get_audio_permissions

[Jeremy Bícha]

On Sat, May 4, 2024 at 4:00 AM Dylan Aïssi  wrote:
>
> Hello Sergio and Jeremy,
>
> Le sam. 4 mai 2024 à 05:48, Michael Welsh Duggan  a écrit :
> >
> > After updating my linux kernel to 6.7.12-1, I keep getting the following
> > message in my syslog, once a second:
> >
> > pipewire-pulse[]: default: snap_get_audio_permissions: kernel lacks
> > 'fine grained unix mediation'; snap audio permissions won't be honored.
> >
>
> It seems that snap support in pipewire requires a kernel feature
> (fine grained unix mediation) that is not yet enabled in Debian.
>
> I'm thinking of disabling for now the snap support in Debian since
> there is no point in keeping it enabled if it's unusable. But, I will
> keep it enabled for Ubuntu. What do you think?

That makes sense to me.

Thank you,
Jeremy Bícha

Bug#1069919: transition: kimageannotator

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-04-26 23:51:19 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> Control: affects -1 + src:kimageannotator
> X-Debbugs-Cc: kimageannota...@packages.debian.org couc...@debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: by...@debian.org
> Severity: normal
> 
> I would like to initiate the following listed transitions together
> since they are tightly bundled together:
> 
> * https://release.debian.org/transitions/html/auto-kimageannotator.html
> * https://release.debian.org/transitions/html/auto-kcolorpicker.html

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1070258: release-notes: Approach to managing other package managers when upgrading needs documentation

[Justin B Rye]

Manny wrote:
> One of the ways I got burnt in the Bullseye → Bookworm full-upgrade is
> documented here:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070203
> 
> There was no signal given before, during, or after the upgrade warning
> that the non-debian python app “argostranslate” would be ruined. It
> was just a surprise the next time the app was needed that it no longer
> functioned.

The Debian package-management system can never guarantee that software
it doesn't know about will continue to work through an upgrade (even
to a new backport kernel, never mind a whole new stable release).  If
what happened in this case was that pip3 installed code relying on a
particular version of Python, and then you upgraded the system version
of Python, then there are two approaches to protecting yourself: you
can either stick to Debian packaged Python apps, or set up a whole
separate local Python environment that you take responsibility for.

In theory, non-Debian code ecosystems could help you out here by doing
their own OS-compatibility tests and maintaining their own "release
notes".  But that's a lot of work, and unfortunately the developers
who'd need to be doing it have a tendency to ignore OS distributions -
hence all that upstream pip documentation that didn't warn you about
this.

> I’m not sure if the release notes could give any detailed guidance,
> but users should probably be instructed to minimally become aware of
> packages that are at risk. These existing sections are probably
> relevant:
> 
>   4.2.6. Remove non-Debian packages

When this says "packages", it means in the APT sense of the word; you
aren't necessarily expected to remove the things that "pip3 list"
would tell you about, just to be aware of them as things that you need
to take care of.

>   4.2.13. Check package status
> 
> Perhaps users should probably be instructed to run:
> 
>   $ pip list
>   $ pip3 list
>   $ pipx list
> 
> to at least become aware of non-Debian packages that might be impacted
> so they can be reminded to give some thought to it. IMO it’s sensible
> to save the lists from that output to a file and then refer to it
> post-upgrade to test these fragile apps so the nasty surprise of lost
> functionality does not manifest at the time that they need to use it,
> which is about the worst time to discover the loss.
> 
> Rust also has its own package manager (cargo), as does emacs. I have
> no idea if they have the same special needs that pip does. I don’t
> think cargo gives a listing mechanism so perhaps nothing can be done
> there.

There are myriad different available potential footguns of this
general sort: one or more for every active programming language
ecosystem, plus flatpak, make install, and so on.  Once you're using a
local Python environment, there might also be alternatives too new for
the most recent Debian Release Notes to know about.

One workaround that we occasionally try is to have the Release Notes
point at a Debian Wiki page that goes into all the details at length.
In principle that would be possible here, but who would write it?  As
far as I can see nobody has ever bothered to put any information about
pip/pip3/pipx on the Debian wiki in all the years they've existed.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Mo Jun]

Package: transmission-daemon
Followup-For: Bug #1051056

Hi Alex,

My laptop is running Debian sid and I am using transmission-daemon consistently
from long time ago. I didn't observed any memory leak from 4.0.1-1(see [1] if
you are interested) to the current version(4.0.5-2).

By the way, as mentioned in [2], I think this bug is a duplicate of #1015003.
And I think it is also a duplicate of LP: #1973084 [3]. See the Bug Description
of LP: #1973084 for a good summary. If this bug is indeed a duplicate, it would
have been already fixed in unstable, testing and stable, and it does not exist
in oldstable and all older release. Also please note the submitter apparently
uses the stable realse.

Note: I deliberately do not merge/close this bug, as I think it is better
leave it for the Maintainer or the Submitter.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015003#25
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051056#22
[3] https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1973084

Regards,
Jun MO

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

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

Versions of packages transmission-daemon depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66-0local2
ii  libc62.38-7
ii  libcurl4t64  8.7.1-5
ii  libdeflate0  1.20-1
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libgcc-s114-20240429-1
ii  libminiupnpc17   2.2.6-1
ii  libnatpmp1t6420230423-1.2
ii  libssl3t64   3.2.1-3
ii  libstdc++6   14-20240429-1
ii  libsystemd0  255.5-1
ii  transmission-common  4.0.5-2

Versions of packages transmission-daemon recommends:
ii  transmission-cli  4.0.5-2

Versions of packages transmission-daemon suggests:
pn  transmission-remote-gtk | transgui | tremotesf  

-- Configuration Files:
/etc/default/transmission-daemon changed:
ENABLE_DAEMON=0
CONFIG_DIR="/var/lib/transmission-daemon/info"
OPTIONS="--config-dir $CONFIG_DIR"

/etc/transmission-daemon/settings.json [Errno 13] Permission denied:
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#1055755: transition: libre/rem/baresip

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-04-12 21:29:09 +0200, Bastian Germann wrote:
> Control: tags -1 - moreinfo
> 
> On Fri, 10 Nov 2023 22:34:49 +0100 Sebastian Ramacher  
> wrote:
> > Did you coordinate this plan with the maintainer of libre?
> 
> I am now part of the maintaining team and confirm my request.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults

[Justin B Rye]

RL wrote (https://lists.debian.org/debian-doc/2024/05/msg3.html):
> Guilhem Moulin  writes:
>> cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain
>> mode when relying on defaults cipher and password hashing algorithm.
>>
>> The change affects users upgrading from bookworm to trixie.  Plain mode
>> is generally advised against but it still makes sense to include the
>> NEWS entry into the release notes.
> 
> The text needs a bit of intro/context to be readable by an end-user. Can
> you give some pointers to explain the basic issue here - what is "plain
> mode"? is it the default now? what is the change, and what is the user
> meant to do about in response to this change? what is the
> "incompatability"?

I imagine it's connected with the Changelog entry saying:

# + plain mode: Set default cipher to aes-xts-plain64 and password hashing
#   to sha256.  This is a backward incompatible change for plain mode when
#   relying on the defaults.  It doesn't affect LUKS volumes.  Defaults for
#   plain mode should not be relied upon anyway; for many releases the
#   Debian wrappers found in the 'cryptsetup' binary package spew a loud
#   warning when 'ciphers' or 'hash=' are not explicitly specified in the
#   crypttab(5) options of plain devices.  The cryptsetup(8) executable now
#   issue such a warning as well.
 
(But I can't answer any of your questions, except that I noticed a
mention elsewhere of plain mode being the default.)

>>   Default cipher and password hashing for plain mode have respectively
>>   been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256
>>   resp. ripemd160).
> 
> It would help to start with "The" before "default".
> 
> what does "resp." mean in this context?

This one I know (and there's a clue earlier in the sentence): it's a
common non-native-English-speakerism.  "Resp." is short for "and/or
respectively", but it's used where anglophones would be more likely to
use plain "and" or "or", and it's a warning sign of a tortuously
organised sentence.  I'd suggest:
  The default cipher has been changed to aes-xts-plain64 (from
  aes-cbc-essiv:sha256), and the default hash to sha256 (from ripemd160).

(I see crypttab(5) is absolutely infested with resps.)

> Is there a crucial word missing after "hashing" - should it be "hash
> function"?

That (or "password hashing algorithm") would be more natural English,
but it might be better to stick to "hash" since that's the name of the
crypttab field.
 
>>   The new values matches what is used for LUKS, but the change does NOT
>>   affect LUKS volumes.
> 
> "value" not "values" here

(In fact I think he means "the new values match what is used...")

> (assuming LUKS is a noun) "by LUKS" not "for LUKS"?

(No idea.)
 
> the bit after the comma is pretty confusing to a non-expert like me,
> what are you trying to say here? would i expect a change in cryptsetup
> what *does* the change affect?

(No idea.)
 
>>   This is a backward incompatible change for plain mode when relying on
>>   the defaults, which (for plain mode only) is strongly advised
>>   against.
> 
> i'm afraid I cant make any sense out of this paragraph! what is
> "strongly advised against"?

"Relying on the defaults" - that is, leaving the fields empty in
crypttab.
 
>>   For many releases the Debian wrappers found in the ‘cryptsetup’ binary
>>   package have spewed a loud warning for plain devices from crypttab(5)
>>   where ‘cipher=’ or ‘hash=’ are not explicitly specified.  The
>>   cryptsetup(8) executable now issue such a warning as well.
> 
> Is this an unrelated change or is there some link to the above?

Part of the same deprecation process.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1069700: transition: rpm

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-04-23 01:59:12 +0100, Luca Boccassi wrote:
> Package: release.debian.org
> Control: affects -1 + src:rpm
> X-Debbugs-Cc: team+pkg-...@tracker.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> 
> Dear Release Team,
> 
> A new RPM version is available and has been uploaded and accepted in
> experimental as version 4.19.1.1+dfsg-1~exp, and it introduces an ABI
> bump from soname version 9 to 10 for the library packages shipped from
> src:rpm.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Andreas Metzler]

On 2024-05-04 Santiago Vila  wrote:
> found 1064486 0.16.3-1
> tags 1064486 + ftbfs bookworm trixie sid
> thanks

> El 20/4/24 a las 14:12, Andreas Metzler escribió:
> > FWIW I also get testsuite errors on current sid on amd64
> > The following tests FAILED:
> >   83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
> >   90 - rnp_tests.test_ffi_security_profile (Failed)
> >  174 - rnp_tests.test_key_add_userid (Failed)
> >  254 - cli_tests-EncryptElgamal (Failed)

> Hello. This is also happening in bookworm, I assume that for the same 
> underlying reason,
> so I'm adding the bookworm version.
[...]


Hmm. Perhaps a timebomb, i.e. one of the keys used in the testsuite
expired.

cu Andreas

Bug#1063770: transition: mupdf

[Sebastian Ramacher]

control: tags -1 moreinfo

On 2024-02-12 23:30:58 +0900, Kan-Ru Chen wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: mu...@packages.debian.org, pymu...@packages.debian.org, 
> sio...@packages.debian.org, ippsam...@packages.debian.org
> Control: affects -1 + src:mupdf
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi Release Team,
> 
> This is a somewhat unusual transition request. The libmupdf-dev package
> used to only ship static library archives due to upstream preference.
> Recently upstream started to provide makefiles for building shared library
> so I think it's time to ship shared library in Debian.
> 
> I've uploaded the new version to experimental (binary package libmupdf23.10)
> and tried to build the affected reverse build-deps (Cc'ed).
> 
> ippsample - doesn't seem to use mupdf at all
> pymupdf - requires some changes. Likely also needs to update to new upstream 
> version.
> sioyek - requires some changes to drop extra linker flags.

Have bugs been filed for these issues?

Cheers
-- 
Sebastian Ramacher

Bug#1061267: transition: unixcw

[Sebastian Ramacher]

control: tags -1 confirmed

On 2024-01-21 11:21:03 -0800, tony mancill wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: uni...@packages.debian.org
> Control: affects -1 + src:unixcw
> 
> Dear Release Team,
> 
> I am requesting a transition for unixcw [1].  The one reverse
> dependency, cwdaemon, builds correctly against the package in
> experimental.  The auto-transition page is [2].

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1064810: transition: mpi-defaults

[Sebastian Ramacher]

On 2024-05-05 17:59:40 +0200, Sebastiaan Couwenberg wrote:
> On 2/26/24 7:40 AM, Alastair McKinstry wrote:
> > OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.
> 
> This transition is blocking many of the remaining packages rebuilt for
> 64-bit time_t.
> 
> The autopkgtest for slurm-wlm on i386 is blocking testing migration of
> mpich:
> 
>  https://qa.debian.org/excuses.php?package=mpich
> 
> Testing migration of openmpi is likewise blocked by autopkgtest failures on
> i386 of several rdeps:
> 
>  https://qa.debian.org/excuses.php?package=openmpi
> 
> I'm starting to think that it'd be better to drop support for 32bit
> architectures from all these rdeps so they can just use openmpi everywhere
> and not have i386 autopkgtest failures able to block testing migration.

openmpi should migrate with the next britney run.

After that we can look into starting the transition to change
mpi-defaults on 32 bit architctures. That is currently

https://release.debian.org/transitions/html/mpi-defaults.html

This will also require changes to hdf5. Have they been prepared
somewhere?

Cheers
-- 
Sebastian Ramacher

Bug#1070348: pipewire: pipewire-pulse: warningin syslog every second for snap_get_audio_permissions

[Jelle Haandrikman]

Package: pipewire-pulse
Version: 1.0.5-1+b3
Followup-For: Bug #1070348
X-Debbugs-Cc: jha...@freedom.nl

Dear Maintainer,

I run Debian Trixie and I still have this problem. Althought the error message
only occurs every 5 seconds.

May  5 18:15:46 mainbak pipewire-pulse[2168]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.
May  5 18:15:51 mainbak pipewire-pulse[2168]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.
May  5 18:15:56 mainbak pipewire-pulse[2168]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.
May  5 18:16:01 mainbak pipewire-pulse[2168]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.

I would like to know how to bypass this problem for now.

best regards,
Jelle


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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.66
ii  pipewire 1.0.5-1+b3

Versions of packages pipewire-pulse recommends:
ii  wireplumber  0.4.17-1+b2

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  1.0.5-1+b3
ii  pulseaudio-utils  16.1+dfsg1-5

-- no debconf information

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Nilesh Patra]

On Sat, May 04, 2024 at 08:59:19PM +0530, Nilesh Patra wrote:
> Hi Matt,
> 
> Quoting Matt Taggart:
> >  Package: riseup-vpn
> >  Version: 0.21.11+ds1-5+b1
> >  Severity: grave
> >  
> >  When attempting to run the bookworm riseup-vpn package, it fails to 
> >  connect to riseup's servers and gives the following output:
> >  
> >  2024/05/01 18:21:23 Error fetching eip v3 
> >  json:https://api.black.riseup.net/3/config/eip-service.json
> >  
> >  My understanding is that this is due to the package failing to be able 
> >  to verify the current LetsEncrypt cert that host is using. More details at
> >  
> >  https://0xacab.org/leap/bitmask-vpn/-/issues/768
> >  
> >  (supposedly the current upstream snap has this fixed, but I haven't 
> >  tried it)
> >  
> >  As this breaks what the package is supposed to do (at least when using 
> >  riseup as provider, maybe there is a way to point it elsewhere?) I think 
> >  this is grave. Also I think it might be a good candidate for being fixed 
> >  in a stable release update.
> 
> If I am not mistaken, as per the said, issue, it is fixed in the commit
> referenced here, right?
> 
>   
> https://0xacab.org/leap/bitmask-vpn/-/commit/14cf64b10a97c29688f252a7d9d3481c8484aa1d
> 
> I tried this in my testing system and it seems I am able to connect to the VPN
> with this patch applied. Can you confirm?

I tried with this commit using my stable `.deb` in a fresh stable VM and it
seems things are working.

> Consequently, I also did some work to cherry-pick this and prepare a 
> stable-p-u
> upload (not yet uploaded, will do after confirmation) and pushed my changes
> at[1]. I have also compiled the `.deb` for stable and it is ready to be
> consumed[2]. Do you think you could ask someone to check the same?
> 
> Other than that, I also tried to update the package in unstable to the latest
> version to fixup this properly. I was able to build it, pushed my changes
> here[3] and the `.deb` is available here[4]. Again, if you/someone else could
> try this, it'd be great. It is working for me on my debian/testing system.

I asked a friend to check on their testing system and it seems to be working as
well. I will proceed to upload these in a week or so. Until then I am awaiting
your response.

> I would have attemped the update much sooner but unfortunately an update with
> 0xacab's gitlab broke my d/watch file and I did not notice a new version is 
> out
> there sooner.
> 
> I was thinking to go ahead with an upload, but there are a few things that I
> would like to clarify before I do so (btw thanks to the maintainers for
> committing a patch to use with qt6.4):
> 
> 1. Why is the default provider set to "provider = bitmask" in
> providers/vendor.conf? This leads to building the binary called bitmask-vpn
> instead of riseup-vpn. Is there a thought of changing the binary name?
> 
> In current stage it points to just dummy APIs and hence I overrode it in 
> d/rules
> to build riseup-vpn instead.
> 
> 2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
> BSD-2-Clause, BSD-3-Clause and also GPL-3 for
> vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so 
> what
> exactly is the exact license? Is it redistributable under all the three? (I
> don't think so?)
> 
> [1]: 
> https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
> [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
> [3]: 
> https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
> [4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/
> 
> Best,
> Nilesh


Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070428: bin86,elks-libc: copyright file missing (policy 12.5)

[Bastian Germann]

I am uploading another NMU to fix this issue. Sorry about that.
See the attached debdiff.diff -Nru 
linux86-0.16.17/debian/.debhelper/generated/bin86/installed-by-dh_installman 
linux86-0.16.17/debian/.debhelper/generated/bin86/installed-by-dh_installman
--- 
linux86-0.16.17/debian/.debhelper/generated/bin86/installed-by-dh_installman
1970-01-01 00:00:00.0 +
+++ 
linux86-0.16.17/debian/.debhelper/generated/bin86/installed-by-dh_installman
2024-05-05 15:26:06.0 +
@@ -0,0 +1,8 @@
+./debian/man/ar86.1
+./debian/man/objdump86.1
+./debian/man/ar86.1
+./debian/man/objdump86.1
+./debian/man/ar86.1
+./debian/man/objdump86.1
+./debian/man/ar86.1
+./debian/man/objdump86.1
diff -Nru linux86-0.16.17/debian/changelog linux86-0.16.17/debian/changelog
--- linux86-0.16.17/debian/changelog2024-02-21 13:47:40.0 +
+++ linux86-0.16.17/debian/changelog2024-05-05 15:26:06.0 +
@@ -1,3 +1,10 @@
+linux86 (0.16.17-3.6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move the package build directory. Closes: #1070428
+
+ -- Bastian Germann   Sun, 05 May 2024 15:26:06 +
+
 linux86 (0.16.17-3.5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru linux86-0.16.17/debian/rules linux86-0.16.17/debian/rules
--- linux86-0.16.17/debian/rules2024-02-21 13:47:40.0 +
+++ linux86-0.16.17/debian/rules2024-05-05 15:26:06.0 +
@@ -16,98 +16,95 @@
rm -f build
make realclean
rm -f ld/ar.h
-   rm -rf debian/tmp*
+   rm -rf debian/bcc debian/bin86 debian/elks-libc debian/tmp
rm -f debian/files debian/substvars
 
 binary:binary-indep binary-arch
 
 binary-common: build
@test 0 = `id -u` || { echo "Error: not super-user"; exit 1; }
-   rm -rf debian/tmp*
+   rm -rf debian/bcc debian/bin86 debian/elks-libc
install -d debian/tmp
make install DIST=`pwd`/debian/tmp
 #  exit 5
gzip -9f debian/tmp/usr/man/man?/*
 
 binary-indep:  binary-common
-   install -d debian/tmp-elks-libc/DEBIAN
+   install -d debian/elks-libc/DEBIAN
 
 # ``elks-libc'' specific things:
-   install -d debian/tmp-elks-libc/usr/lib/bcc/kinclude
-   mv debian/tmp/usr/lib/bcc/*.* debian/tmp-elks-libc/usr/lib/bcc
-   mv debian/tmp/usr/lib/bcc/include 
debian/tmp-elks-libc/usr/lib/bcc
-   install -d debian/tmp-elks-libc/usr/lib/bcc/kinclude
-   cp -a libc/kinclude/linuxmt 
debian/tmp-elks-libc/usr/lib/bcc/kinclude/linuxmt
-   cp -a libc/kinclude/arch 
debian/tmp-elks-libc/usr/lib/bcc/kinclude/arch
-   touch debian/tmp-elks-libc/usr/lib/bcc/*include/*/
-   mv debian/tmp/usr/lib/bcc/i386 debian/tmp-elks-libc/usr/lib/bcc
+   install -d debian/elks-libc/usr/lib/bcc/kinclude
+   mv debian/tmp/usr/lib/bcc/*.* debian/elks-libc/usr/lib/bcc
+   mv debian/tmp/usr/lib/bcc/include debian/elks-libc/usr/lib/bcc
+   install -d debian/elks-libc/usr/lib/bcc/kinclude
+   cp -a libc/kinclude/linuxmt 
debian/elks-libc/usr/lib/bcc/kinclude/linuxmt
+   cp -a libc/kinclude/arch 
debian/elks-libc/usr/lib/bcc/kinclude/arch
+   touch debian/elks-libc/usr/lib/bcc/*include/*/
+   mv debian/tmp/usr/lib/bcc/i386 debian/elks-libc/usr/lib/bcc
 #
-   install -d debian/tmp-elks-libc/usr/share/doc/elks-libc
-   cp -p Changes 
debian/tmp-elks-libc/usr/share/doc/elks-libc/changelog
-   cp -p Contributors README 
debian/tmp-elks-libc/usr/share/doc/elks-libc/
-   cp -p libc/README 
debian/tmp-elks-libc/usr/share/doc/elks-libc/README.libc
-   cp -p libbsd/README.HLU 
debian/tmp-elks-libc/usr/share/doc/elks-libc/README.libbsd
-   cp -p debian/changelog 
debian/tmp-elks-libc/usr/share/doc/elks-libc/changelog.Debian
-   install -d debian/tmp-elks-libc/usr/share/lintian/overrides
-   cp -p debian/lintian.overrides 
debian/tmp-elks-libc/usr/share/lintian/overrides/elks-libc
-   gzip -9f debian/tmp-elks-libc/usr/share/doc/elks-libc/*
+   install -d debian/elks-libc/usr/share/doc/elks-libc
+   cp -p Changes debian/elks-libc/usr/share/doc/elks-libc/changelog
+   cp -p Contributors README 
debian/elks-libc/usr/share/doc/elks-libc/
+   cp -p libc/README 
debian/elks-libc/usr/share/doc/elks-libc/README.libc
+   cp -p libbsd/README.HLU 
debian/elks-libc/usr/share/doc/elks-libc/README.libbsd
+   cp -p debian/changelog 
debian/elks-libc/usr/share/doc/elks-libc/changelog.Debian
+   install -d debian/elks-libc/usr/share/lintian/overrides
+   cp -p debian/lintian.overrides 

Bug#1070454: Fallback fonts do not work

[Chris Spiegel]

Package: gargoyle-free
Version: 2023.1+dfsg-4

I am the maintainer of Gargoyle. For reference, see
https://github.com/garglk/garglk/issues/822.

Gargoyle used to embed fonts in the binary, so that it always had
fonts to fall back on, no matter what. However, the SIL Open Font
License is incompatible with the GPL. Gargoyle needed new fonts with
wide Unicode support, and inevitably fonts with the OFL had to be
chosen, meaning Gargoyle can no longer embed these fonts.

Instead, Gargoyle has its own fonts that are installed and it
hard-codes paths to these fonts, which are used as fallback fonts. In
addition, Gargoyle hard-codes the path to GNU Unifont, which it also
installs.

The Debian package does not install these fonts, instead apparently
relying on system packages. But Gargoyle does not look at system fonts
for fallbacks, because it can't rely on them being installed. That's
why it includes its own copies of the fonts.  Note that fontconfig IS
used in normal operation to find fonts; it's just the fallback fonts
that it needs to find directly.

The following is what I wrote up in the issue referenced above as a
recommendation:

8< 

• Gargoyle needs to know the paths of fallback fonts. If you don't
want its fonts in /usr/share/fonts, then you can place them in
/usr/share/io.github.garglk/Gargoyle and modify
font_path_fallback_system in garglk/draw.cpp to unconditionally look
for them there. If you really want system fonts to be the fallback
instead, modify the gli_initialize_fonts function to include whatever
fonts you want, ensuring that font_path_fallback_system is looking in
the right place for them.

◦ Gargoyle used to embed fonts in the binary so that fallback
fonts always worked. But the fonts it was using lacked decent Unicode
coverage, and almost all modern fonts use the SIL Open Font License
which does not allow embedding in a GPL program. So Gargoyle now has
to find fonts externally. If a user specifies an invalid font,
Gargoyle will look for its fallback fonts, and if it can't find them,
it aborts.

• Either install Gargoyle's Unifont fonts (which by default go into
/usr/share/io.github.garglk/Gargoyle, so shouldn't interfere with
anything), or make the system's unifont package a dependency, and
modify make_substitution_fonts to point to the system unifont.

8< 

In short, to work properly, Gargoyle needs to know where its fonts
are, and won't rely on fontconfig to find them.  These fallback fonts
will only ever be used if the user's specified fonts can't be found,
or in the case of Unifont, it will be used if the selected font is
missing a glyph.

Bug#1064810: transition: mpi-defaults

[Sebastiaan Couwenberg]

On 2/26/24 7:40 AM, Alastair McKinstry wrote:

OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.


This transition is blocking many of the remaining packages rebuilt for 
64-bit time_t.


The autopkgtest for slurm-wlm on i386 is blocking testing migration of 
mpich:


 https://qa.debian.org/excuses.php?package=mpich

Testing migration of openmpi is likewise blocked by autopkgtest failures 
on i386 of several rdeps:


 https://qa.debian.org/excuses.php?package=openmpi

I'm starting to think that it'd be better to drop support for 32bit 
architectures from all these rdeps so they can just use openmpi 
everywhere and not have i386 autopkgtest failures able to block testing 
migration.


Should we advocate this to the maintainer of these packages or is there 
something else we can do to improve this situation?


Kind Regards,

Bas

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

Bug#1070453: pokefmt does not have a manpage

[Carlos Henrique Lima Melara]

Package: poke
Severity: wishlist
Tags: patch
X-Debbugs-Cc: charlesmel...@riseup.net

Dear Maintainer, hi!

I saw pokefmt doesn't have a manpage, so I've written one using
go-md2man and I'm attaching both files (the original markdown and the
generated manpage) here.

I'm not sending a patch because you might have a different opinion on
how to integrate it in your package. Only incorporate pokefmt.1, create
a helper script to generate the manpage, include a rule i d/rules to
generate it, only do it by hand...

In case you want to generate the manpage from the markdown file, the
command is:

go-md2man -in pokefmt.md.1 -out pokefmt.1

Cheers,
Charles
.nh
.TH pokefmt 1 "May 2024" pokefmt "User Manual"

.SH NAME
.PP
pokefmt - Template system to embed Poke code in files


.SH SYNOPSIS
.PP
\fBpokefmt\fP [POKE-CODE]

.PP
\fBpokefmt\fP [OPTIONS]


.SH DESCRIPTION
.PP
\fBpokefmt\fP copies the content from standard input to standard output and
replaces the Poke code with the result of execution. You can write Poke code
between \fB%{\fR and \fB}%\fR delimters. To simplify printing of expressions, 
pokefmt
also supports embedding of Poke expressions between \fB%(\fR and \fB%)\fR 
delimiters.


.SH OPTIONS
.TP
\fB-h\fP, \fB--help\fP
Show summary of options.

.TP
\fB-v\fP, \fB--version\fP
Show version of program.


.SH EXAMPLES
.PP
As as example, pokefmt will transform the following text

.EX
%{
  load riscv;

  var a = 1, b = 2;
}%
The encoding of ADD R3, R2, R1 instruction in RISC-V instruction set
is %{printf "0x%u32x", rv32_add (3, 2, 1);}%.

The result of %(a)% + %(b)% is %(a + b)%.
.EE

.PP
to this text:

.EX
The encoding of ADD R3, R2, R1 instruction in RISC-V instruct set
is 0x001101b3.

The result of 1 + 2 is 3.
.EE


.SH BUGS
.PP
Report bugs in the bug tracker at
https://sourceware.org/bugzilla/describecomponents.cgi?product=poke
or by email to \&.


.SH SEE ALSO
.PP
\fBpoke\fP(1)


.SH AUTHOR
.TP
Carlos Henrique Lima Melara \&.
Wrote this manpage for the Debian system in May 2024.
pokefmt 1 "May 2024" pokefmt "User Manual"
==

# NAME
pokefmt - Template system to embed Poke code in files

# SYNOPSIS
**pokefmt** [POKE-CODE]

**pokefmt** [OPTIONS]

# DESCRIPTION
**pokefmt** copies the content from standard input to standard output and
replaces the Poke code with the result of execution. You can write Poke code
between `%{` and `}%` delimters. To simplify printing of expressions, pokefmt
also supports embedding of Poke expressions between `%(` and `%)` delimiters.

# OPTIONS

**-h**, **\-\-help**
:   Show summary of options.

**-v**, **\-\-version**
:   Show version of program.

# EXAMPLES
As as example, pokefmt will transform the following text

```
%{
  load riscv;

  var a = 1, b = 2;
}%
The encoding of ADD R3, R2, R1 instruction in RISC-V instruction set
is %{printf "0x%u32x", rv32_add (3, 2, 1);}%.

The result of %(a)% + %(b)% is %(a + b)%.
```

to this text: 

```
The encoding of ADD R3, R2, R1 instruction in RISC-V instruct set
is 0x001101b3.

The result of 1 + 2 is 3.
```
# BUGS
Report bugs in the bug tracker at
https://sourceware.org/bugzilla/describecomponents.cgi?product=poke
or by email to \.

# SEE ALSO

**poke**(1)

# AUTHOR
Carlos Henrique Lima Melara \.
:   Wrote this manpage for the Debian system in May 2024.

Bug#1070430: vzlogger: logrotate exits with error after package removal

[Joachim Zobel]

Am Sonntag, dem 05.05.2024 um 11:12 +0200 schrieb Andreas Beckmann:
> Usually the solution is to specify 'missingok' in the logrotate
> configuration.

There is already a missingok in the configuration. So this is not
causing it. 

> From the attached log (scroll to the bottom...):
> 
> 0m27.6s DEBUG: Starting command: ['nsenter', 
> '--net=/run/netns/piuparts-netns-4', 
> '--uts=/srv/piuparts/tmp/tmprFiuJ6/ns-uts', 'chroot', 
> '/srv/piuparts/tmp/tmprFiuJ6/chroot', '/usr/sbin/logrotate', 
> '/etc/logrotate.d/vzlogger']
> 0m27.6s DUMP: 
>   error: /etc/logrotate.d/vzlogger:7 unknown user 'vzlogger'
>   error: found error in /var/log/vzlogger.log , skipping
> 0m27.6s ERROR: Command failed (status=1): ['nsenter', 
> '--net=/run/netns/piuparts-netns-4', 
> '--uts=/srv/piuparts/tmp/tmprFiuJ6/ns-uts', 'chroot', 
> '/srv/piuparts/tmp/tmprFiuJ6/chroot', '/usr/sbin/logrotate', 
> '/etc/logrotate.d/vzlogger']

Unfortunately the logrotate configuration had not been adapted when the
service users name had been changed from vzlogger to _vzlogger. 

This will be fixed with the next upload.

Thanks for the report,
Joachim

-- 
   Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und
archivieren Sie sie.

Bug#1063026: helvum: Upcoming gtk update

[Jeremy Bícha]

Control: severity -1 serious
Control: tags -1 + ftbfs

Jonas, the Rust GTK crates were uploaded to Unstable today. Could you
upload your helvum package from Experimental to Unstable?

Thank you,
Jeremy Bícha

Bug#1060738:

[Mikael Arguedas]

Hey there :wave:,

The version 3.6.8 is compatible with Python 3.12 that is now used in
experimental (and in Ubuntu 24.04). It would be lovely to be able to have
that version uploaded / supported.

I know little of the Debian process but am happy try and give a hand.

Thanks for all your work!

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

I've been looking at this test failure, but remain puzzled.

Basically, the source for this test is here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
This test is testing code in
https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
which has only two external dependencies
(golang-github-docker-distribution-dev) and
(golang-github-sirupsen-logrus-dev).

I've checked the build log of the previous build at
https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
and note that the same test passes in that build. This also uses the same
package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
golang-github-sirupsen-logrus-dev==1.9.0-1

I also note that the old build was using golang 1.21, and the FTBFS was
introduced after upgrading unstable to golang 1.22.

Shengjing, I believe you handled the recent update of the golang toolchain
from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
resulted from using a newer golang compiler?

I am considering just disabling this test, as the rest of the testsuite
seem to pass, but I'm getting nervous that this wouldn't just paper over a
real issue.

Thanks,


-- 
regards,
Reinhard

Bug#1070452: ITP: pytest-lazy-fixtures -- pytest plugin to use fixtures in @pytest.mark.parametrize

[Julian Gilbey]

Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
1063...@bugs.debian.org

* Package name: pytest-lazy-fixtures
  Version : 1.0.7
  Upstream Contact: Petrov Anton 
* URL : https://github.com/dev-petrov/pytest-lazy-fixtures
* License : Expat
  Programming Lang: Python
  Description : pytest plugin to use fixtures in @pytest.mark.parametrize

 This plugin was inspired by pytest-lazy-fixture; that plugin is incompatible
 with pytest 8.x, so this can be used as a replacement.
 .
 Improvements that have been made in this project:
 .
  * You can use fixtures in any data structures
  * You can access the attributes of fixtures
  * You can use functions in fixtures


This will allow those packages using pytest-lazy-fixture (which is now
unusable in debian/testing) in their tests to migrate to this
maintained alternative.  (See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957)

It will be maintained within the Debian Python Team, and I will be
listed as an Uploader.

Bug#1070451: Lenovo ThinkPad P16 Gen2 won't suspend to RAM on Linux, but will on Windows

[Josh Anders]

Package: linux-image-amd64
Version: 6.7.12-1
Severity: normal
Tags: upstream

Dear Maintainer(s),

I recently picked up a new ThinkPad P16 Gen2. It goes to sleep (suspends to 
RAM) fine on Windows. On Linux, it tries, but fails: the power light pulses, 
but all other activity remains the same (fans continue to spin, session doesn't 
lock, etc).

I've tried the following:

* Checking for updates to the UEFI firmware (there are none; it's up-to-date)
* Checking for power management options in the UEFI firmware (there are very 
few, basically just the ability to turn Intel SpeedStep on/off)
* Upgrading from Bookworm, to bookworm-backports, to Trixie
* Various kernel parameters (acpi_osi=Linux, acpi_osi='Windows 2022', 
acpi_osi='Windows 10', acpi=strict, noapic, etc.)
* An Ubuntu live image
* Compiling my own 6.8.9 kernel

Nothing has helped, so I am opening this bug report. I've attached:

* systemspecs.txt, a more detailed human-readable version of my system hardware
* lspci.txt, the output of lspci -vnn
* dmesg.txt, what happens when I try to suspend to RAM, then resume


Please let me know if you need any additional information or would like me to 
try anything else.


Thank you,
Josh Anders



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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-6.7.12-amd64  6.7.12-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information


ThinkPad P16 Gen 2 Intel (16″) Mobile Workstation
* Model: 21FACTO1WW
* Processor:  13th Generation Intel® Core™ i9-13980HX Processor (E-cores up to 
4.00 GHz P-cores up to 5.60 GHz) selected upgrade
* Operating System: None
* Operating System Language:  N/A
* Microsoft Productivity Software :  None
* Memory:  128 GB DDR5-3600MHz (SODIMM) - (4 x 32 GB) selected upgrade
* RAID Setting:  mdadm
* RAID Config:  RAID0
* First Solid State Drive: Samsung 990 PRO 4 TB
* Second Solid State Drive:  Samsung 990 PRO 4 TB
* SSD Total Capacity:  8 TB
* SSD Config:  SSD
* Display:  16" WQUXGA (3840 x 2400), OLED, Anti-Reflection/Anti-Smudge, Dolby 
Vision™, Touch, HDR 500 True Black, 100%DCI-P3, 400 nits, 60 Hz, Low Blue Light 
selected upgrade
* Factory Color Calibration :  Factory Color Calibration
* Graphic Card:  NVIDIA RTX™ A1000 Laptop GPU 6GB GDDR6 selected upgrade
* Camera:  1080P FHD RGB/IR Hybrid with Microphone selected upgrade
* Pen:  No Pen
* Wireless:  Intel® Wi-Fi 6E AX211 2x2 AX vPro® & Bluetooth® 5.1 or above
* Integrated Mobile Broadband:  Fibocom L860-GL-16 4G LTE CAT16 selected upgrade
* Near Field Communication:  NFC selected upgrade
* Fingerprint Reader:  Fingerprint Reader
* Keyboard:  Backlit, Grey with Number Pad - English (US)
* System Expansion Slots:  Smart Card Reader selected upgrade
* TPM Setting:  Enabled Discrete TPM2.0
* Absolute BIOS Selection:  BIOS Absolute Enabled
* vPro Certified Model:  Non vPro selected upgrade
* Battery:  6 Cell Li-Polymer 94Wh
* Power Cord:  230W Slim 3pin AC Adapter - US selected upgrade
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:a702] (rev 01)
Subsystem: Lenovo Device [17aa:2304]
Flags: bus master, fast devsel, latency 0, IOMMU group 1

00:01.0 PCI bridge [0604]: Intel Corporation Raptor Lake PCI Express 5.0 
Graphics Port (PEG010) [8086:a70d] (rev 01) (prog-if 00 [Normal decode])
Subsystem: Lenovo Device [17aa:2304]
Flags: bus master, fast devsel, latency 0, IRQ 122, IOMMU group 2
Bus: primary=00, secondary=01, subordinate=05, sec-latency=0
I/O behind bridge: 4000-4fff [size=4K] [16-bit]
Memory behind bridge: bd00-be0f [size=17M] [32-bit]
Prefetchable memory behind bridge: 60-6201ff [size=8224M] 
[32-bit]
Capabilities: [40] Express Root Port (Slot+), IntMsgNum 0
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [98] Subsystem: Lenovo Device [17aa:2304]
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [200] L1 PM Substates
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Capabilities: [a90] Data Link Feature 
Capabilities: [a9c] Physical Layer 16.0 GT/s 
Capabilities: [edc] Lane Margining at the Receiver
Capabilities: [adc] Physical Layer 32.0 GT/s 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor 

Bug#900928: Patches Fractal7 ?

[Jonas Smedegaard]

Quoting erebion (2024-05-05 15:27:32)
> On 05.05.24 14:51, Jonas Smedegaard wrote:
> >> Then I'll probably have to install the flatpac which I don't really
> >> like... too bad
> > No, you do not "have to", as there are other options:
> > https://wiki.debian.org/Matrix
> >
> > You might "prefer", depending on various criteria, but those are
> > irrelevant here, so please refrain from further elaborating on your
> > reasons for concluding that in your view you "have to" do something.
> >
> >
> >   - Jonas
> >
> 
> Woah, why so aggressive?

I was unaware that I was agressive: Sorry for any harm that my choice of
words may have caused.

> What is wrong with saying something like "I will have to look for other 
> ways of installing it, in order to use the software, as the method I was 
> hoping for is not available"?

What I find wrong is the "have to [...] use [this particular] software".

I am not upset about imposing such contraint, and (and stated above)
didn't mean to upset anyone by pointing out the constraint either.

What I wanted to do was bring attention to alternatives closer to Debian
than the use of flatpack. And then immediately after providing such
suggestion I wanted to make it clear that I am not inviting further
discussion here, regardless if about shifting packaging format or about
shifting application.


> I bet more people would work on free software if the communication was 
> more polite. And I might as well argue that your unfriendly 'You might 
> "prefer"' and telling someone that their polite response is "irrelevant 
> here" might be in itself an irrelevant response, don't you think?

I will not dive into the vast areas of what I don't think.

(hint: asking negative questions is passive agressive)

Regardless of your tone, I do appreciate your pointing out how my tone
can be perceived negatively.  Thanks for that.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1070450: qm-dsp: autopkgtest regression on arm64, ppc64el and s390x

[Sebastian Ramacher]

Source: qm-dsp
Version: 1.7.1-8
Severity: serious
X-Debbugs-Cc: sramac...@debian.org


qm-dsp currently fails to migrate due to autopkgtest failures on arm64,
ppc64el and s390x.

https://ci.debian.net/packages/q/qm-dsp/testing/arm64/46236204/

112s for t in test-mathutilities test-window test-fft test-pvoc test-resampler 
test-medianfilter; do echo "Running $t"; valgrind -q ./"$t" || exit 1; done
112s Running test-mathutilities
114s Running 11 test cases...
114s 
114s ␛[1;32;49m*** No errors detected
114s ␛[0;39;49mRunning test-window
115s Running 9 test cases...
115s 
115s ␛[1;32;49m*** No errors detected
115s ␛[0;39;49mRunning test-fft
116s Running 21 test cases...
116s 
116s ␛[1;32;49m*** No errors detected
117s ␛[0;39;49mRunning test-pvoc
118s Running 2 test cases...
118s TestPhaseVocoder.cpp(188): ␛[1;31;49merror: in "TestFFT/overlapping": 
absolute value of phase[cmp_i] - phaseExpected2[cmp_i]{1.5297327490291485e-07} 
exceeds 9.9995e-08␛[0;39;49m
118s TestPhaseVocoder.cpp(191): ␛[1;31;49merror: in "TestFFT/overlapping": 
absolute value of unw[cmp_i] - unwExpected2[cmp_i]{1.5297327493613011e-07} 
exceeds 9.9995e-08␛[0;39;49m
118s 
118s ␛[1;31;49m*** 2 failures are detected in the test module "Master Test 
Suite"
118s ␛[0;39;49mmake: *** [Makefile:13: all] Error 1

I've added a hint to get the t64 changes into testing.

Cheers
-- 
Sebastian Ramacher

Bug#1069789: test_bluetooth_hidpp_mouse autopkgtest fails

[Michael Biebl]

Control: severity -1 important

Seems to pass pretty reliably on debci, thus downgrading to important.
https://ci.debian.net/packages/u/upower/

Regards,
Michael

On Wed, 24 Apr 2024 23:34:48 +0500 Andrey Rakhmatullin  
wrote:

Package: upower
Version: 1.90.3-1
Severity: serious

Control: forwarded -1 https://gitlab.freedesktop.org/upower/upower/-/issues/228
Control: tags -1 + upstream

https://ci.debian.net/packages/u/upower/unstable/amd64/45053064/

217s ==
217s ERROR: test_bluetooth_hidpp_mouse
(__main__.Tests.test_bluetooth_hidpp_mouse)
217s Logitech Bluetooth LE mouse with HID++ kernel support
217s --
217s Traceback (most recent call last):
217s   File "/usr/libexec/upower/integration-test.py", line 2337, in
test_bluetooth_hidpp_mouse
217s self.assertEqual(self.get_dbus_dev_property(bat0_up, 'Model'), alias)
217s  
217s   File "/usr/libexec/upower/integration-test.py", line 273, in
get_dbus_dev_property
217s return self.dbus.call_sync(UP, device,
217s^^^
217s gi.repository.GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at
path “/org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_AA_BB” (19)


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

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

Versions of packages upower depends on:
ii  dbus   1.14.10-4+b1
ii  libc6  2.37-18
ii  libglib2.0-0t642.78.4-7
ii  libgudev-1.0-0 238-5
ii  libimobiledevice6  1.3.0-7.1+b1
ii  libplist3  2.2.0-7+b1
ii  libupower-glib31.90.3-1
ii  udev   255.4-1+b1

Versions of packages upower recommends:
ii  polkitd  124-2

upower suggests no packages.

-- debconf-show failed


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070449: linux-image-6.6-rockchip: zz-u-boot-menu postrm script no such file error

[John Sullivan]

Package: linux-image-6.6-rockchip
Version: 6.6.16+rockchip-1
Severity: important
X-Debbugs-Cc: jo...@debian.org

When trying to do an upgrade on the PineTab 2, I get "cannot open 
/usr/share/u-boot-menu/read-config: No such file" when the postrm script 
zz-u-boot-menu tries to run. This blocks upgrade of the package.

-john



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

Kernel: Linux 6.6-rockchip (SMP w/4 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages linux-image-6.6-rockchip depends on:
it  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod31+20240202-2
ii  linux-base  4.9

linux-image-6.6-rockchip recommends no packages.

linux-image-6.6-rockchip suggests no packages.

-- no debconf information