On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote:

Tim wins the prize for the 500th Haskell package in Arch Linux,

http://aur.archlinux.org/packages.php?ID=19205

Which, I should like to note, demonstrates why the original Cabal design[1] was basically right[2] in that it allows this kind of automated translation into native packages. You cannot do that with autoconf. The other distros are following a similar course though not yet quite as successfully as Don has demonstrated for Arch. There are similar translation tools for Gentoo, Debian and RPM-based distros with varying levels of sophistication and automation. I think the folks who hack on these translation tools should get together and share code and experience so we can all achieve better levels of automation. The highest levels of automation will also require more centralised QA on hackage. That's where we should be going. Duncan [1] http://haskell.org/cabal/proposal/index.html [2] I'm not at all claiming credit for that design. That was decided well before I started hacking on Cabal.

Duncan Coutts writes:

The other distros are following a similar course though not yet quite as successfully as Don has demonstrated for Arch. There are similar translation tools for Gentoo, Debian and RPM-based distros

What is the current recommended way to build debian packages? I notice there's a step-by-step description at http://www.haskell.org/haskellwiki/Creating_Debian_packages_from_Cabal_packa... Any reason the manual steps here aren't automated? There's also a different script posted at http://urchin.earth.li/pipermail/debian-haskell/2008-January/000370.html and I distinctly remember other recipes as well, although I can't find them at the moment. For RPM, there seems to be a tool at http://www.serpentine.com/blog/software/cabal-rpm/ Should we (i.e. haskell.org) provide apt- and yummable repositories for (source?) packages for .rpm and .deb? -k -- If I haven't seen further, it is by standing in the footprints of giants

At Tue, 19 Aug 2008 14:06:23 +0100, Ian Lynagh wrote:

...

Any reason the manual steps here aren't automated?

There's not much benefit from automating them (although if someone did so, with a nice way to edit the description etc, then it would be handy). The vast majority of the time in creating Debian packages is:

We (at seereason) have a tool, cabal-debian, for automating the process. It has the following features: 1. automatically generates a working debian directory from the .cabal file with no user intervention (most of the time). It copies as much information from the .cabal file to the debian directory as possible. 2. automatically calculates build-depends during initial (or subsequent) debianization 3. checks that .cabal build-depends and debian build-depends are in-sync during dpkg-buildpackage run. 4. automatically calculates install dependencies of binary .debs during dpkg-buildpackage run. (by writing substvar files and using ${haskell:Depends} in debian/control). 5. can be used to create new debian/control and debian/changelog for an already debianized package. (Useful when information copied from the .cabal file changes in the .cabal file). As you state, most generated packages would need additional polish before they could be uploaded to Debian. The Future ---------- cabal-debian seems good enough for general release. I can imagine cabal-debian being used in three ways: 1. a way for users to quickly debianize a cabal library for local use (because going around the debian package system often leads to pain in the long run). 2. a way for debian/ubuntu developers to create a starting point for a real Debian package. 3. a way to standardize on policy issues, by encapsulating them in a tool which "Does It Right". 4. a way to create an unofficial Haskell repository with lots of packages In my opinion, cabal-debian is quite suitable for (1) already. (2) and (3) require agreement from the Haskell Debian community as to what the best practices really are, and patches to make that happen. cabal-debian currently uses: - haskell-devscripts - the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago) - haskell-utils The basic build is done using the cdbs extension for Haskell (which uses haskell-devscripts). But the version dependencies are updated during the build process using a script from haskell-utils. For (4), it should be pretty easy to use cabal-debian plus this autobuilder: http://src.seereason.com/autobuilder/ to easily create a repository of debian packages that not quite up to debian standards. Whether you would *want* such a thing is obviously an issue for debate: quantity vs quality. But the technology already exists if the desire is there. What's Next? ------------ We are working on getting cabal-debian uploaded to hackage, but we have some patches against haskell-devscripts, and a patch against haskell-utils. The patch against haskell-utils has not been accepted, and may possibly be rejected due to some issue with the way Debian's autobuilders work? It does not make much sense to upload cabal-debian to hackage until the supporting tools are up-to-date. So I guess we need to get our patches accepted upstream. (modifying them if needed). We have also started a tool that is essentially cabal-install + cabal-debian. It has the same purpose as cabal-install, but it debianizes the packages on-the-fly. How You Can Help ---------------- We, (at seereason), make no claims that cabal-debian does anything the right way, the best way, or even a sensible way. Our primary requirements are: 1. that cabal-debian generates sane debianization with minimal pain 2. that the generated debian packages can be built by our autobuilder. This essentially means that you should be able to build them in three steps: i. check out the source ii. install the build-depends listed in debian/control iii. run dpkg-buildpackage I believe this is slight issue with haskell-utils based packages which have a procedure more like: i. check out the source ii. run update-haskell-control iii. install build-dependencies iv. run dpkg-buildpackage If update-haskell-control generated >= build-depends instead of = build-depends, then things would work ok with our autobuilder, but possibly not with Debian's?. Anyway, the point is, we are wide open to suggestions and improvements to cabal-debian. In fact, nothing would make us happier than someone coming along and taking over the whole thing ;) Obtaining --------- cabal-debian can be obtained (via darcs get) here: http://src.seereason.com/cabal-debian/ but you will need other dependencies from here: http://src.seereason.com/ and you will need a patch to haskell-devscripts from here: http://src.seereason.com/quilt/haskell-devscripts-quilt/ and haskell-utils from here: http://src.seereason.com/quilt/haskell-utils-quilt/ Example ------- Here is an example debian directory generated by cabal-debian (which no manual modifications or intervention, AFAIK): http://src.seereason.com/debian/shellac-debian/debian/ You would need the patched haskell-devscripts/haskell-utils and possibly cabal-debian to actually build it though. j.

kaol:

On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote:

...

- the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago)

I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/

One thing that it doesn't do yet is to register the -doc packages.

Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian? -- Don

Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian?

-- Don

I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Having a debianized cabal-install would be the biggest win in my book. If there were an unofficial debianized mirror of hackage, I probably wouldn't use it anyway. --Lane

On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote:

At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote:

...

I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at.

Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages).

Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team.

To add to this I suspect that there are more people involved in the perl team than there even are DDs with ghc6 installed, but maybe I'm just being negative. Maybe the time is ripe for a Debian haskell team? I know the idea has been floated before on the Debian Haskell list but I don't think it's ever gained any momentum. /M

Hi, Am Freitag, den 22.08.2008, 10:13 +0100 schrieb Magnus Therning:

On Fri, Aug 22, 2008 at 2:32 AM, David Bremner wrote:

...

At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote:

...

I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at.

Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages).

Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team.

To add to this I suspect that there are more people involved in the perl team than there even are DDs with ghc6 installed, but maybe I'm just being negative. Maybe the time is ripe for a Debian haskell team? I know the idea has been floated before on the Debian Haskell list but I don't think it's ever gained any momentum.

I had it floated to the debian-haskell mailing list once, but as you said, there were not much responses. The Debian Perl Group (which was started by me some years ago) is indeed a good example for good library package maintenance. What made it successful was, in my opinion, people with constant devotion (that was not me :-)) and a faible for developing tools for the team. Have a look at http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi and you see how it was possible to maintain this number of packages with just a few people. Incidentally, a few days ago Ian Lynagh was asking if someone wants to take over his haskell packages, so if there were a group to be formed, it could start with all the base packages. OTOH, this leaves the question open of who will maintain the compiler itself. Of course, this is a totally different thing than maintaining cabalized libraries and so far, no one has stepped up to give it a shot. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote:

I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at.

Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. One of the main tools that makes this possible is dh-make-perl, which is the moral equivalent of cabal-debian, I guess. Just as important is the shared version control setup and team procedures. David

Christopher Lane Hinson writes:

Having a debianized cabal-install would be the biggest win in my book. If there were an unofficial debianized mirror of hackage, I probably wouldn't use it anyway.

I might. I generally want to use newer versions of development stuff (i.e. Haskell libraries etc) than is available in official repos. Were there an unofficial, cutting edge repo at hackage, I could just add it to my sources.list, instead of compiling stuff myself from darcs repos or hackage tarballs. Even if we only get a handful of users, this would be an important testing stage for packages before submitting them to official Debian (and Ubuntu) repos. I'm all for it. -k -- If I haven't seen further, it is by standing in the footprints of giants

At Thu, 21 Aug 2008 20:10:08 +0300, Kari Pahula wrote:

On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote:

...

- the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago)

I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/

One thing that it doesn't do yet is to register the -doc packages.

Cool. We made some modifications including some patches for the -doc stuff I believe. I'll try to do a merge and get some patches back to you. j.

Ketil Malde wrote:

I've had an interested user, who tried to get one of my programs to run on a Debian machine - running Debian Etch, released a couple of months ago.

Your user is pretty much at the pessimal point in the release cycle. Etch is more than a year old, and lenny (the next release) is in pre-release freeze. None of which helps your users, of course. Perhaps things will improve once lenny is out. [non-working versions snipped]

Granted, not all of this is our fault, but it won't help users to start charging the windmills of Debian conservativism. We really need to make this process smoother, and ideally, provide debs for Etch backports.

Another option is to try installing the version from lenny (6.8.2). This may or may not pull in a wack of dependencies, but is not difficult to try out [1].

I'm not sure how to go about any of this, beyond debianizing my own packages. But that's why I'm telling you. :-)

There was some discussion on the list recently about a tool to semi-automatically debianize haskell packages. Perhaps this is of interest to you. There is also a debian-haskell [2] list, which might be relevant. David [1]: http://wiki.debian.org/AptPinning [2]: currently at http://urchin.earth.li/mailman/listinfo/debian-haskell but possible moving.

On Mon, Aug 25, 2008 at 9:10 AM, Mads Lindstrøm wrote:

Hi

Ketil Malde wrote:

...

I've had an interested user, who tried to get one of my programs to run on a Debian machine - running Debian Etch, released a couple of months ago. Here are some of the hurdles stumbled upon in the process:

Debian Etch were released in April 8th, 2007. 16 months ago. Hardly "a copule of months ago". See http://www.debian.org/News/2007/20070408.en.html . Sure, there have been updates since then, but they are mainly concerned with security and drivers for new hardware.

...

1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. 2. ghc-6.8.3, presumably the binary snapshots, didn't work, neither in i386 nor in x86_64 incarnation. 3. ghc 6.8.1-i386 appears to work, but some of the dependencies failed to compile (tagsoup, in this case) 4. A precompiled (by me), statically linked binary refuses to run with a message of "FATAL: kernel too old".

Granted, not all of this is our fault, but it won't help users to start charging the windmills of Debian conservativism. We really need to make this process smoother, and ideally, provide debs for Etch backports.

I'm not sure how to go about any of this, beyond debianizing my own packages. But that's why I'm telling you. :-)

There are several options:

1) Use the testing or unstable branch of Debian. They got newer packages. Testing (aka. Lenny) has GHC 6.8.2 http://packages.debian.org/lenny/ghc6 .

I'd stay away from 6.8.2 if I were you. It has at least one annoying bug that was fixed in 6.8.3. The one I'm thinking of is getSymbolicLinkStatus returning bogus mtimes on some 32bit platforms.

2) Compile GHC yourself. You can even compile and install GHC (and most Haskell software) on a dedicated user account. In this way you avoid messing up you Debian installation if something goes wrong.

I find with Debian this is the way to go. Install your system and use Debian's packages for everything, and then install your own copy of anything for which you care what version you're running. Not everyone will like this option, but I find it's a decent balance between using what Debian provides and getting the satisfaction of using the versions of things I care about. Jason

ketil:

"Jason Dagit" writes:

...

...

2) Compile GHC yourself.

...

I find with Debian this is the way to go.

Ouch. Okay, I've compiled GHC once. But I would like end-users to be able to use my software, and I simply cannot require them to go through this.

Yes, scary and unacceptable. -- Don

On Wed, Aug 27, 2008 at 10:20 PM, David Bremner wrote:

Ketil Malde wrote:

...

Another Debian question, once I've populated the debian/ directory one way or another, how should this be integrated with the rest of the project? Should it be part of the darcs archive, or a separate archive (foo-debian), or what? How do people organize this?

debian-mentors@lists.debian.org is a good place for generic debian packaging questions. After you have a package which works, and which hopefully lintian (a tool for checking debian packages) does not complain about, you can ask on debian-mentors for a sponsor, who will check over the package and hopefully upload it. Right now there is not too much interest in uploading new packages, because people are trying to get lenny out the door.

I've personally had _very_ limited success in getting any haskell packages (both libs and apps) to attract any interest on debian-mentors. This is very unfortunate. I suspect this is due to haskell being an unknown language to most people on that list, and I also suspect that the rather strict (but completely called for) rules about dependencies and versions for haskell packages are unknown to most DDs. I've long thought that the DDs who are on debian-haskell are in an excellent position to change all of this, but I've never pushed very much on this. I've only ever gotten a single comment on an RFS for a haskell package. The comment was "scary looking package" (http://lists.debian.org/debian-mentors/2007/10/msg00389.html). AFAICS there is great room for improvement here, but this conversation should probably move to debian-haskell or debian-mentor... /M

2008/8/25 Ketil Malde :

1. Etch comes with ghc-6.6, and that didn't work with my .cabal file.

Is it not an option to make your software work with the not-quite-latest compiler? 6.8 is less than a year old, so I imagine 6.6 is still in quite a few major distro's stable repositories. I don't know the details of what changed with Cabal between 6.6 and 6.8, and you didn't provide any details of what broke, so this might not be an option. But something to consider. -- -David

Ketil Malde wrote:

Neither do I have an Etch system around, but I should probably install a virtual machine or something. Ideally, I should work out the minimal requirements (including for dependencies, and for dependencies' dependencies), but in practice, I end up depending on whatever is installed on the computer I use. Lazyness bites again. :-)

If you have a Debian (or presumably Ubuntu) machine of some kind, then the package "pbuilder" makes it reasonably easy to set up build environments for particular releases. It is oriented towards building debian packages, but you can "login" to the environment. This is a lot lighter weight than a virtual machine (it uses chroot). David

On 8/19/08, Erik de Castro Lopo wrote:

Tim Chevalier wrote:

...

The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names.

WAV files can't have ID3 tags, but they most definitely can support metadata including all the ones you mention and much more in an LIST/INFO chunk.

libsndfile (http://www.mega-nerd.com/libsndfile) supports TITLE, COPYRIGHT, SOFTWARE, ARTIST, COMMENY, DATE, ALBUM and LICENSE fields.

I stand corrected. However, some CD ripping programs don't fill in the metadata when creating WAV files. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Being a nerd, which is to say going too far and caring too much about a subject, is the best way to make friends I know." --Sarah Vowell