Make fail aria2

[anonymous]

Hi, I'm trying to compile sali in a debian wheezy (now is testing but I need it to install de nvidia drivers for cuda) and it fails to compile aria2

In file included from FtpConnection.cc:44:0:
util.h: In instantiation of ‘void aria2::util::divide(std::pair<std::pair<T, T>, std::pair<T, T> >&, InputIterator, InputIterator, char) [with InputIterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char> >]’:
FtpConnection.cc:408:75:   required from here

It seems to be a bug from using GCC 4.7 and it's reported in Debian
​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667102

Source: aria2
Source-Version: 1.14.2-2

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

So, the idea of this ticket is to ask for an upgrade of aria version to that working version.

Thanks.

[anonymous]

Replying to anonymous:

Hi, I'm trying to compile sali in a debian wheezy (now is testing but I need it to install de nvidia drivers for cuda) and it fails to compile aria2

This is the complete error:

Making install in src
make[2]: Entering directory `/home/dmontaldo/sali/trunk/src/aria2-1.14.2/src'
g++ -DHAVE_CONFIG_H -I. -I..  -Wall -I../lib -I../intl -DLOCALEDIR=\"/usr/share/locale\" -DCA_BUNDLE=\"\" -DHAVE_CONFIG_H  -I/home/dmontaldo/sali/trunk/src/openssl-0.9.8r/include -I/usr/include/libxml2   -g -O2 -MT FtpConnection.o -MD -MP -MF .deps/FtpConnection.Tpo -c -o FtpConnection.o FtpConnection.cc
In file included from FtpConnection.cc:44:0:
util.h: In instantiation of ‘void aria2::util::divide(std::pair<std::pair<T, T>, std::pair<T, T> >&, InputIterator, InputIterator, char) [with InputIterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char> >]’:
FtpConnection.cc:408:75:   required from here
util.h:124:5: error: ‘stripIter’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
util.h:167:41: note: ‘template<class InputIterator> std::pair<T, T> aria2::util::stripIter(InputIterator, InputIterator, const string&)’ declared here, later in the translation unit
util.h:127:5: error: ‘stripIter’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
util.h:167:41: note: ‘template<class InputIterator> std::pair<T, T> aria2::util::stripIter(InputIterator, InputIterator, const string&)’ declared here, later in the translation unit
util.h:128:5: error: ‘stripIter’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
util.h:167:41: note: ‘template<class InputIterator> std::pair<T, T> aria2::util::stripIter(InputIterator, InputIterator, const string&)’ declared here, later in the translation unit
make[2]: *** [FtpConnection.o] Error 1
make[2]: Leaving directory `/home/dmontaldo/sali/trunk/src/aria2-1.14.2/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/dmontaldo/sali/trunk/src/aria2-1.14.2'
make: *** [/home/dmontaldo/sali/trunk/src/aria2-1.14.2.install] Error 2

[dmontaldo@dc.uba.ar]

Replying to anonymous:

So, the idea of this ticket is to ask for an upgrade of aria version to that working version.

The Debian wheezy version of aria2 is 1.15.1-1
​http://packages.debian.org/wheezy/aria2

I don't know if you need that version but at least the 1.14.2-2 it doesn't have that reported bug.

Thanks!

[bas]

Thanks for reporting. When we switch to wheezy for building SALI/ we will upgrade aria. Dou you have to build your own version of SALI can't you use the current SALI release?

[dmontaldo@dc.uba.ar]

Replying to bas:

Thanks for reporting. When we switch to wheezy for building SALI/ we will upgrade aria. Dou you have to build your own version of SALI can't you use the current SALI release?

I try it for the first time and it doesn't work, at least for me.

I don't remember exactly why, because it was a headache to use system imager to build the image and then found sali to deploy it.
I start deploying the images whit the SI scripts too and then I ask about this in the si-suite mailing list and then I switch completely to sali (thanks for your work!)

I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...

I could give a try now to this binaries in wheezy but keep in mind too that squeeze its very old for some new hardware (like the ones with GPUs).

Thanks and excuse me if I submit to many tickets if you don't plan to compile sali yet in wheezy.

[bas]

We are always interested in updates and patches for SALI and we appreciate your efforts.

First of all SALI has nothing todo with debian squeeze. we only use it to compile and develop SALI. SALI uses a modern linux kernel (3.1.4) and udev if there are missing device drivers we will add them. The combo of kernel and udev is also important one you are already experiencing this. We use SALI to install our images and we have also a GPU cluster. SALI is responsible for detecting hardware like network controllers, disk controllers so we can install the cloned image. The cloned image has all the proper GPU device drivers.

Or do you use SALI differently?

[dmontaldo@dc.uba.ar]

Replying to bas:

We are always interested in updates and patches for SALI and we appreciate your efforts.

First of all SALI has nothing todo with debian squeeze. we only use it to compile and develop SALI. SALI uses a modern linux kernel (3.1.4) and udev if there are missing device drivers we will add them.

I know and I think that this is the big advantage to switch to sali.

The combo of kernel and udev is also important one you are already experiencing this. We use SALI to install our images and we have also a GPU cluster.

But I can't install the nvidia proprietary drivers and cuda toolkit in debian wheezy and that is why I have to upgrade from squeeze to wheezy.
May be it was my mistake but it has an old kernel compared to the one that uses nvidia to compile their modules.

SALI is responsible for detecting hardware like network controllers, disk controllers so we can install the cloned image. The cloned image has all the proper GPU device drivers.

May be this is a technical question but which drivers are you using? the debian package for nvidia drivers?

Or do you use SALI differently?

No, just to deploy the images.

[dmontaldo@dc.uba.ar]

Replying to dmontaldo@…:

Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...

Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*

And change the verbose level to don't show the progress transfered files (I want verbose, but not pass the {VERBOSE_GETIMAGE_OPT} to the rsync)

And add --stats and --human-readable ;)

[bas]

Replying to dmontaldo@…:

Replying to dmontaldo@…:

Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...

Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*

Why? You can exclude this directories when you makeing a image from your golden node. No need to patch these files. What commands do you use to clone a node. There you must exclude these directories.

And change the verbose level to don't show the progress transfered files (I want verbose, but not pass the {VERBOSE_GETIMAGE_OPT} to the rsync)

And add --stats and --human-readable ;)

The different VERBOSE levels are explained in:

• ​https://subtrac.sara.nl/oss/sali/wiki/SaliUsage/Installationparameters#VERBOSE_LEVELnumber

[dmontaldo@dc.uba.ar]

Replying to bas:

Replying to dmontaldo@…:

Replying to dmontaldo@…:

Replying to bas:
I grab the source code of sali to avoid using SI a long time ago (in squeeze compile and works like a charm).
Now that you ask me I think it could be the boot flag (ticket #41), I really don't know when I started looking and changing the code...

Now that you ask I start looking at the code to change the rsync arguments in the initrd/functions/stubs/getimage
I add --exclude=/dev/* --exclude=/sys/*

Why? You can exclude this directories when you makeing a image from your golden node. No need to patch these files. What commands do you use to clone a node. There you must exclude these directories.

It fails the rsync when I was in the chrooted image because I have to mount /dev, /sys, /proc etc

I made a script to chroot the images in a "nice way".
Do you have something to do that?

[dennis]

This has been fixed in the current trunk version, which will be released as version 1.6.0