This is a frequently asked question: What package manager shall I use? . And my answer is the one that suits your needs . In my case, I even use different package managers depending on what I m trying to do. APT vs dpkg, which one is the package manager? In the Debian world, we re usually thinking of APT-based software when we re referring to a package manager . But in truth, the real package manager is dpkg. It s the low-level tool that takes a .deb file and extracts its content on the disk, or that takes the name of a package to remove the associated files, etc. APT is better known because it s the part of the packaging infrastructure that matters to the user. APT makes collection of software available to the user and does the dirty work of downloading all the required packages and installing them by calling dpkg in the correct order to respect the dependencies. But APT is not a simple program, it s a library and several different APT frontends have been developed on top of that library. The most widely known is apt-get since it s the oldest one, and it s provided by APT itself. Graphical APT front-ends update-manager is a simple frontend useful to install security updates and other trivial daily upgrades (if you re using testing or sid). It s the one that you get when you click in the desktop notification that tells you that updates are available. In cases, where the upgrade is too complicated for update-manager, it will suggest to run synaptic which is full featured package manager. You can browse the list on installed/available packages in numerous ways, you can mark packages for installation/upgrade/removal/purge and then run in one go all the recorded actions. software-center aims to be an easy to use application installer, it will hide most of the packaging details and will only present installed/available applications (as defined by a .desktop file). It s very user friendly and has been developed by Ubuntu. Of the graphical front-ends, I use mainly synaptic and only when I m reviewing what I have installed to trim the system down. Console-based GUI APT front-ends In this category, I ll cite only aptitude. Run without parameter, it will start a powerful console-based GUI. Much like synaptic, you can have multiple views of the installed/available packages and mark packages for installation/upgrade/removal/purge before executing everything at once. Command-line based package managers and APT front-ends This is where the well known apt-get fits, but there are several other alternatives: aptitude, cupt, wajig. Wajig and cupt are special cases as they don t use libapt: the former wraps several tools including apt-get, and the latter is a (partial) APT reimplementation (versions 1.x were in Perl, 2.x are now is C++). You re welcome to try them out and find out which one you prefer, but I have never felt the need to use something else than apt-get and aptitude. apt-get or aptitude? First I want to make it clear that you can use both and mix them without problems. It used to be annoying when apt-get did not track which packages were automatically installed while aptitude did, but now that both packages share this list, there s no reason to avoid switching back and forth. I would recommend apt-get for the big upgrades (i.e. dist-upgrade from one stable to the next) because it will always find quickly a relatively good solution while aptitude can find several convoluted solutions (or none) and it s difficult to decide which one should be used. On the opposite for regular upgrades in unstable (or testing), I would recommend aptitude safe-upgrade . It does a better job than apt-get at keeping on hold packages which are temporarily broken due to some not yet finished changes while still installing new packages when required. With aptitude it s also possible to tweak dynamically the suggested operations while apt-get doesn t allow this. And aptitude s command line is probably more consistent: with apt-get you have to switch between apt-get and apt-cache depending on the operation that you want to do, aptitude on the other hand does everything by itself. Take some time to read their respective documentation and to try them.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

A lot of work has taken place since my last report. First, since my original mentor, Matt Zimmerman, is going to be moving, he helped arrange for Stefano Zacchiroli to fill in for him temporarily. I have had a call with Stefano, and I am looking forward to getting to work with him more over the next couple of weeks. Shortly after my first report, we realized that having the dashboard only display bugs severely limited its usefulness. In our original design, we had it pulling a list of bugs with specific usertags from the BTS. This forced all information to be added to bugs, which we viewed as a good thing since it made the information available to the Debian Maintainers without requiring them to familiarize themselves with DEX. The issue was that when looking back at the ancient-patches project or forward to the big merges project, a large portion of the work will be triaging and determining whether or not the changes are even applicable in Debian. If they aren t, there is no reason for a bug to be filed on the BTS. As a result, I spent a fair amount of time re-writing most of the dashboard. It still supports finding bugs on the BTS that have been tagged with a specific DEX usertag, but it is now task-based rather than bug-based. A task can be a bug number, a package name, a patch name, or anything. It is merely something that needs to be done for a project. Each task will have a name, an assignee, a status, a note, and a bug associated with it. There are two ways to define a list of tasks for a project. The first is to tag bugs on the BTS with a user of debian-derivatives@lists.debian.org and a tag with a format of dex-<distribution>- <project> (i.e. dex-ubuntu-ancient-patches). The script will convert the bugs to tasks and automatically set all of the fields. The second method is to specify the list of tasks in a plain text file on the server the scripts are being run on. Eventually, this list will be able to be specified via a web interface. Currently, you are only able to specify the task name in the file. This means that all of the other fields for a task created in this manner are initially blank. I am still deciding on the best way to specify additional information about each task in the file. Once I decide on a method, it should not be too difficult to modify the script to parse and store that additional information. For the ancient patches DEX project, everyone involved had to update a status file stored in a VCS on alioth. This was rather annoying, so we decided early on that we want to be prevent this from being necessary for future projects. This means that the dashboard needs a way for users to modify the information on it. For tasks that are based on bugs, this is rather easy; you simply use the BTS email interface to adjust the bug. However, for other tasks, we needed the ability to modify them on the dashboard. I have managed to get this partially implemented. Currently, all cells on the table are text input fields (with css being used to hide the boxes). This means that you can click on any cell and edit its contents. Hitting the submit button will execute a script to save these changes. This is the tricky part. The dashboard is a collection of html files generated by a python script. The script is meant to be run by cron every n minutes. When you update something via a web interface, you usually expect to see the changes instantly. This means that we can t wait for the python script to run again and re-generate the html files. As a result, I currently have it setup so that when you submit the form, it will go and modify the html files to reflect the changes. The next time cron runs the python script, the html files will be re-created, and the changes made by the user will be lost. Once I come up with a method for storing additional information about a task, it shouldn t be too hard to make changes made by a user via the web interface permanent. I also did some work on a script to generate graphs. There are two types of graphs I hope to be able to display on the dashboard. One graph will help show which individuals have done the most work on a project. I have not started working on this graph yet. The second type of graph is meant to show the number of open tasks versus time. This will allow people to quickly see the progress of a project, estimate how long the project will take to complete, and notice if things start to slow down. I have some initial code for this graph using matplotlib. However, due to the many changes that were made to the dashboard, I had to hold off a bit on this graph, as it relies on certain information provided by the dashboard. I hope to sort out some of the last few issues with this graph, such as getting the axes to display properly, and then merge it with the dashboard sometime in the next few weeks. Allison Randal approached me a while ago to see if my Summer of Code project might be in a state where it could be used to assist with a Python 2.7 DEX project that she was working on. For a while, I did not think that it would be ready. However, last week, I helped her get the related bugs usertagged appropriately, and they now show up in the DEX dashboard. While the dashboard is still not complete, it does allow her and everyone else working on the project to clearly see the tasks (bugs) that they need to focus on and the current status of each of them. I plan to try and incorporate any feedback I receive from people working on this project into my designs. All of my code is available in a git repository on alioth. Keep in mind that it should not be considered stable at this point. Further status updates will be posted on my blog, and I will try to keep the wiki page updated. I am still trying work out where we will host the actual dashboard. In the meantime, you can try out my testing version of it. During the next few weeks, I will be focusing my efforts on coming up with a method for storing additional task information. That will allow me to support permanently storing changes made by users via the web interface. I also hope to finish the first graph script and merge it with the dashboard. Finally, I hope to find a permanent home for the dashboard, as having it on my personal server is not a viable long-term solution. Finally, if anyone is interested in getting involved with DEX, feel free to join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me via email or on IRC (nhandler).</project></distribution>

Hello, this is the 2nd report regarding my project. I'll offer a brief
summary of how are we doing and then the details, so you don't have to
read everything at all.
I have to start saying that over the last two weeks I made a lot of
progress on the project. The most important part: Debian ARM image
integration with Eucalyptus is now cleared. The work to be done for the
next two weeks is pretty much fully coding to achieve what we've committed:
supporting Debian ARM images for Eucalyptus.
What was done so far
--------------------
- I've have identified and mapped what needs to be modified over the
  eucalyptus source for supporting ARM. I'm puting the details on the
  next section. I think this is the most crucial part that is now
  sucessfully achieved.
- I started a Project Log[1] on the wiki, so anyone can check and
  eventyally use the information I've already gathered. The log is being
  updated constantly. You can also check what I've done and what I'm
  working on.
- We got feeback[2] from Eucalyptus developers and packaging
  team regarding developers and packaging team regarding the ultimate
  source for debian/ packaging bits. This was quite important because
  in the past I've managed to build Eucalyptus from source using the debian/
  included in the upstream tarball. However the people in charge
  told us that they were using a different one, which indeed was
  different and resulted in different output than I expected. I'm
  still working on fixing the bits to get a clean build.
- I've joined the pkg-eucalyptus team and I've been given commit rights
  to the repo[2].
1- http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog
2- http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/2011-June/000289.html
What I'll be working over the next two weeks
--------------------------------------------
- Heavily code on the different bits that I've identified and need to be
  changed. They are:
  C code:
  - node/handlers_kvm. c,h  - handles nc creation. nc's are node
  clusters for Eucalyptus, the code is in charge of node creation. It
  prepares the "machine" that is able to run a compatible image.
  - util/data. c,h  - handles instance creation. The code over there
  implements the functions node/handlers_* use, like instance creation
  and libvirt's API parameter passing. Since libvirt's parameters for
  ARM vary from x86's ones, we need to support that.
  Perl code:
  - tools/gen_kvm_libvirt_xml - wrapper tool for creating KVM/QEMU
  libvirt's XML Domain definition. This needs to be heavily
  changed/updated - redesigned, to support ARM architecture.
- Depending on the previous task progress: Modify the Debian packaging
  bits for Eucalyptus and push them to the pkg-eucalyptus's team
  repository. This is not crucial for my project's success but I'd like
  to work with Debian official builds. I've yet to commit the
  Eucalyptus team version to the debian/ dir. I expect to have fixed
  the bits to get a successful and clean build, then commit.
Other plans
-----------
- I expect a slow down on the work pace over the second week due end of
  semester exams on the week from July 3 to July 9. After that week I'm
  on vacations and will be fully dedicated to the project.
- Code changes to Eucalyptus source will be pushed upstream. I would
  not like to keep a separate repo for this. I'll talk about this with
  Steffen. Changes to Debian bits will be pushed to the appropiate repos.
Other bits
----------
When the project started I noted it was too vague for some people and
it's results/output were unclear. This concerned me. However, while the
project started and we got lot of feedback things got much clear and I'd
like to take the opportunity to explain it a bit.
Currently, developers targeting ARM devices are struggling[1] with having
a development environment. There are missing bits that sometimes are not
in place and result on hard time for them. Also, due mobile devices
growth and vendors using Linux-based[2] operating systems it's a nice
opportunity for Debian to keep it's well known fame of: supporting every
arch over the sun. How this project fits, well by offering the ability
for developers to run ARM-based Debian images over x86/x86_64 CPU's
would impact the way they could be more productive and for Debian to be
more adopted as development environment.
I can say that I'm very enthusiast of this opportunity and I'm
certain that the outcome will result in more adoption. Even the Ubuntu
people is now pushing more and more efforts for ARM official support,
due the facts I've stated.
1- http://lists.debian.org/debian-arm/2011/06/msg00020.html
2- http://events.linuxfoundation.org/events/android-builders-summit/back

Well, every once in a while we re forced to do something that isn t particularly interesting or pleasant. Last week it happened again: I had to import a few pretty big PSTs (most 2Gig, one 10Gig, with about 100.000 emails) into our dovecot IMAP. Doing this with Outlook itself was out of the question: it took way too long, even on the local network (many hours for a 1G file) and was prone to hanging and crashes, which were obviously a pain to debug and start over.
Thunderbird was unfortunately not much better, since at least in our tests it didn t import the read status of the emails (they were all marked as unread) and also wasn t particularly good at handling folders with strange names, containing . , / or some more obscure characters. We had used it before for smaller files, where manually dealing with the problems was acceptable, but this time it required something a bit more elaborate, if we were to keep our sanity. Enter libpst. It includes the handy readpst utility which dumps all emails in usable formats in a directory tree, one directory per folder. Unfortunately the Debian version is somewhat outdated and doesn t support the newer Outlook formats, so I did some packaging and even a little bit of patching. It seems Thunderbird also uses this library, which would explain why it didn t handle the Read-Status (haven t confirmed this though; just read it somewhere). The last step was this not-so-little script, which uses the dumped directories from readpst and imports them in IMAP. It would have probably been a bit more elegant to use libpst directly, but I unfortunately didn t have the time to mess around with that. I did have to mess around a lot with encodings though, ergo the unholy chaos with unicode()s and str.encode()s thrown around like rice at a wedding (I could never really wrap my head around charset problems; the subject boggles my mind to this very day). Another useful automation is using the mappings file, which looks something like to automatically import in the right destinations, in case you have a standardized structure.

Hello,

This is second report of my GSoC project for Debian. Since my last
report I have done most of things about my project's design. Me and my
mentor are thought about projects API, design etc. this two weeks. Since
preparing API is the most important task of this project two week is not
a long time, and I don't say that API design is over. According to your
comments or requests I can change the API.

If you want to see how the tool's API look like or tool's source code you
can clone project's git repository at [1]. In repository, under template/
directory you can see that.

Under the directory you will see one file and one directory. Only file is
the tool's main file, called py3build. It is a python3 script. It will
build extensions for Python3.

Firstly It will parse arguments. Arguments are:

--system args: (extension will be build for which build system)
--test: (for only test the extension)
--no-clean: (don't try to call clean method)
--configure-args args: (extra configure args)
--build-args args: (extra build args)
--test-args args: (extra test args)
--quiet: (quiet mode)
--verbose: (verbose mode)
--python-version args: (build for that version)
--build-directory args: (build in given directory)

If there is no given Build System then It will try to get Build System
list. This list will be generated from plugins/ directory which you can
find under my git repository's template/ directory.

I want to describe what will BuildSystem's look like.

Under plugins/ directory you will see __init__.py file. It will contain
base BuildSystem class, main Exception class, and other method specific
Exception classes. (f.e. ConfigureError) Main Exception class will be
derived from Exception class and other Exception classes will be derived
from this class, called Error.

Base BuildSystem will be derived from all other Build System classes. It
has __init__ method which gives build_dir, configure_args, build_args,
test_args for parameter. It will set them to self. parameter_name . So,
if they will be needed from another method, can be retrieved from
self. parameter_name , no need to pass every method.

One of the important BuildSystem class method is detect method. This
method will detect the extension's build system. If given directory has
files for building extensions for this build system (or other magical
detecting ways) it will return true.

After that with configure method we can configure extension for the build
system. This method and other methods in build system classes' will also take version parameter. This parameter will
determine that this extension will be build for which Python version. If there is
any error occurs then it will raise ConfigureError exception.

Clean method will cleans (f.e. removing build files) given directory for
that build system. If there is any error occurs then it will raise
CleanError.

Build method will build extension for the build system. It will use
self.version to determine which version it will be built for. If there is
any error, then raises BuildError.

Last method is called test. This method will test the extension for
self.version Python version. If there is any error occurs then raises
TestError.

Every build system plugin should have one class, same name with file. The
class should extend BuildSystem class and override this class' methods
for working correctly.

I also wrote an example plugin, called example. For show how it will be done (It is under
plugin/ directory under project's git repository).

py3build's get_build_system method will retrieve a BuildSystem list. This
method will be used by determine_build_system method. That method will
determine which build system is usable for this extension. After that
this method also returns a list. List is in order to higher probablity to detect.

Main method will invoke clean_for_build_system with a BuildSystem object
argument for clean for that BuildSystem, configure_for_build_system with
a BuildSystem object argument for configure for that BuildSystem,
make_for_build_system with a BuildSystem object argument for build for
that BuildSystem and test_for_build_system a BuildSystem object argument
for test for that BuildSystem. The call sequence is like that.

Every method will return True if everything is OK.

We are still working on API and this one isn't completed, and
discussing about various problems.

[1] git://git.debian.org/~mesutcan-guest/py3multibuild.git

Even with the availability <video> tag in HTML5, most websites still require the use of Adobe Flash plugin to access some content. If you run a 64-bit (Intel architecture) version of Debian, you can still get this plugin through the flashplugin-nonfree package. Unfortunately, Adobe never commited to a decent support for the 64-bit version of its plugin. The first 64-bit version was provided as late as the fall of 2008. The support was discontinued. Then, we recently got a new preview release but it is still lagging behind the 32-bit version. The 64-bit plugin has two major drawbacks:

• it is not up-to-date and plagued by several security holes which are not planned to be corrected for the 64-bit version;
• it exhibits some bugs of its own, like some sound artifacts which come from the use of memcpy() in place of memmove() and only happens with recent GNU libc (where memcpy() has been optimized and is no longer equivalent to memmove()). Adobe has no plan to fix this. There are several way documented in the bug report to circumvent this bug.

Even if you fix the second point, you have no way to fix the first one. What are the alternatives?

Lightspark Lightspark is a modern, free, open-source Flash player implementation featuring JIT compilation (with the help of LLVM) and hardware acceleration using OpenGL. It only supports Actionscript 3 (introduced in Flash 9) but it now fallbacks to Gnash if an older version is required. The main problem of Lightspark is that it is optimized for modern hardware and uses OpenGL textures to display video frames. This allows to achieve video compositing with the help of the graphic card. Unfortunately, if you use a video card with poor OpenGL performance, like a NVidia card with Nouveau driver, Lightspark is slow as hell. It works well with an Intel card. Currently, Lightspark is only available in experimental for Debian. Install browser-plugin-lightspark.

Gnash Gnash is a more mature project but does not support Actionscript 3. Youtube works well with Gnash, as well as most other applications unless they use too recent features. If your use of Flash is limited, it is a nice alternative. Unfortunately, more and more content are delivered with an application requiring Actionscript 3 support. On Debian, you can get started by installing browser-plugin-gnash.

32-bit Flash plugin on Debian Ubuntu provides Flash as a 32-bit plugin with the help of nspluginwrapper which is a special plugin that will enable the use of a 32-bit plugin inside a 64-bit browser. This seems a sensible choice since Adobe only really supports the 32-bit version. You can also use nspluginwrapper with Debian. You need to download 32-bit version of Flash, uncompress it and put libflashplayer.so in ~/.mozilla/plugins.

# aptitude purge flashplugin-nonfree
# aptitude install nspluginwrapper lib32asound2-plugins
$ cd ~/.mozilla/plugins
$ nspluginwrapper -i $PWD/libflashplayer.so

Beware that you need to watch for updates yourself. Mozilla provides a website checking if plugins are up-to-date. It works with other browsers than Firefox. This is a pity to still need this kind of hack in 2011 but it seems that this is currently the best solution. UPDATED: In a comment, Paul Rufous tells debian-multimedia.org repository provides flashplayer-mozilla package which is the 32-bit plugin with nspluginwrapper.

HTML5 Thanks to the <video> tag available in HTML5, most videos should be available without the need of a special plugin. Unfortunately, HTML5 does not define a list of video codecs and container formats that should be supported by any browser. Therefore, some browsers support Ogg Theora, some others H264 and some of them also support WebM, the new royalty-free format from Google. You can find a good summary of the problem from Mark Pilgrim. With Chromium as found in Debian, you have Ogg Theora, WebM and H264. Youtube has an opt-in program to enable HTML5 video but most other video content are just unavailable without Flash. Web without Flash is not a reality yet.

Grab video with helper tools UPDATED: Josh Triplett pointed in a comment the existence of several command line tools that could be used to download Flash video from popular websites. Those tools include:

• youtube-dl
• get-flash-videos
• clive

Those tools can be useful even if you have installed a Flash plugin since they allow the use of the video player of your choice (better performance, working fullscreen mode). UPDATED: Another solution provided in a comment: Video DownloadHelper extension allows to extract videos from the current web page. In another comment, this is the extension FlashVideoReplacer which is featured. It replaces the Flash container with a standalone player.

Sometimes there s nothing quite so heartwarming as hearing a 4-year-old that doesn t think anybody is listening. When Jacob is all alone in his room, sometimes he will sing. Maybe it s a song he knows, or fragments of a song he knows. Or maybe it s something he just made up on the fly. It might be about trains, cats, letters, or who knows what. Maybe it will crack him up and he ll keep singing and then laugh. Or maybe it will stop in 30 seconds and he ll go on to something else. Brief and out of tune though it may be, it is still one of the most beautiful sounds I know and I love to hear it. Jacob loves to have other people sing, too. Sometimes I will make up songs while we drive: We are driving, we are driving, we are driving down the road; we are driving down the old country road and we re making some dust, yes a lot of dust Or Jacob likes me to sing the songs in the Winnie the Pooh book he has (the original, pre-Disney version, which has the words for the songs but not a tune, so I make up a little bit different one each time). Very occasionally he will sing with me, but if he does, he doesn t want anybody to comment about it. I sing with the Kansas Mennonite Men s Chorus. We re a group of about 300 singers (all men, though not all Kansan and not all Mennonite) that sing for charity. We ve raised over $600,000 for charity so far. I still remember the first time I went to a KMMC practice 3 years ago. It was my first year singing, and the first practice of the season. We started singing the first song, and wow what a powerful moment. Even at its imperfect first practice state, hearing 300 people sing quietly is a powerful sound and when they get to the top of their lungs, it s indescribable. No CD can ever quite do that justice. Jacob and Oliver come to KMMC concerts sometimes, but this year they took a special interest. Oliver pointed to, hm, perhaps 300 men and said dad for each one. (He was quite far away and probably couldn t pick me out specifically.) Jacob, for the first time, sat quietly engrossed in the concert until we got to Dry Bones (a song involving surprise and lots of homemade instruments) which made him laugh out loud. Then he would hide under his seat from the applause. Last week, KMMC went on tour. This was my first choir tour, and Terah came along while the boys spent time with grandparents in Kansas. We sang in Bloomington, IL, and then in Goshen, IN at the fairly new Sauder Concert Hall. That hall is a few years old, and has been reviewed as once of the best concert halls in the world acoustically. It seats 1100 people and was perfect for this. The 85 or so singers from KMMC that went on tour joined the Indiana and Ohio Men s Choruses to make a combined group of about 200 singers. And what an experience that was. I learned later this was the first event to completely pack Sauder Concert Hall. We ended the concert singing the Mennonite Anthem a souped-up version of the doxology. (You can see a video of a different group singing it to get an idea of what it was). This is often joked about as being part of Mennonite DNA. You can gather a random group of Mennonites and ask to hear 606 (its number in, well, an old hymnbook that we don t use anymore) and you can probably get a fairly well-sounding rendition, from memory, a cappella, complete with 4-part harmony, at the drop of the hat. Mennonite youth have been known to sing it in train stations, airports, soccer stadiums, and with kazoos. At Goshen, we had 200 men on stage, plus a brass band, plus 1100 people in the audience facing us. They were, of course, invited to sing along. (That s one of the rules of 606: you can t exclude anybody because even if you tried, they d still sing, because how can you resist?) So I was up there on stage, singing a song I love, and hearing the 1100 people in the audience sing it to me. I could glance out over the front rows and saw the smiles on so many faces as they sang, and what a moving moment that was. The excitement and thrill of it all hit me so much that I could barely finish the song. The numbers aren t all in yet, but I m guessing that we raised over $15,000 for charity last weekend (the choir members paid their own expenses in advance, so 100% of the money raised goes to international relief efforts.) A 4-year-old singing alone in his room is really heartwarming. I have to say that 1300 people singing a song that touches each one of them is a pretty close second.

Half a year ago, I experimented with gtk+ and cairo to extract a PDF screenshot out of a progam, i.e. a screenshot of the window that is not a table of colored dots as a regular PNG file would be, but rather a vector graphic that scales perfectly and has selectable text. The main use that I see is documentation: A scalable screenshots looks much better in print, and even in an online-PDF-file, having the full-text-search also find the text in the images is useful. My experiments back then were successful in a proof-of-concept way, but they were very ugly hacks. With the new version 3 of gtk+, though, things become much easier, as only one cairo context is used, instead of each widget creating its own context to draw on. By now, the first gtk-3 applications have reached Debian unstable, so I thought it would be time to re-do the experiment. And the result is very pleasing: The pdf screenshot program comes as a gtk module that you can load by setting an environment variable before launching a gtk-3 program. The application will run as usual, but there is an additional PDF screenshot button. If you click it, you get a Save File dialog (with a nice, live-updated preview of the screenshot, as an additional gimmick) that lets you save a PDF file. Its as easy as that. You can check out the resulting PDF file of gucharmap and a screencast of me creating that file, including copy n pasting from the resulting document. PS: I would offer the video as well on YouTube, but it seems it does not accept Ogg Theora videos. I hope all of you can make use of the above links. Update: By popular demand, I also created a SVG version. It even looks better because the embedded pixmaps have a higher resolution probably gtk is confused by the resolution of the PDF cairo surface. The code is almost trivially the same. I guess I could add other formats (PNG, PS) as well. Now I just have to find out how to tame GtkFileChooser to offer this feature better.

Half a year ago, I experimented with gtk+ and cairo to extract a PDF screenshot out of a progam, i.e. a screenshot of the window that is not a table of colored dots as a regular PNG file would be, but rather a vector graphic that scales perfectly and has selectable text. The main use that I see is documentation: A scalable screenshots looks much better in print, and even in an online-PDF-file, having the full-text-search also find the text in the images is useful. My experiments back then were successful in a proof-of-concept way, but they were very ugly hacks. With the new version 3 of gtk+, though, things become much easier, as only one cairo context is used, instead of each widget creating its own context to draw on. By now, the first gtk-3 applications have reached Debian unstable, so I thought it would be time to re-do the experiment. And the result is very pleasing: The pdf screenshot program comes as a gtk module that you can load by setting an environment variable before launching a gtk-3 program. The application will run as usual, but there is an additional PDF screenshot button. If you click it, you get a Save File dialog (with a nice, live-updated preview of the screenshot, as an additional gimmick) that lets you save a PDF file. Its as easy as that. You can check out the resulting PDF file of gucharmap and a screencast of me creating that file, including copy n pasting from the resulting document. PS: I would offer the video as well on YouTube, but it seems it does not accept Ogg Theora videos. I hope all of you can make use of the above links.

My internship is now finished, this means that I will be able to work on my GSoC project a lot more than the previous weeks. I hope to make some good progress in the next days.

This last 2 weeks, I was still studying how Jigsaw works. Even if there is no progress on the Jigsaw packaging I have done some packages that will help later.

I ve spend a lot of time trying to package JT Harness and JTReg.
I ve successfully built JT Harness using CDBS but I ve finally rewritten the package using only debhelper and javahelper. Javahelper was really useful to build JAR files, move them to the right directory, put the Javadoc in the right place as well as the examples. The Debian directory of JT Harness can be found on the Java team SVN.

svn co svn+ssh://$ SVN_USER @svn.debian.org/svn/pkg-java/trunk/libjtharness-java

The source package of jtharness build 2 binary packages: libjtharness-java and libjtharness-java-doc. You can see that by looking at the control file in the debian directory. There are some interesting files in this package, let s take a look at them.

First of all, some of the source files needed to be patched for the package to build. So to accomplish this, there is a couple of patches in debian/patches :

• dependencies.diff, used to locate JAR files in /usr/share/java , and,
• rxtx.diff, done by Tom Marble used to change some imports from javax.comm to gnu.io .

To generate these patches, I ve used the edit-patch command which is a really awesome tool. This command uses a temporary shell where we can edit files we want to patch. When the job is done, CTRL + D terminates the temporary shell and the patch is generated.

There are 4 interesting files which are used to build the binary packages and put the files in the right directories. These files are:

• rules,
• libjtharness-java-doc.install,
• libjtharness-java.jlibs, and,
• libjtharness-java-doc.javadoc.

Of course rules is the most important one. This file tells us how packages are built. A good thing is that rules is quite simple in the jtharness case.

#!/usr/bin/make -f
JAVA_HOME = /usr/lib/jvm/default-java

override_dh_auto_build:
ant -f build/build.xml

%:
dh $@ --with javahelper

We just tell where Java is and to use javahelper ( with javahelper). Overriding dh_auto_build is interesting because since the JT Harness uses Ant as build system we need to give to Ant where the build.xml file is. By default Ant is searching it in the current directory but in jtharness the file is in the build directory. Since the Ant build file is correctly written, the build generates JAR files, Javadoc and examples code. And libjtharness-java* files are here to put the generated things in the right places.
The job of libjtharness-java.jlibs is to tell where to find the JAR libraries. In this case, the intesresting JAR files were javatest.jar and jt-junit.jar . So in the .jlibs file we just give where those files are after being built.
The job of libjtharness-java-doc.javadoc is to tell where the Javadoc is and where to put it. So there is only one line that says the generated Javadoc is in jar-build/javadoc and put it in /usr/share/doc/libjtharness-java/api .
And finally, libjtharness-java-doc.install is used to move the examples. The syntax is same as libjtharness-java-doc.javadoc .

The JT Harness package can be found in Sid now thanks to Sylvestre Ledru who uploaded it for me. So the ITP bug that I created is now closed.

Building the package for jtreg is quite similar. In fact, it probably easier but I m still facing a problem. jtharness is just a library, jtreg does have main classes and generate some binaries. The difficulty here is to generate the man pages for the 2 generated binaries: jtdiff and jtreg. These 2 files are shell scripts which just use jtreg.jar with the correct parameters.

I tried several tools to generate the man pages of each script. Sadly, I can t find a way that does not causes any problems.
My first choice was to use help2man. This tool looked like to be perfect for the job. But I couldn t find how to launch the scripts correctly. The scripts needs jtreg.jar but they also need javatest.jar from the libjtharness-java package. The classpath cannot be set correctly due how the scripts are written. So to use help2man I ll probably have to patch and completely rewrite jtdiff.sh and jtreg.sh in the sources.
My second choice was to use txt2man. During the build of jtreg there is a usage.txt file which is generated and which can be used as a man page. txt2man can take this text file and output a man page based on the text. I thought it was working but when building the package, lintian threw some warnings about syntax errors in the man pages.

W: jtreg: manpage-has-bad-whatis-entry usr/share/man/man1/jtdiff.1.gz
W: jtreg: manpage-has-errors-from-man usr/share/man/man1/jtdiff.1.gz 292: warning [p 4, 3.3i]: cannot adjust line

Finally, few days ago I decided to try rst2man. This tool looks cool and easy to use. But the text that I have to convert into a man page is not a reStructured text so it cannot without patching the usage.txt file for example. I was going to do it but there is no such file in the sources of jtreg. Actually this file is generated during the build but the text had to come from somewhere. And it was from two properties files in the source code.
I m still looking for a good solution to generate the man pages. If someone has any idea just let me know

The debian packaging of jtreg is not in the Java team SVN yet because of the man pages problem. I opened an ITP bug so people know that someone is working on jtreg.

My goal for the next two weeks is to finish the jtreg package, understand how jpkg (which is supposed to create Debian packages) works in Jigsaw and write more examples using the modular JVM.

Things aren t exactly going as smoothly as expected. Here are some explanations. First collateral damage: non-free fglrx and nvidia drivers. We have to admit we didn t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that s the move we call adding multiarch support ). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages. Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded. Second collateral damage: xserver-xorg-core in testing. The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post. That s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path! Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages. To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner. (As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we ll make sure we update the Breaks in the new mesa to make sure that it can t happen. Since it s not as urgent as getting the server in testing fixed, it s only queued for mesa 7.10.3-3 for now.)

DECLARATIVE DIVERSIONS ====================== REPORT 2 This is the second report for declarative diversions for debian as part of Google Summer of Code. My first report was just a design draft but I have since been advised to structure it differently. So in this report I will talk about what I have done to date with the project and what my plans for the immediate future are. For the first while in this project I spent a lot of time with my mentor planning out what we were going to do and we discussed it with everyone who is involved with dpkg to get feedback. I quickly got a great deal of feedback and produced my first design draft. After which I got even more feedback and produced my second design draft. This week is the first week I have spent coding. So far I have coded a parser which works quite well for what we need. I spent the later part of this week integrating it into the existing codebase. But so far everything is looking extremely promising. My plans for the immediate future are to release a third design draft based on feedback from my existing code and to finalise the main part of the work. I believe this will be achieved by the next report date (1st of July) as well as a lot of basic functionality for the project. Anyone who wishes to discuss the project with me can either mail me through the mailing list, catch me on IRC (SCD[Eire]) or email me at sam.dunne101@gmail.com My blog: http://blog.sam-dunne.com My Github: https://github.com/samdunne/dpkg-diversions My code is located in /lib/dpkg/test in the gsoc-testing branch of my code Until next time, ~Sam

Edit Aug 18th: video available (ogv, also on youtube)

Forget AMD, Intel, NVIDIA! Thomas White's incredible work with Neo FreeRunner's puny graphics dec...accelerator, Smedia Glamo 3362 is starting to bear fruits. Not listening to such comments as the chip will never be used anywhere else and why not spend your time doing something more relevant , he has chosen to actually do what he likes and sees as an interesting challenge. And that's often the spirit of free software, so I don't really agree with the naysayers.

The camera shot on the right, running KMS-enabled X.org driver for the glamo chip on my Debian installation (visible software matchbox-window-manager, fbpanel, zhone), is a bit optimistic looking since Zhone happens to draw correctly. A lot of the drawing is not yet synced correctly, which shows as all text and images in eg. GTK applications being garbled. But as little as two days ago one couldn't yet much launch applications without X crashing, so the newest commits by Thomas were a big step forwards. I'm using Debian, and he's not, so I try to find time to help in debugging even though I really can't much help with the driver code.

The driver is not just one piece of code, but consists of a kernel drm driver (direct rendering manager) using GEM, libdrm support for the kernel driver and finally the X.org driver supporting these other components and offering buzz-words like DRI2. There is also a beginning of a Mesa 3D driver, though it is so far just a skeleton driver since the 2D/KMS/EXA/DRM parts are what should be done first before dwelling into the OpenGL realm.

Openmoko the company is basically nowadays just producing new Neo FreeRunners to resellers, but the community of the so far only Free phone is thriving. The final (Openmoko produced, from where gta02-core continues) version of the phone, with the famous buzzing problem fixed, appeared on store shelves some time ago, offering better out-of-the-box phone functionality in addition to all the mini computer features. It was also offered to Debconf visitors on discount.

It's not only cool to have kernel mode-setting, though it is indeed very cool as well. The reason for much sorrow in the whole OM project has been the graphics chip, and some of the problems with the chip are only finally solvable with the kernel doing the mode-setting. So it's both a very modern thing to use KMS, but there are also clear potential benefits of having accurate control over this very sensitive piece of silicon. The current non-KMS X.org driver for example busy loops in order to try to feed the chip at a correct pace, causing CPU usage every time there is any drawing going on.

This is somehow reminding me about getting the best out of 8-bit computers and other hardware with some specific limitations. The glamo chip is very limited in some ways, but also capable in some other ways like theoretically offering MPEG-4 decoding, OpenGL ES 3D support. It's a mixed bag of things, and I can very well imagine it's indeed an interesting challenge to work on it, if you just have the skills (I don't) and nerves (proper debugging tools help).

It's so nerdy to drool over lines in the X.org log, but I just can help it:

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.28 armv5tel Debian
Current Operating System: Linux neo 2.6.29-GTA02_mydrm #2 PREEMPT Mon Aug 17 18:24:39 EEST 2009 armv4tl
...
II) Using KMS!
...
(WW) Glamo(0): EXA hardware acceleration initialising
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Glamo(0): Initialized EXA acceleration
...
(II) Glamo(0): RandR 1.2 enabled, ignore the following RandR disabled message.
...
(II) Glamo(0): [glamo-dri] Name of DRM device is '/dev/dri/card0'
(WW) Glamo(0): [DRI2] Version 1 API (broken front buffer rendering)
(II) Glamo(0): [DRI2] Setup complete
...
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: Loaded and initialized /usr/lib/dri/glamo_dri.so
(II) GLX: Initialized DRI2 GL provider for screen 0
(II) Glamo(0): Adding framebuffer....!
(II) Glamo(0): 8 480 640 16 16 960
(II) Glamo(0): rootPixmap = 0x1d0a00
(II) Glamo(0): Done

I'm writing a blog entry instead of just replying to myself on a mailing list, since this subject might be interesting to a largish portion of the community. Most people assume things just magically work out by themselves and then after a release wonder why it wasn't so.

So, I raised a question on ubuntu-devel-discuss mailing list about whether usb-modeswitch should be included in the default Ubuntu 10.04 LTS installation instead of it only being in the universe repository. Reason was simply that firstly, I've read some general wonderings from the community about why it isn't already so. Secondly, without it my 3G modem (Huawei E1552) was first not functional, but right after installing usb-modeswitch package Network Manager worked smoothly with it.

Since I didn't get much discussion going on besides some statements that it doesn't work for everybody and even has caused extra problems for some others (in 9.10), I asked for a small round of comments on the subject on IRC. The channels are logged so I believe I can quote those a bit.

Colin Watson said among else:

"surely we just want the kernel to DTRT [do the right thing] by default ... this is the upstream trend ... it already DTRT for quite a few devices"
"I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel"
"I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work ... I'm just not very convinced it's a real properly supportable option"
"but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)"

Later on Paul Sladen continued a bit, among else:

"usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile"
"grep -hr MessageContent usb_modeswitch.d/ sort -n uniq -c sort -rn shows the level of duplication in the configuration files"
"...I do like that it is done in userspace though, as so easy to disable if you wanted something else".

Meanwhile I also IM:d a bit with Antti Kaijanm ki from whom I probably originally coined the idea of following whether usb-modeswitch is integrated into Ubuntu or not. He mainly said that he doubts the feasibility of updating kernel's USB storage quirks in a stable release, compared to having stable release upgrades about the usb-modeswitch-data udev rules. He also proposed discussing maintainability and usability by distros with the Debian maintainer and upstream, although it sounds like Colin might have had some talks already.

So there we are now. Apparently at this point it is hoped that as many quirks as possible are inserted in the kernel, see for example drivers/usb/storage/unusual_devs.h in the kernel. But if you have concerns about if 10.04 LTS will be kept up-to-date regarding 3G modems and want to somehow participate in bringing usb-modeswitch into Ubuntu default installation or simply discuss how to handle the kernel SRUs properly, it's time to stand up and do something.

Should there perhaps be a process with which the usb-modeswitch developers would get the information they are gathering more easily to the upstream kernel _and_ (older) distribution kernels? Is this simply a case of being easier to address an issue with a "hackish" approach, or is the usb-modeswitch actually the right way to go?

Note that I'm no expert in this area, I simply become interested in various subject from time to time :)

-Timo, going to figure out a kernel quirk for his 3G modem

Since Matt is going to be busy the next few weeks moving and traveling, he arranged for Stefano Zacchiroli to fill in for him temporarily as my mentor. I must say, I am quite lucky to have the chance to have both Matt and Stefano as mentors this summer. Yesterday, I had my first call with Stefano. I started by filling him in on the current status of the project. We discussed how the dashboard is going to be based on tasks rather than bug . He reminded me that we want to make sure all useful information makes its way back to the BTS (ideally in an automated or) in a fast and easy way. Most of the information that will be stored in the dashboard probably won t be that useful to the package maintainers. However, there will be a column for DEX members to add notes about tasks. This column could potentially contain some useful information. That is one reason that the dashboard will parse this column for bug numbers and then display extended information about the bug. Hopefully, this will encourage DEX members to send information to the BTS when relevant. Having the bug numbers will also allow us to automate sending information from the DEX dashboard to the BTS if we choose to. I also spent some time this week working on a script to generate some graphs. These graphs will allow us to track the number of remaining tasks in a project vs. time. Stefano mentioned possibly borrowing some code from the Ubuntu burndown charts, but right now, I think the Ubuntu charts might be a bit more complicated than what we need. We can always decide to borrow some features/code down the road if necessary. It is also just about time for me to prepare my second formal report for the Summer of Code. I will use that to showcase the current status of the code and make it available for people to test and review.

All mail clients suck. Some just suck less. But they all have their own peculiarities. mutt, for instance, is a full-featured text-mode mail client. As such, it's pretty popular amongst many Linux enthousiasts, including me. A common error made amongst mutt users is to talk about attaching a file in a mail, but then forgetting to actually do so afterwards. This is because mutt starts an external editor to allow you to edit the message in question, which since it's not mutt itself would seem to make it impossible to attach a file while you're editing a mail, requiring one to remember to actually perform the attach step. One solution to this problem could be to use the little script that Steve wrote, which will complain if you mention something about an attachment in a mail without actually attaching anything. While I'm sure it works to some extent, this kind of script has the downside that it's never going to be 100% correct in all cases (you might mistype the word 'attach', or you might use another word that you didn't think about when you wrote the script, or you might be replying to someone who sent you an attachment). However, a better way could be to realize that mutt does, actually, support attaching files while you're editing a mail text, by way of the 'Attach:' pseudo-header. It requires two steps:

1. Make sure that you have set 'edit_headers' to 'yes' in your configuration. This will cause mutt to fire your editor on a file that also contains the (relevant) headers for your mail, rather than just the body.
2. When you want to attach a file, rather than trying to remember to do so after exiting your editor, just add an 'Attach:' header to the headers section of your mail, with as argument a filename optionally followed by a description. When mutt finds that header, it'll attach the named file, and all is well.

Yes, of course, that does mean you'll have to change your habits, and actually remember to add the damn pseudo-header rather than be like me and still forget to attach files. But hey, can't help you with that.

The first concrete outcome from the Debian derivatives census is the creation of Planet Debian Derivatives. For those of you who are interested in the activities of distributions derived from Debian, it aggregates the blogs and planets of all the distributions represented in the derivatives census. The list of feeds will be expanded semi-automatically as more distributions participate in the census and maintainers of census pages add new blog and planet URLs. Many thanks to Joerg Jaspert for doing the necessary setup procedures for the addition of the new sub-planet to Planet Debian. I'm glad that it was accepted alongside the sole language-based sub-planet (Planet Debian Spanish). I plan further integration of information about derivatives with Debian infrastructure. My next target will be integration of information about the packages in Debian derivatives into Debian. I hope to work on getting that information into UDD (and rmadison) and the packages.d.o site during DebConf11 and DebCamp. If you are interested in helping out, please add your ideas to the integration wiki page, check out the code and add more scripts to it. If you have any comments or questions about this or any other activities related to Debian derivatives, please direct them to the debian-derivatives list and the #debian-derivatives IRC channel on OFTC. Those of you interested in the other side of the software stream might want to take a look at Planet Debian Upstream, which is run by the excellent Joey Hess. He is also on the lookout for interesting blogs by people writing software that is packaged in Debian. The site is created using ikiwiki, hosted on branchable and editable with an OpenID account.

Ever since I blogged about the status of GNOME 3 in Debian experimental, my web logs show that many people are looking for ways to try out GNOME 3 with Debian Squeeze. No GNOME 3 for Debian 6.0 Don t hold your breath, it s highly unlikely that anyone of the Debian GNOME team will prepare backports of GNOME 3 for Debian 6.0 Squeeze. It s already difficult enough to do everything right in unstable with a solid upgrade path from the current versions in Squeeze But if you are brave enough to want to install GNOME 3 with Debian 6.0 on your machine then I would suggest that you re the kind of person who should run Debian testing instead (or even Debian unstable, it s not so horrible). That s what most people who like to run recent versions of software do. How to run Debian testing You re convinced and want to run Debian testing? It s really easy, just edit your /etc/apt/sources.list and replace stable with testing . A complete file could look like this:

# Main repository
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
# Security updates
deb http://security.debian.org/debian-security testing main contrib non-free

Now you should be able to run apt-get dist-upgrade and end up with a testing system. How to install GNOME 3 on Debian testing aka wheezy If you want to try GNOME 3 before it has landed in testing, you ll have to add unstable and experimental to your sources.list:

deb http://ftp.debian.org/debian unstable main contrib non-free
deb http://ftp.debian.org/debian experimental main contrib non-free

You should not install GNOME 3 from experimental if you re not ready to deal with some problems and glitches. Beware: once you upgraded to GNOME 3 it will be next to impossible to go back to GNOME 2.32 (you can try it, but it s not officially supported by Debian).

To avoid upgrading all your packages to unstable, you will tell APT to prefer testing with the APT::Default-Release directive:

# cat >/etc/apt/apt.conf.d/local <<END
APT::Default-Release "testing";
END

To allow APT to upgrade the GNOME packages to unstable/experimental, you will also install the following pinning file as /etc/apt/preferences.d/gnome:

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release experimental
Pin-Priority: 990
Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release unstable
Pin-Priority: 990
Package: *
Pin: release experimental
Pin-Priority: 150

Note that I used Pin-Priority: 990 this time (while I used 500 in the article explaining how to install GNOME 3 on top of unstable), that s because you want these packages to have the same priority than those of testing, and they have a priority of 990 instead of 500 due to the APT::Default-Release setting. You re done, your next dist-upgrade should install GNOME 3. It will pull a bunch of packages from unstable too but that s expected since the packages required by GNOME 3 are spread between unstable and experimental.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

13 comments Liked this article? Click here. My blog is Flattr-enabled.

Yesterday I released version 4 of dh-autoreconf, fixing two bugs, and introducing a new feature: Patching ltmain.sh to make -Wl, as-needed work. For this new feature, run dh_autoreconf with the as-needed option. dh_autoreconf will then patch all ltmain.sh equal to the system one (which should be all ltmain.sh files if libtoolize ran before or via dh_autoreconf). On clean, dh_autoreconf_clean reverses the patch again. So, if your package runs autoreconf, and patches ltmain.sh via a patch you can now do this automatically via dh-autoreconf and be future-proof. The only problem is that this might break once the patch no longer applies to libtool, at which point I need to update the package to include an updated patch. A solution for this problem would be to include the patch in libtool itself, as I proposed in Bug#347650. In case this works well, the option could also become the default which would make things even easier.
Filed under: Debian

One of our paper has been accepted to The 14th International ACM SIGSOFT Symposium on Component Based Software Engineering (CBSE-2011) happening in June in Boulder, Colorado, USA. This is a joint work with Roberto Di Cosmo, Ralf Treinen and Stefano Zacchiroli.

Abstract

 Software distributions in the FOSS world rely on so-called 
  package managers for the installation and removal of packages on
  target machines. State-of-the-art package managers are monolithic in
  architecture, and each of them is hard-wired to an ad-hoc 
  dependency solver implementing a customized heuristics. In this
  paper we propose a modular architecture allowing for pluggable
  dependency solvers and backends. We argue that this is the path
  that leads to the next generation of package managers that will
  deliver better results, accept more expressive input languages, and
  can be easily adaptable to new platforms.  We present a working
  prototype---called MPM---which has been implemented following the
  design advocated in this paper.

---

More details about the paper are available here