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

Reply via email to