I should add that the alignment of reserved sectors was already reported
elsewhere:
https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/746262
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or
See previous patch for explanation.
With this patch and the previous two, the
mkdosfs generated FAT32 file systems work well in my extremely
picky TechniSat device. Of course, they're also detected cleanly
by Linux and Windows.
---
src/mkdosfs.c |1 -
1 files changed, 0 insertions(+), 1 delet
For certain file system sizes (in particular, exact GB sizes -
don't ask me why) a Technisat HD S2 Plus DVB receiver will still
choke on mkdosfs generated file systems, even if the sectors per
cluster problem is fixed.
By comparing the properties of generated FAT32 FS with results
of the Windows t
The default sectors per cluster calculated by mkdosfs are outdated,
see http://technet.microsoft.com/en-us/library/cc938438.aspx.
The deviations may cause some 3rd party devices (e.g. TechniSat DVB
receivers) to hang when reading mkdosfs generated file systems.
---
src/mkdosfs.c | 14 +++---
Package: dosfstools
Version: 3.0.13-1
Severity: important
TechniSat DVB receivers like the HD S2 Plus only accept FAT32
formatted external HDDs. If such a FAT32 file system is generated
using mkdosfs, the disk won't be detected, and the DVB receiver
freezes when trying to access the file system.
Ove Kaaven wrote:
>> winedump is unable to find function_grep.pl which is needed to
>> extract function prototypes from DLLs:
>
> Oh, someone actually needs that script?
Well, I did - not sure if I will need it ever again. But "winedump spec
-c" doesn't work without it.
> I don't feel comfortab
Package: wine-utils
Version: 1.0.1-1
Severity: normal
winedump is unable to find function_grep.pl which is needed to
extract function prototypes from DLLs:
winedump spec -I include -c ./ssleay32.dll
Contents of ./ssleay32.dll: 200704 bytes
222 named symbols in DLL, 293 total, 222 unique (ordinal
This isn't just a problem of openssl spradically crashing. It can also
cause silent data corruption. If openssl req -new doesn't crash, the
IPv6 address in the output CSR will be wrong.
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe
Fixes for this bug are upstream:
http://cvs.openssl.org/chngview?cn=17675
http://cvs.openssl.org/chngview?cn=17677
Any chances they'll be intergrated soon?
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas.
Norbert Preining wrote:
> Aehm, AFAIR (not at my computer) the patch *is* included and g-brief
> should work.
>
> Did you actually try and find misbehaviour?
Well - what's wrong here, then? I have the most recent package
installed, all MD5 sums are well, yet the test code fails.
Script started
Package: texlive-latex-extra
Version: 2007.dfsg.3-1
Followup-For: Bug #423919
The current upstream version of g-brief has this problem fixed.
http://ctan.org/get/macros/latex/contrib/g-brief/g-brief.dtx
\def\filedate{2008/07/15}
\def\fileversion{4.0.2}
% 2008-07-15 [EMAIL PROTECTED] -- Since
Debian Bug Tracking System wrote:
Changes:
nss (3.12.0-4) unstable; urgency=low
.
* debian/control: Remove conflict with libnss3-0d, it was only useful when
libnss3-0d was a transitional package. Closes: #490995.
Thank you. Meanwhile, Christian added libxul0d 1.8.1.14 to
debian-mul
Package: libxul0d
Version: 1.8.0.14~pre071019b-0lenny1
Severity: normal
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (91, 'stable'), (90, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en
Modestas Vainius wrote:
> You can get etch packages for ktorrent 2.2.2 from
> http://ktorrent.org/index.php?page=downloads They are as much official
> backports as they can be because they were made by me.
Solution verified, thank you. The bug can be closed.
Why can't you promote this backport
Package: ktorrent
Version: 2.0.3+dfsg1-2.2
Severity: important
Tags: patch
Due to an int32 overflow, ktorrent 2.0.3 corrupts downloaded files which
are bigger than 4GB.
The related kde.org bugzilla is
https://bugs.kde.org/show_bug.cgi?id=132443
The KDE bugzilla contains two patches.
https://bu
Hi,
I ran into the same problem and made a backport of ipt_recent.c for
Sarge's 2.6.8. It was actually pretty simple to backport. Attached is
the diff against the ipt_recent.c source file from Philipp's comment of
6 Jul 2006.
The backported module is already running in one of my systems. Works a
I apologize for having been so silent. The ipw2200 problem is gone
(hasn't been reproducable) since I upgraded to kernel 2.6.16-2. As far
as it regards my initial bu report, the bug can be closed.
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
Package: linux-image-2.6.15-1-686
Version: 2.6.15-1
Severity: important
I just got the following BUG. I copied the message by hand so it's not a
perfect backtrace; I apologize for that.
comm: ipw2200
EIP is at __queue_work+3e
EFLAGS 00200246 Not tainted
eax: f4ba5650 ebx: f44db268 ECX: 0001 E
Package: digikam
Version: 0.8.0-1-1+b1
Severity: important
digikam generates the following error messages:
kio (KMimeType): WARNING: KServiceType::offers : servicetype
Digikam/ImagePlugin not found
kio (KMimeType): WARNING: KServiceType::offers : servicetype
Digikam/ImagePlugin not found
digikam:
I have the same problem here. Vincent's workaround as described in his
posting of Nov. 11 works fine for me.
The problem is that module-assistant doesn't have a concept of one
external module depending on another one (here: ipw2200 depends on
ieee80211).
A possible workaround would be that the ie
Package: initramfs-tools
Version: 0.37
Severity: normal
Tags: patch
mkinitramfs does not copy the /etc/modprobe.d hierarchy to the initial
ramfs. This means that vital module options cannot be passed to the
initramfs system. For my laptop I need the line "options libata atapi_enabled=1"
to be able
Rusty Russell wrote:
Martin Wilck <[EMAIL PROTECTED]> wrote:
0. the module loading tool runs during boot with PID 1.
I do not understand how this can happen. request_module() cannot occur
until usermodehelper_init() is called. This is only done once the init
thread is spawned,
=> unresolved symbols
Possible workarounds:
a) check PID returned by wait4() and only continue if it matches the
forked insmod's PID
b) fork() right after tool startup so that the calling tool isn't
running with PID 1.
Could this be the problem cause here, too?
Regar
23 matches
Mail list logo
