20111130

Con la guardia baja

Lo reconozco. No todos los días está uno con la guardia bien alta, y cuando por despiste o cansancio la bajas un poco, toma hostiazo!!!
Resulta que el día de hoy no es que haya sido especialmente duro, pero sí que acumulo demasiada mierda en la cabeza por lo profesional y también en lo personal y eso, pues no ayuda a estar lo lúcido que hace falta para afrontar las tonterías diarias de los $lusers.
Venía yo de otra sede cuando sólo restaba algo menos de una hora para terminar la jornada, y venía con esas prisas y ese sudorcillo propios de tener más lío que tiempo para desliarme. Caminaba derecho hacia la syscave,  cueva en la que normalmente me refugio de los $lusers, cuando al pasar por el despacho de Mr. Om oigo algo que me pone en alerta.
Mr. Om es alto, delgaucho y dergabao. Tiene un andar tranquilote, con pasos laargos y arrastra los talones con cada zancada. Pinta las pocas canas caracoleadas que le asoman entre sesión y sesión de JustForMen, todas ellas y los demás también peinados hacia atrás con más grasilla que gomina. Se apoya sobre la mesa con los antebrazos cruzados de forma que aunque usa el ratón con la diestra, lo tiene colocado más bien a la siniestra. Si preguntas por él a los demás $lusers no creo que muchos sepan decirte a qué se dedica y pocos que no sepan decirte a que no. Yo lo clasifico dentro del grupo de los indios, debido entre otras cosas a que pasa la mayor parte del tiempo echando humo, sentado contemplando la pantalla del PC como si estuviese ante la tele de los Poltergeist y estuviese viendo algo más allá, o con el resto de vacas sagradas haciendo piña en el bar.
A la puerta de su despacho estaba la Sra. Potato, sujetando el saco que mal esconde su fealdad con una basta cuerda de esas que llevan los monjes de clausura. Es curioso porque a pesar de tener pinta de ser un juguete de plastilina maltratado por un niño cabroncete, es un cuervo, negro y oscuro en todo lo que hace, dice y piensa.
No me ve llegar y justo cuando paso junto a ella la oigo graznar:
- Qué coño! Cómo los desgraciaos estos no nos dejan instalar programas aquí no hay quién trabaje.

Vaya argumento de mierda. Me ve justo cuando termina el graznido y se aleja mientras mueve las piernas y la grasa que se adivina bajo el saco, como bailando al son de músicas distintas.
Al su vez, Mr. Om sale de su hechizo televisivo y me espeta un:
- Oye, échame una mano con esto.
- Tranquilo majo, que suelto el petate en la syscave y vengo enseguida.

Miro la pantalla del teléfono y sólo tengo 3 llamadas perdidas, tampoco es tanto! Vuelvo y comienza el show:
- Dime, qué pasa?
- Que quiero abrir esto que me ha enviado correos y no me deja.
- A ver, ¿qué es lo que quieres abrir?

Mientras señala la única ventana que flota sobre el escritorio de su Microsoft Windows XP con varios cores, me muestra lo holgazán y a su vez zoquete que es haciendo clic repetidamente sobre uno de los archivos que muestra 7zip todavía sin descomprimir, uno con el icono de Adobe PDF.
- ¿Qué narices es eso?
- Es de la empresa de mensajería, y lo tengo que abrir.
- A ver, déjame un momento. 

Descomprimo el paquete en una carpeta sobre el escritorio, y le digo que pruebe de nuevo, sobre lo que supongo es un nuevo programa para generar etiquetas postales o algo así. Se encorva de nuevo, y comienza el ritual, cruce de manos, ojillos hipnóticos, y clic, clic, clic.
- Nada, lo ves?
- Venga, levanta y déjame que tengo mucho lío y poco tiempo que perder.

Me siento y sin pensar voy a lo fácil.
Inicio -> Ejecutar -> cmd y pulso intro.
runas /user:administrador cmd.exe
cd c:/Documents and Settings/mrom/Desktop/mesajeria/
etiqueta.exe

Nada, ni sensación. El cursor muestra el reloj de arena, la flecha y el cursor de arena de nuevo tras unos instantes.
- ¿No tiene esto instrucciones? ¿Donde están?
- No, venía sin instrucciones.
- Ya, y quién te lo ha traído?
- Me lo han enviado por email.
- A ver que lo vea.

Me lo enseña y se me queda la misma cara de lerdo que a él, y no es debido a un contagio por proximidad. Tras leer el contenido del email veo claramente lo sucedido. Miro el remitente pero no me cuadra, CRTL+U para ver el mensaje sin formatear y ahora está claro al 110%.
- ¿Pero tú esperabas este email?
- No, bueno sí, aunque no sé si ese. He pedido un paquete y como me ha llegado ese email, y ponía que no había nadie en la dirección de recogida pues quería imprimir el recibo, aunque me lo envían aquí a la oficina.
- Y claro, eso no te ha parecido raro, porque como no os aviso de estas cosas.

Y me callo por no escupirle a la cara cuatro verdades, para centrarme en lo que estoy, y porque se la han metido a él, y en parte también a mi como administrador, ni más ni menos.
Abro el navegador y apunto a www.virustotal.com, subo el archivo, y el aviso de que ese MD5 ya está en su base de datos, me avisa de lo que ya sabía. Virus!!! según más de la mitad de los motores lo detectan como tal, y por supuesto, y como el puto Murphy me ronda últimamente, nuestro antivirus corporativo no es uno de ellos. Y la muy cerda gruñendo porque no pueden instalar programas!!!
- Ala! Cagada del 12!!
- Apaga el ordeñador y me lo llevas al taller. 
- ¿Qué pasa?
- Que no hacéis ni puto caso a lo que os digo coño!! Y que te quedas sin PC hasta nuevo aviso. Mañana si tengo tiempo lo intento limpiar o te pongo otro y empezamos con este from scratch.

Lo reconozco, culpa mía, de poco valen las excusas, me han pillado con la guardia baja, y zas!!! en toda la boca!!!

Ahi alguien ahí?

20111129

Thunderbird: autoguardar adjuntos - Thunderbird: autosave attachments

Hoy, y después de que unos días atrás introdujese a un $luser en el mundillo de los filtros del cliente de email Mozilla Thunderbird, me ha preguntado si era posible guardar los adjuntos de los correos recibidos cuyo remitente fuese uno en concreto.
La verdad es que no tenía ni idea (y menos mal, que si lo supiese todo igual o era insoportable, o iba por ahí soltando babas y con un embudo en la cabeza), así que me he tirado (no literalmente) a Google y he encontrado la extensión o complemento AttachmentExtractor que, como su nombre indica, pues extrae adjuntos!
Entre las opciones que nos ofrece se encuentran:
  • extraer todos los adjuntos de los mensajes seleccionados
  • autoguardar en una carpeta ya seleccionada, los adjuntos de los mensajes después de recibirlos

La cosa es que este $luser en cuestión necesitaba hacer esto sólo con los mensajes enviados por un remitente en concreto. Pues bien, la extensión nos permite autoguardar los adjuntos de los mensejes con una etiqueta determinada, así que lo que he hecho ha sido lo siguiente:
  1. crear la etiqueta Extrated
  2. crear un filtro para para que etiquete y mueva a una carpeta de la bandeja de entrada los mensajes del remitente en cuestión
  3. configurar AttachmentExtractor para que autoguarde después de recibir, los adjuntos de los email etiquetados como Extracted. Esto se configura en las opciones de la extensión -> Extraer automáticamente y he marcado:

Y a funcionar. A que mola?

Today a $luser, after introduce him into the Mozilla Thunderbird tags' world, asked my about the posibility of autosaving the attachments of the incoming emails. After few seconds wearing my best poker face, I was searching the web looking for the answFew seconds wearing my best poker face, I was searching the web looking for the answer! An it name is AttachmentExtractor, an extension that allows you to autosave the attachment of a group of selected emails.er! An its name is AttachmentExtractor, an extension that allows you to autosave the attachment of a group of selected emails, and more. But $lusers are $lusers and the more you work the less they do! And he needed to autosave just some of the new incoming emails so I have to use my fly's brain and configure his mail client to do the following:
to create the tag Extracted
to configure a filter to mark the dessired email with this label
to configure AttachmentExtractor to autosave the attachments of the incoming emails marked as Extracted (look at the picture above)

And ta-dah!!!

PS. Is there anybody out there? Help me with my English and correct my mistakes! Thanks a lot.

20111125

Scripting: copiando datos a la red - Scripting: backup your data to the network

Tengo dicho una y mil veces a los $lusers de mi organización, que guarden en la red aquellos emails que puedan echar de menos en caso de pérdida. Sí, lo śe, pero me niego a hacer backup de toda la basura que envían y reciben. No somos Google ni mucho menos, así que ¿para que hacer copia de tal cantidad de mie_da?
La cosa es que pedirles que hagan copia de sus favoritos y su libreta de direcciones quizás sea demasiado, así que, teniendo en cuenta que principalmente usan Internet Explorer y Mozilla Firefox para guarri-navegar por la red de redes, y Mozilla Thunderbird como cliente de correo corporativo, he añadido el siguiente script al de logon de Active Directory, con el que copio los archivos a su unidad de usuario de red:
@ECHO OFF
SET BACKUP_DIR=u:\backup
REM Creación de directorios
IF NOT EXIST %BACKUP_DIR% MKDIR %BACKUP_DIR%
IF NOT EXIST %BACKUP_DIR%\ie mkdir %BACKUP_DIR%\ie
IF NOT EXIST %BACKUP_DIR%\ffox mkdir %BACKUP_DIR%\ffox
IF NOT EXIST %BACKUP_DIR%\tbird mkdir %BACKUP_DIR%\tbird
ATTRIB +H %BACKUP_DIR%

REM Backup favoritos de IE
xcopy /q /e /y "%USERPROFILE%\Favoritos" %BACKUP_DIR%\ie\ > NUL
REM Backup marcadores de Firefox
FOR /f "tokens=1 delims=(=" %%G IN ('dir /s/b/a  "%APPDATA%\Mozilla\*.sqlite"') DO copy /y "%%G" %BACKUP_DIR%\ffox > NUL
REM Backup libretas de direcciones de Thunderbird
FOR /f "tokens=1 delims=(=" %%G IN ('dir /s/b/a  "%APPDATA%\*.mab"') DO copy "%%G" %BACKUP_DIR%\tbird > NUL

Por si a alguno le sirviese de ayuda!


"Our SAN will never store the rubbish you store in your mail boxes". I've said that once and again to the $lusers of my organization. If once a year the recieve an important mail they have to save it on the network where the backup proccess will protect them from themselves, but to asking them to save their bookmarks and addressbooks is too much! 
Internet Explorer y Mozilla Firefox are the clients the use to browse the web and Mozilla Thunderbird is the mail client we use so I've added the folloging lines to the Active Directory logon script:
@ECHO OFF
SET BACKUP_DIR=u:\backup
REM Making the backup directories
IF NOT EXIST %BACKUP_DIR% MKDIR %BACKUP_DIR%
IF NOT EXIST %BACKUP_DIR%\ie mkdir %BACKUP_DIR%\ie
IF NOT EXIST %BACKUP_DIR%\ffox mkdir %BACKUP_DIR%\ffox
IF NOT EXIST %BACKUP_DIR%\tbird mkdir %BACKUP_DIR%\tbird
ATTRIB +H %BACKUP_DIR%

REM Backup IE favorites
xcopy /q /e /y "%USERPROFILE%\Favorites" %BACKUP_DIR%\ie\ > NUL
REM Backup Firefox bookmarks
FOR /f "tokens=1 delims=(=" %%G IN ('dir /s/b/a  "%APPDATA%\Mozilla\*.sqlite"') DO copy /y "%%G" %BACKUP_DIR%\ffox > NUL
REM Backup Thunderbird addressbook
FOR /f "tokens=1 delims=(=" %%G IN ('dir /s/b/a  "%APPDATA%\*.mab"') DO copy "%%G" %BACKUP_DIR%\tbird > NUL

I hope it helps you!

PS. I know, I know. My English is not good enought but, the more you help me, the more I learn.

20111121

Kate en modo VI - Using Kate as VI

Ave geeks!
Si eres uno de esos a los que alguna vez se le ha colado un :wq utilizando el editor de textos de KDE Kate estás de suerte, porque aunque no hay cura para los vi-maníacos, podemos configurar Kate para que se comporte de forma similar a VI.
Para ello sólo tenemos que a Preferencias -> Configurar Kate -> Edición y en la pestaña Modo de entrada de VI encontramos lo que buscábamos.
Disfrutadlo con mesura que engancha!

Hi geeks!
I you are one of those who write :wq at least once a week using the Kate, the KDE text editor, this post is for you. There's no cure for that, or not jet, but you can customize Kate to work as VI.
Go to Settings -> Configure Kate -> Editting -> VI input mode
There you'll find everything you were looking for.
Enjoy it!

PS. I know, I know. My English is not good enought but, the more you help me, the more I learn.

20111119

Forzar chequeo de disco al reiniciar - Force check disk on next boot

Estos días he querido realizar un chequeo de los discos de un servidor GNU/Linux con particiones ext4, principalmente porque lo he pasado de físico a virtual y quería comprobar la integridad de estos.
Para hacerlo he utilizado la herramienta tune2fs que permite ajustar determinados parámetros de los sistemas de archivos ext2/ext3/ext4.
Normalmente el chequeo de discos se produce por los siguientes motivos:
 - se detecta algún problema y se chequea para eliminar inconsistencias
 - se ha alcanzado el tiempo máximo entre chequeo y chequeo (Check interval)
 - se ha alcanzado el número máximo de montajes (Maximun mount count)

Para ver estos parámetros introducimos lo siguiente en la consola, siendo /dev/sda1 nuestro fylesystem:
bdispatcher@server:~$ sudo tune2fs -l /dev/sda1

Lo que nos devuelve la información del sistema de archivos /dev/sda1 y que entre otras cosas contiene:
tune2fs 1.41.11 (14-Mar-2010)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          3c30b294-a5f9-43d5-a679-ec12fee8f013
Filesystem magic number:  0xEF53
Default mount options:    (none)
Filesystem state:         clean
Filesystem OS type:       Linux
Mount count:              8
Maximum mount count:      34
Last checked:             Sat Oct 29 12:44:27 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Apr 26 12:44:27 2012

Así que para forzar el chequeo en el próximo reinicio podemos cambiar cualquiera de esas condiciones. En este caso, cambiaremos el número de veces que se ha montado el filesystem:
bdispatcher@server:~$ sudo tune2fs -C 35 /dev/sda1
tune2fs 1.41.11 (14-Mar-2010)
Se pone la cuenta de montajes actual a 35
bdispatcher@server:~$ sudo tune2fs -l /dev/sda1 | grep -i mount
Last mounted on:          /
Default mount options:    (none)
Last mount time:          Sat Nov 19 15:48:33 2011
Mount count:              35
Maximum mount count:      34

Si queremos chequear todos los fylesystems, podemos optar por lo siguiente:
bdispatcher@server:~$ sudo touch /forcefsck

Con esto conseguiremos que en el próximo inicio se haga un chequeo completo de todos los fylesystems. El fichero forcefsck se borrará cuando termine el chequeo.

Agur!


Last week I wanted to check the filesystems of GNU/Linux box with ext4 partitions,  because I've migrated it from phisical to virtual (P2V).
To do that I used the tune2fs command which allows you to adjust tunable parameters on ext2/ext3/ext4 fylesystems.
Normally a fylesystem check occurs for the following reasons:
 - some inconsistency detected
 - the check interval has expired (Check interval)
 - the max mount count has been reached (Maximun mount count)

To show these parameter of the /dev/sda1 fylesystem, let's enter the following on a console:
bdispatcher@server:~$ sudo tune2fs -l /dev/sda1

And this is a brief summary of the info we get:
tune2fs 1.41.11 (14-Mar-2010)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          3c30b294-a5f9-43d5-a679-ec12fee8f013
Filesystem magic number:  0xEF53
Default mount options:    (none)
Filesystem state:         clean
Filesystem OS type:       Linux
Mount count:              8
Maximum mount count:      34
Last checked:             Sat Oct 29 12:44:27 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Apr 26 12:44:27 2012

So to force the filesystem chek on next boot we could change one o those conditions. In this case we'll change the Mount count value:
bdispatcher@server:~$ sudo tune2fs -C 35 /dev/sda1
tune2fs 1.41.11 (14-Mar-2010)
Setting mount count to 35
bdispatcher@server:~$ sudo tune2fs -l /dev/sda1 | grep -i mount
Last mounted on:          /
Default mount options:    (none)
Last mount time:          Sat Nov 19 15:48:33 2011
Mount count:              35
Maximum mount count:      34

We can also force a full filesystem check just 'touching' the following file:
bdispatcher@server:~$ sudo touch /forcefsck

After entering this command will get a full fylesystem check on the next boot. The  forcefsck file will be deleted on the next boot.

Ciao!

PS. I know, I know. My English is not good enought but, the more you help me, the more I learn.

20111105

Modo VI en la línea de comandos - VI mode on the command line

Desde los primeros días de mi primer trabajo en el que tuve que enfrentarme con la consola de equipos GNU/Linux me acostumbré, por consejo de un ex-jefe y amigo, a utilizarla en modo de comandos vi.
Para conseguir esto, basta con introducir lo siguiente:
set -o vi

A partir de ese momento, la consola funciona como el editor vi, así tienes un modo de inserción y un modo de ejecución de comandos. Desde este, por ejemplo, puedes realizar búsquedas en tu historial de comandos, como si buscases dentro de un documento de texto con vi.
Para volver al modo habitual, introduce lo siguiente:
set -o emacs

Por defecto los sistemas suelen venir en modo emacs, por lo que si como yo, prefieres el modo vi, puedes hacer que sea el predeterminado añadiendo la siguiente entrada al fichero /etc/inputrc:
set editting-mode vi

A disfrutarlo (o sufrirlo según el caso ;P)

Since first days I start working with GNU/Linux I got used to type and work with the vi mode enabled on the command line. To achieve this, just type the following:
set -o vi

Once you have change into the vi mode, the command line works as the vi editor, so it has the insert and the commands modes to work with. So if you, for instance, wants to search for a recently typed command, you can look for it on the same way you'll do on the vi editor.
To return to the previos configuration, just type:
set -o emacs

By default, the systems use to be configured on the emacs mode, but if you like the vi mode, you can do it the the default mode just adding to the /etc/inputrc the following line:
set editting-mode vi

Enjoy it (or suffer with it ;P)

PS. I know, I know. My English is not good enought but, the more you help me, the more I learn.

20111102

Yum GLib-CRITICAL error

Uno de estos días, intentando instalar un paquete en uno de los equipos CentOS (en este caso era un CentOS 4.2 bastante antiguo) que tengo, me he encontrado con el siguiente problema:
[root@server usuarios]# yum search package
Searching Packages:
Setting up repositories
Reading repository metadata in from local files
(process:21149): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): assertion `timer != NULL' failed
(process:21149): GLib-CRITICAL **: file gtimer.c: line 88 (g_timer_destroy): assertion `timer != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 97, in main
    result, resultmsgs = do()
  File "/usr/share/yum-cli/cli.py", line 596, in doCommands
    return self.search()
  File "/usr/share/yum-cli/cli.py", line 1216, in search
    matching = self.searchPackages(searchlist, args, callback=self.matchcallback)
  File "__init__.py", line 1061, in searchPackages
  File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
    self.doSackSetup(thisrepo=thisrepo)
  File "__init__.py", line 260, in doSackSetup
  File "repos.py", line 277, in populateSack
  File "/usr/lib64/python2.3/site-packages/sqlitecachec.py", line 40, in getPrimary
    self.repoid))
TypeError: Can not create index on requires table: near "NOT": syntax error

Para resolverlo lo que hice fue reinstalar el paquete yum. Antes de eso lo busqué dentro de la caché de yum en ese equipo y ahí estaba. Si no hubiese sido así, habría tenido que tirar de los mirrors de CentOS:
[root@server py]# cd  /var/cache/yum/
[root@server yum]# find . -iname "*yum*"
./update/packages/centos-yumconf-4-4.5.noarch.rpm
./update/packages/yum-2.4.2-2.centos4.noarch.rpm
./update/headers/centos-yumconf-4-4.5.noarch.hdr
./update/headers/yum-2.4.2-2.centos4.noarch.hdr
./base/packages/yum-2.4.3-3.el4.centos.noarch.rpm
./base/packages/yum-2.4.3-4.el4.centos.noarch.rpm
./base/packages/yum-metadata-parser-1.0-8.el4.centos.x86_64.rpm
./base/headers/yum-metadata-parser-1.0-8.el4.centos.x86_64.hdr
./base/headers/yum-2.4.3-4.el4.centos.noarch.hdr
./base/headers/yum-2.4.3-3.el4.centos.noarch.hdr

Y ahora sólo resta reinstalar:
[root@server yum]# rpm -Uvh ./base/packages/yum-2.4.3-4.el4.centos.noarch.rpm

Y a funcionar:
[root@server yum]# yum search fdupes
Searching Packages:
Setting up repositories
Reading repository metadata in from local files
update    : ################################################## 1760/1760
Added 1760 new packages, deleted 0 old in 12.75 seconds
primary.xml.gz            100% |=========================| 715 kB    00:10    
base      : ################################################## 1844/1844
Added 781 new packages, deleted 725 old in 9.52 seconds
primary.xml.gz            100% |=========================|  192 B    00:00    
Added 0 new packages, deleted 0 old in 0.05 seconds
primary.xml.gz            100% |=========================|  42 kB    00:00    
extras    : ################################################## 149/149
Added 59 new packages, deleted 58 old in 0.45 seconds
No Matches found


Few day ago, I was trying to install a new package on one of my CentOS box (and old CentOS 4.2 server) when I got the following message::
[root@server usuarios]# yum search package
Searching Packages:
Setting up repositories
Reading repository metadata in from local files
(process:21149): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): assertion `timer != NULL' failed
(process:21149): GLib-CRITICAL **: file gtimer.c: line 88 (g_timer_destroy): assertion `timer != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 97, in main
    result, resultmsgs = do()
  File "/usr/share/yum-cli/cli.py", line 596, in doCommands
    return self.search()
  File "/usr/share/yum-cli/cli.py", line 1216, in search
    matching = self.searchPackages(searchlist, args, callback=self.matchcallback)
  File "__init__.py", line 1061, in searchPackages
  File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
    self.doSackSetup(thisrepo=thisrepo)
  File "__init__.py", line 260, in doSackSetup
  File "repos.py", line 277, in populateSack
  File "/usr/lib64/python2.3/site-packages/sqlitecachec.py", line 40, in getPrimary
    self.repoid))
TypeError: Can not create index on requires table: near "NOT": syntax error

To solve this issue I reinstalled the yum package. I looked for it on the yum cache and there it was, but if not, I could download it from one of the CentOS mirrors:
[root@server py]# cd  /var/cache/yum/
[root@server yum]# find . -iname "*yum*"
./update/packages/centos-yumconf-4-4.5.noarch.rpm
./update/packages/yum-2.4.2-2.centos4.noarch.rpm
./update/headers/centos-yumconf-4-4.5.noarch.hdr
./update/headers/yum-2.4.2-2.centos4.noarch.hdr
./base/packages/yum-2.4.3-3.el4.centos.noarch.rpm
./base/packages/yum-2.4.3-4.el4.centos.noarch.rpm
./base/packages/yum-metadata-parser-1.0-8.el4.centos.x86_64.rpm
./base/headers/yum-metadata-parser-1.0-8.el4.centos.x86_64.hdr
./base/headers/yum-2.4.3-4.el4.centos.noarch.hdr
./base/headers/yum-2.4.3-3.el4.centos.noarch.hdr

So lets reinstall it:
[root@server yum]# rpm -Uvh ./base/packages/yum-2.4.3-4.el4.centos.noarch.rpm

And now it works:
[root@server yum]# yum search fdupes
Searching Packages:
Setting up repositories
Reading repository metadata in from local files
update    : ################################################## 1760/1760
Added 1760 new packages, deleted 0 old in 12.75 seconds
primary.xml.gz            100% |=========================| 715 kB    00:10    
base      : ################################################## 1844/1844
Added 781 new packages, deleted 725 old in 9.52 seconds
primary.xml.gz            100% |=========================|  192 B    00:00    
Added 0 new packages, deleted 0 old in 0.05 seconds
primary.xml.gz            100% |=========================|  42 kB    00:00    
extras    : ################################################## 149/149
Added 59 new packages, deleted 58 old in 0.45 seconds
No Matches found

PS. I know, I know. My English is not good enought but, the more you help me, the more I learn.