Dear Salvatore,
thank your for your response!
I'd gladly report the issue upstream, but I'm not sure on how to approach that.
I'm aware of Bugzilla [1], but so far I have no account there. And the
documentation [2] says, that Bugzilla is likely not the right address anyway:
> Locate the driver
Package: gpicview
Version: 0.2.5-3+b1
Severity: wishlist
Tags: patch upstream
X-Debbugs-Cc: hikaru.deb...@web.de
Dear Gpicview Maintainers,
I found gpicview's default zoom factor steps to be too large for my liking, so I
wrote a small patch to make the steps configurable via the configuration
I can reproduce this with firefox-esr 60.5 on a Cubieboard 2 running
Stretch/armhf. However, in a Buster/armhf chroot Firefox works fine.
To make sure this is not a chroot effect I tried again in a Stretch/armhf
chroot and it shows the same error as the Stetch/armhf host.
For sake of
Hello,
I understand the exchange between upstream and Debian is a bit sluggish here,
but besides that, is there a reason why Pierre's patch has never been applied?
The current situation breaks mkdeb (in some cases?) (e.g. phc_intel [1]) and
this part of Pierre's patch would fix this:
> - fix
I made some further testing, by replacing the current glibc and x11vnc packages
with the ones from before my dist-upgrade (from snapshots) and found,
that the combination new glibc 2.24-8 / old x11vnc 0.9.13-1.2 does not exhibit
the problem, while the combination old glibc 2.24-5 / new x11vnc
It turned out, I had extra characters in my debian/rules file, most likely due
to a mistake while copying the patch from the wiki. This crippled my tar
command, but didn't make it completely useless.
So much for "following instructions". ;-)
Thanks for your patience!
In the end I manually
> Yes it should be made clearer, if you are on amd64 and want the 32 bit
> libraries, not all packages should be installed.
>
> Basically you'll want to install libgl1-nvidia-glx-i386 (or
> nvidia-driver-libs-i386 depending on the branch) and their dependencies.
>
> I've updated the wiki.
Dear Luca,
> Meanwhile, you can build the package from our SVN repositories following
> the instructions on the wiki:
>
> https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
I followed the instructions to the letter on Jessie, with the tar patch and
without it (but
Thanks for the links!
I stumbled upon #2 yesterday before patching the source, but somehow I missed
#1.
#2 doesn't seem all that relevant to me, except for signaling that there might
or might not be some improvement coming from upstream in the long run.
#1 looks pretty similar to my patch. But
From: Bernhard Übelacker bernha...@vr-web.de
I tried as a workaround to build a libqtwebkit package with attached
little modification (does disable JIT, like for other archs).
With this the browser does not crash.
confirmed on real hardware.
From: Lisandro Damián Nicanor Pérez Meyer
Sorry for the delay.
I can confirm that both of Bernhard's patch variants work on real hardware, in
mplayer2 and vlc.
Thank you very much!
kind regards
hikaru
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Also installing the -dbg packages for the shared objects
shown in your backtraces would give even better results:
libjavascriptcoregtk-1.0-0-dbg
libqtwebkit4-dbg
I installed these packages:
libjavascriptcoregtk-1.0-0-dbg
libqtwebkit4-dbg
libc6-dbg:i386
libglib2.0-0-dbg:i386
Hello Bernhard,
thanks for your reply!
I will try to reproduce your findings on real hardware tomorrow.
Can you have a look at the qupzilla and/or xombrero issue as well please? I'm
not sure anymore if it's the same problem,
because meanwhile I installed a qemu vm myself (on Wheezy/amd64) using
Hi Bernhard,
I have run your gdb examples on the K6-2 now and came to the same result for
vlc:
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb0fd4b40 (LWP 1001)]
0xaf19da49 in mid_pred (c=0, b=0, a=0) at
/build/libav-H9AQHK/libav-11.3/libavcodec/x86/mathops.h:77
Hmm, it's a strange thing. If I recompile fso-deviced eveything works as
expected.
But you can reproduce the problem with the packages as they are in Debian
right now?
I just rebuild the Jessie package (armhf) and still get the same startup
error (as I expected).
It seems, the generated .c
That doesn't help:
# apt-get install fso-deviced-n900
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
libgcrypt11 libgee2 libgnutls26 libjpeg62
Use 'apt-get
Package: snowballz
Version: 0.9.5.1-2.1
Severity: minor
Hi,
the snowballz homepage [1] seems to be down. For the package description I'd
suggest to link to the projects sourceforge site [2] instead.
regards
hikaru
[1] http://www.joey101.net/
[2] http://sourceforge.net/projects/snowballz/
Hi,
I can confirm this bug on Squeeze amd64.
Run this in a terminal in bash:
for f in /usr/lib/pymodules/python2.6/misc/* ; do if [ -L $f ] ; then
dpkg -S `readlink $f` ; fi ; done
hik...@squeeze820qm:~$ for f in /usr/lib/pymodules/python2.6/misc/* ; do if [
-L $f ] ; then
dpkg -S
Hello Dana and Nico,
thanks for replying!
I have no idea and am using a top placed panel since quite a while without
ever noticing such a problem.
Ktorrent also does not give me a problem. It opens under Openbox's
placement policy, not from a position specified in the app, and so
doesn't go
Update:
I tried some Ubuntu kernels and while 2.6.27-7-generic and successors have the
same problems like the kernels from lenny-backports, 2.6.24-27-generic burns
DVD+RW at a reasonable speed.
So I guess the critical change happened between 2.6.26 and 2.6.27.
20 matches
Mail list logo
