[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC

On Fri, Sep 17, 2004 at 11:26:36PM +0100, Ian Jackson wrote:
>Thanks to Raul, Bdale and Steinar for comments and suggestions.  At
>Bdale's request I have deleted the old paragraph 17 (which
>contemplated the rpvm maintainer closing their bug).  So ...
>I hereby propose the following resolution and call for an immediate vote:

This vote call is 7 weeks old. May the debian-ctte members vote Ian's
proposal, please.

I've read http://lists.debian.org/debian-ctte/2004/09/msg00006.html
already. I think, we need the debian-ctte's opinion on this matter.

>It appears that everyone agrees on the following set of facts:
> 1. rpvm, an extension for integrating GNU R with PVM, uses a library
>    libgpvm3 from pvm.
> 2. This library is currently in pvm's .deb only as a .a containing
>    non-PIC code.  This is a historical accident and not intended to
>    be the permanent behaviour; it should be changed eventually.
> 3. R expects extensions to be shared libraries and rpvm should not be
>    an exception to this.
> 4. On architectures other than i386 and ARM, shared libraries cannot
>    contain non-PIC code.
> 5. For the reasons above, rpvm has never worked properly (upstream,
>    or Debian) on architectures other than i386 and ARM.
>Disputed questions include:
> 6. Should pvm be changed to ship libgpvm3_pic.a or a suitable .so, for
>    sarge, so that a working rpvm can be made available in sarge on
>    all architectures ?
> 7. What should be done with the bug reports ?
>We note that:
> 8. While the Technical Committee is not the official arbiter of
>    process questions such as the proper use of the bug system, we
>    have been asked for our opinion and it would be helpful of us to
>    give guideance.
> 9. It is not clear how difficult or risky the change would be to make
>    pvm build a suitable library.  It is difficult for the Committee
>    to evaluate this, without a suitable patch to review.
>10. The pvm maintainer is a volunteer is not obliged to do the
>    technical work necessary to support rpvm.
>11. Nothing in the release policy requires or forbid the relevant
>    changes to pvm or rpvm at this stage of the release process.
>We therefore conclude that:
>12. There are (perhaps) two distinct sets of changes required to fix
>    this problem; the changes to pvm to supply a suitable library,
>    and any changes to rpvm to make use of the new library.  And, of
>    course, there are two packages which have some kind of defect.
>    Therefore it is not inappropriate for there to be two bug reports
>    open.
>13. Since rpvm has never been supported other than on i386 and ARM we
>    believe that the current release policy would make the problem
>    non-release-critical for rpvm.  We believe the problem is
>    non-release-critical for pvm.
>14. As the maintainer of each package is a volunteer, they have the
>    freedom to direct their effort as they see fit.  Additionally it
>    is proper for the maintainer to have a strong influence on the
>    perceptions of other developers regarding the best use of effort
>    spent on the package.  The bug system severities provide a
>    suitable way to manage this process.  For non-release-critical
>    bugs, the severity should therefore usually be assigned with free
>    discretion by the maintainer.
>We therefore recommend that:
>15. There should be two open bugs regarding this issue, as follows:
>    #266837 against rpvm regarding the missing architectures, and
>    #266762 against pvm regarding the missing library.  These bugs
>    should have whatever severity the respective package maintainer
>    assigns from time to time.
>16. The rpvm maintainer should (if they see fit and are able) prepare
>    a suitable patch to pvm to arrange for the supply of the
>    necessary library.  Such a patch should be reported to the pvm
>    maintainer via the existing bug.
>17. If such a patch is made available the pvm maintainer should
>    evaluate its suitability for inclusion in sarge.  If the pvm
>    maintainer decides not to include the patch in sarge, or does not
>    respond in a timely manner, then the Committee encourages the
>    rpvm maintainer to bring the matter to our attention, and we will
>    consider whether to overrule the maintainer and direct that the
>    patch should be included in sarge.
>18. We do not rule out alternative technical solutions which the rpvm
>    maintainer may choose to implement.  Nevertheless, no such
>    solution entitles the rpvm maintainer to /mandate/ any change in
>    pvm, or to fight with the pvm maintainer over the severities of
>    pvm bugs.
>19. The Committee's decisions here regarding the releasability of
>    various packages are not to be construed as overruling or
>    directing the Release Team.
>20. The Committee's decisions here regarding the proper use of the
>    bug system are not to be construed as overruling the BTS
>    maintainers.
>21. Therefore, if the Release Team or BTS maintainers disagree with
>    the Committee's decisions here we encourage them to contact us
>    immediately, and the Release Team's or BTS maintainers'
>    instructions will stand during any subsequent discussion.

Kind regards,

Anibal Monsalve Salazar
 .''`. Debian GNU/Linux      |
: :' : Free Operating System | http://www.debiancolombia.org/
`. `'  http://debian.org/    | http://www-personal.monash.edu/~anibal

Attachment: signature.asc
Description: Digital signature

Reply to: