[Pkg-octave-devel] Octave 3.4

[Thomas Weber]

On Tue, Dec 06, 2011 at 04:11:51PM +0100, Sébastien Villemot wrote:
> Thomas Weber <tweber at debian.org> writes:
> 
> > the current packaging can be found at 
> > http://anonscm.debian.org/gitweb/?p=users/tweber/octave.git;a=summary
> > It is based on the octave.git repository we have on git.debian.org.
> > Unless anybody sees some real problem with the repo, I intend to push to
> > our normal repository soon. Uploads will go to experimental.
> 
> Thanks for your work. I have been able to build the package, and I
> successfully tested it against a simple Dynare example.
> 
> I have a few small issues:
> 
> - dh_autoreconf_clean is not run by the clean rule. As a consequence,
>   modified autotools-generated files are left in the build tree. A patch
>   is attached. If this is intentional, it would be useful to add a
>   clarification comment in debian/rules.

Patch applied, thanks.

> - I cannot run git-buildpackage without the --git-ignore-new option,
>   because some files tracked by git are deleted by debian/clean. A
>   similar issue is discussed in this old thread:
> 
>    http://www.mail-archive.com/debian-ocaml-maint@lists.debian.org/msg22803.html
> 
>   ...and the conclusion is that a patch would be more appropriate for
>   removing generated files from upstream tarball. An alternative
>   solution would be to use "git update-index --assume-unchanged", but
>   this is local to a working copy and does not propagate to remote
>   repositories if my understanding is correct.

Sigh. The problem as I see it is: we must be able to regenerate the PDF
files (if we patch just one source file for them, they will be
regenerated anyway). But quilt has no support for binary files, so we
cannot simply patch the files away.

Suggestions welcome.

> - The current changelog entry does not list all the bugs closed in git
>   log messages, but I guess this is only because git-dch has not yet
>   been run

Yes, your guess is correct.

> The only real conflicts seem to concern the alternatives set up by
> octave3.2, octave3.2-headers and octave3.2-info. Since the conflict is
> going to be permanent, we have to use Conflicts and not Breaks (policy
> 7.4). A patch is attached.

Patch applied, thanks.

	Thomas