Bug#422170: hugs: Text.Regex gone!
On Thu, May 03, 2007 at 07:54:41PM -0500, John Goerzen wrote: Package: hugs Version: 98.200609.21-5 Severity: grave Justification: renders package unusable This breaks compatibility with a ton of packages. I have tried to find this in some package, but can't. The lack of it means that I can't build quite a bit of software for Hugs. As noted on the Hugs download page, this module was removed from the underlying base Haskell library package and replaced with non-portable regex-* packages. The only way forward is for the regex-* packages to be made portable and packaged separately. I think you've set the severity of this bug too high: renders package unusable is just not true. I would say it has a major effect on the usability of a package, without rendering it completely unusable to everyone, i.e. important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402476: hugs98: FTBS on powerpc
On Mon, Dec 11, 2006 at 12:26:21AM +, Ross Paterson wrote: I know nothing of powerpc asm, but the GHC code is identical to the Hugs code except that it has r instead of g: __asm__ volatile (dcbf 0,%0\n\tsync\n\ticbi 0,%0 : : r (p)); Moreover this change in the GHC code was made on 4th Jan 2003 with the comment Darwin: Replace g constraint by r in inline assembly, otherwise it won't compile without -O So I'm applying this to the upstream code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336201: acknowledged by developer (Bug#336201: fixed in hugs98 98.200503.08-4)
On Thu, Nov 03, 2005 at 12:13:23PM +0100, Laurent Bonnaud wrote: hugs98 (98.200503.08-4) unstable; urgency=low . * Added buid-depends on gzip (Closes: #336201). Thank you for this new version ! Unfortunately it does not fix my problem. In fact gzip was already installed on my system. The dependency on gzip was unnecessary, as gzip is an essential package. gzip -9v /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian gzip: gzip: No such file or directory /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian: 65.6% -- replaced with /users/info/profs/bonnaud/hugs98-98.200503.08/debian/tmp/hugs/usr/share/doc/hugs/changelog.Debian.gz make: *** [debian/binary-arch.stamp] Error 1 Build command 'cd hugs98-98.200503.08 dpkg-buildpackage -b -uc' failed. E: Child process failed Do you have a private version of gzip? It seems to be adding gzip to the command line of /bin/gzip. (Does gzip -9v foo produce this message?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336201: acknowledged by developer (Bug#336201: fixed in hugs98 98.200503.08-4)
On Thu, Nov 03, 2005 at 04:37:25PM +0100, Laurent Bonnaud wrote: The only non-standard thing I have in my environment that is related to gzip is this variable: GZIP=--best OK, that's the problem. hugs98/debian/rules uses a variable GZIP, and when you make it an environment variable, the setting in rules goes into the environment and confuses gzip. So hugs98/debian/rules needs to use something else. -- 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
On Thu, Apr 21, 2005 at 03:56:50PM +0100, Ian Lynagh wrote: 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): There was a small bug in Hugs, but I think this locale is broken (#305831). 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. I would have thought that cpp input was text -- does cpphs really do anything with crlf's? Anyway, full compatibility with a GHC-compiled version isn't possible (which was you point) so I guess dropping the cpphs/hugs combination seems reasonable, as you have ghc or nhc98 on all archs. 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. I meant that I appreciate that you've been worried about the filename issue for some time, but that it wouldn't justify keeping Hugs out on its own. -- 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 [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]). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
