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/
signature.asc
Description: This is a digitally signed message part
