This is a major issue - if upgrading to experimental packages is not
possible, the next best solution would be to remove the sse/sse2
packages from the repository. This is especially important for Lucid
because it is a LTS.
--
Errors in single-precision BLAS (libatlas3gf-sse)
https://bugs.launchp
I think the bug is actually a duplicate of this one bug 284229; so this
one can be closed.
--
Major python slowdown under X11 and $HOME/.local
https://bugs.launchpad.net/bugs/315022
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubu
It certainly breaks the expected behavior of the ATL_buildinfo function.
If breaking a public function does not qualify as a bug, what does ?
--
new atlas for gfortran ABI has its fortran wrapper built with g77
https://bugs.launchpad.net/bugs/295051
You received this bug notification because you
Is there a reason this is not backported to Intrepid ? I don't have
admin privileges on my box, and this makes Ubuntu unbearable. After a
few hours, I have to restart X, or worse rebooting my machine.
--
console-kit-daemon using a lot of cpu
https://bugs.launchpad.net/bugs/284229
You received thi
Public bug reported:
I notice major slowdown of python on my Ubuntu Hardy system: python -c
"" takes 150 ms to launch, and importing packages is very slow. The
weird thing is that doing the same under a terminal outside my X session
get me back reasonable numbers (~20 ms).
After a couple of sanit
sorry, I forgot to update the bug report. I can confirm that ATLAS is
built with gfortran; the problem is that ATLAS is built in a perticular
manner, which I forgot; only the build info is wrong.
ATLAS debian package is built using a log file, to make sure the binary
is always the same; I reminded
Public bug reported:
Binary package hint: libatlas3gf-base
Intrepid uses gfortran for its ABI:
ldd /usr/lib/libatlas.so outputs libgfortran.so
But atlas fortran wrappers are built with g77, according to
ATL_buildinfo. You can check with this small program:
int main()
{
ATL_buildinfo();
}
Buil
Ming Hua wrote:
> On Mon, Jun 04, 2007 at 01:47:03AM -0000, David Cournapeau wrote:
>> Minase wrote:
>>> Interestingly, I am also using an NFS home... though I can't see why
>>> this could be related.
>>>
>> I think this is really related because t
Minase wrote:
> I just thought I'd chime in to say I am having this same issue with
> Feisty, which never exhibited itself in the previous two versions of
> Ubuntu I have used.
>
> So far, this bug *only* affects gnome-terminal for me - though I don't type
> much Japanese in other applications, so
Ming Hua wrote:
>
> If it still looks like a problem with socket, you can try changing the
> above "scim -d" command to "scim -f x11 --no-socket -d" and see if it
> helps anything.
I still have softwares hanging, but the kanji convertion does work. But
kana to kanji convertion can takes up to seve
Ming Hua wrote:
> Hi David,
>
> I need a clarification about the situation -- does XIM mode work for
> you? To test, modify you .xsession (as you seem to be using .xsession)
> to add:
>
> XMODIFIERS="@im=SCIM"
> GTK_IM_MODULE="xim"
> export XMODIFIERS
> export GTK_IM_MODULE
> scim -d
>
> And then
Public bug reported:
When trying to install tipa, I got the following error:
Setting up tipa (1.3-4build1) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time...
updmap-sys failed. Output has been stored in
/tmp/updmap.cwlv6815
Please include this f
Ming Hua wrote:
> On Mon, May 14, 2007 at 02:23:39AM -0000, David Cournapeau wrote:
>> Sorry for the late reply. It looks like there are two specific
>> problemes, actually: applications hanging up when scim is the IM, and
>> problems when converting from kana to kanji, s
Ming Hua wrote:
>> - XMODIFIERS set to @im=scim
>
> It may not be related to the bug, but this setting is incorrect. The
> correct setting for XMODIFIERS is @im=SCIM, uppercase. However with
> GTK_IM_MODULE set to scim, this environment variable shouldn't have any
> effect.
>
> Would you please s
Public bug reported:
When I updgrade to feisty (from edgy), I noticed that kde applications did not
work anymore (I am using gnome as a DE, but sometimes use kde applications,
mainly kdevelop/kcachegrind). I for example try to launch konqueror from the
command line, and I get first a X error:
"
Public bug reported:
I've just upgraded a machine from edgy to feisty, and I have problems with the
input system, which worked perfectly before. My system is the following:
- I am using scim as the input system
- GTK_IM_MODULE is set to scim
- XMODIFIERS set to @im=scim
- scim -d is launched by
Public bug reported:
Binary package hint: openoffice.org-impress
Using the master layout in impress to change background of some slides
of a presentation is near impossible because of multiple problems.
Here is what I am doing:
- go into view-> master -> slide master
- I create a new master i
Ok, finally, I know where the problem lies.
The equivalence ctype <-> libffi seems to be done in the file
Modules/_ctypes/cfield.c
This file builds a table for the equivalence:
#ifdef HAVE_LONG_LONG
{ 'q', q_set, q_get, &ffi_type_slong, q_set_sw, q_get_sw},
{ 'Q', Q_set, Q_get, &ffi_typ
** Also affects: python2.5 (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
python2.5 compiled with libffi does not support ctypes 64 bits integer
https://launchpad.net/bugs/72505
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/u
After many different compilation of python2.5 from ubuntu packages and
from original source (python.org), I managed to find the problem: the
configuration option --with-system-ffi, which is used by the ubuntu
package. If I use this option for original sources of python, I have the
same problem.
I
I've just reproduced the bug on my minimac (ppc) at home, also
--
python2.5 ctypes.c_longlong has wrong size (32 bits instead of 64)
https://launchpad.net/bugs/71914
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Summary changed:
- ctypes does not have 64 bit integer types
+ python2.5 ctypes.c_longlong has wrong size (32 bits instead of 64)
** Description changed:
Binary package hint: python2.5
- I have recently checked some of my python+ctypes code on python25 to
+ I have recently checked some
Public bug reported:
Binary package hint: python2.5
I have recently checked some of my python+ctypes code on python2.5 to
find it did not work. After quite some time, I found out that
ctypes.c_longlong is 32 bits, whereas it should be 64 bits.
I checked on two different machines (both edgy on x8
** Description changed:
When installing python-numpy, python-numpy-ext and python-scipy, and
when testing the installed packages with a python -c "import scipy as S;
S.test()", errors are reported concerning scipy.lib.lapack:
*
Public bug reported:
When installing python-numpy, python-numpy-ext and python-scipy, and
when testing the installed packages with a python -c "import scipy as S;
S.test()", errors are reported concerning scipy.lib.lapack:
WARNING:
25 matches
Mail list logo
