[Summary: NetworkManager doesn't properly transition away from
/etc/network/interfaces-configured wireless interfaces to using it's own
internal configuration database, causing them to not come up at all]
On Thu, Jan 13, 2011 at 08:30:40PM +0100, Michael Biebl wrote:
> Imho, the cleanest solution
On Mon, Dec 27, 2010 at 10:41:36PM -0600, Steve M. Robbins wrote:
> On Tue, Dec 28, 2010 at 09:38:30AM +1100, Matthew Palmer wrote:
> > On Mon, Dec 27, 2010 at 05:04:02PM +0100, Julien Cristau wrote:
> > > do you plan on NMUing pbuilder for this bug?
> >
> > No, I do
On Mon, Dec 27, 2010 at 05:04:02PM +0100, Julien Cristau wrote:
> do you plan on NMUing pbuilder for this bug?
No, I don't consider it appropriate to NMU for an RC bug that I raised the
severity on, withouth the acknowledgement of the maintainer that the
severity is justified. Someone else NMUing
On Thu, Dec 16, 2010 at 06:14:55PM +0100, Jakub Wilk wrote:
> * Matthew Palmer , 2010-12-15, 14:21:
>> +if mount |grep -q $(readlink -f $BUILDPLACE)/; then
>
> I think
>
> grep -q -F " $(readlink -f $BUILDPLACE)/"
>
> would be more robust.
Right
tag 542915 +patch
usertags 542915 -in-progress +patch-in-git
thanks
Attached is my minimal patch solving the problem of data loss in
bind-mounted directories. It provides a safety net that, in the event that
*anything* is still mounted inside the chroot, no attempt to delete anything
will be made
tag 542915 -moreinfo
severity 542915 grave
thanks
tl;dr: Data loss == grave
Yes, it's only (apparently) hit one person in the wild, but I think the fact
that significant data loss can *ever* occur warrants the severity. I am,
however, working on a fix now, so at least it's presence (regardless o
package ninvaders
tag 597036 pending
thanks
Hi Matt,
Thanks for the patch. The problem doesn't occur for me (I'm guessing it's
an ncurses version change that causes the crash), but I've applied the patch
as it's definitely a potential problem.
I'll make a new upload to unstable Real Soon Now, a
As further confirmation, I've just tested an install on an armel box with
Colin's patch, and it worked nicely there, too.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I can confirm that Colin's patch of Tue, 21 Oct 2008 22:57:45 +0100 fixes
the problem for me on a test install on amd64. I tested by building parted
and then putting the udeb into localudebs and putting it into the initrd.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Fri, Oct 19, 2007 at 09:16:37PM -0400, The Anarcat wrote:
> On Sat, Oct 20, 2007 at 11:06:07AM +1000, Matthew Palmer wrote:
> > Gah, I despise PID files. And programs that assume things about their
> > placement and permissions.
>
> Well, pidfiles do have a function, how
On Fri, Oct 19, 2007 at 08:19:31PM -0400, The Anarcat wrote:
> The fix is simple, and should be part of the postinst (or simply in
> debian/rules):
>
> mkdir /var/run/puppet
> chown puppet:puppet !$
This fix won't work, because /var/run is often a tmpfs, so /var/run/puppet
will get lunched on reb
On Sat, Jan 06, 2007 at 05:36:51PM +, Alex Owen wrote:
> I do not read or write ruby... but I think the problem lies in
> function setpidfile in the file puppet-0.20.1/lib/puppet/daemon.rb
>
> The code looks like:
>Puppet.info "Creating PID file to %s" % @pidfile
>
reassign 389579 libapache2-mod-auth-mysql
thanks
I doubt that anyone would file a bug against an Apache 1.3 module because it
didn't compile with Apache2, so I'm putting this in it's right spot...
At any rate, I don't have a lot of Apache servers left these days (having
switched largely to lightt
On Wed, Sep 07, 2005 at 07:44:36PM +0200, Manolo Díaz wrote:
> console message after crashing:
>
> Including /var/lib/fbpanel/menu
> fbpanel[7544]: segfault at 0008 rip 2e767687 rsp
> 7ff37d20 error 4
>
> I think it could be a specific x86_86 bug.
Could you do some t
Should this bug perhaps be closed now? It's unlikely that this bug has much
value in being fixed.
- Matt
signature.asc
Description: Digital signature
Package: phpwiki
Tags: security
Severity: serious
Just got this through the PHPWiki list. I'm going to pull xmlrpc.inc as
suggested. I pulled the package from Sarge because I didn't think it was
releasable, so there's no need to go through a full DSA cycle. Just keeping
the security team in the
Are you referring to this code in storage/gdbm/gdbm.c::gdbm_init():
/* check record lengths. This is the only spot where these
* values are hard-coded.
*/
if (sizeof(gdbm_timestamp) != 5
|| sizeof(gdbm_data_value_header_t) != 16
On Sat, Mar 26, 2005 at 11:10:42AM +0100, Jérôme Warnier wrote:
> I used to use phpWiki on Debian, and I'm wondering exactly what minor
> bugs make it unreleasable.
> Could you detail, or better, submit bugreports?
#243466. Beyond that, I get the feeling from the upstream mailing list
(phpwiki-ta
Package: phpwiki
Severity: serious
Version: 1.3.7-3
I do not believe that the phpwiki package, as-is, is suitable for testing.
It is several minor releases behind upstream, will take significant work to
ensure easy upgrades to the latest upstream version, and has lots of minor
things that make it
tag 296662 unreproducible
thanks
Naturally, you verified that the bug exists in the Debian packaged version
of IRM before you submitted the bug report, in which case you can give me
the recipe you used to exploit it in the Debian environment.
I had no luck in making this bug appear -- for me, the
On Mon, Feb 07, 2005 at 06:05:27AM -0700, Adam Conrad wrote:
> Due to the simplicity and non-intrusiveness of these changes, if I don't
> see uploads in the next 24 hours, I will happily NMU to fix the affected
> packages.
These would be simple and non-intrusive changes like those made for the
Apa
21 matches
Mail list logo
