Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Wed, Nov 22, 2023 at 09:47:37AM +0100, Preuße, Hilmar wrote: > >This patch passed all my testing. Pavel > > > Great! Patch is in repo and will be in next upload. For the record: people who are suffering from this bug on unpatched systems can workaround it by simply adding path to filename when calling a5toa4... Pavel
Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Tue, Nov 21, 2023 at 01:55:57PM +0100, Preuße, Hilmar wrote:
> > Hilmar, please hold on with upload. I need to improve the patch as it breaks
> > with absolute paths. Don't know where I made the mistake because I was
> > testing
> > for it before going public. Anyway I need to come with a better fix.
> > Will keep you posted...
> >
>
> Thanks for information. I'll comment the patch for now.
This patch passed all my testing. Pavel
--- pfarrei.tlu 2023-11-21 11:43:19.611137725 +0100
+++ pfarrei.tlu 2023-11-21 11:46:53.993277671 +0100
@@ -100,11 +100,15 @@
-- build the temporary tex file
local tmpdir = os.tmpdir("pfarrei.XX" )
local tmpfile = string.match( arg[i], '.*/(.*)$') or arg[i]
+ -- pdflatex's -output-directory search for source pdf works with path specification but fails
+ -- when simple file name in the current working directory is provided, we need to provide '../' then
+ local local_source=''
+ if tmpfile == arg[i] then local_source = '../' end
local basename = string.match( tmpfile,'(.*)%.[^.]*$') or tmpfile
tmpfile = tmpdir..'/'..basename..'.tex'
local file = assert( io.open( tmpfile, 'w' ) )
if booklet then assert( file:write("\\PassOptionsToPackage{booklet}{pfarrei}\n") ) end
- assert( file:write("\\def\\OriginalFile{",arg[i],"}\n") )
+ assert( file:write("\\def\\OriginalFile{"..local_source,arg[i],"}\n") )
assert( file:write("\\input{a5toa4.tex}\n") )
assert( file:flush() )
file:close()
Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Sun, 10 Sep 2023 23:26:05 +0200 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= wrote: > > I got a response from Markus Kohm: > > The problem is known, but he does not intent to fix it because he does > > not have enough time. > > He recommends pdfjam which can do the same task. > > > > So I think a5toa4 should be removed. > > > > Thanks for the effort! > > I tag the bug wontfix, but I don't remove the package. You can try proposed fix on your current setup. https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg220760.html I plan to push it into CTAN, so it will hopefully get fixed in trixie (or bookworm if some cares to backport the fix). Pavel
Bug#730111: Still present in 2.1.3-1
On Fri, 4 Dec 2020 21:24:23 +0100 Pavel Sanda wrote: > On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing > wrote: > > Bug still like described in Nov. 2013, none of the proposed actions out > > of the comments have been done. > > The change of the message to be more informative will be fixed in lyx 2.3.7 & > 2.4. > https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit > > Moving RCS from suggested to Recommends look reasonable to me. > After that the bug can be closed. Dear Tobias, what is your take on this? 2.3.7 with fixed error handling is now in bookworm. - Either this is enough and we close the bug as wontfix - or we add RCS as Recommended and this is the right time to do it. I do not have strong opinion, what is your take on this? Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Mon, Jan 23, 2023 at 12:05:05PM +0100, Stefano Simonucci wrote: > With the driver nouveau instead of nvidia lyx is working also in the mate > (or gnome) environment. To sum, the offending commit in 2.3.7 is 8b6460e4f2d40 (Improve HiDpi handling). The suggestion is to add in ~/.lyx/preferences \draw_strategy backingstore and also report back the environment (Wayland/X11, Gnome/KDE/...), Qt version and whether HiDPI is used on the systema. Since I did not get any additional response from the reporter this is best we can have for the moment. Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Sun, Jan 22, 2023 at 08:04:09PM +0100, Dr. Tobias Quathamer wrote: > Sorry that I cannot provide any more useful ideas to narrow down this bug. We discovered meantime with Stefano the offending commit in 2.3.7 and opened the issue on lyx devel list. Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Fri, Jan 20, 2023 at 11:28:31AM +0100, Stefano Simonucci wrote: > I have updated the whole system. Do I try reinstalling lyx 2.3.6? If it's in your capabilities to build 2.3.6 on your own that would help. (apt build-dep lyx (as a root) and then compile locally as user and just try running it - happy to provide more instructions if necessary). Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Fri, Jan 20, 2023 at 11:13:31AM +0100, Stefano Simonucci wrote: > After the last upgrade of the package, the lyx editor is broken. Just to be sure: 1) it worked correcly with 2.3.6? 2) the only thing which was upgraded was LyX but not the rest of the system (e.g. Qt libes/ X libraries...)? Pavel
Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software
On Tue, Dec 13, 2022 at 04:23:21PM -0500, Jeremy Bicha wrote: > On Tue, Dec 13, 2022 at 4:19 PM Pavel Sanda wrote: > > > > On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini > > wrote: > > > LyX is listed on my system as proprietary software in gnome-software. > > > Looking online I found several people having this issue with other > > > programs, and the cause was always that the license couldn't be read by > > > gnome-software properly. > > > > > > Please ensure that gnome-software can properly read the license. If the > > > bug is not on our end, let me know and I will contact gnome-software > > > developers. > > > > Well, LyX installs it's licences where it should, i.e. into > > /usr/share/doc/lyx/copyright. > > If there is something specific WRT gnome, we can do it but we need > > gnome maintainers input... I don't use gnome personally so can't > > even test it. > > > > I CC maintainer of gnome-software if he has some hints for us. > > The GNOME Software app prefers to use AppStream metadata. > > https://wiki.debian.org/AppStream/Guidelines > https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html I see, thanks for your input. Ok, then this should be fixed in 2.4 series (cd5d1be8f8925) as org.lyx.LyX.metainfo.xml will be installed in /usr/share/metainfo/. For 2.3.x series appdata.xml is inside tarball but not installed. Tobias, 2.3.7 should be out within two weeks and I leave it to you whether manually fix it for bookworm's 2.3.7 or leave it for 2.4 which won't make it for the upcoming debian release. Pavel
Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software
On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini wrote: > LyX is listed on my system as proprietary software in gnome-software. Looking > online I found several people having this issue with other programs, and the > cause was always that the license couldn't be read by gnome-software properly. > > Please ensure that gnome-software can properly read the license. If the bug > is not on our end, let me know and I will contact gnome-software developers. Well, LyX installs it's licences where it should, i.e. into /usr/share/doc/lyx/copyright. If there is something specific WRT gnome, we can do it but we need gnome maintainers input... I don't use gnome personally so can't even test it. I CC maintainer of gnome-software if he has some hints for us. Pavel
Bug#1010624: neuron-dev: Compilation/linking problems with nrnivmodl
Package: neuron-dev Version: 7.6.3-1+b3 Severity: normal X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, I encountered several problems while trying to compile with nrnivmodl. When running it nrnivmodl expects that 1) for compilation openmpi (mpicc et al.) is present 2) for linking -lmeschach is expected to work 1. is solved by installing libopenmpi-dev 2. is solved by installing libmeschach-dev (libmeschach.so.1.2 was present, but for -lmeschach to work libmeschach.so link needs to be present and that is provided by libmeschach-dev) I wonder whether these should be dependencies (or at least suggested ones) for neuron-dev. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages neuron-dev depends on: ii libc6 2.31-13+deb11u3 ii libstdc++6 10.2.1-6 ii neuron 7.6.3-1+b3 neuron-dev recommends no packages. neuron-dev suggests no packages. -- no debconf information
Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination
On Mon, Apr 25, 2022 at 04:25:04PM +0200, Julien Cristau wrote: > On Mon, Apr 25, 2022 at 03:53:22PM +0200, Pavel Sanda wrote: > > for keyboard configuration I use the following command on my system: > > setxkbmap -model pc105 -layout "us,cz_qwerty" -option > > "grp:alt_shift_toggle" > > > > The cz_qwerty layout works mostly fine, except one singular failure: > > dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U). > > > > I am afraid non-native prepared/"fixed" this layout, because the layout > > logically ends up with caron+u, which is non-existent in czech while > > on all czech keyboards you end up with overring+u (ů, see > > https://en.wikipedia.org/wiki/Ring_(diacritic) ). > > > > It renders this layout unusable for continuous czech writing, can it get > > fixed? > > (Or at leat can you give me a hint where to fix this, I expect this could > > be two-liner change in some kayboard-layout files...) > > > The cz_qwerty layout is defined here: > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/ade97960d7bfc7fde8d08e9fa5584e7c3c51c23b/symbols/cz#L81 > > Key combinations including those with dead keys live in Xlib though: > https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre > > Reassigning to xkeyboard-config for now, let us know if you end up > reporting/fixing this upstream. Thanks. I figured out that this is actually minor problem as I can avoid dead caron altogether, as caps lock works with ů (for some reason I was mislead by seing the character " on top of the key ů, but of course caps lock is not identical to the shift key). So although I still consider this bug in the layout, its fairly minor and if we close this as wontfix, it's not big deal. Pavel
Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination
Package: x11-xkb-utils Version: 7.7+5 Severity: normal X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, for keyboard configuration I use the following command on my system: setxkbmap -model pc105 -layout "us,cz_qwerty" -option "grp:alt_shift_toggle" The cz_qwerty layout works mostly fine, except one singular failure: dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U). I am afraid non-native prepared/"fixed" this layout, because the layout logically ends up with caron+u, which is non-existent in czech while on all czech keyboards you end up with overring+u (ů, see https://en.wikipedia.org/wiki/Ring_(diacritic) ). It renders this layout unusable for continuous czech writing, can it get fixed? (Or at leat can you give me a hint where to fix this, I expect this could be two-liner change in some kayboard-layout files...) -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-xkb-utils depends on: ii libc62.31-13+deb11u3 ii libx11-6 2:1.7.2-1 ii libxaw7 2:1.0.13-1.1 ii libxkbfile1 1:1.1.0-1 ii libxt6 1:1.2.0-1 x11-xkb-utils recommends no packages. x11-xkb-utils suggests no packages. -- no debconf information
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 01:53:53PM -0300, Hernán Gustavo Solari wrote: > I work as well as the other. The fix was committed to upstream and will be fixed in 2.4. Pavel
Bug#1008266: unar: obsolete syntax of bash-completion file
Package: unar Version: 1.10.1-2+b6 Severity: normal Tags: patch X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, bash-completion script syntax is outdated for this package and as a result completion does not work here. The situation can be simply fixed by replacing "have" to "_have" keyword at lines 3 & 46. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unar depends on: ii dpkg 1.20.9 ii gnustep-base-runtime 1.27.0-3 ii libbz2-1.01.0.8-4 ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libgnustep-base1.27 1.27.0-3 ii libicu67 67.1-7 ii libobjc4 10.2.1-6 ii libstdc++610.2.1-6 ii libwavpack1 5.4.0-1 ii zlib1g1:1.2.11.dfsg-2 unar recommends no packages. unar suggests no packages. -- no debconf information
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 10:45:22AM -0300, Hernán Gustavo Solari wrote: > FIXED! > I am attaching the script. I think the end of script should be different though. See attached. Does this script work the way you expect? Pavel lyx Description: application/lyx
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 09:39:54AM -0300, Hernán Gustavo Solari wrote: > The bash-complete script does not work. It calls "have lyx" but have is not a > program. Strange "have()" should have been defined in /usr/share/bash-completion/bash_completion which should be called via /etc/bash_completion But it does not work here either. Not completion expert, but I see bunch of other scripts using "have" as well so I wonder whether this is wider issue. Pavel
Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py
On Mon, 3 Jan 2022 21:53:44 +0100 Pavel Sanda wrote: > On Wed, 29 Dec 2021 04:15:48 -0800 "Leo L. Schwab" wrote: > > Discovered this while trying to use Editorium's LyXBook modules. > > layout2layout.py was konking out with "TypeError: cannot use a bytes > > pattern on a string-like object." After a bunch of debugging, I found > > some strings in the script that hadn't been bytes-ified, which seemed to > > fix the problem. Patch attached. > > The patch can not be taken as is to the upstream. > Would you mind reporting the exact recipy how to reproduce your problem > (maybe attach layout and example lyx file?) The bug should be fixed upstream in lyx 2.4 https://www.lyx.org/trac/changeset/940d3ceeb9e6d8ce216afedf18c898ec075cc27d/lyxgit Pavel
Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py
On Wed, 29 Dec 2021 04:15:48 -0800 "Leo L. Schwab" wrote: > Discovered this while trying to use Editorium's LyXBook modules. > layout2layout.py was konking out with "TypeError: cannot use a bytes > pattern on a string-like object." After a bunch of debugging, I found > some strings in the script that hadn't been bytes-ified, which seemed to > fix the problem. Patch attached. The patch can not be taken as is to the upstream. Would you mind reporting the exact recipy how to reproduce your problem (maybe attach layout and example lyx file?) Thanks, Pavel
Bug#992592: lightdm fails to start after update to bullseye (missing '/var/lib/lightdm/data')
Package: lightdm Version: 1.26.0-7 Severity: grave Justification: renders package unusable X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, updating debian to bullseye killed access to my desktop environment. It was actually stretch->buster and then (after appropriate reboots etc.) buster->bullseye, so not sure which of two steps broke it. lightdm used to be default DM and was not working anymore after the update. Checking logs with lightdm --test-mode --debug showed critical line about missing /var/lib/lightdm/data like in bugs #947319 and #931335. apt-get purge lightdm apt-get install lightdm fixed the situation (purge was clearly doing bunch of stuff in /etc/ which should be probably part of distro-update procedures(?). -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.20-2 ii debconf [debconf-2.0] 1.5.77 ii libaudit1 1:3.0-2 ii libc6 2.31-13 ii libgcrypt201.8.7-6 ii libglib2.0-0 2.66.8-1 ii libpam-systemd [logind]247.3-6 ii libpam0g 1.4.0-9 ii libxcb11.14-3 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.8-2 ii lsb-base 11.1.0 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+22 Versions of packages lightdm suggests: ii accountsservice 0.6.55-3 ii upower 0.99.11-2 pn xserver-xephyr -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds
On Sat, Feb 27, 2021 at 02:25:28PM +0100, Dr. Axel Stammler wrote: > It happens with all documents in different situations, one of them > reproducibly being: > > - file ??? save as > - trying to copy the filename by pressing ^C > - pressing to close the file dialogue > - Lyx now freezes for about 30s > - you get impatient and try to click on something (like ???cancel???) or to > close the file dialogue or Lyx by clicking on the window decoration Unfortunately I can not reproduce, though I am not sure I understand step 2 in the recipy. > I suspect it has something to do with Lyx's interaction with the window > manager. That migh well be. What WM do you use? It might also be that Qt version plays a role so we might want to recheck the problem once bullseye becomes stable. > > If you look on top report is 100% taken by lyx process itself or some > > conversion routine in background (e.g. conversion of figure). > > Lyx Is it in your capability to provide gdb backtrace from the freezing period or perhaps look whether strace reports something interesting at that time? (You might need something like $ strace /usr/bin/lyx 2>&1|grep -vE 'localtime|gettimeofday|clock_gettime|^read|POLLIN' to avoid excessive overreporting). Please keep bugs.debian.org CC-ed, thanks :) Pavel
Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds
On Fri, 05 Feb 2021 15:35:13 +0100 Axel Stammler wrote: > Package: lyx > Version: 2.3.2-1 > Severity: important > > Dear Maintainer, > > Lyx again and again suddenly stops reacting to pointer and keyboard and takes > all CPU > capacity. Sometimes it quickly recovers without any errors, sometimes it > needs to be killed > after, say, an hour. This will be hard to fix unless some more information is provided. Is there recipy how to reproduce this behaviour? Does it happen with some particular document? If you look on top report is 100% taken by lyx process itself or some conversion routine in background (e.g. conversion of figure). Pavel
Bug#980044: warning: while removing fonts-lyx, directory '/usr/share/fonts/truetype/lyx' not empty so not removed
On Wed, 13 Jan 2021 19:21:49 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson wrote: > Removing fonts-lyx (2.3.6-1) ... > dpkg: warning: while removing fonts-lyx, directory > '/usr/share/fonts/truetype/lyx' not empty so not removed > > # find /usr/share/fonts/truetype/lyx > /usr/share/fonts/truetype/lyx > /usr/share/fonts/truetype/lyx/.uuid Dupe of your own bug #923939 from 2019. Haven't time to look at the issue, but the good news is that fontconfig should drop the .uuid feature in future releases. Pavel
Bug#867577: #867577 lyx: Alt-m triggers space dialog in math mode
On Fri, 30 Mar 2018 02:48:49 -0400 Paul Elliott wrote: > I have noticed this bug too. But only when using kde plasma, goes away when > using Gnome. I couldn't reproduce on plasma 5.18.5 & Qt 5.12.8. If you can still see this bug what versions of Qt and Plasma you are using? Pavel
Bug#915113: lyx: Has problem exporting to Postscript - fails on converting certain images
On Mon, Dec 14, 2020 at 03:41:37PM +0100, Pavel Sanda wrote:
> On Mon, 14 Dec 2020 12:11:50 +0100 Adrian Immanuel =?ISO-8859-1?Q?Kie=DF?=
> wrote:
> > the described problem of exporting to Postscript is gone.
>
> Good, closing this bug.
>
> > The problem, that seminar based slides are only exported to portrait
> > mode persist. Try to export a seminar based slide to landscape page
> > format, and it will always end up in portrait mode.
>
> Does adding
> \usepackage[landscape]{geometry}
> to preamble help?
If we are talking specifically about postscript, this bug might be related:
https://www.lyx.org/trac/ticket/2721
> Pavel
Bug#964090: Please upload backport
On Wed, 7 Oct 2020 13:15:23 -0700 Felix Lechner wrote: > Control: tags -1 + patch > > Hi, > > > Is this because of a ghostscript vulnerability? > > The PDF policy restriction is also in effect on Debian stable even > though that release ships with Ghostscript 9.27, which online sources > suggest is safe. [1] > > Converting images to PDF is a very common functionality. Please > provide a backport with the attached patch, or similar. Thanks! Another package negatively affected with the current restrictions is lyx - see bugs 911236 and 975678. PDF and EPS coders need to be allowed for normal functionality. Pavel
Bug#767072: lyx: default papersize neglect /etc/papersize ?
On Tue, 28 Oct 2014 14:12:48 +0100 SZABO Zsolt wrote: > I am very sorry, but it turned out after inspecting the situation more > precisely, that it is about the geometry package: > when I set margins explicitly then the geometry package is loaded > (of course) and its default papersize is different from the system default > which is overwritten... > > Anyway, I think it is still a (minor) bug, because a simple user who > originally used the default papersize setting and then sets the margins > does not expect that he should also set the papersize explicitly on a > different tab... I do not see that /etc/papersize is respected at all (in buster), not even LaTeX seem to respect it. This might not be trivial to get right. Moving to wishlist Pavel
Bug#915113: lyx: Has problem exporting to Postscript - fails on converting certain images
On Fri, 30 Nov 2018 17:05:58 +0100 Adrian Immanuel Kiess wrote: > currently in Debian/testing LyX fails on exporting to Postscript documents due > to error in exporting or converting certain images (if not all). Is this problem fixed for you now? Otherwise I would like to see the full output of when running postscript build (via View->Messages Pane). You ca ncopy paste the output directly into them email. Thanks, Pavel
Bug#930406: [lyx] lyx crashes on file dialog
On Wed, 12 Jun 2019 08:42:56 +0200 Tomasz Wartalski wrote: > Dear maintainer, > > * What led up to the situation? > > Opening lyx and trying to choose a file, e.g. a template. > > * What exactly did you do (or not do) that was effective (or ineffective)? > Opening a template file (e.g. in German: Datei -> Neu von Vorlage -> > choosing a template, eg. docbook article -> crash) > > * What was the outcome of this action? > lyx crashes > > * What outcome did you expect instead? > lyx should open a (template) file > > The same happens if i try to reconfigure lyx (in german: Werkzeuge -> > Neu konfigurieren). The problem is reproducible as it happens every time > i try to do one of the above. I´m using KDE at a recent debian testing. > > A backtrace is attached below. The backtrace is unfortunately not informative (and won't be unless you try to compile lyx on your own with debuging symbols enabled). I can not reproduce in stable-debian settings, so perhaps it has something to do with running unstable? Can you perhaps try whether it's better with 2.3.6 now? Pavel
Bug#935814: still actual for lyx (version 2.3.3-3) in debian unstable
On Thu, 23 Jan 2020 14:36:35 +0700 A L wrote: > Dear Maintainer, > this bug is still actual in lyx (version 2.3.3-3) in debian unstable This problem with non-ASCII paths should be fixed in 2.3.5. Can you give it a try in unstable? The lyx bug in question is here: https://www.lyx.org/trac/ticket/11146 Note however that some folks still report problems so we need more feedback on this: https://www.lyx.org/trac/ticket/11940 Note that in this bug underlying LaTeX version matters, so please report it together with lyx version. Thanks, Pavel
Bug#918504: lyx: `lyx --export latex ` outputs loads of errors [patch attached]
On Sun, 06 Jan 2019 20:52:44 +0100 Georges Khaznadar wrote: > > lyx --export latex someFile.lyx outputs loads of errors, with this pattern: > > Traceback (most recent call last): > File "/usr/share/lyx/scripts/convertDefault.py", line 38, in > output = output.decode() > AttributeError: 'str' object has no attribute 'decode' This should be fixed since lyx 2.3.3. Pavel
Bug#816173: [Pkg-lyx-devel] Bug#816173: Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist
On Tue, 1 Mar 2016 10:40:49 +0100 Sven Hoexter wrote: > If not abort with an error message pointing > to the -userdir option. I think using the -userdir option is also the > way to go if you use lyx during build time in minimal build environments > like sbuild chroots. Agreed. I added hint for -userdir option in the error message. This will be fixed with lyx 2.4. Pavel
Bug#758875: Still wrongly named/typo
On Wed, 18 Mar 2015 12:28:30 +0100 Alexander Stiebing wrote: > The problem reported as "first" (and as "moreover"): > Confirmed that the menu entry is wrongly given in 'it/splash.lyx', but > it should by now be called 'Documento>Mostra (altri formati)>DVI', not > like the proposed string out of the bug report Reportedly this is fixed in 2.3. > > The problem reported as "third": > the reported typo is still in 'it/splash.lyx' This has been fixed now and will be part of lyx 2.3.7 & 2.4. Pavel
Bug#879602: [lyx] Broken svn auto-detecion
On Mon, 23 Oct 2017 12:14:41 +0200 Philipp Klaus Krause wrote: > lyx tries to autodetect if a file is under verison control. When lyx > 2.2.3 reads an input file, it recursively checks parent directories for > .svn, .git, etc. > > In case it find a .svn directory, it invokes svn info to parse the > output to see if the file is under version control. For svn, the code is > in SVN::findFile in lines 1154ff of src/VCBackend.cpp. > > However, there is a bug in checking if a file is in svn. If the file is > in a directory that is not under svn, but a parent directory is under > svn, lyx will invoke svn info. Since the directory itself is not under > svn, svn info will fail "svn: E155007: > '/home/philipp/sdcc-2/build/doc/sdccman.lyx' is not a working copy"; lyx > considers this an error. Looks like correct analysis. > This issue makes out-of-tree builds fail. Example: the sdcc manual is a > .lyx file. When checking out sdcc from svn, and then trying to do an > out-of-tree build in a directory build, it fails due to this bug. Despite the warning from svn info, lyx normally loads up the file, exports it etc. So I do not follow what "out-of-tree builds fail" exactly means or what kind of problem you actually encounter. Pavel
Bug#457232: [Pkg-lyx-devel] Bug#457232: lyx: Fails to fully parse document for display.
On Thu, 20 Dec 2007 23:06:26 +0100 Sven Hoexter wrote: > forwarded 457232 http://bugzilla.lyx.org/show_bug.cgi?id=449 > tags 457232 upstream > thanks > > Hi Nick, > it doesn't look like it's easy to fix. The problem is already reported > upstream so I'd suggest you read the comments on the report upstream > to maybe find a solution that fits your needs. > http://bugzilla.lyx.org/show_bug.cgi?id=449 Should be fixed in lyx 2.4.0. Pavel
Bug#786698: lyx: No mandatory rcs check-in before closing Lyx
On Sun, 24 May 2015 16:03:54 +0200 Martin Haase wrote: > I just realized that it is possible to exit from the program without > prior checking in the changes to a document. I find this rather peculiar, > and I don't think it should happen this way. Lyx should keep "in mind" > whether a document has been registered with rcs and change its exit > behaviour accordingly. I don't find it peculiar, but YMMV. In any case this is wishlist and unlikely to be solved on Debian BTS. Filing bug at LyX bugtracker might help thought I don't see it likely. Pavel
Bug#362052: [t...@lyx.org: Re: #4370: Please implement a check-in and re-checkout in one step menu item]
On Tue, 2 Nov 2010 20:59:57 +0100 Sven Hoexter wrote: > Status update ... The second reported issue is fixed since lyx 1.6, the first one is wontfix for 12 years already. As such I would close this bug. Pavel
Bug#730111: Still present in 2.1.3-1
On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing wrote: > Bug still like described in Nov. 2013, none of the proposed actions out > of the comments have been done. The change of the message to be more informative will be fixed in lyx 2.3.7 & 2.4. https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit Moving RCS from suggested to Recommends look reasonable to me. After that the bug can be closed. Pavel
Bug#597676: Export options vanish every other time
On Wed, 6 Oct 2010 11:55:24 +1000 Brendon Higgins wrote: > (Original reporter here.) I just tried with a clean ~/.lyx, and things seem > to > behave themselves. So there's something in my .lyx that lyx does not like. It > turns out that it's certainly my preferences file. I narrowed it down after > comparing the two folders recursively and moving things to the clean .lyx one > by one. > > I had a look at the settings for these formats, and noticed that "Document > Format" is not ticked for them. If I change that for, say, "PDF (pdflatex)" > so > that it is ticked, then that particular option shows up in the Export menu > all > the time, as you ought to expect. > > Before anyone shouts PEBKAC, while I did change the viewer application option > (as you can tell), I don't believe I would have been silly enough to change > that tick mark. I reckon, somehow, that property must have been either > unchecked or not set by default properly when this property was introduced in > an earlier version. (I've been using lyx on this machine since 2006, and > would > have had similar settings, using kghostview rather than okular.) There are two ways how this could have happened 1) either user somehow unknowingly deselected that option or played manually with the preferences file 2) something weird happened while lyx converted the pref file from lyx 1.5 -> lyx 1.6. Anyway even if 2) is true (and I dont remember similar problem reports) we are today at >= 2.1 versions where ->1.6 conversions are irrelevant. As such we can close this bug. Pavel
Bug#524332: lyx: No toolbox in LyX's window
On Thu, 16 Apr 2009 12:18:09 +0200 Renaud Lacour wrote: > LyX's toolboxes are hidden and can't be displayed by the related menu > items. I can see a small piece of one toolbox on startup, which most > part seems to be hidden behind the menu bar. After loading a document, > there is no toolbox at all. > Clearing .lyx directory didn't help. It happened recently and *may* be > related to xorg's recent upgrade. This problem appears if Qt settings in .config/LyX/ get corrupted for whatever reason. There is very little you can do to programatically restore such corrupted files expcept manually delete them. I think this bug should be closed as wontfix. Pavel
Bug#507045: [Pkg-lyx-devel] Bug#507045: lyx: Several standard document classes not available
On Thu, 27 Nov 2008 20:49:51 -0800 "Marc J. Driftmeyer" wrote: > Better yet, provide a help document declaring the missing styles and > classes that aren't available under Debian; and then reference how to > install them locally to add those classes that don't comply with > Debian's strict licensing policy. That way it allows folks unfamiliar > with /usr/local/share/texmf/ how that works with the Debian mktexlsr > approach to updating local and global classes. I believe this is daunting task. Templates can (dis)appear even across minor lyx versions and tracking all this would be very time consuming and would have minor impact except of few niche users. In a decade no one volunteer to maintain such document and I don't see this will change. Non-debian specific document showing you which lyx related classes were detected on your system is always to be found in Help->LaTeX Configuration. The report 45 is a different bug already solved by clean up the cache. All in all I think this bug should be closed. Pavel
Bug#858535: lyx: Does not display ooint symbol
On Thu, 23 Mar 2017 08:44:47 +0100 "g.gragnani" wrote: > at my site the math symbol \oiint is no longer displayed when using the > math editor. Is is however inserted in the tex source code, but not > seeing it makes the program prone to typing errors. This is known bug, which I fixed for LyX 2.4, cf https://www.lyx.org/trac/ticket/8493 Pavel
Bug#911236: LyX: Error converting images
On Wed, 17 Oct 2018 15:44:23 +0200 Adrian Immanuel Kiess wrote: >* What exactly did you do (or not do) that was effective (or > ineffective)? > apt-get -u dist-upgrade >* What was the outcome of this action? > LyX has problems converting images This could be consequence of strict imagemagick policies, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975678 Does allowing pdf coders in /etc/ImageMagick-6/policy.xml helps your situation? Pavel
Bug#831839: Your mail
On Thu, 28 Dec 2017 13:02:44 +0100 Jean-Marc Lasgouttes wrote: > Is the situation better with LyX 2.2.3? There have been some changes in > to improve performance. Meantime there were multiple performance fixes committed and since we did not receive any feedback from the reporter I would close this bug. Pavel
Bug#975678: lyx: Strict imagemagick policies render LyX unusable when working with vector graphics
Package: lyx Version: 2.3.2-1 Severity: important Dear package maintainer(s), we (LyX developers) are getting repeated reports of LyX's broken handling of pdf/postscript graphics rendering (LaTeX export works fine). This is because of debian stringent policy in /etc/ImageMagick-6/policy.xml disabling ghostscript handling. This was likely introduced due to ghostcript vulnerabilities couple years back, which are fixed now, but the fear of new potential vulnerabilities probably caused the ongoing ban of ghostcript. While I understand the possible security implications on servers, the current policy renders LyX unusable for anyone on desktop, who wishes to use eps/pdf vector graphics, which is typical graphics input format in LaTeX world. On top of this, if user is not root as well, he can't even override these policies. This puts us in a weird position, that we can't help some users even when we detect why their documents do not compile anymore. Would you be willing to make some compromise on systems where users install LyX? I can imagine different ways, e.g.: - allow eps/pdf coders when LyX is installed - ask user when installing LyX whether he wants to to allow such coders - or at least issue warning that unless admin tweaks policy.xml LyX won't function properly. Or any other approach which would help to solve this issue. I see that the imagemagick policy patch in question is in buster but not in bullseye. Not sure whether it means debian wants to keep future imagemagick policies in their vanilla form or it was moved to debconf. In any case I would like raise our voice about this problem explicitely. While this bug is sort of generalized version of #971630 (we also want eps format to work) and might not be high priority from imagemagick POV (could be considered a corner case), I file this under LyX as the consequences are way more serious for its functionality. Thanks, Pavel -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=en_US.UTF-8 (charmap=ISO-8859-2) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lyx depends on: ii libc62.28-10 ii libenchant1c2a 1.6.0-11.1+b1 ii libgcc1 1:8.3.0-6 ii libmagic11:5.35-4+deb10u1 ii libmythes-1.2-0 2:1.2.4-3 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5gui5 5.11.3+dfsg1-1+deb10u4 ii libqt5svg5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u4 ii libstdc++6 8.3.0-6 ii lyx-common 2.3.2-1 ii xdg-utils1.1.3-1+deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages lyx recommends: ii dvipng 1.15-1.1 ii evince [pdf-viewer] 3.30.2-3+deb10u1 ii fonts-lyx2.3.2-1 ii ghostscript 9.27~dfsg-2+deb10u4 ii gv [pdf-viewer] 1:3.7.4-2 ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii poppler-utils0.71.0-5 ii preview-latex-style 11.91-2 ii psutils 1.17.dfsg-4 ii texlive-fonts-recommended2018.20190227-2 ii texlive-generic-extra2018.20190227-2 ii texlive-generic-recommended 2018.20190227-2 ii texlive-latex-extra 2018.20190227-2 ii texlive-latex-recommended2018.20190227-2 ii texlive-science 2018.20190227-2 ii xpdf [pdf-viewer]3.04-13 Versions of packages lyx suggests: pn chktex pn gnuhtml2latex pn groff ii inkscape0.92.4-3 pn latex2rtf ii librsvg2-bin2.44.10-2.1 pn libtiff-tools pn linuxdoc-tools pn noweb ii rcs 5.9.4-5 pn sgmltools-lite ii texlive-plain-generic [tex4ht] 2018.20190227-2 pn texlive-xetex pn writer2latex pn wv -- no debconf information
Bug#902141: gv: Mimetype application/postscript missing
Package: gv Version: 1:3.7.4-1+b1 Severity: normal Hi, gv is not listed as an postscript viewer option in mime-based dialogs (in this case in firefox). It seems that debian system internaly uses application/postscript for postscript files but gv offers only line MimeType=application/ps;application/pdf; in /usr/share/applications/gv.desktop Thus gv is rejected in default listing of viewers (I guess in many applications) and adding application/postscript to the MimeType line could fix it. Cheers, Pavel -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=en_US:en (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gv depends on: ii ghostscript-x 9.20~dfsg-3.2+deb9u1 ii libc6 2.24-11+deb9u3 ii libx11-6 2:1.6.4-3 ii libxinerama1 2:1.1.3-1+b3 ii libxmu62:1.1.2-2 ii libxt6 1:1.1.5-1 ii xaw3dg 1.5+E-18.2 Versions of packages gv recommends: ii xaw3dg 1.5+E-18.2 gv suggests no packages. -- no debconf information
