Bug#1059460: [INTL:es] Spanish translation of sudo debconf template

[Camaleón]

Package: sudo
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.

Kindly place this file in debian/po/ as es.po for your next upload.

Cheers,
-- 
Camaleón# Translation of sudo debconf templates to Spanish
# Copyright (C) 2023 Camaleon 
# This file is distributed under the same license as the sudo package.
# Camaleon , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: sudo\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2023-11-20 12:50+0100\n"
"PO-Revision-Date: 2023-12-14 18:19+0100\n"
"Language-Team: Debian Spanish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Last-Translator: Camaleón \n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"Language: es\n"

#. Type: note
#. Description
#: ../sudo-ldap.templates:1001
msgid "sudo-ldap is going away after trixie"
msgstr "El paquete sudo-ldap va a desaparecer a partir de Trixie."

#. Type: note
#. Description
#: ../sudo-ldap.templates:1001
msgid ""
"Debian 13, \"trixie\", will be the last version of Debian that "
"supports sudo-ldap."
msgstr ""
"Debian 13 «Trixie» será la última versión de Debian que admita sudo-"
"ldap."

#. Type: note
#. Description
#: ../sudo-ldap.templates:1001
msgid ""
"The Debian sudo team recommends the use of libsss-sudo for new "
"installations and the migration of existing installations from sudo-"
"ldap to libsss-sudo and sssd"
msgstr ""
"El equipo de sudo de Debian recomienda utilizar libsss-sudo en las "
"nuevas instalaciones y migrar desde sudo-ldap a libsss-sudo y sssd en "
"las instalaciones existentes."

#. Type: note
#. Description
#: ../sudo-ldap.templates:1001
msgid ""
"See /usr/share/doc/sudo-ldap/NEWS.Debian.gz for more explanation. "
"This is also being discussed in #1033728 in the Debian BTS."
msgstr ""
"Consulte «/usr/share/doc/sudo-ldap/NEWS.Debian.gz» para más "
"información. También se está debatiendo este asunto en el BTS de "
"Debian (#1033728)."

Bug#1059459: Need participation in writing an article about shutdown from the creators of Debian

[Alexander]

Package: base
Version: 1

Hello,
There was a need to write an article about shutdown at 
https://bugzilla.kernel.org/show_bug.cgi?id=218266

Apparently, the participation of Debian specialists is needed, who can describe 
the shutdown issue from the point of view of the internal structure of Debian. 
Not all developers there are Debian users.
In particular: is the SIGTERM signal generally suitable for saving user program 
data in Debian or should you look towards the dbus PrepareForShutdown signal.

Many proposed solutions (mostly around the same SIGTERM) in this area do not 
work for Debian, although, apparently, they work for the developers themselves 
who use other distributions.

Thank you !

Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Mon, Dec 25, 2023 at 10:16:13PM +0100, Abou Al Montacir wrote:
> On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> > lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2,
> > lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and
> > lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way
> > unless there is a need for change.
> IDE and utils packages are providing binaries.
> other ones are providing libraries, so, taking into account below comment, I'd
> say they should be M-A:same.

In principle, I agree here. For them to become M-A:same they must first
become A:any as M-A:same is not valid for A:all. The question that is
not clear to me is whether this is worth the effort, i.e. whether it
poses a practical difference to any actual use case. And of course the
answer to this question may change over time.

> > lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units,
> > lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These
> > are metapackages and those typically have their Architecture field match
> > the one they forward to, but this is not the case here. It's not clear
> > whether this needs to change. As long as we only need it for the native
> > architecture, this can be fine. They must not become M-A:foreign though.
> These packages need to pull the versioned homonyme package (example: lazarus-
> ide-2.2) for the architecture in use.
> If I aptitude install lazarus-ide I'd expect that lazarus-ide-2.2:amd64 is
> installed on a amd64 machine, not arm or any other arch.

That all works both with A:all and A:any. The property you want is valid
as long as these packages are not marked M-A:foreign regardless of their
Architecture field.

> However I would expect to be able to install lcl-units-2.2:armhf for cross
> compilation.

What you cannot do currently is install lcl-units:armhf on an amd64
machine (because lcl-units is A:all and implicitly M-A:no). As a
downstream of lazarus, you typically do not want to encode the version
(and ddrescueview does not), so the build dependency will likely be
lcl-units rather than lcl-units-2.2 (or in the case of ddrescueview lcl
rather than lcl-2.2). If you want to support cross compilation, all of
these likely have to become A:any.

> > lcl is much like lazarus-ide and friends except that it is M-A:foreign
> > and this is what this bug report is about.
> Not exactly, because lazarus-ide pull an IDE which is a program, while lcl 
> pulls
> libraries which are object files used for cross compilation.

My comparison of lcl ad lazarus-ide was done on a rather abstract level.
The supposed similarity is that they both are empty A:all packages
depending on other packages from src:lazarus. I did not mean to imply
functional similarity.

As you say, lcl ensures presence of libraries. I imply here that those
libraries are architecture-dependent. Hence lcl must not be M-A:foreign.
It is this M-A:foreign that actively breaks the cross compilation use
case that you supposedly try to address using it.

> This makes the entire difference and was a headache to fix multi-arch errors,
> warnings and hints in the packages tracker.

I happen to be the author of the multiarch hinter. Please go into
further detail as to what kind of errors you were faced with. Also note
that in the presence of wrong Multi-Arch annotations (such as the case
of lcl), the hinter will also give you wrong warnings. It very much is
crucial for the correct operation of the hinter to remove this
M-A:foreign.

I appreciate more detail on what went wrong here.

> For the M-A: foreign, I don't see what is the issue here. lcl-units is an 
> A:all
> package, so you can install whatever version it will be the same.

The problem with M-A:foreign is that it masks a dependency constraint.
When you install Build-Depends of a source package, you may choose the
host architecture (i.e. the one you are building for) and all of your
Build-Depends implicitly get requested for that host architecture. When
I natively build for amd64 on amd64, I want my lcl-units dependency to
install lcl-units-2.2:amd64. When I cross build for armhf on amd64, I
want my lcl-units dependency to install lcl-units-2.2:armhf! While the
package content of lcl-units is the same, the dependency is quite
different. If lcl-units is A:all M-A:no (as is currently the case), it
cannot satisfy the :armhf dependency on amd64 and cross build dependency
resolution fails. If it were to become A:all M-A:foreign (wrong), it
would satify the lcl-units:armhf dependency and install
lcl-units-2.2:amd64 which is very much not the thing I wanted.

> For cross compilation, one expects the user to know what he is doing and 
> install
> the right packages manually.

Not at all! For the cross compilation use case, we expect that
dependency resolution works normally and that no manual intervention is
required.

> Maybe you want to say that one can simply use aptitude install lcl-
> units:armhf and all armhf LCL p

Bug#1043037: Reasonable fork of MLMMJ available now

[Chris Knadle]

retitle 1043037 Switch upstream source to fork after release of MLMMJ 1.4
summary 1043037 MLMMJ upstream is dead since 2017, but users of MLMMJ 
have created a usable fork with new features; it's time to switch to it

thanks

New location for ongoing fork MLMMJ releases (current release is 1.4.3):
   https://codeberg.org/mlmmj/mlmmj/releases

--
Chris Knadle
chris.kna...@coredump.us

Bug#1059458: firmware-iwlwifi: please, include latest iwlwifi-QuZ-a0-hr-b0-77 firmware.

[Daniel Serpell]

Package: firmware-iwlwifi
Version: 20230625-2
Severity: wishlist

Current kernel 6.6.8-1 expects a newer version of the firmware for the AX201 
card:

  [15.343946] iwlwifi :00:14.3: Detected crf-id 0x3617, cnv-id 0x2302 
wfpm id 0x8000
  [15.343974] iwlwifi :00:14.3: PCI dev a0f0/4070, rev=0x351, rfid=0x10a100
  [15.357654] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-QuZ-a0-hr-b0-77.ucode (-2)
  [15.357713] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
  [15.357796] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-QuZ-a0-hr-b0-77.ucode (-2)
  [15.357844] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-QuZ-a0-hr-b0-77.ucode failed with error -2

This firmware version is included in the upstream package, but not copied to 
the binary package.

Thank you.

Daniel.

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#988200: xserver-xorg-video-nvidia: user-specified xorg configuration can't find nvidia driver

[Andreas Beckmann]

On 24/12/2023 00.38, Ian Eure wrote:
Just want to pipe in that I’m also affected by this bug, which seems 
very severe.  I don’t see how this package is usable /at all/, in any 
configuration, in its current state.


Please run

  reportbug -N 988200

on the affected system to collect some information about your system 
state that might help diagnose what went wrong in your case.



Andreas

Bug#1057067: RFS: rclone (update) + dep

[Maytham Alsudany]

Hi Go team,

I require a sponsor to review and upload the following packages for me.

Updated:
- rclone (update to 1.65.0, team upload)
Significant changes, please see changelog / commit history
- golang-github-hanwen-go-fuse (update to 2.4.2, team upload)

Thanks,
Maytham


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

Bug#1053864: Resolved by laptop firmware upgrade

[icefox]

fwupdmgr has a firmware upgrade for the laptop in question (AMD Framework 13), 
titled
System Firmware (0.0.3.2 → 0.0.3.3).  The 0.0.3.2 version's issues with 
graphics 
drivers are well documented by the vendor; I would swear that this was already 
installed, but apparently not.  On doing this update, everything appears to 
work 
fine.

Welp, now we know I guess.  Thanks.
-- 

Bug#1059457: qemu-system-gui: README.Debian or manpage needed

[Brian Sammon]

Package: qemu-system-gui
Severity: normal

Dear Maintainer,

This package could really use a README.Debian or something to explain how to 
use it. 
Perhaps it's because I'm not using a standard desktop environment like Gnome or 
KDE, but I can't figure out what this package does.  It doesn't seem to install 
a program in /usr/bin/ , for example.

-- 
Brian Sammon 

Bug#1056017: rlvm: FTBFS: boost1.83 transition

[Bo YU]

Hi！

On Tue, Dec 26, 2023 at 1:24 AM Ying-Chun Liu (PaulLiu)
 wrote:
>
> Hi Bo YU,
>
> Please NMU it and I'll sponsor it.

Thanks. please to see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059441

```

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rlvm/rlvm_0.14-5.2.dsc

Changes since the last upload:

 rlvm (0.14-5.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix ftbfs on boost1.83. (Closes: #1056017)
   * Use libboost-timer-dev instead of libboost-date-time-dev.

```

BR,
Bo
>
> Yours,
> Paul
>
>
> On 2023/12/25 19:52, Bo YU wrote:
> > Source: rlvm
> > Version: 0.14-5.1
> > Followup-For: Bug #1056017
> > Tags: patch
> >
> > Dear Maintainer,
> >
> > I cost some time to fix the issue and patch attached. Please review it.
> >
> > In order to fix the RC bug ASAP, I may do a NMU to mentor and find a
> > sponsor to upload it. Please feel free to break the process if there is
> > any issue.
> >
> >

Bug#1059040: libxml2: ABI change? (undefined references)

[Thorsten Glaser]

On Mon, 25 Dec 2023, Rene Engelhard wrote:

> In any case, *this* bug is about the ABI change: removed symbols/versions 
> other
> stuff relies on.
>
> Long story short: libxml2 2.12 has still a long road to go with much work on
> your side until you can upload it to unstable.

Sounds like it needs a solib major version and package name change
for coïnstallability, upgrades, etc. *or* a fix that restores the
prior ABI.

Perhaps first ask upstream whether the removal was desired (and in
which case they would do the version bump).

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 22:57 schrieb Rene Engelhard:
I didn't file it for the plain build issue. Nevertheless, if it broke so 
many projects you probably should do a full-fledged rebuild and send 


Well, mitigated by 2.12.3, but still.

But again, this is completely off-topic to what I filed in this bug 
which is the ABI break.


Which *maybe* could be ignored. Maybe one can do Breaks: after a rebuild 
(then you might get a problem inbetween only when in this case 
libreoffice is to be rebuilt. But here libreoffice fails its tests even).


But not until one knows what is affected.

*You* need to do a test as the library maintainer/the one who wants to 
update it, not me.


Regards,

Rene

Bug#1058129: python-scruffy: FTBFS: ModuleNotFoundError: No module named 'imp'

[Dale Richards]

I've opened a merge request in Salsa that fixes this bug and updates the 
package to upstream version 0.3.8.2:
https://salsa.debian.org/python-team/packages/python-scruffy/-/merge_requests/2

Could a DPT member please review and merge/upload as required?

I've also submitted a fix upstream:
https://github.com/snare/scruffy/pull/31


Best regards,
Dale Richards

Bug#1059454: ITP: golang-github-ovn-org-libovsdb -- An OVSDB Client Library

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-ovn-org-libovsdb
  Version : 0.6.0-1
  Upstream Author : Open Virtual Network
* URL : https://github.com/ovn-org/libovsdb
* License : Apache-2.0
  Programming Lang: Go
  Description : An OVSDB Client Library

 OVSDB is the Open vSwitch Database Protocol. It's defined in RFC 7047
 and is used mainly for managing configuration of Open vSwitch and OVN.

This is a dependency for packaging Incus (ITP #1042989).


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

Bug#1059453: ITP: golang-github-openfga-go-sdk -- OpenFGA SDK for Go

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-openfga-go-sdk
  Version : 0.3.3-1
  Upstream Author : OpenFGA
* URL : https://github.com/openfga/go-sdk
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenFGA SDK for Go

 This is an autogenerated Go SDK for OpenFGA. It provides a wrapper
 around the OpenFGA API definition (https://openfga.dev/api).
 .
 OpenFGA is designed to make it easy for application builders to model
 their permission layer, and to add and integrate fine-grained
 authorization into their applications. OpenFGA’s design is optimized
 for reliability and low latency at a high scale.

This is a dependency for packaging Incus (ITP #1042989).


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

Bug#1059455: ITP: golang-github-cenkalti-rpc2 -- Bi-directional RPC

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-cenkalti-rpc2
  Version : 1.0.0-1
  Upstream Author : Cenk Altı
* URL : https://github.com/cenkalti/rpc2
* License : Expat
  Programming Lang: Go
  Description : Bi-directional RPC

 rpc2 is a fork of net/rpc package in the standard library. The main
 goal is to add bi-directional support to calls. That means server can
 call the methods of client. This is not possible with net/rpc package.
 In order to do this it adds a *Client argument to method signatures.

This is a dependency for packaging golang-github-ovn-org-libovsdb.


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

Bug#1059456: ITP: golang-github-cenkalti-hub -- Simple PubSub library

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-cenkalti-hub
  Version : 1.0.2-1
  Upstream Author : Cenk Altı
* URL : https://github.com/cenkalti/hub
* License : Expat
  Programming Lang: Go
  Description : Simple PubSub library

 This library provides a simple event dispatcher for
 the publish/subscribe pattern.

This is a dependency for packaging golang-github-cenkalti-rpc2.


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

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 22:33 schrieb Rene Engelhard:

The tests are still failing and there is no patch anywhere yet, see


Sorry, link got lost: 
https://bugs.documentfoundation.org/show_bug.cgi?id=158423


and c) you ignore the actual issue here at hand and that is that the new 
libxml2 breaks the ABI, causing at least libxmlsec to be needed to be 
rebuilt.


I didn't file it for the plain build issue. Nevertheless, if it broke so 
many projects you probably should do a full-fledged rebuild and send 
patches before uploading to unstable and putting this on all maintainers 
(or by making them get a FTBFS bug by Lucas once a rebuild happens at 
which time people won't remember the libxml2 update)


In any case, *this* bug is about the ABI change: removed 
symbols/versions other stuff relies on.


Long story short: libxml2 2.12 has still a long road to go with much 
work on your side until you can upload it to unstable.


Regards,

Rene

Bug#1059452: opennds: CVE-2023-41101 CVE-2023-41102

[Salvatore Bonaccorso]

Source: opennds
Version: 9.10.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for opennds.

CVE-2023-41101[0]:
| An issue was discovered in the captive portal in OpenNDS before
| version 10.1.3. get_query in http_microhttpd.c does not validate the
| length of the query string of GET requests. This leads to a stack-
| based buffer overflow in versions 9.x and earlier, and to a heap-
| based buffer overflow in versions 10.x and later. Attackers may
| exploit the issue to crash OpenNDS (Denial-of-Service condition) or
| to inject and execute arbitrary bytecode (Remote Code Execution).


CVE-2023-41102[1]:
| An issue was discovered in the captive portal in OpenNDS before
| version 10.1.3. It has multiple memory leaks due to not freeing up
| allocated memory. This may lead to a Denial-of-Service condition due
| to the consumption of all available memory.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41101
https://www.cve.org/CVERecord?id=CVE-2023-41101
[1] https://security-tracker.debian.org/tracker/CVE-2023-41102
https://www.cve.org/CVERecord?id=CVE-2023-41102
[3] 
https://source.sierrawireless.com/-/media/support_downloads/security-bulletins/pdf/swi-psa-2023-006-r3.ashx
[4] 
https://github.com/openNDS/openNDS/commit/69dde77927b252e2a4347170504a785ac5d50c33

Regards,
Salvatore

Bug#1059451: opennds: CVE-2023-38313 CVE-2023-38314 CVE-2023-38315 CVE-2023-38316 CVE-2023-38320 CVE-2023-38322 CVE-2023-38324

[Salvatore Bonaccorso]

Source: opennds
Version: 9.10.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for opennds.

CVE-2023-38313[0]:
| An issue was discovered in OpenNDS Captive Portal before 10.1.2. it
| has a do_binauth NULL pointer dereference that can be triggered with
| a crafted GET HTTP request with a missing client redirect query
| string parameter. Triggering this issue results in crashing openNDS
| (a Denial-of-Service condition). The issue occurs when the client is
| about to be authenticated, and can be triggered only when the
| BinAuth option is set.


CVE-2023-38314[1]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. It has a NULL pointer dereference in preauthenticated() that
| can be triggered with a crafted GET HTTP request with a missing
| redirect query string parameter. Triggering this issue results in
| crashing OpenNDS (a Denial-of-Service condition).


CVE-2023-38315[2]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. It has a try_to_authenticate NULL pointer dereference that
| can be triggered with a crafted GET HTTP with a missing client token
| query string parameter. Triggering this issue results in crashing
| OpenNDS (a Denial-of-Service condition).


CVE-2023-38316[3]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. When the custom unescape callback is enabled, attackers can
| execute arbitrary OS commands by inserting them into the URL portion
| of HTTP GET requests.


CVE-2023-38320[4]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. It has a show_preauthpage NULL pointer dereference that can
| be triggered with a crafted GET HTTP with a missing User-Agent
| header. Triggering this issue results in crashing OpenNDS (a Denial-
| of-Service condition).


CVE-2023-38322[5]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. It has a do_binauth NULL pointer dereference that be
| triggered with a crafted GET HTTP request with a missing User-Agent
| HTTP header. Triggering this issue results in crashing OpenNDS (a
| Denial-of-Service condition). The issue occurs when the client is
| about to be authenticated, and can be triggered only when the
| BinAuth option is set.


CVE-2023-38324[6]:
| An issue was discovered in OpenNDS Captive Portal before version
| 10.1.2. It allows users to skip the splash page sequence when it is
| using the default FAS key and when OpenNDS is configured as FAS
| (default).

[7] contains the report, and these issues are fixed in v10.1.2
upstream. Note two more are fixed in 10.1.3 (separate bug for it
coming to separate the CVEs) and a set of CVEs are apparently yet
unresolved.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-38313
https://www.cve.org/CVERecord?id=CVE-2023-38313
[1] https://security-tracker.debian.org/tracker/CVE-2023-38314
https://www.cve.org/CVERecord?id=CVE-2023-38314
[2] https://security-tracker.debian.org/tracker/CVE-2023-38315
https://www.cve.org/CVERecord?id=CVE-2023-38315
[3] https://security-tracker.debian.org/tracker/CVE-2023-38316
https://www.cve.org/CVERecord?id=CVE-2023-38316
[4] https://security-tracker.debian.org/tracker/CVE-2023-38320
https://www.cve.org/CVERecord?id=CVE-2023-38320
[5] https://security-tracker.debian.org/tracker/CVE-2023-38322
https://www.cve.org/CVERecord?id=CVE-2023-38322
[6] https://security-tracker.debian.org/tracker/CVE-2023-38324
https://www.cve.org/CVERecord?id=CVE-2023-38324
[7] 
https://source.sierrawireless.com/-/media/support_downloads/security-bulletins/pdf/swi-psa-2023-006-r3.ashx
[8] 
https://github.com/openNDS/openNDS/commit/cd4004fc3cf79c0f2bc0ee98db30d225d0b79bc9

Regards,
Salvatore

Bug#1058795: installing docker.io makes all qemu guests lose internet connection

[Michael Tokarev]

On Sat, 16 Dec 2023 14:54:32 +0100 Wolfgang Rohdewald  
wrote:

Package: docker.io
Version: 20.10.24+dfsg1-1+b3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

   * What led up to the situation?

installed docker.io with existing qemu guests in bridge mode, did not do
anything else.


This seems to be because docker includes some firewall rules which does not
play nice with existing firewall rules.  For example, in my case I use
nftables, and after docker.io is installed, I had to

 rmmod xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo 
xt_addrtype nft_compat br_netfilter

in order to make my bridge working again.  It isn't only qemu guests which
are broken, it's everything connected to the host bridge besides the host
itself, - eg nspawn containers.

/mjt

Bug#1058029: qemu-guest-agent: QEMU-GA WON'T START

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

11.12.2023 14:51, Y :

Package: qemu-guest-agent
Version: 1:8.1.2+ds-1~bpo12+1
Severity: serious
Justification: 6

Dear Maintainer,

The problem arose after upgrading from bullseye to bookworm.


What did you upgrade, host or guest system?


All was OK on bullseye, but on bookworm qemu-ga refuse to start with
following messages :

1702295113.963828: debug: disabling command: guest-get-devices
1702295113.963868: critical: error opening channel 
'/dev/virtio-ports/org.qemu.guest_agent.0': No such file or directory
1702295113.963873: critical: failed to create guest agent channel
1702295113.963875: critical: failed to initialize guest agent channel

The systemd command looks like :
[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device


This is the standard qga systemd unit file.
This unit file tells systemd to start qemu-ga *only* if
/dev/virtio-ports/org.qemu.guest_agent.0 device is present.

So it is either present and qga will start okay, or it is
not present, and systemd wont start it.  But not both.

I can't reproduce this issue, everything looks and works
like it is supposed to look and work.

Also, there are *lots* of bullseye VMs and hosts has been
upgraded to bookworm, and qemu-ga continues to work just
fine.

I've no idea what to get out of all this.

/mjt

Bug#1059040: libxml2: ABI change? (undefined references)

[Rene Engelhard]

Hi,

Am 25.12.23 um 16:31 schrieb Aron Xu:

Hi Rene,

On Wed, Dec 20, 2023 at 3:39 AM Rene Engelhard  wrote:

Am Tue, Dec 19, 2023 at 08:03:56PM +0100 schrieb Rene Engelhard:

LibreOffice builds (patch available), but doesn't yet build with 2.12.

"... but doesn't yet succeed the tests with 2.12"


That didn't change, see below.

[...]


Do we have removed symbols/removed versions here? (libxmlsec.so.1 was
not rebuilt)

After a rebuild of libxmlsec1 this link succeeds...


I see that you've committed this patch[1] to libreoffice, does this


Which is the above patch I mentioned to fix the *BUILD* with libxml2. 
After that applied I ran into the issue which resulted in thig bug 
report (see below in c))


The tests are still failing and there is no patch anywhere yet, see


It would actually be helpful to read because that one is said a) here 
and b) in the commit ("|Only the build, not the tests (yet)!")|



mean I can proceed to upload this version of libxml2 to unstable
without further action? Or is there anything else I should coordinate
with you to prevent breakage?


and c) you ignore the actual issue here at hand and that is that the new 
libxml2 breaks the ABI, causing at least libxmlsec to be needed to be 
rebuilt.



Regards,


Rene

Bug#1059450: libspreadsheet-parseexcel-perl: CVE-2023-7101

[Salvatore Bonaccorso]

Source: libspreadsheet-parseexcel-perl
Version: 0.6500-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.6500-1.1
Control: found -1 0.6500-1
Control: affects -1 + libspreadsheet-parsexlsx-perl

Hi,

The following vulnerability was published for libspreadsheet-parseexcel-perl.
The writeup[2] contains a descrption of the issue and pocs. Note that
the issue in Spreadsheet::ParseExcel will affect as well
Spreadsheet::ParseXLSX relying on Spreadsheet::ParseExcel but AFAIU,
the issue needs to be fixed in Spreadsheet::ParseExcel.

CVE-2023-7101[0]:
| Spreadsheet::ParseExcel version 0.65 is a Perl module used for
| parsing Excel files. Spreadsheet::ParseExcel is vulnerable to an
| arbitrary code execution (ACE) vulnerability due to passing
| unvalidated input from a file into a string-type “eval”.
| Specifically, the issue stems from the evaluation of Number format
| strings (not to be confused with printf-style format strings) within
| the Excel parsing logic.


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-7101
https://www.cve.org/CVERecord?id=CVE-2023-7101
[1] https://github.com/haile01/perl_spreadsheet_excel_rce_poc

Regards,
Salvatore

Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign

[Abou Al Montacir]

Hi Helmut,

On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> Hi,
> 
> On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote:
> > Just like lcl, lcl-2.2 is also a virtual package.
> 
> This is technically wrong. The term "virtual package" refers to a binary
> package name that is provided by some package but doesn't exist as a
> .deb. Both lcl and lcl-2.2 exist as .deb files and thus are called
> "concrete packages".
Yes, indeed, you are right here, even of I question myself if we do really need
to have this kind of meta package or we should just migrate to really virtual
packages.
> 
> > If I look to all other virtual packages, they are Arch: all, and I tend to
> > agree
> > with that.
> 
> Since virtual packages do not exist as concrete packages, they do not
> have an Architecture field and inherit their architecture from the
> providing concrete packages. I sense that your use of "virtual packages"
> does not match the definitions in Debian policy section 7.5.
> 
> I guess that what you mean here is more commonly called "meta package"
> or "dependency package".  Does that make sense to you?
Absolutely!
> 
> > However, I'm not very familiar with multi-arch subtleties.
> 
> I am, but I am very much unfamiliar with Pascal, so we will only make a
> dent on this if we manage to combine our knowledge.
I don't think you need to know much about Pascal for this problem.
We just need to install a set of libraries with FPC/Lazarus and we want also to
keep old version upon major version upgrade, just like GCC for example.
For Lazarus, there is a small complication, as it supports both Gtk and Qt
widget sets, so we need to support installing either or both, but with Gtk2 as
default.
In future, there will also be support for Gtk3, but I fear this is not yet ready
for next months. 
> 
> > So if you want to fix this, please provide a proposal for then entire set of
> > packages.
> > 
> > I would glad then to fix it.
> 
> I fear that my knowledge of Pascal is too limited here, but let me try
> anway:
Let me give some background:
Lazarus is an IDE for Pascal. It comes with a huge number of libraries (called
packages or components).
Upstream generates a huge unique deb package which is about 1GB size.
On Debian, we decided to split this into small packages in order to ease
installation on some reduced HDD architectures.
Thus we split it into IDE, and LCL (Lazarus component libraries) packages.
We also want to keep old IDE version upon upgrade, in case someone's code breaks
due to new version changes in the IDE.  BTY, we do the same thing for FPC.

Lazarus deb package is meant to be used by those people who don't want to deal
with what they exactly need, and thus installing this package will pull
everything while ensuring upgrades. This is just like the gcc or kernel package.

More advance people can install only IDE, or only LCL tools with some components
and use command line lazbuild tool. 
> 
> lazarus-2.2 and lazarus look like a metapackages. They presently are
> A:all and implicitly M-A:no. That much seems fine to me. Due to
> depending on lcl-2.2, they must not become M-A:foreign.
Yes, exact.
> 
> lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary
> packages containing source code only are commonly that way.
Yes, this is needed for optimal usage of the IDE, with automatic suggestion, but
also while box debugging.
> 
> lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2,
> lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and
> lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way
> unless there is a need for change.
IDE and utils packages are providing binaries.
other ones are providing libraries, so, taking into account below comment, I'd
say they should be M-A:same.
> 
> lcl-2.2 is A:any M-A:same. This is a metapackage for libraries and A:any
> M-A:same is commonly correct for libraries.
OK.
> 
> lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary
> packages containing documentation only are commonly that way.
OK.
> 
> lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units,
> lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These
> are metapackages and those typically have their Architecture field match
> the one they forward to, but this is not the case here. It's not clear
> whether this needs to change. As long as we only need it for the native
> architecture, this can be fine. They must not become M-A:foreign though.
These packages need to pull the versioned homonyme package (example: lazarus-
ide-2.2) for the architecture in use.
If I aptitude install lazarus-ide I'd expect that lazarus-ide-2.2:amd64 is
installed on a amd64 machine, not arm or any other arch.
However I would expect to be able to install lcl-units-2.2:armhf for cross
compilation.
> 
> lcl is much like lazarus-ide and friends except that it is M-A:foreign
> and this is what this bug report is about.
Not exactly, because lazarus-ide pull an IDE

Bug#992131: R8169 CRASH! (rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100))

[Vincas Dargis]

Still happening with 6.6 on Sid...

Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix

[Mathias Gibbens]

Package: game-data-packager
Version: 76
Severity: normal

  After building and installing the package for Indiana Jones and the
Fate of Atlantis, it fails to start because scummvm now knows about two
"atlantis" games: "scumm:atlantis" and "cryomni3d:atlantis". Without
the "scumm:" prefix in the Exec statement of the generated .desktop
file, nothing happens when trying to launch the game.

> --- a/fate-of-atlantis-en-data.desktop2023-12-25 20:44:49.888531966 
> +
> +++ b/fate-of-atlantis-en-data.desktop2023-12-25 20:44:46.200557922 
> +
> @@ -6,4 +6,4 @@
>  Terminal=false
>  Type=Application
>  Categories=Game;AdventureGame;
> -Exec=scummvm -p /usr/share/games/fate-of-atlantis-en atlantis
> +Exec=scummvm -p /usr/share/games/fate-of-atlantis-en scumm:atlantis


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

Bug#1059448: python3-influxdb emits errors on installation

[David Starner]

Package: python3-influxdb
Version: 5.3.1-5
Severity: normal
X-Debbugs-Cc: prosfil...@gmail.com

Upon installation, dkg says
Setting up python3-influxdb (5.3.1-5) ...
/usr/lib/python3/dist-packages/influxdb/tests/client_test.py:527: 
SyntaxWarning: invalid escape sequence '\('
  "\(use 'n', 'u', 'ms', 's', 'm' or 'h'\)"
/usr/lib/python3/dist-packages/influxdb/tests/influxdb08/client_test.py:309: 
SyntaxWarning: invalid escape sequence '\('
  "Invalid time precision is given. \(use 's', 'm', 'ms' or 'u'\)"
/usr/lib/python3/dist-packages/influxdb/tests/influxdb08/client_test.py:453: 
SyntaxWarning: invalid escape sequence '\('
  "Invalid time precision is given. \(use 's', 'm', 'ms' or 'u'\)"
/usr/lib/python3/dist-packages/influxdb/tests/influxdb08/client_test.py:737: 
SyntaxWarning: invalid escape sequence '\('
  "'permissions' must be \(readFrom, writeTo\) tuple"



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

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

Versions of packages python3-influxdb depends on:
ii  python3   3.11.6-1
ii  python3-dateutil  2.8.2-3
ii  python3-msgpack   1.0.3-3+b1
ii  python3-requests  2.31.0+dfsg-1
ii  python3-six   1.16.0-4
ii  python3-tz2023.3.post1-2

python3-influxdb recommends no packages.

python3-influxdb suggests no packages.

-- no debconf information

Bug#1059447: src:lz4-java: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: lz4-java
Version: 1.8.0-3
Severity: serious
Control: close -1 1.8.0-4
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:lz4-java has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on i386.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=lz4-java



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058245: libportal: FTBFS: dh_auto_test regression with python3-dbusmock (>= 0.30.0-2)

[Simon McVittie]

Control: retitle -1 libportal: FTBFS: dh_auto_test regression with 
python3-dbusmock (>= 0.30.0-2)

On Tue, 12 Dec 2023 at 09:11:51 +0100, Lucas Nussbaum wrote:
> >  TestRemoteDesktop.test_connect_to_eis 
> > _
> > 
> > self =  > testMethod=test_connect_to_eis>
> > 
> > def test_connect_to_eis(self):
> > >   setup = self.create_session(start_session=True)
> > 
> > pyportaltest/test_remotedesktop.py:428: 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 
> > pyportaltest/test_remotedesktop.py:62: in create_session
> > self.setup_daemon(params=params, extra_templates=extra_templates)
> > pyportaltest/__init__.py:99: in setup_daemon
> > self.start_session_bus()
> > /usr/lib/python3/dist-packages/dbusmock/testcase.py:296: in 
> > start_session_bus
> > cls.__start_bus('session')
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 
> > 
> > cls = 
> > bus_type = 'session'
> > 
> > @classmethod
> > def __start_bus(cls, bus_type) -> None:
> > bustype = BusType(bus_type)
> > old_pid = getattr(DBusTestCase, f"{bustype.value}_bus_pid")
> > >   assert old_pid is None, f"PID {old_pid} still alive?"
> > E   AssertionError: PID 3954437 still alive?
> > 
> > /usr/lib/python3/dist-packages/dbusmock/testcase.py:284: AssertionError

(and many similar assertion errors)

These tests passed with python3-dbusmock 0.29.1-2, but fail starting
from version 0.30.0-2. I don't know whether this is a bug in libportal
or in python3-dbusmock, and I haven't bisected python3-dbusmock to an
exact commit.

smcv

Bug#1059061: libssh: CVE-2023-6004

[Salvatore Bonaccorso]

Hi Martin,

On Mon, Dec 25, 2023 at 11:25:18AM +0100, Martin Pitt wrote:
> Hello Salvatore and all,
> 
> Salvatore Bonaccorso [2023-12-22 20:34 +0100]:
> > On Fri, Dec 22, 2023 at 04:39:46PM +0100, Martin Pitt wrote:
> > > Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > > > > However, the fix for CVE-2023-6004 caused a regression:
> > > > > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > > > > I will monitor this, and include the fix in the security upload once 
> > > > > it is
> > > > > available (or presumably they'll do a 0.10.7). So if it's alright 
> > > > > with you,
> > > > > I'll delay the stable-security update for a few days.
> > > >
> > > > Rigth, it's not that pressing that we get updates out, so let's
> > > > monitor this, have 0.10.7 uploaded and exposed as well then to
> > > > unstable for a while and then look at bookworm-security. Btw, we will
> > > > as well need bullseye-security.
> > >
> > > Ack. The fix landed upstream, and they said they won't do a 0.10.7 
> > > immediately,
> > > so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole 
> > > cockpit
> > > integration test suite at it (which exercises libssh pretty thoroughly via
> > > cockpit-ssh), and it is happy.
> > >
> > > I'll let that simmer for a few days to let it go into testing, and 
> > > prepare the
> > > security updates soon.
> >
> > Thanks, that sounds good.
> 
> The new upstream release plus regression fix have propagated to testing, to
> Ubuntu devel, and also is progressing well into Fedora. By now the tests have
> validated it enough for me to be confident in the fixes.
> 
> I prepared the security update for Debian 12 bookworm, including a debdiff:
> https://people.debian.org/~mpitt/tmp/
> 
> Please feel free to dput it yourself, or I can do it if/when you ack.
> 
> I'll coordinate the update to oldstable with Sean (see the other thread).

Thank for clarifying in the followup, oldoldstable will be handled by
LTS so far, and thanks for preparing your work for bookworm and
bullseye.

For tracking + archiving purpose it would be good if the debdiff can
be attached here as well, but realize the size might be a bit off.

Could you do the following changes: use bookworm-security instead of
stable-securtiy (the bullseye one was already ok). It's not a strict
requirement, but is less confusing to explicitly use the codenames.

Please do upload to security-master, I will try to handle the DSA in
the next few days (will be not around tomorrow at least).

Both will need to be build with -sa.

Regards,
Salvatore

Bug#1059427: bullseye-pu: package haproxy/2.2.9-2+deb11u6

[Salvatore Bonaccorso]

Hi,

On Mon, Dec 25, 2023 at 10:35:16AM +0100, Tobias Frost wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: hapr...@packages.debian.org, t...@security.debian.org
> Control: affects -1 + src:haproxy
> 
> Hi,
> 
> For ELTS I was fixing haproxy's CVES CVE-2023-40225 and CVE-2023-45539,
> and I also like to fix those for stable and oldstable.
> 
> CC'ing the security team, in case they want to issue an DSA instead.
> 
> The changes can also be found on the LTS repository:
> https://salsa.debian.org/lts-team/packages/haproxy
> 
> [ Tests ]
> I've tested the fixes manually, using netcat to inject
> problematic http requests and confirm that the patched
> version rejects the malicous requests. (using nginx and
> also netcat as http server.)
> 
> (Being verbose here to document the tests for later reference ;-))
> 
> haproxy is listening on port 8080
> 
> e.g for CVE-2023-40225:
> echo 'GET /index.nginx-debian.html# HTTP/1.0' | netcat localhost 8080
> must be rejected with 400 Bad Request
> and without the "#" accepted.
> 
> for CVE-2023-45539, nginx is stopped, and netcat listens on port 80:
> echo 'GET / HTTP/.1.1
> host: whatever
> content-length:
> ' | netcat localhost 8080
> 
> If the request is accepted (and forwarded to the listening netcat),
> haproxy is vulnerable. If a "400 Bad request" ist thrown, without
> netcat receiving something, haproxy is not vulnerable.
> 
> (haproxy is running on port 8080)
> 
> [ Risks ]
> Upstream patch, applied cleanly.
> 
> [ 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
> 
> Debdiff attached.
> 
> I'v uploaded the package to o-s-p-u already.

Thanks, but I have already worked on the haproxy update for bullseye
and bookworm.

SRM, can you please reject the packages from stable-new and
olstable-new so once I release the DSA, that version won't clash
versionwise?

Regards,
Salvatore

Bug#1059446: libvte-dev: Please consider enabling sixel support

[Matthias Geiger]

Package: libvte-dev
Severity: wishlist

Dear Maintainer,

please consider enabling sixel support for libvte. At the moment this
prevents images from rendering in vte-based terminals. While it is still
experimental I think this could be enabled so users can test the feature
and report possible bugs. 

best,

werdahias

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages libvte-dev depends on:
pn  libcairo2-dev
pn  libglib2.0-dev   
pn  libgtk2.0-dev
pn  libpango1.0-dev  
pn  libvte-common
pn  libvte9  
ii  libx11-dev   2:1.8.7-1

libvte-dev recommends no packages.

libvte-dev suggests no packages.

Bug#1059445: RM: cataclysm-dda [i386 armel armhf] -- ROM; 32 bit architectures no longer supported by upstream

[Reiner Herrmann]

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

Hi,

please remove the i386 / armel / armhf builds of src:cataclysm-dda, as
upstream is aware of issues with 32-bit architectures, but unable to
support it [0].

Thanks!

Kind regards,
  Reiner

[0] 
https://github.com/CleverRaven/Cataclysm-DDA/issues/64504#issuecomment-1481920922

Bug#946382: This bug report seems useless in my opinion

[Georges Khaznadar]

Hello Dan,

I patched crontab.5 to take your advice in count.

Just hoping that no other purist would notify me that lining up columns
can be done with spaces rather that with zeroes.

I uploaded release 3.0pl1-182 right now.

Best regards,   Georges.


Dan Jacobson a écrit :
> > "GK" == Georges Khaznadar  writes:
> GK> Hello Dan,
> 
> GK> I would like to get more information about your intent, for this bug
> GK> report.
> 
> Looking at the crontab(5) man page,
> everything lines up very pretty:
> 
> 
>17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
>25 6 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
>47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.weekly )
>52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.monthly )
> 
> But that is because the author picked 6 hours for each.
> 
> Let's see what would happen otherwise:
>17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
>25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
>47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.weekly )
>52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.monthly )
> Oh darn, that looks ugly.
> 
> The question that crosses users minds is: "Can I rewrite it
>17  * * * *  root  cd / && run-parts --report /etc/cron.hourly
>25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
>47 06 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.weekly )
>52 06 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.monthly )
> or will that be taken as octal (even if octal 6 is just 6), or illegal?
> Please don't force me to test to find the answer."
> 
> I'm just saying the man page needs to state clearly what will happen.
> 
> Sure, one could just add spaces instead of zeros to make the columns
> line up. But that would just be avoiding the issue.
> 
> GK> Should leading zeroes be supported for the sake of making columns line
> GK> up, or should leading zeroes be used to introduce octal constants, in
> GK> your opinion?
> 
> Nobody wants octal. I'm just trying to make columns line up.
> 
> GK> As far as I understand the code of the file entry.c, numbers are parsed
> GK> by the function atoi:
> GK> -8<- file entry.c's excerpt --
> GK>   if (all_digits) {
> GK>   *numptr = atoi(temp);
> GK>   return ch;
> GK>   }
> GK> -8<---
> 
> GK> ... which means that numbers prefixed by zeroes are considered as
> GK> decimal.
> 
> OK that's great. Please mention so on crontab(5). Thanks.
> 
> In fact perhaps add an example saying one can use spaces and zeros to make the
> columns line up:
> 
>25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
>47 06 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.weekly )
>52  4 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.monthly )

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1056017: rlvm: FTBFS: boost1.83 transition

[Ying-Chun Liu (PaulLiu)]

Hi Bo YU,

Please NMU it and I'll sponsor it.

Yours,
Paul


On 2023/12/25 19:52, Bo YU wrote:

Source: rlvm
Version: 0.14-5.1
Followup-For: Bug #1056017
Tags: patch

Dear Maintainer,

I cost some time to fix the issue and patch attached. Please review it.

In order to fix the RC bug ASAP, I may do a NMU to mentor and find a
sponsor to upload it. Please feel free to break the process if there is
any issue.




OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059444: LXD: cython3 autopkgtest hangs forever due to stall in copyup

[Stefano Rivera]

Package: autopkgtest
Version: 5.31.1
Severity: normal

This reproduces reliably, but I haven't got to the bottom of it. It
looks like a stalled pipeline somewhere.

Run autopkgtest on the current cython in unstable (3.0.6-2) with lxd,
and it'll hang forever.

Eventually failing:
pep526_variable_annotations.cpp: In function ‘PyObject* 
__pyx_pw_27pep526_variable_annotations_11test_tuple(PyObject*, PyObject* 
const*, Py_ssize_t, PyObject*)’:
pep526_variable_annotations.cpp:13880:33: note: ‘result’ declared here
13880 | __pyx_ctuple_int__and_float result;
  | ^~

autopkgtest [13:03:43]: test testsuite: ---]
Error: Failed to retrieve PID of executing child process
autopkgtest-virt-lxd [13:03:43]: copyup source failed, status 255
Error: Failed to retrieve PID of executing child process
autopkgtest [13:03:44]: ERROR: testbed failure: sent `auxverb_debug_fail', got 
`copy-failed', expected `ok...'


autopkgtest-virt-lxd is sitting in sys.stdin.readline.strip() waiting for 
instructions.

autopkgtest is waiting for lxc to finish.

Stefano

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.7.6
ii  libdpkg-perl1.22.2
ii  mawk1.3.4.20231126-1
ii  procps  2:4.0.4-2
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.32.2-1

Versions of packages autopkgtest suggests:
pn  docker.io
ii  fakemachine  0.0.7-2
pn  lxc  
pn  lxd  
ii  ovmf 2023.05-2
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.7
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
ii  qemu-utils   1:8.1.2+ds-1
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-2
ii  vmdb20.28-1
ii  zerofree 1.1.1-1

-- no debconf information

Bug#1059443: [INTL:ro] Romanian debconf templates translation of "x2goserver"

[Remus-Gabriel Chelu]

Package: x2goserver
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the 
«x2goserver_debconf» file.


A draft has been posted to the debian-l10n-romanian mailing list 
allowing for

review.
Please add it to your next package revision.

--
Thanks,
Remus-Gabriel# Mesajele în limba română pentru pachetul x2goserver (debconf).
# Romanian translation of x2goserver (debconf).
# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the x2goserver package.
#
# Remus-Gabriel Chelu , 2023
#
msgid ""
msgstr ""
"Project-Id-Version: x2goserver\n"
"Report-Msgid-Bugs-To: x2goser...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-29 09:26+0100\n"
"PO-Revision-Date: 2023-12-17 23:57+0100\n"
"Last-Translator: Remus-Gabriel Chelu \n"
"Language-Team: Romanian \n"
"Language: ro\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && "
"n%100<=19) ? 1 : 2);\n"
"X-Generator: Poedit 3.2.2\n"

#. Type: text
#. Description
#: ../x2goserver.templates:1001
msgid "X2Go Server / PostgreSQL Upgrade"
msgstr "Actualizarea serverului X2Go / PostgreSQL"

#. Type: text
#. Description
#: ../x2goserver.templates:1001
msgid ""
"You have configured X2Go Server with PostgreSQL as session DB backend and "
"you are upgrading x2goserver from a version minor to 3.1.0.0."
msgstr ""
"Ați configurat serverul X2Go cu PostgreSQL ca server de baze de date "
"pentru sesiuni și actualizați «x2goserver» de la o versiune anterioară a "
"versiunii 3.1.0.0."

#. Type: text
#. Description
#: ../x2goserver.templates:1001
msgid ""
"Please follow these PostgreSQL DB upgrade instructions before you continue "
"using your X2Go Server: /usr/share/doc/x2goserver/README.upgrade-pgsql-"
"database.gz"
msgstr ""
"Vă rugăm să urmați aceste instrucțiuni de actualizare a bazei de date "
"PostgreSQL înainte de a continua să utilizați serverul X2Go: /usr/share/"
"doc/x2goserver/README.upgrade-pgsql-database.gz"

#. Type: text
#. Description
#: ../x2goserver.templates:2001
msgid "X2Go Server Upgrade"
msgstr "Actualizarea serverului X2Go"

#. Type: text
#. Description
#: ../x2goserver.templates:2001
msgid ""
"You are upgrading from an X2Go Server version (< 4.1.0.0). Between 4.1.0.0 "
"and 4.0.0.x the package structure has undergone a major change."
msgstr ""
"Efectuați o actualizare de la o versiune a serverului X2Go (< 4.1.0.0). "
"Între versiunile 4.1.0.0 și 4.0.0.x, structura pachetelor a suferit o "
"schimbare majoră."

#. Type: text
#. Description
#: ../x2goserver.templates:2001
msgid ""
"Note that most of the Perl code in X2Go Server has been moved into its own "
"Perl API X2Go::Server."
msgstr ""
"Rețineți că cea mai mare parte a codului Perl din X2Go Server a fost mutat "
"în propria sa API Perl X2Go::Server."

#. Type: boolean
#. Description
#: ../x2goserver-desktopsharing.templates:1001
msgid "Create x2godesktopsharing group?"
msgstr "Doriți să creați grupul „x2godesktopsharing”?"

#. Type: boolean
#. Description
#: ../x2goserver-desktopsharing.templates:1001
msgid ""
" X2Go Desktop Sharing grants users the privileges to share X2Go/X11\n"
" desktop session with one another via membership of a common POSIX\n"
" group. The group being used for this can be configured system-wide and\n"
" on a per-user basis (in X2Go Desktop Sharing's user configuration).\n"
" .\n"
" Please specify whether X2Go Desktop Sharing should set up the group\n"
" \"x2godesktopsharing\" as the system-wide default group used for this\n"
" purpose.\n"
" .\n"
" Alternatively, if you reject this option, you will be asked to assign\n"
" the role to some already existing group.\n"
" .\n"
" With no such group users will not be able to share X2Go/X11 desktop\n"
" sessions."
msgstr ""
" Dacă partajarea biroului X2Go poate utiliza un grup existent\n"
" (eventual dintr-o bază de date LDAP), atunci puteți specifica\n"
" acest nume de grup în ecranul următor.\n"
" \n"
" Partajarea biroului X2Go acordă utilizatorilor privilegiile de a\n"
" partaja sesiunea de birou X2Go/X11 între ei prin apartenența la un\n"
" grup POSIX comun. Grupul utilizat în acest scop poate fi configurat la\n"
" nivel de sistem și pentru fiecare utilizator în parte (în configurația\n"
" utilizatorului din partajarea biroului X2Go).\n"
" .\n"
" Vă rugăm să specificați dacă partajarea biroului X2Go ar trebui să\n"
" configureze grupul „x2godesktopsharing” ca grup implicit utilizat în\n"
" acest scop la nivelul întregului sistem.\n"
" .\n"
" Alternativ, dacă respingeți această opțiune, vi se va cere să atribuiți\n"
" rolul acesta unui grup deja existent.\n"
" .\n"
" În lipsa unui astfel de grup, utilizatorii nu vor putea partaja sesiuni\n"
" de birou X2Go/X11."

#. Type: boolean
#. Description
#: ../x2goserver-desktopsharing.templates:2001

Bug#1059417: ed: install (r)ed into /usr/bin

[Helmut Grohne]

Hi Ian,

On Sun, Dec 24, 2023 at 10:39:43PM +, Ian Jackson wrote:
> Chris Hofstaedtler writes ("Bug#1059417: ed: install (r)ed into /usr/bin"):
> > I'm attaching a trivial patch to implement such a move.
> > As explained in debian/changelog, the update-alternatives calls are
> > intentionally kept unchanged, to preserve existing user
> > configuration.
> 
> I assume that you are following a plan developed by Helmut et al, as
> part of the overall Debian usrmerge mitigation plan.

I confirm.

> I don't think I agree with this change, as provided, because it will
> cause ed to move to /usr/bin on downstreams that don't do usrmerge.

I don't think there is any reasonable way to continue supporting
unmerged layouts. There are many places already that break subtly there.
For instance, the protective diversions for m-a:same shared file loss
generally leave the old file around in the aliased location on umerged
systems. We do not have the resources to support both merged and
unmerged layouts. A main reason to switching to merged-only was reducing
the support cost down the line.

> And then, without changing the diversion, the package is actually
> broken.

Could it be that you mean s/diversion/alternatives/ here? I am having
difficulty locating said diversion and your argument becomes true when
interpreting it the other way.

> I think there could be an affordance in dh_auto_configure that allows
> this all to work properly.
> 
> I assume there is some reason why we aren't, in Debian, changing
> dh_auto_configure to interpret --bindir=/bin as --bindir=/usr/bin.

I am all ears. I do not harm unmerged users intentionally. When there is
a cheap way to implement mitigations without hurting unmerged, I do so.
The change you propose here is not without issues.

For one thing dh_auto_configure has never inspected user's arguments so
far. The promise has always been appending them. What you propose is a
significant departure from those semantics.

If we were to change debhelper in such a way, packages would move their
files on a binNMU. Such moves tend to cause RC bugs. Cases such as ed
are (hopefully) simple. If this change were to be done to e.g. gzip
(which is diverted by zutils), we could end up with /bin/zgrep missing
after upgrade.

While the intention is to make this as easy as possible on the
maintainer side, every time we changed such a default location
(dh_installinit, dh_installudev, systemd.pc, udev.pc) we were faced with
a number of packages breaking and filed patches for them beforehand. A
similar approach could be used here in principle.

The approach that probably is the easiest to unmerged downstreams is
dh-sequence-movetousr / dh_movetousr. It's a noop in bookworm-backports
and downstreams can similarly disable it when doing rebuilds.

Helmut

Bug#1059442: gitg: Commit dialog overrides Ctrl+Left/Right

[Stefan Tauner]

Package: gitg
Version: 41-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: stefan.tau...@gmx.at

Dear Maintainers,

after upgrading to Bookworm I have noticed that Ctrl+Left/Right does not work
as expected in the commit dialog of gitg. Usually Ctrl+Left/Right moves the
cursor one word to the left or right, respectively. This is true for GUI text
boxes like the one in reportbug I am currently typing in but also terminal
applications etc. The version of gitg in Bookworm has added a commit message
history feature to the commit dialog that is navigated via said shortcuts,
unfortunately, and it drives me a little bit crazy.

This problem has been reported (1) and fixed (2) upstream by using
Alt+Page up/Page down. I have added the upstream patch to the bookworm branch
of my salsa fork of gitg (3). "debuild -b -uc -us" isn't working due to an
unrelated lintian error:
"E: gitg: library-not-linked-against-libc
[usr/lib/gitg/gitg/plugins/libdiff.so]"
But "fakeroot debian/rules binary" spat out a working .deb that seems to work
fine.

I believe this is a candidate for being backported to Bookworm as the source
change is tiny and the bug is a regression introduced by Bookworm. I am happy
to help if need be (but I am not a Debian maintainer).

KR

1: https://gitlab.gnome.org/GNOME/gitg/-/issues/351
2:
https://gitlab.gnome.org/GNOME/gitg/-/commit/d768b107aef1944d945e73ecf14d74746338afe4
3:
https://salsa.debian.org/stefanct/gitg/-/commit/bdb80f0a76c789cdb3a78d5e4270f7d3daa4f67f


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (89, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gitg depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gir1.2-peas-1.0   1.34.0-1+b1
ii  git   1:2.39.2-1.1
ii  gsettings-desktop-schemas 43.0-1
ii  libc6 2.36-9+deb12u3
ii  libcairo2 1.16.0-7
ii  libdazzle-1.0-0   3.44.0-1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgee-0.8-2  0.20.6-1
ii  libgirepository-1.0-1 1.74.0-3
ii  libgit2-glib-1.0-01.1.0-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgspell-1-2 1.12.0-1+b2
ii  libgtk-3-03.24.38-2~deb12u1
ii  libgtksourceview-4-0  4.8.4-4
ii  libjson-glib-1.0-01.6.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpeas-1.0-0 1.34.0-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libxml2   2.9.14+dfsg-1.3~deb12u1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Cyril Brulebois]

Julian Andres Klode  (2023-12-25):
> We picked the previous XFS patch for extent parsing but did not pick
> this one because it had not been merged at that point yet, the fix
> only got merged two weeks or so ago, and we didn't want to take chances
> and pick it ahead of time as it's security critical code (filesystem
> parsing is where all the security bugs live!).
> 
> The release was supposed to be out 2 weeks ago but got pushed back
> another week to last week's release, sadly.

Thanks for all the details, and sorry if it appeared I was chasing you
down; I just stumbled upon this again while re-testing various things,
and was merely wondering whether things were.


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


signature.asc
Description: PGP signature

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

On Mon, Dec 25, 2023 at 04:33:36PM +0100, Cyril Brulebois wrote:
> Julian Andres Klode  (2023-12-25):
> > The final grub 2.12 that includes the fix should hit unstable in the
> > middle of January. As you might be aware many are busy with family
> > stuff and holiday celebrations right now.
> 
> Sure. I wasn't aware an upstream release was in the pipes, only that
> patches have existed and been confirmed OK for close to 2 months.

We picked the previous XFS patch for extent parsing but did not pick
this one because it had not been merged at that point yet, the fix
only got merged two weeks or so ago, and we didn't want to take chances
and pick it ahead of time as it's security critical code (filesystem
parsing is where all the security bugs live!).

The release was supposed to be out 2 weeks ago but got pushed back
another week to last week's release, sadly.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Cyril Brulebois]

Julian Andres Klode  (2023-12-25):
> The final grub 2.12 that includes the fix should hit unstable in the
> middle of January. As you might be aware many are busy with family
> stuff and holiday celebrations right now.

Sure. I wasn't aware an upstream release was in the pipes, only that
patches have existed and been confirmed OK for close to 2 months.

> As always though it stands to reason that this is a change that should
> (have been) reverted in xfsprogs first until a grub that understands
> it has been released in a stable point release such that you can use a
> stable grub to inspect an XFS filesystem created by a trixie xfsprogs.

The more we tick boxes in the compatibility matrix, the happier, yes.

> It seems the bug has been wrongly reassigned instead of being cloned
> and reassigned, so I'm cloning it back to xfsprogs.

Right, this would have been easier to track if debian-boot@ had been put
(and kept) in the loop all along.


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


signature.asc
Description: PGP signature

Bug#1059040: libxml2: ABI change? (undefined references)

[Aron Xu]

Hi Rene,

On Wed, Dec 20, 2023 at 3:39 AM Rene Engelhard  wrote:
>
> Am Tue, Dec 19, 2023 at 08:03:56PM +0100 schrieb Rene Engelhard:
> > LibreOffice builds (patch available), but doesn't yet build with 2.12.
>
> "... but doesn't yet succeed the tests with 2.12"
>
> > S=/home/rene/LibreOffice/git/libreoffice-24-2 && I=$S/instdir && 
> > W=$S/workdir &&  /usr/bin/ccache x86_64-linux-gnu-g++ -pthread  
> > -flto=jobserver -fuse-linker-plugin -O2  -Wl,-z,origin 
> > '-Wl,-rpath,$ORIGIN/../Library' -Wl,-rpath-link,$I/program  -Wl,-z,defs 
> > -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc  -Wl,--hash-style=gnu  
> > -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib  
> > -L$I/program  -L$I/program  -L$W/LinkTarget/Library -ffat-lto-objects 
> > -Wl,-z,relro$W/CxxObject/xmlsecurity/workben/pdfverify.o   
> > -Wl,--start-group-Wl,--end-group -Wl,--no-as-needed -luno_cppu 
> > -luno_cppuhelpergcc3 -luno_sal -lxmlsecurity -lmergedlo  -o 
> > $W/LinkTarget/Executable/pdfverify
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlIOFTPMatch@LIBXML2_2.4.30'
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlNanoFTPCleanup@LIBXML2_2.4.30'
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlIOFTPOpen@LIBXML2_2.4.30'
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlIOFTPClose@LIBXML2_2.4.30'
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlIOFTPRead@LIBXML2_2.4.30'
> > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> > `xmlNanoFTPInit@LIBXML2_2.4.30'
> > collect2: error: ld returned 1 exit status
> > make[3]: *** 
> > [/home/rene/LibreOffice/git/libreoffice-24-2/solenv/gbuild/LinkTarget.mk:853:
> >  
> > /home/rene/LibreOffice/git/libreoffice-24-2/workdir/LinkTarget/Executable/pdfverify]
> >  Error 1
> >
> > Do we have removed symbols/removed versions here? (libxmlsec.so.1 was
> > not rebuilt)
>
> After a rebuild of libxmlsec1 this link succeeds...
>

I see that you've committed this patch[1] to libreoffice, does this
mean I can proceed to upload this version of libxml2 to unstable
without further action? Or is there anything else I should coordinate
with you to prevent breakage?


Regards,
Aron Xu

[1]https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/56d340483b0285c079c7ac08ddf441457d40b955

Bug#1052838: [debian-mysql] Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1

[Otto Kekäläinen]

Hi!

> The ci.debian.net results for mariadb seem to be very flaky lately (on
> amd64 they fail roughly 9/10) since version 1:10.11.6-1. Might be
> related (although the failure is different). i386 and arm64 seem to be
> exceptions.

No - the current CI failures for MariaDB are unrelated and not due to
this local port issue.

(Current MariaDB failures are partly due to OpenSSL API text change in
https://github.com/openssl/openssl/commit/81b741f68984 and partfly due
to upstream bug https://jira.mariadb.org/browse/MDEV-32843 - both
issues has known fixes, just a matter of dev time to commit and push)

Bug#1058890: more tests

[Dr . André Desgualdo Pereira]

If I use "echo mem > /sys/power/state" instead of systemctl to suspend, the 
result is the same, ie, the notebook doesn't seem to fully wake up, when trying 
to wake up from suspend, the screen stays black.
The CAPS LOCK led doesn't change when pressing the CAPS LOCK button, but the 
computer can shutdown with "Alt + SysRq + B". 

-- 
André Desgualdo Pereira

Bug#1059441: RFS: rlvm/0.14-5.2 [NMU] [RC] -- RealLive virtual machine clone

[Bo YU]

Package: sponsorship-requests
Severity: important

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

 * Package name : rlvm
   Version  : 0.14-5.2
   Upstream contact : Elliot Glaysher 
 * URL  : http://rlvm.net
 * License  : BSD-3-clause-variant-2, BSD-3-clause-variant-6, 
BSD-3-clause-variant1, Expat, LGPL-2.1+, jagarl, BSD-3-clause-variant-5, 
BSD-2-clause, BSD-3-clause-variant-10, BSD-3-clause-variant-8, GPL-3+, GPL-2+, 
LGPL-2+, Expat-variant-1, BSD-3-clause-variant-4, BSD-3-clause-variant3, 
BSD-3-clause-variant-9
 * Vcs  : [fill in URL of packaging vcs]
   Section  : games

The source builds the following binary packages:

  rlvm - RealLive virtual machine clone

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rlvm/rlvm_0.14-5.2.dsc

Changes since the last upload:

 rlvm (0.14-5.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix ftbfs on boost1.83. (Closes: #1056017)
   * Use libboost-timer-dev instead of libboost-date-time-dev.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1057679: dracut fix problem

[progserega]

Thank you very match, Bastian Blank!

Dracut help fix this issue:
0. add cache to root logical volume.
1. I install dracut (it remove initramfs-tools)
2. add modules lvm and mdadm to dracut
3. update all initrd-images by dracut
4. add GRUB_CMDLINE_LINUX="rd.md=1 rd.md.conf=1 rd.auto=1" to /etc/default/grub 
(becouse system not boot after switch to dracut in my case) for init mdadm by 
initramfs at boot.
5. dpgk-reconfigure grub-pc
6. reboot twice
7. after all reboot - dirty cache for root lv was normal.

dracut + some tuning = fix dirty cache "bug" on root.

But I think this problem was not in lvmcache, but in initramfs-tools, which not 
correct unmount root? So lvmcache simply show this problem... And without 
lvmcache but with initramfs-tools - at any reboot root was not correctly 
unmount?

-- 

Bug#1059426: bookworm-pu: package haproxy/2.6.12-1+deb12u1

[Moritz Muehlenhoff]

On Mon, Dec 25, 2023 at 10:32:41AM +0100, Tobias Frost wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: hapr...@packages.debian.org
> X-Debbugs-Cc: t...@security.debian.org
> Control: affects -1 + src:haproxy
> 
> Hi,
> 
> For ELTS I was fixing haproxy's CVES CVE-2023-40225 and CVE-2023-45539,
> and I also like to fix those for stable and oldstable.

Please don't just go ahead and prepare updates for bullseye/bookworm
without prior coordination.

haproxy is listed in data/dsa-needed.txt as Salvatore as working on it
(and in fact updates are already uploaded/built on security-master)

Cheers,
Moritz

Bug#1059440: Nuspell missing man page

[Otto Kekäläinen]

Package: nuspell
Version: 5.1.4-1
Severity: normal
Tags: upstream

While trying to learn how to use Nuspell I noticed that it has no man page in
Debian (https://dyn.manpages.debian.org/jump?q=nuspell yields 'page not
found'). The README about the tool usage at
https://github.com/nuspell/nuspell/blob/master/README.md#using-the-command-
line-tool is only 4 lines long.

However, I did find
https://manpages.ubuntu.com/manpages/jammy/en/man1/nuspell.1.html. I don't now
where the source of that file is (wasn't able to find it on Launchpad).

I would like to suggest to have this man page source included as a patch in
Debian, and also upstreamed.

I am sure there are many more like me who are evaluating if they should migrate
from Hunspell to Nuspell and thus how exactly to do it, and how to use Nuspell.
That man page was very useful for me.

Thanks!



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

Kernel: Linux 5.15.0-88-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Free Ekanayaka]

Hello Raphael,

Raphael Hertzog  writes:

> Hello,
>
> On Sat, 21 Oct 2023, Free Ekanayaka wrote:
>> raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1,
>> which is waiting in the NEW queue.
>
> This one is available in unstable now. I would really like to see incus
> in unstable/testing and even in bookworm-backports at some point.

Yes, Mathias and I are working on uploading Incus to unstable. You can
follow the progress here:

https://wiki.debian.org/Incus

we're definitely close-ish now, but there are still a few things to do.

> We are considering to use LXD in the context of debusine[1]

Very nice project, I didn't know about it, thanks.

> but given the latest developments with Canonical, it would make sense
> for us to start directly with incus.

Yeah, I'd of course recommend that. Although if you really need to make
progress now, using LXD and then migrating to Incus shouldn't be hard,
both in terms of scripts/code and of existing deployments. YMMV.

> I think it would make sense to upload current (non-LTS) versions in
> unstable right ahead and then stick to the LTS version once they have
> released it.

That's the plan indeed.

Free

Bug#1059439: jsonnet: add loongarch64 support

[zhangdandan]

Source: jsonnet
Version: 0.20.0+ds-1
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the jsonnet failed on my local loong64 rootfs environment.
We need to add build support for loong64 in debian/control.
At the same time, we also need to add the loongarch64 support in jsonnet 
source code.


Please consider the patch I have attached.
The jsonnet source package was compiled successfully on my local env and 
the tests passed.

```
8: /home/jsonnet-0.20.0+ds/test_suite/run_tests.sh: All 157 test scripts 
pass.

8/8 Test #8: regression_test ..   Passed   34.02 sec
100% tests passed, 0 tests failed out of 8
Total Test time (real) =  34.04 sec
```

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru jsonnet-0.20.0+ds/debian/control jsonnet-0.20.0+ds/debian/control
--- jsonnet-0.20.0+ds/debian/control2023-07-30 13:33:59.0 +
+++ jsonnet-0.20.0+ds/debian/control2023-07-30 13:37:07.0 +
@@ -11,7 +11,7 @@
 Rules-Requires-Root: no
 
 Package: jsonnet
-Architecture: amd64 arm64 armhf i386 armel ppc64el riscv64
+Architecture: amd64 arm64 armhf i386 armel loong64 ppc64el riscv64
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: data templating language
  A data templating language for app and tool developers
@@ -37,7 +37,7 @@
 
 Package: libjsonnet0
 Section: libs
-Architecture: amd64 arm64 armhf i386 armel ppc64el riscv64
+Architecture: amd64 arm64 armhf i386 armel loong64 ppc64el riscv64
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: data templating language (lib)
  A data templating language for app and tool developers
@@ -63,7 +63,7 @@
 
 Package: libjsonnet-dev
 Section: libdevel
-Architecture: amd64 arm64 armhf i386 armel ppc64el riscv64
+Architecture: amd64 arm64 armhf i386 armel loong64 ppc64el riscv64
 Depends: ${misc:Depends}, libjsonnet0 (= ${binary:Version})
 Description: data templating language (devel)
  A data templating language for app and tool developers
@@ -89,7 +89,7 @@
 
 Package: python3-jsonnet
 Section: python
-Architecture: amd64 arm64 armhf i386 armel ppc64el riscv64
+Architecture: amd64 arm64 armhf i386 armel loong64 ppc64el riscv64
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends},
 Description: data templating language (Python)
  A data templating language for app and tool developers
diff -Nru jsonnet-0.20.0+ds/debian/patches/add-loongarch64-support.patch 
jsonnet-0.20.0+ds/debian/patches/add-loongarch64-support.patch
--- jsonnet-0.20.0+ds/debian/patches/add-loongarch64-support.patch  
1970-01-01 00:00:00.0 +
+++ jsonnet-0.20.0+ds/debian/patches/add-loongarch64-support.patch  
2023-07-30 13:37:07.0 +
@@ -0,0 +1,28 @@
+Description: add loongarch64 support 
+Last-Update: 2023-12-25
+
+--- 
jsonnet-0.20.0+ds.orig/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/cpu.hpp
 jsonnet-0.20.0+ds/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/cpu.hpp
+@@ -91,6 +91,11 @@
+ #   define C4_WORDSIZE 8
+ #   define C4_BYTE_ORDER _C4EL
+ 
++#elif defined(__loongarch64)
++#   define C4_CPU_LOONGARCH64
++#   define C4_WORDSIZE 8
++#   define C4_BYTE_ORDER _C4EL
++
+ #elif defined(SWIG)
+ #else
+ #   error "unknown CPU architecture"
+--- 
jsonnet-0.20.0+ds.orig/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/fast_float/include/fast_float/float_common.h
 
jsonnet-0.20.0+ds/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/fast_float/include/fast_float/float_common.h
+@@ -8,7 +8,7 @@
+ #if (defined(__x86_64) || defined(__x86_64__) || defined(_M_X64)   \
+|| defined(__amd64) || defined(__aarch64__) || defined(_M_ARM64) \
+|| defined(__MINGW64__)  \
+-   || defined(__s390x__)\
++   || defined(__s390x__) || defined(__loongarch64)  \
+|| (defined(__ppc64__) || defined(__PPC64__) || defined(__ppc64le__) \
+|| defined(__PPC64LE__) || defined(__riscv) && __riscv_xlen == 64))
+ #define FASTFLOAT_64BIT
diff -Nru jsonnet-0.20.0+ds/debian/patches/series 
jsonnet-0.20.0+ds/debian/patches/series
--- jsonnet-0.20.0+ds/debian/patches/series 2022-07-31 13:53:10.0 
+
+++ jsonnet-0.20.0+ds/debian/patches/series 2023-07-30 13:37:07.0 
+
@@ -1,3 +1,4 @@
 0001-fix-FTBFS-on-several-release-architectures.patch
 0002-fix-compile-error-in-armel.patch
 0003-add-support-riscv64.patch
+add-loongarch64-support.patch

Bug#1059438: ITP: ruby-deb-version, A port of "Debian Version" comparison function to Ruby

[Ajayi Olatunji O.]

Package: wnpp
Severity: wishlist
Owner: Ajayi Olatunji
X-Debbugs-CC:debian-de...@lists.debian.org

* Package name: ruby-deb-version

   Version : 1.0.2
   Upstream Author : Nemo

* URL : https://github.com/captn3m0/ruby-deb-version#readme
* License : MIT
   Programming Lang:Ruby
   Description : A port of Debian Version comparison to Ruby.

 This package is a build dependency for ruby-arr-pm, a package required
in gitlab 16.6.2

Bug#1059437: mrtg does not aquire data from /usr/sbin/smartctl after upgrade

[DM]

Package: mrtg
Version: 2.17.10-5
Severity: important

Dear Maintainer, after upgrade from Deabian 10 till Debian 12 through Debian 11 
mrtg.conf was moved to another location. I made apropriate adjustments 
in new tocation of config file. All graphics was working except data about hdd 
disk temperature.
Previously worked Targets does not work.
It's get data from smartctl:
Target[hdd_temp_sda]: `/usr/sbin/smartctl -a -s on /dev/disk/by-id/ata-sda | 
grep Temp | awk -F " " '{print $10}'`
After upgrade all such targets get no data and graphics are not built.
Directly runned command are okay. Data are being getted.
As I think, such problem appears because smartctl takes some time. And when 
mrtg were launched through crontab it were normal.
And now it terminate early than it gets result.
I tried to make temp location for data, but it didn't fix problem.
Try fix with this:
crontab -l
  */5 * * * * /usr/local/sbin/mrtg_smartctl_scan.sh 2>&1 >/dev/null
cat /usr/local/sbin/mrtg_smartctl_scan.sh
  #!/usr/bin/env bash
  /usr/sbin/smartctl -a -s on /dev/disk/by-id/ata-sd1 | grep Temp | awk -F " " 
'{print $10}'> /tmp/ata_1
in mrtg.conf
  Target[hdd_temp_sdb]: `/usr/bin/cat /tmp/ata_1`
But it doesn't work.
I tried to check getting data with such setup:
  Target[hdd_temp_sda]: `/usr/bin/cat /tmp/ata_1; echo 1; echo 2; echo 3;`
And it showed that first data a missed.
So how can it be fixed? Or I should reinstall Debian 10?

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-13-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mrtg depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u2
ii  libgd3 2.3.3-9
ii  libsnmp-session-perl   1.14~git20221124T101957-1
ii  perl   5.36.0-7

mrtg recommends no packages.

Versions of packages mrtg suggests:
ii  apache2 [httpd] 2.4.57-2
ii  lynx [www-browser]  2.9.0dev.12-1
pn  mrtg-contrib

-- Configuration Files:
/etc/cron.d/mrtg [Errno 2] Нет такого файла или каталога: '/etc/cron.d/mrtg'
/etc/mrtg.cfg [Errno 2] Нет такого файла или каталога: '/etc/mrtg.cfg'
/etc/mrtg/mrtg.cfg [Errno 13] Отказано в доступе: '/etc/mrtg/mrtg.cfg'

-- debconf information:
* mrtg/remove_cron: false
* mrtg/create_www: false
  mrtg/fix_permissions: false
* mrtg/conf_mods: true

-- debsums errors found:
debsums: changed file /lib/systemd/system/mrtg.service (from mrtg package)

Bug#926388: status of this bug: #926388 / Stop adding the DebianEdu root CA to NSS shared database

[Holger Levsen]

On Mon, Dec 25, 2023 at 01:06:55PM +0100, Guido Berhoerster wrote:
> This commit is currently part of a draft MR: 
> https://salsa.debian.org/debian-edu/debian-edu-config/-/merge_requests/28
> The fix is only applicable for unstable and cannot be backported to bookworm.

thanks for the clarifications, Guido!


-- 
cheers,
Holger

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

Everyone is entitled to their own opinion, but not their own facts.


signature.asc
Description: PGP signature

Bug#926388: status of this bug: #926388 / Stop adding the DebianEdu root CA to NSS shared database

[Guido Berhoerster]

Am 25.12.23 um 12:06 schrieb Holger Levsen:
> control: tags -1 - pending
> thanks
> 
> hi,
> 
> #926388 "let Firefox trust /etc/ssl/certs/ca-certificates.crt"
> has been marked as pending with
> https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/4b63838ab777314d4611195f0be58c29203b8f1a
> but this commit was never merged into the master branch, thus I'm
> removing the pending tag now.
> 
> Do we need this for bookworm or is just cruft?

This commit is currently part of a draft MR: 
https://salsa.debian.org/debian-edu/debian-edu-config/-/merge_requests/28

The fix is only applicable for unstable and cannot be backported to bookworm.

-- 
Guido Berhoerster

Bug#1056017: rlvm: FTBFS: boost1.83 transition

[Bo YU]

Source: rlvm
Version: 0.14-5.1
Followup-For: Bug #1056017
Tags: patch

Dear Maintainer,

I cost some time to fix the issue and patch attached. Please review it.

In order to fix the RC bug ASAP, I may do a NMU to mentor and find a
sponsor to upload it. Please feel free to break the process if there is
any issue.


-- 
Regards,
--
  Bo YU

diff -Nru rlvm-0.14/debian/changelog rlvm-0.14/debian/changelog
--- rlvm-0.14/debian/changelog  2021-10-04 03:16:33.0 +0800
+++ rlvm-0.14/debian/changelog  2023-12-25 15:40:26.0 +0800
@@ -1,3 +1,11 @@
+rlvm (0.14-5.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs on boost1.83. (Closes: #1056017)
+  * Use libboost-timer-dev instead of libboost-date-time-dev.
+
+ -- Bo YU   Mon, 25 Dec 2023 15:40:26 +0800
+
 rlvm (0.14-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rlvm-0.14/debian/control rlvm-0.14/debian/control
--- rlvm-0.14/debian/control2021-10-04 03:16:13.0 +0800
+++ rlvm-0.14/debian/control2023-12-25 15:40:26.0 +0800
@@ -4,7 +4,6 @@
 Maintainer: Ying-Chun Liu (PaulLiu) 
 Build-Depends: debhelper (>= 10),
google-mock,
-   libboost-date-time-dev,
libboost-dev,
libboost-filesystem-dev,
libboost-iostreams-dev,
@@ -12,6 +11,7 @@
libboost-python-dev,
libboost-serialization-dev,
libboost-thread-dev,
+   libboost-timer-dev,
libfreetype6-dev,
libgl1-mesa-dev,
libglew-dev,
diff -Nru rlvm-0.14/debian/patches/005_fix_boost_ftbfs.patch 
rlvm-0.14/debian/patches/005_fix_boost_ftbfs.patch
--- rlvm-0.14/debian/patches/005_fix_boost_ftbfs.patch  1970-01-01 
07:30:00.0 +0730
+++ rlvm-0.14/debian/patches/005_fix_boost_ftbfs.patch  2023-12-25 
15:40:26.0 +0800
@@ -0,0 +1,65 @@
+Description: fix ftbfs on boost1.83 
+Author: Bo YU  
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056017 
+Last-Update: 2023-12-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/vendor/wxInclude.cpp
 b/vendor/wxInclude.cpp
+@@ -18,7 +18,7 @@
+ #include 
+ #include 
+ #include 
+-#include 
++#include 
+ 
+ namespace po = boost::program_options;
+ namespace fs = boost::filesystem;
+@@ -207,7 +207,7 @@
+ if ( opt.count( "input-file" ) || opt.count( "input-type" ) ) {
+   if ( opt.count( "output-file" ) ) { 
+   /* Create timer */
+-  boost::timer timer;
++  boost::timer::cpu_timer timer;
+ 
+   /* Create output file */
+   std::string headername( opt[ "output-file" 
].as() );
+@@ -361,7 +361,7 @@
+ 
+   /* Show status */
+ if (!silent)
+-  std::cout << "Build  : " << timer.elapsed() << "s needed 
for conversion of " << list.size() << " files." << std::endl;
++  std::cout << "Build  : " << timer.elapsed().user<< "s 
needed for conversion of " << list.size() << " files." << std::endl;
+   } else {
+   throw std::invalid_argument( "No output 
defined!" );
+   }
+--- a/SConstruct
 b/SConstruct
+@@ -81,6 +81,7 @@
+   "boost_iostreams",
+   "boost_filesystem",
+   "boost_date_time",
++  "boost_timer",
+   "boost_thread",
+   "boost_system"])
+ 
+--- a/src/systems/base/system.h
 b/src/systems/base/system.h
+@@ -33,6 +33,7 @@
+ #include 
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+--- a/src/utilities/file.h
 b/src/utilities/file.h
+@@ -31,6 +31,7 @@
+ #include 
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ 
diff -Nru rlvm-0.14/debian/patches/series rlvm-0.14/debian/patches/series
--- rlvm-0.14/debian/patches/series 2020-02-01 10:20:05.0 +0800
+++ rlvm-0.14/debian/patches/series 2023-12-25 15:37:58.0 +0800
@@ -2,3 +2,4 @@
 002_include-iostream.patch
 003_use_pkg-config_for_freetype2.patch
 004_port_to_python3.patch
+005_fix_boost_ftbfs.patch


signature.asc
Description: PGP signature

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Raphael Hertzog]

Hello,

On Sat, 21 Oct 2023, Free Ekanayaka wrote:
> raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1,
> which is waiting in the NEW queue.

This one is available in unstable now. I would really like to see incus
in unstable/testing and even in bookworm-backports at some point.

We are considering to use LXD in the context of debusine[1] but given the
latest developments with Canonical, it would make sense for us to start
directly with incus.

I think it would make sense to upload current (non-LTS) versions in
unstable right ahead and then stick to the LTS version once they have
released it.

Cheers,

[1] https://freexian-team.pages.debian.net/debusine/
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1059436: lxappearance segmentation fault

[Karine Crèvecœur]

Package: lxappearance
Version: 0.6.3-5
Severity: grave

Hi,

Wen I start lxappearance that leads to the following messages:

(lxappearance:10707): Gtk-WARNING **: 12:14:33.248: Theme parsing error: 
:1:17: Expected a string.
segmentation fault

I tried to not use theme at all, I moved the ~/.config/gtk-* to another
place (under ~/dot.config/ to be precise). The messages are the same.

With gdb I saw the issue came in cairo_surface_get_content () from
/lib/x86_64-linux-gnu/libcairo.so.2

I tried to run the application with:
  $ LANG=C lxpappearance
It was the same issue.

system information:
debian/sid
architecture amd64

kernel: linux 6.6.8 (uname -r)
Locale: LANG=fr_FR.utf8
shell: /bin/bash
init: systemd

apt-cache depends lxappearance:
  Dépend: libc6
  Dépend: libdbus-1-3
  Dépend: libgdk-pixbuf-2.0-0
  Dépend: libglib2.0-0
  Dépend: libgtk-3-0
  Dépend: libx11-6
  Recommande: lxde-settings-daemon
lxsession

Cheers.
--
Karine Crévecœur

Bug#1059431: linux: FTBFS on mips64el: make[3]: *** [/<>/Makefile:246: __sub-make] Error 2

[Bastian Blank]

On Mon, Dec 25, 2023 at 11:38:17AM +0100, Sebastian Ramacher wrote:
> (sorry, I wasn't able to find an error, so this is the end of the build
> log.)

The error is:

| Relocations overflow available space!
| Please adjust CONFIG_RELOCATION_TABLE_SIZE to at least 0x001d3000
| make[6]: *** [/<>/arch/mips/Makefile.postlink:28: vmlinux] Error 
1
| make[6]: *** Deleting file 'vmlinux'
| make[5]: *** [/<>/scripts/Makefile.vmlinux:37: vmlinux] Error 2
| make[4]: *** [/<>/Makefile:1176: vmlinux] Error 2
| make[4]: *** Waiting for unfinished jobs

Bastian

-- 
The sight of death frightens them [Earthers].
-- Kras the Klingon, "Friday's Child", stardate 3497.2

Bug#1059435: golang-github-go-xorm-core: superseded by xorm.io/xorm (golang-xorm-xorm)

[Maytham Alsudany]

Source: golang-github-go-xorm-core
Severity: important

Dear Maintainer,

This package has been superseded by xorm.io/xorm (I'm planning on
packaging this). Upstream's Gitea repo has been archived.

I believe you should open an RM request for this package.

Kind regards,
Maytham

Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...

[Rafael Laboissière]

* Rafael Laboissière  [2023-12-22 04:36]:


* Sébastien Villemot  [2023-12-21 15:23]:


Le jeudi 21 décembre 2023 à 08:49 +0100, Rafael Laboissière a écrit :

* Santiago Vila  [2023-12-20 22:03]:


El 20/12/23 a las 21:08, Rafael Laboissière escribió:

HOME := $(shell mktemp -d)

so that the same directory is never used twice between consecutive builds.


Yes, this is a much better solution. Thanks for the 
suggestion. I am just wondering: is there a simple way to 
delete the temporary directory after he build is finished ?


I don't know, but most people build packages in 
temporary/disposable chroots, so if the package just writes a 
few files which are also small, it's not something for which I 
would worry too much.


Yes, it not really a worrisome issue. However, I have just noticed 
that the solution that you proposed with mktemp is a little bit 
intrusive. Indeed, a new temporary directory is created at each 
invocation of debain/rules, such that I end up with five 
/tmp/tmp.* directories after package building, with only the last 
one being actually used. I will try another approach, probably by 
changing the dh_octave_check script, which is the one that 
eventually needs a writable $HOME directory.


Note that within the context of a shell script, the following 
ensures that the directory is automatically deleted upon exit:


tmpdir=$(mktemp -d) 
cleanup () 
{ 
   rm -rf "${tmpdir}" 
} 
trap cleanup EXIT


Thanks, Sébastien.

I think that it is possible to do something similar in Perl (the 
language in which dh_octave_check is written) by using the %SIG hash. 
I will take a look at it.


I got confused, sorry. Actually, dh_octave_check is written in Shell.

I have uploaded version 1.6.0 of dh-octave with the needed changes.

Best,

Rafael

Bug#926388: status of this bug: #926388 / Stop adding the DebianEdu root CA to NSS shared database

[Holger Levsen]

control: tags -1 - pending
thanks

hi,

#926388 "let Firefox trust /etc/ssl/certs/ca-certificates.crt"
has been marked as pending with
https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/4b63838ab777314d4611195f0be58c29203b8f1a
but this commit was never merged into the master branch, thus I'm
removing the pending tag now.

Do we need this for bookworm or is just cruft?


-- 
cheers,
Holger

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

We can send billionaires to space but not kids to fully funded public schools.


signature.asc
Description: PGP signature

Bug#1059434: ITP: vibes -- visualizer for intervals and boxes

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissière 
X-Debbugs-Cc: debian-de...@lists.debian.org

 * Package name: vibes
   Version : 0.2.3
   Upstream Contact: https://github.com/ENSTABretagneRobotics
 * URL : http://enstabretagnerobotics.github.io/VIBES/
 * License : GPL-3+, LGPL-3+
   Programming Lang: C++
   Description : visualizer for intervals and boxes

VIBes is a visualization system that aims at providing people working 
with interval methods a way to display results (boxes, pavings), 
without worrying with GUI programming. It provides drawing functions 
accessible from a lot of programming languages, without complex 
installation and library dependencies. The main design goal of VIBes 
is to be cross-platform, available from different programming 
languages, simple to set-up, easy to port to a new language.

A preliminary version of the package is available at 
https://salsa.debian.org/debian/vibes

This package is a dependency for the octave-vibes package, which was 
part of the Debian distribution, but is useless without the 
VIBes-viewer.

Bug#1059433: RFP: gruvbox-gtk-theme -- GTK+ gruvbox theme

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

* Package name: gruvbox-gtk-theme
  Version : git snapshot
  Upstream Contact: Fausto-Korpsvart
* URL : https://github.com/Fausto-Korpsvart/Gruvbox-GTK-Theme
* License : GPL-3
  Programming Lang: CSS
  Description : GTK+ gruvbox theme

gtk-gruvbox is a really nice GTK theme i use and would like to see it it
debian. It comes with a dark and light variant and bordered/borderless
variant. 

best,

werdahias

Bug#1059432: openafs: install afsd into /usr/sbin

[Chris Hofstaedtler]

Source: openafs
Version: 1.8.10-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi!

openafs-client installs afsd into /sbin. For the ongoing Debian
UsrMerge effort [1] it should move (back?) into /usr/sbin in the trixie
cycle.

I'm attaching a possible patch for your convenience. It looks good
to me, but since I do not have an AFS setup, I have not tested it.

Please still read the wiki page on moving files, especially if you
intend to backport to bookworm or earlier.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru openafs-1.8.10/debian/changelog openafs-1.8.10/debian/changelog
--- openafs-1.8.10/debian/changelog	2023-12-24 06:56:47.0 +0100
+++ openafs-1.8.10/debian/changelog	2023-12-25 11:39:19.0 +0100
@@ -1,3 +1,11 @@
+openafs (1.8.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move afsd (back) into /usr/sbin (Closes: #-1).
+Update path in init script and systemd service unit.
+
+ -- Chris Hofstaedtler   Mon, 25 Dec 2023 11:39:19 +0100
+
 openafs (1.8.10-2) unstable; urgency=medium
 
   * Update lintian overrides to use appropriate context.
diff -Nru openafs-1.8.10/debian/openafs-client.init openafs-1.8.10/debian/openafs-client.init
--- openafs-1.8.10/debian/openafs-client.init	2023-12-22 23:47:52.0 +0100
+++ openafs-1.8.10/debian/openafs-client.init	2023-12-25 11:38:25.0 +0100
@@ -34,7 +34,7 @@
 DKMSDIR=${DKMSDIR:-$MODULEROOT/updates/dkms}
 
 # Exit if the package is not installed.
-[ -x /sbin/afsd ] || exit 0
+[ -x /usr/sbin/afsd ] || exit 0
 
 # Define LSB log_* functions and get other support infrastructure.
 . /lib/lsb/init-functions
@@ -137,14 +137,14 @@
 
 # Start afsd.  Be careful not to start it if another one is already running,
 # as that has a bad tendency to hang the system.  Earlier versions of the
-# openafs-client package put afsd in /usr/sbin.
+# openafs-client package put afsd in /sbin.
 start_client() {
 if pidof /sbin/afsd >/dev/null || pidof /usr/sbin/afsd >/dev/null ; then
 echo "."
 else
 choose_afsd_options
 echo " afsd."
-start-stop-daemon --start --quiet --exec /sbin/afsd -- $AFSD_OPTIONS
+start-stop-daemon --start --quiet --exec /usr/sbin/afsd -- $AFSD_OPTIONS
 fi
 
 # From /etc/openafs/afs.conf.client, whether to enable fcrypt encryption.
@@ -196,7 +196,7 @@
 
 case "$1" in 
 start)
-if is_on $AFS_CLIENT && test -x /sbin/afsd ; then
+if is_on $AFS_CLIENT && test -x /usr/sbin/afsd ; then
 echo -n "Starting AFS services:"
 if load_client ; then
 start_client
@@ -210,7 +210,7 @@
 ;;
 
 force-start)
-if test -x /sbin/afsd ; then
+if test -x /usr/sbin/afsd ; then
 echo -n "Starting AFS services:"
 if load_client ; then
 start_client
diff -Nru openafs-1.8.10/debian/openafs-client.install openafs-1.8.10/debian/openafs-client.install
--- openafs-1.8.10/debian/openafs-client.install	2023-12-22 23:47:52.0 +0100
+++ openafs-1.8.10/debian/openafs-client.install	2023-12-25 11:36:29.0 +0100
@@ -28,7 +28,7 @@
 debian/tmp/usr/sbin/fstrace usr/sbin
 debian/tmp/usr/sbin/rmtsysd usr/sbin
 
-debian/tmp/usr/sbin/afsdsbin
+debian/tmp/usr/sbin/afsdusr/sbin
 
 debian/openafs-client-precheckusr/share/openafs
 debian/openafs-client-postcheckusr/share/openafs
diff -Nru openafs-1.8.10/debian/openafs-client-precheck openafs-1.8.10/debian/openafs-client-precheck
--- openafs-1.8.10/debian/openafs-client-precheck	2023-12-22 23:47:52.0 +0100
+++ openafs-1.8.10/debian/openafs-client-precheck	2023-12-25 11:39:08.0 +0100
@@ -46,7 +46,7 @@
 }
 
 # Exit if the package is not installed.
-[ -x /sbin/afsd ] || exit 1
+[ -x /usr/sbin/afsd ] || exit 1
 
 # Do some other checks for prerequisites
 if ! [ -f "${CACHEINFO}" ]; then
diff -Nru openafs-1.8.10/debian/openafs-client.service openafs-1.8.10/debian/openafs-client.service
--- openafs-1.8.10/debian/openafs-client.service	2023-12-22 23:47:52.0 +0100
+++ openafs-1.8.10/debian/openafs-client.service	2023-12-25 11:36:47.0 +0100
@@ -9,7 +9,7 @@
 Type=forking
 RemainAfterExit=true
 ExecStartPre=/usr/share/openafs/openafs-client-precheck
-ExecStart=/sbin/afsd $AFSD_ARGS
+ExecStart=/usr/sbin/afsd $AFSD_ARGS
 ExecStartPost=/usr/bin/fs setcrypt $AFS_SETCRYPT
 ExecStartPost=/usr/bin/fs sysname $AFS_SYSNAME
 ExecStop=/bin/grep -qv ^1$ /proc/sys/kernel/modules_disabled

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Martin Pitt [2023-12-25 11:25 +0100]:
> The new upstream release plus regression fix have propagated to testing, to
> Ubuntu devel, and also is progressing well into Fedora. By now the tests have
> validated it enough for me to be confident in the fixes.
>
> I prepared the security update for Debian 12 bookworm, including a debdiff:
> https://people.debian.org/~mpitt/tmp/

This contains the update for Debian 11 bullseye (oldstable) as well now.

> I'll coordinate the update to oldstable with Sean (see the other thread).

I meant oldoldstable (Debian 10 buster), sorry. I'll leave that to Sean.

Thanks,

Martin

Bug#1059431: linux: FTBFS on mips64el: make[3]: *** [/<>/Makefile:246: __sub-make] Error 2

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=linux&arch=mips64el&ver=6.6.8-1&stamp=1703469825&raw=0

  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/nfc/nci/nci.ko net/nfc/nci/nci.o 
net/nfc/nci/nci.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/nfc/nci/nci.ko
# LD [M]  net/nfc/nfc_digital.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/nfc/nfc_digital.ko net/nfc/nfc_digital.o 
net/nfc/nfc_digital.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/nfc/nfc_digital.ko
# LD [M]  net/psample/psample.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/psample/psample.ko net/psample/psample.o 
net/psample/psample.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/psample/psample.ko
# LD [M]  net/ife/ife.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/ife/ife.ko net/ife/ife.o net/ife/ife.mod.o;  
/usr/bin/make -f /<>/arch/mips/Makefile.postlink net/ife/ife.ko
# LD [M]  net/openvswitch/openvswitch.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/openvswitch/openvswitch.ko 
net/openvswitch/openvswitch.o net/openvswitch/openvswitch.mod.o;  /usr/bin/make 
-f /<>/arch/mips/Makefile.postlink net/openvswitch/openvswitch.ko
# LD [M]  net/openvswitch/vport-vxlan.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/openvswitch/vport-vxlan.ko 
net/openvswitch/vport-vxlan.o net/openvswitch/vport-vxlan.mod.o;  /usr/bin/make 
-f /<>/arch/mips/Makefile.postlink net/openvswitch/vport-vxlan.ko
# LD [M]  net/openvswitch/vport-geneve.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/openvswitch/vport-geneve.ko 
net/openvswitch/vport-geneve.o net/openvswitch/vport-geneve.mod.o;  
/usr/bin/make -f /<>/arch/mips/Makefile.postlink 
net/openvswitch/vport-geneve.ko
# LD [M]  net/openvswitch/vport-gre.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/openvswitch/vport-gre.ko 
net/openvswitch/vport-gre.o net/openvswitch/vport-gre.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/openvswitch/vport-gre.ko
# LD [M]  net/vmw_vsock/vsock.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/vmw_vsock/vsock.ko net/vmw_vsock/vsock.o 
net/vmw_vsock/vsock.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/vmw_vsock/vsock.ko
# LD [M]  net/vmw_vsock/vsock_diag.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/vmw_vsock/vsock_diag.ko net/vmw_vsock/vsock_diag.o 
net/vmw_vsock/vsock_diag.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink net/vmw_vsock/vsock_diag.ko
# LD [M]  net/vmw_vsock/vmw_vsock_virtio_transport.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/vmw_vsock/vmw_vsock_virtio_transport.ko 
net/vmw_vsock/vmw_vsock_virtio_transport.o 
net/vmw_vsock/vmw_vsock_virtio_transport.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink 
net/vmw_vsock/vmw_vsock_virtio_transport.ko
# LD [M]  net/vmw_vsock/vmw_vsock_virtio_transport_common.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/vmw_vsock/vmw_vsock_virtio_transport_common.ko 
net/vmw_vsock/vmw_vsock_virtio_transport_common.o 
net/vmw_vsock/vmw_vsock_virtio_transport_common.mod.o;  /usr/bin/make -f 
/<>/arch/mips/Makefile.postlink 
net/vmw_vsock/vmw_vsock_virtio_transport_common.ko
# LD [M]  net/vmw_vsock/vsock_loopback.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/vmw_vsock/vsock_loopback.ko 
net/vmw_vsock/vsock_loopback.o net/vmw_vsock/vsock_loopback.mod.o;  
/usr/bin/make -f /<>/arch/mips/Makefile.postlink 
net/vmw_vsock/vsock_loopback.ko
# LD [M]  net/nsh/nsh.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/nsh/nsh.ko net/nsh/nsh.o net/nsh/nsh.mod.o;  
/usr/bin/make -f /<>/arch/mips/Makefile.postlink net/nsh/nsh.ko
# LD [M]  net/hsr/hsr.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/hsr/hsr.ko net/hsr/hsr.o net/hsr/hsr.mod.o;  
/usr/bin/make -f /<>/arch/mips/Makefile.postlink net/hsr/hsr.ko
# LD [M]  net/qrtr/qrtr.ko
  ld -r -m elf64ltsmip -z noexecstack --no-warn-rwx-segments --build-id=sha1  
-T scripts/module.lds -o net/qrtr/qrtr.ko net/qrtr

Bug#1059430: nvme-cli: install systemd unit files again into /usr

[Chris Hofstaedtler]

Source: nvme-cli
Version: 2.6-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi!

Your package previously moved systemd units into /lib, because of
missing debhelper support. For the ongoing Debian UsrMerge effort
[1] they need to move back into /usr/lib.

I'm attaching a patch to implement this, probably just reverting
what was done previously.

However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru nvme-cli-2.6/debian/changelog nvme-cli-2.6/debian/changelog
--- nvme-cli-2.6/debian/changelog	2023-10-04 14:53:26.0 +0200
+++ nvme-cli-2.6/debian/changelog	2023-12-25 11:16:45.0 +0100
@@ -1,3 +1,10 @@
+nvme-cli (2.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units again into /usr/lib/systemd/system. (Closes: #-1)
+
+ -- Chris Hofstaedtler   Mon, 25 Dec 2023 11:16:45 +0100
+
 nvme-cli (2.6-1) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru nvme-cli-2.6/debian/control nvme-cli-2.6/debian/control
--- nvme-cli-2.6/debian/control	2023-10-04 14:53:11.0 +0200
+++ nvme-cli-2.6/debian/control	2023-12-25 11:16:45.0 +0100
@@ -5,6 +5,7 @@
 Build-Depends:
  asciidoc,
  cmake,
+ debhelper (>= 13.11.6),
  debhelper-compat (= 13),
  flake8 ,
  isort ,
diff -Nru nvme-cli-2.6/debian/patches/debian/0002-meson-systemd.patch nvme-cli-2.6/debian/patches/debian/0002-meson-systemd.patch
--- nvme-cli-2.6/debian/patches/debian/0002-meson-systemd.patch	2023-10-04 14:52:52.0 +0200
+++ nvme-cli-2.6/debian/patches/debian/0002-meson-systemd.patch	1970-01-01 01:00:00.0 +0100
@@ -1,15 +0,0 @@
-Author: Daniel Baumann 
-Description: Overwriting systemd unit directory until debhelper supports /usr/lib/systemd/system (Closes: #1034232).
-
-diff -Naurp nvme-cli.orig/meson.build nvme-cli/meson.build
 nvme-cli.orig/meson.build
-+++ nvme-cli/meson.build
-@@ -26,7 +26,7 @@ sysconfdir = join_paths(prefixdir, get_option('sysconfdir'))
- 
- udevrulesdir   = join_paths(prefixdir, get_option('udevrulesdir'))
- dracutrulesdir = join_paths(prefixdir, get_option('dracutrulesdir'))
--systemddir = join_paths(prefixdir, get_option('systemddir'))
-+systemddir = '/lib/systemd/system'
- rundir = join_paths(prefixdir, get_option('rundir'))
- 
- ###
diff -Nru nvme-cli-2.6/debian/patches/series nvme-cli-2.6/debian/patches/series
--- nvme-cli-2.6/debian/patches/series	2023-10-04 14:52:52.0 +0200
+++ nvme-cli-2.6/debian/patches/series	2023-12-25 11:16:45.0 +0100
@@ -1,2 +1 @@
 debian/0001-meson-nose2.patch
-debian/0002-meson-systemd.patch

Bug#1059061: libssh: CVE-2023-6004

[Martin Pitt]

Hello Salvatore and all,

Salvatore Bonaccorso [2023-12-22 20:34 +0100]:
> On Fri, Dec 22, 2023 at 04:39:46PM +0100, Martin Pitt wrote:
> > Salvatore Bonaccorso [2023-12-22 13:20 +0100]:
> > > > However, the fix for CVE-2023-6004 caused a regression:
> > > > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> > > > I will monitor this, and include the fix in the security upload once it 
> > > > is
> > > > available (or presumably they'll do a 0.10.7). So if it's alright with 
> > > > you,
> > > > I'll delay the stable-security update for a few days.
> > >
> > > Rigth, it's not that pressing that we get updates out, so let's
> > > monitor this, have 0.10.7 uploaded and exposed as well then to
> > > unstable for a while and then look at bookworm-security. Btw, we will
> > > as well need bullseye-security.
> >
> > Ack. The fix landed upstream, and they said they won't do a 0.10.7 
> > immediately,
> > so I backported it and uploaded as 0.10.6-2 to sid. I threw the whole 
> > cockpit
> > integration test suite at it (which exercises libssh pretty thoroughly via
> > cockpit-ssh), and it is happy.
> >
> > I'll let that simmer for a few days to let it go into testing, and prepare 
> > the
> > security updates soon.
>
> Thanks, that sounds good.

The new upstream release plus regression fix have propagated to testing, to
Ubuntu devel, and also is progressing well into Fedora. By now the tests have
validated it enough for me to be confident in the fixes.

I prepared the security update for Debian 12 bookworm, including a debdiff:
https://people.debian.org/~mpitt/tmp/

Please feel free to dput it yourself, or I can do it if/when you ack.

I'll coordinate the update to oldstable with Sean (see the other thread).

Thanks,

Martin

Bug#1059429: nvme-stas: install systemd unit files again into /usr

[Chris Hofstaedtler]

Source: nvme-stas
Version: 2.3.1-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi!

Your package previously moved systemd units into /lib, because of
missing debhelper support. For the ongoing Debian UsrMerge effort
[1] they need to move back into /usr/lib.

I'm attaching a patch to implement this, probably just reverting
what was done previously.

However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier. The patch has
already been checked by a local dumat copy.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru nvme-stas-2.3.1/debian/changelog nvme-stas-2.3.1/debian/changelog
--- nvme-stas-2.3.1/debian/changelog	2023-12-10 11:42:55.0 +0100
+++ nvme-stas-2.3.1/debian/changelog	2023-12-25 11:19:28.0 +0100
@@ -1,3 +1,11 @@
+nvme-stas (2.3.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd unit files again into /usr/lib/systemd/system.
+(Closes: #-1)
+
+ -- Chris Hofstaedtler   Mon, 25 Dec 2023 11:19:28 +0100
+
 nvme-stas (2.3.1-1) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru nvme-stas-2.3.1/debian/control nvme-stas-2.3.1/debian/control
--- nvme-stas-2.3.1/debian/control	2023-12-10 11:38:24.0 +0100
+++ nvme-stas-2.3.1/debian/control	2023-12-25 11:19:28.0 +0100
@@ -5,6 +5,7 @@
 Uploaders:
  Benjamin Drung ,
 Build-Depends:
+ debhelper (>= 13.11.6),
  debhelper-compat (= 13),
  dh-python,
  docbook-xml,
diff -Nru nvme-stas-2.3.1/debian/rules nvme-stas-2.3.1/debian/rules
--- nvme-stas-2.3.1/debian/rules	2023-12-10 11:38:24.0 +0100
+++ nvme-stas-2.3.1/debian/rules	2023-12-25 11:19:28.0 +0100
@@ -8,9 +8,3 @@
 
 override_dh_auto_test:
 	dh_auto_test || true
-
-execute_after_dh_auto_install:
-	# Moving systemd unit directory (#1034225)
-	mkdir -p debian/nvme-stas/lib/systemd
-	mv debian/nvme-stas/usr/lib/systemd/system debian/nvme-stas/lib/systemd
-	rmdir -p --ignore-fail-on-non-empty debian/nvme-stas/usr/lib/systemd

Bug#1059428: Add support for loong64

[liuxiang]

Package: brian
Version: 2.5.4-3
Severity: normal
X-Debbugs-Cc: liuxi...@loongson.cn

Dear Maintainer,

  Please add loong64 support, patch file is attached.

Thanks

diff -ruN brian-2.5.4-bk/brian2/codegen/cpp_prefs.py brian-2.5.4/brian2/codegen/cpp_prefs.py
--- brian-2.5.4-bk/brian2/codegen/cpp_prefs.py	2023-12-25 08:37:13.0 +
+++ brian-2.5.4/brian2/codegen/cpp_prefs.py	2023-12-25 08:57:33.323718519 +
@@ -124,7 +124,7 @@
 "-mtune=native",
 "-std=c++11",
 ]
-elif re.match("^(parisc.*|riscv.*|mips.*)$", machine):
+elif re.match("^(parisc.*|riscv.*|mips.*|loong64.*)$", machine):
 default_buildopts = [
 "-w",
 "-O3",
@@ -155,7 +155,7 @@
 elif re.match('^(alpha|ppc.*|sparc.*)$', machine):
 default_buildopts = ['-w', '-O3', '-ffast-math', '-fno-finite-math-only',
  '-mcpu=native', '-mtune=native', '-std=c++11']
-elif re.match('^(sh|m68k|ia64|parisc.*|riscv.*|mips.*)$', machine):
+elif re.match('^(sh|m68k|ia64|parisc.*|riscv.*|mips.*|loong64.*)$', machine):
 default_buildopts = ['-w', '-O3', '-ffast-math', '-fno-finite-math-only',
  '-std=c++11']
 else:

Bug#1059427: bullseye-pu: package haproxy/2.2.9-2+deb11u6

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hapr...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:haproxy

Hi,

For ELTS I was fixing haproxy's CVES CVE-2023-40225 and CVE-2023-45539,
and I also like to fix those for stable and oldstable.

CC'ing the security team, in case they want to issue an DSA instead.

The changes can also be found on the LTS repository:
https://salsa.debian.org/lts-team/packages/haproxy

[ Tests ]
I've tested the fixes manually, using netcat to inject
problematic http requests and confirm that the patched
version rejects the malicous requests. (using nginx and
also netcat as http server.)

(Being verbose here to document the tests for later reference ;-))

haproxy is listening on port 8080

e.g for CVE-2023-40225:
echo 'GET /index.nginx-debian.html# HTTP/1.0' | netcat localhost 8080
must be rejected with 400 Bad Request
and without the "#" accepted.

for CVE-2023-45539, nginx is stopped, and netcat listens on port 80:
echo 'GET / HTTP/.1.1
host: whatever
content-length:
' | netcat localhost 8080

If the request is accepted (and forwarded to the listening netcat),
haproxy is vulnerable. If a "400 Bad request" ist thrown, without
netcat receiving something, haproxy is not vulnerable.

(haproxy is running on port 8080)

[ Risks ]
Upstream patch, applied cleanly.

[ 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

Debdiff attached.

I'v uploaded the package to o-s-p-u already.

Cheers,
-- 
tobi
diff -Nru haproxy-2.2.9/debian/changelog haproxy-2.2.9/debian/changelog
--- haproxy-2.2.9/debian/changelog  2023-04-10 16:18:09.0 +0200
+++ haproxy-2.2.9/debian/changelog  2023-12-25 09:46:44.0 +0100
@@ -1,3 +1,13 @@
+haproxy (2.2.9-2+deb11u6) bullseye; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Import upstream patch for CVE-2023-40225, forwarding malformed
+Content-Length Headers. Closes: #1043502.
+  * Import upstream patch for CVE-2023-45539, accepting invalid requests
+containing '#' as part of the URI component.
+
+ -- Tobias Frost   Mon, 25 Dec 2023 09:46:44 +0100
+
 haproxy (2.2.9-2+deb11u5) bullseye-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru haproxy-2.2.9/debian/.gitlab-ci.yml 
haproxy-2.2.9/debian/.gitlab-ci.yml
--- haproxy-2.2.9/debian/.gitlab-ci.yml 1970-01-01 01:00:00.0 +0100
+++ haproxy-2.2.9/debian/.gitlab-ci.yml 2023-12-25 09:46:44.0 +0100
@@ -0,0 +1,7 @@
+---
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'bullseye'
diff -Nru haproxy-2.2.9/debian/patches/CVE-2023-40225.patch 
haproxy-2.2.9/debian/patches/CVE-2023-40225.patch
--- haproxy-2.2.9/debian/patches/CVE-2023-40225.patch   1970-01-01 
01:00:00.0 +0100
+++ haproxy-2.2.9/debian/patches/CVE-2023-40225.patch   2023-12-25 
09:46:44.0 +0100
@@ -0,0 +1,257 @@
+Description: CVE-2023-40225 - http: reject any empty content-length header 
value 
+ The content-length header parser has its dedicated function, in order
+ to take extreme care about invalid, unparsable, or conflicting values.
+ But there's a corner case in it, by which it stops comparing values
+ when reaching the end of the header. This has for a side effect that
+ an empty value or a value that ends with a comma does not deserve
+ further analysis, and it acts as if the header was absent.
+ .
+ While this is not necessarily a problem for the value ending with a
+ comma as it will be cause a header folding and will disappear, it is a
+ problem for the first isolated empty header because this one will not
+ be recontructed when next ones are seen, and will be passed as-is to the
+ backend server. A vulnerable HTTP/1 server hosted behind haproxy that
+ would just use this first value as "0" and ignore the valid one would
+ then not be protected by haproxy and could be attacked this way, taking
+ the payload for an extra request.
+ .
+ In field the risk depends on the server. Most commonly used servers
+ already have safe content-length parsers, but users relying on haproxy
+ to protect a known-vulnerable server might be at risk (and the risk of
+ a bug even in a reputable server should never be dismissed).
+ .
+ A configuration-based work-around consists in adding the following rule
+ in the frontend, to explicitly reject requests featuring an empty
+ content-length header that would have not be folded into an existing
+ one:
+ .
+ http-request deny if { hdr_len(content-length) 0 }
+ .
+ The real fix consists in adjusting the parser so that it always expects a
+ value at the beginning of the header or after a comma. It 

Bug#1059426: bookworm-pu: package haproxy/2.6.12-1+deb12u1

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hapr...@packages.debian.org
X-Debbugs-Cc: t...@security.debian.org
Control: affects -1 + src:haproxy

Hi,

For ELTS I was fixing haproxy's CVES CVE-2023-40225 and CVE-2023-45539,
and I also like to fix those for stable and oldstable.

CC'ing the security team, in case they want to issue an DSA instead.

The changes can also be found on the LTS repository:
https://salsa.debian.org/lts-team/packages/haproxy

[ Tests ]
I've tested the fixes manually, using netcat to inject
problematic http requests and confirm that the patched
version rejects the malicous requests. (using nginx and
also netcat as http server.)

(Being verbose here to document the tests for later reference ;-))

haproxy is listening on port 8080

e.g for CVE-2023-40225:
echo 'GET /index.nginx-debian.html# HTTP/1.0' | netcat localhost 8080
must be rejected with 400 Bad Request
and without the "#" accepted.

for CVE-2023-45539, nginx is stopped, and netcat listens on port 80:
echo 'GET / HTTP/.1.1
host: whatever
content-length:
' | netcat localhost 8080

If the request is accepted (and forwarded to the listening netcat),
haproxy is vulnerable. If a "400 Bad request" ist thrown, without
netcat receiving something, haproxy is not vulnerable.

(haproxy is running on port 8080)

[ Risks ]
Upstream patch, applied cleanly. 

[ 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

Debdiff attached.

I'v uploaded the package to s-p-u already.
diff -Nru haproxy-2.6.12/debian/changelog haproxy-2.6.12/debian/changelog
--- haproxy-2.6.12/debian/changelog 2023-04-01 11:05:57.0 +0200
+++ haproxy-2.6.12/debian/changelog 2023-12-25 10:03:03.0 +0100
@@ -1,3 +1,13 @@
+haproxy (2.6.12-1+deb12u1) bookworm; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Import upstream patch for CVE-2023-40225, forwarding malformed
+Content-Length Headers. Closes: #1043502.
+  * Import upstream patch for CVE-2023-45539, accepting invalid requests
+containing '#' as part of the URI component.
+
+ -- Tobias Frost   Mon, 25 Dec 2023 10:03:03 +0100
+
 haproxy (2.6.12-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru haproxy-2.6.12/debian/.gitlab-ci.yml 
haproxy-2.6.12/debian/.gitlab-ci.yml
--- haproxy-2.6.12/debian/.gitlab-ci.yml1970-01-01 01:00:00.0 
+0100
+++ haproxy-2.6.12/debian/.gitlab-ci.yml2023-12-25 10:03:03.0 
+0100
@@ -0,0 +1,7 @@
+---
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'bookworm'
diff -Nru haproxy-2.6.12/debian/patches/CVE-2023-40225.patch 
haproxy-2.6.12/debian/patches/CVE-2023-40225.patch
--- haproxy-2.6.12/debian/patches/CVE-2023-40225.patch  1970-01-01 
01:00:00.0 +0100
+++ haproxy-2.6.12/debian/patches/CVE-2023-40225.patch  2023-12-25 
10:03:03.0 +0100
@@ -0,0 +1,257 @@
+Description: CVE-2023-40225 - http: reject any empty content-length header 
value 
+ The content-length header parser has its dedicated function, in order
+ to take extreme care about invalid, unparsable, or conflicting values.
+ But there's a corner case in it, by which it stops comparing values
+ when reaching the end of the header. This has for a side effect that
+ an empty value or a value that ends with a comma does not deserve
+ further analysis, and it acts as if the header was absent.
+ .
+ While this is not necessarily a problem for the value ending with a
+ comma as it will be cause a header folding and will disappear, it is a
+ problem for the first isolated empty header because this one will not
+ be recontructed when next ones are seen, and will be passed as-is to the
+ backend server. A vulnerable HTTP/1 server hosted behind haproxy that
+ would just use this first value as "0" and ignore the valid one would
+ then not be protected by haproxy and could be attacked this way, taking
+ the payload for an extra request.
+ .
+ In field the risk depends on the server. Most commonly used servers
+ already have safe content-length parsers, but users relying on haproxy
+ to protect a known-vulnerable server might be at risk (and the risk of
+ a bug even in a reputable server should never be dismissed).
+ .
+ A configuration-based work-around consists in adding the following rule
+ in the frontend, to explicitly reject requests featuring an empty
+ content-length header that would have not be folded into an existing
+ one:
+ .
+ http-request deny if { hdr_len(content-length) 0 }
+ .
+ The real fix consists in adjusting the parser so that it always expects a
+ value at the beginning of the header or after a comma. It will now reject
+

Bug#1058553: node-js-sdsl: FTBFS: TypeError: Cannot set property constructor of [object Object] which has only a getter

[Ying-Chun Liu (PaulLiu)]

Hi Yadd,

I think this FTBFS is caused by TTSC introduced by commit 
a3371fa529c30a579f52f507b6e5fcd902d30505.

Can I revert this change? Or we need to upgrade TTSC?

Yours,
Paul


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059425: cpu-checker: enable loongarch64 build

[zhangdandan]

Source: cpu-checker
Version: 0.7-1.3
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the cpu-checker failed on my local loong64 rootfs environment.
We need to add build support for loong64 in debian/control.
At the same time, we also need to add the loongarch64 support in kvm-ok 
for the LoongArch architecture.


Please consider the patch I have attached.
Referring to other architectures, I have submitted a bug to the Ubuntu 
launchpad, plesase see https://bugs.launchpad.net/cpu-checker/+bug/2047347

Your opinions are welcome.

thanks,
Dandan Zhang

diff -Nru cpu-checker-0.7/debian/control cpu-checker-0.7/debian/control
--- cpu-checker-0.7/debian/control  2021-08-02 13:30:02.0 +
+++ cpu-checker-0.7/debian/control  2021-09-14 06:45:39.0 +
@@ -9,7 +9,7 @@
 Vcs-Bzr: lp:~cpu-checker-dev/cpu-checker/trunk
 
 Package: cpu-checker
-Architecture: amd64 arm64 armhf i386 ppc64el powerpc riscv64 s390x
+Architecture: amd64 arm64 armhf i386 loong64 ppc64el powerpc riscv64 s390x
 Depends: msr-tools [amd64 i386], ${shlibs:Depends}, ${misc:Depends}
 Conflicts: qemu-kvm (<< 0.12.3-0ubuntu13)
 Replaces: qemu-kvm (<< 0.12.3-0ubuntu13)
diff -Nru 
cpu-checker-0.7/debian/patches/cpu-checker-add-loongarch64-support.patch 
cpu-checker-0.7/debian/patches/cpu-checker-add-loongarch64-support.patch
--- cpu-checker-0.7/debian/patches/cpu-checker-add-loongarch64-support.patch
1970-01-01 00:00:00.0 +
+++ cpu-checker-0.7/debian/patches/cpu-checker-add-loongarch64-support.patch
2021-09-14 06:45:39.0 +
@@ -0,0 +1,26 @@
+Description: Add loongarch64 support 
+Last-Update: 2023-12-25
+
+--- cpu-checker-0.7.orig/kvm-ok
 cpu-checker-0.7/kvm-ok
+@@ -63,6 +63,10 @@ case "$(uname -m)" in
+   virt="RISCV"
+   kvm_mod="kvm"
+   ;;
++loongarch64)
++  virt="LOONGARCH"
++  kvm_mod="kvm"
++  ;;
+ *)
+   virt=$(egrep -m1 -w '^flags[[:blank:]]*:' /proc/cpuinfo | egrep -wo 
'(vmx|svm)') || true
+   [ "$virt" = "vmx" ] && kvm_mod="kvm_intel"
+@@ -122,6 +126,9 @@ elif [ "$virt" = "ARM" ]; then
+ elif [ "$virt" = "RISCV" ]; then
+ # Should also test that we booted in HS mode, if detectable
+ :
++elif [ "$virt" = "LOONGARCH" ]; then
++# Should also test that we booted in LVZ mode, if detectable
++:
+ elif [ "$virt" = "generic" ]; then
+ :
+ else
diff -Nru cpu-checker-0.7/debian/patches/series 
cpu-checker-0.7/debian/patches/series
--- cpu-checker-0.7/debian/patches/series   2021-08-02 13:30:02.0 
+
+++ cpu-checker-0.7/debian/patches/series   2021-09-14 06:45:39.0 
+
@@ -3,3 +3,4 @@
 powerpc-dummy.patch
 cpu-checker-s390x.patch
 riscv64-dummy.patch
+cpu-checker-add-loongarch64-support.patch

Bug#1059424: Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

Control: tag 1059424 patch

(switching to the cloned xfsprogs bug)

On Mon, Dec 25, 2023 at 09:15:59AM +0100, Julian Andres Klode wrote:
> Control: clone -1 -2
> Control: reassign -2 xfsprogs
> 
> On Sat, Dec 23, 2023 at 11:11:53PM +0100, Cyril Brulebois wrote:
> > Hi,
> > 
> > Anthony Iliopoulos  (2023-10-30):
> > > On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > > > Anthony Iliopoulos  writes:
> > > > 
> > > > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > > > ...
> > > > >>   error: invalid XFS directory entry.
> > > > ...
> > > > > This issue exists independently of the large extent counter, and it is
> > > > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > > > #1051543.
> > > > 
> > > > Ah, yes -- good point.
> > > > 
> > > > > There's a proposed fix at [1], and it works as expected with that 
> > > > > patch
> > > > > applied.
> > > > ...
> > > > > [1] 
> > > > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> > > > 
> > > > I can confirm that having applied both patches:
> > > > 
> > > >   https://salsa.debian.org/philh/grub2/-/pipelines/596346
> > > > 
> > > > it now succeeds at both installing grub, and then booting the system:
> > > > 
> > > >   https://openqa.debian.net/tests/200503#details
> > > 
> > > Thanks for confirming, perhaps then you can add your tested-by in the
> > > respective patches upstream.
> > > 
> > > BTW, another handy way to test if this works is via grub-mount.
> > 
> > Any chance we could have an updated grub2 package to fix this?
> 
> The final grub 2.12 that includes the fix should hit unstable in the
> middle of January. As you might be aware many are busy with family
> stuff and holiday celebrations right now.
> 
> As always though it stands to reason that this is a change that should
> (have been) reverted in xfsprogs first until a grub that understands it
> has been released in a stable point release such that you can use a
> stable grub to inspect an XFS filesystem created by a trixie xfsprogs.
> 
> It seems the bug has been wrongly reassigned instead of being cloned
> and reassigned, so I'm cloning it back to xfsprogs.

Ah I see I fixed this in Ubuntu's xfsprogs back in November, so patch
attached, I seem to have forgotten to forward this?

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


xfsprogs_6.5.0-1_6.5.0-1ubuntu1.diff.gz
Description: application/gzip

Bug#946382: This bug report seems useless in my opinion

[Dan Jacobson]

> "GK" == Georges Khaznadar  writes:
GK> Hello Dan,

GK> I would like to get more information about your intent, for this bug
GK> report.

Looking at the crontab(5) man page,
everything lines up very pretty:


   17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
   25 6 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
   47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )
   52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.monthly )

But that is because the author picked 6 hours for each.

Let's see what would happen otherwise:
   17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
   25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
   47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )
   52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.monthly )
Oh darn, that looks ugly.

The question that crosses users minds is: "Can I rewrite it
   17  * * * *  root  cd / && run-parts --report /etc/cron.hourly
   25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
   47 06 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )
   52 06 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.monthly )
or will that be taken as octal (even if octal 6 is just 6), or illegal?
Please don't force me to test to find the answer."

I'm just saying the man page needs to state clearly what will happen.

Sure, one could just add spaces instead of zeros to make the columns
line up. But that would just be avoiding the issue.

GK> Should leading zeroes be supported for the sake of making columns line
GK> up, or should leading zeroes be used to introduce octal constants, in
GK> your opinion?

Nobody wants octal. I'm just trying to make columns line up.

GK> As far as I understand the code of the file entry.c, numbers are parsed
GK> by the function atoi:
GK> -8<- file entry.c's excerpt --
GK> if (all_digits) {
GK> *numptr = atoi(temp);
GK> return ch;
GK> }
GK> -8<---

GK> ... which means that numbers prefixed by zeroes are considered as
GK> decimal.

OK that's great. Please mention so on crontab(5). Thanks.

In fact perhaps add an example saying one can use spaces and zeros to make the
columns line up:

   25 16 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
   47 06 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )
   52  4 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.monthly )

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

Control: clone -1 -2
Control: reassign -2 xfsprogs

On Sat, Dec 23, 2023 at 11:11:53PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> Anthony Iliopoulos  (2023-10-30):
> > On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > > Anthony Iliopoulos  writes:
> > > 
> > > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > > ...
> > > >>   error: invalid XFS directory entry.
> > > ...
> > > > This issue exists independently of the large extent counter, and it is
> > > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > > #1051543.
> > > 
> > > Ah, yes -- good point.
> > > 
> > > > There's a proposed fix at [1], and it works as expected with that patch
> > > > applied.
> > > ...
> > > > [1] 
> > > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> > > 
> > > I can confirm that having applied both patches:
> > > 
> > >   https://salsa.debian.org/philh/grub2/-/pipelines/596346
> > > 
> > > it now succeeds at both installing grub, and then booting the system:
> > > 
> > >   https://openqa.debian.net/tests/200503#details
> > 
> > Thanks for confirming, perhaps then you can add your tested-by in the
> > respective patches upstream.
> > 
> > BTW, another handy way to test if this works is via grub-mount.
> 
> Any chance we could have an updated grub2 package to fix this?

The final grub 2.12 that includes the fix should hit unstable in the
middle of January. As you might be aware many are busy with family
stuff and holiday celebrations right now.

As always though it stands to reason that this is a change that should
(have been) reverted in xfsprogs first until a grub that understands it
has been released in a stable point release such that you can use a
stable grub to inspect an XFS filesystem created by a trixie xfsprogs.

It seems the bug has been wrongly reassigned instead of being cloned
and reassigned, so I'm cloning it back to xfsprogs.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1059423: r-cran-lwgeom: Please add loong64 binary output for Loongarch

[yalingfang]

Source: r-cran-lwgeom
Version: 0.2-13-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear Maintainer,
     Currently no loong64 binary output for r-cran-lwgeom in Loongarch env.

The buildd link is following:

https://buildd.debian.org/status/package.php?p=r-cran-lwgeom&suite=sid

I have verified and compiled pass by adding loong64 to debian/control 
file in my local env.


Attach the control patch.
Please add support for it. Thanks!
Any question, contact me!


add_loong64_output.patch
Description: Binary data

Bug#1059422: sdbus-cpp: pkgconfig fails to resolve systemd dependency

[Amin Bandali]

Source: sdbus-cpp
Version: 1.4.0-1
Severity: serious
Justification: causes dependent packages to fail to build from source
Tags: patch upstream

Dear maintainer,

The upstream sdbus-cpp 1.4.0 release shipped with a problematic
sdbus-c++.pc pkgconfig file that causes dependent packages that
use it to fail to build from source.  For example:

https://buildd.debian.org/status/fetch.php?pkg=ring&arch=amd64&ver=20230922.0%7Eds2-1%2Bb1&stamp=1701601320&raw=0

The issue was reported[1] and fixed[2] upstream already, but
there hasn't been a new release as of yet.  Given the severity
of the issue, please consider doing an upload with the attached
patch for the time being, until upstream releases a new version
with the fix included.

I'd look to do an NMU with the patch in the next week or two if you
may be unavailable/busy, so as to unbreak dependent packages' build.

Thanks,
-a

[1] https://github.com/Kistler-Group/sdbus-cpp/issues/377
[2] https://github.com/Kistler-Group/sdbus-cpp/pull/378

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2803722..7d29973 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,7 +12,8 @@ include(GNUInstallDirs) # Installation directories for `install` command and pkg
 # PERFORMING CHECKS & PREPARING THE DEPENDENCIES
 #---
 
-set(LIBSYSTEMD "systemd")
+set(LIBSYSTEMD_IMPL "systemd")
+set(LIBSYSTEMD_LIB "libsystemd")
 
 option(BUILD_LIBSYSTEMD "Build libsystemd static library and incorporate it into libsdbus-c++" OFF)
 
@@ -23,13 +24,15 @@ if(NOT BUILD_LIBSYSTEMD)
 message(WARNING "libsystemd not found, checking for libelogind instead")
 pkg_check_modules(Systemd IMPORTED_TARGET GLOBAL libelogind>=236)
 if(TARGET PkgConfig::Systemd)
-set(LIBSYSTEMD "elogind")
+set(LIBSYSTEMD_IMPL "elogind")
+set(LIBSYSTEMD_LIB "libelogind")
 string(REPLACE "." ";" VERSION_LIST ${Systemd_VERSION})
 list(GET VERSION_LIST 0 Systemd_VERSION)
 	else()
 message(WARNING "libelogind not found, checking for basu instead")
 pkg_check_modules(Systemd IMPORTED_TARGET GLOBAL basu)
-set(LIBSYSTEMD "basu")
+set(LIBSYSTEMD_IMPL "basu")
+set(LIBSYSTEMD_LIB "basu")
 # https://git.sr.ht/~emersion/basu/commit/d4d185d29a26
 set(Systemd_VERSION "240")
 endif()
@@ -125,8 +128,8 @@ add_library(sdbus-c++-objlib OBJECT ${SDBUSCPP_SRCS})
 target_compile_definitions(sdbus-c++-objlib PRIVATE
 BUILD_LIB=1
 LIBSYSTEMD_VERSION=${LIBSYSTEMD_VERSION}
-SDBUS_${LIBSYSTEMD}
-SDBUS_HEADER=<${LIBSYSTEMD}/sd-bus.h>)
+SDBUS_${LIBSYSTEMD_IMPL}
+SDBUS_HEADER=<${LIBSYSTEMD_IMPL}/sd-bus.h>)
 target_include_directories(sdbus-c++-objlib PUBLIC $
$)
 if(BUILD_SHARED_LIBS)
@@ -236,6 +239,7 @@ if(BUILD_SHARED_LIBS AND (BUILD_LIBSYSTEMD OR Systemd_LINK_LIBRARIES MATCHES "/l
 else()
 set(PKGCONFIG_REQS "")
 endif()
+set(PKGCONFIG_DEPS ${LIBSYSTEMD_LIB})
 configure_file(pkgconfig/sdbus-c++.pc.in pkgconfig/sdbus-c++.pc @ONLY)
 install(FILES ${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/sdbus-c++.pc
 DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig COMPONENT dev)
diff --git a/pkgconfig/sdbus-c++.pc.in b/pkgconfig/sdbus-c++.pc.in
index 07034769..1e17f33d 100644
--- a/pkgconfig/sdbus-c++.pc.in
+++ b/pkgconfig/sdbus-c++.pc.in
@@ -5,7 +5,7 @@ includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
 
 Name: @PROJECT_NAME@
 Description: C++ library on top of sd-bus, a systemd D-Bus library
-Requires@PKGCONFIG_REQS@: @LIBSYSTEMD@
+Requires@PKGCONFIG_REQS@: @PKGCONFIG_DEPS@
 Version: @SDBUSCPP_VERSION@
 Libs: -L${libdir} -l@PROJECT_NAME@
 Cflags: -I${includedir}
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 56c48528..85abf97e 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -106,7 +106,7 @@ include_directories(${CMAKE_CURRENT_SOURCE_DIR})
 add_executable(sdbus-c++-unit-tests ${UNITTESTS_SRCS})
 target_compile_definitions(sdbus-c++-unit-tests PRIVATE
 LIBSYSTEMD_VERSION=${LIBSYSTEMD_VERSION}
-SDBUS_HEADER=<${LIBSYSTEMD}/sd-bus.h>)
+SDBUS_HEADER=<${LIBSYSTEMD_IMPL}/sd-bus.h>)
 target_link_libraries(sdbus-c++-unit-tests sdbus-c++-objlib GTest::gmock)
 
 add_executable(sdbus-c++-integration-tests ${INTEGRATIONTESTS_SRCS})