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 #217299,
regarding [dpatch-edit-patch] allow arbitrary functions to be user-defined
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.)
--
217299: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217299
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpatch
Version: 1.24
Severity: wishlist
Tags: patch
Hello,
I plan to extend dpatch a bit to use the translucency module in order to
mirror the directory before patching (thus way the "copy performance"
;-] and disk space efficiency can be increased significantly). The
change should be customisable. So I wish that dpatch loads custom
functions from a file in ~ (overriding the default ones) and the copy
method is moved to an extra function. The patches in attachment should
implement all this.
MfG,
Eduard.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian 2.4.23-pre2 #1 Mi Sep 3 16:09:39 CEST 2003 i686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
-- no debconf information
--
Die Liebe stirbt meist an den kleinen Fehlern, die man am Anfang so
entzückend findet.
-- Albert Schweitzer
--- /usr/bin/dpatch-edit-patch 2003-08-03 14:29:30.000000000 +0200
+++ dpatch-edit-patch 2003-10-23 21:04:55.000000000 +0200
@@ -22,6 +22,7 @@
# Import functions dpep_usage(), dpep_template(), dpep_parse_options(),
# dpep_message(), dpep_parse_longopt_value()
. /usr/share/dpatch/dpatch-edit-patch.functions
+test -e ~/.dpe.functions && . ~/.dpe.functions
dpep_parse_options "$@" || true
@@ -172,10 +173,7 @@
dpep_message warn "* No base-patch supplied, not applying any patches."
fi
-dpep_message norm "* Copying $DPEP_SOURCEDIR to work directory."
-cd "$WORKDIR"
-cp -a "$DPEP_SOURCEDIR" "$(basename $DPEP_SOURCEDIR)"
-
+dpep_mirror_directory "$DPEP_SOURCEDIR" "$WORKDIR"
# Change to the workdirectory, apply the patch we're editing if we're
# editing one, and launch an interactive shell.
--- /usr/share/dpatch/dpatch-edit-patch.functions 2003-08-03
14:29:30.000000000 +0200
+++ dpatch-edit-patch.functions 2003-10-23 21:07:56.000000000 +0200
@@ -212,6 +212,12 @@
done
}
+dpep_mirror_directory () {
+ dpep_message norm "* Copying $1 to work directory."
+ cd "$2"
+ cp -a "$1" "$(basename $1)"
+}
+
dpep_cleanup() {
# Clean up before exiting (unless requested to keep working dir)
--- 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 ---
