Search Results: "ana"

21 March 2008

Gintautas Miliauskas: Launchpad translations revisited

I am trying to add some order to the mess that is the Launchpad translation repository. Problem is, strings translated just once through Launchpad stick around forever, even if you change them in upstream later. In effect, a lot of translation bugfixes were not reaching Ubuntu users. I thought I had that covered. Unfortunately it's not the case. I just noticed that in the Launchpad package list sorting by changed strings only sorts the first page! Initially I had noticed random package names and mistakenly thought that the whole package list was sorted. The whole list (~1500 packages, shown in 75 package chunks) is sorted by "importance", so it's basically random. Good luck finding modified packages in that haystack. Seeking computer-literate monkeys.
Earn up to five bananas per hour!
Must be able to use mouse. Unless... how about increasing the batch size? Turns out that in Launchpad the batch size is not capped, so by changing a URL parameter you can just set it to a high number, wait a few short moments, and get the complete list of packages. Sort that by changed strings and we're done, right? We're done finding the local translations, but not fixing (reverting) them. The new, larger list reveals that there are more than a few of those with quite more than a few strings that should in 99% of the cases be reverted to packaged versions. Here's how that works: Monkey operator instruction manual
  1. Click on 'Packaged' radio button for all 10 entries on page (no batch size modifications allowed here...)
  2. Click 'save'
  3. Repeat until the page says 'No more translations'
  4. Done. Not! When you click the 'Save button', the starting offset is changed for the next page. However, the translations you just marked are removed from the list at the same time. So, if you were looking at translations 1-10, after pressing 'Save & Continue' you will actually be looking at translations 21-30, not 11-20! To get to the 'lost' translations, you have to retrieve the list from the start again. So, load the initial page and go to step #1 to fix the remaining half of translations. Next time you reach this step, half of those will be left. Next time, half of half of those. Isn't that fun!
Where's that monkey ad again? A brute force solution could be to write a script. That could save some bananas. Not that we could run out of them as this whole thing is pretty much bananas. That does not look like a clean solution though. Does anyone know if there there is a better way?

Aigars Mahinovs: Blog-split

Occasionally I post (or could post) things that are not fit for Debian Planet (non-English) or Ubuntu.lv Planet (unrelated to Latvian or Debian/Ubuntu matters), so I finally budged and switch the planet feeds to their own categories so that such things can be managed on a per-post basis. Anyone know a Wordpress plugin that would allow to set multiple default categories?

20 March 2008

Jeff Bailey

More updates:

* I can now walk to the mailbox on my own, and I only need to rest once on the way.
* I'm generally leaving the walker alone. It causes me more grief than it solves.
* I feel confident making the three steps up and down the balcony - which is good because the main doors are still too heavy for me.
* I've had a shower. I smell much better.
* We're starting to take visitors now - Jim and Sarah were here last night, Andrew and Sarah are coming tonight. It'll be nice to feel a little less isolated.
* I haven't spoken to my dad in a couple of days, but they were still scheduling his angiogram when I last spoke to him. All the walking and stuff that I've been doing means that I'm spending the balance of my day sleeping, so hopefully I'll catch up later today.

At this point, I'll probably post updates a lot less frequently, because it feels like the initial touch-and-go part is done. I'm looking forward to being off the steroids, and slowly spacing out the medications and such, but we're just in that zone where I'm getting up and around and am just waiting for lifting restrictions and such to be removed.

In the last few days, I've managed to sort out the various school extensions I need, the short term disability paperwork, the DMV disabled sticker paperwork, and all that.

Phone calls are much appreciated - the number is in my Orkut and Facebook profiles, it gives me a chance to interact with people and I'm starting to worry that I have too much time and am bothering the ones I talk to al the time. I'm still quite behind on emails, mostly because typing on the blackberry gets to be a bit much after a while.

I suspect I'm about to go into that annoying phase of recovery where nothing is urgent anymore, and we're coping, but we go stir-crazy because I'm not actually better enough to interact with the world yet and Angie still has to do almost everything for me. Any suggestions on making that part of the recovery suck less are appreciated! I've watched it a pile of times, but everyone seems to forget about it (including the people going through it).

Sunrise is 7:11 here this morning, I think I'll try to sit outside for it.

19 March 2008

Eddy Petrișor: News from other worlds

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:
The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

Benjamin Mako Hill: Geek Nutrition Survey

My partner Mika is doing a research project on geek nutrition. In addition to being a geek herself, she's got degrees in human nutrition and public health. She works at Harvard School of Public Health. So she seems pretty qualified and I'm looking forward to the results. She's trying to get a little bit of data on the food culture and eating habits of GNU/Linux's users and developers. If you can take a couple minutes to fill out a survey, it would be very helpful to her. The survey is anonymous and only takes results from the first 100 people. Analyzed anonymous results will posted publicly. Comments should be sent to 5colorsaday@gmail.com. The survey took me under 3 minutes to fill out. The survey itself is online here. Mika will present initial results and analysis on her blog and at Penguicon which both of us will be attending.

Russell Coker: The Inevitability of Victory

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

Share This

18 March 2008

Axel Beckert: MicroClient Sr.

About a year ago, I bought a Norhtec MicroClient Jr., a complete 200 MHz MMX-compatible SoC (“Vortex86”) PC so small that it fits into your hand or onto VESA mountings. Althought thought as thin client, the machine has 128 MB RAM and runs Debian from either netboot, USB stick, CF card or 2.5” harddisk without problems and not even that slow. Later last year, we needed more MicroClient Jrs. at work and since the MicroClient JrSX had a 300 MHz 486SX-compatible SoC processor (“Vortex86SX”) from MSTi and 128 MB DDR RAM instead of SD RAM, we expected them at least in the same performance range and bought a few for ETH and I also bought one for myself. Well, they were about three times slower, since the FPU is missing, not all programs from Debian Etch work fine, e.g. X doesn’t work without patching and recompiling (with Sid, X works, but not the kernel anymore)… BTW: I had both machines with me at FOSDEM ‘08 at the Debian booth and the MMX-compatible machine also at Chemnitzer Linux-Tage (CLT) at the Symlink booth and in Kurt Gramlich’s talk about ecological computers. So if you saw them there, just imagine the same case, with a twice to three times faster CPU and four times the amount of RAM, but with roughly the same carbon foot-print! For our thin client purposes at work we now use ALIX boards from PC Engines (Mini-ITX format) with 500 MHz AMD Geode processors. They’re much faster than the MicroClient Jr. and need even less power. Today, while surfing around on some Mini-ITX shops, I found some computer in obviously MicroClient Jr. case, but with 500 MHz VIA Eden processor and 512 MB of RAM. I first couldn’t believe it. They are selling it as eTC-2500. Since eTC-2300 was one of the brandings of the MicroClient Jr. which is called eBox-2300 officially by the manufacturer DM&P, I searched for eBox-2500, but didn’t find anything useful. Then I looked at the manufacturer’s product page at CompactPC.com.tw and found the eBox-4300 — so it’s really true, they managed to fit a board with 500 MHz VIA processor and half a Gig of RAM into the already fscking small space inside the MicroClient Jr. case, and even without needing more power: Still 15W from the power adaptor. Next stop was Norhtec’s Website. And yes, they also have a new MicroClient product: The MicroClient Sr.. I really need to have one of those for my MicroClient collection! ;-)

Neil Williams: GNOME 2.22 and GPE (gpe-filemanager to be exact)

This could be fun - gpe-filemanager is not currently available for Emdebian because it depends on libgnomevfs which in turn brings in a variety of other dependencies ending up with liborbit2 which simply does not (and appears cannot) cross build.
Thankfully, GNOME 2.22 deprecates libgnomevfs in favour of GIO which is already part of libglib2.0-0 and only needs other stuff via plugins.

I need now to port deb-gview to GIO and, in the process, probably see if gpe-filemanager can also be ported to GIO. After all, a GUI without a file manager is going to look a little odd.

I'm still working on libqof2 upstream too so it looks like I won't be doing much on Lenny for a while - not directly at least.

I expect to have deb-gview 2.0.0 depending on GIO and in Lenny and maybe quicklist too. (Typical, no sooner does quicklist migrate from Gtk1 than it also needs to migrate from libgnomevfs.) Then there's all my usual Debian and Emdebian stuff.

Patrick Winnertz: switched from kde3 to kde4

Yesterday I made the switch from kde3 to kde4. But before I dumped all installed packages into a file ( if I have to restore) and backuped my configuration files for kde. After some fiddeling with kde4 and the dependencies I had a full kde4 installed. My problem was that: 
apt-get -t experimental install kde4
won't resolve all dependencies... So my apt-get line was quite long. (After I was finished, I thought that maybe pinning would be a better idea). In general kde4 is usable, but there are some quite annoying things: But of course there are quite many improvements, I'll list here only those which I consider very useful :) Some things which are definitly missing in kde4 (which have to be ported to qt4) are kpowersave and knetworkmanager. Furthermore kontact and amarok, but there is work in progress.

17 March 2008

Russell Coker: Barack Obama wants a National CTO

I am just watching US Senator Barack Obama speaking at Google about his bid to become the next US president [1]. He has announced plans for allowing greater citizen oversight of the government including having all government data in open file formats (a great idea - the Australian Bureau of Statistics has a large amount of data online in Excel format). But his most significant item so far is to have a National CTO (Chief Technology Officer). It’s an idea that seems totally obvious now that I’ve heard it and leaves me wondering why I never thought of it before! Barack understand technology, wants a functioning democracy, and gets a +5 Insightful from me for the CTO idea! He also announced a plan to double federal funding for basic scientific research as part of a measure to make the US more competitive with other countries. He mentioned the US standing in the world as a problem (it’s the first mention of this that I’ve heard from anyone in the US government) and notes this as an issue which limits the ability of the US to save lives in regions such as the Darfur. He also claims that there is no clash of civilisations and cites his experience living in a Muslim country as helping to build bridges. When discussing his reasons for running he said that he believes that he can bring his country together to solve problems better than other candidates. That’s the type of thing you often hear and ignore in political campaigns. It is often difficult to believe that someone wants to be famous and powerful for anything other than the most selfish reasons. But Barack gives me the strong impression that he is genuine. He stated a plan to shut down Guantanamo bay (presumably just the prison and torture aspect - I’m guessing that he is not intending to close the military base) and to stop “rendition” (sending prisoners to other countries to be tortured). His plans for education are innovative, as part of educating young children (0-3 years old) he stated an aim to teach parents to read so that they can read to their children! It’s sensible and obvious once you have heard it, but no-one seems to have publicised that idea before. He announced that he will increase teachers’ salaries. He describes the US as having an “empathy deficit“, it’s obvious to almost everyone outside the US but not something that many people in the US realise. He wants decisions to be based on facts and is determined to use facts when dealing with health insurance companies. I just wish that we had some politicians like him in Australia. In terms of policy the Greens politicians would agree with him, but the combination of great policies, insight, and excellent delivery seems a lot better than any of the options in Australia. Update: Changed the post (including the permalink) to have the correct spelling of Barack. Mental note - double check the spelling of everything in the permalink.

Share This

Russell Coker: Barak Obama wants a National CTO

I am just watching US Senator Barak Obama speaking at Google about his bid to become the next US president [1]. He has announced plans for allowing greater citizen oversight of the government including having all government data in open file formats (a great idea - the Australian Bureau of Statistics has a large amount of data online in Excel format). But his most significant item so far is to have a National CTO (Chief Technology Officer). It’s an idea that seems totally obvious now that I’ve heard it and leaves me wondering why I never thought of it before! Barak understand technology, wants a functioning democracy, and gets a +5 Insightful from me for the CTO idea! He also announced a plan to double federal funding for basic scientific research as part of a measure to make the US more competitive with other countries. He mentioned the US standing in the world as a problem (it’s the first mention of this that I’ve heard from anyone in the US government) and notes this as an issue which limits the ability of the US to save lives in regions such as the Darfur. He also claims that there is no clash of civilisations and cites his experience living in a Muslim country as helping to build bridges. When discussing his reasons for running he said that he believes that he can bring his country together to solve problems better than other candidates. That’s the type of thing you often hear and ignore in political campaigns. It is often difficult to believe that someone wants to be famous and powerful for anything other than the most selfish reasons. But Barak gives me the strong impression that he is genuine. He stated a plan to shut down Guantanamo bay (presumably just the prison and torture aspect - I’m guessing that he is not intending to close the military base) and to stop “rendition” (sending prisoners to other countries to be tortured). His plans for education are innovative, as part of educating young children (0-3 years old) he stated an aim to teach parents to read so that they can read to their children! It’s sensible and obvious once you have heard it, but no-one seems to have publicised that idea before. He announced that he will increase teachers’ salaries. He describes the US as having an “empathy deficit“, it’s obvious to almost everyone outside the US but not something that many people in the US realise. He wants decisions to be based on facts and is determined to use facts when dealing with health insurance companies. I just wish that we had some politicians like him in Australia. In terms of policy the Greens politicians would agree with him, but the combination of great policies, insight, and excellent delivery seems a lot better than any of the options in Australia.

Share This

16 March 2008

Gregor Herrmann: sunday evening

finally, after waiting for some years, we now get the profil delivered directly to our doorstep on sunday mornings too, instead of stuffed into the mailbox on monday by the regular postal service. it started two or three weeks ago, but today was the first sunday where I actually managed to take my time to read it on the first possible day.

spending two hours in the bathtub with a news magazine that is officially released only tomorrow is a good break between Java packages before & Perl packages afterwards.

Daniel Burrows: Apologies for spamming the planet...

I just happened to take a look at the output of a Web log analyzer and noticed a huge increase in traffic yesterday. I thought that was odd, since I hadn't written any new blog posts recently or published new stuff on my Web page. So I took a look at the logs themselves and noticed that a whole bunch of my recent hits listed their referer as planet.debian.net. This is where you start getting a sinking feeling...and yes, when I checked the Planet in a Web browser, sure enough, it looks like my whole blog got dumped out on the Planet. For some reason my own RSS reader didn't pick it up, so I wouldn't even have noticed if I hadn't been checking on my Web server stats. I'm not sure why, but I bet it has to do with the fact that I upgraded ikiwiki yesterday. So if you've seen the new ikiwiki version that came out recently, take a little care when you update and make sure it doesn't impact your RSS feed.

Alexis Sukrieh: The road to Backup Manager 0.7.7

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release). All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way. So, fear a new release soon…

Daniel Burrows: aptitude 0.4.11 released

I've released version 0.4.11 of the aptitude package manager (release notes). Due to ongoing work by the installer team, I uploaded this release to experimental rather than unstable; once things are clear I will upload a build to unstable (probably promoting the experimental cwidget to unstable at the same time). The initial upload accidentally left out libept support, so I'm preparing a new upload as I write this. The aptitude search language and its documentation have gotten particular attention in this release. The most visible change is the introduction of a new syntax for search expressions: in addition to the old style of ~i, you can now type ?installed. Not only is this more readable and more memorable, it means that I'll be much more able to expand the breadth of the query language: it was becoming rather difficult to select new single-character flags for search terms, so expanding the namespace is nice. On this note, a number of search terms have been added to the language; see the release notes or the aptitude user's manual for details.
PS: if you're wondering about the quote in the release notes: I just needed to vent a little about that incident in a way that I found amusing and harmless; I'm over it now, and hopefully this will be the last time I mention it in public.

15 March 2008

John Goerzen: At long last, software.complete.org migrated to Redmine

I've been writing a bit about Trac and Redmine lately. For approximately the 1/3 of the publically-available software that I've written, I maintain a Trac site for it at software.complete.org. This 1/3 is generally the third that has the most interest from others, and there's a bug tracker, wiki, download area, etc.

Trac is nice, and much nicer than one of the *Forge systems for a setup of this scale. But it has long bugged me that Trac has no integration between projects. To see what open bugs are out there on my software, I have to check -- yes -- 17 individual bug trackers.

To keep track on the wikis to make sure that nobody is adding spam, I have to subscribe to 17 different RSS feeds.

It took me some time just to hack up a way so I didn't have to have 17 different accounts to log in to...

So, mainly, my use case for Trac isn't what it was intended for.

Enter Redmine. It's similar in concept to Trac -- a lightweight project management system. But unlike Trac, Redmine allows you to have separate projects, but still manage them all as one if you please.

Redmine didn't have Git support in its latest release, but there was a patch in Redmine's BTS for it. I discussed why it wasn't being applied with Redmine's author, and then went in and fixed it up myself. (I used Git to make a branch off the Redmine SVN repo -- very slick.) Unlike Trac's Git support, Redmine's is *fast*. I tested it against a clone of the Linux kernel repo on my local machine.

There are a few things about Redmine I don't like, but I have learned that they mainly have to do with Ruby on Rails. As someone pointed out on Planet Debian lately (sorry, can't find the link), the very nature of Rails makes it almost impossible for OS developers like Debian to include Rails apps in the distribution.

Not only that, but it seems like Rails assumes that even if you are just going to *use* an app, you know how to *write* one. For instance, this is pretty much the extent of documentation on how to set up a Rails app to be able to send out mail:


# See Rails::Configuration for more options


And of course, googling that turns up nothing useful.

Redmine is a rails app, so it cannot escape some of this. It seems to be a solid piece of work, but Rails seems to make things unnecessarily complex. That, and I've found some bugs in the underlying Rails infrastructure (like activerecord not quoting the schema name when talking to PostgreSQL) that make me nervous about the stack.

But the site is up and running well now, so I'm happy, and am planning to keep working with Redmine for quite some time.

David Moreno Garza: Places I've lived in

Recently, chatting with some folks on the TextMotion IRC channel, I started thinking on the places I ve lived my whole life. From the bottom of my mind, this is a rough list: Such is life :)

Daniel Burrows: Full upgrade and conflicts

Erich Schubert wonders how to improve the handling of conflicts in package managers, particularly in aptitude full-upgrade and apt-get dist-upgrade. From the point of view of the package manager, conflicts are a bit tricky to deal with. The problem is that a conflict only really tells you not to install two packages at once; it doesn't tell you which package should end up on the system by default. Worse, aptitude has two approaches to this:
  • When a package is marked for installation in the visual interface or listed on the command-line, then if Aptitude::Auto-Install is enabled, aptitude will automatically resolve conflicts in favor of that package. The same applies to packages that are upgraded by pressing U or by full-upgrade.
  • When aptitude's dependency resolver encounters a conflict, it considers both resolutions to the conflict to be equally valid. If there are no other reasons to choose one package over the other, it will be unpredictable which one gets removed first, and even when there are reasons to choose, the user may not understand what they are.
I don't think it's possible to always make upgrades predictable. But I think that even just making Auto-Install stick to installing packages and not removing conflicts would be a plus. Installing obvious dependencies up-front is good because it means less work for the resolver and a more predictable starting point. Many trivial dependency problems can even be completely solved this way. But removing conflicts is a lot trickier and should probably kick the problem into the full resolver. Unfortunately, the code enabled by Auto-Install is all deep in the guts of libapt. I've tried to avoid duplicating this code so far, but it does seem like I periodically run into cases where it doesn't do exactly what I need, so maybe I'll have to eventually. :-(

Daniel Burrows: HOWTO get and compile the apt source repository using bzr

Getting apt apt's source code is managed using bzr. Very fine tutorials and documentation on bzr exist on the Web; I'll give a brief rundown of some useful commands here, but you should read bzr-specific documentation to get a complete understanding of it. bzr is available in the Debian repositories, and likely other distributions have a package of it as well. The master apt branch for Debian is available at http://bzr.debian.org/apt/debian-sid. Yes, that looks like an empty directory if you view it with a Web browser, but it really contains the source tree. To retrieve it, run: 
bzr branch http://bzr.debian.org/apt/debian-sid apt-debian-sid
That will download the repository to the directory apt-debian-sid. It takes a long time to download a fresh copy of the code, so be patient. When bzr branch finishes running, you have a new private copy of the source tree to work with. You can commit changes with bzr commit, download updates with bzr merge, see what you've changed with bzr diff, and copy your changes to a public location with bzr push. Read the bzr manpage and user's manual for full documentation on how to use bzr. Other public repositories of apt code include:
Compiling apt from its repository To compile apt, you'll need the following packages on Debian:
  • g++
  • make
  • libdb4.4-dev
  • gettext
  • libcurl4-gnutls-dev or libcurl3-gnutls-dev
  • xmlto
That will allow you to build apt without installing it by running make. xmlto is not listed in the Build-Depends line of apt, but you won't be able to produce manpages without it. In particular, you'll need it to produce a Debian package (see below).
Installing a build of the apt repository The easiest way to install a custom build of apt out of a repository checkout is to build a Debian package from the checkout. Install the following packages:
  • dpkg-dev
  • debhelper
and run the following command in the top-level directory of the apt repository: 
dpkg-buildpackage -rfakeroot -us -uc
This will compile apt and produce several .deb packages in the parent directory of the repository. To install the generated packages, I recommend first installing the devscripts package and then running debi. You can also install the .deb packages by hand by running dpkg -i FILENAME.deb (...). Warning: installing an interim build of apt is likely to break all the packages that depend on it, such as aptitude and synaptic; interim builds might also be buggy and do strange things to your system. You should not install an unreleased version of apt unless you are sure that you can fix any problems that you encounter as a result of doing so.

Daniel Burrows: aptitude 0.4.10 released

I've just released version 0.4.10 of aptitude, a terminal and command-line package management tool for Debian. This release has many user-visible changes (see the changelog below). It also fixes an annoying and much-reported segfault. The Debian packages of this version are built against the new version of cwidget, which is sitting in NEW, but if you're impatient you can compile it by hand by dropping the versioned dependency. The dependency is there to ensure that we don't get dependency skew across architectures (aptitude depending on libcwidget0 on some archs and libcwidget1 on others) and doesn't represent an actual build requirement of aptitude.
[12/15/2007] Version 0.4.10 Oscillating Reindeer
  • New features:
    • In command-line mode, if the resolver fails to produce a solution for whatever reason, then instead of aborting the program entirely aptitude will now display a prompt at which you can fix the dependency problems by hand. Enter r at this prompt to try to automatically fix dependencies again.
    • safe-upgrade will now install new packages to fulfill dependences (but it will never remove packages, downgrade packages, or install a version that's not the default). The option --no-new-installs will disable this behavior.
    • Updates and commands that install, remove, or upgrade packages will now display a brief summary of what changed. For instance: 
      There are now 64 updates [+10], 3 new [+1].
      Unfortunately, this change requires reading the cache after an update is complete. Passing -q will disable this behavior, but also make the update progress bar less attractive. More work on resolving this tension between features and performance remains to be done.
    • Add an option --allow-untrusted to override trust warnings. (Closes: bug #452201, bug #452541)
    • Recommended packages are now hidden if quiet mode is enabled. (Closes: bug #452202)
    • The options Aptitude::ProblemResolver::Trace-File and Aptitude::ProblemResolver::Trace-Directory allow you to generate a minimal cut of the cache that allows a problem resolver run to be reproduced. The eventual aim is both to simplify bug reporting and to generate a corpus of automatic test cases for the resolver (although more work needs to be done to accomplish the latter).
    • When run in command-line mode, instead of displaying many separate and sometimes duplicative groups of packages (e.g.: installed, auto-installed, auto-installed in a light cream sauce, etc), aptitude displays packages in a few exclusive categories and uses tags (like the existing purge tag) to provide more state information. For instance: 
      $ aptitude -s install wesnoth
The following NEW packages will be installed:
  wesnoth wesnoth-data a  wesnoth-music a 
$ aptitude -s remove freeciv-data
    (... dependency resolution ...)
The following packages will be REMOVED:
  freeciv-client-gtk a  freeciv-data freeciv-server a  ggzcore-bin u 
  libggz-gtk1 u  libggz2 u  libggzcore9 u  libggzdmod6 u  libggzmod4 u
      Here a indicates that a package was automatically installed or removed, and u indicates that a package is being removed because it is unused. Hopefully this will be less confusing than the old format.
  • Bug fixes:
    • Crashes and serious errors:
      • Track down and fix a SEGV triggered on the first action after a cache reload (sometimes). There are multiple bugs where this might have been the root cause, but it's confirmed that it was the cause of at least bug #454695, bug #454700, bug #455349, and bug #453362. Bug bug #455865 is almost certainly the same issue, and bug bug #352278 may be another manifestation of it.
      • If StepLimit is set to 0, refuse to solve dependencies instead of going into an infinite loop. (Closes: bug #451311)
    • Minor bugs:
      • Return a failing exit code after jumping from the command-line to visual mode if the last install run failed. (Closes: bug #282408)
      • Return a failing exit code from aptitude update if any download fails. (Closes: bug #233129)
    • Cosmetic and UI bugs:
      • In addition to Enter, Space will now activate checkboxes and radio buttons. (Closes: bug #451765)
      • Abort the program if we get EOF at the resolver prompt instead of claiming the resolver failed.
      • Command-line searches will now only print each result once. (Closes: bug #450798)
    • Documentation bugs:
      • The options menu documentation now minimally describes the new configuration interface.
      • The documentation of the configuration file options has been placed back in alphabetic order after apparently suffering bitrot over the years.
      • Corrected the documented default of Parse-Description-Bullets to match reality.
      • The manpages for aptitude-create-state-bundle and aptitude-run-state-bundle are now generated using DocBook, which should produce higher-quality and more consistent typesetting, as well as making the manpages more maintainable and allowing translators to easily produce localized versions of the manpages.
  • Internal changes:
    • Removed some unit tests that really tested cwidget.
  • Translation updates:
    • French (Christian Perrier)

Next.

Previous.