Bug#772845: freetuxtv: package keeps crushing at startup screen
Hi
I confirm that the patch file 02-crash.diff (corresponding to svn commit 750)
solves this segfault issue.
To fix the compilation issue mentionned by Petter Reinholdtsen above,
apparently you also need to apply
the commit 747 (patch attached).
Best,
Pierre L.Index: lib/libvlc-gtk/gtk-libvlc-media-player.c
===
--- lib/libvlc-gtk/gtk-libvlc-media-player.c (révision 746)
+++ lib/libvlc-gtk/gtk-libvlc-media-player.c (révision 747)
@@ -1819,7 +1819,7 @@
// Create the media player if not initialized
gtk_libvlc_media_player_initialize (self, );
- g_return_if_fail(priv->initialized == TRUE);
+ g_return_val_if_fail(priv->initialized == TRUE, gtkstate);
if(pError == NULL){
Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)
Hi!
Some other matters lead me to learn a bit of the pdf format, so I've tried to
investigate some more this bug.
First, the ps2pdf shipped with Jessie seems to still produce the same pdf
out of my test.tex / test.dvi / test.ps (with only a few minor textual
differences in optional fields such as metadatas).
Secondly, the pdf viewers available in Jessie are doing a better job
at displaying this test.pdf:
- Evince (or actually the underlying poppler library) is now displaying
correctly
this problematic pdf. Try for instance 'pdftocairo -png test.pdf test.png'.
- Xpdf is still displaying correctly these pdf, but still with the warning
about "Bad bounding box in Type 3 glyph".
- I tried to use directly gs for rendering to png, and it works fine:
gs -dSAFER -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dBATCH
-dGraphicsAlphaBits=4 -dQUIET -r100 -sOutputFile=test.png test.pdf
- The only issue left is with the mupdf viewer (or its command-line tool
mudraw).
I've attached the png obtained from the original test.pdf via:
mudraw -o test.png test.pdf
It looks exactly as the earlier faulty display (three black dots instead of
the expected text) that was obtained via Wheezy's evince.
Anyway, I still think that ps2pdf is producing an erroneous pdf, and that the
various
pdf viewers are doing there best to overcome this issue. Indeed, as hinted by
the
xpdf warnings, the /FontBBox [0 0 1 -1] in test.pdf looks quite wrong.
NB: Actually, I inspected an uncompressed version of test.pdf, obtained by
'pdftk test.pdf output testu.pdf uncompress' , but you could do the same thing
with the original test.pdf.
In particular the last number in /FontBBox is the max height of characters
(inversed
by a -1 in /FontMatrix). If we enlarge this height, say to a /FontBBox of [0 0
1 -25],
we start seeing in mupdf the lower half of the characters of the text "Bla Bla
Bla".
If you continue to a /FontBBox of [0 0 1 -58], the text is displayed correctly
(I've tried 58 since it seem to be the largest height of the four bitmap
characters
in the text (see /H in the uncompressed pdf). Strangely, the width doesn't seem
to
need any fixing in the /FontBBox, probably because of the /Widths directive.
This faulty FontBBox seems indeed to be introduced by ps2pdf, since there's
apparently
a /FBB[0 0 0 0] and a /FootBBox FBB in the initial test.ps. I really don't know
much
of PostScript, but that looks like a [0 0 0 0] FontBBox, meaning "autodetect" ?
Btw, trying a [0 0 0 0] FontBBox in test.pdf doesn't please mupdf (back to a
few black
dots).
Finally, a few words about the latex code (my previous test.tex) that lead to
this issue.
After some more googling, it appears that using \usepackage[T1]{fontenc} is
fine, and even
a good idea (see for instance [1]). But this line is normally meant to be used
in combination
with some extra font package, e.g. \usepackage{cm-super} or
\usepackage{lmodern} or
\usepackage{ae}, the latter being my favorite. With any of these font packages,
we obtain
nice Type 1 fonts, while the T1 fontenc alone leads to the use of Type 3 fonts
(see [2]), and
these Type 3 fonts seem to be a frequent source of issues. In particular here,
my original
test.tex with an extra \usepackage{ae} leads (still via dvips and ps2pdf) to a
pdf
which displays ok, even with mupdf. Nonetheless, it would be nice to fix this
issue with
Type 3 FontBBox.
Best regards,
Pierre
PS: I also tried ps2pdf on an i386 machine, but the behavior was the same as
what I describe
above for amd64. Strange, since for the initial reporter this bug was apparently
architecture-related ?
[1]
http://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc
[2]
http://tex.stackexchange.com/questions/1291/why-are-bitmap-fonts-used-automatically
Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)
Hello again,
I took a few minutes to minimize my own example of unreadable pdf.
I ended with a quite bare test.tex:
\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
Bla Bla Bla
\end{document}
Please find attached this file, plus the corresponding test.ps
obtained via latex test dvips test.dvi and the test.pdf produced
by ps2pdf test.ps.
As previously, evince doesn't display correctly the text of this test.pdf:
you only see a few (bottom?) black pixels for each letter. With xpdf the display
is ok, but with warnings about Bad bounding box in Type 3 glyph.
This definitively looks like a font issue, since without the
\usepackage[T1]{fontenc} line the display is back to normal.
Best regards,
Pierre
\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
Bla Bla Bla
\end{document}
test.ps
Description: PostScript document
test.pdf
Description: Adobe PDF document
Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)
Evince can also display Postscript. For the garbled PDFs, do the corresponding Postscript look fine in Evince? Yes, the above test.ps is displayed nicely by evince (or gv, or whatever). When displaying tp2A_scilab_N1.ps in evince, the display is ok, but I get some warnings: GPL Ghostscript 9.05: Error: Font Renderer Plugin ( FreeType ) return code = -1 Not sure whether these warnings are related with the current issue... If not, this seems not a Ghostscript bug, but a TeX (or user) bug to me. Well, obviously many things could be at fault here : - the postscript creator indeed (latex + dvips) - ps2pdf - the pdf viewers Or any combination of the three :-(. Anyway, it's just a wild guess, but the garbled evince + the error msgs in xpdf make me suspicious about the content of these pdf files. Btw, what would you call a user bug ? I've used this kind of tex sources with T1 fontenc for ages without issues up to now. Thanks for your help Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558479: nvidia-kernel-source: Version 190.42-2 does not build against 2.6.32rc8 in Unstable
Hi Same issue here. I've managed to build this nvidia module nonetheless by creating manually the missing file module-common.lds, see [1] for the content it should have. Before that, I had to cheat a bit: I've found no linux-kbuild-2.6.32 yet, which is required by linux-headers-2.6.32-rc8-*. So I made one myself out of linux-kbuild-2.6.31 sources (and some nasty sed -i -e s/2.6.31/2.6.32/g): no surprise it isn't fulling working ;-) Have you done something similar, or does linux-kbuild-2.6.32 exists somewhere I didn't looked ? So anyway, I think this bug is more related with linux-kbuild-* package (or lack thereof) than with nvidia-kernel-source. Best regards, Pierre Letouzey [1] : http://www.linuxhq.com/kernel/v2.6/32-rc8/scripts/module-common.lds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511899: ITP: coinor-csdp -- A software package for semidefinite programming
Quoting Soeren Sonnenburg so...@debian.org: Sure, but you should carefully check whether licenses (coinor uses CLP) are compatible and maybe askt on the coinor mailinglist if they can give an exception in case there is a problem... Soeren Well, I'm clearly no license-expert, so feel free to prove me wrong, but I don't think we have a license issue here: currently coq and csdp form two separate and autonomous processes. Simply, coq may submit a problem to csdp (by mean of a pipe or whatever) and digest the output of csdp about this particular problem. In addition, coq is clearly usable even without csdp being installed on the system: in this case, the proof method that uses cdsp as oracle will not be available, but coq provides many other proof methods (they may be slower and/or more painful, but they work). Best, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511899: ITP: coinor-csdp -- A software package for semidefinite programming
Hi This ITP is a nice idea. In my research group, we're now using csdp as an external oracle when solving inequalities in the Coq proof assistant (see [1], or more specifically [2] for the use of csdp in Coq). This coinor-cdsp package could simplify things quite a bit for us, by becoming a recommends or suggests or whatever for package coq. Anyway, if you need early testers, or even help during the creation of this package, let me know... Best regards, Pierre Letouzey (Coq development team) letouzey AT pps.jussieu.fr [1]: http://packages.debian.org/coq [2]: http://www.irisa.fr/lande/fbesson/Fast_Reflexive_Arithmetics_Tactics.pdf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490945: tkgate: wrong path for simulator gsim
Package: tkgate
Version: 1.8.7-1
Severity: important
tkgate is currently unable to launch any simulation of a circuit.
Menu Simulate/Start a Simulation leads to an error pop-up:
Failed to start simultor '/usr/share/tkgate-1.8.7/libexec/gsim'
(by the way, there is a typo in the word simultor).
This issue seems to come from file /usr/share/tkgate-1.8.7/scripts/parms.tcl,
at line 41:
set simExec ${tkg_gateHome}/libexec/gsim
Either this line could be fixed to contain a reference to /usr/bin/gsim, or
/usr/share/tkgate-1.8.7/libexec could be created (as a simlink to /usr/bin ?).
Thanks in advance,
Pierre L.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fr_FR.utf8)
Shell: /bin/sh linked to /bin/bash
Versions of packages tkgate depends on:
ii libc6 2.7-11 GNU C Library: Shared libraries
ii libx11-6 2:1.0.3-7 X11 client-side library
ii tcl8.48.4.19-2 Tcl (the Tool Command Language) v8
ii tk8.4 8.4.19-1 Tk toolkit for Tcl and X11, v8.4 -
ii tkgate-data 1.8.7-1Event driven digital circuit simul
Versions of packages tkgate recommends:
ii tkgate-doc1.8.7-1Event driven digital circuit simul
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
