Re: Bug#537492: menu: Binary without execution bits.
On 2009-07-18 22:28 +0200, Cyril Brulebois wrote:
> Hello -devel, I need a tiny wider audience for that one.
>
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> (18/07/2009):
>> On Sat, Jul 18, 2009 at 09:35:57PM +0200, Cyril Brulebois wrote:
>> > Package: menu
>> > Version: 2.1.41
>> > Severity: grave
>> > Justification: Fucks up upgrades.
>> >
>> > Sounds like some bits are missing:
>> > | -rw-r--r-- root/root 122920 2008-10-24 21:03 ./usr/bin/update-menus
>> >
>> > Which leads to:
>> > | install/elserv: Deleting /tmp/elc_eXSJx7.log
>> > | install/devscripts-el: Handling emacs21, logged in /tmp/elc_U0zTnA.log
>> > | install/devscripts-el: Deleting /tmp/elc_U0zTnA.log
>> > | /var/lib/dpkg/info/emacs21.postinst: line 24: /usr/bin/update-menus: Permission denied
This looks strange, it seems that the test found update-menus
executable, but it no longer is. Namely, the shell has apparently
hashed it, since otherwise you would "update-menus: command not found"
instead of "permission denied".
This may be because the dpkg trigger for update-menus had been
activated. Can you examine your dpkg.log entries of the failed upgrade?
>> > | dpkg : erreur de traitement de emacs21 (--configure) :
>> > | le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
>> > | Des erreurs ont été rencontrées pendant l'exécution :
>> > | emacs21
>> > | E: dpkg returned non-zero status: 256
>> > | E: error performing command 'full-upgrade'
>> >
>> > (Sorry about the French bits, but heh.)
>> >
>> > No surprise, chmod is used in menu's postinst. WTF?
>>
>> /var/lib/dpkg/info/emacs21.postinst is broken, not menu.
>
> I'm repeating here what I said on the bugreport, because I think that
> (Houston) we've got a problem. It's quite classical to use the following
> bit to test for a binary to call:
> | if [ -x "`which invoke-rc.d 2>/dev/null`" ]
>
> See debhelper's sources:
> | git grep -e '-x.*which'|wc -l
> | 12
>
> But:
> | $ if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi
> | FAIL
>
> And also, under zsh:
> | $ which doublefailure 2>/dev/null
> | doublefailure not found
>
> Leading to:
> | if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi
> | [: too many arguments
This is missing the double quotes that are present in the debhelper
script snippet. Thanks to them, there is only one argument for [ -x .
> I guess we need a plan to fix some maintainer scripts, or am I grossly
> overlooking things here?
There is nothing obviously wrong with them, and the snippet had worked
fine for many years.
Sven
Reply to: