Bug#1084048: release.debian.org: Debian Trixie and Rust 2024 / rustc toolchain version

[Fabian Grünbichler]

ore 2025-02-20? we definitely don't want
to be stuck on a beta release for Trixie..

Thanks for your consideration,
Fabian

0: https://doc.rust-lang.org/edition-guide/editions/index.html
1: 
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-July/044870.html

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Fabian Greffrath]

Am Dienstag, dem 01.10.2024 um 03:26 +0200 schrieb Santiago Vila:
> b) The SHELL="bash -Eeuo pipefail" definition in debian/rules.

I think I can just remove these lines, upstream did the same some years
ago:

https://github.com/freedoom/freedoom/commit/77c53e11adfb1e5124e363d68518527c4fcfdf1a

Thanks again!

 - Fabian



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

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Fabian Greffrath]

Thank you very much for this update!

Am 2024-10-01 03:26, schrieb Santiago Vila:

Maybe we could just take for granted that deutex has PNG support,
because it has, and drop the check in the toplevel Makefile,


Since `deutex-check` isn't declared as a .PHONY rule, I think I can just 
run `touch deutex-check` before the build and be done with it.


 - Fabian

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Fabian Greffrath]

Maybe the `deutex -h` output to stdout get spoiled by other build steps 
running in parralel, so that it doesn't include "PNG" as an isolated 
word anymore?


 - Fabian

Bug#1080073: gstreamer1.0-fdkaac: Please upgrade to gst-plugins-bad1.0_1.24.7

[Fabian Greffrath]

Package: gstreamer1.0-fdkaac
Version: 1.20.0-1
Severity: wishlist

Hi,

this package has fallen a bit behind the gst-plugins-bad1.0 package
with which it shares sources. Please upgrade to keep both in sync.

Thanks!

 - Fabian


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

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gstreamer1.0-fdkaac depends on:
ii  libc6   2.39-7
ii  libfdk-aac2 2.0.2-1
ii  libglib2.0-0t64 [libglib2.0-0]  2.81.2-1
ii  libgstreamer-plugins-base1.0-0  1.24.7-1
ii  libgstreamer1.0-0   1.24.7-1

gstreamer1.0-fdkaac recommends no packages.

gstreamer1.0-fdkaac suggests no packages.

-- no debconf information

Bug#1079980: Processing Triggers for man-db takes an eternity

[Fabian V. Thobe]

Just for the SEO of this ticket: 

I can confirm that the following command to update resolves the problem of slow 
man-db performance on E2 Micro Instances on Google Cloud during apt upgrade 
activities: 

sudo apt install -t bullseye-backports man-db

Bug#1080006: Acknowledgement (RM: fonts-alegreya-sans -- RoM; no rdeps; outdated; dead upstream; superseded by fonts-liberation and fonts-croscore)

[fabian]

Control: retitle -1 RM: fonts-arkpandora -- RoM; no rdeps; outdated; 
dead upstream; superseded by fonts-liberation and fonts-croscore

Bug#1080006: RM: fonts-alegreya-sans -- RoM; no rdeps; outdated; dead upstream; superseded by fonts-liberation and fonts-croscore

[fabian]

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

Please remove fonts-arkpandora. There was only one non-NMU upload in 
2014. Since then, upstream has vanished and the fonts themselves have 
been superseded by at least two other font sets in Debian that follow 
the same goal, namely fonts-liberation and fonts-croscore.
Its removal has already been discussed before in #872766. Back then, 
there was one reverse dependency "libphp-jpgraph" which prevented this 
step. This package, however, has since been removed from Debian as well.


Thank you!

Cheers,

 - Fabian

Bug#1079980: Processing Triggers for man-db takes an eternity

[Fabian Thobe]

Package: man-db
Version: 2.9.4-2
Severity: wishlist

Dear Colin,

in 2011 man-db was declared
slow.https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696503

I can confirm that even in 2024 running a vanilla VM of the poorest
level (E2 micro) on
google cloud it still is. Like badly slow. I can confirm that
downloading the entire current debian iso on terrible indonesian wifi
with copper backend takes less than Processing triggers for man-db
(2.9.4-2) ... Is there anything to be done?

Bug#1057780: fixed in gdb 15.1-1

[Fabian Grünbichler]

FWIW, this change made rustc's (and notmuch's, see #1077911) build
dependencies unsatisfiable. they both have/had a dependency on gdb, and
a conflict on gdb-minimal, since the latter didn't provide all the
features required.

with the reversal of provides (gdb providing gdb-minimal instead of the
other way round), this combination is now unsatisfiable.

the new provides make more sense, so mainly leaving this here on zumby's
request (and for any other packages using such a combination ;)), not
asking for a revert or anything like that..

Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly

[Fabian Grünbichler]

On August 2, 2024 10:56:36 AM GMT+02:00, Gianfranco Costamagna 
 wrote:
>control: tags -1 moreinfo
>
>> BTW what's the difference with wasi-libc package ?
>
>yeah, looks like the same idea and code, and yet another fork
>
>This branch is 289 commits ahead of, 138 commits behind 
>WebAssembly/wasi-libc:main.
>
>https://github.com/wasix-org/wasix-libc
>https://github.com/WebAssembly/wasi-libc
>
>wasix looks a fork of wasi, but both are actively maintained
>Ximin and Fabian, since you maintain wasi-libc, I think we should hear your 
>opinion before moving with this RFS/ITP

wasi-libc is used by rustc to build the wasm-wasi targets (recently in another 
variant called preview2, so there is still work going on there as well), and as 
such is not replaceable by wasix-libc (and I am not aware of any plans to 
change that upstream, but I am not that involved in that ecosystem). the whole 
wasm ecosystem is full of forks and somewhat related, yet incompatible "specs". 
 Other than that, I am afraid I don't really have an opinion - but thanks for 
reaching out! :)

Bug#1065860: fonts-cantarell: Please drop dependencies on python3-distutils

[Fabian Greffrath]

Hi Emmanuel,

Am Freitag, dem 12.07.2024 um 17:23 -0300 schrieb Emmanuel Arias:
> Please if you have any objection or you want to do any change please
> let
> me know.

no objections, please feel free to upload asap.

Thanks,

 - Fabian



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

Bug#498048: Not resolved bug #498048 from Sat, 6 Sep 2008 / Chained ogg-flac files don't work

[Fabian Greffrath]

Hello,

Am Sonntag, dem 07.07.2024 um 12:38 +0200 schrieb phil995511 -:
> I'm a LMS (Logitech Music Server) user on Debian. With this software
> solution 30~40 % of web radio dont work because chained ogg-flac
> files don't work :-(
> 
> 16 years after its creation, this bug has not been resolved and
> continues to cause problems for people who use Debian as a music
> server ;-(

lack of response for 16 years is most often a sign that the issue has
been reported to the wrong address. And indeed, it is nearly impossible
for a software distribution such as Debian to coordinate the
implementation of a feature that requires patches in multiple upstream
sources. It is always best to discuss such issues with the enthusiasts
that actually care about these very specific features, such as the
community in the slimdevices forums.

> The user philippe_44 who is one of the developers of the LMS found
> the solution and said he provided it to you a few months ago.

I don't know who that collective "you" is, but as you stated yourself,
this bug report has seen no activity for the past 16 years and I cannot
remember any other mail addressing this specific issue as well.

> https://forums.slimdevices.com/forum/user-forums/general-discussion/1686476-problems-playing-web-radios-in-flac?p=1686490#post1686490
> 
> Would you be so kind as to make this patch available in Debian as
> soon as possible, please ?

Now that the issue has been reported to FLAC upstream and a fix is
provided, it is up to the FLAC upstream maintainers to review the patch
and either accept it or request changes. Then, it will eventually end
up in the next upstream release and we will package that for Debian.

I am not going to add a patch to the Debian package that has not yet
been approved by FLAC upstream.

> With the agreement of their managers, you could use the Debian
> Security Channel to distribute this important update quickly to
> Debian users...

Absolutely no, no chance! Most impotantly, because this is not a
security fix. Quite the contrary, this patch adds a lot of code that
hasn't been approved by upstream yet and applying it from the PR would
be much more of a new security risk than anything else.


> The fact that this problem has remained unresolved for all this time
> is certainly pushing people to look for solutions other than Debian
> ;-(

Well, since the fix hasn't even made it into FLAC upstream yet, I don't
see how this is a Debian specific issue in any way. Any other
distribution will face the same issue.

Sorry I couldn't help, but you will need a bit more patience. :/

Cheers,

 - Fabian




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

Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code

[Fabian Grünbichler]

On Thu, Jul 11, 2024 at 06:06:21PM GMT, Jonas Smedegaard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org, build-common team 
> 

Hi!

(all of what follows is my personal opinion and not coordinated with
other members of the Rust packaging team).

I know the team and you have had differences in the past about how to
approach packing crates and/or software written in Rust, and I can and
do respect the technical aspects of that (at least in parts).

Some sort of attempt to reconcile your pre-existing vendored forks of
the rust-team tooling with the original source, or at least a heads-up
about this plan of yours would have been appreciated. I don't see any
technical obstacles for having a single set of low-level Rust-helper
tools for packaging. I see a lot of downsides to having two such sets
that are 90% compatible, but subtly different and drifting apart over
time.

Please (seriously!) reconsider this, and try to work together with the
existing Rust team to develop a/the common set of (low-level) tooling
and helpers. A lot of the team members are also packaging
Rust-related/using software outside of debcargo-conf (e.g., as part of
the Gnome team), and desire similar features that you do for your
workspace-based, packaged from git crates.

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: dh-rust

The name is pretty misleading IMHO, this is dh-cargo and a helper from
the cargo package, forked and renamed (and extended), even though it is
not Rust or rustc, but cargo that is the target here..

You also conveniently fail to mention that this is a (personal) fork of
existing packages/scripts from existing packages.

>   Version : 0.0.1
>   Upstream Contact: build-common team 
> * URL : https://salsa.debian.org/build-common-team/dh-rust
> * License : GPL-3+

This part in particular almost seems like a hostile takeover - the
original tools are all MIT or Apache-2.0 licensed (the latter is not
mentioned in your git history, but the cargo wrapper is copied from
src:cargo or src:rust, which lists it as dual-licensed), and while you
kept the copyright notices, you didn't keep the license text (which
makes this a violation of the original license that require keeping it,
at least covering those parts originally written under that license -
unless you've actually gotten permission from all of the original
authors and just didn't mention that anywhere..).

With your "relicensing" you effectively made your forks live on the end
of a one-way street - you can take changes made in the original tools
authored by the Rust team, but prevent us from incorporating changes you
(or other contributors) do on your end, unless they are explicitly
dual-licensed, or our tools need to relicensed as well.

While this is obviously okay for you to do from a license stand point
(provided you keep the original license texts as well? but IANAL,
etc.pp.), it's a bit like a slap in the face to your fellow Debian
members in the Rust team, especially given the lack of communication.

>   Programming Lang: Perl
>   Description : debhelper buildsystem for Rust code
> 
>  dh-rust provides a debhelper buildsystem to build Rust code.
>  .
>  This builds and tests binaries and libraries from rust crates,
>  the latter installed as source code below /usr/share/cargo/registry.
>  .
>  Feature highlights, compared to dh-cargo:
>   * supports workspace (i.e. multi-crate project)
>   * allows overriding CARGO_HOME
>   * installs crate contents using "cargo package"
>   * can use debian/Cargo.lock or Cargo.lock during build
>   * uses crates below debian/vendorlibs when available
>   * builds in make target dh_auto_build (not dh_auto_test)

This is also factually wrong - dh-cargo doesn't build in dh_auto_test,
it tests there. It builds in dh_auto_install, and I am currently working
on changing that as part of integrating cdylib support..

But note that there is a reason it's done that way currently - cargo
handles configs (including the override for using packaged crates)
differently in `install` vs `build` - the latter can pick up a wrong
config shipped by the crate/project itself, with higher precedence than
the one managed by the wrapper, with all sorts of "fun" side-effects.

> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaQAvoACgkQLHwxRsGg
> ASEvTQ//W+YQjP71QIGyP3bgs2Sow8pSRga9BkbY7vjGNGGih9FPGFxDmG18dSV0
> JcLHuksh+kjHxoDoFpufOLcNTBPf3AQG6O6VuySxt7cG9L27w1a7jxKBXvKtDAtW
> 7ZBEi/fySLj5PyHYyZWY2fLmhEzBMmuNcY/l1wBklktF5Jkc7mwYSaqI/3mMxeeE
> pa6btQuW3Mdf3SyZEc05eriNIi9A6wBTy0Yc+m7oU2QGo+2ckXy3hOcN2SjQR5OM
> /h3NydY+bXP8V9Sz/wJ0qhep89Mh/CvEcKeNyw1BbKCHr1e+4UQ8WzEsWSq9c1+c
> f8woy3KNbtt1JXpCaJcM2I+PBOIaZ0HupV4IzQYevbpSawgnLY5AsGruJgAHiERj
> GVdBrykEj2YHfhw6clqJVTxx2sVYifLgOu5RiM4dGsBwMf0DpuqWXh3HeXnS6Z81
> 2xj0PTA5t38bQsqLW0JU1IOvzR4m/40SDMpTWo3FjWpc263QmjFMRXSVaUha8qQs
> fV9WhL0jTjvNbrUxRM7jKaPyi

Bug#1070492: mixxx: Tries to use the network during build

[fabian]

Hi,

Am 04.07.2024 08:01, schrieb Gianfranco Costamagna:
Also this patch is needed to adapt build dependencies with the t64 
renamed ones


diff -Nru mixxx-2.4.0+dfsg/debian/control 
mixxx-2.4.0+dfsg/debian/control

--- mixxx-2.4.0+dfsg/debian/control 2024-03-12 00:14:18.0 +0100
+++ mixxx-2.4.0+dfsg/debian/control 2024-07-04 07:55:35.0 +0200
@@ -55,8 +54,8 @@
  libtag1-dev,
  libupower-glib-dev,
  libusb-1.0-0-dev,
- libvamp-hostsdk3v5,
- libvamp-sdk2v5,
+ libvamp-hostsdk3t64,
+ libvamp-sdk2t64,
  libvorbis-dev,
  libwavpack-dev,
  pkgconf,


why does this package need to Build-Depend on shared library packages 
anyway? Why not the vamp-plugin-sdk package?


 - Fabian

Bug#1074448: corrosion: fails to build with rustc >= 1.79

[Fabian Grünbichler]

nux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> [  0%] Built target cargo-prebuild_rust_lib
> gmake[4]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
>Compiling rust-lib v0.1.0 (/<>/test/cbindgen/rust2cpp/rust)
> Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.51s
> Copying byproducts `librust_lib.a` to 
> /<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> [  0%] Built target _cargo-build_rust_lib
> gmake[4]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> [  0%] Built target cargo-build_rust_lib
> gmake[4]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[4]: Entering directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> [ 25%] Generate cbindgen bindings for crate rust_lib
> thread 'main' panicked at 'Unable to find rust_lib for 
> "/<>/test/cbindgen/rust2cpp/rust/Cargo.toml"', 
> src/bindgen/cargo/cargo.rs:92:21
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> gmake[4]: *** 
> [CMakeFiles/_corrosion_cbindgen_rust_lib_bindings.dir/build.make:74: 
> corrosion_generated/cbindgen/rust_lib/include/rust-lib.h] Error 101
> gmake[4]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[3]: *** [CMakeFiles/Makefile2:264: 
> CMakeFiles/_corrosion_cbindgen_rust_lib_bindings.dir/all] Error 2
> gmake[2]: *** [Makefile:91: all] Error 2
> gmake[3]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> gmake[2]: Leaving directory 
> '/<>/obj-x86_64-linux-gnu/test/cbindgen/build-cbindgen_rust2cpp'
> CMake Error at /<>/test/ConfigureAndBuild.cmake:110 (message):
>   Build step failed.  Exit code: `2`
> 
> 
> 
> test 23
>   Start 23: cbindgen_rust2cpp_run_cpp-exe
> Failed test dependencies: cbindgen_rust2cpp_build
>  5/69 Test #23: cbindgen_rust2cpp_run_cpp-exe 
> ***Not Run   0.00 sec

I'll try to keep an eye out for corrosion regressions in the future
before uploading to unstable!

thanks in advance,
Fabian

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

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

[Fabian Grünbichler]

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

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

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

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

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

Bug#962508: switch libcurl to openssl by default

[Fabian Grünbichler]

On Mon, 08 Jun 2020 19:16:27 -0400 Harlan Lieberman-Berg  wrote:
> Package: cargo
> Version: 0.43.1-3
> Severity: wishlist
> 
> Hello fellow Rustaceans!
> 
> Because cargo has a direct dependency on OpenSSL, it seems logical that we
> should switch the priority of openssl and gnutls so Cargo, at least by 
> default,
> isn't building against two different TLS implementations.
> 
> This is especially important considering GnuTLS has had some painful security
> incidents recently: CVE-2020-13777 in particular.
> 
> Should just require switching the order of the libcurl dep in d/control.

Hi,

took a look at this while going through bug backlog. Unfortunately it's not as 
easy - switching the direct cargo->gnutls dep around to use the openssl variant 
works, but
- libgit2 pulls in mbedtls
- curl itself pulls in gnutls and nettle (via librtmp1), even in the openssl 
variant

if those are fixed at some point, switching over seems sensible. 

libgit2 is in the process of being replaced upstream with gix, but I suspect 
that will still take a while to be completed.

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Fabian Grünbichler]

On Sat, Apr 27, 2024 at 05:40:49PM +0800, Maytham Alsudany wrote:
> Hi everyone,
> 
> Thanks for your input and suggestions. I've attached an updated patch with
> several changes, including improving making the description of the field more
> specific, adding another example that is not Go/Rust related, and improving 
> the
> Rust example to show the simultaneous use of Static-Built-Using and 
> Built-Using.
> 
> I would greatly appreciate any more feedback for this new patch. If you 
> believe
> that it is complete (and you are a DD), it would be very helpful if you could
> second this consensus and proposal.
> 
> The relevant part of the new patch has been included at the bottom of this
> email.
> 

[..]

> 
> Below is the relevant part of the updated patch, to save you from downloading
> the attachment:
> 
> ``Static-Built-Using``
> ~~
> 
> This ``Static-Built-Using`` field must list source packages who's
> contents (like source code or data) were incorporated into the binary
> package during the build, including an "exactly equal" ("=") version
> relation on the version that was used to build that version of the
> incorporating binary package.
> 
> Cases where this field may be used include (but are not limited to)
> linking against static libraries in other packages, builds for
> source-centered languages such as Go and Rust, usage of header-only
> C/C++ libraries and injecting data blobs into code.
> 
> This is useful to track whether the package might need to be rebuilt
> when source packages listed here have been updated. This is important
> to stay ahead of the package failing to build from source (FTBFS) with
> the updated versions of the listed source packages, or security
> updates in the listed source packages.
> 
> Unlike Built-Using, the Debian archive will **not** retain the
> versions of the source packages listed in the Static-Built-Using
> field. This means that any package listed in Static-Built-Using who's
> license requires its source code to be available must also
> simultaneously be listed in the Built-Using field.
> 
> A package that needs domain name suffix data from the publicsuffix
> binary package would list it in the ``Static-Built-Using`` field like
> so:
> 
> ::
> 
> Static-Built-Using: publicsuffix (= 20231001.0357-0.1)
> 
> A package statically linked with a library from the
> golang-github-mattn-go-xmpp-dev binary package would have this field
> in its control file:
> 
> ::
> 
> Static-Built-Using: golang-github-mattn-go-xmpp (= 0.2.0-1)
> 
> A package statically linked with the libraries contained in the
> librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
> the latter is licensed under GPL-3+ (a license that requires full
> source code to be available), would have these fields in its control
> file:
> 
> ::
> 
> Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
> Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 0.3.2-1+b1)
> 

LGTM, consider this Seconded :) (even though it is not currently tagged as
"Wording Proposed ;))

Fabian


signature.asc
Description: PGP signature

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Fabian Grünbichler]

On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote:
> Hello Go and Rust packagers,
> 
> On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote:
> 
> > With the increasing amount of programs in Debian that Build-Depend and
> > statically link with Golang and Rust libraries, it's important that
> > the Debian Policy clearly sets out the requirements for declaring
> > these statically-linked libraries.
> 
> I think Maytham is right that updating Policy for this is a priority.
> It has been bothering me that misunderstandings of Built-Using have been
> proliferating somewhat among newer contributors.  See also #999785.
> 
> Could you take a look at his proposed changes to Policy in #1069256,
> please, and confirm they successfully reconcile Debian Policy with your
> team policies?

Speaking for the Rust side - I'd say they match our expected usage of
the field. A slight rephrasing of "linked to libraries in other
packages" might match it even better, since in Rust's case, we are
usually talking about linking to libraries compiled from sources shipped
in other packages (librust-X-dev only contains the sources and possibly
helper scripts needed to build them, but not the compiled library).

But it also covers static linking of native libraries, so the current
phrasing matches that. Might be bikeshedding/nitpicky though ;)

> I think that we should also include an explanation of why we have chosen
> to do this using a new field in d/control like Static-Built-Using.
> Policy is meant to be a record of our lessons learned in building a
> distribution, and the lessons learned in trying to handle these new
> hyper-statically linked language ecosystems seem important.
> 
> My immediate question is why the Haskell and OCaml team's approaches,
> were not copied.  They seem to work well and don't require a new field.
> That seems worth writing down.

I am not sure about the details of their approach... are those available
somewhere?

> Thank you Maytham for your work so far.

Thanks to both of you! :)

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

[Fabian Grünbichler]

On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote:
> Hi Matthias,
> 
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > This is the same situation as in #1040477. This is an issue wrt how we
> > generate the semvers. I image rust-proc-macro-crate-1 would pose the same
> > problem. Quoting you from 1040477:
> 
> Right!
> 
> > Is the only workaround dropping Ma:same here ?
> 
> I see very little alternatives. We must choose:
> 
>  * Do not combine M-A:same + Provides: foo + Breaks: foo.
>  * Fix dose/apt/dpkg to agree on what this means.
> 
> If we were to adapt dose and apt, they's simply arrive at the conclusion
> that M-A:same would not work here so that really is not what you'd want
> here. This amounts to fixing dpkg to allow this very combination in the
> same way that apt and dose allow it. So yeah, changing dpkg could be an
> option. Ccing dpkg-devel about it.
> 
> The first alternative means that we must not combine them at the same
> time. As we very much want M-A:same, we must not have this combination
> of Provides and Brekas. Keep in mind that they serve slightly different
> purposes. We have Breaks + Replaces and you can only replace a real
> package but Provides introduce a virtual package. In effect we're
> dealing with a package that sometimes is virtual and other times is
> real. We can choose different names for these uses. The real package
> could be renamed and also provide the virtual facility. All of them
> would now provide the virtual one as virtual only and none of them would
> have the virtual name. The Breaks and Replaces would be updated to match
> the real name.

we discussed this in the past already around bookworm's release, but
haven't fixed the debcargo side generating these.

see #1040477 and #1054156

IIRC the solution was to switch to Conflicts, and maybe stop providing
librust-bitflags-dev and friends (those without any semver parts in the
package name) in the semver-suffix variant, right?

> This may not work for the in-archive situations right now as Breaks and
> Replaces may still be necessary for upgrades, but it is something that
> may work in future situations of the same kind.
> 
> In the mean time, consider that M-A:same presently is a lie. Removing it
> is better than continuing to lie. It's not like we must have everything
> in perfect multiarch. Even for cross compilation, we often can get away
> without M-A:same by only requiring a package for the host architecture.
> M-A:same is not the goal. It's a tool and way may consider using other
> tools.
> 
> Helmut
> 

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

[Fabian Grünbichler]

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> > Hi Wesley, Yaroslav, Carsten and Mike,
> 
> Hi Fabian,
> 
> Let me start by thanking you for the work going into packaging rustc.
> 
> > while we try to keep rustc somewhat current in sid, this is not always
> > possible in a timely manner.
> 
> rustc 1.70 was released on June 1 and made it to unstable in September.
> We're now 7 months later.

yeah, most of the delay there was a result of bookworm and the freeze
(rustc as part of the toolchain set gets frozen early, and we found out
the hard way this time around that if we prepare release in experimental
we still have to go through bin-NEW - and of course, we've also had our
hands full with other getting-rustc-stuff-ready-for-bookworm things at
that time).

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

see above. 4-5 versions is  not unheard of. when 1.70 was released, we
had 1.67 in experimental, for example.

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

we might have different definitions of "somewhat current" :)

most stable projects are okay with about 6 months lag, which is about 4
rustc releases.  and that's not taking into account that we don't always
package the latest release the moment it's out of the door for things
depending on rustc/cargo either.

I do aim for less, of course, but it doesn't always work out as
intended.

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

well, the amount of work it takes is about the same, but the wait is of
course longer if the lag is bigger, yes.

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

well, I'd be happy to share the workload ;)

but it requires a substantial commitment - reviewing an MR for an
update is not that much less work than doing it myself, since the
package is quite complex, and quite important. I can do that a few
times, but if it's not for somebody who wants to comaintain long-term
it's probably time better spent improving the tooling or specific bugs.

I do hope to at least get rid of two bottle necks soon that have
affected updates in the past
- the split between cargo and rustc, with cargo having its own set of
  problems that made updating harder, which should be mostly eliminated
  with the merge
- me just being a DM, with additional delays introduced by waiting for
  somebody else from the team somewhat familiar with the packages
  uploading to bin-NEW (I am a DD now, but my key/account is not active
  yet)

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

that's good to know, I'll still try to get the lag reduced ASAP!

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

[Fabian Grünbichler]

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

Hi Wesley, Yaroslav, Carsten and Mike,

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

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

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

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

Fabian

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

[Fabian Grünbichler]

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

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

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

[Fabian Grünbichler]

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

Hi!

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

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

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

Fabian

Bug#1068443: systemd: "systemctl --user ..." results in Connection refused

[Fabian Greffrath]

Am Samstag, dem 06.04.2024 um 11:15 +0200 schrieb Michael Biebl:
> Is the problem reproducible after a reboot?
> Is the problem reproducible for a freshly created user?

Interestingly, today it worked when I wanted to reproduce the issue.
I'll report back when it occurs again.

Thanks!

 - Fabian



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

Bug#1068114: libfluidsynth-dev: package dependencies incongruent with libfluidsynth

[fabian]

Am 03.04.2024 01:22, schrieb Gravis:
Since you are basing dependencies on the generated pkg-config file then 
this
means that the libfluidsynth-dev package is built with 
enable-systemd=on while

the libfluidsynth package is being built with enable-systemd=off


What makes you think it is built without systemd support?

This is an excerpt from the build log:

"""
Miscellaneous support:
  D-Bus: yes
  LADSPA support:yes
  LASH support:  no
  NETWORK Support:   yes
IPV6 Support:yes
  Readline:  yes (NOTE: GPL library)
  systemd:   yes
  getopt:yes
"""

https://buildd.debian.org/status/fetch.php?pkg=fluidsynth&arch=amd64&ver=2.3.4-1%2Bb3&stamp=1711274976&raw=0

 - Fabian

Bug#1065787: [Pkg-rust-maintainers] Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Fabian Grünbichler]

On Sun, Mar 17, 2024 at 06:53:34AM +0100, Emanuele Rocca wrote:
> 
> On 2024-03-16 04:21, Emanuele Rocca wrote:
> > With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf
> 
> And on armel too. Fixed armhf/armel packages uploaded.
> 
> > Fabian: it seems that cargo's build-depend on git can be dropped? The
> > package builds fine without, tests included.
> 
> I haven't touched build-depends and git is still currently
> uninstallable. For this reason cargo would not cleanly build from source
> on armhf/armel in case of sourceful upload, but as I said without git it
> does build fine. Leaving this one up to Fabian!

it is only used for some tests, and does are properly guarded to be
skipped if git is not around:

 $ rg requires_git
 tests/testsuite/git.rs
 2713:#[cargo_test(requires_git)]
 2816:#[cargo_test(requires_git)]
 2873:#[cargo_test(requires_git)]
 
 tests/testsuite/git_gc.rs
 92:#[cargo_test(requires_git)]

or, from a build log with git removed from d/control:

 $ rg '^test git.*ignored' ../cargo_0.70.1*-17T*.build
 ../cargo_0.70.1+ds1-2_amd64-2024-03-17T07:49:03Z.build
 4480:test git::git_fetch_cli_env_clean ... ignored, git not installed
 4483:test git::git_with_cli_force ... ignored, git not installed
 4504:test git::use_the_cli ... ignored, git not installed
 4510:test git_gc::use_git_gc ... ignored, git not installed

that being said, these tests are for the opt-in feature of cargo using
the git binary/CLI instead of libgit2 (or, in more recent versions,
gitoxide) for various git related operations (fetching crates.io index
if not opting into the sparse index feature, fetching git dependencies
in Cargo.toml, ..).

I don't expect that to break, but obviously while git is not installable
that feature of cargo is unavailable as well. So a rebootstrap without
git present seems okay if that speeds up things.

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Fabian Grünbichler]

On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote:
> Hi!
> 
> Is anyone perhaps planning to fix cargo?
> 
> For example curl isn't building on armel/armhf now and numerous packages
> that depend of curl are not building on armel/armhf.
> 
> Thanks in advance to the person who steps up.

see the (linked) t64 transition bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197

Bug#1036884: transition: time64_t

[Fabian Grünbichler]

On Tue, Mar 12, 2024 at 05:55:59PM +0100, Emanuele Rocca wrote:
> [ debian-rust added to CC ]
> 
> Hi,
> 
> On 2024-03-12 11:03, Simon McVittie wrote:
> > In the medium term, cargo needs re-bootstrapping on the affected
> > architectures (armel and armhf, plus a bunch of -ports architectures
> > where as far as I can see cargo was never available in the past) -
> > that's #1065787, and Steve already replied to that bug describing how
> > Ubuntu did this.
> 
> I don't think Ubuntu actually fixed cargo yet, at least if the data in
> UDD is reliable -- and if I'm looking in the right place. :-)
>
> udd=> select source,version,date from ubuntu_upload_history where 
> source='cargo' order by date desc limit 2;
>  source |  version   |  date  
> ++
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.20.04.2 | 2023-07-05 09:36:28+00
>  cargo  | 0.67.1+ds0ubuntu0.libgit2-0ubuntu0.22.04.2 | 2023-07-05 09:36:27+00
> (2 rows)
> 
> Maybe when Steve mentioned the work done in Ubuntu on
> https://bugs.debian.org/1065787#22 he meant other packages?

possibly the "Ubuntu did this" was referring to post-cargo/rustc-merge?

we've planned that as well, and it's about 75% prepared, but I didn't
manage to finish in Debian in time for t64 to kick off so I held off
finalizing it until the dust settles. in hindsight, that might have been
a mistake - src:rustc (the target of the source package merge) comes
with builtin (re)bootstrap support from upstream statically linked
stage0 ;)

> > Is there a porter who can take responsibility for that?
> 
> I did manage to get cargo to build in a armhf chroot by manually
> installing the various deps, see the build artifacts at
> https://people.debian.org/~ema/cargo/. I can work on armel next. The
> tests are green but maybe there's some more meaningful validation we can
> do before uploading? Anyone from debian-rust has ideas or comments?

if the tests are green, you could try a rebuild of rustc and/or cargo
with the built cargo next? I don't think anything else that is packaged
exercises anywhere near that amount of the functionality of cargo ;)

thanks for taking care of this! don't hesitate to holler here or in
#debian-rust/dev/release (ping me for the latter two, I don't read the
full backlog there).

Fabian

Bug#1051487: This not a double dependency

[fabian]

Hi Georges,

Am 12.03.2024 08:42, schrieb Georges Khaznadar:
It rather means: if some Foo.t1 font cannot be found, for any reason, 
take

another surely existing font as a default.


Yes, but by depending on the fonts-urw-base35 package you already _make 
sure_ that the T1 fonts can be found, so there is no need to also depend 
on the secondary order fallback fonts as well.



Would it be better to pick something like the font C059-Roman.t1,
by default?


Please choose default fonts that can be satisfied by only one package 
dependency.


 - Fabian

Bug#1064980: lua-dkjson 2.5-3 missing symlink for lua5.4

[Fabian Thrum]

Package: lua-dkjson
Version: 2.5-3
Severity: normal
X-Debbugs-Cc: fabian.th...@nfon.com

Dear Maintainer,

I tried to use lua-dkjson 2.5-3 with debian 11 and lua 5.4.
The library can not be included/used because because it is missing in the 
LUAPATH of lua5.4
I added the symlink manually and than it worked. 
mkdir /usr/share/lua/5.4
ln -s /../5.1/dkjson.lua /usr/share/lua/5.4/dkjson.lua
After that I could use the lib also with lua5.4
My admin preferes to have it fixed in the package before rolling it out on many 
mashines.
The missing symlink is present/fixend with Debian 12 and lua-dkjson 2.6-2.
I suggest to options as a way to fix it:
- The missing symlink can be added to 2.5.3
- Or version 2.6-2 gets added to debian 11 as default


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

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

lua-dkjson depends on no packages.

Versions of packages lua-dkjson recommends:
ii  lua-lpeg  1.0.2-1

lua-dkjson suggests no packages.

-- no debconf information

Bug#1064539: systemd: DHCPPrefixDelegation does not allow zero value in Token=

[Fabian Müller]

Package: systemd
Version: 252.19-1~deb12u1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: fmu+deb...@never-afk.de

Dear Maintainer,


   * What led up to the situation?

I wanted systemd-networkd to select the first address (zero) from the ipv6
prefix that was delegated to me. My provider (Vodafone Kabel / Germany) offers
me a /56 prefix via prefix delegation.

My .network file looks like this:

[Match]
Name=enp1s0

[Network]
IPv6AcceptRA=yes
DHCP=yes
DHCPPrefixDelegation=yes

[DHCPv6]
PrefixDelegationHint=::/56
UseDNS=no
UseAddress=no

[DHCPPrefixDelegation]
Token=static:::


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

I tried to set the "Token=" option in the [DHCPPrefixDelegation] section of my
.network file as follows:

[DHCPPrefixDelegation]
Token=static:::

   * What was the outcome of this action?

The resulting ipv6 address is selects via eui64 instead of static.
So i get a address like this 2001:db8::a60:6eff:feda:858a/64

   * What outcome did you expect instead?

I expected the address to be zero. More like this: 2001:db8::/64 (which is a
valid ipv6 address).

I also tried the following values:
Token=static:::0 # does not work
Token=:: # does not work
Token=static::: # does not work
Token=static:::1 # works as expected, but is not what i want, address would be
2001:db8::1/64


-- Package-specific info:

-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9+deb12u3
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u1
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.11-1~deb12u2
ii  libsystemd-shared  252.19-1~deb12u1
ii  libsystemd0252.19-1~deb12u1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-1~deb12u1
ii  systemd-timesyncd [time-daemon]  252.19-1~deb12u1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2+b1
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  policykit-1   122-3
ii  polkitd   122-3
pn  systemd-boot  
ii  systemd-container 252.19-1~deb12u1
pn  systemd-homed 
ii  systemd-resolved  252.19-1~deb12u1
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1~deb12u1
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 252.19-1~deb12u1
ii  udev   252.19-1~deb12u1

-- no debconf information

Bug#1062016: Consider providing separate librsvg2 package

[Fabian Grünbichler]

On Wed, 31 Jan 2024 00:14:50 +0100 Matthias Geiger  wrote:
> please consider providing a librust-librsvg2-dev package. This should
> just install the rust source files under
> /usr/share/cargo/registry/librsvg2-VERSION. This will be needed by
> loupe/glycin to load svgs (other crates also started depend on
> librsvg2).
> 
> f_g: Is an install of those files compatible with our setup even if some
> deps of librsvg2 are not in debian yet (it's built vendored) ?

Hi (f_g here ;)),

For librsvg to be usable as a Rust dependency in Debian, all its
dependencies (which are currently vendored) also need to be packaged as
Rust source code in a way that allows rdeps of librust-librsvg-dev to
find them.

There are two approaches for the vendored deps:

1) package each of them in the regular fashion (if missing, upgrading/..
otherwise), and build-depend on them in src:librsvg instead of vendoring
them

2) ship them in some non-standard path (from the vendored copies), but
make cargo pick them up via some hack (patch/source replacement, path
deps, extra vendoring step in d/rules of all rdeps, ..)

Building a librust-librsvg-dev containing the librsvg Rust source (and
for variant 2 above, the vendored sources) should be fairly
straight-forward.

Obviously 1) is the cleaner approach, since it would also allow
src:libsrvg to stop vendoring its Rust dependencies, reducing the number
of duplicate copies in the archive.

I am not sure what sort of exception/agreement there is in place w.r.t.
librsvg's current vendoring, and whether that should be re-evaluated now
that it is properly published on crates.io and no longer uses vendoring
upstream (AFAICT).

The main downside is that currently non-vendored statically linked Rust
binaries/cdylibs only have "limited" security support. IMHO this is
something we should try to solve during the Trixie release cycle, or at
least start working on in earnest.

Bug#1021711: rustc: Bootstrapping process only seems to work for amd64

[Fabian Grünbichler]

On Thu, 13 Oct 2022 12:42:59 +0100 Christopher Obbard 
 wrote:
> Package: rustc
> Version: 1.61.0+dfsg1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> When following the bootstrapping process in d/README.source, it only
> seems to generate a tarball with the amd64 binaries despite the variable
> upstream_bootstrap_arch set to include more bootstrap architectures.
> 
> I am running:
> 
>   $ upstream_bootstrap_arch="amd64 arm64" debian/rules source_orig-stage0
>   ...
>   debian/make_orig-stage0_tarball.sh
>   downloading 
> https://static.rust-lang.org/dist/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>    
> 100.0%
>   extracting 
> rustc/build/cache/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   downloading 
> https://static.rust-lang.org/dist/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>    
> 100.0%
>   extracting 
> rustc/build/cache/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   downloading 
> https://static.rust-lang.org/dist/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>    
> 100.0%
>   extracting 
> rustc/build/cache/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   building stage0 tar file now, this will take a while...
>   
> 
>   orig-stage0 bootstrapping tarball created in 
> ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz
>   containing the upstream compilers for amd64 arm64
> 
>   You *probably* now want to do the following steps:
> 
>   1. Add [!amd64 !arm64] to the rustc/cargo Build-Depends in d/control
>   2. Update d/changelog
>   3. Run `dpkg-source -b .` to generate a .dsc that includes this tarball.
>   
> 
> 
>   $ tar tvf ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz
>   drwxr-xr-x root/root 0 2022-10-13 11:34 2022-04-07/
>   -rw--- root/root  57248964 2022-04-07 14:44 
> 2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   -rw--- root/root   6585328 2022-04-07 14:41 
> 2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   -rw--- root/root  27569116 2022-04-07 14:44 
> 2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz
>   -rw-r--r-- root/root 0 2022-10-13 11:34 
> dpkg-source-dont-rename-parent-directory
> 
> As you can see, only the x86_64 binary is present inside the stage0 tarball.
> 
> To workaround this locally, I manually called
>   $ PYTHONPATH=src/bootstrap debian/get-stage0.py 
> then re-ran the source_orig-stage0 which packed the downloaded tarballs into
> the stage0 tarball.

since this came up in IRC a few times as well - I can reproduce the
problem, and I think it stems from the interaction between the two
architecture(-test).mk files and debian/rules, but I haven't had time to
investigate more (yet).

Bug#1031693: import-dsc: dangling pristine-tar treeish with multiple components

[Fabian Grünbichler]

On Fri, 8 Dec 2023 15:52:30 + Huw Jones  wrote:
> Hi,
> 
> Is there anything I can do to help resolve this issue?
> 
> Kind regards,
> Huw

FWIW, this also affects plain "gbp import-orig" with component tar
balls, and the patch from this bug fixes the issue for me when applied
on top of 0.9.33 from sid.

Bug#1061486: 7zip: Has both Breaks+Replaces and Conflicts against p7zip-full and p7zip

[Fabian Greffrath]

Source: 7zip
Version: 23.01+dfsg-7
Severity: normal

Hi again,

currently, the 7zip package has both a versioned Breaks+Replaces as
wellas a versioned Conflicts relationship against the p7zip-full and
p7zip packages. In general, if a package conflict can be resolved by
installing a specific version of "the other" package, a
Breaks+Replaces relationship is sufficient. A Conflicts relationship
is meant for two packages which can never get installed at the same
time, e.g. because they provide the same service.

https://www.debian.org/doc/debian-policy/ch-relationships.html

Cheers,

 - Fabian



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

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

Bug#1061485: 7zip: The 7zip-standalone package isn't standalone

[Fabian Greffrath]

Source: 7zip
Version: 23.01+dfsg-7
Severity: normal

Hi,

currently, the 7zip-standalone package has a hard dependency on the
full-featured 7zip package, rendering it quite useless as a "light"
standalone package.

Please consider either turning it into an actual standalone package
without any further dependencies or remove it altogether, if it
doesn't provide any more functionality than the 7zip package and
depends on it anyway.

Thanks,

 - Fabian



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

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

Bug#1060674: mjpegtools-gtk: broken dependencies

[fabian]

Hi,

the mjpegtools-gtk package has been removed from Debian to get rid of 
the libgtk2 dependency.


- Fabian

Am 12.01.2024 15:52, schrieb Vladmimir Stavrinov:

Package: mjpegtools-gtk
...
Debian Release: trixie/sid

Bug#1053556: [Pkg-rust-maintainers] Bug#1053556: Bug#1050769: dh-cargo: should provide a build() method

[Fabian Grünbichler]

On Mon, Oct 30, 2023 at 09:30:57AM +0900, Marc Dequènes wrote:
> Quack,
> 
> Sorry for the lag, I really lacked time and energy recently but I'll try to
> upload a fix soon.
> 
> On 2023-10-07 04:09, Jeremy Bícha wrote:
> > No, greetd needs to build itself correctly regardless of whether there
> > are helper functions available.
> 
> You're right and I did not realize nocheck would be used for real in this
> package. I never saw this as a perfect solution but until debcargo
> implements what's needed that seemed fine.
> 
> > https://salsa.debian.org/debian/greetd/-/merge_requests/4
> 
> It looks fine but that's precisely what I wanted to avoid: I do not want to
> maintain the build steps and have to update the calls and flags when cargo
> or any other piece of tooling changes.
> Maybe that won't change often but that's still silly to implement that in
> each and every leaf package and as a consequence there's no unified policy.
> Unfortunately I do not have the bandwidth to propose debcargo changes.

I think we can actually implement a build-step, and no-op that in
debcargo/dh-cargo for pure library crates (for those, "building" is just
testing, the build result is thrown away and only the sources are
contained in the "built" binary package). this should get us what you
want (building application with nocheck, just skipping tests) without
causing any fallout, although it of course requires careful testing.

FWIW, dh_auto_install (which runs `cargo install`) would also take care
of building the binary, if it hasn't been built already. so for a
regular application packaged in debcargo-conf, a nocheck build already
works and skips the tests while still building the application binary.

> So I guess I'll apply the patch you kindly provided but I'm thinking about
> handing over the maintainership of wlgreet and greetd to people who really
> have time to do it properly, or… maybe comaint.
> 
> Anyway, thanks for the report and patch everyone.
> \_o<

Bug#1051501: [Pkg-rust-maintainers] Bug#1051501: provide subcommand that lists debian dependencies for a crate

[Fabian Grünbichler]

On Fri, Sep 08, 2023 at 06:50:22PM +, Jelmer Vernooij wrote:
> Package: debcargo
> Severity: wishlist
> 
> I've packaged a few Python packages that include rust code. Since they're
> python packages, I can't just use debcargo.  However, it would be great if I
> somehow use debcargo to extract Debian dependency information from Cargo.toml.
> 
> Perhaps a subcommand for debcargo that just dumps out a list of Debian
> dependencies and the features they are relevant for?

FWIW, there's both salsa issue[0] and a draft MR[1] open for this, the
former even predates this wishlist bug. Maybe something to finish over
the holidays ;)

FWIW, as a workaround, you can use debcargo's "local crate support" to
kickstart your d/control contents.

given a dir that contains a Cargo.toml file (let's call it "foobar"),
create a debian/debcargo.toml file with the following contents:

overlay = "."
crate_src_path = ".."

and add "debian" to the excludes in Cargo.toml:

exclude = ["debian/"]

(or add it an already existing list of exclusions)

now the following command will generate the debian dir like for a
regular debcargo-packaged crate, even if "foobar" is not published on
crates.io:

debcargo package --config ./foobar/debian/debcargo.toml --no-overlay-write-back 
--directory ./tmp-foobar foobar 0.1.0

FWIW, since this effectively calls "cargo publish" under the hood, it
has the same restrictions w.r.t. dependencies in Cargo.toml (no
unversioned deps except for dev-dependencies which are ignored, no
path/git deps except if they have a version requirement, ..).

0: https://salsa.debian.org/rust-team/debcargo/-/issues/56
1: https://salsa.debian.org/rust-team/debcargo/-/merge_requests/49

Bug#1055918: [Pkg-rust-maintainers] Bug#1055918: rust-hyper: please provide newer upstream branch v1.0

[Fabian Grünbichler]

On Tue, Nov 14, 2023 at 10:25:51AM +0100, Jonas Smedegaard wrote:
> Source: rust-hyper
> Version: 0.14.25-2
> Severity: normal
> Tags: upstream
> 
> Please separately most likely separately rather than upgrading, due to
> not yet stable) newer upstream branch v1.0 (even if only available as
> release candidate for now).

hyper is stable upstream now, so we should probably prepare a transition
for this eco-system (hyper*, http*, h2, ..). one known (to me) blocker
is reqwest, which hasn't updated upstream yet:

https://github.com/seanmonstar/reqwest/issues/2039

Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Fabian Grünbichler]

On Thu, Dec 07, 2023 at 01:02:58AM +, Peter Green wrote:
> On the one hand I'm not at all convinced this bug is rc, on the other
> hand I don't think shipping a four year old version of env-logger
> in the next release of Debian is a great idea.
> 
> So I decided to look at the reverse dependencies, I found three
> 
> safe-vdash - this is a Jonas package, the dependency on rust-env-logger-0.7 
> seems bogus, I filed a bug.
> rust-tracing-log - the new version no longer depends on env-logger, I updated 
> it along with it's reverse dependency tracing-subscriber.
> rspotify - this package is long term broken, noctis expressed an interest in 
> fixing it back in January but I don't know what if-any progress he has made 
> since then.

(as always!) thanks for the analysis above. I agree that reducing the
env_logger versions in testing is a good idea in any case.

the question is whether we want to drop the unversioned provides in
semver-suffixed packages altogether in debcargo - IIRC debcargo itself
would never generate an unversioned dependency in d/control except if
Cargo.toml itself has an unversioned dependency, which is not possible
for crates on crates.io. that would only leave manually generated
dependencies, or patched crates with very strong relaxation.

and even so, the normal flow for semver-suffix packages would work just fine:
- fork semver suffix package, upload to NEW/experimental
- wait for NEW processing
- bump regular package, upload both to unstable

and any package that uses an unversioned dependency would stay on the
non-suffixed package providing/containing the latest packaged version,
while anything depending on the old semantic version would switch to the
suffixed package.

the only thing that wouldn't work anymore is having a versioned dep on
the unversioned package where the version constraint would only be
satisfied by the suffixed package.

e.g., librust-env-logger-dev (<= 0.8)

Bug#892958: deb-systemd-invoke: add support for "reload-or-restart"

[Fabian Grünbichler]

On Mon, 17 Dec 2018 16:51:53 +0100 Fabian =?utf-8?Q?Gr=C3=BCnbichler?=  wrote:
> any feedback on this? I am waiting to rebase the debhelper MR making use
> of this functionality until there is some kind of indication that it
> might be accepted here ;)

FWIW, I rebased both the init-system-helpers/deb-systemd-invoke as well as 
debhelper/dh_installsystemd MRs, and would still appreciate feedback since I'd 
like this to be a supported option in trixie+ :)

Bug#1004430: #1004430: tar: `numeric-owner` not honored for ACLs

[Fabian Grünbichler]

On July 25, 2023 10:51 pm, Timo Lindfors wrote:
> Hi,
> 
> just for your information, upstream has recently accepted the following 
> patch:
> 
> http://git.savannah.gnu.org/cgit/tar.git/commit/?id=5461025569c2d946fb31b79f16f60e923bbd79f9

and accordingly, this is now fixed upstream in v1.35 :)

Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: Bug#1042859: cargo: Please upgrade to at least 0.67.0

[Fabian Grünbichler]

On Fri, Nov 03, 2023 at 03:24:07PM +0100, Eduard Bloch wrote:
> Hallo,
> * Fabian Grünbichler [Fri, Nov 03 2023, 01:57:08PM]:
> > > Eduard Bloch  hat am 03.11.2023 13:46 CET geschrieben:
> > >
> > >
> > > Hallo,
> > > * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]:
> > >
> > > > > the version of Cargo seriously needs an update. Because the word is
> > > > > moving and the old version performs increasingly bad.
> > > >
> > > > the upgrade (to 0.70.1, since later versions require a lot of NEW 
> > > > processing first) is being prepared, but it takes a long time because 
> > > > it is very involved.
> > > >
> > > > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48
> > > > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21
> > > >
> > > > also related, and hopefully improving this in the future:
> > > >
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658
> > > > https://salsa.debian.org/rust-team/rust/-/merge_requests/27
> > >
> > > Okay, I get the idea. That said, I find it quite strange that you want
> > > to include a Python dependency in order to run a central Rust tool.
> > >
> > > Would you like me to rewrite the proposed cargo wrapper script into a
> > > native Rust app? That's a serious offer, I have IMHO sufficient Python
> > > and Rust experience, recently working on something partly similar
> > > (https://gitlab.com/setecastronomy/wec ).
> >
> >
> > I am not sure what you are referring to, but the fact that some 
> > helper/wrapper scripts are written in python is in no way related to what 
> > is making updates cumbersome at the moment.
> 
> I was refering to the last link from the post above:
> 
> https://salsa.debian.org/rust-team/rust/-/merge_requests/27/diffs#98066737513db2808acb090ffe631b89bd788499

that is not related at all either to updating cargo, or merging the two
source packages..

> > and we most definitely don't want to rewrite the cargo wrapper in rust, 
> > that would serve no purpose at all.
> 
> Depends on the whole picture. From that statement I understand that
> reducing dependencies on further interpreters (like Python) is not a
> goal here.

it is indeed not, see below.

> > > (Not sure about bootstrapping, though. Is rustc available while our
> > > source package is being built?)
> >
> > of course rustc is required to build both rustc and cargo, since both are 
> > written in rust. note that rustc itself also has a build-dependency on 
> > python anyway, since it's (internal) bootstrapping/build tool is written in 
> > python (and rust).
> 
> Okay. But I did not have only build-deps of the Debian source package
> in mind, more the dependencies of the binary package, i.e. what the
> regular user (application developer) gets. Why should cargo have a
> dependency on Python? Looks quite strange to me.

it should not - but it also does not.

cargo (the package in Debian) only suggest python3. you can use
(/usr/bin/)cargo (the binary as packaged in Debian) without having
python installed. only when you use cargo via the wrapper script
/usr/share/cargo/bin/cargo, which exists for integrating cargo into
Debian packaging, would you need to have python3 installed. that script
is not in anyone's $PATH (by default), and is only supposed to be called
directly or indirectly via d/rules (manually after doing the appropriate
setup steps, or via dh-cargo) when building a package. dh-cargo as a
result depends on python3, but that is not relevant for someone just
installing cargo to run cargo-the-binary for application development.


signature.asc
Description: PGP signature

Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: cargo: Please upgrade to at least 0.67.0

[Fabian Grünbichler]

> Eduard Bloch  hat am 03.11.2023 13:46 CET geschrieben:
> 
>  
> Hallo,
> * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]:
> 
> > > the version of Cargo seriously needs an update. Because the word is
> > > moving and the old version performs increasingly bad.
> >
> > the upgrade (to 0.70.1, since later versions require a lot of NEW 
> > processing first) is being prepared, but it takes a long time because it is 
> > very involved.
> >
> > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48
> > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21
> >
> > also related, and hopefully improving this in the future:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658
> > https://salsa.debian.org/rust-team/rust/-/merge_requests/27
> 
> Okay, I get the idea. That said, I find it quite strange that you want
> to include a Python dependency in order to run a central Rust tool.
> 
> Would you like me to rewrite the proposed cargo wrapper script into a
> native Rust app? That's a serious offer, I have IMHO sufficient Python
> and Rust experience, recently working on something partly similar
> (https://gitlab.com/setecastronomy/wec ).


I am not sure what you are referring to, but the fact that some helper/wrapper 
scripts are written in python is in no way related to what is making updates 
cumbersome at the moment.

and we most definitely don't want to rewrite the cargo wrapper in rust, that 
would serve no purpose at all.

> (Not sure about bootstrapping, though. Is rustc available while our
> source package is being built?)

of course rustc is required to build both rustc and cargo, since both are 
written in rust. note that rustc itself also has a build-dependency on python 
anyway, since it's (internal) bootstrapping/build tool is written in python 
(and rust).

Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: cargo: Please upgrade to at least 0.67.0

[Fabian Grünbichler]

> Eduard Bloch  hat am 02.11.2023 09:54 CET geschrieben:
> 
>  
> severity 1042859 important
> thanks
> 
> Hallo,
> * Mike Hommey [Wed, Aug 02 2023, 06:37:08AM]:
> 
> > 0.66 is the version of cargo that goes alongside rustc 1.65.
> > 0.67 is the version of cargo that goes alongside rustc 1.66.
> > Unstable and testing have rustc 1.66, so cargo should be updated to at
> > least version 0.67.
> 
> Dear Rust Maintainers,
> 
> the version of Cargo seriously needs an update. Because the word is
> moving and the old version performs increasingly bad.

the upgrade (to 0.70.1, since later versions require a lot of NEW processing 
first) is being prepared, but it takes a long time because it is very involved.

https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48
https://salsa.debian.org/rust-team/cargo/-/merge_requests/21

also related, and hopefully improving this in the future:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658
https://salsa.debian.org/rust-team/rust/-/merge_requests/27

Bug#1055088: game-data-packager: jazz_jackrabbit_collection information outdated

[fabian]

Am 2023-11-02 15:10, schrieb Alexandre Detiste:

Do you know what "_csv2" means ?


Nope, sorry. I have just taken the archive as it comes.

Cheers,

 - Fabian

Bug#1055088: game-data-packager: jazz_jackrabbit_collection information outdated

[Fabian Greffrath]

Package: game-data-packager
Version: 77
Severity: normal
X-Debbugs-Cc: openj...@packages.debian.org

Hi,

the packaging information for the jazz_jackrabbit_collection package
from GOG.com is outdated. Thre is a new package available for download
called 'setup_jazz_jackrabbit_collection_2.0_csv2_(51327).exe' now,
and some of the file contents have changed.

What is the best way to update g-d-p in this regard? Manually, file by
file? Or is there a better way?

Cheers,

 - Fabian


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

Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 game-data-packager depends on:
ii  python3 3.11.4-5+b1
ii  python3-debian  0.1.49
ii  python3-yaml6.0.1-1

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  77

Versions of packages game-data-packager suggests:
pn  arj   
ii  binutils  2.41-6
pn  cabextract
pn  cdparanoia
pn  dynamite  
ii  gcc   4:13.2.0-1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  innoextract   1.9-0.1
pn  lgc-pg
ii  lgogdownloader3.11-2
ii  lhasa [lzh-archiver]  0.4.0-1
ii  make  4.3-4.1
ii  p7zip-full16.02+dfsg-8
ii  pkexec123-3
ii  python3-gi3.46.0-1
ii  python3-omg   0.5.1-1
ii  python3-pil   10.0.0-1
pn  steam 
pn  steamcmd  
pn  unace-nonfree 
ii  unar  1.10.7+ds1+really1.10.1-2+b3
pn  unrar 
pn  unshield  
ii  unzip 6.0-28
pn  vorbis-tools  
ii  xdelta1.1.3-10.4
ii  xdelta3   3.0.11-dfsg-1.2
pn  xorriso   

-- no debconf information

Bug#1055058: handbrake-cli: Encoding with svt_av1 or svt_av1_10bit fails

[fabian]

Hi Julian,

"""
[13:21:57] encavcodecInit: avcodec_find_encoder_by_name(libsvtav1) 
failed

ERROR: Failure to initialise thread 'FFMPEG encoder (libavcodec)'
"""

most probably related to this:

"""
 ffmpeg (7:6.0-7) unstable; urgency=medium
 .
   * debian/: Disable libsvtav1 to unblock transition
"""


Cheers,

 - Fabian

Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Fabian Grünbichler]

On Fri, Oct 27, 2023 at 07:55:07PM +0300, Adrian Bunk wrote:
> On Fri, Oct 27, 2023 at 05:07:12PM +0200, Fabian Grünbichler wrote:
> > On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote:
> > > Package: librust-env-logger-0.7+default-dev
> > > Severity: serious
> > > 
> > > https://buildd.debian.org/status/fetch.php?pkg=mdevctl&arch=arm64&ver=1.2.0-4%2Bb3&stamp=1697626199&raw=0
> > > 
> > > ...
> > > Merged Build-Depends: ..., librust-env-logger+default-dev,
> > > ...
> > > The following NEW packages will be installed:
> > > ...
> > >   librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev
> > > ...
> > > error: failed to select a version for the requirement `env_logger = 
> > > "^0.10.0"`
> > > ...
> > > 
> > > 
> > > This is due to:
> > >   librust-env-logger+default-dev reverse Provides:
> > >   librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4)
> > >   librust-env-logger-dev 0.10.0-2 (= 0.10.0-2)
> > > 
> > > 
> > > I'll file a separate bug for mdevctl having a too loose build dependency.
> > 
> > I am not sure why it shouldn't? librust-env-logger-0.7-dev does contain
> > env_logger source code after all
> >...
> 
> Having two in the archive makes it unpredictable which version the 
> dependency solver uses when building a reverse dependency.

yes. with the caveat listed below that having such a dep in the first
place is non-standard.

> Different architectures might end up being built with different versions.

that's always true though since nothing forces builds on different archs
to use the same set of packages?

> A binNMU might change the version used, even switching from 0.10 to 0.7.

yes. if the rdep is compatible with both versions, is that a problem?
and this is also the case in general, a binNMU is not different than
other builds in this regard, right?

> rust-env-logger-0.7 (0.7.1-3) unstable; urgency=medium
>   * Release as versioned package for other rdeps that can't update to 0.9
> 
> This should really only be used after an explicit opt-in.

it is. having an unversioned dependency is one way to say "I am fine
with getting a version that might not be the most recent". the other is
depending on (in this case) librust-env-logger-0.7-dev (or a variant
thereof), which might be built by src:rust-env-logger (in version
0.7.X-Y) or by src:rust-env-logger-0.7 (in version 0.7.X-Y).

the non-versioned variant should only be used if you want to build with
a possible range of versions and don't care which one you get. the
default behaviour (at least in Rust packaging) is to depend on the
semver-prefix-containing variant, which entails exactly the behaviour
you want, except for a possible short period of time where
src:rust-env-logger in the newer version might not have hit the archive
yet, but src:rust-env-logger-0.7 already has. in that case, the two
should be functionally identical though, so it matters even less which
one gets picked ;)

> 
> >...
> > depending on just librust-env-logger+default-dev without a
> > version constraint says "I want env_logger with the default feature(s),
> > but don't care about the version" - which in almost all cases isn't
> > sensible.
> >...
> 
> 
> There are packages with
>   Build-Depends: librust-env-logger+default-dev (>= 0.9)
> in the archive, if these were >= 0.7 it would be the same problem.

yes, but if they were >= 0.7 they should be fine with 0.7? and if the
new src:rust-env-logger (in version > 0.7) doesn't build yet on an arch,
or is still waiting for some dependency to become available, or .. then
changing the semver suffix package to not provide librust-env-logger-dev
would break those rdeps, since they become unsatisfiable? or, if the old
version is still around binary-wise, the builds might pick up different
versions anyway on different architectures..

the only reason those semver-suffix packages even exist in the first
place is to allow
- seamless transitions
- keeping older versions around for a time in case the upstream
  ecosystem hasn't upgraded fully yet, and doing it downstream is not
  feasible because the breaking changes are too big

while the latter could be supported even with the non-versioned provides
dropped, the former would not, at least not for rdeps that opt into
relaxing the semver constraints.

the only reason to have an unversioned dep is to not need an immediate
rebuild:
- upload package A with (build-)dep on env-logger >= 0.7 when 0.7 is in the
  archive
-- expecting a compatible 0.8/0.9/..
- env-logger 0.8 gets uploaded at the same time as env-logger-0.7 semver
  varia

Bug#1054156: [Pkg-rust-maintainers] Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Fabian Grünbichler]

On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote:
> Package: librust-env-logger-0.7+default-dev
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=mdevctl&arch=arm64&ver=1.2.0-4%2Bb3&stamp=1697626199&raw=0
> 
> ...
> Merged Build-Depends: ..., librust-env-logger+default-dev,
> ...
> The following NEW packages will be installed:
> ...
>   librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev
> ...
> error: failed to select a version for the requirement `env_logger = "^0.10.0"`
> ...
> 
> 
> This is due to:
>   librust-env-logger+default-dev reverse Provides:
>   librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4)
>   librust-env-logger-dev 0.10.0-2 (= 0.10.0-2)
> 
> 
> I'll file a separate bug for mdevctl having a too loose build dependency.

I am not sure why it shouldn't? librust-env-logger-0.7-dev does contain
env_logger source code after all

the expectation is that any rdep that requires a certain version
(according to the semantic versioning rules employed by almost the
entire rust ecosystem) would encode that information in the Debian
package relationship (either by adding a version constraint, or
depending on the virtual or real package encoding the appropriate
version prefix in the package name/provides, or both).  by virtue of
those rules, depending on just librust-env-logger+default-dev without a
version constraint says "I want env_logger with the default feature(s),
but don't care about the version" - which in almost all cases isn't
sensible.

there's ongoing work on providing a command in debcargo that allows
rdeps that don't use debcargo for the full packaging (e.g., because they
are a rust component of a bigger project) to translate Cargo.toml into
corresponding, version-constraint-preserving Debian package relationship
stanzas:

https://salsa.debian.org/rust-team/debcargo/-/merge_requests/49


signature.asc
Description: PGP signature

Bug#1054658: rustc: merge src:cargo into src:rustc

[Fabian Grünbichler]

Source: rustc
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

as discussed in the last rust team meeting, we'd like to merge the
packaging of src:rustc and src:cargo. this bug report is filed to have a
place for discussing potential objections and collect input.

a bit of background about the status quo. the rust toolchain consist of
many parts, only some of which are packaged for Debian. the two big
components are cargo (the package manager and build tool) and rustc (the
compiler + stdlib). while some parts of the toolchain are developed
upstream in their own repository, the development of the toolchain
itself happens via a single repository:

https://github.com/rust-lang/rust/

similarly, the official release artifacts are created for all components
from this repository, including binary artifacts and source tarballs,
such as
https://forge.rust-lang.org/infra/other-installation-methods.html#source-code

currently, the packaging structure is like this:

1.) src:rustc

uses a repacked/pruned version of the official toolchain source tarball.
pruning happens via subset of debian/patches and some helper scripts.
components which are not needed for packaging in Debian are removed, to
minimize vendoring.

among other things, an embedded copy of LLVM, the cargo tool and
documentation, non-essential parts of rust-analyzer and other tools
either not packaged or packaged separately are removed.

besides the compiler and std library, src:rustc currently also builds
binary packages for two adjacent tools: clippy and rustfmt, as well as a
binary needed for macro support in rust-analyzer, helpers for
integration into gdb and lldb, and documentation.

clippy, rustfmt and rust-analyzer are all developed as standalone
projects in their own git repositories, but merged into the main rust
toolchain repository and released as one toolchain upstream.

2.) src:cargo

this source package and the corresponding binary packages contain the
cargo tool and some helper scripts specific to Debian. it currently uses
GH tag/release tar balls from the main development repository of cargo.
pruning of the tarball happens via a complicated procedure that attempts
to re-use patches for vendored crates from debcargo-conf (the Debian
Rust team monorepo for packaging regular crates). this procedure is
non-deterministic (it runs `cargo vendor` which can pick up newer
versions if run at a later point in time) and quite involved. as a
result, updating src:cargo usually entails updating a big chunk of
crates packaging via debcargo-conf to reduce the version drift between
the packaged versions which patches we want to reuse, and the versions
picked up by `cargo vendor`.

3.) src:rust-cargo

since there are at least two packages in Debian that employ cargo as
library, cargo is also packaged as a regular library crate via
crates.io. this package is then used as build-dependency for other
packages, like debcargo, the main helper used by the Debian Rust team.


the proposal is to ditch src:cargo in favor of moving the associated
helpers to src:rustc, and no longer patching out cargo-related
components of the toolchain there. as a result, bin:cargo and
bin:cargo-doc would be built from src:rustc, with both parts being built
from the same upstream toolchain release tarball, instead of from two
different "releases". src:rust-cargo would stay as it is now.

pros:

- Ubuntu already made this switch a couple versions back, syncing in
  both ways would be easier[0]
- rustc and cargo would always be packaged in lockstep, instead of cargo
  lagging behind like it has most of the time in the recent past
- the complicated patch syncing step is gone
- one less source package with special vendoring considerations
- packaging the cargo book instead of just rustdoc API documentation
  would be feasible
- bin:cargo would finally have the right version number (right now, it
  has the "eternally unstable" one of the cargo library crate)

cons

- more care needs to be taken when pruning the toolchain release
  tarball, since cargo has more network related vendoring where we don't
  want to bundle C libraries by accident
- effort to switch over packaging (although a lot of the Ubuntu change
  can likely be re-used)


any input/feedback would be appreciated!

0: https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/202


signature.asc
Description: PGP signature

Bug#1053096: dh-cargo-built-using should switch to Static-Built-Using

[Fabian Grünbichler]

Package: dh-cargo
Version: 30
Severity: wishlist
X-Debbugs-Cc: debian@fabian.gruenbichler.email

See https://wiki.debian.org/StaticLinking and 
https://lists.debian.org/debian-legal/2023/09/msg3.html

dh-cargo-built-using currently sets Built-Using for "source-left" licenses, and
X-Cargo-Built-Using for any others (while going through the transitive dep
tree). it should switch to Static-Built-Using like dh-go, so that a new dh tool
for aggregating d/copyright does not need to special case different language
ecosystems/substvars.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dh-cargo depends on:
ii  cargo  0.66.0+ds1-1
ii  debhelper  13.11.4
ii  perl   5.36.0-7
ii  python33.11.2-1+b1

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information

Bug#983291: Re: Default font: Transition from DejaVu to Noto

[Fabian Greffrath]

> If I recall it correctly, the primary suggestion in that bug report
> is to split fonts-noto-core into an LCG and an "other" package.

I have created a MR to implement this:

https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1

 - Fabian



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

Bug#1051815: [Pkg-rust-maintainers] Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Fabian Grünbichler]

> Peter Green  hat am 13.09.2023 05:24 CEST geschrieben:
> On 12/09/2023 23:30, Faidon Liambotis wrote:
> > Control: reassign -1 rustc 1.68.2+dfsg1-1
> > Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)
> >
> > On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:
> >> The autopkgtests for wasmedge fail with rustc 1.68, I have observed this 
> >> with
> >> both testing and unstable's versions of wasmedge, and with both testing and
> >> unstable's versions of wasi-lib.
> > Thanks for the report. Actually, I think the WasmEdge autopkgtests are
> > catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries
> > that do not work with neither WasmEdge, nor Wasmtime (the latter is not
> > in Debian).
> And it seems the issue persists with rustc 1.69 :(
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wasmedge/37797497/log.gz

this is most likely a regression in wasi-libc (it just got exposed once rustc 
switched to the new version). the last version enabled stack protection since 
upstream allegedly supports that now, seems it's still broken and I'll revert 
that change and report back.

Bug#1041312: [Pkg-fonts-devel] Bug#1041312: fonts-noto: Migrate to new upstream sources, and split the fonts according to upstream

[fabian]

Hi Amr,

Am 2023-07-17 12:19, schrieb Amr Ibrahim:

https://github.com/notofonts/notofonts.github.io


the fonts appear to be organized into different subdirectories with 
varying content.


Do you know upstream's stance on this? Is hinted/ttf always preferable 
over unhinted/* and what's the matter with the fonts in googlefonts/*? 
And how about the unhinted/variable-ttf, unhinted/slim-variable-ttf and 
unhinted/otf variants?


You can see from that website that upstream releases individual font 
files. So

please try to re-package the font files in Debian accordingly.


They offer a snapshow of the entire repository for download in the 
Releases section:


https://github.com/notofonts/notofonts.github.io/releases

These could be downloaded, have the undesired fonts stripped off, get 
repacked and split up into indiviual Debian packages.


I have to admit that I just tried this for the fun, but gave up when the 
download size reached 1GB. o_O


Cheers,

 - Fabian

Bug#1051487: python3-reportlab: depends on T1 and TTF fallback fonts at the same time

[Fabian Greffrath]

Package: python3-reportlab
Version: 4.0.4-11
Severity: minor

Hi,

according to the comment added in
debian/patches/dejavu-font-default.diff:

# the T1 file was not yet found!
# fall back to Vera TTF font

This reads to me that python-reportlabs tries to find the T1 fonts
*first* and then falls back trying to find the TTF fonts only if the
former doesn't succeed. However, the package has hard dependencies on
both the T1 fonts in fonts-urw-base35, and the TTF fallback fonts in
fonts-dejavu-core and fonts-dejavu-extra.

I guess it would suffice to let the package depend on
"fonts-urw-base35 | fonts-dejavu-core, fonts-urw-base35 |
fonts-dejavu-extra" to make sure that either the T1 fonts or *both*
TTF fallback fonts packages are installed.

Thanks!

Cheers,

 - Fabian


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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-reportlab depends on:
ii  fonts-dejavu-core   2.37-8
ii  fonts-dejavu-extra  2.37-8
ii  fonts-urw-base3520200910-7
ii  python3 3.11.4-5+b1
ii  python3-freetype2.4.0-1
ii  python3-pil 10.0.0-1
ii  python3-rlpycairo   0.3.0-2

python3-reportlab recommends no packages.

Versions of packages python3-reportlab suggests:
ii  evince [pdf-viewer] 45~alpha-2
pn  python-reportlab-doc
pn  python3-egenix-mxtexttools  

-- no debconf information

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Fabian Grünbichler]

> On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
>  wrote:
> > Package: src:rustc
> > Version: 1.66.0+dfsg1-1
> > Severity: wishlist
> > 
> > Chromium's new rust build requirements include the need for
> > /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libprofiler_builtins-*.rlib.
> > It would be really helpful to have this built into Debian's rust
> > packages.
> > 
> > Ubuntu apparently enabled it, and you can see their patch here:
> > 
> > 
> > However, that didn't work for me, at least not with the default of
> > BUILD_WINDOWS=true in rustc's current debian/rules. The build involving
> > --target $(WINDOWS_ARCH)-pc-windows-gnu  requires
> > libclang-rt-15-dev-wasm64 and some extra logic. I'm currently working on
> > an updated patch now.
> > 
> > 
> > 
> 
> 
> Alright, here's a patch that builds in sid.  I don't know exactly whether
> the stuff with wasi targets are okay building against libclang-rt-15-dev
> (amd64 package), or if it's supposed to be using the two dev-wasm packages,
> but I assumed the wasm packages. I'm also not sure if the versioned
> build-deps in the ubuntu patch are necessary, but I didn't include them.
> 
> This patch adds "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or whatever
> architecture it happens to be building on) to the profiler_builtins build
> flags when the target matches the host. In the case where the target is
> different from the host, it assumes a wasm build and sets
> "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending upon
> whether the target is 32 or 64 bits, respectively.

Thanks for the patch! the Windows part in d/rules looks wrong to me -
that is built with mingw, not wasi. I assume you are not interested in
that part, so maybe it would also be an option to guard it based on
target and just build it for the regular one (or regular+wasm, but not
windows/mingw)?

Bug#1051318: ITP: rust-xtr -- Gettext helper for Rust crates

[Fabian Grünbichler]

Package: wnpp
Severity: wishlist
Owner: Fabian Grünbichler 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org, 
debian@fabian.gruenbichler.email

* Package name: rust-xtr
* Version : 0.1.9
* Upstream Contact: Olivier Goffart 
* URL : https://github.com/woboq/tr/tree/master/xtr
* License : AGPL-3.0
* Programming Lang: Rust
* Description : Gettext helper for Rust crates

xtr is a tool for extracting strings from a Rust crate, for further processing
i18n flows. It is similar to GNU's xgettext, and can extract strings annotated
using the tr macro from its sibling crate 'tr', but also supports other gettext
based localisation crates such as gettext-rs, gettext, rocket_i18n.

The package will be maintained under the Debian Rust team umbrella in
debcargo-conf.

Bug#1050218: python3-reportlab: please do not depend on ttf-bitstream-vera

[Fabian Greffrath]

Package: python3-reportlab
Version: 4.0.4-9
Severity: normal

Hi,

currently python3-reportlab is the only package on my system which
pulls in the deprecated ttf-bitstream-vera font, which has long been
obsoleted by fonts-dejavu. Please change to *any* other font or at
least offer a choice of alternative fonts, but I really don't want
ttf-bitstream-vera on my system.

Thanks!

Cheers,

 - Fabian


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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-reportlab depends on:
ii  fonts-urw-base3520200910-7
ii  python3 3.11.4-5+b1
ii  python3-freetype2.4.0-1
ii  python3-pil 10.0.0-1
ii  python3-rlpycairo   0.3.0-2
ii  ttf-bitstream-vera  1.10-8.2

python3-reportlab recommends no packages.

Versions of packages python3-reportlab suggests:
ii  evince [pdf-viewer] 45~alpha-2
pn  python-reportlab-doc
pn  python3-egenix-mxtexttools  

-- no debconf information

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[fabian]

Hi Gunnar,

Am 2023-08-19 16:04, schrieb Gunnar Hjalmarsson:
Another question is if the Noto Sans Mono deficiency is important 
enough to motivate a Debian level change in this respect. I don't know. 
@Fabian, I sent this reply to you as well in the hope to broaden the 
discussion a bit.


thanks for asking my opinion!

Well, to be honest, the first thing I did after the change of the 
default monospace font in fontconfig was to manually change my terminal 
font back to DejaVu Sans Mono (I use FiraCode in my text editor anyway, 
so no need to change anythere there). I just can't stand the look of the 
Noto font family, and Noto Mono in particular.


However, I don't think that the upstream change to prefer Noto Mono over 
DejaVu Sans Mono was a decision based on aesthetics, but on sheer number 
of available glyphs. I guess they want to make sure that the default 
font chosen is the one that's available for the most script types.


However, we, in Debian, as a distribution, have all the rights to aim 
for the most aesthetically pleasing view of our default installation and 
thus I support the change back to DejaVu Sans Mono as the default 
monospace font. This, and we already support a localized installation 
and install some additional font packages based on the locale set during 
D-I. So, in the end, we always end up with more than just the default 
font, and thus can prefer one that "looks better" and gets supported by 
other fonts for additional glyph coverage.


Cheers,

 - Fabian

Bug#1050000: installation-reports: please install libpam-fprintd on a laptop with fingerprint reader

[Fabian Greffrath]

Package: installation-reports
Severity: wishlist


Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 20230808

Machine: Lenovo IdeaPad 5 14IAL7
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Hi,

I don't have a bug to report, installation went smooth this time! Just
a suggestion to make: My laptop has a built-in fingerprint reader
(relevant output of lsusb below). However, after installation it is
still impossible to register a fingerprint on the user setup page of
the gnome-settings app. This possibility is only added after the
libpam-fprintd package is installed. Thus, my suggestion is that if a
fingerprint reader is detected during the hardware detection phase
during the Debian installation to install the libpam-fprintd package.

Thanks!

 - Fabian


Bus 003 Device 003: ID 04f3:0c4d Elan Microelectronics Corp. ELAN:Fingerprint


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="13 (trixie) - installer build 20230808-00:02:33"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux brainbug 6.4.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-2 
(2023-07-30) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4601] 
(rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:382b]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder 
Lake-UP3 GT2 [Iris Xe Graphics] [8086:46a8] (rev 0c)
lspci -knn: Subsystem: Lenovo Device [17aa:382f]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Alder Lake Innovation Platform Framework Processor Participant [8086:461d] (rev 
04)
lspci -knn: Subsystem: Lenovo Device [17aa:3832]
lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core 
Processor PCI Express x4 Controller #0 [8086:464d] (rev 04)
lspci -knn: Subsystem: COMPAL Electronics Inc Device [14c0:013d]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation 12th Gen Core 
Processor Gaussian & Neural Accelerator [8086:464f] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:3838]
lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Alder Lake-P 
Thunderbolt 4 USB Controller [8086:461e] (rev 04)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 
3.2 xHCI Host Controller [8086:51ed] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3825]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared 
SRAM [8086:51ef] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3823]
lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake 
PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3814]
lspci -knn: Kernel driver in use: intel-lpss
lspci -knn: Kernel modules: intel_lpss_pci
lspci -knn: 00:15.3 Serial bus controller [0c80]: Intel Corporation Alder Lake 
PCH Serial IO I2C Controller #3 [8086:51eb] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3821]
lspci -knn: Kernel driver in use: intel-lpss
lspci -knn: Kernel modules: intel_lpss_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Alder 
Lake PCH HECI Controller [8086:51e0] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:382d]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:51ba] 
(rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3809]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Alder Lake PCI Express 
x1 Root Port #10 [8086:51b1] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:380d]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1e.0 Communication controller [0780]: Intel Corporation Alder 
Lake PCH UART #0 [8086:51a8] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:3818]
lspci -knn: Kernel dr

Bug#1040837: [Pkg-rust-maintainers] Bug#1040837: Bug#1040837: rust-log: breaks API without coordination

[Fabian Grünbichler]

On Sat, Jul 15, 2023 at 05:07:25PM +0200, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2023-07-15 09:55:04)
> > Quoting Fabian Grünbichler (2023-07-12 19:53:08)
> > > The feature in question is probably not a good candidate for packaging
> > > though, given the lack of stability guarantees provided by upstream[0]:
> > > 
> > > > This module is unstable and breaking changes may be made at any time.
> > > > See the tracking issue for more details.
> > > 
> > > The referenced tracking issue can be found here[1].
> > > 
> > > While the required crates (multiple ones from sval-rs/value-bag) are
> > > being packaged (mostly done, pending a re-upload to NEW and review
> > > there), I wonder whether enabling the feature was not a
> > > mistake/premature in the first place.
> > > 
> > > I did a quick test with ratt with the attached diff applied, and except
> > > for rust-sequoia-net (which fails for other reasons which are already
> > > fixed in experimental and just need a re-upload of the version there to
> > > unstable), building at least worked fine. I am not too familiar with
> > > either async-std, nor the kv feature of log to say whether this approach
> > > would be feasible - I'd be happy to hear your thoughts though! IMHO
> > > keeping this unstable aspect out of the archive for the time being would
> > > save us all from periodic breakage, with log itself (without the KV
> > > feature) being rather widely used.
> > 
> > Makes sense.
> > 
> > I will go through those of the reverse dependencies that I am involved
> > in maintaining, to see if th unstable feature can be avoided - and might
> > reach out for help if I cannot figure it out on my own.
> 
> While I appreciate your suggested patch for rust-async-std, the main
> obstacle to getting rid of the feature seems to not be rust-async-std
> but instead rust-kv-log-macro which has 19 reverse dependencies:
> 
> aardvark-dns
> rust-ahash
> rust-ahash-0.7
> rust-ashpd
> rust-async-attributes
> rust-async-std
> rust-async-std-resolver
> rust-async-tar
> rust-erbium
> rust-femme
> rust-flume
> rust-futures-timer
> rust-oxilangtag
> rust-oxiri
> rust-rustls
> rust-sequoia-net
> rust-trust-dns-client
> rust-trust-dns-resolver
> rust-trust-dns-server
> 
> I am not happy to create Debian-specific patches to somehow replace
> rust-kv-log-macro, and even if you were kind enough to initially create
> such patches there is still the headache of maintaining them.

ack, that's fair enough, like I said, I am not all too familiar with
that part of the ecosystem. IIRC this is the second or third time that
it breaks in Debian via sval..

> If the feature in rust-log really is considered too unstable for use in
> Debian, then it seems to me that we need to convince upstream projects
> to acknowledge that and themselves avoid the feature.

probably it would be best to push for stabilization :) do you want to
file some issues or should I? ;)

Bug#1041264: fonts-recommended: depends on removed fonts-liberation2

[Fabian Greffrath]

Why the severity? The fonts-liberation2 package is now a transitional package 
which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy 
gesendet

Bug#1041264: fonts-recommended: depends on removed fonts-liberation2

[Fabian Greffrath]

Why the severity? The fonts-liberation2 package is now a transitional package 
which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy 
gesendet

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Fabian Greffrath]

Do you have the heif-gdk-pixbuf package installed? Von meinem/meiner Galaxy 
gesendet

Bug#1040837: [Pkg-rust-maintainers] Bug#1040837: rust-log: breaks API without coordination

[Fabian Grünbichler]

On Tue, Jul 11, 2023 at 01:47:53PM +0200, Jonas Smedegaard wrote:
> Source: rust-log
> Version: 0.4.19-2
> Severity: serious
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> rust-log 0.4.19-2 apparently removed upstream feature kv_unstable
> (according to inspection of source of that packaging release -
> related changelog entry does not mention that feature).
> 
> This change to upstream API was done without coordination with
> reverse dependencies, and breaks at least librust-async-std-dev
> and its 17 reverse dependencies.
> 
> Yes, I am aware that changelog entry indicates this being a temporary
> change, pending packages lingering in NEW queue.  Please don't release
> breaking changes without prior coordination with reverse dependencies
> (e.g. the changes that cause bug#1040702), and in cases that is not
> possible (e.g. when accidentally ending at bug#1040702) then please
> notify reverse dependencies e.g. using a bugreport with tag "affects".

This was by mistake, and not on purpose.

The feature in question is probably not a good candidate for packaging
though, given the lack of stability guarantees provided by upstream[0]:

> This module is unstable and breaking changes may be made at any time.
> See the tracking issue for more details.

The referenced tracking issue can be found here[1].

While the required crates (multiple ones from sval-rs/value-bag) are
being packaged (mostly done, pending a re-upload to NEW and review
there), I wonder whether enabling the feature was not a
mistake/premature in the first place.

I did a quick test with ratt with the attached diff applied, and except
for rust-sequoia-net (which fails for other reasons which are already
fixed in experimental and just need a re-upload of the version there to
unstable), building at least worked fine. I am not too familiar with
either async-std, nor the kv feature of log to say whether this approach
would be feasible - I'd be happy to hear your thoughts though! IMHO
keeping this unstable aspect out of the archive for the time being would
save us all from periodic breakage, with log itself (without the KV
feature) being rather widely used.

In a slightly related note, there will be two upcoming transitions that
will affect (rust) packages of yours (bindgen to 0.65, and toml to 0.7)
as part of updating rust-cargo to 0.70. Would you appreciate bugs with
patches filed before the transition starts, or do you want to handle
those on your own? You can find some details in the (WIP) tracking
issue[2]. bindgen should be pretty straight-forward, for toml we will
likely opt for a period of semver-suffixing since the versions do have
breaking changes where breakage is not detected at compile time.

0: https://docs.rs/log/latest/log/kv/index.html
1: https://github.com/rust-lang/log/issues/328
2: https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48
diff --git a/rust-async-std-1.12.0/debian/changelog 
b/rust-async-std-1.12.0-patched/debian/changelog
index dfa43a8..5d6258f 100644
--- a/rust-async-std-1.12.0/debian/changelog
+++ b/rust-async-std-1.12.0-patched/debian/changelog
@@ -1,3 +1,9 @@
+rust-async-std (1.12.0-12.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+ -- Fabian Grünbichler   Wed, 12 Jul 2023 13:43:22 
+0200
+
 rust-async-std (1.12.0-12) unstable; urgency=medium
 
   * tighten autopkgtests
diff --git a/rust-async-std-1.12.0/debian/control 
b/rust-async-std-1.12.0-patched/debian/control
index 767ca01..84a3e66 100644
--- a/rust-async-std-1.12.0/debian/control
+++ b/rust-async-std-1.12.0-patched/debian/control
@@ -12,15 +12,12 @@ Build-Depends:
  librust-async-lock-2+default-dev ,
  librust-async-process-1+default-dev ,
  librust-crossbeam-utils-0.8+default-dev ,
- librust-femme-2+default-dev ,
  librust-futures-0.3+default-dev ,
  librust-futures-core-0.3+alloc-dev ,
  librust-futures-core-0.3+std-dev ,
  librust-futures-io-0.3+default-dev ,
  librust-futures-lite-1+default-dev ,
- librust-kv-log-macro-1+default-dev ,
  librust-log-0.4+default-dev ,
- librust-log-0.4+kv-unstable-dev ,
  librust-memchr-2+default-dev ,
  librust-once-cell-1+default-dev ,
  librust-pin-project-lite-0.2+default-dev ,
@@ -53,9 +50,7 @@ Depends:
  librust-futures-core-0.3+alloc-dev,
  librust-futures-io-0.3+default-dev,
  librust-futures-lite-1+default-dev,
- librust-kv-log-macro-1+default-dev,
  librust-log-0.4+default-dev,
- librust-log-0.4+kv-unstable-dev,
  librust-memchr-2+default-dev,
  librust-once-cell-1+default-dev,
  librust-pin-project-lite-0.2+default-dev,
diff --git 
a/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff 
b/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff
new file mode 100644
index 000..33b5de9
--- /dev/null
+++ b/rust-async-std-1.12.0-patched/debian/patches/disable-unstable-log-kv.diff
@@ -0,0 +1,77 @@
+Index: rust-async-std-1.12.0/Cargo.toml
+==

Bug#1040477: [Pkg-rust-maintainers] Bug#1040477: Bug#1040477: librust-syn-1-dev fails to coinstall

[Fabian Grünbichler]

On Thu, Jul 06, 2023 at 04:39:08PM +0100, Peter Green wrote:
> > I'd be very interested in knowing what this self-conflict is supposed to
> > achieve.
> 
> It is common upstream for there to be multiple semver-incompatible versions
> of each rust crate in use at a given time. Incompatibilities can range from
> minor corner cases that are easily patched away to complete redesigns
> 
> We try to only package one version of each crate at a time, but sometimes
> that isn't practical. When it becomes impractical we crate semver-suffix
> packages. The convention in the rust team is that the un-suffixed packages
> are used for the latest version and suffixed versions are used for any
> older versions.
> 
> When packaged crates are installed on a Debian system. They are installed
> in a path that depends on the upstream version of a crate.
> 
> This creates a problem though, if the same version is packaged as both
> a non-suffixed and suffixed version. Something that happens fairly
> frequently when a new version is introduced e.g.
> 
> Before:
> 
> librust-foo-dev version 1.23-1
> 
> After:
> 
> librust-foo-1-dev version 1.23-2
> librust-foo-dev version 2.34-1
> 
> This doesn't always happen, indeed it didn't happen in the case of syn,
> because a new upstream release of syn 1.x at the same time at the same
> time the semver suffix was introduced. However debcargo works on one
> crate at a time. so it doesn't know if this has happened or not.
> 
> When this happens, it leads to a file conflict. In an attempt to fix
> this breaks+replaces were added. Unfortunately these proved to be
> insufficient because while breaks against virtual packages work,
> replaces apparently don't. We are in the process of considering
> several options to fix this, but overall switching to conflicts+replaces
> seems the least likely to be problematic.
> 
> Do you encounter the same problem if you replace the breaks with
> conflicts? if so we would need to do something about it. I think
> the easiest would probablly be to put a version constraint on the
> conflicts/replaces. It would mean we would have to take care that
> semver-suffixed packages had a higher Debian revision than their
> un-suffixed counterparts, but I think that is managable.

and, with a bit of unexpected delay (sorry), the result of a discussion
Helmut and me had in parallel on IRC:

the issue with Conflicts arises in combination with M-A:same, since dpkg
and apt don't agree on which one of those two "angles" has higher
priority. to sort that out would require a release cycle or two.

it seems like this leaves the other alternative from #1034939 [0,
CC-ed], namely, switching the breaks and replaces to point at the real
package (version guarded), so that upgrading from "old" non suffixed
package (for which a newer version should exist by definition if a
suffixed package of the same version exists) while installing the
suffixed package of the same "old" version at the same time works. the
main downside (and reason why we preferred the Conflicts-based variant)
is that this means that two suffixed packages with different versions
are no longer co-installable (since the one with the higher version
would break the older one). thankfully, such issues should seldomly
matter in practice. or we could investigate just switching the replaces,
and keeping the breaks as is.

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

Bug#1040299: apt changelog should display local changelogs if fetching fails

[Fabian Grünbichler]

Package: apt
Version: 2.6.1
Severity: minor

Dear Maintainer,

with the recent change of long changelogs being truncated automatically, and
the full version of such truncated changelogs always being fetched by
`apt[-get] changelog`, there is no way anymore to use `apt changelog` to just
display "the changelog", if either

- the repository metadata doesn't contain a `Changelogs` reference (many 3rd
  party repositories, but also stable-security and stable-updates!)
- the "online" changelog does not exist (yet)

this is the case for security updates as well, e.g. today's ghostscript update
for bookworm (10.0.0-dfsg11+deb12u1):
- before the update, it fails because the changelog for that version is not
  found on metadata.ftp-masters.debian.org (ghostscript is also shipped by the
  "main" repository that has metadata.f-m.d.o as Changelogs host)
- after the update, it still fails for the same reason, even though at least
  the truncated changelog is available by virtue of the package being
  installed..

it would be nice if we could get back the old behaviour of "if fetching fails,
display local changelog contents" (possibly with a hint/warning about that 
fact).

it also seems to me like it is possible to confuse apt about where to fetch
changelogs from, as per the above example (security upgrade fetches changelog
from regular repo) - but since that requires control of the Release file, it's
probably not much of an issue in practice.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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 apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-5
ii  dpkg-dev1.21.22
ii  gnupg   2.2.40-1.1
pn  powermgmt-base  

-- no debconf information

Bug#1039955: fonts-liberation should provide /usr/share/fonts/truetype/liberation2 for backwards compatibility

[Fabian Greffrath]

Hi Nilesh,

Am Freitag, dem 30.06.2023 um 08:53 +0530 schrieb Nilesh Patra:
> Could you consider to vendor truetype/liberation2 as a symlink to
> truetype/liberation?

sure, I could do that. But then we'd end up again with two entries in
the file system for the same (in this case even identical) font.
Getting rid of this was the main incentive for this transition in the
first place.

I don't expect many packages to depend on the precise location of the
font files in the file system at all, we have fontconfig for this. The
actual transition from fonts-liberation2 to fonts-liberation (>= 1:2)
will be short and painless: You literally only have to change one char
in the path names.

In other words, I am reluctant to add additional complexity to the
transitional dummy package to ease a transition that's as complex as
changing a single char in a path name for depending packages.

I hope you understand.

Cheers,

 - Fabian



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

Bug#1039564: zsnes: is limited to the i386 architecture

[fabian]

Am 2023-06-27 14:49, schrieb Simon McVittie:

As a non-maintainer I didn't want to be the one to suggest that


I just filed #1039568:

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

Thanks for the wake up call. ;)

 - Fabian

Bug#1039568: RM: zsnes -- ROM; i386-only, abandoned upstream, alternatives exist

[Fabian Greffrath]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

as outlined by smcv in #1039564:

zsnes is i386-only due to its use of i386 assembly language, and this
seems unlikely to change any time soon.

Alternatives available for multiple CPUs include:

- ares
- higan
- mednafen
- any libretro frontend (for example retroarch) with one of:
- libretro-bsnes-mercury family
- libretro-snes9x (non-free)

Upstram development has ceased in 2007, the last Debian maintainer upload was 
in 2014 and there are more viable alternatives available.

Thanks!

 - Fabian

Bug#1039564: zsnes: is limited to the i386 architecture

[fabian]

Am 2023-06-27 10:47, schrieb Simon McVittie:

zsnes is i386-only due to its use of i386 assembly language, and this
seems unlikely to change any time soon.


We should probably just RM it.

Upstram development has ceased in 2007, the last Debian maintainer 
upload was in 2014 and there are more viable alternatives available.


 - Fabian

Bug#1039449: fluidsynth: High memory usage even if not used

[fabian]

Hi Witold,

Am 2023-06-26 02:32, schrieb Witold Baryluk:

I do not know why it autostarts, my guess is that pipewire or something
else starts it, even if it is not needed. (it runs as a normal user, 
not
some system user, and there are no init.d script or systemd units for 
it

that I can find)


well, it does come with a systemd unit:

/usr/lib/systemd/user/fluidsynth.service

If this service is enabled, fluidsynth acts as a MIDI daemon, i.e. as a 
virtual MIDI device.


You may either want to disable this service, or switch to a different 
default soundfont with a smaller memory footprint, e.g. the one in the 
`timgm6mb-soundfont` package, either by uninstalling all soundfont 
packages but this one or by using Debian's `update-alternatives` 
mechanism.


Hope that helps!

 - Fabian

Bug#1039059: fonts-liberation2: `dpkg: warning: unable to delete old directory '/usr/share/fonts/truetype/liberation2': Directory not empty`

[fabian]

control: reassign -1 fontconfig

Notorious fontconfig bug, reassigning.

Am 2023-06-25 09:38, schrieb Paul Menzel:

Package: fonts-liberation2
Version: 1:2.1.5-2
Severity: minor


Dear Debian folks,


Upgrading *fonts-liberation2*, the warning below is shown.

```
USER@ersatz:~$ sudo LANG=C apt full-upgrade
[…]
Unpacking fonts-liberation2 (1:2.1.5-2) over (2.1.5-1) ...
dpkg: warning: unable to delete old directory 
'/usr/share/fonts/truetype/liberation2': Directory not empty

[…]
USER@ersatz:~$ ls -lRa /usr/share/fonts/truetype/liberation2
/usr/share/fonts/truetype/liberation2:
insgesamt 12
drwxr-xr-x  2 root root 4096 23. Jun 22:01 .
drwxr-xr-x 42 root root 4096 10. Okt 2022  ..
-rw-r--r--  1 root root   36 18. Dez 2018  .uuid
USER@ersatz:~$ cat /usr/share/fonts/truetype/liberation2/.uuid
75c3161b-0e12-4500-a013-a12507e6361aUSER@ersatz:~$
```


Kind regards,

Paul

Bug#1037357: closed by Debian FTP Masters (reply to Gürkan Myczko ) (Bug#1037357: fixed in flowblade 2.10.0.1-1)

[fabian]

Am 2023-06-23 20:38, schrieb fab...@greffrath.com:

Not sure what you mean.


Sorry, ignore me. Replied to the wrong bug.

 - Fabian

Bug#1037357: closed by Debian FTP Masters (reply to Gürkan Myczko ) (Bug#1037357: fixed in flowblade 2.10.0.1-1)

[fabian]

Am 2023-06-23 20:31, schrieb Martin-Éric Racine:

Not fixed. Re-opening.


Not sure what you mean.

This has all happened just today. Leave it some time to settle.

https://tracker.debian.org/news/1438362/accepted-fonts-liberation-1215-2-source-all-into-unstable/

 - Fabian

Bug#1003010: closed by Debian FTP Masters (Bug#1038940: Removed package(s) from unstable)

[fabian]

Am 2023-06-23 19:38, schrieb Martin-Éric Racine:

The description of the ROM bug makes it pretty clear that v1 is no
longer maintained, while v2 is. In other words, fonts-liberation
should ahve been removed from the archive, while fonts-liberation2 be
kept.


No, everything went alright. The fonts-liberation2 package is continued 
under the fonts-liberation name.


I think I have made this clear here
https://lists.debian.org/debian-devel/2023/06/msg00220.html
and here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038940

Greetings,

 - Fabian

Bug#1038940: RM: fonts-liberation2 -- ROM; obsoleted by fonts-liberation (>= 1:2.1.5-2~)

[Fabian Greffrath]

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

Hi,

as announced on debian-devel [1], Liberation fonts v1 have been
abandoned upstream and Liberation fonts v2 are the only maintained
version - along with the Liberation Sans Narrow font which has been
extracted out of the v1 releases.

It does thus not make sense anymore to have the v1 fonts packaged
separately n Debian and let them block the "fonts-liberation" package
name, with the prefered version of the fonts moved out into the
"fonts-liberation2" package.

With the latest upload, I have thus let the v2 font take over the
src:fonts-liberation package name, providing both fonts-liberation and
fonts-liberation2 binary packages, the latter being a transitional
dummy package depending on the further.

So, so src:fonts-liberation2 package is now obsolete and should get
removed from Debian unstable (and testing).

Thank you!

Cheers,

 - Fabian


[1] https://lists.debian.org/debian-devel/2023/06/msg00220.html

Bug#1003010: fonts-liberation2: please Provides fonts-liberation

[Fabian Greffrath]

Hi there,

sorry for the late reply!

Am Sonntag, dem 02.01.2022 um 20:44 +0200 schrieb Martin-Éric Racine:
> It would be desirable for fonts-liberation2 to Provides fonts-
> liberation so as to avoid installing two versions of essentially the
> same font.

First, strictly speaking fonts-liberation and fonts-liberation2 aren't
only two versions of the same font, but in fact tw different fonts.
Apart from the fact that both get installed into two different
locations in the file system (obviously), the v1 package contains one
more font family than the v2 package, i.e. Sans Narrow.

Second, what causes the situation that both fonts are installed at the
same time? Is it package dependencies and if yes, which packages cause
this? Because, well apart from Sans Narrow, there is no technical
reason to have both versions installed at the same time.

Cheers,

 - Fabian



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

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Fabian Greffrath]

Hi Reimar,I remember that back then, when powerpc was still a release 
architecture in Debian, we built two flavors of the ffmpeg libraries -- one 
with altivec and one 
without:https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184That
 code is still there, so I wonder why your linker doesn't pick up the flavor 
that matches your processor's instruction set.Cheers, - Fabian Von 
meinem/meiner Galaxy gesendet
 Ursprüngliche Nachricht Von: Reimar Döffinger 
 Datum: 06.06.23  20:24  (GMT+01:00) An: Lorenzo 
, 448...@bugs.debian.org Betreff: Bug#448105: mplayer: 
Illegal Instruction in init_audio_codec > On 6 Jun 2023, at 15:17, Reimar 
Döffinger  wrote:> >> Disable altivec for everyone 
doesn't seem a good compromise to me, I'm>> going to build twice on powerpc and 
let the user decide which one to use> > To be clear: as MPlayer has no 
hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure 
guess), the most performance critical stuff in FFmpeg should not be 
affected.So, funny thing. I installed debian-ppc on qemu g3 emulated 
system.What did I find out:- xfce4 crashes with illegal instruction- ffmpeg 
does not crash, but only because it is built with --disable-altivec which makes 
it basically unusably slow on e.g. G4 systems.So there is no winning.So for 
practical purposes, you can just as well compile MPlayer with 
--disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't 
make a relevant difference.On the details what goes on here (skip if you do not 
like rants):What is the source of all these issues? gccIn the past, -maltivec 
was used to just enable support for altivec intrinsics.However gcc then changed 
and generated Altivec instructions even from plain C code.While that makes 
sense in a way, it meant code everywhere broke on non-altivec systems.This 
includes FFmpeg.For packages important enough/depending on maintainer, the 
"solution" was to disable altivec completely, making these programs vastly 
slower on Altivec enabled computers.Others like xfce4 and MPlayer only work on 
PPC systems with Altivec.Without extensive code and build system changes, this 
seems now an unsolvable situation.Unless someone adds an option like -faltivec 
that Apple had, which allows the intrinsics but not compiler generation of 
altivec instructions (I think gcc maintainers at one point said they could not 
do that).clang has both -faltivec and -maltivec, but neither are properly 
documented, so who knows if they would help here or not.Either way, without 
someone EXTREMELY motivated, this seems not solvable (switching to clang with 
-faltivec if it were to work just MIGHT have a chance).I guess it's a lesson in 
not buying into architectures where the creators don't have their shit together 
enough to get even the basics right - and upstreamed... (I guess it's mostly 
solved by PPC being as good as dead now).(don't get me wrong, I still sometimes 
boot my old MacMini with G4 and update to latest Debian, but I think the ISA is 
just dead at this point, unfortunately).Sorry for the long rant,Reimar

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Fabian Grünbichler]

with sequoia being released with base64 0.21 support, I will start
preparing updates for the crates below (at least those maintained by the
Rust team - coordinating with team members as necessary, of course).

I haven't decided yet whether uploading to experimental is the way to
go, or whether straight to unstable post-bookworm makes more sense.

I'll update this bug report accordingly.

Versions of rust-base64 in unstable:
  librust-base64-dev   0.13.0-1

Versions of rdeps of rust-base64 in unstable, that also exist in testing:
  librust-alacritty-terminal-dev   0.17.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-cargo-dev0.66.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-cookie-dev   0.16.0-1 depends on  
   librust-base64-0.13+default-dev,
  librust-fernet-dev   0.2.0+really0.1.4-2 depends 
on librust-base64-0.13+default-dev,
  librust-grep-printer-dev 0.1.6-1  depends on  
   librust-base64-0.13+default-dev,
  librust-jsonwebtoken-dev 8.2.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-oauth2-dev   4.3.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-pem-dev  1.0.2-1  depends on  
   librust-base64-0.13+default-dev,
  librust-plist-dev1.3.1-1  depends on  
   librust-base64-0.13+default-dev,
  librust-postgres-protocol-dev0.6.4-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-reqwest-dev  0.11.13-1depends on  
   librust-base64-0.13+default-dev,
  librust-ron-dev  0.7.1-1  depends on  
   librust-base64-0.13+default-dev,
  librust-ruma-common-dev  0.10.5-2 depends on  
   librust-base64-0.13+default-dev,
  librust-rust-argon2-dev  1.0.0-2  depends on  
   librust-base64-0.13+default-dev,
  librust-rustls-pemfile-dev   1.0.0-1+b1   depends on  
   librust-base64-0.13+default-dev,
  librust-sequoia-autocrypt-dev0.24.0-1 depends on  
   librust-base64+default-dev (>= 0.12-~~),
  librust-sequoia-net-dev  0.25.0-2 depends on  
   librust-base64+default-dev (>= 0.12-~~),
  librust-sequoia-openpgp-dev  1.12.0-2 depends on  
   librust-base64-0.13+default-dev | librust-base64-0.12+default-dev,
  librust-sniffglue-dev0.15.0-3+b2  depends on  
   librust-base64-0.13+default-dev,
  librust-totp-rs-dev  3.0.1-2  depends on  
   librust-base64-0.13+default-dev,
  librust-transmission-client-dev  0.1.3-2  depends on  
   librust-base64-0.13+default-dev,
  librust-ureq-dev 2.6.2-3  depends on  
   librust-base64-0.13+default-dev,

Source packages in unstable whose autopkgtests are triggered by rust-base64:
  rust-base64ct1.5.1-1  triggered 
by librust-base64-dev=0.13.0-1
  rust-native-tls  0.2.11-1 triggered 
by librust-base64-dev=0.13.0-1
  rust-psa-crypto  0.9.2-2  triggered 
by librust-base64-dev=0.13.0-1
  rust-rustls  0.20.8-4 triggered 
by librust-base64-dev=0.13.0-1
  rust-ttf-parser  0.15.2-1 triggered 
by librust-base64-dev=0.13.0-1
  rust-webpki  0.22.0-1 triggered 
by librust-base64-dev=0.13.0-1

Bug#1035824: installation-reports: unable to detect Realtek RTL8188EUS 802.11n USB WiFi adapter

[Fabian Greffrath]

Package: installation-reports
Severity: normal

Boot method: USB
Image version: debian-bookworm-DI-rc2-amd64-netinst.iso (downloaded 2023-05-05)

Machine: Lenovo IdeaPad 5


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

Sadly, another failed attempt to install Debian on my brand-new Lenovo
IdeaPad 5, this time using a USB dongle equiped with the Realtek
RTL8188EUS chip set.

The installer failed to detect the network adapter and presented me
with a list of kernel modules, none of which got my device to work.
This is what dmesg reports after I plug the adapter into a USB port on
my current device, which is obviously not the same one as the report
applies to  (which is why I removed all of the appended logs):

[42871.476218] usb 1-4: new high-speed USB device number 19 using xhci_hcd
[42871.624725] usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, 
bcdDevice= 0.00
[42871.624729] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[42871.624731] usb 1-4: Product: 802.11n NIC
[42871.624732] usb 1-4: Manufacturer: Realtek
[42871.624733] usb 1-4: SerialNumber: 00E04C0001
[42871.936975] r8188eu: module is from the staging directory, the quality is 
unknown, you have been warned.
[42871.970033] usbcore: registered new interface driver r8188eu
[42872.005633] r8188eu 1-4:1.0 wlx482254c71aaf: renamed from wlan0
[42872.597812] r8188eu 1-4:1.0: firmware: direct-loading firmware 
rtlwifi/rtl8188eufw.bin
[42872.597825] r8188eu 1-4:1.0: Firmware Version 11, SubVersion 1, Signature 
0x88e1
[42881.731472] r8188eu 1-4:1.0: firmware: direct-loading firmware 
rtlwifi/rtl8188eufw.bin

Interstingly, calling dmesg on the system where the installation
attempt failed, the line starting with 42871.936975,i.e. where the
actual kernel module is loaded, and all following ones are omitted.


Hope this helps!

Cheers,

 - Fabian

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[fabian]

Hi guys,

Am 05.05.2023 18:09, schrieb Diederik de Haas:

Too recent for Bookworm as it appears that it was added in 6.2,
while Bookworm has 6.1.


today I tried again with a TP-Link TL-WN725N Nano USB dongle which 
contains the Realtek RTL8188EU chip set. Same result, the adapter is not 
recognized and I am presented with a list of kernel modules of which 
none works. But in this case, I am pretty sure that the RTL8188EU chip 
*should* be supported by a recent kernel.


Any hints, or should I file a separate installation report?

Cheers,

 - Fabian

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[fabian]

Am 05.05.2023 18:23, schrieb Cyril Brulebois:

Right, initial support seems to have been merged in time for v6.2-rc1
only.


Oh, no!

When will be the earliest chance for a D-I image with kernel >= 6.2?

Cheers,

 - Fabian

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Fabian Greffrath]

Package: installation-reports
Severity: normal

Boot method: USB
Image version: debian-bookworm-DI-rc2-amd64-netinst.iso from 2023-05-05
Date: 2023-05-05 12:00

Machine: Lenovo IdeaPad 5 14IAL7
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

Thi shappened on a different machine than the one I write this report
from (obviously, thus removed the logs below).

Today I attempted to install Debian bookworm on a brand new Lenovo
IdeaPad 5 14IAL7 with an i5-1235U CPU, 16GB RAM and 512GB SDD.

The installation failed to proceed at the network card detection
stage. Apparently, the machine has a Realtek RTL8852BE adapter, which
*should* be supported by recent kernels. However, the installer
presented me with a list of kernel modules to choose from. I went
through the list and selected anything that even remotely matched the
adapter name, but without success. Since I only had downloaded the
netinst image, I had to quit the installation proess at this point.

Cheers,

 - Fabian

Bug#1034939: [Pkg-rust-maintainers] Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Fabian Grünbichler]

On Fri, Apr 28, 2023 at 08:42:07PM +0100, Peter Green wrote:
> On 28/04/2023 18:58, Fabian Grünbichler wrote:
> > I see no practical issue with 2 meaning we can't have multiple semver
> > suffix packages variants of a single crate installed - having the
> > unversioned and one semver suffix package in one suite at any given time
> > should already be the exception, having more than that should be even
> > more rare,
> 
> In an ideal world I would agree, the transition from semver
> "n" to semver "n+1" would be complete before the transition
> from semver "n+1" to semver "n+2" starts.
> 
> I've certainly seen cases where that didn't happen though.
> clap springs to mind as a currently ongoing one where we
> have versions 2, 3 and 4 of clap in bookworm and clap 2
> still has more users than clap 3 and 4 combined.

in the archive, yes. in one transitive build dep tree that requires them
to be co-installed?

there are only a few crates that come my mind that bump that often and
are that widely used that we might run into it. clap ticks the first
box, but since it's mainly used by binaries directly (it's for argument
parsing after all ;)). nom would be a realistic use case where a big
project might transitively pull in 3 versions at some point (we
currently have 3.x, 4.x and 7.x (unversioned) in the archive, but 3.x
and 4.x seem to be cruft and removable.

I did a quick check (obviously, this is only a point-in-time snapshot!),
right now we have rust binaries with the following 18 semver suffix
dependencies in their transitive build dep tree in unstable (according
to X-Cargo-Built-Using):

rust-ahash-0.7 (= 0.7.6-11)
rust-arrayvec-0.5 (= 0.5.2-2)
rust-blake2b-simd-0.5 (= 0.5.11-1)
rust-block-buffer-0.9 (= 0.9.0-1)
rust-cfg-if-0.1 (= 0.1.10-2)
rust-clap-2 (= 2.34.0-3)
rust-clap-3 (= 3.2.23-4)
rust-digest-0.9 (= 0.9.0-2)
rust-env-logger-0.7 (= 0.7.1-3)
rust-foreign-types-0.3 (= 0.3.2-1)
rust-foreign-types-shared-0.1 (= 0.1.1-1)
rust-md-5 (= 0.10.1-1)
rust-mio-0.6 (= 0.6.23-2)
rust-semver-0.9 (= 0.9.0-3)
rust-semver-parser-0.7 (= 0.7.0-1)
rust-sha-1-0.9 (= 0.9.8-1)
rust-sha2-0.9 (= 0.9.9-2)
rust-sha3-0.9 (= 0.9.1-1)

of these, only three are (transitively) depended on in both semver
suffix and unversioned variants by any one package according to
X-Cargo-Built-Using:

rust-cfg-if is used in two versions by:
 qwertone
 alacritty
 bat
 fd-find
 libslirp-helper
 rust-code-analysis-cli
 sniffglue

rust-mio by:
 alacritty
 libslirp-helper

rust-semver by:
 grcov
 rusty-tags

keep in mind that this possible misses some additional dependency trees
that are not resulting in any binary crate binary packages (e.g.,
packaging efforts that are not yet finished).

> >and there should be no need to have them *installed* at the
> >same time since these packages are only used as build deps.
> 
> More than one semver of the same crate can be used in the same
> build process. Also collapse_features means that crates often end
> up in the transitive build-dependency graph of a package even
> though they are not actually used in the build.
> 
> I feel this is the kind of thing that would rarely cause problems,
> but when it does cause problems they would be of the
> "painted into a corner" type that are very difficult to deal with.

well, dealing with boils down to either:
- delay the crate update until more users of the outdated version have
  upgraded upstream and we can drop an old version
- write the patches for doing that upgrade and submit them upstream
- fork the oldest version in Debian to give a new name and patch its
  users (meh)
- manually dropping the Breaks+Replaces after ensuring that the
  offending combination of versions doesn't exist in the archive anymore

the first two are valid options IMHO, and decrufting an old version
before introducing a second old version into the archive seems desirable
in almost all cases that I can think of, regardless of whether it is
*needed* or not.

that being said - I now did some practical tests:
- install librust-mio-dev from bullseye
- install librust-mio-extras-dev from bookworm (which depends on
  mio 0.6)

now do a regular dist-upgrade, no problem, since librust-mio-dev gets
unpacked first (old files for 0.6.23 gone) and only then
librust-mio-0.6-dev gets unpacked (new files for 0.6.23 are not
conflicting) - that might just be luck though? or the Breaks guiding
the ordering, even though technically it only ensures that the broken
package is deconfigured, not that it is upgraded?

I see no practical difference when repeating the experiment with
librust-mio-0.6-dev patched + bumped to switch the B+R to
librust-mio-dev (<< 0.6.24~), the upgrade works just as fine.

with Replaces + Conflicts on librust-mio-0.6.23-dev, the upgrade works
as well. attempting to install the librust-mio-dev package from 

Bug#1034939: [Pkg-rust-maintainers] Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Fabian Grünbichler]

On Fri, Apr 28, 2023 at 07:58:35PM +0200, Fabian Grünbichler wrote:
> 2) if the "fork point" corresponds to the version in the soon-to-be-old
> stable release, and the semver suffix package is still in testing when
> that becomes the stable release (as then the unversioned package in
> (old)stable and the semver suffix package in (new)stable ship the same
> path)
> 
> is 2) actually true for any of the filed bugs at the moment? if not,
> then IMHO we can ignore this until bookworm is out the door, decide on
> and ship the fix in debcargo, and ease out the problematic packages by
> updating them (basically option 5). like Peter noted below, these are
> packages almost certainly only installed on developer machines (or the
> odd programmer's who doesn't use the stock, upstream way of doing rust
> developement) and in 'unclean' build environments, not on regular
> servers or end user machines.

I guess I could have checked that myself before writing -
rust-block-buffer is in bullseye with version 0.9.0-4, and
rust-block-buffer-0.9 is in bookworm with version 0.9.0-1, so yeah, this
affects bullseye->bookworm upgrades, although with all the caveats Peter
and I mentioned, which might still be an argument for not "hotfixing"
this in bookworm now.

Bug#1034939: librust---dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Fabian Grünbichler]

as reference, the (simplified) problematic combination:

rust-foobar in version X.Y.Z-A
ships librust-foobar-dev which provides librust-foobar-X-dev,
librust-foobar-X.Y-dev and librust-foobar-X.Y.Z-dev (all in version
X.Y.Z-A)

is what I call the "unversioned" package in the rest of this mail (it
doesn't have any part of the upstream version encoded in either the
source package name or its binary package names. like all rust crates,
it does have the prefixes of the upstream version encoded in virtual
package names).

rust-foobar-X in version X.Y.Z-B
ships librust-foobar-X-dev which provides librust-foobar-dev,
librust-foobar-X.Y-dev and librust-foobar-X.Y.Z-dev (all in version
X.Y.Z-B)

is the "semver suffix" package (because its source package name and the
binary package name(s) contain a suffix with the first part semver
component of the upstream version) - it provides both the unversioned
package name and the prefixes that are no already in its actual package
name.

note that A and B don't have to be identical at any point of these
packages' lifecycle, although they might be. so exact matching based on
the full package version is not possible.

there's the special case of X being 0 that change some details, but not
in a way that matter. there might also be more librust-foobar[-X]+F-dev
binary packages with corresponding provides, or additional provides
without their own binary package, where F is some feature of the crate.
AFAICT this also shouldn't change anything about the analysis below,
provided the set of features is identical across the two source
packages, so I am going to ignore this as well :)

On Fri, Apr 28, 2023 at 04:21:08PM +0100, Peter Green wrote:
> On 28/04/2023 06:05, Helmut Grohne wrote:
> > Can you go into more detail as to what you mean with "don't support
> > version ranges"?
> 
> You can place a lower bound on the version, place an upper bound
> on the version or constrain to a precise version. But you can't
> constrain to a range of versions.

exactly, and since the conflict ist actually on an upstream-version
specific path, and the debian revisions of the two involved source
packages might not be related/identical, we can't do an exact match.

so the only solution IMHO is to have an upper bound on the next upstream
version, i.e. if the semver "fork point" is X.Y.Z, << X.Y.(Z+1)~ ? an
unversioned librust-foobar-dev that contains crate version > X.Y.Z, even
with the first two components identical, is okay, since the path in
/usr/share/cargo/registry is different then.

> >   In principle, you could declare the Replacs to be
> > slightly broader than necessary (i.e. instead of declaring against the
> > specific range, you can replace all old packages). Do you agree that
> > this is feasible?
> It would indeed be feasible to continue declaring the breaks
> against the virtual package, while declaring the replaces
> against the physical package.
> 
> My only concern is this may bring in bug reports complaining
> about a replaces without a matching breaks. Tehcnically I
> don't see anything in policy actually forbidding such but
> it goes against the norm.

the question is whether switching just the Replaces as opposed to both
B+R to the unversioned package has any advantage in the way apt and co
handle it? if not, then switching the B+R to have the same dependency
might be a good idea if just for consistency's sake.

> >   5. In a different bug, Samuel Thibault observed that the target package
> >  was not part of bullseye. As such, an upgrade scenario involving it
> >  was unlikely. All of the 6 affected librus-*-dev packages are not
> >  part of bullseye. We could argue that the risk of these effects
> >  showing up in practice is not big enough to warrant an invasive fix.
> >  Rather, we'd downgrade them to important (and upgrade to serious
> >  when we see them in the wild) and close them after bookworm (since
> >  we don't support skip upgrades).
> 
> While the target packages aren't part of bullseye, they could well end up 
> pulled
> in as part of an upgrade, since the purpose of these packages is to continue
> providing older versions of a crate when the main package of the crate is
> upgraded.

semver suffix packages are problematic at two points:

1) when they are initially created in sid, where for a time (until the
unversioned package is updated) both source packages and their binary
packages might co-exist in sid and/or testing

this could be avoided by always updating the unversioned first, but one
common reason is avoiding breaking half of the archive when doing such a
transition, so..

2) if the "fork point" corresponds to the version in the soon-to-be-old
stable release, and the semver suffix package is still in testing when
that becomes the stable release (as then the unversioned package in
(old)stable and the semver suffix package in (new)stable ship the same
path)

is 2) actually true for any of the filed bugs at the moment? if not,
the

Bug#1034555: unblock: fluidsynth/2.3.1-2

[Fabian Greffrath]

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

Please unblock package fluidsynth

[ Reason ]
This revision fixes a regression that was introduced upstream between
the 2.3.0 and 2.3.1 releases and has been fixed in the 2.3.2 release.

[ Impact ]
The regression introduced a multi-second gap between looping MIDI
tracks. Since fluidsynth is the default renderer for MIDI music in
SDL2, this will affect *a lot* of games in Debian.

[ Tests ]
n/a

[ Risks ]
None, I'd say. The fix has been backported from the upstream GIT
repository and is in the 2.3.2 version, which has already been
released. The output of `git show -w c0e2ef` on the commit in question
has three lines of code changes, the rest is indentation:

--- a/src/midi/fluid_midi.c
+++ b/src/midi/fluid_midi.c
@@ -2179,6 +2179,8 @@ fluid_player_callback(void *data, unsigned int msec)
 fluid_atomic_int_set(&player->seek_ticks, -1); /* clear seek_ticks 
*/
 }
 
+if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+{
 /* Once we've run out of MIDI events, keep playing until no voices 
are active */
 if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
 {
@@ -2207,6 +2209,7 @@ fluid_player_callback(void *data, unsigned int msec)
 {
 status = FLUID_PLAYER_PLAYING;
 }
+}
 
 /* Once there's no reason to keep playing, we're actually done */
 if(status == FLUID_PLAYER_DONE)


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

[ Other info ]
n/a

unblock fluidsynth/2.3.1-2
diff -Nru fluidsynth-2.3.1/debian/changelog fluidsynth-2.3.1/debian/changelog
--- fluidsynth-2.3.1/debian/changelog   2022-12-30 16:10:11.0 +0100
+++ fluidsynth-2.3.1/debian/changelog   2023-04-18 07:48:30.0 +0200
@@ -1,3 +1,11 @@
+fluidsynth (2.3.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Apply patch from upstream to fix seamless looping between MIDI
+files.
+
+ -- Fabian Greffrath   Tue, 18 Apr 2023 07:48:30 +0200
+
 fluidsynth (2.3.1-1) unstable; urgency=medium
 
   * New upstream version 2.3.1
diff -Nru 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
--- 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  1970-01-01 01:00:00.0 +0100
+++ 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  2023-04-18 07:47:25.0 +0200
@@ -0,0 +1,76 @@
+From c0e2ef4243b83f29620b2078fc0f1198bafd7d90 Mon Sep 17 00:00:00 2001
+From: derselbst 
+Date: Sun, 2 Apr 2023 17:31:24 +0200
+Subject: [PATCH 46/49] Fix seamless looping between MIDI files
+
+Fixes #1227
+---
+ src/midi/fluid_midi.c | 45 +++
+ 1 file changed, 24 insertions(+), 21 deletions(-)
+
+diff --git a/src/midi/fluid_midi.c b/src/midi/fluid_midi.c
+index 0676c452..b72c3914 100644
+--- a/src/midi/fluid_midi.c
 b/src/midi/fluid_midi.c
+@@ -2178,34 +2178,37 @@ fluid_player_callback(void *data, unsigned int msec)
+ player->start_msec = msec;  /* should be the (synth)-time of 
the last tempo change */
+ fluid_atomic_int_set(&player->seek_ticks, -1); /* clear 
seek_ticks */
+ }
+-
+-/* Once we've run out of MIDI events, keep playing until no voices 
are active */
+-if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
++
++if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+ {
+-/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
+-if(!player->end_pedals_disabled)
++/* Once we've run out of MIDI events, keep playing until no 
voices are active */
++if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
+ {
+-for(i = 0; i < synth->midi_channels; i++)
++/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
++if(!player->end_pedals_disabled)
+ {
+-fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
+-fluid_synth_cc(player->synth, i, SOSTENUTO_SWITCH, 0);
++ 

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Fabian Grünbichler]

On Thu, Apr 13, 2023 at 05:21:50PM +0100, Peter Green wrote:
> On 13/04/2023 15:31, Peter Green wrote:
> 
> > I've filed a bug with sequoia upstream. I haven't investigated the other
> > packages at this time.
> 
> I just did a quick test of sniffglue, ron and ureq, sniffglue and ron were
> all able to run "cargo test --all --all-targets --all-features" succesfully
> with the base64 dependency bumped to 0.21. ureq required a slighkt different
> testing methodology to avoid some unrelated issues but also seemed ok.
> 
> So it seems that sequoia is now likely the only blocker.
> 
> P.S. ureq is maintained by Jonas outside debcargo-conf.

sounds like it should be do-able to upgrade once the freeze is lifted :)
thanks for the follow-up!

Bug#1034050: fonts-creep2: generated font is TrueType, not OpenType

[Fabian Greffrath]

Am Freitag, dem 07.04.2023 um 15:14 +0100 schrieb
nwil...@glyphography.com:
> based on the outline format contained within (quadratic vs cubic 
> Beziers), then filename extension alone is not adequate.
> 
> Similarly, if the intent is to make some sort of distinction based on
> the contents of the tables (e.g., GSUB and GPOS), then the filename 
> extension still isn't adequate, because .ttf files can and do include
> those tables (see Noto and many many others).

I'd say we make the distinction by container format. Though, I agree
that this distinction is still pretty arbitrary.

 - Fabian



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

Bug#1034020: openal-soft: please upgrade to 1.23

[Fabian Greffrath]

Source: openal-soft
Version: 1:1.19.1-2
Severity: wishlist

Hi there,

please upgrade the openal-soft package to upstream version 1.23!

The 1.19.1 release which is currently in Debian exhibits some serious
clicking when sounds are played repeatedly in Doom source ports and
reportedly these clinks are fixed in newer versions (at least 1.21.1):

https://github.com/fabiangreffrath/woof/pull/973#issuecomment-1499154366

Also, you may want to upgrade the Homepage field in debian/control and
the debian/watch file to point to the new upstream location at
https://github.com/kcat/openal-soft

Thanks!

Cheers,

 - Fabian


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1032935: unblock: fonts-dejavu/2.37-6

[Fabian Greffrath]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: fonts-dej...@packages.debian.org
Control: affects -1 + src:fonts-dejavu

Please unblock package fonts-dejavu.

The upstream Makefle touches all generated TTF font files with the time
stamp of the corresponding SFD source file, so time stamps are never
updated between package revisions from the same sources.

The -6 package revision touches all generated TTF font files with
$SOURCE_DATE_EPOCH, so the time stamps are updated whenever the package
revision is updated.

This fixes bug #1032599.

Please find the debdiff attached.

Thanks!

 - Fabian

diff -Nru fonts-dejavu-2.37/debian/changelog fonts-dejavu-2.37/debian/changelog
--- fonts-dejavu-2.37/debian/changelog	2023-02-26 07:54:14.0 +0100
+++ fonts-dejavu-2.37/debian/changelog	2023-03-10 09:35:35.0 +0100
@@ -1,3 +1,10 @@
+fonts-dejavu (2.37-6) unstable; urgency=medium
+
+  * Touch all generated TTF files with SOURCE_DATE_EPOCH time,
+Closes: #1032599.
+
+ -- Fabian Greffrath   Fri, 10 Mar 2023 09:35:35 +0100
+
 fonts-dejavu (2.37-5) unstable; urgency=medium
 
   [ Paul Menzel ]
diff -Nru fonts-dejavu-2.37/debian/rules fonts-dejavu-2.37/debian/rules
--- fonts-dejavu-2.37/debian/rules	2023-02-07 08:26:34.0 +0100
+++ fonts-dejavu-2.37/debian/rules	2023-03-10 09:33:34.0 +0100
@@ -1,11 +1,14 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/pkg-info.mk
+
 %:
 	dh $@
-	
+
 override_dh_auto_build:
 	make full-ttf
 	sh debian/scripts/generate-udeb.sh
+	touch --no-create --date="$(shell date --utc --date=@${SOURCE_DATE_EPOCH} --iso-8601=seconds)" build/*.ttf
 
 override_dh_auto_clean:
 	$(RM) -rf tmp/ build/ udeb-generated/ udeb-build/


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

Bug#1032785: mipsel: gdb fails to find symbols in rust binary

[Fabian Grünbichler]

Package: gdb
Version: 13.1-2
Severity: important
Control: affects -1 src:rustc

basically a follow-up to #1031946 - there are at least two more rustc
test cases that fail with gdb 13.1 (but used to work with gdb 12.1),
this time only affecting mipsel.

I extracted the test cases in the existing reproducer repository[0], you
will need a mipsel machine (/VM) with rustc and cargo installed (I used
1.63 from bookworm).

I'll work around the issue for now by allowing rustc to build in
experimental even with these test cases failing, but a rebuild of rustc
on mipsel in bookworm would (likely) fail until this is fixed properly.

0: https://salsa.debian.org/fg/rustc-gdb-1031745/-/blob/main/README-mips.md
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031946

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

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

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.11-1+b2
ii  libc6   2.36-8
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.2
ii  libmpfr64.2.0-1
ii  libncursesw66.4-2
ii  libpython3.11   3.11.2-5
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b2
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-2
ii  libxxhash0  0.8.1-1
ii  libzstd11.5.4+dfsg2-4
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#1031946: gdb: one remaining breakage in rustc gdb testcases

[Fabian Grünbichler]

Package: gdb
Version: 13.1-1
Severity: normal
Control: affects -1 src:rustc

After the fix for #1031745 (thanks for the fast turnaround!), there
still is one test case (unsized.rs) that fails with gdb 13.1 (both -1
and -2), but didn't with 12.1.

I updated the reproducer repo[0], broken and good output look like this:

8< broken
Breakpoint 1 at 0x81dd: file src/main.rs, line 88.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, rustc_gdb_1031745::main () at src/main.rs:88
88  zzz(); // #break
$1 = &rustc_gdb_1031745::Foo<[u8]> 0x7fffdd88
$2 = &rustc_gdb_1031745::Foo> 0x7fffdd88
$3 = &rustc_gdb_1031745::Foo {pointer: 0x55593034, 
vtable: 0x555a3000warning: (Internal error: pc 0x555a3000 in read in 
CU, but not in symtab.)
warning: (Error: pc 0x555a3000 in address map, but not in symtab.)
}
$4 = alloc::boxed::Box, 
alloc::alloc::Global> {pointer: 0x555a7ba0, vtable: 0x555a3000warning: 
(Internal error: pc 0x555a3000 in read in CU, but not in symtab.)
warning: (Error: pc 0x555a3000 in address map, but not in symtab.)
}
$5 = &(i32, i32, [i32]) [(0, 1, 0), (2, 3, 0)]
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x555a3020, vtable: 
0x555a3030warning: (Internal error: pc 0x555a3030 in read in CU, but 
not in symtab.)
warning: (Error: pc 0x555a3030 in address map, but not in symtab.)
}
>8

8< good (gdb 12.1-4 from bookworm)
Breakpoint 1 at 0x81dd: file src/main.rs, line 88.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, rustc_gdb_1031745::main () at src/main.rs:88
88  zzz(); // #break
$1 = &rustc_gdb_1031745::Foo<[u8]> {data_ptr: 0x7fffdd88, length: 4}
$2 = &rustc_gdb_1031745::Foo> {data_ptr: 
0x7fffdd88, length: 4}
$3 = &rustc_gdb_1031745::Foo {pointer: 0x55593034, 
vtable: 0x555a3000}
$4 = alloc::boxed::Box, 
alloc::alloc::Global> {pointer: 0x555a7ba0, vtable: 0x555a3000}
$5 = &(i32, i32, [i32]) {data_ptr: 0x55593038, length: 2}
$6 = &(i32, i32, dyn core::fmt::Debug) {pointer: 0x555a3020, vtable: 
0x555a3030}
>8

Since this no longer (fatally) affects the build of rustc, I opted for a
lower severity this time around. It looks like an issue with symbol
mapping/lookup again. Feel free to adjust if you consider this blocking.

0: https://salsa.debian.org/fg/rustc-gdb-1031745

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

Kernel: Linux 6.1.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 gdb depends on:
ii  libbabeltrace1  1.5.11-1+b2
ii  libc6   2.36-8
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.2
ii  libmpfr64.2.0-1
ii  libncursesw66.4-2
ii  libpython3.11   3.11.2-4
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b2
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-2
ii  libxxhash0  0.8.1-1
ii  libzstd11.5.4+dfsg2-3
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#1031745: gdb: breaks rustc gdb debuginfo tests

[Fabian Grünbichler]

Hi!

I extracted one of the failing tests and the corresponding gdb commands
so that you can more easily (and quicker) reproduce the issue:

https://salsa.debian.org/fg/rustc-gdb-1031745

instructions are contained within as well. changing the triggering
function (multiple_arguments) to either just have the tuple as argument,
or making the signature

 fn multiple_arguments((oo, pp): (isize, isize), (qq, rr): (isize, isize)) { 

(and adapting the call accordingly) makes the problem go away.

just having multiple_arguments with the call as standalone test case
also doesn't trigger the issue.

Bug#1031745: gdb: breaks rustc gdb debuginfo tests

[Fabian Grünbichler]

Package: gdb
Version: 13.1-1
Severity: serious
Control: affects -1 src:rustc
Justification: breaks unrelated software

While preparing an update to rustc 1.65 for experimental, we noticed
that the recent gdb update in sid makes rustc FTBFS by causing 5 of its
gdb-integration test cases fail.

test [debuginfo-gdb] src/test/debuginfo/destructured-fn-argument.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/function-arguments.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-stack-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-unique-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/unsized.rs ... FAILED
command did not execute successfully: 
"/<>/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" 
"--compile-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"
 "--rustc-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" 
"/<>/src/test/debuginfo" "--build-base" 
"/<>/build/x86_64-unknown-linux-gnu/test/debuginfo" "--stage-id" 
"stage2-x86_64-unknown-linux-gnu" "--suite" "debuginfo" "--mode" "debuginfo" 
"--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" 
"--llvm-filecheck" "/usr/lib/llvm-15/bin/FileCheck" "--optimize-tests" 
"--linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--target-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" "src/tools/tidy" 
"--verbose" "--llvm-version" "15.0.7" "--llvm-components" "aarch64 
aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info 
aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser 
amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca 
amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler 
arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc 
avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf 
bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen core 
coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf 
debuginfopdb demangle dlltooldriver dwarflinker dwp engine executionengine 
extensions filecheck frontendopenacc frontendopenmp fuzzercli fuzzmutate 
globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc 
hexagondisassembler hexagoninfo instcombine instrumentation interfacestub 
interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc 
lanaidisassembler lanaiinfo libdriver lineeditor linker lto m68k m68kasmparser 
m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit 
mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo 
mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler 
msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo 
objcarcopts objcopy object objectyaml option orcjit orcshared orctargetprocess 
passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc 
powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser 
riscvcodegen riscvdesc riscvdisassembler riscvinfo runtimedyld scalaropts 
selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler 
sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc 
systemzdisassembler systemzinfo tablegen target textapi transformutils ve 
veasmparser vecodegen vectorize vedesc vedisassembler veinfo webassembly 
webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler 
webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser 
x86codegen x86desc x86disassembler x86info x86targetmca xcore xcorecodegen 
xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" 
"" "--cflags" "" "--cxxflags" "" "--adb-path" "adb" "--adb-test-dir" 
"/data/tmp/work" "--android-cross-path" "" "--channel" "stable"

our rustc build uses an (arch-dependent) cut-off for the number of "allowed to
fail" tests - for amd64 it is 8, the current version of rustc in testing/sid
(1.63.0+dfsg1-2) had 2 such failing tests when it was initially built, a
rebuild with gdb from unstable causes the fail count to go to 8 - while not
failing the build itself, the errors look problematic enough to me that it
should likely be looked at more closely *before* gdb ends up in
testing/bookworm. it does also prevent us from getting through the backlog of
rustc upstream releases in experimental, since the baseline for rustc 1.65 test
failures is 4, and the 6 additional ones caused by gdb push it over the
threshold.

the same tests are failing for
- rustc 1.65 (not yet uploaded, MR on salsa[0] which successfully bui