Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion
Adam C Powell IV
hazelsct at debian.org
Sat Oct 2 15:06:14 UTC 2010
First, apologies for the delay in getting back to you on this. I was
waiting for an opportunity to sink a good amount of time into reviewing
your patches, and it didn't come, until I realized this morning that I
had missed your deadline by a day. :-(
On Thu, 2010-09-23 at 12:00 +0200, Andre Espaze wrote:
> Hello Adam,
> > > 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.
> I have enclosed in the 'salome-packaging-0.2.tar.gz' archive the patches
> updated to the 5.1.4 version for the KERNEL, GUI, GEOM, MED, SMESH and
> VISU modules. Once I get your agreement, I plan to send that archive to
> upstream because I am around half way of the porting task, with around
> 50 patches on 100. Moreover most of the essential modules are working.
> My concern is now to know which kind of patches are going to be accepted
> before continuing.
> The patches come with a documentation explaining briefly their
> meaning. Then the steps on how to build and run every module on Debian
> sid are described. I did not use the tools in the Debian packaging
> system (debian/rules, fakeroot, git-buildpackage, quilt) in order to
> ease the review process. Instead, I imitate the building process
> by listing commands. By that way, I hope that it will be possible
> to discuss with upstream on a specific point by directly using
> the commands provided by their build system.
Thank you for taking on this huge task! I can see that you've put an
enormous amount of work into making the patches really helpful for
My only concern about the whole thing is that the -debian-dirs patches
right now are not in good shape for upstream, so I think we should
figure out how to make them more generic using libdir and bindir before
sending them in. This will be very tricky for source code files, like
C++ code. The best way to do this will probably be to use -DBINDIR=...
and -DLIBDIR=... where those are substituted in the Makefile by
I'll see about converting those patches in this way. In the meantime, I
think everything else is ready to go in. Thanks again for a great piece
of work, and apologies again for the delay in getting this feedback to
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part
More information about the debian-science-maintainers