On Sun, Apr 26, 2009 at 9:39 AM, Marc - A. Dahlhaus <[email protected]> wrote: > Dan McGee schrieb: >> >> On Sun, Apr 26, 2009 at 9:04 AM, Marc - A. Dahlhaus <[email protected]> wrote: >> >>> >>> Allan McRae schrieb: >>> >>>> >>>> Marc - A. Dahlhaus wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> i've spotted a problem in makepkg's cleanup part if the host is running >>>>> bash-4.0. >>>>> As makepkg runs bash with option -e, on bash-4.0 it fails if strip >>>>> reports an unsupported binary. >>>>> The following trivial patch fixes the problem. >>>>> >>>>> Signed-off-by: "Marc - A. Dahlhaus" <[email protected]> >>>>> >>>>> --- pacman-3.2.2.orig/scripts/makepkg.sh.in >>>>> +++ pacman-3.2.2/scripts/makepkg.sh.in >>>>> @@ -766,11 +766,11 @@ tidy_install() { >>>>> find ${strip_di...@]} -type f 2>/dev/null | while read binary ; >>>>> do >>>>> case "$(file -biz "$binary")" in >>>>> *application/x-sharedlib*) # Libraries (.so) >>>>> - /usr/bin/strip --strip-debug "$binary";; >>>>> + /usr/bin/strip --strip-debug "$binary" || true;; >>>>> *application/x-archive*) # Libraries (.a) >>>>> - /usr/bin/strip --strip-debug "$binary";; >>>>> + /usr/bin/strip --strip-debug "$binary" || true;; >>>>> *application/x-executable*) # Binaries >>>>> - /usr/bin/strip "$binary";; >>>>> + /usr/bin/strip "$binary" || true;; >>>>> esac >>>>> done >>>>> fi >>>>> >>>> >>>> I don't think this is a good approach to the problem. Having "|| true" >>>> means if there is a real problem, then it gets ignored. >>>> >>> >>> What real problem could arise? >>> An unsupported binary? Would print errors but creates the package mostly >>> stripped. >>> A missing strip command? Would print errors but creates the package >>> unstripped. >>> A damaged storage... but i think in that case makepkg would have failed >>> in >>> the actual build step and not in cleanup. >>> >>>> >>>> I suppose the real question is: How do you actually get an unsupported >>>> binary? My guess is this occurs when building a package from a binary >>>> source, in which case "options=('!strip')" would be the solution. >>>> >>> >>> The package that triggered this, was xen. >>> xen installs some gzipped content inside /usr/lib which strip doesn't >>> support. >>> >>> $ file -biz usr/lib/xen/boot/ioemu-stubdom.gz >>> application/x-executable; charset=binary >>> compressed-encoding=application/x-gzip; charset=binary; charset=binary >>> >>> The file itself is a bootable image file for grub. >>> >>> The library strip lines are not needed. >>> What about a case which catches *"*compressed-encoding*" and continues >>> with >>> the next file?* >>> >> >> I'm with Allan here- we should fix the real problem rather than adding >> a "|| true" and calling it a day. >> > > This was an ugly hack, i know, hence the last few lines of my message. >> >> I wouldn't be against an exclusion of "compressed-encoding=" when >> running strip- Allan, what do you think? The easiest way of >> implementing this would be to make it the first case and make it a >> no-op. > > Thats what i had in mind. > > I'll do a complete rebuild of all packages and grep for unsupported binarys > in the logs. > There might be some other types where this could bite us. I'll report back > after that.
Is it actually strip-able? Could we actually unpack it (based on the compressed-encoding), strip it, and repack? _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
