starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #1569] Unable to compile with libmdns-0.9.2: arguments to this method are incorrect #709

New issue
Closed
opened 2026-02-27 19:32:05 +03:00 by kerem · 12 comments
kerem commented 2026-02-27 19:32:05 +03:00
Owner
Copy link

Originally created by @flocke on GitHub (Sep 5, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1569

Description

Build fails recently in Docker container rust:slim-bookworm.

I am not sure what exactly changed recently but I have been using the same Docker container to build librespot for a while now and it recently stopped working.

I don't know enough about Rust to debug myself, but I can provide any addition information that is required.

Version

I tried the latest 0.7.1 as well as 0.7.0 (which worked previously).

How to reproduce

Use the following Dockerfile to reproduce:

FROM rust:slim-bookworm AS builder
ARG LIBRESPOT_VERSION=0.7.1
 
RUN DEBIAN_FRONTEND=noninteractive apt-get update && \
    apt-get full-upgrade -y && \
    apt-get install -y libasound2-dev pkg-config libssl-dev

RUN cargo install librespot --version "${LIBRESPOT_VERSION}"

Log

51.41 error[E0308]: arguments to this method are incorrect
51.41    --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/librespot-discovery-0.7.1/src/lib.rs:409:33
51.41     |
51.41 409 |             let svc = responder.register(
51.41     |                                 ^^^^^^^^
51.41 410 |                 DNS_SD_SERVICE_NAME.to_owned(),
51.41     |                 ------------------------------ expected `&str`, found `String`
51.41 411 |                 name.into_owned(),
51.41     |                 ----------------- expected `&str`, found `String`
51.41     |
51.41 note: method defined here
51.41    --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libmdns-0.9.2/src/lib.rs:292:12
51.41     |
51.41 292 |     pub fn register(&self, svc_type: &str, svc_name: &str, port: u16, txt: &[&str]) -> Service {
51.41     |            ^^^^^^^^
51.41 help: try removing the method call
51.41     |
51.41 410 -                 DNS_SD_SERVICE_NAME.to_owned(),
51.41 410 +                 DNS_SD_SERVICE_NAME,
51.41     |
51.41 help: consider borrowing here
51.41     |
51.41 411 |                 &name.into_owned(),
51.41     |                 +
51.41 
51.51 For more information about this error, try `rustc --explain E0308`.
51.51 error: could not compile `librespot-discovery` (lib) due to 1 previous error
51.51 warning: build failed, waiting for other jobs to finish...
60.07 error: failed to compile `librespot v0.7.0`, intermediate artifacts can be found at `/tmp/cargo-installA5cVQf`.
60.07 To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Host (what you are running librespot on):

  • OS: Arch Linux with Docker (build and running librespot + snapcast inside Docker)
  • Platform: x86_64
Originally created by @flocke on GitHub (Sep 5, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1569 ### Description Build fails recently in Docker container `rust:slim-bookworm`. I am not sure what exactly changed recently but I have been using the same Docker container to build librespot for a while now and it recently stopped working. I don't know enough about Rust to debug myself, but I can provide any addition information that is required. ### Version I tried the latest `0.7.1` as well as `0.7.0` (which worked previously). ### How to reproduce Use the following `Dockerfile` to reproduce: ```Dockerfile FROM rust:slim-bookworm AS builder ARG LIBRESPOT_VERSION=0.7.1 RUN DEBIAN_FRONTEND=noninteractive apt-get update && \ apt-get full-upgrade -y && \ apt-get install -y libasound2-dev pkg-config libssl-dev RUN cargo install librespot --version "${LIBRESPOT_VERSION}" ``` ### Log ``` 51.41 error[E0308]: arguments to this method are incorrect 51.41 --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/librespot-discovery-0.7.1/src/lib.rs:409:33 51.41 | 51.41 409 | let svc = responder.register( 51.41 | ^^^^^^^^ 51.41 410 | DNS_SD_SERVICE_NAME.to_owned(), 51.41 | ------------------------------ expected `&str`, found `String` 51.41 411 | name.into_owned(), 51.41 | ----------------- expected `&str`, found `String` 51.41 | 51.41 note: method defined here 51.41 --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libmdns-0.9.2/src/lib.rs:292:12 51.41 | 51.41 292 | pub fn register(&self, svc_type: &str, svc_name: &str, port: u16, txt: &[&str]) -> Service { 51.41 | ^^^^^^^^ 51.41 help: try removing the method call 51.41 | 51.41 410 - DNS_SD_SERVICE_NAME.to_owned(), 51.41 410 + DNS_SD_SERVICE_NAME, 51.41 | 51.41 help: consider borrowing here 51.41 | 51.41 411 | &name.into_owned(), 51.41 | + 51.41 51.51 For more information about this error, try `rustc --explain E0308`. 51.51 error: could not compile `librespot-discovery` (lib) due to 1 previous error 51.51 warning: build failed, waiting for other jobs to finish... 60.07 error: failed to compile `librespot v0.7.0`, intermediate artifacts can be found at `/tmp/cargo-installA5cVQf`. 60.07 To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path. ``` ### Host (what you are running `librespot` on): - OS: Arch Linux with Docker (build and running librespot + snapcast inside Docker) - Platform: x86_64
kerem 2026-02-27 19:32:05 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@kingosticks commented on GitHub (Sep 5, 2025):

Seems to be due to the new libmdns release. I've not looked properly but did it bump the MSRV in a patch release?! That's not ideal.

<!-- gh-comment-id:3259314242 --> @kingosticks commented on GitHub (Sep 5, 2025): Seems to be due to the new libmdns release. I've not looked properly but did it bump the MSRV in a patch release?! That's not ideal.
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@flocke commented on GitHub (Sep 5, 2025):

I will try to downgrade libmdns tomorrow to check.

Breaking changes in a patch release are always fun...

<!-- gh-comment-id:3259335395 --> @flocke commented on GitHub (Sep 5, 2025): I will try to downgrade libmdns tomorrow to check. Breaking changes in a patch release are always fun...
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@kingosticks commented on GitHub (Sep 5, 2025):

I can reproduce this by removing our Cargo.lock and re-building. Downgrading libmdns fixes it.

We either pin libmdns to v0.9.1 or we fix the compilation issue. The cargo suggestions doesn't work for v0.9.1 so perhaps pinning is easiest.

<!-- gh-comment-id:3259921236 --> @kingosticks commented on GitHub (Sep 5, 2025): I can reproduce this by removing our Cargo.lock and re-building. Downgrading libmdns fixes it. We either pin libmdns to v0.9.1 or we fix the compilation issue. The cargo suggestions doesn't work for v0.9.1 so perhaps pinning is easiest.
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@roderickvd commented on GitHub (Sep 6, 2025):

Seems to be due to the new libmdns release. I've not looked properly but did it bump the MSRV in a patch release?! That's not ideal.

Indeed… the new libmdns is nice to have though because it decreases the size of our dependency tree and binary.

We either pin libmdns to v0.9.1 or we fix the compilation issue. The cargo suggestions doesn't work for v0.9.1 so perhaps pinning is easiest.

Let’s fix it if we can. Doesn’t just &name (without into_owned) cut it?

<!-- gh-comment-id:3261161231 --> @roderickvd commented on GitHub (Sep 6, 2025): > Seems to be due to the new libmdns release. I've not looked properly but did it bump the MSRV in a patch release?! That's not ideal. Indeed… the new libmdns is nice to have though because it decreases the size of our dependency tree and binary. > We either pin libmdns to v0.9.1 or we fix the compilation issue. The cargo suggestions doesn't work for v0.9.1 so perhaps pinning is easiest. Let’s fix it if we can. Doesn’t just `&name` (without `into_owned`) cut it?
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@kingosticks commented on GitHub (Sep 6, 2025):

That's what I tried, and with 0.9.1 it complained about both.

<!-- gh-comment-id:3261357008 --> @kingosticks commented on GitHub (Sep 6, 2025): That's what I tried, and with 0.9.1 it complained about both.
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@urknall commented on GitHub (Sep 6, 2025):

how about:

            let svc = responder.register(
                DNS_SD_SERVICE_NAME,
                name.as_ref(),
                port,
                &TXT_RECORD,
            );
<!-- gh-comment-id:3261459702 --> @urknall commented on GitHub (Sep 6, 2025): how about: ```rust let svc = responder.register( DNS_SD_SERVICE_NAME, name.as_ref(), port, &TXT_RECORD, ); ```
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@urknall commented on GitHub (Sep 6, 2025):

&*name,

should also work

<!-- gh-comment-id:3261499615 --> @urknall commented on GitHub (Sep 6, 2025): &*name, should also work
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@urknall commented on GitHub (Sep 6, 2025):

That's what I tried, and with 0.9.1 it complained about both.

weird, i just tried with:

            let svc = responder.register(
                DNS_SD_SERVICE_NAME,
                &name,
                port,
                &TXT_RECORD,
            );

            let svc = responder.register(
                DNS_SD_SERVICE_NAME,
                &*name,
                port,
                &TXT_RECORD,
            );

            let svc = responder.register(
                DNS_SD_SERVICE_NAME,
                name.as_ref(),
                port,
                &TXT_RECORD,
            );

all of them worked on my system

EDIT: sorry, i just saw you talked about 0.9.1, i tested with 0.9.2

<!-- gh-comment-id:3261561197 --> @urknall commented on GitHub (Sep 6, 2025): > That's what I tried, and with 0.9.1 it complained about both. weird, i just tried with: ```rust let svc = responder.register( DNS_SD_SERVICE_NAME, &name, port, &TXT_RECORD, ); let svc = responder.register( DNS_SD_SERVICE_NAME, &*name, port, &TXT_RECORD, ); let svc = responder.register( DNS_SD_SERVICE_NAME, name.as_ref(), port, &TXT_RECORD, ); ``` all of them worked on my system EDIT: sorry, i just saw you talked about 0.9.1, i tested with 0.9.2
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@photovoltex commented on GitHub (Sep 6, 2025):

0.9.1 wants String and 0.9.2 wants &str. For the first .into() should work, but Into<Stirng> for Cow isn't implemented as it seems.

<!-- gh-comment-id:3261657287 --> @photovoltex commented on GitHub (Sep 6, 2025): `0.9.1` wants `String` and `0.9.2` wants `&str`. For the first `.into()` should work, but `Into<Stirng>` for `Cow` isn't implemented as it seems.
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@kingosticks commented on GitHub (Sep 6, 2025):

Slight tangent but why doesn't the Cargo lock file get used when people do cargo install librespot?

<!-- gh-comment-id:3261738237 --> @kingosticks commented on GitHub (Sep 6, 2025): Slight tangent but why doesn't the Cargo lock file get used when people do `cargo install librespot`?
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@willstott101 commented on GitHub (Sep 6, 2025):

0.9.2 is yanked. Can someone confirm cargo automatically reverts to 0.9.1 in their workspace?

<!-- gh-comment-id:3262242276 --> @willstott101 commented on GitHub (Sep 6, 2025): 0.9.2 is yanked. Can someone confirm cargo automatically reverts to 0.9.1 in their workspace?
kerem commented 2026-02-27 19:32:05 +03:00
Author
Owner
Copy link

@flocke commented on GitHub (Sep 13, 2025):

Slight tangent but why doesn't the Cargo lock file get used when people do cargo install librespot?

That is something I was asking myself as well. You need to manually add --locked to the command in order to use the lock file. I did this now for my Dockerfile just to make sure I always use the tested combination of packages. But in my opinion that should be the default behavior...

<!-- gh-comment-id:3288618706 --> @flocke commented on GitHub (Sep 13, 2025): > Slight tangent but why doesn't the Cargo lock file get used when people do `cargo install librespot`? That is something I was asking myself as well. You need to manually add `--locked` to the command in order to use the lock file. I did this now for my `Dockerfile` just to make sure I always use the tested combination of packages. But in my opinion that should be the default behavior...
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
v0.8.0
v0.7.1
v0.7.0
v0.6.0
v0.5.0
v0.4.2
v0.4.1
v0.4.0
v0.3.1
v0.3.0
v0.2.0
v0.1.6
v0.1.5
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels   
A-Alsa

   
SpotifyAPI

   
Tokio 1.0

   
audio

   
bug

   
can't reproduce

   
compilation

   
dependencies

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
high priority

   
imported

   
imported

   
invalid

   
new api

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
reverse engineering

   
wiki

   
wontfix
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#709
No description provided.