Modify

Opened 8 years ago

Closed 7 years ago

#42 closed task (fixed)

Make fail aria2

Reported by: anonymous Owned by: bas
Priority: major Milestone: SALI 1.6.0
Component: sali kernel/initrd Version: trunk
Keywords: debian, debian wheezy Cc:

Description

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.

Attachments (0)

Change History (15)

comment:1 in reply to: ↑ description Changed 8 years ago by 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

comment:2 in reply to: ↑ description Changed 8 years ago by 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!

comment:3 Changed 8 years ago by dmontaldo@dc.uba.ar

  • Owner changed from dmontaldo@dc.uba.ar to anonymous
  • Status changed from new to assigned

comment:4 Changed 8 years ago by dmontaldo@dc.uba.ar

  • Keywords debian debian wheezy added
  • Summary changed from Make fail to Make fail aria2

comment:5 follow-up: Changed 8 years ago by 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?

comment:6 Changed 8 years ago by bas

  • Component changed from sali to sali kernel/initrd
  • Owner changed from anonymous to bas
  • Status changed from assigned to accepted
  • Type changed from defect to task

comment:7 Changed 8 years ago by dennis

  • Priority changed from blocker to major

comment:8 in reply to: ↑ 5 ; follow-up: Changed 8 years ago by 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.

comment:9 follow-up: Changed 8 years ago by 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?

comment:10 in reply to: ↑ 9 Changed 8 years ago by 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.

comment:11 in reply to: ↑ 8 ; follow-up: Changed 8 years ago by 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 ;)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 8 years ago by 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:

comment:13 in reply to: ↑ 12 Changed 8 years ago by 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?

comment:14 Changed 8 years ago by dennis

  • Milestone set to SALI 1.6.0

comment:15 Changed 7 years ago by dennis

  • Resolution set to fixed
  • Status changed from accepted to closed

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

Add Comment

Modify Ticket

Change Properties
Action
as closed The owner will remain bas.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.