for various reasons/limitations/bugs/whatever, i rewrote epatch. seems to
work for me, but in case someone wants to check before i release:
epatch() {
_epatch_draw_line() {
# create a line of same length as input string
[[ -z $1 ]] && set "$(printf "%65s" ')"
echo "${1//?/=}"
}

unset P4CONFIG P4PORT P4USER # keep perforce at bay #56402

# Let the rest of the code process one user arg at a time --
# each arg may expand into multiple patches, and each arg may
# need to start off with the default global EPATCH_xxx values
if [[ $# -gt 1 ]] ; then
local m
for m in "$@" ; do
epatch "${m}"
done
return 0
fi

local SINGLE_PATCH="no"
# no args means process ${EPATCH_SOURCE}
[[ $# -eq 0 ]] && set -- "${EPATCH_SOURCE}"

if [[ -f $1 ]] ; then
SINGLE_PATCH="yes"
set -- "$1"
# Use the suffix from the single patch (localize it); the code
# below will find the suffix for us
local EPATCH_SUFFIX=$1

elif [[ -d $1 ]] ; then
# Some people like to make dirs of patches w/out suffixes (vim)
set -- "$1"/*${EPATCH_SUFFIX:+."${EPATCH_SUFFIX}"}

else
# sanity check ... if it isn't a dir or file, wtf man ?
[[ $# -ne 0 ]] && EPATCH_SOURCE=$1
echo
eerror "Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:"
eerror
eerror " ${EPATCH_SOURCE}"
eerror " ( ${EPATCH_SOURCE##*/} )"
echo
die "Cannot find $EPATCH_SOURCE!"
fi

local PIPE_CMD
case ${EPATCH_SUFFIX##*.} in
xz) PIPE_CMD="xz -dc" ;;
lzma) PIPE_CMD="lzma -dc" ;;
bz2) PIPE_CMD="bzip2 -dc" ;;
gz|Z|z) PIPE_CMD="gzip -dc" ;;
ZIP|zip) PIPE_CMD="unzip -p" ;;
*) ;;
esac

[[ ${SINGLE_PATCH} == "no" ]] && einfo "${EPATCH_MULTI_MSG}"

local x
for x in "$@" ; do
# If the patch dir given contains subdirs, or our EPATCH_SUFFIX
# didn't match anything, ignore continue on
[[ ! -f ${x} ]] && continue

local patchname=${x##*/}

# Apply single patches, or forced sets of patches, or
# patches with ARCH dependant names.
# ???_arch_foo.patch
# Else, skip this input altogether
local a=${patchname#*_} # strip the ???_
a=${a%%_*} # strip the _foo.patch
if ! [[ ${SINGLE_PATCH} == "yes" ||
${EPATCH_FORCE} == "yes" ||
${a} == all ||
${a} == ${ARCH} ]]
then
continue
fi

# Let people filter things dynamically
if [[ -n ${EPATCH_EXCLUDE} ]] ; then
# let people use globs in the exclude
eshopts_push -o noglob

local ex
for ex in ${EPATCH_EXCLUDE} ; do
if [[ ${patchname} == ${ex} ]] ; then
eshopts_pop
continue
fi
done
eshopts_pop
fi

if [[ ${SINGLE_PATCH} == "yes" ]] ; then
if [[ -n ${EPATCH_SINGLE_MSG} ]] ; then
einfo "${EPATCH_SINGLE_MSG}"
else
einfo "Applying ${patchname} ..."
fi
else
einfo " ${patchname} ..."
fi

# most of the time, there will only be one run per unique name,
# but if there are more, make sure we get unique log filenames
local STDERR_TARGET="${T}/${patchname}.out"
if [[ -e ${STDERR_TARGET} ]] ; then
STDERR_TARGET="${T}/${patchname}-$$.out"
fi

printf "***** %s *****

" "${patchname}" > "${STDERR_TARGET}"

# Decompress the patch if need be
local count=0
local PATCH_TARGET
if [[ -n ${PIPE_CMD} ]] ; then
PATCH_TARGET="${T}/$$.patch"
echo "PIPE_COMMAND: ${PIPE_CMD} ${x} > ${PATCH_TARGET}" >> "${STDERR_TARGET}"

if ! (${PIPE_CMD} "${x}" > "${PATCH_TARGET}") >> "${STDERR_TARGET}" 2>&1 ; then
echo
eerror "Could not extract patch!"
#die "Could not extract patch!"
count=5
break
fi
else
PATCH_TARGET=${x}
fi

# Check for absolute paths in patches. If sandbox is disabled,
# people could (accidently) patch files in the root filesystem.
# Or trigger other unpleasantries #237667. So disallow -p0 on
# such patches.
local abs_paths=$(egrep -n '^[-+]{3} /' "${PATCH_TARGET}" | awk '$2 != "/dev/null" { print }')
if [[ -n ${abs_paths} ]] ; then
count=1
printf "NOTE: skipping -p0 due to absolute paths in patch:
%s
" "${abs_paths}" >> "${STDERR_TARGET}"
fi

# Dynamically detect the correct -p# ... i'm lazy, so shoot me :/
while [[ ${count} -lt 5 ]] ; do
# Generate some useful debug info ...
(
_epatch_draw_line "***** ${patchname} *****"
echo
echo "PATCH COMMAND: patch -p${count} ${EPATCH_OPTS} < '${PATCH_TARGET}'"
echo
_epatch_draw_line "***** ${patchname} *****"
) >> "${STDERR_TARGET}"

if (patch -p${count} ${EPATCH_OPTS} --dry-run -f < "${PATCH_TARGET}") >> "${STDERR_TARGET}" 2>&1 ;
then
(
_epatch_draw_line "***** ${patchname} *****"
echo
echo "ACTUALLY APPLYING ${patchname} ..."
echo
_epatch_draw_line "***** ${patchname} *****"
patch -p${count} ${EPATCH_OPTS} < "${PATCH_TARGET}" 2>&1
) >> "${STDERR_TARGET}"

if [ $? -ne 0 ] ; then
echo
eerror "A dry-run of patch command succeeded, but actually"
eerror "applying the patch failed!"
#die "Real world sux compared to the dreamworld!"
count=5
fi
break
fi

: $(( count++ ))
done

# if we had to decompress the patch, delete the temp one
if [[ -n ${PIPE_CMD} ]] ; then
rm -f "${PATCH_TARGET}"
fi

if [[ ${count} -ge 5 ]] ; then
echo
eerror "Failed Patch: ${patchname} !"
eerror " ( ${PATCH_TARGET} )"
eerror
eerror "Include in your bugreport the contents of:"
eerror
eerror " ${STDERR_TARGET}"
echo
die "Failed Patch: ${patchname}!"
fi

# if everything worked, delete the patch log
rm -f "${STDERR_TARGET}"
eend 0
done

[[ ${SINGLE_PATCH} == "no" ]] && einfo "Done with patching"
: # everything worked
}
-mike

On Sat, Dec 19, 2009 at 12:37 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> for various reasons/limitations/bugs/whatever, i rewrote epatch. *seems to
> work for me, but in case someone wants to check before i release:

Wouldn't it be safer to let this run on, say, Patrick's or Deigo's
tinderboxes for a day or so before pushing this to eutils?

Murphy's law becomes more applicable as the affected domain of a
change increases

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

On Sat, Dec 19, 2009 at 01:06:22PM +0530, Nirbheek Chauhan wrote:
> On Sat, Dec 19, 2009 at 12:37 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > for various reasons/limitations/bugs/whatever, i rewrote epatch. *seems to
> > work for me, but in case someone wants to check before i release:
>
> Wouldn't it be safer to let this run on, say, Patrick's or Deigo's
> tinderboxes for a day or so before pushing this to eutils?
>
> Murphy's law becomes more applicable as the affected domain of a
> change increases

Err... that's a damn fine idea actually, although it requires getting
them to agree to it.

For changes of this sort, abusing the tinderboxes to get a real world
test run makes a lot of sense.

Diego/Patrick- thoughts?

~harring

Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto:
>
> For changes of this sort, abusing the tinderboxes to get a real world
> test run makes a lot of sense.

I can put it into run with the tinderbox, no problem with that.

But I think that we should really use both: Patrick's should be better
for I/O so maybe you (or Zac) can come up with a script to just try
unpack and prepare phases for all ebuilds rather than keeping the whole
merge…

--
Diego Elio Pettenò — “Flameeyes�
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/

On Saturday 19 December 2009 07:33:33 Diego Elio “Flameeyes� Pettenò wrote:
> Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto:
> > For changes of this sort, abusing the tinderboxes to get a real world
> > test run makes a lot of sense.
>
> I can put it into run with the tinderbox, no problem with that.

i'll wait until the end of the year to commit it
-mike

On 12/19/2009 04:33 AM, Diego Elio “Flameeyes� Pettenò wrote:
> But I think that we should really use both: Patrick's should be better
> for I/O so maybe you (or Zac) can come up with a script to just try
> unpack and prepare phases for all ebuilds rather than keeping the whole
> merge…

A script that calls `ebuild foo.ebuild clean prepare` would probably
do the trick. It might be hard to know if the patches are applying
correctly though, until you try to build it.
--
Thanks,
Zac

On Saturday 19 December 2009 07:33:33 Diego Elio “Flameeyes� Pettenò wrote:
> Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto:
> > For changes of this sort, abusing the tinderboxes to get a real world
> > test run makes a lot of sense.
>
> I can put it into run with the tinderbox, no problem with that.

i'm guessing you havent seen any problems then
-mike

> i'm guessing you havent seen any problems then

Sorry forgot to notice you, nope the tinderbox completed the run, and
restarted now, no problem at all.

--
Diego "Flameeyes" Pettenò - flameeyes@gmail.com
Free Software developer and consultant
http://blog.flameeyes.eu/

On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:

> if (patch -p${count} ${EPATCH_OPTS} --dry-run -f <
"${PATCH_TARGET}") >>
> "${STDERR_TARGET}" 2>&1 ; then

Just FYI.
There seems to be a little 'problem' with this, as patch is validated in --
dry-run mode before applying, no .rej files are generated, thus the only
feedback is hunk # that failed from ${T}/${patchfile}.out.

--
regards
MM

On Wednesday 23 November 2011 18:19:40 Maciej Mrozowski wrote:
> On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:
> > if (patch -p${count} ${EPATCH_OPTS} --dry-run -f <
> "${PATCH_TARGET}") >>
> > "${STDERR_TARGET}" 2>&1 ; then
>
> There seems to be a little 'problem' with this, as patch is validated in --
> dry-run mode before applying, no .rej files are generated, thus the only
> feedback is hunk # that failed from ${T}/${patchfile}.out.

this is always how epatch has worked. my rewrite didn't change that.

personally, i've never found .rej useful. and the .out file tells you exactly
what hunk failed, so i don't see a problem here.
-mike