[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1099694: papers: fails to build



On Sat, 08 Mar 2025 20:15, Fabian Grünbichler <debian@fabian.gruenbichler.email> wrote:
On Thu, Mar 6, 2025, at 9:45 PM, Jeremy Bícha wrote:
Source: papers
Version: 48~beta-3
Severity: serious
Tags: ftbfs trixie sid
X-Debbugs-CC: debian-rust@lists.debian.org

Papers now fails to build. Because the build succeeds in Ubuntu 25.04
which is generally very similar to Debian Unstable currently for GNOME
and Rust dependencies, my guess is this might be caused by rustc 1.85.
Ubuntu 25.04 uses rustc 1.84 instead.

Papers 48 RC also fails to build in Debian.

The full build log can be found in recent Salsa CI pipelines.
https://salsa.debian.org/gnome-team/papers/-/pipelines

AFAICT, this is related to regenerating the bindings during the build
(I have no idea about the details of the involved components) and not
to the rustc update:

 [289/292] /usr/bin/gi-docgen generate --quiet --fatal-warnings --config=help/reference/libview/libppsview.toml '--add-include-path=/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/help/reference/libview/../../../libdocument' --output-dir=help/reference/libview/libpps  view --no-namespace-dir '--content-dir=/build/reproducible-path/papers-48~beta/help/reference/libview' libview/PapersView-4.0.gir
 [290/292] '/build/reproducible-path/papers-48~beta/rust/update-bindings.sh' '/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/libview/PapersView-4.0.gir' '/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/libdocument/PapersDocument-4.0.gir'
 /build/reproducible-path/papers-48~beta/rust /build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu
 Error: "GirXml: ../../pps-girs/PapersDocument-4.0.gir at line 17:3: Unexpected element <format>"
 Error: "GirXml: ../pps-girs/PapersDocument-4.0.gir at line 17:3: Unexpected element <format>"
 Error: "GirXml: ../../pps-girs/PapersDocument-4.0.gir at line 17:3: Unexpected element <format>"
 Error: "GirXml: ../pps-girs/PapersDocument-4.0.gir at line 17:3: Unexpected element <format>"
 /build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu
 [290/292] env 'CODEGEN_BUILD_DIR=/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/shell/src' SYSTEM_DEPS_PAPERS_VIEW_4_0_NO_PKG_CONFIG=1 'SYSTEM_DEPS_PAPERS_VIEW_4_0_SEARCH_NATIVE=/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/libview' SYSTEM_DEPS_PAPER  S_VIEW_4_0_LIB=ppsview-4.0 SYSTEM_DEPS_PAPERS_DOCUMENT_4_0_NO_PKG_CONFIG=1 'SYSTEM_DEPS_PAPERS_DOCUMENT_4_0_SEARCH_NATIVE=/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/libdocument' SYSTEM_DEPS_PAPERS_DOCUMENT_4_0_LIB=ppsdocument-4.0 /usr/share/cargo/bin/cargo buil  d --manifest-path '/build/reproducible-path/papers-48~beta/shell/Cargo.toml' --target-dir '/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/shell/src' --release --features with-keyring --features spell-check
 debian cargo wrapper: options = ['parallel=16'], profiles = [], parallel = ['-j16'], lto =
 debian cargo wrapper: rust_type = x86_64-unknown-linux-gnu, gnu_type = x86_64-linux-gnu
 debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', '/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', '-j16', '--target', 'x86_64-unknown-linux-gnu', '--manifest-path', '/build/reproducible-path/papers-48~beta/shell/Cargo.toml', '--target  -dir', '/build/reproducible-path/papers-48~beta/obj-x86_64-linux-gnu/shell/src', '--release', '--features', 'with-keyring', '--features', 'spell-check'],) {}
    Compiling proc-macro2 v1.0.92
    Compiling unicode-ident v1.0.13
    Compiling serde v1.0.217

if my guess is correct, this regeneration step via gir is supposed to
recreate the auto module (see the comment up top in the files in that
directory), which includes removing it first. the module/dir is there
in the source package, but after the build has failed, it is missing
in the working tree. the error above happens right before the real rust
part of the build starts.

is there a difference in the gir parts that might be at fault?

Hi,
this is what I also suspected (unfortuntately saw that more than once for gtk-rs).
Does upstream have some xmlstarlet "hacks" to parse the XML ?
For gtk-rs, I took upstreams' hacks deleting some xml data since that trips up /usr/bin/gir otherwise. I don't really have time to debug, but this is what I would look into (or if it is valid XML at those lines ?) You can take a look at the XML editing in src:rust-glibs' source.

best,

werdahias


Reply to: