On Sat, 2005-10-08 at 22:08 +0200, Frank Lichtenheld wrote:
It seems most man pages have changed their section from 8 to 1
(even though I haven't found the changelog entry for that yet)
but the references were only sparsely updated and many false
ones remain.
2005-01-14 Scott James Remnant
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 326986 perl,libnss-ldap
retitle 326986 getpwnam fails if libnss-ldap.conf is not readable
thanks
On Wed, 2005-09-07 at 10:30 -0700, Aaron T Porter wrote:
On Wed, Sep 07, 2005 at 01:09:22PM +0100, Scott James Remnant wrote:
On Tue, 2005-09-06 at 17:46 -0700, Aaron T Porter wrote
On Wed, 2005-08-31 at 17:49 +0200, Christian Perrier wrote:
Quoting Stepan Golosunov ([EMAIL PROTECTED]):
Package: dpkg
Version: 1.10.28
Severity: minor
Tags: l10n patch
man -L ru start-stop-daemon
says that short vershion of --nicelevel is -n
Scott, you fix or I fix?
If it's
On Thu, 2005-08-25 at 19:19 +0200, Thomas Hood wrote:
I take it that dpkg will be changed someday so that an unmodified
conffile will have its perms updated?
Yeah, that should be supported I think. Don't know whether it'll get
fixed in 1.13, but 2.0 would inherently fix it I think.
Scott
--
On Fri, 2005-08-19 at 10:30 +0300, Jari Aalto wrote:
Problem:
W: foo source: source-contains-svn-control-dir src/os/.svn
It is typical that packages are put into Revision control and worked
in there. However not all programs are aible to export things (like
RCS). It would help if
reopen 170575
merge 170575 324741
thanks
On Tue, 2005-08-23 at 20:21 +0200, Bastian Blank wrote:
#170575 was marked fixed some time ago, but the version in sid does not
accept such dependency lines.
dpkg has _never_ had support for arch-specific Depend lines, just
Build-Depend. That bug
On Thu, 2005-08-18 at 19:48 +0200, Sven Mueller wrote:
Basically the subject says everything needed:
Please include the attached file as /etc/bash_completion.d/dpkg-source.
This will enable bash command completion for dpkg-source in a (hopefully
correct and) intelligent way.
Sorry for being
On Fri, 2005-07-15 at 21:16 +0200, Goswin von Brederlow wrote:
talking to joeyh he said that he did a patch for the same thing as
well. Comparing the two his is the preferable solution so please
ignore this patch and stick with his.
I don't suppose you happen to know where joeyh's patch _is_
On Sat, 2005-07-16 at 12:49 +1000, Michael Wardle wrote:
Would it not be more efficient if this information were stored
in /var/lib/dpkg/status?
I would find this feature very useful.
Out of interest, what would you find it useful _for_ ?
I can't think of a use-case for this field that
On Mon, 2005-08-15 at 11:01 +1000, Michael Wardle wrote:
On Sun, 2005-08-14 at 22:41 +0100, Scott James Remnant wrote:
On Sat, 2005-07-16 at 12:49 +1000, Michael Wardle wrote:
Would it not be more efficient if this information were stored
in /var/lib/dpkg/status?
I would find
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
tags 296026 pending
thanks
So we can replicate this with a banana:
syndicate tmp# dpkg -i banana.deb
Selecting previously deselected package banana.
(Reading database ... 126150 files and directories currently installed.)
Unpacking banana (from banana.deb) ...
Setting up banana (1.0) ...
syndicate tmp# dpkg -i banana.deb
Selecting previously deselected package banana.
(Reading database ... 126152 files and directories currently installed.)
Unpacking banana (from banana.deb) ...
Setting up banana (1.0) ...
syndicate tmp# dpkg -i banana-icecream.deb
Selecting previously deselected
As well as this way round:
syndicate tmp# dpkg-divert --package banana-icecream --divert /banana.other
--add /banana
Adding `diversion of /banana to /banana.other by banana-icecream'
syndicate tmp# dpkg -i banana.deb Selecting previously deselected package
banana.
(Reading database ... 126152
So it turns out this way is true too:
syndicate tmp# dpkg-divert --package banana --divert /banana.other --add /banana
Adding `diversion of /banana to /banana.other by banana'
syndicate tmp# dpkg -i banana.deb
Selecting previously deselected package banana.
(Reading database ... 126152 files
This mail is just to clarify for myself, because I'm dizzy and forgetful
at times, that this bug doesn't appear to be dpkg not removing diverted
files during upgrade.
It's more subtle than that, it's dpkg not removing the NOT diverted file
during an upgrade.
Scott
--
Have you ever, ever felt
unmerge 15695
reassign 15695 lilo
merge 15162 15965
kthxbye
This is another bug that's a copy of 15162, dpkg is informing the old
version that an upgrade to it was aborted -- and lilo's postinst is
failing to catch that particular postinst argument.
(ps. Andrés, as you can guess, you can just
unmerge 65690
close 65690
kthxbye
This is an old bug, and cannot be replicated. dpkg is extra-ordinarily
anal about checking that every write() and the close() succeed -- and
will roll-back the installation or upgrade of a package if the disk
becomes full while it does so.
If you can come up
unmerge 96391
close 96391
kthxbye
I don't really think it's dpkg's problem that you ran out of disk space,
it did the best it could and will roll back the install/upgrade of that
package and leave your system how it found it.
Scott
--
Have you ever, ever felt like this?
Had strange things
unmerge 106224
close 106224
kthxbye
This is an old bug, and is currently unreproducible. There were recent
fixes to dpkg's error handling and unpack clean-up that may have fixed
this.
Please try again, and if you still get the problem, open a new bug.
The intended behaviour is that on the
It's not actually in infinite loop, it will break out when it reaches
too many errors, but if it didn't do that it would be.
In packages.c depossi_ok_found() we encounter emacs20 and note that we
need it to configure emacs20-el, so add it to the queue and return.
When it fails, we take it off
On Fri, 2005-07-01 at 11:13 +0200, Wolfram Quester wrote:
On Thu, Jun 30, 2005 at 05:02:36PM +0100, Scott James Remnant wrote:
On Thu, 2005-06-30 at 17:38 +0200, Wolfram Quester wrote:
there is another appearence of the same bug, but with another extension,
which was not captured
The bug the person above mentions is very different...
That's when the previous version contained a directory, and the new
version doesn't. dpkg obviously tries to remove it ... but this is a
symlink on the user's machine and dpkg removes the symlink (because it
handles symlink-to-directories as
tags 313554 pending
thanks
On Tue, 2005-06-14 at 04:03 -0700, Karl Hegbloom wrote:
In: man dpkg-architecture, I find:
BACKWARD COMPATIBILITY
The DEB_HOST_ARCH_CPU and DEB_HOST_ARCH_OS variables were only intro-
duced in relatively versions of dpkg-architecture
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
27 matches
Mail list logo
