Ricardo Wurmus writes:
> Andreas Enge writes:
>
>> Hello Ricardo,
>>
>> On Sat, Feb 17, 2018 at 02:04:31PM +0100, Ricardo Wurmus wrote:
>>> I’ve built ghc-resourcet successfully with this change. I’d be happy if
>>> those of you who reported build failures could please retry building
>>> ghc-re
Hi Timothy,
> We could follow the style of Hackage and force everything to reference
> the base libraries. To make this work, we would have to make builds
> fail if they don’t reference a base library that they need. Maybe
> there’s a way to hide the base libraries in the Haskell build system,
Hi Danny,
Danny Milosavljevic writes:
> I don't see where the diamond depenency is...
GHC includes “transformers”, which is what most packages use, but
“ghc-mtl” includes a different version (it has the same version number,
so it is hard to see from the warnings).
> But Timothy has a patchset
Hi Mark,
> Unfortunately, the patch applied by Danny didn't fix the problem on
> Hydra. I didn't look very closely, but from a glance the failure looks
> the same:
Yeah, but it fixed the ghc-pkg one ("ghc-pkg couldn't decommit memory"
or something) - so we can be reasonably sure that the ghc pac
Hi Danny,
Danny Milosavljevic writes:
> On Thu, 15 Feb 2018 03:41:33 -0500
> Mark H Weaver wrote:
>
>> 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.
>
> Yes, that's pre
Ricardo Wurmus writes:
> I’ll merge core-updates into master now.
Is that premature? There are still over 500 newly failed jobs on
core-updates compared to master.
https://hydra.gnu.org/eval/109914?compare=109912
Mark
Ricardo Wurmus writes:
> So let’s apply the patch.
> Danny, could you please do this on master and core-updates?
>
> I’d like to merge core-updates this week and it would be great if we
> could build all of the Haskell packages (and all those R packages that
> depend on Pandoc) before the merge.
Andreas Enge writes:
> Hello Ricardo,
>
> On Sat, Feb 17, 2018 at 02:04:31PM +0100, Ricardo Wurmus wrote:
>> I’ve built ghc-resourcet successfully with this change. I’d be happy if
>> those of you who reported build failures could please retry building
>> ghc-resourcet with current master or co
Ricardo Wurmus writes:
>> Based on your earlier suggestion, I played around with removing all the
>> packages that GHC provides. I made the same change to ghc-mtl on
>> core-updates, and it allows me to build ghc-resourcet.
> […]
>> Is this too drastic? I could rebase on top of your ghc-mtl cha
Hello Ricardo,
Ricardo Wurmus writes:
> thanks for the extra information.
Thank you for picking that up.
> I find it very puzzling that I cannot reproduce these build failures on
> my machine.
>
> I have just rebuilt ghc-resourcet with a modified ghc-mtl, which I
> suspect is the source of the
Hello Ricardo,
On Sat, Feb 17, 2018 at 02:04:31PM +0100, Ricardo Wurmus wrote:
> I’ve built ghc-resourcet successfully with this change. I’d be happy if
> those of you who reported build failures could please retry building
> ghc-resourcet with current master or core-updates (the fix to ghc-mtl i
Hi Timothy,
> Ricardo Wurmus writes:
>
>> I have just rebuilt ghc-resourcet with a modified ghc-mtl, which I
>> suspect is the source of the problem, because it pulls in a newer
>> version of ghc-transformers. I’m going to push this to core-updates and
>> master in a moment.
>
> Based on your e
Hi Ricardo,
Ricardo Wurmus writes:
> I have just rebuilt ghc-resourcet with a modified ghc-mtl, which I
> suspect is the source of the problem, because it pulls in a newer
> version of ghc-transformers. I’m going to push this to core-updates and
> master in a moment.
Based on your earlier sugg
Ricardo Wurmus writes:
> Timothy Sample writes:
>
>> Ricardo Wurmus writes:
>>
>>> I think that’s a misunderstanding. The cause for the error is earlier
>>> when it complains that some packages depend on different versions of the
>>> “transformers” package. “StateT” is a monad transformer.
>
Hi Oleg,
thanks for the extra information.
I find it very puzzling that I cannot reproduce these build failures on
my machine.
I have just rebuilt ghc-resourcet with a modified ghc-mtl, which I
suspect is the source of the problem, because it pulls in a newer
version of ghc-transformers. I’m g
Ricardo Wurmus writes:
> Oleg Pykhalov writes:
>
>> Ricardo Wurmus writes:
>>
>>> Marius Bakke writes:
>>>
Should we do a new merge to get the GHC patch, or just merge
core-updates and let the problem "fix itself" on 'master'?
>>>
>>> I’d prefer building GHC and ghc-resourcet first.
Timothy Sample writes:
> Ricardo Wurmus writes:
>
>> I think that’s a misunderstanding. The cause for the error is earlier
>> when it complains that some packages depend on different versions of the
>> “transformers” package. “StateT” is a monad transformer.
>
> For what it’s worth, I fixed t
Oleg Pykhalov writes:
> Ricardo Wurmus writes:
>
>> Marius Bakke writes:
>>
>>> Should we do a new merge to get the GHC patch, or just merge
>>> core-updates and let the problem "fix itself" on 'master'?
>>
>> I’d prefer building GHC and ghc-resourcet first. We don’t know if this
>> patch act
Ricardo Wurmus writes:
> Marius Bakke writes:
>
>> Should we do a new merge to get the GHC patch, or just merge
>> core-updates and let the problem "fix itself" on 'master'?
>
> I’d prefer building GHC and ghc-resourcet first. We don’t know if this
> patch actually fixes our problems. We shoul
Mark H Weaver writes:
> Ricardo Wurmus writes:
>
>> Marius Bakke writes:
>>
>>> Should we do a new merge to get the GHC patch, or just merge
>>> core-updates and let the problem "fix itself" on 'master'?
>>
>> I’d prefer building GHC and ghc-resourcet first. We don’t know if this
>> patch act
Leo Famulari writes:
> On Fri, Feb 16, 2018 at 07:12:47PM +0100, Marius Bakke wrote:
>> Ricardo Wurmus writes:
>>
>> > Marius Bakke writes:
>> >
>> >> Should we do a new merge to get the GHC patch, or just merge
>> >> core-updates and let the problem "fix itself" on 'master'?
>> >
>> > I’d pre
On Fri, Feb 16, 2018 at 07:12:47PM +0100, Marius Bakke wrote:
> Ricardo Wurmus writes:
>
> > Marius Bakke writes:
> >
> >> Should we do a new merge to get the GHC patch, or just merge
> >> core-updates and let the problem "fix itself" on 'master'?
> >
> > I’d prefer building GHC and ghc-resource
Ricardo Wurmus writes:
> Marius Bakke writes:
>
>> Should we do a new merge to get the GHC patch, or just merge
>> core-updates and let the problem "fix itself" on 'master'?
>
> I’d prefer building GHC and ghc-resourcet first. We don’t know if this
> patch actually fixes our problems. We shoul
Ricardo Wurmus writes:
> Marius Bakke writes:
>
>> Should we do a new merge to get the GHC patch, or just merge
>> core-updates and let the problem "fix itself" on 'master'?
>
> I’d prefer building GHC and ghc-resourcet first. We don’t know if this
> patch actually fixes our problems. We shoul
Marius Bakke writes:
> Should we do a new merge to get the GHC patch, or just merge
> core-updates and let the problem "fix itself" on 'master'?
I’d prefer building GHC and ghc-resourcet first. We don’t know if this
patch actually fixes our problems. We should merge master into
core-updates a
Danny Milosavljevic writes:
> git am just failed because the index is not matching.
>
> So I'll not push my core-updates.
>
> Next, I tried git merge origin/master which gave me a number of merge
> conflicts.
>
> One of those is gnu/local.mk:
>
> + %D%/packages/patches/gettext-multi-core.patch
git am just failed because the index is not matching.
So I'll not push my core-updates.
Next, I tried git merge origin/master which gave me a number of merge conflicts.
One of those is gnu/local.mk:
+ %D%/packages/patches/gettext-multi-core.patch \
+ %D%/packages/patches/gette
Hi Danny,
Danny Milosavljevic writes:
>> Danny, could you please do this on master and core-updates?
>
> I've done it on master now.
Thank you!
> Maybe it's me being used to SVN, but can I git am the commit to
> core-updates?
Yes.
> Wouldn't that cause a conflict on the next merge of master
On Thu, Feb 15, 2018 at 06:03:56PM +0100, Danny Milosavljevic wrote:
> Hi Ricardo,
>
> > Danny, could you please do this on master and core-updates?
>
> I've done it on master now.
>
> Maybe it's me being used to SVN, but can I git am the commit to core-updates?
>
> Wouldn't that cause a confli
Danny Milosavljevic writes:
> So the only problematic case is that the build process finds MADV_FREE
> but the running Linux doesn't yet have it and a ghc program runs on it.
>
> Reading MADV_DONTNEED docs again, MADV_DONTNEED pretty much does the same
> as MADV_FREE - but MADV_DONTNEED promises
Hi Ricardo,
> Danny, could you please do this on master and core-updates?
I've done it on master now.
Maybe it's me being used to SVN, but can I git am the commit to core-updates?
Wouldn't that cause a conflict on the next merge of master to core-updates
(because of the missing in-betweens) ?
Mark H Weaver writes:
> So far, almost all of the new packages are building successfully on
> Hydra, but I see one failure: ghc-resourcet, which in turn causes
> r-bookdown to dep-fail:
>
> https://hydra.gnu.org/build/2495799/nixlog/1/raw
Hmm, how odd. I did build ghc-resourcet before, but I
Timothy Sample writes:
> Unfortunately, I don’t know enough about Haskell to comment on whether
> or not these packages “really shouldn’t be overridden” or not. (It
> makes sense to me, but OTOH, why are they all split up and on Hackage if
> not for tinkering?) If they really shouldn’t be over
Ricardo Wurmus writes:
> I think that’s a misunderstanding. The cause for the error is earlier
> when it complains that some packages depend on different versions of the
> “transformers” package. “StateT” is a monad transformer.
For what it’s worth, I fixed this error on my machine by adding
“
On Thu, Feb 15, 2018 at 12:04:04PM +0100, Danny Milosavljevic wrote:
> So I suspect that Ricardo has a Linux >= 4.5 but Andreas and Hydra
> have a Linux < 4.5. Is that correct?
Strangely not. I am running Guix on Debian with a kernel 4.9.0-5-amd64.
Andreas
> I think it just didn't update one of the packages or the package database
> and now it got the wrong version where someone changed the type signature
> on one side and the other side is stale.
Or:
Configuring resourcet-1.1.7.5...
Warning: This package indirectly depends on multiple versions of
Hi Mark,
Hi Ricardo,
On Thu, 15 Feb 2018 03:41:33 -0500
Mark H Weaver wrote:
> 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.
Yes, that's precisely the problem.
* The [gl
Ricardo Wurmus writes:
> Mark H Weaver writes:
>
>> I suppose if one reads the error message literally:
>>
>> Control/Monad/Trans/Resource/Internal.hs:302:10: error:
>> • Could not deduce (MonadBase IO (Strict.StateT s m))
>> arising from the superclasses of an instance declara
Mark H Weaver writes:
> 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.
>
> The recently created evaluation 109913 on Hydra is for core-updates with
> the recent Haskell changes included. It'll be interesting t
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
Hi Danny,
Danny Milosavljevic writes:
> Hi Mark,
> Hi Ricardo,
>
> On Wed, 14 Feb 2018 20:39:12 +0100
> Ricardo Wurmus wrote:
>
>> Nor do I see this message:
>>
>> ghc-pkg: unable to decommit memory: Invalid argument
>
> Which Linux kernel version does this run on?
Last I knew, Hydra's x8
Hi Mark,
Hi Ricardo,
On Wed, 14 Feb 2018 20:39:12 +0100
Ricardo Wurmus wrote:
> Nor do I see this message:
>
> ghc-pkg: unable to decommit memory: Invalid argument
Which Linux kernel version does this run on?
> I don’t know what this message means, but the messages about requiring a
If t
Andreas Enge writes:
> On Wed, Feb 14, 2018 at 04:23:47PM -0500, Mark H Weaver wrote:
>> Ricardo Wurmus writes:
>> > I’m afraid I cannot reproduce this. I removed the successfully built
>> > ghc-resourcet from the store and rebuilt it successfully.
>>
>> FWIW, on Hydra, the same failure happe
Hello,
On Wed, Feb 14, 2018 at 04:23:47PM -0500, Mark H Weaver wrote:
> Ricardo Wurmus writes:
> > I’m afraid I cannot reproduce this. I removed the successfully built
> > ghc-resourcet from the store and rebuilt it successfully.
>
> FWIW, on Hydra, the same failure happened on both x86_64 and
Ricardo Wurmus writes:
> Ricardo Wurmus writes:
>
>> Mark H Weaver writes:
>>
>>> So far, almost all of the new packages are building successfully on
>>> Hydra, but I see one failure: ghc-resourcet, which in turn causes
>>> r-bookdown to dep-fail:
>>>
>>> https://hydra.gnu.org/build/2495799/n
Ricardo Wurmus writes:
> My local log looks rather different (see attached file).
mlrjkywz6grnmf84gwmy3ggx1zglkd-ghc-resourcet-1.1.7.5.drv.bz2
Description: Binary data
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Ricardo Wurmus writes:
> Mark H Weaver writes:
>
>> So far, almost all of the new packages are building successfully on
>> Hydra, but I see one failure: ghc-resourcet, which in turn causes
>> r-bookdown to dep-fail:
>>
>> https://hydra.gnu.org/build/2495799/nixlog/1/raw
>
> Hmm, how odd. I d
Hi Ricardo,
Ricardo Wurmus writes:
> I’ve just pushed a very large number of updates to Haskell packages and
> switched to GHC 8 as the default.
Wow, it's an impressive amount of work, kudos to you!
So far, almost all of the new packages are building successfully on
Hydra, but I see one failure
Ludovic Courtès writes:
>> * updating Haskell packages automatically is dangerous as not all
>> packages work well together. When updating I often had to take a few
>> steps back to reduce the version number. On Hackage I picked the LTS
>> version where available.
>
> Does that mean that
Hello,
Ricardo Wurmus skribis:
> I’ve just pushed a very large number of updates to Haskell packages and
> switched to GHC 8 as the default.
Thanks for the heroic work!
> * updating Haskell packages automatically is dangerous as not all
> packages work well together. When updating I often h
Hi Guix,
I’ve just pushed a very large number of updates to Haskell packages and
switched to GHC 8 as the default.
I have built almost all of these updated packages and some packages that
depend on them, including r-rmarkdown, hisat, darcs, xmonad, and r-rcas.
One notable exception is idris — I
51 matches
Mail list logo
