Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion
Andre Espaze
andre.espaze at logilab.fr
Wed Oct 13 15:38:34 UTC 2010
Hi Adam,
>
> 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. :-(
No problem, I understand that you are very busy. Thank you very much for
the review.
>
> 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
> upstream.
>
> 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
> configure.
Ok, it sounds good.
>
> 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
> you.
Are you working on those patches or may I try to help you? From now,
I understand that I should wait a little more before sending the first
release. By the end of the month, I can also send patches that are ready
to go in if you would prefer that option.
Best regards,
André
More information about the debian-science-maintainers
mailing list