Menu
▾
▴
fisterra-devel
|
From: Maria I. F. T. <mif...@ig...> - 2007-09-19 17:49:42
|
Hello
I have installed jhbuild-buildbot for fisterra in my machine and I found
some problems in the process of building.
First:
In the step of build for fisterra-repair module it fails because tries
to write in a directory where it hasn't permissions (this is /etc/pam.d)
and for this reason the process isn't completed successfully. This fail
happens when command "make install" is executing.
I don't know if I can do something to solve this.
Second:
The other modules are built successfully and I'm trying to execute unit
tests for fisterra-base module in the slave.
First time the system executed the step make-check and in this step the
command "jhbuild --moduleset=fisterra.modules pathrun fisterra-base
make-check.sh", one of the fails appeared was:
** (Libfisterra: GNOME business applications development
framework:7200): WARNING **: Error: libpq.so.2: cannot open shared
object file: No such file or directory
** ERROR **: f_da_provider_init: GDA provider does not exist
aborting...
I solve the first error adding to path the place where the library libpq.so.2 is but now the output is:
Error: Could not find provider SQLite in the current setup
[...]
check_fisterra-base.c:146:F:Core:check_fisterra_base_sqlite:
******************************************************
The sqlite gda provider is not (properly) installed
There are certain tests that rely on that provider; so,
those tests will fail without actually being executed
******************************************************
I don't write all the output because is too long. This behaviour is in the slave.
Then I execute "make -k check" in my directory, (not in the slave) where I have downloaded and
installed fisterra-base by manual process, and all tests passed successfully.
I think that to solve this in the slave I have to change or add a environment variable but really I don't know.
If someone has an idea, could you help me?
Third:
Executing this tests in the slave the result of one is segmentation fault but in my directory it passed successfully. This
behaviour seems stranged and I think that it can be solved substituing this code (in fisterra-base/ut/common/check_util.c in the test
check_util_name_month):
gchar* months[] = {"January",
"February",
"March",
"April",
"May",
"June",
"July",
"August",
"September",
"October",
"November",
"December"};
int i;
for (i=1;i<13;i++){
fail_unless(strcmp(u_get_name_of_month(i),
months[i]));
fail_unless(strcmp(u_month_number_to_month_string(i),
months[i]));
}
for that one:
int i;
for (i=1;i<13;i++){
fail_unless(!strcmp(u_get_name_of_month(i),
months[i-1]));
fail_unless(!strcmp(u_month_number_to_month_string(i),
months[i-1]));
}
Because strcmp returns 0 if the strings are equals and fail_unless(0) make the test fails. And I think that the counter of the array it was wrong.
I don't know what I can do with this because the next time the jhbuild-buildbot execute the step of update the sources will be overwritten and
the test will fail again.
|
|
From: Jorge B. G. <yor...@gm...> - 2007-09-20 02:09:09
|
O M=E9rcores 19 Setembro 2007 19:49, Maria Isabel Franco Trillo escribiu: > Hello > > I have installed jhbuild-buildbot for fisterra in my machine and I found > some problems in the process of building. > > First: > In the step of build for fisterra-repair module it fails because tries > to write in a directory where it hasn't permissions (this is /etc/pam.d) > and for this reason the process isn't completed successfully. This fail > happens when command "make install" is executing. > I don't know if I can do something to solve this. I also saw this, when I was testing fisterra-repair. That's because=20 fisterra-repair always tries to install a file in /etc/pam.d, it doesn't=20 matter what prefix or options you pass to the configure script. Look at this file: /src/server/etc/Makefile.am That directory is hard-coded in a line like: pamconfdir =3D /etc/pam.d There are two options, install this always as root, or to change that line.= I=20 think that folder should depend on an option passed to the configure script. > Second: > The other modules are built successfully and I'm trying to execute unit > tests for fisterra-base module in the slave. > > First time the system executed the step make-check and in this step the > command "jhbuild --moduleset=3Dfisterra.modules pathrun fisterra-base > make-check.sh", one of the fails appeared was: > > ** (Libfisterra: GNOME business applications development > framework:7200): WARNING **: Error: libpq.so.2: cannot open shared > object file: No such file or directory > ** ERROR **: f_da_provider_init: GDA provider does not exist > aborting... > > I solve the first error adding to path the place where the library > libpq.so.2 is but now the output is: > > Error: Could not find provider SQLite in the current setup > [...] > check_fisterra-base.c:146:F:Core:check_fisterra_base_sqlite: > ****************************************************** > The sqlite gda provider is not (properly) installed > There are certain tests that rely on that provider; so, > those tests will fail without actually being executed > ****************************************************** When I found the error complaining about the SQLite provider not found, I=20 solved it installing the package gda2-sqlite. But if (as you say) it works= =20 when you try it manually in your directory , may be that's not the problem= =20 (or it could be that when it works you are trying in other machine, where=20 that package is already installed). Anyway, test that you have the needed gda2-* packages. Regards, Yortx. |
|
From: API <api...@ig...> - 2007-09-20 06:51:36
|
> I also saw this, when I was testing fisterra-repair. That's because > fisterra-repair always tries to install a file in /etc/pam.d, it doesn't > matter what prefix or options you pass to the configure script. > Look at this file: /src/server/etc/Makefile.am > That directory is hard-coded in a line like: pamconfdir = /etc/pam.d > There are two options, install this always as root, or to change that line. I > think that folder should depend on an option passed to the configure script. Well, you could made this to solve this concrete problem, but there are a problem You can configure other directories because is fisterra who use this, like the serverconfdir in the same Makefile.am. If we are compiling in a local directory, we can change the directory, and fisterra will find the file correctly. But this directory is hardcoded because who will use the file "fisterra" is the pam module, and to work properly, the file is needed to be on this directory. If we configure this directory to a local one, we can solve the problem making a `make install`, but the authentication will fail if we try to execute this. Currently, the auth module (on fisterra-bmodules-auth) uses pam to make the authentication, and uses the "hard-coded" file called "fisterra". In this way we can configure the authentication very easy, as there are several pam modules: using a file, using a ldap, etc. In this case, it is configured to use a pwd file. In theory, thinking in the project as an open project, it is simply an configuration example, there are any point on documentation that says that?, that explain how configure and how works the authentication, and that this is only a example? Another point: there are a problem with this implementation. As I say, the fisterra-bmodule-auth module uses the `fisterra` file to authenticate. This has a problem: what happens if you have several applications based on fisterra? (ie: fisterra-repair and fisterra-distribution). The problem is that to authenticate you'll be sharing the same authentication file. Well, when you start to work, you can have different acls, as this in on database, but at first, to authenticate, you share the pam.d fisterra, as it is used on fisterra-bmodules. Looking a cvs log at Makefile.am, you can see that at begining this authentication file was on fisterra-bmodules. This was because is shared, but was moved because in theory you use a concrete file for each application. But as I say, it is shared. If we make each concrete app to install his fisterra file, each one will be replacing the fisterra file of the others. This "shared approach" has sense if all the fisterra applications on a machine share his users, but Im not sure if we can suppose this at this moment. Other problem with this approach is that it is difficult to add new users, although with the acls, it is difficult to add users (in fact, this is more a "role" approach). Should be reviewed the fisterra-bmodule-auth? For example: in others applications based on fisterra, we don't use fisterra-bmodules-auth to authenticate, the app implements the authentication himself, and uses the database to manage the users that can authenticate, and to add users. === API (api...@ig...) |
|
From: Xabier R. C. <xrc...@ig...> - 2007-09-24 08:46:25
|
O Xov, 20-09-2007 =E1s 04:10 +0200, Jorge Barreiro Gonzalez escribiu: > I also saw this, when I was testing fisterra-repair. That's because=20 > fisterra-repair always tries to install a file in /etc/pam.d, it doesn't=20 > matter what prefix or options you pass to the configure script. > Look at this file: /src/server/etc/Makefile.am > That directory is hard-coded in a line like: pamconfdir =3D /etc/pam.d > There are two options, install this always as root, or to change that lin= e. I=20 > think that folder should depend on an option passed to the configure scri= pt. I think if you are using the autotools you have the possibility of specifying a directory which really installs everything under the place you decide: make install DESTDIR=3D/my/dir Try this and if this doesn't work I can take a deeper look. Greetings! --=20 Xabier Rodr=EDguez Calvar Enxe=F1eiro en Inform=E1tica Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: xrc...@ig... IGALIA http://www.igalia.com |
|
From: API <api...@ig...> - 2007-09-24 09:21:40
|
From: Xabier Rodriguez Calvar <xrc...@ig...> Subject: Re: [Fisterra-devel] problems with jhbuild-buildbot in fisterr= a Date: Mon, 24 Sep 2007 10:45:50 +0200 > O Xov, 20-09-2007 =E1s 04:10 +0200, Jorge Barreiro Gonzalez escribiu:= > > I also saw this, when I was testing fisterra-repair. That's because= = > > fisterra-repair always tries to install a file in /etc/pam.d, it do= esn't = > > matter what prefix or options you pass to the configure script. > > Look at this file: /src/server/etc/Makefile.am > > That directory is hard-coded in a line like: pamconfdir =3D /etc/pa= m.d > > There are two options, install this always as root, or to change th= at line. I = > > think that folder should depend on an option passed to the configur= e script. > = > I think if you are using the autotools you have the possibility of > specifying a directory which really installs everything under the pla= ce > you decide: > = > make install DESTDIR=3D/my/dir > = > Try this and if this doesn't work I can take a deeper look. > = You should read my answer to this problem, that I sent past Thursday (I= know that it is long), as make what you say is really easy, but it is not the rea= l problem = with this variable. =3D=3D=3D API (api...@ig...) |
|
From: Maria I. F. T. <mif...@ig...> - 2007-09-25 09:14:07
|
Finally, in the first problem, I tried to add DISTDIR option to 'make' and now build process is completed successfully. I know that, with this change, the application won't work, but for the time being none unit test is made for this module (fisterra-repair) and after building none step more is executed, but in the future this should be changed (it would be only delete the line with module_makeargs in .jhbuildrc file in the slave). Nevertheless I'm going to have a look at fisterra-bmodule-auth. The second one I have found was solved erasing libgda of moduleset, because files for SQLite provider wasn't intalled (I had to delete the whole source code and installed files of the previous libgda build to allow that the application use correct gda files installed in the system). |
Thanks for helping keep SourceForge clean.
X