Package: iceweasel
Version: 2.0.0.8-1
Severity: normal
The following simple web page does not produce the correct result in
Iceweasel:
Test Page
Item one
This text should be visible!
If I remove any of the style items or element the text becomes
visible.
I've filed bug with Mozilla fol
I've can reproducibly revert to 1.5 but all attempts to then follow the steps
to install 2.0 through up a popup
saying something to the effect that another version of icedove is running, kill
it or restart your system.
There's nothing to kill, a new x zsession doesn't work, a reboot doesn't work
There's a similar problem with mod_python reg.expr.:
< "mod_python\/(1.*|2\.([0-6]\..*|7\.[0-6]))"
---
> "mod_python\/(1.*|2\.([0-6]\..*|7\.[0-6]$))"
Cheers,
Igor
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: nikto
Version: 1.35-1
Severity: normal
The incorrect reg.expr. for mod_ssl makes nikto report a warning for
mod_ssl/2.8.2 when mod_ssl/2.8.25 is used. The fix is to add EOL symbol ($)
in the matching reg.expr.:
< "mod_ssl\/(1.*|2\.([0-7].*|8\.[0-6]))"
---
> "mod_ssl\/(1.*|2\.([0-7].*|8\.[
Arnaud Fontaine wrote:
Are you planning a new stable release of pyme soon which will include
this patch ?
Well.. I do plan 0.7.1 release "any minute now" for the last half an
year. :-(
I want to figure out why do I still have problems with MinGW32 built
PyMe on Windows.
The problems boil
Igor Belyi wrote:
I'm still trying to find the right workaround for this. For now it
seems SWIG 1.3.28 is not good
version to use for pyme build.
I've got it! Here's a slightly better patch which should not break back
compatibility and does not use
undocumented features. I&#
OK, I've looked at it and I'm sorry to say I don't think this is the
right patch.
It seems to me that the patch disables gpgme.i's "const char *" typemap
definition by using
SWIG's bug of not reporting invalid syntax but silently ignoring it to
work around another SWIG
bug of the typemap causi
Package: usbmount
Version: 0.0.14
Followup-For: Bug #317022
Our friends in udev moved vol_id from /sbin into /lib/udev which results in
usbmount to not find it. I don't know in which version of udev this change
happen since I just started using usbmount. For now I just created sym.link
/sbin/vol_i
Sorry, I'm on LinuxWorld Expo this week and won't be able to look at
this until next week. If this switch appears just in 1.3.28 swig then
the change should be a little bit bigger for back compatibility.
Shortly, I greatly appreciate the patch - it gives me the right
direction where I need to l
Could you specified versions of SWIG, SSL, and gcc used?
Thanks,
Igor
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Marc Haber wrote:
No, in the current packages, everything is fine.
Well... It appeared to be my own mistake...
In my /etc/hosts I had localhost first and the machine name second. As a
result "hostname --fqdn" was returning
localhost instead of the name of the machine which in turn resulted i
Andreas Metzler wrote:
On 2006-01-19 Igor Belyi <[EMAIL PROTECTED]> wrote:
Template: exim4/dc_other_hostnames
Type: string
Default:
Description: Other destinations for which mail is accepted:
Please enter a list of domains for which this machine should consider
itself the final desti
I do believe that besides update-exim4.conf.8 you also need to fix
exim4-config.templates which caused
me to make the same mistake of not including mailname by saying:
Template: exim4/dc_other_hostnames
Type: string
Default:
Description: Other destinations for which mail is accepted:
Please ente
While this bug still active Samba team already released 3.0.20a.
The release statement is "This is the latest stable release of Samba.
This is the version
that production Samba servers should be running for all current bug-fixes."
Igor
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
Eduard Bloch wrote:
Nice. I have read that paper
http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf to get an
overview on its features.
Thanks. This paper triggered my interest in reviewing what I've done in
the code. :-) The good news is that zlib module releases the global
lock
Eduard Bloch wrote:
Interesting. Looks nice, most things are done the same way I did with
C++, and looking very clean. I was rewritting advfs primarily to make it
multithreaded, since we have a Dual-Opteron cluster nearby so Klaus
could compress his DVDs in 5 minutes using best compression rathe
Eduard Bloch wrote:
#include
* Eduard Bloch [Tue, Aug 23 2005, 12:22:04AM]:
Eh, did you test that with the _driver_? I am rewritting advfs right now
and stumbled over the same problem.
Hm.. Since you rewritting advfs, I wonder if you will find useful my 2
cents in a form of python scripts
Bastian Blank wrote:
On Wed, Jun 29, 2005 at 08:49:21AM -0400, Igor Belyi wrote:
Here's what I get with lvm2 2.01.04-5 tools:
# vgdisplay lvmg
[...]
Formatlvm1
[...]
So it is lvm1.
Do you need those 64K of metadata as well?
On related note,
Bastian Blank wrote:
On Tue, Jun 28, 2005 at 07:11:49PM -0400, Igor Belyi wrote:
Attached is the /etc/lvm/backup/lvmg config file for the group.
You forget one essential information: lvm1 or lvm2 metadata, otherwise
I'm only able to say: works for me.
Bastian
Here's
Package: lvm2
Version: 2.01.12-2
Followup-For: Bug #315339
Installing new lvm2 makes stripped VG unrecognizable.
Downgrading lvm2 back to 2.01.04-5 fixes the problem.
# vgdisplay lvmg
LV backup: inconsistent LE count 1832 != 3662
Internal error: LV segments corrupted in backup.
Volume group
Sebastien Bacher wrote:
http://bugzilla.gnome.org/show_bug.cgi?id=171991
Thanks, upstream is the right place to have an advice on that.
Just to avoid confusion - I'm not asking for an advice, I'm asking to
fix the problem. I even provided a solution.
Upstream is the right place for fixing
To make life easier I've reported this bug to the upstream developers as
well. The following is the reference to the bug report:
http://bugzilla.gnome.org/show_bug.cgi?id=171991
Cheers,
Igor
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PR
OK, attached is the patch which does make the problem go away.
Here's the justification for upstream developers:
According to what I saw in the code functions
gtk_tree_view_real_toggle_cursor_row(tree_view) and
gtk_tree_view_real_select_cursor_row(tree_view, FALSE) /* note the FALSE
for start_ed
Sorry, the patch screws us selection process completely... That what you
get from creating a patch in unfamiliar code. :(
From debugging I know that the callback is called in
gtk_tree_view_real_set_cursor() but with Shift and Control modifier the
real selection happen only in gtk_tree_view_real
Interestingly enough, the following small patch fixes the problem. I'm
not very much familiar with gtk+2.0 internals to know if there's some
other side effects of this change. I'd appreciate if somebody can check it.
Cheers,
Igor
--- gtk+-2.6.2/gtk/gtktreeview.c.orig 2005-03-27 16:25:48.000
Package: libgtk2.0-0
Version: 2.6.2-4
Severity: important
The number of selected rows in a GtkTreeVew is incorrect in "cursor-changed"
callback when rows are selected with a modefier - Ctrl or Shift.
This problem does not happen when rows are selected without a modifier
or when number of selected
Solution to the bug appears to be very simple.
The patch is attached.
Igor
--- gpgme/wait-global.c.orig 2005-03-25 16:45:14.0 -0500
+++ gpgme/wait-global.c 2005-03-25 16:51:40.0 -0500
@@ -174,7 +174,10 @@
free (li);
}
else
+{
ctx = NULL;
+*status = 0;
+
Package: libgpgme11-dev
Version: 1.0.2-1
Severity: normal
gpgme_wait(ctx, &status, 0) on timeout returns ctx instead of NULL which
makes it difficult to distinguish from a program return when ctx in not NULL.
Plus, on timeout status is unchanged instead of being forced into 0.
As a work around I s
Package: libgpgme11
Version: 1.0.2-1
Severity: important
Starting asynchronouse call and then canceling it with gpgme_cancel do cause
gpgme_wait() return Canceled error but leaves gpg process working and
finishing the call.
Attached is a slightly modified t-genkey test from the gpgme source showi
Previous patch did not return correct device number for the backing file
location on LOOP_GET_STATUS call. Updated patch is attached.
Igor
--- modules/cloop/compressed_loop.c.orig 2005-03-05 01:16:13.0 -0500
+++ modules/cloop/compressed_loop.c 2005-03-05 01:20:25.0 -0500
@@ -120,6
After some thoughts I decided to fix this bug.
It appears that you need to use O_LARGEFILE flag to filp_open() if the
caller can handle 64 bit addressing in the file. And since cloop uses
64bit loff_t addresses it should be able to do it.
Attached is a patch addressing this problem. I also made
Package: cloop-src
Version: 2.01.5-3
Severity: important
I've been experimenting with a 3.7Gb compressed images and I've noticed
that when I specify then when loading cloop module like this:
% modprobe cloop file=bigfile
it fails saying "Unable to get file bigfile for cloop device". On the other
h
Package: dmsetup
Version: 2:1.01.00-1
Severity: minor
man dmsetup in the OPTIONS section says
"-j|--minor minor" which actually should be "-m|--minor minor"
Igor
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Li
Package: cloop-utils
Version: 2.01.5-3
Severity: important
create_compressed_fs add extra block to the compressed image if the size of
the original image is a multiple of the block size. You can verify this by
the following simple test:
% head -c 65536 /dev/zero > uncompressed.iso
% create_compres
Package: python-gtk2-doc
Version: 2.5.1-1
Severity: normal
Document pages of the python-gtk2-doc located in
/usr/share/doc/python-gtk2-doc/html refer to tutorial pages
as the ones placed in ../pygtk2tutorial where as python-gtk2-tutorial
puts them into /usr/share/doc/python-gkt2-tutorial/html
Run
Subject: gaim: Markup buttons toggle back when message is sent.
Package: gaim
Version: 1:1.1.1-1
Severity: normal
Markup buttons (bold, italic, underline, font) are triggered back into some
predefined state even when "Default Formatting" is not checked in the
"Message Text" of the Preferences. The
36 matches
Mail list logo
