Planet SoC -

Aptitude 0.5.0 (aka Aptitude-gtk) released

ObeyArthurLiu — Wed, 12 Nov 2008 10:31:22 +0100

Long time no post. Anyway, I have some good news.
The Gtk code for Aptitude has been merged some time ago into the main development trunk and we now have a release in Experimental.

For those that don’t know about it, here’s what it’s all about : “The new frontend is is an effort to bring some of the design principles of the curses frontend to a GUI environment, while also exploiting the unique features a GUI gives us and exploring ways to deal with changes in the environment in the nine years since aptitude was first designed.”
I had a very good time this summer working on Aptitude with Daniel Burrows in the Google Summer of Code program and I’m very glad we now have a real release. This version is by no means final or perfect but it’s a good start.
Head for the blog post from Daniel for some other informations : [Daniel Burrows]

Going to London - Cambridge

ObeyArthurLiu — Sun, 17 Aug 2008 23:56:26 +0200

I’ll be in Great Britain next week. I’ll come to the Debian Party 2008 in Cambridge on Saturday 23rd August and will be back to London to visit ’till Wednesday 27th August. I’m staying by myself in a nice little hotel in Bloomsbury.
It will be very interesting to meet Debian people and probably do some pitching for my Aptitude GTK project which is making nice progress.

I’ve never been to London before. In fact, I’ve been once when very young and all that I can remember is that the hot dogs seemed nice :). I’m currently reading the Lonely Planet book about London and filling my program. Hi, London!

State of the Aptitude (week 12)

ObeyArthurLiu — Wed, 13 Aug 2008 13:00:34 +0200

Hi folks!
We’re almost done for the official Summer of Code program and I thought that I couldn’t let it end without another update, so here we are (you may thank Daniel Burrows for additional poking).
The Gtk+ interface for Aptitude is making great progress. The product is not final yet but already implements many of the planned ideas, with others to come.
Here are the screenies:

So, let’s see the tasks presented in my previous update:

A real user interface <- much progress here
Being reliable… <- check! we don’t crash all the time anymore
Packages dependencies, pre-dependencies, etc. <- check!
Hyperlinks between packages <- check!
Advanced package search <- check!
Tags support (tag clouds ?) <- well, no clouds yet, but we have tags
Linking with interesting data sources like popcon <- not done yet
A lot of interesting things <- well..

In some more details: we are now much closer to the final interface. Some things are not done yet, for example, notification bars à la Iceweasel (or is it Firefox ?) are in the works for unobtrusive notifications about important things and a little guidance.
We are much more reliable now. We eliminated lots of memory management problems that resulted from, mmh, imperfect coding discipline. We also lock the interface when important backend stuff reload to prevent the user from shooting himself in the foot when triggering an install when the APT cache is reloading for example.. The backend refactoring took a sizable part of this second term but it was worth it. The code is now much cleaner and uses no more (at least much fewer) ugly unscalable hacks.
One very important feature of Aptitude is the ability to easily display all kinds of dependencies and navigate through them by hyperlinking. It’s now working in the Gtk+ interface as well. Feel free to click on whatever looks like a package or a package version.
We now support the powerful Aptitude package searching syntax. Daniel Burrows is talking with Enrico Zini to bring the power of apt-xapian-index to Aptitude: autocompletion! lightning fast full-text searches! tag clouds! ponies!
There is still a lot to be done. I’m not going away after the GSoC program. I’m here to stay, for Aptitude and Debian. Daniel Burrows has been very helpful and supportive. The Debian community is as awesome as I knew it before participating in the program.
Daniel Burrows is planning to merge the Gtk+ interface into the main branch in September and packages may appear into Experimental. With the very interesting evolutions of the upcoming Adept-3, Lenny+1 will show very interesting changes in the area of packages managers.
Now for you. I need you to test my interface. All necessary instructions are on the development trac : http://dev.graffit.net/aptitude/trac.

Back from Zurich

ObeyArthurLiu — Sun, 13 Jul 2008 12:37:57 +0200

I finally got back from Switzerland. Google invited all the Summer of Code students to visit their offices. I chose to go to the Zurich one. It wasn’t the closest (London was) but it was the largest and it had more engineers than MBAs.

It has been very interesting meeting other Summer of Code participants from all Europe and a lot of other people of the free software community. There were about 40 people overall for the meeting at Google, along with free beer, cake and nice food.

I gave a talk about Aptitude, how it could be useful and how I worked so far. It was nice to see that nearly a third of the audience used Debian or a derivative.
By the way, the proprietary Nvidia X driver seriously messed up with the projector. It just wouldn’t detect the external display at more than 640×480, which Impress didn’t like at all. I didn’t feel like hacking around my xorg.conf while on stage so I went without the slides (well, you could see about a half of each slide actually). I heard that it was because of my old GPU (GeForce 7400) that I had poor support and the impossibility of, for example, doing RandR correctly. I had to restart X and stuff…
The talk went smoothly otherwise and Google staff graced some of us with a guided visit of the 6 stories building, complete with slides, cable-cars and 18th century-themed rooms. I had to sign a NDA over whatever secrets I may see and surender my DSLR, but you can find pretty pictures in this blog post from Valleywag.

The Google office really lived up to the hype. I wondered: do people actually work in there ? I guess they must do, and very well.

Back from Zurich

ObeyArthurLiu — Sun, 13 Jul 2008 12:37:57 +0200

11 Jul 2008

acjensen — Fri, 11 Jul 2008 17:25:01 +0200

Yesterday, 10 July, was the due date for the second
milestone of my work on DebGraph. I am happy to report that
we are roughly two weeks ahead of schedule, so meeting this
milestone was not a cause for worry.

We now have support for the following graph operators:

Difference
Intersection
Filter (by properties)
Find Cycles (via Tarjan’s
algorithm)
Find Dependencies
Find Reverse Dependencies
Symmetric Difference (XOR)
Union

The next milestone includes the development of a high-level
language (or integration with an existing extension
language) that streamlines the construction of complex
queries using the operators listed above. We can build
arbitrarily complex queries using the C++ operators, but
dealing with the static typing and compiler toolchain can be
very clunky. As such, I have spent the past week working on
Lua bindings for DebGraph, which will enable us to query the
graph of Debian packages from a clean, dynamically typed
language. Lua has a powerful C API that exposes the Lua
stack and lets us move DebGraph information to and from the
Lua interpreter. I’m writing documentation that outlines
how to use DebGraph from both C++ and Lua in order to make
this work accessible to more folks.

Sneak peak

As an example, we can utilize the FindCycles operator in Lua
as follows:

libdg = package.loadlib("./libdebgraph.so",
"luaopenlibdebgraph")
libdg()
LoadPackages('cache')
-- 'g' is the main graph of unstable binary-arm packages
cycles = FindCycles(g)
print("Found " .. #fc .. " cycles")
for compkey,comp in pairs(cycles) do
    compnodes = ""
    for nodekey,node in pairs(comp) do
        prop = GetProperty(node, "Package")
        compnodes = compnodes .. prop .. " "
    end
    print("* " .. comp_nodes)
end

The above Lua script produces the following result:

reading cache/unstable/main/binary-arm/Packages
Found 61 cycles
* debconf-english debconf-i18n debconf
* perl-modules perl 
* cdebconf fontconfig-config fontconfig gsfonts-x11
libcairo2 libfontconfig1 libgtk2.0-0 libpango1.0-0
libpango1.0-common libxft2 ucf x11-utils xutils
[...]

These are the package names in the strongly connected
components, shown in alphabetical order.

There is still a lot of work to do before the Lua binding
will achieve feature parity with the core library, but we
have now laid the foundation (and a brick or two).

Going to Google Europe HQ, Zurich, Switzerland

ObeyArthurLiu — Thu, 10 Jul 2008 00:48:49 +0200

I’m going to the Google Europe Headquarters in Zerich, Switzerland, tomorrow (July 10th).
Google is inviting us Summer of Code students, which is really nice.
I should be there in the middle of the afternoon from Paris.
I’ll be wearing a Slashdot tshirt. Drop me a mail or a comment if you go too so we can meet!

State of the Aptitude (week 7)

ObeyArthurLiu — Thu, 10 Jul 2008 00:39:10 +0200

New status update!
Here’s what Aptitude looks like:

(more screenshots after the break)
I’ve been exploring how the APT libraries work and how to interact with the aptitude back-end and here’s what it can do now:

Update package lists
Display package lists
Basic package search
Mark packages for install/remove/purge/keep/hold
Display package actions for execution
Display conflicts
Display and navigate between package conflict solutions
Apply them
Execute package actions (ie. actually install stuff)

What’s missing:

A real user interface
Being reliable…
Packages dependencies, pre-dependencies, etc.
Hyperlinks between packages
Advanced package search
Tags support (tag clouds ?)
Linking with interesting data sources like popcon
A lot of interesting things

Basic functions of a package manager are already covered. We’re still at the APT API exploration phase although we’re almost done with it. I will soon start working on the final user interface and the real code design.
The current code is about 2000 lines of hastily hacked together C++ and XML. I’ll have to restart the coding with a more elaborate Object design. Something that will be easier to work with in the future.
The code is on http://dev.graffit.net/aptitude/trac. You can try to compile it and play with it. On the other hand I’m going to scrape most of the code soon for the restart so if you’re bored..
A walkthrough and more screenshots after the break.

Here’s a walkthrough of what you can do right now:

State of the Aptitude (week 7)

ObeyArthurLiu — Thu, 10 Jul 2008 00:39:10 +0200

Update package lists
Display package lists
Basic package search
Mark packages for install/remove/purge/keep/hold
Display package actions for execution
Display conflicts
Display and navigate between package conflict solutions
Apply them
Execute package actions (ie. actually install stuff)

What’s missing:

A real user interface
Being reliable…
Packages dependencies, pre-dependencies, etc.
Hyperlinks between packages
Advanced package search
Tags support (tag clouds ?)
Linking with interesting data sources like popcon
A lot of interesting things

Here’s a walkthrough of what you can do right now:

Daniel Burrows on cwidget-gtk

ObeyArthurLiu — Tue, 24 Jun 2008 07:28:15 +0200

Sometimes people propose other solutions to have the Aptitude-gtk project done, like :
I’d have thought that the most interesting way of doing aptitude-gtk would be to write a gtk backend for libcwidget. -Karellen
As this might be of interest to more people, I’ll repost Daniel Burrows‘ response :
Although I can see where you’re coming from, a GTK+ backend to cwidget would have no significant upsides and significant downsides.
The main upside to doing that from a practical point of view is that you would have only one piece of “driver” code for the GTK+ and curses interfaces. You wouldn’t have to rewrite the entire interface from scratch to create a GUI frontend.
But this is just an illusory benefit. cwidget is a terminal interface library and aptitude’s curses frontend is a terminal-based UI. From a practical point of view, this means that aptitude regularly assumes that, for instance, to clear out a line it’s sufficient to output $WIDTH space characters (ASCII 32) with the desired background style. A port of cwidget to GTK+ would have to introduce new, interface-independent abstractions for all operations like this and eliminate all direct use of terminal-based assumptions, at a significant cost in complexity for both cwidget and the aptitude frontend. In order to transition to these new conventions, I believe you would have to rewrite large portions of both cwidget *and* aptitude in order to make the interface abstraction layer work. (remember: the justification for doing this is to avoid having to rewrite aptitude!)
Furthermore, while this approach avoids reimplementing aptitude’s curses interface (sort of, except where it doesn’t — see above), it does so at the cost of requiring you to reimplement all of cwidget, for GTK+. I just did a quick line count (with “wc -l”): in all of cwidget there are 23,390 lines of code, while aptitude’s curses frontend has around 23,359 lines of code (some of which are actually shared with the other frontends but are in the curses directory due to the historical organization of the code tree). Not only is a rewrite of cwidget more involved, but the amount of code you’d have to replace is comparable to the amount implicated in a rewrite of aptitude itself!
Finally, even if these costs weren’t enough to eliminate the idea, it’s not at all clear to me that a GTK+ backend for cwidget is even desirable. Although aptitude has some superficial similarities to a GUI program, the process of designing an interface to run in a terminal (where the available input mechanisms are relatively restricted and all output is to a character-cell grid) is rather different from the process of designing a GUI. GUI programs can’t rely on some simplifying assumptions that terminal programs can, and at the same time they have a lot more options available to them (just to name a few: graphics, multiple windows, differing text sizes and rotated text). Trying to force everything through an abstraction designed for terminal output would require you to either

eschew those options,
provide abstract GUI components that somehow “fell back” to terminal rendering in a terminal, or
add ways for the frontend to extend the abstract widgets with custom functionality.

1. is not an option because I (and, I think, Arthur) want to design a good GTK+ package manager, not a good GTK+ imitation of a console package manager. 2. and 3. amount, in my strong opinion, to writing two separate interfaces but intertwining their implementations in a mass of maintenance-resistant and extension-resistant spaghetti code.
At the end of the day, I think that having two separate frontends (sharing backend logic where appropriate, of course) is a far cleaner and more maintainable design, and also easier to create.
As I said earlier, I intend to go a little farther than just making a GTK+ “skin” over the curses interface. Think less like gvim and emacs and more like maybe ddd.
I should also add that the cwidget library is used by no major programs except Aptitude so few others would benefit from a GTK+ backend. As the cwidget library homepage says:
cwidget was originally an internal user interface library for the aptitude package manager. This means, on the one hand, that cwidget is known to work in the real world for a real application; on the other hand, it means that the feature set of cwidget is coextensive with the requirements of aptitude.