Debian Bug report logs - #457075
ITP: salome -- framework for engineering simulation

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Debian Bugs <submit@bugs.debian.org>

Subject: RFP: Salomé

Date: Wed, 19 Dec 2007 10:07:47 -0500

Package: wnpp
Severity: wishlist

Package name: salome
Version: 3.2.6
Author: Open Cascade SAS (OCC), a French software services company
URL: http://www.salome-platform.org/
License: LGPL
Description: Engineering simulation framework

Salomé is a powerful LGPL framework for engineering simulations.  It has
CAD capability within itself, can import and export CAD files in IGES
format, can mesh those files, and control an external parallel solver
such as Code Aster, then visualize the results.  Salomé is at the heart
of the new CAELinux (Computer-Aided Engineering Linux) live DVD
distribution.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

Message #16 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: 457075@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: RFP: Salomé

Date: Wed, 02 Jan 2008 08:08:06 -0500

retitle 457075 ITP: Salomé
thanks

I'm actively working on this package and its dependencies, most notably
OpenCASCADE, and should have something ready by 1/3.

On Wed, 2007-12-19 at 10:07 -0500, Adam C Powell IV wrote:
> Package: wnpp
> Severity: wishlist
> 
> Package name: salome
> Version: 3.2.6
> Author: Open Cascade SAS (OCC), a French software services company
> URL: http://www.salome-platform.org/
> License: LGPL
> Description: Engineering simulation framework
> 
> Salomé is a powerful LGPL framework for engineering simulations.  It has
> CAD capability within itself, can import and export CAD files in IGES
> format, can mesh those files, and control an external parallel solver
> such as Code Aster, then visualize the results.  Salomé is at the heart
> of the new CAELinux (Computer-Aided Engineering Linux) live DVD
> distribution.
> 
> -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

Message #27 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Jordi Mallach <jordi@debian.org>

To: debian-science@lists.debian.org

Cc: 457075@bugs.debian.org

Subject: Status of Salomé packaging

Date: Thu, 21 Aug 2008 13:19:27 +0200

Hi Adam & rest of list,

I've been checking the archives for progress on Salomé's ITP, which
seemed quite promising back in March. However, after the success with
the OpenCASCADE effort, I see no more references to Salomé.

Is the ITP stalled for some licensing reason, or do the compile problems
still apply and have not been resolved yet?

Thanks in advance for the info!

Jordi

PS: please CC, I'm not subscribed to this list.
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Message #32 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Jordi Mallach <jordi@debian.org>, 457075@bugs.debian.org

Cc: debian-science@lists.debian.org

Subject: Re: Bug#457075: Status of Salomé packaging

Date: Thu, 21 Aug 2008 08:02:40 -0400

[Message part 1 (text/plain, inline)]

On Thu, 2008-08-21 at 13:19 +0200, Jordi Mallach wrote:
> Hi Adam & rest of list,
> 
> I've been checking the archives for progress on Salomé's ITP, which
> seemed quite promising back in March. However, after the success with
> the OpenCASCADE effort, I see no more references to Salomé.
> 
> Is the ITP stalled for some licensing reason, or do the compile problems
> still apply and have not been resolved yet?

I have resolved the compile problems, but at runtime, none of the
modules load.  (As noted in this bug, you can get the latest at
http://lyre.mit.edu/~powell/salome/ .)  I've solved this problem before,
and could solve it again.

But upstream practices are really frustrating me.  They released a new
binary 3.2.9 Salomé-MECA back in -- forgot, March? -- but with no source
code.  So any new effort I make is already obsolete.  Furthermore, they
have never released the source of the MECA extensions, even though this
is supposed to be an open source project.

To add insult to injury, they have *never* replied to ANY of my emails
or website inquiries.  (I even took the time to write to specific
developers in French, but with no reply.)  I have put a *TON* of effort
into this, on the order of 100 hours, as you can see from the nearly 50
patches, and really feel blown off and disrespected by upstream.

At some point I'll give up on upstream and go ahead and fix the 3.2.6
package, essentially maintaining a Debian fork until upstream releases
more source.  But this is a very low priority for the above reasons.

While ranting about upstream, I should thank Sylvestre Ledru for
participating in the discussion with upstream, including using some of
his contacts to try to move this along.  I hear there will be a meeting
in September to try to resolve some of these issues, and will return to
packaging work if something comes out of this process.

> PS: please CC, I'm not subscribed to this list.

[Likewise for followups.]

-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 (application/pgp-signature, inline)]

Message #37 received at 457075@bugs.debian.org (full text, mbox, reply):

From: "Ondrej Certik" <ondrej@certik.cz>

To: "Adam C Powell IV" <hazelsct@debian.org>

Cc: "Jordi Mallach" <jordi@debian.org>, 457075@bugs.debian.org, debian-science@lists.debian.org

Subject: Re: Bug#457075: Status of Salomé packaging

Date: Thu, 21 Aug 2008 15:47:14 +0200

On Thu, Aug 21, 2008 at 2:02 PM, Adam C Powell IV <hazelsct@debian.org> wrote:
> On Thu, 2008-08-21 at 13:19 +0200, Jordi Mallach wrote:
>> Hi Adam & rest of list,
>>
>> I've been checking the archives for progress on Salomé's ITP, which
>> seemed quite promising back in March. However, after the success with
>> the OpenCASCADE effort, I see no more references to Salomé.
>>
>> Is the ITP stalled for some licensing reason, or do the compile problems
>> still apply and have not been resolved yet?
>
> I have resolved the compile problems, but at runtime, none of the
> modules load.  (As noted in this bug, you can get the latest at
> http://lyre.mit.edu/~powell/salome/ .)  I've solved this problem before,
> and could solve it again.
>
> But upstream practices are really frustrating me.  They released a new
> binary 3.2.9 Salomé-MECA back in -- forgot, March? -- but with no source
> code.  So any new effort I make is already obsolete.  Furthermore, they
> have never released the source of the MECA extensions, even though this
> is supposed to be an open source project.
>
> To add insult to injury, they have *never* replied to ANY of my emails
> or website inquiries.  (I even took the time to write to specific
> developers in French, but with no reply.)  I have put a *TON* of effort
> into this, on the order of 100 hours, as you can see from the nearly 50
> patches, and really feel blown off and disrespected by upstream.
>
> At some point I'll give up on upstream and go ahead and fix the 3.2.6
> package, essentially maintaining a Debian fork until upstream releases
> more source.  But this is a very low priority for the above reasons.
>
> While ranting about upstream, I should thank Sylvestre Ledru for
> participating in the discussion with upstream, including using some of
> his contacts to try to move this along.  I hear there will be a meeting
> in September to try to resolve some of these issues, and will return to
> packaging work if something comes out of this process.

This is really frustrating. Sorry to hear that! That's why I prefer
small tools, or tools that are simple in nature, so that in the worse
case one can maintain it alone if upstream decides to close the
source.

Ondrej

Message #42 received at 457075@bugs.debian.org (full text, mbox, reply):

From: "Christophe Prud'homme" <prudhomm@debian.org>

To: "Ondrej Certik" <ondrej@certik.cz>

Cc: "Adam C Powell IV" <hazelsct@debian.org>, "Jordi Mallach" <jordi@debian.org>, 457075@bugs.debian.org, debian-science@lists.debian.org

Subject: Re: Bug#457075: Status of Salomé packaging

Date: Thu, 21 Aug 2008 22:28:32 +0200

To follow Ondrej comment,

I have been in contact with some people close to the Salome  project.
With almost the same ones we are going to
have a "similar project" to build a recently funded  open platform
(OPUS) for uncertainty quantification in simulations possibly based on
openturns (in the NEW queue). I will be extra careful that Salome's
mess doesn't happen again. I also try at each meeting to bring forth
Debian's (Adam's and others) huge efforts  to bring Salome to its
users.

Best regards
C.

Message #47 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: 457075@bugs.debian.org

Cc: Jordi Mallach <jordi@debian.org>, debian-science@lists.debian.org

Subject: Re: Bug#457075: Status of Salomé packaging

Date: Fri, 22 Aug 2008 08:14:19 -0400

[Message part 1 (text/plain, inline)]

On Thu, 2008-08-21 at 22:28 +0200, Christophe Prud'homme wrote:
> To follow Ondrej comment,
> 
> I have been in contact with some people close to the Salome  project.
> With almost the same ones we are going to
> have a "similar project" to build a recently funded  open platform
> (OPUS) for uncertainty quantification in simulations possibly based on
> openturns (in the NEW queue). I will be extra careful that Salome's
> mess doesn't happen again. I also try at each meeting to bring forth
> Debian's (Adam's and others) huge efforts  to bring Salome to its
> users.

Thank you very much Christophe.  It would be terrific to have a
cooperative partner in the Salomé upstream developers.  I think they
share our goal of broadening the use of this amazing project by making
it much easier to install and use in Debian and derivative distros, and
I look forward to being a part of a future vibrant Salomé user/developer
community.

-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 (application/pgp-signature, inline)]

Message #52 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Jordi Mallach <jordi@debian.org>

To: 457075@bugs.debian.org, debian-science@lists.debian.org

Cc: Adam C Powell IV <hazelsct@debian.org>

Subject: Re: Bug#457075: Status of Salomé packaging

Date: Tue, 26 Aug 2008 11:34:34 +0200

[Message part 1 (text/plain, inline)]

On Thu, Aug 21, 2008 at 08:02:40AM -0400, Adam C Powell IV wrote:
> I have resolved the compile problems, but at runtime, none of the
> modules load.  (As noted in this bug, you can get the latest at
> http://lyre.mit.edu/~powell/salome/ .)  I've solved this problem before,
> and could solve it again.
> 
> But upstream practices are really frustrating me.  They released a new
> binary 3.2.9 Salomé-MECA back in -- forgot, March? -- but with no source
> code.  So any new effort I make is already obsolete.  Furthermore, they
> have never released the source of the MECA extensions, even though this
> is supposed to be an open source project.
> 
> To add insult to injury, they have *never* replied to ANY of my emails
> or website inquiries.  (I even took the time to write to specific
> developers in French, but with no reply.)  I have put a *TON* of effort
> into this, on the order of 100 hours, as you can see from the nearly 50
> patches, and really feel blown off and disrespected by upstream.

I am very sorry to learn about this. Hopefully the situation can be
straightened with Christophe's mediation.

> At some point I'll give up on upstream and go ahead and fix the 3.2.6
> package, essentially maintaining a Debian fork until upstream releases
> more source.  But this is a very low priority for the above reasons.
> 
> While ranting about upstream, I should thank Sylvestre Ledru for
> participating in the discussion with upstream, including using some of
> his contacts to try to move this along.  I hear there will be a meeting
> in September to try to resolve some of these issues, and will return to
> packaging work if something comes out of this process.

I am interested in having official Salomé Debian packages as it seems
we'll have to do an install for a client at work, and naturally I prefer
.debs for everything. From the threads I've read on the mailing list, it
looks like a .deb would really simplify the job.

I'll try to keep an eye on this bug report for new updates, if any.

Adam, it's evident you've invested lots of effort and patience into this
package and its dependencies. You have a big Thank You! from me for the
result so far. Let's hope things change for the better in the near
future!

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

[signature.asc (application/pgp-signature, inline)]

Message #57 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>

To: 457075@bugs.debian.org, 457075-subscribe@bugs.debian.org

Subject: Salome platform - Progress?

Date: Fri, 12 Jun 2009 04:43:18 +0100

Any progress on Salome platform packaging? ITP #457075 ?

=/



-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

Message #62 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>, 457075@bugs.debian.org

Subject: Re: Bug#457075: Salome platform - Progress?

Date: Fri, 12 Jun 2009 10:02:32 -0400

[Message part 1 (text/plain, inline)]

On Fri, 2009-06-12 at 04:43 +0100, Dmitrijs Ledkovs wrote:
> Any progress on Salome platform packaging? ITP #457075 ?

No, afraid I haven't even tried the new version.  My old package is
available at http://lyre.mit.edu/~powell/salome/ but it took some 100+
hours to patch it to get to that state, and upstream *never* replied to
*any* of my inquiries about merging my patches, even when I tracked down
a developer through some other leads and wrote a long email in French.

The good news is that with OpenCASCADE in main and Qt 4.5 with LGPL,
Salomé is now legal -- and can go into main.

I could just upload my old package, but don't have a lot of impetus to
work on anything new.  Feel free to pick it up and work on it yourself.
I've moved on to Gmsh and Elmer for my work.

> =/

Indeed...

-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 (application/pgp-signature, inline)]

Message #67 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org

Subject: Re: Bug#457075: Salome platform - Progress?

Date: Fri, 12 Jun 2009 15:16:18 +0100

2009/6/12 Adam C Powell IV <hazelsct@debian.org>:
> On Fri, 2009-06-12 at 04:43 +0100, Dmitrijs Ledkovs wrote:
>> Any progress on Salome platform packaging? ITP #457075 ?
>
> No, afraid I haven't even tried the new version.  My old package is
> available at http://lyre.mit.edu/~powell/salome/ but it took some 100+
> hours to patch it to get to that state, and upstream *never* replied to
> *any* of my inquiries about merging my patches, even when I tracked down
> a developer through some other leads and wrote a long email in French.
>

Thanks a lot for your work.

> The good news is that with OpenCASCADE in main and Qt 4.5 with LGPL,
> Salomé is now legal -- and can go into main.
>

This is certainly interesting.

> I could just upload my old package, but don't have a lot of impetus to
> work on anything new.  Feel free to pick it up and work on it yourself.
> I've moved on to Gmsh and Elmer for my work.
>

I do consider Gmsh. It is nice. But is there anything better than gmsh
for creating geometry models in IGES and STEP (NURBS ;-) )?


>> =/
>
> Indeed...
>

Heh. One day all upstreams will become amazing and friendly.......

> -Adam
> --
> GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
>
> Engineering consulting with open source tools
> http://www.opennovation.com/
>



-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

Message #72 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>, 457075@bugs.debian.org

Subject: Re: Bug#457075: Salome platform - Progress?

Date: Mon, 15 Jun 2009 11:27:17 -0400

[Message part 1 (text/plain, inline)]

On Fri, 2009-06-12 at 15:16 +0100, Dmitrijs Ledkovs wrote:
> 2009/6/12 Adam C Powell IV <hazelsct@debian.org>:
> > On Fri, 2009-06-12 at 04:43 +0100, Dmitrijs Ledkovs wrote:
> >> Any progress on Salome platform packaging? ITP #457075 ?
> >
> > No, afraid I haven't even tried the new version.
> 
> > I could just upload my old package, but don't have a lot of impetus to
> > work on anything new.  Feel free to pick it up and work on it yourself.
> > I've moved on to Gmsh and Elmer for my work.
> >
> 
> I do consider Gmsh. It is nice. But is there anything better than gmsh
> for creating geometry models in IGES and STEP (NURBS ;-) )?

I don't know, but Elmer imports the formats I need.

> >> =/
> >
> > Indeed...
> >
> 
> Heh. One day all upstreams will become amazing and friendly.......

"I have a dream..." :-)

-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 (application/pgp-signature, inline)]

Message #77 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: 457075@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: RFP: salome -- a LGPL framework for engineering simulation

Date: Sun, 29 Nov 2009 20:31:44 -0500

[Message part 1 (text/plain, inline)]

retitle 457075 RFP: salome-- a LGPL framework for engineering simulation
thanks

Wow, switched to ITP nearly two years ago.  Apologies to those who
avoided packaging on seeing the ITP.

My earlier work is at: http://lyre.mit.edu/~powell/salome/

-Adam

On Wed, 2008-01-02 at 08:08 -0500, Adam C Powell IV wrote:
> retitle 457075 ITP: Salomé
> thanks
> 
> I'm actively working on this package and its dependencies, most notably
> OpenCASCADE, and should have something ready by 1/3.
> 
> On Wed, 2007-12-19 at 10:07 -0500, Adam C Powell IV wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > Package name: salome
> > Version: 3.2.6
> > Author: Open Cascade SAS (OCC), a French software services company
> > URL: http://www.salome-platform.org/
> > License: LGPL
> > Description: Engineering simulation framework
> > 
> > Salomé is a powerful LGPL framework for engineering simulations.  It has
> > CAD capability within itself, can import and export CAD files in IGES
> > format, can mesh those files, and control an external parallel solver
> > such as Code Aster, then visualize the results.  Salomé is at the heart
> > of the new CAELinux (Computer-Aided Engineering Linux) live DVD
> > distribution.
> > 
> > -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 (application/pgp-signature, inline)]

Message #84 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>

Cc: 457075@bugs.debian.org

Subject: Re: Bug#457075: Salome platform - Progress?

Date: Sun, 29 Nov 2009 21:33:08 -0500

[Message part 1 (text/plain, inline)]

Hello again,

On Mon, 2009-06-15 at 11:27 -0400, Adam C Powell IV wrote:
> On Fri, 2009-06-12 at 15:16 +0100, Dmitrijs Ledkovs wrote:
> > 2009/6/12 Adam C Powell IV <hazelsct@debian.org>:
> > > On Fri, 2009-06-12 at 04:43 +0100, Dmitrijs Ledkovs wrote:
> > >> Any progress on Salome platform packaging? ITP #457075 ?
> > >
> > > No, afraid I haven't even tried the new version.
> > 
> > > I could just upload my old package, but don't have a lot of impetus to
> > > work on anything new.  Feel free to pick it up and work on it yourself.
> > > I've moved on to Gmsh and Elmer for my work.
> > >
> > 
> > I do consider Gmsh. It is nice. But is there anything better than gmsh
> > for creating geometry models in IGES and STEP (NURBS ;-) )?
> 
> I don't know, but Elmer imports the formats I need.

Just wanted to follow up on this: FreeCAD is now in unstable and
testing, and is a nice CAD framework which aims for a very extensive
feature set.  It's not yet 1.0, but is probably something you would find
helpful.

Also, I just converted my ITP bug for Salome to an RFP, I had been
taking too long and didn't want to discourage anyone from working on it.

-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 (application/pgp-signature, inline)]

Message #91 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: 457075@bugs.debian.org

Cc: control@bugs.debian.org, Dmitrijs Ledkovs <dmitrij.ledkov@gmail.com>, Gerber van der Graaf <gerber.vdgraaf@gmail.com>, Sylvestre Ledru <sylvestre@debian.org>

Subject: Re: RFP: salome -- a LGPL framework for engineering simulation

Date: Thu, 07 Jan 2010 07:10:02 -0500

[Message part 1 (text/plain, inline)]

retitle 457075 ITP: salome -- framework for engineering simulation
thanks

I'm actually making some progress on a package, so I'm going to go back
to an ITP.  5.1.3-1 is at the URL below, though only two modules build,
and I have yet to attempt any testing, so it's definitely not ready to
upload.

I'll either make rapid progress in the next couple of days, or it will
wait for a few weeks...  In the meantime, feel free to build on it.

-Adam

On Sun, 2009-11-29 at 20:31 -0500, Adam C Powell IV wrote:
> retitle 457075 RFP: salome-- a LGPL framework for engineering simulation
> thanks
> 
> Wow, switched to ITP nearly two years ago.  Apologies to those who
> avoided packaging on seeing the ITP.
> 
> My earlier work is at: http://lyre.mit.edu/~powell/salome/
> 
> -Adam
> 
> On Wed, 2008-01-02 at 08:08 -0500, Adam C Powell IV wrote:
> > retitle 457075 ITP: Salomé
> > thanks
> > 
> > I'm actively working on this package and its dependencies, most notably
> > OpenCASCADE, and should have something ready by 1/3.
> > 
> > On Wed, 2007-12-19 at 10:07 -0500, Adam C Powell IV wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > 
> > > Package name: salome
> > > Version: 3.2.6
> > > Author: Open Cascade SAS (OCC), a French software services company
> > > URL: http://www.salome-platform.org/
> > > License: LGPL
> > > Description: Engineering simulation framework
> > > 
> > > Salomé is a powerful LGPL framework for engineering simulations.  It has
> > > CAD capability within itself, can import and export CAD files in IGES
> > > format, can mesh those files, and control an external parallel solver
> > > such as Code Aster, then visualize the results.  Salomé is at the heart
> > > of the new CAELinux (Computer-Aided Engineering Linux) live DVD
> > > distribution.
> > > 
> > > -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 (application/pgp-signature, inline)]

Message #98 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: 457075@bugs.debian.org

Subject: Salomé packaging

Date: Sun, 10 Jan 2010 14:29:03 -0500

[Message part 1 (text/plain, inline)]

Greetings,

For those interested, I'm re-doing the Salomé .deb I started three years
ago.  Salomé is a finite element pre-post processing framework, with a
lot of other things in there as well.

Though some things have improved between version 3.2.6 and 5.1.3, many
have not, so although this likely won't take 100+ hours like the last
one did, it's taking more effort than I can give to it.  I've got five
modules configuring, compiling and installing, but will not be able to
work on it for the next couple of weeks.

<rant>Among other things, it needs major updates for modern compilers,
for OpenMPI, and for new versions of other packages.  It amazes me that
upstream can get it to build at all, but then, they seem to only build
to certain particular narrow (and old) platforms/targets, and don't
accept outside patches (never looked at the 50+ I generated last time),
so it is not surprising that this is the result.</rant>

Because I can't do the whole package, I'm putting up the progress I've
made thus far at http://lyre.mit.edu/~powell/salome/ for others to work
on.  The -2 .dsc and .debian.tar.gz files are there, the rest will
follow later today.  I'm reluctant to put it in git until an audit turns
up the non-free and other troublesome files, to avoid having to change
the upstream branch and dfsg tarball too many times.  (I've only audited
the first two modules thus far, which seem dfsg-clean.)

Speaking of which, random -legal question: one directory has a .sxw,
a .pdf and a .ps.  The .pdf and ps files are clearly generated from the
sxw.  Does a .dfsg tarball have to remove the .pdf and .ps files, and
somehow re-generate them from the .sxw, or can it just leave them in?
Is there a way to script OO.o to generate a .pdf from a .sxw?

Note: the files whose debian/patches/series entries are commented are
old patches from 3.2.6 which I haven't backported.  They're there to
provide some guidance into how to fix problems related to those I fixed
back then.  The uncommented patches are new, and many of them are ready
to go to upstream.  A few others need only to be made more general
before going upstream, e.g. test for files in dependency packages both
where upstream installs them and where Debian installs them, etc.

To summarize, I need help with the following:
      * Copyright audit of the tree
      * Getting the other modules to configure, compile and install
      * Making patches upstream-compatible, and sending them to upstream

Hopefully in a month or two we'll have both a good Salomé package in
Debian, and a more enlightened upstream!

-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 (application/pgp-signature, inline)]

Message #103 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: pyves@logilab.fr, dede@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Sun, 10 Jan 2010 17:53:21 -0500

[Message part 1 (text/plain, inline)]

On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote:
> Hi,
> 
> On Sun, Jan 10, 2010 at 02:29:03PM -0500, Adam C Powell IV wrote:
> > For those interested, I'm re-doing the Salomé .deb I started three years
> > ...
> > Because I can't do the whole package, I'm putting up the progress I've
> > ...
> > To summarize, I need help with the following:
> >       * ...
> >       * Getting the other modules to configure, compile and install
> >       * Making patches upstream-compatible, and sending them to upstream
> 
> As part of the OpenHPC project[1], Logilab commited itself to package
> Salomé for Debian. We had seen the great work you have done and are
> glad that you are resuming it.

Wow, thank you for this terrific news!  Have you started to forward-port
the old patches to a new package, or are you using a different approach?

A correction: most of my work on this was two years ago, not three.

> André Espaze has been developing a connector between Salomé and
> Code_Aster for the past few months. He is about to continue his work
> with the packaging of Salomé. He will have the help of Pierre-Yves
> David. We also have a Debian developer on the team, Alexandre Fayolle,
> but he will not have a lot of time for this particular project in the
> upcoming months.

Okay.  Let me know how I can best fit in with your plans for this
project.

> I am cc'ing every person involved to make sure everyone can get in
> touch easily. Is debian-science the best place to discuss this topic
> or should we take the discussion off-list?

I think this list is pretty good as long as we are talking about
generalities, as I think some of the people on the list will have good
suggestions.  When we start to get into the details of patches and the
package, maybe it will make sense to go off-list.

> Hopefully, the fact that we have been working with upstream for years
> will help us get this work done more easily.

This is terrific.  My patches are Debian-specific, and need some work to
make them fit the needs of both upstream and Debian.  This gives me hope
that doing that work will help to actually get the patches into the
upstream source!

This is the best news I've heard in a long time.  Thanks again, I look
forward to working with you.

Regards,
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 (application/pgp-signature, inline)]

Message #108 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: pyves@logilab.fr, dede@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Mon, 25 Jan 2010 11:45:27 -0500

[Message part 1 (text/plain, inline)]

Hello again,

I now have 10 modules enabled, and have made all but one of the patches
upstream-friendly, though I've only uploaded the -3 source package to
http://lyre.mit.edu/~powell/salome/ at the moment.

Nicolas, can you do me a favor and try to push some of the patches
upstream?  You can find them in the salome_5.1.3-3.debian.tar.gz file,
in the debian/patches directory; I can send them to you individually if
you prefer.  The patches fall into in several categories, and are
separated out by module:

      * *-safe-include: Eliminate extern "C" blocks where they are
        unnecessary -- and even harmful, as they break building with
        OpenMPI.  See the patch head for details.
      * *-cleanup: Fixes for compiler bugs which break the build with
        recent compilers.
      * *-hdf5-needs-mpi: The HDF5 header and library files need MPI in
        order to work, so this includes the MPI -I and -L flags in with
        those of HDF5, and puts MPI checks before HDF5 ones.
      * *-mpich-mpi: Replace MPICH checks with MPI checks, as I've made
        it compatible with OpenMPI.
      * *-use-gui-check: Use check_GUI.m4 in the GUI module directory,
        instead of the rewritten version of that file in several other
        module directories.
      * *-build-in-tree: Debian requires that the whole package build
        first, then install.  These patches make this possible.

These patches will not only make it easier to maintain the package, but
will assist anyone building Salomé on Debian/Ubuntu in the future.  And
all of them should preserve the ability to build as before, let me know
if that is not the case.

Other specific patches:

      * kernel-remove-mpi-undefs: Not sure why these undefs are there,
        they break OpenMPI compatibility.
      * kernel-occ-includes: Search for OpenCASCADE header files both in
        the default location when building OCC from source and also in
        the Debian/Ubuntu package location.
      * hxx2solame-destdir: Use DESTDIR for install.
      * med-scotch: Search for Scotch files both in the default location
        when building Scotch from source and also in the Debian/Ubuntu
        package location.
      * med-missing-libs: Add the MED libraries to the mprint_version
        link command.
      * visu-flags-typo: Fix incorrect automake flags variable.
      * kernel-mpi-libs: This is the one which should *not* go upstream,
        as it tests for the Debian-specific MPI alternative symlink lib
        names.

Now for one problem.  The VISU module doesn't completely compile,
because of a symbol/prototype incompatibility within its CONVERTER
library.  I don't know quite enough C++ to fix this, can someone help?

Before upload, I think this needs a few more modules, a full copyright
audit, and at least a working GUI shell.  I've only done the audit for
the first two modules (KERNEL and HXX2SALOME), and haven't tried running
the shell yet...

Cheers,
Adam

On Sun, 2010-01-10 at 17:53 -0500, Adam C Powell IV wrote:
> On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote:
> > Hi,
> > 
> > As part of the OpenHPC project[1], Logilab commited itself to package
> > Salomé for Debian. We had seen the great work you have done and are
> > glad that you are resuming it.
> 
> Wow, thank you for this terrific news!  Have you started to forward-port
> the old patches to a new package, or are you using a different approach?
> 
> A correction: most of my work on this was two years ago, not three.
> 
> > André Espaze has been developing a connector between Salomé and
> > Code_Aster for the past few months. He is about to continue his work
> > with the packaging of Salomé. He will have the help of Pierre-Yves
> > David. We also have a Debian developer on the team, Alexandre Fayolle,
> > but he will not have a lot of time for this particular project in the
> > upcoming months.
> 
> Okay.  Let me know how I can best fit in with your plans for this
> project.
> 
> > I am cc'ing every person involved to make sure everyone can get in
> > touch easily. Is debian-science the best place to discuss this topic
> > or should we take the discussion off-list?
> 
> I think this list is pretty good as long as we are talking about
> generalities, as I think some of the people on the list will have good
> suggestions.  When we start to get into the details of patches and the
> package, maybe it will make sense to go off-list.
> 
> > Hopefully, the fact that we have been working with upstream for years
> > will help us get this work done more easily.
> 
> This is terrific.  My patches are Debian-specific, and need some work to
> make them fit the needs of both upstream and Debian.  This gives me hope
> that doing that work will help to actually get the patches into the
> upstream source!
> 
> This is the best news I've heard in a long time.  Thanks again, I look
> forward to working with you.
> 
> Regards,
> 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 (application/pgp-signature, inline)]

Message #113 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: pyves@logilab.fr, dede@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Tue, 26 Jan 2010 10:22:12 -0500

[Message part 1 (text/plain, inline)]

Sorry, forgot to mention a couple of things yesterday.  First, the
package doesn't build in current unstable, because HDF5 transitioned and
MED didn't transition with it.  I may be able to help with MED to
resolve this, but not until next week.  (It builds fine in my unstable
chroot updated a few days ago, but that machine doesn't have enough disk
space to build the whole thing.)

On Mon, 2010-01-25 at 11:45 -0500, Adam C Powell IV wrote:
> Now for one problem.  The VISU module doesn't completely compile,
> because of a symbol/prototype incompatibility within its CONVERTER
> library.  I don't know quite enough C++ to fix this, can someone help?

Second, the log with this build failure is in
http://lyre.mit.edu/~powell/salome/salome_5.1.3-3_amd64.build - search
for *** .  The relevant files are
VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx and .hxx.  I
don't understand why TGetFieldData in the prototype with the vtkDataSet*
argument works for both TGetPointData and TGetCellData but the one with
the VISU::TFieldList* argument doesn't...

-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 (application/pgp-signature, inline)]

Message #118 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 17:32:35 +0100

Hi Adam,

I am André Espaze, the Logilab's employee supposed to help you in the
Salomé packaging for Debian. First I wanted to thank you for the great
work that you did on the current package. Then I would like to let you
know my progress on the testing part.

I have succeeded to build most of the Salomé modules with the 
version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ 
however I wanted to discuss the following problems:

    - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4"
    else vtk is not found and many components do not build.
    - it lacks the omniorb4-nameserver package in the dependency list 
    else the KERNEL component does not find the omniNames command.
    - as you said, the med 2.3.5 library needs to be built manually 
    with hdf5-1.8.4 but the main problem is that tests do not pass 
    in that case.
    - it seems to lack the 'config.h' file in the libopencascade-* 
    packages. Else do you know where that file could be? I fear that 
    some components (like GEOM) really need it.
    - the GEOM module crashes when trying to add a geometrical object

You can find all the steps that I did, more details and also more problems 
at: http://www.python-science.org/ticket/1383

How to you plan to collaborate on the package building? I would suggest
to use the project http://www.python-science.org/project/salome-packaging
because I can be efficiently organized on such a platform. Would you
like to add a git or mercurial repository on which we will share the
package source code?

I am looking forward to work with you,

André

On Tue, Jan 26, 2010 at 10:22:12AM -0500, Adam C Powell IV wrote:
> Sorry, forgot to mention a couple of things yesterday.  First, the
> package doesn't build in current unstable, because HDF5 transitioned and
> MED didn't transition with it.  I may be able to help with MED to
> resolve this, but not until next week.  (It builds fine in my unstable
> chroot updated a few days ago, but that machine doesn't have enough disk
> space to build the whole thing.)
> 
> On Mon, 2010-01-25 at 11:45 -0500, Adam C Powell IV wrote:
> > Now for one problem.  The VISU module doesn't completely compile,
> > because of a symbol/prototype incompatibility within its CONVERTER
> > library.  I don't know quite enough C++ to fix this, can someone help?
> 
> Second, the log with this build failure is in
> http://lyre.mit.edu/~powell/salome/salome_5.1.3-3_amd64.build - search
> for *** .  The relevant files are
> VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx and .hxx.  I
> don't understand why TGetFieldData in the prototype with the vtkDataSet*
> argument works for both TGetPointData and TGetCellData but the one with
> the VISU::TFieldList* argument doesn't...
> 
> -Adam
> -- 
> GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
> 
> Engineering consulting with open source tools
> http://www.opennovation.com/

Message #123 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Denis Barbier <bouzim@gmail.com>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: Adam C Powell IV <hazelsct@debian.org>, debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 18:09:14 +0100

On 2010/2/11 Andre Espaze:
[...]
>    - it seems to lack the 'config.h' file in the libopencascade-*
>    packages. Else do you know where that file could be? I fear that
>    some components (like GEOM) really need it.
[...]

Hi André,

This file has been dropped intentionnally, it does not make sense to
ship a config.h file in a -dev package, you would have trouble if you
build an application that uses autotools and ship its own config.h.
See http://git.debian.org/?p=debian-science/packages/opencascade.git;a=blob;f=debian/patches/drop-config-h.patch

Denis

Message #128 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Nicolas Chauvat <nicolas.chauvat@logilab.fr>

To: Andre Espaze <dede@logilab.fr>

Cc: Adam C Powell IV <hazelsct@debian.org>, debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 18:54:53 +0100

Hi,

On Thu, Feb 11, 2010 at 05:32:35PM +0100, Andre Espaze wrote:
> How to you plan to collaborate on the package building? I would suggest
> to use the project http://www.python-science.org/project/salome-packaging
> because I can be efficiently organized on such a platform. Would you
> like to add a git or mercurial repository on which we will share the
> package source code?

If it is to be hosted on python-science.org, please make it a hg repo
and it will be easier for us on the admin side since
hg.python-science.org is already operationnal.

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  

Message #133 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Nicolas Chauvat <nicolas.chauvat@logilab.fr>

Cc: Andre Espaze <dede@logilab.fr>, Adam C Powell IV <hazelsct@debian.org>, debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 21:43:31 +0100

Le jeudi 11 février 2010 à 18:54 +0100, Nicolas Chauvat a écrit :
> Hi,
> 
> On Thu, Feb 11, 2010 at 05:32:35PM +0100, Andre Espaze wrote:
> > How to you plan to collaborate on the package building? I would suggest
> > to use the project http://www.python-science.org/project/salome-packaging
> > because I can be efficiently organized on such a platform. Would you
> > like to add a git or mercurial repository on which we will share the
> > package source code?
> 
> If it is to be hosted on python-science.org, please make it a hg repo
> and it will be easier for us on the admin side since
> hg.python-science.org is already operationnal.
Well, Debian (Science) has hosting capabilities and Debian tools prefers
Git or SVN.
I also think it would be easier to stick with Debian hosting since we
already have accounts, procedures and so on...

Sylvestre

Message #138 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 17:43:38 -0500

[Message part 1 (text/plain, inline)]

Hello Andre,

On Thu, 2010-02-11 at 17:32 +0100, Andre Espaze wrote:
> Hi Adam,
> 
> I am André Espaze, the Logilab's employee supposed to help you in the
> Salomé packaging for Debian. First I wanted to thank you for the great
> work that you did on the current package. Then I would like to let you
> know my progress on the testing part.

Great, thanks for following up on this.

> I have succeeded to build most of the Salomé modules with the 
> version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ 
> however I wanted to discuss the following problems:
> 
>     - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4"
>     else vtk is not found and many components do not build.

Indeed, I built -3 before VTK 5.4 was in unstable.  I am using
--with-vtk-version=5.4 which seems to do the same thing.

>     - it lacks the omniorb4-nameserver package in the dependency list 
>     else the KERNEL component does not find the omniNames command.

Okay, the salome binary package needs to depend on this, right?  I don't
think it needs to be in Build-Depends.

>     - as you said, the med 2.3.5 library needs to be built manually 
>     with hdf5-1.8.4 but the main problem is that tests do not pass 
>     in that case.

There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in
the git repository) to build these two using the default MPI
implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2,
which will require further changes to the current HDF5 package...).  The
HDF5 team is a bit slow to adopt patches, but hopefully plans for a
March freeze will get this done, so MED-MPI and Salomé can get in.

>     - it seems to lack the 'config.h' file in the libopencascade-* 
>     packages. Else do you know where that file could be? I fear that 
>     some components (like GEOM) really need it.

Denis replied to this.  I didn't notice any problems building GEOM, are
there run-time issues which could result from missing this file?

>     - the GEOM module crashes when trying to add a geometrical object

I see.  Could this be related to the OCC config.h issue?  I don't see
how...

I'm impressed that it actually runs -- hadn't tried to run it yet!

> You can find all the steps that I did, more details and also more problems 
> at: http://www.python-science.org/ticket/1383

Thanks, I'll look over this.

> How to you plan to collaborate on the package building? I would suggest
> to use the project http://www.python-science.org/project/salome-packaging
> because I can be efficiently organized on such a platform. Would you
> like to add a git or mercurial repository on which we will share the
> package source code?

It is already on the Debian Science git repository at
http://git.debian.org/git/debian-science/packages/salome.git/ .  I'm
trying to get it to work with git/quilt, as right now a couple of the
"clean" targets are a bit too aggressive -- they remove a lot that
shouldn't be removed.

> I am looking forward to work with you,

I am as well!  Thanks for the post.

-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 (application/pgp-signature, inline)]

Message #143 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: alf@logilab.fr, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>

Subject: Re: Salomé packaging

Date: Thu, 11 Feb 2010 20:16:02 -0500

[Message part 1 (text/plain, inline)]

Hello again,

I think this is getting into the technical details, so it is probably
not so interesting to the debian-science list.  I'm afraid I can't
figure out a way to set up an account on ww.python-science.org; if you
can let me know how then I'll go ahead and use that.

In the meantime, I'd like to let you know how to build the versions of
dependencies I'm using.

I don't know why the med-fichier tests are failing with HDF5 1.8.4.  To
build my patched hdf5 package for Debian, you can do the following (in a
Debian unstable chroot):

        apt-get source hdf5
        rm -rf hdf5-1.8.4/debian
        svn co svn://svn.debian.org/svn/pkg-grass/packages/hdf5
        cp -a hdf5/trunk/debian hdf5-1.8.4/
        wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=hdf5-default-mpi.patch;att=1;bug=510057' -O hdf5-default-mpi.patch
        cd hdf5-1.8.4/
        patch -p0 < ../hdf5-default-mpi.patch
        dpkg-buildpackage

Install the resulting .deb packages, particularly libhdf5-mpi-dev which
should depend on libhdf5-openmpi-dev.  Then you can build the latest
med-fichier using:

        git clone http://git.debian.org/git/debian-science/packages/med-fichier.git -b master
        cd med-fichier
        git-buildpackage

It should all build correctly.  At this point, does this version of
med-fichier pass or fail the tests?

You can get and build my latest salome package by the same "git clone"
command but substitute salome for med-fichier.  It still needs a lot of
tweaking before it is ready to upload into Debian unstable.  And first
the patched HDF5 package needs to go in, along with the new med-fichier.

-Adam

On Thu, 2010-02-11 at 17:43 -0500, Adam C Powell IV wrote:
> Hello Andre,
> 
> On Thu, 2010-02-11 at 17:32 +0100, Andre Espaze wrote:
> > Hi Adam,
> > 
> > I am André Espaze, the Logilab's employee supposed to help you in the
> > Salomé packaging for Debian. First I wanted to thank you for the great
> > work that you did on the current package. Then I would like to let you
> > know my progress on the testing part.
> 
> Great, thanks for following up on this.
> 
> > I have succeeded to build most of the Salomé modules with the 
> > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ 
> > however I wanted to discuss the following problems:
> > 
> >     - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4"
> >     else vtk is not found and many components do not build.
> 
> Indeed, I built -3 before VTK 5.4 was in unstable.  I am using
> --with-vtk-version=5.4 which seems to do the same thing.
> 
> >     - it lacks the omniorb4-nameserver package in the dependency list 
> >     else the KERNEL component does not find the omniNames command.
> 
> Okay, the salome binary package needs to depend on this, right?  I don't
> think it needs to be in Build-Depends.
> 
> >     - as you said, the med 2.3.5 library needs to be built manually 
> >     with hdf5-1.8.4 but the main problem is that tests do not pass 
> >     in that case.
> 
> There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in
> the git repository) to build these two using the default MPI
> implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2,
> which will require further changes to the current HDF5 package...).  The
> HDF5 team is a bit slow to adopt patches, but hopefully plans for a
> March freeze will get this done, so MED-MPI and Salomé can get in.
> 
> >     - it seems to lack the 'config.h' file in the libopencascade-* 
> >     packages. Else do you know where that file could be? I fear that 
> >     some components (like GEOM) really need it.
> 
> Denis replied to this.  I didn't notice any problems building GEOM, are
> there run-time issues which could result from missing this file?
> 
> >     - the GEOM module crashes when trying to add a geometrical object
> 
> I see.  Could this be related to the OCC config.h issue?  I don't see
> how...
> 
> I'm impressed that it actually runs -- hadn't tried to run it yet!
> 
> > You can find all the steps that I did, more details and also more problems 
> > at: http://www.python-science.org/ticket/1383
> 
> Thanks, I'll look over this.
> 
> > How to you plan to collaborate on the package building? I would suggest
> > to use the project http://www.python-science.org/project/salome-packaging
> > because I can be efficiently organized on such a platform. Would you
> > like to add a git or mercurial repository on which we will share the
> > package source code?
> 
> It is already on the Debian Science git repository at
> http://git.debian.org/git/debian-science/packages/salome.git/ .  I'm
> trying to get it to work with git/quilt, as right now a couple of the
> "clean" targets are a bit too aggressive -- they remove a lot that
> shouldn't be removed.
> 
> > I am looking forward to work with you,
> 
> I am as well!  Thanks for the post.
> 
> -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 (application/pgp-signature, inline)]

Message #148 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Wed, 17 Feb 2010 11:37:08 +0100

Hi Adam,

Thank you very much for your fast reply. I am sorry for not being as
responsive, I am new to Debian packaging and I am also discovering git.

> > I have succeeded to build most of the Salomé modules with the 
> > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ 
> > however I wanted to discuss the following problems:
> > 
> >     - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4"
> >     else vtk is not found and many components do not build.
> 
> Indeed, I built -3 before VTK 5.4 was in unstable.  I am using
> --with-vtk-version=5.4 which seems to do the same thing.
Yes but I have a slight preference for VTKSUFFIX because it avoids such
warning in the configure step::

    WARNING: unrecognized options: --with-vtk-version

when the module does not deal with VTK. Anyway I would like to discuss 
the configure step in the following ticket:
http://www.python-science.org/ticket/1405 
> 
> >     - it lacks the omniorb4-nameserver package in the dependency list 
> >     else the KERNEL component does not find the omniNames command.
> 
> Okay, the salome binary package needs to depend on this, right?  I don't
> think it needs to be in Build-Depends.
Yes you are right and I made a mistake. The omniorb4-nameserver is
already in debian/control, I did not know the difference between
Build-Depends and Depends.
> 
> >     - as you said, the med 2.3.5 library needs to be built manually 
> >     with hdf5-1.8.4 but the main problem is that tests do not pass 
> >     in that case.
> 
> There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in
> the git repository) to build these two using the default MPI
> implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2,
> which will require further changes to the current HDF5 package...).  The
> HDF5 team is a bit slow to adopt patches, but hopefully plans for a
> March freeze will get this done, so MED-MPI and Salomé can get in.
Med is running fine with the build instructions that you provided me
off list.  Thanks for the informations.
> 
> >     - it seems to lack the 'config.h' file in the libopencascade-* 
> >     packages. Else do you know where that file could be? I fear that 
> >     some components (like GEOM) really need it.
> 
> Denis replied to this.  I didn't notice any problems building GEOM, are
> there run-time issues which could result from missing this file?
> 
> >     - the GEOM module crashes when trying to add a geometrical object
> 
> I see.  Could this be related to the OCC config.h issue?  I don't see
> how...
In fact I do not say that the problem is related but I just wanted to
check the preprocessor definitions in that file and maybe find some
clues. I was afraid that upstream use the '-config config.h' gcc option
when building Salome, thus potentially introducing custom definitions. 

When I compiled Salomé for my first time on Debian Lenny, I got a
runtime crash of GEOM because of the NO_CXX_EXCEPTION definition used 
by OpenCascade. I got it in my build process because I had 
not set my OpenCascade version correctly (see 
KERNEL_SRC_5.1.3/salome_adm/unix/config_files/check_cas.m4 for the 
complete story).
> 
> I'm impressed that it actually runs -- hadn't tried to run it yet!
Yes, it runs, with very few modules (only KERNEL and GUI from now) 
but that is already a nice start.
> 
> > How to you plan to collaborate on the package building? I would suggest
> > to use the project http://www.python-science.org/project/salome-packaging
> > because I can be efficiently organized on such a platform. Would you
> > like to add a git or mercurial repository on which we will share the
> > package source code?
> 
> It is already on the Debian Science git repository at
> http://git.debian.org/git/debian-science/packages/salome.git/ .
Thank you, I built Salomé again from that repo. My tickets are 
there:
http://www.python-science.org/project/salome-packaging/0.1
and we can discuss the specific details off list.

Cheers,

André

Message #153 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: alf@logilab.fr, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Salomé packaging

Date: Wed, 17 Feb 2010 11:59:32 +0100

> I think this is getting into the technical details, so it is probably
> not so interesting to the debian-science list.  I'm afraid I can't
> figure out a way to set up an account on ww.python-science.org; if you
> can let me know how then I'll go ahead and use that.
A message with your first and last names needs to be send to:                                             
    nicolas.chauvat@logilab.fr
However Nicolas just told me that Sylvestre would prefer to use the
Debian tracking system. Do you know where should I move the work from
http://www.python-science.org/project/salome-packaging?
> 
> In the meantime, I'd like to let you know how to build the versions of
> dependencies I'm using.
> 
> I don't know why the med-fichier tests are failing with HDF5 1.8.4.  To
> build my patched hdf5 package for Debian, you can do the following (in a
> Debian unstable chroot):
> 
>         apt-get source hdf5
>         rm -rf hdf5-1.8.4/debian
>         svn co svn://svn.debian.org/svn/pkg-grass/packages/hdf5
>         cp -a hdf5/trunk/debian hdf5-1.8.4/
>         wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=hdf5-default-mpi.patch;att=1;bug=510057' -O hdf5-default-mpi.patch
>         cd hdf5-1.8.4/
>         patch -p0 < ../hdf5-default-mpi.patch
>         dpkg-buildpackage
> 
> Install the resulting .deb packages, particularly libhdf5-mpi-dev which
> should depend on libhdf5-openmpi-dev.  Then you can build the latest
> med-fichier using:
> 
>         git clone http://git.debian.org/git/debian-science/packages/med-fichier.git -b master
>         cd med-fichier
>         git-buildpackage
> 
> It should all build correctly.  At this point, does this version of
> med-fichier pass or fail the tests?
All the tests pass, that is really great. I would like to add such
documentation do the salome.git repo, inside the debian directory. I
have added the following ticket:
http://www.python-science.org/ticket/1403
that will certainly move.
> 
> You can get and build my latest salome package by the same "git clone"
> command but substitute salome for med-fichier.  It still needs a lot of
> tweaking before it is ready to upload into Debian unstable.  And first
> the patched HDF5 package needs to go in, along with the new med-fichier.
I have succeeded to build salome at revision
181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI
running out of the box at the end. I plan to investigate on the GEOM
runtime problem first, is it allright for you?

Then I have some questions regarding the packaging workflow. My main
problem is that running::

    git-buildpackage --git-ignore-new

cleans everything and start from scratch. By the way I had to add 
the '--git-ignore-new' option but did not understand why. I finally use:

    ./debian/rules build

for building everything after small changes. And:

    ./debian/rules install

for then testing the updated version in debian/tmp. The step that I 
did not find is how to apply the series of patch once I pull from 
http://git.debian.org/git/debian-science/packages/salome.git 
Reading:
http://www.debian.org/doc/maint-guide/ch-build.en.html#s-completebuild
I did not find the tool. I first thought about the dpatch candidate but
the command is not installed on my system so I wonder how git-buildpackage
works.


André    

Message #158 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: debian-science@lists.debian.org, pyves@logilab.fr, alf@logilab.fr, 457075@bugs.debian.org

Subject: Re: Salomé packaging

Date: Wed, 17 Feb 2010 06:16:38 -0800

[Message part 1 (text/plain, inline)]

Hello Andre,

No problem regarding the reply time.  It takes a while to come up to
speed on git, quilt, and the complicated Debian packaging system.

I've made a lot of progress in getting salome to build and clean itself
properly, so some things should be much easier.  The only thing not
building properly at this point is VISU, there's a C++ problem mentioned
earlier which I don't know how to resolve.

On Wed, 2010-02-17 at 11:37 +0100, Andre Espaze wrote:
> Hi Adam,
> 
> Thank you very much for your fast reply. I am sorry for not being as
> responsive, I am new to Debian packaging and I am also discovering git.
> 
> > > I have succeeded to build most of the Salomé modules with the 
> > > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ 
> > > however I wanted to discuss the following problems:
> > > 
> > >     - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4"
> > >     else vtk is not found and many components do not build.
> > 
> > Indeed, I built -3 before VTK 5.4 was in unstable.  I am using
> > --with-vtk-version=5.4 which seems to do the same thing.
> Yes but I have a slight preference for VTKSUFFIX because it avoids such
> warning in the configure step::
> 
>     WARNING: unrecognized options: --with-vtk-version
> 
> when the module does not deal with VTK.

Good point.  I have just made that change, thanks.

> Anyway I would like to discuss 
> the configure step in the following ticket:
> http://www.python-science.org/ticket/1405 

You make a good point about different features needed for different
modules.  But I think the loop is helpful because it is easy to change
or fix variables which apply to all of the modules, and cuts down on the
size of the rules file.  It needs to do the documentation separately for
each module because not all modules have documentation; I'd like to keep
from having to do that in the configure-stamp target.

That said, if you can produce a patch which does this without making
things too long (for example by having a COMMON_CONFIGURE_OPTIONS
makefile variable for options needed by all modules), I will likely
adopt it.

[Skipping resolved issues...]

> > I'm impressed that it actually runs -- hadn't tried to run it yet!
> Yes, it runs, with very few modules (only KERNEL and GUI from now) 
> but that is already a nice start.

Great, let's see how we can make the other modules work...

> > > How to you plan to collaborate on the package building? I would suggest
> > > to use the project http://www.python-science.org/project/salome-packaging
> > > because I can be efficiently organized on such a platform. Would you
> > > like to add a git or mercurial repository on which we will share the
> > > package source code?
> > 
> > It is already on the Debian Science git repository at
> > http://git.debian.org/git/debian-science/packages/salome.git/ .
> Thank you, I built Salomé again from that repo. My tickets are 
> there:
> http://www.python-science.org/project/salome-packaging/0.1
> and we can discuss the specific details off list.

Sounds good.  Thanks for your help!

-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 (application/pgp-signature, inline)]

Message #163 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: alf@logilab.fr, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Salomé packaging

Date: Wed, 17 Feb 2010 06:48:17 -0800

[Message part 1 (text/plain, inline)]

On Wed, 2010-02-17 at 11:59 +0100, Andre Espaze wrote:
> > I think this is getting into the technical details, so it is probably
> > not so interesting to the debian-science list.  I'm afraid I can't
> > figure out a way to set up an account on ww.python-science.org; if you
> > can let me know how then I'll go ahead and use that.
> A message with your first and last names needs to be send to:                                             
>     nicolas.chauvat@logilab.fr
> However Nicolas just told me that Sylvestre would prefer to use the
> Debian tracking system. Do you know where should I move the work from
> http://www.python-science.org/project/salome-packaging?

Until salome is uploaded into Debian, it will not be possible to use the
bug tracking system for individual issues.  At this point, the only
"bug" in Debian is that salome isn't there -- #457075. :-)

> > In the meantime, I'd like to let you know how to build the versions of
> > dependencies I'm using.
> > 
> > I don't know why the med-fichier tests are failing with HDF5 1.8.4.  To
> > build my patched hdf5 package for Debian, you can do the following (in a
> > Debian unstable chroot):
> > 
> >         apt-get source hdf5
> >         rm -rf hdf5-1.8.4/debian
> >         svn co svn://svn.debian.org/svn/pkg-grass/packages/hdf5
> >         cp -a hdf5/trunk/debian hdf5-1.8.4/
> >         wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=hdf5-default-mpi.patch;att=1;bug=510057' -O hdf5-default-mpi.patch
> >         cd hdf5-1.8.4/
> >         patch -p0 < ../hdf5-default-mpi.patch
> >         dpkg-buildpackage
> > 
> > Install the resulting .deb packages, particularly libhdf5-mpi-dev which
> > should depend on libhdf5-openmpi-dev.  Then you can build the latest
> > med-fichier using:
> > 
> >         git clone http://git.debian.org/git/debian-science/packages/med-fichier.git -b master
> >         cd med-fichier
> >         git-buildpackage
> > 
> > It should all build correctly.  At this point, does this version of
> > med-fichier pass or fail the tests?
> All the tests pass, that is really great.

Excellent!  I'm glad to hear it.  I sent my patches to med-fichier
upstream, and they let me know they have already included my changes
into their 3.0.0 version under development.

> I would like to add such
> documentation do the salome.git repo, inside the debian directory. I
> have added the following ticket:
> http://www.python-science.org/ticket/1403
> that will certainly move.

Good point.  I haven't used the Debian Science Wiki, perhaps that's a
good place to put such documentation at this point.

> > You can get and build my latest salome package by the same "git clone"
> > command but substitute salome for med-fichier.  It still needs a lot of
> > tweaking before it is ready to upload into Debian unstable.  And first
> > the patched HDF5 package needs to go in, along with the new med-fichier.
> I have succeeded to build salome at revision
> 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI
> running out of the box at the end. I plan to investigate on the GEOM
> runtime problem first, is it allright for you?

Yes.  But please try re-cloning it, I have made a lot of progress, and
some things might work now that didn't before.  I think your tickets
1398, 1400 and 1402 are fixed now.

My suspicion is that the geom issue might due to incorrect directory
usage for the OpenCascade data files.  I've just added tests for their
location in check_cas.m4, and will change
KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
CAS_DATADIR variables accordingly (will need to move it to
envProducts.sh.in and have configure generate the .sh file).

I believe all of this should work using both the standard OpenCascade
build method and the Debian package, so the resulting patch should be
acceptable to upstream.  Please let me know if you see anything which
does not satisfy this goal.

> Then I have some questions regarding the packaging workflow. My main
> problem is that running::
> 
>     git-buildpackage --git-ignore-new
> 
> cleans everything and start from scratch. By the way I had to add 
> the '--git-ignore-new' option but did not understand why. I finally use:
> 
>     ./debian/rules build
> 
> for building everything after small changes. And:
> 
>     ./debian/rules install
> 
> for then testing the updated version in debian/tmp.

git-buildpackage is very strict about having a pristine tree at the
start of the build.  I have only just finished getting "fakeroot
debian/rules clean" to restore the tree to the original state so it will
work properly.

The workflow should go something like this:
     1. git-buildpackage (which applies the patches and builds)
     2. If it doesn't finish building, fix build issues, using quilt to
        apply changes to the right patches (see below).  Keep using make
        and make install until it works, then finish package building
        using fakeroot debian/rules binary
     3. Install and test the package, and fix details, again using quilt
        to apply changes to the right patches.
     4. fakeroot debian/rules clean
     5. quilt pop -a
     6. rm -rf .pc
     7. Commit changes to the local git repository, which should only be
        in the debian directory.  (This can also be done after 2 or 3 if
        it's easier to separate out the changes into multiple commits at
        that step.)
     8. Go back to step 1 and try again.  If git-buildpackage doesn't
        work, there's something wrong with the clean process.

> The step that I 
> did not find is how to apply the series of patch once I pull from 
> http://git.debian.org/git/debian-science/packages/salome.git 
> Reading:
> http://www.debian.org/doc/maint-guide/ch-build.en.html#s-completebuild
> I did not find the tool. I first thought about the dpatch candidate but
> the command is not installed on my system so I wonder how git-buildpackage
> works.

This package uses the quilt system to manage its patches, which is
becoming the most popular way to do so.  Its documentation is in the
file /usr/share/doc/quilt/quilt.html with a nice summary in the
file /usr/share/doc/quilt/README.source .

I like it because it is very easy to put specific changes in the right
patches using quilt, and to manage interactions between patches.

Regards,
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 (application/pgp-signature, inline)]

Message #168 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: alf@logilab.fr, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Salomé packaging

Date: Tue, 23 Feb 2010 10:05:03 +0100

Hi Adam,

> 
> Until salome is uploaded into Debian, it will not be possible to use the
> bug tracking system for individual issues.  At this point, the only
> "bug" in Debian is that salome isn't there -- #457075. :-)
Ok, so from now I organise tickets on
http://www.python-science.org/project/salome-packaging
and I keep you in touch with my progress.
> 
...
> 
> > I would like to add such
> > documentation do the salome.git repo, inside the debian directory. I
> > have added the following ticket:
> > http://www.python-science.org/ticket/1403
> > that will certainly move.
> 
> Good point.  I haven't used the Debian Science Wiki, perhaps that's a
> good place to put such documentation at this point.
Perfect, I will add a page on the wiki as soon as my documentation is
ready. I will restart from a clean sid install today. I plan to document
every module so it will help me to supply the 'debian/rules' patch
of ticket http://www.python-science.org/ticket/1405.
> 
> > > You can get and build my latest salome package by the same "git clone"
> > > command but substitute salome for med-fichier.  It still needs a lot of
> > > tweaking before it is ready to upload into Debian unstable.  And first
> > > the patched HDF5 package needs to go in, along with the new med-fichier.
> > I have succeeded to build salome at revision
> > 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI
> > running out of the box at the end. I plan to investigate on the GEOM
> > runtime problem first, is it allright for you?
> 
> Yes.  But please try re-cloning it, I have made a lot of progress, and
> some things might work now that didn't before.  I think your tickets
> 1398, 1400 and 1402 are fixed now.
Congratulations, your Release 5.1.3-4 worked fine and closed those three
tickets concerning MED build and install as well as GEOM install. So 
now the MED and GEOM modules are present when starting Salome.
> 
> My suspicion is that the geom issue might due to incorrect directory
> usage for the OpenCascade data files.  I've just added tests for their
> location in check_cas.m4, and will change
> KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
> CAS_DATADIR variables accordingly (will need to move it to
> envProducts.sh.in and have configure generate the .sh file).
Unfortunately, I still get the same crash for GEOM with the SIGFPE 
Arithmetic exception, forcing me to kill Salome. I plan to investigate
this problem as soon as the documentation is ready.

Thank you very much for your explanations on git-buildpackage and 
the Debian build process, they clarified many points. My main problem
in Salome packaging is that the building process is resource intensive
and thus takes lot of time. I sometimes also run out of disk space but
that is really part of the fun.

Best regards,

André

Message #173 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 23 Feb 2010 15:26:45 -0500

[Message part 1 (text/plain, inline)]

Hi Andre,

On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > Until salome is uploaded into Debian, it will not be possible to use the
> > bug tracking system for individual issues.  At this point, the only
> > "bug" in Debian is that salome isn't there -- #457075. :-)
> Ok, so from now I organise tickets on
> http://www.python-science.org/project/salome-packaging
> and I keep you in touch with my progress.

Great, thanks.  I'm making pretty quick progress (well, as much as can
be done in one or two builds per day), I think the first upload should
come fairly soon, within a week or so.
 
> > > I would like to add such
> > > documentation do the salome.git repo, inside the debian directory. I
> > > have added the following ticket:
> > > http://www.python-science.org/ticket/1403
> > > that will certainly move.
> > 
> > Good point.  I haven't used the Debian Science Wiki, perhaps that's a
> > good place to put such documentation at this point.
> Perfect, I will add a page on the wiki as soon as my documentation is
> ready. I will restart from a clean sid install today. I plan to document
> every module so it will help me to supply the 'debian/rules' patch
> of ticket http://www.python-science.org/ticket/1405.

Thanks.  I just changed from --with-netgen to NETGENHOME so there should
be no more "unrecognized option" warnings.  But NETGENPLUGIN doesn't
work because of a missing header file.  I'm going to work on the netgen
package and see if I can get the Salomé interface changes in there
without disrupting the existing interface and applications which link to
it.

Before you start on the patch, let's discuss its utility: how useful
will it be to have separate configure commands and a *very* long
configure-stamp target in debian/rules, vs. the current loop?  I think
my preference is the loop because it's short and easy to maintain.

> > > > You can get and build my latest salome package by the same "git clone"
> > > > command but substitute salome for med-fichier.  It still needs a lot of
> > > > tweaking before it is ready to upload into Debian unstable.  And first
> > > > the patched HDF5 package needs to go in, along with the new med-fichier.
> > > I have succeeded to build salome at revision
> > > 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI
> > > running out of the box at the end. I plan to investigate on the GEOM
> > > runtime problem first, is it allright for you?
> > 
> > Yes.  But please try re-cloning it, I have made a lot of progress, and
> > some things might work now that didn't before.  I think your tickets
> > 1398, 1400 and 1402 are fixed now.
> Congratulations, your Release 5.1.3-4 worked fine and closed those three
> tickets concerning MED build and install as well as GEOM install. So 
> now the MED and GEOM modules are present when starting Salome.

Terrific!  Onward to the other issues...

> > My suspicion is that the geom issue might due to incorrect directory
> > usage for the OpenCascade data files.  I've just added tests for their
> > location in check_cas.m4, and will change
> > KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
> > CAS_DATADIR variables accordingly (will need to move it to
> > envProducts.sh.in and have configure generate the .sh file).
> Unfortunately, I still get the same crash for GEOM with the SIGFPE 
> Arithmetic exception, forcing me to kill Salome. I plan to investigate
> this problem as soon as the documentation is ready.

Thanks.  The runSalome script should be working now, if not let me know
what kind of errors it gives.

> Thank you very much for your explanations on git-buildpackage and 
> the Debian build process, they clarified many points. My main problem
> in Salome packaging is that the building process is resource intensive
> and thus takes lot of time. I sometimes also run out of disk space but
> that is really part of the fun.

Indeed, the frustration and the fun. :-)

-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 (application/pgp-signature, inline)]

Message #178 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 25 Feb 2010 17:19:32 +0100

Hi Adam,
> 
> On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > > Until salome is uploaded into Debian, it will not be possible to use the
> > > bug tracking system for individual issues.  At this point, the only
> > > "bug" in Debian is that salome isn't there -- #457075. :-)
> > Ok, so from now I organise tickets on
> > http://www.python-science.org/project/salome-packaging
> > and I keep you in touch with my progress.
> 
> Great, thanks.  I'm making pretty quick progress (well, as much as can
> be done in one or two builds per day), I think the first upload should
> come fairly soon, within a week or so.
Ok, today I have worked on your revision:

    c56f196854092f0dc0d222de71de1a4532f214ec
    Release 5.1.3-4 "Look ma, it builds!"

of the master branch or do you have another branch that I could follow?
>  
> > > > I would like to add such
> > > > documentation do the salome.git repo, inside the debian directory. I
> > > > have added the following ticket:
> > > > http://www.python-science.org/ticket/1403
> > > > that will certainly move.
> > > 
> > > Good point.  I haven't used the Debian Science Wiki, perhaps that's a
> > > good place to put such documentation at this point.
> > Perfect, I will add a page on the wiki as soon as my documentation is
> > ready. I will restart from a clean sid install today. I plan to document
> > every module so it will help me to supply the 'debian/rules' patch
> > of ticket http://www.python-science.org/ticket/1405.
> 
> Thanks.  I just changed from --with-netgen to NETGENHOME so there should
> be no more "unrecognized option" warnings.  But NETGENPLUGIN doesn't
> work because of a missing header file.  I'm going to work on the netgen
> package and see if I can get the Salomé interface changes in there
> without disrupting the existing interface and applications which link to
> it.
> 
> Before you start on the patch, let's discuss its utility: how useful
> will it be to have separate configure commands and a *very* long
> configure-stamp target in debian/rules, vs. the current loop?  I think
> my preference is the loop because it's short and easy to maintain.
I think you are right, I need a documentation for every module because 
I should build Salome for other distribution as well. However that is
not relevant to mix such work with debian/rules. The start of my 
documentation can be found here:
https://hg.python-science.org/salome-packaging/

> 
> 
> > > My suspicion is that the geom issue might due to incorrect directory
> > > usage for the OpenCascade data files.  I've just added tests for their
> > > location in check_cas.m4, and will change
> > > KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
> > > CAS_DATADIR variables accordingly (will need to move it to
> > > envProducts.sh.in and have configure generate the .sh file).
> > Unfortunately, I still get the same crash for GEOM with the SIGFPE 
> > Arithmetic exception, forcing me to kill Salome. I plan to investigate
> > this problem as soon as the documentation is ready.
> 
> Thanks.  The runSalome script should be working now, if not let me know
> what kind of errors it gives.
It was still crashing but I finally found the problem by exporting:

    DISABLE_FPE=1

before running Salomé. You may want to look at:
https://hg.python-science.org/salome-packaging/rev/8ab11e56314a
for more details.
By the way, I did not need the variables CASROOT, CSF_GraphicShr, 
CSF_UnitsLexicon and CSF_UnitsDefinition for running the GEOM module.
Moreover in debian/runSalome.in, the variables CSF_UnitsLexicon and 
CSF_UnitsDefinition seems to point on a wrong path. The correct one 
should be:
share/opencascade/6.3.0/src
instead of:
share/opencascade
but you may use another opencascade package version.

I keep you in touch with the build process, I again ran out of disk space 
today. But thank you very much for all your efforts, I feel that it is 
going forward.

Kind regards,

André

Message #183 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 25 Feb 2010 13:10:58 -0500

[Message part 1 (text/plain, inline)]

On Thu, 2010-02-25 at 17:19 +0100, Andre Espaze wrote:
> Hi Adam,
> > 
> > On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > > > Until salome is uploaded into Debian, it will not be possible to use the
> > > > bug tracking system for individual issues.  At this point, the only
> > > > "bug" in Debian is that salome isn't there -- #457075. :-)
> > > Ok, so from now I organise tickets on
> > > http://www.python-science.org/project/salome-packaging
> > > and I keep you in touch with my progress.
> > 
> > Great, thanks.  I'm making pretty quick progress (well, as much as can
> > be done in one or two builds per day), I think the first upload should
> > come fairly soon, within a week or so.
> Ok, today I have worked on your revision:
> 
>     c56f196854092f0dc0d222de71de1a4532f214ec
>     Release 5.1.3-4 "Look ma, it builds!"
> 
> of the master branch or do you have another branch that I could follow?

That's the current public branch now.  I'm working now on my own branch,
which doesn't build because of a problem with $(wildcard...) in the
rules file which I mentioned on debian-science.  I'm testing a possible
solution based on Aaron Ucko's reply, and will push everything to alioth
if/when it works.

Also, the NETGENPLUGIN module will not work until the new netgen package
is uploaded.  That in turn depends on togl, which I just learned is
packaged but waiting for upload.  I'm going to see if I can upload togl,
then the new netgen, in order to get all of this working (since I need
this plugin for my work).

> > > > > I would like to add such
> > > > > documentation do the salome.git repo, inside the debian directory. I
> > > > > have added the following ticket:
> > > > > http://www.python-science.org/ticket/1403
> > > > > that will certainly move.
> > > > 
> > > > Good point.  I haven't used the Debian Science Wiki, perhaps that's a
> > > > good place to put such documentation at this point.
> > > Perfect, I will add a page on the wiki as soon as my documentation is
> > > ready. I will restart from a clean sid install today. I plan to document
> > > every module so it will help me to supply the 'debian/rules' patch
> > > of ticket http://www.python-science.org/ticket/1405.
> > 
> > Thanks.  I just changed from --with-netgen to NETGENHOME so there should
> > be no more "unrecognized option" warnings.  But NETGENPLUGIN doesn't
> > work because of a missing header file.  I'm going to work on the netgen
> > package and see if I can get the Salomé interface changes in there
> > without disrupting the existing interface and applications which link to
> > it.
> > 
> > Before you start on the patch, let's discuss its utility: how useful
> > will it be to have separate configure commands and a *very* long
> > configure-stamp target in debian/rules, vs. the current loop?  I think
> > my preference is the loop because it's short and easy to maintain.
> I think you are right, I need a documentation for every module because 
> I should build Salome for other distribution as well. However that is
> not relevant to mix such work with debian/rules. The start of my 
> documentation can be found here:
> https://hg.python-science.org/salome-packaging/

Great, thanks.

> > > > My suspicion is that the geom issue might due to incorrect directory
> > > > usage for the OpenCascade data files.  I've just added tests for their
> > > > location in check_cas.m4, and will change
> > > > KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
> > > > CAS_DATADIR variables accordingly (will need to move it to
> > > > envProducts.sh.in and have configure generate the .sh file).
> > > Unfortunately, I still get the same crash for GEOM with the SIGFPE 
> > > Arithmetic exception, forcing me to kill Salome. I plan to investigate
> > > this problem as soon as the documentation is ready.
> > 
> > Thanks.  The runSalome script should be working now, if not let me know
> > what kind of errors it gives.
> It was still crashing but I finally found the problem by exporting:
> 
>     DISABLE_FPE=1
> 
> before running Salomé. You may want to look at:
> https://hg.python-science.org/salome-packaging/rev/8ab11e56314a
> for more details.

Ah, this is good information!  I'm including this in runSalome.in .

> By the way, I did not need the variables CASROOT, CSF_GraphicShr, 
> CSF_UnitsLexicon and CSF_UnitsDefinition for running the GEOM module.
> Moreover in debian/runSalome.in, the variables CSF_UnitsLexicon and 
> CSF_UnitsDefinition seems to point on a wrong path. The correct one 
> should be:
> share/opencascade/6.3.0/src
> instead of:
> share/opencascade
> but you may use another opencascade package version.

You're right, it's based on an older version of the opencascade package.
I'll fix it.

> I keep you in touch with the build process, I again ran out of disk space 
> today. But thank you very much for all your efforts, I feel that it is 
> going forward.

You're welcome, I'll let you know when I push everything to alioth
(a.k.a. git.debian.org).

-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 (application/pgp-signature, inline)]

Message #188 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Fri, 26 Feb 2010 16:21:11 -0500

[Message part 1 (text/plain, inline)]

Hi Andre,

On Thu, 2010-02-25 at 13:11 -0500, Adam C Powell IV wrote:
> On Thu, 2010-02-25 at 17:19 +0100, Andre Espaze wrote:
> > Hi Adam,
> > > 
> > > On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > > > > Until salome is uploaded into Debian, it will not be possible to use the
> > > > > bug tracking system for individual issues.  At this point, the only
> > > > > "bug" in Debian is that salome isn't there -- #457075. :-)
> > > > Ok, so from now I organise tickets on
> > > > http://www.python-science.org/project/salome-packaging
> > > > and I keep you in touch with my progress.
> > > 
> > > Great, thanks.  I'm making pretty quick progress (well, as much as can
> > > be done in one or two builds per day), I think the first upload should
> > > come fairly soon, within a week or so.
> > Ok, today I have worked on your revision:
> > 
> >     c56f196854092f0dc0d222de71de1a4532f214ec
> >     Release 5.1.3-4 "Look ma, it builds!"
> > 
> > of the master branch or do you have another branch that I could follow?
> 
> That's the current public branch now.  I'm working now on my own branch,
> which doesn't build because of a problem with $(wildcard...) in the
> rules file which I mentioned on debian-science.  I'm testing a possible
> solution based on Aaron Ucko's reply, and will push everything to alioth
> if/when it works.

Everything works now, so I just pushed a bunch of changes to alioth,
including the LIGHT and PYLIGHT CORBA-free GUI modules.

I'm adding MULTIPR now, which should be the last module (XDATA and YACS
gave me some trouble, the others have non-free dependencies).  Then I'm
going to do a .desktop file so it can run from the Applications or KDE
menu, and when that's done it should be set to upload!

Oh, except for the HDF5 and MED issue.  Well, when bug 510057 closes,
then it will be ready to upload.

-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 (application/pgp-signature, inline)]

Message #193 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 4 Mar 2010 17:36:00 +0100

Hi Adam,

> > > > 
> > > > On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > > > > > Until salome is uploaded into Debian, it will not be possible to use the
> > > > > > bug tracking system for individual issues.  At this point, the only
> > > > > > "bug" in Debian is that salome isn't there -- #457075. :-)
> > > > > Ok, so from now I organise tickets on
> > > > > http://www.python-science.org/project/salome-packaging
> > > > > and I keep you in touch with my progress.
> > > > 
> > > > Great, thanks.  I'm making pretty quick progress (well, as much as can
> > > > be done in one or two builds per day), I think the first upload should
> > > > come fairly soon, within a week or so.
> > > Ok, today I have worked on your revision:
> > > 
> > >     c56f196854092f0dc0d222de71de1a4532f214ec
> > >     Release 5.1.3-4 "Look ma, it builds!"
> > > 
> > > of the master branch or do you have another branch that I could follow?
> > 
> > That's the current public branch now.  I'm working now on my own branch,
> > which doesn't build because of a problem with $(wildcard...) in the
> > rules file which I mentioned on debian-science.  I'm testing a possible
> > solution based on Aaron Ucko's reply, and will push everything to alioth
> > if/when it works.
> 
> Everything works now, so I just pushed a bunch of changes to alioth,
> including the LIGHT and PYLIGHT CORBA-free GUI modules.
Thank you very much for the push, I have succeeded a complete build
at revision:

    5f1c9676ce493cb5f31f01c8a12c4f697308e2fe
    Updated time stamp.
    Fri Feb 26

However I had to set up a virtual machine with 20Go of disk and 1024Mo 
of RAM on a server. I had finally to move away from the chrooted
environment on my local machine. For the installation part, it seems
that there is a cyclic dependency between salome and salome-common.
Obviously salome-common should not depend on salome.

> 
> I'm adding MULTIPR now, which should be the last module (XDATA and YACS
> gave me some trouble, the others have non-free dependencies).  Then I'm
> going to do a .desktop file so it can run from the Applications or KDE
> menu, and when that's done it should be set to upload!
> 
> Oh, except for the HDF5 and MED issue.  Well, when bug 510057 closes,
> then it will be ready to upload.
For that point and also the packaging steps, I have started a draft
of documentation on the mercurial repo:
    http://hg.python-science.org/salome-packaging/
in the file:
    debian-packaging.rst
It is supposed to end up on the debian wiki. In case you have time
to read it, would you have comments? I really feel beginner for the 
Debian packaging process.
Else I have also uploaded the documentation for the modules MED, SMESH
and VISU.

However, I got a runtime error with my version, the study server is 
not found even if I only work with the KERNEL and GUI modules. I am
going to run a new build at revision:

    1a1c81a479c5c021ff685046623831ffc3621ccf
    Wed Mar 3 17:36:30

I saw that you already fixed the 'killSalome' command problem pointing
on python2.4.

Kind regards,

André

Message #198 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 04 Mar 2010 12:11:54 -0500

[Message part 1 (text/plain, inline)]

Hello Andre,

On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote:
> > > > > On Tue, 2010-02-23 at 10:05 +0100, Andre Espaze wrote:
> > > > > > > Until salome is uploaded into Debian, it will not be possible to use the
> > > > > > > bug tracking system for individual issues.  At this point, the only
> > > > > > > "bug" in Debian is that salome isn't there -- #457075. :-)
> > > > > > Ok, so from now I organise tickets on
> > > > > > http://www.python-science.org/project/salome-packaging
> > > > > > and I keep you in touch with my progress.
> > > > > 
> > > > > Great, thanks.  I'm making pretty quick progress (well, as much as can
> > > > > be done in one or two builds per day), I think the first upload should
> > > > > come fairly soon, within a week or so.
> > > > Ok, today I have worked on your revision:
> > > > 
> > > >     c56f196854092f0dc0d222de71de1a4532f214ec
> > > >     Release 5.1.3-4 "Look ma, it builds!"
> > > > 
> > > > of the master branch or do you have another branch that I could follow?
> > > 
> > > That's the current public branch now.  I'm working now on my own branch,
> > > which doesn't build because of a problem with $(wildcard...) in the
> > > rules file which I mentioned on debian-science.  I'm testing a possible
> > > solution based on Aaron Ucko's reply, and will push everything to alioth
> > > if/when it works.
> > 
> > Everything works now, so I just pushed a bunch of changes to alioth,
> > including the LIGHT and PYLIGHT CORBA-free GUI modules.
> Thank you very much for the push, I have succeeded a complete build
> at revision:
> 
>     5f1c9676ce493cb5f31f01c8a12c4f697308e2fe
>     Updated time stamp.
>     Fri Feb 26
> 
> However I had to set up a virtual machine with 20Go of disk and 1024Mo 
> of RAM on a server. I had finally to move away from the chrooted
> environment on my local machine.

Yes, it's kind of annoying how much disk space it takes!

> For the installation part, it seems
> that there is a cyclic dependency between salome and salome-common.
> Obviously salome-common should not depend on salome.

You're right, this would be a serious bug.  I just changed and pushed
the fix.

> > I'm adding MULTIPR now, which should be the last module (XDATA and YACS
> > gave me some trouble, the others have non-free dependencies).  Then I'm
> > going to do a .desktop file so it can run from the Applications or KDE
> > menu, and when that's done it should be set to upload!
> > 
> > Oh, except for the HDF5 and MED issue.  Well, when bug 510057 closes,
> > then it will be ready to upload.
> For that point and also the packaging steps, I have started a draft
> of documentation on the mercurial repo:
>     http://hg.python-science.org/salome-packaging/
> in the file:
>     debian-packaging.rst
> It is supposed to end up on the debian wiki. In case you have time
> to read it, would you have comments? I really feel beginner for the 
> Debian packaging process.
> Else I have also uploaded the documentation for the modules MED, SMESH
> and VISU.

Thank you, I will look at that.

> However, I got a runtime error with my version, the study server is 
> not found even if I only work with the KERNEL and GUI modules. I am
> going to run a new build at revision:
> 
>     1a1c81a479c5c021ff685046623831ffc3621ccf
>     Wed Mar 3 17:36:30

I am having the same problem, and don't know how to fix it.  I wonder
what has changed since you were last able to run it.  I guess we should
do a git bisect, but given the build time, that will take quite a while!

> I saw that you already fixed the 'killSalome' command problem pointing
> on python2.4.

Yes, and a few others.  The YACS module should now build, it seemed like
an important one to get in there.  Now only XDATA remains (the others
depend on non-free packages, as described in debian/rules).

Also, VISU still doesn't finish building, I wish I had the C++ skills to
deal with that. :-(

I think we're almost there...

-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 (application/pgp-signature, inline)]

Message #208 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Mon, 08 Mar 2010 10:07:37 -0500

[Message part 1 (text/plain, inline)]

Hi again,

On Thu, 2010-03-04 at 12:12 -0500, Adam C Powell IV wrote:
> On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote:
> > However, I got a runtime error with my version, the study server is 
> > not found even if I only work with the KERNEL and GUI modules. I am
> > going to run a new build at revision:
> > 
> >     1a1c81a479c5c021ff685046623831ffc3621ccf
> >     Wed Mar 3 17:36:30
> 
> I am having the same problem, and don't know how to fix it.  I wonder
> what has changed since you were last able to run it.  I guess we should
> do a git bisect, but given the build time, that will take quite a while!

Which was the last version that ran without this error?  I'd like to
figure out the differences and try to get this working.  I've tried a
couple of changes to no avail, and this is the last thing keeping me
from a -5 "release"...

Thanks,
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 (application/pgp-signature, inline)]

Message #213 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 9 Mar 2010 17:23:07 +0100

Hi Adam
> 
> On Thu, 2010-03-04 at 12:12 -0500, Adam C Powell IV wrote:
> > On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote:
> > > However, I got a runtime error with my version, the study server is 
> > > not found even if I only work with the KERNEL and GUI modules. I am
> > > going to run a new build at revision:
> > > 
> > >     1a1c81a479c5c021ff685046623831ffc3621ccf
> > >     Wed Mar 3 17:36:30
> > 
> > I am having the same problem, and don't know how to fix it.  I wonder
> > what has changed since you were last able to run it.  I guess we should
> > do a git bisect, but given the build time, that will take quite a while!
> 
> Which was the last version that ran without this error?  I'd like to
> figure out the differences and try to get this working.  I've tried a
> couple of changes to no avail, and this is the last thing keeping me
> from a -5 "release"...
The last working version was actually the -4:

    c56f196854092f0dc0d222de71de1a4532f214ec
    Release 5.1.3-4 "Look ma, it builds!"

Obviously, the KERNEL module works correctly but the GUI one does
not want to start. I am compiling the GUI module separately for comparing
the build processes.

Kind regards,

André

Message #218 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 09 Mar 2010 16:20:08 -0500

[Message part 1 (text/plain, inline)]

Hi André,

On Tue, 2010-03-09 at 17:23 +0100, Andre Espaze wrote:
> > On Thu, 2010-03-04 at 12:12 -0500, Adam C Powell IV wrote:
> > > On Thu, 2010-03-04 at 17:36 +0100, Andre Espaze wrote:
> > > > However, I got a runtime error with my version, the study server is 
> > > > not found even if I only work with the KERNEL and GUI modules. I am
> > > > going to run a new build at revision:
> > > > 
> > > >     1a1c81a479c5c021ff685046623831ffc3621ccf
> > > >     Wed Mar 3 17:36:30
> > > 
> > > I am having the same problem, and don't know how to fix it.  I wonder
> > > what has changed since you were last able to run it.  I guess we should
> > > do a git bisect, but given the build time, that will take quite a while!
> > 
> > Which was the last version that ran without this error?  I'd like to
> > figure out the differences and try to get this working.  I've tried a
> > couple of changes to no avail, and this is the last thing keeping me
> > from a -5 "release"...
> The last working version was actually the -4:
> 
>     c56f196854092f0dc0d222de71de1a4532f214ec
>     Release 5.1.3-4 "Look ma, it builds!"

That's what I thought.  I tried that one today (backported to Ubuntu
Karmic), and it didn't work.  I guess I'll have to bring X up in the
chroot to check it there, then start the bisect process.

Thanks,
-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 (application/pgp-signature, inline)]

Message #223 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 11 Mar 2010 17:23:57 +0100

Hi Adam,

> > The last working version was actually the -4:
> > 
> >     c56f196854092f0dc0d222de71de1a4532f214ec
> >     Release 5.1.3-4 "Look ma, it builds!"
> 
> That's what I thought.  I tried that one today (backported to Ubuntu
> Karmic), and it didn't work.  I guess I'll have to bring X up in the
> chroot to check it there, then start the bisect process.
It still does not work but I wanted to let you know where I am. 
I have worked at revision:
    862cebe157a4ce50984d6fc15758da7d3ca96e2a
    Thu Mar 4 20:29:30 2010
By applying the following patches on the KERNEL module:
    kernel-safe-include.patch
    kernel-mpi-includes.patch
    kernel-mpi-libs.patch
    kernel-hdf5-needs-mpi.patch
    kernel-remove-mpi-undefs.patch
and:
    gui-mpich-mpi.patch
on the GUI one, it works when installing it by hand in a local
directory (I have used ~/sroot/). However it does not work when
following the debian/rules install path. I thought that lines 206 
and 207 of debian/rules where the problem:

    mv debian/tmp/usr/bin/*.py \
    $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/
    chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*

but it is not enough to make it works. For all the processing at
line 200, I do not understand where the files are. By running for 
example:

    find /usr/ -name config_appli.xml

I do not find anything however I can find this file in my local ~/sroot
directory. However I may have messed the install process, I am running
a new build now.

Then I guess that we need to build Salome with hdf5 including mpi
because we can not force the user to use libhdf5-serial when he will
want to install Salome. Dealing with patches make the debuging harder
for getting a first running version but I think that you have solved the
problem. I have tried with and without hdf5 and I get the same behavior
for the KERNEL part.

I keep you in touch once my new version is running, I am getting 
more confortable with the Debian packaging tools.

With kind regards,

André

Message #228 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 16 Mar 2010 06:49:06 -0400

[Message part 1 (text/plain, inline)]

Hi André,

Sorry about the delay, I've been trying to get X working in a chroot but
a known bug is making the keyboard and mouse not work...  Copying my sid
chroot into its own partition now to try to boot and test there.

On Thu, 2010-03-11 at 17:23 +0100, Andre Espaze wrote:
> > > The last working version was actually the -4:
> > > 
> > >     c56f196854092f0dc0d222de71de1a4532f214ec
> > >     Release 5.1.3-4 "Look ma, it builds!"
> > 
> > That's what I thought.  I tried that one today (backported to Ubuntu
> > Karmic), and it didn't work.  I guess I'll have to bring X up in the
> > chroot to check it there, then start the bisect process.
> It still does not work but I wanted to let you know where I am. 
> I have worked at revision:
>     862cebe157a4ce50984d6fc15758da7d3ca96e2a
>     Thu Mar 4 20:29:30 2010
> By applying the following patches on the KERNEL module:
>     kernel-safe-include.patch
>     kernel-mpi-includes.patch
>     kernel-mpi-libs.patch
>     kernel-hdf5-needs-mpi.patch
>     kernel-remove-mpi-undefs.patch
> and:
>     gui-mpich-mpi.patch
> on the GUI one, it works when installing it by hand in a local
> directory (I have used ~/sroot/). However it does not work when
> following the debian/rules install path. I thought that lines 206 
> and 207 of debian/rules where the problem:
> 
>     mv debian/tmp/usr/bin/*.py \
>     $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/
>     chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*
> 
> but it is not enough to make it works.

I thought that might be an issue too.  You might also try commenting the
lines which delete the .pyc (and maybe .pyo) files from /usr/bin.
Together they are supposed to make the package more efficient by
shipping just .py files and having them compile at install time, but it
seems like it will take some time to let Salomé know that those files
are not in /usr/bin.

> For all the processing at
> line 200, I do not understand where the files are. By running for 
> example:
> 
>     find /usr/ -name config_appli.xml
> 
> I do not find anything however I can find this file in my local ~/sroot
> directory. However I may have messed the install process, I am running
> a new build now.
> 
> Then I guess that we need to build Salome with hdf5 including mpi
> because we can not force the user to use libhdf5-serial when he will
> want to install Salome. Dealing with patches make the debuging harder
> for getting a first running version but I think that you have solved the
> problem. I have tried with and without hdf5 and I get the same behavior
> for the KERNEL part.

Indeed.  I am still waiting for the HDF5/GIS team to fix bug 510057
which has had a patch for six weeks now, so we can upload the new MED
and not have to use out-of-archive packages...

> I keep you in touch once my new version is running, I am getting 
> more confortable with the Debian packaging tools.

Thanks, I'll let you know if I can test the unstable packages, so we can
start a git bisect.

-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 (application/pgp-signature, inline)]

Message #233 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Fri, 02 Apr 2010 13:56:48 -0400

[Message part 1 (text/plain, inline)]

Hi everyone and apologies for the long delay since I last wrote.

On Tue, 2010-03-16 at 06:49 -0400, Adam C Powell IV wrote:
> On Thu, 2010-03-11 at 17:23 +0100, Andre Espaze wrote:
> > > > The last working version was actually the -4:
> > > > 
> > > >     c56f196854092f0dc0d222de71de1a4532f214ec
> > > >     Release 5.1.3-4 "Look ma, it builds!"
> > > 
> > > That's what I thought.  I tried that one today (backported to Ubuntu
> > > Karmic), and it didn't work.  I guess I'll have to bring X up in the
> > > chroot to check it there, then start the bisect process.
> > It still does not work but I wanted to let you know where I am. 
> > I have worked at revision:
> >     862cebe157a4ce50984d6fc15758da7d3ca96e2a
> >     Thu Mar 4 20:29:30 2010
> > By applying the following patches on the KERNEL module:
> >     kernel-safe-include.patch
> >     kernel-mpi-includes.patch
> >     kernel-mpi-libs.patch
> >     kernel-hdf5-needs-mpi.patch
> >     kernel-remove-mpi-undefs.patch
> > and:
> >     gui-mpich-mpi.patch
> > on the GUI one, it works when installing it by hand in a local
> > directory (I have used ~/sroot/). However it does not work when
> > following the debian/rules install path. I thought that lines 206 
> > and 207 of debian/rules where the problem:
> > 
> >     mv debian/tmp/usr/bin/*.py \
> >     $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/
> >     chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*
> > 
> > but it is not enough to make it works.
> 
> I thought that might be an issue too.  You might also try commenting the
> lines which delete the .pyc (and maybe .pyo) files from /usr/bin.
> Together they are supposed to make the package more efficient by
> shipping just .py files and having them compile at install time, but it
> seems like it will take some time to let Salomé know that those files
> are not in /usr/bin.
> 
> > For all the processing at
> > line 200, I do not understand where the files are. By running for 
> > example:
> > 
> >     find /usr/ -name config_appli.xml
> > 
> > I do not find anything however I can find this file in my local ~/sroot
> > directory. However I may have messed the install process, I am running
> > a new build now.
> > 
> > Then I guess that we need to build Salome with hdf5 including mpi
> > because we can not force the user to use libhdf5-serial when he will
> > want to install Salome. Dealing with patches make the debuging harder
> > for getting a first running version but I think that you have solved the
> > problem. I have tried with and without hdf5 and I get the same behavior
> > for the KERNEL part.
> 
> Indeed.  I am still waiting for the HDF5/GIS team to fix bug 510057
> which has had a patch for six weeks now, so we can upload the new MED
> and not have to use out-of-archive packages...
> 
> > I keep you in touch once my new version is running, I am getting 
> > more confortable with the Debian packaging tools.
> 
> Thanks, I'll let you know if I can test the unstable packages, so we can
> start a git bisect.

I've been getting VirtualBox to work, as suggested by Sylvestre (thanks
again!).  I spent a while trying to get shared folders to work, then
realized just this morning that I could just download stuff from the
net, so I finally have a pure unstable environment to (try to) run
Salomé.

André, I'm having trouble running version 5.1.3-4 from
http://lyre.mit.edu/~powell/salome/ -- I get the same error as with more
recent versions: "Study server is not found".  Are you setting some
environment variables to make it work?

-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 (application/pgp-signature, inline)]

Message #238 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 6 Apr 2010 14:07:17 +0200

Hi Adam,

> Hi everyone and apologies for the long delay since I last wrote.
No problem, I was also busy on others projects but I am back 
on Salomé for this week and I should work full time on it 
for the week starting on the 19th of april.
> 
> I've been getting VirtualBox to work, as suggested by Sylvestre (thanks
> again!).  I spent a while trying to get shared folders to work, then
> realized just this morning that I could just download stuff from the
> net, so I finally have a pure unstable environment to (try to) run
> Salomé.
> 
> André, I'm having trouble running version 5.1.3-4 from
> http://lyre.mit.edu/~powell/salome/ -- I get the same error as with more
> recent versions: "Study server is not found".  Are you setting some
> environment variables to make it work?
In fact I did not run an installed version because my system could not
build the binary packages due to a lack of memory. That is one of the
reason why I work now in a virtual machine on a dedicated server.
For using the 5.1.3-4, I simply ran:

    ./debian/rules install

and then I have started Salome from the debian/tmp/usr directory by 
ajusting the environment variables as you did in runSalome. Would you
be interested if I run a build of the 5.1.3-4 again? I could try to
find back every step.

Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The
funny point is that I can run Salomé when compiling it by hand in a
dedicated directory. An identified problem was the line:

    chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*

however I still get the 'Study server is not found' error at startup. I
have reached a point where I am comparing the configuration steps,
I hope to identify the problem soon.

Best regards,

André

Message #243 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 06 Apr 2010 11:23:53 -0400

[Message part 1 (text/plain, inline)]

Hi André,

On Tue, 2010-04-06 at 14:07 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> > Hi everyone and apologies for the long delay since I last wrote.
> No problem, I was also busy on others projects but I am back 
> on Salomé for this week and I should work full time on it 
> for the week starting on the 19th of april.
> > 
> > I've been getting VirtualBox to work, as suggested by Sylvestre (thanks
> > again!).  I spent a while trying to get shared folders to work, then
> > realized just this morning that I could just download stuff from the
> > net, so I finally have a pure unstable environment to (try to) run
> > Salomé.
> > 
> > André, I'm having trouble running version 5.1.3-4 from
> > http://lyre.mit.edu/~powell/salome/ -- I get the same error as with more
> > recent versions: "Study server is not found".  Are you setting some
> > environment variables to make it work?
> In fact I did not run an installed version because my system could not
> build the binary packages due to a lack of memory. That is one of the
> reason why I work now in a virtual machine on a dedicated server.
> For using the 5.1.3-4, I simply ran:
> 
>     ./debian/rules install
> 
> and then I have started Salome from the debian/tmp/usr directory by 
> ajusting the environment variables as you did in runSalome. Would you
> be interested if I run a build of the 5.1.3-4 again? I could try to
> find back every step.

Ah, that would be very helpful.  I'd like to get runSalome to work, but
I first have to have something working in order to do that. :-)

> Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The
> funny point is that I can run Salomé when compiling it by hand in a
> dedicated directory. An identified problem was the line:
> 
>     chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*
> 
> however I still get the 'Study server is not found' error at startup. I
> have reached a point where I am comparing the configuration steps,
> I hope to identify the problem soon.

Thanks for your work on this.  Between the two of us, I hope we can find
out what's breaking this soon...

-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 (application/pgp-signature, inline)]

Message #248 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 7 Apr 2010 12:06:58 +0200

[Message part 1 (text/plain, inline)]

Hi Adam,

> 
> > Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The
> > funny point is that I can run Salomé when compiling it by hand in a
> > dedicated directory. An identified problem was the line:
> > 
> >     chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*
> > 
> > however I still get the 'Study server is not found' error at startup. I
> > have reached a point where I am comparing the configuration steps,
> > I hope to identify the problem soon.
> 
> Thanks for your work on this.  Between the two of us, I hope we can find
> out what's breaking this soon...
I made the KERNEL and GUI modules work this morning on the 5.1.3-5
release. I have enclose the patch 'kernel-gui-building.patch' that
should be applied on the revision:

    862cebe157a4ce50984d6fc15758da7d3ca96e2a
    Thu Mar 4 20:29:30 2010
    Remove troublesome /usr/bin subdirectory from HXX2SALOME.

by:

    patch -p1 < kernel-gui-building.patch

The steps for running the resulting Salome are provided inside the patch.

For me, the main problem was that I did not install the shared 
librairies stored in the package libsalome-dev. It explains why
I could run Salome by ajusting environment variables to debian/tmp/usr 
but never once installed on the system. By the way, it is correct 
to have the line:
    usr/lib/*.so
inside 'debian/libsalome-dev.files'? 

I guess that it is not relevant to run the 5.1.3-4 build again 
if this version works for you. I am now starting a complete build
with all modules.

Best regards,

André

[kernel-gui-building.patch (text/x-diff, attachment)]

Message #253 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 14 Apr 2010 22:38:32 -0400

[Message part 1 (text/plain, inline)]

Hi André,

Apologies for the long delay in replying since your message arrived.
I've been very busy, and just yesterday finally compiled Salomé.

On Wed, 2010-04-07 at 12:06 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> > 
> > > Concerning the 5.1.3-5, I can not start Salomé from debian/tmp/usr. The
> > > funny point is that I can run Salomé when compiling it by hand in a
> > > dedicated directory. An identified problem was the line:
> > > 
> > >     chmod -x $(CURDIR)/debian/tmp/usr/lib/python2.5/*-packages/salome/*
> > > 
> > > however I still get the 'Study server is not found' error at startup. I
> > > have reached a point where I am comparing the configuration steps,
> > > I hope to identify the problem soon.
> > 
> > Thanks for your work on this.  Between the two of us, I hope we can find
> > out what's breaking this soon...
> I made the KERNEL and GUI modules work this morning on the 5.1.3-5
> release. I have enclose the patch 'kernel-gui-building.patch' that
> should be applied on the revision:
> 
>     862cebe157a4ce50984d6fc15758da7d3ca96e2a
>     Thu Mar 4 20:29:30 2010
>     Remove troublesome /usr/bin subdirectory from HXX2SALOME.
> 
> by:
> 
>     patch -p1 < kernel-gui-building.patch
> 
> The steps for running the resulting Salome are provided inside the patch.
> 
> For me, the main problem was that I did not install the shared 
> librairies stored in the package libsalome-dev. It explains why
> I could run Salome by ajusting environment variables to debian/tmp/usr 
> but never once installed on the system.

Indeed, you found the problem!  The shared libraries themselves are not
in the -dev package, only the symlinks are, but for some reason the -dev
package is required to run Salomé.  We'll have to investigate why...

> By the way, it is correct 
> to have the line:
>     usr/lib/*.so
> inside 'debian/libsalome-dev.files'? 

That's fine: the shared library package gets the real shared libraries
*.so.0.0.0 , and -dev gets the symlinks *.so .  If the library loading
code needs the .so files, then that's something to fix.

> I guess that it is not relevant to run the 5.1.3-4 build again 
> if this version works for you. I am now starting a complete build
> with all modules.

I've built -5 with everything but VISU and NETGENPLUGIN (which don't
build), they're at http://lyre.mit.edu/~powell/salome/ .

There's lots more to do, but having a version which runs seems like a
big milestone.  If you could test it, that would be great.  This may
even be worth uploading, so it gets started in the NEW queue, and if all
goes well we can start using the Debian bug reporting system.

By the way, have you had any luck with asking upstream to adopt some of
these patches?  Let me know if you need more information about any of
them.

-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 (application/pgp-signature, inline)]

Message #258 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 20 Apr 2010 15:25:27 +0200

Hi Adam,

> Apologies for the long delay in replying since your message arrived.
> I've been very busy, and just yesterday finally compiled Salomé.
No problem, I have been busy too last week and I am now coming back
on Salomé.
> 
> > I made the KERNEL and GUI modules work this morning on the 5.1.3-5
> > release. I have enclose the patch 'kernel-gui-building.patch' that
> > should be applied on the revision:
> > 
> >     862cebe157a4ce50984d6fc15758da7d3ca96e2a
> >     Thu Mar 4 20:29:30 2010
> >     Remove troublesome /usr/bin subdirectory from HXX2SALOME.
> > 
> > by:
> > 
> >     patch -p1 < kernel-gui-building.patch
> > 
> > The steps for running the resulting Salome are provided inside the patch.
> > 
> > For me, the main problem was that I did not install the shared 
> > librairies stored in the package libsalome-dev. It explains why
> > I could run Salome by ajusting environment variables to debian/tmp/usr 
> > but never once installed on the system.
> 
> Indeed, you found the problem!  The shared libraries themselves are not
> in the -dev package, only the symlinks are, but for some reason the -dev
> package is required to run Salomé.  We'll have to investigate why...
Ok, I will add this point to the ticket list.
> 
> > By the way, it is correct 
> > to have the line:
> >     usr/lib/*.so
> > inside 'debian/libsalome-dev.files'? 
> 
> That's fine: the shared library package gets the real shared libraries
> *.so.0.0.0 , and -dev gets the symlinks *.so .  If the library loading
> code needs the .so files, then that's something to fix.
Thanks for clarifying this point, it makes sense now.
> 
> > I guess that it is not relevant to run the 5.1.3-4 build again 
> > if this version works for you. I am now starting a complete build
> > with all modules.
> 
> I've built -5 with everything but VISU and NETGENPLUGIN (which don't
> build), they're at http://lyre.mit.edu/~powell/salome/ .
I am building it but the test server got a problem during the night
so I had to start from the beginning this morning. However I could 
run the GEOM, MED and SMESH modules without problem on the last build.
> 
> There's lots more to do, but having a version which runs seems like a
> big milestone.
Yes, I agree.

>  If you could test it, that would be great.  This may
> even be worth uploading, so it gets started in the NEW queue, and if all
> goes well we can start using the Debian bug reporting system.
Excellent, I keep you in touch once I can test.
> 
> By the way, have you had any luck with asking upstream to adopt some of
> these patches?  Let me know if you need more information about any of
> them.
I discussed that point with Nicolas yesterday. I am supposed to submit
the KERNEL and GUI patches this week. Then I will start to review and 
test the remaining patches but they look fine. I will also try to have
a look at the VISU module because post-processing is an important 
use case.

Best regards,

André

Message #263 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: Adam C Powell IV <hazelsct@debian.org>, 457075@bugs.debian.org, alf@logilab.fr, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 20 Apr 2010 16:18:45 +0200

Le mardi 20 avril 2010 à 15:25 +0200, Andre Espaze a écrit :
> 
> > By the way, have you had any luck with asking upstream to adopt some
> of
> > these patches?  Let me know if you need more information about any
> of
> > them.
> I discussed that point with Nicolas yesterday. I am supposed to submit
> the KERNEL and GUI patches this week. 
Great!
Do you have some information on the potential inclusions of these
patches ?

By the way, Christophe Trophime updated the Code Aster packages that
Adam and I wrote a while ago.
I am going to review them for their inclusions into Debian.

Sylvestre

Message #268 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 21 Apr 2010 09:56:38 +0200

[Message part 1 (text/plain, inline)]

Hi Adam,

> 
> > I guess that it is not relevant to run the 5.1.3-4 build again 
> > if this version works for you. I am now starting a complete build
> > with all modules.
> 
> I've built -5 with everything but VISU and NETGENPLUGIN (which don't
> build), they're at http://lyre.mit.edu/~powell/salome/ .
> 
> There's lots more to do, but having a version which runs seems like a
> big milestone.  If you could test it, that would be great.  This may
> even be worth uploading, so it gets started in the NEW queue, and if all
> goes well we can start using the Debian bug reporting system.
It works that time, I only had to export the LD_LIBRARY_PATH variable 
in runSalome, I have attached the patch.

I could run Salome with the GEOM, MED, SMESH and YACS modules which 
are loaded by default. The MULTIPTR and HELLO modules work too when
added on the command line. The PYHELLO module seems to have a loading
problem but that is a developer example. The remaining modules do not
seem to have a GUI. I plan to work on the VISU module now once the 
patches are sent to upstream. 
Thank you very much for the great work, I am glad to see a first 
working version in Debian.

All the best,

André

[run-salome.patch (text/x-diff, attachment)]

Message #273 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Sylvestre Ledru <sylvestre@debian.org>

Cc: Adam C Powell IV <hazelsct@debian.org>, 457075@bugs.debian.org, alf@logilab.fr, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 21 Apr 2010 10:04:32 +0200

Hi Sylvestre,

On Tue, Apr 20, 2010 at 04:18:45PM +0200, Sylvestre Ledru wrote:
> Le mardi 20 avril 2010 à 15:25 +0200, Andre Espaze a écrit :
> > 
> > > By the way, have you had any luck with asking upstream to adopt some
> > of
> > > these patches?  Let me know if you need more information about any
> > of
> > > them.
> > I discussed that point with Nicolas yesterday. I am supposed to submit
> > the KERNEL and GUI patches this week. 
> Great!
> Do you have some information on the potential inclusions of these
> patches ?
Nicolas knows some of the upstream developers so we hope to succeed
the inclusions but there is no guarantee.
> 
> By the way, Christophe Trophime updated the Code Aster packages that
> Adam and I wrote a while ago.
> I am going to review them for their inclusions into Debian.
I am interested to help on that task once the first Salome version run.
Moreover the metis package will also be useful for the MED module
of Salome.

See you soon,

André

Message #278 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Nicolas Chauvat <nicolas.chauvat@logilab.fr>

To: Sylvestre Ledru <sylvestre@debian.org>

Cc: Andre Espaze <dede@logilab.fr>, Adam C Powell IV <hazelsct@debian.org>, 457075@bugs.debian.org, alf@logilab.fr, nico@logilab.fr

Subject: Salomé sources now available via git

Date: Wed, 21 Apr 2010 12:49:08 +0200

http://git.salome-platform.org/gitweb/

Looks like they are slowly opening up. Hopefully, it will make
collaboration much easier.

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  

Message #283 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Nicolas Chauvat <nicolas.chauvat@logilab.fr>, 457075@bugs.debian.org

Subject: Re: Bug#457075: Salomé sources now available via git

Date: Wed, 21 Apr 2010 16:15:16 +0100

On 21 April 2010 11:49, Nicolas Chauvat <nicolas.chauvat@logilab.fr> wrote:
> http://git.salome-platform.org/gitweb/
>
> Looks like they are slowly opening up. Hopefully, it will make
> collaboration much easier.
>

Great news. I wonder why git though? It was clearly that they were
using hg before with all the .hg* files leaking in the tarball....

Message #288 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 22 Apr 2010 17:27:13 +0200

Hi Adam,

> > 
> > > I guess that it is not relevant to run the 5.1.3-4 build again 
> > > if this version works for you. I am now starting a complete build
> > > with all modules.
> > 
> > I've built -5 with everything but VISU and NETGENPLUGIN (which don't
> > build), they're at http://lyre.mit.edu/~powell/salome/ .
> > 
> > There's lots more to do, but having a version which runs seems like a
> > big milestone.  If you could test it, that would be great.  This may
> > even be worth uploading, so it gets started in the NEW queue, and if all
> > goes well we can start using the Debian bug reporting system.
> It works that time, I only had to export the LD_LIBRARY_PATH variable 
> in runSalome, I have attached the patch.
> 
Now that the first version work, I have added the link BuildingSalome 
to the page:
http://wiki.debian.org/DebianScience/Engineering
Comments and changes are very welcome.

All the best,

André

Message #293 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 22 Apr 2010 18:42:13 -0400

[Message part 1 (text/plain, inline)]

Thank you Andre, the debian-science entry looks terrific!

It's very frustrating that bug 510057 against hdf5 is nearly 16 months
old, and there has been a simple patch available for 3.5 months, but
they have just added a new upstream version, with no progress on this or
571453. :-(  I'm going to send a reminder to these two bugs.

I've tagged what's on lyre as -5 in alioth, and am working toward -6.
I'm also trying to get NETGENPLUGIN working, and have started a port to
the nglib 4.9.x API.  But I'm having trouble, as you'll see if you try
to build with it enabled (I disabled it in debian/rules for now).

I did notice a post on "Netgen and Salome" on the Netgen forum [1]
indicating that Salome developers are porting to the 4.9.x nglib.h API,
so I guess we'll be able to see that in the git repository [2] soon.
But the repository currently doesn't test for the new API, so if a port
is in progress, it's not in git yet...

[1] http://sourceforge.net/projects/netgen-mesher/forums/forum/905306/topic/3451454
[2] http://git.salome-platform.org/gitweb/?p=NETGENPLUGIN_SRC.git;a=summary

I need this plugin for my own purposes, so after finishing an overall
package which is upload-worthy I'm going to keep working on it.

-Adam

On Thu, 2010-04-22 at 17:27 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> > > 
> > > > I guess that it is not relevant to run the 5.1.3-4 build again 
> > > > if this version works for you. I am now starting a complete build
> > > > with all modules.
> > > 
> > > I've built -5 with everything but VISU and NETGENPLUGIN (which don't
> > > build), they're at http://lyre.mit.edu/~powell/salome/ .
> > > 
> > > There's lots more to do, but having a version which runs seems like a
> > > big milestone.  If you could test it, that would be great.  This may
> > > even be worth uploading, so it gets started in the NEW queue, and if all
> > > goes well we can start using the Debian bug reporting system.
> > It works that time, I only had to export the LD_LIBRARY_PATH variable 
> > in runSalome, I have attached the patch.
> > 
> Now that the first version work, I have added the link BuildingSalome 
> to the page:
> http://wiki.debian.org/DebianScience/Engineering
> Comments and changes are very welcome.
> 
> All the best,
> 
> André
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[signature.asc (application/pgp-signature, inline)]

Message #298 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Fri, 23 Apr 2010 18:47:32 -0400

[Message part 1 (text/plain, inline)]

Hello all,

I think we're getting close to a -6 release and first upload into Debian
unstable.  I'm noticing two issues though which will need just a tiny
bit of work.

First, the -dev dependency extends beyond libsalome-dev.  For example,
the GEOM module requires libTKOpenGl.so which is in
libopencascade-visualization-dev so salome must depend on at least that
package as well.  There are likely others.  Can some of you help me to
figure out what is required?  If we miss a couple before upload, that's
probably okay, we'll just get even more bug reports for these than we
otherwise would. :-)

Later we can hopefully modify Salomé's shared lib loading code so it
detects the soname at build time and loads that file at runtime, as this
is a bug.  If anyone can figure out an easy way to do that now, great;
otherwise we need to add a few -dev packages to the dependencies.

Second, I've cut the number of lintian warnings by dozens by making
the .py files non-executable.  The one problem that results is during
startup, which can be solved by the following patch:

diff --git a/KERNEL_SRC_5.1.3/bin/runSalome.py b/KERNEL_SRC_5.1.3/bin/runSalome.py
index d67d6b0..550a6c2 100755
--- a/KERNEL_SRC_5.1.3/bin/runSalome.py
+++ b/KERNEL_SRC_5.1.3/bin/runSalome.py
@@ -191,7 +191,7 @@ class ContainerPYServer(Server):
         if sys.platform == "win32":
           self.CMD=[os.environ["PYTHONBIN"], '\"'+os.environ["KERNEL_ROOT_DIR"] + '/bin/salome/SALOME_ContainerPy.py'+'\"','FactoryServerPy']
         else:
-          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
+          self.CMD=['python','/usr/lib/python2.5/site-packages/salome/SALOME_ContainerPy.py','FactoryServerPy']
 
 # ---
 
My python is even worse than my French, so that's the best I can do, but
I'm certain there's a better way.  Can someone help my pathetic python,
hopefully in a way that will be acceptable to upstream?

This is getting exciting, we're just about there!  I think this will be
ready for its first upload on Monday...  Any differing opinions?

-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 (application/pgp-signature, inline)]

Message #303 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: 457075@bugs.debian.org

Subject: Re: Question on Salome package organization

Date: Mon, 26 Apr 2010 13:18:54 -0400

[Message part 1 (text/plain, inline)]

Greetings again,

salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ .  The
package is big and ugly and kludgey, but I've tested it a bit and
confirmed that it runs from the menu.

I built it with -sa and closed the ITP bug in the changelog, so it
should be ready for its first upload.  The question is: should I upload
it?

Here are the arguments as I see them.  For uploading: 
      * It seems to work (run), and thus can meet users' needs 
      * Quicker reply from ftp-masters on copyright and other uploading
        issues 
      * Broader testing, especially if it gets into squeeze 
      * Possibly more devs interested in helping with debugging and
        package development 
      * Use of the BTS to track issues 
      * It will take a lot of work to fix some of the issues below,
        let's work on them together

Against uploading: 
      * The package is buggy!  In particular, module loading
        requires .so files, so one needs to install about 100 MiB worth
        of -dev packages in order to run it 
      * Package layout is not finalized, as demonstrated below 
      * Shared library versioning isn't even finalized...

In short, I think this package is about where OpenCASCADE and OpenOffice
were when first uploaded: crude and simple packaging of a very useful
piece of software, with plans for big packaging changes.  I'd like to go
ahead and upload in about 24 hours unless anyone has a strong objection.

-Adam

On Thu, 2010-04-22 at 19:23 -0400, Adam C Powell IV wrote: 
> Hello André and list,
> 
> On Thu, 2010-04-22 at 15:04 +0200, Andre Espaze wrote:
> > Dear list,
> > 
> > Now that salome-5.1.3-5 is running, I started a documentation on its
> > content and finally found a question on Debian package organization.
> ...
> 
> The current package organization is a "legacy" system from back when I
> first started to package version 3.2.6.  It's really not very good. :-)
> 
> > I am aware of my ignorance on Debian package policy,
> 
> Debian package policy doesn't require any particular organization, it
> just indicates what should be in shared lib, python, etc. packages.
> 
> > but I would suggest
> > such kind of organization:
> > 
> >     - salome-core (the usual pre and post processings)
> >     - salome-core-dev (its development files)
> >     - salome-advance (the advanced uses)
> >     - salome-advance-dev (its development files)
> >     - salome-dev (every module for the Salome developer with
> >     development files)
> >     - salome-doc (the actual documentation)
> 
> I like this organization.  It's something like the transition we did for
> Open CASCADE a couple of years ago, led by Jason Kraftcheck and Denis
> Barbier. [1]
> 
> [1] http://lists.debian.org/debian-science/2008/01/msg00013.html
> 
> I have a few suggestions:
>       * There are a lot of "[T|t]est*" binaries in the salome package.
>         It would be good to separate these out into salome-core-test
>         etc. packages so one doesn't need to install them along with the
>         main binaries.
>       * The shared libraries should go in their own packages, such as
>         libsalome-core etc.  Because their interface changes with every
>         version, they should probably change from the 0.0.0 version
>         designation to using the libtool "-release" flag with the
>         package version, e.g. libGLViewer-5.1.3.so .
>       * I think there should be a package called plain "salome" with the
>         core functionality which people expect to have when they think
>         of Salomé.
>       * The documentation also desparately needs to break up!  I suggest
>         salome-doc for the non-built docs, and salome-user-doc and
>         salome-dev-doc for the docs made with "make -C [MODULE]/doc
>         usr_docs" and dev_docs respectively.
>       * As for implementation, instead of SALOME_MODULES, perhaps we can
>         have SALOME_CORE_MODULES, etc., and install them with DESTDIR=
>         $(CURDIR)/debian/salome-core or -advanced etc., and then move
>         around the shared libs, header files, symlinks, and python files
>         from there.
> 
> > Another solution would be to provide a package for every Salome module
> > but it seems to be confusing because of the modules number. Moreover the
> > package creations is going to become inconvenient while producing very
> > little improvement to the user. Who is going to create a mesh without
> > using the GUI but only through a CORBA service (thus installing only
> > salome-kernel and salome-smesh)? The same scenario can be repeated to
> > others modules as well.
> 
> I agree this would not be a helpful solution.
> 
> > In conclusion, is it worth to wonder about a new Salome package
> > organization?
> 
> Definitely!  Thanks for the suggestion.  It will all take a lot of work,
> and should probably happen after the initial package goes into unstable,
> but it will make people's lives much easier in the post-squeeze release.
> 
> -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 (application/pgp-signature, inline)]

Message #308 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: debian-science@lists.debian.org, 457075@bugs.debian.org

Subject: Re: Question on Salome package organization

Date: Mon, 26 Apr 2010 23:07:18 +0200

Le lundi 26 avril 2010 à 13:18 -0400, Adam C Powell IV a écrit :
> Greetings again,
> 
> salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ .  The
> package is big and ugly and kludgey, but I've tested it a bit and
> confirmed that it runs from the menu.
> 
> I built it with -sa and closed the ITP bug in the changelog, so it
> should be ready for its first upload.  The question is: should I upload
> it?
> 
> Here are the arguments as I see them.  For uploading: 
>       * It seems to work (run), and thus can meet users' needs 
>       * Quicker reply from ftp-masters on copyright and other uploading
>         issues 
>       * Broader testing, especially if it gets into squeeze 
>       * Possibly more devs interested in helping with debugging and
>         package development 
>       * Use of the BTS to track issues 
>       * It will take a lot of work to fix some of the issues below,
>         let's work on them together
> 
> Against uploading: 
>       * The package is buggy!  In particular, module loading
>         requires .so files, so one needs to install about 100 MiB worth
>         of -dev packages in order to run it 
>       * Package layout is not finalized, as demonstrated below 
>       * Shared library versioning isn't even finalized...
> 
> In short, I think this package is about where OpenCASCADE and OpenOffice
> were when first uploaded: crude and simple packaging of a very useful
> piece of software, with plans for big packaging changes.  I'd like to go
> ahead and upload in about 24 hours unless anyone has a strong objection.
Well done for this packaging!
I say, the sooner, the better!

One more argument: we could plug Aster into Salome thanks to pylotage.

If we are lucky, it could even make it for Squeeze!

Sylvestre

Message #313 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>

To: Sylvestre Ledru <sylvestre@debian.org>, 457075@bugs.debian.org

Subject: Re: Bug#457075: Question on Salome package organization

Date: Tue, 27 Apr 2010 00:27:52 +0100

On 26 April 2010 22:07, Sylvestre Ledru <sylvestre@debian.org> wrote:
> Le lundi 26 avril 2010 à 13:18 -0400, Adam C Powell IV a écrit :
>> In short, I think this package is about where OpenCASCADE and OpenOffice
>> were when first uploaded: crude and simple packaging of a very useful
>> piece of software, with plans for big packaging changes.  I'd like to go
>> ahead and upload in about 24 hours unless anyone has a strong objection.
> Well done for this packaging!
> I say, the sooner, the better!
>
> One more argument: we could plug Aster into Salome thanks to pylotage.
>
> If we are lucky, it could even make it for Squeeze!
>
> Sylvestre
>

Upload! =) we do have mingw packages in the archive which are not in
the perfect condition but they are extremly useful.

Message #318 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Nicolas Chauvat <nicolas.chauvat@logilab.fr>

To: Sylvestre Ledru <sylvestre@debian.org>

Cc: Adam C Powell IV <hazelsct@debian.org>, debian-science@lists.debian.org, 457075@bugs.debian.org

Subject: Re: Question on Salome package organization

Date: Tue, 27 Apr 2010 09:36:31 +0200

On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote:
> Well done for this packaging!

Yep, nice job.

> One more argument: we could plug Aster into Salome thanks to pylotage.
> 
> If we are lucky, it could even make it for Squeeze!

+1, let's try to get it into squeeze. It will mean more users and
developers, even though the packaging changes completely for squeeze+1.

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  

Message #323 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: 457075@bugs.debian.org

Subject: Re: Question on Salome package organization

Date: Tue, 27 Apr 2010 13:58:37 -0400

[Message part 1 (text/plain, inline)]

On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote:
> On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote:
> > Well done for this packaging!
> 
> Yep, nice job.

Thanks.

> > One more argument: we could plug Aster into Salome thanks to pylotage.
> > 
> > If we are lucky, it could even make it for Squeeze!
> 
> +1, let's try to get it into squeeze. It will mean more users and
> developers, even though the packaging changes completely for squeeze+1.

Done!

-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 (application/pgp-signature, inline)]

Message #328 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: debian-science@lists.debian.org

Cc: 457075@bugs.debian.org

Subject: Re: Question on Salome package organization

Date: Wed, 28 Apr 2010 07:41:01 -0400

[Message part 1 (text/plain, inline)]

On Tue, 2010-04-27 at 13:58 -0400, Adam C Powell IV wrote:
> On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote:
> > > One more argument: we could plug Aster into Salome thanks to pylotage.
> > > 
> > > If we are lucky, it could even make it for Squeeze!
> > 
> > +1, let's try to get it into squeeze. It will mean more users and
> > developers, even though the packaging changes completely for squeeze+1.
> 
> Done!

Sorry, bunch of errors on my part, should have -7 on lyre and uploaded
by the end of today.

-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 (application/pgp-signature, inline)]

Message #335 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 5 May 2010 09:40:16 +0200

Hi Adam,

Sorry for the delay, I have missed the -6 release but I have
just built the -7 one which works fine. I have updated the
documentation on:
http://wiki.debian.org/BuildingSalome
It seems that building Med dependencies by hand is no longer needed
because libmed-2.3.6-2 is now available in Debian sid.  I only had one
problem during the installation step with the 'salome.desktop' file
which did not exist but it may be an error on my side. I will see
if I can reproduce it in the next build.

> First, the -dev dependency extends beyond libsalome-dev.  For example,
> the GEOM module requires libTKOpenGl.so which is in
> libopencascade-visualization-dev so salome must depend on at least that
> package as well.  There are likely others.  Can some of you help me to
> figure out what is required?  If we miss a couple before upload, that's
> probably okay, we'll just get even more bug reports for these than we
> otherwise would. :-)
I can help on that part once the VISU module is working, I have just
added a ticket on the Logilab's project:
http://www.python-science.org/ticket/1841
> 
> Later we can hopefully modify Salomé's shared lib loading code so it
> detects the soname at build time and loads that file at runtime, as this
> is a bug.  If anyone can figure out an easy way to do that now, great;
> otherwise we need to add a few -dev packages to the dependencies.
I have added a ticket too:
http://www.python-science.org/ticket/1822
but to my point of view such change should be difficult.
> 
> Second, I've cut the number of lintian warnings by dozens by making
> the .py files non-executable.  The one problem that results is during
> startup, which can be solved by the following patch:
> 
> diff --git a/KERNEL_SRC_5.1.3/bin/runSalome.py b/KERNEL_SRC_5.1.3/bin/runSalome.py
> index d67d6b0..550a6c2 100755
> --- a/KERNEL_SRC_5.1.3/bin/runSalome.py
> +++ b/KERNEL_SRC_5.1.3/bin/runSalome.py
> @@ -191,7 +191,7 @@ class ContainerPYServer(Server):
>          if sys.platform == "win32":
>            self.CMD=[os.environ["PYTHONBIN"], '\"'+os.environ["KERNEL_ROOT_DIR"] + '/bin/salome/SALOME_ContainerPy.py'+'\"','FactoryServerPy']
>          else:
> -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> +          self.CMD=['python','/usr/lib/python2.5/site-packages/salome/SALOME_ContainerPy.py','FactoryServerPy']
>  
>  # ---
>  
> My python is even worse than my French, so that's the best I can do, but
> I'm certain there's a better way.  Can someone help my pathetic python,
> hopefully in a way that will be acceptable to upstream?
I think that SALOME_ContainerPy.py should be considered as an executable
script because its first line starts with:

    #! /usr/bin/env python

As a consequence, it should live inside /usr/bin like others commands
so no patch is required.  The only reproach to upstream may be to keep
the '.py' extension which is confusing because SALOME_ContainerPy is
supposed to be a command.  I have moved SALOME_ContainerPy.py to /usr/bin
and made it executable and Salome was still working. I think that it
should be possible to add this behavior to the Debian package during
the installation step.  What is your opinion on this point? Would you
like me to work on a patch?


All the best,

André

Message #340 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Alexander Reichle-Schmehl <ftpmaster@debian.org>

Cc: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>, Archive Administrator <installer@ftp-master.debian.org>, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, alf@logilab.fr, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>, Andre Espaze <andre.espaze@logilab.fr>

Subject: Re: salome_5.1.3-7_amd64.changes REJECTED

Date: Wed, 05 May 2010 14:31:14 -0400

[Message part 1 (text/plain, inline)]

On Wed, 2010-05-05 at 18:09 +0000, Alexander Reichle-Schmehl wrote:
> Hi Maintainer!
> 
> I'm sorry but I need to temporarily reject your package, as it is by far the
> largest currently sitting in the NEW queue and ftp-master is currently running
> low on disc space.
> 
> I didn't had the time to investigate your package (beside seeing that it is the
> largest in the NEW queue and rejecting it would reduce the size of NEW by more
> than a half!).

Oh dear, that's too bad...  But yes, it is a gigantic package.

If I make a version without the -doc binary, that takes it from 859 to
235 MiB including .orig.tar.gz.  (The -doc binary has a huge amount of
very large generated documentation...)  Does that reduce it's size
enough to consider re-uploading?

I can appreciate the burden of checking a package of this size.
But It's taken a good-sized team a few months of concerted effort to get
this far (development actually started about two and a half years ago),
and we'd like to be able to use the BTS to track the various issues with
the package, among other concerns.

[Also, there's a summary of all of the copyright statements in every
file of every module in debian/copyright-audit/ to make your life
easier.]

> A better solution is currently being worked on, but might need some time.  Once
> we have a) a new ftp-master server or b) archieved the etch release, you can
> reupload your package.

Makes sense.  But if the above isn't sufficient reduction in the package
size, how will we know when this happens?

Thanks,
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 (application/pgp-signature, inline)]

Message #345 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 05 May 2010 14:43:38 -0400

[Message part 1 (text/plain, inline)]

Hi André,

On Wed, 2010-05-05 at 09:40 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> Sorry for the delay, I have missed the -6 release but I have
> just built the -7 one which works fine.

No problem.  -6 had a dumb mistake which caused it to be rejected by
Debian right away, so you didn't miss anything.

> I have updated the
> documentation on:
> http://wiki.debian.org/BuildingSalome
> It seems that building Med dependencies by hand is no longer needed
> because libmed-2.3.6-2 is now available in Debian sid.

Right, the Debian-GIS team finally updated HDF5, so I was able to upload
the new and working MED package.

> I only had one
> problem during the installation step with the 'salome.desktop' file
> which did not exist but it may be an error on my side. I will see
> if I can reproduce it in the next build.

That file should be in the debian directory.  debian/rules copies it
into debian/tmp, then it's in salome.files so it should get into the
salome package (dpkg -c tells which files are in a .deb).

> > First, the -dev dependency extends beyond libsalome-dev.  For example,
> > the GEOM module requires libTKOpenGl.so which is in
> > libopencascade-visualization-dev so salome must depend on at least that
> > package as well.  There are likely others.  Can some of you help me to
> > figure out what is required?  If we miss a couple before upload, that's
> > probably okay, we'll just get even more bug reports for these than we
> > otherwise would. :-)
> I can help on that part once the VISU module is working, I have just
> added a ticket on the Logilab's project:
> http://www.python-science.org/ticket/1841
> > 
> > Later we can hopefully modify Salomé's shared lib loading code so it
> > detects the soname at build time and loads that file at runtime, as this
> > is a bug.  If anyone can figure out an easy way to do that now, great;
> > otherwise we need to add a few -dev packages to the dependencies.
> I have added a ticket too:
> http://www.python-science.org/ticket/1822
> but to my point of view such change should be difficult.

I agree, the problem seems to also be in OpenCASCADE (bug 550445), so it
may be that Salomé uses OCC's loading mechanism.  Yeah, this one will
take a bit of time to track down.

> > Second, I've cut the number of lintian warnings by dozens by making
> > the .py files non-executable.  The one problem that results is during
> > startup, which can be solved by the following patch:
> > 
> > diff --git a/KERNEL_SRC_5.1.3/bin/runSalome.py b/KERNEL_SRC_5.1.3/bin/runSalome.py
> > index d67d6b0..550a6c2 100755
> > --- a/KERNEL_SRC_5.1.3/bin/runSalome.py
> > +++ b/KERNEL_SRC_5.1.3/bin/runSalome.py
> > @@ -191,7 +191,7 @@ class ContainerPYServer(Server):
> >          if sys.platform == "win32":
> >            self.CMD=[os.environ["PYTHONBIN"], '\"'+os.environ["KERNEL_ROOT_DIR"] + '/bin/salome/SALOME_ContainerPy.py'+'\"','FactoryServerPy']
> >          else:
> > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> > +          self.CMD=['python','/usr/lib/python2.5/site-packages/salome/SALOME_ContainerPy.py','FactoryServerPy']
> >  
> >  # ---
> >  
> > My python is even worse than my French, so that's the best I can do, but
> > I'm certain there's a better way.  Can someone help my pathetic python,
> > hopefully in a way that will be acceptable to upstream?
> I think that SALOME_ContainerPy.py should be considered as an executable
> script because its first line starts with:
> 
>     #! /usr/bin/env python
> 
> As a consequence, it should live inside /usr/bin like others commands
> so no patch is required.  The only reproach to upstream may be to keep
> the '.py' extension which is confusing because SALOME_ContainerPy is
> supposed to be a command.  I have moved SALOME_ContainerPy.py to /usr/bin
> and made it executable and Salome was still working. I think that it
> should be possible to add this behavior to the Debian package during
> the installation step.  What is your opinion on this point? Would you
> like me to work on a patch?

Sure, though I think it might make sense to remove the .py from the
ending then, like avs2med and a couple of others.  In Debian, executable
scripts are not supposed to have extensions, not even .sh .

Make sure your patch eventually puts it into the /usr/bin directory of
the python2.5-salome package, or else it will generate another lintian
error (python script without python dependency).

Thanks,
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 (application/pgp-signature, inline)]

Message #350 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Joerg Jaspert <joerg@debian.org>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: Alexander Reichle-Schmehl <ftpmaster@debian.org>, Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>, Archive Administrator <installer@ftp-master.debian.org>, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, alf@logilab.fr, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>, Andre Espaze <andre.espaze@logilab.fr>

Subject: Re: salome_5.1.3-7_amd64.changes REJECTED

Date: Thu, 06 May 2010 06:31:59 +0200

>> I'm sorry but I need to temporarily reject your package, as it is by far the
>> largest currently sitting in the NEW queue and ftp-master is currently running
>> low on disc space.

>> I didn't had the time to investigate your package (beside seeing that it is the
>> largest in the NEW queue and rejecting it would reduce the size of NEW by more
>> than a half!).

> If I make a version without the -doc binary, that takes it from 859 to
> 235 MiB including .orig.tar.gz.  (The -doc binary has a huge amount of
> very large generated documentation...)  Does that reduce it's size
> enough to consider re-uploading?

Yes.

> I can appreciate the burden of checking a package of this size.

In this case it wasnt about checking it at all. "Only" about the sheer
size and the fact that ftpmaster does have some space issues.

> But It's taken a good-sized team a few months of concerted effort to get
> this far (development actually started about two and a half years ago),
> and we'd like to be able to use the BTS to track the various issues with
> the package, among other concerns.

Oh sure, of course.

>> A better solution is currently being worked on, but might need some time.  Once
>> we have a) a new ftp-master server or b) archieved the etch release, you can
>> reupload your package.
> Makes sense.  But if the above isn't sufficient reduction in the package
> size, how will we know when this happens?

The archive of the etch release will get a message to d-d-a or so. :)

Also, we are getting new hardware for ftpmaster, which has much more
diskspace too, and which will finally allow us to setup
data.debian.org. Your package, at least the -doc part, seems a good
target for that.

-- 
bye, Joerg
[ New Maintainer Prozess ]
<panthera> ein jahr ist ein bisschen zu optimistisch,
<_rene_> panthera: kommt auf den NM/AM an.
        /* _rene_ ist pantheras AM und lässt sich mit pantheras 
           package check schon ein wenig Zeit ;) */

Message #355 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Joerg Jaspert <joerg@debian.org>

Cc: Alexander Reichle-Schmehl <ftpmaster@debian.org>, Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>, Archive Administrator <installer@ftp-master.debian.org>, 457075@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, alf@logilab.fr, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>, Andre Espaze <andre.espaze@logilab.fr>

Subject: Re: salome_5.1.3-7_amd64.changes REJECTED

Date: Thu, 06 May 2010 12:43:59 -0400

[Message part 1 (text/plain, inline)]

On Thu, 2010-05-06 at 06:31 +0200, Joerg Jaspert wrote:
> >> I'm sorry but I need to temporarily reject your package, as it is by far the
> >> largest currently sitting in the NEW queue and ftp-master is currently running
> >> low on disc space.
> 
> >> I didn't had the time to investigate your package (beside seeing that it is the
> >> largest in the NEW queue and rejecting it would reduce the size of NEW by more
> >> than a half!).
> 
> > If I make a version without the -doc binary, that takes it from 859 to
> > 235 MiB including .orig.tar.gz.  (The -doc binary has a huge amount of
> > very large generated documentation...)  Does that reduce it's size
> > enough to consider re-uploading?
> 
> Yes.

Thanks very much, I'll prepare and upload it today.

> > I can appreciate the burden of checking a package of this size.
> 
> In this case it wasnt about checking it at all. "Only" about the sheer
> size and the fact that ftpmaster does have some space issues.

I understand, the -doc package has a ridiculous size.  We're planning to
cut it into separate user and developer documentation, and split it
further into core and specialty functionality.  That doesn't help the
upload size, but will help users to get the help they need without using
excessive disk space.

> >> A better solution is currently being worked on, but might need some time.  Once
> >> we have a) a new ftp-master server or b) archieved the etch release, you can
> >> reupload your package.
> > Makes sense.  But if the above isn't sufficient reduction in the package
> > size, how will we know when this happens?
> 
> The archive of the etch release will get a message to d-d-a or so. :)
> 
> Also, we are getting new hardware for ftpmaster, which has much more
> diskspace too, and which will finally allow us to setup
> data.debian.org. Your package, at least the -doc part, seems a good
> target for that.

Thanks, we'll look for the announcements on d-d-a and add -doc when
appropriate.

-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 (application/pgp-signature, inline)]

Message #360 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 06 May 2010 15:08:32 -0400

[Message part 1 (text/plain, inline)]

Hi again,

On Wed, 2010-05-05 at 14:44 -0400, Adam C Powell IV wrote:
> On Wed, 2010-05-05 at 09:40 +0200, Andre Espaze wrote:
> > > Second, I've cut the number of lintian warnings by dozens by making
> > > the .py files non-executable.  The one problem that results is during
> > > startup, which can be solved by the following patch:
> > > 
> > > diff --git a/KERNEL_SRC_5.1.3/bin/runSalome.py b/KERNEL_SRC_5.1.3/bin/runSalome.py
> > > index d67d6b0..550a6c2 100755
> > > --- a/KERNEL_SRC_5.1.3/bin/runSalome.py
> > > +++ b/KERNEL_SRC_5.1.3/bin/runSalome.py
> > > @@ -191,7 +191,7 @@ class ContainerPYServer(Server):
> > >          if sys.platform == "win32":
> > >            self.CMD=[os.environ["PYTHONBIN"], '\"'+os.environ["KERNEL_ROOT_DIR"] + '/bin/salome/SALOME_ContainerPy.py'+'\"','FactoryServerPy']
> > >          else:
> > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> > > +          self.CMD=['python','/usr/lib/python2.5/site-packages/salome/SALOME_ContainerPy.py','FactoryServerPy']
> > >  
> > >  # ---
> > >  
> > > My python is even worse than my French, so that's the best I can do, but
> > > I'm certain there's a better way.  Can someone help my pathetic python,
> > > hopefully in a way that will be acceptable to upstream?
> > I think that SALOME_ContainerPy.py should be considered as an executable
> > script because its first line starts with:
> > 
> >     #! /usr/bin/env python
> > 
> > As a consequence, it should live inside /usr/bin like others commands
> > so no patch is required.  The only reproach to upstream may be to keep
> > the '.py' extension which is confusing because SALOME_ContainerPy is
> > supposed to be a command.  I have moved SALOME_ContainerPy.py to /usr/bin
> > and made it executable and Salome was still working. I think that it
> > should be possible to add this behavior to the Debian package during
> > the installation step.  What is your opinion on this point? Would you
> > like me to work on a patch?
> 
> Sure, though I think it might make sense to remove the .py from the
> ending then, like avs2med and a couple of others.  In Debian, executable
> scripts are not supposed to have extensions, not even .sh .
> 
> Make sure your patch eventually puts it into the /usr/bin directory of
> the python2.5-salome package, or else it will generate another lintian
> error (python script without python dependency).

I just took care of this, the result is in the alioth git repository.

I'm going to build and test -8 with this and -doc package removal, and a
couple of other little changes, then test and re-upload.

-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 (application/pgp-signature, inline)]

Message #365 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Denis Barbier <bouzim@gmail.com>

To: Adam C Powell IV <hazelsct@debian.org>, Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Subject: Re: Bug#457075: Salomé packaging

Date: Mon, 10 May 2010 12:28:55 +0200

Greetings,

I am not a Salome user, but here are some (hopefully not too stupid)
remarks about
   http://ftp-master.debian.org/new/salome_5.1.3-8.html

  * Binary packages are under the contrib/ section, AFAICT they can be
moved into main
  * libsalome and libsalome-dev ships a lot of shared libraries, some
of which with very generic names libe libHELLO.so or libLauncher.so.
This is a potential source of conflict, can all these libraries be
moved into a private directory like /usr/lib/salome/ ?
  * Libraries generated by swig have an underscore prepended, which
means that they are not opened by the dynamic loader and should be
moved into a private directory.
  * Ditto for binaries; and there is a concrete conflict, salome ships
/usr/bin/display which means that many people will not be able to
install this package since imagemagick is very popular.  Can binaries
be moved into a private directory, like /usr/lib/salome/bin/ ?  I
guess that runSalome and killSalome have to be put under /usr/bin/, I
can't tell for other binaries.
  * Binary packages seem to contain lots of tests
(/usr/bin/*[tT][eE][sS][tT]* or /usr/lib/lib*[tT][eE][sS][tT]*), can
they be dropped?
  * Description of the salome binary package has to be updated, AFAICT
there is no binary under /usr/bin/salome/
  * salome-common is quite large, are files under
/usr/share/salome/resources/med/ really needed?  It looks like *.med
files are already provided by salome-examples.

Denis

Message #370 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Denis Barbier <bouzim@gmail.com>, 457075@bugs.debian.org

Cc: Andre Espaze <andre.espaze@logilab.fr>

Subject: Re: Bug#457075: Salomé packaging

Date: Mon, 10 May 2010 18:32:20 -0400

[Message part 1 (text/plain, inline)]

Hello Denis,

On Mon, 2010-05-10 at 12:28 +0200, Denis Barbier wrote:
> Greetings,
> 
> I am not a Salome user, but here are some (hopefully not too stupid)
> remarks about
>    http://ftp-master.debian.org/new/salome_5.1.3-8.html
> 
>   * Binary packages are under the contrib/ section, AFAICT they can be
> moved into main

Wow, this should have been changed a *long* time ago when Open CASCADE
was accepted to Debian main!  Thanks, just made the change on alioth.

>   * libsalome and libsalome-dev ships a lot of shared libraries, some
> of which with very generic names libe libHELLO.so or libLauncher.so.
> This is a potential source of conflict, can all these libraries be
> moved into a private directory like /usr/lib/salome/ ?
>   * Libraries generated by swig have an underscore prepended, which
> means that they are not opened by the dynamic loader and should be
> moved into a private directory.

Good points.  The default salome behavior is to have them in a private
directory (I think /usr/lib/salome), I moved them into /usr/lib , but
you bring up a good reason to put them in the private directory.

I'll test this in my next build.

>   * Ditto for binaries; and there is a concrete conflict, salome ships
> /usr/bin/display which means that many people will not be able to
> install this package since imagemagick is very popular.  Can binaries
> be moved into a private directory, like /usr/lib/salome/bin/ ?  I
> guess that runSalome and killSalome have to be put under /usr/bin/, I
> can't tell for other binaries.

Same as above, I'll see what happens if they're in a separate directory.

>   * Binary packages seem to contain lots of tests
> (/usr/bin/*[tT][eE][sS][tT]* or /usr/lib/lib*[tT][eE][sS][tT]*), can
> they be dropped?

The plan is to move them into separate test binary packages.

>   * Description of the salome binary package has to be updated, AFAICT
> there is no binary under /usr/bin/salome/

You're right, that will just change to /usr/lib/salome/bin under the
plan you suggested.

>   * salome-common is quite large, are files under
> /usr/share/salome/resources/med/ really needed?  It looks like *.med
> files are already provided by salome-examples.

Good point -- many of those can probably go into the test binary
packages as well.

The test packages are described in the recent discussion on Salome
packaging on the debian-science email list. [1]  The others are errors I
really should have caught before!

-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 (application/pgp-signature, inline)]

Message #375 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Mon, 17 May 2010 12:06:38 +0200

[Message part 1 (text/plain, inline)]

Hi Adam,

Sorry for the lack of news, I was focus on making VISU work.  I have
succeeded to build a Salome package however the current result is
unfortunately split from our development line. That's why I will first
explain my steps and then ask your advice on the merge as I saw that
serious reorganizations are also pending.

My goal is to provide a functional Salome package for mechanical
engineering even if incomplete. As a consequence the necessary modules
are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
in the build process of debian/rules, I decided to build it by hand by
exporting the necessary environment variables. In that case I only had
to modify the gui-build-in-tree.patch (attached to the mail) for making
the libVISU linking work by adding the path to libToolsGUI.
However, back to the complete debian/rules process, the compilation
was still failing in the VISU CONVERTER library because of an absent
template symbol (probably the same problem described in your mail on
the 25th of January). So I needed to investigate the configure and 
build steps of debian/rules but those steps take lot of time. For 
easing my researchs, I decided to work on a package building
only the necessary modules which I called salome-core. The working
snapshot is available here:
http://www.python-science.org/files/salome-core.tar.gz
and I have attached the resulting debian/rules which configure
every module separately. I could not find the problem in the 
previous loop configuration.

From there two questions arise. First, I like the debian/rules file
of salome-core but I remember that you were against such solution for
maintenance reasons. Would you like me to adapt it as a loop or did you
finally change your mind? From now it seems anyway that VISU needs to be
configured separately. Second, could the current salome-core package be
a starting point for the reorganizations that we discussed previously?
For me it has the main advantage to build only the necessary modules,
thus saving time for every run of Salome packaging. However it will 
require to write several packages (salome-advance and salome-dev). 
By comparing to the opencascade package, I understand that the whole
building should be made in a row and the subpackages splitted by 
several *.install files.

...
> > > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
        +          self.CMD=['SALOME_Container','FactoryServerPy']
(I have adapted the patch to the current version.)
...
> I just took care of this, the result is in the alioth git repository.
Thank you for the update. Even if the current version work, I would
prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
'/usr/bin/SALOME_Container' already exists and is finally overwritten in
the install step of debian/rules.

Even if several points still need to be discussed or adapted, the
good point is that we know now how to build a Salome package with the
essential modules. Once again, thank you very much for all your efforts.
I am going to track the remaining bugs at runtime (some menu do not show
up in SMESH, the results can not be seen in VISU).

All the best,

André

[gui-build-in-tree.patch (text/x-diff, attachment)]

[rules (text/plain, attachment)]

Message #380 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 18 May 2010 06:52:27 -0400

[Message part 1 (text/plain, inline)]

Hello André,

Thanks for your work on this, I'm glad it's working.  I'm afraid I won't
have much time to look into your tree, let alone merge the differences,
for a few days, but will get back to you soon.

-Adam

On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote:
> Hi Adam,
> 
> Sorry for the lack of news, I was focus on making VISU work.  I have
> succeeded to build a Salome package however the current result is
> unfortunately split from our development line. That's why I will first
> explain my steps and then ask your advice on the merge as I saw that
> serious reorganizations are also pending.
> 
> My goal is to provide a functional Salome package for mechanical
> engineering even if incomplete. As a consequence the necessary modules
> are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
> in the build process of debian/rules, I decided to build it by hand by
> exporting the necessary environment variables. In that case I only had
> to modify the gui-build-in-tree.patch (attached to the mail) for making
> the libVISU linking work by adding the path to libToolsGUI.
> However, back to the complete debian/rules process, the compilation
> was still failing in the VISU CONVERTER library because of an absent
> template symbol (probably the same problem described in your mail on
> the 25th of January). So I needed to investigate the configure and 
> build steps of debian/rules but those steps take lot of time. For 
> easing my researchs, I decided to work on a package building
> only the necessary modules which I called salome-core. The working
> snapshot is available here:
> http://www.python-science.org/files/salome-core.tar.gz
> and I have attached the resulting debian/rules which configure
> every module separately. I could not find the problem in the 
> previous loop configuration.
> 
> >From there two questions arise. First, I like the debian/rules file
> of salome-core but I remember that you were against such solution for
> maintenance reasons. Would you like me to adapt it as a loop or did you
> finally change your mind? From now it seems anyway that VISU needs to be
> configured separately. Second, could the current salome-core package be
> a starting point for the reorganizations that we discussed previously?
> For me it has the main advantage to build only the necessary modules,
> thus saving time for every run of Salome packaging. However it will 
> require to write several packages (salome-advance and salome-dev). 
> By comparing to the opencascade package, I understand that the whole
> building should be made in a row and the subpackages splitted by 
> several *.install files.
> 
> ...
> > > > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
>         +          self.CMD=['SALOME_Container','FactoryServerPy']
> (I have adapted the patch to the current version.)
> ...
> > I just took care of this, the result is in the alioth git repository.
> Thank you for the update. Even if the current version work, I would
> prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
> '/usr/bin/SALOME_Container' already exists and is finally overwritten in
> the install step of debian/rules.
> 
> Even if several points still need to be discussed or adapted, the
> good point is that we know now how to build a Salome package with the
> essential modules. Once again, thank you very much for all your efforts.
> I am going to track the remaining bugs at runtime (some menu do not show
> up in SMESH, the results can not be seen in VISU).
> 
> All the best,
> 
> André
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[signature.asc (application/pgp-signature, inline)]

Message #385 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Thu, 27 May 2010 18:30:01 +0200

[Message part 1 (text/plain, inline)]

Hello Adam,

I have just succeeded to make a 5.1.3-9 release with VISU, I have
enclosed the 2 patches. I also wanted to let you know that I have
understood the runtime problems of VISU but I need to progress
by steps (my solution is still too messy for being published). I will
first be glad if the -9 release works for you too.

With a fresh sid version, I got a problem on /bin/sh now linked to dash
because autoconf publishes configure scripts with /bin/sh at top but
the KERNEL configure.ac script uses 'function' which is a bash command.
I could not find a solution yet (even by tweaking SHELL and
CONFIG_SHELL). 

Then I wonder if doing a:
    chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/*
is a nice idea because you can not list directories any more. I got
this problem while debugging. I will try to provide a solution on that
point by listing required scripts.

Best regards,

André

> On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote:
> > Hi Adam,
> > 
> > Sorry for the lack of news, I was focus on making VISU work.  I have
> > succeeded to build a Salome package however the current result is
> > unfortunately split from our development line. That's why I will first
> > explain my steps and then ask your advice on the merge as I saw that
> > serious reorganizations are also pending.
> > 
> > My goal is to provide a functional Salome package for mechanical
> > engineering even if incomplete. As a consequence the necessary modules
> > are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
> > in the build process of debian/rules, I decided to build it by hand by
> > exporting the necessary environment variables. In that case I only had
> > to modify the gui-build-in-tree.patch (attached to the mail) for making
> > the libVISU linking work by adding the path to libToolsGUI.
> > However, back to the complete debian/rules process, the compilation
> > was still failing in the VISU CONVERTER library because of an absent
> > template symbol (probably the same problem described in your mail on
> > the 25th of January). So I needed to investigate the configure and 
> > build steps of debian/rules but those steps take lot of time. For 
> > easing my researchs, I decided to work on a package building
> > only the necessary modules which I called salome-core. The working
> > snapshot is available here:
> > http://www.python-science.org/files/salome-core.tar.gz
> > and I have attached the resulting debian/rules which configure
> > every module separately. I could not find the problem in the 
> > previous loop configuration.
> > 
> > >From there two questions arise. First, I like the debian/rules file
> > of salome-core but I remember that you were against such solution for
> > maintenance reasons. Would you like me to adapt it as a loop or did you
> > finally change your mind? From now it seems anyway that VISU needs to be
> > configured separately. Second, could the current salome-core package be
> > a starting point for the reorganizations that we discussed previously?
> > For me it has the main advantage to build only the necessary modules,
> > thus saving time for every run of Salome packaging. However it will 
> > require to write several packages (salome-advance and salome-dev). 
> > By comparing to the opencascade package, I understand that the whole
> > building should be made in a row and the subpackages splitted by 
> > several *.install files.
> > 
> > ...
> > > > > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> >         +          self.CMD=['SALOME_Container','FactoryServerPy']
> > (I have adapted the patch to the current version.)
> > ...
> > > I just took care of this, the result is in the alioth git repository.
> > Thank you for the update. Even if the current version work, I would
> > prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
> > '/usr/bin/SALOME_Container' already exists and is finally overwritten in
> > the install step of debian/rules.
> > 
> > Even if several points still need to be discussed or adapted, the
> > good point is that we know now how to build a Salome package with the
> > essential modules. Once again, thank you very much for all your efforts.
> > I am going to track the remaining bugs at runtime (some menu do not show
> > up in SMESH, the results can not be seen in VISU).
> > 
> > All the best,
> > 
> > André
> -- 
> GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
> 
> Engineering consulting with open source tools
> http://www.opennovation.com/

[visu-building.patch (text/x-diff, attachment)]

[release-5.1.3-9.patch (text/x-diff, attachment)]

Message #390 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Fri, 28 May 2010 13:18:24 -0400

[Message part 1 (text/plain, inline)]

Hello Andre,

I've installed your patches, but still have the same build error:

./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray* VISU::GetIDMapper<VISU::TGetPointData>(VISU::TFieldList*, VISU::TGetPointData, char const*)'
collect2: ld returned 1 exit status

It seems like if the problem were the missing -L...TOOLSGUI then there
would have been a missing library instead of a missing symbol...  But
then, you were able to get it to build with these changes, so there must
be something I don't understand going on here.

I did install your patches in pieces, not all at once, so I may have
missed something.  Can you compare the tree currently in git with your
own, to see if there are some significant differences which would cause
it to not build?

I hope we can get this working soon!

-Adam

On Thu, 2010-05-27 at 18:30 +0200, Andre Espaze wrote:
> Hello Adam,
> 
> I have just succeeded to make a 5.1.3-9 release with VISU, I have
> enclosed the 2 patches. I also wanted to let you know that I have
> understood the runtime problems of VISU but I need to progress
> by steps (my solution is still too messy for being published). I will
> first be glad if the -9 release works for you too.
> 
> With a fresh sid version, I got a problem on /bin/sh now linked to dash
> because autoconf publishes configure scripts with /bin/sh at top but
> the KERNEL configure.ac script uses 'function' which is a bash command.
> I could not find a solution yet (even by tweaking SHELL and
> CONFIG_SHELL). 
> 
> Then I wonder if doing a:
>     chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/*
> is a nice idea because you can not list directories any more. I got
> this problem while debugging. I will try to provide a solution on that
> point by listing required scripts.
> 
> Best regards,
> 
> André
> 
> > On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote:
> > > Hi Adam,
> > > 
> > > Sorry for the lack of news, I was focus on making VISU work.  I have
> > > succeeded to build a Salome package however the current result is
> > > unfortunately split from our development line. That's why I will first
> > > explain my steps and then ask your advice on the merge as I saw that
> > > serious reorganizations are also pending.
> > > 
> > > My goal is to provide a functional Salome package for mechanical
> > > engineering even if incomplete. As a consequence the necessary modules
> > > are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
> > > in the build process of debian/rules, I decided to build it by hand by
> > > exporting the necessary environment variables. In that case I only had
> > > to modify the gui-build-in-tree.patch (attached to the mail) for making
> > > the libVISU linking work by adding the path to libToolsGUI.
> > > However, back to the complete debian/rules process, the compilation
> > > was still failing in the VISU CONVERTER library because of an absent
> > > template symbol (probably the same problem described in your mail on
> > > the 25th of January). So I needed to investigate the configure and 
> > > build steps of debian/rules but those steps take lot of time. For 
> > > easing my researchs, I decided to work on a package building
> > > only the necessary modules which I called salome-core. The working
> > > snapshot is available here:
> > > http://www.python-science.org/files/salome-core.tar.gz
> > > and I have attached the resulting debian/rules which configure
> > > every module separately. I could not find the problem in the 
> > > previous loop configuration.
> > > 
> > > >From there two questions arise. First, I like the debian/rules file
> > > of salome-core but I remember that you were against such solution for
> > > maintenance reasons. Would you like me to adapt it as a loop or did you
> > > finally change your mind? From now it seems anyway that VISU needs to be
> > > configured separately. Second, could the current salome-core package be
> > > a starting point for the reorganizations that we discussed previously?
> > > For me it has the main advantage to build only the necessary modules,
> > > thus saving time for every run of Salome packaging. However it will 
> > > require to write several packages (salome-advance and salome-dev). 
> > > By comparing to the opencascade package, I understand that the whole
> > > building should be made in a row and the subpackages splitted by 
> > > several *.install files.
> > > 
> > > ...
> > > > > > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> > >         +          self.CMD=['SALOME_Container','FactoryServerPy']
> > > (I have adapted the patch to the current version.)
> > > ...
> > > > I just took care of this, the result is in the alioth git repository.
> > > Thank you for the update. Even if the current version work, I would
> > > prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
> > > '/usr/bin/SALOME_Container' already exists and is finally overwritten in
> > > the install step of debian/rules.
> > > 
> > > Even if several points still need to be discussed or adapted, the
> > > good point is that we know now how to build a Salome package with the
> > > essential modules. Once again, thank you very much for all your efforts.
> > > I am going to track the remaining bugs at runtime (some menu do not show
> > > up in SMESH, the results can not be seen in VISU).
> > > 
> > > All the best,
> > > 
> > > André
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[signature.asc (application/pgp-signature, inline)]

Message #395 received at 457075-close@bugs.debian.org (full text, mbox, reply):

From: hazelsct@debian.org (Adam C. Powell, IV)

To: 457075-close@bugs.debian.org

Subject: Bug#457075: fixed in salome 5.1.3-8

Date: Mon, 31 May 2010 19:34:20 +0000

Source: salome
Source-Version: 5.1.3-8

We believe that the bug you reported is fixed in the latest version of
salome, which is due to be installed in the Debian FTP archive:

libsalome-dev_5.1.3-8_all.deb
  to contrib/s/salome/libsalome-dev_5.1.3-8_all.deb
libsalome5.1.3-0_5.1.3-8_amd64.deb
  to contrib/s/salome/libsalome5.1.3-0_5.1.3-8_amd64.deb
python2.5-salome_5.1.3-8_amd64.deb
  to contrib/s/salome/python2.5-salome_5.1.3-8_amd64.deb
salome-common_5.1.3-8_all.deb
  to contrib/s/salome/salome-common_5.1.3-8_all.deb
salome-examples_5.1.3-8_all.deb
  to contrib/s/salome/salome-examples_5.1.3-8_all.deb
salome_5.1.3-8.debian.tar.gz
  to contrib/s/salome/salome_5.1.3-8.debian.tar.gz
salome_5.1.3-8.dsc
  to contrib/s/salome/salome_5.1.3-8.dsc
salome_5.1.3-8_amd64.deb
  to contrib/s/salome/salome_5.1.3-8_amd64.deb
salome_5.1.3.orig.tar.gz
  to contrib/s/salome/salome_5.1.3.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 457075@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Adam C. Powell, IV <hazelsct@debian.org> (supplier of updated salome package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 07 May 2010 07:18:21 -0400
Source: salome
Binary: salome salome-common python2.5-salome libsalome5.1.3-0 libsalome-dev salome-examples
Architecture: source amd64 all
Version: 5.1.3-8
Distribution: unstable
Urgency: low
Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Adam C. Powell, IV <hazelsct@debian.org>
Description: 
 libsalome-dev - Numerical simulation pre- and post-processor development files
 libsalome5.1.3-0 - Numerical simulation pre- and post-processor development files
 python2.5-salome - Numerical simulation pre- and post-processor
 salome     - Numerical simulation pre- and post-processor
 salome-common - Numerical simulation pre- and post-processor
 salome-examples - Numerical simulation pre- and post-processor documentation
Closes: 457075
Changes: 
 salome (5.1.3-8) unstable; urgency=low
 .
   * Removed the salome-doc binary package to cut disk space use dramatically.
   * Moved SALOME_ContainerPy.py back to /usr/bin and dropped the Py.py ending.
   * Moved SALOME_Container and other python scripts to python2.5-salome.
   * Made python2.5-salome conflict with old salome because of this.
   * Stripped .sh from shell script file names in /usr/bin .
 .
 salome (5.1.3-7) unstable; urgency=low
 .
   * Added quilt Build-Dependency.
 .
 salome (5.1.3-6) unstable; urgency=low
 .
   [ Andre Espaze ]
   * Added libsalome-dev dependency to salome, as it's necessary for now.
   * Added LD_LIBRARY_PATH setting to runSalome.in.
 .
   [ Gerber van der Graaf ]
   * Menu entry in salome.menu file.
 .
   [ Adam C. Powell, IV ]
   * Removed modules: VISU doesn't build, SIERPINSKY depends on it, NETGENPLUGIN
     but requires significant updates to work with Debian's 4.9.x package.
   * Revamped rules so build-arch/install-arch/binary-arch doesn't do all of the
     documentation building.
   * Un-did some of Andre's changes regarding python file permissions and .awk
     and .tgz file locations.
   * New salome.desktop file for Applications menu entry.
   * Added quilt pop -a and removal of .pc to debian/rules clean target.
   * Added libopencascade-visualization-dev dependency to salome.
   * Patched runSalome.py to not require executable .py files.
   * Changed to omniidl[-python] Build-Dep reflecting unstable name change.
   * Changed control file encoding to UTF-8.
   * First upload (closes: #457075).
 .
 salome (5.1.3-5) unstable; urgency=low
 .
   * Python 2.5/2.6 installation flexibility to build on Ubuntu Karmic.
   * New modules: NETGENPLUGIN, YACS, MULTIPR, LIGHT, PYLIGHT.
   * Started module XDATA, need to finish fixing very broken clean target.
   * Generalize MPI usage away from OpenMPI-only.
   * Fixed the runSalome script UnitsAPI directory location, added DISABLE_FPE=1
     so the GEOM module works properly, and added new module root dirs.
   * Fixed the killSalome script by making it config-able.
   * Updated install target in rules.
   * Changed salome-common dependency on salome to Recommends.
   * Removed .la files from -dev package.
   * Added ${misc:Depends} to all package dependencies.
   * Corrected debhelper and python-central Build-Depends etc.
   * Bumped Standards-Version.
 .
 salome (5.1.3-4) unstable; urgency=low
 .
   * Team maintenance by debian-science.
   * Complete source code copyright audit by Gerber van der Graaf, updated
     copyright and included all of his analysis in the copyright-audit
     directory.
   * New modules: COMPONENT, CALCULATOR, PYCALCULATOR, SIERPINSKY.
   * Started module NETGENPLUGIN, need libnetgen-dev B-D and possibly patches.
   * Tell salome about new VTK 5.4.
   * Fixed Makefile clean targets so the tree goes back to its original state.
   * Updated OpenCascade detection to include data files.
 .
 salome (5.1.3-3) unstable; urgency=low
 .
   * New modules: RANDOMIZER, HELLO, PYHELLO, VISU, SMESH.
   * All patches are now upstream-ready except kernel-mpi-libs which is
     Debian-specific.
 .
 salome (5.1.3-2) unstable; urgency=low
 .
   * New modules: GUI, GEOM, MED.
   * Lots of new patches and Build-Depends!
   * Removed patch-stamp and unpatch targets since source format 3.0 takes care
     of that.
 .
 salome (5.1.3-1) unstable; urgency=low
 .
   * New upstream release.
   * Starting simple -- just builds two modules for now.
   * Switch to dpkg-source 3.0 (quilt) format.
   * Bumped Standards-Version.
   * Changed approach to HDF5/MPI linkage.
   * Started backporting patches -- thankfully some are already in upstream.
 .
 salome (3.2.6-7) unstable; urgency=low
 .
   * Fixed sip by a QT_VERS change.
   * Fixed netgen plugin link directory problem.
   * Added automake to xdata configure target.
   * Using python-central properly for python2.4-salome and salome-xdata.
   * Lots of cleanups inspired by lintian.
 .
 salome (3.2.6-6) unstable; urgency=low
 .
   * OmniORB 4.1.x port has no known build bugs now (thanks: Thomas Girard).
   * Added build-deps python-qt-dev, sip4, python-sip4-dev, and libvtk5-qt3-dev.
   * Created Build-Conflicts against other MPI implementations.
 .
 salome (3.2.6-5) unstable; urgency=low
 .
   * New patch porting to omniORB 4.1.x (thanks: Thomas Girard).
 .
 salome (3.2.6-4) unstable; urgency=low
 .
   * Added NETGENPLUGIN module (required considerable hacking).
   * Changed libdev package to arch all because it is.
   * Concatenated .m4 files into salome.m4 for libdev package.
   * Moved IDL files to /usr/share/idl/salome.
   * Added new salome-xdata package.
   * Added examples package with content from SAMPLES directory.
   * Added more inter-package dependencies.
   * Added the CASROOT valiable and three derivatives to the runSalome script.
   * A new README.Debian.html file explains the package and gives a TODO list.
   * Added bindir=/usr/bin to avoid having stuff in /usr/bin/salome.
   * Removed the $bindir/appliskel and $bindir/styles directories.
   * Removed executable bit on xdata .png and .qm resources files.
   * New docs generated by "make usr_docs" and "make dev_docs".
 .
 salome (3.2.6-3) unstable; urgency=low
 .
   * Ported the VISU and SMESH modules to VTK 5.
   * Completed packaging for the VISU and SMESH modules.
   * Removed the GetPropagationSource() method from the StdMeshers_Propagation
     class because it causes a link relocation error (why??).
   * Added gfortran and libboost-signals-dev to Build-Depends.
   * Completed building of packages conforming to FHS standard.
   * Added _ROOT_DIR and PYTHONPATH variables to runSalome script.
   * Made a link /usr/bin/runSalome to /usr/bin/salome/runSalome.
   * Added a salome-common package for the resources.
 .
 salome (3.2.6-2) unstable; urgency=low
 .
   * Patched KERNEL OpenCASCADE, MPI and HDF5 .m4 files for Debian.
   * Fixed many C++ headers to include hdf5 without extern "C", and before med.
   * Hacked KERNEL_SRC_3.2.6/src/Communication/SALOME_Comm_i.hxx to
     include missing #defines needed by ios_base.h (is this a compiler bug?).
   * Set libdir=/usr/lib.
   * Added general packaging for all of the modules.
   * Omitting NETGENPLUGIN for now because interface seems to have changed.
   * Omitting GHS3DPLUGIN because it is non-free.
   * Patched all modules' missing DESTDIR support.
   * Fixed all modules' deprecated file references.
   * Removed all modules' extraneous aclocal.m4 target dependencies.
   * Fixed several modules' incorrect KERNEL IDL directory settings.
   * Fixed all modules' erroneous creation of salome_adm directories, which
     prevents the proper link from forming.
   * Removed modules' copying adm_local to builddir because we build in place.
   * Hacked GUI, GEOM and SMESH modules' check functions so configuring all
     modules before building them all works.
   * Fixed MED, RANDOMIZER and VISU modules' check functions.
   * Patched modules so they can include headers and link to libs in place.
   * Fixed executables' linking to properly use libtool --mode=link.
   * Fixed modules' makefiles to install to proper libdir.
   * Ported GUI module to VTK 5 and sip 4.7.
   * Added missing sources explicitly to Makefile.in to get around a make bug.
   * Fixed MED for Debian libmed-dev compatibility and header completeness.
   * Added KERNEL variables to the PY* modules' makefiles.
 .
 salome (3.2.6-1) unstable; urgency=low
 .
   * First Debianization of Salomé.
   * Needs to use MPI prefix for HDF5 prefix because HDF5 test comes first
     (i.e. upstream assumes that HDF5 is independent of MPI).
   * Patches configure to include -lmpi++ in MPI_LIBS and properly specify
     the Debian location of OpenCASCADE headers.
Checksums-Sha1: 
 0003f19fbdb1dc75cc9d049c96f447ee5ba9dc22 2144 salome_5.1.3-8.dsc
 643c775f90277314983747e002918ee5b826db90 106470135 salome_5.1.3.orig.tar.gz
 74fb7e7297c1dad78c5307e7a9128e567b7ac154 56425 salome_5.1.3-8.debian.tar.gz
 472323433309325e1768e202c744bccdc117e177 7514196 salome_5.1.3-8_amd64.deb
 ff535e5ba3a460678f4fcba947ecd3817bc57437 6810028 python2.5-salome_5.1.3-8_amd64.deb
 9389c0db4d96477315e6232604902369587e4b6b 26579684 libsalome5.1.3-0_5.1.3-8_amd64.deb
 1529d1bf53881c86eb2d6ea27fe2cb118a83af65 25126512 salome-common_5.1.3-8_all.deb
 5ffdc02736965f55c6a27caab826ba1cbc6a636d 1746780 libsalome-dev_5.1.3-8_all.deb
 e1c0af5d4b9dd8f365ec72dc1ce9fa6ee2dcafe9 39945956 salome-examples_5.1.3-8_all.deb
Checksums-Sha256: 
 fc0613acf67f25164cfac29dbe6b133daba1a0f8928bffbb5b60889c6e82b651 2144 salome_5.1.3-8.dsc
 78ce2acc9cfa474e030723674f4420c420fd2de926b1939455c3716f1fd48a2b 106470135 salome_5.1.3.orig.tar.gz
 c4d67a537a05c4cb7aa7903faeec314687191460e2e4dab7e82936819b4930eb 56425 salome_5.1.3-8.debian.tar.gz
 5847bca117075bba445ae72a1404d9084f794c04dad0a5d755faeabdabf6f6fc 7514196 salome_5.1.3-8_amd64.deb
 59e217f714743519a0ea21903ff007542cefbbb29280b4c908cabc95d9b81761 6810028 python2.5-salome_5.1.3-8_amd64.deb
 65d73c9b0729ddc6fc2eb08f03f42715411a58f691c5851da3d4de0eff9f6c3b 26579684 libsalome5.1.3-0_5.1.3-8_amd64.deb
 7ee0df2b9e80d4f8d9312c574b4e2b887589e13e86c98f18629a582a1f30c0e3 25126512 salome-common_5.1.3-8_all.deb
 d3c138845af4ec00f7aafffa6a37609760f399f099f3521953c6d5750768a47e 1746780 libsalome-dev_5.1.3-8_all.deb
 f63bdf95ad446d11aedf7459c649416a5577b92ef7b9076914896966673581f0 39945956 salome-examples_5.1.3-8_all.deb
Files: 
 dbecdc78e9b8bf8b5dbfe0b8b9b458fd 2144 contrib/science extra salome_5.1.3-8.dsc
 8564d0a7ef94d4d6d4b4c82ade84b1b0 106470135 contrib/science extra salome_5.1.3.orig.tar.gz
 232bddf39caa5131ce50fc9848c6c3c2 56425 contrib/science extra salome_5.1.3-8.debian.tar.gz
 8ac7c3800136106132325b8adb8daed3 7514196 contrib/science extra salome_5.1.3-8_amd64.deb
 2434928e365ab40595efc2617657eb4a 6810028 contrib/python extra python2.5-salome_5.1.3-8_amd64.deb
 99e0c274577e2d8c382d94fb6fe90572 26579684 contrib/libs extra libsalome5.1.3-0_5.1.3-8_amd64.deb
 636a6defc5640651f52f4245321a092c 25126512 contrib/science extra salome-common_5.1.3-8_all.deb
 bc831969163f1e25ac96313abb24025d 1746780 contrib/libdevel extra libsalome-dev_5.1.3-8_all.deb
 3707aa14110cc88675d3c79feed925f2 39945956 contrib/doc extra salome-examples_5.1.3-8_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvkTs0ACgkQUm8B6FZO5LbHBgCeNG/WR4q7XQMZ9Jsrns2iI32t
bgQAnRndBEVnfll5nOBKlFnKOCr84LJh
=k4p+
-----END PGP SIGNATURE-----

Message #400 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 1 Jun 2010 10:53:29 +0200

Hi Adam,
> 
> I've installed your patches, but still have the same build error:
> 
> ./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray* VISU::GetIDMapper<VISU::TGetPointData>(VISU::TFieldList*, VISU::TGetPointData, char const*)'
> collect2: ld returned 1 exit status
> 
> It seems like if the problem were the missing -L...TOOLSGUI then there
> would have been a missing library instead of a missing symbol...  But
> then, you were able to get it to build with these changes, so there must
> be something I don't understand going on here.
> 
> I did install your patches in pieces, not all at once, so I may have
> missed something.  Can you compare the tree currently in git with your
> own, to see if there are some significant differences which would cause
> it to not build?
I feel really sorry for the wrong patch that I sent you, the reason
is that I forgot to add the CXXFLAGS="-g" in the configure command, I was
building VISU without optimizations. I hope that I did not make you
loose too much time. Since my last successful build, I have looked
deeper into the problem and I found that g++ inline small template
function with -O2. Here I imitate the GetIDMapper definition found in
src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705:

    $ cat test.cpp
    class Data{
    };

    template <class TData>
    void
    GetIDMapper(TData data)
    {
    }

    void test(void)
    {
        GetIDMapper(Data());
    }

When compiling without optimizations, the GetIDMapper symbol is built:

    $ g++ -c test.cpp && readelf -s test.o | grep GetIDMapper
    ... _Z11GetIDMapperI4DataEvT_

However -O2 will inline the template function:

    $ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper

For not loosing optimizations on the whole build, I have finally
found that I can control g++:
 
    $ cat test.cpp
    class Data{
    };

    template <class TData>
    __attribute__((noinline))
    void
    GetIDMapper(TData data)
    {
    }

    void test(void)
    {
        GetIDMapper(Data());
    }
    $ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper
    ... _Z11GetIDMapperI4DataEvT_

So the good new is that I will provide a VISU patch and we can again
configure VISU in the for loop of debian/rules. Will it be possible
to reset the last commit? I deeply apologize for my mistake.  For not
reproducing the same problem, I am going to build a new Salome version
and send you patches carefully once everything works.
By the way, is the 'git-builpackage' command that exports CXXFLAGS
to '-O2 -g'? I could not yet understand that step.

Best regards,

André

> On Thu, 2010-05-27 at 18:30 +0200, Andre Espaze wrote:
> > Hello Adam,
> > 
> > I have just succeeded to make a 5.1.3-9 release with VISU, I have
> > enclosed the 2 patches. I also wanted to let you know that I have
> > understood the runtime problems of VISU but I need to progress
> > by steps (my solution is still too messy for being published). I will
> > first be glad if the -9 release works for you too.
> > 
> > With a fresh sid version, I got a problem on /bin/sh now linked to dash
> > because autoconf publishes configure scripts with /bin/sh at top but
> > the KERNEL configure.ac script uses 'function' which is a bash command.
> > I could not find a solution yet (even by tweaking SHELL and
> > CONFIG_SHELL). 
> > 
> > Then I wonder if doing a:
> >     chmod -x debian/tmp/usr/lib/python2.5/*-packages/salome/*
> > is a nice idea because you can not list directories any more. I got
> > this problem while debugging. I will try to provide a solution on that
> > point by listing required scripts.
> > 
> > Best regards,
> > 
> > André
> > 
> > > On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote:
> > > > Hi Adam,
> > > > 
> > > > Sorry for the lack of news, I was focus on making VISU work.  I have
> > > > succeeded to build a Salome package however the current result is
> > > > unfortunately split from our development line. That's why I will first
> > > > explain my steps and then ask your advice on the merge as I saw that
> > > > serious reorganizations are also pending.
> > > > 
> > > > My goal is to provide a functional Salome package for mechanical
> > > > engineering even if incomplete. As a consequence the necessary modules
> > > > are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing
> > > > in the build process of debian/rules, I decided to build it by hand by
> > > > exporting the necessary environment variables. In that case I only had
> > > > to modify the gui-build-in-tree.patch (attached to the mail) for making
> > > > the libVISU linking work by adding the path to libToolsGUI.
> > > > However, back to the complete debian/rules process, the compilation
> > > > was still failing in the VISU CONVERTER library because of an absent
> > > > template symbol (probably the same problem described in your mail on
> > > > the 25th of January). So I needed to investigate the configure and 
> > > > build steps of debian/rules but those steps take lot of time. For 
> > > > easing my researchs, I decided to work on a package building
> > > > only the necessary modules which I called salome-core. The working
> > > > snapshot is available here:
> > > > http://www.python-science.org/files/salome-core.tar.gz
> > > > and I have attached the resulting debian/rules which configure
> > > > every module separately. I could not find the problem in the 
> > > > previous loop configuration.
> > > > 
> > > > >From there two questions arise. First, I like the debian/rules file
> > > > of salome-core but I remember that you were against such solution for
> > > > maintenance reasons. Would you like me to adapt it as a loop or did you
> > > > finally change your mind? From now it seems anyway that VISU needs to be
> > > > configured separately. Second, could the current salome-core package be
> > > > a starting point for the reorganizations that we discussed previously?
> > > > For me it has the main advantage to build only the necessary modules,
> > > > thus saving time for every run of Salome packaging. However it will 
> > > > require to write several packages (salome-advance and salome-dev). 
> > > > By comparing to the opencascade package, I understand that the whole
> > > > building should be made in a row and the subpackages splitted by 
> > > > several *.install files.
> > > > 
> > > > ...
> > > > > > > > -          self.CMD=['SALOME_ContainerPy.py','FactoryServerPy']
> > > >         +          self.CMD=['SALOME_Container','FactoryServerPy']
> > > > (I have adapted the patch to the current version.)
> > > > ...
> > > > > I just took care of this, the result is in the alioth git repository.
> > > > Thank you for the update. Even if the current version work, I would
> > > > prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because
> > > > '/usr/bin/SALOME_Container' already exists and is finally overwritten in
> > > > the install step of debian/rules.
> > > > 
> > > > Even if several points still need to be discussed or adapted, the
> > > > good point is that we know now how to build a Salome package with the
> > > > essential modules. Once again, thank you very much for all your efforts.
> > > > I am going to track the remaining bugs at runtime (some menu do not show
> > > > up in SMESH, the results can not be seen in VISU).
> > > > 
> > > > All the best,
> > > > 
> > > > André
> -- 
> GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6
> 
> Engineering consulting with open source tools
> http://www.opennovation.com/

Message #405 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Adam C Powell IV <hazelsct@debian.org>

To: Andre Espaze <andre.espaze@logilab.fr>, 457075@bugs.debian.org

Cc: alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Tue, 01 Jun 2010 18:48:49 -0400

[Message part 1 (text/plain, inline)]

Hello Andre,

First, some great news: Salomé was accepted into unstable!  Now we can
file multiple independent bugs and track all of these issues separately.

On Tue, 2010-06-01 at 10:53 +0200, Andre Espaze wrote:
> Hi Adam,
> > 
> > I've installed your patches, but still have the same build error:
> > 
> > ./.libs/libVisuConvertor.so: undefined reference to `vtkIntArray* VISU::GetIDMapper<VISU::TGetPointData>(VISU::TFieldList*, VISU::TGetPointData, char const*)'
> > collect2: ld returned 1 exit status
> > 
> > It seems like if the problem were the missing -L...TOOLSGUI then there
> > would have been a missing library instead of a missing symbol...  But
> > then, you were able to get it to build with these changes, so there must
> > be something I don't understand going on here.
> > 
> > I did install your patches in pieces, not all at once, so I may have
> > missed something.  Can you compare the tree currently in git with your
> > own, to see if there are some significant differences which would cause
> > it to not build?
> I feel really sorry for the wrong patch that I sent you, the reason
> is that I forgot to add the CXXFLAGS="-g" in the configure command, I was
> building VISU without optimizations. I hope that I did not make you
> loose too much time.

Aha!  That makes a lot of sense.  Don't worry, it didn't take me a lot
of time to rebuild the package a couple of times.

But this suggests that it might be best to compile only that file using
-g so the rest of VISU can still be optimized.  What do you think?

> Since my last successful build, I have looked
> deeper into the problem and I found that g++ inline small template
> function with -O2. Here I imitate the GetIDMapper definition found in
> src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705:
> 
>     $ cat test.cpp
>     class Data{
>     };
> 
>     template <class TData>
>     void
>     GetIDMapper(TData data)
>     {
>     }
> 
>     void test(void)
>     {
>         GetIDMapper(Data());
>     }
> 
> When compiling without optimizations, the GetIDMapper symbol is built:
> 
>     $ g++ -c test.cpp && readelf -s test.o | grep GetIDMapper
>     ... _Z11GetIDMapperI4DataEvT_
> 
> However -O2 will inline the template function:
> 
>     $ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper
> 
> For not loosing optimizations on the whole build, I have finally
> found that I can control g++:
>  
>     $ cat test.cpp
>     class Data{
>     };
> 
>     template <class TData>
>     __attribute__((noinline))
>     void
>     GetIDMapper(TData data)
>     {
>     }
> 
>     void test(void)
>     {
>         GetIDMapper(Data());
>     }
>     $ g++ -O2 -c test.cpp && readelf -s test.o | grep GetIDMapper
>     ... _Z11GetIDMapperI4DataEvT_

Very interesting!  It sounds like with a lot of hard work you've found
an important g++ optimization bug...

> So the good new is that I will provide a VISU patch and we can again
> configure VISU in the for loop of debian/rules. Will it be possible
> to reset the last commit? I deeply apologize for my mistake.  For not
> reproducing the same problem, I am going to build a new Salome version
> and send you patches carefully once everything works.

Sounds good, thank you.

> By the way, is the 'git-builpackage' command that exports CXXFLAGS
> to '-O2 -g'? I could not yet understand that step.

I believe dpkg-buildpackage sets those flags.  But it should be possible
to set them locally within debian/rules or Makefile.am.

Regards,
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 (application/pgp-signature, inline)]

Message #410 received at 457075@bugs.debian.org (full text, mbox, reply):

From: Andre Espaze <andre.espaze@logilab.fr>

To: Adam C Powell IV <hazelsct@debian.org>

Cc: 457075@bugs.debian.org, alf@logilab.fr, Sylvestre Ledru <sylvestre.ledru@inria.fr>, nico@logilab.fr, dmitrij.ledkov@ubuntu.com, Gerber van der Graaf <gerber.vdgraaf@gmail.com>

Subject: Re: Bug#457075: Salomé packaging

Date: Wed, 2 Jun 2010 11:56:38 +0200

[Message part 1 (text/plain, inline)]

Hello Adam,
> 
> First, some great news: Salomé was accepted into unstable!  Now we can
> file multiple independent bugs and track all of these issues separately.
Excellent! I am really glad to hear it.
> 
> > I feel really sorry for the wrong patch that I sent you, the reason
> > is that I forgot to add the CXXFLAGS="-g" in the configure command, I was
> > building VISU without optimizations. I hope that I did not make you
> > loose too much time.
> 
> Aha!  That makes a lot of sense.  Don't worry, it didn't take me a lot
> of time to rebuild the package a couple of times.
> 
> But this suggests that it might be best to compile only that file using
> -g so the rest of VISU can still be optimized.  What do you think?
In fact g++ can be controlled on function inlining.
> 
> > Since my last successful build, I have looked
> > deeper into the problem and I found that g++ inline small template
> > function with -O2. Here I imitate the GetIDMapper definition found in
> > src/CONVERTOR/VISU_MergeFilterUtilities.cxx:705:
...
> 
> Very interesting!  It sounds like with a lot of hard work you've found
> an important g++ optimization bug...
I am not sure if it is a bug. I guess that template function inlining
should be controlled when optimizing. I have enclosed you a tested patch
for removing template function inlining of GetIDMapper but it should be
applied after the commit:

    f57b74db488c91754eadbca263c065ff2022ac71
    Thu May 27 21:56:53 2010 -0400
    Timestamp the changelog

It means that the last commit should be reverted. I made a successful
build of Salome with VISU by using the corresponding Debian rules 
(that I have enclosed in case you would like to check) but you will
see that VISU is configured in the for loop like others modules.

Finally I have sent my patch to bug 584172 where a better solution
has already been suggested by Denis but requires a new complete build.
Now I will try to improve the package organizations and wait for 
your Salome bug entries on which I can help.

> 
> > By the way, is the 'git-builpackage' command that exports CXXFLAGS
> > to '-O2 -g'? I could not yet understand that step.
> 
> I believe dpkg-buildpackage sets those flags.  But it should be possible
> to set them locally within debian/rules or Makefile.am.
Thank you for the explanation, I have just discovered dpkg-buildflags
used by dpkg-buildpackage:

    $ dpkg-buildflags --get CXXFLAGS
    -g -O2

Best regards,

André

[no-template-function-inline.patch (text/x-diff, attachment)]

[rules (text/plain, attachment)]

Send a report that this bug log contains spam.