On Thu, 2024-11-21 at 17:13 +0100, Bastian Germann wrote:
> Control: severity -1 serious
>
> Am 21.11.24 um 16:33 schrieb James Bottomley:
> > Ideally I'd prefer Debian to have the same version as every other
> > distribution, but I think removing the ancient version
On Fri, 05 Jun 2015 15:24:09 +0100 Peter J Ross wrote:
> On Fri, 05 Jun 2015 12:04:52 +0100 =?utf-8?b?SnVoYSBKw6R5a2vDpA==?=
> wrote:
> > Not a SCALAR reference at /usr/bin/get-iplayer line 7099.
>
> This has been fixed upstream in version 2.93.
>
> Current upstream version is 2.94.
I confirm
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.
> >
> >
On Sat, 2012-05-19 at 16:19 +0200, Marco d'Itri wrote:
> On May 19, James Bottomley 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.
In
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.
Thi
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 don
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).
&
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 tried
db5.1_recover -h /var/lib/postgrey/
but that doesn't fix the problem. Whateve
'd child never writes
> > 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).
>
>
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote:
> > (5) Child process B is waken up and sees old value at in
> ,
> > through different cache line. B sleeps.
>
> This isn't possible. at this point, A and B have the same virtual
> address and mapping
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 userspac
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
> > in
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: Proces
> 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 i
s actually caused 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 Botto
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 tha
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 c
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 upg
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
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
> >
> >
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 0.0
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
CC
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:
http://bugs.gentoo.org/show_b
24 matches
Mail list logo
