debian-haskell March 2008

debian-haskell@lists.urchin.earth.li

5 participants
8 discussions

Using cdbs and haskell-devscripts to build Haskell libraries
by Kari Pahula 31 Mar '08

31 Mar '08

I wasn't quite happy with either haskell-utils' or haskell-devscripts' style of Haskell library packaging. In my eyes, haskell-utils was just too messy with all those generated files and haskell-devscripts was too monolithic, with a magic dh_haskell call that did all the work. It was a step in the right direction, but I felt that it replicated much of what was done in CDBS and rightly belonged to its domain. Therefore, I chose to reimplement (most of) the wheel. I discarded most of haskell-devscripts and just used dh_haskell_prep and made a CDBS rule file to take care of the rest. Here's my complete debian/rules file, using CDBS: #!/usr/bin/make -f include $(CURDIR)/debian/hlibrary.mk Neat, no? And this should work for any cabalized Haskell library. That's the theory, at least. The rest is mostly controlled by debian/control. This has been successfully tested with haskell-binary (already in unstable) and haskell-hlist. I know some people wouldn't touch CDBS if they can help it...

2 3

getting gtk2hs to build on amd64
by Matthew Danish 14 Mar '08

14 Mar '08

gtk2hs packages currently do not have up-to-date versions in unstable for amd64 because of a very small issue: they attempt to force the usage of gcc-4.1 which will not work with GHC 6.8 on amd64. I have successfully modified the rules file to use gcc-4.2 or 4.3 instead, and compiled my own packages. I have not detected any ill effects while developing with these gtk2hs packages. There is a comment to the effect that "split-objs" doesn't work on gcc-4.2 -- I've been assured that comment is now out of date. I propose a minor change: - # Do not use gcc-4.2 until it works: - # Use gcc-4.1 until ghc/split-obj/gcc-4.2 work togehter - configure_flags += --with-hcflags="-O -pgmc gcc-4.1" + configure_flags += --with-hcflags="-O -pgmc gcc-4.2" or gcc-4.3. I would prefer not to NMU this if either of you have the time to make a proper upload. However, if not, I will probably go ahead and do so next week. This simple change would fix two high priority bugs: #463290, #461422. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org

3 3

Re: [Debian-haskell] binNMUs to keep haskell packages in sync
by Joachim Breitner 09 Mar '08

09 Mar '08

Hi, sorry for asking to CC: debian-haskell, it does not seem to allow mails from non-subscribers. Am Sonntag, den 09.03.2008, 23:02 +0100 schrieb Bastian Blank: > On Sun, Mar 09, 2008 at 07:42:59PM +0100, Joachim Breitner wrote: > > haskell libraries have the unfortunate requirement to need exactly the > > version of dependencies installed that they were built against. > > Can you please explain why? And does a rebuild in the same environment > also break it? AFAIK the compiler, GHC, does heavy cross-module optimization and inlining. I’m not fully aware of the technical details, but I was told by people who hopefully know that we should keep the binary dependencies strict. So > > binary dependencies are fixed (==) to the version that was installed > > during installation. > > Exact version is >> x, << x+1. You mean exact revision. You are right, sorry. I do mean revision. > > Currently, we also fix the build-dependencies, to keep the packages in > > sync across different arches, and do sourceful uploads of all depending > > package when we upgrade a library. I don’t like this situation, and I’m > > wondering if we could not do binNMUs to keep the packages in sync. > > BinNMUs will only work with loose build-deps. Exactly, but loose build deps would lead to packages getting out of sync unless we do binNMUs to fix that. Example: (Library B depends on A.) 1 New version of A is uploaded 2 B is uninstallable current situation: 3 New sourceful version of B has to be uploaded manually 4 buildds build new version of B against new version of A on all platforms (but the uploaders) automatically what I’d like to have: 3 We notice that B is uninstallable (with some script’s help) 4 binNMUs are schedueled for all archs where the new version of A is installed 5 buildds build new binary versions I’m just not sure if point 4 wouldn’t be too much of a burden for the buildds and w-b admins. > > I’m also guessing that not having strict build-dependencies might make > > work easier for releasing or security updates, but that’s just guesswork > > on my side :-) > > You are already in touch with security? This is a large problem. No, I wasn’t aware that is was such a problem. I’ll get in touch with them in case we have to stick to the strict build-dep situation. With loose build-deps, there woudn’t be a large problem with security, would there? Thanks for your reply, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Build dependencies too tight?
by Joachim Breitner 09 Mar '08

09 Mar '08

Hi, I’ve just uploaded a new build of xmonad to make sure the build-dependencies match the ones in the archive. I’m wondering if this strictness (setting the build-dependencies on haskell modules exactly to the version currently installed) is really needed. The policy only mentions it is used to keep the architectures in sync, but I don’t really understand the problem this is fixing. I’m also wondering if we can’t keep the archives in sync using binNMUs. I would think it saves us some work this way. It’s also nicer to our users who try to re-build a certain package on their local machine, without having the very exact build-dependencies installed. I’m probably missing some point here, but I’d like to learn about it. Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 3

binNMUs to keep haskell packages in sync
by Joachim Breitner 09 Mar '08

09 Mar '08

Hi release team, haskell libraries have the unfortunate requirement to need exactly the version of dependencies installed that they were built against. So binary dependencies are fixed (==) to the version that was installed during installation. Currently, we also fix the build-dependencies, to keep the packages in sync across different arches, and do sourceful uploads of all depending package when we upgrade a library. I don’t like this situation, and I’m wondering if we could not do binNMUs to keep the packages in sync. I’m also guessing that not having strict build-dependencies might make work easier for releasing or security updates, but that’s just guesswork on my side :-) So my question to you is: Would it be acceptable if there were regular binNMU requests for haskell libraries? I assume we can format them in any format you like and need to make this effort as little as possible for you. Thanks, Joachim PS: Please answer to both lists, I’m only subscribed to one. -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Re: [Debian-haskell] ghc6.8, xmonad and haskell-utils
by Christopher Lane Hinson 05 Mar '08

05 Mar '08

> that you tried it and it worked is more likely to get it uploaded sooner In that case, I was able to add to my sources.list: deb-src http://haskell-unsafe.alioth.debian.org/archive/amd64 . unstable even though I'm using i386 testing/unstable (prefers testing), and use apt-src to build, ghc6, haskell-utils, haskell-mtl, haskell-stream, haskell-arrows. The only issue is that you must remove all libghc6 packages and ghc6 packages before using dpkg to install new ones, to save a lot a headache with the package management system. Old libghc6-things don't seem to be removable once a new ghc6 is installed. Also, I get this error on apt-src build haskell-opengl, which I have no idea about: [34 of 84] Compiling Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelMap ( Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelMap.hs, dist/build/Graphics/Rendering/OpenGL/GL/PixelRectangles/PixelMap.o ) /tmp/ghc7639_0/ghc7639_0.split__65.s: Assembler messages: /tmp/ghc7639_0/ghc7639_0.split__65.s:637:0: Error: unknown pseudo-op: `.ln.text' make: *** [build-stamp] Error 1 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 Let me know what else I could do to help.

2 1

Updated haskell-utils and library packages in Haskell Unsafe
by Ian Lynagh 05 Mar '08

05 Mar '08

Hi all, Updated haskell-utils and ghc6 library packages are now in Haskell Unsafe (for amd64/Linux/unstable). The only packages with code changes are: * haskell-utils: Now makes tighter deps and build-deps, finally in line with the Debian Haskell policy. I've just noticed that one of the deps is still loose (the foo-dev dep of the foo-prof package), but I'll leave fixing that for the next iteration, I think. * x11: was 1.3.0, now 1.4.1. Please let me know of any successes or failures you have with them. Assuming nothing show-stopping turns up I'll upload to Debian in a day or two. Thanks Ian

3 7

Fwd: Bug#464013: libghc6-missingh-dev: Fails to install.
by John Goerzen 05 Mar '08

05 Mar '08

This seems to be a recurring problem, and I'm not sure how to deal with it. Say we have hslogger, and MissingH. MissingH build-deps and deps on hslogger. When hslogger gets a new version in its cabal file, GHC no longer sees it when you try to use MissingH because it has a different version. Then MissingH has to be rebuilt, and in the meantime, things are broken. Is there any nice automatic way to prevent this problem?

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

debian-haskell March 2008