Re: Help on packaging advi (current status)
On Mon, Jan 03, 2005 at 05:50:44PM +0100, Helge Kreutzmann wrote:
> Hello,
> Sven Luther asked me to help in the packaging of advi. In the
Thanks Helge for the great job you do on this. I am also CCing advi upstream
on this, as they may have some comments that may prove usefull.
> following I list the points I have worked on/work on/will work on with
> some comments. Please tell me if you have specific requirements or
> disagree with a certain change. The intended time frame is over the
> next weeks, hopefully quite quick.
Make sure to put things in a branch of the advi package in the svn repo (svn
cp packages/advi/trunk packages/advi/branches/split or whatever name), and
checkin often, so we can all contribute.
> #233322:
> Status: In progress
> Things to discuss:
> a) movie
> The upstream tar ball is missing the example movie, probably due
> to size constraints, correct? I used a random mpeg-file from my
> disk (and a locally compiled mplayer) and it worked fine. I
> guess a note in README.Debian is sufficient
Would adding a smallish movie or something not be possible ?
> b) xanim
> The animations in the test/-directory use xanim. This works fine
> with a locally compiled xanim, but AFAIK xanim is (no-longer)
> shipped by Debian. I currently consider replacing the
> xanim-calls by animate calls as in the other demos.
Ok.
> c) exact relation to advi
> Currently I have a general dependency on advi >= the first
> version after the split, so people over slow links can only
> update the examples if really necessary. Whenever new demos are
> added, this needs to be checked, of course (e.g., if new
> features of advi are used)
Seems reasonable to me.
> d) size / playable / installer script
> I installed it in a way such that every dvi file is actually
> fully playable (except for the missing mpeg mentioned above) if
> all required software is installed. Unfortunately this increase
> the package size, as e.g., some eps-files must not be
Well, the obviously fix to this one would be to fix the advi bug which allows
to use compressed eps files. Will look into this next weel.
> compressed. I think this is ok, because advi only recommends it,
> so it can be skipped on disks with low space, and users can have
> a look as much as possible. Alternativly I can provide a script,
> which copies and uncompresses the demos, but then it would
> uncompress everything and users might run into their quotas.
> If #277654 is solved, than dics usage can be reduced again.
Indeed. Let's unpack it for now, until i look at this bug.
> e) build failures
> the test/-directory compiled fine, but in the examples I had to
> patch in two files. One patch might not be necessary (it sets an
> TEXINPUTS, which classhes with a locally set one), but in the
> other case I had to comment out some latex code as I did not
> understand what was going on:
> advi-1.6.0/examples/seminar/a14/mon-seminar.tex
> Right now it compiles, but I am not sure if I commented out, or
> too much.
> f) does advi embedd some eps?
> The files display fine, although some eps were only present at
> compile time (I think). I will investigate...
Mmm, which eps are those ?
> g) Short description (review after checkin) and exact dependencies
> (dito)
> h) Long term tetex-compatibility (e.g. prosper)
> As mentioned above, some code is not compatible with current
> tetex. Also I noticed, that several style files are included,
> some of which are not in Debian, some might (did not check). In
> a later stage, the styles in the examples should be checked and
> possibly synced with the ones shipped by Debian. But at least
> the source should be mentioned, if applicable, e.g.,
> xprosper.sty belongs to HA-Prosper, but this is nowhere
> mentioned (at least an URL should be provided)
> i) manual
> I think the manual should be added to the examples. Havn't done
> so because I was missing a build dependency
> j) does clean delete too much?
> While writing this, I notice that many things get deleted
> although they are in the upstream tarball -- I will investigate
> this (later)
> k) In test/, some ocaml code is compiled (e.g., taquin). Is this
> plattform independent, e.g., can this be shipped in an all package?
> If not, than this would defect one of the purposes of the
> package split (disk space saved on the mirrors). Right now I
> assume that it is indeed portable.
If it is bytecode then yet, try running file on them, and see what it says.
> #286457
> Status: Understood
> Things to discuss:
> I understand this now (I missed the .advirc files when first
> reporting). Unless someone objects, I close this one.
>
> #277654
> Status: Patch
> Things to discuss:
> I would simply link the man page for zadvi to the advi one and
> patch the man page to mention both.
>
> #286452
> Status: Patch
> Things to discuss:
> I will fix the spelling only and close it (the TODO should be
> updated sometime, but this is up to the real maintainers)
>
> #286454
> Status: Patch
> Things to discuss:
> I will correct the spelling but leave it open (point a))
>
> #286455
> Status: Patch
> Things to discuss:
> None (unless you propose a different spelling)
>
> #286456
> Status: Patch
> Things to discuss:
> I will apply a), d), f), g), h), j), l), o)
> The other items should be discussed and applied later, possibly
> cloning this bug.
>
> #286458
> Status: Patch
> Things to discuss:
> I will apply it along the lines of #277654 and the patch. Unless
> you dislike bzip2 functionality.
>
>
> If there are other rules/comments you'd like to be seen taken care of
> (beside the usual Debian packaging rules), please tell me which. Also
> I will commit the changes one by one when they are ready, so in case
> something has to be optimized, it still can be done.
Cool.
Friendly,
Sven Luther
Reply to: