On Tue, 01 Nov 2011, Colin Watson wrote:
> What I think we settled on as the least bad option is to refine the
> dpkg-buildpackage workaround so that it does not export environment
> variables if the package it's building is using debhelper compat level 9
> or above, and to manually review all such
Hi Martin,
On Fri, 15 Jul 2011, Martin Pitt wrote:
> sorry for the very late reply, this got lost in my mailbox.
Heh, I see that didrocks did not forget to ping you :-)
> Raphael Hertzog [2011-05-01 9:24 +0200]:
> > Introducing a work-around in the already released appor
On Sun, 10 Jul 2011, Reinhard Tartler wrote:
> Naturally, I've forwarded that change to debian and got the following
> response. If someone objects to the change I've implemented, please tell
> so me and I'll revert it. Otherwise, I'll follow what change James will
> implement in debian and replace
On Mon, 02 May 2011, Brian Murray wrote:
> This particular bug report was reported during a distribution upgrade of
> Ubuntu from Maverick to Natty. This is recognizable by the attachments
> named 'VarLogDistupgrade'. The call to apport was actually made by
> update-manager, in DistUpgradeView.py
Hi,
On Mon, 02 May 2011, Robert Collins wrote:
> On Sun, May 1, 2011 at 7:24 PM, Raphael Hertzog wrote:
> > whenever an upgrade fails early in the unpack (either broken preinst,
> > corrupted archive, etc.), APT still tries to configure it and
> > it results in a suppl
Hello,
whenever an upgrade fails early in the unpack (either broken preinst,
corrupted archive, etc.), APT still tries to configure it and
it results in a supplementary error in the upgrade log that looks like
this:
dpkg: error processing onboard (--configure):
package onboard is already installe
On Fri, 08 Apr 2011, Dave Morley wrote:
> We now have the blue Ubuntu indicator when an application requires
> viewing so I don't particularly see not having an indicator as an issue
> as long as the application icon shows up in the app launcher. If we
> went with gnome 3.0 people would have the s
Hi,
On Wed, 09 Feb 2011, sean finney wrote:
> so i didn't exactly leave in a huff, but i did signal that i had
> no further intention of wasting my time until i had some idea
> that it would actually go anywhere.
I'm sorry for all this. The problem is that Guillem is a single point of
failure in
Hi,
On Mon, 13 Dec 2010, Daniel Holbach wrote:
> The general plan looks like this:
> 1. decide on a toolkit
I would highly suggest that you give a try to publican. It's already
available in Ubuntu and I co-maintain it in Debian.
It's docbook based but it generates good looking documentation, an
