[Debichem-devel] Will we manage to upgrade jmol

[Ximin Luo]

Andreas Tille:
> Hi,
> 
> On Tue, Nov 22, 2016 at 01:40:44PM +0100, Michael Banck wrote:
>>
>> [...]
>>
>>> [1] https://anonscm.debian.org/git/debichem/packages/jmol.git
>>
>> Ximin Luo has started packaging Jmol from scratch (thanks to Stuart
>> Prescott for pointing me to it) and came quite a long way here:
>>
>> https://github.com/infinity0/jmol
>>
>> Ximin, I'd be more than happy to add you to the Debichem project so you
>> can import and continue your work in that git repo.
>>
>> Or you take over maintainership yourself if you prefer that.
> 
> I'd be in favour of team maintenance in a repository at git.debian.org
> (either DebiChem or Debian Science).  Having repositories hanging around
> somewhere else kicks out several QA tools and should be avoided.
> 
> In any case thanks to Ximin Luo for his effort on Jmol
> 

Hi all, I would also prefer team maintenance. But just so you know, I'm unlikely to work on any other Debichem / Debian-Med packages, and I'm doing Jmol only because of SageMath. But you can add me to debichem if you like, and I'll use the existing git repo.

The task is definitely too big for one single maintainer. Let me explain the current situation in my github repo.

Jmol, JSpecView and JSpecViewLib are circularly-dependent on each other (on a source-level, i.e. at build-time) and can't be split without heavy re-factoring from upstream. Yes, JSV/JSVLib is "technically" in a separate sourceforge repo, but they copy Jmol source files across from ../Jmol and use them during the build. Jmol itself also uses JSV/JSVLib class files during the build. So the MUST be in the same Debian source package.

I tried to communicate this point to upstream but I don't think they understood this properly, and we had many other issues to talk about so I didn't try to spend more time explaining this in more detail.

What I am doing atm, instead of using the upstream tarball, is checking out Jmol + JSV + JSVLib from exact SVN revisions using a shell script. This is very awkward because upstream stores both end-result build products (.jar etc) as well as intermediate build products (source files copied from ../Jmol or ../JSpecView etc) so I also have to prune them before putting it all in a tarball:

https://github.com/infinity0/jmol/blob/master/debian/make-orig-tarball.sh

I am trying to ask upstream to take over this work but progress is very slow and I think there are some communication problems (possibly partly caused by bad mail<->sf interactions). See here for details:

https://sourceforge.net/p/jmol/bugs/587/?page=1 (the zeroth page is probably not worth your time reading, I summarise it in the rest of this email)

Anyway, once you put Jmol + JSV + JSVLib in the same Debian source package, you can call the Makefile (that I wrote myself) and produce all the jars etc. I think the newest version of Jmol actually has *less* dependencies than the one currently in Debian. So this task is doable, and with multiple maintainers the task of creating the orig-tarball becomes easier.

I will try to do the above before the stretch freeze, for SageMath. I plan to adapt the existing packaging that already exists in Debichem git, but using my github Jmol as the "orig" form and version of it.

What is currently blocking is JSmol. With some patching, this can probably be split from Jmol completely and perhaps even put into a separate Debian source package that depends on Jmol. However the build process is quite bad. Upstream's build process involves clicking on a bunch of buttons to run this Eclipse plugin:

https://github.com/infinity0/java2script/

I managed to figure out how to automate this completely, and you can build Debian binary packages using the this repo already. The downside is we will have to Build-Depends on eclipse-3.8. This is not ideal, but I don't see any other feasible options.

However for Debian *policy* purposes we are stuck on this issue:

https://github.com/zhourenjian/java2script/issues/8

I need to figure out how to generate 4 javascript files from their original java sources. I haven't had the time yet to do that, feel free to continue this work.

Then after this is complete, we will have to do a similar thing on the JSmol side:

https://sourceforge.net/p/jmol/bugs/589/

Then after that we can package JSmol.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git