Aptitude History Tracking progress report, Week 6
In these two weeks, I focus on two points in the timeline:
a) Write code to add the history to a sqlite database, and code to retrieve the history from the database.
b) Show the history of a particular package in the GUI and terminal.
I had thought about doing this after the Mid-term evaluation, but Daniel suggested me to first work on this before implement the new undo and the redo.
For a) I redefined the database draft that had been around for some time to have a database schema like this:
History Entries
/ \
Dpkg Changes Aptitude State
In which History Entries is used to store basic information about a change (package name, date, type of change, etc.) and the rest of the details can be subdivided into tables, and depending on the type of change, use some or other tables. Similarly, the retrieve of the history from the database depends on the type of change.
In b) I added command line support, thus having the ability to view history of a package as $ aptitude history [PACKAGE ...].
For the GUI, I have based on the code made to view the files and folders (filesview), and added a subtab in the packet tab.
Following the Filesview scheme, I created the HistoryColumns class to manage columns containing historical information, the HistoryTreeView and HistoryView classes with which were implement to handle the ListStore to view the data.
For now the details shown are few, but I hope to get the proper view of the related changes (deps, suggested, etc). Besides working with the cwidget/ncurses interface in future.
Gtk Viewer
Apart from that, I was in Bogotá a few days doing the paperwork for the visa, I get the answer the next Tuesday .
The outline for the DebConf could be something like this:
Introduction
Deliverable 1: History Explorer/Viewer (What has been done so far and what is missing)
Deliverable 2: Undo – Redo (What has been done so far and what is missing)
I hope we meet in Caceres.
Aptitude History Tracking progress report, Week 4
The recording came to the public in the process of selecting of a new Principal. To which the current Principal presented to evaluate their re-election and he was elected.
Given this, the students have expressed in various ways against his re-election. Protests which the only way out that saw the direction of the university was the cancellation of the semester, extent to which students lost all the money and time invested. With the cancellation of the semester, 19 students took the main cathedral of the city and began a hunger strike and a large part establishes safeguards against the university for denying the right to education.
Yesterday the Board of Governors of the university decided to reverse the agreement that canceled the semester, but still maintains the Principal in his post, which is no solution to the crisis at the university.
I think I deviate slightly from the topic, I just wanted you to know a little the problems of the university, which is a reflection in small scale of the country, where the dictator of the moment simply to disqualify the opposition branded they as terrorist and sent to silence by force and not arguing as should be.
Since the previous report I had a more fluid communication with Daniel, in large part by the access to the repository. Most of these two weeks I have spent the time polishing the code that I made the first two weeks. Now I get the most information from the changes in dpkg and aptitude states, but recently I have been a problem presented in the order in which these data should be collected when I remove a global variable that was clearly a sign of bad programming, I am focused on circumventing this problem before proceeding. Another important change was the creation of a class to manage the database and the text logs.
For the next weeks I hope to start working on the undo and redo systems.
Aptitude History Tracking progress report, Week 2
The first important task when one wants to carry out a historical study of the behavior of a system is to determine what information you want to store and how this is going to be saved, thinking of providing an easy way to access information when needed.
In our case, we need to store the information of the packages status and the actions that have been made to them. For now I have confronted the aptitude state and the dpkg state.
We use the state of dpkg to see the changes that other applications (Apt, Synaptic, Adept, etc..) can perform on the packets.
So the first task was to create routines to save in each member of the history the information that can be collected from pkgstates and the cache, which really is not much. This process is accompanied by the function to write in the text log and the binary database. I believe that work it’s around 70-75%, missing optimization and definitions of some values.
I have been working this week on the aptitude state , creating a vector of entries which is storing the information collected from the state’s changes through the functions cleanup_after_change, apply_solution and build_selection_list from aptitudeDepCache, calling on the last function to the routine that writes the whole vector of changes made so far in the text log and the database, I think this work is located at 50%.
Plan for next weeks
For the dpkg state, optimize the functions and add to the info of each package the date when it changed. Maybe based on /var/log/dpkg.log
For the Aptitude state, finishing collecting the information about changes. For example the dep that trigger a change, groups of packets that share the same reason of change. Look at other relevant information that could be included for the trace of each package. Change the structure of the database to include information that is missing.
Summer of Code @ Debian
This year I will be participating in Google Summer of Code! My work proposal “Aptitude Package Management History Tracking” has been selected. So I will be working for Debian and my mentor will be Daniel Burrows. To give you an idea of what I will doing this summer I leave you with my proposal (without some details that are beside the point 
).
Project title: Aptitude Package Management History Tracking
Synopsis: Aptitude currently does not track actions that the user has performed beyond a single session of the program. One of the most frequent requests from users is to find out when they made a change to a package, or why a package was changed; we want to store this information and expose it in the UI in convenient locations. As a side effect, this might also provide some ability to revert past changes.
Benefits to Debian: The change history of the packages on a system has become a recurrent need for many systems administrators, who see an opportunity in this possibility to manage more efficiently the resources on their machines. The impact would be positive in many users who use Aptitude interface for APT, not only on the command line application, but also on Aptitude-GTK.
Deliverables: The module which is intended to be designed for Summer of Code 2009, will be composed of two major parts: Add the functionality for Undo – Redo changes in Aptitude (undo really exists, but is replaced with a version that uses the history) and explore the history of a particular package, in each case made the appropriate changes to the UI, to give greater facilities to users.
Project details: The main idea is to make Aptitude store and record the history of actions that an user has done on each package. By having this information and can access it in an orderly manner can be completed easily reach other goals, such as:
* Provide an easy way to find out how and why a package was installed or uninstalled on the system, changes can be made by hand, by dependency, suggested packages, conflicts between packages, etc.
* Give the possibility to undo a lot of changes in a single action, taking into account the limits of the APT system.
* Provide a mechanism for system administrators to audit the history of a package and add notes to it.
* This history should also preserve the information generated in su-to-root operations
* Also thanks to this should be easy to implement ‘redo’, something aptitude has always lacked.
The difficulty in conducting this project is not the collection of data, but it’s to define the proper way in which to store the information in the way that it can be efficient and not to overload Aptitude. It seems the best approach that can be given to this problem is that proposed by Daniel Burrows (See his ideas in [1]), in which it would have a set of text logs and a database binary simultaneously, that for readability by the user in text files and increase the efficiency of Aptitude reaching the database directly. If the database were to fail, Aptitude could scan the log to recreate the database, which also makes it necessary to write code to do the text log – database processing
Since the project can range from different points of view is necessary to discuss and define several issues with the Aptitude developers and some experienced users of Debian, for example:
* What to do with past actions of an “Undo”, delete them or preserve them.
* Whether to include also details on the history of resolver interactions.
* Define whether the record should be updated immediately changes are made or be expected to finish the session to record the actions taken.
* Establishing rules and / or tools to remove old entries in the log. For example, with the rules I am talking about erasing the old posts in the database beyond a certain age. The tools can be commands whose purpose is to delete manually the history, aptitude “remove history” to say something.
I hope this items can be defined on the first month of the GSoC to work on a fixed path to follow and not suffer setbacks, yet it would be open space for made minor changes on the fly.
As already mentioned above, the first priority is to define the structure of the database, this with the help of the SQLite library, at the end of this (the more creative phase) I begin to define a series of classes and routines necessary in principle to update the records of this database, this section should define a common set of calls that would serve both for the command line application and the cwidget-ncurses and GTK interfaces, since these classes would be accessed by aptitude when it receives the outputs the processes of APT (Maybe based on pkgstates).
As second and third period, classes should be created for the operations “undo/redo”, and for the queries for the database which will be used to display information in an orderly manner in the UI. As the ncurses and GTK interfaces are very similar in concepts (signals and slot object-oriented C++), which happens once we have the code for ncurses is that is relatively easy and quick also have support for GTK (or vice versa). The code for the command line application would be a little different but easy to implement once we have defined the needed queries. Here we must bear in mind that would work with separate packages, Aptitude and Aptitude-gtk, which required a good time for the test period.
The final set of code. Will be for fix fails in the database, generating the transformation between the text log and the binary data base. In addition to providing tools for maintenance work, which would be the least complicated part of the project, things made by the style of “delete from history where date < $somedate”.
Project schedule:
The preliminary timeline for the project, according to the schedule of GSoC:
April 20, Accepted student proposals announced
Week 1, 2 and 3:
Project initialization
Analysis of existing data model for the history entries, getting to know the coding style and documentation writing concepts. Improving communication skills and understanding the Community, discuss any outstanding issues that are mentioned in the Project details.
Install and configure the necessary software to implement the project on my computer.
Week 4: Improving the sketch of the data model, considering the corrections arising in the analysis of the past three weeks.
May 23, Students begin coding for their GSoC projects
Week 5: Implement the data model.
Week 6: Write code to convert the history entries to and from text and write unit tests for this code.
Week 7: Write code to compute the history list for the current session and store it in a member of aptitude’s cache wrapper.
Week 8~9: Write code to implement undo/redo on top of the history list and replace the current undo code for packages with the new undo/redo code.
Week ~9-10: Testing and correction of bugs discovered so far.
July 13, Mid-term evaluations deadline
Week 11: Write code to add the live history list to a sqlite cache database, and code to retrieve history from the database.
Week 12-13: Write a GUI viewer for the history list, and code to show the history of a particular package.
Week 14: Write code to generate log files in /var/log with history information.
Week 15: Write code that, if the cache database is missing, reads those log files to rebuild it.
August 10, ‘Pencils down’ date
Week 16: Extensive test case analysis whit Bug Fix.
Week 17: Final documentation improvements and some improvements in the code.
August 24: Final evaluation deadline
Project completed.
Note: The documentation is generated simultaneously with the code throughout the summer, making the necessary improvements to the final dates.
[1] http://lists.alioth.debian.org/pipermail/aptitude-devel/2008-December/001071.html
Crónica Jornadas de Software Libre 2008
Ya un tiempo después de haber pasado por el trajín de ser anfitriones de las JSL quiero dedicarle unas cuantas lineas (desde mi punto de vista) a esta labor, la que en los últimos meses se convirtió en mi preferida y fue a que le dedique mas tiempo que a cualquier otra cosa.
Foto grupal, JSL2008
Planeación, como nos las craneamos
A vista de la mayoría la labor preparativa de las JSL en Bucaramanga empezó en Medellín el año pasado en medio de unas cuantas polas, en las que Juliancho dejo salir su parentesco con el Tuerto Gil y comenzó un despliegue político/propagandístico para traernos las JSL a nuestra casa (Realmente llevábamos un buen tiempo planeando que íbamos a hacer para convencer a la gente), fue así como por varias horas discutimos con los pastusos que también se las querían llevar exponiendo argumentos y contra argumentos los unos a los otros, y como obviamente, como si se tratara de una discusión entre un ateo y un creyente, ninguna parte fue capaz de convencer a la otra dejamos la decisión para el otro día en las mesas de trabajo. Para ese domingo teníamos la carreta preparada con meses de anticipación, los designados para echarla fueron Ivan y Julian por que el resto nos aculillamos. Entonces están los dos y tratan de comenzar a hablar, llevan tan solo cinco segundos diciendo quienes son cuando de se oye un “¿De donde son?” – “de Bucaramanga” – AHHH!!! Si Si Bravo, bravo bravo… ehh!!! se decidió mientras lo pobres seguían hablando, al final nadie los escucho pero nos la trajimos para Bucaramanga, los pastusos no alcanzaron ni siquiera a hablar por que las mesas de trabajo acabaron por pupitrazo después de la histeria colectiva 
Ya de vuelta en Bucaramanga empezamos a camellarle, lo primero era definir fechas para trabajar sobre el tiempo, aun así se demoro un buen tiempo tener una fecha fija, se realizo un intento de votación por colibrí quedando para agosto, pero cometimos el error de no ver el calendario de la universidad antes de proponer las fechas de votación, coincidiendo entonces las JSL con las vacaciones de la UIS, por lo que nos quedaba imposible gestionar espacios dentro de la universidad. Para lo cual anteponiendo como excusa la falta de afluencia en la votación decidimos re-abrirla y realizamos la conocida técnica del traslado de votos, todos los cusolitas que estábamos en agosto nos pasamos para octubre y así se nos acomodaron mejor las cosas.
Entonces por esa época ya teníamos material publicitario asegurado, algunos recuerdos para los asistentes, contactos con un invitado especial, call for papers en curso, preinscripciones realizándose en la pagina web, algún dinero y con esperanzas de poder recaudar algo mas con los certificados… En fin, íbamos por buen camino. Solo nos faltaba asegurar el espacio físico en donde llevar a cabo las Jornadas para lo cual comenzamos a hacer lobby, primero en el auditorio Luis A. Calvo donde nos respondieron “Esta ocupado por el congreso de Ingeniería Industrial”. No importa, nos dijimos, entonces vamos al Ágora donde nos dijeron de nuevo “Esta ocupado por el congreso de Ingeniería Industrial”, ah! bueno vamos al auditorio de Mecánica y allá también nos encontramos con un “Esta ocupado por el congreso de Ingeniería Industrial”, y así pasamos por otros tres auditorios echándole la madre al dichoso congreso de Industrial…
En fin nos vimos otra vez obligados a un cambio de fecha, decidimos correr el evento 15 días. Lo primero fue asegurar un auditorio, seguido a esto comenzamos a cuadrar cronograma, confirmar ponentes, definir las temáticas para el foro, plantear discusiones para las mesas de trabajo, detalles de logística, etc.
Bueno hasta acá he hablado del proceso pero poco de la gente. En un principio eramos pocos ya que algunos de los que estábamos se graduaron, eramos básicamente 8 pero gracias al FLISoL y los talleres que realizamos periódicamente varias personas afines pero que no se habían involucrado mucho con la organización se nos fueron pegando y conformamos un buen equipo de trabajo. Puede ser una virtud o un defecto, pero en todo el proceso de organización del evento no tuvimos altercados entre nosotros, solo alguna que otra perla como por ejemplo la del personaje que había quedado encargado de enviar por fax las invitaciones que nos solicitaron y faltando 8 días para el evento en un charla en el IRC dice “marica, yo mañana envío las cartas de invitación, fijo!”, cartas que menos mal habíamos enviado dos meses antes ya que sabíamos que el encargado podía salir con esas. A pesar de los varios llamados por listas de correo a otros grupos o personas que quisiera colaborar fue poca la afluencia de colaboradores externos a los ya nombrados, contados con los dedos de la mano. Pero ya en el transcurso de las JSL nos enteramos de por lo menos la existencia de otro grupo en la ciudad y espero podamos coordinar con ellos para acciones futuras.
También quiero resaltar acá las personas de otras partes del país que nos colaboraron, como Kal que nos ayudo bastante en la parte web, Nonroot y Duma con el wargame, Neoecos con el asesino (que lamentablemente no se pudo realizar) y algunos premios para los juegos.
Desarrollo, como nos fue
Llego el día del evento, Viernes 31 de Octubre, llegamos todos al rededor de las 7 de la mañana para cuadrar últimos detalles. Los asistentes comenzaron a llegar puntuales, y como en todos los eventos se hacen filas enormes, menos mal fueron bastantes las personas que se encargaron de la acreditación y salimos bien librados de esto. Este día todo nos salio bien, creo que el único problema fue en el taller de virtualización ya que los equipos no tenían instalado el software requerido por los talleristas, pero para mi la instalada debería estar incluida en el taller. Paralelamente a las actividades del día tres de nosotros nos dedicamos a hablar con el sindicato de trabajadores de la universidad, ya que había rumores de ellos iban a cerrar la universidad al día siguiente. Luego de un tiempo nos confirmaron lo del cierre pero había posibilidad de que dejaran entrar a los participantes de las Jornadas. Aun así no nos confiamos y logramos conseguir otro auditorio a las 8 de la noche, el de la facultad de salud de la UIS.
Amaneció cerrada la universidad como nos lo habían dicho, y también la facultad de salud, por lo cual nos quedamos sin lugar. Hable en varias ocasiones con las directivas del sindicato obteniendo repetidamente respuestas negativas, no nos iban a dejar entrar. Decidimos esperar a que se levantara el cierre, que se tenia planeado vendría siendo a las 10 de la mañana. Pero no sucedió, en vez de esto tuvimos un roce con el sindicato y varios terminamos tildados de fachos y uribistas. Entonces nos llevamos a la gente al parque de los niños, tratando de quemar tiempo mientras conseguíamos algún lugar donde poder hacer las actividades del día. La primera opción fue alquilar un salón de festejos, que pagamos sin pensar, pero afortunadamente antes de dar esa información un amigo nos confirmo un espacio en la UNAB, discutimos entre todos en que íbamos a emplear la tarde, se decidió que en ponencias dejando la presentación de grupos y el foro para el día siguiente, citamos entonces a las 2 de la tarde. Ya en la UNAB todo se llevo a cabo a la perfección y quedamos de vernos en la noche para la tradicional Debeta.
Gracias a las influencias de algunas de nuestras compañeras los que primero llegamos terminamos escuchando vallenato y salsa, por lo cual varios de nosotros nos salimos a tomarnos unas polas en otro lado, estando en esas llegaron los paisas que rebautizaron las JSL como las Jornadas de Salsa Libre y con ellos convencimos a los otros para irnos a otro chuzo, para lo cual como es tradicional en Bucaramanga nos citamos en otro parque, y estando ya listos para entrar en un bar la mitad del parche decide abrirse y coger para una discoteca!!! bueno al final no importa porque después de emborracharnos en el bar nos fuimos para la discoteca a azotar baldosa con los que ya estaban allá
El domingo la madrugada fue dura, mas para los que nos quedamos hasta las 5 tomando, pero a las 9 ya estábamos saliendo hacia la finca/colegio para rematar la jornada. En la mañana se presentaron los grupos con mucha gente nueva y buenas ideas terminando casi a la una por lo cual todos salieron directo a comer lechona y llenar el estomago. Después de su correspondiente locha e integración al rededor de un balón, una piscina o un frisbee convocamos a las mesas de trabajo. Para saber lo que se hablo en las mesas lo mejo es ver la relatoría y las conclusiones. Ya terminada la discusión siguio el final y algunas despedidas.
Conclusiones, que nos quedo
Trabajar con personas comprometidas es lo mejor que se puede hacer en estos casos, nosotros lo hicimos de una forma excelente, creo que ninguna responsabilidad adquirida se evadió (aunque alguno que otro evadió tener responsabilidades ) a la vez que trabajamos siempre teniendo en cuenta el tiempo, por lo cual fueron pocas las que quedaron para lo ultimo pero al ya tener una persona encargada de esa dichas labores todo funciono, lo único fue algo que se nos salio de las manos como el cierre por parte del sindicato, para el cual fue como el plan Z el que nos termino funcionando.
Hablando de dinero, los certificados nos sirvieron mucho, financiaron los gastos debidos alcanzando hasta para subsidiar algo del costo del traslado y la comida del Domingo, definitivamente algo a tener en cuenta para las próximas JSL aunque les de pinta de un evento mas formal, no termina siendolo.
El wargame y los demás juegos tiene que estar definidos y montados con varios días de anticipación, por dejarlos para ser montados el día del evento solo pudimos jugar dos tardes al wargame y el asesino no se pudo realizar (Preinscripcion web para los juegos?)
Ya solo me quedaría agradecer todos los que hicieron posible este espacio, no solo a los organizadores y colaboradores, cada cual sabe el rol que desempeño, sino también a los asistentes ya que las JSL las hacen los que vienen, por que como organizador se esta prácticamente ocupado todo el tiempo y no podemos participar de la forma que quisiéramos, aun así me las goce.
