GNU bug report logs - #36084
ghc-tasty/ghc-clock circular dependency breaking is broken

Previous Next

Package: guix;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Robert Vollmert <rob <at> vllmrt.net>
To: bug-guix <at> gnu.org
Subject: ghc-tasty/ghc-clock circular dependency breaking is broken
Date: Tue, 4 Jun 2019 02:26:04 +0200
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):

From: Timothy Sample <samplet <at> ngyro.com>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36084 <at> debbugs.gnu.org
Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is
 broken
Date: Tue, 16 Jul 2019 11:08:04 -0400
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):

From: Robert Vollmert <rob <at> vllmrt.net>
To: Timothy Sample <samplet <at> ngyro.com>
Cc: 36084 <at> debbugs.gnu.org
Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is
 broken
Date: Tue, 16 Jul 2019 18:17:26 +0200

> 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):

From: Timothy Sample <samplet <at> ngyro.com>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36084-done <at> debbugs.gnu.org
Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is
 broken
Date: Tue, 16 Jul 2019 15:11:00 -0400
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):

From: Robert Vollmert <rob <at> vllmrt.net>
To: 36084 <at> debbugs.gnu.org
Cc: Timothy Sample <samplet <at> ngyro.com>
Subject: not really fixed?
Date: Wed, 17 Jul 2019 16:13:59 +0200
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.