Gnumeric 1.12.13 has been released. It fixes this issue. I received
a stack trace
offline and it matches a very recently fixed bug that came in from Redhat.
M.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Dmitry,
other distributions ship development packages, so it would make sense
for Debian to do that too. There are two target groups of users: plugin
writers and those with their own command line tools. The latter group
might be empty.
Note, that we have never promised A[BP]I stability and
I think you misunderstand random_01_device.
It does read 256 bytes at a time. (Assuming gnm_float is 8 bytes.) But it
doesn't do
a read every time -- in fact only once every 32 times it is called.
The fact that I can reproduce this with ibus also prove that it's gnumeric
bug
No, it does not. It proves the problem is in either Gnumeric or in
both ibus and fcitx. (Or
in all three, for that matter.)
But we looked and noticed that fcitx does something wrong. That
should be fixed.
Fixed upstream yesterday.
M.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The hang has been fixed upstream. It was (and the as-values
thing mostly was) a matter of taking an extremely long time,
not a hang per se.
Morten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The as values problems are fixed upstream.
Morten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I am unable to reproduce the ods save issue. It does use a lot of cpu
for a short
while, but then finishes as expected. Your stack trace suggests that it did
finish.
I am unclear on how to reproduce the the BadAlloc crash. Could you please spell
out the steps in detail? I.e., what is selected
Ok, got it. Fix will land upstream shortly. The problem is that
the dragging of the little square (as opposed to dragging of the
data) is creating a crazy-tall tooltip that gtk+ cannot handle.
You can use copy+paste instead.
Note: you are better off using HYPOT over IMABS+COMPLEX.
The latter
The problem is not the header files, but that we need to ensure that the
proper include path is set up.
This is needed because sparse currently tries to mimic some
indeterminate gcc version in terms of predefines. A similar solution
would be needed to mimic any other compiler. We obviously need
10 matches
Mail list logo
