Bug#836329: [Pkg-lyx-devel] Bug#836329: fonts-lyx: bad fonts rendered with matplotlib
Hi, we have two related problems here: 1) At http://www.lyx.org/trac/changeset/f496ec373bafa/lyxgit we changed the font style from "Regular" to "LyX" to work around a qt shortcoming. This is probably the reason why cmr10.ttf is not used any longer to display the superscript 3. Note that the discussion at the bug http://www.lyx.org/trac/ticket/9229 which was solved by this change did include the former maintainers of the Debian LyX package. We did try hard not to break any package depending on LyX fonts. 2) The font replacement algorithm used by matplotlib has a bug. It seems it uses some kind of symbol font which causes the omega instead of the superscript 3. This symbol does not come from the additionally queried cmex10.ttf font, I believe this font is tested because cmr10.ttf did not work, but is then discarded as well. Georg
Bug#829271: Missing libqt4-svg depency
Package: lyx Version: 2.2.0-1 Hi, LyX requires the qt SVG module to display toolbar icons correctly since version 2.2.0. Since qt loads this at runtime it is not picked up automatically when building the package. Please add a manual dependency on libqt4-svg. Note: This was reported originally on the LyX users list: http://www.mail-archive.com/lyx-users@lists.lyx.org/msg103465.html Thanks, Georg
Bug#823811: [Pkg-lyx-devel] Bug#823811: LyX: missing out-of-the box support for Hebrew
Hi Tzafrir, thank you very much for the report. Am 09.05.2016 um 12:05 schrieb Tzafrir Cohen: Package: lyx Version: 2.1.4-2 Severity: minor Dear Maintainer, I'm not much of a LaTeX / LyX user myself anymore, but decided to report this following a discussion I had in a community forum recently. When I try to use Hebrew with LyX and can either: Use the default (pdflatex): In that case Hebrew support is through babel. The fonts it points to are a set of fonts not really available anywhere. At the time I packaged Hebrew support for babel that included usage of the culmus fonts. I guess some extra effort could be put into making the Culmus fonts the default ones (the originals were a set of low quality fonts of dubious legal status). That would need to be solved at LaTeX level, or did I misunderstand something? To my knowledge, LyX does not load any special hebrew fonts. Use xelatex: In that case Hebrew support is through polyglossia (and implicitly: bidi). Works generally better. However: * The LyX user interface still fails to "reverse" Hebrew. I would have expected a QT-based program to do that. This is an issue I would probably take upstream. Yes, this is definitely upstream. Some work has been done for RTL support for the upcoming 2.2.0 release. It would be nice if you could test whether the situation has improved in this version: ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0rc1 Unfortunately there is a lack of RTL languages upstream, so your testing would be very valuable. RTL bugs in the 2.1.x line will mot likely not being fixed anymore, the 2.2 line is the one where all work goes ATM. * Debian comes with several good font sets that have a good coverage of Hebrew, as well as many other scripts (for instance: Deja-Vu). Yet, I need to explicitly set the serif font of the document in order for documents with Hebrew texts to render. Can't the default be changed? This would probbaly be a debian specific default, to be made by the packager, and would require that the LyX package depends on some font packages. Upstream cannot assume anything about installed fonts. Unfortunately LyX does not have a proper debian maintainer at the moment. Georg
Bug#816173: [Pkg-lyx-devel] Bug#816173: Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist
Am 28.02.2016 um 18:22 schrieb Sven Hoexter: On Sun, Feb 28, 2016 at 11:42:52AM +0100, picca wrote: Hi, while preparing my tango package, I need to build the documentation with lyx. For future reference, here is the d-d thread: https://lists.debian.org/debian-devel/2016/02/msg00454.html It seems that it is not allow to write outside the source directory except /tmp during the build process. I see at least two problems. 1) lyx try to create a $HOME/.lyx even if $HOME does not exist 2) it would be great to avoir creating this .lyx directory by default. While I agree that 1) is a bug 2) is a bit more complicated. It is documented that LyX needs a user configuration directory. If the default location does not fit, you can use the -userdir parameter. Where is the problem? Would you like to fail in a different way if $HOME does not exist? It would be easy to add a check for that, but I'd like to understand the problem before doing anything. LyX is not really intended to be used this way, it's more or less centered around the idea of an GUI use in a real user environment. Most people do indeed use LyX that way, but using it via command line without a GUI is an important use case as well (and works fine in general). It's part of the whole configuration problem, kind of a dublicate of #397464. Yes. Parts of the configuration in .the user directory are needed (they are expensive to calculate), other could be gathered by different mechanisms if somebody would take the time to implement that. Georg
Bug#753993: lyx: SIGSEGV when saving a new LyX file resulting in data loss
The development of the 2.0.x series of LyX was closed with the release of 2.0.8.1. There will be no further bug fixes upstream, and I don't think it makese sense to try debian specific fixes. Unfortunately LyX 2.1.0 suffers from a more serious crash which is extremely difficult to reproduce, but has been seen by several people, see http://www.lyx.org/trac/ticket/9049. I doubt it has anything to do with this report, but I mention it for completeness. Thanks, Georg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700828: fixed upstream
tags 700828 fixed-upstream thanks Thanks for reporting, I fixed the bug for 2.0.6 (http://www.lyx.org/trac/changeset/a53dd33474f51645b5c692751fc036d4a7a03dcd/lyxgit) and 2.1 (http://www.lyx.org/trac/changeset/d2d0f1964ddafb1b46448a9e2d59255cf2875283/lyxgit). Georg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510609: esint10.ttf missing
Package: latex-xft-fonts Version: 1.8 The esint10.ttf font is missing from the font package. It is needed for consistent look of integral signs in LyX. It is available from the LyX source package (directory lib/fonts). That directory contains also some other fonts that are supposed to be a better replacement for the fonts of this package (maybe they fix bug 388795?). Therefore an alternative solution might be to drop this package completely, and create a new ttf-lyx-fonts package from the LyX sources. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506482: [Pkg-lyx-devel] Bug#506482: Regression: shift+select no longer works in math mode
Am Freitag, 21. November 2008 schrieb Alex Roper: It used to be in older versions of LyX you could use SHIFT+arrows to select in math mode. I find this feature crucial, as it allows me to do algebraic manipulation in LyX far faster than I could write it out by hand, eliminating my paper dependence. The new version looks snazzy and has a bunch of cool new features, but I have pinned the old one because this is simply a deal killer for me. This is supposed to work out of the box without any customization. I don't see this problem in a self compiled current 1.6svn. Can you give a precise recipe? Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499629: [Pkg-lyx-devel] Bug#499629: Bug#499629: texlive-latex-extra should be recommended dependency
Am Montag, 22. September 2008 schrieb Per Olofsson: I wouldn't say it's unusual to have LyX installed without texlive-latex-extra. Although I agree that it's very unfortunate that integrals don't work without it. Maybe this bug should be reassigned to texlive, and esint asked to be moved to texlive-latex-recommended or texlive-fonts-recommended or something. Integrals work fine without esint. Simply set the use esint setting from auto to off. The problem is that the look of many integrals is inconsistent without esint. It also depends on whether you use wasysym and/or amsmath (and in which order you load those packages). IMO, the esint package is a must for everybody who uses more than just \int. OTOH people who dont use more specialized integral symbols or even math at all will never need the esint package. If there was a texlive-math package I would put esint into that package. texlive-latex-recommended might be too strong for non-math users, texlive-fonts-recommended is wrong IMHO because esint is not only a font, it fixes other packages. IMHO the current status is not too bad: If somebody actually uses an integral that triggers esint, he will get a LaTeX error. If he does not know esint, he can find some information in the documentation, and then eithwer switch off esint or search for it in the package database, and install the needed package. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473077: [Pkg-lyx-devel] Bug#473077: Bug#473077: lyx: lyx can't start
Am Freitag, 28. März 2008 schrieb Per Olofsson: I think the problem lies within ntfs-3g. I can't see any generic instances of stat64 returning EILSEQ inside the kernel. However, lyx shouldn't crash because of this in any case - there is either a bug in boost or in lyx. Sure, the crash is a bug regardless of the reason. LyX probably passes the filename in the wrong encoding to boost::filesystem. Arnaud, please file the problem upstream at http://bugzilla.lyx.org (a link to the debian bug should be enough). Did you give the file name on the command line? Then it could also be that LyX does not interpret the encoding of the command line correctly. Georg
Bug#315570: Please fix this bug - it makes the package unusable
The subject says it. I have spent a considerable time debugging this until I found this report. The latest patch by Andreas (although it did not apply cleanly) fixed the issue. Here are my observations: I use arpack from a C++ program via some selfmade bindings. Without the patch it works fine on an amd 64bit machine using gcc/gfortran 4.0.1 (SuSE 10.0). I get lots of nans in znaupd on two amd 32bit machines: One running SuSE 9.2 using gcc/g77 3.3, and the other one running Debian etch using gfortran/gcc 4.1. arpack was self compiled on the SuSE machines (using the debian source packages - a procedure I often use successfully for scientific software that is not available on SuSE, thanks to the good suppport in Debian) and I used the .deb on the debian machine. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428967: [Pkg-lyx-devel] Bug#428967: Bug#428967: lyx: main window does not repaint with Qt 4.3
Am Freitag, 15. Juni 2007 12:06 schrieb Per Olofsson: Hi, On 2007-06-15 Laurent Bonnaud wrote: since I upgraded this system with Qt 4.3 from experimental, lyx does not work any longer. It opens its main window but is not able to draw it: $ lyx QWidget::repaint: Recursive repaint detected QWidget::repaint: Recursive repaint detected [...] This problem has been reported some time ago on the Mac (and fixed), search the LyX devel mailing list archives. Thank you for reporting this. We are going to upload LyX 1.5.0rc1 soon, I will check if the bug is still present in that version. I don't think that using rc1 it will make a difference. Maybe Qt 4.3 is not as binary compatible to 4.2 as supposed and recompiling against Qt 4.3 helps? Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329331: [Pkg-lyx-devel] Bug#329331: Really???
Am Montag 23 April 2007 22:32 schrieb Marco Herrn: Hi, On Sun, Apr 22, 2007 at 05:31:10PM +0200, Georg Baum wrote: Since LyX 1.4.0 it is not possible anymore to omit the extension in LyX, so this bug is no longer applicable and should have been closed with the first 1.4.x release in debian. LyX will omit the extension for LaTeX export if that is possible. Uhm, maybe you misunderstood the bugreport. It is _not_ related to LyX exporting LaTeX files, but only to the image preview inside LyX. I understood that. Therefore I wrote that this report is no longer applicable. Since LaTeX doesn't need the extension, I would prefer that LyX also doesn't need it. As I explained already this is not possible anymore. Sven Hoexter wrote: Sounds like the behaviour upstream prefers is the contradiction of what Marco would like to have. Is there a way we can agree to close this bug? Like a technical reason why it's not a good idea to implement the wished behaviour? Well, if this is the case, then this bug can be closed. But I am not yet sure that we are talking about the same problem. Georg Baum wrote: I ask another question: Is there any reason why you would _not_ want to specify exactly which file you want to include? The reason I want it, is that I need to output my document as PDF and PS, therefore are having the images in EPS and PDF format. Since LaTeX and pdfLaTeX cannot use the image format of the other, I need a way to specify both (by omitting the extension). No, you don't need to do that. As I wrote LyX does not have the limitations of LaTeX. LyX does not have the limitations of LaTeX. It works out of the box with many image formats, and you can make it work with any image format you like by specifying additional converters. I did not know that. What means LyX works with many image formats? Am I able to create only an EPS file and LyX handles the conversion to PDF if necessary? Exactly. In fact it is not LyX that converts the images, but it knows about helper applications. Look at the file format and converter sections in the preferences dialog if you want to see which programs are used. The documenation (I believe the customization guide) also explains this in more detail. Since there is always exactly one original image the recommended practice is to use that and let LyX take care of the conversion to the needed format. That would be fine. It would be the preferred way for me. But how does that work together with LaTeX? Does LyX create all the necessary formats by converting and these files can also be used after an export of the document to LaTeX? Yes. You have two export formats that you can use: LaTeX (plain) and LaTeX (pdflatex). The first will produce eps files, the second will produce pdf files for vector graphics and png for bitmap graphics. If you need both, just export to both formats, but be aware that the generated .tex file can vary slightly. BTW, is there any special reason why you want to run latex and pdflatex manually? Unless that is the case I suggest to export directly to pdf or ps, then LyX will also take care of running latex, bibtex and makedindex. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329331: Really???
Since LyX 1.4.0 it is not possible anymore to omit the extension in LyX, so this bug is no longer applicable and should have been closed with the first 1.4.x release in debian. LyX will omit the extension for LaTeX export if that is possible. Did you really try to omit the extension with LyX 1.4.x? If that worked at all then it is a bug. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329331: [Pkg-lyx-devel] Bug#329331: Really???
Am Sonntag, 22. April 2007 18:11 schrieb Sven Hoexter: Sounds like the behaviour upstream prefers is the contradiction of what Marco would like to have. Is there a way we can agree to close this bug? Like a technical reason why it's not a good idea to implement the wished behaviour? I ask another question: Is there any reason why you would _not_ want to specify exactly which file you want to include? LyX does not have the limitations of LaTeX. It works out of the box with many image formats, and you can make it work with any image format you like by specifying additional converters. Since there is always exactly one original image the recommended practice is to use that and let LyX take care of the conversion to the needed format. Apart from that the old code in 1.3.x was complicated and caused several problems, one being the reason for this bug report. Another one: The edit button in the graphics dialog (new in 1.4.x) would not work. We had long discussions when this part of the code was changed, but I do yet have to see one reason why it would be desirable to omit the extension in LyX. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415636: Fixed upstream
Fixed upstream: http://www.lyx.org/trac/changeset/17506 Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338924: this is done on purpose!
\screen_font_encoding is an xforms-only setting that is ignored by lyx-qt on purpose. The encoding of fonts is transparently handled by qt, and LyX has no chance to influence it. If you have encoding problems with LyX then the reason is not a wrong font encoding, but something on a higher level: LyX may internally need a different locale than you are using, because up to version 1.4.x it does not understand unicode. See http://bugzilla.lyx.org/show_bug.cgi?id=1755. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402148: Fwd: Re: Source for latex-xft-fonts?
Forgot to CC the bug tracker. -- Weitergeleitete Nachricht -- Subject: Re: Source for latex-xft-fonts? Date: Dienstag, 16. Januar 2007 20:59 From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Am Dienstag, 16. Januar 2007 20:36 schrieb John Levon: On Tue, Jan 16, 2007 at 08:11:22PM +0100, Per Olofsson wrote: There is a bug filed against the latex-xft-fonts Debian package about the lack of source code for it (http://bugs.debian.org/402148). This prevents the package from entering etch (the upcoming stable release of Debian). Apparently the fonts have been converted from the corresponding LaTeX .pfb fonts. Does anyone know how this was done? Is it possible to automate? I've entirely forgotten how I did it, but it definitely involved some manual fixing of the fonts. I used some popular open-source font editor, which I've also forgotten, and I had to fix some stuff up if I remember rightly. You probably used fontforge (formerly called PFAEdit IIRC). I have no idea what sources they're looking for. It's like complaining a .jpg doesn't have sources when it's a scanned in photo. No, it is rather like looking for the source of a jpeg that somebody created by manually modifying another one. This cannot be automated either. To me the ttf fonts look like a derived work of the original pfb versions. So, these could be considered as source, but the normal way of automated building from source would not work, so it would be pointless. AFAIK the original pfb fonts are under the LPPL, so I think the following would work: - The ttf files are considered as source technically. - The README documents that they were converted from the .pfb files and polished manually after that. - The README documents where to get the .pfb files (required by the LPPL). IANAL, but I see no reason why this would not work. Georg --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393834: [Pkg-lyx-devel] Bug#393834: lyx-xforms: Ends with assertion failure when navigating document
Am Mittwoch, 18. Oktober 2006 08:50 schrieb Sven Hoexter: On Tue, Oct 17, 2006 at 07:33:40PM -0400, Mark Carroll wrote: Hello Mark, hello *, I'm not sure if there is still someone interested in fixing bugs in the xforms frontend. I'd suggest you to try out the qt frontend by installing the lyx-qt package. I am pretty sure that this bug is independant of the frontend, because the coord cache is filled in the kernel. The interesting question is: Is it reproducible? If yes, how? Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390279: Probably fixed in 1.4.3
This is most probably a gcc 4.1 - boost bind related problem. See http://bugzilla.lyx.org/show_bug.cgi?id=2677. If that is the case then it is fixed in LyX 1.4.3 which will hopefully be uploaded soon to debian. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265030: Ispell and pspell still supported in 1.4?
Am Mittwoch, 6. September 2006 18:28 schrieb Sven Hoexter: On Wed, Sep 06, 2006 at 03:45:49PM +0200, Enrico Forestieri wrote: On Wed, Sep 06, 2006 at 12:20:26PM +0200, Sven Hoexter wrote: The Debian package has a bugreport about ispell problems. It seems to try to select the wrong dictionary for the enviroment. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265030 I don't think this is a LyX bug. At least if you don't pretend that LyX should also take care of the external programs' configuration... I mean, if an english dictionary is asked for and an english dictionary doesn't exist, it is not a LyX fault. If an american dictionary exists and you are fine with using it as if it was an english dictionary, then it is not LyX responsibility to set up the symlinks necessary to use it in that way... I've not yet investigated this issue to say who to blame for this problem. At least I can reproduce it. Anyway I did not want to say anything about this bug. I just wanted to note that someone uses ispell and seems to care about problems with it. That's all. I agree with Enrico that in this particular case LyX is not to blame, but the problem is more general: LyX simply asks for a dictionary that is named after the document language and does not check at all whether that is a vlid dictionary name. That works well in many cases, but not in all, and I think we need a translation list LyX language name - dictionary name for all supported languages and dictionaries. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265030: [Pkg-lyx-devel] Bug#265030: Ispell and pspell still supported in 1.4?
Am Mittwoch, 6. September 2006 21:15 schrieb Per Olofsson: Note that the libaspell support works well, since it uses language codes (e.g. en_US, sv_SE) instead of language names (english, swedish). You are right, I thought that the ispell dictionary names were used for all spell checkers, but that is wrong. I'd be all for dropping ispell support in the LyX Debian package and just tell people to use aspell. For debian that makes sense, because we know that a usable aspell exists, for the generic source package I'd keep it. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#193792: I can confirm this Bug is still present in LyX 1.4.2
Am Freitag, 28. Juli 2006 20:58 schrieb Sven Hoexter: Hi, ok I can confirm that this bug is still present in LyX 1.4.2. It seems to me that the intermediate Linuxdoc-sgml output is broken. Why linuxdoc-sgml? How do you prodcue the html? Is this one of the standard converters? All html-export related bug reports are useless unless you give the converter (including all flags that are used), too. It seems to me that it's just a missing /sect1 and linuxdoc simply terminates at the linebreak. Indeed. The question is: How was this file created? Directly from LyX, or via a .tex-linuxdoc translator? Georg: I'm not sure if I should post this to lyx-devel or attach the information and the sample file to http://bugzilla.lyx.org/show_bug.cgi?id=1759 Please open a new bug for the sgml problem (does that also occur when you export to linuxdoc sgml?). 1759 is very confusing, and I don't know what to do with that. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269968: [Pkg-lyx-devel] Bug#269968: Bug seems to be valid for other dvi viewers aswell
Am Freitag, 28. Juli 2006 21:16 schrieb Sven Hoexter:
Hi,
this bug also occurs with kdvi. Probably other dvi viewers are effect
aswell.
The xdvi manpage suggest to use \usepackage[dvips]{geometry} within the
TeX input file.
The geometry package can cause problems if used together with certain other
packages, but that is not important. Important is the fact that the paper
size is specified in the dvi file, and one way to ensure that is to use
the geometry package with the dvips option.
This bug should be reported in LyX bugzilla please (or maybe it exists
already, I don't know).
Georg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357119: fixed in current upstream version 1.4.1
Am Samstag, 27. Mai 2006 15:08 schrieb Martin Michlmayr: * Georg Baum [EMAIL PROTECTED] [2006-05-12 22:18]: This bug is fixed in the current upstream version 1.4.1. It compiles fine with gcc 4.1. When will this be uploaded? Probably soon (by NMU). See http://lists.alioth.debian.org/pipermail/pkg-lyx-devel/2006-May/000757.html Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215889: fixed in current version 1.4.1
LyX uses the new program tex2lyx to import LaTeX documents since 1.4.0, and tex2lyx does not have this problem: http://bugzilla.lyx.org/show_bug.cgi?id=971 Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357119: fixed in current upstream version 1.4.1
This bug is fixed in the current upstream version 1.4.1. It compiles fine with gcc 4.1. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286555: LyX works fine with python 2.4
The conflict with python 2.4 should be removed (as was done in ubuntu already). LyX works fine with python 2.4. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251873: diff file available
I have created my own package. Feel free to use the attached diff as a
base for an official one.
Georg
diff -ruN libmarc-charset-perl-0.95.orig/debian/changelog libmarc-charset-perl-0.95/debian/changelog
--- libmarc-charset-perl-0.95.orig/debian/changelog 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/changelog 2006-03-05 16:37:59.0 +0100
@@ -0,0 +1,5 @@
+libmarc-charset-perl (0.95-1) unstable; urgency=low
+
+ * Initial version
+
+ -- Georg Baum [EMAIL PROTECTED] Sun, 05 Mar 2006 16:18:16 +0100
diff -ruN libmarc-charset-perl-0.95.orig/debian/compat libmarc-charset-perl-0.95/debian/compat
--- libmarc-charset-perl-0.95.orig/debian/compat 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/compat 2006-03-05 16:56:29.0 +0100
@@ -0,0 +1 @@
+4
diff -ruN libmarc-charset-perl-0.95.orig/debian/control libmarc-charset-perl-0.95/debian/control
--- libmarc-charset-perl-0.95.orig/debian/control 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/control 2006-03-05 17:13:54.0 +0100
@@ -0,0 +1,31 @@
+Source: libmarc-charset-perl
+Section: perl
+Priority: optional
+Maintainer: Georg Baum [EMAIL PROTECTED]
+Build-Depends: debhelper (= 4.0.0), perl
+Standards-Version: 3.6.1
+
+Package: libmarc-charset-perl
+Architecture: all
+Depends: ${perl:Depends}, libclass-accessor-perl
+Description: Bidirectional MARC-8 - Unicode converter module for perl
+ MARC::Charset is a package to assist you in converting converting data encoded
+ using MARC-8 character sets to Unicode (UTF-8).
+ .
+ The MARC format (MAchine Readable Cataloging) has been used since the early
+ 1970s to encode bibliographic data. Since catalogers have used non-Latin
+ character sets for a long time, MARC had to grapple with the issue of encoding
+ non-ASCII data in an 8-bit environment from very early on; this became known
+ as the MARC-8 Environment.
+ .
+ In 1992 the Unicode standard provided a a uniform encoding for all major
+ modern written languages. The MARC21 standard now supports encoding character
+ data in Unicode, specifically the UCS Transformation Formats-8 (UTF-8). UTF-8
+ has the advantage that it allows normal ASCII (8-bit) data to exist side by
+ side with the full repertoire of Unicode characters (16-bit).
+ .
+ Unicode notwithstanding, libraries still have a wealth of data encoded using
+ MARC-8. Yet, some new data formats such as XML require that characters are
+ encoded using Unicode. In order to fascilitate conversion the Library of
+ Congress graciously published character mappings to enable the conversion
+ of MARC-8 data to Unicode.
diff -ruN libmarc-charset-perl-0.95.orig/debian/copyright libmarc-charset-perl-0.95/debian/copyright
--- libmarc-charset-perl-0.95.orig/debian/copyright 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/copyright 2006-03-05 16:52:02.0 +0100
@@ -0,0 +1,12 @@
+This package was debianized by Georg Baum [EMAIL PROTECTED]
+Sun Mar 5 16:18:16 CET 2006
+
+
+It was downloaded from http://www.cpan.org/modules/by-module/MARC/MARC-Charset-0.95.tar.gz
+
+Upstream Author(s): Copyright (C) 2002 Ed Summers [EMAIL PROTECTED]
+
+Copyright:
+
+This software is free software and may be distributed under the same
+terms as Perl itself.
diff -ruN libmarc-charset-perl-0.95.orig/debian/docs libmarc-charset-perl-0.95/debian/docs
--- libmarc-charset-perl-0.95.orig/debian/docs 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/docs 2006-03-05 16:20:50.0 +0100
@@ -0,0 +1 @@
+README
diff -ruN libmarc-charset-perl-0.95.orig/debian/rules libmarc-charset-perl-0.95/debian/rules
--- libmarc-charset-perl-0.95.orig/debian/rules 1970-01-01 01:00:00.0 +0100
+++ libmarc-charset-perl-0.95/debian/rules 2006-03-05 17:11:16.0 +0100
@@ -0,0 +1,84 @@
+#!/usr/bin/make -f
+# Sample debian/rules that uses debhelper.
+# GNU copyright 1997 to 1999 by Joey Hess.
+
+# Uncomment this to turn on verbose mode.
+#export DH_VERBOSE=1
+
+
+
+ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -g
+endif
+ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+ INSTALL_PROGRAM += -s
+endif
+
+configure: configure-stamp
+configure-stamp:
+ dh_testdir
+ perl Makefile.PL INSTALLDIRS=vendor
+ touch configure-stamp
+
+
+build: build-stamp
+build-stamp: configure-stamp
+ dh_testdir
+ $(MAKE)
+ touch build-stamp
+
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp configure-stamp install-stamp
+ -$(MAKE) clean
+ dh_clean
+
+install: install-stamp
+install-stamp: build-stamp
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+ dh_installdirs
+ $(MAKE) install PREFIX=$(CURDIR)/debian/libmarc-charset-perl/usr
+# rm `find . -name perllocal.pod`
+# rm -rf debian/libmarc-charset-perl/usr/lib
+ touch install-stamp
+
+
+# Build architecture-independent files here.
+binary-indep: build install
+ dh_testdir
+ dh_testroot
+# dh_installdebconf
+ dh_installdocs
+ dh_installexamples
+ dh_installmenu
Bug#207507: Fixed upstream
Am Freitag, 14. Oktober 2005 07:22 schrieben Sie: So, the lyx side of this is completely fixed now, and it's just a tetex filename parser issue? Yes. There is little hope that the latter is going to change, this is simply a limitation of TeX. See also http://sarovar.org/tracker/index.php?func=detailaid=377group_id=106atid=493 and the pdftex mailing list for details. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329331: Fixed in upcoming 1.4.0
This is fixed in the upcoming 1.4.0 release. A fix in 1.3.x is not possible because it requires a file format change, and that is not allowed in 1.3.x. The solution for now is not to omit the extension, LyX will omit it in LaTeX output if it is possible (at least in 1.3.6, don't know about earlier versions. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#275325: 1.3.6 is now available
LyX 1.3.6 with lost of fixes was just released - see http://www.lyx.org/announce/1_3_6.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#193645: Fixed upstream
This bug is fixed upstream in the just released LyX 1.3.6. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#207507: Fixed upstream
This is fixed in 1.3.6. If you don't use a temporary directory or export the file as LaTeX you'll need tetex 3.0, but even with that it will not work in all cases (no spaces are allowed for .bib files and graphics with pdflatex and pdf output) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#193645: (no subject)
According to John Levon this is a qt bug that can't be worked around in LyX. Search the developers mailing list archive (link at http://www.lyx.org/internet/mailing.php3) for details. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203284: (no subject)
This bug is reproducible and known upstream. It is partly fixed in 1.3.5 and completely in the upcoming 1.4cvs. See http://bugzilla.lyx.org/show_bug.cgi?id=605 for details. Georg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
