Bug#659081: Taking binary from hackage or GHC?

[Ian Lynagh]

On Wed, Feb 08, 2012 at 11:24:00AM +0100, Joachim Breitner wrote:
> 
> GHC 7.4.1 started to ship and expose the binary library, version
> 0.5.0.3. On hackage is binary-0.5.1.0.

Actually, 7.4.1 comes with 0.5.1.0. The release notes have the wrong
version number, unfortunately.

>  * Use the version provided by GHC and drop the independent binary
> package (as we have done with random, for example).

I would recommend this option.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#616494: git-annex: FTBFS on various archs: undefined reference to symbol 'sem_close@@GLIBC_…'

[Ian Lynagh]

On Tue, Mar 08, 2011 at 01:58:40PM +, Iain Lane wrote:
> On Tue, Mar 08, 2011 at 06:56:03PM +0530, Joachim Breitner wrote:
> >Hi,
> >
> >Am Dienstag, den 08.03.2011, 18:44 +0530 schrieb Joachim Breitner:
> >>But with kfreebsd-amd64, we have one successful and one failing build on
> >>the same machine, fano:
> >>https://buildd.debian.org/fetch.cgi?pkg=ghc;ver=7.0.2-1;arch=kfreebsd-amd64;stamp=1299357096
> >>https://buildd.debian.org/fetch.cgi?pkg=ghc;ver=7.0.2-2;arch=kfreebsd-amd64;stamp=1299584180

The first (successful) build says:

checking for library containing sem_close... none required

> And as the failures come when building the in-tree ghc-pwd copy, it
> looks like we have a misbuild. This is what my explicit -optl-pthread
> hack was to get around — so the ghc-pwd build links correctly.
> 
> I've added Ian (Lynagh) to cc. Ian, do you have any insight here? Do
> we need to add AC_SEARCH_LIBS checks for all sem_* functions to
> libraries/unix/configure.ac? And what about my hacks to explicitly
> link with pthread to bootstrap? (See debian bug #616494 for the
> history).
> 
> I guess as a last resort, we can disable the new
> --no-add-needed/--no-copy-dt-needed-entries stuff in our ghc build.

My guess is that if you don't have the stricter behaviour introduced by
http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html
then the build will go through and detect that no library is needed, but
if you then try to use the binary on a machine that does have the
stricter behaviour then the compiler won't be able to link anything
using unix.

So using your hack to get GHC built with the strictly-behaving linker on
all platforms should bootstrap the solution, and once all buildds have
the strict behaviour the hack won't be needed any more.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#346248: make: 3.80+3.81.b4-1 much slower than 3.80-9 in some situations

[Ian Lynagh]

On Tue, Feb 15, 2011 at 12:54:49AM -0600, Jonathan Nieder wrote:
> 
> Ian Lynagh wrote:
> 
> > With the attached Makefile, make 3.80+3.81.b4-1 is much slower than
> > 3.80-9 at running "make -wr stage1/ghc-6.4.1" (only a few seconds in the
> > cutdown case, but more in the real thing - I never waited for it to
> > terminate to know how much more).
> 
> Just because I'm curious: did ghc ever learn to work around this?

Yes:

Mon Feb 27 10:59:39 GMT 2006  Simon Marlow 
  * remove empty .SECONDARY target
  
  This works around a problem with recent versions of GNU make that take
  a long time when all targets are declared intermediate with
  .SECONDARY.  See 
  
https://savannah.gnu.org/bugs/?func=detailitem&item_id=15584
  
  for discussion of the GNU make issue.

-
-# This line prevents GNU make from deleting any intermediate targets:
-
-.SECONDARY:



Thanks
Ian




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#592548: rubber-info gives "IndexError: list index out of range"

[Ian Lynagh]

Package: rubber
Version: 1.1-2.2
Severity: normal


$ rubber -p foo.tex
compiling foo.tex...
compiling foo.tex...
running dvips on foo.dvi...
$ rubber-info foo
Traceback (most recent call last):
  File "/usr/bin/rubber-info", line 9, in 
Main()(sys.argv[1:])
  File "/usr/share/rubber/rubber/cmd_info.py", line 206, in __call__
self.main(cmdline)
  File "/usr/share/rubber/rubber/cmd_info.py", line 132, in main
return self.info_log(self.act)
  File "/usr/share/rubber/rubber/cmd_info.py", line 178, in info_log
if msg.display_all(log.get_errors()): return 0
  File "/usr/share/rubber/rubber/__init__.py", line 136, in display_all
for msg in generator:
  File "/usr/share/rubber/rubber/rules/latex/__init__.py", line 416, in parse
last_file = self.update_file(line, pos, last_file)
  File "/usr/share/rubber/rubber/rules/latex/__init__.py", line 444, in 
update_file
last = stack[-1]
IndexError: list index out of range
$ 

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages rubber depends on:
ii  python  2.5.2-3  An interactive high-level object-o
ii  python-support  0.8.4lenny1  automated rebuilding support for P
ii  texlive-latex-base  2007.dfsg.2-1~lenny2 TeX Live: Basic LaTeX packages

rubber recommends no packages.

Versions of packages rubber suggests:
ii  imagemagick 7:6.3.7.9.dfsg2-1~lenny3 image manipulation programs
pn  sam2p  (no description available)
ii  transfig1:3.2.5-rel-3.1  Utilities for converting XFig figu

-- no debconf information
\documentclass[a4paper]{article}

\usepackage{color}
\usepackage{framed}
\definecolor{shadecolor}{rgb}{0.7,1,0.7}

\newcommand{\z}{\hspace*{\fill}\setlength\parskip{0pt}\par}

\setlength{\overfullrule}{2pt}
\showboxdepth=3\showboxbreadth=99

\begin{document}

\title{XXX}
\author{XXX}
\maketitle

\tableofcontents

\begin{shaded}
\z

xx x x x xx xxx  xxx xx xxx x xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

xxx\z

x xx x xx xx xxx,\z

x xx x xx xx xxx,\z

xx, xx xx, xx x\z

xx, xx xx, xx x\z

xx, xx xx, xx;\z
\z

xx x x x xx xxx  xx xx xxx x xxx\z

xx x xx x xx\z

xx x xx xx xxx\z

xx x xx xxx \z

xx x xx xx xxx\z

xx x xx x xx\z

xx x xx x xx\z

xx x xx xx xxx\z

xx x xx xxx \z

xx x xx xx xxx,\z

xx, xx xx, xx\z

x xx, xx xx, xx\z

x xx, xx xx, xx\z

x x xxx x xxx,\z

x xx x xx xx xxx,\z

x xx x xx xxx ,\z

x xx x xx xx xxx,\z

xx, xx xx, xx x\z

xx, xx xx, xx x\z

xx, xx xx, xx\z
x\z
 x x , x xx , xx x xx  x x xx \z
 xx xx xx xxx x xxx\z

\z

x x x xx x \z

x x xx\z

xx \z

xxx x   xx;\z

xx x xx\z

\z

xx\z

x\z

x xx x x x\z

x xxx x xxx\z

x x \z

x  x xx\z

x x xxx xx x \z

xx \z

\z

xx x  x ;\z

xxx x x xxx x x ;\z

xx x xx\z

\z

x x x x\z

x\z

x  xx x xx\z

x xx x \z

x x xx\z

x \z

xx xxx x x xx x x  xx x,\z

 x  xx \z

x  x x x xxx x xxx\z

xx x x\z

xx x xxx xx x \z

xxx x  x xxx xx xxx\z

xxx x xx   xx xx,\z

 x  xx x\z
 x xxx x  xx x\z
 x  x  x xxx xx  xxx\z
 xx xx xx x x x x\z

xxx x xx, x xxx\z
 xx xx  x\z

xxx xxx\z

xxx xx  x x x\z

 x xx xxx x xxx\z

 x x x\z

xxx x   xx\z

x x  xx \z

xxx x xx  xx\z

xxx x  x  xx x\z

x  x x xxx x\z

xx x xx \z

x  x xxx $\Rightarrow$  x xxx \z

\z
 xxx\z
\z

 xxx xx \z

x x xxx xx x\z

xxx\z
 xx xx \z
x x xxx xxx\z
x\z
\z
 xxx\z
x \z
x x\z
\z
 xxx\z
x

Bug#469801: Up for adoption?

[Ian Lynagh]

On Sat, Jul 11, 2009 at 04:45:29PM +1000, Erik de Castro Lopo wrote:
> Ian,
> 
> I heard on the debian-haskell mailing list that this is up for adoption.
> 
> Is that so?

Yes.

> If it is, I'd be happy to adopt it, bring it up to date and
> add a man page.

Great; please adopt away.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#464364: [Debian-haskell] How to get haddock 2 into Debian

[Ian Lynagh]

On Sun, Oct 05, 2008 at 02:01:39AM +0200, Joachim Breitner wrote:
> 
> I’d like to bring up
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464364
> again, because haddock 2 has some features I’d really like to see.

GHC 6.10 will include haddock 2.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#464364: haddock 2

[Ian Lynagh]

This looks like it isn't as simple as I'd assumed:

http://www.haskell.org/pipermail/cvs-ghc/2008-June/042779.html

It sounds like currently it would need the haddock source to be put into
the ghc6 package, and the two built together.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483178: please include libsrc in ghc6-doc

[Ian Lynagh]

On Wed, May 28, 2008 at 06:58:06PM +0200, Peter Berry wrote:
> 
> Though it does beg the question of why there was a ghc6-libsrc package
> in the first place.

It was added by a previous maintainer, and at a time when the source
wasn't in the documentation.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483178: please include libsrc in ghc6-doc

[Ian Lynagh]

On Tue, May 27, 2008 at 06:40:20PM +0200, Stefan Potyra wrote:
> Package: ghc6-doc
> 
> (forwarding  to you), summary:

Thanks for forwarding it, Stefan.

> while ghc6-doc provides html pages showing the library sources, it would be
> nice if it could also ship the plain source files which used to be found in 
> ghc6-libsrc. That way the source files could be browsed with a text editor and
> not just via the browser.

Personally I think that the HTMLised sources in the documentation plus
"apt-get source" is enough.

I also don't see why it makes sense to do this for the libraries that
happen to need to come in the ghc6 packages, but not all the other
libraries; e.g. I think the source for mtl is at least as likely to be
wanted as the source for process. But putting a copy of the whole source
package in one of the binary packages feels wrong to me.

Any other opinions?


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#481556: ghc6: fails to create symlink

[Ian Lynagh]

On Sat, May 17, 2008 at 01:45:52AM +0200, Jochem Berndsen wrote:
> 
> The ghc6 package does not create a symlink of /usr/bin/ghc-pkg to
> ghc-pkg6,

Hmm, it should do. Can you tell me what

update-alternatives --display ghc

says please? And also

ls -l /usr/bin/ghc-pkg
ls -l /etc/alternatives/ghc-pkg

> Not sure if those libghc6-*-dev packages should be fixed or this one,
> though.

Packages should really be using ghc-pkg6, anyway.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#469852: Debian Bug #469852, lack of Xinerama support in libghc6-x11-dev

[Ian Lynagh]

On Tue, May 20, 2008 at 07:08:20PM +0200, Joachim Breitner wrote:
> 
> Am Dienstag, den 20.05.2008, 12:46 +0100 schrieb Ian Lynagh:
> > On Mon, May 19, 2008 at 04:03:43PM -0500, Spencer Janssen wrote:
> > > What is the status of bug #469852?
> > 
> > It is unlikely to be fixed before ghc6 and all the Haskell libraries
> > migrate to testing.
> 
> thanks for the input.
> 
> Once the ghc6 migration is done (hopefully soon), can we try to fix this
> bug right away afterwards, to maybe get the xinerama-aware haskell-x11,
> haskell-hgl, xmonad and xmonad-contrib in lenny as well? 

Of course.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#479209: ghc6: ghc --make Setup -o setup -package Cabal broken on powerpc

[Ian Lynagh]

On Sat, May 03, 2008 at 11:41:44AM +0200, Arjan Oosting wrote:
> 
> After your upload of GHC 6.8.2-5 the build daemon on powerpc tried to
> build a couple of packages of mine (haskell-hsql, haskell-uulib and 
> haxml) but failed to build them. In the logs I see the following happen:
> 
>  dh_testdir
>  ghc --make Setup -o setup -package Cabal 
>  ghc-6.8.2: timer_create: Invalid argument

I can't reproduce this in bruckner's unstable dchroot.

Does anyone know what's going on please?


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478705: ghc6: -fvia-C broken

[Ian Lynagh]

On Wed, Apr 30, 2008 at 08:38:37AM -0500, John Goerzen wrote:
> 
> When I try to build programs with -fvia-C, I get:
> 
> cc1: error: unrecognized command line option "-fno-toplevel-reorder"
> 
> gcc is 4.2.2-1 here.

Works for me:

$ gcc -fno-toplevel-reorder q.c 
$ gcc --version
gcc (GCC) 4.2.2 (Debian 4.2.2-1)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ ghc -fvia-C q.hs
$ dpkg -s ghc6 | grep "^Version"
Version: 6.8.2-2


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#470165: haskell-cgi control file comes with (perhaps) bogus versions on its build dependencies

[Ian Lynagh]

Hi David,

On Sun, Mar 09, 2008 at 09:11:07AM -0700, David Fox wrote:
> 
> The new haskell-utils 1.11 does a good job of determining what
> versions of the library packages to create dependencies on, but the
> control file that
> results when building haskell-cgi also has strict build dependencies
> on those packages.  This means that if you have slightly different
> versions of
> the packages, you can't build.

Please see
http://urchin.earth.li/pipermail/debian-haskell/2008-March/000386.html
for a discussion of why this is.

> Also, there should be a build
> dependency haskell-utils (>= 1.11).

Hmm, I don't think that's necessary, but I haven't actually tested it
with an older version. What goes wrong?

You will need 1.11 if you want to run
debian/rules update-generated-files
but that's not done when building.

(perhaps I should build-dep on 1.11 anyway, just to make it easier for
people who want to update-generated-files, though).


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#464364: New upstream version available

[Ian Lynagh]

On Wed, Feb 06, 2008 at 01:39:05PM +, Chris Lamb wrote:
> 
> The latest version of Haddock (2.0.0.0) was released on January 8th 2008.
> Hopefully it can uploaded soon.

I will be being cautious about moving to haddock 2 until it's more
widely used.

Everyone, please let me know if this causes a problem for you.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#461162: Please disable user installed packages while building

[Ian Lynagh]

Hi Joachim,

On Thu, Jan 17, 2008 at 01:13:59AM +0100, Joachim Breitner wrote:
> 
> I’ve stumbled a few times over failing builds because they were using
> some of my user-installed haskell packages that were of incompatible
> versions.
> 
> I’d suggest that the rules file should configure cabal (or something) so
> that it will not use user-installed packages, but only system-wide
> installed.

That should already be the case: we don't pass --user to
./setup-ghc configure
so user-installed packages shouldn't be used. Can you give me
instructions to reproduce the problem, please (preferrably with a
single small package).


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#465058: Please provide accurate repacking information

[Ian Lynagh]

Hi Chris,

On Sun, Feb 10, 2008 at 12:41:47PM +, Chris Lamb wrote:
>
> Version: 6.8.2-1
> 
> Would it be possible for debian/copyright to describe which parts of the
> upstream tarball that have been removed?
> 
> This file currently claims that this package is based on [0]
> 
> [0] http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2

The problem is that this URL is wrong; for the 6.8.2 packages it should
be:
http://www.haskell.org/ghc/dist/6.8.2/ghc-6.8.2-src.tar.bz2
No files have been removed from the tarball.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#454440: NMU done

[Ian Lynagh]

Hi Joachim,

On Mon, Feb 04, 2008 at 05:24:08PM +0100, Joachim Breitner wrote:
> 
> I am doing an NMU upload of version 1.4.1

libghc6-x11-dev is just one small piece of a much larger, more
complicated system, and it is necessary to consider the whole system
when making changes to part of it.

I apologise if I am doing you a disservice here, but based on what I've
seen you say you don't seem to have realised that your original proposed
upload would have conflicted with the 1.3.0-1 package that I was testing
while getting 2 dozen packages all working together correctly for the
GHC 6.8.2 update.

Nor do you seem to have realised that your current NMU will break
libghc6-hgl-dev 3.2.0.0-1 - or at least I haven't seen any indication
that you plan to fix it. I'm not sure if there are any other issues to
consider; thinking about that is part of the reason updating packages is
not trivial.

> I think our users have waited long enough.

I think users using unstable, and even testing, ought to be able to
install the packages from your homepage if they are desperate for the
latest and greatest. The primary purpose of testing/unstable is to
prepare the packages for the next release. I'm sure we will get
everything sorted out in plenty of time for the next stable release.

I know that, due to other things going on in my life recently, I haven't
been able to spend as much time as I'd like on Debian packaging;
however, by doing random uploads, seemingly without considering all the
consequences, you are just making it harder for me to make sure that
everything gets done and everything works.

> I hope there is no bad personal reason for the delay of your work.

Thank you; there is not.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#460385: Splitter bug

[Ian Lynagh]

Thanks for the report; I can see what the problem is and should have a
fix uploaded soon.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457086: --enable-split-objs not always good

[Ian Lynagh]

Hi Joachim,

On Wed, Dec 19, 2007 at 06:10:59PM +0100, Joachim Breitner wrote:
> 
> your rules files use --enable-split-objs for all packages when on i386.
> Some packages[1] have problems building with that option,

Do you mean

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428060

? If so, it is a ghc6 bug and will be fixed in the 6.8.2 packages.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#454440: May I upload X11 1.4.1?

[Ian Lynagh]

Hi Joachim,

On Tue, Dec 25, 2007 at 08:04:56PM +0100, Joachim Breitner wrote:
> 
> the xmonad 0.5 packages are now pretty much finished, and I’m just
> waiting for the new version of X11 to appear in the archive. Do you mind
> if I NMU the new version?

Please do not.


Thanks
Ian




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#433001: libghc6-mtl-dev: package unusable; installation in wrong directories

[Ian Lynagh]

Hi Norman,

On Fri, Jul 13, 2007 at 03:48:37PM +0100, Norman Ramsey wrote:
> 
> This package installs files into the wrong directories.
> Most of what goes into /usr/lib/mtl-1.0.1/ghc-6.6.1 needs to go into
> /usr/lib/ghc-6.6.1/imports instead.  The .a file needs to go into 
> /usr/lib/ghc-6.6.1.

What exactly goes wrong?

The files are supposed to go into /usr/lib/mtl-1.0.1/ghc-6.6.1 and the
/usr/lib/libghc6-mtl-dev/register.sh script then contains things like

import-dirs: /usr/lib/mtl-1.0.1/ghc-6.6.1
library-dirs: /usr/lib/mtl-1.0.1/ghc-6.6.1

to tell GHC where they are.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419671: Fixed in upstream darcs repo

[Ian Lynagh]

This is fixed in the upstream darcs repo.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#431843: Reassigning to ghc6

[Ian Lynagh]

reassign 431843 washngo
thanks

Hi John,

On Sun, Aug 05, 2007 at 07:35:53AM -0500, John Goerzen wrote:
> On Sunday 05 August 2007 6:54:30 am Kurt Roeckx wrote:
> >
> > I can't reproduce this problem (on amd64) in either stable or unstable.
> 
> You won't be able to.  You'll only be able to reproduce it on platforms that 
> don't support ghci, such as alpha, powerpc, m68k, ertc.  On these platforms, 
> runhaskell is broken.  Instead of calling ghci, on those platforms, it 
> should use ghc to compile the program to a binary in a temporary location 
> and then call that.
> 
> > I also have to wonder which versions of ghc6 you think this bug applies
> > to, it currently doesn't have any version information.
> 
> All that have runhaskell, which would be all recent ones.

This is essentially a duplicate of #320335 which you reported.
In the short term at least, you will have to build washngo a different
way (e.g. compile Setup.lhs and run the binary).

If it is a standard Cabal library then you may find
http://urchin.earth.li/pipermail/debian-haskell/2007-June/000322.html
useful.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#436006: ghc6-doc: Missing links to library documentation

[Ian Lynagh]

Hi Dylan,

On Sat, Aug 04, 2007 at 10:43:28PM +0700, Dylan Thurston wrote:
> 
> The page file:///usr/share/doc/ghc6-doc/html/libraries/index.html used
> to have links to all of the various modules organized by hierarchy.
> This has now disappeared, and so it is difficult to navigate to the
> documentation to the individual modules.  Please bring back the
> hierarchical index.

It should still be there.
Did the package install cleanly?
Does running this as root make it reappear?:

cd /usr/share/doc/ghc6-doc/html/libraries
/usr/lib/ghc6-doc/gen_contents_index


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#426335: can not resolve names in .haddock files generated on other architectures

[Ian Lynagh]

[ from Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426335 ]

On Mon, May 28, 2007 at 03:29:14AM +0200, Arjan Oosting wrote:
> 
> I am updating my Debian packages and was trying to generate haddock
> documentation which links to haddock documentation of other packages.
> I have tried a couple of times with different options, --use-package,
> - --read-interface, but haddock keeps complaining that it can not
> resolve the names:
> 
> [...]
> 
> After some searching I think I have found the problem. The .haddock
> interface files which haddock generated are architecture dependent:
> 
> http://www.haskell.org/pipermail/haskell/2007-March/019196.html
> 
> The interface files in your packages are generated on amd64 while I
> build my packages on i386, hence I encounter problems.

OK, I've looked at an interface file generated for a trivial module on
amd64 and i386, and it looks like a simple word-size problem; one starts

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^DMain

and the other

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^DMain


The attached patch makes the Binary instance for Int always output
64 bits, which looks like it solves the problem. I can't see anything
else likely to cause problems at first glance.


Thanks
Ian


New patches:

[Store Int's as Int64's regardless of how wide Int is
Ian Lynagh <[EMAIL PROTECTED]>**20070528122649
 This is in order to make portable interface files
] {
hunk ./src/Binary.hs 439
-#if SIZEOF_HSINT == 4
-put_ bh i = put_ bh (fromIntegral i :: Int32)
-get  bh = do
-	x <- get bh
-	return $! (fromIntegral (x :: Int32))
-#elif SIZEOF_HSINT == 8
hunk ./src/Binary.hs 443
-#else
-#error "unsupported sizeof(HsInt)"
-#endif
}

Context:

[bug fix
Wolfgang Jeltsch <[EMAIL PROTECTED]>**20070419182340
 When Haddock was invoked with the --ignore-all-exports flag but the ignore-exports module attribute wasn't used, hyperlinks weren't created for non-exported names.
 
 This fix might not be as clean as one would wish (since --ignore-all-exports now results in ignore_all_exports = True *and* an additional OptIgnoreExports option for every module) but at least the bug seems to be resolved now.
] 
[URL expansion for %%, %L, %{LINE}
Roberto Zunino <[EMAIL PROTECTED]>**20070421023643] 
[Add a flag --allow-missing-html
Ian Lynagh <[EMAIL PROTECTED]>**20070307145955
 With this flag, haddock ignores whether or not the HTML directory of
 packages depended upon exists. We need this when haddocking groups of
 packages that aren't installed yet.
] 
[Add a --ghc-pkg flag
Ian Lynagh <[EMAIL PROTECTED]>**20070307144253] 
[added substitution %{FILE///c}
Conal Elliott <[EMAIL PROTECTED]>**20070214215400] 
[Do not create empty tables for data declarations which don't have any constructors, instances or comments. Gets better HTML 4.01 compliance
Neil Mitchell**20070206174912] 
[infix type op precedence tweak, ppHsNameAsVar 
Conal Elliott <[EMAIL PROTECTED]>**20070115171157] 
[tweaked tyvarop precedence
Conal Elliott <[EMAIL PROTECTED]>**20070110002300] 
[added infix type operators
Conal Elliott <[EMAIL PROTECTED]>**20070105172038] 
[Make the search box in a form so that enter does the default search
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**20070112125817] 
[Make the max number of results 75 instead of 50, to allow map searching in the base library to work
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**20070112122501] 
[Rewrite much of the index searching code, previously was too slow to execute on the base library with IE, the new version guarantees less than O(log n) operations be performed, where n is the number in the list (before was always O(n))
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**20070112121746] 
[Make the index be in case-insensitive alphabetic order
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007085143] 
[Change from tabs to spaces in the ppHtmlIndex function
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007082244] 
[Delete more stuff that is no longer required
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007082119] 
[Delete dead code, now there is only one index page
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007081746] 
[Add searching on the index page
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007070709] 
[Never do spliting index files into many
Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**2007054115] 
[add test for blank lines inside @...@ code block
Simon Marlow <[EMAIL PROTECTED]>**20070109131444] 
[allow blank lines inside a @...@ code block
Simon Marlow <[EMAIL PROTECTED]>**20070109131434] 
[Fix up a case of extra vertical space after a code block
Simon Marlo

Bug#420004: closed by Ian Lynagh <[EMAIL PROTECTED]> (Re: missing "ghc" symlinks to "ghc6")

[Ian Lynagh]

On Fri, May 11, 2007 at 03:14:33PM +0100, Frederik Eaton wrote:
> 
> # /usr/sbin/update-alternatives --display ghc
> ghc - status is manual.
>  link currently points to /usr/lib/ghc-6.4/bin/ghc

The alternatives system thinks you have manually set ghc to point to ghc
6.4. This is probably due to a bug in an older version of ghc6.

> Your suggestion 'update-alternatives --auto ghc' does work, however.

OK, so it sounds like you are now sorted.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#422705: ghc6: Please provide GHC 6.6.1

[Ian Lynagh]

On Mon, May 07, 2007 at 03:18:20PM -0400, Mark Carroll wrote:
> Package: ghc6
> Version: 6.6-3
> Severity: wishlist
> 
> Could we have ghc 6.6.1 provided somewhere?
> It fixes a few bugs. Thanks.

http://urchin.earth.li/pipermail/debian-haskell/2007-May/000313.html


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#417722: libreadline5: Type of rl_extend_line_buffer in documentation is incorrect

[Ian Lynagh]

Package: libreadline5
Version: 5.2-2
Severity: normal

The documentation claims

Function: int rl_extend_line_buffer (int len)

but readline.h has

extern void rl_extend_line_buffer PARAMS((int));

and utils.c has

void
rl_extend_line_buffer (len)
 int len;

i.e. it returns void, not int.


Thanks
Ian

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.14-2-amd64-k8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages libreadline5 depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libncurses5  5.5-2   Shared libraries for terminal hand
ii  readline-common  5.2-1   GNU readline and history libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408000: Bug #408000

[Ian Lynagh]

reassign 408000 hpodder
thanks

Hi John,

http://tunes.org/~nef/logs/haskell/06.12.08 is the log of the last time
you asked me about this. Grepping for CosmicRay should give most, if not
all, of the relevant lines and little else.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404350: libghc6-glut-dev: ghc -package GLUT should imply -lglut

[Ian Lynagh]

On Mon, Dec 25, 2006 at 12:26:02AM +0100, Arjan Oosting wrote:
> 
> I have tracked them down and I am going to upload a NMU in a moment.
> Attached is the interdiff. 

Fantastic, thanks!

> Greetings and a Merry Christmas,

And to you!


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404350: libghc6-glut-dev: ghc -package GLUT should imply -lglut

[Ian Lynagh]

On Sat, Dec 23, 2006 at 08:05:50PM +0100, Arjan Oosting wrote:
> 
> When compiled with ghc -package GLUT -lglut tut.hs it works fine. When
> the ghc is called with -package GLUT it should imply -lglut.

We should get

ld-options: -lglut -lSM -lICE -lXmu -lXi -lGLU -lGL -lm

in /usr/lib/libghc6-glut-dev/register.sh but I only get it when building
in a chroot, not when building with pbuilder. I suspect there's a
missing build-dep. If anyone tracks it down, feel free to NMU.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403842: MkProg: hmake: the compiler 'ghc' is not known.

[Ian Lynagh]

severity 403842 normal
thanks

On Tue, Dec 19, 2006 at 06:24:29PM -0600, JP Sugarbroad wrote:
> 
> % hmake -ghc test.hs
> MkProg: hmake: the compiler 'ghc' is not known.

You can use

hmake -hc=ghc6 test.hs

or, after running the following:

hmake-config new
hmake-config add ghc

or just (as root):

hmake-config /var/lib/hmake/debian/hmakerc add ghc

your command

hmake -ghc test.hs

will also work.


I think to have -ghc work out of the box the right thing might be to
have a ghc package. I will think about this more, but it isn't going to
happen for etch.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403270: Can't step into libc functions with libc6-dbg

[Ian Lynagh]

Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal


Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):

 I have the impression that I should be able to use gdb to step 
  into libc functions if I set LD_LIBRARY_PATH to /usr/lib/debug, but 
  it doesn't seem to work (for vfprintf, for example) (on amd64)
 it appears to be lacking line number info.
 probably it's built with -g1... I remember a couple platforms 
  did that to work around old gcc bugs
 "vfprintf" itself is not interesting, because it's an alias, not 
  a real function; if you step into it, you'll end up in _IO_vfprintf.
 yep, that's what happened.  poke debian-glibc or file a bug 
  report about that.
 Thanks for looking into it - is it OK to copy/paste the above 
  into the report?
 sure


Thanks
Ian

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.14-2-amd64-k8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages libc6-dbg depends on:
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330924: Some more info

[Ian Lynagh]

Hi John,

On Fri, Sep 30, 2005 at 03:32:30PM -0500, John Goerzen wrote:
> 
> I am also seeing a lot of this:
> 
>   Program error: : IO.getContents: protocol error (invalid
>   character encoding)

Do you have a way to reproduce this, either with 0.7 or 0.8?

Also, what arch are you using?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342227: sparc built unregisterised

[Ian Lynagh]

Version: 6.4.1-2

Sparc started being built unregisterised in 6.4.1-2, fixing this
problem.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384514: ghc6 fixed on alpha

[Ian Lynagh]

Version: 6.6-1

6.6-1 successfully built 6.6-2.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393582: diff.gz for new upstream

[Ian Lynagh]

Hi Arjan,

On Wed, Oct 18, 2006 at 02:55:45PM +0200, Arjan Oosting wrote:
> 
> I have prepared a diff.gz for the new upstream release.

Thanks, I'll take a look.

> I could not test the build with GHC 6.6 yet as libghc6-readline-dev is
> not available yet.

It should be provided by ghc6 - please let me know if it's not for some
reason!

Don't worry about testing the build, though.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393731: Please include the mtl package

[Ian Lynagh]

On Tue, Oct 17, 2006 at 12:07:43PM -0400, Bryan Donlan wrote:
> 
> ghc6 6.6-1 no longer includes the mtl package:

It is now packaged separately as libghc6-mtl-dev, and I've just uploaded
it. It'll have to be manually processed out of the NEW queue as it is a
new package, though.

I'll leave this bug here for information until the packages hit the
archive.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384514: Progress

[Ian Lynagh]

I have a patched 6.6 RC that seems to work, albeit currently overly
cautious (and hence slower than necessary).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#388275: Please include monad transformer library (mtl)

[Ian Lynagh]

Hi Emilio,

On Tue, Sep 19, 2006 at 04:15:02PM +0200, Emilio Gallego wrote:
> 
> I'm glad to see ghc-cvs updated again, thank you very much! But
> I've been testing my Haskell programs against it,

Thanks for doing the testing!

> I'm aware that beginning with ghc 6.6, lots of extra libs won't be
> included, but I didn't tought that mtl was going to be split too. So
> it'd be very useful either to reinclude mtl or provide a separate
> package for it.

For ghc6 there will certainly be a libghc6-mtl-dev package (and for a
number of other extralibs packages too), but I'm not sure what to do
about ghc-cvs and extralibs yet.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389828: Please include the mk/ files in ghc6

[Ian Lynagh]

On Wed, Sep 27, 2006 at 04:28:37PM -0700, David Fox wrote:
> 
> It is very helpful to have the configured versions of the files in mk 
> for building some external libraries.

Do you have any examples of libraries that need this, and what they need
it for?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369947: Concern about this

[Ian Lynagh]

On Tue, Jun 13, 2006 at 10:04:29AM -0500, John Goerzen wrote:
> 
> Are you going to upload it any time soon?

Yes (possibly this weekend, but that might well turn out to be
infeasible).


Thanks
Ian, with a strong sense of deja vu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#365497: ghc6: Ghci crash on PowerPC

[Ian Lynagh]

Hi Dieter,

On Sun, Apr 30, 2006 at 03:48:23PM +0200, Dieter Schuster wrote:
> 
> If I have the following file, then gchi-6.4.1 will crash on PowerPC if
> I try to create a Object of type Test.
> 
> --
> module Bug where
> 
> data Test = Const Integer deriving (Show)
> --
> 
> The output of ghci-6.4.1:
> --
> Loading package base-1.0 ... linking ... done.
> Compiling Bug  ( 6.4.1-bug.hs, interpreted )
> Ok, modules loaded: Bug.
> *Bug> Const 1
> Segmentation fault
> --
> 
> This bug will not appeary with the version 6.4.2 of ghc, so please
> update to this version.

This sounds like http://hackage.haskell.org/trac/ghc/ticket/631 which I
don't believe is fixed in 6.4.2. My current plan is for ppc to not
include ghci because of this issue.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334156: NMU of hat

[Ian Lynagh]

Hi Arjan,

On Tue, Apr 18, 2006 at 04:41:20PM +0200, Arjan Oosting wrote:
> 
> I am preparing an NMU of hat

My plan has been to file a bug requesting hat's removal. If you would
like to take over the package then please feel free, but an NMU would
probably be a waste of effort.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362654: [m68k] ghc6 ftbfs

[Ian Lynagh]

On Fri, Apr 14, 2006 at 03:23:31PM -0500, Stephen R Marenka wrote:
> 
> I'm willing to do a binNMU build of ghc6 with gcc-4.1 to ensure that
> works and to get us in sync.

Will future maintainer uploads then build OK on m68k, or will I need to
build-dep on and explicitly use gcc-4.1?

> However, I want to make sure that's okay with you

It is, but thanks for asking  :-)

> and that you don't have another upload planned any time soon
> (due to how long it takes to build on m68k).

What is "any time soon"? Upstream are promising 6.4.2 next week, so by
the time it's released, packaged, tested and I've checked through the
bug list I'm sure your build will have finished.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#360177: ghc6: FTBFS (ppc64): TOC section size exceeds 64k

[Ian Lynagh]

On Fri, Mar 31, 2006 at 09:15:20AM +0200, Andreas Jochens wrote:
> 
> On 06-Mar-31 00:15, John Goerzen wrote:
> > There may be better ways to do that -- perhaps -mminimal-toc for gcc?
> 
> Yes, something like this would be better. 

I've forwarded the suggestion to the Gentoo guys. However, in Debian ghc
on ppc64 will be unregisterised, and there are problems with ghci when
unregisterised: http://hackage.haskell.org/trac/ghc/ticket/631
so my plan is to have it disabled in 6.4.2 anyway.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#357941: ghc6: where is HaXml?

[Ian Lynagh]

On Mon, Mar 20, 2006 at 07:50:06AM -0500, Ian Zimmerman wrote:
> 
> The source for HaXml is in the corresponding ghc6-libsrc package,
> but imports are nowhere to be found.

HaXml is not built by the upstream GHC by default, and furthermore we
believe that, where possible, libraries in Debian should be in their own
package so that the same version is available for all Haskell
implementations. Unfortunately we don't currently have a HaXml package
in Debian, though.

However, this probably means I should not be putting the HaXml source in
the libsrc package; I'll try to address this in the next upload.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#356450: [EMAIL PROTECTED]: manpage for ghc]

[Ian Lynagh]

On Sun, Mar 12, 2006 at 04:06:08AM +0100, Jeroen van Wolffelaar wrote:
> Package: ghc6
> Severity: wishlist
> 
> - Forwarded message from Jeffrey Bolden <[EMAIL PROTECTED]> -
> 
> This came up in a websearch.  But there is a manpage for GHC you may  
> just want to forward this to whomever would be responsible for the bug:
> 
> http://linux.com.hk/penguin/man/1/ghc6.html

What is the bug here? The above page contains the manpage as generated
by the scripts originally written by Michael Weber for Debian, and the
latest packages still contains this manpage as far as I can see.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#354872: Not quite what I expected

[Ian Lynagh]

On Mon, Mar 06, 2006 at 07:16:27AM -0600, Taral wrote:
> I'm sorry, I must not have been clear. The problem here isn't that amd64
> wasn't registerised (that was already noted). It was that unregisterised
> build need to have the NCG disabled to prevent them having this same
> problem.
> 
> I'm sure it's just a small patch to the build.mk data, but I'm not
> familiar enough with ghc to make up a patch.

There are two entries in the changelog related to this bug:

   * On the list of arches we build registerised:
 * Add amd64. Closes: #354872.
 * Remove sparc (it has bitrotted).
 List now reads "i386 amd64".

and:

   * Add "GhcWithNativeCodeGen=NO" to mk/build.mk when we are building
 unregisterised.

I believe that either would fix the particular problem you had, and you
can make an argument for the "Closes: #354872." being attached to either
one. However, the important thing is that both have been done  :-)


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#348633: ghc6: effective FTBFS because of a bug in /usr/bin/make

[Ian Lynagh]

Hi Jurij,

On Mon, Feb 27, 2006 at 09:40:49AM -0800, Jurij Smakov wrote:
> 
> As it appears that upstream is reluctant to consider it a bug in make 
> (see 346248 for discussion), I started playing with ghc6 build system in 
> an attempt to come up with a workaround. I was able to build it in under 
> 3.5 hours on a 1.7GHz Pentium IV machine with the attached patch. For some 
> targets it takes forever for make to parse the dependency graph of a large 
> list of prerequisites, the patch just remakes these prerequisites one by 
> one in three bottleneck places.

Over the weekend I confirmed that removing the ".SECONDARY:" fixed the
problem, at the slight expense of make being less convenient while doing
development. I've checked it works OK on x86, and have left vore to
churn at it.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341797: ghc6 on sparc

[Ian Lynagh]

On Mon, Feb 20, 2006 at 12:15:55PM -0800, Jurij Smakov wrote:
> 
> So, it looks like there are more severe problems on sparc than the ones 
> you've mentioned.

I know ghc6 is broken on sparc, but when it is also unbuildable
/everywhere/ I can't fix it.

If it's important to you to do a binary-only upload just for sparc then
you'll have to install a working ghc (the last 6.4 probably works) and
make 3.80, then search for DEB_HOST_ARCH in debian/rules and remove
sparc from the list of arches (this is untested, but it's the most
likely solution to the problem).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341797: ghc6 on sparc

[Ian Lynagh]

Hi Jurij,

On Fri, Feb 17, 2006 at 11:49:32PM -0800, Jurij Smakov wrote:
> 
> There has been no improvement on ghc6 situation on sparc since December. 
> At the moment about 20 packages FTBFS there due to the fact that ghc6 is 
> unusable. It would be great if you could do something about it, or give 
> some directions on what needs to be done to get ghc6 fixed. Please let me 
> know if you need anything tested.

ghc6 has been unbuildable since November due to first xmltex being
broken[1], and then problems with make[2]. It looks like the make
problem won't be fixed for the next release, so will have to be worked
around in GHC; hopefully we'll have a workaround soon and I can try to
get ghc6 on sparc fixed.


Thanks
Ian

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338327
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346248



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350443: randomRs eats unbounded heap space

[Ian Lynagh]

On Sun, Jan 29, 2006 at 09:59:44AM -0800, Daniel Burrows wrote:
> 
>   I was writing a program that needed large quantities of random numbers,
> and so I used randomRs to generate a stream that I could consume:
> 
> map (lineChars!) $ randomRs (bounds lineChars) g
> 
>   lineChars is of course an array that I'm pulling elements from.  Imagine
> my surprise when, within seconds of starting the compiled program, it had
> eating 80% of my virtual memory space!  After learning how to use the GHC
> heap profiler, I was able to trace my troubles to the above expression.
> On a whim, I replaced it with the following expression (which ought to be
> equivalent):
> 
> map (lineChars!) $ unfoldr (Just . randomR (bounds lineChars)) g
> 
>   As soon as I did so, the memory leak vanished.  I don't understand why
> randomRs is eating tons of heap here, but it seems pretty clear that it's
> the culprit.

It looks to me like it's building a value of type
StdGen -> somethingorother
and keeping it around in case randomLines is called again.

You can work around this, in this case at least, by not exporting
randomLines (e.g. change the first line to "module Main (main) where")
or not compiling this module with optimisation.

It looks fixed in the head (what will become 6.6), but I've forwarded it
upstream anyway in case the true problem is not fixed, or it hasn't been
fixed in the stable branch (what will be 6.4.2).


Incidentally, IMO your code would be much more maintainable if you used
something like

splits :: [Int] -> String -> [String]
splits (s:ss) xs = case splitAt s xs of
   (ys, zs) -> ys:splits ss zs
splits [] _ = [] -- Never actually happens in your case

splits splitPoints toSplit

rather than

map fst $ tail $ scanl (flip ($) . snd) ([], toSplit) $
  map splitAt splitPoints

although YMMV  :-)


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346248: /usr/bin/make's 11th hour

[Ian Lynagh]

On Thu, Jan 26, 2006 at 10:56:53AM -0500, Justin Pryzby wrote:
> 
> Ian is right, make has now been processing ghc6 for 11 hours
> (/tmp/buildd/ghc6-6.4.1/ghc/compiler).  Why did you say, that you
> think it eventually terminates?

Because the testcase I gave when reporting the bug terminates, and I
believe the problem is just a larger instance of that case.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#348633: make infinite loop (with some recursion??)

[Ian Lynagh]

On Wed, Jan 18, 2006 at 01:33:20AM -0500, Justin Pryzby wrote:
> 
> ghc6 compilation sends make into an infinite loop

This sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346248

I don't believe it's infinite, incidentally.

> This can run for many minutes..

For days, IME.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337603: Probable GHC bug

[Ian Lynagh]

tags 337603 +unreproducible

On raptor I get well past the failure the buildd saw, failing at the
install point the other arches failed at instead.

Can anyone reproduce this?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346248: make: 3.80+3.81.b4-1 much slower than 3.80-9 in some situations

[Ian Lynagh]

On Fri, Jan 06, 2006 at 04:43:37PM +, Ian Lynagh wrote:
> 
> With the attached Makefile, make 3.80+3.81.b4-1 is much slower than
> 3.80-9 at running "make -wr stage1/ghc-6.4.1" (only a few seconds in the
> cutdown case, but more in the real thing - I never waited for it to
> terminate to know how much more).

I've just tried the real thing, and it's still thinking after >24 hours
of CPU time, so this is effectively going to cause FTBFSs for me
(although technically I think it will eventually terminate).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337603: Probable GHC bug

[Ian Lynagh]

On Mon, Jan 02, 2006 at 06:26:16AM -0600, John Goerzen wrote:
> 
> The original bug appears to be limited to s390.  I see binary packages
> have been built for 8 platforms without trouble.  I believe the bug
> lies with GHC, so I am reassigning this bug to ghc6.

I'll try and have a look when DA have installed the build-deps on
raptor.


Incidentally, the

Build-Depends: [...], ghc6 (>= 6.4), ghc6 (<< 6.5), [...]

doesn't make sense. I recommend using update-haskell-control (from the
haskell-utils package) and the appropriate variables from
/usr/lib/haskell-utils/ghc6_vars to get the right build-deps (and deps).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346248: make: 3.80+3.81.b4-1 much slower than 3.80-9 in some situations

[Ian Lynagh]

Package: make
Version: 3.80-9
Severity: normal


With the attached Makefile, make 3.80+3.81.b4-1 is much slower than
3.80-9 at running "make -wr stage1/ghc-6.4.1" (only a few seconds in the
cutdown case, but more in the real thing - I never waited for it to
terminate to know how much more).


Thanks
Ian


$ dpkg -s make | grep Version
Version: 3.80+3.81.b4-1
$ time make -wr stage1/ghc-6.4.1 
make: Entering directory `/tmp/wibble'
Makefile:20: stage1/profiling/CostCentre.o stage1/profiling/SCCfinal.o 
stage1/main/Config.o
make: *** No rule to make target `profiling/CostCentre.lhs', needed by 
`stage1/profiling/CostCentre.o'.  Stop.
make: Leaving directory `/tmp/wibble'

real0m4.318s
user0m4.315s
sys 0m0.002s
$


$ dpkg -s make | grep Version
Version: 3.80-9
$ time make -wr stage1/ghc-6.4.1 
make: Entering directory `/tmp/wibble'
Makefile:20: stage1/profiling/CostCentre.o stage1/profiling/SCCfinal.o 
stage1/main/Config.o
make: *** No rule to make target `profiling/CostCentre.lhs', needed by 
`stage1/profiling/CostCentre.o'.  Stop.
make: Leaving directory `/tmp/wibble'

real0m0.008s
user0m0.006s
sys 0m0.003s
$

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.14-2-amd64-k8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages make depends on:
ii  libc6 2.3.5-8.1  GNU C Library: Shared libraries an

-- no debconf information

OBJS = stage1/profiling/CostCentre.o stage1/profiling/SCCfinal.o 
stage1/main/Config.o

CONFIG_HS   = Config.hs

$(CONFIG_HS) : Makefile
echo "module Config where" > $(CONFIG_HS)

.SECONDARY:

stage1/%.o : %.hs
:

stage1/%.o : %.lhs   
:

%.hi : %.o
:

$(warning $(OBJS))
stage1/ghc-6.4.1 :: $(OBJS)
echo Finished

#

stage1/utils/PrimPacked.o : utils/PrimPacked.lhs
stage1/utils/OrdList.o : utils/OrdList.lhs
stage1/utils/FastString.o : utils/FastString.lhs
stage1/utils/FastString.o : stage1/utils/PrimPacked.hi
stage1/utils/FastTypes.o : utils/FastTypes.lhs
stage1/utils/FastTypes.o : stage1/utils/FastString.hi
stage1/utils/Maybes.o : utils/Maybes.lhs
stage1/utils/Maybes.o : stage1/utils/FastString.hi
stage1/utils/Pretty.o : utils/Pretty.lhs
stage1/utils/Pretty.o : stage1/utils/PrimPacked.hi
stage1/utils/Pretty.o : stage1/utils/PrimPacked.hi
stage1/utils/Pretty.o : stage1/utils/FastString.hi
stage1/utils/Pretty.o : stage1/utils/FastString.hi
stage1/utils/FastMutInt.o : utils/FastMutInt.lhs
stage1/utils/BitSet.o : utils/BitSet.lhs
stage1/utils/BitSet.o : stage1/utils/FastString.hi
stage1/stranal/StrictAnal.o : stranal/StrictAnal.lhs
stage1/stranal/SaLib.o : stranal/SaLib.lhs
stage1/stranal/SaAbsInt.o : stranal/SaAbsInt.lhs
stage1/parser/ParserCoreUtils.o : parser/ParserCoreUtils.hs
stage1/parser/LexCore.o : parser/LexCore.hs
stage1/parser/LexCore.o : stage1/parser/ParserCoreUtils.hi
stage1/parser/Ctype.o : parser/Ctype.lhs
stage1/parser/Ctype.o : stage1/utils/FastString.hi
stage1/main/PackageConfig.o : main/PackageConfig.hs
stage1/main/PackageConfig.o : stage1/utils/FastString.hi
stage1/main/PackageConfig.o : stage1/utils/FastString.hi
stage1/main/Constants.o : main/Constants.lhs
stage1/main/Constants.o : stage1/utils/FastString.hi
stage1/main/Config.o : Config.hs
stage1/utils/Panic.o : utils/Panic.lhs
stage1/utils/Panic.o : stage1/utils/FastTypes.hi
stage1/utils/Panic.o : stage1/main/Config.hi
stage1/utils/Panic.o : stage1/utils/FastString.hi
stage1/simplCore/SAT.o : simplCore/SAT.lhs
stage1/simplCore/SAT.o : stage1/utils/Panic.hi
stage1/simplCore/SAT.o : stage1/utils/FastString.hi
stage1/simplCore/SATMonad.o : simplCore/SATMonad.lhs
stage1/simplCore/SATMonad.o : stage1/utils/Panic.hi
stage1/simplCore/SATMonad.o : stage1/utils/FastString.hi
stage1/utils/IOEnv.o : utils/IOEnv.hs
stage1/utils/IOEnv.o : stage1/utils/Panic.hi
stage1/utils/IOEnv.o : stage1/utils/FastString.hi
stage1/utils/StringBuffer.o : utils/StringBuffer.lhs
stage1/utils/StringBuffer.o : stage1/utils/Panic.hi
stage1/utils/StringBuffer.o : stage1/utils/FastString.hi
stage1/utils/StringBuffer.o : stage1/utils/FastString.hi
stage1/utils/UnicodeUtil.o : utils/UnicodeUtil.lhs
stage1/utils/UnicodeUtil.o : stage1/utils/Panic.hi
stage1/utils/UnicodeUtil.o : stage1/utils/FastString.hi
stage1/utils/Util.o : utils/Util.lhs
stage1/utils/Util.o : stage1/utils/FastTypes.hi
stage1/utils/Util.o : stage1/utils/Panic.hi
stage1/utils/Util.o : stage1/utils/FastString.hi
stage1/main/DriverUtil.o : main/DriverUtil.hs
stage1/main/DriverUtil.o : stage1/parser/Ctype.hi
stage1/main/DriverUtil.o : stage1/main/Config.hi
stage1/main/DriverUtil.o : stage1/utils/Panic.hi
stage1/main/DriverUtil.o : stage1/utils/Util.hi
stage1/main/DriverUtil.o : stage1/utils/FastString.hi
stage1/main/DriverPhases.o : main/DriverPhases.hs
stage1/main/DriverPhases.o : stage1/utils/Panic.hi
stage1/main/DriverPhases.o : stage1/main/D

Bug#341797: ghc6 on sparc

[Ian Lynagh]

Hi all,

These look like symptoms of bitrot in ghc6's registerised sparc support.
I'll make it unregisterised for the next ghc6 upload, but this won't
happen until I can install ghc6's build-deps again (#338327 / #340076).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337909: ghc6: regression in Cabal

[Ian Lynagh]

On Mon, Nov 07, 2005 at 09:19:41AM +0100, Matej Vela wrote:
> Package: ghc6
> Version: 6.4.1-1
> Severity: serious
> Justification: causes an FTBFS for haskelldb, washngo
> Tags: upstream patch

Thanks. I'll look into this once ghc6's build-depends are in order.


Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334110: ghc6 bootstrap status update.

[Ian Lynagh]

On Tue, Nov 01, 2005 at 12:50:57PM -0500, Nathanael Nerode wrote:
> Hello! It appears that ghc6 still needs bootstrapping on sparc and m68k.

AFAIK these have unrelated problems and all bootstrapping is done.

#33 looks like the bug to me.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328941: Fwd: [Re: pugs: FTBFS on 64 bit arches: internal error] [EMAIL PROTECTED]

[Ian Lynagh]

Hi Florian,

See forwarded e-mail.


Thanks
Ian

--- Begin Message ---
On Wed, Oct 19, 2005 at 06:22:35PM +0100, Ian Lynagh wrote:
> On Wed, Oct 19, 2005 at 07:13:25PM +0200, Kurt Roeckx wrote:
> > On Tue, Oct 18, 2005 at 12:47:36PM +0100, Ian Lynagh wrote:
> > > On Sun, Sep 18, 2005 at 12:35:31PM +0200, Kurt Roeckx wrote:
> > > > Package: pugs
> > > > Version: 6.2.9-1
> > > > Severity: important
> > > > 
> > > > Your package is failing to build on 64 bit arches with the
> > > > following error:
> > > > Triggering rebuild... done.
> > > > Generating precompiled Prelude... pugs: internal error: scavenge_one: 
> > > > strange o bject 68
> > > 
> > > Can you retry it with ghc 6.4.1-1 (built in unstable for most arches)
> > > please?
> > 
> > It seems to work now, atleast on amd64.
> 
> alpha/ia64 people, can you set pugs to needs-build please?

No.  The latest upload of pugs did not contain a dsc file.  Someone needs to
fix this, and then wanna-build will do as expected.
--- End Message ---

Bug#328941: pugs: FTBFS on 64 bit arches: internal error

[Ian Lynagh]

On Wed, Oct 19, 2005 at 07:13:25PM +0200, Kurt Roeckx wrote:
> On Tue, Oct 18, 2005 at 12:47:36PM +0100, Ian Lynagh wrote:
> > On Sun, Sep 18, 2005 at 12:35:31PM +0200, Kurt Roeckx wrote:
> > > Package: pugs
> > > Version: 6.2.9-1
> > > Severity: important
> > > 
> > > Your package is failing to build on 64 bit arches with the
> > > following error:
> > > Triggering rebuild... done.
> > > Generating precompiled Prelude... pugs: internal error: scavenge_one: 
> > > strange o bject 68
> > 
> > Can you retry it with ghc 6.4.1-1 (built in unstable for most arches)
> > please?
> 
> It seems to work now, atleast on amd64.

alpha/ia64 people, can you set pugs to needs-build please?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328941: pugs: FTBFS on 64 bit arches: internal error

[Ian Lynagh]

Hi Kurt,

On Sun, Sep 18, 2005 at 12:35:31PM +0200, Kurt Roeckx wrote:
> Package: pugs
> Version: 6.2.9-1
> Severity: important
> 
> Your package is failing to build on 64 bit arches with the
> following error:
> Triggering rebuild... done.
> Generating precompiled Prelude... pugs: internal error: scavenge_one: strange 
> o bject 68

Can you retry it with ghc 6.4.1-1 (built in unstable for most arches)
please?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#283981: Fixed in ghc6

[Ian Lynagh]

reassign 283981 alex, ghc-cvs, haddock
thanks

ghc6 removed: 6.4.1-1 built with gcc 4.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#331704: RM: nhc98 -- RoM

[Ian Lynagh]

Package: ftp.debian.org
Severity: normal

nhc98 can no longer cover the arches ghc doesn't build on, and hasn't
followed important development of the Haskell language.

Please remove it from unstable (all arches and source).

Brief discussion at:
http://urchin.earth.li/pipermail/debian-haskell/2005-September/000130.html


Thanks
Ian

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8.1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#331701: RM: ghc5 -- RoM; obsolete

[Ian Lynagh]

Package: ftp.debian.org
Severity: normal

ghc5 is uninstallable, obsolete and doesn't build with the current
toolchain. Please remove it (all arches and source).

Brief discussion at:
http://urchin.earth.li/pipermail/debian-haskell/2005-September/000124.html


Thanks
Ian

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8.1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#329322: ghc6: New upstream version

[Ian Lynagh]

On Wed, Sep 21, 2005 at 08:45:31AM +0200, Florian Ragwitz wrote:
> 
> ghc 6.4.1 has been released. Please update your package.

The current plan is to wait until the gmp transition has happened before
doing that.

In the mean time, there are source and binary packages in the i386
Haskell Unsafe repo should you want them:
http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327459: [xml/sgml-pkgs] xsltproc oddness

[Ian Lynagh]

On Mon, Sep 12, 2005 at 11:45:48AM +0200, Mike Hommey wrote:
> On which arch did you test that ?

x86.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327459: xsltproc oddness

[Ian Lynagh]

Just had a quick look at this.

This is reproducible for me (note the changing result):

$ dchroot
Executing shell in 'unstable' chroot.
$ xsltproc /html/docbook.xsl conftest.xml; echo $?
warning: failed to load external entity "/html/docbook.xsl"
cannot parse /html/docbook.xsl
0
$ xsltproc /html/docbook.xsl conftest.xml; echo $?
warning: failed to load external entity "/html/docbook.xsl"
cannot parse /html/docbook.xsl
4
$ xsltproc /html/docbook.xsl conftest.xml; echo $?
warning: failed to load external entity "/html/docbook.xsl"
cannot parse /html/docbook.xsl
4
$ 

and also reproducibly:

$ dchroot
Executing shell in 'unstable' chroot.
$ env
HZ=100
SHELL=/bin/bash
TERM=screen
USER=igloo
MAIL=/var/mail/igloo
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
PWD=/home/igloo
SHLVL=1
HOME=/home/igloo
LOGNAME=igloo
_=/usr/bin/env
$ xsltproc /html/docbook.xsl conftest.xml; echo $?
warning: failed to load external entity "/html/docbook.xsl"
cannot parse /html/docbook.xsl
4
$ xsltproc /html/docbook.xsl conftest.xml; echo $?
warning: failed to load external entity "/html/docbook.xsl"
cannot parse /html/docbook.xsl
4
$ 

This is with xsltproc 1.1.14-1; anyone got any idea what's going on?

I suspect this is related to why the automated builds are (mostly)
failing and the manual ones aren't.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299702: Hugs98-2005 should not go into sarge yet

[Ian Lynagh]

On Sat, Sep 03, 2005 at 02:30:31PM -0700, Isaac Jones wrote:
> 
>   So what needs to happen for the GHC
> bootstrapping is that a binary version of GHC needs to get uploaded to
> each platform?  I'm still wondering if Ian is planning to let it enter
> testing at that point.

If GHC 6.4.1 is released before 6.4 goes into testing I'll ask the
release team what they want me to do.

Reaching "that point" isn't just a matter of the remaining ghc6 uploads
incidentally; it also requires builds of libraries like missingh
happening and doing something with
libghc6-hunit-dev libghc6-cabal-dev hat-ghc6
(and possibly less obvious things that don't jump to mind immediately).

Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319222: ghc6: Depends on non-existing package

[Ian Lynagh]

Hi Kurt,

On Tue, Aug 30, 2005 at 01:04:22AM +0200, Kurt Roeckx wrote:
> 
> I would like to get a new version of ghc6 into unstable soon.
> I think it's best to build the current version with gcc 3.3.
> Upstream seem to be taking a while to get the new release out

Yeah; the release seemed imminent on the 11th, but this was shortly
followed by Mrs Upstream, with complete disregard for the release
schedule, giving birth.

I'm afraid I don't have a good estimated release date now, but I think
he'll be back at work soon.

Unfortunately at each stage I've been under the impression the release
will probably have happened before m68k has built everything, making
spending time on uploading a new 6.4 et al an unattractive proposition.

Believe me, I'm as frustrated by this as you. But at the same time, I
don't think Debian is in a position to throw stones regarding such
matters  :-)

> that should work with gcc 4.0, and I'm not really sure how stable
> that is going to be on all arches we have.  Looking at the
> changelog, it seems that it already had it share of problems with
> compiler versions.

*nod*; I've done prerelease builds on a couple of arches, so I'm hoping
that won't be a problem this time round.

> There are going to be some problems getting this build in any
> case.  ghc6 build-depends on itself, which currently means it
> depends on libgmp3, and that of course conflicts with
> libgmp3c2/libgmp3-dev.  This means someone will have to build all
> those things manually on all arches.
> 
> How to get around this and get a working version:
[...]

An alternative is to install everything but the Haskellish packages,
unpack the debs of the things you are missing and:

sed -i "s#/usr/#`pwd`/usr/#g" usr/bin/*
for p in usr/lib/ghc-*/package.conf.shipped
do sed -e "s#/usr/\(lib\|share\)/ghc#`pwd`&#g" \
   < "$p" > `echo "$p" | sed "s/\.shipped$//"`
done
for f in usr/bin/*6
do
ln -s `echo "$f" | sed "s#.*/##"` `echo "$f" | sed "s/6$//"`
done

and set PATH accordingly. This has the advantage (for me, at least) of
not needing twiddling as root.

> I'll can do an NMU of this if you want.

Please feel free.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319294: Internal compiler error: The impossible happened

[Ian Lynagh]

On Wed, Jul 20, 2005 at 04:52:13PM -0700, Daniel Burrows wrote:
> 
>   I was experimenting with writing a functional heap when I got the following 
> error from ghc:
> 
> ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
>   ds_app_type PriorityQueue.PriorityQueue{tc r1qv} [k{tv a1vx}]

With the current CVS GHC, either STABLE or HEAD branch, I get:

$ ghc -c PriorityQueue.hs

PriorityQueue.hs:16:4:
Class `PriorityQueue' used as a type
In the class declaration for `PriorityQueue'
$

so this will be fixed in the next upload.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#317069: ghc6-hopengl: Missing Several Depends

[Ian Lynagh]

On Tue, Jul 05, 2005 at 07:08:54PM -0500, Eric Etheridge wrote:
> 
> Then I searched for libsm.a in the debian packages, found that it was in 
> libsm-dev, and installed that:
> 
> I searched for libxmu.a, found it was in libxmu-dev, and installed that. 
> That was enough for successful compilation.

It looks like you are right, thanks. I'll try to look into this for my
next upload.

> A further test with an actual HOpenGL program successfully compiled at 
> that point, although I did get a message which I think is not related:
> 
> Xlib:  extension "XFree86-DRI" missing on display ":0.0".

I don't think this is related. It means you don't have DRI (Direct
Rendering Infrastructure) support. If your graphics card supports this
then setting it up would make rendering faster.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315003: libghc6-cabal-dev: Uninstallable; causes other packages to fail to build

[Ian Lynagh]

Package: libghc6-cabal-dev
Severity: grave
Justification: renders package unusable


libghc6-cabal-dev depends on ghc6 (<< 6.2.3), but 6.4-4 is currently in
unstable. Thus it is uninstallable.

This is causing other packages to fail to build, e.g.:

http://buildd.debian.org/fetch.php?&pkg=haskell-http&ver=0.4.20050430-1&arch=alpha&stamp=1119062164&file=log&as=raw

I think that under our current plan it should be removed, but if you
disagree then it at least needs to be updated.


Thanks
Ian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#311835: haskell-cabal: FTBFS: Can't satisfly build dependency on ghc6

[Ian Lynagh]

On Sun, Jun 05, 2005 at 10:30:24PM -0700, Isaac Jones wrote:
> 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?

All the latest versions of the implementations come with cabal (although
the nhc98 with cabal isn't yet uploaded pending the conclusion of the
discussion on the debian-haskell list).

> If so, packages which build-depend on Cabal should have bugs filed
> against them, not against Cabal, for failing to build.

The implementations should be providing what is necessary, e.g. ghc6
provides libghc6-cabal-dev. Something will still need to be done for any
packages using versioned build-deps, of course.

> If not, I'll upload a new version of Cabal with a fixed build-depends.

If you don't do an upload then you should file a removal request or
it'll hold everything out of testing.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309025: Bus error on hppa

[Ian Lynagh]

On Thu, May 19, 2005 at 04:01:04AM +0200, Arjan Oosting wrote:
> 
> Is this bug already coordinated with ghc upstream.

Yes. One problem is already found and fixed, but it looks like there is
at least one still to go...


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309025: ghc6: Crashes with bus error on hppa

[Ian Lynagh]

On Sat, May 14, 2005 at 08:21:45PM -0600, LaMont Jones wrote:
> On Sat, May 14, 2005 at 08:18:43PM -0600, LaMont Jones wrote:
> > > hppa people, any idea what's going on?
> > echo 1 > /proc/sys/kernel/unaligned-trap 
> > and try again.
> 
> Gah.  Let me try that again from the top.
> 
> echo 0 > /proc/sys/kernel/unaligned-trap
> 
> and you'll find that the unaligned load/store in ghc causes the bus
> error.

Can someone please make paer and sarti agree on the value, so either the
build works or I can debug it?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309025: ghc6: Crashes with bus error on hppa

[Ian Lynagh]

tags 309025 +unreproducible
thanks

On Fri, May 13, 2005 at 03:44:02PM -0500, John Goerzen wrote:
> Package: ghc6
> Version: 6.4-3
> Severity: important
> Tags: sid
> 
> >>From the build log at
> http://buildd.debian.org/fetch.php?&pkg=missingh&ver=0.11.0&arch=hppa&stamp=1115974118&file=log&as=raw
> 
> make setup
> make[1]: Entering directory `/build/buildd/missingh-0.11.0'
> ghc -package Cabal Setup.lhs -o setup
> make[1]: *** [setup] Bus error

Works for me on paer:

[...]
make setup
make[1]: Entering directory `/home/igloo/qqq/missingh-0.11.0'
ghc -package Cabal Setup.lhs -o setup
make[1]: Leaving directory `/home/igloo/qqq/missingh-0.11.0'
./setup configure --prefix= --ghc
Warning: No license-file field.
Configuring MissingH-0.11.0...
configure: searching for ghc in path.
[...]
dpkg-deb: building package `libghc6-missingh-dev' in 
`../libghc6-missingh-dev_0.11.0_hppa.deb'.
 dpkg-genchanges
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload; Debian-native package (full source is included)


hppa people, any idea what's going on?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299702: Hugs98-2005 shouldn't go into sarge yet

[Ian Lynagh]

On Wed, Apr 20, 2005 at 02:47:05AM +0100, [EMAIL PROTECTED] wrote:
> Thanks for the patient explanation.  I know it's too late, but ...
> 
> > The locale based filename thing in hugs is also a concern, though, in my
> > opinion. Currently two packages build-depend on hugs: haskell-utils and
> > cpphs. I think haskell-utils currently only uses filenames containing
> > a-zA-Z0-9./_ so we could wrap that in a script that sets the locale to C
> > (or maybe do that at the start of main?).
> 
> That shouldn't be necessary -- all the locales in Debian agree with C
> on ASCII-only text.

Ah, that would be convenient. I've just done a quick test and they all
seem OK except vi_VN.TCVN (both with latest CVS and the release):

---
$ export HUGSDIR=hugsdir
$ LC_ALL=vi_VN.TCVN src/hugs
__   __ __  __     ___  _
||   || ||  || ||  || ||__  Hugs 98: Based on the Haskell 98 standard
||___|| ||__|| ||__||  __|| Copyright (c) 1994-2005
||---|| ___||   World Wide Web: http://haskell.org/hugs
||   || Report bugs to: hugs-bugs@haskell.org
||   || Version: 20050421   _

Haskell 98 mode: Restart with command line option -98 to enable extensions

ERROR "hugsdir/libraries/Hugs/Prelude.hs":1 - Unrecognised character `\0' in 
column 1

FATAL ERROR: Unable to load Prelude
$ 
---

> > cpphs currently accepts 8-bit
> > chars in filenames being #included, as does cpp; maybe you will argue
> > that making use of that is foolish, but nevertheless I think I would
> > rather drop the ability to "compile" with hugs in order to keep its
> > behaviour consistent.
> 
> Do you mean #include's in the source file, which is read in text mode?

It is currently, but with new hugs I think it should really be being
read in binary mode and cpphs then do its own line ending magic.

Reading in binary mode doesn't fix the filename issue AFAICS, though;
with:

main = do h <- openBinaryFile "w" ReadMode
  s <- hGetLine h
  removeDirectory s

I get:

19704 read(3, "Foo\302\243bar\n\n", 4096) = 10
19704 rmdir("Foo??bar") = -1 ENOENT (No such file or directory)

> > We'll also have to go over any packages that stay using hugs to make
> > sure they are opening files in binary mode when appropriate etc. (In
> > principle this should be done regardless, but within the systems Debian
> > currently supports it's not been an issue thus far).
> 
> Hugs is Suggest'ed by ctklight, haskell-mode, haskell-utils and
> haskell-doc.  Presumably ctklight is in the same boat as cpphs.

Hmm, thanks. Given it's only a suggests I imagine it's only generated
code that actually uses hugs, although it seems odd it doesn't also
suggest ghc[56]. Looks like something for us to check out, anyway  :-)

> It's a tradeoff, I just don't think it's a grave bug.

The severity of Debian bug 299702 is just the mechanism used to keep the
package out of testing.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299702: Hugs98-2005 shouldn't go into sarge yet

[Ian Lynagh]

On Tue, Apr 19, 2005 at 11:12:55AM +0100, Ross Paterson wrote:
> Ian Lynagh <[EMAIL PROTECTED]> writes:
> > 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.
> 
> What incompatibilities with GHC 6.2 and nhc98 1.16 have you discovered
> that weren't present in 200311?  I know of:
> 
> Library changes (also present in GHC 6.4 and nhc98 1.18):
> * instance Integral CTime removed (#299568):
>   avoid fromIntegral on this type.
> * Show andFunctor instances added for FiniteMap:
>   can be worked around using cpp.
> * System.IO no longer re-exports System.IO.Error:
>   need to tweak imports a little.
> 
> Hugs only:
> * locale-based encoding of character I/O (#299570):
>   use binary I/O for binary data.
> * locale-based encoding of filenames and environment variables in H98 libs:
>   a loss when these are binary or in an unknown encoding,
>   but a gain for users who use their locale's encoding
>   (and H98 specifies these as String, not [Word8]).

Given you suggest workarounds I'm going to assume this really means "why
isn't the new hugs in sarge?" and answer accordingly, but FWIW I don't
remember anything not on your lists above.

First a bit of context: When I opened this bug we'd just had the
announcement from the release team that the infrastructure holding up
the release process "will be fully operational in the space of two
weeks", along with a request to avoid uploads of new upstream versions
of software; this is even more important in things like libraries and
compilers as regressions can affect other packages too.

We also had concensus that it was better to ship consistent libraries
with each of the implementations, so sarge would at least be consistent
with itself even if not the state of the art (and given the state of the
art is likely to have additional differences over sarge's lifespan,
keeping it compatible is an impossible task).

We could have tried to get all the new versions in, together with hmake,
darcs and probably more packages that either needed patches backported
or new versions uploaded to make them coexist with the changes in the
implementations. However, at the time, it seemed better not to rush
everything in at the last minute, but rather to stick with the
well-tested packages we already had. Having a chronic bug slip through
and sarge stuck with it for its whole lifetime would be really annoying!

Unfortuantely, more than a month on I believe we're still waiting on the
infrastructure. I can appreciate that you are frustrated to not have the
latest hugs in the upcoming Debian release, but rest assured that I am
equally annoyed by the many missed deadlines and seeming inability of
Debian to make progress on the release that means that this is still an
open issue.


The locale based filename thing in hugs is also a concern, though, in my
opinion. Currently two packages build-depend on hugs: haskell-utils and
cpphs. I think haskell-utils currently only uses filenames containing
a-zA-Z0-9./_ so we could wrap that in a script that sets the locale to C
(or maybe do that at the start of main?). cpphs currently accepts 8-bit
chars in filenames being #included, as does cpp; maybe you will argue
that making use of that is foolish, but nevertheless I think I would
rather drop the ability to "compile" with hugs in order to keep its
behaviour consistent.

We'll also have to go over any packages that stay using hugs to make
sure they are opening files in binary mode when appropriate etc. (In
principle this should be done regardless, but within the systems Debian
currently supports it's not been an issue thus far).

Finally, it also means that if everything /did/ go into sarge then the
implementations would be less consistent with each other. In terms of
non-binary-IO this is probably a good thing, as we shouldn't be
encouraging people to use readFile etc as if they did binary IO. But for
filenames we just have 2 incompatible designs. I think I've said this
before, but while I applaud the efforts to put unicode support into
Haskell implementations I would have prefered a suitable replacement of
the IO libraries to have been designed first so that the problems with
unrepresentable filenames would never have come up.


Thanks
Ian

[1] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#305178: ghc-cvs: ftbfs [sparc] build takes too long, many errors

[Ian Lynagh]

On Mon, Apr 18, 2005 at 06:21:00AM -0700, Blars Blarson wrote:
> 
> cd ./codeGen/should_compile && 
> '/tmp/buildd/ghc-cvs-20050331/ghc/compiler/stage2/ghc-inplace' -no-recomp 
> -dcore-lint -Dsparc_unknown_linux -c cg002.hs -O -prof -auto-all   
> >cg002.comp.stderr 2>&1
> Compile failed (status 25344) errors were:
> 
> *** unexpected failure for cg002(prof)

While investigating this I discovered that there is a known problem with
threads on hppa under 2.4 (and IA64 seemed to have some issues too), so
I'm waiting until the Debian machines get upgraded (presumably post
sarge) before picking this up again.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#283024: Fwd: [Re: [nhc-bugs] nhc98 1.18, gcc 3.4 and FC3] [Malcolm.Wallace@cs.york.ac.uk]

[Ian Lynagh]

--- Begin Message ---
Gérard Milmeister <[EMAIL PROTECTED]> writes:

> I cannot compile nhc98 1.18 on Fedora Core 3 with gcc 3.4.3.
> The same was the case with nhc98 1.17 and 1.16.
> Here is the problem:
> 
> OS allocated a heap in high memory (>0x8000)
> which breaks this program's run-time system.
>   hpStart=0xb7e5e008, hpEnd=0xb7ed3308

Yes, we know about this bug, hence the error message.  Unfortunately, it is
tricky to fix, because both the runtime interpreter and the garbage collector
use the highest-bit of a heap address for some internal purposes.  However,
we have a student who has sketched out some potential solutions to the
problem, and are hopeful that it can be fixed in the next month or two.

Regards,
Malcolm
___
Nhc-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/nhc-bugs
--- End Message ---

Bug#299570: [Haskell-cafe] invalid character encoding

[Ian Lynagh]

On Sun, Mar 20, 2005 at 01:33:44AM +, [EMAIL PROTECTED] wrote:
> On Sat, Mar 19, 2005 at 07:14:25PM +0000, Ian Lynagh wrote:
> 
> > Most importantly, though: is there any way to remove this file without
> > doing something like an FFI import of unlink?
> > 
> > Is there anything LC_CTYPE can be set to that will act like C/POSIX but
> > accept 8-bit bytes as chars too?
> 
> en_GB.iso88591 (or indeed any .iso88591 locale) will match the old
> behaviour (and the GHC behaviour).

This works for me with en_GB.iso88591 (or en_GB), but not en_US.iso88591
(or en_US). My /etc/locale.gen contains:

en_GB ISO-8859-1
en_GB.ISO-8859-15 ISO-8859-15
en_GB.UTF-8 UTF-8

So is there anything that /always/ works?

> Indeed it's possible to have filenames (under POSIX, anyway) that H98
> programs can't touch (under Hugs).  That's pretty much follows from
> the Haskell definition FilePath = String.  The other thread under this
> subject has touched on the need for an (additional) API using an abstract
> FilePath type.

Hmm. I can't say I'm convinced by all this without having something like
that API.

> Yes, I don't see how to avoid this when using mbtowc() to do the
> conversion: it makes no distinction between a bad byte sequence and an
> incomplete one.

Perhaps you could use mbrtowc instead?

My manpage says

If the n bytes starting at s do not contain a complete multibyte  char-
acter,  mbrtowc  returns  (size_t)(-2).  This  can  happen even if n >=
MB_CUR_MAX, if the multibyte string contains redundant shift sequences.

If  the  multibyte  string  starting at s contains an invalid multibyte
sequence  before  the  next   complete   character,   mbrtowc   returns
(size_t)(-1) and sets errno to EILSEQ. In this case, the effects on *ps
are undefined.

For both functions my manpage says

CONFORMING TO
   ISO/ANSI C, UNIX98


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#300385: haddock: FTBFS (amd64/gcc-4.0): lexical error in string/character literal

[Ian Lynagh]

On Sat, Mar 19, 2005 at 01:38:48PM +0100, Andreas Jochens wrote:
> 
> When building 'haddock' on amd64 with gcc-4.0,

amd64 doesn't actually use a later gcc than other arches, right?

This looks like #283981, which I was just letting new upstream versions
fix in the natural order of things, but I can be more proactive if it's
causing problems?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#300343: ghc6: New major version, 6.4

[Ian Lynagh]

On Fri, Mar 18, 2005 at 09:54:54PM -0800, Echo Nolan wrote:
> Package: ghc6
> Version: 6.2.2-3
> Severity: wishlist
> 
> see http://haskell.org/ghc/download_ghc_64.html

Thanks.

There are some issues with 6.4, so I haven't uploaded it to unstable
yet, but there are i386 deps in experimental.

> Architecture: powerpc (ppc)

If you want to build it for powerpc yourself, you might need to apply
this patch first:

http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/includes/MachRegs.h.diff?r1=1.21;r2=1.21.2.1

Otherwise, I will try to do another experimental upload soon, which will
hopefully autobuild on most arches (including powerpc).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299570: [Haskell-cafe] invalid character encoding

[Ian Lynagh]

On Wed, Mar 16, 2005 at 11:55:18AM +, Ross Paterson wrote:
> On Wed, Mar 16, 2005 at 03:54:19AM +0000, Ian Lynagh wrote:
> > Do you have a list of functions which behave differently in the new
> > release to how they did in the previous release?
> > (I'm not interested in changes that will affect only whether something
> > compiles, not how it behaves given it compiles both before and after).
> 
> I got lost in the negatives here.  It affects all Haskell 98 primitives
> that do character I/O, or that exchange C strings with the C library.

In the below, it looks like there is a bug in getDirectoryContents.

Also, the error from w.hs is going to stdout, not stderr.

Most importantly, though: is there any way to remove this file without
doing something like an FFI import of unlink?

Is there anything LC_CTYPE can be set to that will act like C/POSIX but
accept 8-bit bytes as chars too?


(in the POSIX locale)
$ echo 'import Directory; main = getDirectoryContents "." >>= print' > q.hs
$ runhugs q.hs 
[".","..","q.hs"]
$ touch 1`printf "\xA2"`
$ runhugs q.hs
runhugs: Error occurred

ERROR - Garbage collection fails to reclaim sufficient space


$ echo 'import Directory; main = removeFile "1\xA2"' > w.hs
$ runhugs w.hs

Program error: 1?: Directory.removeFile: does not exist (file does not exist)
$ strace -o strace.out runhugs w.hs > /dev/null
$ grep unlink strace.out | head -c 14 | hexdump -C
  75 6e 6c 69 6e 6b 28 22  31 3f 22 29 20 20|unlink("1?")  |
000e
$ strace -o strace2.out rm 1*
$ grep unlink strace2.out | head -c 14 | hexdump -C
  75 6e 6c 69 6e 6b 28 22  31 a2 22 29 20 20|unlink("1.")  |
000e
$ 



Now consider this e.hs:


import IO

main = do hWaitForInput stdin 1
  putStrLn "Input is ready"
  r <- hReady stdin
  print r
  c <- hGetChar stdin
  print c
  putStrLn "Done!"


$ { printf "\xC2\xC2\xC2\xC2\xC2\xC2\xC2"; sleep 30; } | runhugs e.hs
Input is ready
True

Program error: : IO.hGetChar: protocol error (invalid character encoding)
$ 

It takes 30 seconds for this error to be printed. This shows two issues:
First of all, I think you should be giving an error as soon as you have
a prefix that is the start of no character. Second, hReady now only
guarantees hGetChar won't block on a binary mode handle, but I guess
there is not much we can do except document that (short of some hideous
hacks).


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299570: [Haskell-cafe] invalid character encoding

[Ian Lynagh]

On Tue, Mar 15, 2005 at 10:44:28AM +, Ross Paterson wrote:
> On Mon, Mar 14, 2005 at 07:38:09PM -0600, John Goerzen wrote:
> > I've got some gzip (and Ian Lynagh's Inflate) code that breaks under
> > the new hugs with:
> > 
> >  : IO.getContents: protocol error (invalid character encoding)
> > 
> > What is going on, and how can I fix it?
> 
> A Haskell 98 Handle is a character stream, and doesn't support binary
> I/O.  This would have bitten you sooner or later on systems that do CRLF
> conversion, but Hugs is now much stricter, because character streams now
> use the encoding determined by the current locale (for the C locale, that
> means ASCII only).

Do you have a list of functions which behave differently in the new
release to how they did in the previous release?
(I'm not interested in changes that will affect only whether something
compiles, not how it behaves given it compiles both before and after).

Simons, Malcolm, are there any such functions in the new ghc/nhc98?

Also, are you all agreed that the hugs interpretation of the report is
correct, and thus ghc at least is buggy in this respect? (I'm afraid I
haven't been able to test nhc98 yet).

Finally, the hugs behaviour seems a little odd to me. The below shows 4
cases where iconv complains when asked to convert utf8 to utf8, but hugs
only gives an error in one of them. In the others it just truncates the
input. Is this really correct? It also seems to behave the same for me
regardless of whether I export LC_CTYPE to en_GB.UTF-8 or C.


Thanks
Ian


printf "\x00\x7F" > inp1
printf "\x00\x80" > inp2
printf "\x00\xC4" > inp3
printf "\xFF\xFF" > inp4
printf "\xb1\x41\x00\x03\x65\x6d\x70\x74\x79\x00\x03\x00\x00\x00\x00\x00" > inp5
echo 'main = do xs <- getContents; print xs' > run.hs
for i in `seq 1 5`; do runhugs run.hs < inp$i; done
for i in `seq 1 5`; do runghc6 run.hs < inp$i; done
for i in `seq 1 5`; do echo $i; iconv -f utf8 -t utf8 < inp$i; done

which gives me the following output:

$ for i in `seq 1 5`; do runhugs run.hs < inp$i; done
"\NUL\DEL"
"\NUL"
"\NUL"
""
"
Program error: : IO.getContents: protocol error (invalid character 
encoding)
$ for i in `seq 1 5`; do runghc6 run.hs < inp$i; done
"\NUL\DEL"
"\NUL\128"
"\NUL\196"
"\255\255"
"\177A\NUL\ETXempty\NUL\ETX\NUL\NUL\NUL\NUL\NUL"
$ for i in `seq 1 5`; do echo $i; iconv -f utf8 -t utf8 < inp$i; done
1
2
iconv: illegal input sequence at position 1
3
iconv: incomplete character or shift sequence at end of buffer
4
iconv: illegal input sequence at position 0
5
iconv: illegal input sequence at position 0
$ 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299702: hugs shouldn't go into sarge yet

[Ian Lynagh]

severity 299702 serious
thanks

On Tue, Mar 15, 2005 at 10:45:19PM +, Martin Michlmayr wrote:
> * Ian Lynagh <[EMAIL PROTECTED]> [2005-03-15 22:21]:
> > Package: hugs
> > Version: 98.200503.08-1
> > Severity: normal
> ^^
> > We're not sure the new hugs should go into sarge without matching new
> 
> The severity is too low.

Hmm, thanks. How odd - I'm sure I type "serious" at a "[normal]" prompt.
Oh, I see, reportbug downgrades the bug when you say "unknown" to what
part of policy is violated. Bah.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299702: hugs shouldn't go into sarge yet

[Ian Lynagh]

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.


Thanks
Ian

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages hugs depends on:
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libncurses5 5.4-4Shared libraries for terminal hand
ii  libreadline44.3-15   GNU readline and history libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299576: RM: nhc98 [m68k] -- RoM; produces incorrect code

[Ian Lynagh]

Package: ftp.debian.org
Severity: normal

Hi,

Please can you remove nhc98 on m68k only in unstable?

It produces incorrect code for even trivial programs.


Thanks
Ian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#283981: Fixed in happy

[Ian Lynagh]

reassign 283981 ghc6, alex, ghc-cvs, haddock
thanks

happy removed: fixed in 1.15-1.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#283981: Compiler errors with gcc-3.4

[Ian Lynagh]

Hi Daniel,

On Thu, Dec 02, 2004 at 09:43:18AM -0800, Daniel Schepler wrote:
> 
> > On Wed, Dec 01, 2004 at 10:41:57PM -0800, Daniel Schepler wrote:
> >> When I set the default compiler to gcc-3.4 instead of -3.3

Can you clarify exactly what you mean here please?
Are you just manually altering the /usr/bin/gcc symlink or what?


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#294481: ghci -lpthread fails

[Ian Lynagh]

On Fri, Feb 11, 2005 at 11:27:21AM -, Simon Marlow wrote:
> On 10 February 2005 23:35, Ian Lynagh wrote:
> 
> > I'm no library expert, so there may be a cleaner/simpler/more portable
> > equivalent to the above.
> 
> I'm not that familiar with libtool, but I guess what  you're doing here
> is creating a dummy shared library which is linked against -lpthread,
> and linking that into GHCi?

Yup.

> I don't see any reason why we couldn't automate the process, except that
> getting all the fiddly details right would probably be a nightmare.

Like I say, I'm no expert either  :-(

> And would you require libtool to be installed?  What about other
> platforms - Mac OS X?

If the necessary bits aren't available then you can fall back to acting
like -optl-foo and are no worse off than currently.

I think libtool is supposed to take care of the portability side for
you, so hopefully lots of special casing won't be necessary. I don't
know how well that works in practice, though.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#294481: ghci -lpthread fails

[Ian Lynagh]

On Thu, Feb 10, 2005 at 07:00:47PM +0100, Juliusz Chroboczek wrote:
> Hi Ian,
> 
> > What is your particular problem?
> 
> Running Darcs under ghci.

This seems to work for me (at least in as much as ghci loads and
FastPackedString.lengthPS (FastPackedString.packString "Foo")
says 3):

rm -rf .libs
rm *ghcidarcsfoo*
touch ghcidarcsfoo.c
libtool --mode=compile gcc -g -O -c ghcidarcsfoo.c
libtool --mode=link gcc -g -O -o libghcidarcsfoo.la ghcidarcsfoo.lo -lpthread 
-rpath /usr/lib
libtool --mode=install cp libghcidarcsfoo.la `pwd`/libghcidarcsfoo.la
libtool --finish /usr/lib
ghci -cpp -package unix -package parsec -O -funbox-strict-fields -Werror 
-package util -I. -DHAVE_CURSES -optl-lcurses -optl-lz -L`pwd` 
-optl-lghcidarcsfoo darcs.lhs compat.o fpstring.o zlib_helper.o c_context.o

Is there a problem with this? Could something along these lines be done
when -lfoo (as opposed to -optl-lfoo, which for consistency should
probably be left alone) is given on the ghci command-line?

I'm no library expert, so there may be a cleaner/simpler/more portable
equivalent to the above.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#294481: ghci -lpthread fails

[Ian Lynagh]

On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote:
> Package: ghc6
> Version: 6.2.2-2
> 
> /usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU
> linker script, not a shared object.  This breaks ghci.

Known problem:

http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html

What is your particular problem?

CCing glasgow-haskell-users@haskell.org as someone there may have an
answer, or be interested to know the problem exists if not.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291231: hmake: Does not handle proprocessor flags

[Ian Lynagh]

Hi John,

On Wed, Jan 19, 2005 at 08:35:13AM -0600, John Goerzen wrote:
> 
> Although its manpage implies that hmake handles proprocessor flags
> automatically in all cases, it dies compiling files that use HaXml
> because it tries to process the GHC code (which happens to occur first)
> instead of the nhc98 code.  As far as I can tell, it doesn't even manage
> to invoke nhc98.
> 
> I even tried:
> 
> HFLAGS="-cpp" hmake -cpp -IHaXml-1.12/src -nhc98 -o dtmconv dtmconv.hs
> 
> It made no difference.

Your report is rather vague. If I use HaXml from
http://www.haskell.org/HaXml/HaXml-1.12.tar.gz and run

hmake -cpp -IHaXml-1.12/src -nhc98 -o dtmconv dtmconv.hs

(the HFLAGS="-cpp" doesn't affect the output and I would advise against
using it) then I get:

Fail: Can't find module System.IO.Unsafe in user directories
.
HaXml-1.12/src
  Or in installed libraries/packages at
/usr/include/nhc98
  Asked for by: HaXml-1.12/src/Text/XML/HaXml/Parse.hs
  Fix using the -I, -P, or -package flags.

Stop - hmake dependency error.

Is this the problem you're having?

This is because HaXml-1.12/src/Text/XML/HaXml/Parse.hs contains

if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ > 502 )
import System.IO.Unsafe (unsafePerformIO)
#elif defined(__GLASGOW_HASKELL__) || defined(__HUGS__)
import IOExts (unsafePerformIO)
#elif defined(__NHC__) && ( __NHC__ > 114 )
*   import System.IO.Unsafe (unsafePerformIO)
#elif defined(__NHC__)
import IOExtras (unsafePerformIO)
#elif defined(__HBC__)
import UnsafePerformIO
#endif

(it is the line I have marked with a * that it is complaining about),
System.IO.Unsafe is in package base and hmake wasn't looking in the base
package by default.

Version 3.09-2 should fix the above issue. If that doesn't solve your
problem then please can you give me step by step instructions to
reproduce the problem and say exactly what error you get?

If that was the problem, please can you close this bug (or let me know
and I'll do it).


Incidentally,

hmake -cpp -IHaXml-1.12/src -nhc98 -o dtmconv dtmconv.hs

now gives

Fail: Can't find module System.Posix.Time in user directories
.
HaXml-1.12/src
  Or in installed libraries/packages at
/usr/include/nhc98
/usr/include/nhc98/base
  Asked for by: dtmconv.hs
  Fix using the -I, -P, or -package flags.

Stop - hmake dependency error.

which looks like an unportability in your code.


Thanks
Ian



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]