Package: libreoffice
Version: 1:3.4.6-2
Severity: grave
Justification: renders package unusable
I am getting very strange and gravely bad input behavior anytime I have any
LibreOffice window open. I've tried it with both writer and calc; the same
things happen:
Keyboard input is delayed by a
Ping?
The patch given in message #40 of the bug archive solved the problem, and
has been running error-free continuously since. Just wondering if it's
been made part of the standard patches Debian applies to the original
upsteam source yet, or even better, pushed upstream for inclusion in the
I was trying to do a selective upgrade last weekend, and got hit by what
sounds exactly like this bug. It messed up both the available and the
status file. I keep a nice automated backup system running, so I restored
those two files from the last backup. Tried the upgrade again. Same
result.
On Sun, Jan 17, 2010 at 04:47:12PM -0800, Tim Kientzle wrote:
On Fri, Jan 15, 2010 at 08:06:54PM -0800, Carl Miller wrote:
cramfs takes a shortcut with device nodes, and assigns them all inode 1.
I presume it also assigns nlinks == 1?
That would appear to be the case. Here's the tail end
On Sat, Jan 16, 2010 at 05:09:45AM +, Clint Adams wrote:
You mean something like this?
diff --git a/src/copyout.c b/src/copyout.c
index 98f3895..f0741f7 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -121,7 +121,9 @@ count_defered_links_to_dev_ino (struct cpio_file_stat
On Mon, Jan 18, 2010 at 11:52:12AM -0800, Carl Miller wrote:
So now my question is, why do callers of add_inode() not check the
st_nlinks for being 1 first, like callers of add_link_defer()? Is
there some reason that it *should* be this way? If not, I'd propose
putting that check
On Mon, Jan 18, 2010 at 02:06:07PM -0800, Carl Miller wrote:
On Mon, Jan 18, 2010 at 11:52:12AM -0800, Carl Miller wrote:
So now my question is, why do callers of add_inode() not check the
st_nlinks for being 1 first, like callers of add_link_defer()? Is
there some reason
On Sat, Jan 16, 2010 at 05:09:45AM +, Clint Adams wrote:
You mean something like this?
diff --git a/src/copyout.c b/src/copyout.c
index 98f3895..f0741f7 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -121,7 +121,9 @@ count_defered_links_to_dev_ino (struct cpio_file_stat
Package: cpio
Version: 2.10-1
Severity: normal
cramfs takes a shortcut with device nodes, and assigns them all inode 1.
When using cpio to copy files out of a cramfs image, cpio turns the second
and all subsequent copied device nodes into hard links to the first copied
out device node, based on
Morita, nice work! I was planning on doing the exact same thing after
I straced a running fcrackzip and saw what was going on.
However, I see one problem with your proposed patch. You've left out
the check against unzip returning 1, which according to the comments
in the original code, should
I can corroborate this bug. I just upgraded to module-init-tools
3.7-pre9-1, and oss-compat 0.0.4+nmu3, and had the exact same thing
happen to me.
I found that the minimal way out of it was to comment out any line
in any /etc/modprobe.d/* file that began with install and referenced
any
Package: x11-common
Version: 1:7.0.17
Followup-For: Bug #362915
I'd like to report four more packages that conflict with x11-common
due to installing files in /usr/X11R6/bin
xftp
xext
xpaste
ghostview
-- System Information:
Debian Release: testing/unstable
APT prefers
Package: cpio
Version: 2.6-11
Severity: important
I am seeing certain archives created by cpio -o -H ustar come out
unextractable by either tar or cpio. It appears to be data dependent.
The ones that work, work reliably, and the ones that fail, fail
repeatably in the same spot.
Backing up the
I've bzip2'ed up the check-bin.tar from the bug report and posted it at:
http://www.energoncube.net/ebay/Debian_cpio_bug_358990/G9SAOwe43r_VLWPUhdLiKXR5hu0zxFh1/check-bin.tar.bz2
In case you have difficulty finding a set of test data with which to
reproduce the bug, I've also posted a tarball
Package: cpio
Version: 2.6-4
Followup-For: Bug #326090
It's much worse than just that cpio -p does not copy dangling symlinks.
Try adding to your archive a symlink that's not dangling, but whose
target file is not in the archive. In this case, cpio dereferences the
link and includes the
Package: libpam-runtime
Version: 0.76-23
Severity: minor
I had a box recently on which several random files on the root partition
were deleted due to filesystem corruption. I had been reinstalling
packages with the --force-confmiss option to dpkg to repopulate the
missing config files, and
Package: apcupsd
Version: 3.10.16-6
Severity: minor
Nothing in the package is actually linking against libgd2.so. Requesting
removal of that dependency. I've got multiple headless boxes running
apcupsd on which I need to keep libgd2-noxpm, libfreetype6, libjpeg62
and libpng12-0 installed
17 matches
Mail list logo
