Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Hi Matthias,

On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> This is the same situation as in #1040477. This is an issue wrt how we
> generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> problem. Quoting you from 1040477:

Right!

> Is the only workaround dropping Ma:same here ?

I see very little alternatives. We must choose:

 * Do not combine M-A:same + Provides: foo + Breaks: foo.
 * Fix dose/apt/dpkg to agree on what this means.

If we were to adapt dose and apt, they's simply arrive at the conclusion
that M-A:same would not work here so that really is not what you'd want
here. This amounts to fixing dpkg to allow this very combination in the
same way that apt and dose allow it. So yeah, changing dpkg could be an
option. Ccing dpkg-devel about it.

The first alternative means that we must not combine them at the same
time. As we very much want M-A:same, we must not have this combination
of Provides and Brekas. Keep in mind that they serve slightly different
purposes. We have Breaks + Replaces and you can only replace a real
package but Provides introduce a virtual package. In effect we're
dealing with a package that sometimes is virtual and other times is
real. We can choose different names for these uses. The real package
could be renamed and also provide the virtual facility. All of them
would now provide the virtual one as virtual only and none of them would
have the virtual name. The Breaks and Replaces would be updated to match
the real name.

This may not work for the in-archive situations right now as Breaks and
Replaces may still be necessary for upgrades, but it is something that
may work in future situations of the same kind.

In the mean time, consider that M-A:same presently is a lie. Removing it
is better than continuing to lie. It's not like we must have everything
in perfect multiarch. Even for cross compilation, we often can get away
without M-A:same by only requiring a package for the host architecture.
M-A:same is not the goal. It's a tool and way may consider using other
tools.

Helmut

Bug#1053334: galera-4: FTBFS because of expired certificates

[Otto Kekäläinen]

> What about bullseye, which is also a supported distribution?
>
> I have not reached the point where I want to do NMUs for these kind
> of bugs, but if this were my package, I would certainly do an upload
> for bullseye as well. If I can be of any help, please say so.

This bug report was about Bookworm, but sure, we can do Bullseye as
well. WIP at https://salsa.debian.org/otto/galera/-/commits/debian/bullseye

If you want to help, you can file a MR on Salsa at any time or review
existing open MRs.

No need to do NMUs - the actual upload is not the work, but doing the
commits and filing the stable-update bug reports to release manager.

Bug#1069702: python3-tqdm: unable to set format for numbers with unit_scale

[Alexander Inyukhin]

Package: python3-tqdm
Version: 4.66.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

I'm having trouble formatting numbers in progress bars when using
unit_scale. Unfortunately, there doesn't seem to be a way to do this
without overriding a lot of code.

As shown in line 565 of /usr/lib/python3/dist-packages/tqdm/std.py, the
`str()` method is being used to convert the floats to strings before
printing them.

Minimal working example:

import tqdm
import time

for i in tqdm.tqdm(range(7), unit_scale=1/7):
time.sleep(0.1)
print()

Output for this code:

  0%|   | 0.0/1.0 [00:00

Bug#1069183: [Aptitude-devel] Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

Hey.

Just upgraded (via aptitude) to the most recent apt in sid on a number
of nodes (this time, all *without* any Icinga/Prometheus stuff)... and
on all nodes the locking issue showed up:

# aptitude
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done

(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../libapt-pkg6.0t64_2.9.2_amd64.deb ...
Unpacking libapt-pkg6.0t64:amd64 (2.9.2) over (2.9.1) ...
Setting up libapt-pkg6.0t64:amd64 (2.9.2) ...
(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../archives/apt_2.9.2_amd64.deb ...
Unpacking apt (2.9.2) over (2.9.1) ...
Setting up apt (2.9.2) ...
dpkg: error: dpkg frontend lock was locked by another process with pid
59222
Note: removing the lock file is always wrong, can damage the locked
area
and the entire system. See
.
Scanning processes... 
Scanning candidates...
Scanning processor microcode...   
Scanning linux images...  

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 root @ session #2: aptitude[57943], bash[1142]

No VM guests are running outdated hypervisor (qemu) binaries on this
host.
E: Sub-process /usr/bin/dpkg returned an error code (2)
Processing triggers for man-db (2.12.1-1) ...
Processing triggers for libc-bin (2.37-18) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../apt-utils_2.9.2_amd64.deb ...
Unpacking apt-utils (2.9.2) over (2.9.1) ...
Setting up apt-utils (2.9.2) ...
Processing triggers for man-db (2.12.1-1) ...
Scanning processes... 
Scanning candidates...
Scanning processor microcode...   
Scanning linux images...  

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 root @ session #2: aptitude[57943], bash[1142]

No VM guests are running outdated hypervisor (qemu) binaries on this
host.
Press Return to continue, 'q' followed by Return to quit.



So as David already said, it seems to be frontend lock related... but I
guess this indicates now that the process that gets in its way may
after all *not* be check_apt or the exporter for Prometheus.


Cheers,
Chris.

Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate

[Olivier Mehani]

Package: gdm3
Version: 45.0.1-3
Followup-For: Bug #1059245

Dear Maintainer,


I have just had the same bug happen on a different machine after an 
upgrade.

See attached apt history for the differences in packages before/after 
the issue appeared.

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

   * What led up to the situation?

apt-get dist-upgrade

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

Forced Xorg, rather than Wayland (with WaylandEnable=true), but neither 
work, same as for the original issue.

   * What was the outcome of this action?

GDM failed to start.

   * What outcome did you expect instead?

GDM starts.

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


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

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

Versions of packages gdm3 depends on:
ii  accountsservice   23.13.9-6
ii  adduser   3.137
ii  dbus [default-dbus-system-bus]1.14.10-4
ii  dbus-bin  1.14.10-4
ii  dbus-daemon   1.14.10-4
ii  dconf-cli 0.40.0-4+b1
ii  dconf-gsettings-backend   0.40.0-4+b1
ii  debconf [debconf-2.0] 1.5.86
ii  gir1.2-gdm-1.045.0.1-3
ii  gnome-session [x-session-manager] 45.0-2
ii  gnome-session-bin 45.0-2
ii  gnome-session-common  45.0-2
ii  gnome-settings-daemon 46~beta-2
ii  gnome-shell   44.9-1
ii  gnome-terminal [x-terminal-emulator]  3.51.90-1
ii  gsettings-desktop-schemas 46.0-1
ii  libaccountsservice0   23.13.9-6
ii  libaudit1 1:3.1.2-2
ii  libc6 2.37-15
ii  libcanberra-gtk3-00.30-11
ii  libcanberra0  0.30-11
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libgdm1   45.0.1-3
ii  libglib2.0-0  2.78.4-1
ii  libglib2.0-bin2.78.4-1
ii  libgtk-3-03.24.41-1
ii  libgudev-1.0-0238-3
ii  libkeyutils1  1.6.3-3
ii  libpam-modules1.5.2-9.1+b1
ii  libpam-runtime1.5.2-9.1
ii  libpam-systemd [logind]   255.4-1
ii  libpam0g  1.5.2-9.1+b1
ii  librsvg2-common   2.54.7+dfsg-2
ii  libselinux1   3.5-2
ii  libsystemd0   255.4-1
ii  libx11-6  2:1.8.7-1
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.15-1
ii  libxdmcp6 1:1.1.2-3
ii  mutter [x-window-manager] 44.8-3
ii  polkitd   124-1
ii  procps2:4.0.4-4
ii  systemd-sysv  255.4-1
ii  ucf   3.0043+nmu1
ii  x11-common1:7.7+23
ii  x11-xserver-utils 7.7+10

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.50.0-1+b1
ii  desktop-base   12.0.6+nmu1
ii  gnome-session [x-session-manager]  45.0-2
ii  x11-xkb-utils  7.7+8
ii  xserver-xephyr 2:21.1.12-1
ii  xserver-xorg   1:7.7+23
ii  zenity 4.0.1-1

Versions of packages gdm3 suggests:
pn  libpam-fprintd
ii  libpam-gnome-keyring  42.1-1+b2
pn  libpam-pkcs11 
pn  libpam-sss
ii  orca  46.1-1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
WaylandEnable=false
[security]
[xdmcp]
[chooser]
[debug]
Enable=true


-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

*** /home/shtrom/apt_history_gdm_issue.log

Start-Date: 2024-04-20  20:59:25
Commandline: apt-get -y upgrade
Requested-By: shtrom (1000)
Upgrade: dpkg:amd64 (1.22.2, 1.22.4), fontconfig:amd64 (2.14.2-6, 2.15.0-1.1), 
libvulkan1:amd64 (1.3.268.0-1, 1.3.275.0-1), libvulkan1:i386 (1.3.268.0-1, 
1.3.275.0-1), reportbug:amd64 (12.0.0, 13.0.1), libsvtav1enc1d1:amd64 
(1.7.0+dfsg-2, 1.7.0+dfsg-2+b1), libsvtav1enc1d1:i386 (1.7.0+dfsg-2, 
1.7.0+dfsg-2+b1), libbox2d2:amd64 (2.4.1-3, 2.4.1-3+b2), 
libgucharmap-2-90-7:amd64 (1:15.1.2-1, 1:15.1.2-1+b1), libsphinxbase3:amd64 
(0.8+5prealpha+1-16+b1, 0.8+5prealpha+1-16+b2), 

Bug#1069701: haskell-hspec-hedgehog: please add support for loong64

[wuruilong]

Source: haskell-hspec-hedgehog
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

haskell-hspec-hedgehog compiles incorrectly on loongarch, the attached patch 
has solved the problem, please refer to the patch to modify the code

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- haskell-hspec-hedgehog-0.0.1.2-origin/hspec-hedgehog.cabal  2024-04-23 
01:31:13.0 +
+++ haskell-hspec-hedgehog-0.0.1.2/hspec-hedgehog.cabal 2024-04-23 
01:23:33.121573479 +
@@ -41,7 +41,7 @@
   Spec.hs
   hs-source-dirs:
   test
-  if arch(arm) || arch(mips) || arch(s390x) || arch(i386) || arch(riscv64)
+  if arch(arm) || arch(mips) || arch(s390x) || arch(i386) || arch(riscv64) || 
arch(loongarch64)
 ghc-options: -threaded -rtsopts
   else
 ghc-options: -threaded -rtsopts -with-rtsopts=-N

Bug#1069700: transition: rpm

[Luca Boccassi]

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.

The reverse-build-depends on librpm-dev are:

createrepo-c
freeipa
libdnf
libdrpm
libextractor
libguestfs
libmodulemd
libsolv
libzypp
openscap
zypper

I have build-tested them all on amd64, only libdrpm needs changes but
there's a new version that I just uploaded that works with both, so
only binNMUs will be needed.

-- 
Kind regards,
Luca Boccassi


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

Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20

[Jacob Rhoads]

Seeing this same issue. In my case, it ended up being caused by Crowdstrike
Falcon Sensor combined with this specific kernel. Reverting the kernel or
upgrading Falcon (via Falcon upgrade policy) works around this issue, for
now.

I think I see that 6.1.87 has attempted to fix some BHI implementation
issues that were originally introduced in 6.1.85. Perhaps certain kernel
modules aren't ready for this syscall hardening?

Bug#1065222: O: pychm -- Python binding for CHMLIB - Python 3

[yokota]

Hello,

Debian pychm was updated.
I can't upload the new package because I don't have upload rights.
Please upload the new package by someone in debian-python who has upload rights.

--
YOKOTA Hiroshi

Bug#264500: fmtools: fmscan patch to allow choice of threshold signal strength (attached)

[Petter Reinholdtsen]

Control: tags -1 + patch

[Gregory P. Smith] 2004-08-08]
> The fmscan utility is not nearly as useful as it could be without
> this patch.  this adds the -t command line option to allow control of
> the threshold signal strength that fmscan uses to decide if a station
> can be received.  please apply to future debian packages of this tool
> and submit to the upstream maintainer.

Thank you for the patch.  I am sad to see it has lingered here for so
long.  CC to the upstream email address, in the hope that upstream can
have a look at the patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264500 >.  Not
convinced that the old email address still work, but it is worth a try.
:)
-- 
Happy hacking
Petter Reinholdtsen

Bug#1068024: revert to version that does not contain changes by bad actor

[Thorsten Glaser]

Christoph Anton Mitterer dixit:

>So Thorsten, in case you or someone else is aware of any [intermediate]
>results from these task forces ([9[) it would be nice to hear about
>them or better even in form of some "official" statement from Debian.

JFTR I’m not involved in those myself.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1069699: RFP : Cars Sports Racing Speed Dreams' fork

[Xavier Bertaux]

Package: cars-sports-racing
Severity: /wishlist/

I left the Speed Dreams project to found my own project more in line with what 
I originally wanted to do with the project.

I have just released version 1.0 of the cars-sports-racing project  licence 
GPL2/GPL3 (also on Sourceforge: 
https://sourceforge.net/projects/cars-sports-racing/

The main difference at the moment is that this project is focused on unlocking 
challenges to be able to access the following races and other cars, I have also 
removed the OpenSceneGraph engine which remains a very good library but which 
is no longer developed ( just in maintenance), I'm leaning more towards an 
internal OpenGL3 engine.

The long-term objective of this project is to have a career mode integrated 
directly into the internal engine.

Cheers

Xavier BERTAUX

Bug#1069698: lists.debian.org: Automatic replies from Apple Support China

[Santiago Vila]

Package: lists.debian.org

Dear Debian listmasters:

Many people report that messages sent to certain n...@bugs.debian.org
addresses receive automatic replies from Apple Support China.

Apparently it does not happen with every bug report, but only with
those which are RC, which suggests that there may be one subscriber
of debian-bugs-rc with a forwarding rule causing the automatic replies.

A bisection method has been suggested to discover the address causing
the replies, but I believe it would be possible to do it in one shot
by sending "fake" email messages (appearing to come from the list)
to every subscriber of debian-bugs-rc, with different From: fields.

(This is actually the idea behind VERP, except that the forwarding rule
causing the problem is so broken that we would have to use the real From:
instead of the envelope from).

Thanks.

Bug#1069697: lintian: debian-changelog-line-too-short CVEs

[Thorsten Glaser]

Package: lintian
Version: 2.117.0

P: openjdk-8-doc: debian-changelog-line-too-short CVEs 
[usr/share/doc/openjdk-8-doc/changelog.Debian.gz:4]

The changelog in question is:

  * New upstream release
  * CVEs
- CVE-2024-21011
- CVE-2024-21085
- CVE-2024-21068
- CVE-2024-21094
  * Security fixes
[…]

I find this a little opinionated anyway, but here not quite
appropriate as the changelog “line” spans more than a physical
line. Maybe, if you won’t consider the space until the next
/^  \* / a “line”, then at least exclude itemisations from that tag?

Thanks.

Bug#1068008: rustc: Please package rust 1.75 or higher

[NoisyCoil]

Package: rustc
Followup-For: Bug #1068008
X-Debbugs-Cc: noisyc...@tutanota.com

Hi,

I join the others in offering my help. If there is anything we can do please 
let us know!

Best,

NoisyCoil

Bug#953844: This appears to be due to "provide-stdint-for-embedded.patch"

[Johannes Schauer Marin Rodrigues]

Hi Keith,

On Thu, 14 Jul 2022 15:19:22 +0100 Steve Capper  wrote:
> With some stracing, it became apparent that the newlib headers were 
> pulling in an extra stdint.h (that wasn't part of newlib). I rebuilt the 
> gcc-arm-none-eabi package with the "provide-stdint-for-embedded.patch" 
> removed. That then allowed me to build the SCP firmware without issue.

I made the same discovery when building my package pico-sdk (currently in NEW).
The package builds fine if I remove provide-stdint-for-embedded.patch from
gcc-arm-none-eabi. But with gcc-arm-none-eabi in unstable I have to apply the
following patch to my package pico-sdk:

--- a/test/pico_stdlib_test/pico_stdlib_test.c
+++ b/test/pico_stdlib_test/pico_stdlib_test.c
@@ -9,6 +9,7 @@
 #include "pico/stdlib.h"
 #include "pico/bit_ops.h"
 #include 
+#define PRIu64 "lu"
 
 void test_builtin_bitops() {
 int32_t x = 0;
--- a/test/pico_time_test/pico_time_test.c
+++ b/test/pico_time_test/pico_time_test.c
@@ -12,6 +12,7 @@
 #include "pico/test.h"
 #include 
 PICOTEST_MODULE_NAME("pico_time_test", "pico_time test harness");
+#define PRIi64 "li"
 
 #define NUM_TIMEOUTS 500
 #define MAX_TIMERS_PER_POOL 250

I landed here as Raspberry PI developer Andrew Scheller found this bug with the
Debian packaging of of gcc-arm-none-eabi.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1069678: openjdk-8: CVE-2024-21011 CVE-2024-21068 CVE-2024-21085 CVE-2024-21094

[Thorsten Glaser]

tags 1069678 + pending
thanks

I’m working on it. Upload should come RSN.

AIUI the security team can feel free to ignore openjdk-8
as it’s in sid for bootstrapping and preparing ELTS upgrades
and downstreams purposes, and not “as is” security-supported
in Debian, so if it helps lowering the workload…

Bug#1068008: rustc: Please package rust 1.75 or higher

[Wesley Schwengle]

Hello all,

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
>
> >
> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

I second the "Is there anything we can do the make things better?". Are there
things we can do now already, that might speed up packaging rust to
1.77/1.78/1.79 besides waiting the t64 migration to be completed?

I can offer a day a week in help if needed.

Cheers,
Wesley

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Håkon Nessjøen]

I have pushed to the new vcs at https://salsa.debian.org/haakonn/mactelnet,
and fixed the things you mentioned.

I also added close tags for both bug #1047023 and #1039260 which I think is
fixed by this release.
I am unsure on how to test #1047023 if not by just running the mentioned
commands "dpkg-buildpackage ; dpkg-buildpackage -S", and those ran without
any errors, so hopefully that bug is also fixed.

On Sun, 14 Apr 2024 at 23:12, Luca Boccassi  wrote:

> The devices are all configured already by the time a normal service is
> started, so you can omit it entirely then
>
> On Sun, 14 Apr 2024 at 20:26, Håkon Nessjøen 
> wrote:
> >
> > It needs the devices, but not for them to have ip yet.
> >
> > søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi :
> >>
> >> If it doesn't need the network to be configured then you can avoid any
> >> dependency at all.
> >>
> >> On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen 
> wrote:
> >> >
> >> > Thanks for your help, so far. Great to hear that you are willing to
> sponsor it!
> >> >
> >> > I will change the dependencies of the service file as you said, but
> since it in theory works before you have an IP address, so it shouldn't
> need to wait for a DHCP client to finish before starting up, is it possible
> that there are other dependencies I should target? Or does it still give
> most sense to use the dependencies you mentioned? I don't have very much
> experience with the order of things in the systemd startup process.
> >> >
> >> > I will request an account for Salsa in the meantime.
> >> >
> >> > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi  wrote:
> >> >>
> >> >> Requires=systemd-networkd.service
> >> >> After=systemd-networkd.service
> >> >>
> >> >> if you want to order it after the network is available, instead of
> >> >> those two lines you should use:
> >> >>
> >> >> Wants=network-online.target
> >> >> After=network-online.target
> >> >>
> >> >> so that it works with other network managers too. Also if
> >> >> mactelnet-locales only install locales, then it should be
> architecture
> >> >> "all" instead of "any". Also, consider requesting an account for
> Salsa
> >> >> and moving the repository there.
> >> >>
> >> >> If you fix these things and close the changelog I can sponsor the
> upload.
> >> >>
> >> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen <
> haakon.nessj...@gmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > In relation to a new upstream version of mactelnet, I have updated
> the debian packaging for this new version, which uses systemd service file
> instead of the old sysv-init. I just need to find a sponsor, so that the
> package can be updated. My last sponsor stopped being a DM for 6 years ago
> I think. I'm not sure if it is ok to use this bug as a reason for updating
> the module to a new minor version, not just a patch or debian patch. As
> mactelnet has new functionality, supporting newer devices/authentication
> protocol.
> >> >> >
> >> >> > Looking at RFS requests, they seem to either be about new
> packages, adopted packages, or just security fixes. But this is a new
> upstream version. How should I go forward with this?
> >> >> >
> >> >> > On Mon, 26 Jun 2023 at 00:26,  wrote:
> >> >> >>
> >> >> >> Package: mactelnet
> >> >> >> Severity: important
> >> >> >> User: bl...@debian.org
> >> >> >> Usertags: missing-systemd-service
> >> >> >>
> >> >> >> Dear Maintainer(s),
> >> >> >>
> >> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init
> script
> >> >> >> without a corresponding systemd unit file. The default init
> system in
> >> >> >> Debian is systemd, and so far this worked because a transitional
> >> >> >> sysv-init-to-unit generator was shipped by systemd. This is in the
> >> >> >> process of being deprecated and will be removed by the time Trixie
> >> >> >> ships, so the remaining packages that ship init scripts without
> >> >> >> systemd units will stop working.
> >> >> >>
> >> >> >> There are various advantages to using native units, for example
> the
> >> >> >> legacy generator cannot tell the different between a oneshot
> service
> >> >> >> and a long running daemon. Also, sanboxing and security features
> >> >> >> become available for services. For more information, consult the
> >> >> >> systemd documentation:
> >> >> >>
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> >> >> >>
> >> >> >> You can find the Lintian warning here:
> >> >> >>
> >> >> >> https://lintian.debian.org/sources/mactelnet
> >> >> >>
> >> >> >> In case this is a false positive, please add a Lintian override to
> >> >> >> silence it and then close this bug.
> >> >> >>
> >> >> >> Thanks!
>

Bug#1069696: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.

[Chen, Xingyu]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : gensync
   Version  : 2.0.5-1
   Upstream contact : Kevin Chen 
 * URL  : https://github.com/nislab/gensync-lib
 * License  : GPL
 * Vcs  :
   Section  : libs

The source builds the following binary packages:

  gensync - a library for efficient synchronization of data over a network. 
Gensync is a library that uses many different syncing algorithms to sync data 
between two nodes in a network. These algorithms include IBLTs, CPISyncs, 
HashSyncs, Cuckoo Syncs, and more.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc

Changes for the initial release:

 gensync (2.0.5-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #1069684)  

Regards,
--
  Kevin Chen

Bug#1064613: vtun: Segmentation fault with default config

[Bernhard Übelacker]

On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?= 
 wrote:

I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf 
into
/etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the 
service
with systemctl I get the following error on the dmesg log:

[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 
89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 
0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

I checked the config and the manual but I haven't been able to use the package 
due to the segfault.
BTW, the autogenerated systemd unit has the attributes RemainAfterExit=yes, 
SuccessExitStatus=5 6,
so even on failure the unit appears as "active (exited)". Hence it needs a 
"systemctl restart",
"systemctl start" won't do anything which is a bit counterintuitive.



Hello,
I am not the maintainer of vtun, just tried to find some more informations 
about the crash.
I was not able to reproduce it inside a minimal VM, but I think
from the dmesg lines it happened in netlib.c line 156.

This looks like ifa->ifa_addr is no valid pointer but gets dereferenced.
I guess it might be related to the network configuration of this specific host,
maybe containing an interface without having an address assigned.

Kind regards,
Bernhard


148 int getifaddr(struct sockaddr_storage *addr, char * ifname, sa_family_t 
af)
...
154
155  for (ifa = ifas; ifa; ifa = ifa->ifa_next) {
156 if( ifa->ifa_addr->sa_family != af ||
157strcmp(ifname, ifa->ifa_name) )

https://sources.debian.org/src/vtun/3.0.4-2/netlib.c/#L156
https://man7.org/linux/man-pages/man3/getifaddrs.3.html
# 2024-04-22 Trixie/testing amd64 qemu VM

apt update
apt install systemd-coredump mc htop gdb

# with unstable
apt install vtun vtun-dbgsym devscripts
apt build-dep vtun



mkdir /home/benutzer/source/vtun/orig -p
cd/home/benutzer/source/vtun/orig
dget 
https://snapshot.debian.org/archive/debian-debug/20191112T220504Z/pool/main/v/vtun/vtun_3.0.4-2.dsc
dpkg-source -x vtun_3.0.4-2.dsc


cp -a /usr/share/doc/vtun/examples/vtund-server.conf /etc/vtund.conf

cp -a /etc/default/vtun /etc/default/vtun.orig
sed -i 's/# RUN_SERVER=no/RUN_SERVER=yes/g' /etc/default/vtun


wget 
https://snapshot.debian.org/archive/debian/20220514T093947Z/pool/main/v/vtun/vtun_3.0.4-2%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20220514T091215Z/pool/main/v/vtun/vtun-dbgsym_3.0.4-2%2Bb1_amd64.deb
dpkg -i *.deb

systemctl start vtun.service

-> Could not reproduce the crash




[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 
10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 
7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4
0b0100
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access

 
echo -n "find /b ..., ..., 0x" && \
echo "24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 
08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 
00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q --pid $(pgrep vtund)
(gdb) pipe info target | grep -E ".text$"
0x55c1fbd0f7f0 - 0x55c1fbd19ba1 is .text
(gdb) find /b 0x55c1fbd0f7f0, 0x55c1fbd19ba1, 0x24, 0x10, 0xe8, 0x2f, 
0x96, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x88, 0x0d, 0x01, 0x00, 0x00, 0x48, 0x8b, 
0x44, 0x24, 0x10, 0x48, 0x89, 0x44, 0x24, 0x08, 0x48, 0x85, 0xc0, 0x0f, 0x84, 
0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc3, 0x90, 0x48, 0x8b, 0x6b, 0x18, 0x66, 
0x44, 0x39, 0x7d, 0x00, 0x0f, 0x85, 0xd1, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x73, 
0x08, 0x4c, 0x89, 0xef, 0xe8, 0x55, 0x97, 0xff
0x55c1fbd15e0a 
1 pattern found.
(gdb) b * (0x55c1fbd15e0a + 42)
Breakpoint 1 at 0x55c1fbd15e34: file ./netlib.c, line 156.
(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x55c1fbd15e34 in getifaddr at 
./netlib.c:156
(gdb) disassemble /r 0x55c1fbd15e0a, 0x55c1fbd15e0a + 62
Dump of assembler code from 0x55c1fbd15e0a to 0x55c1fbd15e48:
   0x55c1fbd15e0a :   24 10   and$0x10,%al
   0x55c1fbd15e0c :   e8 2f 96 ff ff  call   
0x55c1fbd0f440 
   0x55c1fbd15e11 :   85 c0   test   %eax,%eax
   0x55c1fbd15e13 :   0f 88 0d 01 00 00   js 
0x55c1fbd15f26 
   0x55c1fbd15e19 :   48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x55c1fbd15e1e :   48 89 44 24 08 

Bug#1068008: rustc: Please package rust 1.75 or higher

[Mike Hommey]

On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> Hi Wesley, Yaroslav, Carsten and Mike,

Hi Fabian,

Let me start by thanking you for the work going into packaging rustc.

> while we try to keep rustc somewhat current in sid, this is not always
> possible in a timely manner.

rustc 1.70 was released on June 1 and made it to unstable in September.
We're now 7 months later.

At the time rustc 1.70 was released, unstable had... 1.63, which was
released close to a year prior, at which time unstable had... 1.59.

"rustc somewhat current in sid" might have been true in the past, but
that has unfortunately not been the case for at least two years, now.
I'm not discounting your work, merely stating the hard truth.

The sad part is, as you noted, the more outdated the version in unstable
is, the worse it gets to update it...

> I am sorry to say that I don't expect us to be caught up with 1.75
> (which is 5 trips through bin-NEW, one of them bigger than usual cause
> of the merge, and probably 20-40h of rebasing and testing work on my
> end) until at least the end of May :( I will make sure to include the
> requirements of thunderbird/firefox if things get stuck in NEW for too
> long.

And by end of May, we'll be close to the upstream release of rustc 1.79...

Is there anything we can do to make things better? Presumably, the
src:cargo merge should help here, at least a little (because cargo being
outdated has also been another source of recurring problems).

At least for firefox, I managed to relax the rustc requirement back to
1.70, so the urgency is slightly less severe at least for that package,
for now.

Mike

Bug#1057107: bullseye-pu: package libssh2/1.9.0-2

[Nicolas Mora]

Le 2024-04-22 à 13 h 08, Jonathan Wiltshire a écrit :


Please go ahead.


Thanks, it's uploaded

Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd

[Martina Ferrari]

Hi,

I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my 
box running transmission-daemon is on stable..


On 12/04/2024 11:01, Alexandre Rossi wrote:

Hi,


Today I noticed transmission-daemon being down after a reboot, and saw it is
crashing with a malloc error. After some debugging, I found out that this only
happens if I am using the `--portmap` option *and* a local minissdpd is
running.


Does this still happen with 4.x?

What is the setup to reproduce?

$ sudo apt install minissdpd
[...]
$ /usr/bin/transmission-daemon -f --log-debug --portmap
WARN: --log-debug is deprecated. Use --log-level=debug
[...]
[2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 initnatpmp succeeded 
(0) (port-forwarding-natpmp.cc:38)
[2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 
sendpublicaddressrequest succeeded (2) (port-forwarding-natpmp.cc:38)
[2024-04-12 11:57:46.232] inf port-forwarding.cc:215 State changed from 'Not 
forwarded' to 'Starting' (port-forwarding.cc:215)
[...]
[2024-04-12 11:57:54.230] dbg port-forwarding-natpmp.cc:42 
readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not 
support nat-pmp); errno is 111 (Connexion refusée) 
(port-forwarding-natpmp.cc:42)
[2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:290 UPNP_GetValidIGD 
failed: Connexion refusée (111) (port-forwarding-upnp.cc:290)
[2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:291 If your router 
supports UPnP, please make sure UPnP is enabled! (port-forwarding-upnp.cc:291)
[2024-04-12 11:57:54.230] inf port-forwarding.cc:215 State changed from 
'Starting' to '???' (port-forwarding.cc:215)
[2024-04-12 11:58:02.738] inf session.cc:1328 Transmission version 4.0.5 
(a6fe2a64aa) shutting down (session.cc:1328)
[...]
Closing transmission session... done.

** does not crash **

Thanks,

Alex


--
Martina Ferrari

Bug#1065053: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.239.06-1~deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065053: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.239.06-1~deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1067106: bullseye-pu: package nvidia-settings/470.239.06-1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065266: bullseye-pu: package php-phpseclib/2.0.30-2+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065268: bullseye-pu: package phpseclib/1.0.19-3+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065079: bullseye-pu: package php-doctrine-annotations/1.11.2-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065077: bullseye-pu: package php-zend-code/4.0.0-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065076: bullseye-pu: package php-proxy-manager/2.11.1+1.0.3-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065075: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u5

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065071: bullseye-pu: package php-symfony-contracts/1.1.10-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Feb 29, 2024 at 12:30:50PM +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1, similar to #1065058 in
> bookworm.

Please go ahead.

Thanks,



-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1065070: bookworm-pu: package php-composer-xdebug-handler/1.4.5-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Feb 29, 2024 at 12:25:45PM +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1, similar to #1065057 in
> bookworm.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069603: [Pkg-openssl-devel] Bug#1069603: Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert

[Sebastian Andrzej Siewior]

On 2024-04-21 19:30:21 [+0200], Paul Gevers wrote:
> Hi
Hi,

> > Could britney be hinted to migrate both at the same time? This should
> > solve the issue you pointed out.
> 
> There is no "please test together" knob if that's what you mean (is that
> what you mean?).

Yes, it is/ was.

>  I have triggered the test manually, so for now the lights
> are green. Because those expire, I have added a hint to ignore the failure
> of the old version in testing.

Okay, thank you.
In general I would poke the release team once I would expect it to
migrate but didn't. But give the current events, I just waited until
something happens.

> Paul

Sebastian

Bug#1069695: RFS: streamlink/6.7.3-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

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

Dear mentors,

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

  * Package name: streamlink
Version : 6.7.3-1~bpo12+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:

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


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.3-1~bpo12+1.dsc



Differences from testing package (6.7.3-1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.


Changes since the previous backported version in bookworm:
streamlink (6.7.3-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.
  * d/patches: remove upstreamed patch to fix exceptiongroup usages

 -- Alexis Murzeau   Mon, 22 Apr 2024 22:09:36 +0200

streamlink (6.7.3-1) unstable; urgency=medium

  * tests: also run build_backend tests
  * d/source/options: ignore .devcontainer and .vscode
  * New upstream version 6.7.3

 -- Alexis Murzeau   Mon, 15 Apr 2024 15:49:45 +0200

Regards,

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


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Matthias Geiger]

On Mon, 22 Apr 2024 21:01:22 +0200 Helmut Grohne  wrote:
> Package: librust-bitflags-1-dev
> Version: 1.3.2-5+b1
> Severity: serious
> Justification: causes an installation failure
>
> Hi,
>
> Attempting to install librust-bitflags-1-dev for multiple architectures
> fails, because apt and dpkg disagree about how breaks and provides work.
> apt thinks that self-breaks can be ignored, but dpkg thinks that since
> librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it
> cannot be coinstalled and gives up. You cannot combine such
> breaks+provides with m-a:same. The simplest workaround here is dropping
> m-a:same as it cannot be exercised anyway.
>
> Helmut


This is the same situation as in #1040477. This is an issue wrt how we 
generate the semvers. I image rust-proc-macro-crate-1 would pose the 
same problem. Quoting you from 1040477:



A very simple workaround from my pov would be temporarily removing
Multi-Arch: same. Of course that would make the package unavailable to
cross compilation, but on the flip side, it already is. After dropping
Multi-Arch: same, dose would no longer consider solutions involving
coinstallations of it and archive testing could continue.

Failing that, the only way I see is blacklisting the package in crossqa,
but then I'd probably forget about it and it would also be surprising in
the diagnostics as crossqa would always tell that this package does not
exist. I prefer having you work around the issue. A simple upload
dropping M-A:same removes the worst of pain and gives us time to work on
a generic solution. Do you agree?


Is the only workaround dropping Ma:same here ?

Unfortunately we need the semvers (but try to keep them to a minimum).

CC'd Fabian since he is a bit more knowledgable than me here.

best,


--
Matthias Geiger 
Debian Maintainer

Bug#1068008: rustc: Please package rust 1.75 or higher

[Fabian Grünbichler]

On Fri, 29 Mar 2024 11:14:44 -0400 Wesley Schwengle  
wrote:
> Package: rustc
> Version: 1.70.0+dfsg1-9
> Severity: wishlist
> X-Debbugs-Cc: wes...@schwengle.net
> 
> Dear Maintainer,
> 
> 
> I was trying to build a rust package from source when I noticed they use
> traits. Async traits are supported as of 1.75. It would be beneficial to 
> Debian that
> we can start developing rust with these traits.
> 
> Currently upstream sits at 1.77.x, it would be nice if we could get at least 
> to
> 1.75 , but 1.77.x would be preferred.
> 
> https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html
> 
> 
> Many thanks and cheers,
> Wesley

Hi Wesley, Yaroslav, Carsten and Mike,

while we try to keep rustc somewhat current in sid, this is not always
possible in a timely manner.

We are currently stuck on a few related issues:
- the planned src:cargo and src:rustc merge being delayed because of t64
- t64 still not being done for us because LLVM is broken on armel
- updating rustc can only be done version by version(!), or by a massive
  re-bootstrapping on each arch to jump versions

I am sorry to say that I don't expect us to be caught up with 1.75
(which is 5 trips through bin-NEW, one of them bigger than usual cause
of the merge, and probably 20-40h of rebasing and testing work on my
end) until at least the end of May :( I will make sure to include the
requirements of thunderbird/firefox if things get stuck in NEW for too
long.

I will prioritize the merge upload at the start of May, even if t64 is
not done by then. In the worst case, armel/armhf will have to be
rebootstrapped at some later point if they don't manage to catch up in
time.

Fabian

Bug#1066379: Re: loqui: FTBFS: loqui-core-gtk.gob:256:25: error: implicit declaration of function ‘account_list_dialog_open_for_connect’ [-Werror=implicit-function-declaration]

[Andreas Rönnquist]

Control: tags -1 + pending

On Wed, 10 Apr 2024 12:19:54 -0400 Nick Rosbrook  wrote:
> This FTBFS is due to a missing include of account_list_dialog.h. In
> Ubuntu we applied this patch to fix it.
> 
>   * debian/patches: fix implicit declaration of
> account_list_dialog_open_for_connect
> 
> 
> Thanks for considering the patch.

Thanks for the patch!

I intend to NMU this shortly with Nick's patch, debdiff attached.
Please let me know asap if you want me to hold it.

/Andreas
gus...@debian.org


nmu_fixing_1066379.debdiff
Description: Binary data

Bug#1029007: rustc: Recommends: cargo version no longer in testing or unstable

[Fabian Grünbichler]

On Mon, 16 Jan 2023 15:08:52 + Julian Gilbey  wrote:
> Package: rustc
> Version: 1.63.0+dfsg1-1
> Severity: normal
> 
> This version of rustc in unstable and testing says:
> Recommends: cargo (>= 0.64.0~~), cargo (<< 0.65.0~~), llvm-14
> but the version of cargo now in unstable and testing is 0.66.0+ds1-1.
> 
> Best wishes,
> 
>Julian

this will fix itself once we merge src:cargo and src:rustc, since then
they will have the same version and we can always recommend that in both
directions :)

Bug#1069019: rustc: request to upgrade to 1.71.0 or later

[Fabian Grünbichler]

On Mon, 15 Apr 2024 16:12:43 +0800 WANG Rui  wrote:
> Source: rustc
> Version: 1.70.0+dfsg1-9
> Severity: normal
> 
> Dear Maintainer,
> 
> I am the maintainer for the Rust LoongArch target, and I am reporting a build
> failure issue with `rustc` on LoongArch64. I am seeking your assistance in
> addressing this issue.
> 
> In Rust compiler v1.71.0, the `loongarch64-unknown-linux-gnu` target was 
> promoted
> to tier 2. If we were able to upgrade to 1.71.0 or later, this would easily 
> resolve
> the loongarch64 build issue.
> 
> Release notes: https://github.com/rust-lang/rust/releases/tag/1.71.0

Hi!

rustc upgrades are currently stalled a bit by two factors:
- the planned src:rustc and src:cargo merge not being done yet (which
  might take a bit of FTP master review time before hitting the archive,
  once uploaded)
- t64 still breaking LLVM and thus rustc on armel at least

once those are sorted out, I am planning on speed running incremental
updates as fast as my free time, FTP master review and buildd queues
allow ;)

unless some show stopper shows up that makes that particular change
impossible, enabling loong64 support with the update to 1.71 should be
no problem.

Fabian

Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected

[Holger Levsen]

On Mon, Apr 22, 2024 at 02:41:44PM -0400, Daniel Kahn Gillmor wrote:
> /var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting 
> "then")
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb 
> (--unpack):
>  new libsequoia-octopus-librnp package pre-installation script subprocess 
> returned error exit status 2

fixed in git.
 
> Please try at least installing and uninstalling the package before
> pushing it into unstable!

the change seems innocent enough... (I just wasnt expected the different
formatting styles...)

> This also makes me wonder whether we should be doing anything in an
> autopkgtest kind of way for this package.  It'd be great to get some
> more automated confirmation that the things are working as expected
> before we inflict them on the rest of the debian ecosystem :P

the irony is: the autopkg tests for the package had failed which I blamed
on unstables unstableness these days, so I reviewed the diff once more,
(again) didnt notice the introduced bug and did a source only upload,
because the change were tiny... :/

to me this is more an argument for unstable-untested, or testing maybe.


-- 
cheers,
Holger

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

20230709: Today was the warmest day on earth in 125,000 years. Today was also
the day with the most planes in the air at one time ever in history. By the time
you read this both of these records have probably been broken.


signature.asc
Description: PGP signature

Bug#1069694: python-google-auth: please drop python3-six dependency

[Alexandre Detiste]

Source: python-google-auth
Version: 2.28.2-1
Severity: normal


Use of "six" has been removed in last upload.

Greetings

Bug#1065743: postfix 3.5.25-0+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1065743 = 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: postfix
Version: 3.5.25-0+deb11u1

Explanation: upstream bugfix release

Bug#1069689: mandos lost mandos.service systemd unit

[Bastian Germann]

I am uploading Helmut's changes as NMU. The debdiff is attached.

mandos_1.8.16-1.2.debdiff
Description: Binary data

Bug#1069253: libapache2-mod-auth-openidc 2.4.9.4-0+deb11u4 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069253 = 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: libapache2-mod-auth-openidc
Version: 2.4.9.4-0+deb11u4

Explanation: fix mising input validation leading to DoS [CVE-2024-24814]

Bug#1068514: imlib2 1.7.1-2+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068514 = 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: imlib2
Version: 1.7.1-2+deb11u1

Explanation: 

Bug#1069693: network-manager-fortisslvpn: upgrading the stack from network-manager-fortisslvpn-gnome to ppp broke a current working VPN configuration

[Patrice Duroux]

Package: network-manager-fortisslvpn
Version: 1.4.0-1.1
Severity: normal

Dear Maintainer,

Don't know yet what is the guilty in the network stack (network-manager-
fortisslvpn? network-manager? ppp?).
Downgrading to 1.4.0-1+b1, and so network-manager and ppp due to dependency
constraint, restore this VPN connection.
What I can see as related is a message like in journalctl:

Peer refused to agree to his IP address

If needed, what can I do more to help tracking this?

Regards,
Patrice


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

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

Versions of packages network-manager-fortisslvpn depends on:
ii  libc62.37-18
ii  libglib2.0-0t64  2.78.4-6
ii  libnm0   1.46.0-1+b1
ii  network-manager  1.46.0-1+b1
ii  openfortivpn 1.22.0-1
ii  ppp  2.4.9-1+1.1+b2

network-manager-fortisslvpn recommends no packages.

network-manager-fortisslvpn suggests no packages.

-- no debconf information

Bug#1069692: nfs-ganesha: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Sebastian Ramacher]

Source: nfs-ganesha
Version: 4.3-9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=nfs-ganesha=armel=4.3-9=1713793450=0

[ 93%] Building C object FSAL/FSAL_GPFS/CMakeFiles/fsalgpfs.dir/file.c.o
cd /<>/src/obj-arm-linux-gnueabi/FSAL/FSAL_GPFS && /usr/bin/cc 
-DHAS_DOFF -D_GNU_SOURCE=1 -Dfsalgpfs_EXPORTS 
-I/<>/src/obj-arm-linux-gnueabi/include 
-I/<>/src/include -I/<>/src/include/os/linux 
-I/include -I/usr/include/ntirpc -I/usr/include/dbus-1.0 
-I/usr/lib/arm-linux-gnueabi/dbus-1.0/include 
-I/<>/src/FSAL/FSAL_GPFS -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64 -fno-strict-aliasing -O2 -g -DNDEBUG -fPIC -MD -MT 
FSAL/FSAL_GPFS/CMakeFiles/fsalgpfs.dir/file.c.o -MF 
CMakeFiles/fsalgpfs.dir/file.c.o.d -o CMakeFiles/fsalgpfs.dir/file.c.o -c 
/<>/src/FSAL/FSAL_GPFS/file.c
In file included from /usr/include/features.h:393,
 from /usr/include/assert.h:35,
 from /<>/src/FSAL/FSAL_GPFS/file.c:38:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^

Cheers
-- 
Sebastian Ramacher

Bug#1069691: libmaus2: FTBFS on arm64: what(): AutoArray failed to allocate 1398102 elements (11184816 bytes)

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=libmaus2=arm64=2.0.813%2Bds-2=1713374325=0

   libmaus2 2.0.813: test/test-suite.log
===

# TOTAL: 13
# PASS:  11
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: testRank.sh
=

/<>/test /<>/test
/<>/test
[V] testing FastRank...done.
[V] testing RunLengthBitVector...done.
[V] testing E2Append:
[V]rank class libmaus2::rank::ERank222BAppend writer type 
libmaus2::bitio::BitWriterTemplate data type unsigned long
[V] loop 1
[V] libmaus2::rank::ERank222BAppendDynamic loop 1
[V] loop 2
[V] libmaus2::rank::ERank222BAppendDynamic loop 2
[V] loop 3
[V] libmaus2::rank::ERank222BAppendDynamic loop 3
[V] loop 4
[V] libmaus2::rank::ERank222BAppendDynamic loop 4
[V] loop 5
[V] libmaus2::rank::ERank222BAppendDynamic loop 5
[V] testing WaveletTree rank/select random (size 128)...done.
[V] testing WaveletTree smaller/larger...done.
[V] testing CacheLineRank:
terminate called after throwing an instance of 
'libmaus2::exception::LibMausException'
  what():  AutoArray failed to 
allocate 1398102 elements (11184816 bytes)
current total allocation 11521707

/<>/src/.libs/libmaus2_stacktrace.so.2(libmaus2::stacktrace::StackTrace::StackTrace()+0x74)[0xb4644b88]
/<>/src/.libs/libmaus2_exception.so.2(libmaus2::exception::LibMausException::LibMausException()+0x40)[0xb4e42b40]
/<>/src/.libs/testRank(libmaus2::autoarray::AutoArrayAllocate::allocate(unsigned 
long)+0xc4)[0xe833c2c4]
/<>/src/.libs/testRank(testCacheLineRank()+0x88)[0xe831d318]
/<>/src/.libs/testRank(main+0x134)[0xe830b834]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc4)[0xb4886dc4]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xb4886e98]
/<>/src/.libs/testRank(_start+0x30)[0xe830c5f0]

./testRank.sh: line 7: 355775 Aborted ../src/testRank
Exiting with return code 134
FAIL testRank.sh (exit status: 134)

FAIL: testdnarank.sh


/<>/test /<>/test
/<>/test
[V] running short tests...
AutoArray failed to allocate 16 
elements (128 bytes)
current total allocation 341115

/<>/src/.libs/libmaus2_stacktrace.so.2(libmaus2::stacktrace::StackTrace::StackTrace()+0x74)[0xa4e64b88]
/<>/src/.libs/libmaus2_exception.so.2(libmaus2::exception::LibMausException::LibMausException()+0x40)[0xa55b2b40]
/<>/src/.libs/testdnarank(libmaus2::autoarray::AutoArrayAllocate::allocate(unsigned 
long)+0xc4)[0xc76d0e24]
/<>/src/.libs/testdnarank(libmaus2::rank::DNARankTemplate<64u>::loadFromRunLength(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > > const&, unsigned long)+0x108)[0xc76dcfd8]
/<>/src/.libs/testdnarank(void 
testShort >(unsigned 
long)+0x27c)[0xc77008bc]
/<>/src/.libs/testdnarank(main+0x15c)[0xc76b16cc]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc4)[0xa50a6dc4]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xa50a6e98]
/<>/src/.libs/testdnarank(_start+0x30)[0xc76b1970]

Exiting with return code 1
FAIL testdnarank.sh (exit status: 1)

Cheers
-- 
Sebastian Ramacher

Bug#1069690: bookworm-pu: package libkf5ksieve/4:22.12.3-1+deb12u1

[Patrick Franz]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: delta...@debian.org
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
There is a bug in libkf5sieve where the password instead of the
username is sent when using managesieve and could therefore be
logged on a server as the login will fail.

[ Impact ]
Potentially sensitive passwords are logged on a server.

[ Tests ]
Affected user has successfully tested the patched version.

[ Risks ]
The patch is trivial (1 line is changed) and it's quite obvious
that it was a bug in the first place.

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

[ Changes ]
1-line patch to fix the bug.
diffstat for libkf5ksieve-22.12.3 libkf5ksieve-22.12.3

 changelog   |8 
 patches/password_leak.patch |   30 ++
 patches/series  |1 +
 3 files changed, 39 insertions(+)

diff -Nru libkf5ksieve-22.12.3/debian/changelog 
libkf5ksieve-22.12.3/debian/changelog
--- libkf5ksieve-22.12.3/debian/changelog   2023-03-01 21:32:56.0 
+0100
+++ libkf5ksieve-22.12.3/debian/changelog   2024-04-22 17:43:15.0 
+0200
@@ -1,3 +1,11 @@
+libkf5ksieve (4:22.12.3-1+deb12u1) bookworm; urgency=medium
+
+  [ Patrick Franz ]
+  * Add patch to prevent leaking passwords into server-side logs
+(Closes: #1069163).
+
+ -- Patrick Franz   Mon, 22 Apr 2024 17:43:15 +0200
+
 libkf5ksieve (4:22.12.3-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru libkf5ksieve-22.12.3/debian/patches/password_leak.patch 
libkf5ksieve-22.12.3/debian/patches/password_leak.patch
--- libkf5ksieve-22.12.3/debian/patches/password_leak.patch 1970-01-01 
01:00:00.0 +0100
+++ libkf5ksieve-22.12.3/debian/patches/password_leak.patch 2024-04-19 
13:08:00.0 +0200
@@ -0,0 +1,30 @@
+From 6b460ba93ac4ac503ba039d0b788ac7595120db1 Mon Sep 17 00:00:00 2001
+From: Laurent Montel 
+Date: Wed, 8 Mar 2023 06:51:22 +0100
+Subject: [PATCH] Fix 467034: libksieve/src/kmanagesieve/session.cpp assigns
+ password to username & gets logged(
+
+Bug investigate by "bib" thanks
+BUG: 467034
+BUG: 437858
+FIXED-IN: 5.23.0
+---
+ src/kmanagesieve/session.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/kmanagesieve/session.cpp b/src/kmanagesieve/session.cpp
+index 26fd7b59..0e40d721 100644
+--- a/src/kmanagesieve/session.cpp
 b/src/kmanagesieve/session.cpp
+@@ -273,7 +273,7 @@ KManageSieve::AuthDetails 
Session::requestAuthDetails(const QUrl )
+ AuthDetails ad;
+ ad.valid = false;
+ if (dlg->exec()) {
+-ad.username = dlg->password();
++ad.username = dlg->username();
+ ad.password = dlg->password();
+ ad.valid = true;
+ }
+-- 
+GitLab
+
diff -Nru libkf5ksieve-22.12.3/debian/patches/series 
libkf5ksieve-22.12.3/debian/patches/series
--- libkf5ksieve-22.12.3/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libkf5ksieve-22.12.3/debian/patches/series  2024-04-19 13:08:20.0 
+0200
@@ -0,0 +1 @@
+password_leak.patch

Bug#956080: closed by Debian FTP Masters (reply to Andreas Rönnquist ) (Bug#956080: fixed in gamazons 0.83-12)

[Helmut Grohne]

Control: reopen -1
Control: retitle -1 gamazons contains a broken, outdated, embeded copy of 
PKG_CHECK_MODULES

On Sun, Apr 21, 2024 at 03:51:10PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:gamazons package:
> 
> #956080: gamazons FTCBFS: multiple reasons
> 
> It has been closed by Debian FTP Masters  
> (reply to Andreas Rönnquist ).

Half of the problem is fixed.

> gamazons fails to cross build from source. The immediate failure happens
> during dh_auto_clean. It invokes make distclean. The makefile figures
> that its config.status is outdated and that it needs to configure again.
> It does so for the build architecture, misses dependencies (which are
> only requested for the host architecture) and fails. A simple way around
> this is touching config.status before invoking make distclean. The
> attached patch implements that.

This is fixed.

> Then, ./configure uses the build architecture pkg-config. This is a bug
> in the PKG_CHECK_MODULES macro. The file aclocal.m4 ships a broken,
> outdated, embedded copy this macro. The upstream macro as shipped by
> pkg-config is fixed. Please remove this copy to use the fixed upstream
> version. Failing that, please update your embedded copy and register it
> with the security tracker. Please refer to
> https://wiki.debian.org/EmbeddedCodeCopies for details on the process.
> Please remember that since ./configure is not regenerated during a
> package build, you must do so manually before your upload in both cases.
> I'm not including a patch for this second issue, because it is already
> fixed in pkg-config itself.

This is unfixed.

Helmut

Bug#1069689: mandos lost mandos.service systemd unit

[Helmut Grohne]

Source: mandos
Version: 1.8.16-1.1
Severity: serious
Tags: patch
Justification: prevent testing migration after unintentional deletion of 
systemd unit
X-Debbugs-Cc: Bastian Germann 
User: helm...@debian.org
Usertags: dep17p6

The last mandos upload is the first after systemd.pc having moved
systemdsystemunitdir from /lib to /usr/lib. mandos' upstream Makefile
uses this to see where to install units to, but it also only does that
if the relevant directory exists. Now since the new location wasn't
created, it ceased installing the unit. We need to create the new
location to reinstate the unit. Patch attached. I think the loss of the
unit is unintantional and for that reason file this as rc bug. Please
adjust if you disagree.

This change makes mandos backports-unsafe. I don't expect mandos to be
backported.

Helmut
diff --minimal -Nru mandos-1.8.16/debian/changelog 
mandos-1.8.16/debian/changelog
--- mandos-1.8.16/debian/changelog  2024-04-19 13:08:30.0 +0200
+++ mandos-1.8.16/debian/changelog  2024-04-22 21:13:43.0 +0200
@@ -1,3 +1,10 @@
+mandos (1.8.16-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install mandos.service again. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Apr 2024 21:13:43 +0200
+
 mandos (1.8.16-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru mandos-1.8.16/debian/mandos.dirs 
mandos-1.8.16/debian/mandos.dirs
--- mandos-1.8.16/debian/mandos.dirs2019-08-18 21:51:02.0 +0200
+++ mandos-1.8.16/debian/mandos.dirs2024-04-22 21:13:43.0 +0200
@@ -5,6 +5,6 @@
 etc/dbus-1/system.d
 usr/sbin
 var/lib/mandos
-lib/systemd/system
 usr/lib/tmpfiles.d
 usr/lib/sysusers.d
+usr/lib/systemd/system

Bug#1069688: libsequoia-octopus-librnp has an undeclared file conflict on /usr/lib/thunderbird/librnp.so

[Helmut Grohne]

Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + thunderbird

libsequoia-octopus-librnp has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/thunderbird/librnp.so is contained in the packages
 * libsequoia-octopus-librnp/1.8.1-3 as present in unstable
 * thunderbird/1:122.0~b2-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1066327: chmlib: FTBFS: chm_http.c:167:32: error: implicit declaration of function ‘inet_addr’ [-Werror=implicit-function-declaration]

[Zixing Liu]

Package: chmlib
Followup-For: Bug #1066327
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/implicit-declarations.patch: Add missing includes and
fix large file support. (LP: #2062947).


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-28-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru chmlib-0.40a/debian/patches/implicit-declarations.patch 
chmlib-0.40a/debian/patches/implicit-declarations.patch
--- chmlib-0.40a/debian/patches/implicit-declarations.patch 1969-12-31 
17:00:00.0 -0700
+++ chmlib-0.40a/debian/patches/implicit-declarations.patch 2024-04-19 
20:28:30.0 -0600
@@ -0,0 +1,38 @@
+Description: Add missing includes and fix large file support
+Author: Zixing Liu 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066327
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2062947
+Forwarded: no
+Last-Update: 2024-04-19
+---
+--- chmlib-0.40a.orig/src/chm_http.c
 chmlib-0.40a/src/chm_http.c
+@@ -34,6 +34,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #if __sun || __sgi
+ #include 
+ #define strrchr rindex
+@@ -43,6 +44,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ /* threading includes */
+ #include 
+--- chmlib-0.40a.orig/src/chm_lib.c
 chmlib-0.40a/src/chm_lib.c
+@@ -86,7 +86,9 @@
+ #include 
+ /* #include  */
+ #endif
+-
++#ifdef _LARGEFILE_SOURCE
++#define pread64 pread
++#endif
+ /* includes/defines for threading, if using them */
+ #ifdef CHM_MT
+ #ifdef WIN32
diff -Nru chmlib-0.40a/debian/patches/series chmlib-0.40a/debian/patches/series
--- chmlib-0.40a/debian/patches/series  1969-12-31 17:00:00.0 -0700
+++ chmlib-0.40a/debian/patches/series  2024-04-19 20:25:29.0 -0600
@@ -0,0 +1 @@
+implicit-declarations.patch

Bug#1068118: amavisd-new 2.11.1-5+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068118 = 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: amavisd-new
Version: 2.11.1-5+deb11u1

Explanation: handle multiple boundary parameters that contain conflicting 
values [CVE-2024-28054]

Bug#1068750: moment-timezone.js: FTBFS everywhere

[Martina Ferrari]

Hi Santiago,

On Wed, 10 Apr 2024 12:39:54 +0200 Santiago Vila  wrote:


Dear maintainer:

This package currently fails to build from source in all supported 
distributions.

# Fail the build if the tzdata package does not match TZVER.
grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi


Yes, this is expected after each update to tzdata.


I'm curious: Does this package embed the information from tzdata into 
javascript code,
in such a way that a change in tzdata requires a rebuild?


Yes. It is the only way I found to keep the package aligned with tzdata 
while ensuring it is fully built from source: upstream ships the 
pre-compiled tzdata information, so I regenerate those files using the 
tzdata package.



I think it would be highly desirable to find a way for this package to do what
it's supposed to do without having to fix it in oldstable and stable every year.


Without a new upload, I cannot imagine how.. :-/


(In fact, I asked Paul Gevers about this, he says that a package which we know
for sure that it will fail to build during the support time of the release is 
RC).


It fails to build if tzdata is updated, but it never stops working. It 
just needs to be updated as often as tzdata is. But if you have a 
suggestion to make this more automatic, I would love to hear it.. I have 
been doing this very repetitive maintenance for years!



--
Martina Ferrari

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Helmut Grohne]

Package: librust-bitflags-1-dev
Version: 1.3.2-5+b1
Severity: serious
Justification: causes an installation failure

Hi,

Attempting to install librust-bitflags-1-dev for multiple architectures
fails, because apt and dpkg disagree about how breaks and provides work.
apt thinks that self-breaks can be ignored, but dpkg thinks that since
librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it
cannot be coinstalled and gives up. You cannot combine such
breaks+provides with m-a:same. The simplest workaround here is dropping
m-a:same as it cannot be exercised anyway.

Helmut

Bug#1069200:

[rob]

I believe this error is occuring on linux-image-6.1.10-20-amd64 and not
linux-image-6.1.18-amd64 because the initramfs includes btusb and btintel
for that image.  I was able to fix the error on my local machine by running
update-initramfs using a module list that did not contain those two modules.

Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected

[Daniel Kahn Gillmor]

Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor 

Trying to install libsequoia-octopus-librnp:

/var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting 
"then")
dpkg: error processing archive 
/tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb 
(--unpack):
 new libsequoia-octopus-librnp package pre-installation script subprocess 
returned error exit status 2

Please try at least installing and uninstalling the package before
pushing it into unstable!

This also makes me wonder whether we should be doing anything in an
autopkgtest kind of way for this package.  It'd be great to get some
more automated confirmation that the things are working as expected
before we inflict them on the rest of the debian ecosystem :P

   --dkg

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

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

Versions of packages libsequoia-octopus-librnp depends on:
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libhogweed6t64  3.9.1-2.2
ii  libnettle8t64   3.9.1-2.2
ii  libsqlite3-03.45.1-1
ii  libssl3t64  3.2.1-3

Versions of packages libsequoia-octopus-librnp recommends:
ii  zenity  4.0.1-1

Versions of packages libsequoia-octopus-librnp suggests:
ii  thunderbird  1:115.10.1-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#979617: tcplay: VeraCrypt support

[Daniel Kahn Gillmor]

On Sun 2024-04-21 15:44:12 +0200, László Böszörményi (GCS) wrote:
>  I prefer communication first. :) Currently I'm travelling so I can
> only check it on Tuesday.

That's why i uploaded to DELAYED/15 :)  thanks for offering to take a
look at it later this week, László!

>  There were some license problems in the past at least, which
> prevented packaging. I will check the current situation.

That's good to know!  in the version i uploaded, it looked like a simple
2-clause BSD, but i'm sure you have more detailed historical knowledge.

All the best,

 --dkg


signature.asc
Description: PGP signature

Bug#1064920: FTBFS on 32-bit architectures

[Taihsiang Ho (tai271828)]

I created a pull request to fix the build issue. Please review
https://salsa.debian.org/bluefield-team/rshim-user-space/-/merge_requests/11
-tai

On Tue, Feb 27, 2024 at 7:27 PM dann frazier  wrote:
>
> Source: rshim-user-space
> Version: 2.0.12+debian-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> The switch to fuse3 appears to have introduced a build issue for 32-bit
> architectures such as armhf:
>
> From 
> https://buildd.debian.org/status/fetch.php?pkg=rshim-user-space=armhf=2.0.20%2Bdebian-1=1709056732=0
>  :
>
> gcc -DHAVE_CONFIG_H -I. -I..  -Wall -DHAVE_RSHIM_NET 
> -I/usr/include/libusb-1.0  -DHAVE_RSHIM_USB 
> -I/usr/include/arm-linux-gnueabihf  -DHAVE_RSHIM_PCIE -I/usr/include/fuse3  
> -DHAVE_RSHIM_FUSE -Wdate-time -D_FORTIFY_SOURCE=2 -DFUSE_USE_VERSION=30 
> -DDEFAULT_RSHIM_CONFIG_FILE='"/etc/rshim.conf"'  -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -c -o 
> rshim-rshim_fuse.o `test -f 'rshim_fuse.c' || echo './'`rshim_fuse.c
> In file included from /usr/include/fuse3/fuse_lowlevel.h:25,
>  from /usr/include/fuse3/cuse_lowlevel.h:19,
>  from rshim_fuse.c:23:
> /usr/include/fuse3/fuse_common.h:928:1: error: static assertion failed: 
> "fuse: off_t must be 64bit"
>   928 | _Static_assert(sizeof(off_t) == 8, "fuse: off_t must be 64bit");
>   | ^~
> rshim_pcie.c: In function ‘rshim_pcie_mmap_vfio’:
> rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long unsigned 
> int’ to ‘__off_t’ {aka ‘long int’} changes value from ‘7696581394436’ to ‘4’ 
> [-Woverflow]
>52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
>   | ^
> rshim_pcie.c:634:18: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
>   634 |  VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) +
>   |  ^~~~
> rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long unsigned 
> int’ to ‘__off_t’ {aka ‘long int’} changes value from ‘7696581394436’ to ‘4’ 
> [-Woverflow]
>52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
>   | ^
> rshim_pcie.c:643:19: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
>   643 |   VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) +
>   |   ^~~~
> rshim_fuse.c: In function ‘rshim_fuse_misc_read’:
> rshim_fuse.c:713:36: warning: format ‘%ld’ expects argument of type ‘long 
> int’, but argument 5 has type ‘uint64_t’ {aka ‘long long unsigned int’} 
> [-Wformat=]
>   713 |   n = snprintf(p, len, "%-16s%ld(s)\n", "UP_TIME", 
> value/BF3_REF_CLK_IN_HZ);
>   |  ~~^
>   ||
>   |long int
>   |  %lld
> rshim_fuse.c: In function ‘rshim_fuse_misc_write’:
> rshim_fuse.c:954:25: warning: format ‘%lx’ expects argument of type ‘long 
> unsigned int *’, but argument 3 has type ‘uint64_t *’ {aka ‘long long 
> unsigned int *’} [-Wformat=]
>   954 | if (sscanf(p, " 0x%lx", ) != 1)
>   |   ~~^   ~~
>   | |   |
>   | |   uint64_t * {aka long long unsigned int *}
>   | long unsigned int *
>   |   %llx
> make[3]: *** [Makefile:524: rshim-rshim_fuse.o] Error 1
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
> (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> 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

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Sat, 20 Apr 2024 20:36:11 +0200 Matthias Geiger 
 wrote:

> Source: rust-async-process
> Version: 1.7.0-4
> Severity: important
> Tags: ftbfs
> X-Debbugs-Cc: jbi...@debian.org, werdah...@riseup.net
>
>
> I didn't have time to investigate this yet. I'd appreciate it if you
> coud take a look at this as it is blocking the
> event-listener-transition.

>

2.2.1 (the latest upstream release) should fix this. Please consider 
uploading this version so we can proceed with the event-listener transition.


best,

--
Matthias Geiger 
Debian Maintainer

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Julian Andres Klode]

On Mon, Apr 22, 2024 at 07:41:42PM +0200, Dominique Dumont wrote:
> On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote:
> > This should be fixed in apt git already, just needs an upload,
> > which is waiting-ish for some more merges
> 
> Given [1], I need to ask... 
> 
> Is this a definitive fix or will this feature come back with apt 3.0 ?

The feature remains available in output version 3.0 which is what
apt(8) is defaulting to right now. apt-get remains at output version
0 at least until 4.0.

This should be fixed in apt side on 2.9.2 I just uploaded, but
either way it's a weird thing to break because we change progress
messages for interactive output, maybe run with -q instead or don't
pretend to be a tty.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Dominique Dumont]

On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote:
> This should be fixed in apt git already, just needs an upload,
> which is waiting-ish for some more merges

Given [1], I need to ask... 

Is this a definitive fix or will this feature come back with apt 3.0 ?

All the best

[1] 
https://salsa.debian.org/apt-team/apt/-/commit/fc35b4d7d95b2848db482021df4f4500ac142080

Bug#1069685: haskell-language-c-quote: Missing build dependency on alex

[Adrian Bunk]

Source: haskell-language-c-quote
Version: 0.13.0.1-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian Haskell Group 
, Kari Pahula 

https://buildd.debian.org/status/logs.php?pkg=haskell-language-c-quote=0.13.0.1-1

...
Error: hlibrary.setup: The program 'alex' version >=3 is required but it could
not be found.
...

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

[Paul Gevers]

Hi,

On 22-04-2024 10:39 a.m., Andreas Beckmann wrote:
Nice. Is there a chance to get isolation-machine supported on salsa.d.o, 
too?


I don't know. I'm not involved with salsa.

For this concrete case it may be as simple as adding dependency on sudo. 
In case it is trivial for you to rerun the failing test with extra 
dependencies, could you try that? I'd like to avoid doing debugging NMUs 
with untested bugfixes ;-)


root@host:~# 
/tmp/autopkgtest.W4BpP1/build.hRn/src/debian/tests/test-dm-writeboost.sh 


/tmp/autopkgtest.W4BpP1/build.hRn/src/debian/tests/test-dm-writeboost.sh
II: Checking for 14G available disk space...OK
II: Creating loop files:
II: - backing-2083.img...OK
II: - cache-2083.img...OK
II: Connecting to loop devices:
II: - backing-2083.img -> /dev/loop0...[  404.085269] loop0: detected 
capacity change from 0 to 20971520

OK
II: - cache-2083.img -> /dev/loop1...[  404.106845] loop1: detected 
capacity change from 0 to 8388608

OK
II: Initialize cache...OK
II: Loading dm-writeboost module...modprobe: FATAL: Module dm-writeboost 
not found in directory /lib/modules/6.6.15-amd64

FAILED!
II: Detaching /dev/loop1...
II: Detaching /dev/loop0...
II: Deleting file images...
EE: FAIL

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069546: ktorrent: FTBFS on armel: dh_install: error: missing files, aborting

[Aurélien COUDERC]

Control: severity -1 wishlist

Bug#1069546: ktorrent: FTBFS on armel: dh_install: error: missing files, aborting

[Aurélien COUDERC]

Control: retitle -1 ktorrent: FTBFS on arches without QtWebEngine
Control: severity -1 whishlist
Control: tags -1 + wontfix

Le 20 avril 2024 15:23:30 GMT+02:00, Lucas Nussbaum  a écrit :
>Source: ktorrent
>Version: 22.12.3-2
>Severity: serious
>Justification: FTBFS
>Tags: trixie sid ftbfs
>User: lu...@debian.org
>Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
>
>Hi,

Dear Lucas,

>During a rebuild of all packages in sid, your package failed to build
>on armel.

what happens is that on arches that don't have QtWebEngine, the ktorrent build 
succeeds but doesn't produce some of the files expected by dh_install for the 
arch:all ktorrent-data package.

The issue doesn't happen on buildds where arch:all packages are built on amd64 
and other arches run dh_install -a.

There is no easy way to split the generation of the arch:all files for ktorrent 
in a separate build-indep target so I'm marking this bug as whishlist+wontfix.


Happy hacking,
--
Aurélien

Bug#1069614: erfs: isolation-machine autopkgtest fails: sshfs failed

[Paul Gevers]

Control: severity -1 serious
Control: retitle -1 erfs: no longer functional, should be removed

Hi

On 22-04-2024 1:37 p.m., Skyper x wrote:

The erfs service was shut down and this tool is no longer functional. It should 
be removed.


Please file an RM bug against the ftp.debian.org pseudo package.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069417: upgrade procedure instructs users to run “apt update” but neglects upgrading

[Paul Gevers]

Hi Holger,

On 22-04-2024 9:05 a.m., Holger Wansing wrote:

A patch for above two issues is attached (against the bookworm branch; any
such changing needs to be ported to master/trixie as well).


Feel free to push. Bonus points if you remove the deleted text from 
translations too (where you're confident).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064550: bullseye-pu: libjwt/1.10.2-1+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Feb 24, 2024 at 12:49:21AM +, Thorsten Alteholz wrote:
> The attached debdiff for libjwt fixes CVE-2024-25189 in Bullseye. It is
> marked as no-dsa by the security team.
> The fix is straightfoward and should not make any problems.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1057107: bullseye-pu: package libssh2/1.9.0-2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Dec 19, 2023 at 07:52:02PM -0500, Nicolas Mora wrote:
> Hello,
> 
> Thank you for the feedback, the new attached debdiff should fix these.
> 
> Thanks!

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069683: firefox-esr: clearkey gmp plugin crashes

[Julien Cristau]

On Mon, Apr 22, 2024 at 18:44:02 +0200, Julien Cristau wrote:

> Package: firefox-esr
> Version: 115.10.0esr-1~deb12u1
> Severity: normal
> X-Debbugs-Cc: jcris...@debian.org
> 
> It seems that the gmp code does not expect the executable to be called
> something other than firefox:
> 
> GMPChild::MakeCDMHostVerificationPaths
> (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#424)

Wrong URL here, I meant to link to
https://searchfox.org/mozilla-esr115/rev/d80a6646e597210be779f6cdbd8af0044e94312b/dom/media/gmp/GMPChild.cpp#424

> calls AppendHostPath with /usr/lib/firefox-esr/firefox, but that file
> doesn't exist, so AppendHostPath fails, and we end up calling into
> VerifyCdmHost_0
> (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#422)

And wrong URL there, this was meant to be
https://searchfox.org/mozilla-esr115/rev/d80a6646e597210be779f6cdbd8af0044e94312b/media/gmp-clearkey/0.1/gmp-clearkey.cpp#152

> with aNumFiles==2, which fails the assertion that it's equal to
> NumExpectedHostFiles (4).
> 

Bug#1068514: bullseye-pu: package imlib2/1.7.1-2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Apr 06, 2024 at 10:55:25PM +0200, Markus Koschany wrote:
> Fixing CVE-2024-25447, CVE-2024-25448 and CVE-2024-25450 in bullseye.
> 

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1067148: bullseye-pu: package hovercraft/2.7-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Mar 19, 2024 at 11:55:34AM +0100, Andreas Beckmann wrote:
> @@ -25,6 +25,7 @@ Package: hovercraft
>  Architecture: all
>  Depends: python3-docutils,
>   libjs-impress (>= 1.0.0~),
> + python3-setuptools,
>   ${misc:Depends},
>   ${python3:Depends},
>   ${sphinxdoc:Depends}

This alignment looks funny; with it fixed please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1067544: bullseye-pu: libmicrohttpd/0.9.72-2+deb11u1.debdiff

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Mar 23, 2024 at 12:01:09PM +, Thorsten Alteholz wrote:
> The attached debdiff for libmicrohttpd fixes CVE-2023-27371 in Bullseye. It
> is marked as no-dsa by the security team.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1068694: bullseye-pu: package json-smart/2.2-2+deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Apr 09, 2024 at 10:01:11AM +0200, Andreas Beckmann wrote:
> +++ b/debian/patches/0004-CVE-2021-31684-Fix-indexOf.patch
> @@ -0,0 +1,27 @@
> +From: HAPPY 

Well if that doesn't tickle my antennae nothing will :)

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1068082: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote:
> As requested by the security team, I would like to bring the microcode
> update level for Intel processors in Bullseye and Bookworm to match what
> we have in Sid and Trixie.  This is the bug report for Bullseye, a
> separate one will be filled for Bookmorm.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069684: ITP: gensync -- a library for efficient synchronization of data over blockchain networks

[Chen, Xingyu]

Package: wnpp
Severity: wishlist

* Package name: gensync
  Version : 2.0.6
  Upstream Author : Ari Trachtenberg
* URL : https://github.com/nislab/gensync-lib
* License : GPL
  Programming Lang: C++
  Description : a library for efficient synchronization of data over a 
network. Gensync is a library that uses many different syncing algorithms to 
sync data between two nodes in a network. These algorithms include IBLTs, 
CPISyncs, HashSyncs, Cuckoo Syncs, and more.


Gensync is an open-source data reconciliation library developed by Boston 
University NISLAB. It has been released on macports and. It would be nice to 
also have it in Debian.

Bug#1065302: RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major Emacs mode for editing Rust source code)

[Xiyue Deng]

Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major 
Emacs mode for editing Rust source code

Another sync to latest snapshot that fixes precedence with rust-ts-mode.
(Mentors[1], team repo[2].)  PTAL, TIA!

-- 
Xiyue Deng

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

Bug#1069297: bullseye-pu: package reportbug/7.10.3+deb11u2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Fri, Apr 19, 2024 at 04:03:37PM +0200, Andreas Beckmann wrote:
> After the release of bookworm, we should rotate the release codenames in
> reportbug/bullseye again to keep reportbug/bullseye useful. Fixed in
> sid/bookworm via #1034260.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069253: bullseye-pu: package libapache2-mod-auth-openidc/2.4.9.4-0+deb11u4

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Apr 18, 2024 at 09:44:59PM +0200, Moritz Schlarb wrote:
> Backported the patch to fix CVE-2024-24814.
> Does not require DSA as per #1064183#28.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1068947: bullseye-pu: package curl/7.74.0-1.3+deb11u12

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Apr 13, 2024 at 11:36:17PM -0300, Guilherme Puida Moreira wrote:
> 1. Fix CVE-2024-2398

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069683: firefox-esr: clearkey gmp plugin crashes

[Julien Cristau]

Package: firefox-esr
Version: 115.10.0esr-1~deb12u1
Severity: normal
X-Debbugs-Cc: jcris...@debian.org

It seems that the gmp code does not expect the executable to be called
something other than firefox:

GMPChild::MakeCDMHostVerificationPaths
(https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#424)
calls AppendHostPath with /usr/lib/firefox-esr/firefox, but that file
doesn't exist, so AppendHostPath fails, and we end up calling into
VerifyCdmHost_0
(https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#422)
with aNumFiles==2, which fails the assertion that it's equal to
NumExpectedHostFiles (4).

Cheers,
Julien

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.17
ii  fontconfig   2.15.0-1.1
ii  libasound2   1.2.10-3
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcairo-gobject21.18.0-1+b1
ii  libcairo21.18.0-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libdbus-glib-1-2 0.112-3+b1
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgcc-s114-20240201-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libpango-1.0-0   1.52.0+ds-1
ii  libstdc++6   14-20240201-3
ii  libvpx7  1.12.0-1.2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.4-1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec60  7:6.1.1-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5+b1
pn  pulseaudio 

-- debconf-show failed

Bug#1069286: dcmtk 3.6.7-9~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069286 = 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: dcmtk
Version: 3.6.7-9~deb12u1

Explanation: clean up properly on purge

Bug#1069274: pdudaemon 0.0.8.58.g597052b-1+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069274 = 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: pdudaemon
Version: 0.0.8.58.g597052b-1+deb12u1

Explanation: depend on python3-aiohttp

Bug#1069262: u-boot 2023.01+dfsg-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069262 = 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: u-boot
Version: 2023.01+dfsg-2+deb12u1

Explanation: fix orion-timer for booting sheevaplug and related platforms

Bug#1068836: yapet 2.6-2~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068836 = 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: yapet
Version: 2.6-2~deb12u1

Explanation: do not call EVP_CIPHER_CTX_set_key_length() in crypt/blowfish and 
crypt/aes

Bug#1069252: libapache2-mod-auth-openidc 2.4.12.3-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1069252 = 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: libapache2-mod-auth-openidc
Version: 2.4.12.3-2+deb12u1

Explanation: fix mising input validation leading to DoS [CVE-2024-24814]

Bug#1068242: libtool 2.4.7-7~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068242 = 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: libtool
Version: 2.4.7-7~deb12u1

Explanation: conflict with libltdl3-dev; fix check for += operator in 
func_append

Bug#1051024: igtf-policy-bundle 1.128-1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1051024 = 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: igtf-policy-bundle
Version: 1.128-1~deb12u1

Explanation: address CAB Forum S/MIME policy change; apply accumulated updates 
to trust anchors

Bug#1057222: pwnam: couldn't get password of "loginname" xscreensaver-auth exited with signal 6

[Tormod Volden]

Hi Andreas, did you find out more about this issue?

Just to clarify a few things:

>  pwnam: couldn't get password of "loginname"
This is a normal condition if PAM is used, therefore this message is
only printed in verbose mode, and is likely not important here.

> xscreensaver-auth exited with signal 6
Signal 6 is SIGABRT and this is likely xscreensaver-auth calling
abort(). I would guess it happens in xscreensaver_auth_conv() due to
an unexpected condition.

Would you be able to debug this function a bit closer? If rebuilding,
it would be nice if you could try 6.08 from unstable also, it should
build fine on stable without any changes.

Not so many use NIS nowadays, I suspect the issue is related to the
use of NIS through PAM.

Regards,
Tormod

Bug#1069682: debian-cd DVD source run failing

[Steve McIntyre]

Package: cdimage.debian.org

As a reminder for me: the latest weekly build failed, looks like
source packages no longer fit???

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

Bug#1069681: less does not escape special characters when outputting the filename

[Vincent Lefevre]

Package: less
Version: 590-2.1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

"less" does not escape special characters when outputting the
filename, either in the status line or in an error message.

With untrusted filenames (like in CVE-2024-32487), weird things
can happen in the terminal, which might be used for attacks.

For instance,

$ echo foo > test$'\033'\[\?40h$'\033'\[\?3h
$ less test$'\033'\[\?40h$'\033'\[\?3h

(in shells that understand the $'...' syntax, such as bash or zsh)
resizes the xterm window from 80 columns to 132 columns.

I can't reproduce this issue with the upstream version when the
file is viewable (the status line can be a bit incorrect, though);
I suppose that there was some fix in the recent past. When the
file is not viewable, same problem due to the error message. I've
reported the bug here:

  https://github.com/gwsw/less/issues/503

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

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

Versions of packages less depends on:
ii  libc6  2.37-18
ii  libtinfo6  6.4+20240414-1

less recommends no packages.

less suggests no packages.

-- no debconf information

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

Bug#1069144: ADvice about htis pocl issue on armel

[Andreas Beckmann]

On 17/04/2024 09.38, PICCA Frederic-Emmanuel wrote:

1026s 
dlopen("/tmp/autopkgtest-lxc.1tg98r_u/downtmp/autopkgtest_tmp/.cache/pocl/kcache/GI/PODCELNLNPFCGBFNGLEIHDEIECBKNFCDBNAPP/check_atomic32/0-0-0/check_atomic32.so")
 failed with 
'/tmp/autopkgtest-lxc.1tg98r_u/downtmp/autopkgtest_tmp/.cache/pocl/kcache/GI/PODCELNLNPFCGBFNGLEIHDEIECBKNFCDBNAPP/check_atomic32/0-0-0/check_atomic32.so:
 undefined symbol: __atomic_fetch_add_4'.
1026s note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.


Sounds like this needs to be linked with something like -latomic on 
armel. And pocl probably should do that ...


There is a test in CMakeLists.txt whether 64-bit atomics require 
-latomic (which is true on armel), and therefore libpocl.so.2 is already 
 linked against libatomic, but that does not seem to be sufficient.


But we should probably start with adding some new tests to pocl that 
make use of some atomic types (32-bit int, 64-bit int) and consequently 
these missing functions.


Patches welcome, a simple OpenCL kernel using atomics should be a 
sufficient.


Andreas

Bug#1069680: Add systemctl socket status to tgtbasedmpaths test

[Mitchell Dzurick]

Package: multipath-tools
Version: 0.9.7-7
Subject: Add systemctl socket status to tgtbasedmpaths test

Hi, I have a simple MR up at
https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/12.
This adds the socket to the systemctl status command for the dep8 test.

I'm working on updating the socket/service interactions so it'd be nice to
have the status of the socket in this dep8 test.

Thanks!
-Mitch

Bug#1067251: librust-isahc-dev: impossible to install

[Matthias Geiger]

On Wed, 20 Mar 2024 21:29:24 +0100 Matthias Geiger 
 wrote:

> Package: librust-isahc-dev
> Severity: grave
> Justification: not installable
> X-Debbugs-Cc: werdah...@riseup.net
>

Unfortunately polling 2.x to 3.x had breaking changes. This is my 
attempt at a


(non-working) patch bumping polling (see attachment). Maybe you can 
figure out the missing bits; this is too difficult for me.


best,

werdahias
diff --git a/Cargo.toml b/Cargo.toml
index d797d20..62ca8cd 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -43,7 +43,7 @@ futures-io = "0.3.24" # futures-io ecosystem compatibility
 http = "0.2.1" # http ecosystem compatibility, part of API
 log = "0.4" # log ecosystem compatibility
 once_cell = "1" # used for a few singletons
-polling = "2" # async I/O driver
+polling = "3" # async I/O driver
 sluice = "0.5.4" # byte buffers between curl and Isahc
 url = "2.1" # URL parsing
 waker-fn = "1" # async primitive
diff --git a/src/agent/selector.rs b/src/agent/selector.rs
index 813e708..836dd39 100644
--- a/src/agent/selector.rs
+++ b/src/agent/selector.rs
@@ -1,5 +1,5 @@
 use curl::multi::Socket;
-use polling::{Event, Poller};
+use polling::{Event, Poller, Events};
 use std::{
 collections::{HashMap, HashSet},
 io,
@@ -30,7 +30,7 @@ pub(crate) struct Selector {
 
 /// Socket events that have occurred. We re-use this vec every call for
 /// efficiency.
-events: Vec,
+events: Events,
 
 /// Incrementing counter used to deduplicate registration operations.
 tick: usize,
@@ -50,7 +50,7 @@ impl Selector {
 poller: Arc::new(Poller::new()?),
 sockets: HashMap::with_hasher(Default::default()),
 bad_sockets: HashSet::with_hasher(Default::default()),
-events: Vec::new(),
+events: Events::new(),
 tick: 0,
 })
 }
@@ -144,7 +144,7 @@ impl Selector {
 // We don't do this immediately after polling because the caller may
 // choose to de-register a socket before the next call. That's why we
 // wait until the last minute.
-for event in self.events.drain(..) {
+for event in self.events.iter() {
 let socket = event.key as Socket;
 if let Some(registration) = self.sockets.get_mut() {
 // If the socket was already re-registered this tick, then we
@@ -211,21 +211,17 @@ fn poller_add(poller: , socket: Socket, readable: bool, writable: bool) -
 // operation as a modification is sufficient to handle this.
 //
 // This is especially common with the epoll backend.
-if let Err(e) = poller.add(socket, Event {
-key: socket as usize,
-readable,
-writable,
-}) {
+if let Err(e) = poller.add(socket, 
+Event::readable(socket.try_into().unwrap()),
+) {
 tracing::debug!(
 "failed to add interest for socket {}, retrying as a modify: {}",
 socket,
 e
 );
-poller.modify(socket, Event {
-key: socket as usize,
-readable,
-writable,
-})?;
+poller.modify(socket, 
+Event::readable(socket.try_into().unwrap()),
+)?;
 }
 
 Ok(())
@@ -239,21 +235,17 @@ fn poller_modify(
 ) -> io::Result<()> {
 // If this errors, we retry the operation as an add instead. This is done
 // because epoll is weird.
-if let Err(e) = poller.modify(socket, Event {
-key: socket as usize,
-readable,
-writable,
-}) {
+if let Err(e) = poller.modify(socket, 
+Event::readable(socket.try_into().unwrap()),
+) {
 tracing::debug!(
 "failed to modify interest for socket {}, retrying as an add: {}",
 socket,
 e
 );
-poller.add(socket, Event {
-key: socket as usize,
-readable,
-writable,
-})?;
+poller.add(socket,
+Event::readable(socket.try_into().unwrap()),
+)?;
 }
 
 Ok(())

Bug#1069642: Same error

[obonsky]

Today raised same error on my colleague's two laptops and on one server
with this kernel. It was not possible to boot, only with older kernel.