Importing the original repo about sge HOT 14 CLOSED

I don't know which the "release-tarballs" of the Debian people are and where I can find them.

But the one I have (from darcs) is definitely the latest development branch.
All other versions will not compile under Stretch because of OpenSSL 1.1.

I just tried it and the darcs clone builds Debian Stretch packages as version 8.1.9.

sge_8.1.9-1_amd64.deb  
sge-common_8.1.9-1_all.deb  
sge-dbg_8.1.9-1_amd64.deb  
sge-doc_8.1.9-1_all.deb

But without the latest patches I sent to the darcs ticket system, the master does not work.

from sge.

I don't know which the "release-tarballs" of the Debian people are and where I can find them.

Here is 8.1.9+dfsg

http://http.debian.net/debian/pool/main/g/gridengine/gridengine_8.1.9+dfsg.orig.tar.gz

But the one I have (from darcs) is definitely the latest development branch.
All other versions will not compile under Stretch because of OpenSSL 1.1.

OpenSSL 1.0 is available in Stretch. You get it from the libssl1.0-dev package: https://packages.debian.org/stretch/libssl1.0-dev

from sge.

I am mostly referring to the debian repo here
https://salsa.debian.org/hpc-team/gridengine.git
and @0xaf1f told me they base its source on the release tarballs from Dave (which I don't know exactly where they are from).

Anyway the differences between our repos and theirs are pretty small and I'm not sure how much we care that our tags of older versions don't fully line up with theirs-- I think we're mostly concerned about the future, not the past. If it's OK with @0xaf1f, I'd rather just continue from the current master, and apply Marco's patches, and get something that works without worrying about past release tags are 100% correct.

@Kunzol, how did you determine that your repo is smaller than this one?

from sge.

@0xaf1f told me they base its source on the release tarballs from Dave (which I don't know exactly where they are from).

Those used to be at http://arc.liv.ac.uk/downloads/SGE/releases, but it looks like Dave made them available at https://sourceforge.net/projects/gridengine/.

If it's OK with @0xaf1f, I'd rather just continue from the current master, and apply Marco's patches, and get something that works without worrying about past release tags are 100% correct.

I wonder if those tags should instead be deleted then. They didn't actually exist in this repository to begin with and, if they don't represent the labeled release, then it's probably better not to name them as such.

from sge.

from sge.

From the commit numbers and the date, this one is the "newest", which I call the "developer-branch":

https://arc.liv.ac.uk/trac/SGE/browser/sge

From this I made the git.

The release is the version tagged with 819, which is a bit behind. I assume this is the start point for packaging for several distros (debian, redhat, ...). I suggest we should switch to version 9.0.0 as soon as we are done adding all patches and get a first stable release. 8.1.8 is anyway not compatible with 8.1.9.

Debian has both libssl-1.1 and libssl-1.0. As we have the SGE code which works with 1.1 we should go for the newest.

We have now two "branches" we have to bring together.

• The developer branch plus patches in the ticket system, which are mainly fixes for the functionality
• The debian gitlab branch maintained by @0xaf1f which has a lot of fixes for packaging

Both are important and the only question is: Which one should we start with.

Personally I would start with the "developer branch" and go through each commit of @0xaf1f debian gitlab and add them.

We should always keep in mind that SGE is not only for Debian even if we do not have all platforms (Solaris, Windows, Redhat, ...) available to test. Currently I think we are still in line with this.

@Kunzol, how did you determine that your repo is smaller than this one?

@danpovey, I clone it and use "du"

from sge.

from sge.

I'm having trouble getting rid of commits that fail fsck.
Marco, is there any chance you could do your same process as you did before to get the git version of the darcs repo, but on the following source instead?
https://arc.liv.ac.uk/repos/darcs/sge-release/

from sge.

OK, I've managed to import the sge_release repo and its tags, and fortunately they seem to line up with what the Debian people had. I'm going to work on the assumption that the master of the 'sge' repo is the up-to-date master, and the tags from the 'sge-release' repo are accurate (which they do seem to be). I'll work on updating the tags in this repo to-morrow.

from sge.

OK, I have recreated the repo based on Marco's darcs-to-git. The master comes from Dave's 'sge' repo and the tags come from Dave's 'sge-release' repo. Marco, let's focus on getting your patches merged so we can compile without having to get the old OpenSSL source.

from sge.

Interesting, the github clone is still much (5 times!) larger that the one I produced with 'darcs-to-git'.

$ git clone https://github.com/son-of-gridengine/sge.git
Cloning into 'sge'...
remote: Counting objects: 72419, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 72419 (delta 34), reused 24 (delta 24), pack-reused 72382
Receiving objects: 100% (72419/72419), 407.35 MiB | 25.73 MiB/s, done.
Resolving deltas: 100% (56529/56529), done.
$ du -sh sge
465M    sge
$ git clone https://gitlab.bfabric.org/schmidt/sge.git mysge
Cloning into 'mysge'...
remote: Counting objects: 64836, done.
remote: Compressing objects: 100% (13681/13681), done.
remote: Total 64836 (delta 49488), reused 64836 (delta 49488)
Receiving objects: 100% (64836/64836), 27.75 MiB | 29.59 MiB/s, done.
Resolving deltas: 100% (49488/49488), done.
$ du -sh mysge
85M     mysge

from sge.

from sge.

You are right, after I did a "git gc --aggressive" it shrunk to about 85M, which is the same size as my clone.
Let's see if the automatic garbage collector will shrink it.

Anyway. We finishend importing the original source from the darcs repo at Liverpool.
I will now add the missing patches and create pull requests.
Best we close this and make new issues for the pull requests if needed.

Thanks for working together to make this a success!

from sge.

I'll try git gc --aggressive and then git push with the --mirror option, if github will allow it.

No -- thank you!
Closing this issue.

from sge.