GNU bug report logs - #56771
[PATCH 00/33] *** Update Jami to 20220725, core Qt packages along the way

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Jack Hill <jackhill <at> jackhill.us>, Lars-Dominik Braun <lars <at> 6xq.net>, 56771 <at> debbugs.gnu.org
Subject: [bug#56771] [PATCH 00/33] *** Update Jami to 20220725, core Qt packages along the way
Date: Mon, 01 Aug 2022 11:39:16 -0400

Hi Maxime,

Maxime Devos <maximedevos <at> telenet.be> writes:

> On 25-07-2022 23:17, Maxim Cournoyer wrote:
>> Hello Guix,
>>
>> This series add the base Qt 6 components required by Jami and updates Jami
>> itself to its latest stable release (made today!).  All the Qt components
>> updated have their test suite enabled except for qtwebengine, for which it was
>> already disabled. [...]
>
> This patch series appears to have caused some failures in other
> packages:
> <https://ci.guix.gnu.org/eval/504295?border-high-time=1659350617&border-high-id=1141372&status=failed>,
> could they be fixed?

Thanks for the heads-up.  It appears the qt-build-system change
(introducing #:qtbase) broke all packages explicitly defining the build
arguments, in which case #:qtbase is #f.

The following change fixes it:

--8<---------------cut here---------------start------------->8---
modified   guix/build-system/qt.scm
@@ -122,7 +122,7 @@ (define private-keywords
 
 (define* (qt-build name inputs
                    #:key
-                   qtbase
+                   (qtbase (default-qtbase))
                    source (guile #f)
                    (outputs '("out")) (configure-flags ''())
                    (search-paths '())
@@ -161,7 +161,7 @@ (define builder
                     #:phases #$(if (pair? phases)
                                    (sexp->gexp phases)
                                    phases)
-                    #:qtbase #$qtbase
+                    #:qtbase #+qtbase
                     #:qt-wrap-excluded-outputs #$qt-wrap-excluded-outputs
                     #:qt-wrap-excluded-inputs #$qt-wrap-excluded-inputs
                     #:configure-flags #$configure-flags
@@ -193,7 +193,7 @@ (define* (qt-cross-build name
                          #:key
                          source target
                          build-inputs target-inputs host-inputs
-                         qtbase
+                         (qtbase (default-qtbase))
                          (guile #f)
                          (outputs '("out"))
                          (configure-flags ''())
@@ -250,7 +250,7 @@ (define %outputs
                                               search-path-specification->sexp
                                               native-search-paths)
                     #:phases #$phases
-                    #:qtbase #$qtbase
+                    #:qtbase #+qtbase
                     #:configure-flags #$configure-flags
                     #:make-flags #$make-flags
                     #:out-of-source? #$out-of-source?
--8<---------------cut here---------------end--------------->8---
                     
We could also refrain from introducing this argument, instead finding
the qtbase in use via search-input-file at the place where we need to
know its store output to figure out the version used; that'd be simpler,
but would remove the mechanism here that allows a user potentially
mixing qt5 and qt6 (probably not a very useful use case) and being able
to explicitly set the qtbase used for wrapping/building.

What do you think?

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.