Fortunately or unfortunately, I made extensive changes to this code in
November:
https://github.com/ddssff/cabal-debian/commit/480f4f099657a20eb46a45c0ca5f492038773e5b
Could you test the latest version of cabal-debian and see if it resolves
your issue? Thanks!
Package: haskell-devscripts
Version: 0.12-0+seereason1~trusty2
Severity: normal
Dear Maintainer,
patch:
>From 6b5eb542a018f966db070fc1ab802f2c94746b51 Mon Sep 17 00:00:00 2001
From: David Fox <d...@seereason.com>
Date: Tue, 22 Nov 2016 09:28:47 -0800
Subject: =?UTF-8?q?Prevent=20g
Package: libpam-runtime
Source: pam
Version: 1.1.0-2
In version 1.1.0,
libpam-modules pre-depends on libpam0g
libpam0g depends on libpam-runtime
libpam-runtime depends on libpam-modules
It is therefore impossible to install any of these, because libpam0g needs
to be installed first, but
On Wed, Jun 10, 2009 at 2:55 PM, Marco Túlio Gontijo e Silva
mar...@holoscopio.com wrote:
Hi.
Em Ter, 2009-06-09 às 00:48 +0200, Joachim Breitner escreveu:
at the moment, if you put
Depends: ${haskell:Depends}
in debian/control for the -doc package stanza, dh_haskell_prep will add
On Thu, Feb 19, 2009 at 5:07 PM, Joachim Breitner nome...@debian.org wrote
So yes, I'm very confident that haddock's interface files are not arch
independent. Which is quite bad, I guess.
I see two solutions:
* We patch haddock to not store any arch dependent data.
(Probably quite some
On Sun, Oct 5, 2008 at 9:29 AM, Joachim Breitner [EMAIL PROTECTED] wrote:
Hi Ian,
Am Sonntag, den 05.10.2008, 12:43 +0100 schrieb Ian Lynagh:
On Sun, Oct 05, 2008 at 02:01:39AM +0200, Joachim Breitner wrote:
I'd like to bring up
On Sat, Oct 4, 2008 at 5:01 PM, Joachim Breitner [EMAIL PROTECTED] wrote:
Hi,
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.
From what I'm reading in
I'm on lenny, and just upgraded to version 169.12 of nvidia-glx, which
still contains SSE code linked in, and I
have an Athlon Thunderbird (pre-palomino) processor, which lacks
movups and other SSE instructions.
After looking in the README file in /usr/share/doc/nvidia-glx, and
having been clued
Hi Ian. Ok, I reviewed that message, and I think I understand the
difficulty. I'm using our autobuilder to build many packages for many
distributions (feisty, gutsy, hardy, etch, lenny, sid) so I want to make
sure everything just works when you dpkg-buildpackage. My preference
would be to
The haskell-cgi patch modifies debian/rules so the generated files are
updated during the build.
The haskell-utils patch adds a dependency on dctrl-tools, which contains
grep-status.
--- haskell-cgi/debian/control~ 2008-03-09 08:03:18.0 -0700
+++ haskell-cgi/debian/control 2008-03-09
Package: haskell-utils
Version: 1.11
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
The attached patches resolve the issue for me.
--- haskell-utils-1.11/update-haskell-control.lhs.in~ 2008-03-03 08:58:42.0 -0800
+++ haskell-utils-1.11/update-haskell-control.lhs.in 2008-03-09 09:23:15.0 -0700
@@ -194,18 +194,22 @@
deps = buildDepends pd
--
Ok, I will update. I have made a similar patch for Ubuntu's
linux-restricted-modules-2.6.20 package which uses /etc/ld.so.conf.d.
Romain Beauxis wrote:
Hi !
I am considering your proposition for futur package releases..
My system does not come with a /etc/ld.so.conf file but a
I have made one correction to this patch. In the changes to
nvida-glx.links.in the links to
usr/lib/libGL.so.#VERSION# and usr/lib/libGLcore.so.#VERSION# should be in the
subdirectory /usr/lib/nvidia:
+usr/lib/nvidia/libGL.so.#VERSION# usr/lib/nvidia/libGL.so.1
@@ -0,0 +1,240 @@
+#!/usr/bin/runhaskell
+
+-- Parse an xorg.conf file, modify it, and rewrite it.
+-- Author: David Fox [EMAIL PROTECTED], 19 Nov 2006.
+
+import Control.Exception
+import Data.List
+import Data.Maybe
+import System.Cmd
+import System.Console.GetOpt
+import System.Directory
+import
diff -ruN fglrx-driver-8.28.8.orig/debian/control fglrx-driver-8.28.8/debian/control
--- fglrx-driver-8.28.8.orig/debian/control 2006-11-17 07:25:56.0 -0500
+++ fglrx-driver-8.28.8/debian/control 2006-11-17 07:26:55.0 -0500
@@ -13,7 +13,6 @@
Recommends: fglrx-kernel-src (=
The install location of the enable/disable scripts was in /usr/sbin
instead of /sbin
diff -ruN fglrx-driver-8.28.8.orig/debian/control fglrx-driver-8.28.8/debian/control
--- fglrx-driver-8.28.8.orig/debian/control 2006-11-17 07:25:56.0 -0500
+++ fglrx-driver-8.28.8/debian/control
:56.0 -0500
@@ -0,0 +1,240 @@
+#!/usr/bin/runhaskell
+
+-- Parse an xorg.conf file, modify it, and rewrite it.
+-- Author: David Fox [EMAIL PROTECTED], 19 Nov 2006.
+
+import Control.Exception
+import Data.List
+import Data.Maybe
+import System.Cmd
+import System.Console.GetOpt
+import
Package: fglrx-driver
Version: 8.28.8-3
Severity: wishlist
Tags: patch
The fglrx-driver package conflicts with nvidia-glx and performs some
diversions that disable the 3-D capabilities of the other xorg drivers.
This causes problems when users switch to a new video card, move their
hard
Package: 915resolution
Version: 0.5.2-5
Severity: normal
We are having some trouble using the 915resolution package in our
pre-installed ISO. Because the default configuration file has no XRESO
and YRESO values, it causes apt-get to die when installed onto a system
that doesn't have an Intel
Attached is a patch to accommodate changes in 2.6.18. I have built this
but do not have the device to test it.
--- bcm5700/src/mm.h~ 2006-05-11 04:11:56.0 -0400
+++ bcm5700/src/mm.h2006-10-08 11:31:11.0 -0400
@@ -27,6 +27,7 @@
#define __NO_VERSION__
#endif
#include
One I encountered was XHTML:
http://www.cs.chalmers.se/~bringert/darcs/haskell-xhtml/doc/. It does
'include $(TOP)/mk/boilerplate.mk' at the top of its Makefile.
Ian Lynagh wrote:
On Wed, Sep 27, 2006 at 04:28:37PM -0700, David Fox wrote:
It is very helpful to have the configured
Package: ghc6
Version: 6.4.2-2
Severity: wishlist
Tags: patch
It is very helpful to have the configured versions of the files in mk
for building some external libraries. I have patched the rules file as
follows to achieve this:
--- ghc6/debian/rules~2006-09-27 04:52:53.0 -0400
Package: powermgmt-base
Version: 1.28
The postinst uses /sbin/MAKEDEV which is part of the makedev package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libraw1394
Version: 1.2.1-1
The postinst for libraw1394-8 uses /sbin/MAKEDEV, which is part of the
makedev package. The dependency specifies makedev | udev, but udev no
longer provides /sbin/MAKEDEV (did it ever?)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Chris Hanson wrote:
David Fox wrote:
Package: powermgmt-base
Version: 1.28
The postinst uses /sbin/MAKEDEV which is part of the makedev package.
Are you sure about that? On my machine it has that dependency:
ravna:1$ dpkg --status powermgmt-base
Package: powermgmt
Chris Hanson wrote:
David Fox wrote:
Are you sure about that? On my machine it has that dependency:
Yes, but it is an OR with udev, so if udev is already installed it won't
install makedev. It should depend on udev and makedev.
That's
Package: dpkg
Version: 1.13.20
The post install script for dpkg uses the perl English.pm module, and
therefore fails unless perl-modules is installed with it. I discovered
this trying to create a build environment from the current (as of 3 June
2006) sid distribution.
--
To UNSUBSCRIBE,
28 matches
Mail list logo
