I forwarded this upstream.
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Arjan,
Great work. I'm really excited that you are doing this. You can
become maintainer if you like, or I can stay maintainer for now if you
just want to NMU this package.
Ross, sorry for not getting back to you about this packaging. Thanks
so much for doing so much hard work to make the
Arjan Oosting [EMAIL PROTECTED] writes:
Hi Isaac,
I was going through the BTS and saw that this RC bug is still open. Do
you think you will upload a new version of libghc6-cabal-dev or could
the package be removed as ghc6 ships a recent version of Cabal now?
I think I will package a new
Peter Van Eynde [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.6-1
Severity: normal
Hello,
While stressing darcs to the limits I fear ran into the error
described at:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2006-March/006246.html
error message:
darcs: internal
Thanks. I'll check it out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
See forwarded message. Looks resolved. Will check for this patch in
next upload.
---BeginMessage---
Tommy Pettersson [EMAIL PROTECTED] added the comment:
fixed in 1.0.7 by:
Sat Mar 4 12:15:32 CET 2006 Eric Kow [EMAIL PROTECTED]
* Improved support for absolute paths (issue39)
--
Thanks, Tommy.
Is this going to be integrated upstream too? It looks like it tries
running pager if it can, and if not calls less, then more, which seems
fine for all architectures. I don't actually know how standard PAGER
or pager are.
peace,
isaac
Tommy Pettersson [EMAIL PROTECTED]
Tommy Pettersson [EMAIL PROTECTED] writes:
Hrm, the sensible-editor patch (sorry for the faulty one) should be:
I used the first one since it's a smaller change. I have thesame
question as last time, will this live upstream?
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Package: qemu
Version: 0.8.0-2
Severity: normal
After a few minutes of using qemu, the control key gets stuck on. I'm
using Debian GNU/Linux (on both host and qemu), and this happens with
the qemu machine running 2.4.26 and 2.4.27 versions of the kernel.
I'm not sure how to go about debugging
This is fixed in head, probably will be fixed in next release. Will
verify at that time.
---BeginMessage---
Tommy Pettersson [EMAIL PROTECTED] added the comment:
fixed in 1.0.6
Sat Dec 10 22:51:22 CET 2005 [EMAIL PROTECTED]
* implementation of --set-scripts-executable on local darcs get
Package: wnpp
Severity: wishlist
* Package name: trac-hacks
Version :
Upstream Author :
* URL or Web page : http://trac-hacks.org/
* License :
Description : A collection of very useful trac plugins
trac-hacks.org hosts a collection of very useful trac plugins.
Wouter Verhelst [EMAIL PROTECTED] writes:
reopen 340942
thanks
On Wed, Jan 18, 2006 at 09:03:10PM -0800, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#340942: darcs_1.0.4-1(m68k/unstable): configure failed,
which was filed against the darcs
retitle 348807 Make postinst script more robust in case package has been removed
thanks
Jose. Thanks for the details. For now, I'd advise that you not use
unregister. There's no reason to unregister Cabal since there's a
cabal package. I'll look into making the script more robust so it
Comments from the GHC maintainer:
On Wed, Jan 18, 2006 at 08:59:18PM -0800, Isaac Jones wrote:
Hi Ian. Can you comment on this bug at all?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341517
I assume it's the same as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342227
At any rate
José Salavert Torres [EMAIL PROTECTED] writes:
Package: libghc6-cabal-dev
Version: 1.1.3
if this package is installed and you run:
# ghc-pkg unregister Cabal
then you can't run:
# apt-get remove libghc6-cabal-dev
if you install the package, the old cabal version (1.0), which comes
This now builds as of darcs-1.0.5. Did anything change in upstream to
make this work, or was there a change in the build-depends?
http://buildd.debian.org/fetch.php?pkg=darcsver=1.0.5-3arch=m68kstamp=1137441558file=logas=raw
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
retitle 341517 FTBFS: SPARC
thanks
Darcs building on SPARC has failed in a number of ways recently.
cannot actually use libcurl
[FastPackedString.o] Bus error
and currently:
checking where GHC keeps its libraries... /usr/lib/ghc-6.4.1
checking GHC.Handle.openFd... Terminated
make: ***
retitle 237857 darcs fails to build on mipsel
thanks
The tex4ht related bugs should be solved now, since we're no longer
building the documentation (sorta) since it comes in the upstream
tarball.
This doesn't work perfectly, but hopefully it'll be better in future
upstream.
peace,
isaac
--
Matt Kraai [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.5-3
When I try to pull all of the changes from the upstream directory to
the debian directory, darcs fails:
Does running 'darcs repair' actually fix the problem, or not?
Darcs upstream, is this a known bug?
peace,
isaac
On 1/15/06, David Roundy [EMAIL PROTECTED] wrote:
On Sun, Jan 15, 2006 at 01:14:57PM +0100, Aurelien Jarno wrote:
darcs build-depends on latex2html, which is in non-free. Therefore, it
could not stay in main, as stated by policy 2.2.1:
I believe that darcs should be able to get by without a
On 1/12/06, David Roundy [EMAIL PROTECTED] wrote:
When building darcs from a tarball, the documentation shouldn't be
built, since it's built during the make dist that generates the tarball...
From what I can tell, the makefiles are set up such that it's
impossible not to rebuild the
David, Is there anything that can be done in configure to set the
TEX4HTENV variable in Debian? I think that would fix the build
problem we're seeing, at least on i386. There are also flags to
tex4ht where you can specify this path.
TEX4HTENV=/etc/tex4ht/tex4ht.env
peace,
isaac
This is probably due to a documentation build failure as below:
Output written on darcs.dvi (228 pages, 826908 bytes).
Transcript written on darcs.log.
--- warning --- Can't find/open file `tex4ht.env | .tex4ht'
--- error --- Illegal storage address
The program segfaults when it can't find
I sent your patch upstream for them to have a look. Hopefully I can
get it into the 1.0.5 release.
peace,
isaac
Tags 341599 +moreinfo
thanks
Daniel,
David Roundy replied to your bug report some time back. Can you verify
whether this is in fact a bug, or an issue with your mailer or
something else?
peace,
isaac
Can anyone verify whether this is fixed in 1.0.5? If so, can the
original submitter, Matt, please close this by emailing
[EMAIL PROTECTED]
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This doesn't look like it's fixed in 1.0.5. Can anyone verify?
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This does not appear to be fixed in 1.0.5.
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: hugs
Version: 98.200503.08-4
Severity: wishlist
from an email between me ian:
Should I add a runhaskell script to the hugs package?
Yes.
If so, what
priority should I install it at?
I suggest 5620050308
5 == hugs
6 == stable (CVS snapshot would use 3)
20050308 == date
Can you
From the upstream maintainer
that run-haskell only works after loading haskell-site-file.el is
completely normal. As for the keymapp nil error on run-hugs
I believe it was fixed in 2.1 (but the corresponding fix for ghci
is only in CVS).
From upstream:
AFAIK that sounds like some bug in auto-fill-mode which has been
partly fixed in Emacs-22.
Yes, can you please?On 1/5/06, Matt Kraai [EMAIL PROTECTED] wrote:
Package: darcsVersion: 1.0.3-2When I try to unpull a particular patch, darcs fails: $ darcs unpull Thu Jan5 09:28:33 PST 2006[EMAIL PROTECTED]
* Imported autogen-5.8.1pre3 into Darcs repository Shall I unpull this patch? (1/25)
Does debuild use make -e? Why is it getting input from user environment variables? That's a little strang.
GZIP is a standard environment variable for this program, so we should
perhaps avoid using it since user environment variables apparently leak
into the make environment, but I don't know why
I am seeing a similar problem. Any clues on this yet?
---BeginMessage---
David Roundy [EMAIL PROTECTED] added the comment:
(Forwarded from the debian bug tracker...)
On Sat, Dec 17, 2005 at 11:07:38PM +0100, Juliusz Chroboczek wrote:
Your patch looks good to me -- but it's out of date.
A patch against the darcs-unstable tree would be warmly
Hi Ian. Look like a GHC bug?
Blars Blarson [EMAIL PROTECTED] writes:
Package: haskell-cabal
Version: 1.1.3
Severity: serious
Justification: no longer builds from source
haskell-cabal failed to build on a sparc buildd, duplicated on my
sparc pbuilder.
Message from David Roundy:
darcs.cgi should be compatible with darcs-createrepo
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297782
I'd really like to just remove darcs-createrepo, as it's a complicated
ill-tested script that must be run as root. That would solve this
problem...
--
Message from David Roundy:
fails to look for new files if there is a socket
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304264
Worth fixing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Message from David Roundy:
darcs: ignores changes if an absolute path is specified
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306063
Still there, and someone could fix it, I suppose. It doesn't strike me as
being very high priority.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Message from David Roundy:
darcs: --set-scripts-executable works partially
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328032
Can you see if you can reproduce this bug? I don't get it, at least not
with a remote get. For a local get, --set-scripts-executable has no
effect--which is a
Message from David Roundy:
Please reflow --help output to the terminal width
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332542
I'd put it as a wishlist. I think it'd be a good idea, but would
require quite a bit more infrastructure in our printing engine.
--
To UNSUBSCRIBE, email
Message from David Roundy:
Doesn't like pasted text.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333251
I've seen this before, but it's hard to reproduce, and I haven't tracked
down what precisely causes it. It's something to do with our buffer
handling.
I have also seen this.
Message from David Roundy:
get-ing a repository that contains an upper case file name fails on vfat
filesystem
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325693
This is an odd one--I've never seen a bug report like it.
David, what do you think of the attached patch in the Debian bug
Message from David Roundy:
Darcs hang on some conflicts during pull
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336327
This is a known issue, and not going to be fixed until the new conflict
handling code is done. It's much of the reason for the new conflict
handling code.
--
To
Message from David Roundy:
Command to provide a summary of an emailed patch.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335043
apply --dry-run would be a good thing to add.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Blars Blarson [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.4-2
Severity: serious
Justification: no longer builds from source
darcs failed to build on a sparc buildd, duplicated on my sparc pbuilder.
Didn't you already file this bug yesterday:
From: Blars Blarson [EMAIL
David Roundy [EMAIL PROTECTED] writes:
(snip)
... It would help to have the config.log.
Most likely the curl-config output is messed up in some way. We use
curl-config to determine which flags to use to link with curl, but then we
check whether these flags actually work, and it is this
Greetings. I just uploaded a new darcs, version 1.0.4 to Debian.
After a while, it'll be available via apt-get for unstable. I am
unsure whether your bug is fixed in this new version. If you have a
moment, can you check to see whether it is fixed? After upgrading,
please verify that you are
John Goerzen [EMAIL PROTECTED] writes:
retitle 336327 Darcs hang on some conflicts during pull
reassign 336327 darcs
thanks
On Mon, Oct 31, 2005 at 10:55:13AM -0500, James Vega wrote:
Can you make your repositories available somewhere for us to examine?
darcs get
John Goerzen [EMAIL PROTECTED] writes:
On Mon, Oct 31, 2005 at 09:42:37AM -0800, Isaac Jones wrote:
darcs get http://jamessan.com/~jamessan/fish/fish/
darcs get http://jamessan.com/~jamessan/fish/fish.upstream/
The dsc, diff.gz, and orig.tar.gz are also in the top-level fish
directory
Thanks for the bug report. I just did an upload which I hope will fix
it. Please re-open the bug if not :) Look for the -4 version.
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: haskell-cabal
Severity: normal
From: Frederik Eaton
Subject: cabal installation
It would be nice if cabal would unlink destination files before
installing over them, rather than just calling copyFile. It appears
that when copyFile finds that a destination file already exists,
rather
I'll look at this next time I do an upload. Thanks for the heads-up.
Tom Parker [EMAIL PROTECTED] writes:
Version: 1.0.3-2
The --with-sendmail flag is now available on current unstable Darcs
(1.0.3-2), so why does darcs still build-depend on exim4 |
mail-transport-agent?
--
To
This looks fixed. Should be closed on next upload.
---BeginMessage---
On Thu, Oct 06, 2005 at 05:27:30PM -0400, Juliusz Chroboczek via RT wrote:
Actually, I sort of take back my previous post to this bug. Perhaps we
should make --summary have an effect when combined with --all. I'm
Daniel Burrows [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.3-2
Severity: normal
Sometimes (not always) if I paste text into a darcs prompt, such as
the one asking for a patch name, or even if I just type too quickly,
darcs dies like this:
darcs: stdin: hSetBuffering:
Daniel Burrows [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.3-2
Severity: minor
On a thin terminal, the output of darcs --help is nearly unreadable.
It would be nice if it could be reflowed to the terminal width.
Thanks for the bug report. I'm forwarding this upstream.
peace,
/mount.davfs/
chmod g+w /var/run/mount.davfs/
All of this may be dangerous on a multi-user machine.
peace,
isaac
--
isaac jones [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.3-2
Severity: important
The original file has 0755 but after a darcs get
--set-scripts-executable, the mode is 0754.
What sort of file is this? How can I reproduce it?
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
gary ng [EMAIL PROTECTED] writes:
testing shell script. It is very simple to reproduce.
Just with the following :
mkdir dir1
cd dir1
echo #!/bin/sh a
chmod 0755 a
darcs init
darcs add *
darcs record
cd ..
darcs get --set-scripts-executable dir1 dir2
Now dir2/a is 0754, instead of
Arjan Oosting [EMAIL PROTECTED] writes:
tags pending 327491
thanks
Op za, 10-09-2005 te 15:57 +0200, schreef Emilio Jesus Gallego Arias:
Package: drift
Version: 2.1.1-1
Severity: serious
Hi,
this package should be uploaded to comply with the gcc ABI transition,
as it currently
Thomas Dickey [EMAIL PROTECTED] writes:
I see byacc is checked for in the hugs98 configure script, but parser.y
doesn't contain any bison-specific junk. Any idea why byacc is being
picked on here?
Either configure or the upstream author thinks it won't work with byacc:
checking for byacc...
Roger Leigh [EMAIL PROTECTED] writes:
Is this bug still applicable. Can it enter etch/testing?
I'm afraid that this bug is still applicable until a GHC 6.4 version
enters testing. Perhaps this will happen now that the 'grave' bugs
are cleared? Are we waiting forf 6.4.1 before letting GHC
A binary NMU was recently performed, which may fix the problem. I'm
also going to be making a source upload soon. Please let me know if
this doesn't help.
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Roger Leigh [EMAIL PROTECTED] writes:
Hi,
Has any progress been made on this yet? amd64 will be entering the
archive soon, at which point this will become a serious bug.
It's also worth pushing upstream--they may want to integrate this
(-fPIC) in their build since it will affect all amd64
Roger Leigh [EMAIL PROTECTED] writes:
Isaac Jones [EMAIL PROTECTED] writes:
Roger Leigh [EMAIL PROTECTED] writes:
Is this bug still applicable. Can it enter etch/testing?
I'm afraid that this bug is still applicable until a GHC 6.4 version
enters testing. Perhaps this will happen now
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sat, Sep 03, 2005 at 01:23:52PM -0700, Isaac Jones wrote:
A binary NMU was recently performed, which may fix the problem. I'm
also going to be making a source upload soon. Please let me know if
this doesn't help.
I know, and I thought I send a mail
Simon Michael [EMAIL PROTECTED] writes:
I got this to install by downloading the latest libgmp3 and darcs debs
from packages.debian.org and installing them by hand. Is this a
dangerous thing to do ? It gives the appearance of working just fine.
This shouldn't cause any problem. You may be
Package: haskell-cabal
Severity: wishlist
Consider adding a --with-package-conf= flag to the configure command,
or the register command.
ALSO: make --user default when configure with --user?
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Kurt Roeckx [EMAIL PROTECTED] writes:
Hi,
Is there any progress on this? Is there a reason you didn't
switch to the new ghc6 6.4 yet?
Yes, the problem is that ghc 6.4 comes with Cabal, but it needs to be
removed for me to upload a new version of haskell-cabal, or
libghc6-cabal-dev will
Do you have other related environment variables set, such as VISUAL?
Did you see this section in the manual:
DARCS_EDITOR
When pulling up an editor (for example, when adding a long comment in
record), darcs uses the contents of DARCS_EDITOR if it is defined. If
not, it tries the contents of
I believe that GHC 6.4 should come with Cabal, but I'm not positive
about what Ian decided. Ian: Does it come with Cabal?
If so, packages which build-depend on Cabal should have bugs filed
against them, not against Cabal, for failing to build.
If not, I'll upload a new version of Cabal with a
Philipp Kern [EMAIL PROTECTED] writes:
Package: darcs
Version: 1.0.2-1
Severity: wishlist
Hi Isaac,
please update the darcs revision in Debian to the latest prerelease
source[1] as this fixes some issues and has some UI improvements I miss
when I work on my Debian packages. I saw that
Package: haskell-cabal
Severity: normal
Peter Simons reports:
I've run into a problem when trying to build a package with
Cabal using a different GHC version than the one found in
the $PATH. It looks like this:
$ runghc Setup.lhs configure --with-compiler=/opt/ghc/bin/ghc-6.2.2
Warning: No
Package: haskell-cabal
Severity: wishlist
It's been reported that there are packages with version numbers like
5.01 which will be parsed as 5.1 by cabal.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux
Package: haskell-cabal
Severity: wishlist
Cabal should generate ghci files at build time rather than using
ghc-pkg to do it during register. This will be better for systems
like Gentoo which don't like to have any files which are not managed
by the package. Here's a bash funciton to do this,
Isaac Jones [EMAIL PROTECTED] writes:
The right thing to do is probably to run ranlib upon installation, not
during linking. Will try to attack this before 1.1 release.
Arthur, I just added this to Cabal in CVS and Darcs. Can you please
check that out and see if it solves your problem
The right thing to do is probably to run ranlib upon installation, not
during linking. Will try to attack this before 1.1 release.
peace,
isaac
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: haskell-cabal
Severity: normal
From: Ashley Yakeley
Subject: Bug in Cabal creating user package.conf
I don't know if this has already been mentioned, but there's a bug in
Cabal which I noticed when I tried to configure a package:
$ runghc Setup.hs configure
...
configure:
There have been requests for more fine-tuned flags to haddock and to
various preprocessors. People aren't content with the default flags
:)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Jérémy Bobbio [EMAIL PROTECTED] writes:
Hello,
Attached is a test case for this bug.
Thanks for this!
I integrated this test case into my test suite, and fixed this bug. I
also added logic to remove the generated stub files while performing a
./setup clean.
You'll have to get the fix from
I was also unable to find any way to express that this library needs
to be linked with an OS threaded RTS. It might be a bit too
GHC-specific, but it would be great for HFuse.
I'm not sure what you mean by this; can you use ghc-options to do
this?
pax
--
To UNSUBSCRIBE, email to [EMAIL
Package: haskell-cabal
Severity: wishlist
From Niklas Broberg:
With ordinary configure scripts, you can finetune installation using
flags like --libdir, --bindir, --includedir etc. This doesn't seem to
work with Cabal just yet, but I don't think there are any reasons why
it shouldn't be
Package: haskell-cabal
Severity: wishlist
Several people have requested an uninstall target for cabal.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.21
Locale: LANG=C, LC_CTYPE=C
Package: haskell-cabal
Severity: normal
From: Ashley Yakeley:
I've just started using Cabal, for my time library implementation
(http://semantic.org/TimeLib/). I have some issues:
1. If I do runghc Setup.hs haddock and then runghc Setup.hs install,
the documentation doesn't appear to get
Package: haskell-cabal
Severity: normal
A bug report from: Niklas Broberg
I have a configure script that uses some custom --with-X flags. I now
want to access this script through Cabal. If I say
./configure --with-sessiondb-driver=PostgreSQL
the @DB_UPPER@ markers in my files get exchanged
Package: haskell-cabal
Severity: normal
Though there is a UserHook for it, there is no ./setup test command
to call this hook.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.21
Locale: LANG=C,
Package: libghc6-cabal-dev
Severity: normal
Problem reported by: Jérémy Bobbio [EMAIL PROTECTED]:
I might have hit a Cabal bug while attempting to cabalize HFuse. When
using``foreign import wrapper´´, GHC generates
ModuleName_stub.{h,c,o} files. These files are not handled at all by
Cabal
version information and exit
register.sh:
#!/bin/sh
echo 'name: Cabal
version: 0.5
license: BSD3
copyright: 2003-2005, Isaac Jones
maintainer: Isaac Jones [EMAIL PROTECTED
Ian Lynagh [EMAIL PROTECTED] writes:
Package: hugs
Version: 98.200503.08-1
Severity: normal
We're not sure the new hugs should go into sarge without matching new
ghc/nhc98 due to library changes. We also need to check these changes
don't cause any breakage elsewhere.
Just a note to
Thanks for the nice bug report.
It looks like you're probably using haskell-mode 2.0 (the packaged
version). Apparently there's a bug for xemacs in lhs mode. It works
fine in gnu emacs. I don't think this is related to the warning you
get.
The message about turn-on-haskell-font-lock is just a
I would be happy to sponsor someone taking over this package! I will
sing your praises if you get it into sarge.
I don't know much about latex, but I have a package that depends on
this package, and I can see a number of the problems with it, so I can
check that they're fixed. Let me know :)
91 matches
Mail list logo
