Re: Bug#537492: menu: Binary without execution bits.

2009-07-19 Thread Julien Cristau
On Sat, Jul 18, 2009 at 22:28:23 +0200, Cyril Brulebois wrote:

> 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
> 
Why would you point /bin/sh to zsh?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#537492: menu: Binary without execution bits.

2009-07-19 Thread Joey Hess
Cyril Brulebois wrote:
> I guess we need a plan to fix some maintainer scripts, or am I grossly
> overlooking things here?

j...@gnu:~/src/debhelper/autoscripts>cat postinst-menu
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then


Which works fine in this case.

-- 
see shy jo


signature.asc
Description: Digital signature


Re: Bug#537492: menu: Binary without execution bits.

2009-07-18 Thread Daniel Moerner
On Sat, Jul 18, 2009 at 9:20 PM, Cyril Brulebois wrote:
> Sven Joachim  (18/07/2009):
>> 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?
>
> (No sign of triggers, it's just that emacs21 gets configured before
> menu.)
>
> That one might be arch-related:
> | kbsd:/home/kibi# which update-menus
> | /usr/bin/update-menus
> | kbsd:/home/kibi# ls -l /usr/bin/update-menus
> | -rw-r--r-- 1 root root 113028 jun  8 13:13 /usr/bin/update-menus
>
> That's on GNU/kFreeBSD. I still have to investigate why, but it looks
> like if [ -x /usr/bin/update-menus ] returns true even with the
> above-mentioned conditions. Cc'ing -bsd.

Could this be the fakeroot chmod race problem again? (e.g. a faulty
build of menu)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534879

Daniel

-- 
Daniel Moerner 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#537492: menu: Binary without execution bits.

2009-07-18 Thread Cyril Brulebois
Sven Joachim  (18/07/2009):
> 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?

(No sign of triggers, it's just that emacs21 gets configured before
menu.)

That one might be arch-related:
| kbsd:/home/kibi# which update-menus
| /usr/bin/update-menus
| kbsd:/home/kibi# ls -l /usr/bin/update-menus 
| -rw-r--r-- 1 root root 113028 jun  8 13:13 /usr/bin/update-menus

That's on GNU/kFreeBSD. I still have to investigate why, but it looks
like if [ -x /usr/bin/update-menus ] returns true even with the
above-mentioned conditions. Cc'ing -bsd.

> > 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 .

Indeed, thanks.

/me gets back to fixing (real) bugs.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: Bug#537492: menu: Binary without execution bits.

2009-07-18 Thread Sven Joachim
On 2009-07-18 22:28 +0200, Cyril Brulebois wrote:

> Hello -devel, I need a tiny wider audience for that one.
>
> Bill Allombert  (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/root122920 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#537492: menu: Binary without execution bits.

2009-07-18 Thread Cyril Brulebois
Hello -devel, I need a tiny wider audience for that one.

Bill Allombert  (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/root122920 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
> > | 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

I guess we need a plan to fix some maintainer scripts, or am I grossly
overlooking things here?

Mraw,
KiBi.


signature.asc
Description: Digital signature