Package: vips
Version: 7.10.16-1
Severity: serious
Justification: Policy 8.1, 8.6
Hi, Jay.
At least on amd64, VIPS's shared libraries appear to have changed
names from libvips(CC).so.10.8.0 to libvips(CC).so.9.9.1, which not
only breaks anything built against the previous release but also
-alternatives --remove x-cursor-theme $x
done
;;
esac
#DEBHELPER#
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
the components without trouble.
Do you have any idea how to fix the problem?
As I said, I believe you need to create wrappers.
Thanks.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email
a line, so
I can ask my sponsor to upload the package.
Your proposed new release works great; feel free to pass it along to
your sponsor.
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info
Package: gnunet-gtk
Version: 0.7.0a-1
Severity: grave
Justification: renders package unusable
For some reason, gnunet-gtk's control file specifies a hard-coded list
of (binary) dependencies; although this is technically legal, it's
prone to get out of date when transitions (such as libextractor's
contain a few tidbits of information that can be
of interest to users.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
just forgot about that, and I didn't consider the issue worth bugging
him about.)
Anyway, thanks for the report, which I'll try to address before too long.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info
didn't know it took all those arguments. :-)
Never underestimate the flexibility of (e)lisp. ;-)
Thanks for the quick reply!
You're welcome.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE
Package: subversion
Version: 1.1.4-2.1
Severity: normal
File: /usr/bin/svndumpfilter
Tags: patch upstream
On amd64, and AFAICT any 64-bit platform, svndumpfilter dies fairly
quickly with the message svn: Can't write to stream: Invalid
argument. I tracked this down to the program's non-portable
Package: ocamlagrep
Version: 1.0-6
Severity: serious
Justification: Policy 3.5
When you reworked your packaging to stop hardcoding ocaml's
ever-changing ABI, you appear to have twice made an unfortunate typo,
neglecting to precede either occurrence of {F:OCamlABI} with a dollar
sign ($). As a
--- cinepaint-0.20-1/debian/changelog
+++ cinepaint-0.20-1/debian/changelog
@@ -1,3 +1,10 @@
+cinepaint (0.20-1-1.0) unstable; urgency=low
+
+ * Quasi-NMU.
+ * Fix Bracketing to HDR plugin to compile on 64-bit systems.
+
+ -- Aaron M. Ucko [EMAIL PROTECTED] Wed, 11 Jan 2006 11:05:10 -0500
+
cinepaint
Package: dmake
Version: 4.3+cvs20060104-3
Severity: serious
Justification: no longer builds from source
For whatever reason, dmake ships ancient versions of config.guess and
config.sub, dating from 2002 and 2001 respectively, resulting in some
Debian architectures being reported as [i]nvalid
, that should no longer be a concern, so I'll try to
remember to revert that change for my next upload. (Given that
4.0.2-4 also enabled the c2a transition, I assume I won't need any
GCC-related build-dependencies; please correct me if I'm mistaken.)
Thanks for the report.
--
Aaron M. Ucko, KB1CJC
Package: rus-ispell
Severity: serious
Justification: Policy 4.8
Although your control file properly lists aspell-ru as architecture
any, your rules inappropriately build it from the binary-indep target,
blocking it from being autobuilt. Could you please correct this?
Thanks.
-- System
Package: cameleon
Version: 1.9.9.cvs20051129-1
Severity: serious
Justification: fails to build from source
The latest cameleon package FTBFS on most architectures (except for
arm, where it evidently got lucky) because it tries to run convert
without a build dependency on imagemagick. Could you
Package: exim4-doc-info
Version: 4.60-1
Severity: grave
Justification: renders package unusable
exim4-doc-info seems to have wound up empty aside from some metadata
under /usr/share/doc; could you please restore the actual info files?
Thanks!
-- System Information:
Debian Release:
Package: oleo
Version: 1.99.16-8
Severity: important
oleo still depends on the old libxdb1c102 package, which is likely to
disappear from the archive soon; could you please rebuild against
libxdb-dev (= 1.2.0-6) to pick up the new libxdb1 package?
Thanks!
BTW, I investigated what was up with
Package: alsa-source
Version: 1.0.10-2
Severity: grave
Justification: renders package unusable
alsa-source's config script fails on my system (which has bash 3.1-1
installed as /bin/sh); AFAICT, the problem is constructs such as
ALSA_NOPNP=$(. /etc/alsa/alsa-source.conf /dev/null 21 ;
are now honored properly, per #332489).
Thanks for pointing out the discrepancy; I'll report it to upstream,
and expect they'll fix it for 1.1.7.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info
a file or
directory is being referenced. I've added the maintainer of that file
I'm pretty sure the message just means that gdb can't find ChkIfEv.c
to show you the actual contents of its line 57
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED
Package: mtr
Version: 0.58-1.0.0.1.pure64
Followup-For: Bug #254089
I just noticed (thanks to debsecan) that because of this bug, I still
have an old, patched version of mtr that's vulnerable to CVE-2004-1224.
Anyway, if you don't want to hardcode -lresolv, my suggestion would be
to adjust the
Package: g++-4.0
Version: 4.0.2-3
Followup-For: Bug #336463
My latest upload of fltk1.1 (1.1.6-9) runs into identical lossage on
mips and mipsel, on sources that did not change since before my
previous upload (which built fine), so G++ definitely appears to be
the culprit. Logs:
Package: debianutils
Version: 2.15.1
Severity: normal
Hi, Clint.
The utilities mktemp and tempfile both assume that if TMPDIR is set,
it points to a writable directory; although that's normally true, it's
not actually guaranteed to hold. (For example, I have a system with
libpam-tmpdir enabled
Package: libfile-mimeinfo-perl
Version: 0.12-3
Followup-For: Bug #340777
reopen 340777
thanks
You appear to have made a typo when introducing the new dependency:
The following packages have unmet dependencies:
libfile-mimeinfo-perl: Depends: libefile-desktopentry-perl but it is not
Package: rlpr
Version: 2.05-2
Severity: important
rlpr's new preinst script contains the line
[ -L /usr/doc/rlpr ] rm -f /usr/doc/rlpr
which causes the script to abort when there isn't already such a
symlink (because it's running in -e mode, per Policy 6.1). To avoid
this problem,
Package: python-codespeak-lib
Version: 0.7-svn20050721-2
Severity: grave
Justification: renders package unusable
python-codespeak-lib has a dependency on python (= 2.4); however,
Debian's python metapackage is still versioned 2.3.5-3, rendering the
python-codespeak-lib metapackage uninstallable
Package: x-window-system-core
Version: 6.9.0.dfsg.1-1
Severity: normal
Happy holidays, and congratulations on getting 6.9.0 out the door!
That said, I'm afraid I have a bug to report:
As noted in #334721, which I believe it's too late to reopen :-/, the
libgl1-mesa-dri should be an alternative
text
realname Aaron M. Ucko
email [EMAIL PROTECTED]
no-cc
header X-Debbugs-CC: [EMAIL PROTECTED]
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux
Package: muine
Version: 0.8.3-7
Severity: grave
Justification: renders package unusable
When muine jumped the gun on gtk-sharp2 2.3.91, it did so only for
i386; on other architectures, the autobuilders naturally continued to
use 1.9.5. As such, could you please reupload the package, preferably
Package: aqsis
Followup-For: Bug #324025
Please don't forget to upload a new revision with Andreas's fixes
applied. (Alternatively, may I NMU for this?)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture:
Package: yacas
Version: 1.0.57-2
Severity: serious
Tags: patch
Justification: no longer builds from source
As you may have heard, Debian is undertaking an ongoing transition to
G++ 4. This affects yacas, particularly given that yacas-proteus
could really stand to be rebuilt against current
Package: vdslib
Severity: grave
Justification: renders package unusable (uninstallable binaries)
libvds-dev still depends on the old libfltk1.1c102 package; please
rebuild it with GCC 4.0 and a recent version of libfltk1.1-dev
(1.1.6-6) or newer for the current C++ ABI transition.
AFAICT, this
concern.
Thanks; apologies for neglecting to check on an official architecture.
Rebuilding it for sarge doesn't make any sense here.
*nod*
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE
Package: microcode.ctl
Version: 1.12-1
Severity: normal
Somewhat confusingly, Debian's designation for Intel's new line of
64-bit x86-compatible processors is amd64 (after that architecture's
original designer), *not* ia64. (The latter is a radically different
architecture developed in
Package: rpm
Version: 4.4.1-2
Severity: important
On architectures such as amd64 with 32-bit cousins, rpm thinks it
should use /usr/lib64 for some things; while this may be true on Red
Hat systems, it misfires on Debian. (In particular, librpm4 is
effectively empty, and rpm lacks proper
Package: ace
Version: 5.4.7-4
Severity: serious
Justification: no longer builds from source
Given that the platforms on which ace still tries to build with gcc 4
are by and large still running into link problems such as #324271, I
would suggest dropping back to g++-3.4 on *all* platforms for the
Package: libcurl3-gnutls-dev, libcurl3-openssl-dev
Version: 7.15.0-1
Severity: serious
Justification: Policy 3.5
Your fix for #333609 appears to have backfired dramatically: because
bracketed architecture lists are legal only in *build*-depends,
dpkg-dev kindly swallowed the entire Depends:
Package: privoxy
Version: 3.0.3-5
Followup-For: Bug #314868
reopen 314868
thanks
Your fix for this bug only covered the case of invoking the init
script directly; please also suppress output when invoke-rc.d is
available (generally true nowadays).
Thanks.
-- System Information:
Debian Release:
everywhere to ensure compatibility
across systems?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
produces and parses.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Miriam Ruiz [EMAIL PROTECTED] writes:
You're right. I've modified the patch and i guess it's OK now :)
Yes, much better. Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email
Package: ecj-bootstrap-gcj
Version: 3.1.1-2
Severity: grave
Justification: renders package unusable
} Setting up ecj-bootstrap-gcj (3.1.1-2) ...
} /var/lib/dpkg/info/ecj-bootstrap-gcj.postinst: line 4: --slave: command not
found
} dpkg: error processing ecj-bootstrap-gcj (--configure):
}
Package: lilypond-data
Version: 2.6.3-4
Severity: serious
Justification: Policy 5.6.8, 9.1.1
Hi, Thomas.
lilypond-data appears to have gained an architecture-dependent file,
which is inappropriate both because the package is architecture-all
and because the file is under /usr/share:
$ dpkg -L
and not overriden in octave-mode AFAICT) and M-C-h
(bound to mark-defun by default, and overriden to octave-mark-defun in
octave-mode). If backspace is generating C-h rather than DEL, then
that's a misconfiguration on the user's part that will generally play
badly with Emacs.
--
Aaron M. Ucko
Package: libcommandline-ruby1.8
Version: 0.7.10-1
Severity: serious
Justification: Policy 9.10 (doc-base section 2.3)
The two files libcommandline-ruby1.8 installs in /usr/share/doc-base
lack Files fields, breaking installation on at least some
systems (those with doc-base installed?):
} Setting
sense, it should be okay to leave it as it is and
just rename the doc-base files as I suggested. Alternatively, you
could split it out into a new -common or -doc package, but the
ftpmasters might consider that to be overkill.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org
Package: neon26
Version: 0.26.2-2
Severity: serious
Justification: no longer builds from source
Your latest neon26 upload, while otherwise laudable, breaks on 64-bit
platforms because the library-renaming patch does not (fully) apply;
see, for instance,
Package: gtk-recordmydesktop
Version: 0.3.0r2-1
Severity: grave
Justification: renders package unusable
Although gtk-recordmydesktop uses python-central, it lacks a proper
Python-Version: field, and consequently gets stuck in a half-installed
state from which one cannot even back it out without
Incidentally, why is the package architecture: any rather than all?
Its actual contents appear to be entirely architecture-independent.
I'm tempted to wonder whether its sponsor reviewed it at all.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED
Package: quinn-diff
Version: 0.65
Severity: important
[Resending, as the first copy I sent Friday afternoon seems to have
vanished without a trace.]
AFAICT, quinn-diff's version-comparison code originates from an
ancient version of dpkg that didn't support tildes in version numbers;
as a result,
Package: xchat
Version: 2.6.4-2
Severity: grave
Justification: renders package unusable
xchat depends on having an identical version of xchat-common, which is
fine for regular uploads but breaks on binary-only NMUs, such as the one
that just happened for the libdbus-1-3 transition. To correct
Package: gnucash
Version: 2.0.1-2
Severity: grave
Justification: renders package unusable
Hi, Thomas!
gnucash depends on having an identical version of gnucash-common,
which is fine for regular uploads but breaks on binary-only NMUs, such
as the one that just happened for the libdbus-1-3 and
Package: quinn-diff
Version: 0.65
Severity: important
AFAICT, quinn-diff's version-comparison code originates from an
ancient version of dpkg that didn't support tildes in version numbers;
as a result, it incorrectly treats foo~bar as NEWER than foo.
One practical effect of this is that the
Package: ggz-gtk-games
Version: 0.0.13-2
Severity: grave
Justification: renders package unusable (uninstallable)
ggz-gtk-games continues to depend on ggz-gtk-game-data
(= ${Source-Version}), although the data package is now called
ggz-gtk-games-data. Please correct this discrepancy.
Thanks!
--
Package: lush
Version: 1.2-1
Followup-For: Bug #350409
Not only does binary-arch continue to build lush-library, it fails to
build lush. Please swap the rules, such that binary-*arch* invokes
dh_xxx with -a and binary-*indep* invokes dh_xxx with -i.
Thanks!
-- System Information:
Debian
Package: lush
Version: 1.2-1
Severity: important
lush's dependency on lush-library (= ${Source-Version}) will be
impossible to fulfill if lush undergoes a binary-only NMU for whatever
reason; please add a versioned build dependency on
dpkg-dev (= 1.13.19) and change the dependency on lush-library
at it? The fix is a
one-liner, and upstream applied it three months ago:
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_render.c?r1=1.49r2=1.50view=patch
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info
Package: bitcollider-plugins
Version: 0.4.0-3.2
Severity: grave
Justification: renders package unusable
For whatever reason, bitcollider-plugins has a hard-coded dependency
on bitcollider (= 0.4.0-3), which is no longer in unstable; even if
you remember to keep the dependency current in your
Package: bmpx
Version: 0.32.0-1
Severity: important
On 64-bit platforms, bmpx fails to detect that libc includes gettext; as
such, it unnecessarily builds its own version, and proceeds to ship a
copy of locale.alias that conflicts with the standard system one (in
locales or belocs-locales-data).
Package: nethack-x11
Version: 3.4.3-9
Severity: grave
Justification: renders package unusable
Greetings.
I'm sorry to say your fix for #362331 was somewhat off -- nh10.pcf.gz
is now getting installed *as* rather than *in* /usr/share/fonts/misc,
presumably because you forgot to ensure that the
Package: erlang-base-hipe
Version: 1:11.b.1.dfsg-1
Severity: normal
erlang-base(-hipe)'s post-installation and pre-removal scripts search
for services that depend on erlang by running dpkg -S individually on
each file in /etc/init.d. While this is technically valid, it can
take a *very* long
Package: python-4suite-rdf
Version: 1.0~rc4cvs20061016-1
Severity: grave
Justification: renders package unusable (uninstallable)
dpkg: error processing
/var/cache/apt/archives/python-4suite-rdf_1.0~rc4cvs20061016-1_amd64.deb
(--unpack):
trying to overwrite
Aaron M. Ucko [EMAIL PROTECTED] writes:
Adding --disable-error-on-warning to configure_args in debian/rules
lets the warnings remain warnings and the build get further; however,
the test suite still encounters a few failures at runtime. :-/
To wit:
FAIL: numbers.test: max: big / real: (= big
Package: texlive-lang-spanish
Version: 2005.dfsg.1-1
Severity: important
texlive-lang-spanish fails to install on systems that still have teTeX
as a base (for instance, because a number of its reverse dependencies
have not yet declared support for TeXLive) because eshyph.tex tries to
\input
packages; having maintained a large public TeX
installation in the past, I truly appreciate the Debian team's work.
(I'm afraid I don't have time to help aside from sending occasional
bug reports, though.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED
I see this too; Ubuntu's 017_en_US_UTF-8_XI18N_OBJS.diff (attached,
and only partially applied upstream AFAICT) corrects the references to
nonexistent shared objects, which look like an accidental regression
on upstream's part incurred when switching to git.
--
Aaron M. Ucko, KB1CJC (amu
Package: exim4-config
Version: 4.63-4
Severity: wishlist
File: /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs
/etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs currently
defines MAIN_LOG_SELECTOR unconditionally; could you please
conditionalize it on .ifndef MAIN_LOG_SELECTOR so that
Package: qc-usb-source
Version: 0.6.4-4
Followup-For: Bug #389342
tags 389342 + patch
thanks
Getting qc-usb-source to build under 2.6.18 just requires adding two
#include directives, one conditional, per the below patch; please
apply it when you get a chance.
Thanks!
diff -u
] sys_init_module+0x18a6/0x1a85
[80160752] system_call+0x7e/0x83
[2ab8f3af8a0c]
Code: 48 39 06 76 1d 83 c1 01 81 f9 de 00 00 00 75 07 b9 ff ff ff
RIP [883e22a7] :openafs:check_table+0x27/0x4c
RSP 81002554bd90
CR2: fffd
--
Aaron M. Ucko, KB1CJC (amu
Aaron M. Ucko [EMAIL PROTECTED] writes:
Getting qc-usb-source to build under 2.6.18 just requires adding two
#include directives, one conditional, per the below patch; please
apply it when you get a chance.
Minor correction: *both* headers appear to be new to 2.6.18, so please
conditionalize
Package: acl2
Version: 3.0.1-1
Followup-For: Bug #381477
AFAICT, the prior FTBFS was due to a gcl bug which has since been
fixed; as such, requeuing acl2 should resolve this bug.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500,
team (or else upload a build yourself if you have
access to a suitable machine).
Anyway, I believe I arranged for the amd64 buildd admins to get a copy
of my previous message, but I'm explicitly copying them now just in
case.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org
an internet
connection to look up CMAKE_CURRENT_BINARY_DIR in their wiki[2]?
My condolences. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
please address them as well, or at least
apply the suggested workaround (--disable-error-on-warning)?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Package: iceape-browser
Version: 1.0.6-1
Severity: grave
Justification: renders package unusable
iceape-browser crashes immediately on startup, even with my old
Mozilla profile moved aside. Here's what I got out of gdb:
(gdb) info registers
rax0x0 0
rbx0x905378
Mike Hommey [EMAIL PROTECTED] writes:
Could you also attach a strace ?
No problem; hope it helps.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
strace.iceape.bz2
Description: Binary data
Mike Hommey [EMAIL PROTECTED] writes:
Damn, I knew that, but I thought I fixed it :(
On the bright side, you shouldn't encounter any coordination-related
delays. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address
of having previously installed
(upgraded to) extension packages whose iceape support is somewhat off.
As such, could you please fix diggler, livehttpheaders, and
tabextensions to install their symlinks under /usr/share, and have
iceape-browser conflict with prior versions?
Thanks!
--
Aaron M. Ucko
stray symlink
(installed-chrome.txt), requiring a small amount of extra manual
cleanup.
At any rate, that seems to have been the only problem; with a proper
chrome setup, iceape starts normally.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid
Package: lyskom-elisp-client
Version: 0.48-6
Severity: critical
Justification: breaks unrelated software
/usr/lib/emacsen-common/packages/install/lyskom-elisp-client wipes out
all .el files under /usr/share/$FLAVOR/site-lisp, rather than just
lyskom-elisp-client.el; this hurts auctex, which
Package: svn-autoreleasedeb
Version: 0.11-1
Severity: grave
Justification: renders package unusable
The package containing /usr/bin/svn is named subversion (and is
already a dependency of svn-buildpackage anyway).
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
Package: libgdal1-1.3.2
Version: 1.3.2-1
Severity: important
Unpacking libgdal1-1.3.2 (from .../libgdal1-1.3.2_1.3.2-1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/libgdal1-1.3.2_1.3.2-1_amd64.deb
(--unpack):
trying to overwrite `/usr/share/gdal/cubewerx_extra.wkt', which is
to work around the issue by explicitly adding
--with-script-dir=/usr/share/yacas to configure's arguments in
debian/rules.
Thanks for the report.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE
Package: libgcj6
Version: 4.0.2-7
Severity: important
For some reason, attempting to convert decimal strings that correspond
to numbers below a certain threshold (between 4.24374e-214 and
4.24375e-214) to doubles (which should have an appreciably wider
range) ends up segfaulting within the guts
I've done a little more testing, with the following conclusions:
- The bug is also present in some older libgcj versions, including in
particular libgcj5 3.4.4-5 and libgcj6 4.0.2-6.
- The bug appears to be absent in gcc-snapshot 20051124-1.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu
=textr2=textdiff_format=u
Could you please apply that patch?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
Package: bind9
Version: 1:9.5.0.dfsg.P2-3
Severity: grave
Justification: renders package unusable (uninstallable)
The latest bind9 upload declares a dependency on lsb-base = 9.2.14,
which does not exist. Did you perhaps mean = 9.2-14, with a hyphen
in place of the second dot?
-- System
Package: swi-prolog-xpce
Version: 5.6.58-1
Severity: grave
Justification: renders package unusable (uninstallable)
Presumably as a side effect of switching to dh_install,
swi-prolog-xpce now contains at least one file already present in
swi-prolog:
Preparing to replace swi-prolog-xpce 5.6.57-1
Aaron M. Ucko [EMAIL PROTECTED] writes:
swi-prolog-xpce now contains at least one file already present in
swi-prolog:
FTR, further investigation reveals that to be a massive understatement.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http
Package: conduit
Version: 0.3.12-2
Severity: grave
Justification: renders package unusable (uninstallable)
$ aptitude -s install conduit
[...]
The following packages have unmet dependencies:
conduit: Depends: python-gconf which is a virtual package.
Depends:
Package: rubygems1.9
Version: 1.2.0-1
Severity: grave
Justification: renders package unusable (uninstallable)
Unpacking rubygems1.9 (from .../rubygems1.9_1.2.0-1_all.deb) ...
dpkg: error processing /var/cache/apt/archives/rubygems1.9_1.2.0-1_all.deb
(--unpack):
trying to overwrite
Package: qcad
Version: 2.0.5.0-1-3
Severity: serious
Justification: Policy 7.2
Given that qcad presumably still needs its architecture-independent
data, it should depend on the new qcad-data package that now contains
them.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
Package: ski
Version: 1.3.2-2.1
Severity: serious
File: /etc/init.d/ski
Justification: Policy 10.4
Despite specifying /bin/sh as its interpreter, /etc/init.d/ski makes
use of the bashism function when defining verify_binfmt_mnt. Could
you please fix it to use portable function-definition
Package: llvm-examples
Version: 2.2-8
Severity: grave
Justification: renders package unusable
The architecture-independent llvm-examples package is currently
uninstallable in fresh amd64 environments because it depends on an
identical version of the architecture-dependent llvm-dev package, but
extra
information, which the BTS can presumably at least arrange to ignore
for the time being if fully handling it is too involved.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
--
To UNSUBSCRIBE
Package: user-mode-linux
Version: 2.6.25-1um-1
Severity: serious
Tags: patch
Justification: no longer builds from source
user-mode-linux fails to build on amd64 with the following error:
| CC arch/um/sys-x86_64/ksyms.o
| arch/um/sys-x86_64/ksyms.c:16: error: '__memcpy' undeclared here
as their definition.
FWIW, that leads to warnings (which I'll trust to be harmless) about
memcpy already being exported. That said, I agree that there's no
sense in diverging from upstream any more than strictly necessary.
Will apply, and reupload later today. Thanks.
Thanks!
--
Aaron M. Ucko
Package: muscle
Version: 3.70+fix1-1
Severity: serious
Justification: Policy 6.6(4)
Could muscle please declare Conflicts: muscle-doc? As it stands, it
merely declares Provides: muscle-doc, which, while harmless and even
informative, serves little practical purpose given that muscle-doc's
only
Package: libsvn-ruby
Version: 1.4.6dfsg1-1
Severity: serious
Justification: Policy 2.3
libsvn-ruby no longer contains any content whatsoever, just an empty
/usr/share/doc directory; dpkg consequently classifies it as
disappeared, causing apt(itude) to consider libsvn-ruby1.8 orphaned
and propose
Package: python-netcdf
Version: 2.4.11-1+b1
Severity: grave
Justification: renders package unusable (uninstallable)
python-netcdf evidently depends on ${Source-Version} of the arch-all
python-scientific package; as such, binNMUs, as just occurred for the
libnetcdf transition, make it
1 - 100 of 3052 matches
Mail list logo
