Bug#830303: mmc0: Unexpected interrupt 0x04000000.
On Mon, May 10, 2021 at 2:51 PM Alexandros Kosiaris wrote: > > On Sun, May 9, 2021 at 11:06 PM Salvatore Bonaccorso > wrote: > > > > Contol: tags -1 + moreinfo > > > > On Mon, Feb 18, 2019 at 11:54:23PM +0200, Alexandros Kosiaris wrote: > > > Hi, > > > > > > For what it's worth, it seems on this specific hardware: > > > > > > Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc] > > > > > > the problem can be resolved by passing: > > > > > > debug_quirks2=0x4 to sdhci kernel module. > > > > > > Note that there is also the debug_quirks param. I did set some values > > > for it but the working one is the default, namely 0 > > > > > > For more information have a look at > > > https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55 > > > > > > I just tested it on a Macmini7,1Debian having Stretch with > > > 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am > > > hoping everything will work out ok and I won't have to report more > > > stuff > > > > is the issue still reproducible with a recent kernel? If not we might > > go ahead and close the bugreport. > > It is. I just tried on buster's 4.19.0-16-amd64 and the issue persists > for me. I 'll also try to reproduce with bullseye's 5.10.28-1 and > report results here. Reproduced on bullseye with 5.10.28-1 as well. The fix remains to have in a file in /etc/modprobe.d (e.g. sdhci.conf) the following: options sdhci debug_quirks2=0x4 Regards,
Bug#830303: mmc0: Unexpected interrupt 0x04000000.
On Sun, May 9, 2021 at 11:06 PM Salvatore Bonaccorso wrote: > > Contol: tags -1 + moreinfo > > On Mon, Feb 18, 2019 at 11:54:23PM +0200, Alexandros Kosiaris wrote: > > Hi, > > > > For what it's worth, it seems on this specific hardware: > > > > Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc] > > > > the problem can be resolved by passing: > > > > debug_quirks2=0x4 to sdhci kernel module. > > > > Note that there is also the debug_quirks param. I did set some values > > for it but the working one is the default, namely 0 > > > > For more information have a look at > > https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55 > > > > I just tested it on a Macmini7,1Debian having Stretch with > > 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am > > hoping everything will work out ok and I won't have to report more > > stuff > > is the issue still reproducible with a recent kernel? If not we might > go ahead and close the bugreport. It is. I just tried on buster's 4.19.0-16-amd64 and the issue persists for me. I 'll also try to reproduce with bullseye's 5.10.28-1 and report results here. > > Regards, > Salvatore
Bug#914577: fixed in dropwatch 1.5.1-1
On Wed, Nov 13, 2019 at 9:35 PM Dmitry Smirnov wrote: > > On Thursday, 14 November 2019 3:33:42 AM AEDT Alexandros Kosiaris wrote: > > Thanks, I 'll take up on your offer. If anything I 'll manage to learn > > more about the bureaucracy aspects of package maintainer ship and > > avoid such mistakes in the future. > > That's not a bureaucracy but important aspects of cooperation. Notion of > ownership matters only as long as you have something to deliver. Therefore > transparency (not bureaucracy) is crucial. Even when the work is unfinished, > announce that you are on the task and where your work-in-progress repository > is. That's precisely what ITP bugs are about - cooperation and coordination. I think I might have used the term bureaucracy a bit too liberally. What I meant is the administrative processes governing this (which I clearly am not familiar with yet). But otherwise, fully agreed. > > -- > All the best, > Dmitry Smirnov. > > --- > > Success consists of going from failure to failure without loss of enthusiasm. > -- Winston Churchill
Bug#914577: fixed in dropwatch 1.5.1-1
Hello, On Wed, Nov 13, 2019 at 1:38 AM Dmitry Smirnov wrote: > > On Wednesday, 13 November 2019 9:09:30 AM AEDT Moritz Mühlenhoff wrote: > > Why did you take over that ITP without even syncing up with the person > > (CCed) who indicated to be working on it in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914577#10 ? > > Excuse me, I was taking over "RFP" and there was nothing to sync about as > there were no publicly visible progress whatsoever. > That's probably my fault for not knowing I should have also CCed cont...@bugs.debian.org in my email. > Alexandros, you are most welcome to co-maintain this package. > Next time please ensure to re-title the bug properly and keep it updated on > your progress. > Thanks, I 'll take up on your offer. If anything I 'll manage to learn more about the bureaucracy aspects of package maintainer ship and avoid such mistakes in the future.
Bug#914577: ITP: dropwatch -- A tool for detecting and diagnosing packets being dropped
Package: wnpp Followup-For: Bug #914577 Owner: Alexandros Kosiaris
Bug#830303: mmc0: Unexpected interrupt 0x04000000.
Hi, For what it's worth, it seems on this specific hardware: Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc] the problem can be resolved by passing: debug_quirks2=0x4 to sdhci kernel module. Note that there is also the debug_quirks param. I did set some values for it but the working one is the default, namely 0 For more information have a look at https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55 I just tested it on a Macmini7,1Debian having Stretch with 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am hoping everything will work out ok and I won't have to report more stuff
Bug#881255: ganeti-2.15: Force cache=none for KVM when aio=native
Package: ganeti-2.15
Severity: normal
Tags: upstream patch
Dear Maintainer,
Starting with version 2.6, QEMU will fail to start with an error when
aio=native and no cache=none is present. This is documented in
http://wiki.qemu.org/ChangeLog/2.6. QEMU has been complaining about this
since 2.3.
Attached is a patch that detects this in the hypervisor setup and force
the disk_cache setting, logging it at the same time. The patch verbatim
taken from
https://github.com/ganeti/ganeti/commit/1e510ccd092f472919a9f8b34ede838476ab7e2e.patch
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ganeti-2.15 depends on:
ii adduser3.115
ii bridge-utils 1.5-13+deb9u1
ii debconf [debconf-2.0] 1.5.61
pn fping
ii iproute1:4.9.0-1
ii iproute2 4.9.0-1
ii iputils-arping 3:20161105-1
ii lvm2 2.02.168-2
ii openssh-client 1:7.4p1-10+deb9u1
pn openssh-server
ii openssl1.1.0f-3
ii python 2.7.13-2
pn python-bitarray
pn python-fdsend
pn python-ipaddr
ii python-openssl 16.2.0-1
ii python-paramiko2.0.0-1
pn python-psutil
ii python-pycurl 7.43.0-2
pn python-pyinotify
ii python-pyparsing 2.1.10+dfsg1-1
ii python-simplejson 3.10.0-1
ii socat 1.7.3.1-2+deb9u1
ganeti-2.15 recommends no packages.
ganeti-2.15 suggests no packages.
>From 1e510ccd092f472919a9f8b34ede838476ab7e2e Mon Sep 17 00:00:00 2001
From: Alexandros Kosiaris <akosia...@gmail.com>
Date: Thu, 1 Jun 2017 12:53:05 +0300
Subject: [PATCH] Force cache=none for KVM when aio=native (#43)
Starting with version 2.6, QEMU will fail to start with an error when
aio=native and no cache=none is present. This is documented in
http://wiki.qemu.org/ChangeLog/2.6. QEMU has been complaining about this
since 2.3. Detect this in the hypervisor setup and force the disk_cache
setting, logging it at the same time.
Signed-off-by: Alexandros Kosiaris <akosia...@gmail.com>
Reviewed-by: Federico Morg Pareschi <m...@google.com>
---
lib/hypervisor/hv_kvm/__init__.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/hypervisor/hv_kvm/__init__.py
b/lib/hypervisor/hv_kvm/__init__.py
index 15f75ef48..d483808d6 100644
--- a/lib/hypervisor/hv_kvm/__init__.py
+++ b/lib/hypervisor/hv_kvm/__init__.py
@@ -1123,6 +1123,12 @@ def _GenerateKVMBlockDevicesOptions(self, up_hvp,
kvm_disks,
" to prevent shared storage corruption on migration",
disk_cache)
cache_val = ",cache=none"
+ elif aio_mode == constants.HT_KVM_AIO_NATIVE and disk_cache != "none":
+# TODO: make this a hard error, instead of a silent overwrite
+logging.warning("KVM: overriding disk_cache setting '%s' with 'none'"
+" to prevent QEMU failures in version 2.6+",
+disk_cache)
+cache_val = ",cache=none"
elif disk_cache != constants.HT_CACHE_DEFAULT:
cache_val = ",cache=%s" % disk_cache
else:
Bug#821848: perl: Regexp-matching "hangs" indefinitely on illegal input using binmode :utf8 using 100%CPU
Package: perl
Version: 5.20.2-3+deb8u4
Severity: normal
Tags: upstream patch
Dear Maintainer,
There is a bug in Perl 5.8.9 (at least) that causes regular
expressions an malformed UTF8 inputs to go into a forever loop and
consume 100% CPU. Upstream's tracker url is
https://rt.perl.org/Public/Bug/Display.html?id=123562. Patch is at
http://perl5.git.perl.org/perl.git/commitdiff/22b433eff9a1ffa2454e18405a56650f07b385b5
and attached is a version rebased for Debian Jessie. I have not
confirmed it, but based on the versions numbers I believe Stretch and Sid are
also affected.
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages perl depends on:
ii dpkg 1.17.26
ii libbz2-1.01.0.6-7+b3
ii libc6 2.19-18+deb8u4
ii libdb5.3 5.3.28-9
ii libgdbm3 1.8.3-13.1
ii perl-base 5.20.2-3+deb8u4
ii perl-modules 5.20.2-3+deb8u4
ii zlib1g1:1.2.8.dfsg-2+b1
Versions of packages perl recommends:
ii netbase 5.3
pn rename
Versions of packages perl suggests:
pn libterm-readline-gnu-perl | libterm-readline-perl-perl
ii make4.0-8.1
ii perl-doc5.20.2-3+deb8u4
-- no debconf information
Index: perl-5.20.2/regexec.c
===
--- perl-5.20.2.orig/regexec.c
+++ perl-5.20.2/regexec.c
@@ -7830,6 +7830,10 @@ S_reghop3(U8 *s, SSize_t off, const U8*
if (UTF8_IS_CONTINUED(*s)) {
while (s > lim && UTF8_IS_CONTINUATION(*s))
s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
}
/* XXX could check well-formedness here */
}
@@ -7856,6 +7860,10 @@ S_reghop4(U8 *s, SSize_t off, const U8*
if (UTF8_IS_CONTINUED(*s)) {
while (s > llim && UTF8_IS_CONTINUATION(*s))
s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
}
/* XXX could check well-formedness here */
}
@@ -7887,6 +7895,10 @@ S_reghopmaybe3(U8* s, SSize_t off, const
if (UTF8_IS_CONTINUED(*s)) {
while (s > lim && UTF8_IS_CONTINUATION(*s))
s--;
+if (! UTF8_IS_START(*s)) {
+dTHX;
+Perl_croak(aTHX_ "Malformed UTF-8 character (fatal)");
+}
}
/* XXX could check well-formedness here */
}
Index: perl-5.20.2/t/re/pat.t
===
--- perl-5.20.2.orig/t/re/pat.t
+++ perl-5.20.2/t/re/pat.t
@@ -20,7 +20,7 @@ BEGIN {
require './test.pl';
}
-plan tests => 726; # Update this when adding/deleting tests.
+plan tests => 727; # Update this when adding/deleting tests.
run_tests() unless caller;
@@ -1602,6 +1602,21 @@ EOP
ok(1, "did not crash");
ok($match, "[bbb...] resolved as character class, not subscript");
}
+{ # Test that we handle some malformed UTF-8 without looping [perl
+# #123562]
+
+my $code='
+BEGIN{require q(test.pl);}
+use Encode qw(_utf8_on);
+my $malformed = "a\x80\n";
+_utf8_on($malformed);
+watchdog(3);
+$malformed =~ /(\n\r|\r)$/;
+print q(No infinite loop here!);
+';
+fresh_perl_like($code, qr/Malformed UTF-8 character/, {},
+"test that we handle some UTF-8 malformations without looping" );
+}
} # End of sub run_tests
1;
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Hello Andreas, I am sorry, I somehow missed the first correspondence, thanks for contacting me directly (I was actually beginning to lose hope). I will have a look at it ASAP On Fri, Mar 21, 2014 at 3:45 PM, Andreas Tille ti...@debian.org wrote: Hi again Alexandros, as I said two monthes ago: Your patch does not apply. I checked again and it turns out that the problem that it contains a patch for a non-existing Makefile.in - how did you got this file. We'd happily fix this bug but for me it is hard to reproduce (since I do not use this package) and your patch simply does not apply so I have no idea how I can help you. Kind regards Andreas. On Tue, Jan 21, 2014 at 05:05:50PM +0100, Andreas Tille wrote: Hi Alexandros, thanks for the patch to the problem report. I tried to apply this to the status of the corresponding Git repository git://git.debian.org/git/debian-med/snappy-java.git It seems you did not created the patch against this repository since it also contained an empty debian/patches/series file and a debian/source/format file. After dealing with some warnings the essential patch seems to be in debian/patches/jni.patch Unfortunately if I put this at the end of the series file it does not apply cleanly. Would you be so kind to rework your patch to apply cleanly with quilt? Your help is greatly appreciated since we simply have created the package as some precondition without the necessary solid Java background. Kind regards Andreas. -- http://fam-tille.de -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Package: libsnappy-java
Version: 1.0.4.1~dfsg-1
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
Apologies if this the wrong package to open a bug against, I was unsure whether
I should open it against libsnappy-java or libsnappy1, feel free to
reassign it if needed
While trying to use the simple example from the snappy-java documentation
attached below I encountered an error of FAILED_LOAD_NATIVE_LIBRARY. After a
lot of reading it seems like the upstream ships compiled versions of shared
object (.so) files for various OSes and architectures that get included in the
shipped jar file. Those are stripped out in the Debian package and a dependency
to the libsnappy1 package is declared. That is a nice approach IMHO
However, the .so file shipped by the libsnappy1 package
(/usr/lib/libsnappy.so.1.1.3) does not contain the necessary JNI bindings and
as a result the JNI calls from the Java code fail.
I have managed to bypass the problem by recompiling the libsnappy1 package
with the JNI bindings provided in the libsnappy-java package. I attach the
patch. I am not sure however if this is the best possible solution. It is
however a relatively clean one. Of course this solution is against the
libsnappy1 package and not the libsnappy-java package
Reproduce with:
SnappyTests.java:
import org.xerial.snappy.Snappy;
import java.lang.String;
import java.lang.System;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
class SnappyTests {
public static void main(String[] args) throws
UnsupportedEncodingException, IOException {
String input = Hello snappy-java! Snappy-java is a JNI-based wrapper of
+ Snappy, a fast compresser/decompresser.;
byte[] compressed = Snappy.compress(input.getBytes(UTF-8));
byte[] uncompressed = Snappy.uncompress(compressed);
String result = new String(uncompressed, UTF-8);
System.out.println(result);
}
}
Compile with:
javac -cp /usr/share/java/snappy-java.jar SnappyTests.java
Run with:
java -cp '/usr/share/java/snappy-java.jar:.' SnappyTests
Stacktrace returned is:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
at SnappyTests.main(SnappyTests.java:11)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1856)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
... 8 more
Exception in thread main org.xerial.snappy.SnappyError:
[FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
at SnappyTests.main(SnappyTests.java:11)
-- System Information:
Debian Release: 7.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -urN b/snappy-1.0.4/debian/libsnappy1.links a/snappy-1.0.4/debian/libsnappy1.links
--- b/snappy-1.0.4/debian/libsnappy1.links 1970-01-01 00:00:00.0 +
+++ a/snappy-1.0.4/debian/libsnappy1.links 2013-11-06 14:47:02.701611660 +
@@ -0,0 +1 @@
+usr/lib/libsnappy.so.1 usr/lib/libsnappyjava.so
diff -urN b/snappy-1.0.4/debian/patches/jni.patch a/snappy-1.0.4/debian/patches/jni.patch
--- b/snappy-1.0.4/debian/patches/jni.patch 1970-01-01 00:00:00.0 +
+++ a/snappy-1.0.4/debian/patches/jni.patch 2013-11-06 14:39:55.093530261 +
@@ -0,0 +1,411 @@
+--- /dev/null 2013-05-23 22:06:22.347926853 +
b/SnappyNative.cc 2013-11-06 12:27:53.491596706 +
+@@ -0,0 +1,237 @@
++/*--
++ * Copyright 2011 Taro L. Saito
++ *
++ * Licensed under the Apache License, Version 2.0 (the License);
++ * you may not use this file except in compliance with the License.
++ * You may obtain a copy of the License at
++ *
++ * http://www.apache.org/licenses/LICENSE-2.0
++ *
++ * Unless required by applicable law or agreed to in writing, software
++ * distributed under the License is distributed on an AS IS BASIS,
++ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
++ * See the License for the specific language governing permissions and
++ * limitations under the License.
++
Bug#620186: Init.d-script leaves mpt-statusd process defunct
I confirm this bug which is open since 2011. If anyone touches this, maybe we should also say RUN_DAEMON=no by default (especially if the bug is not fixed)? I have a feeling few users just install this and wait for the daemon to inform them that the RAID array has problem. A monitoring/alerting infrastructure quite possibly exists already if you have MPT controllers and duplicating it is probably unwanted behaviour anyway. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712572: fai-setup-storage: Fails to identify some drives in certain controller configurations
Package: fai-setup-storage
Severity: normal
Tags: patch
Dear Maintainer,
While trying to use fai to setup some HP Proliant DL 380 G7 servers with
two controllers, one with internal disks connected to it and one with
two selves of 15 disks each connected cascadingly to it it was noticed
that some drives would not be detected by setup-storage. Both
controllers are driven by cciss driver which shows up drives in a format
like: /dev/cciss/c0d0
While trying to figure out the problem I noticed that drive detection
relies on using some regular expressions to parse /proc/partitions. Those
were not matching drives with more than 1 digit (i.e. /dev/cciss/c0d12).
After ameliorating them with the provided patch (which also applies to
master in github) the problem was resolved and all drives were
succefully detected.
-- System Information:
Debian Release: 7.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From dd3c48663ea8e712270f845e71aa5504aed55603 Mon Sep 17 00:00:00 2001
From: Alexandros Kosiaris akosia...@gmail.com
Date: Mon, 17 Jun 2013 13:46:37 +0300
Subject: [PATCH] Handle better some controllers drive detection
In some cases drives in some controllers would not be detected by fai
and would not be present during partitioning. Turns out this is caused
by some regular expressions not matching correctly some cases, for
example ccciss/c0d12. Amending those regular expressions to fix that
---
lib/fai-disk-info |2 +-
lib/setup-storage/Init.pm |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/fai-disk-info b/lib/fai-disk-info
index 4b09e58..1ba4ebd 100755
--- a/lib/fai-disk-info
+++ b/lib/fai-disk-info
@@ -19,6 +19,6 @@ checkdisk() {
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# echo a space separated list of devices and their block size
-egrep ' etherd/e[[:digit:]]+\.[[:digit:]]+\b| i2o/hd.\b| cciss/c.d.\b| ida/c.d.\b| rd/c.d.\b| hd.\b| sd[a-z]{1,2}\b|/disc\b| vd.\b| xvd.\b' /proc/partitions | checkdisk
+egrep ' etherd/e[[:digit:]]+\.[[:digit:]]+\b| i2o/hd.+\b| cciss/c.+d.+\b| ida/c.+d.+\b| rd/c.+d.+\b| hd.\b| sd[a-z]{1,2}\b|/disc\b| vd.\b| xvd.\b' /proc/partitions | checkdisk
diff --git a/lib/setup-storage/Init.pm b/lib/setup-storage/Init.pm
index 751efb2..d829916 100644
--- a/lib/setup-storage/Init.pm
+++ b/lib/setup-storage/Init.pm
@@ -236,7 +236,7 @@ sub phys_dev {
return (1, /dev/$1, $2);
}
elsif ($dev =~
-m{^/dev/(cciss/c\dd\d|ida/c\dd\d|rd/c\dd\d|ataraid/d\d|etherd/e\d+\.\d+)(p(\d+))?$})
+m{^/dev/(cciss/c\d+d\d+|ida/c\d+d\d+|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+)(p(\d+))?$})
{
defined($2) or return (1, /dev/$1, -1);
return (1, /dev/$1, $3);
@@ -320,7 +320,7 @@ sub mark_encrypted {
sub make_device_name {
my ($dev, $p) = @_;
$dev .= p if ($dev =~
-m{^/dev/(cciss/c\dd\d|ida/c\dd\d|rd/c\dd\d|ataraid/d\d|etherd/e\d+\.\d+)$});
+m{^/dev/(cciss/c\d+d\d+|ida/c\d+d\d+|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+)$});
if ((FAI::loopback_dev($dev))[0])
{
$p += (FAI::loopback_dev($dev))[1];
--
1.7.10.4
Bug#674539: ITP: beanstalkc -- beanstalkc is a simple beanstalkd client library for Python
Package: wnpp Severity: wishlist Owner: Alexandros Kosiaris akosiaris+deb...@gmail.com * Package name: beanstalkc Version : 0.2.0 Upstream Author : Andreas Bolka a...@bolka.at * URL : http://pypi.python.org/pypi/beanstalkc/ * License : Apache Software License Programming Lang: Python Description : beanstalkc is a simple beanstalkd client library for Python beanstalkc is a simple beanstalkd client library for Python. beanstalkd is a fast, distributed, in-memory workqueue service. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519563: bacula-director-common: Bacula-director init script help function does not mention reload functionality
Package: bacula-director-common
Version: 2.4.4-1
Severity: minor
Tags: patch
The bacula-director init script usage function does not mention the possibility
of reload functionality although such
functionality exists in the init script. The following trivial patch fixes that.
--- bacula-director 2009-01-09 23:10:49.0 +0200
+++ bacula-director.new 2009-03-13 16:27:22.0 +0200
@@ -120,7 +120,7 @@
*)
N=/etc/init.d/$NAME
# echo Usage: $N {start|stop|restart|reload|force-reload} 2
- echo Usage: $N {start|stop|restart|force-reload} 2
+ echo Usage: $N {start|stop|restart|reload|force-reload} 2
exit 1
;;
esac
-- System Information:
Debian Release: lenny/sid
APT prefers intrepid-updates
APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500,
'intrepid-backports'), (500, 'intrepid')
Architecture: i386 (i686)
Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
