I just got a patch today that wants to move the openssl_tpm2_engine to
using a newer form of the martial functions that were introduced in
v1331 and thus aren't in the version packaged by Debian. The trigger
is that the older forms are deprecated and can now be compiled out for
newer versions of t
On Sat, 2023-07-22 at 16:19 +0100, Richard Lewis wrote:
> On Sat, 22 Jul 2023 at 15:48, james.bottom...@hansenpartnership.com
> wrote:
> > The systemd chkrootkit.timer has this line:
> >
> > OnBootSec=30min
> >
> > Which means it runs 30 minutes after a reboot. I tend to upgrade
> > my servers
On Wed, 2022-12-07 at 17:04 +0100, Ard Biesheuvel wrote:
> On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann wrote:
> >
> > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote:
> > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote:
> > > > So
On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote:
> So at some point, these drivers will be removed rather than kept
> alive by the core team unless someone steps up.
How important is keeping them alive? I can volunteer to "maintain"
them which I anticipate won't be much effort (plus I'm u
On Sun, 2022-12-04 at 23:49 +0100, Dylan Aïssi wrote:
> Le dim. 4 déc. 2022 à 23:28, James Bottomley
>
> So please restore the state of this bug report and open your own bug
> report.
I'm not really as expert in the bug control system as debian developers
are supposed to be but I
On Sun, 2022-12-04 at 22:42 +0100, Dylan Aïssi wrote:
> Le sam. 3 déc. 2022 à 15:45, James Bottomley
> a écrit :
> >
> > I just tested this out with the same results as previously reported
> >
>
> Do you mean you don't have sound at all using pipewire 0.
I just tested this out with the same results as previously reported
James
mythtv still works fine, but google-chrome (used for streaming)
doesn't. I'm still using pulseaudio with pipewire-pulse and what
pavucontrol shows me is google-chrome having difficulty connecting to
the audio output (keeps appearing and disappearing in the playback
tab).
Falling back to 0.3.58 fi
Subject: linux-image-5.5.0-2-amd64 won't boot in a AMD SEV Virtual Machine
Package: src:linux
Version: 5.5.17-1
Severity: important
The boot failure is total: not even a console log can be seen, and
seems to be due to the necessary memory encryption option not being set
in the debian kernel:
# C
On Wed, 2019-10-02 at 22:07 +0200, Salvatore Bonaccorso wrote:
> > Linux Kernel 5.2 is completely unusable on most of my systems. The
> > problem seems to be something to do with memory compaction causing
> > intervals where the system becomes unresponsive.
> >
> > This is definitely an upstream
Package: src:linux
Version: 5.2.9-2
Severity: important
Tags: upstream
Dear Maintainer,
Linux Kernel 5.2 is completely unusable on most of my systems. The problem
seems to be something to do with memory compaction causing intervals where
the system becomes unresponsive.
This is definitely an up
On Tue, 19 Mar 2019 21:53:41 + Scott Kitterman wrote:
> This is fixed in a new upstream release that I expect to package
> shortly.
Me too on being affected by this and waiting to the fixed version 3.4.4
being packaged. Since postfix is actually rejecting email permanently,
shouldn't this be
On Tue, 2019-01-29 at 10:54 +0100, Bernhard Schmidt wrote:
> Hi James,
>
> thanks. Have you raised this issue with upstream somehow? I know
> chan_sip is deprecated, but I doubt a bug this severe would be
> undetected for that long.
>
> I'll try to whip together a test for this (my test installat
On Thu, 2019-02-07 at 22:55 +0100, Jean-Marc wrote:
> On Mon, 26 Nov 2018 23:41:13 +0100 Sebastian Andrzej Siewior a...@breakpoint.cc> wrote:
> > On 2018-11-04 22:15:04 [+0100], Kurt Roeckx wrote:
> > > > You're implying openvpn doesn't pick up the openssl.cnf changes
> > > > so I have to set tls-
Tags: patch
This is the patch I have applied to my system which fixes the problem
locally
James
---
Index: BUILD/channels/chan_sip.c
===
--- BUILD.orig/channels/chan_sip.c
+++ BUILD/channels/chan_sip.c
@@ -10997,6 +10997,8 @@ stati
On Thu, 2018-11-08 at 23:23 +0100, Daniele Tricoli wrote:
> On 11/8/18 10:26 PM, James Bottomley wrote:
> > The reported bug is a well known API incompatibility going> from
> > urllib3 1.23 to 1.24 and affects more than just mythtv.
>
> It's not sure that this is
On Thu, 2018-11-08 at 22:10 +0100, Daniele Tricoli wrote:
> Thanks for your report!
> Unfortunately package from deb-multimedia.org are not official, so
> you should ask to deb-multimedia.org maintainers as reported in their
> FAQ
I don't think this is necessarily their fault. The reported bug is
Package: python-urllib3
Version: 1.24-1
Severity: important
Mythtv version 29.1+fixes20180821.gite5fc66e822-dmo2 is failing with
mythtv@vito:~$ /usr/share/mythtv/metadata/Television/ttvdb.py -B Superstore
Traceback (most recent call last):
File "/usr/share/mythtv/metadata/Television/ttvdb.py",
On Sun, 2018-11-04 at 21:30 +0100, Kurt Roeckx wrote:
> On Sun, Nov 04, 2018 at 12:13:43PM -0800, James Bottomley wrote:
> >
> > No, I'm saying with no client tls-version-min specified at all (the
> > usual default openvpn config) it fails in 1.1.1 and works with
>
On Sun, 2018-11-04 at 21:10 +0100, Kurt Roeckx wrote:
> On Sun, Nov 04, 2018 at 11:39:59AM -0800, James Bottomley wrote:
> > >
> > > On which side do you use tls-version-min?
> >
> > client
> >
> > > Can you please give the version of bo
On Sun, 2018-11-04 at 20:32 +0100, Kurt Roeckx wrote:
> On Sun, Nov 04, 2018 at 11:19:41AM -0800, James Bottomley wrote:
> > On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> > > This is not at all how the version negiotation in TLS 1.2 and
> > > below works. Th
On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> This is not at all how the version negiotation in TLS 1.2 and
> below works. The client just indicates the highest version it
> supports, so for instance TLS 1.2. It's then up to the server to
> pick a version that the client supports, so one
On Sun, 2018-11-04 at 18:43 +0100, Kurt Roeckx wrote:
> Older versions of openvpn only support TLS 1.0 because they told
> OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
> should make it support all TLS versions since openvpn 2.3.4 or
> something like that, and I think 2.4 or newer s
Package: openssl
Version: 1.1.1-2
Severity: important
I've applied all the downgrades recommended to the openssl.cnf file
and most services are now working again with the exception of openvpn.
The only failure seems to be a VPN connection to an openwrt router.
The router is running Chaos Calmer 1
I'm getting this same segfault as well. My old remote fell apart, so I
was trying to train the IR receiver on a new one (well, the unused VCR
section of the current TV remote.
This is what I get:
Starting program: /usr/bin/irrecord -d /dev/lirc0 -f
[Thread debugging using libthread_db enabled]
U
I can confirm that all the previously failing tools (dovecot, stunnel
etc) are working again with 1.1.0g-2
Presumably this also fixes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875423
James
On Wed, 2017-08-16 at 08:34 +0200, Sebastian Andrzej Siewior wrote:
> On 2017-08-14 10:46:04 [-0700], James Bottomley wrote:
> >
> > Just a me too on this: on upgrade, both dovecot and a stunnel based
> > web application got broken for an older android client.
> > Do
Just a me too on this: on upgrade, both dovecot and a stunnel based web
application got broken for an older android client. Downgrading
to 1.1.0f-3 fixes the problem for both dovecot and stunnel4
James
On Wed, 2016-05-11 at 12:06 +0200, Michael Biebl wrote:
> Hi James
>
> On Thu, 15 Oct 2015 10:55:05 -0700 James Bottomley
> wrote:
> > On Thu, 2015-10-15 at 19:45 +0200, Michael Biebl wrote:
> > > Btw, in both cases (#770135 and #793814) the users have been
> > &
On Thu, 2016-02-11 at 23:41 +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 17 Jan 2015 09:08:32 -0800 James Bottomley
> wrote:
> > Package: systemd
> > Version: 215-8
> > Severity: normal
> >
> > Almost every time the system reboo
On Thu, 2015-10-15 at 19:45 +0200, Michael Biebl wrote:
> Btw, in both cases (#770135 and #793814) the users have been restarting
> the dbus daemon. You mentioned that you did not do that.
>
> So I'm not sure if it's actually the same issue after all and your
> problem should be tracked as a separ
On Thu, 2015-10-15 at 07:35 +0200, Stefano wrote:
> Same here. I have a git server with clients connecting every 10 minutes or
> so via SSH, and the problem is exactly the same.
>
> About 20 hours from reboot logind goes nuts, then it must be restarted at
> very variable intervals, about a couple
On Thu, 2015-10-15 at 01:06 +0200, Michael Biebl wrote:
> Am 15.10.2015 um 00:34 schrieb James Bottomley:
> > On Thu, 2015-10-15 at 00:30 +0200, Michael Biebl wrote:
> >> Am 15.10.2015 um 00:16 schrieb James Bottomley:
> >>> Since there doesn't seem to have
On Thu, 2015-10-15 at 00:30 +0200, Michael Biebl wrote:
> Am 15.10.2015 um 00:16 schrieb James Bottomley:
> > Since there doesn't seem to have been any progress on this from the
> > systemd side, and I'm really tired of my email users yelling at me
> > (justifiabl
Since there doesn't seem to have been any progress on this from the
systemd side, and I'm really tired of my email users yelling at me
(justifiably since once the systemd-logind service dies, dovecot sasl
fails to work and they can't send email), this is the script I came up
with to alleviate the p
Package: asterisk
Version: 1:13.1.0~dfsg-1.1+b1
Severity: normal
Under systemv init, asterisk is spawned by /etc/init.d/asterisk, which
checks the /etc/default/asterisk file and spawns asterisk realtime
(with the -p flag) unless the default is altered to AST_REALTIME=no
However, with the change t
On Sun, 2015-10-04 at 23:06 +, Debian Bug Tracking System wrote:
> Well, this is apparently an apache configuration problem, causing the
> service to return a non-zero exit code.
>
> Once you fix that, the service should not be marked as failed.
That's pretty obviously an incorrect deduction,
On Wed, 2015-09-30 at 15:20 +0200, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> Am 26.09.2015 um 18:08 schrieb James Bottomley:
> > Package: systemd
> > Version: 226-3
> > Severity: normal
> >
> > rebooting the current system often causes listed i
Package: systemd
Version: 225-1
My fatal symptoms are that Postfix SASL stops working with
Sep 17 07:11:11 bedivere postfix/smtpd[20955]: warning: unknown[x.x.x.x]: SASL
PLAIN authentication failed: Connection lost to authentication server
Which is really annoying because it requires fixing by
Package: libmyth-0.27-0
Version: 0.27.4+fixes20150606-dmo1
Severity: normal
Upstream bug: https://code.mythtv.org/trac/ticket/12460
A bug has been introduced into mythtv that prevents the grabber from
fetching data for special episodes. The problem is a check in
metadatadownload.cpp which checks
Package: grub2-common
Version: 2.02~beta2-23
Severity: important
usertags: debian-b...@lists.debian.org
Doing a fresh install of Jessie netinst on factory brand new 4TB disk
failed to reboot. The system completely refuses to boot after the usb
key is removed. The problem, as it turns out on my s
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
Package: fail2ban
Version: 0.9.1-1
Severity: important
the recidive jail is spewing lines into fail2ban.log like this
2015-05-02 11:30:38,076 fail2ban.action [26155]: ERROR iptables -N
f2b-recidive
iptables -A f2b-recidive -j RETURN
iptables -I INPUT -p all -m multiport --dports all -j
stack/dovecot-virtual file is
Lists/openstack-dev
inthread refs or from "james bottomley" keyword thread
It's a standard search for threads I've either replied to or marked with
an imap keyword 'thread'
The imap command
0 status virtual/openstack (MESSAGES UNSE
Package: libnet-dns-perl
Version: 0.80.2-2
Severity: important
This causes bugs in any package which checks the version; for instance:
/etc/cron.daily/amavisd-new:
Argument "0.80_2" isn't numeric in numeric ge (>=) at
/usr/share/perl5/Mail/SpamAssassin/Plugin/AskDNS.pm line 214.
Argument "0.80_2
Package: spamassassin
Version: 3.4.0-2
Severity: important
It fails with:
bedivere spamd[2472]: Can't locate Mail/SpamAssassin/CompiledRegexps/body_0.pm
in @INC (you may need to install the
Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains:
/var/lib/spamassassin/compiled/5.02
Package: fail2ban
Version: 0.8.13-1
Severity: normal
The regular expression for reporting the actual falining lines in
sendmail-whois-lines.conf does not match the ban lines by recidive in
fail2ban.log. The reason is that the IP address appears at the end of
the line, so the grep
grep '[^0-9][^0
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
OK, so rather than try to guess based on x86, lets involve the experts;
I've cc'd the sparclinux list.
Sparc people,
The failure alluded to below occurs on an SMP system, but not on a UP
one. The symptom appears to indicate the failure of interrupt delivery
on SMP, which is why the MPT card fail
Package: asterisk
Version: 1:1.8.4.3-1
Severity: important
Tags: upstream patch
Upstream bugzilla: https://issues.asterisk.org/jira/browse/ASTERISK-18086
Any phone that uses INVITE to 0.0.0.0 to place a call on hold fails
with asterisk 1.8. This feature works in asterisk 1.6, so this is
a featu
Upstream already noted the issue:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6392#c1
And committed the same fix:
http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Dns.pm?r1=926883&r2=928958&pathrev=928958&diff_format=h
So it should be safe to apply to debian.
Ja
On Tue, 2011-04-19 at 11:20 +0200, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz
> Subject: [PATCH v2] pata_cmd64x: add enablebits checking
>
> Fixes IDE -> libata regression.
>
> IDE's cmd64x host driver has been supporting enablebits checking
> since the initial driver's m
On Mon, 2011-04-18 at 14:12 +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 18-04-2011 3:58, James Bottomley wrote:
>
> > I've got a parisc system where the DVD drive is hardwired to a silicon
> > image controller:
>
> > 00:02.0 IDE interface: Silicon Ima
On Sun, 2011-04-17 at 21:25 -0400, John David Anglin wrote:
> This is excellent detective work. If I might ask, how did you trace
> the module loads and successful inits?
Heh, you're expecting me to name magic tracing tools? Well (shuffles
feet) I just put printks in kernel/modules.c to do it.
I've got a parisc system where the DVD drive is hardwired to a silicon
image controller:
00:02.0 IDE interface: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to
ATA Host Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI
On Sun, 2011-04-17 at 20:37 +0100, Ben Hutchings wrote:
> On Sun, 2011-04-17 at 14:28 -0500, James Bottomley wrote:
> > I traced the module loads and successful inits and found it; it's
> > pata_cmd64x ... it loads but never returns from init. I bet it's
> > tryi
On Sun, 2011-04-17 at 10:23 -0500, James Bottomley wrote:
> It's most likely a driver module that's getting loaded which is turned
> off in the booting configuration ... finding it isn't going to be easy,
> though ...
Finally got a build (had to swap out -Os for -O2).
I
On Sun, 2011-04-17 at 11:11 -0400, John David Anglin wrote:
> > On Sat, 2011-04-16 at 19:35 -0400, John David Anglin wrote:
> > > On Sat, 16 Apr 2011, James Bottomley wrote:
> > >
> > > > Strike that one ... I enabled USB in my 2.6.39-rc3 build and it
On Sat, 2011-04-16 at 19:35 -0400, John David Anglin wrote:
> On Sat, 16 Apr 2011, James Bottomley wrote:
>
> > Strike that one ... I enabled USB in my 2.6.39-rc3 build and it inserts
> > the OHCI module and discovers the ports just fine.
>
> Boot 2.6.39-rc3 fails for
On Sat, 2011-04-16 at 15:48 -0500, James Bottomley wrote:
> On Sat, 2011-04-16 at 15:29 -0400, John David Anglin wrote:
> > > On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
> > > > I posted this debian bug report because the most recent debian
> > > &g
On Sat, 2011-04-16 at 15:29 -0400, John David Anglin wrote:
> > On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
> > > I posted this debian bug report because the most recent debian
> > > SMP kernel build fails to boot on my rp3440:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
On Sat, 2011-04-16 at 14:07 -0400, John David Anglin wrote:
> I posted this debian bug report because the most recent debian
> SMP kernel build fails to boot on my rp3440:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622997
>
> I don't think debian kernels have worked since lenny.
Hmm, well
Package: mpg321
Version: 0.2.13-1
Severity: important
After a recent upgrade in testing, mpg321 which is run by asterisk
for music on hold consumes 100% CPU all the time.
Dropping back to version 0.2.12-1 fixes the problem
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
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
On Wed, 2009-05-06 at 16:19 +0200, maximilian attems wrote:
> [4194023.390744] [ cut here ]
> [4194023.448362] WARNING: at
> /build/buildd-linux-2.6_2.6.29-3-alpha-bvFcox/linux-2.6-2.6.29/debian/build/source_alpha_none/kernel/so
Is there any way we can get what that file
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
ers on the internet.
You cannot allow this to go into stable ... and a warning isn't enough,
it would have to be a preconfig that forces the admin to pay attention
(or preferably something that detects postfix is using a different
port).
James Bottomley
--
To UNSUBSCRIBE,
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
On Wed, 2007-05-16 at 14:36 +0100, Leigh Blackwell wrote:
> I have been looking at the issue with theses cerc devices, has this
> bug 374792 been closed based on people reverting the firmware to < 6.61.
>
> Unfortunately Dell doesn't support a Firmware version that old on our
> Server, is it po
On Sun, 2006-10-08 at 21:16 -0600, Grant Grundler wrote:
> I didn't know Compaq used two different 53[cC]510 parts.
> Patch below adds the same tweak to the 0x0010 device ID.
>
> James or willy, this look good to you?
It seems reasonable.
Can we get confirmation from the bug submitter that it ac
On Sun, 2006-10-08 at 14:40 -0700, Matt Taggart wrote:
> dann frazier writes...
>
> > hey Grant/James,
> > It looks like we're still having cpqarray/sym2 conflicts under
> > 2.6.18 - any idea what this problem may be?
>
> This is for dl380. At the very bottom (after the close of the bug) of
>
On Fri, 2006-08-18 at 12:39 -0400, Kyle McMartin wrote:
> The problem is because they both claim support for the same PCI Ids:
That's this fix, isn't it?
http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=b2b3c121076961333977f485f0d54c22121df920
James
--
To
Package: libmail-spf-query-perl
Version: 1.997-3
The mail.err log files have these errors in:
Dec 29 06:16:36 redscar spamd[7945]: Can't locate LMAP/CID2SPF.pm in
@INC (@INC
contains: ../lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.8.7
/usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/lib/
On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote:
> Sure enough, the kernel now boots. I'll attach the "dmesg" output here.
>
> Do you guys have a "final" patch in mind?
>
> Let me know if there are other tests you'd like me to run. Now that I
> know how to do this, I should be able to turn a
On Sun, 2005-11-13 at 14:42 -0500, Doug Ledford wrote:
> The device is on a non-LVD bus. Certain devices were created back when
> the spec still stated that using PPR negotiation messages on a non-LVD
> bus was a no-no. As the echo buffer was an addition to support DV, and
> originally DV wasn
On Sun, 2005-11-13 at 13:03 -0500, Graham Knap wrote:
> Doug Ledford <[EMAIL PROTECTED]> wrote:
> > You already said it didn't help with the problem,
>
> I meant that I don't think I successfully disabled DV, because the boot
> messages were *identical*, except for the line where the kernel shows
On Sun, 2005-11-13 at 12:41 -0500, Doug Ledford wrote:
> If the drive is unaccessible after the DV failure, even on a warm reboot
> (which includes a SCSI bus reset), then the drive is flat hung.
> Something done in the current code is breaking it. Can you get a boot
> with DV turned off and ca
On Tue, 2005-11-08 at 20:47 -0500, Graham Knap wrote:
> Target 0 Negotiation Settings
> User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
> Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
That's a bit
e much appreciated.
>
> Hi Graham,
>
> thanks for your detailed report. This does smell a lot like a driver
> bug, and as such, its proably best passed onto the upstream maintainers.
> As such I've CCed James Bottomley and linux-scsi for comment.
>
> The other main p
97 matches
Mail list logo