Insider infos, master your Debian/Ubuntu distribution
If you checkout Dropbox’s Linux download page, you will see that Debian packages are provided. Up to a few days ago, they only provided packages for Ubuntu and Fedora.
I’m glad to see that packaging nautilus-dropbox for Debian and being in touch with them due to this led to this result.
Another positive outcome is that the version 0.7.0 now ensures the origin of the downloaded binaries with GPG.
I am currently running a crowdfunding campaign whose ultimate goal is to liberate the English translation of a French book that I have written. This book will be named The Debian Administrator’s Handbook because it has primarily been written for Debian.
But since Ubuntu is based on Debian, a large part of its content applies equally well to Ubuntu. While discussing with Mark Shuttleworth, he suggested me to reuse those parts and to create a new book dedicated to Ubuntu. It would also cover the latest cloud technologies that Ubuntu has been delivering (since this is a topic that the current book does not cover).
This is something that I have been envisioning for a while and something that I would be ready to try if we manage to complete the liberation of the current book. This project would then bring a truly free book to the Ubuntu ecosystem.
There’s a policy in place that ensures that official Ubuntu books use a free software/culture license and they are effectively available under the terms of a Creative Commons Share Alike license. But try to create a derivative book… you won’t find the “sources” (LaTeX or DocBook usually with most big books). You can only find a few PDF copies if you google for it. But this is really not the preferred form of modification for such a book.
Those books are also not packaged. Ubuntu much like Debian deserves to have a good book embodying the values of free software that can be shipped together with its product.
When I speak of liberation of the book, I really mean it in the way that free software hackers are used to: a public Git repository containing the DocBook sources, the pictures and the .dia files for the various schemas.
I understand that at this point this proposed Ubuntu book is really hypothetical (“vaporware” one could say) but we need to go step by step to make it a reality. And the first step is to ensure that we manage to liberate the Debian Administrator’s Handbook.
For this I am seeking the support of the Ubuntu community to promote the current fundraising campaign. If the perspective of the Ubuntu book is not enough to convince you, you’ll be glad to learn that I also commit to give back to Ubuntu 15% of the money raised via the link below (once VAT has been subtracted).
Click here to go to the crowdfunding campaign page and pledge a few euros. Then share this article (or the link https://debian-handbook.info/go/ulule-ubuntu/) and convince others to participate.
At this point, the liberation target is entirely reachable with your help and the help of the community: the remaining 18 K€ needed in the liberation fund represent 720 persons giving 25 EUR each or 1800 persons giving 10 EUR each.
Thank you very much for your support and your help in this project!
Continuing my series of articles on dpkg’s errors, this time I’ll cover a pretty common one which has several variations:
Setting up acpid (1:2.0.12-1) ... rm: cannot remove `/etc/rc1.d/K20acpid': No such file or directory dpkg: error processing acpid (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: acpid
Even if dpkg is failing and outputting the error message, the real problem is not in dpkg but in the installed package (acpid in the example above). As we already learned, a package contains not only files but also “maintainer scripts” that are executed at various points of the installation process (see some useful graphics to understand how they are called, thanks to Margarita Manterola).
In the introductory example it was acpid’s “post-installation script” that failed, and dpkg is only forwarding that failure back to the caller. The maintainer scripts are stored in /var/lib/dpkg/info/. You can thus inspect them and even modify them if you hit a bug and want to work around it (do this only if you understand what you do!).
One common modification is to add “set -x” at the start of the script and to retry the failing operation. That way you can see what’s executed exactly. Here’s what the output could look like after the addition of “set -x” to /var/lib/dpkg/info/acpid.postinst:
$ sudo dpkg --configure acpid Setting up acpid (1:2.0.12-1) ... + dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.10-3 + dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.6-16 + dpkg --compare-versions 1:2.0.11-1 lt 1.0.6-6 + rm /etc/rc1.d/K20acpid rm: cannot remove `/etc/rc1.d/K20acpid': No such file or directory dpkg: error processing acpid (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: acpid
This output helps you locate the command that is actually failing. Here’s it’s relatively easy since we have an error message from “rm”. And the fix is trivial too, we replace “rm” with “rm -f” so that it doesn’t fail when the file doesn’t exist (this is a fake bug I made up for this article—I just added a failing rm call—but it’s inspired by real bugs I experienced).
Maintainer scripts are supposed to be idempotent: we should be able to execute them several times in a row without bad consequences. It happens from time to time that the maintainer gets this wrong… on the first try it works, so he uploads his package and we discover the problem only later once someone ended up executing the same code twice for some reason.
Follow me on Identi.ca, Twitter, Facebook and Google+. Or subscribe to this blog by RSS or by email.
This is probably one of the most common errors. You’re very likely to encounter it, in particular if you tend to mix packages from various origins/distributions, or if you’re using unstable. It looks like this:
Unpacking gbonds-data (from .../gbonds-data_2.0.3-2_all.deb) ... dpkg: error processing /var/cache/apt/archives/gbonds-data_2.0.3-2_all.deb (--unpack): trying to overwrite '/usr/share/omf/gbonds/gbonds-C.omf', which is also in package gbonds 2.0.2-9 dpkg-deb: subprocess paste killed by signal (Broken pipe)
A given file can only be provided by a single package. So if you try to install a package that provides a file that is already part of another installed package, it will fail with a message similar to the above one.
Sometimes this failure will be meaningful because dpkg prevented you to install two unrelated packages that happen to have a real file conflict. In other cases, like in the example above, this failure is just the result of a mistake.
The version 2.0.3-1 of gbonds split the architecture independent files in a separate package called gbonds-data but the maintainer forgot to add the required control field in gbonds-data (Replaces: gbonds (<< 2.0.3-1)). That field allows dpkg to take over files from the listed packages.
If you want to ignore the file conflict and let dpkg take over the file (even without the Replaces), you can pass the --force-overwrite command-line option.
But you’re not using dpkg directly, you’re probably using an APT frontend (like apt-get or aptitude). Don’t worry, there’s a simple way to define custom dpkg options to use:
# apt-get -o Dpkg::Options::="--force-overwrite" install gbonds-data
The syntax is a bit weird, but the “::” after “Options” is important, it’s the syntax that defines a list item value instead of a single value. And you can effectively pass multiple options to dpkg by putting multiple -o Dpkg::Options::="…".
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.
