Bug#747031: fixed in python-debian 0.1.22
Hi Stuart, On Wed, Jun 11, 2014 at 10:12:21PM +1000, Stuart Prescott wrote: > Hi John, > > >* python_support: Avoid hashlib dependency, using the built-in _sha or > > _sha1 module (depending on Python version) instead. That way we > > don't link in OpenSSL, which has an incompatible license. > > (Closes: 747031) > > We should be careful that this particular change is not backwards compatible > with wheezy's python: > > $ PYTHONPATH=. python -c 'import debian.debian_support; > debian.debian_support.new_sha1()' > Traceback (most recent call last): > File "", line 1, in > File "debian/debian_support.py", line 50, in new_sha1 > "Built-in sha1 implementation not found; cannot use hashlib" > NotImplementedError: Built-in sha1 implementation not found; cannot use > hashlib implementation because it depends on OpenSSL, which may not be linked > with this library due to license incompatibilities > > (the test suite does fail which would alert a backporter) > > Fiddling around with an internal interface like _sha feels quite wrong too. I > think it's likely to bring pain back to us in the future. For what it's worth, I don't particularly like this solution either. I couldn't find a better one (at least not a tecnhical one - see below). > I'm quite unconvinced by the argument that a GPL'd script can't import > hashlib; I think GPLv3 is quite clear that "hashlib" is a Standard Interface > of the Python programming language and that making use of it is fine; the > language is less precise for GPLv2 but I still don't think there's a problem > there. There are plenty of other GPL'd things in Debian that "import hashlib" > and I don't think anyone's interested in working on this. I actually am convinced by the debian-legal argument that the exception doesn't apply for Debian (because Debian distributes both OpenSSL and python-debian), but the alternative to this hacky crap is to modify our own license to allow linking with OpenSSL. Which honestly is probably not too hard since there were only a handful of contributors to python_support.py. > I've taken this particular issue out of the too-hard-basket and put it back > in > several times already... thanks for taking a crack at it. No problem. Feel free to revert the change if it's causing problems. -- John Wright signature.asc Description: Digital signature
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line "[ 0.000000] " to dmesg file
On Sun, Oct 20, 2013 at 10:25:31PM -0400, Alex Vanderpol wrote: > Unfortunately I no longer have any of those crash dumps available to > send you anything, I had sent what I had gotten to the kernel > maintainers previously in an attempt to track down the cause of the > crashing, which I don't believe was ever figured out exactly but was > ultimate fixed in a later kernel version. I don't know if they would > still happen to have it on hand or not, though. > > For what it's worth, there never was a vmcore file created any time > I did get a dump, instead I always got two separate files, one which > is the main core dump and one which is supposed to be the dmesg log > dump which unfortunately was never actually able to be dumped (the > issue I filed this bug report about). If the end result is supposed > to be one vmcore file, I suspect the inability of makedumpfile to > dump the kernel dmesg log prohibited it from combining the two files > into one file. It's always two separate files. They are not meant to be combined - the dmesg dump is just intended for convenience (you can just read the file as text instead of opening a dump with crash). > Using the 'log' command from within crash was ultimately useless as > well, as the kernel log wasn't dumped, therefore there wasn't any > log for crash to open. > > This issue was with kernel 3.11-rc4-amd64 in its stock configuration. Not a Debian package? I'm not sure what you mean when you say stock configuration. Do you mean you ran 'make defconfig' to generate the kernel .config? > I hope what information I am able to give you proves to be at least > somewhat useful. I'm not really sure what you saw. :-/ I'll see if I can reproduce anything with linux-image-3.11-1-amd64_3.11.5-1_amd64 when I have some free time (I lost the VM I use for testing this stuff). It's possible there was a short-lived bug in the kernel itself, causing some corrupt representation of its log buffer. > On 2013-10-20 10:29 PM, John Wright wrote: > >Hi Alex, > > > >On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: > >>Package: makedumpfile > >>Version: 1.5.4-1 > >>Severity: grave > >>Justification: renders package unusable > >> > >>Dear Maintainer, > >> > >>There seems to be a serious issue with makedumpfile that causes it to fail > >>to > >>dump the kernel log when collecting crash dump information. Instead, the > >>program continues to run indefinitely, continually appending the line "[ > >>0.00] " to the file as it seems to attempt to dump the log, which, if > >>left > >>alone for any considerable length of time, can rapidly result in a very > >>large, > >>entirely useless dmesg dump file. > >> > >>I have been trying to collect crash dump information for a crash that's > >>triggered whenever Folding@Home's FahCore_a4 attempts to resume an > >>in-progress > >>work unit, however, every crash dump I've collected has had this problem. > >>The > >>main dump file seems to be dumped without a problem (though crash > >>identifies it > >>as a partial dump, possibly due to the kernel log being dumped into a > >>separate > >>file). > >> > >>I hope you can look into this issue and hopefully it can be sorted out soon. > >Sorry for the long delay in my response. This seems like a serious but > >not actually grave issue, since the core dump does actually exist (even > >though you have to interrupt the dmesg extraction). crash identifies > >the dump as a partial dump because we explicitly ignore zero pages and > >userspace pages. Within crash, you should be able to use the 'log' > >command to get the most recent log messages before the crash...assuming > >crash doesn't break in the same way makedumpfile does. > > > >I will try to reproduce this, but I worry the problem might be somewhat > >specific either to your crash or some other part of your configuration. > >Would you feel comfortable making the vmcore available to me? It would > >also help to know the exact kernel version, and access to a dbg package > >if it's not a stock kernel. > > > >Sorry for the issue and thanks for the report! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line "[ 0.000000] " to dmesg file
Hi Alex, On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: > Package: makedumpfile > Version: 1.5.4-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > There seems to be a serious issue with makedumpfile that causes it to fail to > dump the kernel log when collecting crash dump information. Instead, the > program continues to run indefinitely, continually appending the line "[ > 0.00] " to the file as it seems to attempt to dump the log, which, if left > alone for any considerable length of time, can rapidly result in a very large, > entirely useless dmesg dump file. > > I have been trying to collect crash dump information for a crash that's > triggered whenever Folding@Home's FahCore_a4 attempts to resume an in-progress > work unit, however, every crash dump I've collected has had this problem. The > main dump file seems to be dumped without a problem (though crash identifies > it > as a partial dump, possibly due to the kernel log being dumped into a separate > file). > > I hope you can look into this issue and hopefully it can be sorted out soon. Sorry for the long delay in my response. This seems like a serious but not actually grave issue, since the core dump does actually exist (even though you have to interrupt the dmesg extraction). crash identifies the dump as a partial dump because we explicitly ignore zero pages and userspace pages. Within crash, you should be able to use the 'log' command to get the most recent log messages before the crash...assuming crash doesn't break in the same way makedumpfile does. I will try to reproduce this, but I worry the problem might be somewhat specific either to your crash or some other part of your configuration. Would you feel comfortable making the vmcore available to me? It would also help to know the exact kernel version, and access to a dbg package if it's not a stock kernel. Sorry for the issue and thanks for the report! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696386: makedumpfile fails with elf_readall error : more information
On Thu, Dec 20, 2012 at 02:39:09PM +0100, Bouchard Louis wrote: > I have just completed a subsequent test on Ubuntu 13.04 Raring, which > uses the same version of makedumpfile and libelf1. To my surprize, it > DOES work correctly on Ubuntu. > > Could this be related the the build of the library ? Interesting. That's a possibility, but tracking down the specific difference in Ubuntu's and Debian's toolchains is going to be tricky. Does it work in Ubuntu with Debian's kernel, or vice versa? -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623470: Configuring kdump-tools fails when there is no crashkernel= in the kernel cmdline
On Wed, Apr 20, 2011 at 05:28:09PM +0300, Sami Liedes wrote: > Package: kdump-tools > Version: 1.3.7-1 > Severity: serious > > Hi, > > kdump-tools fails to configure on my laptop: > > > Setting up kdump-tools (1.3.7-1) ... > Starting kdump-tools: no crashkernel= parameter in the kernel cmdline ... > failed! > invoke-rc.d: initscript kdump-tools, action "start" failed. > dpkg: error processing kdump-tools (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > kdump-tools > > > I don't think the command line I used to boot the kernel should > prevent a package from configuring. The command line: > > > $ cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-2.6.38.3 root=/dev/mapper/rootvg-root ro > Thanks for the bug report. You're right, the package should not fail to configure. I'll modify the init script so that it prints a warning and exits with status 0 in this case. -- John Wright signature.asc Description: Digital signature
Bug#623011: python-debian: FTBFS: Test failure (missing Build-Depends?)
On Sat, Apr 16, 2011 at 08:47:51AM -0700, Daniel Schepler wrote:
> Source: python-debian
> Version: 0.1.19
> Severity: serious
>
> From my pbuilder build log:
>
> ...
> # run the tests
> cd tests && ./test_deb822.py
> ...
> --
> Ran 39 tests in 0.165s
>
> OK
> cd tests && ./test_debfile.py
> ..
> --
> Ran 10 tests in 0.220s
>
> OK
> cd tests && ./test_debtags.py
> ...
> --
> Ran 3 tests in 0.006s
>
> OK
> cd tests && ./test_changelog.py
> ..
> --
> Ran 14 tests in 0.031s
>
> OK
> cd tests && ./test_debian_support.py
> .E
> ==
> ERROR: testversions (__main__.VersionTests)
> --
> Traceback (most recent call last):
> File "./test_debian_support.py", line 77, in testversions
> ValueError, cls, 'a1:1.8.8-070403-1~priv1')
> File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
> callableObj(*args, **kwargs)
> File "../lib/debian/debian_support.py", line 170, in __init__
> raise NotImplementedError("apt_pkg not available; install the "
> NotImplementedError: apt_pkg not available; install the python-apt package
>
> ------
> Ran 6 tests in 0.011s
>
> FAILED (errors=1)
> make: *** [build-stamp] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
Crap. Sorry. Will fix this tonight.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587137: python-debian: FTBFS: failed test
tags 587137 + pending thanks On Fri, Jun 25, 2010 at 01:24:46PM +0100, James Westby wrote: > On Fri, 25 Jun 2010 12:17:48 +0200, Lucas Nussbaum > wrote: > > > == > > > FAIL: test_tar_bz2 (__main__.TestDebFile) > > > -- > > > Traceback (most recent call last): > > > File "./test_debfile.py", line 140, in test_tar_bz2 > > > './usr/share/locale/bg/') > > > AssertionError: './usr/share/locale/bg' != './usr/share/locale/bg/' > > > > > > -- > > > Ran 10 tests in 0.144s > > > > > > FAILED (failures=2) > > > make: *** [build-stamp] Error 1 > > My patch to the list a couple of weeks ago was intended to address these > issues. > > I haven't committed my patch to git yet, as I couldn't bring myself to > fight with git to make sure it pushed the right thing, and I can't > upload anyway. > > If someone wants to upload with the patch that would be great. I just committed and pushed it. I'm planning on working on #586021 in the next few days, so I'll hold off actually uploading for now. John -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
reassign 562398 libdebian-installer4-udeb
found 562398 0.69
retitle 562398 libdebian-installer: strange behavior with more than one version
of a package in a Packages file
affects 562398 + anna
tags 562398 + patch
thanks
On Sun, May 02, 2010 at 03:08:08PM -0600, John Wright wrote:
> Specifically, what happens is that anna unpacks all the packages in one
> batch, and then it configures all of them. But while unpacking another
> version of a package while another vesrion is in an
> unpacked-but-not-configured state is ok, it's not ok to configure a
> package that's already in the configured state. So if a package is in
> the list twice, it fails at the second configure for that package.
Here's what's happing in libd-i: Upon encountering a Packages stanza
with the same Package field as one it's previously seen,
di_packages_parser_read_name sets the data pointer the rest of the
parsing functions will use to the previously-used di_packages pointer.
At first glance, this would appear simply to prefer packages that appear
later in the Packages file, irrespective of version. Unfortunately, it
appends the di_package to the package list
(&parser->data->packages->list) whether it's a newly allocated one or an
old one. So while only one actual di_package exists for a particular
package name, it might appear multiple times in the list.
The simple way to fix the anna issue is to make sure we only append
newly allocated di_package objects to the list. But it would be nice to
favor new versions rather than whatever shows up latest in the Packages
file (for example, to facilitate #389430 or LP#234486).
I've attached a quick reproducer to demonstrate the issue, and a patch.
I would prefer if the version comparison could happen during the
Packages file parsing, rather than after the fact (since this way
requires creating a temporary hash table and traversing the list a
couple of extra times), but that change would seem to be very invasive.
In any case, after pounding my head for a couple of hours, I couldn't
figure out how to do it any better with the current parsing
infrastructure. :)
--
John Wright
#include
#include
#include
int main(int argc, char **argv)
{
di_packages_allocator *allocator = di_system_packages_allocator_alloc();
di_packages *packages;
di_package *package, *last_package = NULL;
di_slist_node *node;
const char *packages_file;
if (argc == 2)
packages_file = argv[1];
else {
printf("Usage: %s \n", argv[0]);
return 1;
}
packages = di_system_packages_read_file(packages_file, allocator);
for (node = packages->list.head; node; node = node->next) {
package = node->data;
if (!package)
printf("package == NULL\n");
if (package == last_package)
printf("Eek! package == last_package\n");
printf("Package: %s\n", package->package);
printf("Version: %s\n", package->version);
printf("\n");
last_package = package;
}
return 0;
}
Package: baz
Version: 0.0~hpde1
Package: bang
Version: 0.133
Package: baz
Version: 0.0hpde1
Package: foo
Version: 1.2.3
Package: foo
Version: 1.2.3hpde1
Package: bar
Version: 2.3.4hpde1
Package: bar
Version: 2.3.4
Package: baz
Version: 0.1
>From 64d06247e4fdb35fd7f33eb7020ec84584e23b42 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Sun, 2 May 2010 22:15:11 -0600
Subject: [PATCH] Filter out old versions after parsing a Packages file
The previous behavior favored packages showing up later in the Packages
file rather than packages with later versions, and wound up putting
multiple entries for the same package in the di_packages list. This
patch ensures a new di_package is created for each stanza, and then
filters out all but the latest versions before returning the di_packages
pointer.
There's a small memory leak for each di_slist_node corresponding to an
old package version. It can't be helped, as far as I can tell, because
of how the memory for those are allocated (using mem_chunk). The bulk
of the memory used for those is freed, just not the di_slist_node glue.
This patch also fixes a bug in di_hash_table_insert, where the key was
not being reset after potentially destroying the old key and changing
the value for a key (which may contain the key itself).
---
include/debian-installer/packages.h |4 ++
src/hash.c |1 +
src/packages.c | 69 +++
src/packages_parser.c |8 +++-
4 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/include/debian-installer/packages.h b/include/debian-installer/packages.h
index c5e4576..0d7dd1c 100644
--- a/include/debian-installer/packages.h
+++ b/include/debian-installer/packages.h
@@ -71,6 +71,10 @@ void di_p
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
On Thu, Dec 24, 2009 at 01:30:04PM +0100, Frans Pop wrote: > On Thursday 24 December 2009, Frans Pop wrote: > > So the error is probably the result of anna trying to install the same > > package twice. > > The exit code of anna was 8, which matches an error during unpack or > configure. I've run into this with a custom installer suite with udebs overriding those in lenny's main/debian-installer. My solution at the time was just to filter the Packages file in net-retriever so that anna was only given one version of any particular package. (Ubuntu did something similar, see [1].) However, it should probably be fixed in anna or libdebian-installer itself. :) Specifically, what happens is that anna unpacks all the packages in one batch, and then it configures all of them. But while unpacking another version of a package while another vesrion is in an unpacked-but-not-configured state is ok, it's not ok to configure a package that's already in the configured state. So if a package is in the list twice, it fails at the second configure for that package. I'm trying to better understand anna and libd-i to come up with a suitable patch... [1]: https://bugs.launchpad.net/ubuntu/+source/net-retriever/+bug/234486 -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539187: libgv-python: broken symlink /usr/lib/pyshared/python2.{4,5}/_gv.so
Package: libgv-python Version: 2.20.2-3+b4 Severity: grave Justification: renders package unusable I can't import the gv module: jswri...@callisto:~$ python Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gv Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.5/gv.py", line 7, in import _gv ImportError: No module named _gv Poking around: jswri...@callisto:~$ file /usr/lib/pyshared/python2.5/_gv.so /usr/lib/pyshared/python2.5/_gv.so: broken symbolic link to `../../python2.5/site-packages/libgv_python25.so' The symlink wasn't broken in version 2.20.2-3; I think the binNMU, which would have used a later version of python-support, broke it. I suspect the fix to #523033 might have caused it, but I'm assigning it to libgv-python for now just in case. :) Thanks, John Wright -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgv-python depends on: ii libc62.9-22 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-11 GCC support library ii libgraphviz4 2.20.2-3+b4 rich set of graph drawing tools ii libstdc++6 4.4.0-11The GNU Standard C++ Library v3 ii python 2.5.4-2 An interactive high-level object-o ii python-support 1.0.3 automated rebuilding support for P libgv-python recommends no packages. libgv-python suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537758: Adopting trac-mercurial
Hi Christoph, On Sun, Jul 26, 2009 at 10:07:13AM +0200, Christoph Egger wrote: > owner 537758 ! > retitle 537758 ITA: trac-mercurial -- Mercurial version control backend for > Trac > kthxbye > > Hi! > > I'm using trac + mercurial + this plugin in production an plan > continuing to do so. Because of this I'll adopt this package and > (probably) to collab-maint. Great! I'm glad it will be getting the attention it deserves. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526346: Patch
tags 526346 + patch
thanks
Hello,
The build system in this version of apr doesn't work with libtool 2.x.
It's fixed in the upstream Subversion repository. The attached patch is
a port of the relevant commits in upstream svn.
Thanks,
--
John Wright
#! /bin/sh /usr/share/dpatch/dpatch-run
## 025_libtool_2.x_fixes.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Update build system to work with libtool 2.x
## DP:
## DP: This corresponds to upstream revisions:
## DP: 733052
## DP: 742752
## DP: 748902
## DP: 757363
@DPATCH@
diff --git a/build/buildcheck.sh b/build/buildcheck.sh
index 62fe931..c236810 100755
--- a/build/buildcheck.sh
+++ b/build/buildcheck.sh
@@ -38,7 +38,7 @@ fi
# output is multiline from 1.5 onwards
# Require libtool 1.4 or newer
-libtool=`build/PrintPath glibtool libtool libtool15 libtool14`
+libtool=`build/PrintPath glibtool1 glibtool libtool libtool15 libtool14`
lt_pversion=`$libtool --version 2>/dev/null|sed -e
's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'`
if test -z "$lt_pversion"; then
echo "buildconf: libtool not found."
diff --git a/buildconf b/buildconf
index bc0e9fd..11554ed 100755
--- a/buildconf
+++ b/buildconf
@@ -23,7 +23,7 @@
#
build/buildcheck.sh || exit 1
-libtoolize=`build/PrintPath glibtoolize libtoolize15 libtoolize14 libtoolize`
+libtoolize=`build/PrintPath glibtoolize1 glibtoolize libtoolize15 libtoolize14
libtoolize`
if [ "x$libtoolize" = "x" ]; then
echo "libtoolize not found in path"
exit 1
@@ -35,17 +35,20 @@ fi
# Note: APR supplies its own config.guess and config.sub -- we do not
# rely on libtool's versions
#
-echo "Copying libtool helper files ..."
+echo "buildconf: copying libtool helper files using $libtoolize"
# Remove any libtool files so one can switch between libtool 1.3
# and libtool 1.4 by simply rerunning the buildconf script.
-(cd build ; rm -f ltconfig ltmain.sh libtool.m4)
-
-$libtoolize --copy --automake
-
-if [ -f libtool.m4 ]; then
- ltfile=`pwd`/libtool.m4
-else
+(cd build ; rm -f ltconfig ltmain.sh libtool.m4 ltoptions.m4 ltsugar.m4
ltversion.m4 lt~obsolete.m4)
+
+lt_pversion=`$libtoolize --version 2>/dev/null|sed -e
's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'`
+lt_version=`echo $lt_pversion|sed -e 's/\([a-z]*\)$/.\1/'`
+IFS=.; set $lt_version; IFS=' '
+if test "$1" = "1"; then
+ $libtoolize --copy --automake
+ if [ -f libtool.m4 ]; then
+ltfile=`pwd`/libtool.m4
+ else
ltfindcmd="`sed -n \"/=[^\\\`]/p;/libtool_m4=/{s/.*=/echo /p;q;}\" \
< $libtoolize`"
ltfile=${LIBTOOL_M4-`eval "$ltfindcmd"`}
@@ -54,21 +57,21 @@ else
ltpath=`dirname $libtoolize`
ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
fi
-fi
-
-if [ ! -f $ltfile ]; then
+ fi
+ if [ ! -f $ltfile ]; then
echo "$ltfile not found"
exit 1
+ fi
+ # Do we need this anymore?
+ echo "buildconf: Using libtool.m4 at ${ltfile}."
+ cat $ltfile | sed -e 's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/' >
build/libtool.m4
fi
-
-echo "buildconf: Using libtool.m4 at ${ltfile}."
-
-cat $ltfile | sed -e 's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/' >
build/libtool.m4
-
-# libtool.m4 from 1.6 requires ltsugar.m4
-if [ -f ltsugar.m4 ]; then
- rm -f build/ltsugar.m4
- mv ltsugar.m4 build/ltsugar.m4
+if test "$1" = "2"; then
+ $libtoolize --copy
+ # Wouldn't it just be better to define top_builddir??
+ mv build/libtool.m4 build/libtool.m4.$$
+ cat build/libtool.m4.$$ | sed -e
's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/' > build/libtool.m4
+ rm build/libtool.m4.$$
fi
# Clean up any leftovers
@@ -77,22 +80,22 @@ rm -f aclocal.m4 libtool.m4
#
# Generate the autoconf header and ./configure
#
-echo "Creating include/arch/unix/apr_private.h.in ..."
+echo "buildconf: creating include/arch/unix/apr_private.h.in ..."
${AUTOHEADER:-autoheader}
-echo "Creating configure ..."
+echo "buildconf: creating configure ..."
### do some work to toss config.cache?
${AUTOCONF:-autoconf}
# Remove autoconf 2.5x's cache directory
rm -rf autom4te*.cache
-echo "Generating 'make' outputs ..."
+echo "buildconf: generating 'make' outputs ..."
build/gen-build.py make
# Create RPM Spec file
if [ -f `which cut` ]; then
- echo rebuilding rpm spec file
+ echo "buildconf: rebuilding rpm spec file"
( REVISION=`build/get-version.sh all include/apr_version.h APR`
VERSION=`echo $REVISION | cut -d- -s -f1`
RELEASE=`echo $REVISION | cut -d- -s -f2`
diff --git a/configure.in b/configure.in
index 46b4b32..2ac1439 100644
--- a/configure.in
+++ b/configure.in
Bug#525088: xtables-addons-source: should depend on pkg-config
My patch won't apply, since I ran into this while attempting a backport. Sorry about that. Still, the solution is simple enough: add pkg-config to the dependency list of xtables-addons-source. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525088: xtables-addons-source: should depend on pkg-config
Package: xtables-addons-source Version: 1.14-1 Severity: serious Tags: patch The configure script in xtables-addons-source requires pkg-config to be available: checking for libxtables... configure: error: in `/usr/src/modules/xtables-addons': configure: error: The pkg-config script could not be found or is too old. Make sure it is in your PATH or set the PKG_CONFIG environment variable to the full path to pkg-config. Alternatively, you may set the environment variables libxtables_CFLAGS and libxtables_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. To get pkg-config, see <http://pkg-config.freedesktop.org/>. See `config.log' for more details. make[1]: *** [binary-modules] Error 1 make[1]: Leaving directory `/usr/src/modules/xtables-addons' make: *** [kdist_build] Error 2 BUILD FAILED! I have attached a patch. Thanks, -- John Wright diff --git a/debian/control b/debian/control index 0c4d347..11e3cf4 100644 --- a/debian/control +++ b/debian/control @@ -15,6 +15,7 @@ Depends: module-assistant, debhelper (>= 5), make, bzip2, +pkg-config, iptables-dev Description: Source for the xtables-addons driver This package provides the source code for the xtables-addons kernel modules.
Bug#518929: current trac-mercurial does not work with mercurial 1.1.2
On Mon, Mar 09, 2009 at 10:57:17AM +0100, Alban Browaeys wrote: > Package: trac-mercurial > Version: 0.11.0.5dev~svnr7354-2 > Severity: grave > Justification: renders package unusable > > Latest 0.11 branch of trac-mercurial fixes thoses issues raised by the > changes in mercurial 1.1.2 > especially get_version gone and bug about index not being integer in browser > view. > > I made a local package just checking out the svn co > http://svn.edgewall.com/repos/trac/sandbox/mercurial-plugin-0.11 and adding > the debian directory. Then building . This went fine. > > Cheers, > Alban Hi Alban, I'll package up the latest upstream version this weekend. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501207: destar: Fails to run with python2.5
On Tue, Oct 07, 2008 at 09:07:10AM +0300, Faidon Liambotis wrote: > John Wright wrote: > > Yes, lenny will have both python2.4 and python2.5. One workaround, at > > least for the compiler.ast.From problem, would be to run destar with > > #!/usr/bin/python2.4 instead of #!/usr/bin/python. But I think it > > better to fix the bug rather than try to work around it, if possible. > Definitely, my concern was for the backwards compatibility. > > >> Are your fixes backwards compatible? It'd suck to fix this only to have > >> a bug report the day after "fails to run with python2.4" :) > > > > I made sure the fix for #501207 was backwards-compatible. As for the > > SyntaxError problem, I'm surprised it ever worked at all. Function > > definitions with optional arguments before required positional arguments > > aren't legal in 2.4 either (I'm not sure when/if they ever were). Maybe > > quixote used to generate different actual Python code than it does now > > in this case? Anyway, I'm pretty certain the patch for the SyntaxError > > will work with python2.4, but I'll check tomorrow. > Great, thanks a lot! It still works for me when I replace "#!/usr/bin/env python" with "#!/usr/bin/env python2.4" in /usr/share/destar/python/destar.py. -- John Wright <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501207: destar: Fails to run with python2.5
On Tue, Oct 07, 2008 at 08:42:26AM +0300, Faidon Liambotis wrote: > John, hi, > > John Wright wrote: > > The above problem is actually the same as bug 501207. However, with > > that patch applied, I get the following problem starting destar: > > > The attached patch fixes the SyntaxError. > Thanks a lot for these patches! > > I have absolutely no clue about python and I don't think anyone in the > team does -- which effectively means that we need all the help we can get. > > So, bear with me if this is a silly question: I was under the impression > that lenny will be shipped with both python 2.4 and 2.5 and that these > should be co-installable. Yes, lenny will have both python2.4 and python2.5. One workaround, at least for the compiler.ast.From problem, would be to run destar with #!/usr/bin/python2.4 instead of #!/usr/bin/python. But I think it better to fix the bug rather than try to work around it, if possible. > Are your fixes backwards compatible? It'd suck to fix this only to have > a bug report the day after "fails to run with python2.4" :) I made sure the fix for #501207 was backwards-compatible. As for the SyntaxError problem, I'm surprised it ever worked at all. Function definitions with optional arguments before required positional arguments aren't legal in 2.4 either (I'm not sure when/if they ever were). Maybe quixote used to generate different actual Python code than it does now in this case? Anyway, I'm pretty certain the patch for the SyntaxError will work with python2.4, but I'll check tomorrow. -- John Wright <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501207: destar: Fails to run with python2.5
block 501207 by 484360
tags 501207 + patch
thanks
The above problem is actually the same as bug 501207. However, with
that patch applied, I get the following problem starting destar:
[EMAIL PROTECTED]:~$ destar
DeStar 0.2.2, Copyright (C) 2005 by Holger Schurig and contributors.
DeStar comes with ABSOLUTELY NO WARRANTY. This is free software,
you are welcome to redistribute it under certain conditions;
see the included files GPL-2.txt and COPYRIGHT.txt
Serving application 'page_main' on port 8080
warning: Computing default hostname
info: Medusa (V1.11) started at Mon Oct 6 18:08:53 2008
Hostname: neptune.jswright
Port:8080
Note: you need the cdr_sqlite3_custom module to have CDR and Stats
functionalities
Note: you don't seem to have access to /var/log/asterisk/master.db yet created
by cdr_sqlite3_custom. See INSTALL.txt for details.
Traceback (most recent call last):
File "/usr/share/destar/python/destar.py", line 139, in
pub.run()
File "/usr/share/destar/python/Server.py", line 168, in run
publisher = self.publishclass(self.approot)
File "/var/lib/python-support/python2.5/quixote/publish.py", line 107, in
__init__
self.root_namespace = _get_module(root_namespace)
File "/var/lib/python-support/python2.5/quixote/publish.py", line 32, in
_get_module
__import__(name)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 127, in
find_import_module
return self.loader.load_module(fullname, stuff)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 107, in
load_module
return _load_ptl(name, filename, file)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 82, in
_load_ptl
return _exec_module_code(code, name, filename)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 35, in
_exec_module_code
exec code in mod.__dict__
File "/usr/share/destar/python/page_main.ptl", line 74, in
m = __import__(s)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 127, in
find_import_module
return self.loader.load_module(fullname, stuff)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 107, in
load_module
return _load_ptl(name, filename, file)
File "/var/lib/python-support/python2.5/quixote/ptl_import.py", line 72, in
_load_ptl
code = compile_template(file, filename, output)
File "/var/lib/python-support/python2.5/quixote/ptl_compile.py", line 303, in
compile_template
template.compile()
File "/usr/lib/python2.5/compiler/pycodegen.py", line 111, in compile
tree = self._get_tree()
File "/var/lib/python-support/python2.5/quixote/ptl_compile.py", line 274, in
_get_tree
tree = parse(self.source, self.filename)
File "/var/lib/python-support/python2.5/quixote/ptl_compile.py", line 232, in
parse
raise SyntaxError(str(e), (filename, e.lineno, e.offset, e.text))
SyntaxError: non-default argument follows default argument (page_owner_cdr.ptl)
The attached patch fixes the SyntaxError.
--
John Wright <[EMAIL PROTECTED]>
--- destar-0.2.2.orig/page_owner_cdr.ptl
+++ destar-0.2.2/page_owner_cdr.ptl
@@ -239,7 +239,7 @@
return render()
-def cdrShowResults [html] (where=[], limit, offset, total = 0, field=_("Time_of_start"), order="DESC"):
+def cdrShowResults [html] (where, limit, offset, total = 0, field=_("Time_of_start"), order="DESC"):
if total == 0:
''
'--No records to Show--'
--- destar-0.2.2.orig/page_stats_cdr.ptl
+++ destar-0.2.2/page_stats_cdr.ptl
@@ -244,7 +244,7 @@
return render()
-def cdrShowResults [html] (where=[], limit, offset, total = 0, field="start", order="DESC"):
+def cdrShowResults [html] (where, limit, offset, total = 0, field="start", order="DESC"):
if total == 0:
''
'--No records to Show--'
Bug#491830: trac-mercurial: Can't synchronize with the repository / Repository checkins event provider (ChangesetModule) failed
retitle 491830 trac-mercurial: README file should contain updated configuration information severity 491830 normal thanks Hi Christoph, On Tue, Jul 22, 2008 at 11:17:20AM +0200, Christoph Haas wrote: > Package: trac-mercurial > Version: 0.11.0.5dev~svnr7354-1 > Severity: grave > Justification: renders package unusable > > It appears like the 0.11.05dev version of the the trac-mercurial package isn't > working at all here. I get this warning on every page: > > Warning: Can't synchronize with the repository (Unsupported version > control system "hg". Check that the Python support libraries for "hg" are > correctly installed.) > > The "Timeline" view in Trac gives this additional message: > > Repository checkins event provider (ChangesetModule) failed: > TracError: Unsupported version control system "hg". Check that the Python > support libraries for "hg" are correctly installed. > > In my Trac config file I added these lines: > > [trac] > repository_dir = /path/to/my/repository > repository_type = hg > > [components] > trac.versioncontrol.hg.* = enabled > # This has changed from the following line apparently: > #tracvc.hg.* = enabled Can you try: [components] tracext.hg.* enabled in the Trac config file (from http://trac.edgewall.org/wiki/TracMercurial#Settingupthemercurialplugin) I guess upstream's README is ancient. If this fix doesn't work for you, feel free to change the bug title and severity back. Meanwhile, I'll patch the README file and file a bug upstream. -- John Wright <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443641: [Piuparts-devel] Bug#443641: piuparts: UnboundLocalError: local variable 'deps_info' referenced before assignment
On Sun, Sep 23, 2007 at 02:22:10PM +1000, Aníbal Monsalve Salazar wrote: > Package: piuparts > Severity: serious > Version: 0.27 > > After upgrading piuparts today, it dies as so: > > 3m32.9s DUMP: > (Reading database ... 5051 files and directories currently installed.) > Removing screenkast ... > Purging configuration files for screenkast ... > 3m32.9s DEBUG: Command ok: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', '--purge', > 'screenkast'] > 3m32.9s DEBUG: Starting command: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', > '--remove', '--pending'] > 3m32.9s DEBUG: Command ok: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', '--remove', > '--pending'] > 3m32.9s DEBUG: Starting command: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', > '--purge', '--pending'] > 3m33.0s DEBUG: Command ok: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', '--purge', > '--pending'] > 3m33.0s DEBUG: Starting command: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', > '--remove', '--pending'] > 3m33.0s DEBUG: Command ok: ['chroot', '/tmp/tmpZuDmDw', 'dpkg', '--remove', > '--pending'] > 3m33.0s DEBUG: Starting command: ['chroot', '/tmp/tmpZuDmDw', 'umount', > '/proc'] > 3m33.0s DEBUG: Command ok: ['chroot', '/tmp/tmpZuDmDw', 'umount', '/proc'] > Traceback (most recent call last): > File "/usr/sbin/piuparts", line 1471, in ? > main() > File "/usr/sbin/piuparts", line 1436, in main > args, packages): > File "/usr/sbin/piuparts", line 1050, in install_purge_test > return check_results(chroot, root_info, file_owners, deps_info=deps_info) > UnboundLocalError: local variable 'deps_info' referenced before assignment Agh! This is my fault. I tested with and without --warn-on-others, but apparently I didn't test without --apt. I'm about to commit the fix. Sorry about that. -- John Wright <[EMAIL PROTECTED]>
Bug#441188: Missing Build-Depends
tags 441188 +patch thanks Hello, Adding libnm-util-dev to the Build-Depends fixes the build for me. -- John Wright <[EMAIL PROTECTED]> diff -r eeb406871960 -r d938290990ac debian/control --- a/debian/control Mon Sep 10 01:25:52 2007 -0600 +++ b/debian/control Mon Sep 10 01:32:07 2007 -0600 @@ -2,7 +2,7 @@ Section: net Section: net Priority: optional Maintainer: Soren Hansen <[EMAIL PROTECTED]> -Build-Depends: cdbs, debhelper (>= 5), network-manager-dev, automake1.9, gnome-common, intltool, libgnomeui-dev, libdbus-glib-1-dev, patchutils +Build-Depends: cdbs, debhelper (>= 5), network-manager-dev, automake1.9, gnome-common, intltool, libgnomeui-dev, libdbus-glib-1-dev, patchutils, libnm-util-dev Standards-Version: 3.7.2 Package: network-manager-openvpn
Bug#441189: Missing Build-Depends
tags 441189 +patch thanks Hello, Looks like you need to add "libnm-util-dev" to the list of Build-Depends. The attached patch fixes the build for me. -- John Wright <[EMAIL PROTECTED]> diff -r e7f4f0eef040 -r 00874119ee55 debian/control --- a/debian/control Mon Sep 10 00:53:39 2007 -0600 +++ b/debian/control Mon Sep 10 00:59:31 2007 -0600 @@ -2,7 +2,7 @@ Section: net Section: net Priority: optional Maintainer: Soren Hansen <[EMAIL PROTECTED]> -Build-Depends: cdbs, debhelper (>= 5), network-manager-dev, automake1.9, gnome-common, intltool, libgnomeui-dev, libdbus-glib-1-dev, patchutils +Build-Depends: cdbs, debhelper (>= 5), network-manager-dev, automake1.9, gnome-common, intltool, libgnomeui-dev, libdbus-glib-1-dev, patchutils, libnm-util-dev Standards-Version: 3.7.2 Package: network-manager-vpnc
Bug#359095: dh-kpatches: bugs in apply perl script
On Sun, Jul 15, 2007 at 12:49:11AM +0200, Cyril Brulebois wrote: > tag 359095 patch > thanks > > John Wright <[EMAIL PROTECTED]> (15/02/2007): > > tags + patch > > thanks > > You were missing the bug number, your patch didn't appear (e.g. on the > list of RC bugs). Whoops! Thanks for correcting... -- John Wright -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431248: [Piuparts-devel] Bug#431248: piuparts: AssertionError
On Wed, Jul 04, 2007 at 07:18:03PM +0200, Ana Guerrero wrote: > On Wed, Jul 04, 2007 at 11:15:12AM -0600, John Wright wrote: > > tags 431248 +pending > > thanks > > > > On Wed, Jul 04, 2007 at 06:09:43PM +0200, Ana Guerrero wrote: > > > On Sun, Jul 01, 2007 at 04:45:44PM +1000, Aníbal Monsalve Salazar wrote: > > > > I'm getting the following messages after upgrading piuparts today: > > > > > > > > Traceback (most recent call last): > > > > File "/usr/sbin/piuparts", line 1232, in ? > > > > main() > > > > File "/usr/sbin/piuparts", line 1217, in main > > > > if install_and_upgrade_between_distros(args, packages): > > > > File "/usr/sbin/piuparts", line 936, in > > > > install_and_upgrade_between_distros > > > > root_info = chroot.save_meta_data() > > > > File "/usr/sbin/piuparts", line 621, in save_meta_data > > > > assert dirpath[:4] == root > > > > AssertionError > > > > > > > > > > This bug is caused by m4. From piuparts-0.21/Makefile : > > > > > > piuparts.py: piuparts.py.in > > > m4 -D __PIUPARTS_VERSION__=$$(dpkg-parsechangelog | grep ^Version: \ > > > | cut -d' ' -f2) < $< > $@ > > > > > > m4 not only replaces __PIUPARTS_VERSION__ for the current version, it > > > makes > > > another weird substitutions in the piuparts.py that triggers this problem. > > > [1]. If somebody speaks m4 and know what this happens please share it :D > > > > Ok, fixed by using m4's "-P" option. Now, we get something more like > > what was indended: > > > > > > [EMAIL PROTECTED]:~/debian/piuparts/trunk$ make piuparts.py > > m4 -P -D __PIUPARTS_VERSION__=$(dpkg-parsechangelog | grep ^Version: | cut > > -d' ' -f2) < piuparts.py.in > piuparts.py > > [EMAIL PROTECTED]:~/debian/piuparts/trunk$ diff -u piuparts.py.in > > piuparts.py > > --- piuparts.py.in 2007-07-03 23:34:30.0 -0600 > > +++ piuparts.py 2007-07-04 11:10:07.0 -0600 > > @@ -30,7 +30,7 @@ > > """ > > > > > > -VERSION = "__PIUPARTS_VERSION__" > > +VERSION = "0.22" > > > > > > import time > > > > > > I've committed the fix... > > > > See the mail I just send you about this... we were both commiting different > fixes for this almost at the same time :( > I would rather skip m4. Ana, Please feel free to revert and use sed. John
Bug#431248: [Piuparts-devel] Bug#431248: piuparts: AssertionError
tags 431248 +pending thanks On Wed, Jul 04, 2007 at 06:09:43PM +0200, Ana Guerrero wrote: > On Sun, Jul 01, 2007 at 04:45:44PM +1000, Aníbal Monsalve Salazar wrote: > > I'm getting the following messages after upgrading piuparts today: > > > > Traceback (most recent call last): > > File "/usr/sbin/piuparts", line 1232, in ? > > main() > > File "/usr/sbin/piuparts", line 1217, in main > > if install_and_upgrade_between_distros(args, packages): > > File "/usr/sbin/piuparts", line 936, in > > install_and_upgrade_between_distros > > root_info = chroot.save_meta_data() > > File "/usr/sbin/piuparts", line 621, in save_meta_data > > assert dirpath[:4] == root > > AssertionError > > > > This bug is caused by m4. From piuparts-0.21/Makefile : > > piuparts.py: piuparts.py.in > m4 -D __PIUPARTS_VERSION__=$$(dpkg-parsechangelog | grep ^Version: \ > | cut -d' ' -f2) < $< > $@ > > m4 not only replaces __PIUPARTS_VERSION__ for the current version, it makes > another weird substitutions in the piuparts.py that triggers this problem. > [1]. If somebody speaks m4 and know what this happens please share it :D Ok, fixed by using m4's "-P" option. Now, we get something more like what was indended: [EMAIL PROTECTED]:~/debian/piuparts/trunk$ make piuparts.py m4 -P -D __PIUPARTS_VERSION__=$(dpkg-parsechangelog | grep ^Version: | cut -d' ' -f2) < piuparts.py.in > piuparts.py [EMAIL PROTECTED]:~/debian/piuparts/trunk$ diff -u piuparts.py.in piuparts.py --- piuparts.py.in 2007-07-03 23:34:30.0 -0600 +++ piuparts.py 2007-07-04 11:10:07.0 -0600 @@ -30,7 +30,7 @@ """ -VERSION = "__PIUPARTS_VERSION__" +VERSION = "0.22" import time I've committed the fix... John
Bug#425639: pciutils (Priority: standard) depends on libpci2 (Priority: optional)
Package: pciutils Version: 1:2.2.4~pre4-1 Severity: serious Justification: Policy 2.5 pciutils depends on libpci2, but libpci2 is of lower priority. According to Policy 2.5, "Packages must not depend on packages with lower priority values (excluding build-time dependencies)." You mentioned in #399161 that you planned to drop the libpci2 dependency after etch anyway--here's another reason to do so. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages pciutils depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libpci2 2:2.1.11-3 Obsolete shared library for access pciutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410944: python-numpy: trying to overwrite `/usr/lib/python2.4/site-packages/numpy/f2py/src/fortranobject.h'
This seems to be caused by the fix for #410067. After looking at that bug, it seems to me that these files really should be in python-numpy and not in python-numpy-dev. Or maybe f2py ought to go into python-numpy-dev? John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359095: dh-kpatches: bugs in apply perl script
tags + patch
thanks
> Package: dh-kpatches
> Version: 0.100.1
> Severity: grave
> Tags: experimental
> Justification: renders package unusable
>
> I built a kernel-patch package for the hard disk queue freezing patch
> that is used with the IBM ThinkPad HDAPS support code. It was built with
> dh-kpatches 0.100.1, and I was told by a user that this package does not
> work. The following errors are made in the apply perl script:
>
> a) line 63
> if (defined $DEBPATCHFILES[$IDX] ...
> is the wrong test since an empty string is defined in perl.
> It should be
> if( not ($DEBPATCHFILES[$IDX] eq "")
I think it really should be checking for definedness. Just in case,
I've added a check for empty string as well in the attached patch.
> b) line 153
> printf 'Disk queue freezing support (queuefreeze)"
> has inconsistent quotation marks
I've fixed this in the attached patch...
In any case, neither of these problems exist in the version in unstable
-- can you use it instead of the one in experimental for now?
John
diff -Nur dh-kpatches-0.100.1.orig/dh-kpatches.nw dh-kpatches-0.100.1/dh-kpatches.nw
--- dh-kpatches-0.100.1.orig/dh-kpatches.nw 2003-12-16 01:54:17.0 -0700
+++ dh-kpatches-0.100.1/dh-kpatches.nw 2007-02-15 01:01:38.0 -0700
@@ -241,7 +241,7 @@
our $STRIPLEVEL=$STRIPLEVELS[$IDX];
our $PATCHFILE;
-if (defined $DEBPATCHFILES[$IDX] and
+if (defined $DEBPATCHFILES[$IDX] and $DEBPATCHFILES[$IDX] ne "" and
(-r 'version.Debian' or -r 'README.Debian' )) {
$PATCHFILE=$DEBPATCHFILES[$IDX];
} else {
@@ -350,7 +350,7 @@
mkdir -p \${docdir}
(
-printf '#PATCHNAME# (#PATCHID#)"
+printf '#PATCHNAME# (#PATCHID#)'
EOF
;
print REGISTER "printf 'for kernel $ENV{KPATCH_#CLEANPATCHID#},'\n"
Bug#381907: Proposed patch
tags 381907 +patch thanks Hello, I have attached an adaptation of upstream's "hotfix" from http://twiki.org/cgi-bin/view/Codev/SecurityAlertSecureFileUploads . The patch adds a patch in debian/patches, so please remember to run 'debian/rules patch' before building the package, so that the patch will be applied. Thanks, John Wright === added file 'debian/patches/upstream-Codev.SecurityAlertSecureFileUploads.patch' --- debian/patches/upstream-Codev.SecurityAlertSecureFileUploads.patch 1970-01-01 00:00:00 + +++ debian/patches/upstream-Codev.SecurityAlertSecureFileUploads.patch 2006-08-24 18:37:39 + @@ -0,0 +1,27 @@ +--- debian/apache.conf 2006-08-24 18:25:47 + debian/apache.conf 2006-08-24 18:33:57 + +@@ -12,4 +12,23 @@ + Allow from all + + ++ ++Options None ++AllowOverride None ++Allow from all ++ ++# Disable interpreting of php in the pub directory ++ ++php_admin_flag engine off ++ ++ ++php3_engine off ++ ++ ++# This line will redefine the mime type for the most common ++# types of scripts. It will also deliver HTML files as if ++# they are text files ++AddType text/plain .html .htm .shtml .php .php3 .phtml .phtm .pl .py .cgi ++ ++ + # End twiki Configuration Block +
Bug#381907: Better patch
Whoops, I forgot to include a regex fix in lib/TWiki.cfg in the last
patch. Here's an updated patch.
This time, I've attached the file that goes into debian/patches rather
than a patch that adds a patch to debian/patches. Sorry if the last one
caused any confusion...
Thanks,
John Wright
=== modified file 'debian/apache.conf'
--- debian/apache.conf 2006-08-24 19:13:04 +
+++ debian/apache.conf 2006-08-24 19:16:54 +
@@ -12,4 +12,23 @@
Allow from all
+
+Options None
+AllowOverride None
+Allow from all
+
+# Disable interpreting of php in the pub directory
+
+php_admin_flag engine off
+
+
+php3_engine off
+
+
+# This line will redefine the mime type for the most common
+# types of scripts. It will also deliver HTML files as if
+# they are text files
+AddType text/plain .html .htm .shtml .php .php3 .phtml .phtm .pl .py .cgi
+
+
# End twiki Configuration Block
=== modified file 'lib/TWiki.cfg'
--- lib/TWiki.cfg 2006-08-24 19:13:04 +
+++ lib/TWiki.cfg 2006-08-24 19:16:33 +
@@ -116,7 +116,7 @@
# WARNING: Be sure to update this list with any
# configuration or script filetypes that are
# automatically run by your web server
-$uploadFilter = "^(\.htaccess|.*\.(?:php[0-9s]?|phtm[l]?|pl|py|cgi))\$";
+$uploadFilter =
"^(\.htaccess|.*\.(?i)(?:php[0-9s]?(\..*)?|[sp]htm[l]?(\..*)?|pl|py|cgi))\$"
# Set ENV{'PATH'} explicitly for taint checks ( #!perl -T
option ) :
# (Note: PATH environment variable is not changed if set to
"")
# $safeEnvPath - safe operating system PATH setting for use by TWiki scripts.
Bug#383823: Proposed patch
tags 383823 +patch
thanks
This seems to be fixed in version 2.2.1 upstream. I've attached a patch
that patches the affected file up to the version in 2.2.1. It works for
me.
Thanks,
John Wright
=== added file 'debian/patches/gap_thumbnail-free.diff'
--- debian/patches/gap_thumbnail-free.diff 1970-01-01 00:00:00 +
+++ debian/patches/gap_thumbnail-free.diff 2006-08-24 02:05:50 +
@@ -0,0 +1,46 @@
+--- gimp-gap-2.2.0/gap/gap_thumbnail.c 2004-04-30 12:08:22.0 -0600
gimp-gap-2.2.1/gap/gap_thumbnail.c 2006-05-31 03:58:29.0 -0600
+@@ -42,7 +42,6 @@
+ #include "config.h"
+
+ /* SYSTEM (UNIX) includes */
+-#include
+ #include
+ #include
+ #include
+@@ -53,6 +52,8 @@
+ #include
+ #include
+
++#include
++
+ #ifdef G_OS_WIN32
+ #include
+ # ifndef S_ISDIR
+@@ -295,7 +296,7 @@
+);
+ g_object_unref(pixbuf);
+ }
+- g_free(thumbnail);
++ g_object_unref(thumbnail);
+ }
+ g_free(dst_png_thumb_full);
+ }
+@@ -450,7 +451,7 @@
+ if(gap_lib_file_exists(png_thumb_full) == 1)
+ {
+ if (gap_debug) printf ("gap_thumb_file_delete_thumbnail:
png_thumb_full: %s\n", png_thumb_full);
+- remove(png_thumb_full);
++ g_remove(png_thumb_full);
+ }
+ g_free(png_thumb_full);
+ }
+@@ -600,7 +601,7 @@
+ *th_bpp = nchannels;
+
+ }
+-g_free(thumbnail);
++g_object_unref(thumbnail);
+ }
+
+ return (pixbuf);
Bug#384112: Proposed patch
tags 384112 +patch
thanks
I have attached a patch that updates freeloader to the new Python
policy, which ought to fix this bug.
Thanks,
John Wright
=== added file 'debian/pycompat'
--- debian/pycompat 1970-01-01 00:00:00 +
+++ debian/pycompat 2006-08-24 00:16:43 +
@@ -0,0 +1,1 @@
+2
=== modified file 'debian/control'
--- debian/control 2006-08-23 23:50:14 +
+++ debian/control 2006-08-24 00:16:43 +
@@ -2,13 +2,14 @@
Section: net
Priority: optional
Maintainer: Julien Valroff <[EMAIL PROTECTED]>
-Build-Depends-Indep: debhelper (>= 5.0.0), cdbs, findutils (>= 4.1.7),
imagemagick (>= 6), python (>= 2.3), python-gtk2 (>= 2.6), python-gnome2 (>=
2.10), bittorrent (>= 3.4), bittorrent (<< 4.0)
+Build-Depends-Indep: debhelper (>= 5.0.37.2), cdbs, findutils (>= 4.1.7),
imagemagick (>= 6), python (>= 2.3), python-gtk2 (>= 2.6), python-gnome2 (>=
2.10), bittorrent (>= 3.4), bittorrent (<< 4.0), python-central (>= 0.5)
Standards-Version: 3.6.2
+XS-Python-Version: all
Package: freeloader
Architecture: all
Depends: ${python:Depends}, python-gtk2 (>= 2.6), python-gnome2 (>= 2.10),
bittorrent (>= 3.4), bittorrent (<< 4.0), python-glade2 (>= 2.6), librsvg2-2
-Recommends: python-gnome2-extras (>= 2.6), python2.3-gamin
+Recommends: python-gnome2-extras (>= 2.6), python-gamin
Description: A nice GNOME download manager supporting torrents
Freeloader is a nice GNOME download manager written in Python
and supporting torrents. Its main features are:
@@ -21,3 +22,4 @@
* Support for retrieval from most URLs (ftp, http, etc)
* Support for hiding in system tray
* Interruptible downloads
+XB-Python-Version: ${python:Versions}
=== modified file 'debian/rules'
--- debian/rules2006-08-23 23:50:14 +
+++ debian/rules2006-08-24 00:16:43 +
@@ -8,4 +8,5 @@
convert -density 255 -background none -size 160x160 -resize 32x32 \
$(CURDIR)/share/pixmaps/freeloader_icon.svg \
$(CURDIR)/debian/freeloader/usr/share/pixmaps/freeloader.xpm
+ dh_pycentral
dh_python
Bug#365146: joy2key: FTBFS with new X packages: Bad link line
Daniel Schepler wrote: > Package: joy2key > Version: 1.6.1-2 > Severity: serious > > From my pbuilder build log: > > ... > checking for X... libraries , headers in standard search path > ... > i486-linux-gnu-gcc -Wall -g -O2 -o joy2key joy2key.o -L -lX11 > joy2key.o: In function `argtokey': > /tmp/buildd/joy2key-1.6.1/joy2key.c:734: undefined reference to > `XStringToKeysym' > /tmp/buildd/joy2key-1.6.1/joy2key.c:736: undefined reference to > `XKeysymToKeycode' > ... > collect2: ld returned 1 exit status > make[2]: *** [joy2key] Error 1 > make[2]: Leaving directory `/tmp/buildd/joy2key-1.6.1' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/tmp/buildd/joy2key-1.6.1' > make: *** [build-stamp] Error 2 I've fixed the configure.ac file and regenerated the configure script. A fixed package is available at http://movingsucks.org/joy2key . I'll ask Dannf to upload it when I see him Monday; if somebody wants to sponsor it before then, I won't complain. :) John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349611: joy2key: breaks install
Gerfried Fuchs wrote: > severity 349611 grave > thanks > > Hi! > > This even breaks when dhelp isn't installed, making the package > uninstallable at all. The complete postinst script isn't needed, the > complete doc-base file for joy2key is wrong, none of the mentioned > targets within there does exist. I didn't include a postinst script... And it installs for me if I don't have doc-base installed. As for the doc-base issue, I accidentally left the dh_make-generated file in the package. I have fixed it; it should be uploaded soon. In the meantime, the package is available at http://movingsucks.org/joy2key . Sorry for the bug! I'm still a little new at this. John signature.asc Description: OpenPGP digital signature
Bug#346404: Patch: remove xlibs-dev build-depends
Package: xjig Followup-For: Bug #346404 I have attached a patch to replace the xlibs-dev Build-Depends with the correct packages. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.6-xenU Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) xlibs-dev-fix.patch Description: Binary data
Bug#346396: Patch: fix build-depends on xlibs-dev
Package: floatbg Followup-For: Bug #346396 I have attached a patch which removes the xlibs-dev build dependency and adds the specific packages actually needed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.6-xenU Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) xlibs-dev-fix.patch Description: Binary data
Bug#337997: Patch: fix build-depends
Package: xine-lib Followup-For: Bug #337997 I have attached a patch which removes the xlibs-dev build-dependency and adds the specific packages actually needed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.6-xenU Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) xlibs-dev.patch Description: Binary data
Bug#334124: aime: Still fails to build
Strange, it builds fine for me on both ia64 and x86 with this patch. This looks suspiciously like bug #292953. I've been working on version 0.60.3-7.1, which includes (most of) a patch submitted to that bug. For some reason, although that patch includes the change that I submitted above, it was left out in the NMU. Does it not build on other architectures than x86 and ia64? John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334124: Patch
Hello,
I've attached a patch that allows aime to build on 64-bit platforms.
I'm not sure how (or if) this actually worked on anything before. fputc
takes a char, and the original code passed an integer-cast pointer to char.
John
diff -Nur aime-0.60.3-orig/src/editor.cpp aime-0.60.3/src/editor.cpp
--- aime-0.60.3-orig/src/editor.cpp 2001-09-29 06:20:21.0 -0600
+++ aime-0.60.3/src/editor.cpp 2005-10-23 15:32:07.368929533 -0600
@@ -649,7 +649,7 @@
while (tmp_lin != NULL)
{ fputs(tmp_lin->the_line.str_show(),fp);
-fputc((int)"\n",fp);
+fputc('\n',fp);
tmp_lin = tmp_lin->next_line;
}
return 1;
