Juntando varias capturasen una se puede producir el siguiente error:
:~/xplico/capturas$ mergecap *.pcap -w ../todo.pcap
mergecap: Can't open or create ../todo.pcap: That file format doesn't support per-packet encapsulations
Se soluciona especificando el formato de menos nivel OSI de las presentes capturas. Por ejemplo:
:~/xplico/capturas$ mergecap -T ether *.pcap -w ../todo.pcap
Compilando Monit puede producirse el siguiente aviso/errror:
root@server56:~/monit-5.0.3# ./configure
(...)
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for SSL support... enabled
checking for SSL include directory... Not found
Couldn't find your SSL header files.
Use --with-ssl-incl-dir option to fix this problem or disable
the SSL support with --without-ssl
#
Se soluciona instalando las librerías de SSL:
root@server56:~/monit-5.0.3# sudo apt-get install libssl-dev
Generando un paquete instalador .deb puede ocurrir el siguiente error:
vb@vk:~/xplico_0.5.4_final/xplico-0.5.4$ sudo dpkg-buildpackage -rfakeroot
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package xplico
dpkg-buildpackage: source version 0.5.4
dpkg-buildpackage: source changed by Gianluca Costa
dpkg-buildpackage: host architecture i386
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7)
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
Se soluciona sencilla e intuitivamente instalando el paquete “debhelper”:
vb@vk:~/xplico_0.5.4_final/xplico-0.5.4$ sudo apt-get install debhelper
Instalando módulos de Pear puede ocurrir, sobre todo en versiones inestables de Ubuntu, el siguiente error:
root@prueba-egroupware:/usr/share/egroupware/# sudo pear install Auth_SASL
pear.php.net is using a unsupported protocal - This should never happen.
install failed
Se soluciona borrando los repositorios extras que vienen por defecto añadidos:
root@prueba-egroupware:# rm /usr/share/php/.channels/*
root@prueba-egroupware:# pear update-channels
Updating channel "doc.php.net"
Update of Channel "doc.php.net" succeeded
Updating channel "pear.php.net"
Update of Channel "pear.php.net" succeeded
Updating channel "pecl.php.net"
Update of Channel "pecl.php.net" succeeded
Y ya quedaría listo el sistema para instalar módulos, por ejemplo:
root@prueba-egroupware:/# pear install Auth_SASL
downloading Auth_SASL-1.0.3.tgz ...
Starting to download Auth_SASL-1.0.3.tgz (5,724 bytes)
.....done: 5,724 bytes
En la instalación de eGroupware 1.6 en Debian/Ubuntu puede ocurrir el siguiente mensaje de error:
Comprobando si .././sitemgr-doc no tiene permiso de escritura para todo el mundo:
¡¡.././sitemgr-doc no existe!!
La ruta indicada parece ser equívoca, al no existir en el directorio previo un directorio llamado “sitemgr” conteniendo a otro llamado “doc”. En realidad se refiere a ./sitemgr/doc. Por tanto se soluciona adecuando los permisos de este directorio:
$ cd /usr/share/egroupware
$ sudo chmod -R 755 sitemgr
$ rm -Rf sitemgr/doc
$ mkdir sitemgr/doc
$ chmod 777 sitemgr/doc
Compilando aplicaciones, como Ghostpdl para Xplico, puede ocurrir el siguiente error:
error "X11/Xlib.h No such file or directory"
El cuals e soluciona instalando los headers de X11:
$ sudo apt-get install libx11-dev
Otro error puede ser:
In file included from ../gs/base/gdevx.c:19:
../gs/base/x_.h:133:29: error: X11/Intrinsic.h: No such file or directory
../gs/base/x_.h:134:30: error: X11/StringDefs.h: No such file or directory
../gs/base/x_.h:135:25: error: X11/Shell.h: No such file or directory
In file included from ../gs/base/gdevx.c:31:
../gs/base/gdevx.h:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gdev_x_resources'
../gs/base/gdevx.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gdev_x_fallback_resources'
Solucionable con:
$ sudo apt-get install libxt-dev libxaw7-dev
Para portar o migrar una base de datos SQL almacenada en un motor Sqlite2 hacia Sqlite3, tan solo es necesario el último binario de Sqlite3 (a fecha de redacción de este artículo, la versión 3.6.20.
Para convertirla por tanto vale con ejecutar:
$sqlite baseDatos2.db .dump | sqlite3 baseDatos3.db
De modo que el primer comando, correspondiente al binario de sqlite2, exporte la base de datos en formato estándar y sirva de entrada al binario de Sqlite3 que la creará con el nuevo formato.
En el framework Cakephp 1.2 se puede producir la pérdida de sesión aparentemente de manera aleatoria. Suele suceder cuando se cambia de página rápidamente y/o no se deja terminar la carga de una de ellas, solicitando pasar a la siguiente antes de finalizar la ejecución del código de la actual. Para evitar problemas de seguridad, Cakephp resetea automáticamente la sesión del usuario.
Para evitarlo, es necesario rebajar el nivel de seguridad de la aplicación:
$sudo nano /var/www/myApp/app/config/core.php
Cambiando a nivel medio la seguridad:
(...)
Configure::write('Security.level', 'medium');
(...)
Además, si la aplicación utiliza Ajax, es necesario poner el siguiente parámetro a false o creará una nueva sesión:
(...)
Configure::write('Session.checkAgent', false);
(...)
Fuente: Cakephp google group
Utilizando la API de Sqlite 3 en C++ puede ocurrir el caso de acceder a una base de datos y tras una consulta, quedar ésta bloqueada, produciendo un mensaje de error “database is locked” y en el caso de terceras aplicaciones, generando una consulta “SELECT name FROM sqlite_master WHERE type = ‘table’” que en nada se relaciona con la base de datos en uso. Esto se debe a que si al intentar una base de datos se produce un error, se crea una auxiliar básica que en la mayoría de las veces no sirve para nada.
En el siguiente código se puede comprobar, si se invoca dos o más veces, el error:
CÓDIGO ERRÓNEO - WRONG CODE
std::integer countCrimes (string selectedCrimeID, std::vector trainingFileSet, string pathDB){
sqlite3* db;
char* db_err;
sqlite3_stmt *stmt;
cout << "Openning DB connection" << endl;
string SQLquery = "select count(*) from crimes";
sqlite3_open_v2( pathDB.c_str(), &db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, 0);
int rc = sqlite3_prepare_v2(db, SQLquery.c_str(), strlen(SQLquery.c_str()), &stmt, NULL);
if (SQLITE_OK != rc) { cout << sqlite3_errmsg(db) << endl; //En el segundo acceso a la BD mostrará "database is locked"}
sqlite3_exec(db, SQLquery.c_str() , NULL, 0, &db_err);
sqlite3_step(stmt);
long int occurrencesFound = atoi (sqlite3_column_name(stmt, 0));
std::cout << occurrencesFound << "files hashes of crime " << selectedCrimeID << " in data base."<< endl;
sqlite3_close(db);
sqlite3_free(db_err);
return trainingFileSet;
}
Pese a que se cierra la conexión y aparentemente todo se realiza correctamente, el problema viene por no incluir la orden que indica a Sqlite que el resultado de esa sentencia SQL ya ha sido recibida y por tanto puede continuar procesando las siguientes que vengan, ya que la base de datos se queda bloqueada por la actual sentencia sql. Por lo tanto, siempre que se ejecute una instrucción, hay que utilizar el método sqlite3_finalize(stmt) para no dejar bloqueada la base de datos.
std::integer countCrimes (string selectedCrimeID, std::vector trainingFileSet, string pathDB){
sqlite3* db;
char* db_err;
sqlite3_stmt *stmt;
cout << "Openning DB connection" << endl;
string SQLquery = "select count(*) from crimes";
sqlite3_open_v2( pathDB.c_str(), &db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, 0);
int rc = sqlite3_prepare_v2(db, SQLquery.c_str(), strlen(SQLquery.c_str()), &stmt, NULL);
if (SQLITE_OK != rc) { cout << sqlite3_errmsg(db) << endl; }
sqlite3_exec(db, SQLquery.c_str() , NULL, 0, &db_err);
sqlite3_step(stmt);
long int occurrencesFound = atoi (sqlite3_column_name(stmt, 0));
std::cout << occurrencesFound << "files hashes of crime " << selectedCrimeID << " in data base."<< endl;
sqlite3_finalize(stmt);
sqlite3_close(db);
sqlite3_free(db_err);
return trainingFileSet;
}
Fuentes: Igor Tandetnik, DMertl
Compilando un proyecto con las librerías Boost se pueden producir simultaneamente los siguientes errores:
Description Resource Path Location Type changes meaning of ‘special_values_parser’ from ‘class boost::date_time::special_values_parser<date_type, charT>’ MyProject line 34, external location: /usr/include/boost/date_time/special_values_parser.hpp C/C++ Problem
Description Resource Path Location Type declaration of ‘void boost::date_time::date_input_facet<date_type, CharT, InItrT>::special_values_parser(boost::date_time::special_values_parser<date_type, charT>)’ MyProject line 560, external location: /usr/include/boost/date_time/date_facet.hpp C/C++ Problem
Son debidos a un cambio de versión de GCC. Por tanto, las soluciones serían:
Como workaround, añadir el parámetro “-fpermissive” en la compilación para convertir este tipo de errores en warnings.
Aunque resulte evidente, lo más conveniente es arreglar el código para cumplir la normativa de GCC, según se indica en el apartado GCC Name lookup changes. En el caso de Boost, basta con actualizar las librerías Boost a la versión 1.40 o posterior (aunque puede que el bug se halla solucionado en previas versiones). En el caso de Debian/Ubuntu se pueden localizar los paquetes aquí ó en el siguiente repositorio:
deb http://ftp.de.debian.org/debian sid main
