Bug#1070839: [Help] Re: Bug#1070839: r-cran-data.table: autopkgtest regression on i386

[Andreas Tille]

Control: tags -1 help

Hi Graham,

Am Fri, May 10, 2024 at 10:44:48AM + schrieb Graham Inggs:
> Source: r-cran-data.table
> Version: 1.15.4+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> r-cran-data.table's autopkgtest has regressed on i386 [1].  I've
> copied what I hope is the relevant part of the log below.
> 
> Regards
> Graham
> 
> [1] https://ci.debian.net/packages/r/r-cran-data.table/testing/i386/

I need help for this package which seems to be urgent and is blocking
some migrations.  I will not be able to do anything on this bug before
June.

Maybe the most straightforward way to tackle this is to simply remove
the one failing test?  Anyone is kindly invited to work on this /
contact upstream (or even remove the package and packages depending from
it for i386 / 32bit architectures).  The package is team maintained
and everybody can do a team upload.

Kind regards
Andreas.

-- 
https://fam-tille.de

Bug#1070877: debian-installer: xfsprogs not available in the installer, but xfs fs type available, mkfs fails

[Cyril Brulebois]

Hi Witold,

And thanks for your report.

Witold Baryluk  (2024-05-11):
> Which is weird, because xfsprogs-udev is there.
> 
> No issues with btrfs, ext2-4, fat, jfs. They are available by default.

This is #1070795.

Such bug reports would ideally be filed with:

  X-Debbugs-Cc: debian-b...@lists.debian.org


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


signature.asc
Description: PGP signature

Bug#1070878: gnome-boxes: gnome session crashes when creating vm in gnome-boxes

[Gabriel Francisco]

Package: gnome-boxes
Version: 43.2-1
Severity: important
X-Debbugs-Cc: frc.gabr...@gmail.com

Dear Maintainer,

My gnome shell session crashes when creating a virtual machine in gnome-boxes.

The coredumpctl tool shows me the following message:

   PID: 52454 (gnome-session-b)
   UID: 1000 (gabriel)
   GID: 1000 (gabriel)
Signal: 11 (SEGV)
 Timestamp: Sat 2024-05-11 07:07:57 CEST (23min ago)
  Command Line: /usr/libexec/gnome-session-binary --systemd-service
--session=gnome
Executable: /usr/libexec/gnome-session-binary
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-
gnome\x2dsession\x2dmanager.slice/gnome-session-manager@gnome.service
  Unit: user@1000.service
 User Unit: gnome-session-manager@gnome.service
 Slice: user-1000.slice
 Owner UID: 1000 (gabriel)
   Boot ID: 33c14517a636473099e28c35d4c5d503
Machine ID: 820fc7876e3345e19598e5e97e242ef8
  Hostname: PC90024
   Storage: /var/lib/systemd/coredump/core.gnome-
session-b.1000.33c14517a636473099e28c35d4c5d503.52454.171540407700.zst
(present)
  Size on Disk: 637.2K
   Message: Process 52454 (gnome-session-b) of user 1000 dumped core.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libudev.so.1 from deb systemd-252.22-1~deb12u1.amd64
Module libsystemd.so.0 from deb systemd-252.22-1~deb12u1.amd64
Stack trace of thread 52454:
#0  0x7fba0a69cc01 g_type_check_instance_is_fundamentally_a
(libgobject-2.0.so.0 + 0x3ac01)
#1  0x7fba0a67d87d g_object_unref (libgobject-2.0.so.0 +
0x1b87d)
#2  0x7fba0a5725fd n/a (libglib-2.0.so.0 + 0x565fd)
#3  0x7fba0a572f2f n/a (libglib-2.0.so.0 + 0x56f2f)
#4  0x7fba0a57313c n/a (libglib-2.0.so.0 + 0x5713c)
#5  0x7fba0a576317 n/a (libglib-2.0.so.0 + 0x5a317)
#6  0x7fba0a576c1f g_main_loop_run (libglib-2.0.so.0 +
0x5ac1f)
#7  0x55f1ef68609e main (gnome-session-binary + 0xe09e)
#8  0x7fba0a1fa24a __libc_start_call_main (libc.so.6 +
0x2724a)
#9  0x7fba0a1fa305 __libc_start_main_impl (libc.so.6 +
0x27305)
#10 0x55f1ef686681 _start (gnome-session-binary + 0xe681)

Stack trace of thread 52464:
#0  0x7fba0a2cf15f __GI___poll (libc.so.6 + 0xfc15f)
#1  0x7fba0a576277 n/a (libglib-2.0.so.0 + 0x5a277)
#2  0x7fba0a576c1f g_main_loop_run (libglib-2.0.so.0 +
0x5ac1f)
#3  0x7fba0a7e5eaa n/a (libgio-2.0.so.0 + 0x122eaa)
#4  0x7fba0a5a3ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#5  0x7fba0a25c134 start_thread (libc.so.6 + 0x89134)
#6  0x7fba0a2dc7dc __clone3 (libc.so.6 + 0x1097dc)

Stack trace of thread 52462:
#0  0x7fba0a2d4719 syscall (libc.so.6 + 0x101719)
#1  0x7fba0a5d1ac4 g_cond_wait (libglib-2.0.so.0 + 0xb5ac4)
#2  0x7fba0a54016b n/a (libglib-2.0.so.0 + 0x2416b)
#3  0x7fba0a5a413a n/a (libglib-2.0.so.0 + 0x8813a)
#4  0x7fba0a5a3ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#5  0x7fba0a25c134 start_thread (libc.so.6 + 0x89134)
#6  0x7fba0a2dc7dc __clone3 (libc.so.6 + 0x1097dc)

Stack trace of thread 55429:
#0  0x7fba0a2d4719 syscall (libc.so.6 + 0x101719)
#1  0x7fba0a5d1c90 g_cond_wait_until (libglib-2.0.so.0 +
0xb5c90)
#2  0x7fba0a540143 n/a (libglib-2.0.so.0 + 0x24143)
#3  0x7fba0a540775 g_async_queue_timeout_pop
(libglib-2.0.so.0 + 0x24775)
#4  0x7fba0a5a42fd n/a (libglib-2.0.so.0 + 0x882fd)
#5  0x7fba0a5a3ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#6  0x7fba0a25c134 start_thread (libc.so.6 + 0x89134)
#7  0x7fba0a2dc7dc __clone3 (libc.so.6 + 0x1097dc)

Stack trace of thread 52469:
#0  0x7fba0a2cf15f __GI___poll (libc.so.6 + 0xfc15f)
#1  0x7fba0a576277 n/a (libglib-2.0.so.0 + 0x5a277)
#2  0x7fba0a576930 g_main_context_iteration
(libglib-2.0.so.0 + 0x5a930)
#3  0x7fba081fb4bd n/a (libdconfsettings.so + 0xb4bd)
#4  0x7fba0a5a3ab1 n/a (libglib-2.0.so.0 + 0x87ab1)
#5  0x7fba0a25c134 start_thread (libc.so.6 + 0x89134)
#6  0x7fba0a2dc7dc __clone3 (libc.so.6 + 0x1097dc)

Stack trace of thread 52463:
#0  0x7fba0a2cf15f __GI___poll (libc.so.6 + 0xfc15f)
#1  0x7fba0a576277 n/a (libglib-2.0.so.0 + 0x5a277)
#2  0x7fba0a576930 g_main_context_iteration

Bug#1070785: libsnappy-dev: Ambiguity in Compress method signatures causes FTBFS in ceph

[GCS]

Hi James,

On Thu, May 9, 2024 at 9:03 AM James Page  wrote:
cd > The patch added to restore older API signatures to resolve Bug 1070217
> creates ambiguity in the method signatures resulting in FTBFS in at
> least the ceph package:
[...]
> The compression options parameter which was added for >= 1.2 of snappy
> provides a default, so the added method with no options creates this
> ambiguity.
 For the time being ceph might patch to call directly the new API with
changing line 78 of SnappyCompressor.h:
snappy::Compress(, );
to
snappy::Compress(, , {});

I can't test it myself as in my test environment ceph can't even
configure due to:
-- crypto soname: libcrypto.so.3
CMake Error at 
/usr/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
  Could NOT find Python3 (missing: Python3_LIBRARY Python3_INCLUDE_DIR
  Development) (found suitable exact version "3.10.13")

But indeed, I should do a transition of snappy with a prepared new library name.

Regards,
Laszlo/GCS

Bug#1070877: debian-installer: xfsprogs not available in the installer, but xfs fs type available, mkfs fails

[Witold Baryluk]

Package: debian-installer
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

This is against di in testing, for trixie. netinst iso
from 2024-05-10.

xfs-modules 6.7.12-1
libparted2-udev 3.6-4
partman-auto 164
partman-auto-raid 52
partman-base 227
partman-utils 227
partman-basicfilesystems 165
partman-basicmethods 75
partman-btrfs 60
partman-cros 6
partman-efi 103
partman-ext3 113
partman-iscsi 77
partman-jfs 63
partman-md 107
partman-partitioning 151
partman-target 128
partman-xfs 69
partman-xfsprogs-udev 6.7.0-2




There are some other bugs, related to xfs, but not quite like this.

For example there is a separate bug that causes xfsprogs to not be
installed in target (which is fine to do by default, but not when one
has at least 1 xfs file system configured in target tree).


My problem is that one cannot even create xfs in partman.

If one selects Use as: XFS file system, and then continue
it will fail with fatal error, and no help either in partman,
installer or in logs.

I figured out that this is because mkfs.xfs is not available
in the installer environment.

Which is weird, because xfsprogs-udev is there.


No issues with btrfs, ext2-4, fat, jfs. They are available by default.


Regards,
Witold

Bug#1065722: FTBFS: /usr/lib/python3/dist-packages/torch/include/c10/util/C++17.h:27:2: error: #error You need C++17 to compile PyTorch

[Yadd]

Control: tags -1 + patch

Hi,

updating to 0.18 fixes the build issue: see 
https://salsa.debian.org/deeplearning-team/pytorch-vision/-/merge_requests/2


Best regards,
Xavier

Bug#1036826: Please start handling \c

[Helge Kreutzmann]

Hello Martin,
Am Fri, May 10, 2024 at 06:55:38PM +0200 schrieb Martin Quinson:
> tag 1036826 fixed-upstream
> thanks
> 
> Hello Helge,
> 
> I think I fixed this bug upstream, and it will be part of the next release,
> later this month. I did not implement a full support for \c since it's
> difficult in the current code base, but at least the groff.1 page proceeds. 

This is very good news. Thank you very much!

> If you have other failures from other pages, please tell me so that I can 
> check
> whether my fix is enough even before the release.

I can do so tomorrow afternoon, if this has time until then (I have
limited access atm). 

> Thanks for your help and patience,

The thanks is on my side!

Greetings

 Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1070876: linux: hang when resuming from suspend

[Mike Kupfer]

Source: linux
Version: 5.10.0-29
Severity: important
X-Debbugs-Cc: kup...@rawbw.com

Dear Maintainer,

With the 5.10.0-29 kernel, my Dell Latitude E7250 hangs when resuming
from suspend-to-RAM.  I have not once gotten a successful resume; this
problem does not appear at all with the 5.10.0-28 kernel.

The visible symptom is that I see the display as it was at the time of
suspend, but there is no response to the trackpad or keyboard.  If
there is a screen locker that displays the time (e.g., Cinnamon), the
time-of-suspend is displayed, even when the resume happens several
minutes (or longer) after the suspend.  I have tried the following
desktop sessions: Cinnamon, i3, and maybe Xfce, too.  I've also seen
this hang after suspending from the lightdm login screen.

I have also seen the same (or at least a similar) hang a couple times
with the 5.10.0-29 kernel on a different system.  That one is a
ZaReason Limbo (AMD FX-6300 processor, Radeon graphics).  Most of the
time, though, I can resume that system okay, at least with Cinnamon
and i3.

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

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

Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries

[Xiyue Deng]

Daniel Kahn Gillmor  writes:

> Control: tags 1069908 - moreinfo
>
> Hi Xiyue Deng--
>
> On Wed 2024-05-08 19:13:37 -0700, Xiyue Deng wrote:
>> For this issue, it looks like debian-bug.el is passing "--list-cc=none"
>> to reportbug which then becomes part of the message.  This is fixed in
>> [1] and pending sponsoring.
>
> thanks for this analysis and work!
>

Sure thing!

>> I cannot seem to reproduce this.  debian-bug.el tries to get full name
>> and email from several sources, such as user-full-name,
>> user-mail-address, envvars like DEBFULLNAME, DEBNAME, NAME, DEBEMAIL,
>> EMAIL, REPORTBUGEMAIL, etc.  So there may be something unconventional
>> that triggered this.  Can you check if your configuration set those info
>> in multiple places?  What happens if you clear some of them?
>
> Here are the plausibly relevant env vars i have set (generated by
> running `M-1 M-! printenv` from within emacs itself and then manually
> pruning for things that include either my name or e-mail address):
>
> ```
> DEBFULLNAME=Daniel Kahn Gillmor
> DEBEMAIL=d...@fifthhorseman.net
> DEBSIGN_MAINT=Daniel Kahn Gillmor 
> EMAIL=d...@fifthhorseman.net
> ```
>
> None of this seems wrong to me; or even if it does, it still ought to be
> able to be correctly interpreted by debian-bug.el, and de-duplicated.
>
> I decided to look in ~/.reportbugrc and i find i have the following settings:
>
> ```
> reportbug_version "5.0"
> mode standard
> ui text
> no-cc
> list-cc-me
> ```
>
> I have no recollection of setting either no-cc or list-cc-me, and i
> confess i don't really understand why these options are distinct.
> Perhaps this was from ancient run (or runs?) of `reportbug --configure`?
>
> Without modifying any env vars, I tried commenting out both the `no-cc`
> and `list-cc-me` options in ~/.reportbugrc, and with both of those
> removed, the generated X-Debbugs-Cc line after a `M-x debian-bug` was
> just:
>
> ```
> X-Debbugs-Cc: none, Daniel Kahn Gillmor 
> ```
>

Thanks for testing.  So what's happening is that the info debian-bug get
from the envvars are your full name and your email address.  On the
other hand with "list-cc-me" you only get the email part there.  So from
debian-bug point of view those are different info so the de-duplication
doesn't happen (if both have the same info debian-el will dedup though).

Ideally there should be a way to let reportbug ignore the configuration
files and only process options passing through command line so that user
configuration doesn't change its behavior, but as far as I can tell
there is no option to do that (yet)[1].  Hopefully it will be
implemented eventually.

> So perhaps with the fix you have pending, this will be resolved.
>

Sounds good.

> Thanks!
>
> --dkg
>

[1] 
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/utils.py?ref_type=heads#L1458
-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1070836: rust-apple-nvram: Switch from rust-nix 0.26 to 0.27

[peter green]

I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.


The relavent change is.


All Cargo features have been removed from the default set. Users will
need to specify which features they depend on in their Cargo.toml.


I've bumped the dependency, added the feature, run the autopkgtest
and uploaded the package.

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Lorenzo]

Hi,

On Tue, 07 May 2024 15:08:37 +0200
Martin Steigerwald  wrote:

>[...]
> 
> Are init scripts supposed to be started with PATH variable set up and 
> exported or not? How is it done with SysVInit? I bet it would be best
> to match as close as possible what SysVInit is doing to be as
> compatible as possible.
I checked this and in sysvinit you don't have this bug because during
boot sysvscripts are run via /etc/ini.d/rc script, and there is an
'export PATH' there. It could probably be triggered by calling the
script directly during runtime.
In runit we are calling scripts directly in stage1 so we have this bug

> 
> Otherwise it might be challenging to chase and find all the corner
> cases with existing setups. And as there is no issue initializing the
> network in the container with SysVInit instead of Runit used as PID
> 1, I'd consider a change in Runit. At least it could be challenging
> to find whether networking inside a container is the only thing that
> breaks.
I want to dig this further, I don't recall broken network under docker
and I don't think is broken under qemu, but I can be wrong or remember
something from before /etc/init.d/rc usage was dropped from stage1

> 
>
> 
> > > I just wonder why stage 2 contains /usr/local bin directories. I
> > > think that should not be the case. Shall I report this as a
> > > different issue?
> > 
> > PATH is passed to env call for runsvdir, so I guess one can exec a
> > bin from local as runscript (not sure) without setting the PATH. I
> > can't think of other use cases..
> > I'm fine with removing, just a bit wary, I'm afraid to break some
> > custom setup
> 
> Hmm, I get that. I am just a bit concerned as it may be a security
> issue.
not urgent, but could you elaborate this (security implications)? is
something like an attacker placing a modified foo in /usr/local/ that
overrides the legit foo in /usr/bin or is something else? one still
needs root privileges to write to /usr/local..

Lorenzo

> 
> > > I added empty "debug" and "verbose" files in /etc/runit but did
> > > not find any debug output. Maybe those files needed to have some
> > > content. Maybe it requires bootlogd.
> > 
> > those files only work for runit stuff (runscripts and the sv
> > trigger), boot scripts are for sysvinit and do not obey to runit
> > settings :( perhaps it's time to roll some native runit
> > bootscripts..
> 
> I see. Well that would be great. But also would require a lot of work
> and testing I bet.
> 
> Best,

Bug#1070875: glibc: FTBFS on hppa - Encountered regressions that don't match expected failures

[John David Anglin]

Source: glibc
Version: 2.38-10
Severity: normal
Tags: ftbfs

Dear Maintainer,

The following tests are known to fail on hppa when glibc is built with
gcc-13 or later:

FAIL: math/test-double-fma
FAIL: math/test-double-ldouble-fma
FAIL: math/test-float32x-float64-fma
FAIL: math/test-float32x-fma
FAIL: math/test-float64-fma
FAIL: math/test-ldouble-fma

The tests do not fail when glibc is built with gcc-12.

See following gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.38-10=1715383873=0

Things get worse with gcc-14.  I suspect this is an issue with nan
representation.

Please change the above tests to xfails.

Thanks,
Dave Anglin

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

Kernel: Linux 6.1.90+ (SMP w/4 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: systemd (via /run/systemd/system)

Bug#1069743: Removal of features from default keepassxc package

[James Lu]

Hi,

Chiming in as another regular keepassxc user. When I first saw the 
keepassxc / keepassxc-full split I did not think much of it. But reading 
the comments on the upstream issue has gotten me frustrated.


Please consider resolving this in a way that doesn't break existing 
installations. It's easy to catch these changes when they're presented 
one-by-one when upgrading e.g. a system running testing regularly, but 
they're far more likely to miss when dozens of packages update all at 
once with the next stable release. Either the minimal package should 
only be applied as default for new installations, or the minimal package 
should explicitly warn when attempting to use a feature that's unavailable.


The second part I take issue with is the wording with which this is 
being communicated. There is no need to use charged terminology like 
"feature creep"[1], "crappy version"[2], or "use at your own risk"[3] 
when describing variants. This reads as disrespectful to both upstream 
and the userbase at large - let people decide for themselves what 
features are useful instead of dismissing their use-case outright.


[1]: 
https://salsa.debian.org/debian/keepassxc/-/blob/main/debian/NEWS?ref_type=heads
[2]: 
https://github.com/keepassxreboot/keepassxc/issues/10725#issuecomment-2104401817
[3]: 
https://salsa.debian.org/debian/keepassxc/-/blob/main/debian/control?ref_type=heads#L76-78


Best,
James


OpenPGP_0x2EC3F60DE71C0B9D.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070339: libata bug after resume from suspend

[Phillip Susi]

After updating to the -21 kerenl, I could not reproduce this anymore.  I
went back and forth between -21 and -20 a few times, and found the exact
steps to reproduce it, but it only works under -20:

1) enable runtime PM on the disks
2) wait for runtime PM to suspend the disks
3) suspend the system


So it seems that this has been fixed.

Bug#1070874: O: ramond -- IPv6 Router Advertisement MONitoring Daemon

[Boyuan Yang]

Package: wnpp
Control: affects -1 + src:ramond
X-Debbugs-Cc: ram...@packages.debian.org
X-Debbugs-Cc: by...@debian.org
Severity: normal

I intend to orphan the ramond package.

Its upstream has been inactive since 2013, and no upstream activity
is expected in the future.

The package description is:
 ramond is a scriptable IPv6 Router Advertisement Monitoring Daemon.
 .
 The tool was designed to `clear' (by sending spoofed zero lifetime
 adverts) rogue-routes sent by users running 6to4 gateways on a campus
 network.
 .
 Actions are scriptable. Almost all the available information is
 passed to a script via environmental variables.

Thanks,
Boyuan Yang


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

Bug#1070873: O: latencytop -- Tool for developers to visualize system latencies

[Boyuan Yang]

Package: wnpp
Control: affects -1 + src:latencytop
X-Debbugs-Cc: latency...@packages.debian.org
X-Debbugs-Cc: by...@debian.org
Severity: normal

I intend to orphan the latencytop package. Its upstream is now
inactive, and no major packaging changes will be expected in
the future.

The package description is:
 LatencyTOP is a Linux tool for software developers (both kernel
 and userspace), aimed at identifying where in the system latency
 is happening, and what kind of operation/action is causing the
 latency to happen so that the code can be changed to avoid the
 worst latency hiccups.

Thanks,
Boyuan yang


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

Bug#1070872: libm.a lost fmod + fmodf on i386 + m68k

[Adrian Bunk]

Package: libc6-dev
Version: 2.38-7
Severity: serious
Tags: ftbfs
Control: affects -1 src:zsh

https://buildd.debian.org/status/logs.php?pkg=zsh=5.9-6%2Bb1

...
gcc -static   -o zsh main.o  `cat stamp-modobjs`   -lpcre2-8 -lgdbm -lcap 
-lncursesw -ltinfo -ltinfo -lrt -lm  -lc
...
./obj-static/Src/../../Src/math.c:1260:(.text+0x1d8e): undefined reference to 
`fmod'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:228: zsh] Error 1



$ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod
w_fmodl_compat.o: file format elf32-i386
w_fmod_compat.o: file format elf32-i386
w_fmodf_compat.o: file format elf32-i386
e_fmodl.o: file format elf32-i386
 g F .text  0013 __ieee754_fmodl
w_fmodl.o: file format elf32-i386
 g F .text  0085 __fmodl
 *UND*   __ieee754_fmodl
  wF .text  0085 fmodf64x
  wF .text  0085 fmodl
e_fmod.o: file format elf32-i386
 g F .text  0013 __ieee754_fmod
w_fmod.o: file format elf32-i386
e_fmodf.o: file format elf32-i386
 g F .text  0013 __ieee754_fmodf
w_fmodf.o: file format elf32-i386
e_fmodf128.o: file format elf32-i386
 g F .text  0c9b __ieee754_fmodf128
 *UND*   __ieee754_fmodf128
 *UND*   __ieee754_fmodf128
w_fmodf128.o: file format elf32-i386
 g F .text  0237 __fmodf128
 *UND*   __ieee754_fmodf128
  wF .text  0237 fmodf128
$


With 2.37-13 this is instead:

$ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod
w_fmodl_compat.o: file format elf32-i386
w_fmod_compat.o: file format elf32-i386
w_fmodf_compat.o: file format elf32-i386
e_fmodl.o: file format elf32-i386
 g F .text  0013 __ieee754_fmodl
w_fmodl.o: file format elf32-i386
 g F .text  0085 __fmodl
 *UND*   __ieee754_fmodl
  wF .text  0085 fmodf64x
  wF .text  0085 fmodl
e_fmod.o: file format elf32-i386
 g F .text  0013 __ieee754_fmod
w_fmod.o: file format elf32-i386
 g F .text  006b __fmod
 *UND*   __ieee754_fmod
  wF .text  006b fmodf32x
  wF .text  006b fmodf64
  wF .text  006b fmod
e_fmodf.o: file format elf32-i386
 g F .text  0013 __ieee754_fmodf
w_fmodf.o: file format elf32-i386
 g F .text  0063 __fmodf
 *UND*   __ieee754_fmodf
  wF .text  0063 fmodf32
  wF .text  0063 fmodf
e_fmodf128.o: file format elf32-i386
 g F .text  0cc5 __ieee754_fmodf128
 *UND*   __ieee754_fmodf128
 *UND*   __ieee754_fmodf128
w_fmodf128.o: file format elf32-i386
 g F .text  0237 __fmodf128
 *UND*   __ieee754_fmodf128
  wF .text  0237 fmodf128
$

Bug#1069693: ppp >=2.5.0 breaks network-manager-fortisslvpn

[Maurizio Avogadro]

Some more info gathered this afternoon.

It seems that network-manager-fortisslvpn also makes a mess with the routing 
table after the connection has been established.


I could easily get a working VPN by adding

ipcp-accept-remote

to /etc/ppp/options and manually launching openfortivpn; such setting also 
allowed NetworkManager to accept the IP address supplied by the counterpart (it 
was the default until ppp v2.4.9), but in this case the connection didn't work 
until I deleted a rule in the routing table which routed the IP address of the 
remote gateway through the ppp0 interface (!).


A duplicate default route through the main physical network interface was 
created too and the spawned pppd process didn't exit after the connection has 
been terminated and had to be killed manually: none of these issues happened 
when openfortivpn was launched manually.


Thanks

Bug#1070837: gnome-shell: Last Gnome-Shell upgrade crashes logged session

[Julien Negros]

Hi ! Thanks for your quick followup

> Control: tags -1 + moreinfo
>
> On Fri, 10 May 2024 at 12:08:27 +0200, Julien Negros wrote:
> > In Bookworm last gnome-shell upgrade 43.9-0+deb12u1 -> 43.9-0+deb12u2
> > closes current logged session. Same issue with Bullseye
> > (3.38.6-1~deb11u1 -> 3.38.6-1~deb11u2). Doesn't look like an actual
> > crash in logs : [...] But rather a GDM restart.
>
> I did not experience this when upgrading several bookworm GNOME machines,
> and one bullseye virtual machine. My GNOME session continued to run until
> I rebooted the machine manually.
>
> In general I would recommend rebooting the system anyway after installing
> security updates in core library packages like libglib2.0-0, otherwise
> running programs and sessions will remain vulnerable.

I agree but the issue here is having the session closed when doing a simple apt 
upgrade...

> Are you sure you were not using some tool like checkrestart or needrestart
> that detected gdm3 as a service that was affected by the security-fixed
> versions of libglib2.0-0, and offered to restart it for you?
>
> In needrestart's default configuration, it will default to not
> restarting gdm3 and other known display managers (this is set up in
> $nrconf{override_rc}, in /etc/needrestart/needrestart.conf), but if they
> are explicitly selected to be restarted, it will assume you are aware of
> the consequences and do as you ask.

needrestart and debian-goodies are not installed in our workstations, but we 
use needrestart on our servers so I'm familiar with the use of this tool. That 
could have been a lead though.

> I don't know whether checkrestart has similar mechanisms.
>
> If you *do* restart gdm3, then it is probably expected that active GUI
> sessions managed by gdm3 will be terminated - that's why needrestart avoids
> doing this by default.
>
> smcv

If you are not affected by this there must be something specific with out setup 
(we do all kind of tweaks to our Debian installations), that would also explain 
why I can't find any complain online since Monday... But I have no clue what it 
could be. If you or anyone has any idea where to look that would be great :)

--
Julien Negros

Bug#1070871: thunderbird: please use system librnp

[Daniel Kahn Gillmor]

Package: thunderbird
Version: 1:115.10.1-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

Thunderbird was (understandably) using an internal copy of librnp
because upstream hadn't releasd a version with
`rnp_signature_get_features`

Now that 0.17.1-1 is in debian/unstable, please rebuild thunderbird to
use the system version of librnp.

thanks!

--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 thunderbird depends on:
ii  debianutils  5.17
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.11-1+b1
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.38-7
ii  libcairo-gobject21.18.0-3+b1
ii  libcairo21.18.0-3+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdbus-glib-1-2 0.112-3+b2
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgcc-s114-20240330-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b3
ii  libglib2.0-0t64  2.80.1-1
ii  libgtk-3-0t643.24.41-4
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libotr5t64   4.1.1-5.1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libstdc++6   14-20240330-1
ii  libvpx8  1.13.1-2+b1
ii  libx11-6 2:1.8.7-1+b1
ii  libx11-xcb1  2:1.8.7-1+b1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.4-1
ii  psmisc   23.7-1
ii  x11-utils7.7+6+b1
ii  zenity   4.0.1-1+b1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages thunderbird recommends:
pn  myspell-en-us | hunspell-dictionary | myspell-dictionary  

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.4.0~RC4-1
ii  libgssapi-krb5-2  1.20.1-6+b1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1070870: loook: typo in package description: "formsm" - correct to "forms"

[Daniel Martineschen]

Package: loook
Version: 0.9.0-1
Severity: minor

Dear Maintainer,

as a member of the translation team for Brazil I found a typo in the 
project description - "formsm" instead of forms. Please correct.


Typo is present in versions loook (0.8.6-1), loook (0.8.6-2), loook 
(0.9.0-1)




-- 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/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en

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

Versions of packages loook depends on:
ii python3 3.10.6-1~22.04
ii python3-tk 3.10.8-1~22.04

Versions of packages loook recommends:
pn libreoffice | calligra 

loook suggests no packages.

Bug#1068695: bookworm-pu: package json-smart/2.2-2+deb12u1

[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#1064648: allegro5-doc: please make the build reproducible.

[James Addison]

Hi Andreas,

On Thu, 9 May 2024 at 11:17, Andreas Rönnquist  wrote:
>
> Those fixes was obviously not enough, just see the repro reports.

Ok, yep - thanks for checking those.

When I check the reports, most of the remaining problems seem to relate to
duplicate definitions appearing in the documentation (for example, a definition
for "al_color_cmyk" appearing twice).

> The strange thing is that it according to the tests does seem to build
> reproducible on arm64...

Puzzling indeed.  I'll have another read through the codebase soon.

> One other detail is that on armhf the only change seems to be the
> architecture which is included in the ALLEGRO_PKG_HOST_SYSTEM variable.
>
> Is there some magic like SOURCE_DATE_EPOCH to use that would avoid this
> problem in this case?

Not as far as I'm aware, no - for SOURCE_DATE_EPOCH, there is a range of
possible integer values that are all equally valid, so it's straightforward to
select one to make a package build reproducible.  Specifiying an arbitrary but
static architecture could be at-least challenging, and at-worst misleading or
potentially compatibility-breaking.

In this kind of situation I'd generally recommend working backwards to figure
out whether -- and if so, how -- the nondeterministic value is used.  I didn't
find any search results for ALLEGRO_PKG_HOST_SYSTEM in Debian codesearch[1],
so I'd recommend a reprotest build after removing it to see whether that
succeeds (I'll try this soon).

Regards,
James

[1] - https://codesearch.debian.net/search?q=ALLEGRO_PKG_HOST_SYSTEM

[2] - https://salsa.debian.org/reproducible-builds/reprotest

Bug#1070853: strace: test failures on 32bit with 64bit time_t

[Adrian Bunk]

Control: retitle -1 strace: test failures on 32bit

The tests also fail on i386, so do not seem to be related to time_t.

cu
Adrian

Bug#568834: Bug#882872: First stab at functionality for copying files

[Nicolas Schier]

On Fri, May 10, 2024 at 10:52:07AM -0400, Benj. Mako Hill wrote:
> Greetings!
> 
> 
> > Your patch looks good to me and works as promised, thanks!  Before 
> > forwarding
> > it to upstream, we need an appropriate update of vidir documentation.  Are 
> > you
> > interested in preparing that?  (If not, I can do it.)
> 
> Sorry I lost track of this. Are we still waiting on documentation? If
> so, I'm happy to do this so that this can land.

yes, it would be great to have it as complete as possible, before contacting
upstream.  But please be warned that upstream ardly accepts patches that
introduce new features [1].

Kind reards,
Nicolas


[1]: https://joeyh.name/blog/entry/Volunteer_Responsibility_Amnesty_Day/


-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#1070869: libpam-modules: pam_lastlog.so does not exist

[Francois Mescam]

Package: libpam-modules
Version: 1.5.3-7
Severity: normal

Dear Maintainer,

I observe in the logs :
May 10 08:49:16 xx login[1633]: PAM adding faulty module: pam_lastlog.so
May 10 08:49:16 xx login[1633]: PAM unable to dlopen(pam_lastlog.so): 
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file 
or
+directory
May 10 08:49:23 xx login[1633]: pam_unix(login:session): session opened for 
user root(uid=0) by root(uid=0)
May 10 08:49:23 xx login[601537]: ROOT LOGIN  on '/dev/tty1'

I found that pam_lastlog.so does not exist in libpam-modules 1.5.3-7 but
it exists in 1.5.2-9.1+b1.

I don't know exactly what action produce the logs because I've tried to
log in a virtual console as root but no logs are produce again.

Kind regards

Francois

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

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

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  libaudit1  1:3.1.2-2
ii  libc6  2.38-7
ii  libcrypt1  1:4.4.36-4
ii  libdb5.3t645.3.28+dfsg2-7
ii  libpam-modules-bin 1.5.3-7
ii  libpam0g   1.5.3-7
ii  libselinux13.5-2+b2
ii  libsystemd0255.5-1

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information:
  libpam-modules/disable-screensaver:
  libpam-modules/profiles-disabled:
  libpam-modules/deprecate-tally:

Bug#1062249: tagging 1046274, fixed 1062998 in 4.19.0-1.1~exp1, tagging 1062998, tagging 1062072 ...

[Micha Lenk]

Control: tags -1 = patch
Control: fixed -1 libchipcard/5.99.1beta-2
Control: close -1

The versions in the archive are already fixed. Nothing left to do. Closing...

Regards,
Micha

Bug#1070868: vstream-client: make the build system respect Debian compiler flags

[Zixing Liu]

Package: vstream-client
Version: 1.2-7
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

This patch makes the build system respect Debian compiler flags to ensure
build consistency.

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

- Use dpkg-buildflags, and build with -D_LARGEFILE64_SOURCE since
  test-client.c uses fopen64.


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-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 vstream-client-1.2/debian/control vstream-client-1.2/debian/control
--- vstream-client-1.2/debian/control   2022-01-16 14:25:17.0 -0700
+++ vstream-client-1.2/debian/control   2024-05-10 14:37:40.0 -0600
@@ -2,7 +2,8 @@
 Priority: optional
 Maintainer: Paul Hedderly 
 Build-Depends: debhelper-compat (= 13),
-   autotools-dev
+   autotools-dev,
+   dpkg-dev
 Standards-Version: 3.9.2
 Vcs-Browser: https://salsa.debian.org/debian/vstream-client
 Vcs-Git: https://salsa.debian.org/debian/vstream-client.git
diff -Nru vstream-client-1.2/debian/rules vstream-client-1.2/debian/rules
--- vstream-client-1.2/debian/rules 2022-01-16 14:25:17.0 -0700
+++ vstream-client-1.2/debian/rules 2024-05-10 14:34:09.0 -0600
@@ -31,6 +31,10 @@
 #major=`ls src/.libs/lib*.so.* | \
 # awk '{if (match($$0,/\.so\.[0-9]+$$/)) print substr($$0,RSTART+4)}'`
 
+export DEB_CPPFLAGS_MAINT_APPEND := -D_LARGEFILE64_SOURCE
+export DEB_CFLAGS_MAINT_APPEND := -Wall
+include /usr/share/dpkg/buildflags.mk
+
 config.status: configure
dh_testdir
# Add here commands to configure the package.
@@ -40,7 +44,7 @@
 ifneq "$(wildcard /usr/share/misc/config.guess)" ""
cp -f /usr/share/misc/config.guess config.guess
 endif
-   ./configure --prefix=/usr
+   CFLAGS="$(CPPFLAGS) $(CFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure 
--prefix=/usr
# THIS IS POINTLESS... BECAUSE THE UPSTREAM BUILD SYSTEM IS SIMPLE AND 
MESSY!
 
 #CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"

Bug#1070768: bpfcc: ftbfs on ppc64el

[Luca Boccassi]

On Fri, 10 May 2024 at 20:03, Nilesh Patra  wrote:
>
> Quoting Luca Boccassi:
> >  Source: bpfcc
> >  Version: 0.29.1+ds-1
> >  Severity: serious
> >  Tags: ftbfs
> >
> >  Hi,
> >
> >  bpfcc has been failing to build on ppc64el for a long time, and this is
> >  keeping it out of testing.
> >
> >  If you don't have time to fix it, could you please consider at least a
> >  quick upload to remove ppc64el from the list of architectures, so that
> >  it can go back to testing?
> >
> >  Thanks!
> >
>
> Vasudev, Ritesh, this bug is causing a bunch of packages getting removed from
> testing (bpfcc and transitive reverse depends). Can I ask you to please take
> care of this, maybe dropping ppc64el altogether if it is not feasible to fix?

Unless there are objections, I am going to NMU to delayed/3 tomorrow
to remove ppc64el

Bug#1070768: bpfcc: ftbfs on ppc64el

[Nilesh Patra]

Quoting Luca Boccassi:
>  Source: bpfcc
>  Version: 0.29.1+ds-1
>  Severity: serious
>  Tags: ftbfs
>  
>  Hi,
>  
>  bpfcc has been failing to build on ppc64el for a long time, and this is
>  keeping it out of testing.
>  
>  If you don't have time to fix it, could you please consider at least a
>  quick upload to remove ppc64el from the list of architectures, so that
>  it can go back to testing?
>  
>  Thanks!
>  

Vasudev, Ritesh, this bug is causing a bunch of packages getting removed from
testing (bpfcc and transitive reverse depends). Can I ask you to please take
care of this, maybe dropping ppc64el altogether if it is not feasible to fix?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070867: lists.debian.org: debconf25-team

[Santiago Ruano Rincón]

Package: lists.debian.org
Severity: wishlist

Dear lists.debian.org admin,

Could you please create a mailing list for the debconf25 orga team. This
is the required info:

Name: debconf25-team
Rationale: A mailing list is helpful to ease the discussions among the DC25
orga team.
Short description: Team Discussion for organizing DebConf25 in Brest, France
Long description: Team Discussion for organizing DebConf25 in Brest, France
Category: Debconf
Subscription Policy: open
Post Policy: open
Web Archive: yes

Thank you,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries

[Daniel Kahn Gillmor]

Control: tags 1069908 - moreinfo

Hi Xiyue Deng--

On Wed 2024-05-08 19:13:37 -0700, Xiyue Deng wrote:
> For this issue, it looks like debian-bug.el is passing "--list-cc=none"
> to reportbug which then becomes part of the message.  This is fixed in
> [1] and pending sponsoring.

thanks for this analysis and work!

> I cannot seem to reproduce this.  debian-bug.el tries to get full name
> and email from several sources, such as user-full-name,
> user-mail-address, envvars like DEBFULLNAME, DEBNAME, NAME, DEBEMAIL,
> EMAIL, REPORTBUGEMAIL, etc.  So there may be something unconventional
> that triggered this.  Can you check if your configuration set those info
> in multiple places?  What happens if you clear some of them?

Here are the plausibly relevant env vars i have set (generated by
running `M-1 M-! printenv` from within emacs itself and then manually
pruning for things that include either my name or e-mail address):

```
DEBFULLNAME=Daniel Kahn Gillmor
DEBEMAIL=d...@fifthhorseman.net
DEBSIGN_MAINT=Daniel Kahn Gillmor 
EMAIL=d...@fifthhorseman.net
```

None of this seems wrong to me; or even if it does, it still ought to be
able to be correctly interpreted by debian-bug.el, and de-duplicated.

I decided to look in ~/.reportbugrc and i find i have the following settings:

```
reportbug_version "5.0"
mode standard
ui text
no-cc
list-cc-me
```

I have no recollection of setting either no-cc or list-cc-me, and i
confess i don't really understand why these options are distinct.
Perhaps this was from ancient run (or runs?) of `reportbug --configure`?

Without modifying any env vars, I tried commenting out both the `no-cc`
and `list-cc-me` options in ~/.reportbugrc, and with both of those
removed, the generated X-Debbugs-Cc line after a `M-x debian-bug` was
just:

```
X-Debbugs-Cc: none, Daniel Kahn Gillmor 
```

So perhaps with the fix you have pending, this will be resolved.

Thanks!

--dkg


signature.asc
Description: PGP signature

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Carlos Henrique Lima Melara]

Hi, Dylan!

On Fri, Apr 05, 2024 at 09:28:02PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> > Meanwhile, I pinged upstream to ask for their opinion about
> > that to make sure we are not going to break stuff.
> 
> launcher-libseat has an higher priority than launcher-logind,
> that means enabling launcher-libseat will change the default
> behavior for all users. Although this should be harmless
> because libseat should contact logind, it doesn't work for
> whatever reason. I just tested with a VM without a
> graphical login. I can launch weston 10.0.1-1, but
> it fails with 10.0.1-1+deb12u1. So, I guess it would
> require more changes unsuitable for bookworm :-(

First of all, thanks for being so helpful in this wishlist bug!

I did some investigation on weston and turns out out it's pretty easy to
change the launcher order weston uses (see attached patch). I tested it
with a debian12 vm and weston comes up correctly using systemd-logind.
As you said, without this patch, it doesn't. I also did the ABI
compatibility analysis and it's 100% compatible with bookworm's weston.

I think it's a harmless patch, but it would be nice if you could ping
upstream about it. Also, now we have a patch and a new feature so maybe
you think it's too much for a stable update.

Is there a formal procedure to enter Debian's X strike force? Do you
usually use a mailing list or maybe irc? Is there a wiki with more
documentation? I'm spending quite some time looking at it's package so I
might as well try to contribute :-)

> 
> Best,
> Dylan

Cheers,
Charles
From 8d77f72ef669db60a11c9e5e2dd491a638ba76f8 Mon Sep 17 00:00:00 2001
From: Carlos Henrique Lima Melara 
Date: Thu, 9 May 2024 12:53:47 -0300
Subject: [PATCH] d/p/move-libseat-launch-to-lowest-priority.patch: add new
 patch

---
 ...ve-libseat-launch-to-lowest-priority.patch | 39 +++
 debian/patches/series |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/move-libseat-launch-to-lowest-priority.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/move-libseat-launch-to-lowest-priority.patch b/debian/patches/move-libseat-launch-to-lowest-priority.patch
new file mode 100644
index ..e13d090e
--- /dev/null
+++ b/debian/patches/move-libseat-launch-to-lowest-priority.patch
@@ -0,0 +1,39 @@
+From: Carlos Henrique Lima Melara 
+Date: Thu, 9 May 2024 12:46:45 -0300
+Subject: libweston/launcher-util: move launcher-libseat to lowest priority
+
+Previously we had launcher-libseat support disabled in bookworm as it was the
+default in upstream weston. To enable it and support other init systems not
+relying on systemd-logind, we move it to lowest priority. In this way, we can
+have the same behaviour as previously for systems with systemd, but also support
+systems using libseat for example.
+
+Fowarded: not-needed
+Bug-Debian: https://bugs.debian.org/1066112
+Last-Update: 2024-05-09
+---
+ libweston/launcher-util.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/libweston/launcher-util.c b/libweston/launcher-util.c
+index b2219b6..24e74cb 100644
+--- a/libweston/launcher-util.c
 b/libweston/launcher-util.c
+@@ -37,14 +37,14 @@
+ #include 
+
+ static const struct launcher_interface *ifaces[] = {
+-#ifdef HAVE_LIBSEAT
+-	_libseat_iface,
+-#endif
+ #ifdef HAVE_SYSTEMD_LOGIN
+ 	_logind_iface,
+ #endif
+ 	_weston_launch_iface,
+ 	_direct_iface,
++#ifdef HAVE_LIBSEAT
++	_libseat_iface,
++#endif
+ 	NULL,
+ };
+
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..cf9b9c2b
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+move-libseat-launch-to-lowest-priority.patch
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1070866: gpg-from-sq: gpg-from-sq makes the rnp test suite fail

[Daniel Kahn Gillmor]

Package: gpg-from-sq
Version: 0.8.0-5
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 
Control: affects -1 + src:rnp

With gpg-from-sq installed, trying to build rnp 0.17.1-1 results in
these test failures:

---
96% tests passed, 10 tests failed out of 263

Total Test time (real) = 273.53 sec

The following tests FAILED:
254 - cli_tests-SignDefault (Failed)
255 - cli_tests-Encryption (Failed)
256 - cli_tests-SignDSA (Failed)
257 - cli_tests-EncryptElgamal (Failed)
258 - cli_tests-Keystore (Failed)
259 - cli_tests-Misc (Failed)
260 - cli_tests-SignECDSA (Failed)
261 - cli_tests-EncryptEcdh (Failed)
262 - cli_tests-Compression (Failed)
263 - cli_tests-EncryptSignRSA (Failed)
Errors while running CTest
---

Below is example output from the failure of test 260:

-
test 260
Start 260: cli_tests-SignECDSA

260: Test command: /usr/bin/python3 
"/home/dkg/src/rnp/rnp/src/tests/cli_tests.py" "-v" "-d" "SignECDSA"
260: Working Directory: /home/dkg/src/rnp/rnp/build/src/tests
260: Environment variables: 
260:  RNP_TESTS_RNP_PATH=/home/dkg/src/rnp/rnp/build/src/rnp/rnp
260:  RNP_TESTS_RNPKEYS_PATH=/home/dkg/src/rnp/rnp/build/src/rnpkeys/rnpkeys
260:  RNP_TESTS_GPG_PATH=/usr/bin/gpg
260:  RNP_TESTS_GPGCONF_PATH=/usr/bin/gpgconf
260: Test timeout computed to be: 3000
260: Running in /tmp/rnpctmpt95qw7bx
260: /usr/bin/gpg --version
260: 
260: gpg (GnuPG-compatible Sequoia Chameleon) 2.2.40
260: Sequoia gpg Chameleon 0.8.0
260: sequoia-openpgp 1.20.0
260: Copyright (C) 2024 Sequoia PGP
260: License GNU GPL-3.0-or-later 
260: This is free software: you are free to change and redistribute it.
260: There is NO WARRANTY, to the extent permitted by law.
260: 
260: Home: /home/dkg/src/rnp/rnp/debian/.debhelper/generated/_source/home/.gnupg
260: Supported algorithms:
260: Pubkey: RSA, DSA, ECDH, ECDSA, EDDSA
260: Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
260: CAMELLIA128, CAMELLIA192, CAMELLIA256
260: Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
260: Compression: Uncompressed, ZIP, ZLIB, BZIP2
260: Failed to parse GnuPG version.
260: Traceback (most recent call last):
260:   File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 5076, in 

260: setup(LVL)
260:   File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 927, in setup
260: gpg_check_features()
260:   File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 845, in 
gpg_check_features
260: raise_err('Failed to parse GnuPG version.')
260:   File "/home/dkg/src/rnp/rnp/src/tests/cli_common.py", line 39, in 
raise_err
260: raise CLIError(msg, log)
260:   ^^
260:   File "/home/dkg/src/rnp/rnp/src/tests/cli_common.py", line 20, in 
__init__
260: logging.debug(self.log.strip())
260:   ^^
260: AttributeError: 'NoneType' object has no attribute 'strip'
---




--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 gpg-from-sq depends on:
ii  gpg-sq  0.8.0-5

gpg-from-sq recommends no packages.

gpg-from-sq suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1070865: webkit2gtk/experimental FTBFS on big endian

[Adrian Bunk]

Source: webkit2gtk
Version: 2.45.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=2.45.1-1

...
In file included from 
/<>/Source/ThirdParty/skia/include/private/base/SkAPI.h:11,
 from 
/<>/Source/ThirdParty/skia/include/private/base/SkAssert.h:11,
 from 
/<>/Source/ThirdParty/skia/src/base/SkArenaAlloc.h:11,
 from 
/<>/Source/ThirdParty/skia/src/base/SkArenaAlloc.cpp:8:
/<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:57:6:
 error: #error "The Skia team is not endian-savvy enough to support big-endian 
CPUs."
   57 | #error "The Skia team is not endian-savvy enough to support 
big-endian CPUs."
  |  ^
/<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:58:6:
 error: #error "If you still want to use Skia,"
   58 | #error "If you still want to use Skia,"
  |  ^
/<>/Source/ThirdParty/skia/include/private/base/SkLoadUserConfig.h:59:6:
 error: #error "please define I_ACKNOWLEDGE_SKIA_DOES_NOT_SUPPORT_BIG_ENDIAN."
   59 | #error "please define 
I_ACKNOWLEDGE_SKIA_DOES_NOT_SUPPORT_BIG_ENDIAN."
  |  ^
...

Bug#1069759: alabaster: Please update to the latest upstream version

[Dmitry Shachnev]

Control: tags -1 + patch

Dear Maintainer,

On Wed, Apr 24, 2024 at 02:01:42PM +0300, Dmitry Shachnev wrote:
> Source: alabaster
> Version: 0.7.12-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Sphinx now requires alabaster 0.7.14 or newer [1]. It would be nice if you
> packaged the latest version, which is 0.7.16 at the moment [2].
> 
> I can prepare a pull request if needed.

I have prepared a pull request now [1].

[1]: https://github.com/jbouse-debian/alabaster/pull/9

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1070860: musescore3: CVE-2023-44428

[Thorsten Glaser]

Dixi quod…

>Huh. MuseScore (Studio) is a desktop application.

I’ll add a README.Debian note about that fact and that upstream
has never considered crashes on invalid input a bug and that it
hasn’t been designed as a remotely accessible service, but as a
desktop application, and that users should confine suitably.

The Capella import is a vast minority feature and incomplete
anyway, so I douby many users use it directly.

It’ll also document that these versions receive no support
(security or otherwise) from upstream any more (they’ve gone
open-core, proprietary-extension, version 4, which I don’t
intend to package), though there’s a 3.x community effort
whose initiator I know, which I’ve been intending to package
as musescore-snapshot (it’s “tip of the git branch” without
releases to avoid looking official due to the use of the
well-known name) and with whom I’ll cooperate.

This is a bit like the limited security support for binutils,
I suppose. Could/should we document that in the same places?

>I will have to investigate whether they mean indeed this
>or the musescore.com site or mobile äpps or something.

Given the lack of further information, I’ve contacted the ZDI
to get some; otherwise I can run it with valgrind a bit, but
without a reproducer testcase it’s not very likely to find it.

I’ll keep the bugreport informed.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1070864: ITP: golang-github-stratoberry-go-gpsd -- GPSD client

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-github-stratoberry-go-gpsd
  Version : 1.3.0
  Upstream Contact: Josip Lisec 
* URL : https://github.com/stratoberry/go-gpsd
* License : Expat
  Programming Lang: Go
  Description : GPSD client

  go-gpsd is a streaming client for GPSD's JSON service and, as
  such, can be used only in an async manner, unlike clients for
  other languages which support both async and sync modes.

Bug#1070343: openfortivpn: Should not be built with --enable-legacy-pppd with ppp 2.5

[James Cowgill]

Control: retitle -1 openfortivpn: Should not be built with --enable-legacy-pppd 
with ppp 2.5

Hi,

I also encountered this bug as relating to pppd-accept-remote. It
happens because the Debian package is built with --enable-legacy-pppd
which was needed with ppp 2.4 but now needs removing since ppp has been
updated to 2.5 in Debian.

Also adding Depends: ppp (>= 2.5) for good measure seems like a good
idea after.

After doing both of those and rebuilding openfortivpn my existing
config works again.

James

Bug#1070862: and this looses files

[Rene Engelhard]

severity 1070862 serious
thanks

Hi,

this is even worse. It looses  the library file for the "non-main" 
libraries after cleanup:


Clean testing chroot.

# apt install libpoppler-dev libpoppler-cpp-dev
[...]

# apt update
# apt dist-upgrade
The following packages were automatically installed and are no longer 
required:

  libpoppler-cpp0t64 libpoppler126t64
Use 'sudo apt autoremove' to remove them.

Upgrading:
  gcc-14-base libaudit-common libc-bin libgcc-s1 libncursesw6 
libpoppler-dev libslang2  libtinfo6 nano ncurses-bin
  kmodlibaudit1   libc6libkmod2  libpoppler-cpp-dev 
libsharpyuv0   libstdc++6 libwebp7  ncurses-base zlib1g


Installing dependencies:
  ca-certificateslibldap-2.5-0  libnghttp2-14 libpoppler134 
librtmp1   libsasl2-moduleslibssh2-1t64 publicsuffix
  libcurl3t64-gnutls libldap-common libpoppler-cpp0v5 libpsl5t64 
libsasl2-2 libsasl2-modules-db openssl


Suggested packages:
  libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal 
libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql


Summary:
  Upgrading: 20, Installing: 15, Removing: 0, Not Upgrading: 0
  Download size: 11.3 MB
  Space needed: 10.1 MB / 133 GB available

Continue? [Y/n]
Get:1 http://deb.debian.org/debian sid/main amd64 ncurses-bin amd64 
6.5-2 [433 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 gcc-14-base amd64 
14-20240429-1 [43.9 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 libgcc-s1 amd64 
14-20240429-1 [72.4 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libstdc++6 amd64 
14-20240429-1 [715 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 libc6 amd64 2.38-8 
[2771 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 libc-bin amd64 2.38-8 
[610 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 ncurses-base all 6.5-2 
[270 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 libaudit-common all 
1:3.1.2-2.1 [11.4 kB]
Get:9 http://deb.debian.org/debian sid/main amd64 libaudit1 amd64 
1:3.1.2-2.1 [48.5 kB]
Get:10 http://deb.debian.org/debian sid/main amd64 libncursesw6 amd64 
6.5-2 [135 kB]
Get:11 http://deb.debian.org/debian sid/main amd64 libtinfo6 amd64 6.5-2 
[344 kB]
Get:12 http://deb.debian.org/debian sid/main amd64 zlib1g amd64 
1:1.3.dfsg+really1.3.1-1 [87.9 kB]

Get:13 http://deb.debian.org/debian sid/main amd64 kmod amd64 32-1 [95.7 kB]
Get:14 http://deb.debian.org/debian sid/main amd64 libkmod2 amd64 32-1 
[60.1 kB]

Get:15 http://deb.debian.org/debian sid/main amd64 nano amd64 8.0-1 [659 kB]
Get:16 http://deb.debian.org/debian sid/main amd64 openssl amd64 3.2.1-3 
[1360 kB]
Get:17 http://deb.debian.org/debian sid/main amd64 ca-certificates all 
20240203 [158 kB]
Get:18 http://deb.debian.org/debian sid/main amd64 libsasl2-modules-db 
amd64 2.1.28+dfsg1-6 [19.5 kB]
Get:19 http://deb.debian.org/debian sid/main amd64 libsasl2-2 amd64 
2.1.28+dfsg1-6 [56.9 kB]
Get:20 http://deb.debian.org/debian sid/main amd64 libldap-2.5-0 amd64 
2.5.17+dfsg-1 [186 kB]
Get:21 http://deb.debian.org/debian sid/main amd64 libnghttp2-14 amd64 
1.61.0-1+b1 [75.6 kB]
Get:22 http://deb.debian.org/debian sid/main amd64 libpsl5t64 amd64 
0.21.2-1.1 [56.8 kB]
Get:23 http://deb.debian.org/debian sid/main amd64 librtmp1 amd64 
2.4+20151223.gitfa8646d.1-2+b4 [58.5 kB]
Get:24 http://deb.debian.org/debian sid/main amd64 libssh2-1t64 amd64 
1.11.0-4.1+b2 [215 kB]
Get:25 http://deb.debian.org/debian sid/main amd64 libcurl3t64-gnutls 
amd64 8.7.1-5 [433 kB]
Get:26 http://deb.debian.org/debian sid/main amd64 libldap-common all 
2.5.17+dfsg-1 [31.5 kB]
Get:27 http://deb.debian.org/debian sid/main amd64 libpoppler134 amd64 
24.02.0-2 [1029 kB]
Get:28 http://deb.debian.org/debian sid/main amd64 libpoppler-cpp0v5 
amd64 24.02.0-2 [41.3 kB]
Get:29 http://deb.debian.org/debian sid/main amd64 libpoppler-cpp-dev 
amd64 24.02.0-2 [14.7 kB]
Get:30 http://deb.debian.org/debian sid/main amd64 libpoppler-dev amd64 
24.02.0-2 [8080 B]
Get:31 http://deb.debian.org/debian sid/main amd64 libsasl2-modules 
amd64 2.1.28+dfsg1-6 [66.0 kB]
Get:32 http://deb.debian.org/debian sid/main amd64 libsharpyuv0 amd64 
1.4.0-0.1 [113 kB]
Get:33 http://deb.debian.org/debian sid/main amd64 libslang2 amd64 
2.3.3-5 [551 kB]
Get:34 http://deb.debian.org/debian sid/main amd64 libwebp7 amd64 
1.4.0-0.1 [311 kB]
Get:35 http://deb.debian.org/debian sid/main amd64 publicsuffix all 
20231001.0357-0.1 [125 kB]

Fetched 11.3 MB in 2s (6218 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Extracting templates from packages: 100%
Preconfiguring 

Bug#1070860: musescore3: CVE-2023-44428

[Thorsten Glaser]

Moritz Mühlenhoff dixit:

>| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code
>| Execution Vulnerability. This vulnerability allows remote attackers

Huh. MuseScore (Studio) is a desktop application.
I will have to investigate whether they mean indeed this
or the musescore.com site or mobile äpps or something.

But if there’s a fix for a parsing issue, I’ll backport it
(also to musescore2 if applicable).

Thanks for noticing,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#1070862: poppler: possibly unintended revert of t64 renames for non-main library in 24.x

[Jeremy Bícha]

Control: severity -1 serious

On Fri, May 10, 2024 at 1:48 PM Simon McVittie  wrote:
> Please bump this up to RC if analysis shows that it is a genuine problem,
> or close it if analysis shows that I'm being overly cautious.

I think it is appropriate to bump this to RC. I will try to get this
upload done by tomorrow; I'm in the midst of a busy travel week.

Thank you,
Jeremy Bícha

Bug#1070863: inkscape: "Import Web Image" fails with ModuleNotFoundError: No module named 'appdirs'

[Ralf Jung]

Package: inkscape
Version: 1.2.2-2+b3
Severity: normal

Dear Maintainer,

to reproduce, simply click File - Import Web Image. I then get an error dialog 
showing
a Python exception:

Traceback (most recent call last):
  File "/usr/share/inkscape/extensions/other/clipart/import_web_image.py", line 
35, in 
from appdirs import user_cache_dir
ModuleNotFoundError: No module named 'appdirs'

Looks like maybe a dependency on python3-appdirs is missing?
Once I install that, I get another error about importing 'cachecontrol'.
After also installing python3-cachecontrol, the import web window finally 
appears.

Kind regards,
Ralf

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

Kernel: Linux 6.6.15-amd64 (SMP w/20 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 inkscape depends on:
ii  lib2geom1.2.0  1.2.2-3
ii  libatkmm-1.6-1v5   2.28.4-1
ii  libboost-filesystem1.83.0  1.83.0-2+b2
ii  libc6  2.37-15
ii  libcairo-gobject2  1.18.0-1+b1
ii  libcairo2  1.18.0-1+b1
ii  libcairomm-1.0-1v5 1.14.5-1
ii  libcdr-0.1-1   0.1.7-1
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b1
ii  libgc1 1:8.2.6-1
ii  libgcc-s1  14-20240201-3
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-3+b1
ii  libglib2.0-0   2.78.4-1
ii  libglibmm-2.4-1v5  2.66.6-2+b1
ii  libgomp1   14-20240201-3
ii  libgsl27   2.7.1+dfsg-6+b1
ii  libgspell-1-2  1.12.2-1+b1
ii  libgtk-3-0 3.24.41-1
ii  libgtkmm-3.0-1v5   3.24.8-2+b1
ii  libharfbuzz0b  8.3.0-2
ii  libjpeg62-turbo1:2.1.5-2+b2
ii  liblcms2-2 2.14-2+b1
ii  libmagick++-6.q16-98:6.9.12.98+dfsg1-5+b1
ii  libpango-1.0-0 1.52.0+ds-1
ii  libpangocairo-1.0-01.52.0+ds-1
ii  libpangoft2-1.0-0  1.52.0+ds-1
ii  libpangomm-1.4-1v5 2.46.4-1
ii  libpng16-161.6.43-1
ii  libpoppler-glib8   22.12.0-2+b1
ii  libpoppler126  22.12.0-2+b1
ii  libpotrace01.16-2+b1
ii  libreadline8   8.2-3+b1
ii  librevenge-0.0-0   0.0.5-3
ii  librsvg2-common2.54.7+dfsg-2
ii  libsigc++-2.0-0v5  2.12.1-1
ii  libsoup2.4-1   2.74.3-3
ii  libstdc++6 14-20240201-3
ii  libvisio-0.1-1 0.1.7-1+b3
ii  libwpg-0.3-3   0.3.4-3
ii  libx11-6   2:1.8.7-1
ii  libxml22.9.14+dfsg-1.3+b2
ii  libxslt1.1 1.1.35-1
ii  python33.11.6-1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages inkscape recommends:
ii  aspell   0.60.8.1-1+b1
ii  fig2dev  1:3.2.9-3
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  libimage-magick-perl 8:6.9.12.98+dfsg1-5
ii  libwmf-bin   0.2.13-1.1
ii  python3-cssselect1.2.0-2
ii  python3-lxml 5.1.0-1
ii  python3-numpy1:1.24.2-2
ii  python3-scour0.38.2-4.1

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  pstoedit  
ii  python3-packaging 24.0-1
pn  python3-uniconvertor  
ii  ruby  1:3.1

-- no debconf information

Bug#1070862: poppler: possibly unintended revert of t64 renames for non-main library in 24.x

[Simon McVittie]

Source: poppler
Version: 24.02.0-1
Severity: important
X-Debbugs-Cc: po...@debian.org, jeremy.bi...@canonical.com

Attempting to summarize recent discussion with _rene_ on #debian-devel:

poppler in trixie builds these libraries:

- libpoppler126t64
- libpoppler-glib8t64
- libpoppler-qt5-1t64
- libpoppler-qt6-3t64
- libpoppler-cpp0t64

It is not obvious to me whether the -glib, -qt, -cpp libraries genuinely
broke their ABIs during the time64 transition, or whether they were only
renamed out of an abundance of caution.

poppler in experimental and (since today) unstable builds these libraries:

- libpoppler134
- libpoppler-glib8
- libpoppler-qt5-1
- libpoppler-qt6-3
- libpoppler-cpp0v5

In other words, it correctly drops the t64 suffix from the main libpoppler
across a SONAME bump, but it also reverts the renaming of the -glib,
-qt, -cpp libraries.

Was this intentional?

If the higher-level libraries never actually broke their ABI, then renaming
them back to their Debian 12 names might be OK, but they're probably going
to need versioned Breaks/Replaces on their ...t64 names.

If the higher-level libraries *did* break their ABI, then they need to
keep the new t64 names.

Please bump this up to RC if analysis shows that it is a genuine problem,
or close it if analysis shows that I'm being overly cautious.

smcv

Bug#1070861: hdf5: CVE-2024-33877 CVE-2024-33876 CVE-2024-33875 CVE-2024-33874 CVE-2024-33873 CVE-2024-32624 CVE-2024-32623 CVE-2024-32622 CVE-2024-32621 CVE-2024-32620 CVE-2024-32619 CVE-2024-32618 C

[Moritz Mühlenhoff]

Source: hdf5
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for hdf5:
https://www.hdfgroup.org/2024/05/new-hdf5-cve-issues-fixed-in-1-14-4/

CVE-2024-33877[0]:
| HDF5 Library through 1.14.3 has a heap-based buffer overflow in
| H5T__conv_struct_opt in H5Tconv.c.


CVE-2024-33876[1]:
| HDF5 Library through 1.14.3 has a heap buffer overflow in
| H5S__point_deserialize in H5Spoint.c.


CVE-2024-33875[2]:
| HDF5 Library through 1.14.3 has a heap-based buffer overflow in
| H5O__layout_encode in H5Olayout.c, resulting in the corruption of
| the instruction pointer.


CVE-2024-33874[3]:
| HDF5 Library through 1.14.3 has a heap buffer overflow in
| H5O__mtime_new_encode in H5Omtime.c.


CVE-2024-33873[4]:
| HDF5 Library through 1.14.3 has a heap-based buffer overflow in
| H5D__scatter_mem in H5Dscatgath.c.


CVE-2024-32624[5]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5T__ref_mem_setnull in H5Tref.c (called from H5T__conv_ref in
| H5Tconv.c), resulting in the corruption of the instruction pointer.


CVE-2024-32623[6]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5VM_array_fill in H5VM.c (called from H5S_select_elements in
| H5Spoint.c).


CVE-2024-32622[7]:
| HDF5 Library through 1.14.3 contains a out-of-bounds read operation
| in H5FL_arr_malloc in H5FL.c (called from H5S_set_extent_simple in
| H5S.c).


CVE-2024-32621[8]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5HG_read in H5HG.c (called from H5VL__native_blob_get in
| H5VLnative_blob.c), resulting in the corruption of the instruction
| pointer.


CVE-2024-32620[9]:
| HDF5 Library through 1.14.3 contains a heap-based buffer over-read
| in H5F_addr_decode_len in H5Fint.c, resulting in the corruption of
| the instruction pointer.


CVE-2024-32619[10]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5T_copy_reopen in H5T.c, resulting in the corruption of the
| instruction pointer.


CVE-2024-32618[11]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5T__get_native_type in H5Tnative.c, resulting in the corruption of
| the instruction pointer.


CVE-2024-32617[12]:
| HDF5 Library through 1.14.3 contains a heap-based buffer over-read
| caused by the unsafe use of strdup in H5MM_xstrdup in H5MM.c (called
| from H5G__ent_to_link in H5Glink.c).


CVE-2024-32616[13]:
| HDF5 Library through 1.14.3 contains a heap-based buffer over-read
| in H5O__dtype_encode_helper in H5Odtype.c.


CVE-2024-32615[14]:
| HDF5 Library through 1.14.3 contains a heap-based buffer overflow in
| H5Z__nbit_decompress_one_byte in H5Znbit.c, caused by the earlier
| use of an initialized pointer.


CVE-2024-32614[15]:
| HDF5 Library through 1.14.3 has a SEGV in H5VM_memcpyvv in H5VM.c.


CVE-2024-32613[16]:
| HDF5 Library through 1.14.3 contains a heap-based buffer over-read
| in the function H5HL__fl_deserialize in H5HLcache.c, a different
| vulnerability than CVE-2024-32612.


CVE-2024-32612[17]:
| HDF5 Library through 1.14.3 contains a heap-based buffer over-read
| in H5HL__fl_deserialize in H5HLcache.c, resulting in the corruption
| of the instruction pointer, a different vulnerability than
| CVE-2024-32613.


CVE-2024-32611[18]:
| HDF5 Library through 1.14.3 may use an uninitialized value in
| H5A__attr_release_table in H5Aint.c.


CVE-2024-32610[19]:
| HDF5 Library through 1.14.3 has a SEGV in H5T_close_real in H5T.c,
| resulting in a corrupted instruction pointer.


CVE-2024-32609[20]:
| HDF5 Library through 1.14.3 allows stack consumption in the function
| H5E_printf_stack in H5Eint.c.


CVE-2024-32607[21]:
| HDF5 Library through 1.14.3 has a SEGV in H5A__close in H5Aint.c,
| resulting in the corruption of the instruction pointer.


CVE-2024-32606[22]:
| HDF5 Library through 1.14.3 may attempt to dereference uninitialized
| values in h5tools_str_sprint in tools/lib/h5tools_str.c (called from
| h5tools_dump_simple_data in tools/lib/h5tools_dump.c).


CVE-2024-32605[23]:
| HDF5 Library through 1.14.3 has a heap-based buffer over-read in
| H5VM_memcpyvv in H5VM.c (called from H5D__compact_readvv in
| H5Dcompact.c).


CVE-2024-29166[24]:
| HDF5 through 1.14.3 contains a buffer overflow in H5O__linfo_decode,
| resulting in the corruption of the instruction pointer and causing
| denial of service or potential code execution.


CVE-2024-29165[25]:
| HDF5 through 1.14.3 contains a buffer overflow in
| H5Z__filter_fletcher32, resulting in the corruption of the
| instruction pointer and causing denial of service or potential code
| execution.


CVE-2024-29164[26]:
| HDF5 through 1.14.3 contains a stack buffer overflow in
| H5R__decode_heap, resulting in the corruption of the instruction
| pointer and causing denial of service or potential code execution.


CVE-2024-29163[27]:
| HDF5 through 1.14.3 contains a heap buffer overflow in
| H5T__bit_find, resulting in the corruption of 

Bug#1070860: musescore3: CVE-2023-44428

[Moritz Mühlenhoff]

Source: musescore3
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for musescore3.

CVE-2023-44428[0]:
| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code
| Execution Vulnerability. This vulnerability allows remote attackers
| to execute arbitrary code on affected installations of MuseScore.
| User interaction is required to exploit this vulnerability in that
| the target must visit a malicious page or open a malicious file.
| The specific flaw exists within the parsing of CAP files. The issue
| results from the lack of proper validation of the length of user-
| supplied data prior to copying it to a heap-based buffer. An
| attacker can leverage this vulnerability to execute code in the
| context of the current process. Was ZDI-CAN-20769.

Unfortunatetly details are sparse, the only reference is
https://www.zerodayinitiative.com/advisories/ZDI-23-1526/


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-44428
https://www.cve.org/CVERecord?id=CVE-2023-44428

Please adjust the affected versions in the BTS as needed.

Bug#1070859: npgsql: CVE-2024-32655

[Moritz Mühlenhoff]

Source: npgsql
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for npgsql.

CVE-2024-32655[0]:
| Npgsql is the .NET data provider for PostgreSQL. The `WriteBind()`
| method in `src/Npgsql/Internal/NpgsqlConnector.FrontendMessages.cs`
| uses `int` variables to store the message length and the sum of
| parameter lengths. Both variables overflow when the sum of parameter
| lengths becomes too large. This causes Npgsql to write a message
| size that is too small when constructing a Postgres protocol message
| to send it over the network to the database. When parsing the
| message, the database will only read a small number of bytes and
| treat any following bytes as new messages while they belong to the
| old message. Attackers can abuse this to inject arbitrary Postgres
| protocol messages into the connection, leading to the execution of
| arbitrary SQL statements on the application's behalf. This
| vulnerability is fixed in 4.0.14, 4.1.13, 5.0.18, 6.0.11, 7.0.7, and
| 8.0.3.

https://github.com/npgsql/npgsql/security/advisories/GHSA-x9vc-6hfv-hg8c
https://github.com/npgsql/npgsql/commit/f7e7ead0702d776a8f551f5786c4cac2d65c4bc6


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-32655
https://www.cve.org/CVERecord?id=CVE-2024-32655

Please adjust the affected versions in the BTS as needed.

Bug#1070858: golang-github-opencontainers-go-digest: CVE-2024-3727

[Moritz Mühlenhoff]

Source: golang-github-opencontainers-go-digest
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for 
golang-github-opencontainers-go-digest.

CVE-2024-3727[0]:
| A flaw was found in the github.com/containers/image library. This
| flaw allows attackers to trigger unexpected authenticated registry
| accesses on behalf of a victim user, causing resource exhaustion,
| local path traversal, and other attacks.

Details are a little sparse, the only reference is
https://bugzilla.redhat.com/show_bug.cgi?id=2274767 at this point.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-3727
https://www.cve.org/CVERecord?id=CVE-2024-3727

Please adjust the affected versions in the BTS as needed.

Bug#1036826: Please start handling \c

[Martin Quinson]

tag 1036826 fixed-upstream
thanks

Hello Helge,

I think I fixed this bug upstream, and it will be part of the next release,
later this month. I did not implement a full support for \c since it's
difficult in the current code base, but at least the groff.1 page proceeds. 

If you have other failures from other pages, please tell me so that I can check
whether my fix is enough even before the release.

Thanks for your help and patience,
Mt

Le jeudi 14 mars 2024 à 19:56 +, Helge Kreutzmann a écrit :
> Hello Martin,
> Am Sun, Mar 10, 2024 at 10:14:20PM +0100 schrieb Martin Quinson:
> > Instead, I'd appreciate if you could do a merge request with a test file,
> > along
> > with the expected output. It'd save me the time to dig into the discussion
> > of
> > this bug. 
> > 
> > I'm not saying that I won't fix it w/o this test case. I'm just saying that
> > providing a test case is a better approach to speedup the fix than severity
> > abuse.
> 
> I hope explaining the test file in this bug is fine as well, because
> I'm not sure what to do exactly merge and how.
> 
> The test case is groff(1) as it is in Debian unstable:
> 
> $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim
> --option generated --option
> untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U
> NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master groff.1 -M
> utf-8 -p test.pot
> groff.1:2279: (po4a::man)
>   Escape sequence \c encountered. This is not completely
>     handled yet.
> 
> And there is no output.
> 
> If I do a crude preprocessing, it kind of works:
> 
> $ cat groff.1 | perl -p -e 's/\\c\n//' > groff.test.1
> $ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim
> --option generated --option
> untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,U
> NINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master
> groff.test.1 -M utf-8 -p test.pot
> $ wc -l test.pot
> 3157 test.pot
> 
> I hope this helps you working on this, together with the discussion in
> this bug.
> 
> Thanks for your support!
> 
> Greetings
> 
>   Helge



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

Bug#714589:

[Andreas Metzler]

On 2024-05-09 Alex Henrie  wrote:
> This packaging bug is a big problem for Proton's Wine fork, which
> needs both /usr/lib/i386-linux-gnu/libgcrypt.so and
> /usr/lib/x86_64-linux-gnu/libgcrypt.so to be available at build time.
> Currently, Proton built for Debian can only support ECDH in 32-bit
> games or 64-bit games, but not both. See
> https://github.com/ValveSoftware/wine/commit/8ae2eb018d5b6ea97879f2acc4623afa4de6bc83

> However, it won't do much good to fix libgcrypt20-dev without fixing
> its dependency libgpg-error-dev first. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933713

Hello,

changing libgpg-error-dev might be feasible now that we got rid of
gpg-error-config.

However that was quite painful. codesearch.debian.net lists 78 packages
matching libgcrypt-config. I suspect the majority will be using the
macros from libgcrypt.m4 and therefore already use gpgrt-config but
I also suspect that about a quarter of these either do not or do not or
do not use/autoupdate the current libgcrypt.m4

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

Bug#1070857: nix: FTBFS: /usr/bin/ld: cannot find src/libutil/tests/libnixutil-tests.a: No such file or directory

[Santiago Vila]

As promised, here is the patch.

Note: I have actually tested it, and it fixed the build failure for me.
(Thanks to Sergei Trofimovich who helped me to find the fix in the git repo)

Thanks.commit e1cc73faee68409dfdac07a39dca517813a40e2c
Author: Santiago Vila 
Date:   Fri May 10 14:45:00 2024 +0200

Cherry-pick two upstream patches to fix makefile bug. Closes: #1070857.

diff --git a/debian/patches/0013-fix-makefile-bug.patch 
b/debian/patches/0013-fix-makefile-bug.patch
new file mode 100644
index 0..3765db1ec
--- /dev/null
+++ b/debian/patches/0013-fix-makefile-bug.patch
@@ -0,0 +1,22 @@
+From: John Ericson 
+Date: Tue Nov 14 11:42:25 2023 -0500
+Subject: Fix makefile bug confusing `libnixutil-test` exe vs lib
+Bug-Debian: https://bugs.debian.org/1070857
+Origin: upstream, 
https://github.com/NixOS/nix/commit/9c7749e13508996eb9df83b1692664cc8cdbf952
+Forwarded: not-needed
+Last-Update: 2024-05-10
+
+The `-exe` variant is the program, the unsuffixed variant is the library.
+
+The corrected usage matches `libnixstore-test`.
+
+--- a/src/libutil/tests/local.mk
 b/src/libutil/tests/local.mk
+@@ -1,6 +1,6 @@
+ check: libutil-tests_RUN
+ 
+-programs += libutil-tests
++programs += libutil-tests-exe
+ 
+ libutil-tests-exe_NAME = libnixutil-tests
+ 
diff --git a/debian/patches/0014-fix-make-check.patch 
b/debian/patches/0014-fix-make-check.patch
new file mode 100644
index 0..f96519e34
--- /dev/null
+++ b/debian/patches/0014-fix-make-check.patch
@@ -0,0 +1,19 @@
+From: John Ericson 
+Date: Fri Nov 17 11:26:45 2023 -0500
+Subject: Fix `make check`
+Bug-Debian: https://bugs.debian.org/1070857
+Origin: upstream, 
https://github.com/NixOS/nix/commit/293ae592576bb9c48975466613fcba6a30d06f5e
+Forwarded: not-needed
+Last-Update: 2024-05-10
+
+After 9c7749e13508996eb9df83b1692664cc8cdbf952, `libutil-tests_RUN`
+doesn't exist. It needs to become `libutil-tests-exe_RUN`.
+
+--- a/src/libutil/tests/local.mk
 b/src/libutil/tests/local.mk
+@@ -1,4 +1,4 @@
+-check: libutil-tests_RUN
++check: libutil-tests-exe_RUN
+ 
+ programs += libutil-tests-exe
+ 
diff --git a/debian/patches/series b/debian/patches/series
index ef37b55cc..cd4bc73d9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,5 @@
 0010-libexpr-Add-various-files-to-clean-files.patch
 0011-manual-Add-various-files-to-clean-files.patch
 0012-nix-Add-various-files-to-clean-files.patch
+0013-fix-makefile-bug.patch
+0014-fix-make-check.patch

Bug#1070748: gqrx-sdr: it does not start

[A. Maitland Bottoms]

Renzo Davoli  writes:

> It was just a temporary misalignment during packages updates.
>
> Now it works.

That was my thinking too. Do not be sorry about this bug - it was worth
keeping track of.

A lot of transitions went in to making it work. Took a while, but I am
glad to hear you have it working.

(It had originally passed the high bar of "It worked for me when I tried
it before uploading to Debian unstable".)

Soon I will update my "testing" machine, and try out gqrx there
myself. If that goes well, then I will close this bug.

Thanks for your interest in gqrx, and in making the future Trixie
release a quality platform for SDR applications.

73 de aa4hs,
-Maitland

Bug#1070836: rust-apple-nvram: Switch from rust-nix 0.26 to 0.27

[Andreas Henriksson]

Hello Jeremy Bicha,

Thanks for explicitly CCing me on this. See below. There's no urgency to
fix this as the relevant rdeps are still stuck in NEW (for 6+ months).

On Fri, May 10, 2024 at 05:31:54AM -0400, Jeremy Bícha wrote:
> Source: rust-apple-nvram
> Version: 0.2.0-1
> Severity: serious
> Tags: ftbfs upstream sid
> X-Debbugs-CC: andr...@fatal.se
> 
> rust-apple-nvram Depends and Build-Depends: rust-nix 0.26 but Unstable
> has rust-nix 0.27 instead. I tried doing a simple version bump from
> 0.26 to 0.27 in the package but dh_auto_test failed.
> 
> Thank you,
> Jeremy Bícha

I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.

```
error[E0433]: failed to resolve: could not find `ioctl_write_ptr` in `nix`
  --> src/mtd.rs:50:6
   |
50 | nix::ioctl_write_ptr!(mtd_mem_erase, b'M', 2, EraseInfoUser);
   |  ^^^ could not find `ioctl_write_ptr` in `nix`

error[E0433]: failed to resolve: could not find `ioctl_read` in `nix`
  --> src/mtd.rs:51:6
   |
51 | nix::ioctl_read!(mtd_mem_get_info, b'M', 1, MtdInfoUser);
   |  ^^ could not find `ioctl_read` in `nix`

error[E0425]: cannot find function `mtd_mem_get_info` in this scope
  --> src/mtd.rs:54:17
   |
54 | if unsafe { mtd_mem_get_info(file.as_raw_fd(),  
MtdInfoUser::default()) }.is_err() {
   |  not found in this scope

error[E0425]: cannot find function `mtd_mem_erase` in this scope
  --> src/mtd.rs:62:9
   |
62 | mtd_mem_erase(file.as_raw_fd(), _info).unwrap();
   | ^ not found in this scope

Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `apple-nvram` (lib test) due to 4 previous errors
```

Regards,
Andreas Henriksson

Bug#1070857: nix: FTBFS: /usr/bin/ld: cannot find src/libutil/tests/libnixutil-tests.a: No such file or directory

[Santiago Vila]

Package: src:nix
Version: 2.18.1+dfsg-1
Severity: serious
Tags: ftbfs fixed-upstream patch

Dear maintainer:

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


[...]
g++ -o src/libstore/tests/nar-info-disk-cache.o -c src/libstore/tests/nar-info-disk-cache.cc 
-Wdate-time -D_FORTIFY_SOURCE=2  -fstack-protector-strong -Wformat -Werror=format-security 
-ffile-prefix-map=/<>=. -O3  -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-Wno-deprecated-declarations -Werror=switch -g -Wall -include config.h -std=c++2a -I src 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libcpuid -DREADLINE -I/usr/include/x86_64-linux-gnu 
-DLIBARCHIVE_STATIC -I/usr/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I 
src/libstore -I src/libutil -Werror=switch-enum -MMD -MF src/libstore/tests/.nar-info-disk-cache.o.dep 
-MP
g++ -o src/libstore/tests/outputs-spec.o -c src/libstore/tests/outputs-spec.cc -Wdate-time 
-D_FORTIFY_SOURCE=2  -fstack-protector-strong -Wformat -Werror=format-security 
-ffile-prefix-map=/<>=. -O3  -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-Wno-deprecated-declarations -Werror=switch -g -Wall -include config.h -std=c++2a -I src 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libcpuid -DREADLINE -I/usr/include/x86_64-linux-gnu 
-DLIBARCHIVE_STATIC -I/usr/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I 
src/libstore -I src/libutil -Werror=switch-enum -MMD -MF src/libstore/tests/.outputs-spec.o.dep -MP
g++ -o src/libstore/tests/path.o -c src/libstore/tests/path.cc -Wdate-time -D_FORTIFY_SOURCE=2  
-fstack-protector-strong -Wformat -Werror=format-security 
-ffile-prefix-map=/<>=. -O3  -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-Wno-deprecated-declarations -Werror=switch -g -Wall -include config.h -std=c++2a -I src 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libcpuid -DREADLINE -I/usr/include/x86_64-linux-gnu 
-DLIBARCHIVE_STATIC -I/usr/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I 
src/libstore -I src/libutil -Werror=switch-enum -MMD -MF src/libstore/tests/.path.o.dep -MP
g++ -o src/libstore/tests/references.o -c src/libstore/tests/references.cc -Wdate-time 
-D_FORTIFY_SOURCE=2  -fstack-protector-strong -Wformat -Werror=format-security 
-ffile-prefix-map=/<>=. -O3  -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-Wno-deprecated-declarations -Werror=switch -g -Wall -include config.h -std=c++2a -I src 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libcpuid -DREADLINE -I/usr/include/x86_64-linux-gnu 
-DLIBARCHIVE_STATIC -I/usr/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -I 
src/libstore -I src/libutil -Werror=switch-enum -MMD -MF src/libstore/tests/.references.o.dep -MP
ld  -r -o tests/test-libstoreconsumer/libnixstore-tests.o 
src/libstore/tests/derivation.o src/libstore/tests/derived-path.o 
src/libstore/tests/downstream-placeholder.o src/libstore/tests/machines.o 
src/libstore/tests/nar-info-disk-cache.o src/libstore/tests/outputs-spec.o 
src/libstore/tests/path.o src/libstore/tests/references.o
ar crs src/libstore/tests/libnixstore-tests.a 
tests/test-libstoreconsumer/libnixstore-tests.o
g++ -o src/libstore/tests/libnixstore-tests -L/usr/lib/x86_64-linux-gnu 
-Wl,-z,relro -Wl,-z,now  -L/usr/lib/x86_64-linux-gnu -Wl,-z,relro -Wl,-z,now  
-lgtest_main -lgtest  src/libstore/tests/libnixstore-tests.a -lrapidcheck 
-lgtest_main -lgtest  src/libutil/tests/libnixutil-tests.a -lrapidcheck 
-lgtest_main -lgtest  src/libutil/libnixutil.a -pthread -lcrypto -ldl -pthread 
-lbrotlienc -lbrotlicommon -lbrotlidec -lbrotlicommon -larchive -lnettle -lacl 
-llzma -lzstd -llz4 -lbz2 -lz -lxml2 -lz -L/usr/lib/x86_64-linux-gnu 
-lboost_context -lcpuid   src/libstore/libnixstore.a -lsqlite3 -lm -lz -lcurl 
-lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -lgssapi_krb5 
-llber -lldap -llber -lzstd -lbrotlidec -lz -lsodium -pthread -pthread -ldl 
-lseccomp  src/libutil/libnixutil.a -pthread -lcrypto -ldl -pthread -lbrotlienc 
-lbrotlicommon -lbrotlidec -lbrotlicommon -larchive -lnettle -lacl -llzma 
-lzstd -llz4 -lbz2 -lz -lxml2 -lz -L/usr/lib/x86_64-linux-gnu -lboost_context 
-lcpuid   src/libutil/libnixutil.a -pthread -lcrypto -ldl -pthread -lbrotlienc 
-lbrotlicommon -lbrotlidec -lbrotlicommon -larchive -lnettle -lacl -llzma 
-lzstd -llz4 -lbz2 -lz -lxml2 -lz -L/usr/lib/x86_64-linux-gnu -lboost_context 
-lcpuid
/usr/bin/ld: cannot find src/libutil/tests/libnixutil-tests.a: No such file or 
directory
collect2: error: ld returned 1 exit status
make[1]: *** [mk/lib.mk:120: src/libstore/tests/libnixstore-tests] Error 1
rm src/nix/doc/files/profiles.md
make[1]: Leaving directory '/<>'

Bug#1029007: [Pkg-rust-maintainers] Bug#1029007: Bug has reappeared

[Fabian Grünbichler]

On May 9, 2024 11:28:06 PM GMT+02:00, Joseph Carter 
 wrote:
>This bug should've been closed at some point in the past but has reappeared in 
>the newer version:
>
>cargo 1.70.0+dfsg2-1
>rustc 1.70.0+dfsg2-1
>. 
>rustc recommends cargo >= 0.71.0~~ and cargo < 0.72.0~~ … The expected 
>solution to the problem (merging of the cargo and rustc sources) has already 
>happened, so it seems that the thing needed now is some frobbing of substvars 
>for the contol file based on the package version? An = versioned recommends 
>based on the standard/automatic substvars? Exercise left to rust stakeholders 
>to discuss.

Well, that version was the one that causes cargo to have the same version as 
rustc :) I only updated the versioned relations afterwards in order to do it in 
one sweep:

https://salsa.debian.org/rust-team/rust/-/commit/8584fc73267962d11f94d7ed392b4e45bb71d039

https://salsa.debian.org/rust-team/rust/-/commit/92e11c7a6130f8ed313e4cec30b78a762e5d375b

1.71.1 which is currently in bin-NEW awaiting ftp masters review contains those 
changes and will close this bug ;)

Bug#908862: Closing this bug

[Santiago Vila]

fixed 908862 2:24.0.0-2
tags 908862 + bullseye bookworm
thanks

As I did with ceilometer, I'm fixing the metadata with this message.

Thanks.

Bug#908862: Closing this bug

[Santiago Vila]

El 10/5/24 a las 16:22, Thomas Goirand escribió:

After 5 years, I still have no clue on why Neutron couldn't build in your env. 
What I know for sure: I wouldn't build Neutron with only 8GB of RAM in a VM.

At this point, I don't see why this bug should stay open. Nobody is investing 
time on it, neither you, me or upstream. And nobody is able to re-trigger it 
but you, with not enough RAM, it seems.

Closing this bug then...

Feel free to reopen if you still think it should, but them please explain how 
it should be reproduced, and try with enough RAM. Note that stestr will spawn 
as many process as there's CPU, so the more VCPU you have, the more RAM you 
should provide too.


It seems fair to me that you close this bug.

I don't keep failed logs for neutron anymore, and I believe the reason is
that I changed my build setup recently.

Before, I was using directory-based chroots, with the "default" profile
and partition bindings defined in /etc/schroot/default/fstab.

Now I'm using file-based chroots, with the "sbuild" profile and partition
bindings defined in /etc/schroot/sbuild/fstab.

Now this bug is closed and I agree that it's better that it's closed.

However, please do not spread misinformation about the cause of the bug.

No, it was not lack of RAM. I knew it was not when I reported it, and this is
still true, as I have successful build logs with machines with 2 CPUs and 8 GB 
of RAM.

Moreover, neutron still fails in bullseye and bookworm here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html

Maybe you could ask reproducible-builds people to tell you how to reproduce it.

At least I gave you a machine to reproduce it, and you verified that the failure
happened indeed. If any of us had thought about changing the build setup
(in the same machine) maybe we could have discovered the reason at the time.

On the positive side, I think we were very close. If a similar bug happens and
you can reproduce it in a machine which I provide, I think the next logical step
should be to extend the VM offer to upstream.

Also on the positive side: If you can't reproduce any currently open bug 
reported
by Lucas Nussbaum, please contact me privately, I can provide a machine with the
exact specs he used for the build.

Thanks.

Bug#1070856: bookworm-pu: package riseup-vpn/0.21.11+ds1-5+deb12u1

[Nilesh Patra]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: riseup-...@packages.debian.org, nil...@debian.org
Control: affects -1 + src:riseup-vpn
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The bug got introduced due to a change in the external services that riseup-vpn
interacts with (riseup's servers) and failing to identify their letsencrypt 
certs.

Full details at Bug#1070270

[ Impact ]
The package is rendered unusable and the user will not be able to use riseup-vpn
and connect to the vpn.

[ Tests ]
Tried this on a fresh stable VM with multiple different angles.
This has also been tried on a stable user's machine and the problem is verified
to have been fixed.

[ Risks ]
This is a leaf package and the changes are fairly minimal. Very low risk to 
stable.

[ 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 ]
 Add patch to fixup client verification problems with
 riseup-vpn which renders the package useless otherwise.
 At the moment, the current code is unable to identify the
 letsencrypt certs. Used a systempool for the same and create
 a newcertpool as a fallback. Also added a Depends in d/control
 for ca-certificates for the same reason.

[ Other info ]
Since this is a leaf package and the breakage is due to external services, this 
may be a
candidate for stable-updates suite as per 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-the-stable-updates-suite

> Examples of circumstances in which the upload may qualify for such treatment 
> are:
> ...
> Uploads to stable-updates should target their suite name in the changelog as 
> usual, e.g. bookworm.

Since I was confident that this should be accepted, I did a (source-only) 
dput/upload.
diff -Nru riseup-vpn-0.21.11+ds1/debian/changelog 
riseup-vpn-0.21.11+ds1/debian/changelog
--- riseup-vpn-0.21.11+ds1/debian/changelog 2023-03-09 09:51:22.0 
+0530
+++ riseup-vpn-0.21.11+ds1/debian/changelog 2024-05-10 20:13:39.0 
+0530
@@ -1,3 +1,15 @@
+riseup-vpn (0.21.11+ds1-5+deb12u1) bookworm; urgency=medium
+
+  * Add patch to fixup client verification problems with
+riseup-vpn which renders the package useless otherwise.
+At the moment, the current code is unable to identify the
+letsencrypt certs. Used a systempool for the same and create
+a newcertpool as a fallback. Also added a Depends in d/control
+for ca-certificates for the same reason.
+(Closes: #1070270)
+
+ -- Nilesh Patra   Fri, 10 May 2024 20:13:39 +0530
+
 riseup-vpn (0.21.11+ds1-5) unstable; urgency=medium
 
   * Add procps, iproute2 and iptables to Depends (Closes: #1031905)
diff -Nru riseup-vpn-0.21.11+ds1/debian/control 
riseup-vpn-0.21.11+ds1/debian/control
--- riseup-vpn-0.21.11+ds1/debian/control   2023-03-09 09:51:22.0 
+0530
+++ riseup-vpn-0.21.11+ds1/debian/control   2024-05-10 20:13:39.0 
+0530
@@ -52,6 +52,7 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
+ ca-certificates,
  iproute2,
  iptables,
  pkexec,
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch 
riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
--- riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
1970-01-01 05:30:00.0 +0530
+++ riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
2024-05-10 20:13:39.0 +0530
@@ -0,0 +1,27 @@
+From 14cf64b10a97c29688f252a7d9d3481c8484aa1d Mon Sep 17 00:00:00 2001
+From: max b 
+Date: Wed, 8 Mar 2023 12:41:45 -0800
+Subject: [PATCH] Add system certs to bonafide
+
+lilypad/float is now using letsencrypt certs for vpnweb so instead of
+instantiating an empty cert pool, we can just use the system pool and
+then add the manually configured cert for backwards compatibility.
+---
+ pkg/vpn/bonafide/bonafide.go | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/pkg/vpn/bonafide/bonafide.go
 b/pkg/vpn/bonafide/bonafide.go
+@@ -94,7 +94,11 @@
+ 
+ // New Bonafide: Initializes a Bonafide object. By default, no Credentials 
are passed.
+ func New() *Bonafide {
+-  certs := x509.NewCertPool()
++  certs, err := x509.SystemCertPool()
++  if err != nil {
++  log.Println("Error loading SystemCertPool, falling back to 
empty pool")
++  certs = x509.NewCertPool()
++  }
+   certs.AppendCertsFromPEM(config.CaCert)
+   client := {
+   Transport: {
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/series 
riseup-vpn-0.21.11+ds1/debian/patches/series
--- riseup-vpn-0.21.11+ds1/debian/patches/series2023-02-26 
02:39:10.0 +0530
+++ riseup-vpn-0.21.11+ds1/debian/patches/series2024-05-10 
20:13:39.0 +0530
@@ -3,3 +3,4 @@
 

Bug#1070851: glib2.0: minor memory leak after fixing CVE-2024-34397

[Salvatore Bonaccorso]

Hi Simon,

On Fri, May 10, 2024 at 02:40:48PM +0100, Simon McVittie wrote:
> Source: glib2.0
> Version: 2.74.6-2+deb12u1
> Severity: minor
> Tags: patch fixed-upstream
> X-Debbugs-Cc: secur...@debian.org
> Control: found -1 2.79.0+git20240110~g38f5ba3c-1
> Control: found -1 2.66.8-1+deb11u2
> Control: fixed -1 2.80.2-1
> 
> While applying the CVE-2024-34397 fixes to glib2.0 in (old)stable,
> I backported an upstream bug fix from GLib 2.79.x to fix a possible
> use-after-free, which had gone undetected in older versions, but caused
> intermittent failures in the new test coverage that I added to reproduce
> CVE-2024-34397.
> 
> It turns out that this bug fix is not 100% correct, and causes a rare
> memory leak: if a program replaces a non-NULL message body with a different
> non-NULL message body, the first argument of the old message body is leaked.
> This has now been fixed upstream and will be in 2.80.3, and I backported
> the fix in 2.80.2-1 (uploaded to unstable today).
> 
> My current understanding is that this will not affect
> typical applications, and only applications that call
> g_dbus_connection_add_filter() and use it to edit incoming or outgoing
> messages in-place will normally be affected. This is not a common pattern,
> and the only real-world use I'm aware of is that stretch's gdm3 had a hack
> that used this to work around an incompatibility between jessie and stretch
> versions' D-Bus APIs during upgrade.
> 
> This is technically a regression in a security update, so I'm cc'ing
> the security team, but I imagine they will not want to update the DSA
> for this. My inclination is to wait for a few days to see whether
> there are any other regressions; if yes, take the opportunity to
> fix this leak at the same time; and otherwise, propose an upload to
> (old)stable-proposed-updates fixing the memory leak.

Right. If we can avoid doing another regression update since this
looks minor, and batch it instead in the point rleases that would be
preferable. Plan sounds good.

Regards,
Salvatore

Bug#1070855: RFH: opensnitch -- GNU/Linux interactive application firewall

[Petter Reinholdtsen]

Package: wnpp
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org

I used to sponsor the uploader of the opensnitch package, but for
several months now I have not been able to reach him.  This make me
suspect he is no longer around to maintain the package, and I believe
someone else need to take over.  There are new upstream releases
available that should be packaged for Debian.

The package is team maintained under the umbrella of the Debian Go
Packaging team, and its status can be seen in
https://tracker.debian.org/pkg/opensnitch >.

A short story on the usefulness of opensnitch is available from
https://people.skolelinux.org/pere/blog/What_did_I_learn_from_OpenSnitch_this_summer_.html
 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#882872: First stab at functionality for copying files

[Benj. Mako Hill]

Greetings!


> Your patch looks good to me and works as promised, thanks!  Before forwarding
> it to upstream, we need an appropriate update of vidir documentation.  Are you
> interested in preparing that?  (If not, I can do it.)

Sorry I lost track of this. Are we still waiting on documentation? If
so, I'm happy to do this so that this can land.

Regards,
Mako

-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Fri, 10 May 2024 at 15:49, Steve McIntyre  wrote:
>
> On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote:
> >On Fri, 10 May 2024 at 15:36, Steve McIntyre  wrote:
> >> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar  wrote:
> >>
> >> >Maybe we should use a non-trusted cert for the initial setup and only
> >> >switch to a proper cert once everything is confirmed to be working as
> >> >expected?
> >>
> >> Hmmm, maybe? Luca?
> >
> >What do you mean precisely here? A DSA-managed cert used by FTP to
> >sign but that doesn't chain to the Debian CA? Or to do something
> >completely local to the systemd-boot package?
>
> Exactly the former - we can use a test key for signing systemd-boot to
> start with. Once we're happy all round, we can switch to a cert in the
> chain.
>
> >I am fine with any approach that lets us move forward, if that needs
> >to be some intermediate testing stage that's fine by me.
>
> Cool.

Ok, sounds good to me, thanks.

DSA, now that FTP Team has acked with this suggestion to use a test
cert first, are you happy to proceed or is there anything else you
need from me? Thanks!

Bug#996202: EFI Secure Boot for systemd-boot

[Steve McIntyre]

On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote:
>On Fri, 10 May 2024 at 15:36, Steve McIntyre  wrote:
>> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar  wrote:
>>
>> >Maybe we should use a non-trusted cert for the initial setup and only
>> >switch to a proper cert once everything is confirmed to be working as
>> >expected?
>>
>> Hmmm, maybe? Luca?
>
>What do you mean precisely here? A DSA-managed cert used by FTP to
>sign but that doesn't chain to the Debian CA? Or to do something
>completely local to the systemd-boot package?

Exactly the former - we can use a test key for signing systemd-boot to
start with. Once we're happy all round, we can switch to a cert in the
chain.

>I am fine with any approach that lets us move forward, if that needs
>to be some intermediate testing stage that's fine by me.

Cool.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Fri, 10 May 2024 at 15:36, Steve McIntyre  wrote:
>
> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar  wrote:
> >Hi,
> >
> >On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote:
> >> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi 
> >> > On IRC Steve mentioned that he's ok with proceeding with this.
> >> > jcristau from DSA said that it's the FTP team that should confirm the 
> >> > request
> >> > for the new intermediate signer cert for systemd-boot to DSA.
> >> >
> >> > FTP team, are you ok with proceeding with this? If so, would it be
> >> > possible to have an ACK, please? Is there any more information required
> >> > beforehand?
> >
> >As long as the security boot people are fine with this, I think this
> >should be fine. (And AFAIU this seems to be the case.)
>
> Yes, I'm happy for us to add this. Please go ahead.
>
> >Maybe we should use a non-trusted cert for the initial setup and only
> >switch to a proper cert once everything is confirmed to be working as
> >expected?
>
> Hmmm, maybe? Luca?

What do you mean precisely here? A DSA-managed cert used by FTP to
sign but that doesn't chain to the Debian CA? Or to do something
completely local to the systemd-boot package?

I am fine with any approach that lets us move forward, if that needs
to be some intermediate testing stage that's fine by me.

Bug#996202: EFI Secure Boot for systemd-boot

[Steve McIntyre]

On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar  wrote:
>Hi,
>
>On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote:
>> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi 
>> > On IRC Steve mentioned that he's ok with proceeding with this.
>> > jcristau from DSA said that it's the FTP team that should confirm the 
>> > request
>> > for the new intermediate signer cert for systemd-boot to DSA.
>> > 
>> > FTP team, are you ok with proceeding with this? If so, would it be
>> > possible to have an ACK, please? Is there any more information required
>> > beforehand?
>
>As long as the security boot people are fine with this, I think this
>should be fine. (And AFAIU this seems to be the case.)

Yes, I'm happy for us to add this. Please go ahead.

>Maybe we should use a non-trusted cert for the initial setup and only
>switch to a proper cert once everything is confirmed to be working as
>expected?

Hmmm, maybe? Luca?

Also, while I'm thinking about things... We should probably also move
to a new kernel signing cert for unstable/testing now that we've moved
to build-time ephemeral keys for the modules. At some point in the
future that will let us DBX-block the old kernel signing
certificate(s) in a new shim build. Bastian: I'm assuming the
ephemeral change is only a thing in testing/unstable? Can we (easily)
use a different signer for different releases of the kernel here?

In fact, if we're going to generate new keys and certs for the
intermediate signers, it might be worth refreshing them all anyway
maybe?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Bug#996202: EFI Secure Boot for systemd-boot

[Ansgar ]

Hi,

On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote:
> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi 
> > On IRC Steve mentioned that he's ok with proceeding with this.
> > jcristau from DSA said that it's the FTP team that should confirm the 
> > request
> > for the new intermediate signer cert for systemd-boot to DSA.
> > 
> > FTP team, are you ok with proceeding with this? If so, would it be
> > possible to have an ACK, please? Is there any more information required
> > beforehand?

As long as the security boot people are fine with this, I think this
should be fine. (And AFAIU this seems to be the case.)

Maybe we should use a non-trusted cert for the initial setup and only
switch to a proper cert once everything is confirmed to be working as
expected?

Ansgar

Bug#963101: cozy-audiobook-player: "Request For Package"

[Andrey Rakhmatullin]

On Fri, May 10, 2024 at 01:47:29PM +, Manuel Traut wrote:
> Hi,
> 
> I am currently working on this package [0].
In that case please retitle this report to ITP and mark yourself as its
owner, as described at https://www.debian.org/devel/wnpp/#l3

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Nilesh Patra]

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

I got more extensive testing done. This definitely fixes the issue as it helps
verify the letsencrypt certificate.

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

OK, so now the time is up and I've got some spare time now - I am going ahead
with an upload. This look fine and the package works.

> > I would have attemped the update much sooner but unfortunately an update 
> > with
> > 0xacab's gitlab broke my d/watch file and I did not notice a new version is 
> > out
> > there sooner.
> > 
> > I was thinking to go ahead with an upload, but there are a few things that I
> > would like to clarify before I do so (btw thanks to the maintainers for
> > committing a patch to use with qt6.4):

To be clear: these questions do not apply to the stable update. Only to the
unstable one.

> > 1. Why is the default provider set to "provider = bitmask" in
> > providers/vendor.conf? This leads to building the binary called bitmask-vpn
> > instead of riseup-vpn. Is there a thought of changing the binary name?
> > 
> > In current stage it points to just dummy APIs and hence I overrode it in 
> > d/rules
> > to build riseup-vpn instead.

I am keeping this as is.

> > 2. In the vendor/gitlab.com/yawning/obfs4.git/ package, there are 3 license.
> > BSD-2-Clause, BSD-3-Clause and also GPL-3 for
> > vendor/gitlab.com/yawning/obfs4.git/internal/x25519ell2/x25519ell2.go - so 
> > what
> > exactly is the exact license? Is it redistributable under all the three? (I
> > don't think so?)

I found a comment from yawning and added the internal/* under GPL.

Going for an upload to unstable followed by an s-p-u.

> > [1]: 
> > https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/bookworm-pu?ref_type=heads
> > [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/
> > [3]: 
> > https://salsa.debian.org/go-team/packages/riseup-vpn/-/tree/debian/sid?ref_type=heads
> > [4]: https://people.debian.org/~nilesh/riseup-vpn-0.24.5/
[5]: https://gitlab.com/yawning/obfs4/-/issues/5

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done

[Vincent Lefevre]

On 2024-05-10 12:20:43 +0200, Diederik de Haas wrote:
> Control: severity -1 grave
> 
> On 07 May 2024 19:35:30 +0200 Nicolas Noirbent  wrote:
> > Package: how-can-i-help
> > Version: 18
> > Severity: important
> > Tags: patch
> > 
> > Running how-can-i-help outputs nothing past the initial banner, due to an
> > undefined variable:
> 
> Which makes the package unusable, so upgrading severity accordingly

More or less. I got the error after a bug listed at
"New bugs where assistance is requested":

New bugs where assistance is requested (tagged 'help'):
 - libglib2.0-dev - https://bugs.debian.org/1070773 - libglib2.0-dev:i386 on 
amd64 should not require qemu-user

/usr/bin/how-can-i-help:338:in `': undefined local variable or method 
`autorm_header_done' for main:Object (NameError)

autorm_header_done == 0
^^
Did you mean?  autorm_date

BTW, I hadn't got any error after 6 upgrades (not involving ruby) with
how-can-i-help 18, but now I get an error. It should probably have a
testsuite to be able to trigger issues under various conditions.

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

Bug#1070854: clc-intercal FTBFS: dpkg-genbuildinfo: error: binary build with no binary artifacts found

[Adrian Bunk]

Source: clc-intercal
Version: 1:1.00-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=clc-intercal=1%3A1.00-1

...
chmod +x `pwd`/debian/clc-intercal/usr/bin/*
 dpkg-genbuildinfo --build=any -O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo
dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
.buildinfo is meaningless
dpkg-buildpackage: error: dpkg-genbuildinfo --build=any 
-O../clc-intercal_1.00-1_ppc64el-buildd.buildinfo subprocess returned exit 
status 25

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi 
wrote:
> On Fri, 22 Mar 2024 18:13:35 + Luca Boccassi 
> wrote:
> > On Mon, 4 Mar 2024 at 23:58, Luca Boccassi 
wrote:
> > >
> > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre 
> wrote:
> > >
> > > > Modulo those questions, let's talk infrastructure. Off the top
of
> my
> > > > head, in no particular order...
> > > >
> > > >   * We'll need to create a new intermediate signing cert for
> > > > systemd-boot (and another for UKI, I guess). Given recent
> > > > discussions about changing the way we build and sign
kernels,
> we
> > > > should also generate a new signer cert for those too. And
if
> we're
> > > > going that far, we may as well generate a complete new set
of
> 2024
> > > > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA
> about
> > > > doing this piece.
> > >
> > > That makes sense to me, I guess DSA owns the machinery to do
this?
> > >
> > > >   * We'll probably need to add things to the signing setup for
> > > > ftp-master. Nothing earth-shattering, just some config to
> > > > recognise the new set of packages IIRC. I'm sure Bastian
can
> > > > manage this. :-)
> > > >
> > > >   * Are people from the team ready to deal with long-term
> security
> > > > support for the systemd-boot chain?
> > >
> > > Speaking for myself, yes, I am already part of the team who is
> > > responsible for that upstream, and I plan to be very strict about
> not
> > > carrying downstream patches for the signed components outside of
> > > security fixes (and even then, prefer upstream stable point
> releases
> > > that I am also responsible for anyway).
> > >
> > > > That's all I can think of for now, but I wouldn't be surprised
if
> more
> > > > comes to mind tomorrow... :-)
> > >
> > > Thanks for the feedback!
> > 
> > Gentle ping on this - what are the next steps in order to make this
> happen?
> 
> On IRC Steve mentioned that he's ok with proceeding with this.
jcristau
> from DSA said that it's the FTP team that should confirm the request
> for the new intermediate signer cert for systemd-boot to DSA.
> 
> FTP team, are you ok with proceeding with this? If so, would it be
> possible to have an ACK, please? Is there any more information
required
> beforehand?
> 
> Thanks!

Hello FTP Team,

One more gentle ping to unblock progress on this. TIA!

-- 
Kind regards,
Luca Boccassi


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

Bug#1070853: strace: test failures on 32bit with 64bit time_t

[Adrian Bunk]

Source: strace
Version: 6.8-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=strace=armhf=6.8-1=1715348223=0
https://buildd.debian.org/status/fetch.php?pkg=strace=armel=6.8-1=1715346678=0
https://buildd.debian.org/status/fetch.php?pkg=strace=powerpc=6.8-1=1715349316=0

...
FAIL: strace-k.test
PASS: umovestr_cached.test
FAIL: strace-k-with-depth-limit.test
FAIL: strace-k-demangle.test
PASS: strace-DD.test
FAIL: strace-k-p.test
PASS: strace--tips-full.test
PASS: qual_fault-syscall.test
PASS: qual_fault.test
PASS: filtering_syscall-syntax.test
PASS: looping_threads.test
==
   strace 6.8: tests/test-suite.log
==

# TOTAL: 1350
# PASS:  1057
# SKIP:  289
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0
...
FAIL: strace-k
==

+ ../src/strace -V
+ TIMEOUT=timeout -k 5 -s XCPU 1500
+ timeout -k 5 -s XCPU 1500 true
+ [ 1 -eq 0 ]
+ exec timeout -k 5 -s XCPU 1500 ../../tests/strace-k.test
+ : 0
+ : -k
+ : --stack-trace
+ : 
+ [ -f /proc/self/maps ]
+ check_prog grep
+ type grep
+ check_prog readlink
+ type readlink
+ check_prog sed
+ type sed
+ check_prog tr
+ type tr
+ command -v sed
+ path_to_sed=/usr/bin/sed
+ [ -x /usr/bin/sed ]
+ readlink -ev -- /usr/bin/sed
+ path_to_sed=/usr/bin/sed
+ /usr/bin/sed -n s/^[^/]\+[[:space:]]\(\/.*\)$/\1/p /proc/self/maps
+ grep -F -x -e /usr/bin/sed
+ run_prog ../stack-fcall
+ [ 1 -eq 0 ]
+ args=../stack-fcall
+ ../stack-fcall
+ [ x0 = x1 ]
+ run_strace -e chdir -k ../stack-fcall
+ 
+ args=-e chdir -k ../stack-fcall
+ ../../src/strace -o log -e chdir -k ../stack-fcall
+ expected=../../../tests/strace-k.expected
+ awk_script_common=
/^[^ ]/ {
if (out != "")
print out

syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1)
signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1)

if (syscall != $0) {
out = syscall
stop = 0
} else if (signal != $0) {
out = signal
stop = 0
} else {
out = ""
}
}

/^ > too many stack frames/ {
out = out " _too_many_stack_frames_"
stop = 1
}


+ awk_script_symbol=
/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop {
sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1)
out = out " " sym
if (sym == "main")
stop = 1
}


+ awk_script_source=
/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] ([^:]+):([0-9]+)$/ && !stop {
sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1)
if (sym == "main" || sym ~ /f[0-9]/) {
file = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] 
([^:]+):([0-9]+)$/, "\\2", 1)
line = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) \[0x[a-f0-9]+\] 
([^:]+):([0-9]+)$/, "\\3", 1)
sub(".*/", "", file)
out = out " " sym "<" file ":" line ">"
if (sym == "main")
stop = 1
}
}


+ [ --stack-trace = --stack-trace ]
+ awk_script=
/^[^ ]/ {
if (out != "")
print out

syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1)
signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1)

if (syscall != $0) {
out = syscall
stop = 0
} else if (signal != $0) {
out = signal
stop = 0
} else {
out = ""
}
}

/^ > too many stack frames/ {
out = out " _too_many_stack_frames_"
stop = 1
}


/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop {
sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1)
out = out " " sym
if (sym == "main")
stop = 1
}


+ awk 
/^[^ ]/ {
if (out != "")
print out

syscall = gensub(/^([[:alnum:]_]+)\(.*/, "\\1", 1)
signal = gensub(/^--- ([A-Z]+) .*/, "\\1", 1)

if (syscall != $0) {
out = syscall
stop = 0
} else if (signal != $0) {
out = signal
stop = 0
} else {
out = ""
}
}

/^ > too many stack frames/ {
out = out " _too_many_stack_frames_"
stop = 1
}


/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) / && !stop {
sym = gensub(/^ >[^(]+\(([^+]+)\+0x[a-f0-9]+\) .*$/, "\\1", 1)
out = out " " sym
if (sym == "main")
stop = 1
}

 log
+ LC_ALL=C grep -E -x -f ../../../tests/strace-k.expected
+ cat ../../../tests/strace-k.expected
+ cat out
+ cat
Failed pattern of expected output:
^chdir (__kernel_vsyscall )?(__)?chdir f3 f2 f1 f0 main
^SIGURG (__kernel_vsyscall )?(__)?kill f3 f2 f1 f0 main
Actual output:
chdir chdir f3
SIGURG kill f3
+ pattern=
+ pattern=No DWARF information found
+ [ -n No DWARF information found ]
+ LC_ALL=C grep -x  > No DWARF information found
+ dump_log_and_fail_with ../../src/strace -e chdir -k ../stack-fcall 

Bug#1070852: transition: gdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gdal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html

For the Debian GIS team I'd like to transition to GDAL 3.8.0.

All reverse dependencies except python-django and facet-analyser rebuilt 
successfully with GDAL 3.9.0 from experimental as summarized below.


python-django (3:4.2.11-1) FTBFS due to unrelated test failures. (#1042637)

facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to uninstallable 
build dependencies. (#1040334)


Bugreports can be found using the gdal-3.9 usertag:

 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.9


Transition: gdal

 libgdal34t64 (3.8.5+dfsg-1) -> libgdal35 (3.9.0~beta1+dfsg-1~exp1)

The status of the most recent rebuilds is as follows.

 cloudcompare(2.11.3-7.1)  OK
 fiona   (1.9.6-1) OK
 gmt (6.5.0+dfsg-3)OK
 grass   (8.3.2-1) OK
 libcitygml  (2.5.2-1) OK
 libgeo-gdal-ffi-perl(0.11-2)  OK
 libosmium   (2.20.0-1)OK
 mapcache(1.14.0-4)OK
 mapnik  (3.1.0+ds-7)  OK
 mapproxy(2.0.2+dfsg-1)OK
 mapserver   (8.0.1-4) OK
 merkaartor  (0.19.0+ds-5) OK
 mysql-workbench (8.0.32+dfsg-2)   OK
 ncl (6.6.2.dfsg.1-7)  OK
 octave-mapping  (1.4.2-3) OK
 openorienteering-mapper (0.9.5-3.1)   OK
 openscenegraph  (3.6.5+dfsg1-8)   OK
 paraview(5.11.2+dfsg-6)   OK
 pgsql-ogr-fdw   (1.1.4-3) OK
 pktools (2.6.7.6+ds-6)OK
 postgis (3.4.2+dfsg-1)OK
 python-django   (3:4.2.11-1)  FTBFS (#1042637)
 qmapshack   (1.17.1-1)OK
 r-cran-sf   (1.0-15+dfsg-1)   OK
 r-cran-terra(1.7-65-1)OK
 rasterio(1.3.10-2)OK
 saga(9.4.0+dfsg-1)OK
 vtk9(9.1.0+really9.1.0+dfsg2-7.1) OK

 facet-analyser  (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334)
 libgdal-grass   (1:1.0.2-7)   OK
 opencv  (4.6.0+dfsg-13.1) OK
 osmcoastline(2.4.0-2) OK
 qgis(3.34.6+dfsg-1)   OK
 sumo(1.18.0+dfsg-3)   OK


Kind Regards,

Bas

Bug#963101: cozy-audiobook-player: "Request For Package"

[Manuel Traut]

Hi,

I am currently working on this package [0].

I would need a sponsor to review and upload the package.

Thanks
Manuel

[0] https://salsa.debian.org/manut/cozy

Bug#1070748: gqrx-sdr: it does not start

[Renzo Davoli]

It was just a temporary misalignment during packages updates.

Now it works.

Please close/delete this bug report.

Thank you, Sorry

renzo

On Wed, May 08, 2024 at 01:48:00PM +0200, Renzo Davoli wrote:
> Package: gqrx-sdr
> Version: 2.17.5-1+b1
> Severity: important
> X-Debbugs-Cc: re...@cs.unibo.it
> 
> Dear Maintainer,
> 
> * What led up to the situation?
>   update to  2.17.5-1
> * What exactly did you do (or not do) that was effective (or ineffective)?
>   I just tried to run it
> * What was the outcome of this action?
>   It returns the following error:
>   
>   terminate called after throwing an instance of 'std::runtime_error'
>   what():  rpcmanager: Aggregator not in use, and a rpc booter is already 
> registered
>   Aborted
> 
> thank yoy,
>renzo

Bug#1070851: glib2.0: minor memory leak after fixing CVE-2024-34397

[Simon McVittie]

Source: glib2.0
Version: 2.74.6-2+deb12u1
Severity: minor
Tags: patch fixed-upstream
X-Debbugs-Cc: secur...@debian.org
Control: found -1 2.79.0+git20240110~g38f5ba3c-1
Control: found -1 2.66.8-1+deb11u2
Control: fixed -1 2.80.2-1

While applying the CVE-2024-34397 fixes to glib2.0 in (old)stable,
I backported an upstream bug fix from GLib 2.79.x to fix a possible
use-after-free, which had gone undetected in older versions, but caused
intermittent failures in the new test coverage that I added to reproduce
CVE-2024-34397.

It turns out that this bug fix is not 100% correct, and causes a rare
memory leak: if a program replaces a non-NULL message body with a different
non-NULL message body, the first argument of the old message body is leaked.
This has now been fixed upstream and will be in 2.80.3, and I backported
the fix in 2.80.2-1 (uploaded to unstable today).

My current understanding is that this will not affect
typical applications, and only applications that call
g_dbus_connection_add_filter() and use it to edit incoming or outgoing
messages in-place will normally be affected. This is not a common pattern,
and the only real-world use I'm aware of is that stretch's gdm3 had a hack
that used this to work around an incompatibility between jessie and stretch
versions' D-Bus APIs during upgrade.

This is technically a regression in a security update, so I'm cc'ing
the security team, but I imagine they will not want to update the DSA
for this. My inclination is to wait for a few days to see whether
there are any other regressions; if yes, take the opportunity to
fix this leak at the same time; and otherwise, propose an upload to
(old)stable-proposed-updates fixing the memory leak.

smcv
>From 8966099e9bef3fd3481f87bb7ad933f5cacad885 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marco=20Trevisan=20=28Trevi=C3=B1o=29?= 
Date: Wed, 8 May 2024 22:53:51 +0200
Subject: [PATCH] gdbusmessage: Clean the cached arg0 when setting the message
 body

We're now caching arg0 but such value is not cleared when a new body is
set as it's in the connection filter test cases where we've a leak as
highlighted by both valgrind and leak sanitizer
---
 gio/gdbusmessage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gio/gdbusmessage.c b/gio/gdbusmessage.c
index 0b77dc607..331e68d45 100644
--- a/gio/gdbusmessage.c
+++ b/gio/gdbusmessage.c
@@ -1155,10 +1155,12 @@ g_dbus_message_set_body (GDBusMessage  *message,
 
   if (message->body != NULL)
 g_variant_unref (message->body);
+
+  g_clear_pointer (>arg0_cache, g_variant_unref);
+
   if (body == NULL)
 {
   message->body = NULL;
-  message->arg0_cache = NULL;
   g_dbus_message_set_signature (message, NULL);
 }
   else
@@ -1172,8 +1174,6 @@ g_dbus_message_set_body (GDBusMessage  *message,
   if (g_variant_is_of_type (message->body, G_VARIANT_TYPE_TUPLE) &&
   g_variant_n_children (message->body) > 0)
 message->arg0_cache = g_variant_get_child_value (message->body, 0);
-  else
-message->arg0_cache = NULL;
 
   type_string = g_variant_get_type_string (body);
   type_string_len = strlen (type_string);
-- 
2.39.2

Bug#1063358: c-blosc2 tests fail with bus errors on armhf

[Antonio Valentino]

Thanks Graham

On Fri, 10 May 2024 13:14:41 + Graham Inggs  wrote:

Control: tags -1 + patch fixed-upstream

This was fixed in Ubuntu and the patch forwarded upstream;

https://github.com/Blosc/c-blosc2/pull/588




I will back port the patch immediately

cheers
--
Antonio Valentino

Bug#1063358: c-blosc2 tests fail with bus errors on armhf

[Graham Inggs]

Control: tags -1 + patch fixed-upstream

This was fixed in Ubuntu and the patch forwarded upstream;

https://github.com/Blosc/c-blosc2/pull/588

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Hi Roland,

On Fri, May 10, 2024 at 11:18:17AM +0200, Roland Rosenfeld wrote:
> Control: fixed -1 6.1.90+1
> 
> In the meantime I upgraded to linux-image-6.1.0-21-amd64 (6.1.90+1).
> With this version the issue is solved for me.

Thanks for confirming. I in fact missed to add the bug closer for this
in the changelog once the upstream patch got indeed backported as well
to the 6.1.y series.

Regards,
Salvatore

Bug#1070850: cfengine3: missing build-depends on passwd, needed for usermod

[Aurelien Jarno]

Source: cfengine3
Version: 3.21.4-1.1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

cfengine3 fails to build from source on riscv64, here is the relevant
part of the log:

| checking for useradd... no
| checking for usermod... no
| checking for userdel... no

...

| /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  
-I./../libpromises -I./../libntech/libutils -I./../libcfnet -I./../cf-check 
-Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99   -I/usr/include/libxml2   
-Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -Wall 
-Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 
-DNDEBUG -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security   -I/usr/include/libxml2   -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -Wall 
-Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 
-DNDEBUG -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o verify_users_pam.lo verify_users_pam.c
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./../libpromises 
-I./../libntech/libutils -I./../libcfnet -I./../cf-check -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu99 -I/usr/include/libxml2 -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g -Wall -Wno-pointer-sign 
-Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-I/usr/include/libxml2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g -Wall -Wno-pointer-sign 
-Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c verify_users_pam.c 
 -fPIC -DPIC -o .libs/verify_users_pam.o
| verify_users_pam.c: In function ‘SetAccountLockExpiration’:
| verify_users_pam.c:850:50: warning: unused parameter ‘puser’ 
[-Wunused-parameter]
|   850 | static bool SetAccountLockExpiration(const char *puser, bool lock)
|   |  ^
| verify_users_pam.c:850:62: warning: unused parameter ‘lock’ 
[-Wunused-parameter]
|   850 | static bool SetAccountLockExpiration(const char *puser, bool lock)
|   |  ^
| verify_users_pam.c: In function ‘DoCreateUser’:
| verify_users_pam.c:1565:38: warning: unused parameter ‘puser’ 
[-Wunused-parameter]
|  1565 | static bool DoCreateUser(const char *puser, const User *u, enum 
cfopaction action,
|   |  ^
| verify_users_pam.c:1565:57: warning: unused parameter ‘u’ [-Wunused-parameter]
|  1565 | static bool DoCreateUser(const char *puser, const User *u, enum 
cfopaction action,
|   | ^
| verify_users_pam.c:1565:76: warning: unused parameter ‘action’ 
[-Wunused-parameter]
|  1565 | static bool DoCreateUser(const char *puser, const User *u, enum 
cfopaction action,
|   |
^~
| verify_users_pam.c:1566:39: warning: unused parameter ‘ctx’ 
[-Wunused-parameter]
|  1566 |  EvalContext *ctx, const Attributes *a, const 
Promise *pp)
|   |  ~^~~
| verify_users_pam.c:1566:62: warning: unused parameter ‘a’ [-Wunused-parameter]
|  1566 |  EvalContext *ctx, const Attributes *a, const 
Promise *pp)
|   |~~^
| verify_users_pam.c:1566:80: warning: unused parameter ‘pp’ 
[-Wunused-parameter]
|  1566 |  EvalContext *ctx, const Attributes *a, const 
Promise *pp)
|   | 
~~~^~
| verify_users_pam.c: In function ‘DoRemoveUser’:
| verify_users_pam.c:1619:62: warning: unused parameter ‘action’ 
[-Wunused-parameter]
|  1619 | static bool DoRemoveUser (const char *puser, enum cfopaction action)
|   |  ^~
| verify_users_pam.c: In function ‘DoModifyUser’:
| verify_users_pam.c:1642:18: error: ‘USERMOD’ undeclared (first use in this 
function)
|  1642 | strcpy 

Bug#1070849: onetbb: FTBFS: Fix testcases failed on loong64

[zhangdandan]

Source: onetbb
Version: 2021.11.0-2
Severity: normal
Tags: FTBFS patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the onetbb failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
99% tests passed, 1 tests failed out of 137

Total Test time (real) = 233.63 sec

The following tests FAILED:
    133 - test_malloc_whitebox (Failed)
Errors while running CTest
FAILED: CMakeFiles/test.util
```
The full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=onetbb=2021.11.0-2=loong64.


For loongarch64, the size of the huge page I got from /proc/meminfo is 
32768 kB.

```
$ cat /proc/meminfo |grep Hugepagesize
Hugepagesize:  32768 kB
$ uname -m
loongarch64
```

I have adjusted the page size of HUGE_PAGE_SIZE for loongarch64 in 
onetbb package.

I have built successfully on my local ENV and test cases passed.
```
137/137 Test #137: test_malloc_new_handler .. Passed    
0.04 sec

100% tests passed, 0 tests failed out of 137
Total Test time (real) = 332.60 sec
```

The pull request for loongarch64 has been merged in onetbb upstream.
https://github.com/oneapi-src/oneTBB/pull/850/files.
https://github.com/oneapi-src/oneTBB/pull/1230/files.

Meanwhile, you can also consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

Description: Adjust HUGE_PAGE_SIZE size for loongarch64 
Last-Update: 2024-05-10

--- onetbb-2021.11.0.orig/src/tbbmalloc/tbbmalloc_internal.h
+++ onetbb-2021.11.0/src/tbbmalloc/tbbmalloc_internal.h
@@ -102,7 +102,11 @@ void suppress_unused_warning( const T& )
 /*
  * Default huge page size
  */
+#if defined __loongarch64
+static const size_t HUGE_PAGE_SIZE = 32 * 1024 * 1024;
+#else
 static const size_t HUGE_PAGE_SIZE = 2 * 1024 * 1024;
+#endif
 
 /** End of global default constants */
 
--- onetbb-2021.11.0.orig/test/tbbmalloc/test_malloc_whitebox.cpp
+++ onetbb-2021.11.0/test/tbbmalloc/test_malloc_whitebox.cpp
@@ -1257,7 +1257,11 @@ void TestTHP() {
 scalable_allocation_mode(USE_HUGE_PAGES, 1);
 REQUIRE_MESSAGE(hugePages.isEnabled, "Huge pages should be enabled via scalable_allocation_mode");
 
+#if defined __loongarch64
+const int HUGE_PAGE_SIZE = 32 * 1024 * 1024;
+#else
 const int HUGE_PAGE_SIZE = 2 * 1024 * 1024;
+#endif
 
 // allocCount transparent huge pages should be allocated
 const int allocCount = 10;

Bug#1070848: please package version 1.21 (needed for samba ad-dc functionality)

[Michael Tokarev]

Source: krb5
Severity: wishlist
X-Debbugs-Cc: pkg-samba-ma...@lists.alioth.debian.org

Please update krb5 packages to version 1.21 (currently 1.21.2 is available).

This is a minimum required version for Samba AD-DC functionality when built
with MIT-KRB5 implementation.

Thanks,

/mjt

Bug#983227: coz-profiler: drop unused Build-Depends

[Helmut Grohne]

Hi Petter,

On Thu, May 09, 2024 at 11:07:20AM +0200, Petter Reinholdtsen wrote:
> The reason it have these build dependencies, is to make sure the package
> only build on architectures where it will actually work, to avoid
> earning a release critical bug of providing binaries that do not work.
> 
> I am thus very reluctant to drop build dependencies also needed at
> runtime.

Your reasoning on this is sound to me. Would you mind adding comments to
debian/control documenting this non-obvious aspect such that the next
time someone looks for technically unused dependencies they see why
they're there?

>From my pov, please close this bug when documenting their need.

Helmut

Bug#1070840: r-cran-ff: autopkgtest regression with r-base 4.4.0

[Dirk Eddelbuettel]

On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
| 
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel 
| | User: debian...@lists.debian.org
| | Usertags: regression
| | 
| | Hi Maintainer
| | 
| | r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1].
| | I've copied what I hope is the relevant part of the log below.
| 
| FYI, I am not the maintainer of r-cran-ff.
| 
| The package is perfectly clean at CRAN on all hardware-os combinations,
| including amd64 so maybe the maintainer needs to turn this test off:
| 
|https://cloud.r-project.org/web/checks/check_results_ff.html

Also, for what it is worth, installing r-cran-ff and its one dependency in a
container along with r-cran-testthat and its twenty (ick!), and then running
'bash run-unit-test' leads to no issue:

   [ FAIL 0 | WARN 52 | SKIP 0 | PASS 966 ]

Maybe something for the package maintainer to consider.

Dirk

| 
| Dirk
|  
| | Regards
| | Graham
| | 
| | 
| | [1] https://ci.debian.net/packages/r/r-cran-ff/testing/amd64/
| | 
| | 
| | 42s ══ Failed tests
| | 
| | 42s ── Failure ('test-zero_lengths.R:34:3'): file size is correct when
| | creating ff integer from scratch ──
| | 42s file.exists(f1) is not TRUE
| | 42s
| | 42s `actual`: FALSE
| | 42s `expected`: TRUE
| | 42s
| | 42s [ FAIL 1 | WARN 52 | SKIP 0 | PASS 965 ]
| | 42s Error: Test failures
| | 42s Execution halted
| 
| -- 
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070837: gnome-shell: Last Gnome-Shell upgrade crashes logged session

[Simon McVittie]

Control: tags -1 + moreinfo

On Fri, 10 May 2024 at 12:08:27 +0200, Julien Negros wrote:
> In Bookworm last gnome-shell upgrade 43.9-0+deb12u1 -> 43.9-0+deb12u2
> closes current logged session. Same issue with Bullseye
> (3.38.6-1~deb11u1 -> 3.38.6-1~deb11u2). Doesn't look like an actual
> crash in logs : [...] But rather a GDM restart.

I did not experience this when upgrading several bookworm GNOME machines,
and one bullseye virtual machine. My GNOME session continued to run until
I rebooted the machine manually.

In general I would recommend rebooting the system anyway after installing
security updates in core library packages like libglib2.0-0, otherwise
running programs and sessions will remain vulnerable.

Are you sure you were not using some tool like checkrestart or needrestart
that detected gdm3 as a service that was affected by the security-fixed
versions of libglib2.0-0, and offered to restart it for you?

In needrestart's default configuration, it will default to not
restarting gdm3 and other known display managers (this is set up in
$nrconf{override_rc}, in /etc/needrestart/needrestart.conf), but if they
are explicitly selected to be restarted, it will assume you are aware of
the consequences and do as you ask.

I don't know whether checkrestart has similar mechanisms.

If you *do* restart gdm3, then it is probably expected that active GUI
sessions managed by gdm3 will be terminated - that's why needrestart avoids
doing this by default.

smcv

Bug#1070847: ptp4l systemd-service starts before hardware is fully up

[Michael Byczkowski]

Package: linuxptp
Version: 4.2-1

When (re-)booting the system the dependencies of ptp4l@.service (and 
phc2sys@.service) do not seem to be sufficient as the hardware (in this case 
eth0) is not up and running when those services are started, leading to a fail 
in SIOCSHWTSTAMP when using phc2sys -a -rr in phc2sys@.service

ptp4l[540]: [2.126] driver rejected most general HWTSTAMP filter
ptp4l[540]: [2.126] ioctl SIOCSHWTSTAMP failed: Invalid argument
ptp4l[540]: [2.138] port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED 
(FT_UNSPECIFIED)
ptp4l[540]: [2.138] port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[540]: [2.138] port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on 
INIT_COMPLETE
ptp4l[538]: [2.142] ioctl SIOCETHTOOL failed: No such device
ptp4l[538]: [2.156] ioctl SIOCETHTOOL failed: No such device
ptp4l[538]: failed to create a clock
ptp4l[538]: [2.156] PTP device not specified and automatic determination is not 
supported. Please specify PTP device.

Debian 12 (bookworm) with linuxptp 4.2-1

Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 
962bf483c8f326405794827cce8c0313fd5880a8, stage4

2024/04/20 11:53:30 
Copyright (c) 2012 Broadcom
version d1744d21 (release) (embedded)

Linux aion 6.9.0-rc6-v8-16k-NTP+ #9 SMP Thu May  9 14:05:10 CEST 2024 aarch64 
GNU/Linux

Bug#1070844: librust-hyper-rustls-dev: reenable webpki-tokio feature

[Jonas Smedegaard]

Control: tag -1 wontfix

Quoting Maytham Alsudany (2024-05-10 13:18:53)
> The 2001_webpki-roots.patch should be removed as rust-webpki-roots is
> now packaged in Debian, and rust-octocrab fails to build as it cannot
> find the webpki-tokio feature.

I recommend to instead investigate if rust-octocrab can be patched to
not rely on rust-webpki-roots, due to the very purpose of that crate
working against long-term maintained code (see bug#1069946).

Tagging this as wontfix, as it is not sensible for destabilize more
packages.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1031056: Could not reproduce in *trixie*

[Santiago Vila]

fixed 1031056 1:22.0.0-1
tags 1031056 + bookworm
thanks

El 9/5/24 a las 14:05, Thomas Goirand escribió:

I tried rebuilding 3 times ceilometer with 1 CPU (with nr_cpu=1 in grub) in a 
virtual machine, and I couldn't reproduce. Note that it has run unit tests 
twice on each run, with python 3.11 and 3.12, so effectively, I tried 6 times...


Thanks for checking. I see that you skipped bookworm in your tests, which is 
what I reported at the time.

So I went ahead and checked the build in bullseye, bookworm and trixie again, 
using single-cpu systems
of several flavors. This is what I got so far (numbers show failures/tries).

bullseye 0/18
bookworm 17/32
trixie 0/32

I could do more tests than that, but with the above data I think it's fair to 
say that the
problem I reported (FTBFS randomly in bookworm) is not fixed yet.


It's possible that the latest eventlet fixed it. Please try to reproduce this 
bug again, and re-open the bug if you feel like it's still not fixed.


Unfortunately, I can't do that because it's against the rules of version 
tracking.

What I can do is to adjust the metadata to reflect reality, at least that way
we document clearly and faithfully what's going on.

I'm afraid that this might remain unfixed in bookworm forever, even if it 
happens the
currently supported stable distribution.

I understand that you are busy and have to prioritize.

Considering that the bug happens randomly and it may be avoided using nocheck,
I could agree that there are other FTBFS bugs which require more attention.

For example, I would be interested to know your plans regarding python-pycdlib.
I still think that one should be fixed in bookworm and trixie, because
build-essential does not imply that /tmp is in tmpfs. (Please reply in 
#1002789).

Thanks.

Bug#1070846: ITP: smatch -- a static analysis tool for C

[Ricardo B. Marliere]

Package: wnpp
Severity: wishlist
Owner: "Ricardo B. Marliere" 
X-Debbugs-Cc: debian-de...@lists.debian.org, dan.carpen...@linaro.org, 
rica...@marliere.net

* Package name: smatch
  Version : 1.73
  Upstream Contact: sma...@vger.kernel.org
* URL : https://smatch.sourceforge.net/
* License : GPLv2+
  Programming Lang: C
  Description : a static analysis tool for C

Smatch is a code checking framework developed by Dan Carpenter on top of
Sparse [1]. It extends Sparse with useful functionality in the scope of
the Linux Kernel such as data-flow analysis which makes it possible to
detect such things as conditions that will always (or never) be true,
pointers that might be null, and locks that end up in different states
depending on which path is taken through the code [2]. A good
introduction was written by Dan himself [3] and he also had a mentorship
session about it [4], which goes in detail about its usefulness.

[1] https://tracker.debian.org/pkg/sparse
[2] https://lwn.net/Articles/691882/
[3] 
https://blogs.oracle.com/linux/post/smatch-static-analysis-tol-overview-by-dan-carpenter
[4] https://events.linuxfoundation.org/mentorship-session-smatch/

Bug#1070842: r-bioc-mutationalpatterns: autopkgtest regression with r-base 4.4.0

[Dirk Eddelbuettel]

On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel 
| User: debian...@lists.debian.org
| Usertags: regression
| 
| Hi Maintainer
| 
| r-bioc-mutationalpatterns' autopkgtest regresses when tested with r-base 4.4.0
| [1].  I've copied what I hope is the relevant part of the log below.

FYI, I am not the maintainer of r-bioc-mutationalpatterns.

As you likely know, BioConductor aligns its releases with R releases and is
now at release 3.19 (matching R 4.4.0) for which this package is now at
version 3.14.0.

I suggest the maintainer look into upgrading BioConductor to 3.19.

Dirk

| 
| Regards
| Graham
| 
| 
| [1] https://ci.debian.net/packages/r/r-bioc-mutationalpatterns/testing/amd64/
| 
| 
| 125s > test_check("MutationalPatterns")
| 172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
| 172s
| 172s ══ Failed tests
| 
| 172s ── Error ('test-fit_to_signatures_bootstrapped.R:12:3'): Output
| has correct class ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
| test-fit_to_signatures_bootstrapped.R:12:3
| 172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
| 172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 6. │ ├─S4Vectors::isEmpty(sims)
| 172s 7. │ └─S4Vectors::isEmpty(sims)
| 172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 11. └─base::unlist(.)
| 172s ── Error ('test-fit_to_signatures_bootstrapped.R:31:3'): Output
| is equal to expected ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
| test-fit_to_signatures_bootstrapped.R:31:3
| 172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
| 172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 6. │ ├─S4Vectors::isEmpty(sims)
| 172s 7. │ └─S4Vectors::isEmpty(sims)
| 172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 11. └─base::unlist(.)
| 172s ── Error ('test-fit_to_signatures_strict.R:11:1'): (code run
| outside of `test_that()`) ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_strict(...) at
| test-fit_to_signatures_strict.R:11:1
| 172s 2. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 3. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 4. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 5. │ ├─S4Vectors::isEmpty(sims)
| 172s 6. │ └─S4Vectors::isEmpty(sims)
| 172s 7. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 8. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 9. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. └─base::unlist(.)
| 172s
| 172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
| 173s Error: Test failures
| 173s Execution halted

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070843: r-bioc-s4vectors: autopkgtest regression with r-base 4.4.0

[Dirk Eddelbuettel]

On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel 
| User: debian...@lists.debian.org
| Usertags: regression
| 
| Hi Maintainer
| 
| r-bioc-s4vectors' autopkgtest regresses when tested with r-base 4.4.0
| [1].  I've copied what I hope is the relevant part of the log below.

FYI, I am not the maintainer of r-bioc-s4vectors.

As you likely know, BioConductor aligns its releases with R releases and is
now at release 3.19 (matching R 4.4.0) for which this package is now at
version 0.42.0.

I suggest the maintainer look into upgrading BioConductor to 3.19.

Dirk

| 
| Regards
| Graham
| 
| 
| [1] https://ci.debian.net/packages/r/r-bioc-s4vectors/testing/amd64/
| 
| 
| 125s > S4Vectors:::.test()
| 129s Timing stopped at: 0.009 0 0.009
| 129s Error in var(x) : is.atomic(y) is not TRUE
| 129s In addition: Warning messages:
| 129s 1: In combineUniqueCols(X, Y, Z, use.names = FALSE) :
| 129s different values in multiple instances of column 'dup', ignoring this
| 129s column in DFrame 2
| 129s 2: In combineUniqueCols(X, Y, Z) :
| 129s different values for shared rows in multiple instances of column 'dup',
| 129s ignoring this column in DFrame 2
| 129s 3: In combineUniqueCols(x, y2) :
| 129s different values for shared rows in multiple instances of column 'X',
| 129s ignoring this column in DFrame 2
| 130s Loading required package: GenomeInfoDb
| 132s
| 132s
| 132s RUNIT TEST PROTOCOL -- Thu May 9 22:12:10 2024
| 132s ***
| 132s Number of test functions: 74
| 132s Number of errors: 1
| 132s Number of failures: 0
| 132s
| 132s
| 132s 1 Test Suite :
| 132s S4Vectors RUnit Tests - 74 test functions, 1 error, 0 failures
| 132s ERROR in test_Rle_numerical: Error in var(x) : is.atomic(y) is not TRUE
| 132s
| 132s Test files with failing tests
| 132s
| 132s test_Rle-utils.R
| 132s test_Rle_numerical
| 132s
| 132s
| 132s Error in BiocGenerics:::testPackage("S4Vectors") :
| 132s unit tests failed for package S4Vectors
| 132s Calls:  -> 
| 132s Execution halted

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070841: r-bioc-iranges: autopkgtest regression with r-base 4.4.0

[Dirk Eddelbuettel]

On 10 May 2024 at 10:58, Graham Inggs wrote:
| Source: r-bioc-iranges
| Version: 2.36.0-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel 
| User: debian...@lists.debian.org
| Usertags: regression
| 
| Hi Maintainer
| 
| r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
| [1].  I've copied what I hope is the relevant part of the log below.

FYI, I am not the maintainer of r-bioc-iranges.

As you likely know, BioConductor aligns releases with R releases at is now at
release 3.19 for which this package is at version 2.38.0. I suggest the
maintainer look into upgrading BioConductor to 3.19.

Dirk

| 
| Regards
| Graham
| 
| 
| [1] https://ci.debian.net/packages/r/r-bioc-iranges/testing/amd64/
| 
| 
| 194s ***
| 194s Number of test functions: 98
| 194s Number of errors: 1
| 194s Number of failures: 0
| 194s
| 194s
| 194s 1 Test Suite :
| 194s IRanges RUnit Tests - 98 test functions, 1 error, 0 failures
| 194s ERROR in test_AtomicList_numerical: Error in FUN(X[[i]], ...) :
| is.atomic(y) is not TRUE
| 194s
| 194s Test files with failing tests
| 194s
| 194s test_AtomicList-utils.R
| 194s test_AtomicList_numerical
| 194s
| 194s
| 194s Warning messages:
| 194s 1: In recycleListElements(e1, en) :
| 194s Some element lengths are not multiples of their corresponding
| element length in e1
| 194s 2: In x + y :
| 194s longer object length is not a multiple of shorter object length
| 194s 3: In recycleListElements(e1, en) :
| 194s Some element lengths are not multiples of their corresponding
| element length in e1
| 194s 4: In x + y :
| 194s longer object length is not a multiple of shorter object length
| 194s Execution halted

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070845: godot: Update to newest upstream version?

[Petter Reinholdtsen]

Package: godot3
Version: 3.5.2-stable-2
Severity: wishlist

There is a new upstream version 4.2.2-stable available.  Please update
godot in Debian to the newest upstream version.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070840: r-cran-ff: autopkgtest regression with r-base 4.4.0

[Dirk Eddelbuettel]

On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel 
| User: debian...@lists.debian.org
| Usertags: regression
| 
| Hi Maintainer
| 
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1].
| I've copied what I hope is the relevant part of the log below.

FYI, I am not the maintainer of r-cran-ff.

The package is perfectly clean at CRAN on all hardware-os combinations,
including amd64 so maybe the maintainer needs to turn this test off:

   https://cloud.r-project.org/web/checks/check_results_ff.html

Dirk
 
| Regards
| Graham
| 
| 
| [1] https://ci.debian.net/packages/r/r-cran-ff/testing/amd64/
| 
| 
| 42s ══ Failed tests
| 
| 42s ── Failure ('test-zero_lengths.R:34:3'): file size is correct when
| creating ff integer from scratch ──
| 42s file.exists(f1) is not TRUE
| 42s
| 42s `actual`: FALSE
| 42s `expected`: TRUE
| 42s
| 42s [ FAIL 1 | WARN 52 | SKIP 0 | PASS 965 ]
| 42s Error: Test failures
| 42s Execution halted

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070844: librust-hyper-rustls-dev: reenable webpki-tokio feature

[Maytham Alsudany]

Package: librust-hyper-rustls-dev
Version: 0.24.2-2
Severity: important

Dear Maintainer,

The 2001_webpki-roots.patch should be removed as rust-webpki-roots is now
packaged in Debian, and rust-octocrab fails to build as it cannot find the
webpki-tokio feature.

Kind regards,
Maytham


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

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

[Manny]

> I do not fully understand the comment, but to me it rather looks as if the
> author gave some comments on the new behavior of the package instead of
> accepting a bug.

The comment reveals that \maketitle was tinkered with in the newest
version, which is what the new error output points to as problematic.

> I won't do a roll back. If you need the old version back, please install it
> into your LOCALTEMXMF tree and use it.

To be clear, the rollback was not suggested to fix it for me. It’s how
the Debian release would be fixed to function for everyone. Maybe I’m
missing something but I thought the point of version control and the
purpose of Debian stable targeting specific versions?  This aspect of
the Debian effort is a bit murky. It’s strange that the Debian policy
manual and developers’ reference guide do not cover a rollback
procedure when a particular version turns out to be a disaster. Though
I suppose whatever would be prescribed, TeXlive is a beast that would
need an exceptional approach anyway.

Indeed I can hack around the problem to fix it for myself. I
appreciate the tip about LOCALTEMXMF. TIL there is a TeXlive pkg
manager (tlmgr), so I probably need to look into how that works.

Bug#1069602: RFP: rapidgzip -- Parallelized decompression of gzip (Python)

[Maximilian Knespel]

Hello,

I am the developer of rapidgzip. I found this RFP by accident and am 
glad that there is demand. I have zero experience with packaging for 
Debian, but I would be happy to help if a Debian developer decides to 
package this.


Some small adjustments to the metadata:

* Package name: rapidgzip
  Version : 0.13.3 (from Git tags)
  Upstream Author : Maximilian Knespel
* URL :https://github.com/mxmlnkn/rapidgzip
* License : MIT
  Programming Lang: C++
  Description : Parallelized decompression of gzip

In particular, I have filled in my university mail, which I also used for the 
corresponding paper, and I have changed the language to C++.
The Python-version is only a very thin wrapper around the C++ code. A Debian 
package should build from the C++ source directly.
I am basically only using Python for distributing the C++ CLI and also for 
distributing the rapidgzip library for random access and parallel decompression.

Bug#1070843: r-bioc-s4vectors: autopkgtest regression with r-base 4.4.0

[Graham Inggs]

Source: r-bioc-s4vectors
Version: 0.40.2+dfsg-1
Severity: serious
X-Debbugs-Cc: Dirk Eddelbuettel 
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

r-bioc-s4vectors' autopkgtest regresses when tested with r-base 4.4.0
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-s4vectors/testing/amd64/


125s > S4Vectors:::.test()
129s Timing stopped at: 0.009 0 0.009
129s Error in var(x) : is.atomic(y) is not TRUE
129s In addition: Warning messages:
129s 1: In combineUniqueCols(X, Y, Z, use.names = FALSE) :
129s different values in multiple instances of column 'dup', ignoring this
129s column in DFrame 2
129s 2: In combineUniqueCols(X, Y, Z) :
129s different values for shared rows in multiple instances of column 'dup',
129s ignoring this column in DFrame 2
129s 3: In combineUniqueCols(x, y2) :
129s different values for shared rows in multiple instances of column 'X',
129s ignoring this column in DFrame 2
130s Loading required package: GenomeInfoDb
132s
132s
132s RUNIT TEST PROTOCOL -- Thu May 9 22:12:10 2024
132s ***
132s Number of test functions: 74
132s Number of errors: 1
132s Number of failures: 0
132s
132s
132s 1 Test Suite :
132s S4Vectors RUnit Tests - 74 test functions, 1 error, 0 failures
132s ERROR in test_Rle_numerical: Error in var(x) : is.atomic(y) is not TRUE
132s
132s Test files with failing tests
132s
132s test_Rle-utils.R
132s test_Rle_numerical
132s
132s
132s Error in BiocGenerics:::testPackage("S4Vectors") :
132s unit tests failed for package S4Vectors
132s Calls:  -> 
132s Execution halted

Bug#1070841: r-bioc-iranges: autopkgtest regression with r-base 4.4.0

[Graham Inggs]

Source: r-bioc-iranges
Version: 2.36.0-1
Severity: serious
X-Debbugs-Cc: Dirk Eddelbuettel 
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-iranges/testing/amd64/


194s ***
194s Number of test functions: 98
194s Number of errors: 1
194s Number of failures: 0
194s
194s
194s 1 Test Suite :
194s IRanges RUnit Tests - 98 test functions, 1 error, 0 failures
194s ERROR in test_AtomicList_numerical: Error in FUN(X[[i]], ...) :
is.atomic(y) is not TRUE
194s
194s Test files with failing tests
194s
194s test_AtomicList-utils.R
194s test_AtomicList_numerical
194s
194s
194s Warning messages:
194s 1: In recycleListElements(e1, en) :
194s Some element lengths are not multiples of their corresponding
element length in e1
194s 2: In x + y :
194s longer object length is not a multiple of shorter object length
194s 3: In recycleListElements(e1, en) :
194s Some element lengths are not multiples of their corresponding
element length in e1
194s 4: In x + y :
194s longer object length is not a multiple of shorter object length
194s Execution halted

Bug#1070842: r-bioc-mutationalpatterns: autopkgtest regression with r-base 4.4.0

[Graham Inggs]

Source: r-bioc-mutationalpatterns
Version: 3.12.0+dfsg-1
Severity: serious
X-Debbugs-Cc: Dirk Eddelbuettel 
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

r-bioc-mutationalpatterns' autopkgtest regresses when tested with r-base 4.4.0
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-mutationalpatterns/testing/amd64/


125s > test_check("MutationalPatterns")
172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
172s
172s ══ Failed tests

172s ── Error ('test-fit_to_signatures_bootstrapped.R:12:3'): Output
has correct class ──
172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
of class NULL
172s Backtrace:
172s ▆
172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
test-fit_to_signatures_bootstrapped.R:12:3
172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
172s 6. │ ├─S4Vectors::isEmpty(sims)
172s 7. │ └─S4Vectors::isEmpty(sims)
172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
172s 11. └─base::unlist(.)
172s ── Error ('test-fit_to_signatures_bootstrapped.R:31:3'): Output
is equal to expected ──
172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
of class NULL
172s Backtrace:
172s ▆
172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
test-fit_to_signatures_bootstrapped.R:31:3
172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
172s 6. │ ├─S4Vectors::isEmpty(sims)
172s 7. │ └─S4Vectors::isEmpty(sims)
172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
172s 11. └─base::unlist(.)
172s ── Error ('test-fit_to_signatures_strict.R:11:1'): (code run
outside of `test_that()`) ──
172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
of class NULL
172s Backtrace:
172s ▆
172s 1. ├─MutationalPatterns::fit_to_signatures_strict(...) at
test-fit_to_signatures_strict.R:11:1
172s 2. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
172s 3. │ └─MutationalPatterns:::.plot_sim_decay(...)
172s 4. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
172s 5. │ ├─S4Vectors::isEmpty(sims)
172s 6. │ └─S4Vectors::isEmpty(sims)
172s 7. │ └─base::vapply(x, isEmpty, logical(1L))
172s 8. │ ├─S4Vectors (local) FUN(X[[i]], ...)
172s 9. │ └─S4Vectors (local) FUN(X[[i]], ...)
172s 10. └─base::unlist(.)
172s
172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
173s Error: Test failures
173s Execution halted