Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
On Mon, Nov 12, 2018 at 03:09:13PM +0100, Pavel Sanda wrote: > The security problems of ghostscript which caused the policy restrictions > were > fixed with the release of ghostscript 9.25 (released 2018-09-13). > I quickly looked at ubuntu packages and 18.04 already ships 9.25, so > it would be worth filing bug in ubuntu bug system to drop their > imagemagick policy fix otherwise postscript conversion stops working > forever in ubuntu. Agreed. When I did the above, it was while ghostscript still had the issue. Jeff, did you try an apt-get update? Scott signature.asc Description: PGP signature
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
On Sat, Nov 10, 2018 at 02:32:19PM -0500, Scott Kostyshak wrote: > On Sat, Nov 10, 2018 at 02:14:58PM -0500, Paul A. Rubin wrote: > > On 11/5/18 2:32 PM, Jeff Defoe wrote: > > > I realized I was using the Lyx from the Ubuntu repository. When I > > > removed it, added the PPA, and installed LyX from that -- it now seems > > > to work. > > > > > > I do, however, have an odd problem where graphics often don't display in > > > LyX, giving errors such as "error loading file into memory" or "error > > > converting to loadable format" which I didn't get before upgrading to > > > Ubuntu 18.04. > > > > > > Best regards, > > > > > > Jeff > > > > > > > > One possibility has to do with Imagemagick. I recently opened an old LyX > > file with some EPS graphics, and got the "error converting" message on all > > of them. In Tools > Preferences... > File Handling > Converters, the > > converter for EPS to PNG is correctly configured to use the Imagemagick > > convert command. The catch is that recent versions of Imagemagick apparently > > ship with seriously anal retentive permissions by default. If you run > > "convert something.eps something.png" in a terminal, you get an error saying > > something about not being allowed access. > > > > The fix is to open /etc/Imagemagick-6/policy.xml in an editor, using root > > privileges, and comment out the line " > pattern="EPS" />". I also commented out the equivalent lines for PS, PDF and > > XPS just to be safe. After that, LyX was able to display the EPS images. > > I had to do something similar on Ubuntu 18.04 in order to convert PDF > files. The following was helpful: > > https://stackoverflow.com/questions/42928765/convertnot-authorized--erro The security problems of ghostscript which caused the policy restrictions were fixed with the release of ghostscript 9.25 (released 2018-09-13). I quickly looked at ubuntu packages and 18.04 already ships 9.25, so it would be worth filing bug in ubuntu bug system to drop their imagemagick policy fix otherwise postscript conversion stops working forever in ubuntu. Pavel
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
On Sat, Nov 10, 2018 at 02:14:58PM -0500, Paul A. Rubin wrote: > On 11/5/18 2:32 PM, Jeff Defoe wrote: > > I realized I was using the Lyx from the Ubuntu repository. When I > > removed it, added the PPA, and installed LyX from that -- it now seems > > to work. > > > > I do, however, have an odd problem where graphics often don't display in > > LyX, giving errors such as "error loading file into memory" or "error > > converting to loadable format" which I didn't get before upgrading to > > Ubuntu 18.04. > > > > Best regards, > > > > Jeff > > > > > One possibility has to do with Imagemagick. I recently opened an old LyX > file with some EPS graphics, and got the "error converting" message on all > of them. In Tools > Preferences... > File Handling > Converters, the > converter for EPS to PNG is correctly configured to use the Imagemagick > convert command. The catch is that recent versions of Imagemagick apparently > ship with seriously anal retentive permissions by default. If you run > "convert something.eps something.png" in a terminal, you get an error saying > something about not being allowed access. > > The fix is to open /etc/Imagemagick-6/policy.xml in an editor, using root > privileges, and comment out the line " pattern="EPS" />". I also commented out the equivalent lines for PS, PDF and > XPS just to be safe. After that, LyX was able to display the EPS images. I had to do something similar on Ubuntu 18.04 in order to convert PDF files. The following was helpful: https://stackoverflow.com/questions/42928765/convertnot-authorized--erro Scott signature.asc Description: PGP signature
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
On 11/5/18 2:32 PM, Jeff Defoe wrote: I realized I was using the Lyx from the Ubuntu repository. When I removed it, added the PPA, and installed LyX from that -- it now seems to work. I do, however, have an odd problem where graphics often don't display in LyX, giving errors such as "error loading file into memory" or "error converting to loadable format" which I didn't get before upgrading to Ubuntu 18.04. Best regards, Jeff One possibility has to do with Imagemagick. I recently opened an old LyX file with some EPS graphics, and got the "error converting" message on all of them. In Tools > Preferences... > File Handling > Converters, the converter for EPS to PNG is correctly configured to use the Imagemagick convert command. The catch is that recent versions of Imagemagick apparently ship with seriously anal retentive permissions by default. If you run "convert something.eps something.png" in a terminal, you get an error saying something about not being allowed access. The fix is to open /etc/Imagemagick-6/policy.xml in an editor, using root privileges, and comment out the line "rights="none" pattern="EPS" />". I also commented out the equivalent lines for PS, PDF and XPS just to be safe. After that, LyX was able to display the EPS images. Paul
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
I realized I was using the Lyx from the Ubuntu repository. When I removed it, added the PPA, and installed LyX from that -- it now seems to work. I do, however, have an odd problem where graphics often don't display in LyX, giving errors such as "error loading file into memory" or "error converting to loadable format" which I didn't get before upgrading to Ubuntu 18.04. Best regards, Jeff On Sat, Nov 3, 2018 at 1:23 PM Liviu Andronic wrote: > On 11/2/18, Richard Kimberly Heck wrote: > > Unfortunately, without debug symbols, the backtrace is unreadable. I > > don't know if there is an Ubuntu package that would allow you to install > > them. > > If the OP is using the LyX PPA, try to install the lyx-dbg package, > which should give the debugging symbols for LyX. > > Liviu > > > > But you could also try compiling from source with --enable-debug. > > > > Riki > > > > > > On 11/1/18 9:20 PM, Jeff Defoe wrote: > >> ( 1) lyx: lyx() [0x8de95d] > >> ( 2) lyx: lyx() [0x8b] > >> ( 3) lyx: lyx() [0x5a13dc] > >> ( 4) /lib/x86_64-linux-gnu/libc.so.6: > >> /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20] > >> ( 5) lyx: lyx() [0x902e5d] > >> ( 6) lyx: lyx() [0x90164c] > >> ( 7) lyx: lyx() [0x90b451] > >> ( 8) lyx: lyx() [0x6e9d1b] > >> ( 9) lyx: lyx() [0x6eba5b] > >> ( 10) lyx: lyx() [0x661239] > >> ( 11) lyx: lyx() [0x661932] > >> ( 12) lyx: lyx() [0x8b7b22] > >> ( 13) lyx: lyx() [0x7e899f] > >> ( 14) lyx: lyx() [0x6eb595] > >> ( 15) lyx: lyx() [0x6eba16] > >> ( 16) lyx: lyx() [0x661239] > >> ( 17) lyx: lyx() [0x661932] > >> ( 18) lyx: lyx() [0x6adf43] > >> ( 19) lyx: lyx() [0x93e374] > >> ( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > >> ( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*) > >> ( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, > QEvent*) > >> ( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplicationPrivate::notify_helper(QObject*, QEvent*) > >> ( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplication::notify(QObject*, QEvent*) > >> ( 25) lyx: lyx() [0x8f134c] > >> ( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplication::notifyInternal(QObject*, QEvent*) > >> ( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint > >> const&, int, QPainter*, QWidgetBackingStore*) > >> ( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8] > >> ( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QWidgetPrivate::syncBackingStore() > >> ( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > >> ( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QMainWindow::event(QEvent*) > >> ( 32) lyx: lyx() [0x92d70d] > >> ( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplicationPrivate::notify_helper(QObject*, QEvent*) > >> ( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplication::notify(QObject*, QEvent*) > >> ( 35) lyx: lyx() [0x8f134c] > >> ( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplication::notifyInternal(QObject*, QEvent*) > >> ( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) > >> ( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e] > >> ( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7) > >> [0x7f83f85ee287] > >> ( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0] > >> ( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) > >> [0x7f83f85ee54c] > >> ( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> > QEventDispatcherGlib::processEvents(QFlags) > >> ( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666] > >> ( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QEventLoop::processEvents(QFlags) > >> ( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QEventLoop::exec(QFlags) > >> ( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec() > >> ( 47) lyx: lyx() [0x5aa17d] > >> ( 48) lyx: lyx() [0x43d5ad] > >> ( 49) /lib/x86_64-linux-gnu/libc.so.6: > >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97] > >> ( 50) lyx: lyx() [0x449539] > >> > > > > >
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
On 11/2/18, Richard Kimberly Heck wrote: > Unfortunately, without debug symbols, the backtrace is unreadable. I > don't know if there is an Ubuntu package that would allow you to install > them. If the OP is using the LyX PPA, try to install the lyx-dbg package, which should give the debugging symbols for LyX. Liviu > But you could also try compiling from source with --enable-debug. > > Riki > > > On 11/1/18 9:20 PM, Jeff Defoe wrote: >> ( 1) lyx: lyx() [0x8de95d] >> ( 2) lyx: lyx() [0x8b] >> ( 3) lyx: lyx() [0x5a13dc] >> ( 4) /lib/x86_64-linux-gnu/libc.so.6: >> /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20] >> ( 5) lyx: lyx() [0x902e5d] >> ( 6) lyx: lyx() [0x90164c] >> ( 7) lyx: lyx() [0x90b451] >> ( 8) lyx: lyx() [0x6e9d1b] >> ( 9) lyx: lyx() [0x6eba5b] >> ( 10) lyx: lyx() [0x661239] >> ( 11) lyx: lyx() [0x661932] >> ( 12) lyx: lyx() [0x8b7b22] >> ( 13) lyx: lyx() [0x7e899f] >> ( 14) lyx: lyx() [0x6eb595] >> ( 15) lyx: lyx() [0x6eba16] >> ( 16) lyx: lyx() [0x661239] >> ( 17) lyx: lyx() [0x661932] >> ( 18) lyx: lyx() [0x6adf43] >> ( 19) lyx: lyx() [0x93e374] >> ( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) >> ( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*) >> ( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) >> ( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QApplicationPrivate::notify_helper(QObject*, QEvent*) >> ( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QApplication::notify(QObject*, QEvent*) >> ( 25) lyx: lyx() [0x8f134c] >> ( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QCoreApplication::notifyInternal(QObject*, QEvent*) >> ( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint >> const&, int, QPainter*, QWidgetBackingStore*) >> ( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8] >> ( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QWidgetPrivate::syncBackingStore() >> ( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) >> ( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QMainWindow::event(QEvent*) >> ( 32) lyx: lyx() [0x92d70d] >> ( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QApplicationPrivate::notify_helper(QObject*, QEvent*) >> ( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> QApplication::notify(QObject*, QEvent*) >> ( 35) lyx: lyx() [0x8f134c] >> ( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QCoreApplication::notifyInternal(QObject*, QEvent*) >> ( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) >> ( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e] >> ( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: >> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7) >> [0x7f83f85ee287] >> ( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: >> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0] >> ( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: >> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) >> [0x7f83f85ee54c] >> ( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QEventDispatcherGlib::processEvents(QFlags) >> ( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666] >> ( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QEventLoop::processEvents(QFlags) >> ( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: >> QEventLoop::exec(QFlags) >> ( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec() >> ( 47) lyx: lyx() [0x5aa17d] >> ( 48) lyx: lyx() [0x43d5ad] >> ( 49) /lib/x86_64-linux-gnu/libc.so.6: >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97] >> ( 50) lyx: lyx() [0x449539] >> > >
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
Can you describe better what triggers this bug? Unfortunately, without debug symbols, the backtrace is unreadable. I don't know if there is an Ubuntu package that would allow you to install them. But you could also try compiling from source with --enable-debug. Riki On 11/1/18 9:20 PM, Jeff Defoe wrote: > ( 1) lyx: lyx() [0x8de95d] > ( 2) lyx: lyx() [0x8b] > ( 3) lyx: lyx() [0x5a13dc] > ( 4) /lib/x86_64-linux-gnu/libc.so.6: > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20] > ( 5) lyx: lyx() [0x902e5d] > ( 6) lyx: lyx() [0x90164c] > ( 7) lyx: lyx() [0x90b451] > ( 8) lyx: lyx() [0x6e9d1b] > ( 9) lyx: lyx() [0x6eba5b] > ( 10) lyx: lyx() [0x661239] > ( 11) lyx: lyx() [0x661932] > ( 12) lyx: lyx() [0x8b7b22] > ( 13) lyx: lyx() [0x7e899f] > ( 14) lyx: lyx() [0x6eb595] > ( 15) lyx: lyx() [0x6eba16] > ( 16) lyx: lyx() [0x661239] > ( 17) lyx: lyx() [0x661932] > ( 18) lyx: lyx() [0x6adf43] > ( 19) lyx: lyx() [0x93e374] > ( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > ( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*) > ( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) > ( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QApplicationPrivate::notify_helper(QObject*, QEvent*) > ( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QApplication::notify(QObject*, QEvent*) > ( 25) lyx: lyx() [0x8f134c] > ( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QCoreApplication::notifyInternal(QObject*, QEvent*) > ( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint > const&, int, QPainter*, QWidgetBackingStore*) > ( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8] > ( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QWidgetPrivate::syncBackingStore() > ( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > ( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QMainWindow::event(QEvent*) > ( 32) lyx: lyx() [0x92d70d] > ( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QApplicationPrivate::notify_helper(QObject*, QEvent*) > ( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > QApplication::notify(QObject*, QEvent*) > ( 35) lyx: lyx() [0x8f134c] > ( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QCoreApplication::notifyInternal(QObject*, QEvent*) > ( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) > ( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e] > ( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7) > [0x7f83f85ee287] > ( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0] > ( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) > [0x7f83f85ee54c] > ( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QEventDispatcherGlib::processEvents(QFlags) > ( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666] > ( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QEventLoop::processEvents(QFlags) > ( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > QEventLoop::exec(QFlags) > ( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec() > ( 47) lyx: lyx() [0x5aa17d] > ( 48) lyx: lyx() [0x43d5ad] > ( 49) /lib/x86_64-linux-gnu/libc.so.6: > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97] > ( 50) lyx: lyx() [0x449539] >
LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
( 1) lyx: lyx() [0x8de95d] ( 2) lyx: lyx() [0x8b] ( 3) lyx: lyx() [0x5a13dc] ( 4) /lib/x86_64-linux-gnu/libc.so.6: /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20] ( 5) lyx: lyx() [0x902e5d] ( 6) lyx: lyx() [0x90164c] ( 7) lyx: lyx() [0x90b451] ( 8) lyx: lyx() [0x6e9d1b] ( 9) lyx: lyx() [0x6eba5b] ( 10) lyx: lyx() [0x661239] ( 11) lyx: lyx() [0x661932] ( 12) lyx: lyx() [0x8b7b22] ( 13) lyx: lyx() [0x7e899f] ( 14) lyx: lyx() [0x6eb595] ( 15) lyx: lyx() [0x6eba16] ( 16) lyx: lyx() [0x661239] ( 17) lyx: lyx() [0x661932] ( 18) lyx: lyx() [0x6adf43] ( 19) lyx: lyx() [0x93e374] ( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) ( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*) ( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, QEvent*) ( 25) lyx: lyx() [0x8f134c] ( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::notifyInternal(QObject*, QEvent*) ( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8] ( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidgetPrivate::syncBackingStore() ( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) ( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QMainWindow::event(QEvent*) ( 32) lyx: lyx() [0x92d70d] ( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, QEvent*) ( 35) lyx: lyx() [0x8f134c] ( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::notifyInternal(QObject*, QEvent*) ( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e] ( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7) [0x7f83f85ee287] ( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0] ( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f83f85ee54c] ( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QEventDispatcherGlib::processEvents(QFlags) ( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666] ( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QEventLoop::processEvents(QFlags) ( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QEventLoop::exec(QFlags) ( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec() ( 47) lyx: lyx() [0x5aa17d] ( 48) lyx: lyx() [0x43d5ad] ( 49) /lib/x86_64-linux-gnu/libc.so.6: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97] ( 50) lyx: lyx() [0x449539]
Re: Strange screen problem in LyX Version 2.3.1-1
Hello again, Closing all open buffers and reopening a new document has corrected this issue, but if I can help you to find the source of this bug, I would be happy to do it. I use LyX under OSX 10.13.6 Le sam. 27 oct. 2018 à 17:14, Murat Yildizoglu < murat.yildizo...@u-bordeaux.fr> a écrit : > Hello, > I am puzzled by a problem I get in Lyx now. > I have just closed the outline panel and Lyx screen became very weird (see > the screenshot), and I cannot find how I can reset it to its normal > appearance with the documents bar on the top of the editing panel and the > Lyx screen fully usable. Any idea what is going on. > Closing and reopening Lyx does not solve the problem. > > After the first appearance of this problem I have got a SIGSEV: > > ( 1) 1 lyx 0x00010757bd7f > _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > : 1 lyx 0x00010757bd7f > _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > + 190 > ( 2) 2 lyx 0x00010757c2b5 > _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > : 2 lyx 0x00010757c2b5 > _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > + 149 > ( 3) 3 lyx 0x000107312e2b > _ZN3lyx13error_handlerEi : 3 lyx > 0x000107312e2b _ZN3lyx13error_handlerEi + 506 > ( 4) 4 libsystem_platform.dylib0x7fff6970cf5a _sigtramp > : 4 libsystem_platform.dylib0x7fff6970cf5a _sigtramp + 26 > ( 5) 5 lyx 0x000107e91f7f > LinkBackServers : 5 lyx > 0x000107e91f7f LinkBackServers + 314679 > ( 6) 6 QtWidgets 0x000108cc6fba > _ZN15QDockAreaLayout20deleteAllLayoutItemsEv : 6 QtWidgets > 0x000108cc6fba _ZN15QDockAreaLayout20deleteAllLayoutItemsEv > + 42 > ( 7) 7 QtWidgets 0x000108cf3d74 > _ZN17QMainWindowLayoutD2Ev : 7 QtWidgets > 0x000108cf3d74 _ZN17QMainWindowLayoutD2Ev + 52 > ( 8) 8 QtWidgets 0x000108cf3fde > _ZN17QMainWindowLayoutD0Ev : 8 QtWidgets > 0x000108cf3fde _ZN17QMainWindowLayoutD0Ev + 14 > ( 9) 9 QtWidgets 0x000108badaee > _ZN7QWidgetD2Ev : 9 QtWidgets > 0x000108badaee _ZN7QWidgetD2Ev + 414 > ( 10) 10 lyx 0x000107723de2 > _ZN3lyx8frontend7GuiViewD0Ev : 10 lyx > 0x000107723de2 _ZN3lyx8frontend7GuiViewD0Ev + 14 > ( 11) 11 QtCore 0x00010872b050 > _ZN7QObject5eventEP6QEvent : 11 QtCore > 0x00010872b050 _ZN7QObject5eventEP6QEvent + 128 > ( 12) 12 QtWidgets 0x000108bc054b > _ZN7QWidget5eventEP6QEvent : 12 QtWidgets > 0x000108bc054b _ZN7QWidget5eventEP6QEvent + 5787 > ( 13) 13 QtWidgets 0x000108ceaee5 > _ZN11QMainWindow5eventEP6QEvent : 13 QtWidgets > 0x000108ceaee5 _ZN11QMainWindow5eventEP6QEvent + 1733 > ( 14) 14 lyx 0x00010772828d > _ZN3lyx8frontend7GuiView5eventEP6QEvent : 14 lyx > 0x00010772828d _ZN3lyx8frontend7GuiView5eventEP6QEvent + 249 > ( 15) 15 QtWidgets 0x000108b85b2d > _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent : 15 QtWidgets > 0x000108b85b2d > _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent + 301 > ( 16) 16 QtWidgets 0x000108b86ea7 > _ZN12QApplication6notifyEP7QObjectP6QEvent : 16 QtWidgets > 0x000108b86ea7 _ZN12QApplication6notifyEP7QObjectP6QEvent + > 391 > ( 17) 17 lyx 0x00010758c3e0 > _ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent : 17 lyx > 0x00010758c3e0 > _ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent + 22 > ( 18) 18 QtCore 0x000108701414 > _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent : 18 QtCore >0x000108701414 > _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent + 164 > ( 19) 19 QtCore 0x00010870259b > _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData : > 19 QtCore 0x00010870259b > _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData + > 891 > ( 20) 20 QtCore 0x000108701b2d > _ZN16QCoreApplication4execEv : 20 QtCore > 0x000108701b2d _ZN16QCoreApplication4execEv + 509 > ( 21) 21 lyx 0x00010730e65c > _ZN3lyx3LyX4execERiPPc : 21 lyx > 0x00010730e65c _ZN3lyx3LyX4execER
Re: Strange screen problem in LyX Version 2.3.1-1
On 27/10/2018 17:14, Murat Yildizoglu wrote: Hello, I am puzzled by a problem I get in Lyx now. I have just closed the outline panel and Lyx screen became very weird (see the screenshot), and I cannot find how I can reset it to its normal appearance with the documents bar on the top of the editing panel and the Lyx screen fully usable. Any idea what is going on. Closing and reopening Lyx does not solve the problem. After the first appearance of this problem I have got a SIGSEV: ( 1) 1 lyx 0x00010757bd7f _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b : 1 lyx 0x00010757bd7f _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b + 190 ( 2) 2 lyx 0x00010757c2b5 _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b : 2 lyx 0x00010757c2b5 _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b + 149 ( 3) 3 lyx 0x000107312e2b _ZN3lyx13error_handlerEi : 3 lyx 0x000107312e2b _ZN3lyx13error_handlerEi + 506 ( 4) 4 libsystem_platform.dylib 0x7fff6970cf5a _sigtramp : 4 libsystem_platform.dylib 0x7fff6970cf5a _sigtramp + 26 ( 5) 5 lyx 0x000107e91f7f LinkBackServers : 5 lyx 0x000107e91f7f LinkBackServers + 314679 ( 6) 6 QtWidgets 0x000108cc6fba _ZN15QDockAreaLayout20deleteAllLayoutItemsEv : 6 QtWidgets 0x000108cc6fba _ZN15QDockAreaLayout20deleteAllLayoutItemsEv + 42 ( 7) 7 QtWidgets 0x000108cf3d74 _ZN17QMainWindowLayoutD2Ev : 7 QtWidgets 0x000108cf3d74 _ZN17QMainWindowLayoutD2Ev + 52 ( 8) 8 QtWidgets 0x000108cf3fde _ZN17QMainWindowLayoutD0Ev : 8 QtWidgets 0x000108cf3fde _ZN17QMainWindowLayoutD0Ev + 14 ( 9) 9 QtWidgets 0x000108badaee _ZN7QWidgetD2Ev : 9 QtWidgets 0x000108badaee _ZN7QWidgetD2Ev + 414 ( 10) 10 lyx 0x000107723de2 _ZN3lyx8frontend7GuiViewD0Ev : 10 lyx 0x000107723de2 _ZN3lyx8frontend7GuiViewD0Ev + 14 ( 11) 11 QtCore 0x00010872b050 _ZN7QObject5eventEP6QEvent : 11 QtCore 0x00010872b050 _ZN7QObject5eventEP6QEvent + 128 ( 12) 12 QtWidgets 0x000108bc054b _ZN7QWidget5eventEP6QEvent : 12 QtWidgets 0x000108bc054b _ZN7QWidget5eventEP6QEvent + 5787 ( 13) 13 QtWidgets 0x000108ceaee5 _ZN11QMainWindow5eventEP6QEvent : 13 QtWidgets 0x000108ceaee5 _ZN11QMainWindow5eventEP6QEvent + 1733 ( 14) 14 lyx 0x00010772828d _ZN3lyx8frontend7GuiView5eventEP6QEvent : 14 lyx 0x00010772828d _ZN3lyx8frontend7GuiView5eventEP6QEvent + 249 ( 15) 15 QtWidgets 0x000108b85b2d _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent : 15 QtWidgets 0x000108b85b2d _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent + 301 ( 16) 16 QtWidgets 0x000108b86ea7 _ZN12QApplication6notifyEP7QObjectP6QEvent : 16 QtWidgets 0x000108b86ea7 _ZN12QApplication6notifyEP7QObjectP6QEvent + 391 ( 17) 17 lyx 0x00010758c3e0 _ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent : 17 lyx 0x00010758c3e0 _ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent + 22 ( 18) 18 QtCore 0x000108701414 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent : 18 QtCore 0x000108701414 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent + 164 ( 19) 19 QtCore 0x00010870259b _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData : 19 QtCore 0x00010870259b _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData + 891 ( 20) 20 QtCore 0x000108701b2d _ZN
Re: 2.3.1-1 on Mojave debugging
Stephan that makes sense. In my perl script I use open anyway, and I will look at a function for command line use Thank you again. el Sent from Dr Lisse’s iPad mini 4 On 11 Oct 2018, 07:04 +0200, Stephan Witt , wrote: > Am 10.10.2018 um 23:45 schrieb Dr Eberhard W Lisse : > > > > Stephan, > > > > thank you. > > > > I use lyx from the command line a lot and have symlinked > > /Applications/LyX.app/Contents/MacOS/lyx to /usr/local/bin. Using the > > symlink it crashes, using the full path it works. > > I see. > > > Is it reproducible with the symlink? And if so would that be considered > > a bug? > > See > https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html > > I’d say you shouldn’t use a pure symlink. Create a shell script instead > and set the environment up to prepare the proper functioning. Perhaps > it works for you only by using the wrapper script… The binary cannot > correctly determine the location of the frameworks it should use > if you fool it by your symlink. It’s all about security. > > Stephan
Re: 2.3.1-1 on Mojave debugging
Am 10.10.2018 um 23:45 schrieb Dr Eberhard W Lisse : > > Stephan, > > thank you. > > I use lyx from the command line a lot and have symlinked > /Applications/LyX.app/Contents/MacOS/lyx to /usr/local/bin. Using the > symlink it crashes, using the full path it works. I see. > Is it reproducible with the symlink? And if so would that be considered > a bug? See https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html I’d say you shouldn’t use a pure symlink. Create a shell script instead and set the environment up to prepare the proper functioning. Perhaps it works for you only by using the wrapper script… The binary cannot correctly determine the location of the frameworks it should use if you fool it by your symlink. It’s all about security. Stephan > Just for interest sake, I have written 2000 lines of perl code (and > Pashua) as part of a workflow in my practice which fires up templates > (for example standard prescriptions) modifying variables (such as > patient names and the like). > > While I like to be able to modify manually, most of the time I just like > that window to respond to a "LYXCMD:P2:buffer-view:pdf5" after opening. > > While debugging a small issue with this I noticed the above crash > > greetings, el > > > On 2018-10-10 22:12 , Stephan Witt wrote: > [...] >>> Is this reproducible? >> >> No. You don’t use /Applications/LyX.app/Contents/MacOS/lyx ??? >> >> You may try this: >> DYLD_PRINT_LIBRARIES=1 lyx -dbg lyxserver >> >> to see where the plugin lookup is actually searching. >> >> Stephan >> > > -- > Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) > e...@lisse.na/ * | Telephone: +264 81 124 6733 (cell) > PO Box 8421 / > Bachbrecht, Namibia ;/
Re: 2.3.1-1 on Mojave debugging
Stephan, thank you. I use lyx from the command line a lot and have symlinked /Applications/LyX.app/Contents/MacOS/lyx to /usr/local/bin. Using the symlink it crashes, using the full path it works. Is it reproducible with the symlink? And if so would that be considered a bug? Just for interest sake, I have written 2000 lines of perl code (and Pashua) as part of a workflow in my practice which fires up templates (for example standard prescriptions) modifying variables (such as patient names and the like). While I like to be able to modify manually, most of the time I just like that window to respond to a "LYXCMD:P2:buffer-view:pdf5" after opening. While debugging a small issue with this I noticed the above crash greetings, el On 2018-10-10 22:12 , Stephan Witt wrote: [...] >> Is this reproducible? > > No. You don’t use /Applications/LyX.app/Contents/MacOS/lyx ??? > > You may try this: > DYLD_PRINT_LIBRARIES=1 lyx -dbg lyxserver > > to see where the plugin lookup is actually searching. > > Stephan > -- Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) e...@lisse.na/ * | Telephone: +264 81 124 6733 (cell) PO Box 8421 / Bachbrecht, Namibia ;/
Re: 2.3.1-1 on Mojave debugging
Am 10.10.2018 um 13:24 schrieb Dr Eberhard Lisse : > > Hi, > > I am trying to debug a lyxserver issue but when running > > lyx -dbg lyxserver > > I get > > Setting debug level to lyxserver > Debugging `lyxserver' (External control interface) > This application failed to start because it could not find or load > the Qt platform plugin "cocoa" in "". > > Reinstalling the application may fix this problem. > Abort trap: 6 > > Same effect if I use 'any' or other debug levels. > > The lib is present: > > /Applications/LyX.app//Contents/PlugIns/platforms/libqcocoa.dylib > > Is this reproducible? No. You don’t use /Applications/LyX.app/Contents/MacOS/lyx ??? You may try this: DYLD_PRINT_LIBRARIES=1 lyx -dbg lyxserver to see where the plugin lookup is actually searching. Stephan
Re: LyX Version 2.3.1 not showing bold on screen
> On 7 Oct 2018, at 14:00, Jean-Marc Lasgouttes wrote: > > Le 07/10/2018 à 14:46, Paola Manzini a écrit : >> Hi All, >> using LyX 2.3.1 on a MacBook Pro, Mac OS version 10.14 Mojave: bold fonts do >> not show on screen when editing. The documents does compile correctly. I >> haven’t seen this bug reported, so here I go. I had the same problem on Mac >> OS High Sierra. > > Hello, > > This is tracked at https://www.lyx.org/trac/ticket/11271 > > Since it is a Qt issue, we are not sure of what we an do at our level. > > JMarc Oops, sorry I missed that tracked bug. Thanks for clarifying! Paola
Re: LyX Version 2.3.1 not showing bold on screen
Le 07/10/2018 à 14:46, Paola Manzini a écrit : Hi All, using LyX 2.3.1 on a MacBook Pro, Mac OS version 10.14 Mojave: bold fonts do not show on screen when editing. The documents does compile correctly. I haven’t seen this bug reported, so here I go. I had the same problem on Mac OS High Sierra. Hello, This is tracked at https://www.lyx.org/trac/ticket/11271 Since it is a Qt issue, we are not sure of what we an do at our level. JMarc
LyX Version 2.3.1 not showing bold on screen
Hi All, using LyX 2.3.1 on a MacBook Pro, Mac OS version 10.14 Mojave: bold fonts do not show on screen when editing. The documents does compile correctly. I haven’t seen this bug reported, so here I go. I had the same problem on Mac OS High Sierra. Thanks, Paola
Re: Hopefully....LyX 2.3.1-1
Am Montag, den 01.10.2018, 11:23 -0400 schrieb Richard Kimberly Heck: > I think we decided not to bother with tarballs for this release, as > (a) > it is a very minor update, really, (b) people who want to build it > themselves can check out 2.3.1-1, and (c) most people who would be > inclined to build it are on Linux anyway, and there are no relevant > changes for Linux. So you can just send me links to the binaries. > > If anyone objects to that plan, let me know. I am fine with that. We should allow people to check and verify the source for a given binary (that's why I always objected to patching existing tarballs e.g. for windows installer building). If we have a corresponding git tag, that'll be sufficient. IMHO. Jürgen > > Riki > > signature.asc Description: This is a digitally signed message part
[ANNOUNCE] LyX 2.3.1-1
Public release of LyX version 2.3.1-1
=
We are proud to announce the release of LyX 2.3.1-1. This is an update
to the original release of LyX 2.3.1.
There are three main changes, affecting only Windows and OSX. Linux
users can ignore this release.
For Windows:
- We have fixed bug #11210, which caused a crash after closing the PDF
viewer, and in some other cases. See that bug
https://www.lyx.org/trac/ticket/11210
for info.
- We have renamed the executables as "LyX.exe" and "tex2lyx.exe", rather
than "LyX2.3.exe" and "tex2lyx2.3.exe", in line with previous practice.
For OSX, the only change is a packaging fix. The included version of
tex2lyx was linked incorrectly and, as a result, did not work.
Please see below for information on the original 2.3.1 release.
Public release of LyX version 2.3.1
===
We are proud to announce the release of LyX 2.3.1. This is the first
maintenance release in the 2.3.x series.
You can download LyX 2.3.1 from http://www.lyx.org/Download/.
LyX is a document processor that encourages an approach to writing based
on the structure of your documents and not simply their appearance. It is
released under a Free and Open Source Software license.
LyX 2.3.1 is the result of on-going efforts to make our stable version more
reliable and more stable. We have fixed a number of bugs and added some new
features. Please see below for a full list. Perhaps the most important of
these is that Jean-Marc Lasgouttes re-wrote the document painting
mechanism.
This makes LyX snappier, especially on repeated events.
All python scripts distributed with LyX should now be compatible with both
python 2.x and python 3.x.
One oft-requested enhancement was to restore a keyboard shortcut for opening
the 'settings' menu of graphics, reference, etc, insets. This is now
Control-
Alt-i, on Windows and Linux, and Control-Option-i on OSX (assuming you are
using the default keybindings).
A change to how math macros are output can break some documents that use
ERT to comment out macros. Please see bug #11216 if you experience this
sort
of problem.
If you think you have found a bug in LyX 2.3.1, please open a bug report at
http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it
really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel
lists.lyx.org) and ask.
If you have trouble using LyX or have a question, consult the documentation
that comes with LyX (under the Help or Apple menu) and the LyX wiki, which
is at http://wiki.lyx.org/. If you can't find the answer there, e-mail the
LyX users' list (lyx-users lists.lyx.org), where you will find an
active community of people who are ready to help.
We hope you enjoy using LyX 2.3.1.
The LyX team.
http://www.lyx.org
What's new
==
** Updates:
***
* DOCUMENT INPUT/OUTPUT
- It possible to anonymize document's content for bug submissions
via buffer-anonymize lfun (bug 7259).
- Support rotation of multi-page tables via (pdf)lscape (bug 9194).
- Added LFUN_MASTER_BUFFER_EXPORT, which exports the master buffer, along
the lines of LFUN_MASTER_BUFFER_VIEW (bug 8).
- Needauth is not needed for exporting R code (only when executing the
code).
- Center longtable explicitly for compatibility with some packages (bug
10690).
- Fix problems with default conversion script for graphics (part of bug
11186).
* MISCELLANEOUS
- Updated to Qt5 the LyX server example client in development/lyxserver/
* TEX2LYX IMPROVEMENTS
- Add support for biblatex.
- Add support for chapterbib.
- Add support for \includeonly.
- Add support for beamer overlay arguments (bug 11068).
- Update tex2lyx quotation marks detection:
* Consider new quote styles of LyX 2.3.
* Consider changed quote styles in LYX 2.3.
* Try to be a bit smarter with ambiguous quotation marks,
depending on the main quote style and the local context.
- Consider options passed via \PassOptionsToPackage.
- Add support for URW Classico, MinionPro and the new Libertine fonts.
- Add support for \lstinputlisting and \inputminted.
- Add support for the \t*{} (bottomtiebar) macro of TIPA.
- Implement better parsing of some command options (via "literate"
function of some insets) (bug 9563).
- Add support for alignment pseudo-environments as used inside floats
(bug 7857).
* USER INTERFACE
- Overhaul the document painting mechanism. Now the screen is updated
asyncronously (as all normal applications do), which makes LyX
snappier, especially on repeated events. As an added bonus, subpixel
aliasing is honored in the work area.
- Use native file dialogs on all platforms by default. It is now
possible to switch to LyX custom dialogs (which have extra shortcuts
to relevant directories) by setting the preference
\use_native_filedialog true
- Let caret heigh
Re: Hopefully....LyX 2.3.1-1
On 10/1/18 4:28 AM, Stephan Witt wrote: > Am 30.09.2018 um 19:44 schrieb Richard Kimberly Heck : >> I've pushed it to the main repo. > Ok, thank you! It works for me. > > I’ve tested it with the following steps: > 1. check out 2.3.1-1 > 2. build the dist target > 3. use the LyX-2.3-2.3.1-1.tar.bz2 to build the package > 4. verify the produced binaries > > I can upload the resulting package or wait until you make the official > release and use the published tar-balls. I think we decided not to bother with tarballs for this release, as (a) it is a very minor update, really, (b) people who want to build it themselves can check out 2.3.1-1, and (c) most people who would be inclined to build it are on Linux anyway, and there are no relevant changes for Linux. So you can just send me links to the binaries. If anyone objects to that plan, let me know. Riki
Re: Hopefully....LyX 2.3.1-1
Am 30.09.2018 um 19:44 schrieb Richard Kimberly Heck : > > I've pushed it to the main repo. Ok, thank you! It works for me. I’ve tested it with the following steps: 1. check out 2.3.1-1 2. build the dist target 3. use the LyX-2.3-2.3.1-1.tar.bz2 to build the package 4. verify the produced binaries I can upload the resulting package or wait until you make the official release and use the published tar-balls. Stephan > On 09/30/2018 09:44 AM, Stephan Witt wrote: >> Am 30.09.2018 um 00:06 schrieb Richard Kimberly Heck : >>> I have uploaded a new version of the Windows installer to >>> >>>http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ >>> >>> This SHOULD (and does seem to) use a versioned user directory but NOT >>> have versioned executables. Please test. >>> >>> Stefan: I am pretty sure this will be the final version, but I don't >>> want to tag it until I'm sure. Still, if you want to go ahead and build >>> a new package, then you can check out rgheck/2.3.1-1, which is what I >>> will push as a new tag once I am sure. (It'll be exactly the same code, >>> but of course in the main repo.) The only change that will affect you is >>> the one to configure.ac. The others are Windows only. >>> >>> Riki >> I don’t know how to reach the rgheck/2.3.1-1 branch. >> >> But I can simply wait for your push to the main repo.
Re: Hopefully....LyX 2.3.1-1
On 30/09/2018 8:15 p.m., Daniel wrote: On 30/09/2018 00:06, Richard Kimberly Heck wrote: I have uploaded a new version of the Windows installer to http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ This SHOULD (and does seem to) use a versioned user directory but NOT have versioned executables. Please test. Stefan: I am pretty sure this will be the final version, but I don't want to tag it until I'm sure. Still, if you want to go ahead and build a new package, then you can check out rgheck/2.3.1-1, which is what I will push as a new tag once I am sure. (It'll be exactly the same code, but of course in the main repo.) The only change that will affect you is the one to configure.ac. The others are Windows only. Seems to work as expected for me. Thanks! Daniel And for me (including no crash when closing the pdf viewer). Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Hopefully....LyX 2.3.1-1
On 30/09/2018 00:06, Richard Kimberly Heck wrote: I have uploaded a new version of the Windows installer to http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ This SHOULD (and does seem to) use a versioned user directory but NOT have versioned executables. Please test. Stefan: I am pretty sure this will be the final version, but I don't want to tag it until I'm sure. Still, if you want to go ahead and build a new package, then you can check out rgheck/2.3.1-1, which is what I will push as a new tag once I am sure. (It'll be exactly the same code, but of course in the main repo.) The only change that will affect you is the one to configure.ac. The others are Windows only. Seems to work as expected for me. Thanks! Daniel
Hopefully....LyX 2.3.1-1
I have uploaded a new version of the Windows installer to http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ This SHOULD (and does seem to) use a versioned user directory but NOT have versioned executables. Please test. Stefan: I am pretty sure this will be the final version, but I don't want to tag it until I'm sure. Still, if you want to go ahead and build a new package, then you can check out rgheck/2.3.1-1, which is what I will push as a new tag once I am sure. (It'll be exactly the same code, but of course in the main repo.) The only change that will affect you is the one to configure.ac. The others are Windows only. Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
On 9/29/18 7:50 AM, Stephan Witt wrote: > Am 29.09.2018 um 11:09 schrieb Jürgen Spitzmüller : >> Am Freitag, den 28.09.2018, 20:51 -0400 schrieb Richard Kimberly Heck: I think for the sake of clarity we should do that, yes. >>> OK. I personally do not know how to do this, so I will wait >> update version and date in configure.ac > Yes, that’s it, IMO. Plus a 2.3.1.1 tag. Then I can build from the > checkout or make the tar myself. OK, I will do this later today. Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am 29.09.2018 um 11:09 schrieb Jürgen Spitzmüller : > > Am Freitag, den 28.09.2018, 20:51 -0400 schrieb Richard Kimberly Heck: >>> I think for the sake of clarity we should do that, yes. >> >> OK. I personally do not know how to do this, so I will wait > > update version and date in configure.ac Yes, that’s it, IMO. Plus a 2.3.1.1 tag. Then I can build from the checkout or make the tar myself. Stephan > (this should have been done also for the windows updates, IMHO, do > differentiate the respective updates; apart from that, I think we > should tag the versions in git, if we do not want to provide source > tarballs for these sub-minor releases)
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am Freitag, den 28.09.2018, 20:51 -0400 schrieb Richard Kimberly Heck: > > I think for the sake of clarity we should do that, yes. > > OK. I personally do not know how to do this, so I will wait update version and date in configure.ac (this should have been done also for the windows updates, IMHO, do differentiate the respective updates; apart from that, I think we should tag the versions in git, if we do not want to provide source tarballs for these sub-minor releases) Jürgen > > Riki > signature.asc Description: This is a digitally signed message part
Re: LyX 2.3.1 Installer 3
On 28/09/2018 16:13, Daniel wrote: Hi, I am pretty sure that 2) is a bug. Maybe there is a reason for 1) but then the installer should tell the user to uninstall the old version first not only under the conditions mentioned in the initial dialog (see attached screen capture). "reinstall" in the dialog is a bit ambiguous too. I think what is meant is "*uninstall* and reinstall", or? Daniel
Re: LyX 2.3.1 Installer 3
On 29/09/2018 1:53 p.m., Richard Kimberly Heck wrote: On 09/28/2018 12:04 PM, Richard Kimberly Heck wrote: On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: Maybe there is a reason for 1) but then the installer should tell the user to uninstall the old version first not only under the conditions mentioned in the initial dialog (see attached screen capture). I agree. Or it should simply remove the prefixed binaries (maybe after a warning). I'll have to try to figuure out how to do that. I'm surprised that the installer simply writes into the existing directory rather than replacing it. That almost seems like a security issue. So for now, we just remove LyX2.3.exe, etc. But should we just remove the whole directory before we begin the install? Who knows what other stuff there might be in there? Riki I had a problem with Thunderbird so this may be largely a repeat of an email just sent (or which I tried to send). LyX 2.3 (with a space) is where LyX is installed; LyX2.3 (no space) is the user's directory for preferences etc. As I understand it, a minor version upgrade should overwrite the former but not touch the latter (if it already exists). Yes, I see LyX2.3.exe is the binary in version 2.3.1. In 2.2.3 and earlier it is just lyx.exe. This will be relevant when double-clicking on a *.lyx file to open it (which I don't do as a rule, generally opening LyX then finding the file from within LyX, so I hadn't noticed this change in name). Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: LyX 2.3.1 Installer 3
On 09/28/2018 10:52 PM, Andrew Parsloe wrote: > On 29/09/2018 1:53 p.m., Richard Kimberly Heck wrote: >> On 09/28/2018 12:04 PM, Richard Kimberly Heck wrote: >>> On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: >>>> Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: >>>>> Maybe there is a reason for 1) but >>>>> then the installer should tell the user to uninstall the old version >>>>> first not only under the conditions mentioned in the initial dialog >>>>> (see attached screen capture). >>>> I agree. Or it should simply remove the prefixed binaries (maybe after >>>> a warning). >>> I'll have to try to figuure out how to do that. I'm surprised that the >>> installer simply writes into the existing directory rather than >>> replacing it. That almost seems like a security issue. >> So for now, we just remove LyX2.3.exe, etc. But should we just remove >> the whole directory >> before we begin the install? Who knows what other stuff there might be >> in there? >> >> Riki >> > LyX 2.3 (with a space) is where LyX is installed; LyX2.3 (no space) is > the user directory. This has been the practice for 'ages' on windows. Hmm, I am confused then. I'm honestly not sure how LyX2.3 would come to be the user directory. Actually, I do see it now, I think. I'll have to look further at this. > I would expect a minor version upgrade to overwrite the LyX 2.3 > directory, but not overwrite the LyX2.3 directory. I hadn't noticed > before but I see that the binary is LyX2.3.exe (camel-cased & > numbered) for version 2.3.1, but in 2.2.3 (and earlier versions, if I > remember correctly) it is just lyx.exe. It will be LyX.exe in future releases. But of course Windows is case-insensitive. Riki
Re: LyX 2.3.1 Installer 3
On 29/09/2018 1:53 p.m., Richard Kimberly Heck wrote: On 09/28/2018 12:04 PM, Richard Kimberly Heck wrote: On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: Maybe there is a reason for 1) but then the installer should tell the user to uninstall the old version first not only under the conditions mentioned in the initial dialog (see attached screen capture). I agree. Or it should simply remove the prefixed binaries (maybe after a warning). I'll have to try to figuure out how to do that. I'm surprised that the installer simply writes into the existing directory rather than replacing it. That almost seems like a security issue. So for now, we just remove LyX2.3.exe, etc. But should we just remove the whole directory before we begin the install? Who knows what other stuff there might be in there? Riki LyX 2.3 (with a space) is where LyX is installed; LyX2.3 (no space) is the user directory. This has been the practice for 'ages' on windows. I would expect a minor version upgrade to overwrite the LyX 2.3 directory, but not overwrite the LyX2.3 directory. I hadn't noticed before but I see that the binary is LyX2.3.exe (camel-cased & numbered) for version 2.3.1, but in 2.2.3 (and earlier versions, if I remember correctly) it is just lyx.exe. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: LyX 2.3.1 Installer 3
On 09/28/2018 12:04 PM, Richard Kimberly Heck wrote: > On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: >> Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: >>> Maybe there is a reason for 1) but >>> then the installer should tell the user to uninstall the old version >>> first not only under the conditions mentioned in the initial dialog >>> (see attached screen capture). >> I agree. Or it should simply remove the prefixed binaries (maybe after >> a warning). > I'll have to try to figuure out how to do that. I'm surprised that the > installer simply writes into the existing directory rather than > replacing it. That almost seems like a security issue. So for now, we just remove LyX2.3.exe, etc. But should we just remove the whole directory before we begin the install? Who knows what other stuff there might be in there? Riki
Re: LyX 2.3.1 Installer 3
On 09/28/2018 12:04 PM, Richard Kimberly Heck wrote: > On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: >> Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: >>> Hi, >>> >>> I just checked the new installer. The crashing on closing the PDF >>> reader seems fixed. However, >>> >>> 1) if one installs it over the existing version, it will create a >>> second LyX version rather than replace the current one. There will be a >>> LyX.exe as well as a LyX2.3.exe. >> I think this is a consequence of the fix for >> https://www.lyx.org/trac/ticket/11313 >> >> The addition of the version suffix was not intended and caused several >> problems. > Yes. > >>> 2) the new version will not use the earlier version's user directory >>> "LyX2.3" but rather just LyX. >> That's immediately connected to the above. However, there is a method >> in configure.py (checkUpgrade()) that is used by the Mac to copy >> contents from previous user dirs (LyX on Mac uses the version >> suffixes). > Actually, I did not mean to make that change. (The installer code > connects several such things that ought to be separated.) We do want to > have "versioned" user directories on Windows. I'll fix that over the > weekend. Actually actually, I'm wrong about that. This setting depends upon LYX_PROGRAM_PREFIX. We normally do not have the prefix in the case of the Windows install, but 2.3.0 and 2.3.1 (so far) did. So most users will now have a "LyX 2.3" user directory, or something of the sort. I have updated the configure.py script to do something similar to what is done on OSX. This will not work for everyone: If you already have a "LyX" user directory (say from a 2.2.x installation), then we will not copy the "LyX 2.3" directory into it. So I'll put some kind of note on the download page about this, and include it in the announcement. Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
On 09/28/2018 12:36 PM, Jürgen Spitzmüller wrote: > Am Freitag, den 28.09.2018, 12:00 -0400 schrieb Richard Kimberly Heck: >>> Don’t we need a new version tag to get the 2.3.1.1 in the About >>> LyX? >>> I should have ask earlier, I know - sorry. >> >> I'm kind of ignorant of that sort of thing. Anyone? > I think for the sake of clarity we should do that, yes. OK. I personally do not know how to do this, so I will wait Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am Freitag, den 28.09.2018, 12:00 -0400 schrieb Richard Kimberly Heck: > > Don’t we need a new version tag to get the 2.3.1.1 in the About > > LyX? > > I should have ask earlier, I know - sorry. > > > I'm kind of ignorant of that sort of thing. Anyone? I think for the sake of clarity we should do that, yes. Jürgen > (I will hold off on > any announcement.) > > Riki > > signature.asc Description: This is a digitally signed message part
Re: LyX 2.3.1 Installer 3
On 9/28/18 10:31 AM, Jürgen Spitzmüller wrote: > Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: >> Hi, >> >> I just checked the new installer. The crashing on closing the PDF >> reader >> seems fixed. However, >> >> 1) if one installs it over the existing version, it will create a >> second >> LyX version rather than replace the current one. There will be a >> LyX.exe >> as well as a LyX2.3.exe. > I think this is a consequence of the fix for > https://www.lyx.org/trac/ticket/11313 > > The addition of the version suffix was not intended and caused several > problems. Yes. >> 2) the new version will not use the earlier version's user directory >> "LyX2.3" but rather just LyX. > That's immediately connected to the above. However, there is a method > in configure.py (checkUpgrade()) that is used by the Mac to copy > contents from previous user dirs (LyX on Mac uses the version > suffixes). Actually, I did not mean to make that change. (The installer code connects several such things that ought to be separated.) We do want to have "versioned" user directories on Windows. I'll fix that over the weekend. >> Maybe there is a reason for 1) but >> then the installer should tell the user to uninstall the old version >> first not only under the conditions mentioned in the initial dialog >> (see attached screen capture). > I agree. Or it should simply remove the prefixed binaries (maybe after > a warning). I'll have to try to figuure out how to do that. I'm surprised that the installer simply writes into the existing directory rather than replacing it. That almost seems like a security issue. Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
On 9/28/18 1:12 AM, Stephan Witt wrote: > Am 27.09.2018 um 19:56 schrieb Richard Kimberly Heck : >> On 09/23/2018 02:57 AM, Jürgen Spitzmüller wrote: >>> Am Samstag, den 22.09.2018, 20:42 +0200 schrieb Stephan Witt: >> What can be done with it? The error is serious and makes the >> tex2lyx in the original package useless. I propose to replace the >> wrong package with the new one. But is this an option? There is >> no visible difference between the two LyX versions. The About LyX >> info is not different, AFAICS. > We routinely do this for the Windows build, so I think it is ok. > But > maybe we should raise it on the list and see what people think? > JMarc > and Jürgen especially. Yes, we should. It did’t do it in the first place because of the download links - but now I think it doesn’t hurt. What do you think should be done here? >>> I think we should proceed and provide a new binary with a clear >>> distinctive sub-version number (2.3.1.1). And of course announce it >>> (for Mac only) so that Mac users know they should upgrade. >> I have uploaded these now and will wait 24 hours for mirrors to sync >> before making the >> annoucement and chaning the website. > Don’t we need a new version tag to get the 2.3.1.1 in the About LyX? > I should have ask earlier, I know - sorry. I'm kind of ignorant of that sort of thing. Anyone? (I will hold off on any announcement.) Riki
Re: LyX 2.3.1 Installer 3
Am Freitag, den 28.09.2018, 16:13 +0200 schrieb Daniel: > Hi, > > I just checked the new installer. The crashing on closing the PDF > reader > seems fixed. However, > > 1) if one installs it over the existing version, it will create a > second > LyX version rather than replace the current one. There will be a > LyX.exe > as well as a LyX2.3.exe. I think this is a consequence of the fix for https://www.lyx.org/trac/ticket/11313 The addition of the version suffix was not intended and caused several problems. > 2) the new version will not use the earlier version's user directory > "LyX2.3" but rather just LyX. That's immediately connected to the above. However, there is a method in configure.py (checkUpgrade()) that is used by the Mac to copy contents from previous user dirs (LyX on Mac uses the version suffixes). A similar method could be used to copy the contents of LyX2.3 to LyX. > I am pretty sure that 2) is a bug. Maybe there is a reason for 1) > but > then the installer should tell the user to uninstall the old version > first not only under the conditions mentioned in the initial dialog > (see > attached screen capture). I agree. Or it should simply remove the prefixed binaries (maybe after a warning). Jürgen > > Daniel signature.asc Description: This is a digitally signed message part
LyX 2.3.1 Installer 3
Hi, I just checked the new installer. The crashing on closing the PDF reader seems fixed. However, 1) if one installs it over the existing version, it will create a second LyX version rather than replace the current one. There will be a LyX.exe as well as a LyX2.3.exe. And 2) the new version will not use the earlier version's user directory "LyX2.3" but rather just LyX. I am pretty sure that 2) is a bug. Maybe there is a reason for 1) but then the installer should tell the user to uninstall the old version first not only under the conditions mentioned in the initial dialog (see attached screen capture). Daniel
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am 27.09.2018 um 19:56 schrieb Richard Kimberly Heck : > > On 09/23/2018 02:57 AM, Jürgen Spitzmüller wrote: >> Am Samstag, den 22.09.2018, 20:42 +0200 schrieb Stephan Witt: > What can be done with it? The error is serious and makes the > tex2lyx in the original package useless. I propose to replace the > wrong package with the new one. But is this an option? There is > no visible difference between the two LyX versions. The About LyX > info is not different, AFAICS. We routinely do this for the Windows build, so I think it is ok. But maybe we should raise it on the list and see what people think? JMarc and Jürgen especially. >>> Yes, we should. It did’t do it in the first place because of the >>> download links - but now I think it doesn’t hurt. >>> >>> What do you think should be done here? >> I think we should proceed and provide a new binary with a clear >> distinctive sub-version number (2.3.1.1). And of course announce it >> (for Mac only) so that Mac users know they should upgrade. > > I have uploaded these now and will wait 24 hours for mirrors to sync > before making the > annoucement and chaning the website. Don’t we need a new version tag to get the 2.3.1.1 in the About LyX? I should have ask earlier, I know - sorry. Stephan
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
On 09/23/2018 02:57 AM, Jürgen Spitzmüller wrote: > Am Samstag, den 22.09.2018, 20:42 +0200 schrieb Stephan Witt: What can be done with it? The error is serious and makes the tex2lyx in the original package useless. I propose to replace the wrong package with the new one. But is this an option? There is no visible difference between the two LyX versions. The About LyX info is not different, AFAICS. >>> We routinely do this for the Windows build, so I think it is ok. >>> But >>> maybe we should raise it on the list and see what people think? >>> JMarc >>> and Jürgen especially. >> Yes, we should. It did’t do it in the first place because of the >> download links - but now I think it doesn’t hurt. >> >> What do you think should be done here? > I think we should proceed and provide a new binary with a clear > distinctive sub-version number (2.3.1.1). And of course announce it > (for Mac only) so that Mac users know they should upgrade. I have uploaded these now and will wait 24 hours for mirrors to sync before making the annoucement and chaning the website. Riki
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am Samstag, den 22.09.2018, 20:42 +0200 schrieb Stephan Witt: > > > What can be done with it? The error is serious and makes the > > > tex2lyx in the original package useless. I propose to replace the > > > wrong package with the new one. But is this an option? There is > > > no visible difference between the two LyX versions. The About LyX > > > info is not different, AFAICS. > > > > We routinely do this for the Windows build, so I think it is ok. > > But > > maybe we should raise it on the list and see what people think? > > JMarc > > and Jürgen especially. > > Yes, we should. It did’t do it in the first place because of the > download links - but now I think it doesn’t hurt. > > What do you think should be done here? I think we should proceed and provide a new binary with a clear distinctive sub-version number (2.3.1.1). And of course announce it (for Mac only) so that Mac users know they should upgrade. Jürgen signature.asc Description: This is a digitally signed message part
Re: LyX 2.3.1 on Mac package problem - Problem importing latex files
Am 22.09.2018 um 19:33 schrieb Richard Kimberly Heck : > > On 09/22/2018 11:25 AM, Stephan Witt wrote: >> Hi Riki, >> >> did you notice the problem report from Paola Manzini? It’s in mail archive >> here: >> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg206434.html >> >> We never had this problem and I wasn’t aware of the additional linker >> command line >> parameter -headerpad_max_install_names to avoid that error. >> >> I’ve used the lyx-2.3.1-2 tar archive again to build the binaries with it. >> The >> error was solved that way and I’ve uploaded the resulting package here: >> >> https://www.dropbox.com/s/9qu4ty07ama14mw/LyX-2.3.1-2%2Bqt5-x86_64-cocoa.dmg?dl=0 >> https://www.dropbox.com/s/iw36rl9st7kowlo/LyX-2.3.1-2%2Bqt5-x86_64-cocoa.dmg.sig?dl=0 >> >> What can be done with it? The error is serious and makes the tex2lyx in the >> original package useless. I propose to replace the wrong package with the >> new one. But is this an option? There is no visible difference between the >> two LyX versions. The About LyX info is not different, AFAICS. > > We routinely do this for the Windows build, so I think it is ok. But > maybe we should raise it on the list and see what people think? JMarc > and Jürgen especially. Yes, we should. It did’t do it in the first place because of the download links - but now I think it doesn’t hurt. What do you think should be done here? Stephan >> Furthermore I’ve commited two changes to master I want to back port: >> d9c0807227a9bdff2d28a80181d0e7ec5532ba1e >> 28b84f5ddc42d2b4ec973b0abd4f8f3608952c61 >> >> They are for Mac OS builds only. Ok? > > OK. Thanks. Done.
Re: [ANNOUNCE] LyX 2.3.1 Released
On 09/17/2018 08:27 AM, José Abílio Matos wrote: > On Monday, 17 September 2018 04.56.46 WEST Richard Kimberly Heck wrote: >> Since I'm the one who caused the bug, I'm not sure how much praise I get >> for reverting the fix. But thanks anyway! > You are being modest. :-) > The whole process has been very smooth and thus seemingly it does not require > too much effort because of you coordination. That is something to be praised. I appreciate the support, then! Riki
Re: [ANNOUNCE] LyX 2.3.1 Released
On 09/17/2018 03:10 PM, John White wrote: > Congrats. > > I got on lyx.org to make a donation but don't understand the paypal thing as > it is in euros not $. Can I just sent a check on a Reno Nevada USA bank to > the address on that site? No idea, but PayPal will do the currency conversion for you. If you want to find out how many euros 10 dollars is, say, just google "10 dollars in euros". Then give that many euros. Once you log into PayPal, and right before you actually pay, PayPal will tell you how many dollars it is, since your account is in dollars. There are of course some fees built into that, so it will probably be slightly more. Riki On Sunday, September 16, 2018 11:40:46 AM PDT Richard Kimberly Heck wrote: >> Public release of LyX version 2.3.1 >> === >> >> We are proud to announce the release of LyX 2.3.1. This is the first >> maintenance release in the 2.3.x series. >> >> You can download LyX 2.3.1 from http://www.lyx.org/Download/. >> >> LyX is a document processor that encourages an approach to writing based >> on the structure of your documents and not simply their appearance. It is >> released under a Free and Open Source Software license. >> >> LyX 2.3.1 is the result of on-going efforts to make our stable version more >> reliable and more stable. We have fixed a number of bugs and added some new >> features. Please see below for a full list. Perhaps the most important of >> these is that Jean-Marc Lasgouttes re-wrote the document painting >> mechanism. >> This makes LyX snappier, especially on repeated events. >> >> All python scripts distributed with LyX should now be compatible with both >> python 2.x and python 3.x. >> >> One oft-requested enhancement was to restore a keyboard shortcut for opening >> the 'settings' menu of graphics, reference, etc, insets. This is now >> Control- >> Alt-i, on Windows and Linux, and Control-Option-i on OSX (assuming you are >> using the default keybindings). >> >> A change to how math macros are output can break some documents that use >> ERT to comment out macros. Please see bug #11216 if you experience this >> sort >> of problem. >> >> If you think you have found a bug in LyX 2.3.1, please open a bug report at >> http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it >> really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel >> lists.lyx.org) and ask. >> >> If you have trouble using LyX or have a question, consult the documentation >> that comes with LyX (under the Help or Apple menu) and the LyX wiki, which >> is at http://wiki.lyx.org/. If you can't find the answer there, e-mail the >> LyX users' list (lyx-users lists.lyx.org), where you will find an >> active community of people who are ready to help. >> >> We hope you enjoy using LyX 2.3.1. >> >> The LyX team. >> http://www.lyx.org >> >> >> What's new >> == >> >> ** Updates: >> *** >> >> * DOCUMENT INPUT/OUTPUT >> >> - It possible to anonymize document's content for bug submissions >> via buffer-anonymize lfun (bug 7259). >> >> - Support rotation of multi-page tables via (pdf)lscape (bug 9194). >> >> - Added LFUN_MASTER_BUFFER_EXPORT, which exports the master buffer, along >> the lines of LFUN_MASTER_BUFFER_VIEW (bug 8). >> >> - Needauth is not needed for exporting R code (only when executing the >> code). >> >> - Center longtable explicitly for compatibility with some packages (bug >> 10690). >> >> - Fix problems with default conversion script for graphics (part of bug >> 11186). >> >> >> * MISCELLANEOUS >> >> - Updated to Qt5 the LyX server example client in development/lyxserver/ >> >> >> * TEX2LYX IMPROVEMENTS >> >> - Add support for biblatex. >> >> - Add support for chapterbib. >> >> - Add support for \includeonly. >> >> - Add support for beamer overlay arguments (bug 11068). >> >> - Update tex2lyx quotation marks detection: >> * Consider new quote styles of LyX 2.3. >> * Consider changed quote styles in LYX 2.3. >> * Try to be a bit smarter with ambiguous quotation marks, >> depending on the main quote style and the local context. >> >> - Consider options passed via \PassOptionsToPackage. >> >> - Add support for URW Classico, MinionPro and the new Libertine fonts. >> >> - Add support for \lstinputlist
Re: [ANNOUNCE] LyX 2.3.1 Released
On 16/09/2018 17:40, Richard Kimberly Heck wrote: Public release of LyX version 2.3.1 === We are proud to announce the release of LyX 2.3.1. This is the first maintenance release in the 2.3.x series. Thanks a lot for all the developer's work! I am a very happy user of LyX and get more happy with it every release. (The number of bug reports I submit should suggest just this and not the opposite.) Daniel
Re: [ANNOUNCE] LyX 2.3.1 Released
On Monday, 17 September 2018 04.56.46 WEST Richard Kimberly Heck wrote: > Since I'm the one who caused the bug, I'm not sure how much praise I get > for reverting the fix. But thanks anyway! You are being modest. :-) The whole process has been very smooth and thus seemingly it does not require too much effort because of you coordination. That is something to be praised. > The Windows installer is what's taken all my time > > Riki -- José Abílio
Re: [ANNOUNCE] LyX 2.3.1 Released
On Monday, 17 September 2018 04.53.16 WEST Richard Kimberly Heck wrote: > My bad. The website wasn't set up properly to handle this naming scheme. > I've fixed it. > > We had to release with the -2 suffix because earlier and different > tarballs were already in the wild. This was all due to the problems with > #9158, which required fixes after the original lyx-2.3.1.tar.xz was > released. > > Riki What most projects do is to rewrite (sometimes silently) the tarballs. :-) This has happened to me several times, and usually the rpm spec file has a changelog entry like "Respun tarball". A suggestion that can be made in this case is to have rc'c for lyx 2.3.x such that as soon as you are happy with outcome you switch the last rc to the official release. That way we ensure the same development cycle for development and release versions. Just an idea, -- José Abílio
Re: [ANNOUNCE] LyX 2.3.1 Released
On 09/16/2018 05:19 PM, Scott Kostyshak wrote: > On Sun, Sep 16, 2018 at 09:20:01PM +0100, José Abílio Matos wrote: >> On Sunday, 16 September 2018 21.15.02 WEST Jean-Marc Lasgouttes wrote: >>> I have to thank you for all the hard work you put in actually get this >>> release out. >>> >>> JMarc >> +100 ! > +1000 !! :) :) [1] > > Really, thank you Riki. Since I'm the one who caused the bug, I'm not sure how much praise I get for reverting the fix. But thanks anyway! The Windows installer is what's taken all my time Riki
Re: [ANNOUNCE] LyX 2.3.1 Released
On 09/16/2018 04:52 PM, José Abílio Matos wrote: > On Sunday, 16 September 2018 21.33.29 WEST José Abílio Matos wrote: >> In order to build to Fedora I tried to download the xz file and I get: >> >> "The requested URL /pub/lyx/stable/2.3.x/lyx-2.3.1.tar.xz was not found on >> this server." >> >> That happens because of the -2 suffix. I suggest to rename the files (the >> same applies to .tar.gz and .sig files). > The problem is the that the version present is lyx-2.3.x.tar.xz where the x > should really be 1 in this case. My bad. The website wasn't set up properly to handle this naming scheme. I've fixed it. We had to release with the -2 suffix because earlier and different tarballs were already in the wild. This was all due to the problems with #9158, which required fixes after the original lyx-2.3.1.tar.xz was released. Riki
Re: [ANNOUNCE] LyX 2.3.1 Released
On Sun, Sep 16, 2018 at 09:20:01PM +0100, José Abílio Matos wrote: > On Sunday, 16 September 2018 21.15.02 WEST Jean-Marc Lasgouttes wrote: > > I have to thank you for all the hard work you put in actually get this > > release out. > > > > JMarc > > +100 ! +1000 !! :) :) [1] Really, thank you Riki. Scott [1] I usually would be scared to provoke José into an emoji war, but I sincerely believe that Riki deserves all of the "plus n" and emoji inflation that could result. signature.asc Description: PGP signature
Re: [ANNOUNCE] LyX 2.3.1 Released
On Sunday, 16 September 2018 21.33.29 WEST José Abílio Matos wrote: > In order to build to Fedora I tried to download the xz file and I get: > > "The requested URL /pub/lyx/stable/2.3.x/lyx-2.3.1.tar.xz was not found on > this server." > > That happens because of the -2 suffix. I suggest to rename the files (the > same applies to .tar.gz and .sig files). The problem is the that the version present is lyx-2.3.x.tar.xz where the x should really be 1 in this case. PS: I am sorry for sending the original message to the users' list but kmail decided so and I did not notice. My bad. :-) -- José Abílio
Re: [ANNOUNCE] LyX 2.3.1 Released
On Sunday, 16 September 2018 21.15.02 WEST Jean-Marc Lasgouttes wrote: > I have to thank you for all the hard work you put in actually get this > release out. > > JMarc +100 ! -- José Abílio
Re: [ANNOUNCE] LyX 2.3.1 Released
Le 16/09/2018 à 17:40, Richard Kimberly Heck a écrit : Public release of LyX version 2.3.1 === We are proud to announce the release of LyX 2.3.1. This is the first maintenance release in the 2.3.x series. I have to thank you for all the hard work you put in actually get this release out. JMarc
[ANNOUNCE] LyX 2.3.1 Released
Public release of LyX version 2.3.1
===
We are proud to announce the release of LyX 2.3.1. This is the first
maintenance release in the 2.3.x series.
You can download LyX 2.3.1 from http://www.lyx.org/Download/.
LyX is a document processor that encourages an approach to writing based
on the structure of your documents and not simply their appearance. It is
released under a Free and Open Source Software license.
LyX 2.3.1 is the result of on-going efforts to make our stable version more
reliable and more stable. We have fixed a number of bugs and added some new
features. Please see below for a full list. Perhaps the most important of
these is that Jean-Marc Lasgouttes re-wrote the document painting
mechanism.
This makes LyX snappier, especially on repeated events.
All python scripts distributed with LyX should now be compatible with both
python 2.x and python 3.x.
One oft-requested enhancement was to restore a keyboard shortcut for opening
the 'settings' menu of graphics, reference, etc, insets. This is now
Control-
Alt-i, on Windows and Linux, and Control-Option-i on OSX (assuming you are
using the default keybindings).
A change to how math macros are output can break some documents that use
ERT to comment out macros. Please see bug #11216 if you experience this
sort
of problem.
If you think you have found a bug in LyX 2.3.1, please open a bug report at
http://www.lyx.org/trac/wiki/BugTrackerHome. If you're not sure whether it
really is a bug, you can e-mail the LyX developers' mailing list (lyx-devel
lists.lyx.org) and ask.
If you have trouble using LyX or have a question, consult the documentation
that comes with LyX (under the Help or Apple menu) and the LyX wiki, which
is at http://wiki.lyx.org/. If you can't find the answer there, e-mail the
LyX users' list (lyx-users lists.lyx.org), where you will find an
active community of people who are ready to help.
We hope you enjoy using LyX 2.3.1.
The LyX team.
http://www.lyx.org
What's new
==
** Updates:
***
* DOCUMENT INPUT/OUTPUT
- It possible to anonymize document's content for bug submissions
via buffer-anonymize lfun (bug 7259).
- Support rotation of multi-page tables via (pdf)lscape (bug 9194).
- Added LFUN_MASTER_BUFFER_EXPORT, which exports the master buffer, along
the lines of LFUN_MASTER_BUFFER_VIEW (bug 8).
- Needauth is not needed for exporting R code (only when executing the
code).
- Center longtable explicitly for compatibility with some packages (bug
10690).
- Fix problems with default conversion script for graphics (part of bug
11186).
* MISCELLANEOUS
- Updated to Qt5 the LyX server example client in development/lyxserver/
* TEX2LYX IMPROVEMENTS
- Add support for biblatex.
- Add support for chapterbib.
- Add support for \includeonly.
- Add support for beamer overlay arguments (bug 11068).
- Update tex2lyx quotation marks detection:
* Consider new quote styles of LyX 2.3.
* Consider changed quote styles in LYX 2.3.
* Try to be a bit smarter with ambiguous quotation marks,
depending on the main quote style and the local context.
- Consider options passed via \PassOptionsToPackage.
- Add support for URW Classico, MinionPro and the new Libertine fonts.
- Add support for \lstinputlisting and \inputminted.
- Add support for the \t*{} (bottomtiebar) macro of TIPA.
- Implement better parsing of some command options (via "literate"
function of some insets) (bug 9563).
- Add support for alignment pseudo-environments as used inside floats
(bug 7857).
* USER INTERFACE
- Overhaul the document painting mechanism. Now the screen is updated
asyncronously (as all normal applications do), which makes LyX
snappier, especially on repeated events. As an added bonus, subpixel
aliasing is honored in the work area.
- Use native file dialogs on all platforms by default. It is now
possible to switch to LyX custom dialogs (which have extra shortcuts
to relevant directories) by setting the preference
\use_native_filedialog true
- Let caret height depend on character size in math editor.
- Handle properly top/bottom of inset with mac-like cursor movement
(bug 10701).
- Respect the last setting of the 'literal' checkbox when adding citations
via the LyX server (e.g., from JabRef).
- Allow unification of graphic groups inside marked block via context
menu.
- Cosmetic polishment of the "Math Options" pane of Document Settings
(bug 10777).
- UI improvements in the graphics dialog (bug 10771).
- Set tab stop in preamble editor to four characters.
- Provide simple search functionality in preamble (bug 11099).
- Change Settings -> Local Layout to Fixed-width Font and Nowrap (bug
10992).
- Allow LFUN_UNICODE_INSERT to take multiple arguments (bug 11084).
- Added C-M-i as a shortcut for LFUN_INSET_SETTINGS (bug 7662).
* DOCUMENTATION AND LOCALIZATION
-
2.3.1 Again
Hi, all, I somehow failed to upload the tarballs when I uploaded the binaries. (Scatter-brained with the start of the semester.) So I have to do that now. I'll therefore do the release over the weekend. Riki
Re: New 2.3.1 Windows Installer for Testing
On 08/09/2018 21:44, Richard Kimberly Heck wrote: On 09/08/2018 02:29 PM, Daniel wrote: On 08/09/2018 20:13, Richard Kimberly Heck wrote: On 09/08/2018 03:20 AM, Daniel wrote: On 06/09/2018 19:37, Richard Kimberly Heck wrote: Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki I didn't notice any slowness as compared to 2.3.0. On 09/06/2018 05:58 PM, Andrew Parsloe wrote: I've installed this version and it solves the slowness problem with my test document. The kpsewhich.log is not being added to with operations (new paragraphs, selection + deletion, etc.) that were generating entries with the first installer. Great, we'll proceed to release. Riki Maybe it is a good idea to wait a bit with the Windows binary because MiKTeX is down which could lead to problems for people trying the update recommendation on the website: https://miktex.org/alert/update-problem-6824 I'll put some kind of warning on the download page. And we won't be releasing a "bundled" installer. I'm working right now on some instructions for how to install TeXLive for use with LyX. Frankly, I'd encourage everyone to switch to TeXLive. It seems that MiKTeX gets less stable every month. Riki MiKTeX is up and running again. Thanks for the advice but I'll stick to MiKTeX. Except for a couple of recent problems, it served me well enough so far. Daniel
Re: New 2.3.1 Tarballs
On Saturday, 8 September 2018 19.25.41 WEST Richard Kimberly Heck wrote: > New (and seemingly final) tarballs for 2.3.1 are now on the ftp site here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ > > Sorry to those who already built binaries: They'll need to be re-done. This > is all due to the problem with slowness reported in #9158. > > Riki Rebuilt with the new sources for Fedora and EL7 (Red Hat/CentOs/Scientific Linux) in copr: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/ copr is similar to the ppa's from Ubuntu. After the official release I will repeat the same procedure for the real repositories. -- José Abílio
Re: New 2.3.1 Windows Installer for Testing
On 09/08/2018 02:29 PM, Daniel wrote: > On 08/09/2018 20:13, Richard Kimberly Heck wrote: >> On 09/08/2018 03:20 AM, Daniel wrote: >>> On 06/09/2018 19:37, Richard Kimberly Heck wrote: Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki >>> >>> I didn't notice any slowness as compared to 2.3.0. >> >> On 09/06/2018 05:58 PM, Andrew Parsloe wrote: >>> I've installed this version and it solves the slowness problem with my >>> test document. The kpsewhich.log is not being added to with operations >>> (new paragraphs, selection + deletion, etc.) that were generating >>> entries with the first installer. >> >> Great, we'll proceed to release. >> >> Riki > > Maybe it is a good idea to wait a bit with the Windows binary because > MiKTeX is down which could lead to problems for people trying the > update recommendation on the website: > > https://miktex.org/alert/update-problem-6824 I'll put some kind of warning on the download page. And we won't be releasing a "bundled" installer. I'm working right now on some instructions for how to install TeXLive for use with LyX. Frankly, I'd encourage everyone to switch to TeXLive. It seems that MiKTeX gets less stable every month. Riki
Re: New 2.3.1 Windows Installer for Testing
On 08/09/2018 20:13, Richard Kimberly Heck wrote: On 09/08/2018 03:20 AM, Daniel wrote: On 06/09/2018 19:37, Richard Kimberly Heck wrote: Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki I didn't notice any slowness as compared to 2.3.0. On 09/06/2018 05:58 PM, Andrew Parsloe wrote: I've installed this version and it solves the slowness problem with my test document. The kpsewhich.log is not being added to with operations (new paragraphs, selection + deletion, etc.) that were generating entries with the first installer. Great, we'll proceed to release. Riki Maybe it is a good idea to wait a bit with the Windows binary because MiKTeX is down which could lead to problems for people trying the update recommendation on the website: https://miktex.org/alert/update-problem-6824 Daniel
New 2.3.1 Tarballs
New (and seemingly final) tarballs for 2.3.1 are now on the ftp site here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Sorry to those who already built binaries: They'll need to be re-done. This is all due to the problem with slowness reported in #9158. Riki
Re: New 2.3.1 Windows Installer for Testing
On 09/08/2018 03:20 AM, Daniel wrote: > On 06/09/2018 19:37, Richard Kimberly Heck wrote: >> Here: >> >> http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ >> >> Please let us know if this fixes the slowness bug from before. If so, >> we'll proceed to release. >> >> Riki > > I didn't notice any slowness as compared to 2.3.0. On 09/06/2018 05:58 PM, Andrew Parsloe wrote: > I've installed this version and it solves the slowness problem with my > test document. The kpsewhich.log is not being added to with operations > (new paragraphs, selection + deletion, etc.) that were generating > entries with the first installer. Great, we'll proceed to release. Riki
Re: New 2.3.1 Windows Installer for Testing
On 06/09/2018 19:37, Richard Kimberly Heck wrote: Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki I didn't notice any slowness as compared to 2.3.0. Daniel
Re: New 2.3.1 Windows Installer for Testing
On 7/09/2018 5:37 a.m., Richard Kimberly Heck wrote: Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki I've installed this version and it solves the slowness problem with my test document. The kpsewhich.log is not being added to with operations (new paragraphs, selection + deletion, etc.) that were generating entries with the first installer. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
New 2.3.1 Windows Installer for Testing
Here: http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ Please let us know if this fixes the slowness bug from before. If so, we'll proceed to release. Riki
LyX 2.3.1 Again
Hi, all, First, sorry to be slow dealing with the new tarballs, etc. I'm about to upload a new Windows installer for testing, and if that's OK then I'll upload new tarballs, etc, so we can build new binaries, etc. While we're waiting, it seems to me that it is now time to kill off the bundle installer. I was going to wait to do this until 2.3.2, but given the recent chaos with MiKTeX, I don't see how we can release such a thing. This will mean putting some language on the LyX website, similar to what's there for OSX, telling people that they will need to install a TeX distribution. Since this will be a new thing for some people, it'd be nice either there or elsewhere to try to provide some guidance, specifically about how to install TeXLive so as to end up with a functional installation for use with LyX. Are there any Windows users who could experiment with this and come up with some language for the website or wiki? Are there different 'types' of installation people can use? Is it possible for us somehow to create a list of packages that people can pass to TeXLive so those will be installed? The thing I most worry about is font definitions, actually. I personally find the error messages in those cases to be nearly unintelligible. Riki
Re: 2.3.1-1 compilation error on ubuntu 18.04.1 LTS "unsafe absolute working directory name"
It seems that the problem was due to an unintentional change in the name of the folder. It had nothing to do with LyX. Apologies and thanks for your replies! Micha On 05.09.2018 14:25, Kornel Benko wrote: Am Mittwoch, 5. September 2018 14:04:50 CEST schrieb Micha H. Werner : currently, compilation of LyX2.3.1-1 fails on Ubuntu 18.04.1 LTS. This is the complete output of ./configure: root@dell:/local/lyx# ./configure Why do you do this as root? And why in the source dir? configuring LyX version 2.3.0 checking for build type... release checking for version suffix... checking whether Qt5 is requested... no checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking what packaging should be used... posix checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: unsafe absolute working directory name According to configure, the directory name contains unsafe characters (one of >>"#$&'`<<). Kornel
Re: 2.3.1-1 compilation error on ubuntu 18.04.1 LTS "unsafe absolute working directory name"
Le 05/09/2018 à 14:25, Kornel Benko a écrit : Am Mittwoch, 5. September 2018 14:04:50 CEST schrieb Micha H. Werner : currently, compilation of LyX2.3.1-1 fails on Ubuntu 18.04.1 LTS. This is the complete output of ./configure: root@dell:/local/lyx# ./configure Why do you do this as root? And why in the source dir? configuring LyX version 2.3.0 checking for build type... release checking for version suffix... checking whether Qt5 is requested... no checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking what packaging should be used... posix checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: unsafe absolute working directory name According to configure, the directory name contains unsafe characters (one of >>"#$&'`<<). What does "pwd" return? JMarc
Re: 2.3.1-1 compilation error on ubuntu 18.04.1 LTS "unsafe absolute working directory name"
Am Mittwoch, 5. September 2018 14:04:50 CEST schrieb Micha H. Werner : > currently, compilation of LyX2.3.1-1 fails on Ubuntu 18.04.1 LTS. > > This is the complete output of ./configure: > > root@dell:/local/lyx# ./configure Why do you do this as root? And why in the source dir? > configuring LyX version 2.3.0 > checking for build type... release > checking for version suffix... > checking whether Qt5 is requested... no > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-pc-linux-gnu > checking what packaging should be used... posix > checking whether to enable maintainer-specific portions of Makefiles... no > checking whether make supports nested variables... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... configure: error: unsafe > absolute working directory name > > According to configure, the directory name contains unsafe characters (one of >>"#$&'`<<). Kornel signature.asc Description: This is a digitally signed message part.
2.3.1-1 compilation error on ubuntu 18.04.1 LTS "unsafe absolute working directory name"
currently, compilation of LyX2.3.1-1 fails on Ubuntu 18.04.1 LTS. This is the complete output of ./configure: root@dell:/local/lyx# ./configure configuring LyX version 2.3.0 checking for build type... release checking for version suffix... checking whether Qt5 is requested... no checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking what packaging should be used... posix checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: unsafe absolute working directory name
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
Am Sonntag, den 02.09.2018, 12:59 +0200 schrieb Pavel Sanda: > After the recent discovery of ghoscript vulnerabilities distributions > seem to > actually follow suggestion of the security researcher who announced > them > and broadly ban any conversions from ps/eps/pdf/xps in imagemagick no > matter > the consequences. I don't need to stress on this list what it means > for > LyX -- just from todays update of my distro I'm not capable to view > most > of my documents by default... > > Unfortuntaly there is very little we can directly for 2.3.1. > We should at least signalize in announcement for distro maintainers > that this *is* > issue and perhaps add some hint how to allow users to locally enable > things > in policy.xml so they can continue their work. > > In longer-term -- if this ban continues -- we might try to ask Qt to > do the > conversions instead of imagemagick, but that's is definitely not for > 2.3.1. The vulnerabilities have been resolved, so it seem to be a medium-term problem: https://artifex.com/news/ghostscript-security-resolved/ Jürgen > > Other ideas? > > Pavel > > https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/ > signature.asc Description: This is a digitally signed message part
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
On 09/02/2018 10:50 AM, Scott Kostyshak wrote: > On Sun, Sep 02, 2018 at 12:59:22PM +0200, Pavel Sanda wrote: > >> In longer-term -- if this ban continues -- we might try to ask Qt to do the >> conversions instead of imagemagick, but that's is definitely not for 2.3.1. > That might be a good backup to get working well even if it weren't for > this issue. We should do a lot of testing. I'm certain I do not know enough about this part of the code to do this, but anything we can have Qt do for us here seems like the right thing to do. Then again, Ghostscript seems to be embedded in everything. Maybe Qt uses it. Riki
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
On Sun, Sep 02, 2018 at 12:59:22PM +0200, Pavel Sanda wrote: > Unfortuntaly there is very little we can directly for 2.3.1. > We should at least signalize in announcement for distro maintainers that this > *is* > issue and perhaps add some hint how to allow users to locally enable things > in policy.xml so they can continue their work. +1 > In longer-term -- if this ban continues -- we might try to ask Qt to do the > conversions instead of imagemagick, but that's is definitely not for 2.3.1. That might be a good backup to get working well even if it weren't for this issue. We should do a lot of testing. Scott signature.asc Description: PGP signature
Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
Richard Kimberly Heck wrote: > Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. > I suppose we should wait to prepare binaries until we have some feedback. Before we announce we might consider to issue new warning as part of release. Or even as a separate entry. After the recent discovery of ghoscript vulnerabilities distributions seem to actually follow suggestion of the security researcher who announced them and broadly ban any conversions from ps/eps/pdf/xps in imagemagick no matter the consequences. I don't need to stress on this list what it means for LyX -- just from todays update of my distro I'm not capable to view most of my documents by default... Unfortuntaly there is very little we can directly for 2.3.1. We should at least signalize in announcement for distro maintainers that this *is* issue and perhaps add some hint how to allow users to locally enable things in policy.xml so they can continue their work. In longer-term -- if this ban continues -- we might try to ask Qt to do the conversions instead of imagemagick, but that's is definitely not for 2.3.1. Other ideas? Pavel https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/
Re: 2.3.1 Binaries
On Monday, 27 August 2018 19.41.26 WEST Richard Kimberly Heck wrote: > Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. > I suppose we should wait to prepare binaries until we have some feedback. > > Riki Compiled successfully on Fedora 27 to 30 (rawhide), as well as EL7, for all the supported architectures on copr: epel-7-ppc64le epel-7-x86_64 fedora-27-i386 fedora-27-ppc64le fedora-27-x86_64 fedora-28-i386 fedora-28-ppc64le fedora-28-x86_64 fedora-29-i386 fedora-29-ppc64le fedora-29-x86_64 fedora-rawhide-i386 fedora-rawhide-ppc64le fedora-rawhide-x86_64 For further details see: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/ -- José Abílio
Re: 2.3.1 Binaries
On Tue, Aug 28, 2018 at 05:20:38PM +0200, Jean-Pierre Chrétien wrote: > Le 27/08/2018 à 20:41, Richard Kimberly Heck a écrit : > > Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. > > I suppose we should wait to prepare binaries until we have some feedback. Compiles and works well in brief testing. Ubuntu 18.04.1 here, with TeX Live 2018. Configuration Host type: x86_64-pc-linux-gnu Special build flags: build=release std-regex use-hunspell use-enchant Bundled libraries:boost C++ Compiler:g++ (7) C++ Compiler flags: -O2 -std=c++14 C++ Compiler user flags: Linker flags: Linker user flags: Qt Frontend: Qt version: 4.8.7 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx I did get the following message: $ ./src/lyx Gtk-Message: 11:49:35.330: Failed to load module "canberra-gtk-module" After installing the packages libcanberra-gtk-module and libcanberra-gtk0, I no longer get that message. Scott signature.asc Description: PGP signature
Re: 2.3.1 Binaries
Le 27/08/2018 à 20:41, Richard Kimberly Heck a écrit : Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. I suppose we should wait to prepare binaries until we have some feedback. On Debian Stretch, with: Configuration Host type: x86_64-pc-linux-gnu Special build flags: build=release std-regex use-hunspell Bundled libraries:boost mythes C++ Compiler:g++ (6.3.0) C++ Compiler flags: -fPIC -O2 -std=c++14 C++ Compiler user flags: Linker flags: Linker user flags: Qt Frontend: Qt version: 5.7.1 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-2.3.1 compilation runs flawlessly, With TL18, Advanced, Customization and EmbeddeOnjects pdfcompile all right. UserGuide compilation is successful, with two warnings from the indexer: WARNING: Found no :close-range matching an already opened one! Location-reference is 20 in keyword (Environnements de paragraphe). Maybe I lost some of the regular location-references. WARNING: Found a :close-range in the index that wasn't opened before! Location-reference is 37 in keyword (Environnements de Paragraphe) I'll continue and ignore this. The index processor is texindy. -- Jean-Pierre
Re: 2.3.1 Binaries
Sorry, I meant tarballs On 08/27/2018 02:41 PM, Richard Kimberly Heck wrote: > Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. > I suppose we should wait to prepare binaries until we have some feedback. > > Riki > >
2.3.1 Binaries
Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. I suppose we should wait to prepare binaries until we have some feedback. Riki
Re: Translations for 2.3.1
Szőke Sándor wrote: > Dear Pavel, > > I have checked the strings, and found some deviations. I have corrected > them, but have not too much chance to check them in action now. > > Please see the strings in raw, also the updated .po file is attached. > > "Property"- Tulajdonság > "Solution"- Megoldás > "Listing" - Forráskód > "Listings" - Forráskódok > "List of Listings" - Forráskódok listája > "Nomenclature[[output]]" (The string that is output to PDF for the > nomenclature list) - Szakkifejezés[[output]] > "see equation[[nomencl]]" - lásd képlet[[nomencl]] > "page[[nomencl]]" - oldal[[nomencl]] Hi Alex, I took your changes and fixed couple of issues and committed both to 2.3 & 2.4. The changes to layouttranslation will be only part of 2.4 (we never change stable series for obvious reasons). You can see the layout changes in this patch: https://www.lyx.org/trac/changeset/30332ad2e7cd671021495d8adabcd415784d38e9/lyxgit Complete file is here: https://www.lyx.org/trac/browser/lyxgit/lib/layouttranslations?rev=30332ad2e7cd671021495d8adabcd415784d38e9 Hope this is the way you intended. Cheers, Pavel
Re: Translations for 2.3.1
Am Sonntag, 19. August 2018 15:46:30 CEST schrieb Szőke Sándor : > Something else: > Just before this check I found a strange bug in LyX, I was checked and > tried to update the hu version of splash.lyx (it is attached). > After openeing the file and clicking in the 3rd item in the ordered > list. Esp. into the "Dokumentum->Nézet [PDF (pdflatex)]" first word, and > right click than lyx hangs immediately. > I wanted to change the language to Hungarian. > It crash both locale English and Hungarian. (Hungarian is hu_HU.utf8) > You are right, the version is too new. It opens file with lyx2.4 though. Back-converted is fine. Kornel splash.lyx Description: application/lyx signature.asc Description: This is a digitally signed message part.
Strings Frozen for 2.3.1
I've asked our translators to do their work for 2.3.1, so no string-changing commits to 2.3.x until the release. Riki
Re: 2.3.1
On Mon, Jul 30, 2018 at 10:17:47AM +, Jean-Marc Lasgouttes wrote: > Le 30 juillet 2018 04:21:14 GMT+02:00, Richard Kimberly Heck > a écrit : > >Anyone have issues that need resolving before I freeze strings? > >Thinking > >to do that on Tuesday... > > > >Riki > > Not me. Nothing from me Scott signature.asc Description: PGP signature
Re: 2.3.1
Le 30 juillet 2018 04:21:14 GMT+02:00, Richard Kimberly Heck a écrit : >Anyone have issues that need resolving before I freeze strings? >Thinking >to do that on Tuesday... > >Riki Not me. JMarc
2.3.1
Anyone have issues that need resolving before I freeze strings? Thinking to do that on Tuesday... Riki
Re: LyX 2.3.1
Richard Kimberly Heck wrote: > >> Any disagreement? > > That sounds reasonable, but I don't recall many reports from users who > > have installed the 2.2.3 bundle and reported problems. I guess the > > problem comes if they try to update MiKTeX after installing the 2.2.3 > > bundle? > > The answer is back in that thread somewhere I actually looked it up and my understanding now is that 2.2.3 bundle is not problematic, only users who triggered update between October to January. Pavel
Re: LyX 2.3.1
On 05/15/2018 01:14 PM, Scott Kostyshak wrote: > On Tue, May 15, 2018 at 09:30:09AM +, Pavel Sanda wrote: >> Richard Kimberly Heck wrote: >>> I am working on this. I've managed to compile for Windows using mingw on >>> Linux (amazingly easy, actually) but have not dealt with the packaging >>> issues yet. Fortunately, someone who reported a bug to us seems as if >>> they may have done so and is giving me some help. >> Given latest developments we should at least take down bundle installer >> from web download section and advice users to install either texlive or >> miktex on their own because my understanding is that miktex contained >> in the bundle is broken so at least we stop spreading the buggy version. >> >> Any disagreement? > That sounds reasonable, but I don't recall many reports from users who > have installed the 2.2.3 bundle and reported problems. I guess the > problem comes if they try to update MiKTeX after installing the 2.2.3 > bundle? The answer is back in that thread somewhere I managed today to build a Windows installer, though for 2.4.dev. The not "bundled" one. I've got to backport the various changes I had to make to the build scripts, etc, and then I should be able to build an installer for 2.3.0. I guess I'll do the bundled one, too, if I can. The only difference is the installation of MikTeX. Riki
Re: LyX 2.3.1
On Tue, May 15, 2018 at 09:30:09AM +, Pavel Sanda wrote: > Richard Kimberly Heck wrote: > > I am working on this. I've managed to compile for Windows using mingw on > > Linux (amazingly easy, actually) but have not dealt with the packaging > > issues yet. Fortunately, someone who reported a bug to us seems as if > > they may have done so and is giving me some help. > > Given latest developments we should at least take down bundle installer > from web download section and advice users to install either texlive or > miktex on their own because my understanding is that miktex contained > in the bundle is broken so at least we stop spreading the buggy version. > > Any disagreement? That sounds reasonable, but I don't recall many reports from users who have installed the 2.2.3 bundle and reported problems. I guess the problem comes if they try to update MiKTeX after installing the 2.2.3 bundle? Scott signature.asc Description: PGP signature
Re: LyX 2.3.1
Richard Kimberly Heck wrote: > I am working on this. I've managed to compile for Windows using mingw on > Linux (amazingly easy, actually) but have not dealt with the packaging > issues yet. Fortunately, someone who reported a bug to us seems as if > they may have done so and is giving me some help. Given latest developments we should at least take down bundle installer from web download section and advice users to install either texlive or miktex on their own because my understanding is that miktex contained in the bundle is broken so at least we stop spreading the buggy version. Any disagreement? Pavel
Re: LyX 2.3.1
On 05/10/2018 02:37 PM, Richard Kimberly Heck wrote: > On 05/10/2018 11:41 AM, Kornel Benko wrote: >> Am Mittwoch, 9. Mai 2018 11:59:01 CEST schrieb Richard Kimberly Heck >> : >>> On 05/09/2018 11:18 AM, Pavel Sanda wrote: >>>> Jürgen Spitzmüller wrote: >>>>> 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: >>>>> >>>>>> I'm intending to close stable to string changes shortly, so we can move >>>>>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs >>>>>> doing before we notify the translators? >>>>>> >>>>> Any plans how to proceed with the Windows binaries? >>>> If Uwe definitively decided that no compromise is possible (I haven't seen >>>> such >>>> final announcement yet though) and intends to fork the installer to github >>>> we >>>> could simply state on the web that due to lack of manpower we do not offer >>>> official win installer any more and invite potential contributors to pick >>>> up >>>> the code & rebuild it. Sooner or later someone will pop up. >>>> >>>> If that sounds too harsh we could abandon the installer for the moment and >>>> publish just lyx binaries/lyx tree in zip archive and let interested users >>>> install the rest of the chain. That would take some initial effort but once >>>> done, should be easy to maintain for the subsequent stable releases. >>> I am working on this. I've managed to compile for Windows using mingw on >>> Linux (amazingly easy, actually) but have not dealt with the packaging >>> issues yet. Fortunately, someone who reported a bug to us seems as if >>> they may have done so and is giving me some help. >>> >>> Riki >>> >> Did you use cmake? (That is the script development/cmake/scripts/xmingw) >> If so, there should be created 'LyX24-2.4.0-win32.zip'. >> All needed files are also created in the directory 'LYX_INSTALLED' > No, I did not know about that. I just used the mingw-configure script > for autotools. I'll try the cmake version. This almost works now. I had to modify the xmingw script a bit, and I ran into a few other issues that I was able to solve. But now I'm stuck. At the very end, I get: /usr/bin/i686-w64-mingw32-g++ -Wall -Wunused-parameter --std=c++14 -fno-strict-aliasing -O2 -DNDEBUG -Wl,--whole-arceFiles/LyX.dir/objects.a -Wl,--no-whole-archive -o ../bin/LyX.exe -Wl,--out-implib,../bin/libLyX.dll.a -Wl,--major-iman,0,--minor-image-version,0 @CMakeFiles/LyX.dir/linklibs.rsp ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text+0x15fd0): undefined reference to `_imp___ZN8QEv' ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text$_ZN3lyx8frontend20QWindowsMimeMetafileD1Ev[__ontend20QWindowsMimeMetafileD1Ev]+0x8): undefined reference to `_imp___ZN8QWinMimeD2Ev' ../bin/libfrontend_qt.a(GuiApplication.cpp.obj):GuiApplication.cpp:(.text$_ZN3lyx8frontend20QWindowsMimeMetafileD0Ev[__ontend20QWindowsMimeMetafileD0Ev]+0xe): undefined reference to `_imp___ZN8QWinMimeD2Ev' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x72): undefined reference to `z_gzread' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x10c): undefined reference to `z_gzopen' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x182): undefined reference to `z_gzclose' ../bin/libsupport.a(gzstream.cpp.obj):gzstream.cpp:(.text+0x28e): undefined reference to `z_gzwrite' collect2: error: ld returned 1 exit status One of the problems I had, actually, was that #include was failing. I created symlinks to the right files, which I guess were in different directories from where they were expected to be. But now, it seems, the link is failing. I believe the wanted object is libQt5WinExtras.dll.a on this machine, and that is installed. The other problem seems to be with zlib. I've got libz.a and libz.dll.a in the appropriate place. This does work with the autotools build, so I've got the right things somewhere. Riki
Re: LyX 2.3.1
On 05/10/2018 11:41 AM, Kornel Benko wrote: > Am Mittwoch, 9. Mai 2018 11:59:01 CEST schrieb Richard Kimberly Heck > : >> On 05/09/2018 11:18 AM, Pavel Sanda wrote: >>> Jürgen Spitzmüller wrote: >>>> 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: >>>> >>>>> I'm intending to close stable to string changes shortly, so we can move >>>>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs >>>>> doing before we notify the translators? >>>>> >>>> Any plans how to proceed with the Windows binaries? >>> If Uwe definitively decided that no compromise is possible (I haven't seen >>> such >>> final announcement yet though) and intends to fork the installer to github >>> we >>> could simply state on the web that due to lack of manpower we do not offer >>> official win installer any more and invite potential contributors to pick up >>> the code & rebuild it. Sooner or later someone will pop up. >>> >>> If that sounds too harsh we could abandon the installer for the moment and >>> publish just lyx binaries/lyx tree in zip archive and let interested users >>> install the rest of the chain. That would take some initial effort but once >>> done, should be easy to maintain for the subsequent stable releases. >> I am working on this. I've managed to compile for Windows using mingw on >> Linux (amazingly easy, actually) but have not dealt with the packaging >> issues yet. Fortunately, someone who reported a bug to us seems as if >> they may have done so and is giving me some help. >> >> Riki >> > Did you use cmake? (That is the script development/cmake/scripts/xmingw) > If so, there should be created 'LyX24-2.4.0-win32.zip'. > All needed files are also created in the directory 'LYX_INSTALLED' No, I did not know about that. I just used the mingw-configure script for autotools. I'll try the cmake version. I've got Windows 10 running in a VM so I can test the binary there. Riki
Re: LyX 2.3.1
Am Mittwoch, 9. Mai 2018 11:59:01 CEST schrieb Richard Kimberly Heck
:
> On 05/09/2018 11:18 AM, Pavel Sanda wrote:
> > Jürgen Spitzmüller wrote:
> >> 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck:
> >>
> >>> I'm intending to close stable to string changes shortly, so we can move
> >>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs
> >>> doing before we notify the translators?
> >>>
> >> Any plans how to proceed with the Windows binaries?
> > If Uwe definitively decided that no compromise is possible (I haven't seen
> > such
> > final announcement yet though) and intends to fork the installer to github
> > we
> > could simply state on the web that due to lack of manpower we do not offer
> > official win installer any more and invite potential contributors to pick up
> > the code & rebuild it. Sooner or later someone will pop up.
> >
> > If that sounds too harsh we could abandon the installer for the moment and
> > publish just lyx binaries/lyx tree in zip archive and let interested users
> > install the rest of the chain. That would take some initial effort but once
> > done, should be easy to maintain for the subsequent stable releases.
>
> I am working on this. I've managed to compile for Windows using mingw on
> Linux (amazingly easy, actually) but have not dealt with the packaging
> issues yet. Fortunately, someone who reported a bug to us seems as if
> they may have done so and is giving me some help.
>
> Riki
>
Did you use cmake? (That is the script development/cmake/scripts/xmingw)
If so, there should be created 'LyX24-2.4.0-win32.zip'.
All needed files are also created in the directory 'LYX_INSTALLED'
Running
wine LYX_INSTALLED/bin/LyX.exe
starts lyx, but since I don't have python installed under wine, it is not
working.
...
support/Systemcall.cpp (270): Systemcall: 'python -tt
"Z:/BUILD/BUILDMint18/mingw/LYX_INSTALLED/Resources/configure.py"
--binary-dir="Z:/BUILD/BUILDMint18/mingw/LYX_INSTALLED/bin/"' did not start!
support/Systemcall.cpp (271): error The process failed to start. Either the
invoked program is missing, or you may have insufficient permissions to invoke
the program.
LyX: Fertig!
LayoutFile.cpp (111): LayoutFileList::Read: unable to find textclass file
`textclass.lst'.
LayoutFile.cpp (172): LayoutFileList::Read: no textclasses found!
ModuleList.cpp (129): unable to find modules file `lyxmodules.lst'.
No modules will be available.
CiteEnginesList.cpp (174): unable to find cite engines file `citeengines.lst'.
No cite engines will be available.
fixme:ole:RemUnknown_QueryInterface No interface for iid
{0019---c000-0046}
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: LyX 2.3.1
Le 09/05/2018 à 03:45, Richard Kimberly Heck a écrit : 6df8c42e59f7d 7bcb78a77875ec 90cfe4ec3b4ff2 Those would be fine with me. Thanks, they are in now. JMarc
Re: LyX 2.3.1
On 05/09/2018 11:18 AM, Pavel Sanda wrote: > Jürgen Spitzmüller wrote: >> 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: >> >>> I'm intending to close stable to string changes shortly, so we can move >>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs >>> doing before we notify the translators? >>> >> Any plans how to proceed with the Windows binaries? > If Uwe definitively decided that no compromise is possible (I haven't seen > such > final announcement yet though) and intends to fork the installer to github we > could simply state on the web that due to lack of manpower we do not offer > official win installer any more and invite potential contributors to pick up > the code & rebuild it. Sooner or later someone will pop up. > > If that sounds too harsh we could abandon the installer for the moment and > publish just lyx binaries/lyx tree in zip archive and let interested users > install the rest of the chain. That would take some initial effort but once > done, should be easy to maintain for the subsequent stable releases. I am working on this. I've managed to compile for Windows using mingw on Linux (amazingly easy, actually) but have not dealt with the packaging issues yet. Fortunately, someone who reported a bug to us seems as if they may have done so and is giving me some help. Riki
Re: LyX 2.3.1
Jürgen Spitzmüller wrote: > 2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: > > > I'm intending to close stable to string changes shortly, so we can move > > toward 2.3.1. We have a LOT of bug fixes already. Anything that needs > > doing before we notify the translators? > > > > Any plans how to proceed with the Windows binaries? If Uwe definitively decided that no compromise is possible (I haven't seen such final announcement yet though) and intends to fork the installer to github we could simply state on the web that due to lack of manpower we do not offer official win installer any more and invite potential contributors to pick up the code & rebuild it. Sooner or later someone will pop up. If that sounds too harsh we could abandon the installer for the moment and publish just lyx binaries/lyx tree in zip archive and let interested users install the rest of the chain. That would take some initial effort but once done, should be easy to maintain for the subsequent stable releases. Pavel
Re: LyX 2.3.1
2018-05-06 19:50 GMT+02:00 Richard Kimberly Heck: > I'm intending to close stable to string changes shortly, so we can move > toward 2.3.1. We have a LOT of bug fixes already. Anything that needs > doing before we notify the translators? > Any plans how to proceed with the Windows binaries? Jürgen > > Riki > > >
Re: LyX 2.3.1
Le 09/05/2018 à 09:36, Pavel Sanda a écrit : Those would be fine with me. JMarc? P Yes, I am here :) I am busy today, but may manage to do that on Thursday or Friday. JMarc
Re: LyX 2.3.1
Richard Kimberly Heck wrote: > On 05/08/2018 06:47 PM, Pavel Sanda wrote: > > Richard Kimberly Heck wrote: > >> On 05/08/2018 05:30 AM, Pavel Sanda wrote: > >>> Richard Kimberly Heck wrote: > >>>> I'm intending to close stable to string changes shortly, so we can move > >>>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs > >>>> doing before we notify the translators? > >>> Not related to translations, but given mathed still needs some testing > >>> after last patches, what about merging those few regarding cursor size? > >> Which commits do you have in mind? > > 6df8c42e59f7d 7bcb78a77875ec 90cfe4ec3b4ff2 > > Those would be fine with me. JMarc? P
Re: LyX 2.3.1
On 05/08/2018 06:47 PM, Pavel Sanda wrote: > Richard Kimberly Heck wrote: >> On 05/08/2018 05:30 AM, Pavel Sanda wrote: >>> Richard Kimberly Heck wrote: >>>> I'm intending to close stable to string changes shortly, so we can move >>>> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs >>>> doing before we notify the translators? >>> Not related to translations, but given mathed still needs some testing >>> after last patches, what about merging those few regarding cursor size? >> Which commits do you have in mind? > 6df8c42e59f7d 7bcb78a77875ec 90cfe4ec3b4ff2 Those would be fine with me. Riki
Re: LyX 2.3.1
Richard Kimberly Heck wrote: > On 05/08/2018 05:30 AM, Pavel Sanda wrote: > > Richard Kimberly Heck wrote: > >> I'm intending to close stable to string changes shortly, so we can move > >> toward 2.3.1. We have a LOT of bug fixes already. Anything that needs > >> doing before we notify the translators? > > Not related to translations, but given mathed still needs some testing > > after last patches, what about merging those few regarding cursor size? > > Which commits do you have in mind? 6df8c42e59f7d 7bcb78a77875ec 90cfe4ec3b4ff2 Pavel
