Your message dated Fri, 9 Feb 2024 21:52:52 +0100
with message-id <[email protected]>
and subject line Re: rust-glib-sys FTBFS with the nocheck build profile: cp:
cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory
has caused the Debian Bug report #1063498,
regarding rust-glib-sys FTBFS with the nocheck build profile: cp: cannot stat
'/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1063498: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063498
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: rust-glib-sys
Version: 0.18.1-2
Severity: serious
Tags: ftbfs trixie sid
rust-glib-sys fails to build from source in unstable when built with the
nocheck build profile. Since trixie, a nocheck failure is considered
release-critical. A build ends with:
| debian/rules execute_before_dh_auto_build
| make[1]: Entering directory '/<<PKGBUILDDIR>>'
| cp /usr/share/gir-1.0/GLib-2.0.gir /<<PKGBUILDDIR>>
| cp: cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory
| make[1]: *** [debian/rules:9: execute_before_dh_auto_build] Error 1
| make[1]: Leaving directory '/<<PKGBUILDDIR>>'
| make: *** [debian/rules:4: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
Helmut
--- End Message ---
--- Begin Message ---
Version: 0.19.0-1
On Fri, Feb 09, 2024 at 09:41:22PM +0100, Matthias Geiger wrote:
> the version in experimental already contains the fix for this. I hope to
> subsequently upload all of gtk-rs to experimental this weekend and then to
> unstable soon after.
Cool. In that case, just close the bug with the experimental version. We
have version tracking and that tells that the bug still affects
unstable. If you upload another 0.18.* to unstable, you should reclose
the bug.
Helmut
--- End Message ---
