From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: heads-up: Haskell updates Date: Thu, 15 Feb 2018 10:17:22 +0100 Message-ID: <87o9kq7gt9.fsf@elephly.net> References: <87r2ppjbst.fsf@elephly.net> <873723pfya.fsf@netris.org> <871shn8jm5.fsf@elephly.net> <87zi4b744f.fsf@elephly.net> <20180214234721.4e9fe198@scratchpost.org> <87a7waodaa.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emFfc-00037O-5u for guix-devel@gnu.org; Thu, 15 Feb 2018 04:17:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emFfY-0004pa-VZ for guix-devel@gnu.org; Thu, 15 Feb 2018 04:17:36 -0500 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21046) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1emFfY-0004oU-JE for guix-devel@gnu.org; Thu, 15 Feb 2018 04:17:32 -0500 In-reply-to: <87a7waodaa.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel Mark H Weaver writes: > Given that it's using #ifdef to detect this, I'd expect the result to > depend only on the _headers_ being used to compile, and not the actual > kernel running the build. Is that right? If so, this doesn't explain > why it works for Ricardo but not for Andreas and Hydra. > > Note that on our 'master' branch we are using Linux-libre-4.4 kernel > headers, but on 'core-updates' we're using 4.9 kernel headers. FWIW, I only tried to build ghc-resourcet on the master branch, not on core-updates. > I suppose if one reads the error message literally: > > Control/Monad/Trans/Resource/Internal.hs:302:10: error: > =E2=80=A2 Could not deduce (MonadBase IO (Strict.StateT s m)) > arising from the superclasses of an instance declaration > from the context: MonadResource m > bound by the instance declaration > at Control/Monad/Trans/Resource/Internal.hs:302:10-63 > =E2=80=A2 In the instance declaration for > =E2=80=98MonadResource (Strict.StateT s m)=E2=80=99 > > "Could not deduce" might be interpreted to include the case where we > failed for lack of sufficient memory. They might have written the code > to catch any error at all, including out of memory errors, and report > the failure with this error message. I think that=E2=80=99s a misunderstanding. The cause for the error is earl= ier when it complains that some packages depend on different versions of the =E2=80=9Ctransformers=E2=80=9D package. =E2=80=9CStateT=E2=80=9D is a mona= d transformer. I think that =E2=80=9Cghc-pkg=E2=80=9D fails, which leads to some other ver= sion of the transformers package (maybe a default included with GHC) to be used. In the case where ghc-pkg does not fail (as on my laptop) the proper version is used, so there are no problems finding the expected instances. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net