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

[Andre Espaze]

Hi Adam,

> > After a long break, I am back on the Salome packaging.
> 
> Welcome back!  I hope you enjoyed your break.
Sure, it was really nice.

> 
> > 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).
Ok, so I will make a try for this one too.
> 
> >     - 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!
Ok, I will try to submit it in that case, saying that is debatable (like
kernel-doc-images-svg.patch).
> 
> > 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 obviouis; 
Yes but I added it because it is required for illustrating how Salome
is built on Debian and moreover it shows that hard coded paths are
potentially a problem for custom module installations. In case upstream
is interested by such change, I plan to improve it.

> also, kernel-mpi-libs.patch uses
> the Debian-specific MPI symlink name libmpi++ .
Thanks for the precision, I thought libmpi++ was a standard. However should
we ask for a MPI_LIBS environment variable in the configure script?
It seems that '-lmpio -lmpiCC' is MPICH specific.
> 
> 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.
Yes they told me that too, however the changes should not break a serial
HDF5 version.

>  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.
Good news for this one, the file:
KERNEL_SRC_5.1.4/src/LifeCycleCORBA/SALOME_LifeCycleCORBA.cxx
uses already the '2>' syntax. So the remaining changes should pass.
> 
> 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.
Yes, I hope too.

Then what would be the relevant place for submitting patches of the
remaining modules? Is it a good idea to send them to the bugtracker
like I did for the kernel? Or could I let them on the Mercurial
repository of http://www.python-science.org/project/salome-packaging?

All the best,

André