Re: [galaxy-dev] atlas version 3.10.2 installation error

[Peter Cock]

Good news: With Marius' help Biopython 1.67 should be in bioconda
shortly, https://github.com/bioconda/bioconda-recipes/pull/4462

That means any Galaxy package using Biopython needing/wanting
to work under both the legacy XML packaging system and bioconda
will be able to point at Biopython 1.67.

The newer Biopython releases are only in bioconda (and right now,
I have no compelling reason to write new legacy XML packages for
them).

Likewise any Galaxy package using NCBI BLAST+ needing/wanting
to work under both the legacy XML packaging system and bioconda
will be able to point at BLAST+ 2.5.0.

Peter

On Wed, Apr 19, 2017 at 1:17 PM, Peter Cock  wrote:
> I've emailed the rest of the IUC for their input - adding the old versions
> in bioconda should work, or adding the recent Biopython releases as packages
> on the Tool Shed.
>
> For blast_rbh just need a semi-recent Biopython available in both systems
> (until everyone moves over to bioconda - we've not yet done this on our
> local Galaxy for example).
>
> Peter
>
> Peter
>
> On Wed, 19 Apr 2017 at 13:04, Matthias Bernt  wrote:
>>
>> Dear Peter,
>>
>> thanks. Just for understanding: Why not just change the biopython
>> dependency from 1.67 to 1.69, if this is the one available in bioconda.
>> blast_rbh seems to use only the SeqIO fasta parser and writer. This
>> should be no problem.
>>
>> But I guess that for older versions of blast_rbh one might still need
>> legacy packages of biopython. Or could one change the dependencies in
>> older versions? Or would this be no good idea because of backward
>> compatibility?
>>
>> Cheers,
>> Matthias
>>
>>
>>
>>
>>
>> On 19.04.2017 13:50, Peter Cock wrote:
>> > Just lucky timing, could you try blast_rbh v0.1.11,
>> >
>> > https://toolshed.g2.bx.psu.edu/view/peterjc/blast_rbh/d8d9a9069586
>> >
>> > For BLAST+ this ought to work with either bioconda, or the legacy XML
>> > based packages, as both have BLAST+ 2.5.0.
>> >
>> > However, it looks like bioconda only has Biopython 1.68 and 1.69, while
>> > the legacy XML based packages only go up to Biopython 1.67 at the time
>> > of writing... it looks like we'll need to add a couple more legacy
>> > packages.
>> >
>> > Peter
>> >
>> > On Wed, Apr 19, 2017 at 12:01 PM, Matthias Bernt  wrote:
>> >> Dear Peter,
>> >>
>> >> thanks for the info. Would be great to get the update, but since I have
>> >> a
>> >> method that is working for the moment there is no need to hurry.
>> >>
>> >> Best,
>> >> Matthias
>> >>
>> >>
>> >>
>> >> On 19.04.2017 12:57, Peter Cock wrote:
>> >>>
>> >>> Oh right - I've just been updating ncbi_blast_plus this morning
>> >>> to transition to BLAST+ 2.5.0 via either bioconda or the older
>> >>> legacy Tool Shed.
>> >>>
>> >>> I can try to update blast_rbh next, which may solve this by
>> >>> letting you use bioconda.
>> >>>
>> >>> Peter
>> >>>
>> >>> On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt 
>> >>> wrote:
>> 
>>  Dear Marius,
>> 
>>  thanks again for the help. I'm trying to install blast_rbh (owner is
>>  peterjc). The dependencies look as follows:
>> 
>>  blast_rbh
>>  - biopython
>>    - package_biopython_1_64
>>  - package_numpy_1_8
>>    - package_atlas_3_10
>>  - blast
>>  - package_blast_plus_2_2_31
>>    - blast+
>> 
>>  With unchecked "When available, install Tool Shed managed tool
>>  dependencies?" I get all as "Installed, missing tool dependencies".
>>  Blast_rbh is not working since blast+ is not installed. Even if I
>>  install
>>  blast+ manually (in galaxy) its not working (makeblastdb is missing).
>> 
>>  When I leave "When available, install Tool Shed managed tool
>>  dependencies?"
>>  I see blast_rbh, package_blast_plus package_biopython as installed
>>  and
>>  the
>>  others as Installed, missing tool dependencies.
>>  Here blast_rbh is working.
>> 
>>  What would be your suggestion? Live with the latter and file an issue
>>  at
>>  the
>>  tools repository (difficult to say which causes the problem(s))?
>> 
>>  I get similar behavior if I try to install from the test toolshed.
>>  (Only a different error from atlas: /bin/sh: line 3:
>>  /host/static_full_blas_lapack.diff: No such file or directory).
>> 
>>  But, actually I'm trying to automatize tool installation using the
>>  ansible
>>  role ansible-galaxy-tools
>>  (https://github.com/galaxyproject/ansible-galaxy-tools). With this
>>  method
>>  I
>>  get the latter behavior. The role uses uses ephemeris==0.4.0 to
>>  install
>>  tools. There I have seen three global variables that (I guess)
>>  control
>>  the
>>  installation of dependencies.
>> 
>>  INSTALL_TOOL_DEPENDENCIES = False
>>  INSTALL_REPOSITORY_DEPENDENCIES = True
>>  INSTALL_RESOLVER_DEPENDENCIES = 

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Peter Cock]

I've emailed the rest of the IUC for their input - adding the old versions
in bioconda should work, or adding the recent Biopython releases as
packages on the Tool Shed.

For blast_rbh just need a semi-recent Biopython available in both systems
(until everyone moves over to bioconda - we've not yet done this on our
local Galaxy for example).

Peter

Peter

On Wed, 19 Apr 2017 at 13:04, Matthias Bernt  wrote:

> Dear Peter,
>
> thanks. Just for understanding: Why not just change the biopython
> dependency from 1.67 to 1.69, if this is the one available in bioconda.
> blast_rbh seems to use only the SeqIO fasta parser and writer. This
> should be no problem.
>
> But I guess that for older versions of blast_rbh one might still need
> legacy packages of biopython. Or could one change the dependencies in
> older versions? Or would this be no good idea because of backward
> compatibility?
>
> Cheers,
> Matthias
>
>
>
>
>
> On 19.04.2017 13:50, Peter Cock wrote:
> > Just lucky timing, could you try blast_rbh v0.1.11,
> >
> > https://toolshed.g2.bx.psu.edu/view/peterjc/blast_rbh/d8d9a9069586
> >
> > For BLAST+ this ought to work with either bioconda, or the legacy XML
> > based packages, as both have BLAST+ 2.5.0.
> >
> > However, it looks like bioconda only has Biopython 1.68 and 1.69, while
> > the legacy XML based packages only go up to Biopython 1.67 at the time
> > of writing... it looks like we'll need to add a couple more legacy
> packages.
> >
> > Peter
> >
> > On Wed, Apr 19, 2017 at 12:01 PM, Matthias Bernt  wrote:
> >> Dear Peter,
> >>
> >> thanks for the info. Would be great to get the update, but since I have
> a
> >> method that is working for the moment there is no need to hurry.
> >>
> >> Best,
> >> Matthias
> >>
> >>
> >>
> >> On 19.04.2017 12:57, Peter Cock wrote:
> >>>
> >>> Oh right - I've just been updating ncbi_blast_plus this morning
> >>> to transition to BLAST+ 2.5.0 via either bioconda or the older
> >>> legacy Tool Shed.
> >>>
> >>> I can try to update blast_rbh next, which may solve this by
> >>> letting you use bioconda.
> >>>
> >>> Peter
> >>>
> >>> On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt 
> wrote:
> 
>  Dear Marius,
> 
>  thanks again for the help. I'm trying to install blast_rbh (owner is
>  peterjc). The dependencies look as follows:
> 
>  blast_rbh
>  - biopython
>    - package_biopython_1_64
>  - package_numpy_1_8
>    - package_atlas_3_10
>  - blast
>  - package_blast_plus_2_2_31
>    - blast+
> 
>  With unchecked "When available, install Tool Shed managed tool
>  dependencies?" I get all as "Installed, missing tool dependencies".
>  Blast_rbh is not working since blast+ is not installed. Even if I
> install
>  blast+ manually (in galaxy) its not working (makeblastdb is missing).
> 
>  When I leave "When available, install Tool Shed managed tool
>  dependencies?"
>  I see blast_rbh, package_blast_plus package_biopython as installed and
>  the
>  others as Installed, missing tool dependencies.
>  Here blast_rbh is working.
> 
>  What would be your suggestion? Live with the latter and file an issue
> at
>  the
>  tools repository (difficult to say which causes the problem(s))?
> 
>  I get similar behavior if I try to install from the test toolshed.
>  (Only a different error from atlas: /bin/sh: line 3:
>  /host/static_full_blas_lapack.diff: No such file or directory).
> 
>  But, actually I'm trying to automatize tool installation using the
>  ansible
>  role ansible-galaxy-tools
>  (https://github.com/galaxyproject/ansible-galaxy-tools). With this
> method
>  I
>  get the latter behavior. The role uses uses ephemeris==0.4.0 to
> install
>  tools. There I have seen three global variables that (I guess) control
>  the
>  installation of dependencies.
> 
>  INSTALL_TOOL_DEPENDENCIES = False
>  INSTALL_REPOSITORY_DEPENDENCIES = True
>  INSTALL_RESOLVER_DEPENDENCIES = True
> 
>  I guess I could control the behavior with the latter two variables.
> 
>  Best,
>  Matthias
> 
> 
> 
>  On 18.04.2017 19:24, Marius van den Beek wrote:
> >
> >
> > Hi Matthias,
> >
> > it's me again!
> > What tool are you trying to install?
> >
> > My -perhaps- unhelpful suggestion is to not install anything that
> starts
> > with
> > package_* (also called tool shed packages), those should be
> exclusively
> > installed when you absolutely need
> > to install an old tool that can only function with packages.
> > We've switched to conda nowadays, which is much easier to install
> and to
> > maintain.
> > In fact the IUC has ported all their latest tools to conda, and
> > similarly most devteam
> > tools that are still in active use have also been 

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Matthias Bernt]

Dear Peter,

thanks. Just for understanding: Why not just change the biopython 
dependency from 1.67 to 1.69, if this is the one available in bioconda. 
blast_rbh seems to use only the SeqIO fasta parser and writer. This 
should be no problem.


But I guess that for older versions of blast_rbh one might still need 
legacy packages of biopython. Or could one change the dependencies in 
older versions? Or would this be no good idea because of backward 
compatibility?


Cheers,
Matthias





On 19.04.2017 13:50, Peter Cock wrote:

Just lucky timing, could you try blast_rbh v0.1.11,

https://toolshed.g2.bx.psu.edu/view/peterjc/blast_rbh/d8d9a9069586

For BLAST+ this ought to work with either bioconda, or the legacy XML
based packages, as both have BLAST+ 2.5.0.

However, it looks like bioconda only has Biopython 1.68 and 1.69, while
the legacy XML based packages only go up to Biopython 1.67 at the time
of writing... it looks like we'll need to add a couple more legacy packages.

Peter

On Wed, Apr 19, 2017 at 12:01 PM, Matthias Bernt  wrote:

Dear Peter,

thanks for the info. Would be great to get the update, but since I have a
method that is working for the moment there is no need to hurry.

Best,
Matthias



On 19.04.2017 12:57, Peter Cock wrote:


Oh right - I've just been updating ncbi_blast_plus this morning
to transition to BLAST+ 2.5.0 via either bioconda or the older
legacy Tool Shed.

I can try to update blast_rbh next, which may solve this by
letting you use bioconda.

Peter

On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt  wrote:


Dear Marius,

thanks again for the help. I'm trying to install blast_rbh (owner is
peterjc). The dependencies look as follows:

blast_rbh
- biopython
  - package_biopython_1_64
- package_numpy_1_8
  - package_atlas_3_10
- blast
- package_blast_plus_2_2_31
  - blast+

With unchecked "When available, install Tool Shed managed tool
dependencies?" I get all as "Installed, missing tool dependencies".
Blast_rbh is not working since blast+ is not installed. Even if I install
blast+ manually (in galaxy) its not working (makeblastdb is missing).

When I leave "When available, install Tool Shed managed tool
dependencies?"
I see blast_rbh, package_blast_plus package_biopython as installed and
the
others as Installed, missing tool dependencies.
Here blast_rbh is working.

What would be your suggestion? Live with the latter and file an issue at
the
tools repository (difficult to say which causes the problem(s))?

I get similar behavior if I try to install from the test toolshed.
(Only a different error from atlas: /bin/sh: line 3:
/host/static_full_blas_lapack.diff: No such file or directory).

But, actually I'm trying to automatize tool installation using the
ansible
role ansible-galaxy-tools
(https://github.com/galaxyproject/ansible-galaxy-tools). With this method
I
get the latter behavior. The role uses uses ephemeris==0.4.0 to install
tools. There I have seen three global variables that (I guess) control
the
installation of dependencies.

INSTALL_TOOL_DEPENDENCIES = False
INSTALL_REPOSITORY_DEPENDENCIES = True
INSTALL_RESOLVER_DEPENDENCIES = True

I guess I could control the behavior with the latter two variables.

Best,
Matthias



On 18.04.2017 19:24, Marius van den Beek wrote:



Hi Matthias,

it's me again!
What tool are you trying to install?

My -perhaps- unhelpful suggestion is to not install anything that starts
with
package_* (also called tool shed packages), those should be exclusively
installed when you absolutely need
to install an old tool that can only function with packages.
We've switched to conda nowadays, which is much easier to install and to
maintain.
In fact the IUC has ported all their latest tools to conda, and
similarly most devteam
tools that are still in active use have also been ported to use Conda
dependencies.

If you look at this
document
https://galaxyproject.org/admin/tools/add-tool-from-toolshed-tutorial/,
there is a part where you confirm dependencies. If you click on show
detail, and you unselect
When available, install Tool Shed managed tool dependencies?
Galaxy will not try to install these old packages. There are some tools
which come both with
old toolshed dependencies and that have Conda available. You may be
lucky and find that
the tool you are trying to install has Conda dependencies available.
There is a lot more background on the Toolshed and Conda in this
document here:
https://docs.galaxyproject.org/en/master/admin/conda_faq.html

Best,
Marius

On 18 April 2017 at 19:03, Matthias Bernt > wrote:

Dear list,

again me :( stumbling from problem to problem ...

I got compilation errors when installing

package_atlas_3_10 Revision: 98c017ec230d

I tried with gcc 4x and 6x without success. Do I need the intel C
compiler for this tool?

If I got earlier posts

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Peter Cock]

Just lucky timing, could you try blast_rbh v0.1.11,

https://toolshed.g2.bx.psu.edu/view/peterjc/blast_rbh/d8d9a9069586

For BLAST+ this ought to work with either bioconda, or the legacy XML
based packages, as both have BLAST+ 2.5.0.

However, it looks like bioconda only has Biopython 1.68 and 1.69, while
the legacy XML based packages only go up to Biopython 1.67 at the time
of writing... it looks like we'll need to add a couple more legacy packages.

Peter

On Wed, Apr 19, 2017 at 12:01 PM, Matthias Bernt  wrote:
> Dear Peter,
>
> thanks for the info. Would be great to get the update, but since I have a
> method that is working for the moment there is no need to hurry.
>
> Best,
> Matthias
>
>
>
> On 19.04.2017 12:57, Peter Cock wrote:
>>
>> Oh right - I've just been updating ncbi_blast_plus this morning
>> to transition to BLAST+ 2.5.0 via either bioconda or the older
>> legacy Tool Shed.
>>
>> I can try to update blast_rbh next, which may solve this by
>> letting you use bioconda.
>>
>> Peter
>>
>> On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt  wrote:
>>>
>>> Dear Marius,
>>>
>>> thanks again for the help. I'm trying to install blast_rbh (owner is
>>> peterjc). The dependencies look as follows:
>>>
>>> blast_rbh
>>> - biopython
>>>   - package_biopython_1_64
>>> - package_numpy_1_8
>>>   - package_atlas_3_10
>>> - blast
>>> - package_blast_plus_2_2_31
>>>   - blast+
>>>
>>> With unchecked "When available, install Tool Shed managed tool
>>> dependencies?" I get all as "Installed, missing tool dependencies".
>>> Blast_rbh is not working since blast+ is not installed. Even if I install
>>> blast+ manually (in galaxy) its not working (makeblastdb is missing).
>>>
>>> When I leave "When available, install Tool Shed managed tool
>>> dependencies?"
>>> I see blast_rbh, package_blast_plus package_biopython as installed and
>>> the
>>> others as Installed, missing tool dependencies.
>>> Here blast_rbh is working.
>>>
>>> What would be your suggestion? Live with the latter and file an issue at
>>> the
>>> tools repository (difficult to say which causes the problem(s))?
>>>
>>> I get similar behavior if I try to install from the test toolshed.
>>> (Only a different error from atlas: /bin/sh: line 3:
>>> /host/static_full_blas_lapack.diff: No such file or directory).
>>>
>>> But, actually I'm trying to automatize tool installation using the
>>> ansible
>>> role ansible-galaxy-tools
>>> (https://github.com/galaxyproject/ansible-galaxy-tools). With this method
>>> I
>>> get the latter behavior. The role uses uses ephemeris==0.4.0 to install
>>> tools. There I have seen three global variables that (I guess) control
>>> the
>>> installation of dependencies.
>>>
>>> INSTALL_TOOL_DEPENDENCIES = False
>>> INSTALL_REPOSITORY_DEPENDENCIES = True
>>> INSTALL_RESOLVER_DEPENDENCIES = True
>>>
>>> I guess I could control the behavior with the latter two variables.
>>>
>>> Best,
>>> Matthias
>>>
>>>
>>>
>>> On 18.04.2017 19:24, Marius van den Beek wrote:


 Hi Matthias,

 it's me again!
 What tool are you trying to install?

 My -perhaps- unhelpful suggestion is to not install anything that starts
 with
 package_* (also called tool shed packages), those should be exclusively
 installed when you absolutely need
 to install an old tool that can only function with packages.
 We've switched to conda nowadays, which is much easier to install and to
 maintain.
 In fact the IUC has ported all their latest tools to conda, and
 similarly most devteam
 tools that are still in active use have also been ported to use Conda
 dependencies.

 If you look at this
 document
 https://galaxyproject.org/admin/tools/add-tool-from-toolshed-tutorial/,
 there is a part where you confirm dependencies. If you click on show
 detail, and you unselect
 When available, install Tool Shed managed tool dependencies?
 Galaxy will not try to install these old packages. There are some tools
 which come both with
 old toolshed dependencies and that have Conda available. You may be
 lucky and find that
 the tool you are trying to install has Conda dependencies available.
 There is a lot more background on the Toolshed and Conda in this
 document here:
 https://docs.galaxyproject.org/en/master/admin/conda_faq.html

 Best,
 Marius

 On 18 April 2017 at 19:03, Matthias Bernt > wrote:

 Dear list,

 again me :( stumbling from problem to problem ...

 I got compilation errors when installing

 package_atlas_3_10 Revision: 98c017ec230d

 I tried with gcc 4x and 6x without success. Do I need the intel C
 compiler for this tool?

 If I got earlier posts

 (http://dev.list.galaxyproject.org/atlas-3-10-IUC-error-tt4668236.html

 

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Matthias Bernt]

Dear Peter,

thanks for the info. Would be great to get the update, but since I have 
a method that is working for the moment there is no need to hurry.


Best,
Matthias


On 19.04.2017 12:57, Peter Cock wrote:

Oh right - I've just been updating ncbi_blast_plus this morning
to transition to BLAST+ 2.5.0 via either bioconda or the older
legacy Tool Shed.

I can try to update blast_rbh next, which may solve this by
letting you use bioconda.

Peter

On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt  wrote:

Dear Marius,

thanks again for the help. I'm trying to install blast_rbh (owner is
peterjc). The dependencies look as follows:

blast_rbh
- biopython
  - package_biopython_1_64
- package_numpy_1_8
  - package_atlas_3_10
- blast
- package_blast_plus_2_2_31
  - blast+

With unchecked "When available, install Tool Shed managed tool
dependencies?" I get all as "Installed, missing tool dependencies".
Blast_rbh is not working since blast+ is not installed. Even if I install
blast+ manually (in galaxy) its not working (makeblastdb is missing).

When I leave "When available, install Tool Shed managed tool dependencies?"
I see blast_rbh, package_blast_plus package_biopython as installed and the
others as Installed, missing tool dependencies.
Here blast_rbh is working.

What would be your suggestion? Live with the latter and file an issue at the
tools repository (difficult to say which causes the problem(s))?

I get similar behavior if I try to install from the test toolshed.
(Only a different error from atlas: /bin/sh: line 3:
/host/static_full_blas_lapack.diff: No such file or directory).

But, actually I'm trying to automatize tool installation using the ansible
role ansible-galaxy-tools
(https://github.com/galaxyproject/ansible-galaxy-tools). With this method I
get the latter behavior. The role uses uses ephemeris==0.4.0 to install
tools. There I have seen three global variables that (I guess) control the
installation of dependencies.

INSTALL_TOOL_DEPENDENCIES = False
INSTALL_REPOSITORY_DEPENDENCIES = True
INSTALL_RESOLVER_DEPENDENCIES = True

I guess I could control the behavior with the latter two variables.

Best,
Matthias



On 18.04.2017 19:24, Marius van den Beek wrote:


Hi Matthias,

it's me again!
What tool are you trying to install?

My -perhaps- unhelpful suggestion is to not install anything that starts
with
package_* (also called tool shed packages), those should be exclusively
installed when you absolutely need
to install an old tool that can only function with packages.
We've switched to conda nowadays, which is much easier to install and to
maintain.
In fact the IUC has ported all their latest tools to conda, and
similarly most devteam
tools that are still in active use have also been ported to use Conda
dependencies.

If you look at this
document
https://galaxyproject.org/admin/tools/add-tool-from-toolshed-tutorial/,
there is a part where you confirm dependencies. If you click on show
detail, and you unselect
When available, install Tool Shed managed tool dependencies?
Galaxy will not try to install these old packages. There are some tools
which come both with
old toolshed dependencies and that have Conda available. You may be
lucky and find that
the tool you are trying to install has Conda dependencies available.
There is a lot more background on the Toolshed and Conda in this
document here:
https://docs.galaxyproject.org/en/master/admin/conda_faq.html

Best,
Marius

On 18 April 2017 at 19:03, Matthias Bernt > wrote:

Dear list,

again me :( stumbling from problem to problem ...

I got compilation errors when installing

package_atlas_3_10 Revision: 98c017ec230d

I tried with gcc 4x and 6x without success. Do I need the intel C
compiler for this tool?

If I got earlier posts
(http://dev.list.galaxyproject.org/atlas-3-10-IUC-error-tt4668236.html

)

correct a precompiled version should be used anyway?

I'm running galaxy on CentOS 6.8 (64bit) (running in a VirtualBox).

Best,
Matthias


Here is the output (which I guess is verbose output from configure):


/tmp/cctyMGAH.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
probe_OS.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
probe_asm.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
system(make IRun_GAS_x8632 args="-v 2" 

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Peter Cock]

Oh right - I've just been updating ncbi_blast_plus this morning
to transition to BLAST+ 2.5.0 via either bioconda or the older
legacy Tool Shed.

I can try to update blast_rbh next, which may solve this by
letting you use bioconda.

Peter

On Wed, Apr 19, 2017 at 11:52 AM, Matthias Bernt  wrote:
> Dear Marius,
>
> thanks again for the help. I'm trying to install blast_rbh (owner is
> peterjc). The dependencies look as follows:
>
> blast_rbh
> - biopython
>   - package_biopython_1_64
> - package_numpy_1_8
>   - package_atlas_3_10
> - blast
> - package_blast_plus_2_2_31
>   - blast+
>
> With unchecked "When available, install Tool Shed managed tool
> dependencies?" I get all as "Installed, missing tool dependencies".
> Blast_rbh is not working since blast+ is not installed. Even if I install
> blast+ manually (in galaxy) its not working (makeblastdb is missing).
>
> When I leave "When available, install Tool Shed managed tool dependencies?"
> I see blast_rbh, package_blast_plus package_biopython as installed and the
> others as Installed, missing tool dependencies.
> Here blast_rbh is working.
>
> What would be your suggestion? Live with the latter and file an issue at the
> tools repository (difficult to say which causes the problem(s))?
>
> I get similar behavior if I try to install from the test toolshed.
> (Only a different error from atlas: /bin/sh: line 3:
> /host/static_full_blas_lapack.diff: No such file or directory).
>
> But, actually I'm trying to automatize tool installation using the ansible
> role ansible-galaxy-tools
> (https://github.com/galaxyproject/ansible-galaxy-tools). With this method I
> get the latter behavior. The role uses uses ephemeris==0.4.0 to install
> tools. There I have seen three global variables that (I guess) control the
> installation of dependencies.
>
> INSTALL_TOOL_DEPENDENCIES = False
> INSTALL_REPOSITORY_DEPENDENCIES = True
> INSTALL_RESOLVER_DEPENDENCIES = True
>
> I guess I could control the behavior with the latter two variables.
>
> Best,
> Matthias
>
>
>
> On 18.04.2017 19:24, Marius van den Beek wrote:
>>
>> Hi Matthias,
>>
>> it's me again!
>> What tool are you trying to install?
>>
>> My -perhaps- unhelpful suggestion is to not install anything that starts
>> with
>> package_* (also called tool shed packages), those should be exclusively
>> installed when you absolutely need
>> to install an old tool that can only function with packages.
>> We've switched to conda nowadays, which is much easier to install and to
>> maintain.
>> In fact the IUC has ported all their latest tools to conda, and
>> similarly most devteam
>> tools that are still in active use have also been ported to use Conda
>> dependencies.
>>
>> If you look at this
>> document
>> https://galaxyproject.org/admin/tools/add-tool-from-toolshed-tutorial/,
>> there is a part where you confirm dependencies. If you click on show
>> detail, and you unselect
>> When available, install Tool Shed managed tool dependencies?
>> Galaxy will not try to install these old packages. There are some tools
>> which come both with
>> old toolshed dependencies and that have Conda available. You may be
>> lucky and find that
>> the tool you are trying to install has Conda dependencies available.
>> There is a lot more background on the Toolshed and Conda in this
>> document here:
>> https://docs.galaxyproject.org/en/master/admin/conda_faq.html
>>
>> Best,
>> Marius
>>
>> On 18 April 2017 at 19:03, Matthias Bernt > > wrote:
>>
>> Dear list,
>>
>> again me :( stumbling from problem to problem ...
>>
>> I got compilation errors when installing
>>
>> package_atlas_3_10 Revision: 98c017ec230d
>>
>> I tried with gcc 4x and 6x without success. Do I need the intel C
>> compiler for this tool?
>>
>> If I got earlier posts
>> (http://dev.list.galaxyproject.org/atlas-3-10-IUC-error-tt4668236.html
>>
>> )
>>
>> correct a precompiled version should be used anyway?
>>
>> I'm running galaxy on CentOS 6.8 (64bit) (running in a VirtualBox).
>>
>> Best,
>> Matthias
>>
>>
>> Here is the output (which I guess is verbose output from configure):
>>
>>
>> /tmp/cctyMGAH.o: In function `ATL_tmpnam':
>>
>> /gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
>> warning: the use of `tmpnam' is dangerous, better use `mkstemp'
>> probe_OS.o: In function `ATL_tmpnam':
>>
>> /gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
>> warning: the use of `tmpnam' is dangerous, better use `mkstemp'
>> probe_asm.o: In function `ATL_tmpnam':
>>
>> /gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
>> warning: the use of `tmpnam' is 

Re: [galaxy-dev] atlas version 3.10.2 installation error

[Matthias Bernt]

Dear Marius,

thanks again for the help. I'm trying to install blast_rbh (owner is 
peterjc). The dependencies look as follows:


blast_rbh
- biopython
  - package_biopython_1_64
- package_numpy_1_8
  - package_atlas_3_10
- blast
- package_blast_plus_2_2_31
  - blast+

With unchecked "When available, install Tool Shed managed tool 
dependencies?" I get all as "Installed, missing tool dependencies". 
Blast_rbh is not working since blast+ is not installed. Even if I 
install blast+ manually (in galaxy) its not working (makeblastdb is 
missing).


When I leave "When available, install Tool Shed managed tool 
dependencies?" I see blast_rbh, package_blast_plus package_biopython as 
installed and the others as Installed, missing tool dependencies.

Here blast_rbh is working.

What would be your suggestion? Live with the latter and file an issue at 
the tools repository (difficult to say which causes the problem(s))?


I get similar behavior if I try to install from the test toolshed.
(Only a different error from atlas: /bin/sh: line 3: 
/host/static_full_blas_lapack.diff: No such file or directory).


But, actually I'm trying to automatize tool installation using the 
ansible role ansible-galaxy-tools 
(https://github.com/galaxyproject/ansible-galaxy-tools). With this 
method I get the latter behavior. The role uses uses ephemeris==0.4.0 to 
install tools. There I have seen three global variables that (I guess) 
control the installation of dependencies.


INSTALL_TOOL_DEPENDENCIES = False
INSTALL_REPOSITORY_DEPENDENCIES = True
INSTALL_RESOLVER_DEPENDENCIES = True

I guess I could control the behavior with the latter two variables.

Best,
Matthias


On 18.04.2017 19:24, Marius van den Beek wrote:

Hi Matthias,

it's me again!
What tool are you trying to install?

My -perhaps- unhelpful suggestion is to not install anything that starts
with
package_* (also called tool shed packages), those should be exclusively
installed when you absolutely need
to install an old tool that can only function with packages.
We've switched to conda nowadays, which is much easier to install and to
maintain.
In fact the IUC has ported all their latest tools to conda, and
similarly most devteam
tools that are still in active use have also been ported to use Conda
dependencies.

If you look at this
document https://galaxyproject.org/admin/tools/add-tool-from-toolshed-tutorial/,
there is a part where you confirm dependencies. If you click on show
detail, and you unselect
When available, install Tool Shed managed tool dependencies?
Galaxy will not try to install these old packages. There are some tools
which come both with
old toolshed dependencies and that have Conda available. You may be
lucky and find that
the tool you are trying to install has Conda dependencies available.
There is a lot more background on the Toolshed and Conda in this
document here:
https://docs.galaxyproject.org/en/master/admin/conda_faq.html

Best,
Marius

On 18 April 2017 at 19:03, Matthias Bernt > wrote:

Dear list,

again me :( stumbling from problem to problem ...

I got compilation errors when installing

package_atlas_3_10 Revision: 98c017ec230d

I tried with gcc 4x and 6x without success. Do I need the intel C
compiler for this tool?

If I got earlier posts
(http://dev.list.galaxyproject.org/atlas-3-10-IUC-error-tt4668236.html
)
correct a precompiled version should be used anyway?

I'm running galaxy on CentOS 6.8 (64bit) (running in a VirtualBox).

Best,
Matthias


Here is the output (which I guess is verbose output from configure):


/tmp/cctyMGAH.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
probe_OS.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
probe_asm.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
system(make IRun_GAS_x8632 args="-v 2" MYFLAGS="-DATL_OS_Linux" 2>
/dev/null | fgrep SUCCESS)

ierr=256 in command='make IRun_GAS_x8632 args="-v 2"
MYFLAGS="-DATL_OS_Linux" 2> /dev/null | fgrep SUCCESS'!

OUTPUT:
===
system(make IRun_GAS_x8664 args="-v 2" MYFLAGS="-DATL_OS_Linux" 2>
/dev/null | fgrep SUCCESS)
probe_vec.o: In function `ATL_tmpnam':

/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224:
warning: the use of `tmpnam' is 

[galaxy-dev] atlas version 3.10.2 installation error

[Matthias Bernt]

Dear list,

again me :( stumbling from problem to problem ...

I got compilation errors when installing

package_atlas_3_10 Revision: 98c017ec230d

I tried with gcc 4x and 6x without success. Do I need the intel C 
compiler for this tool?


If I got earlier posts 
(http://dev.list.galaxyproject.org/atlas-3-10-IUC-error-tt4668236.html) 
correct a precompiled version should be used anyway?


I'm running galaxy on CentOS 6.8 (64bit) (running in a VirtualBox).

Best,
Matthias


Here is the output (which I guess is verbose output from configure):


/tmp/cctyMGAH.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

probe_OS.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

probe_asm.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'
system(make IRun_GAS_x8632 args="-v 2" MYFLAGS="-DATL_OS_Linux" 2> 
/dev/null | fgrep SUCCESS)


ierr=256 in command='make IRun_GAS_x8632 args="-v 2" 
MYFLAGS="-DATL_OS_Linux" 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===
system(make IRun_GAS_x8664 args="-v 2" MYFLAGS="-DATL_OS_Linux" 2> 
/dev/null | fgrep SUCCESS)

probe_vec.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'


ierr=256 in command='make IRun_VSX MYFLAGS='-DATL_OS_Linux 
-DATL_GAS_x8664' 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===

ierr=256 in command='make IRun_AltiVec MYFLAGS='-DATL_OS_Linux 
-DATL_GAS_x8664' 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===

ierr=256 in command='make IRun_AVXFMA4 MYFLAGS='-DATL_OS_Linux 
-DATL_GAS_x8664' 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===

ierr=256 in command='make IRun_3DNow MYFLAGS='-DATL_OS_Linux 
-DATL_GAS_x8664' 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===

ierr=256 in command='make IRun_NEON MYFLAGS='-DATL_OS_Linux 
-DATL_GAS_x8664' 2> /dev/null | fgrep SUCCESS'!


OUTPUT:
===
probe_arch.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

/tmp/cc8hbxc1.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

ERROR: enum fam=3, chip=2, model=79, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2
/tmp/ccafA8Bi.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

ERROR: enum fam=3, chip=2, model=79, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2
ERROR: enum fam=3, chip=2, model=79, mach=0
make[3]: *** [atlas_run] Error 44
make[2]: *** [IRunArchInfo_x86] Error 2
cmnd='make IRun_comp args="-v 2 -o atlconf.txt -O 1 -A 39 -Si nof77 0 -V 
488  -Fa ic '-fPIC' -Fa sm '-fPIC' -Fa dm '-fPIC' -Fa sk '-fPIC' -Fa dk 
'-fPIC' -Fa xc '-fPIC' -Fa gc '-fPIC' -Fa if '-fPIC' -b 64"'

/tmp/cc8W8Itx.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'

probe_comp.o: In function `ATL_tmpnam':
/gpfs1/data/galaxy_server/galaxy-dev/database/tmp/tmp-toolshed-mtdAAKCLe/ATLAS/build/..//CONFIG/include/atlas_sys.h:224: 
warning: the use of `tmpnam' is dangerous, better use `mkstemp'


ierr=256 in command='find /gpfs1/data/galaxy_server/galaxy-dev/.venv/bin 
/usr/local/gcc/6.2.0-1/bin 
/global/apps/bioinf/galaxy/bin/Python-2.7.13/bin 
/usr/local/sqlite/3.15.1-1/bin 
/global/apps/bioinf/galaxy/bin/postgresql-9.6.2/bin 
/usr/local/git/2.10.1-1/bin /usr/local/pcre/8.38-1/bin 
/usr/local/ncurses/5.9-1/bin /usr/local/bzip2/1.0.6-3/bin 
/usr/local/expat/2.1.1-1/bin /usr/local/curl/7.41.0-1/bin 
/usr/local/openssl/1.0.2-1/usr/bin /usr/local/uge/8.4.4-1/bin/lx-amd64 
/usr/local/bin /bin /usr/bin /usr/local/sbin /usr/sbin /sbin 
/home/songalax/bin -maxdepth 1 -name '*gcc*' -exec ./xisgcc '{}' \;'!


OUTPUT:
===
cmnd=make IRunCComp CC='/usr/local/gcc/6.2.0-1/bin/gcc' CCFLAGS='-O'  | 
fgrep SUCCESS

   /usr/local/gcc/6.2.0-1/bin/gcc -O : SUCCESS!
cmnd=make IRunCComp CC='/usr/bin/gcc' CCFLAGS='-O'  | fgrep SUCCESS
   /usr/bin/gcc -O : SUCCESS!