This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | MakeNBM creates nbm with executable files stored in Info/executables.list but updater read Info/executable.list (missing 's') | ||
---|---|---|---|
Product: | platform | Reporter: | Alexander Pepin <apepin> |
Component: | Autoupdate | Assignee: | dlipin <dlipin> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | issues, sustaining |
Priority: | P2 | Keywords: | REGRESSION |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Alexander Pepin
2010-02-12 10:06:47 UTC
It's reproducible on all platforms except Windows. On Mac term window (dorun.sh) gives: /usr/X11/bin/xterm: Can't execvp /Applications/NetBeans/NetBeans 6.8.app/Contents/Resources/NetBeans/cnd3/bin/dorun.sh: Permission denied To rollback patch1 changes a user just need to reinstall nb6.8 and use a fresh userdir. The reason is the absence of execution permissions for cnd3/bin/dorun.sh I've just installed a fresh 6.8 - cnd3/bin/dorun.sh has execution permissions. If I upgrade it to 6.8.1, i see that cnd3/bin/dorun.sh don't have execution permissions. As soon as I set execution permissions for this file, the bug disappears. When I build IDE from sources, cnd3/bin/dorun.sh execution permissions are set. So I believe the problem is in the installer. The issue is that MakeNBM stores executable files info in Info/executables.list but updater read that information from Info/executable.list Fixed by using Info/executable.list in MakeNBM: http://hg.netbeans.org/core-main/rev/7ddf91788e0d Actually, should be reproducible on 6.9 dev builds as well within the following scenario: 1) Install 6.9 M1 JavaSE 2) Run IDE, open Tools->Plugins, install C/C++, restart 3) After restart cnd/bin/dorun.sh does not have executable permissions Definitely needs to be back-ported to 6.8 (patch2). Dima, I tend to be afraid to backport a change in build infrastructure, which in fact means, that if it should really have to have an influence, then affected NBMs available from Update Center must be rebuilt and go through complete publishing cycle. Please explain why we should not go with a fix rather in updater than in MakeNBM? (I know about singular better than plural rule, but this rule seems to be much softer than what it means if we would have insisted on it) I can't but agree with you, so reverting change in MakeNBM and doing that in autoupdate.services: http://hg.netbeans.org/core-main/rev/244ed71aa63d The patch looks good. Integrated into 'main-golden', will be available in build *201003110200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/244ed71aa63d User: Dmitry Lipin <dlipin@netbeans.org> Log: Better fix for #180672 - fix updater rather than MakeNBM The patch has been ported into release68_fixes repository as http://hg.netbeans.org/release68_fixes/rev/f8848d09917d verified in patch2 candidate 20100318 |