On Fri, 05 Jun 2015 15:24:09 +0100 Peter J Ross peadar.ru...@gmail.com wrote:
On Fri, 05 Jun 2015 12:04:52 +0100 =?utf-8?b?SnVoYSBKw6R5a2vDpA==?=
ju...@iki.fi wrote:
Not a SCALAR reference at /usr/bin/get-iplayer line 7099.
This has been fixed upstream in version 2.93.
Current upstream
On Sat, 2012-05-19 at 22:40 +0100, Adam D. Barratt wrote:
On Sat, 2012-05-19 at 19:55 +0100, James Bottomley wrote:
On Sat, 2012-05-19 at 16:19 +0200, Marco d'Itri wrote:
There is no bug, just don't do stupid things to your system.
Yes, there is. The bug is that testing breaks
Package: netbase
Version: 5.0
Followup-For: Bug #672851
This bug is still present in testing
It means that anyone who does a dist-upgrade -t testing gets no
networking. This just happened to me with a co-lo box resulting in a
wasted hour investigating the source of an apparent boot failure.
On Sat, 2012-05-19 at 16:19 +0200, Marco d'Itri wrote:
On May 19, James Bottomley james.bottom...@hansenpartnership.com wrote:
It means that anyone who does a dist-upgrade -t testing gets no
networking. This just happened to me with a co-lo box resulting in a
Don't do it then ffs
On Sat, 2011-03-05 at 10:34 -0600, James Bottomley wrote:
If I remove the transactions and just do a straight delete, everything
works (at least in my test environment; I'll try it on the real program
tonight). There's actually no real reason for the deletes to be done
transactionally. Even
On Fri, 2011-03-04 at 15:06 -0400, Joey Hess wrote:
James Bottomley wrote:
I picked this up on a recent testing upgrade (last Saturday). My
postgrey process is now dying every night as well (I've set up a harness
to restart it, but it's not ideal).
Following what happened in #441069 I
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
(5) Child process B is waken up and sees old value at x in
oldpage,
through different cache line. B sleeps.
This isn't possible. at this point, A and B have the same virtual
address and mapping for oldpage this means
to the memory that causes the fault.
Thanks for writing and testing a patch.
The case of #561203 is second scenario. I think that this case is
relevant to VIVT-WB machine too (provided kernel does copy by kernel
address).
James Bottomley wrote:
So this is going to be a hard sell because
On Sun, 2010-04-04 at 22:51 -0400, John David Anglin wrote:
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible
On Fri, 2010-04-02 at 12:48 +0900, NIIBE Yutaka wrote:
Thanks for your quick reply.
James Bottomley wrote:
In COW breaking, the page table entry is copied, so A and B no longer
have page table entries at the same physical location. If the COW is
intact, A and B have the same physical
On Fri, 2010-04-02 at 11:41 +0900, NIIBE Yutaka wrote:
(9) Process B does read-access on memory, which gets *NEW* data in
cache (if process space identifier color is same).
Process B does write-access on memory which causes memory fault,
as it's COW memory.
Note: Process B
I am not very good at GCC optimizations. Can you please explain why
this problem is not seen on other architectures? Also can you please
advise if I should add this compiler option for all arch or just hppa.
It's not really a gcc problem, it's an ELF one. The ELF spec for HPPA
says that we
On Sun, 2009-09-06 at 12:06 +0100, Antonio Radici wrote:
thanks for your report, I wrote a preinst script which is running a
db4.7_upgrade if we are upgrading from a version less than 1.31-1.
That sounds like a good fix, thanks.
This is fixed in the git repo in collab-maint and it will be
by binutils outputting duplicate .text
section names. However, this trips a panic on boot because kernel/modules.c
has insufficient error checking for this case
Patches to fix this are
From 1b364bf438cf337a3818aee77d68c0713f3e1fc4 Mon Sep 17 00:00:00 2001
From: James Bottomley james.bottom
On Sat, 2009-08-15 at 19:21 +0100, Ben Hutchings wrote:
On Sat, 2009-08-15 at 10:47 -0700, james.bottom...@hansenpartnership.com
wrote:
Package: linux-image-2.6.30-1-686
Version: 2.6.30-5
Severity: serious
Justification: Policy 2.2.1
That very same section explains why we cannot do
OK, so lets go back to basics here.
The point of a bug report is to report a bug. The Bug here is that
large numbers of systems will break on upgrade to this kernel once it
hits stable. This is the problem that needs fixing.
The fact that you find the suggested fix politically incorrect, or
Package: postgrey
Version: 1.32-3
Severity: serious
Justification: Policy 2.2.1 makes package to buggy to release
This looks to be an incidental fault affecting postgrey, but the serious
consequence is that postgrey refuses to start.
What seems to have happened is that on the recent system
Package: asterisk-app-fax
Version: 0.0.20070624-1
Severity: critical
Justification: causes serious data loss
Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev
is pretty tight. It looks like there was a binary incompatible change
introduced by the upgrade from 0.0.4pre16 to
On Mon, 2008-05-05 at 21:47 +0300, Tzafrir Cohen wrote:
On Mon, May 05, 2008 at 01:13:40PM -0500, James Bottomley wrote:
Package: asterisk-app-fax
Version: 0.0.20070624-1
Severity: critical
Justification: causes serious data loss
Apparently the dependency of asterisk-spandsp-plugins
On Mon, 2008-05-05 at 21:30 +0300, Faidon Liambotis wrote:
James Bottomley wrote:
Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev
is pretty tight. It looks like there was a binary incompatible change
introduced by the upgrade from 0.0.4pre16 to 0.0.4pre18
I
Package: linux-image-2.6.24-1-parisc
Version: 2.6.24-5
Severity: critical
Tags: patch
Justification: breaks the whole system
This actually isn't just a bug in debian, it affects every distro which
uses the stable tree as a base
for instance, the gentoo bug is here:
Package: linux-image-2.6.24-1-parisc64
Version: 2.6.24-5
Severity: critical
Tags: patch
Justification: breaks the whole system
The parisc 64 bit kernel panics on boot with this:
CC net/ipv4/netfilter/iptable_raw.mod.o
CC net/ipv4/tcp_diag.mod.o
CC net/ipv4/tunnel4.mod.o
22 matches
Mail list logo
