Tealdeer build fails

The builds have been unsuccessful since about the start of this month on both my machine and ci.guix.gnu.org. I tried to fix the issue, but I'm unfamiliar with Rust, so I just ended up fumbling around. Thanks to anyone who can get this working again! :D

I have also run into this build failure.

The relevant error message from the build log appears to be:

Compiling openssl-macros v0.1.0

error[E0659]: `parse_quote_spanned` is ambiguous (`macro_rules` vs non-`macro_rules` from other module)

--> /tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:859:67

|

859 | proj_generics.make_where_clause().predicates.push(parse_quote_spanned! { span =>

| ^^^^^^^^^^^^^^^^^^^ ambiguous name

|

note: `parse_quote_spanned` could refer to the macro defined here

--> /tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/utils.rs:22:1

|

22 | / macro_rules! parse_quote_spanned {

23 | | ($span:expr => $($tt:tt)*) => {

24 | | syn::parse2(quote::quote_spanned!($span => $($tt)*)).unwrap_or_else(|e| panic!("{}", e))

25 | | };

26 | | }

| |_^

note: `parse_quote_spanned` could also refer to the macro imported here

--> /tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:7:5

|

7 | *,

| ^

= help: use `self::parse_quote_spanned` to refer to this macro unambiguously

On 17-09-2022 13:55, Daniel Sockwell via Bug reports for GNU Guix wrote:

In antioxidant, I noticed that rust-pin-project-internal@0.4 doesn't

build so I replaced it with rust-pin-project-internal@1 (and likewise

for rust-pin-project).

Maybe the same issue was present in the original cargo-build-system

using code, and a similar fix would work?

Greetings,

Maxime.

I don't get it. How can a package "used to work" and "fail" now? If that is

the case, how is guix "declarative"?

Hi Corvo,

Corvo Liu <lyhokia@gmail.com> writes:

Some dependencies might have been updated in the meantime resulting in

build failures. If you use a Guix commit from back when that package

was building fine, it will still build fine. Guix being reproducible

doesn't mean that Guix doesn't update any of its packages.

Best,

--

Josselin Poiret

Hi,

On Sat, 17 Sep 2022 at 11:55, "Daniel Sockwell" <daniel@codesections.com> wrote:

Indeed, this evaluation of the CI [1] reports [2] this error:

Well, it is part of the Evaluation 5349 [3] which points commit

e6dd58cfb511c23beb4d2732f898bb5479bd52d5, and it reads:

It means the culprit is probably one of these updates:

e6dd58cfb5 gnu: waybar: Update to 0.9.16.

93edae81b6 gnu: rust-clap-3: Update to 3.1.18.

7760e3fb09 gnu: rust-clap-derive-3: Update to 3.1.18.

f7c95ecb67 gnu: rust-thiserror-1: Update to 1.0.37.

51cf11739d gnu: rust-thiserror-impl-1: Update to 1.0.37.

Well, because it is not “inputs” but “hidden” in ’arguments’ via

#:cargo-inputs or #:cargo-development-inputs, “guix graph --path” is

useless here. However,

therefore, one (or both) is the culprit. It seems worth to try with

1.0.26 instead of 1.0.37. Any taker?

1: http://ci.guix.gnu.org/build/156858/details

2: http://ci.guix.gnu.org/build/156858/log/raw

3: http://ci.guix.gnu.org/eval/5349

Cheers,

simon