On Sun, Mar 07, 2010 at 11:00:45PM +0100, Rene Engelhard wrote:
And dist-upgrade (or full-upgrade I think is what aptitude calls it)?
apt-get dist-upgrade, aptitude dist-upgrade and aptitude
full-upgrade all give the same error as safe-upgrade.
Who said that safe-upgrade will work in all
Hi,
On Tue, Oct 27, 2009 at 06:21:24AM +0100, Fabio Rosciano wrote:
thanks for helping out.
Here it is, I can't see anything funny:
[...]
Yes, the logs are pretty much the same as when I did the upgrade, except
I did not have libc6-dev-i386 installed and I went to 2.10.1-1 from
2.9-27.
On Mon, Oct 26, 2009 at 09:02:22AM +0100, Fabio Rosciano wrote:
On Mon, 2009-10-26 at 08:10 +0100, Aurelien Jarno wrote:
Do you have the list of packages that have been upgraded?
I wish I did, but as soon as debconf asked would you like to upgrade
libc6 now? and I answered yes, the system
On Wed, Oct 21, 2009 at 12:01:51PM +0300, Eugene V. Lyubimkin wrote:
However, this is another side of already archived
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543365 (ironically, reported
by you too). On i386 we have the issue: libc6-i686 strictly Pre-Depends on
libc6 (= ...), and
Hi!
Reading the bug report, the $DISTRO check seems bogus.
- It depends on a conffile that is not part of the package. There is
_no_ guarantee that /etc/issue contains any string related to the
distribution.
- Why not just simply check for the presence of /lib/modules/$(uname
On Thu, May 29, 2008 at 12:48:50AM -0400, Eric Dorland wrote:
* Gábor Gombás ([EMAIL PROTECTED]) wrote:
Package: iceweasel
Version: 3.0~b5-4
Severity: grave
Justification: renders package unusable
Hi,
After upgrading xulrunner-1.9 I get the following when I want to run
On Thu, Apr 24, 2008 at 02:21:39PM -0500, John Hasler wrote:
Gabor writes:
That will be difficult since sometimes the bug does not hit for weeks and
then suddenly chrony starts to loop all the time.
Are you saying that you have seen the bug?
Yes, see bug #447011. In fact, #474294 is a
Hi,
On Wed, Jan 09, 2008 at 09:41:57AM +0200, Fabian Fagerholm wrote:
Something seems to go wrong with the debconf stuff. Did you get any
debconf prompts when upgrading the package?
Yes, about where to back up sasldb.
I can't seem to figure out why it would hang, though. Could you send the
Package: mozilla-venkman
Version: 0.9.87.2-1
Severity: critical
Tags: security
Justification: root security hole
Hi,
mozilla-venkman.preinst contains:
#! /bin/sh
find . -maxdepth 1 -mindepth 1 /tmp/fin
Just do an ln -s /etc/shadow /bin/fin as any user
Hi,
This bug seems to take an annoyingly long time to fix, so I tried to run
hald --daemon=no --verbose=yes under valgrind and I got:
==9630== Invalid read of size 1
==9630==at 0x4A07AC4: strcmp (mc_replace_strmem.c:341)
==9630==by 0x4C2E68D: (within /usr/lib/libdbus-1.so.3.4.0)
==9630==
On Thu, Aug 23, 2007 at 09:34:27AM +0200, Ondřej Surý wrote:
So package gets compiled against lidb4.5-dev headers and -ldb-4.4
libraries.
Yes, I also realized that I got the versioning wrong (I somehow thought
it linked to a version higher than the -dev package, but of course the
opposite is
On Tue, Aug 21, 2007 at 10:25:58PM +0200, Ondřej Surý wrote:
So question is where did you get that source code which you sent patch
for?
Oh, the patch is from the set I used for Cyrus builds at some other
place; actually it's against a post-2.3.8 CVS version. I forget to check
the sources of
On Sun, Aug 19, 2007 at 08:07:39PM +0200, Ondřej Surý wrote:
Correct fix would be to find why it didn't find libdb4.4.
The reason is in the comment of the proposed patch. Every libdbX.Y
Debian package installs the library as /usr/lib/libdb-X.Y.so, because
that's the SONAME of the Berkeley DB
On Tue, Aug 21, 2007 at 01:55:56PM +0200, Ondřej Surý wrote:
Now I see. You're right. But where did db-4.5 come from? 2.3.8-1
source from experimental doesn't have it, 2.3.8-1 source from subversion
doesn't have it. Is this your local modification?
I have no idea. Maybe some other
Package: cyrus-imapd-2.3
Version: 2.3.8-1
Severity: grave
Tags: patch
Justification: renders package unusable
Hi,
On AMD64, all daemons and database tools die complaining that they were
compiled against db-4.4 headers but were linked against db-4.5. For
local Cyrus builds I have used the
Package: libsuitesparse
Version: 3.0.0-4
Severity: serious
Justification: Policy 2.2.1
$ apt-cache show libsuitesparse
[...]
Depends: [...], libparmetis3.1
[...]
$ apt-cache show libparmetis3.1
[...]
Section: non-free/libs
[...]
Gabor
-- System Information:
Debian Release: lenny/sid
APT
On Sat, Jul 15, 2006 at 08:42:56AM +0200, Julien Danjou wrote:
In file included from /usr/include/linux/cpumask.h:86,
from /usr/include/asm-i486/processor.h:23,
from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:6,
On Tue, Jan 24, 2006 at 09:44:59PM +0100, Sylvain Le Gall wrote:
Was it during the synchronisation phase (when effectively doing
operation) or before (when calculating changes) ?
I don't really know, I was not sitting in front of the machine during
the synchronization. I only realized the end
Package: unison
Version: 2.13.16-4
Severity: critical
Justification: causes serious data loss
Hi,
I'm regularly replicating my home directory to an USB harddisk using
unison. This morning the USB drive got disconnected during the
synchronization (hw error). Instead of noticing that one of the
19 matches
Mail list logo
