GNU bug report logs -
#66052
[PATCH gnome-team 0/1] Update tracker, and ignore i686 missing tests
Previous Next
Reported by: Vivien Kraus <vivien <at> planete-kraus.eu>
Date: Sun, 17 Sep 2023 13:02:01 UTC
Severity: normal
Tags: patch
Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#66052: [PATCH gnome-team 0/1] Update tracker, and ignore i686 missing tests
which was filed against the guix-patches package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 66052 <at> debbugs.gnu.org.
--
66052: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66052
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Am Montag, dem 18.09.2023 um 19:00 +0200 schrieb Liliana Marie Prikler:
> Am Sonntag, dem 17.09.2023 um 13:29 +0200 schrieb Vivien Kraus:
> > * gnu/packages/gnome.scm (tracker): Update to 3.6.0.
> > [#:phases]: Add 'disable-failing-tests'.
> > ---
> > > > I can do the same as glib, but then on x86_64, where nothing is
> > > > spliced in, the phase becomes `(lambda _)' which is a syntax
> > > > error in Guile (lambdas must have at least one item in body).
> > > > […]
> > > And that's where my original comment with unspecified comes back
> > > in. If you add *unspecified* after a bunch of conditional code
> > > that may or may not get expanded, you will at least not have an
> > > empty body :)
> >
> > Ooh, now I get it. I finally understand that *unspecified* is an
> > actual value in Guile. I’m sorry and a bit embarrassed it took that
> > long. So, something like that?
> Yep, like that. Will test as soon as mumi gives me a non-empty patch
> set.
Mumi still appears broken; pushed anyway.
Cheers
[Message part 3 (message/rfc822, inline)]
Dear guix,
tracker does not build on i686-linux. There are 2 failing test cases: parsing
a double does not give the same result as the compiler implementation of a
literal parser, and the far away dates are off (I suspect a 32-bit time_t).
Anyway, I relaxed the former so that it is equal up to 1e-12, and I disabled
the latter.
What do you think?
Best regards,
Vivien
Vivien Kraus (1):
gnu: tracker: Update to 3.6.0.
gnu/packages/gnome.scm | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
base-commit: e9ff5d51e3297089e66c124195e1f1b42dbded65
--
2.41.0
This bug report was last modified 1 year and 239 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.