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é -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
