Your message dated Tue, 31 Jan 2012 16:48:58 +0100
with message-id <[email protected]>
and subject line dpatch: closing old wontfix bugs
has caused the Debian Bug report #400897,
regarding /usr/share/doc/dpatch/examples/dpatch/01_config.dpatch.gz fails with
non-default workdir
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
400897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400897
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpatch
Version: 2.0.21
Severity: minor
Hi,
the code given in
/usr/share/doc/dpatch/examples/dpatch/01_config.dpatch.gz will fail if
non-default workdir is used.
I'd prefer this to be fixed inside dpatch.lib.sh so that existing code
based on the example does not need to be changed.
Greetings
Marc
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.3-zgsrv
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
dpatch depends on no packages.
Versions of packages dpatch recommends:
ii dpkg-dev 1.13.24 package building tools for Debian
ii fakeroot 1.5.10 Gives a fake root environment
ii patchutils 0.2.31-3 Utilities to work with patches
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
I'm closing a few of age-old bugs filed against dpatch, which have been
marked wontfix for a while now, and which I consider safe to close for
one reason or the other.
These are:
#358019: As explained in my wontfix mail, I don't consider this fixable,
and it's better 'fixed' in another way: changing one's workflow.
#400897: The examples are meant to be simple, and showcase the
defaults. If one deviates from the defaults, then he must take care of
the side-effects too, dpatch is not going to guard against
corner-cases. That is, this isn't a bug, but a design decision.
#217299: See David's explanation from 2004. I'm closing the bug, since
there were no followups anyway.
#328391: Since dpatch-getorigtargz was removed, -b cannot be made
default, therefore I'm closing the bug. dpep wasn't meant to do
everything on behalf of the user anyway.
#330808: No response since 2005, and dpatch was meant to handle
dpatches, and dpatches alone. Furthermore, migrating from dpatch (where
the dpatches are all patch files) to another patch system is trivial,
you can just drop the files there and done. All dpatch scripts that use
the default template are also valid patch files.
#342768: This is actually two feature requests, the first part of which
has been supported by dpatch for ages, the other requires tweaking
dpatch-edit-patch, which would be more effort than the gain. The bug
hasn't seen any noticable traffic since 2005, not even after my spam
late last year, so I'm closing it now.
#345900: 00list is a design decision, it's going to stay.
#531607: dpatch wasn't designed to be able to group patches together,
that would be a larger feature, one which I don't want to do. One can
already achieve something similar, it's just that dpatch apply-all
won't work. But, this is by design, and is going to stay that way.
--
|8]
--- End Message ---
