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

[Adam C Powell IV]

Hello André,

On Thu, 2010-09-16 at 09:34 +0200, Andre Espaze wrote:
> > > 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.

I should probably try to quantify the difference between svg and png.
With svg, after building I get:

% du -s debian/salome-dev-doc/
720516	debian/salome-dev-doc/

I will try commenting those patches next time I build and will let you
know the size of -dev-doc.  (The package builds this now, but it's not a
binary package, because it's too big.  When the Debian infrastructure
changes a bit, then we can include it, though it will increase the
package size quite a bit!)

> > >     - 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).

Thanks.

> > > 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.

Sounds good.  You might see about having it use the bindir and libdir
variables which we set in the make commands, so it works for Debian and
the standard build.

> > 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.

Good idea for MPI_LIBS.

> > 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.

Good point!

> >  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.

Oh good, I'm glad to hear this, so they might accept it.

> > 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.

There's one more: I've dropped all of the -fix-clean patches because
using a separate build directory makes clean much simpler so we don't
need to maintain the patches.  If upstream accepts them, that's fine and
might help someone, but doesn't help us with the new build system.

> 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?

I think the Debian bug tracker is better for me, I find it easier to see
them and give feedback this way, and it's more of a standard Debian way
of doing things.

Thanks,
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/20100916/56ffa300/attachment-0001.pgp>