Hello,
We just patches some of our production Wheezy machines
and encountered this bug as well. In our testing on systems where
there's only one PV in the VG the root device is the /dev/mapper version
in grub.cfg. On systems where there's more than one PV in the VG
grub.cfg gets the UUID of
On 2014-01-30 18:22, gregor herrmann wrote:
On Thu, 30 Jan 2014 17:42:49 +0100, Fernando Santagata wrote:
Sorry for my lack of interaction: after some time everything started
to work fine again. I saw that the bug was in state closed and I
didn't think to write back to you.
#718432 isn't
Hi Fernando,
How are you defining $r in the code you're referencing in Debian bug
718432? Can you send your my $r = line from your code?
Did you switched from mod_perl 1 to mod_perl 2 when upgrading Apache or
was this code working under earlier versions of Apache 2.x?
Keith
So after doing some more digging I've learned that plymouth is shut down
by the init script although it's not clear to me why it's called after
the KDM init script in runlevel 2:
l430:/etc/rc2.d$ ls -l|grep kdm
lrwxrwxrwx 1 root root 13 Sep 3 13:30 S18kdm - ../init.d/kdm
l430:/etc/rc2.d$ ls
I enabled debugging for the Plymouth daemon but it didn't really tell me
much.
Looking at the documentation for Plymouth[1] and /bin/plymouth --help it
looks to me like the display manager is responsible for telling plymouth
to quit. However there isn't anything in the KDM init scripts to
I'm experiencing this bug as well but with KDM. I originally thought
this was related to the known issues[1][2] with KDM and Plymouth but it
looks like it may be a wider issue in Debian.
I'm running jessie on a Lenovo L430 which has an Intel display driver.
Using a hand rolled kernel version
Package: cairo-dock-messaging-menu-plug-in
Version: 3.3.0-1+b1
When I enable the cairo messaging plugin I get the following error when
I double click on it:
The messaging service did not reply. Please check that it is correctly
installed.
I'm unable to determine what messaging service the
On Sat, Aug 13, 2011 at 11:57 PM, Satoru KURASHIKI wrote:
I guess there is no PHP code which using GDBM code. If there is,
they
had falled into troubles after php switched to link from gdbm to
qdbm,
because PHP source package also doesn't include hovel.h. I think
that I
should care the
On Thu, 11 Aug 2011 18:50:12 +0200, Jakub Wilk wrote:
* KURASHIKI Satoru , 2011-08-11, 08:44:
I want to make libqdbm14 dropping gdbm emulation, and add a new
exclusive libqdbm14-gdbm package to provide compatibility for
people
who uses its gdbm emulation. But, I have trouble with packaging
On Mon, 8 Aug 2011 16:31:40 +0200, sean finney wrote:
On Mon,
Aug 08, 2011 at 01:58:27PM +0100, Ian Jackson wrote:
Keith Lawson
writes (How to close bug #620550?): 2. Unless someone knows why PHP is
using qdbm, it should IMO be switched back to gdbm. This is not RC I
think.
I refer
On Sat, 30 Apr 2011 02:39:30 +0900, Satoru KURASHIKI wrote:
hi,
On Sun, Apr 24, 2011 at 2:35 AM, Keith Lawson wrote:
Would it be appropriate to split QDBM into a package with GDBM
compatibility and one without? To get around the problem so we can
upgrade our web servers we removed all gdbm_
On Tue, 26 Apr 2011 18:22:25 +0200, Ansgar Burchardt wrote:
Hi,
Keith Lawson writes:
MySQL won't even let me create the situation described. While it
will
allow for NULL or 0 in a primary key field it only allows for one of
them:
[...]
mysql insert into test_table (pkey,text) values
Package: wnpp
Severity: wishlist
Owner: Keith Lawson ke...@nowhere.ca
* Package name: libapache2-authcookie-perl
Version : 3.18
Upstream Author : Michael Schout msch...@gkg.net
* URL : http://search.cpan.org/dist/Apache-AuthCookie/
* License : GPL, Artistic
On Mon, 25 Apr 2011 20:39:59 +0100, Nicholas Bamber wrote:
I would suggest trying to reproduce this and then debug through the
DBI
code at least. Then it should either be forwarded or marked
unreproducible.
MySQL won't even let me create the situation described. While it will
allow for NULL
But I'm not sure how to fix this problem.
(Is it valid to
downgrade qdbm's versions lower than 1.8.3 ...?)
The problem I've
encountered is specifically with gdbm_open. The version exported from
QDBM overwrites the GDBM version for code running under mod_perl because
PHP in Debian is now
On 4/7/2011 at 1:24 AM, in message 20110407052431.gd10...@ktnx.net,
Damyan
Ivanov d...@debian.org wrote:
[Please excuse the CC in case you are subscribed to debian-perl]
-=| Keith Lawson, Wed, Apr 06, 2011 at 03:39:19PM -0400 |=-
I recently opened bug #620550 under libapache2-mod-perl2
On 4/7/2011 at 10:52 AM, in message
4d9d976a02ac0002c...@sjhcgwiao2.sjhc.london.on.ca, Keith Lawson
keith.law...@sjhc.london.on.ca wrote:
On 4/7/2011 at 1:24 AM, in message 20110407052431.gd10...@ktnx.net,
Damyan
Ivanov d...@debian.org wrote:
[Please excuse the CC in case you
Are we sure this isn't another one of those libdb/libapr breakages?
Our mod_perl code is using GNU DBM, not Berkely DB.
I've tested building libphp5.so from the php.net source for php-5.3.3 and the
problem still persists with my own compiled library.
I've also tried to get a backtrace
I've tested building libphp5.so from the php.net source for php-5.3.3 and
the problem still persists with my own compiled library.
Sorry I was wrong there. I actually managed to break my own test script. The
shared lib I built *does* work. I've attached the shell script I used to run
configure
I've discovered that I can fix mod_perl 2 by removing libapache2-mod-php5.
Looking at the files installed by libapache2-mod-php5 I don't see anything that
should break tie() in mod_perl when that package is installed but it definitely
is.
Can this bug report be moved over to
On 4/4/2011 at 3:06 PM, in message 20110404190614.gk2...@ktnx.net, Damyan
Ivanov d...@debian.org wrote:
-=| Keith Lawson, Mon, Apr 04, 2011 at 12:03:21PM -0400 |=-
I've discovered that I can fix mod_perl 2 by removing
libapache2-mod-php5. Looking at the files installed by
libapache2-mod
Package: libapache2-mod-perl2
Version: 2.0.4-7
Severity: important
After upgrading from lenny to squeeze calls to tie() from code running in
mod_perl 2 are failing.
The following code works fine from the command line but the tie() fails
silently when running in mod_perl 2:
print STDERR $0:
(a blind shot) What are the chances that there are some locally installed
modules (e.g. directly from CPAN) in /usr/local that are used instead of
the upgraded packaged modules in /usr ?
I do have modules installed from the CPAN shell. I just did:
mv /usr/local/lib/perl/5.10.0
23 matches
Mail list logo
