GNU bug report logs -
#36084
ghc-tasty/ghc-clock circular dependency breaking is broken
Previous Next
Reported by: Robert Vollmert <rob <at> vllmrt.net>
Date: Tue, 4 Jun 2019 00:27:01 UTC
Severity: normal
Done: Timothy Sample <samplet <at> ngyro.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36084 in the body.
You can then email your comments to 36084 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#36084
; Package
guix
.
(Tue, 04 Jun 2019 00:27:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Robert Vollmert <rob <at> vllmrt.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 04 Jun 2019 00:27:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built without tests,
while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests.
This means that any package which depends on ghc-tasty and ghc-clock is potentially broken,
e.g.:
Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package tasty (tasty-1.1.0.3-98rSghuW4l26JGzzQLN3ha) requires clock-0.5.1-KAiVgaxjUlIIuEB7RoOIe6
package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires clock-0.7.2-JStwYFlKVmNHl0K1ll1Mx5
I’d suggest breaking the cycle instead by
1. introducing tasty-bootstrap which builds against the `time` module via the cabal flags:
flag clock
description:
Depend on the clock package for more accurate time measurement
default: True
This could be done via
(arguments `(#:configure-flags (“—flag=-clock”)))
as far as I understand.
2. changing ghc-clock to test via tasty-bootstrap (and possibly some more variant testing
packages that would be changed to depend on tasty-bootstrap)
3. changing tasty to test via ghc-clock.
(I gave this approach a shot myself, but I’m running into mysterious silently hanging guild and guix build
processes — possibly some cyclic dependencies which are noticed?)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#36084
; Package
guix
.
(Tue, 16 Jul 2019 15:09:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 36084 <at> debbugs.gnu.org (full text, mbox):
Hi Robert,
Robert Vollmert <rob <at> vllmrt.net> writes:
> ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built without tests,
> while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests.
>
> This means that any package which depends on ghc-tasty and ghc-clock is potentially broken,
> e.g.:
>
> Warning:
> This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
> package tasty (tasty-1.1.0.3-98rSghuW4l26JGzzQLN3ha) requires clock-0.5.1-KAiVgaxjUlIIuEB7RoOIe6
> package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires clock-0.7.2-JStwYFlKVmNHl0K1ll1Mx5
>
> I’d suggest breaking the cycle instead by
>
> 1. introducing tasty-bootstrap which builds against the `time` module via the cabal flags:
>
> flag clock
> description:
> Depend on the clock package for more accurate time measurement
> default: True
>
> This could be done via
> (arguments `(#:configure-flags (“—flag=-clock”)))
> as far as I understand.
>
> 2. changing ghc-clock to test via tasty-bootstrap (and possibly some more variant testing
> packages that would be changed to depend on tasty-bootstrap)
>
> 3. changing tasty to test via ghc-clock.
>
>
> (I gave this approach a shot myself, but I’m running into mysterious silently hanging guild and guix build
> processes — possibly some cyclic dependencies which are noticed?)
After looking at this and your patch at <https://bugs.gnu.org/36249>,
I’m wondering if it works as long as we make sure the versions match.
Can we just inherit the current “ghc-clock”, disable its tests, and call
it “ghc-clock-bootstrap”? Is the Cabal consistency checking too clever
for that?
If that doesn’t work, can you explain why the method you proposed above
doesn‘t work? It seems a little simpler than your patch. In fact,
maybe we could live with the main “ghc-tasty” package being built
without “ghc-clock” (via the flag you mentioned).
Sorry for taking so long to get to this, BTW. :(
-- Tim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#36084
; Package
guix
.
(Tue, 16 Jul 2019 16:18:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 36084 <at> debbugs.gnu.org (full text, mbox):
> On 16. Jul 2019, at 17:08, Timothy Sample <samplet <at> ngyro.com> wrote:
>
> Hi Robert,
>
> After looking at this and your patch at <https://bugs.gnu.org/36249>,
> I’m wondering if it works as long as we make sure the versions match.
> Can we just inherit the current “ghc-clock”, disable its tests, and call
> it “ghc-clock-bootstrap”? Is the Cabal consistency checking too clever
> for that?
>
> If that doesn’t work, can you explain why the method you proposed above
> doesn‘t work? It seems a little simpler than your patch. In fact,
> maybe we could live with the main “ghc-tasty” package being built
> without “ghc-clock” (via the flag you mentioned).
I tried the direct approach again, and this time it worked. Posted an
updated patch.
I believe this should be fine, since GHCs builds should be deterministic.
Cheers
Robert
Reply sent
to
Timothy Sample <samplet <at> ngyro.com>
:
You have taken responsibility.
(Tue, 16 Jul 2019 19:12:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Robert Vollmert <rob <at> vllmrt.net>
:
bug acknowledged by developer.
(Tue, 16 Jul 2019 19:12:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 36084-done <at> debbugs.gnu.org (full text, mbox):
Hi,
Robert Vollmert <rob <at> vllmrt.net> writes:
>> On 16. Jul 2019, at 17:08, Timothy Sample <samplet <at> ngyro.com> wrote:
>>
>> Hi Robert,
>>
>> After looking at this and your patch at <https://bugs.gnu.org/36249>,
>> I’m wondering if it works as long as we make sure the versions match.
>> Can we just inherit the current “ghc-clock”, disable its tests, and call
>> it “ghc-clock-bootstrap”? Is the Cabal consistency checking too clever
>> for that?
>>
>> If that doesn’t work, can you explain why the method you proposed above
>> doesn‘t work? It seems a little simpler than your patch. In fact,
>> maybe we could live with the main “ghc-tasty” package being built
>> without “ghc-clock” (via the flag you mentioned).
>
> I tried the direct approach again, and this time it worked. Posted an
> updated patch.
>
> I believe this should be fine, since GHCs builds should be deterministic.
It looks like this is a common idiom for us, so I’m pretty confident,
too. Fixed in 71e5d425c9b9e108ebdd06d13de45b56dddd9ef5. Thanks!
-- Tim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#36084
; Package
guix
.
(Wed, 17 Jul 2019 14:15:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 36084 <at> debbugs.gnu.org (full text, mbox):
It seems the two clock packages are still subtly different, apparently
due to the tested variant pulling in a dependency on the test libraries.
Compare https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36705.
Configuring tasty-hspec-1.1.5.1...
Warning:
This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
package hspec-core (hspec-core-2.5.5-H06vLnMfEeIEsZFdji6h0O) requires clock-0.7.2-9qwmBbNbGzEOSffjlyarp
package tasty (tasty-1.1.0.3-I8Vu9v0lHj8Jlg3jpKXavp) requires clock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU
It’s possible that this warning is really just a warning, and that there’s
no real problem here because the packages are really the same, but… I
don’t like it.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 15 Aug 2019 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 227 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.