[Pkg-gridengine-devel] Alioth membership and another update

[Dave Love]

Afif Elghraoui <afif at ghraoui.name> writes:

> Hi, all,
> I realized I never directly asked on this list--- May I be added to the
> alioth project for gridengine? My username is afif-guest and I had
> requested membership through the web interface some time ago. I'm also a
> DM, in case that information makes any difference.

I guess there's no-one to do it.  Sorry I hadn't realized you were a
DM.  I assumed "guest" meant not.

> So far, as I mentioned before, I've done my work on the package in my
> personal clone of the repository at
> <http://anonscm.debian.org/cgit/users/afif-guest/gridengine.git/>. I'd
> like to push my commits to the team repository, if possible.

I suppose I can do it indirectly if I still have the means to access it.

> I imported the latest SGE version 8.1.8 and made a few modifications to
> the packaging to get it to build.

I wonder how it failed to build.  I thought it was OK with my version of
the packaging, but no matter.

Well done for working on it.  I think things must have changed with
building since I started.  There are several changes I don't understand
or that won't be necessary in future:

* Add note to README.Debian telling users where to find example pe's

  These should be installed -- they are by inst_sge.

* Do not install the same manpages in both -client and -common

  I haven't followed where the duplication comes from, but I think
  qsched and qstatus should be in common.

* Unmark executable bit from READMEs

  I've pushed a change to obviate that which had been hanging around
  locally.

* Install the template modules configuration in a subfolder of /etc/gridengine

  Those are not environment modules and will cause trouble there.
  Module file are built by inst_sge.

* Move javadoc from gridengine-client into gridengine-common

  If anything, I think these should be in a -dev package, as in Fedora.

* Replace dependency on db-5.1 with unversioned package

  The db tools need to be consistent with the library version used in
  the build.

* Remove dependency on obsolete hardening-wrapper

  It doesn't seem obsolete according to the hardening web page.  I think
  I used it because it was difficult to make sure flags were passed
  through the horrible build system.

If there must be a default installation, I think it should set up CSP to
avoid users being able to impersonate each other.