Note that if you do this, people who install your package will locally
still have the documentation bug, so it's probably better to upload a
new version anyway.
Erik
On 20 January 2016 at 13:41, Oliver Charles wrote:
> This would require the ability to re-upload a package that only has
> documen
On Tue, Mar 17, 2015 at 4:29 PM, Mikhail Glushenkov
wrote:
> Hi,
>
> On 17 March 2015 at 16:15, Thomas Tuegel wrote:
>>
>> Otherwise, please alert me if you have any blocking
>> issues; AFAIK there are none at this time.
>
> There are two test cases that are failing with 7.10, but fixing them
> w
It would perhaps be worth it for someone with the right permissions to
edit the (five) old versions on hackage, and add upper bounds. That
way cabal install wouldn't use this very old version assuming it works
(it probably doesn't).
Erik
On Wed, Dec 17, 2014 at 10:52 AM, Toby Goodwin wrote:
> Hi
The way I usually do this, is your last option: I define 'CPP-Options:
-DDEBUG' in the cabal file. I don't know why this doesn't work for
you. Perhaps it is the final 'install' command, which duplicates the
configure and build, but doesn't have the flag? You could try again
with only 'cabal install
On Sat, May 10, 2014 at 7:15 PM, Bardur Arantsson wrote:
> On 2014-05-10 18:27, Bardur Arantsson wrote:
>>
>> So, here's a little feature request: Couldn't we just have cabal install
>> spit out the full build log in case a build fails? Is there any real
>> disadvantage that I'm not seeing?
>
> (B
Could it be this problem?
https://plus.google.com/115504368969270249241/posts/19fyYuT5C1i
Regards,
Erik
On Thu, May 8, 2014 at 6:23 PM, Simon Peyton Jones
wrote:
> Dear Cabal-ers
>
> I have downloaded a binary installation of GHC 7.8.2, for Linux.
>
> Now I want to install regex-compat. First
You can handle this scenario pretty easily by setting up a private
hackage. Then add a second remote-repo to your cabal config, either
globally or in the sandbox. We do this, and it works pretty well.
Regards,
Erik
On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards
wrote:
> Hi Johan,
>
> Not sur
On Wed, Feb 26, 2014 at 4:01 PM, Johan Tibell wrote:
> On Wed, Feb 26, 2014 at 3:51 PM, Tillmann Rendel
> wrote:
>>
>> 1. change `cabal init` to use the pretty printer.
>> 2. expose the pretty printer at the command line.
>
> Agreed on both points. We should add (2) as `cabal format` (similar t
On Sun, Jan 5, 2014 at 11:37 AM, Daniel Trstenjak
wrote:
> It would be nice if 'cabal sdist' or 'cabal upload' would warn the user
> about missing modules.
This was built to run during 'cabal build' [0] but deemed too slow.
See the issue for a possible future direction.
> It seems that currently
On Sun, Dec 8, 2013 at 7:50 PM, Peter Selinger wrote:
> thanks for your reply! So say my package directory contains two files:
>
> Test.hs
> PreProc.hs
>
> What you are suggesting is:
>
> ghc Test.hs -F -pgmF ./PreProc
>
> However, this gives the error message:
>
> ghc: could not execute: ./Pr
I don't know of anything taking into account the current
configuration. There is cabal sdist --list-sources, which will list
all the files that would be written to a source distribution.
Alternatively, there is the output from 'ghc -M', which generates
dependencies in Makefile format. Neither quite
On Tue, Oct 8, 2013 at 7:40 PM, Adam Foltzer wrote:
> On Tue, Oct 8, 2013 at 9:54 AM, Johan Tibell wrote:
>>
>> I would like for there to be a both a command line flag and a
>> ~/.cabal/config setting (there isn't one already, is there?)
>
> Please let me know if this is the case! I have combed t
On Mon, Sep 16, 2013 at 10:16 AM, Henning Thielemann
wrote:
>
> On Wed, 4 Sep 2013, Johan Tibell wrote:
>
>> * GHCi support. It's now much easier to use ghci when developing your
>> packages, especially if those packages require preprocessors (e.g.
>> hsc2hs).
>
> That's a great feature! How can I
Hi all,
I just upgraded our internal hackage to the latest HEAD. I found that
the behavior of the 'trustees' group has changed. Previously, they
could upload any (existing) package, but that doesn't work anymore.
This functionality was very useful for us, since otherwise, we'd have
to add all our
On Wed, Oct 3, 2012 at 6:06 PM, Johan Tibell wrote:
> On the behalf of the many contributors to cabal, I'm proud to present
> cabal-install-1.16.0.
Congratulations and thanks to all those involved!
> To install:
>
> cabal update
> cabal install cabal-install-1.16.0 Cabal-1.16.0.1
It see
On Tue, Sep 11, 2012 at 11:29 PM, Ian Lynagh wrote:
> On Mon, Sep 10, 2012 at 09:55:30AM +0200, Henning Thielemann wrote:
>>
>> Next test: I have successfully uploaded a package candidate of
>> 'gnuplot'. Now I go to the gnuplot candidate page and click on
>> [maintain]. Then I get a new page with
On Fri, Sep 7, 2012 at 4:28 PM, Ian Lynagh wrote:
> On Fri, Sep 07, 2012 at 04:22:24PM +0200, Erik Hesselink wrote:
>>
>> I created a ticket for hackage2. Should I mark it as such (but not
>> important)? Or will that interfere with this list?
>
> Definitely mark it hac
Hi Ian,
I created a ticket for hackage2. Should I mark it as such (but not
important)? Or will that interfere with this list?
Erik
On Fri, Sep 7, 2012 at 4:07 PM, Ian Lynagh wrote:
>
> Hi all,
>
> FYI, I've been making tickets labelled 'hackage2' and 'important' for
> issues that we need to loo
Hi Ian,
We used acid-state (actually happstack-state) at Silk for our session
store. We had the same problems you describe: slow shutdown/startup,
high memory usage, unable to inspect the data. We recently switched to
an SQL database. Just another data point.
Erik
On Thu, Sep 6, 2012 at 8:49 PM,
On Thu, Sep 6, 2012 at 7:49 PM, Matthew Gruen wrote:
> I'm a little bit confused on the exact set up. The uploaders group seems to
> be roughly the same thing as the trustees group. (Except uploaders has an
> AND relationship with per-package groups as far as membership requirements
> for upload,
On Tue, Sep 4, 2012 at 1:35 AM, Leon Smith wrote:
> On Mon, Sep 3, 2012 at 4:20 AM, Erik Hesselink wrote:
>>
>> I think that the eventual situation should have per-package uploaders.
>> It just seems to dangerous for anyone to be able to upload any
>> package, especial
On Mon, Sep 3, 2012 at 4:38 PM, Ross Paterson wrote:
> In Hackage 1 packages can be deprecated, optionally indicating a
> recommended replacement (the "deprecated" and "superseded by" fields of
> the per-package "tags" file), e.g. partial-lens and binary-strict-0.3.1.
> These don't seem to be in H
On Sat, Sep 1, 2012 at 5:10 PM, Ian Lynagh wrote:
> On Fri, Aug 31, 2012 at 01:57:55AM +0100, Ian Lynagh wrote:
>>
>> On Thu, Aug 30, 2012 at 08:13:01PM -0400, Leon Smith wrote:
>> > Ok, I tried to upload the most recent version of postgresql-simple, and I
>> > couldn't because I'm not the mainta
On Sat, Sep 1, 2012 at 7:25 PM, Ian Lynagh wrote:
> On Sat, Sep 01, 2012 at 07:11:54PM +0200, Erik Hesselink wrote:
>>
>> It's still not working. I'm trying to upload a new version of kqueue
>> (0.1.2.4). I start from
>> http://new-hackage.haskell.org/packages
On Sat, Sep 1, 2012 at 5:11 PM, Ian Lynagh wrote:
> On Fri, Aug 31, 2012 at 11:27:46AM +0200, Erik Hesselink wrote:
>> On Fri, Aug 31, 2012 at 11:12 AM, Erik Hesselink wrote:
>> > On Fri, Aug 31, 2012 at 2:13 AM, Leon Smith wrote:
>> >> Ok, I tried to upl
On Fri, Aug 31, 2012 at 11:12 AM, Erik Hesselink wrote:
> On Fri, Aug 31, 2012 at 2:13 AM, Leon Smith wrote:
>> Ok, I tried to upload the most recent version of postgresql-simple, and I
>> couldn't because I'm not the maintainer for that package.
>
> What is your
Hi Ian,
Looks great, thanks for the work! One question: I see the reverse
dependencies have been disabled, darcs says for 'performance
problems'. Do you have some details? Do you think it is hard to fix?
I wouldn't mind doing some permission granting for the testing period,
by the way.
Erik
On
On Tue, Aug 7, 2012 at 5:18 PM, Johan Tibell wrote:
> On Tue, Jul 31, 2012 at 7:44 PM, Johan Tibell wrote:
>> I was fooling around a bit with the build (it now includes test
>> reports!). Sorry for the noise.
>
> The build now seems to be stable so I've added cabal-devel@haskell.org
> to the list
On Mon, Feb 6, 2012 at 19:07, Duncan Coutts
wrote:
> On 6 February 2012 15:22, Erik Hesselink wrote:
>> Hi all,
>>
>> We run hackage-server internally at Silk. Every time we update to a
>> new version, it is unable to read our old data. Is the acid-state
>> bein
Hi all,
We run hackage-server internally at Silk. Every time we update to a
new version, it is unable to read our old data. Is the acid-state
being versioned correctly? Or is this expected behavior? It is very
annoying for us. If this is expected, is there a way to work around
it?
Erik
_
the other repos. It's not clear to me what the advantage
> of specifying > 1 remote-repo in the config file is.
>
> The idea we had was to enable 'cabal upload' both for public packages going
> to public Hackage and for private packages going to a private Hackage.
>
Hi Carl,
At Silk, we use a private hackage. You can just enter it in your main
cabal config (~/.cabal/config) as an extra entry:
remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
remote-repo: :
The only thing that doesn't work well, is the username/password for
'cabal
32 matches
Mail list logo