On Mon, May 2, 2011 at 1:07 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
libnih1 depends on libc6 ( 2.12). libc6 2.13 is now in unstable,
rendering libnih1 uninstallable. I'm not sure why such a strict
dependency would be needed, but perhaps a mention in the documentation
why
If upstart crashes, a crash dump is most definitely saved.
Upstart handles SIGSEGV by catching it and forking a child and unmasking
that signal in the handler - this means it's an Upstart child process that
actually crashes and dumps core while the parent waits for it to exit and
reaps it. This
locally for my own use case.
Doesn't Debian run depmod in the postinst of the kernel package - and
iirc, again on boot anyway?
In which case, you'd always have module files that match the version of
depmod in the host environment not the build environment.
Scott
--
Scott James Remnant
sc
On Fri, 2009-03-20 at 12:05 +0100, Marco d'Itri wrote:
On Mar 20, Scott James Remnant sc...@canonical.com wrote:
Doesn't Debian run depmod in the postinst of the kernel package - and
iirc, again on boot anyway?
Not anymore on boot, but I can't see why depmod should NOT being run
when
Package: gecode
Severity: serious
The source package as exists in Debian generates a libgecode8 binary
package that contains, as one would expect, a libgecode.so.8 library.
Yet the matching development binary package is named libgecode7-dev,
while it contains a libgecode.so that links to
a bug here. Note that although the patch is against
2.2r2, the difference is small enough that it will apply successfully to
3.0
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
diff -ruNp squashfs-2.2r2~/squashfs-tools/mksquashfs.c squashfs-2.2r2/squashfs-tools/mksquashfs.c
--- squashfs-2.2r2
On Mon, 2005-10-10 at 00:16 +0900, Junichi Uekawa wrote:
dpkg in Debian woody (3.0) is broken by recent linux kernels;
due to the following command changing behavior (mmap of
zero-byte length):
addr=mmap(NULL, 0, PROT_READ, MAP_SHARED, fd, 0);
These bugs are caused by mmap changing
reassign 317082 libc6-dev,dpkg-dev
thanks
I managed to grab Matthias Klose and he helped me get a working demo of
the problem on my lowly i386, and I understand the bug now -- there's
some missing context in the above mails.
For those following, the problem is that people are building 64-bit
On Fri, 2005-08-05 at 18:38 +0300, Török Edvin wrote:
I have made a patch that sets close-on-exec. Tell me if this is what
you expected, and if my patch really fixes what you meant.
Also please test if dpkg still works correctly
That kinda patches gettext g
Already fixed this one, yet
tags 317082 moreinfo
thanks
Unfortunately I don't have either a 64-bit platform, or any real
knowledge of them. I've read this bug a dozen times, and I have
absolutely no idea what I'm supposed to do about it.
Could someone please supply a guide for idiots/dpkg maintainers or
better yet, a
severity 313605 minor
thanks
This bug should not be serious, it is not a severe violation of Debian
policy, and does not, in my opinion make the package unsuitable for release.
Neither is it grave (it does not make dpkg unusuable, or mostly so, or
introduce a security hole) or critical (in order
On Tue, 2005-06-14 at 15:28 -0400, Michael Stone wrote:
On Tue, Jun 14, 2005 at 04:19:20PM +0100, Scott James Remnant wrote:
On Tue, 2005-06-14 at 10:57 -0400, Michael Stone wrote:
dpkg has made the md5sum.textutils binary from the coreutils binary
unavailable in its original path
Clearly we're not getting anywhere by filing bugs on each other's
packages and trading well-judged insults ...
Something has to provide /usr/bin/md5sum, your package (coreutils) has
the best implementation of that. If you also want to
provide /usr/bin/md5sum.textutils, that's your call.
Until
severity 302995 normal
tags 302995 - sid
thanks
On Mon, 2005-04-04 at 02:13 +0200, Santiago Vila wrote:
On Sun, 3 Apr 2005, Blars Blarson wrote:
gettext failed to build from source on the sparc buildd, however it
built fine on my sparc pbuilder. The buildd log lacks some things
that
On Sat, 2005-03-12 at 02:03 -0800, Steve Langasek wrote:
Is it certain that this is a dpkg bug? I notice that the submitter's
typescript shows he was using apt 0.5.27 when upgrading, which was before
the Dpkg::MaxArgs setting was bumped to 1024 -- the first typescript shows a
total of 640
severity 294895 normal
reassign 294895 apt
thanks
On Fri, 2005-03-11 at 12:20 +0100, Frank Kster wrote:
Thank you. This clearly shows that there was no attempt to configure
emacsen-common before giving the error message about a2ps:
On closer examination, a2ps and emacsen-common are being
severity 295169 normal
retitle 265169 [S-S-D] doesn't set HOME enviroment variable when switching
users via --chuid
thanks
merge 265169 267784
thanks
On Sun, 2005-02-13 at 23:42 -0500, Adam R. Skutt wrote:
Justification: breaks unrelated software
Software using start-stop-daemon is implicitly
17 matches
Mail list logo
