Package: coreutils
Version: 5.2.1-2
Severity: normal
rm is not able to delete this symlink:
# ls -ld plus
lrwxrwxrwx 1 root root 14 Aug 16 06:10 plus -> /root/pix/plus
it just hangs. strace shows:
access("plus", W_OK
the folder /root/pix/plus is nfs-mounted and not currently
access
On Tue, Aug 16, 2005 at 11:04:34AM +0800, James Pan wrote:
> see below please.
>
>
> [EMAIL PROTECTED]:~# dpkg-query -l libsnmp5
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-pro
On Mon, Aug 15, 2005 at 03:50:23PM -0700, Steve Langasek wrote:
> On Mon, Aug 15, 2005 at 05:00:42PM +0200, Steinar H. Gunderson wrote:
> > Package: libstonith0
> > Version: 1.2.3-12
> > Severity: serious
>
> > - libstonith0 depends on libsnmp5 (>= 5.1).
> > - libsnmp5 in sid conflicts with libs
reopen 285017
thanks
Hi Maximilian,
its still a bug in the 2.4.27 package. It may or may not be fixable.
And the patch may or may not be appropriate for Sarge.
My current preference for handling problems like this,
is firstly to encourage the user to use a more up to date kernel.
Secondly downg
I tested this on a cygwin system and found a cutoff point of 134217729
transcript:
The last number that woks is 134217729, or 0b1001
or 0x801 , which is interesting... If there was some sort of precision
problem I would have expected it to fail 2 numbers before wher
reassign 323318 kernel-source-2.4.27
merge 323318 320256
thanks
On Mon, Aug 15, 2005 at 11:22:39AM -0700, Matt Kraai wrote:
> Package: kernel-headers-2.4.27-2
> Version: 2.4.27-10
> Severity: serious
>
> hostap-modules-i386 fails to build because a kernel header has an array type
> with an incomp
Package: mutt-ng
Version: 0.0+20050815-1
Severity: wishlist
It will be great if you add libesmtp support by default.
I had some problems while building new snapshot of mutt-ng
(20050815) with existing libesmtp5 (which doesn't export
smtp_session_t smtp_create_session (void) ). Recompili
Package: openbox
Severity: wishlist
The projects seems well maintained, so please add to the end of
'Description:' of package the homepage URL:
Homepage: icculus.org/openbox/
See
6.2.4 Upstream home page
http://www.debian.org/doc/developers-reference/ch-best-pkging-pr
Package: blitz++
Version: 1:0.8-5
Severity: important
Hi,
I have been trying to compile my C++ code, which uses the blitz library, and I
got a bunch of errors[1] in templates of blitz things that were instantiated by
variables in my code. I searched on the errors I was getting, and found some
di
severity 323322 important
thanks
On Mon, Aug 15, 2005 at 12:41:07PM -0700, Matt Kraai wrote:
> Package: hermes1
> Version: 1.3.3+really1.3.2-2
> Severity: serious
>
> hermes1 fails to build because it aliases some variables to undefined
> symbols:
I forced the use of gcc-3.3 since touching herme
On Mon, Aug 15, 2005 at 07:53:03PM +0900, Horms wrote:
> On Mon, Aug 15, 2005 at 10:24:51AM +0200, Moritz Muehlenhoff wrote:
> > Package: linux-2.6
> > Severity: important
> > Tags: security patch
> >
> > There are another two vulnerabilities fixed in 2.6.12.5, that might require
> > backporting t
If the max-children are set to low, the milter shouldn't die correct?
This is the outcome I have. Since I've upped the children to 6, I have
not had a problem.
Stephen Gran wrote:
>This one time, at band camp, Anthony Tippett said:
>
>
>>I am also having the same problem where the milter wil
On Mon, 2005-08-15 at 22:56 +0200, Chris Searle wrote:
> Scanning file /usr/share/fonts/type1/gsfonts/b018012l.pfb...
>
> Then it just hangs there.
The bug is likely in libfreetype6 as that is how fontconfig scans font
files. I'm not seeing any trouble scanning this font on my machine.
Ca
On Mon, Aug 15, 2005 at 02:17:54PM -0500, Ming Hua wrote:
[snip}
>
> Seeing that both stardict and epiphany-browser use C++ and are both
> GTK apps and both built against libstdc++6 (on i386), I suspect this is
> a C++ ABI issue. Does setting GTK_IM_MODULE=xim solve your problem?
>
Yeah, you are
Package: libpmount
Severity: normal
Tags: patch
Hi!
Attached patch fixes:
- check target in Makefile (syntax errors)
- ext2fs.sh (attempts to link with -Lout where it should be -L.)
I also added a pair of improvements:
- ext2fs.sh cleanup to reduce number of fs-specific bits
- add isof
Package: libpmount
Severity: grave
Hi!
>From build log:
cc -Wall -g -D_REENTRANT -fPIC -c -o src/kerndep.lo src/kerndep.c
cc -Wall -g -D_REENTRANT -fPIC -c -o src/mtab.lo src/mtab.c
cc -Wall -g -D_REENTRANT -fPIC -c -o src/pmount.lo src/pmount.c
cc -Wl,-z,defs -Wl,-soname,libpmount.so.0.0 -share
Package: hotplug
Version: 0.0.20040329-24
Severity: wishlist
In /var/log/hotplug are more than 430 files, the oldest is nearly a year old.
In the events file are entrys from Feb 2004. Is it necessary?
Can you use a purge mechanism for that? Logrotate?
Ulrich
-- System Information:
Debian Relea
Hi,
* Rail Aliev <[EMAIL PROTECTED]> [2005-08-16 08:16]:
> It will be great if you add libesmtp support by default.
>
> I had some problems while building new snapshot of mutt-ng
> (20050815) with existing libesmtp5 (which doesn't export
> smtp_session_t
Package: gallery2
Version: 0.0+2.0.rc1-1
Followup-For: Bug #320394
I can confirm that 0.0+2.0.rc1-1 still exhibits this bug. Pressing ^C during
the beta3->rc1 upgrade gave an error, but subsequent dpkg-reconfigure runs
were ^C'able without error.
'ps' output suggests that the problem might have s
package lcap
clone 312948 -1
retitle 312948 lcap: Should warn when capabilities are not enforced
retitle -1 lcap: Produces wrong output when CAP_SYS_MODULE is removed
thanks
Capabilities do in fact change when running lcap - even if capability.ko
isn't loaded. That is, /proc/sys/kernel/cap-bound
Attached is patch that removes the upstream's website reference from the
manpage and adds a pointer to capabilities(7) - please apply.
I've searched for a new upstream website but I couldn't find any
(although admitedly I haven't tried contacting upstream). If it is
actually dead upstream, I s
The way I see it, there are two possible solutions:
a) Completely remove LIDS support by commenting out -DLIDS in the Makefile
b) Comment the (2) perrors() in lcap.c, therefore eliminating the
warnings in non-LIDS systems.
I believe that (b) could be misleading to systems with an LIDS kernel:
The attached patch adds the missing capabilities CAP_MKNOD and
CAP_LEASE, which are the only missing as of 2.6.10.
Please apply.
Regards,
Faidon
diff -Nur lcap-0.0.6/README lcap-void/README
--- lcap-0.0.6/README 2001-03-06 00:53:57.0 +0200
+++ lcap-void/README2005-08-15 09:04:08.0
reopen 317838
thanks
Salut,
the latest version still depends on the unavailable libgmp3:
Package: kismet
Priority: optional
Section: net
Installed-Size: 2928
Maintainer: Francois Gurin <[EMAIL PROTECTED]>
Architecture: i386
Version: 2005.07.R1a-1
Depends: libbz2-1.0, libc6 (>= 2.3.2.ds1-21), lib
401 - 424 of 424 matches
Mail list logo
