Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

[Adam C Powell IV]

Hi Andre,

On Tue, 2010-09-14 at 10:45 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> After a long break, I am back on the Salome packaging.

Welcome back!  I hope you enjoyed your break.

> I was pleased
> to discover all your advances and the new building process for every
> module. Thank you very much for all your efforts. I think that it is
> the right time to start porting the patches to Salome 5.1.4 so we can
> submit them to upstream before a new release.

Great.  My highest priority right now is fixing the remaining RC bug,
having to do with building on minor architectures.  Hopefully the
release team will accept the major reorganization of the binary packages
and build process along with this...

In the meantime, I'm glad you're working on the patch porting!

> I have enclosed most of the patches for building the KERNEL module with
> the 5.1.4 version. Moreover a start of the documentation that I plan
> to send for patches submission can be found here:
> https://hg.python-science.org/salome-packaging/file/d60a8c2112dc/debian-patch-review.rst
> 
> However I wanted to discuss with you on 3 patches that I did not include
> because I thought that they concern Debian choices:
> 
>     - kernel-config-extra.patch

Definitely Debian-only

>     - kernel-doc-images-svg.patch

Upstream probably won't accept, I haven't seen a big reduction in the
documentation size with this patch (haven't tested though).

>     - kernel-install-without-docs.patch

This one is debatable.  I think that when most users do "make && make
install" they don't want to go through the entire documentation building
and installation process, so I would ask and see whether they would be
willing to accept this.  It certainly saves us a *ton* of build time and
disk space on the autobuilders, as when they only build for their own
arch, there is no reason to build and install the documentation!

> and this one does not make sense alone because the command is then
> renamed in 'debian/rules':
> 
>     - kernel-python-noexec.patch

I agree.

> In case you have arguments or ideas about how to submit them, I will
> include them in the report. Now I plan to continue on the following
> modules.

I have a couple more which perhaps should not go upstream.
kernel-debian-dirs.patch is obvious; also, kernel-mpi-libs.patch uses
the Debian-specific MPI symlink name libmpi++ .

In addition, kernel-hdf5-needs-mpi.patch might not be accepted:
Sylvestre tells me that upstream wants to use the "serial" HDF5 version,
not parallel.  And they might not accept kernel-replace-csh-stderr.patch
because I think upstream uses csh/tcsh a lot, and I don't think the 2>
syntax works there.

But kernel-debian-occ.patch *should* go upstream -- it's compatible both
with the traditional OCC install locations, and the Debian/Ubuntu
locations, which are becoming more commonplace and significant.

All the rest look good.

> All the best,

Thanks, it's good to see you back!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20100914/96237f29/attachment.pgp>